From cmadams at hiwaay.net Thu May 1 01:44:11 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 30 Apr 2008 20:44:11 -0500 Subject: is xorg.conf still needed In-Reply-To: <20080430144321.GC1158623@hiwaay.net> References: <1209523940.2906.136.camel@localhost.localdomain> <1209524701.22831.136.camel@aglarond.local> <870180fe0804292031o12327456v8a6af99e71de253@mail.gmail.com> <200804300858.m3U8wCb8018427@tiffany.internal.tigress.co.uk> <20080430141231.GB1158623@hiwaay.net> <1209565903.22831.166.camel@aglarond.local> <20080430144321.GC1158623@hiwaay.net> Message-ID: <20080501014410.GA1394277@hiwaay.net> Once upon a time, Chris Adams said: > Once upon a time, Jeremy Katz said: > > On Wed, 2008-04-30 at 09:12 -0500, Chris Adams wrote: > > > I discovered that in Rawhide (from last week sometime IIRC), the > > > installer will crash if you use a USB KVM switch and switch away > > > (because the USB devices go away; I guess the installer can't handle > > > hot-plug). I have not filed a bug yet because I only hit it once and > > > didn't have any time to reproduce. > > > > It got filed and I'm pretty sure should be fixed in current rawhide > > Thanks (sorry I didn't get it filed myself). I'll give it a try > tonight and file/re-open if I still see a problem Nope, it still crashes for me. I didn't find the existing bug (probably looking for the wrong thing), so I went ahead and opened a new one: https://bugzilla.redhat.com/show_bug.cgi?id=444844 -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From invite+zc4ozzc6 at facebookmail.com Thu May 1 02:28:31 2008 From: invite+zc4ozzc6 at facebookmail.com (Mahesh Kumar Joshi) Date: Wed, 30 Apr 2008 19:28:31 -0700 Subject: Check out my Facebook profile Message-ID: <660d6ac9e2fc8e9633b937c6bc4a2504@register.facebook.com> I set up a Facebook profile where I can post my pictures, videos and events and I want to add you as a friend so you can see it. First, you need to join Facebook! Once you join, you can also create your own profile. Thanks, Mahesh Here's the link: http://www.facebook.com/p.php?i=1262521521&k=XWCY6V65T3YM51B1XA5XY3&r&v=2 ___________________ This e-mail may contain promotional materials. If you do not wish to receive future commercial mailings from Facebook, please click on the link below. Facebook's offices are located at 156 University Ave., Palo Alto, CA 94301. http://www.facebook.com/o.php?u=1260931488&k=ee7eb2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From seg at haxxed.com Thu May 1 02:50:41 2008 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 30 Apr 2008 21:50:41 -0500 Subject: Check out my Facebook profile In-Reply-To: <660d6ac9e2fc8e9633b937c6bc4a2504@register.facebook.com> References: <660d6ac9e2fc8e9633b937c6bc4a2504@register.facebook.com> Message-ID: <1209610241.4950.89.camel@localhost> New Mugshot user? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kevin.kofler at chello.at Thu May 1 03:44:51 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 1 May 2008 03:44:51 +0000 (UTC) Subject: Multilib Middle-Ground References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> Message-ID: Colin Walters verbum.org> writes: > The right way to approach this I think is to target specific third > party applications which we want to work out of the box. Say for > example, Flash and VMWare Workstation. Surely there are others, but I > think we can arrive at a reasonably sane set. We then add these > packages to the default install image. How about the empty set? We should only support properly-packaged RPMs, which will drag in these dependencies if they're installed (from a valid repository or using something like yum localinstall), if the proprietary applications don't want to provide them, why should we care? The KDE Live image is at the limit of CD size, every compat cruft package added is an application we have to remove to compensate for the size, why should we remove useful applications or go over the standard 700 MB CD size to accomodate proprietary crap which we can't ship and which isn't even packaged properly? Kevin Kofler From kevin.kofler at chello.at Thu May 1 03:46:41 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 1 May 2008 03:46:41 +0000 (UTC) Subject: Multilib Middle-Ground References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> Message-ID: Warren Togami redhat.com> writes: > Perhaps we need a third option like "smart" which uses a multilib > whitelist that can be updated via repodata. Anaconda and other GUI > interfaces can allow the user to choose between "smart" and "100% i386 > free". FYI, the KDE Live image for x86_64 is somewhere around 697 to 698 MB, even just glibc.i686 will likely make it go over CD size! Kevin Kofler From dwight at supercomputer.org Thu May 1 03:29:10 2008 From: dwight at supercomputer.org (dwight at supercomputer.org) Date: Wed, 30 Apr 2008 19:29:10 -0800 Subject: is xorg.conf still needed In-Reply-To: <7amle5xkvo.ln2@ppp1053.in.ipex.cz> References: <1209523940.2906.136.camel@localhost.localdomain> <7amle5xkvo.ln2@ppp1053.in.ipex.cz> Message-ID: <200804302029.10986.dwight@supercomputer.org> On Wednesday 30 April 2008 01:13:27 am Matej Cepl wrote: > The whole truth is that we are on the way towards Stateless Linux > (which means here xorg.conf-less X), but we are not there yet. To > be honest, the way is long and the question is whether we will > arrive at Fedora 10 or later. > ... Are we really? Upon what do you base that statement? I'd be very interested in knowing more, because the Stateless Linux mailing list looks rather inactive. Is there a roadmap? And what's the current status? I'd also interested in contributing if I could, because I've found portions of it to be extremely useful. I daresay critical for certain next-generation embedded Linux platforms. It would be great if progress could be made by Fedora 10, and it would be a real shame if that opportunity were lost. Especially since Microsoft is picking up steam in this embedded space, from what I've seen. -dwight- From seg at haxxed.com Thu May 1 05:28:52 2008 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 01 May 2008 00:28:52 -0500 Subject: is xorg.conf still needed In-Reply-To: <200804302029.10986.dwight@supercomputer.org> References: <1209523940.2906.136.camel@localhost.localdomain> <7amle5xkvo.ln2@ppp1053.in.ipex.cz> <200804302029.10986.dwight@supercomputer.org> Message-ID: <1209619732.4950.96.camel@localhost> On Wed, 2008-04-30 at 19:29 -0800, dwight at supercomputer.org wrote: > On Wednesday 30 April 2008 01:13:27 am Matej Cepl wrote: > > > The whole truth is that we are on the way towards Stateless Linux > > (which means here xorg.conf-less X), but we are not there yet. To > > be honest, the way is long and the question is whether we will > > arrive at Fedora 10 or later. > > ... > > Are we really? Upon what do you base that statement? I'd be very > interested in knowing more, because the Stateless Linux mailing list > looks rather inactive. Is there a roadmap? And what's the current > status? We're on our way to the Online Desktop, in which the operating system itself starts to barely matter at all. (Which should draw people to Linux since its cheap and reliable, right? :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From pemboa at gmail.com Thu May 1 06:15:33 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 1 May 2008 01:15:33 -0500 Subject: is xorg.conf still needed In-Reply-To: <1209619732.4950.96.camel@localhost> References: <1209523940.2906.136.camel@localhost.localdomain> <7amle5xkvo.ln2@ppp1053.in.ipex.cz> <200804302029.10986.dwight@supercomputer.org> <1209619732.4950.96.camel@localhost> Message-ID: <16de708d0804302315kcbc6395n1feb0b978fac3ee5@mail.gmail.com> 2008/5/1 Callum Lerwick : > On Wed, 2008-04-30 at 19:29 -0800, dwight at supercomputer.org wrote: > > On Wednesday 30 April 2008 01:13:27 am Matej Cepl wrote: > > > > > The whole truth is that we are on the way towards Stateless Linux > > > (which means here xorg.conf-less X), but we are not there yet. To > > > be honest, the way is long and the question is whether we will > > > arrive at Fedora 10 or later. > > > ... > > > > Are we really? Upon what do you base that statement? I'd be very > > interested in knowing more, because the Stateless Linux mailing list > > looks rather inactive. Is there a roadmap? And what's the current > > status? > > We're on our way to the Online Desktop, in which the operating system > itself starts to barely matter at all. (Which should draw people to > Linux since its cheap and reliable, right? :) Do not believe that this is true at all. But ok. All that will mean is that every one will be using Windows Live, and there will be even less of a market for Linux... I guess that's all off-topic however. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From dwmw2 at infradead.org Thu May 1 07:41:07 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 01 May 2008 08:41:07 +0100 Subject: Multilib Middle-Ground In-Reply-To: <1209579738.8968.153.camel@cutter> References: <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <1209574089.8968.129.camel@cutter> <4818B000.9030001@redhat.com> <1209577677.8968.139.camel@cutter> <4818B396.1070208@redhat.com> <1209578647.8968.145.camel@cutter> <20080430181814.GK2255@devserv.devel.redhat.com> <1209579738.8968.153.camel@cutter> Message-ID: <1209627667.25560.470.camel@pmac.infradead.org> On Wed, 2008-04-30 at 14:22 -0400, seth vidal wrote: > > You'll note the default behavior in F9 is not install any i386 pkgs > unless explicitly asked for (or as a dependency). > > If you want to have dependencies have arch-specific information in > them then, again, we need to talk about that at the rpm layer. I believe this has already been implemented in RPM. https://bugzilla.redhat.com/show_bug.cgi?id=235755 http://devel.linux.duke.edu/gitweb/?p=rpm.git;a=commitdiff;h=48ff62a5291458ed1181cd6c31dcadb193ad2f8e -- dwmw2 From lordmorgul at gmail.com Thu May 1 08:41:24 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Thu, 01 May 2008 01:41:24 -0700 Subject: Multilib Middle-Ground In-Reply-To: References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> Message-ID: <48198234.4040304@gmail.com> Kevin Kofler wrote: > Colin Walters verbum.org> writes: >> The right way to approach this I think is to target specific third >> party applications which we want to work out of the box. Say for >> example, Flash and VMWare Workstation. Surely there are others, but I >> think we can arrive at a reasonably sane set. We then add these >> packages to the default install image. > > How about the empty set? We should only support properly-packaged RPMs, which > will drag in these dependencies if they're installed (from a valid repository > or using something like yum localinstall), if the proprietary applications > don't want to provide them, why should we care? > > The KDE Live image is at the limit of CD size, every compat cruft package added > is an application we have to remove to compensate for the size, why should we > remove useful applications or go over the standard 700 MB CD size to accomodate > proprietary crap which we can't ship and which isn't even packaged properly? Gross exaggeration... 'default install image' doesn't have to mean Live CDs. Also are you actually suggesting that it would be best for those proprietary applications to ship their own libraries because Fedora makes it difficult to get their applications to work on x86_64 boxes due to the company being forced to figure out what i386 rpms they have to explicitly require on those machines... in Fedora... and not in other rpm based distros? You've got to be kidding. -- Andrew Farris www.lordmorgul.net gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29 From paul at city-fan.org Thu May 1 09:14:07 2008 From: paul at city-fan.org (Paul Howarth) Date: Thu, 01 May 2008 10:14:07 +0100 Subject: Multilib Middle-Ground In-Reply-To: <48198234.4040304@gmail.com> References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> Message-ID: <481989DF.30304@city-fan.org> Andrew Farris wrote: > Kevin Kofler wrote: >> Colin Walters verbum.org> writes: >>> The right way to approach this I think is to target specific third >>> party applications which we want to work out of the box. Say for >>> example, Flash and VMWare Workstation. Surely there are others, but I >>> think we can arrive at a reasonably sane set. We then add these >>> packages to the default install image. >> >> How about the empty set? We should only support properly-packaged >> RPMs, which will drag in these dependencies if they're installed (from >> a valid repository or using something like yum localinstall), if the >> proprietary applications don't want to provide them, why should we care? >> >> The KDE Live image is at the limit of CD size, every compat cruft >> package added is an application we have to remove to compensate for >> the size, why should we remove useful applications or go over the >> standard 700 MB CD size to accomodate proprietary crap which we can't >> ship and which isn't even packaged properly? > > Gross exaggeration... 'default install image' doesn't have to mean Live > CDs. Also are you actually suggesting that it would be best for those > proprietary applications to ship their own libraries because Fedora > makes it difficult to get their applications to work on x86_64 boxes due > to the company being forced to figure out what i386 rpms they have to > explicitly require on those machines... in Fedora... and not in other > rpm based distros? You've got to be kidding. $ rpm -qp --requires VMware-server-1.0.5-80187.i386.rpm /bin/sh Does that look like a properly-package RPM to you? No soname deps whatsoever? Paul. From opensource at till.name Thu May 1 09:15:25 2008 From: opensource at till.name (Till Maas) Date: Thu, 01 May 2008 11:15:25 +0200 Subject: Adding /sbin and /usr/sbin to everyone's path in F10 In-Reply-To: References: <1208964631.12717.158.camel@localhost.localdomain> <4811D4CF.4010902@gmail.com> Message-ID: <200805011115.31227.opensource@till.name> On Fri April 25 2008, max bianco wrote: > because using fdisk, for example, implies a certain level of > knowledge. If i fdisk incorrectly i will hose my system beyond my > ability to repair it or i will get access denied or you aren't root or > whatever you like and be just as annoyed that it let me get that far > only to stop me when I try to use it, "If i can't use the tool then > why oh why is it in my path?You've handed me a nail and no hammer!" or > do you think the "average" user should be using fdisk unsupervised? Why do these uses not say "If this tool is not in my path, why is it installed?"? Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From kevin.kofler at chello.at Thu May 1 09:22:08 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 1 May 2008 09:22:08 +0000 (UTC) Subject: Multilib Middle-Ground References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> Message-ID: Andrew Farris gmail.com> writes: > Gross exaggeration... 'default install image' doesn't have to mean Live CDs. > Also are you actually suggesting that it would be best for those proprietary > applications to ship their own libraries because Fedora makes it difficult to > get their applications to work on x86_64 boxes due to the company being > forced to figure out what i386 rpms they have to explicitly require on those > machines... in Fedora... and not in other rpm based distros? You've got to > be kidding. They're not forced to explicitly require anything, just not explicitly turn off the RPM feature which AUTOMATICALLY adds those Requires, in a way which: * is only fulfilled by the correct architecture package of the dependency, because RPM uses libfoo.so.1 for 32-bit and libfoo.so.1()(64bit) for 64-bit dependencies, * works fully across (RPM-based) distributions, because it doesn't require a particular package name, but an soname. And the application won't run anyway if you don't have a library with that soname (which is the whole reason why compat-libstdc++ is needed), so if one distro has libfoo.so.1 and another has libfoo.so.2, omitting the automatic dependencies won't solve the problem, it will just make the application error at runtime rather than at install-time (which sucks, why wait until runtime to report a problem which can be detected during installation?). Kevin Kofler From lordmorgul at gmail.com Thu May 1 09:34:24 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Thu, 01 May 2008 02:34:24 -0700 Subject: Multilib Middle-Ground In-Reply-To: <481989DF.30304@city-fan.org> References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> Message-ID: <48198EA0.5070904@gmail.com> Paul Howarth wrote: > Andrew Farris wrote: >> Kevin Kofler wrote: >>> Colin Walters verbum.org> writes: >>>> The right way to approach this I think is to target specific third >>>> party applications which we want to work out of the box. Say for >>>> example, Flash and VMWare Workstation. Surely there are others, but I >>>> think we can arrive at a reasonably sane set. We then add these >>>> packages to the default install image. >>> >>> How about the empty set? We should only support properly-packaged >>> RPMs, which will drag in these dependencies if they're installed >>> (from a valid repository or using something like yum localinstall), >>> if the proprietary applications don't want to provide them, why >>> should we care? >>> >>> The KDE Live image is at the limit of CD size, every compat cruft >>> package added is an application we have to remove to compensate for >>> the size, why should we remove useful applications or go over the >>> standard 700 MB CD size to accomodate proprietary crap which we can't >>> ship and which isn't even packaged properly? >> >> Gross exaggeration... 'default install image' doesn't have to mean >> Live CDs. Also are you actually suggesting that it would be best for >> those proprietary applications to ship their own libraries because >> Fedora makes it difficult to get their applications to work on x86_64 >> boxes due to the company being forced to figure out what i386 rpms >> they have to explicitly require on those machines... in Fedora... and >> not in other rpm based distros? You've got to be kidding. > > $ rpm -qp --requires VMware-server-1.0.5-80187.i386.rpm > /bin/sh > > Does that look like a properly-package RPM to you? No soname deps > whatsoever? No, it doesn't, which is exactly my point... the harder, or more explicitly, anything must be done to distribute proprietary software... the more likely it will be done with a shell script which spews files all over the place. You don't get proprietary software to work nicely with package management systems by making it even harder. What I'm suggesting is that finding a more inclusive solution to the multilib issue for those applications that need it would be VALUABLE; I'm not suggesting its necessary, or that it really is the free-software world's problem to fix alone. What Kevin seems to be saying is screw proprietary software let it just not work... and thats just a bad plan. Proprietary software SHOULD be shipped as cleanly as possible for the target systems, but if that is difficult to do for the software engineers at those companies, and its hard to maintain, then it WILL be shipped with shell scripts and libraries all embedded in the application. It will be spewing files all over the place, causing library conflicts, and ultimately making Fedora look bad, not the other way around. If the libraries are easy to get put in place, then the system libraries might actually get used, and properly packaged proprietary software might get distributed. If the opposite is true for the libraries, then can you even hope well packaged applications will be shipped from those vendors? -- Andrew Farris www.lordmorgul.net gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29 From paul at city-fan.org Thu May 1 10:12:26 2008 From: paul at city-fan.org (Paul Howarth) Date: Thu, 01 May 2008 11:12:26 +0100 Subject: Multilib Middle-Ground In-Reply-To: <48198EA0.5070904@gmail.com> References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> Message-ID: <4819978A.80304@city-fan.org> Andrew Farris wrote: > Paul Howarth wrote: >> Andrew Farris wrote: >>> Kevin Kofler wrote: >>>> Colin Walters verbum.org> writes: >>>>> The right way to approach this I think is to target specific third >>>>> party applications which we want to work out of the box. Say for >>>>> example, Flash and VMWare Workstation. Surely there are others, but I >>>>> think we can arrive at a reasonably sane set. We then add these >>>>> packages to the default install image. >>>> >>>> How about the empty set? We should only support properly-packaged >>>> RPMs, which will drag in these dependencies if they're installed >>>> (from a valid repository or using something like yum localinstall), >>>> if the proprietary applications don't want to provide them, why >>>> should we care? >>>> >>>> The KDE Live image is at the limit of CD size, every compat cruft >>>> package added is an application we have to remove to compensate for >>>> the size, why should we remove useful applications or go over the >>>> standard 700 MB CD size to accomodate proprietary crap which we >>>> can't ship and which isn't even packaged properly? >>> >>> Gross exaggeration... 'default install image' doesn't have to mean >>> Live CDs. Also are you actually suggesting that it would be best for >>> those proprietary applications to ship their own libraries because >>> Fedora makes it difficult to get their applications to work on x86_64 >>> boxes due to the company being forced to figure out what i386 rpms >>> they have to explicitly require on those machines... in Fedora... and >>> not in other rpm based distros? You've got to be kidding. >> >> $ rpm -qp --requires VMware-server-1.0.5-80187.i386.rpm >> /bin/sh >> >> Does that look like a properly-package RPM to you? No soname deps >> whatsoever? > > No, it doesn't, which is exactly my point... the harder, or more > explicitly, anything must be done to distribute proprietary software... > the more likely it will be done with a shell script which spews files > all over the place. > > You don't get proprietary software to work nicely with package > management systems by making it even harder. What I'm suggesting is > that finding a more inclusive solution to the multilib issue for those > applications that need it would be VALUABLE; I'm not suggesting its > necessary, or that it really is the free-software world's problem to fix > alone. What Kevin seems to be saying is screw proprietary software let > it just not work... and thats just a bad plan. > > Proprietary software SHOULD be shipped as cleanly as possible for the > target systems, but if that is difficult to do for the software > engineers at those companies, and its hard to maintain, then it WILL be > shipped with shell scripts and libraries all embedded in the > application. It will be spewing files all over the place, causing > library conflicts, and ultimately making Fedora look bad, not the other > way around. > > If the libraries are easy to get put in place, then the system libraries > might actually get used, and properly packaged proprietary software > might get distributed. If the opposite is true for the libraries, then > can you even hope well packaged applications will be shipped from those > vendors? VMware does use (mainly) system libraries but for some reason the dependencies on those libraries (by soname, not packagename) as created automatically by RPM are filtered out of the VMware package. If they had been left in, as they would be without what must be manual filtering, then yum would be able to pull in those libraries automatically. I think we are all actually in violent agreement here, it's just that some proprietary vendors seem to go out of their way to defeat the dependency mechanisms that would help tools like yum install their software. Paul. From billcrawford1970 at gmail.com Thu May 1 10:09:42 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Thu, 1 May 2008 11:09:42 +0100 Subject: Multilib Middle-Ground In-Reply-To: <48198EA0.5070904@gmail.com> References: <4817FF36.10305@redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> Message-ID: <544eb990805010309u3849d73aqbdb8016d113ee1d4@mail.gmail.com> On 01/05/2008, Andrew Farris wrote: > If the libraries are easy to get put in place, then the system libraries > might actually get used, and properly packaged proprietary software might > get distributed. If the opposite is true for the libraries, then can you > even hope well packaged applications will be shipped from those vendors? They are deliberately bypassing the mechanisms to make that possible. From j.w.r.degoede at hhs.nl Thu May 1 10:32:38 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 01 May 2008 12:32:38 +0200 Subject: Review swapsies Message-ID: <48199C46.1070903@hhs.nl> Hi, I've this small game I would like to have reviewed: https://bugzilla.redhat.com/show_bug.cgi?id=442022 Its a nice and simple review, anyone want to swap? Regards, Hans From jdieter at gmail.com Thu May 1 10:48:40 2008 From: jdieter at gmail.com (Jonathan Dieter) Date: Thu, 01 May 2008 13:48:40 +0300 Subject: Review swapsies In-Reply-To: <48199C46.1070903@hhs.nl> References: <48199C46.1070903@hhs.nl> Message-ID: <1209638920.2197.1.camel@localhost.localdomain> On Thu, 2008-05-01 at 12:32 +0200, Hans de Goede wrote: > Hi, > > I've this small game I would like to have reviewed: > https://bugzilla.redhat.com/show_bug.cgi?id=442022 > > Its a nice and simple review, anyone want to swap? I don't have anything awaiting review, but I wouldn't mind reviewing it. Just a heads up that this will be the first package I've reviewed (somehow I managed to get yum-presto reviewed without reviewing something else first). Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From alain.portal at free.fr Thu May 1 10:51:45 2008 From: alain.portal at free.fr (Alain PORTAL) Date: Thu, 1 May 2008 12:51:45 +0200 Subject: Orphaning package In-Reply-To: <1209214191.2946.64.camel@vader.jdub.homelinux.org> References: <200804260011.34138.alain.portal@free.fr> <1209214191.2946.64.camel@vader.jdub.homelinux.org> Message-ID: <200805011251.46026.alain.portal@free.fr> Le samedi 26 avril 2008, Josh Boyer a ?crit : > Can you email the issues you're having to > fedora-extras-steering at redhat.com please? Perhaps we can look them over > and find an amicable way to solve them for everyone involved. Finally, mailing to fedora-extras-steering at redhat.com became uneeded as the major issue is now solved. I want to particulary thank Tom "spot" Callaway, who is a great and stubborn mediator, and Paul W. Frields, who both got involved to solve these issues. I want also thank every body who mailed me. Be sure Josh that if I get other similar problems, I'll mail to FESCO. Regards, Alain -- Les pages de manuel Linux en fran?ais http://manpagesfr.free.fr/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From pingou at pingoured.fr Thu May 1 10:56:13 2008 From: pingou at pingoured.fr (pingou) Date: Thu, 01 May 2008 12:56:13 +0200 Subject: Orphaning package In-Reply-To: <200805011251.46026.alain.portal@free.fr> References: <200804260011.34138.alain.portal@free.fr> <1209214191.2946.64.camel@vader.jdub.homelinux.org> <200805011251.46026.alain.portal@free.fr> Message-ID: <4819A1CD.3030704@pingoured.fr> Alain PORTAL wrote: > Le samedi 26 avril 2008, Josh Boyer a ?crit : > >> Can you email the issues you're having to >> fedora-extras-steering at redhat.com please? Perhaps we can look them over >> and find an amicable way to solve them for everyone involved. > > Finally, mailing to fedora-extras-steering at redhat.com became uneeded as the > major issue is now solved. > I want to particulary thank Tom "spot" Callaway, who is a great and stubborn > mediator, and Paul W. Frields, who both got involved to solve these issues. Glad to have you back :) "From the diversity comes the power" Regards, Pierre From pertusus at free.fr Thu May 1 11:02:59 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 1 May 2008 13:02:59 +0200 Subject: searching for co-maintainers for my packages Message-ID: <20080501110259.GA2583@free.fr> Hello, I am going to be in vacations and I have a bunch of packages without co-maintainer. I will remain maintainer, and in general I am in contact with upstream, but who knows, and I think it is better to always have co-maintainers. Would somebody be interested? Normal (or complex) packages: * cernlib -- General purpose CERN library * cernlib-g77 -- General purpose CERN library * gnash -- GNU flash movie player * grads -- Tool for easy acces, manipulation, and visualization of data * kchmviewer -- CHM viewer with KDE support * tetex-tex4ht -- Translates TeX and LaTeX into HTML or XML+MathML Same here, and additionally this is an interdependent stack (currently most don't build, waiting for upstream release for libnc-dap). * bes -- Back-end server software framework for OPeNDAP * dap-freeform_handler -- FreeForm data handler for the OPeNDAP Data server * dap-hdf4_handler -- HDF4 data handler for the OPeNDAP Data server * dap-netcdf_handler -- NetCDF 3 data handler for the OPeNDAP Data server * dap-server -- Basic request handling for OPeNDAP servers * libdap -- The C++ DAP2 library from OPeNDAP * libnc-dap -- The NetCDF interface to DAP-2 from OPeNDAP The remaining are very low work (or no work) * acpi -- Command-line ACPI client * acpitool -- A command line ACPI client for Linux * agg -- Anti-Grain Geometry * archmage -- Extensible reader/decompiler of files in CHM format * asa -- Convert Fortran carriage control characters * bibexport -- Extract entries from BibTeX and .aux files * BibTool -- A Tool for manipulating BibTeX data bases * bitmap -- Bitmap editor and converter utilities for the X Window System * boolstuff -- Disjunctive Normal Form boolean expression library * cppunit -- C++ unit testing framework * docbook2X -- Convert docbook into man and Texinfo * esmtp -- User configurable relay-only Mail Transfer Agent (MTA) * flasm -- Flash bytecode assembler disassembler * g2clib -- GRIB2 encoder/decoder and search/indexing routines in C * gnochm -- CHM file viewer * halevt -- Generic handler for HAL events * intuitively -- Automatic IP detection utility * libchmxx -- C++ bindings for chmlib * libdockapp -- DockApp Development Standard Library * libesmtp -- SMTP client library * libnet -- C library for portable packet creation and injection * libnet10 -- High-level API (toolkit) to construct and inject network packets * libsx -- Simple X library * ooo2txt -- Convert OpenOffice documents to simple text * pam_ssh -- PAM module for use with SSH keys and ssh-agent * perl-Algorithm-CurveFit -- Nonlinear Least Squares Curve Fitting * perl-Cache -- The Cache interface * perl-Feed-Find -- Syndication feed auto-discovery * perl-File-BaseDir -- Use the freedesktop basedir spec * perl-File-DesktopEntry -- Object to handle .desktop files * perl-File-MimeInfo -- Determine file type and open application * perl-File-NFSLock -- Perl module to do NFS (or not) locking * perl-Heap -- Perl extension for keeping data partially sorted * perl-HTML-FormatText-WithLinks -- HTML to text conversion with links as footnotes * perl-LWP-Authen-Wsse -- Library for enabling X-WSSE authentication in LWP * perl-Math-MatrixReal -- Manipulate matrix of Reals * perl-Math-Symbolic -- Symbolic calculations * perl-Parse-Yapp -- Perl extension for generating and using LALR parsers * perl-Statistics-Descriptive -- Perl module of basic descriptive statistical functions * perl-Text-CHM -- Perl extension for handling MS Compiled HtmlHelp Files * perl-Text-Unidecode -- US-ASCII transliterations of Unicode text * pmount -- Enable normal user mount * python-chm -- Python package for CHM files handling * tetex-elsevier -- Elsevier LaTeX style files and documentation * tetex-lineno -- Add line numbers on paragraphs in LaTeX * uread -- Utilities for unformatted fortran files * wdm -- WINGs Display Manager * wmix -- Dockapp mixer * xbae -- Motif matrix, caption and text input widgets * xchm -- A GUI front-end to CHMlib -- Pat From k.georgiou at imperial.ac.uk Thu May 1 11:05:30 2008 From: k.georgiou at imperial.ac.uk (Kostas Georgiou) Date: Thu, 1 May 2008 12:05:30 +0100 Subject: Multilib Middle-Ground In-Reply-To: <604aa7910804301429k472cc2bcq8f9a06c1acd70b33@mail.gmail.com> References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <604aa7910804301429k472cc2bcq8f9a06c1acd70b33@mail.gmail.com> Message-ID: <20080501110530.GA25448@imperial.ac.uk> On Wed, Apr 30, 2008 at 01:29:40PM -0800, Jeff Spaleta wrote: > On Wed, Apr 30, 2008 at 12:27 PM, Colin Walters wrote: > > The right way to approach this I think is to target specific third > > party applications which we want to work out of the box. Say for > > example, Flash and VMWare Workstation. Surely there are others, but I > > think we can arrive at a reasonably sane set. We then add these > > packages to the default install image. > > Would you include the following in your "sane" set? > > MatLab > Mathematica > nag.com library products There are 64bit versions of both so there is no need to install the 32bit vesrions. > any number of proprietary fortran and C compilers Most of them will also have 64bit versions as well. > IDL > LabView > SAS/IML and SAS/STAT No idea but I will not be surprised if 64bit versions are available for them as well. Most often than not they don't run out of the box in fedora without some playing around anyway (you have to label some libs textrel_shlib_t, provide links for things like /usr/share/X11/rgb.txt because they ship their own version of libX11 which expects files under /usr/X11R6 etc.) Kostas From balajig81 at gmail.com Thu May 1 11:07:30 2008 From: balajig81 at gmail.com (G) Date: Thu, 1 May 2008 16:37:30 +0530 Subject: searching for co-maintainers for my packages In-Reply-To: <20080501110259.GA2583@free.fr> References: <20080501110259.GA2583@free.fr> Message-ID: <6dd1343e0805010407l29174de1tcb1358715322d5a@mail.gmail.com> Hi Pat I would be interested in being a co-maintainer of any of the packages. I joined the fedora project as a contributor last week and i ve been doing bug triaging and testing some stuff from the bodhi repository. i could be helpful to you in some manner and acting as a co-maintainer would help me in learning things faster also. Awaiting your reply. Thanks, Regards, Balaji On Thu, May 1, 2008 at 4:32 PM, Patrice Dumas wrote: > Hello, > > I am going to be in vacations and I have a bunch of packages without > co-maintainer. I will remain maintainer, and in general I am in contact > with upstream, but who knows, and I think it is better to always have > co-maintainers. Would somebody be interested? > > Normal (or complex) packages: > > * cernlib -- General purpose CERN library > > * cernlib-g77 -- General purpose CERN library > > * gnash -- GNU flash movie player > > * grads -- Tool for easy acces, manipulation, and visualization of data > > * kchmviewer -- CHM viewer with KDE support > > * tetex-tex4ht -- Translates TeX and LaTeX into HTML or XML+MathML > > Same here, and additionally this is an interdependent stack (currently > most don't build, waiting for upstream release for libnc-dap). > > * bes -- Back-end server software framework for OPeNDAP > > * dap-freeform_handler -- FreeForm data handler for the OPeNDAP Data server > > * dap-hdf4_handler -- HDF4 data handler for the OPeNDAP Data server > > * dap-netcdf_handler -- NetCDF 3 data handler for the OPeNDAP Data server > > * dap-server -- Basic request handling for OPeNDAP servers > > * libdap -- The C++ DAP2 library from OPeNDAP > > * libnc-dap -- The NetCDF interface to DAP-2 from OPeNDAP > > > The remaining are very low work (or no work) > > * acpi -- Command-line ACPI client > > * acpitool -- A command line ACPI client for Linux > > * agg -- Anti-Grain Geometry > > * archmage -- Extensible reader/decompiler of files in CHM format > > * asa -- Convert Fortran carriage control characters > > * bibexport -- Extract entries from BibTeX and .aux files > > * BibTool -- A Tool for manipulating BibTeX data bases > > * bitmap -- Bitmap editor and converter utilities for the X Window System > > * boolstuff -- Disjunctive Normal Form boolean expression library > > * cppunit -- C++ unit testing framework > > * docbook2X -- Convert docbook into man and Texinfo > > * esmtp -- User configurable relay-only Mail Transfer Agent (MTA) > > * flasm -- Flash bytecode assembler disassembler > > * g2clib -- GRIB2 encoder/decoder and search/indexing routines in C > > * gnochm -- CHM file viewer > > * halevt -- Generic handler for HAL events > > * intuitively -- Automatic IP detection utility > > * libchmxx -- C++ bindings for chmlib > > * libdockapp -- DockApp Development Standard Library > > * libesmtp -- SMTP client library > > * libnet -- C library for portable packet creation and injection > > * libnet10 -- High-level API (toolkit) to construct and inject network packets > > * libsx -- Simple X library > > * ooo2txt -- Convert OpenOffice documents to simple text > > * pam_ssh -- PAM module for use with SSH keys and ssh-agent > > * perl-Algorithm-CurveFit -- Nonlinear Least Squares Curve Fitting > > * perl-Cache -- The Cache interface > > * perl-Feed-Find -- Syndication feed auto-discovery > > * perl-File-BaseDir -- Use the freedesktop basedir spec > > * perl-File-DesktopEntry -- Object to handle .desktop files > > * perl-File-MimeInfo -- Determine file type and open application > > * perl-File-NFSLock -- Perl module to do NFS (or not) locking > > * perl-Heap -- Perl extension for keeping data partially sorted > > * perl-HTML-FormatText-WithLinks -- HTML to text conversion with links as footnotes > > * perl-LWP-Authen-Wsse -- Library for enabling X-WSSE authentication in LWP > > * perl-Math-MatrixReal -- Manipulate matrix of Reals > > * perl-Math-Symbolic -- Symbolic calculations > > * perl-Parse-Yapp -- Perl extension for generating and using LALR parsers > > * perl-Statistics-Descriptive -- Perl module of basic descriptive statistical functions > > * perl-Text-CHM -- Perl extension for handling MS Compiled HtmlHelp Files > > * perl-Text-Unidecode -- US-ASCII transliterations of Unicode text > > * pmount -- Enable normal user mount > > * python-chm -- Python package for CHM files handling > > * tetex-elsevier -- Elsevier LaTeX style files and documentation > > * tetex-lineno -- Add line numbers on paragraphs in LaTeX > > * uread -- Utilities for unformatted fortran files > > * wdm -- WINGs Display Manager > > * wmix -- Dockapp mixer > > * xbae -- Motif matrix, caption and text input widgets > > * xchm -- A GUI front-end to CHMlib > > > -- > Pat > > -- > 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 Thu May 1 11:12:57 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Thu, 01 May 2008 12:12:57 +0100 Subject: /etc/alternatives not quite working Message-ID: <1209640378.3358.6.camel@T7.Linux> Hi, For some odd reason emacs has stopped working on my system. Looking at it, there wasn't anything in /etc/alternatives for it. Adding a symlink from /etc/alternatives to /usr/bin/emacs-22.2 is doing nothing. Has something broken or is there something I need to do to register an application in alternatives? TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From pertusus at free.fr Thu May 1 11:20:48 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 1 May 2008 13:20:48 +0200 Subject: searching for co-maintainers for my packages In-Reply-To: <6dd1343e0805010407l29174de1tcb1358715322d5a@mail.gmail.com> References: <20080501110259.GA2583@free.fr> <6dd1343e0805010407l29174de1tcb1358715322d5a@mail.gmail.com> Message-ID: <20080501112048.GB2583@free.fr> On Thu, May 01, 2008 at 04:37:30PM +0530, G wrote: > Hi Pat > > I would be interested in being a co-maintainer of any of the packages. > I joined the fedora project as a contributor last week and i ve been > doing bug triaging and testing some stuff from the bodhi repository. i > could be helpful to you in some manner and acting as a co-maintainer > would help me in learning things faster also. No problem. Are you already sponsored? If not you'll have first to be sponsored. There is an interesting proposal which would suit your case in case you are not sponsored, which is explicitly targeted at having people learn by being co-maintainer: http://fedoraproject.org/wiki/JefSpaleta/ProbationalContributorDraft But before this gets approved, you have to follow http://fedoraproject.org/wiki/PackageMaintainers/Join if you are not already sponsored. If you are already sponsored, just apply in the packagedatabase: http://fedoraproject.org/wiki/PackageMaintainers/UsingPackagedb -- Pat From rawhide at fedoraproject.org Thu May 1 11:24:29 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Thu, 1 May 2008 11:24:29 +0000 (UTC) Subject: rawhide report: 20080501 changes Message-ID: <20080501112429.A1CA8209CF9@releng1.fedora.phx.redhat.com> New package mousetweaks Mouse accessibility support for the GNOME desktop New package mozilla-filesystem Mozilla filesytem layout New package xfwm4-theme-nodoka Nodoka theme for xfwm4 Removed package kcometen3 Removed package kronolith Updated Packages: NetworkManager-1:0.7.0-0.9.3.svn3623.fc9 ---------------------------------------- * Wed Apr 30 2008 Dan Williams - 1:0.7.0-0.9.3.svn3623 - Clean up the dispatcher now that it's service is gone (rh #444798) * Wed Apr 30 2008 Dan Williams - 1:0.7.0-0.9.2.svn3623 - Fix asking applets for the GSM PIN/PUK * Wed Apr 30 2008 Dan Williams - 1:0.7.0-0.9.2.svn3622 - Guess WEP key type in applet when asking for new keys - Correct OK button sensitivity in applet when asking for new WEP keys PackageKit-0.1.12-8.20080425.fc9 -------------------------------- * Wed Apr 30 2008 Richard Hughes - 0.1.12-8.20080425 - Bodge in some of the GPG import code from master in an attempt to be able to install signatures for F9. - Fixes rh#443445, which is a release blocker. anaconda-11.4.0.80-1 -------------------- * Wed Apr 30 2008 Jeremy Katz - 11.4.0.80-1 - And actually include the bash binary too (#443700) (katzj) - Search path rather than hard-coding path to mdadm (#444843) (katzj) bigboard-0.5.34-2.fc9 --------------------- * Wed Apr 30 2008 Owen Taylor - 0.5.34-2 - Fix tarball name for .gz vs .bz2 * Wed Apr 30 2008 Owen Taylor - 0.5.34-1 - New upstream version (Fixes http://bugzilla.gnome.org/show_bug.cgi?id=529972) eclipse-1:3.3.2-11.fc9 ---------------------- * Sat Apr 26 2008 Mat Booth 3.3.2-11 - Fixed some benign errors in copy-platform when calling pdebuild multiple times. * Fri Apr 25 2008 Andrew Overholt 3.3.2-10 - Bump maximum heap size from 256 MB to 512 MB. - Add patch for https://bugs.eclipse.org/bugs/show_bug.cgi?id=214092 (which is really http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6614100). - Some jiggery-pokery for spaces in SWT paths for buildagainstxulrunner patch. * Wed Apr 09 2008 Andrew Overholt 3.3.2-9 - Fix patch level for xulrunner build patch. firefox-3.0-0.60.beta5.fc9 -------------------------- * Wed Apr 30 2008 Christopher Aillon 3.0-0.60 - Rebuild glibc-2.8-2 ----------- * Wed Apr 30 2008 Jakub Jelinek 2.8-2 - fix nscd races during GC (BZ#5381) - rebuilt with fixed GCC to fix regex miscompilation on power6 - SPARC fixes gnome-desktop-2.22.1-4.fc9 -------------------------- * Fri Apr 25 2008 Soren Sandmann - 2.22.1-4 - Fix signed/unsigned mixup, bug 443903 gnome-packagekit-0.1.12-11.20080430.fc9 --------------------------------------- * Wed Apr 30 2008 Richard Hughes - 0.1.12-11.20080430 - Actually build the correct tarball so the patches apply. * Wed Apr 30 2008 Richard Hughes - 0.1.12-10.20080430 - Pull in the new snapshot from the stable GNOME_PACKAGEKIT_0_1_X branch. - Fixes rh#442223, which is a release blocker. * Wed Apr 30 2008 Richard Hughes - 0.1.12-9.20080430 - Pull in the new snapshot from the stable GNOME_PACKAGEKIT_0_1_X branch. - Fixes rh#441755, which is a release blocker. libbonobo-2.22.0-2.fc9 ---------------------- * Tue Apr 29 2008 Ray Strode - 2.22.0-2 - Take name on message bus to tie activation server to desktop session ltsp-5.1.7-2.fc9 ---------------- * Wed Apr 30 2008 Warren Togami - 5.1.7-2 - Allow ltsp-build-client to work in sudo * Mon Apr 28 2008 Warren Togami - 5.1.7-1 - Fix ltsp-server-initialize (eharrison) - Create /etc/mtab in chroot, fixes ltspfs (wtogami) * Sun Apr 27 2008 Warren Togami - 5.1.6-1 - set LANG for login screen from client's /etc/sysconfig/i18n - move /etc/ltsp/ltsp-dhcpd.conf to /etc/ltsp/dhcpd.conf for consistency with Debian - vmclient split out config file into /etc/ltsp/vmclient nagios-plugins-1.4.11-4.fc9 --------------------------- * Wed Apr 30 2008 Mike McGrath 1.4.11-4 - added patch for check_pgsql * Wed Apr 09 2008 Mike McGrath 1.4.11-2 - Fix for 250588 * Thu Feb 28 2008 Mike McGrath 1.4.11-1 - Upstream released version 1.4.11 - Added check_ntp peer and time nspluginwrapper-0.9.91.5-27.fc9 ------------------------------- * Wed Apr 30 2008 Christopher Aillon 0.9.91.5-27 - mozilla-filesystem now owns the plugin source dir rhpl-0.215-3 ------------ * Wed Apr 30 2008 Jeremy Katz - 0.215-3 - Patch hadn't actually been applied, but we've adjusted the xkeyboard-config to have the inet bits by default without needing to specify us+inet scim-1.4.7-23.fc9 ----------------- * Wed Apr 30 2008 Jens Petersen - 1.4.7-23 - remove the multilib scim-bridge-gtk requires hack from scim-lang-* (#444681) * Wed Apr 09 2008 Jens Petersen - 1.4.7-22 - added translations for es, gu, hi, kn, ml, mr, pt_BR, ru, ta, te (Red Hat L10n Team, #431995) - added translations for sk and vi from upstream - updated translations for de, it, ja, ko, pa, zh_CN (Red Hat L10n Team) - scim-1.4.7-ja-sinhala-236715.patch is no longer required * Wed Apr 02 2008 Huang Peng - 1.4.7-21 - Update scim.conf to check qtimm in qt4 folder for qtimm. - Re-add scim-1.4.7-fix-capslock.patch to fix bug #431222. seamonkey-1.1.9-4.fc9 --------------------- * Wed Apr 30 2008 Christopher Aillon - 1.1.9-4 - Require mozilla-filesystem and drop its requires * Thu Apr 17 2008 Kai Engert - 1.1.9-3 - add several upstream patches, not yet released: 425576 (crash), 323508, 378132, 390295, 421622 xfwm4-4.4.2-3.fc9 ----------------- * Wed Apr 23 2008 Christoph Wickert - 4.4.2-3 - Switch to Nodoka theme by default - disable-static instead of removing *.a files * Sun Feb 10 2008 Kevin Fenzi - 4.4.2-2 - Rebuild for gcc43 xulrunner-1.9-0.60.beta5.fc9 ---------------------------- * Wed Apr 30 2008 Christopher Aillon 1.0-0.60 - Some files moved to mozilla-filesystem; kill them and add the Req Broken deps for ppc64 ---------------------------------------------------------- livecd-tools-015-1.fc9.ppc64 requires yaboot perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot From alain.portal at free.fr Thu May 1 11:26:22 2008 From: alain.portal at free.fr (Alain PORTAL) Date: Thu, 1 May 2008 13:26:22 +0200 Subject: Orphaning package In-Reply-To: <4819A1CD.3030704@pingoured.fr> References: <200804260011.34138.alain.portal@free.fr> <200805011251.46026.alain.portal@free.fr> <4819A1CD.3030704@pingoured.fr> Message-ID: <200805011326.22992.alain.portal@free.fr> Le jeudi 01 mai 2008, pingou a ?crit : > Glad to have you back :) Thanks pingou ;-) Regards, Alain -- Les pages de manuel Linux en fran?ais http://manpagesfr.free.fr/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From j.w.r.degoede at hhs.nl Thu May 1 12:08:22 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 01 May 2008 14:08:22 +0200 Subject: Orphaning package In-Reply-To: <4819A1CD.3030704@pingoured.fr> References: <200804260011.34138.alain.portal@free.fr> <1209214191.2946.64.camel@vader.jdub.homelinux.org> <200805011251.46026.alain.portal@free.fr> <4819A1CD.3030704@pingoured.fr> Message-ID: <4819B2B6.8080507@hhs.nl> pingou wrote: > Alain PORTAL wrote: >> Le samedi 26 avril 2008, Josh Boyer a ?crit : >> >>> Can you email the issues you're having to >>> fedora-extras-steering at redhat.com please? Perhaps we can look them over >>> and find an amicable way to solve them for everyone involved. >> >> Finally, mailing to fedora-extras-steering at redhat.com became uneeded >> as the major issue is now solved. >> I want to particulary thank Tom "spot" Callaway, who is a great and >> stubborn mediator, and Paul W. Frields, who both got involved to solve >> these issues. > > Glad to have you back :) > +1 Regards, Hans From josef at toxicpanda.com Thu May 1 12:16:00 2008 From: josef at toxicpanda.com (Josef Bacik) Date: Thu, 1 May 2008 08:16:00 -0400 Subject: Multilib Middle-Ground In-Reply-To: <20080501110530.GA25448@imperial.ac.uk> References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <604aa7910804301429k472cc2bcq8f9a06c1acd70b33@mail.gmail.com> <20080501110530.GA25448@imperial.ac.uk> Message-ID: <1b7401870805010516k7d3c0cadp5df5c1a162ebd2d4@mail.gmail.com> Gmail makes it hard for me to follow long threads, so sorry if this response is a little out of place. What exactly is the purpose of installing 32bit binaries on a 64bit box? The only things I've been able to see in this thread is for installing proprietary applications. So we as the Fedora community, who are strongly dedicated to being open and free, are going to great lengths in order to make sure that we can better use proprietary applications/formats? Every time I do an install on one of my boxes I have to run my little "get rid of all the 32 bit rpms" script, otherwise I end up with weird dependancy hell problems. Granted the dependancy hell problems are usually my own doing by running some rawhide packages and such, but nevertheless the problems do not occur with just x86_64/noarch packages. I do not use flash, because I believe in what are supposedly the core values of Fedora. I do not use any proprietary software, because I believe in freedom and openness. Albeit there are plenty of users who do not share my views, I think that punishing us that do believe in everything that Fedora is supposed to be about should not be having to go out of their way in order to put their system back into a normal state. I think that if you wish to install proprietary software on your system, you should be the one who has to do clicky clicky in order to make it work, and not I who has to run this crappy script just to have a clean x86_64 install. I believe having anything but the default be non-multilib is sending the wrong kind of message, and is border line hypocritical. Add an option so that people can have the multilib stuff installed works, but forcing everybody to have twice the number of packages installed is a poor answer. Josef From rdieter at math.unl.edu Thu May 1 12:18:12 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 01 May 2008 07:18:12 -0500 Subject: Wanted: (Co-)maintainer for Kronolith References: <1209552429.5892.48.camel@localhost.localdomain> Message-ID: Jason L Tibbitts III wrote: >>>>>> "LK" == Lubomir Kundrak writes: > > LK> Hi, It has came to my attention, that maintainer of kronolith has > LK> been unresponsive for some time. > > Which is odd, because he committed to Horde earlier this month. > > I have the Horde stack deployed here and would be willing to help out, > but at the moment I don't have a test environment set up so in this > particular instance I wouldn't have been very useful. > > I'll work on getting something set up and add myself to the package > when I'll be able to assist. fyi, rel-eng blocked this pkg from f9, at least until it's maintainership status can be verified. -- Rex From rjones at redhat.com Thu May 1 12:49:45 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 1 May 2008 13:49:45 +0100 Subject: Review swapsies In-Reply-To: <48199C46.1070903@hhs.nl> References: <48199C46.1070903@hhs.nl> Message-ID: <20080501124945.GA25217@amd.home.annexia.org> On Thu, May 01, 2008 at 12:32:38PM +0200, Hans de Goede wrote: > I've this small game I would like to have reviewed: > https://bugzilla.redhat.com/show_bug.cgi?id=442022 > > Its a nice and simple review, anyone want to swap? Looks like someone took that one, but I have these to swap with anyone, with the most important ones (to me) listed first: https://bugzilla.redhat.com/show_bug.cgi?id=442705 (pa_bitmatch) https://bugzilla.redhat.com/show_bug.cgi?id=442871 (virt-top) https://bugzilla.redhat.com/show_bug.cgi?id=443449 (udpcast) https://bugzilla.redhat.com/show_bug.cgi?id=442873 (virt-df, requires 442705) https://bugzilla.redhat.com/show_bug.cgi?id=443449 (ocaml-pgocaml) https://bugzilla.redhat.com/show_bug.cgi?id=444428 (cmigrep) https://bugzilla.redhat.com/show_bug.cgi?id=435431 (ocaml-deriving) https://bugzilla.redhat.com/show_bug.cgi?id=442875 (virt-ctrl) https://bugzilla.redhat.com/show_bug.cgi?id=435299 (ocaml-pa-monad) https://bugzilla.redhat.com/show_bug.cgi?id=435287 (ocaml-json-static) https://bugzilla.redhat.com/show_bug.cgi?id=434707 (ocaml-sexplib) If you want me to take some reviews in return, let me know. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From lesmikesell at gmail.com Thu May 1 12:52:13 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 01 May 2008 07:52:13 -0500 Subject: Multilib Middle-Ground In-Reply-To: <4819978A.80304@city-fan.org> References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819978A.80304@city-fan.org> Message-ID: <4819BCFD.5070108@gmail.com> Paul Howarth wrote: > > > I think we are all actually in violent agreement here, it's just that > some proprietary vendors seem to go out of their way to defeat the > dependency mechanisms that would help tools like yum install their > software. Have you looked at what packages have to include to install on more than one linux distro/version? And fedora is the worst of the bunch in terms of not being compatible with last week's version of itself. Give the 3rd party packagers a target before you complain about them missing it. -- Les Mikesell lesmikesell at gmail.com From stlwrt at gmail.com Thu May 1 12:54:55 2008 From: stlwrt at gmail.com (Pavel Shevchuk) Date: Thu, 1 May 2008 15:54:55 +0300 Subject: F9 installation screenshot In-Reply-To: <1209596606.8968.166.camel@cutter> References: <1209506979.22831.121.camel@aglarond.local> <20080430025732.GV26399@inocybe.teonanacatl.org> <28979.192.54.193.59.1209541945.squirrel@rousalka.dyndns.org> <1209585473.4950.79.camel@localhost> <1209588047.29552.37.camel@rousalka.okg> <4818DD86.5020805@ncsu.edu> <1209595046.4950.84.camel@localhost> <1209596606.8968.166.camel@cutter> Message-ID: Could we stop insulting each other instead of working on fedora? I see no rational discussion anymore in this thread =( On 5/1/08, seth vidal wrote: > On Wed, 2008-04-30 at 17:37 -0500, Callum Lerwick wrote: > > On Wed, 2008-04-30 at 16:58 -0400, Casey Dahlin wrote: > > > Sweet horror of horrors! A hotdog with eyes! Imagine how offended people > > > might be! > > > > It might offend the vegetarians, but does a hot dog really count as > > meat? > > > Yes, and disgusting livestock practices. > > > -sv > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- http://scwlab.com From paul at city-fan.org Thu May 1 12:57:21 2008 From: paul at city-fan.org (Paul Howarth) Date: Thu, 01 May 2008 13:57:21 +0100 Subject: Multilib Middle-Ground In-Reply-To: <4819BCFD.5070108@gmail.com> References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819978A.80304@city-fan.org> <4819BCFD.5070108@gmail.com> Message-ID: <4819BE31.9030306@city-fan.org> Les Mikesell wrote: > Paul Howarth wrote: >> > I think we are all actually in violent agreement here, it's just >> that some proprietary vendors seem to go out of their way to defeat >> the dependency mechanisms that would help tools like yum install their >> software. > > Have you looked at what packages have to include to install on more > than one linux distro/version? And fedora is the worst of the bunch in > terms of not being compatible with last week's version of itself. Give > the 3rd party packagers a target before you complain about them missing it. As Kevin mentioned earlier in this thread, the soname dependencies that RPM adds automatically are *real* dependencies and I'm not aware of any RPM-based distribution that doesn't use them. So what's the point of stripping them out? Stripping of pathname-based and package-name based dependencies I can understand, but not the library deps. Paul. From jwboyer at gmail.com Thu May 1 12:58:30 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 01 May 2008 07:58:30 -0500 Subject: Orphaning package In-Reply-To: <200805011251.46026.alain.portal@free.fr> References: <200804260011.34138.alain.portal@free.fr> <1209214191.2946.64.camel@vader.jdub.homelinux.org> <200805011251.46026.alain.portal@free.fr> Message-ID: <1209646710.2946.109.camel@vader.jdub.homelinux.org> On Thu, 2008-05-01 at 12:51 +0200, Alain PORTAL wrote: > Le samedi 26 avril 2008, Josh Boyer a ?crit : > > > Can you email the issues you're having to > > fedora-extras-steering at redhat.com please? Perhaps we can look them over > > and find an amicable way to solve them for everyone involved. > > Finally, mailing to fedora-extras-steering at redhat.com became uneeded as the > major issue is now solved. > I want to particulary thank Tom "spot" Callaway, who is a great and stubborn > mediator, and Paul W. Frields, who both got involved to solve these issues. > > I want also thank every body who mailed me. Excellent news. > Be sure Josh that if I get other similar problems, I'll mail to FESCO. Great! Fortunately in this case, it didn't even take actual FESCo involvement to come to a resolution. I particularly like it when members of the community are able to help one another through situations like this. (Yes, I know spot is in FESCo, but he acted as any other contributor would have anyway). josh From lesmikesell at gmail.com Thu May 1 12:58:47 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 01 May 2008 07:58:47 -0500 Subject: Multilib Middle-Ground In-Reply-To: <544eb990805010309u3849d73aqbdb8016d113ee1d4@mail.gmail.com> References: <4817FF36.10305@redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <544eb990805010309u3849d73aqbdb8016d113ee1d4@mail.gmail.com> Message-ID: <4819BE87.4000400@gmail.com> Bill Crawford wrote: > On 01/05/2008, Andrew Farris wrote: > >> If the libraries are easy to get put in place, then the system libraries >> might actually get used, and properly packaged proprietary software might >> get distributed. If the opposite is true for the libraries, then can you >> even hope well packaged applications will be shipped from those vendors? > > They are deliberately bypassing the mechanisms to make that possible. What's the standard mechanism to do this across rpm-using distributions and version? -- Les Mikesell lesmikesell at gmail.com From lesmikesell at gmail.com Thu May 1 13:13:19 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 01 May 2008 08:13:19 -0500 Subject: Multilib Middle-Ground In-Reply-To: <48198EA0.5070904@gmail.com> References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> Message-ID: <4819C1EF.6050009@gmail.com> Andrew Farris wrote: > > No, it doesn't, which is exactly my point... the harder, or more > explicitly, anything must be done to distribute proprietary software... > the more likely it will be done with a shell script which spews files > all over the place. > > You don't get proprietary software to work nicely with package > management systems by making it even harder. Would you mind leaving the 'p' word out of this discussion? The same principle applies to all software that isn't recompiled and repackaged between every version, including the user's own and other programs where source is available but you don't want to have to rebuild (if we did want to recompile every week we'd be running gentoo...). Pretending this is specific to proprietary software puts the wrong spin on the conversation here. The only difference being proprietary makes in this case is that someone else needs to do this work and probably maintain specific versions separately for each fedora version instead of every using doing that himself. -- Les Mikesell lesmikesell at gmail.com From skvidal at fedoraproject.org Thu May 1 13:13:53 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 01 May 2008 09:13:53 -0400 Subject: Multilib Middle-Ground In-Reply-To: <1209627667.25560.470.camel@pmac.infradead.org> References: <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <1209574089.8968.129.camel@cutter> <4818B000.9030001@redhat.com> <1209577677.8968.139.camel@cutter> <4818B396.1070208@redhat.com> <1209578647.8968.145.camel@cutter> <20080430181814.GK2255@devserv.devel.redhat.com> <1209579738.8968.153.camel@cutter> <1209627667.25560.470.camel@pmac.infradead.org> Message-ID: <1209647633.3249.14.camel@cutter> On Thu, 2008-05-01 at 08:41 +0100, David Woodhouse wrote: > On Wed, 2008-04-30 at 14:22 -0400, seth vidal wrote: > > > > You'll note the default behavior in F9 is not install any i386 pkgs > > unless explicitly asked for (or as a dependency). > > > > If you want to have dependencies have arch-specific information in > > them then, again, we need to talk about that at the rpm layer. > > I believe this has already been implemented in RPM. > > https://bugzilla.redhat.com/show_bug.cgi?id=235755 > http://devel.linux.duke.edu/gitweb/?p=rpm.git;a=commitdiff;h=48ff62a5291458ed1181cd6c31dcadb193ad2f8e > But not in one that's in fedora, yet. -sv From lesmikesell at gmail.com Thu May 1 13:16:25 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 01 May 2008 08:16:25 -0500 Subject: Multilib Middle-Ground In-Reply-To: <4819BE31.9030306@city-fan.org> References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819978A.80304@city-fan.org> <4819BCFD.5070108@gmail.com> <4819BE31.9030306@city-fan.org> Message-ID: <4819C2A9.3050202@gmail.com> Paul Howarth wrote: > Les Mikesell wrote: >> Paul Howarth wrote: >>> > I think we are all actually in violent agreement here, it's just >>> that some proprietary vendors seem to go out of their way to defeat >>> the dependency mechanisms that would help tools like yum install >>> their software. >> >> Have you looked at what packages have to include to install on more >> than one linux distro/version? And fedora is the worst of the bunch >> in terms of not being compatible with last week's version of itself. >> Give the 3rd party packagers a target before you complain about them >> missing it. > > As Kevin mentioned earlier in this thread, the soname dependencies that > RPM adds automatically are *real* dependencies and I'm not aware of any > RPM-based distribution that doesn't use them. So what's the point of > stripping them out? > > Stripping of pathname-based and package-name based dependencies I can > understand, but not the library deps. Are they the same across all RPM based systems? -- Les Mikesell lesmikesell at gmail.com From dpierce at redhat.com Thu May 1 13:21:53 2008 From: dpierce at redhat.com (Darryl L. Pierce) Date: Thu, 01 May 2008 09:21:53 -0400 Subject: Check out my Facebook profile In-Reply-To: <1209610241.4950.89.camel@localhost> References: <660d6ac9e2fc8e9633b937c6bc4a2504@register.facebook.com> <1209610241.4950.89.camel@localhost> Message-ID: <4819C3F1.6010601@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Callum Lerwick wrote: | New Mugshot user? | Is there a Mugshot group for Fedora package maintainers? - -- Darryl L. Pierce - Phone: (919) 754-4383 "In matters of style, swim with the current; In matters of principle, stand like a rock." - Thomas Jefferson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFIGcPxjaT4DmxOfxsRAsxIAJ4xAlJslffbWtPoa4Ez3Dw+rA6DbACdHhcp t3531oSLx/YLjRUA2g1OLiA= =59cD -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: dpierce.vcf Type: text/x-vcard Size: 265 bytes Desc: not available URL: From skvidal at fedoraproject.org Thu May 1 13:22:18 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 01 May 2008 09:22:18 -0400 Subject: Multilib Middle-Ground In-Reply-To: <4819C2A9.3050202@gmail.com> References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819978A.80304@city-fan.org> <4819BCFD.5070108@gmail.com> <4819BE31.9030306@city-fan.org> <4819C2A9.3050202@gmail.com> Message-ID: <1209648138.3249.17.camel@cutter> On Thu, 2008-05-01 at 08:16 -0500, Les Mikesell wrote: > > Stripping of pathname-based and package-name based dependencies I can > > understand, but not the library deps. > > Are they the same across all RPM based systems? > The library deps sorta have to be. The deps come out of what the program is linked to. as an example run: ldd /usr/bin/xterm and look at what it outputs -sv From dwight at supercomputer.org Thu May 1 12:56:56 2008 From: dwight at supercomputer.org (dwight at supercomputer.org) Date: Thu, 1 May 2008 04:56:56 -0800 Subject: is xorg.conf still needed In-Reply-To: <1209619732.4950.96.camel@localhost> References: <1209523940.2906.136.camel@localhost.localdomain> <200804302029.10986.dwight@supercomputer.org> <1209619732.4950.96.camel@localhost> Message-ID: <200805010556.57121.dwight@supercomputer.org> On Wednesday 30 April 2008 10:28:52 pm Callum Lerwick wrote: > On Wed, 2008-04-30 at 19:29 -0800, dwight at supercomputer.org wrote: > > On Wednesday 30 April 2008 01:13:27 am Matej Cepl wrote: > > > The whole truth is that we are on the way towards Stateless > > > Linux (which means here xorg.conf-less X), but we are not > > > there yet. To be honest, the way is long and the question is > > > whether we will arrive at Fedora 10 or later. > > > ... > > > > Are we really? Upon what do you base that statement? I'd be very > > interested in knowing more, because the Stateless Linux mailing > > list looks rather inactive. Is there a roadmap? And what's the > > current status? > > We're on our way to the Online Desktop, in which the operating > system itself starts to barely matter at all. (Which should draw > people to Linux since its cheap and reliable, right? :) I don't believe it, but your reply doesn't answer my question. Where's the roadmap, and what's the plan for getting there? And who's in charge, and who's involved? -dwight- From pertusus at free.fr Thu May 1 13:37:25 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 1 May 2008 15:37:25 +0200 Subject: Multilib Middle-Ground In-Reply-To: <4819BCFD.5070108@gmail.com> References: <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819978A.80304@city-fan.org> <4819BCFD.5070108@gmail.com> Message-ID: <20080501133725.GA16265@free.fr> On Thu, May 01, 2008 at 07:52:13AM -0500, Les Mikesell wrote: > Paul Howarth wrote: >> > I think we are all actually in violent agreement here, it's just that >> some proprietary vendors seem to go out of their way to defeat the >> dependency mechanisms that would help tools like yum install their >> software. > > Have you looked at what packages have to include to install on more than > one linux distro/version? And fedora is the worst of the bunch in terms of > not being compatible with last week's version of itself. Give the 3rd > party packagers a target before you complain about them missing it. It is not fedora as such. The change in ABI (binary interfaces) or API comes from upstream. And since fedora follows upstream, ABI break when there is an upstream release breaking ABI. Some projects take care of ABI stability (glibc, gnome, netcdf) other don't (openssl, libdap). Also it may happen that ABI breaks when compiler change and also kernel compatibilities change. And fedora also follow upstream in that. There could be policies to avoid breaking ABI within a fedora release, but so far there is no consensus on that subject and it is left to the packager. RHEL tries to keep ABI stable during the whole distro lifetime. -- Pat From mjs at CLEMSON.EDU Thu May 1 00:03:11 2008 From: mjs at CLEMSON.EDU (Matthew Saltzman) Date: Wed, 30 Apr 2008 20:03:11 -0400 Subject: F9 installation screenshot In-Reply-To: <1209588047.29552.37.camel@rousalka.okg> References: <8990327d0804290423o6bef20c0g8ab07576ea81068@mail.gmail.com> <20080429121439.GN27333@localhost.localdomain> <8990327d0804290558k5f32d775ic9ddd24b164f4744@mail.gmail.com> <8990327d0804290600x12482214s97fc57b14098f3be@mail.gmail.com> <1209481464.18191.6.camel@gibraltar.str.redhat.com> <20080429154009.GR26399@inocybe.teonanacatl.org> <1209506979.22831.121.camel@aglarond.local> <20080430025732.GV26399@inocybe.teonanacatl.org> <28979.192.54.193.59.1209541945.squirrel@rousalka.dyndns.org> <1209585473.4950.79.camel@localhost> <1209588047.29552.37.camel@rousalka.okg> Message-ID: <1209600192.30793.9.camel@valkyrie.localdomain> On Wed, 2008-04-30 at 22:40 +0200, Nicolas Mailhot wrote: > Le mercredi 30 avril 2008 ? 14:57 -0500, Callum Lerwick a ?crit : > > On Wed, 2008-04-30 at 09:52 +0200, Nicolas Mailhot wrote: > > > I, for one was glad when those (and previous redneck jokes) were > > > kicked out of the installer. The text and imagery used were just too > > > US-centric to be comfortable, and got old fast. > > > > It's a two way street. > > > > Yes, it's cool to hate America these days. I'm no fan of our current > > foreign policy myself. But it is still rather insulting in many circles > > that you paint all Americans as being rednecks like you just did. > > Since you seem not to have gotten the reference, one of the ancient Red > Hat releases bragged about Redneck support in its image/text install > train. I can tell you this had a terrible effect on people that were > installing for another locale and found out half the needed pieces for > this locale were missing (but that's ok, Redneck is in, who actually > needs more than English+Redneck). IIRC (maybe someone who was there can correct me), back in the early days of Red Hat Linux (like 3.0.3 or something), the first experiment in i18n was to create the Redneck locale (was it Donnie Barnes who was the Carolina native who was the target of that little joke?). The staff thought it was amusing enough that they left it in as a language option in the installer, so you saw all the dialog boxes translated from English to Redneck. I (transplanted Yankee) thought it was kind of amusing at the time, but I suppose it doesn't really have a place in a polished, professional, worldwide distro. > > So get a grip. Everyone is not seing the world through and American eye. > American junk food industry imagery is not a positive image everywhere. > American cultural references and priorities are not shared by most of > the world. > > That does not mean the world is seething with American haters. Indeed > the "if you don't aspire to be copycat Americans you must hate us" is > another typical American world-view that can be terribly annoying to > non-Americans (including to people who have a generally positive viex of > the USA). > > ?Smart international organisations have nothing to win in draping > themselves in American symbols and imagery (or Chinese symbols and > imagery or French symbols and imagery, etc). You win hearth by > emphasising your local presence and if you can't do it you better > project a bland and neutral image. My spell-checker is complaining about some of your 's''s 8^). > -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From ajackson at redhat.com Thu May 1 13:41:00 2008 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 01 May 2008 09:41:00 -0400 Subject: is xorg.conf still needed In-Reply-To: <4818F11C.1070803@conversis.de> References: <1209523940.2906.136.camel@localhost.localdomain> <20080430085648.GA2919@evileye.atkac.englab.brq.redhat.com> <1209562121.22831.164.camel@aglarond.local> <1209564017.15542.315.camel@localhost.localdomain> <4818F11C.1070803@conversis.de> Message-ID: <1209649260.15542.349.camel@localhost.localdomain> On Thu, 2008-05-01 at 00:22 +0200, Dennis Jacobfeuerborn wrote: > Adam Jackson wrote: > > Ideally, though this doesn't work yet, you'd just do: > > > > Section "Device" > > Driver "vesa" > > EndSection > > It doesn't? This is what my xorg.conf looks like: > > Section "Device" > Driver "nouveau" > Identifier "Videocard0" > EndSection > > That works fine for me. Nice! I still don't like the magic Videocard0 there, that should get filled in for you. But that's better than I thought. - ajax From wtogami at redhat.com Thu May 1 13:45:09 2008 From: wtogami at redhat.com (Warren Togami) Date: Thu, 01 May 2008 09:45:09 -0400 Subject: Multilib Middle-Ground In-Reply-To: <1209599611.4950.88.camel@localhost> References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <604aa7910804301429k472cc2bcq8f9a06c1acd70b33@mail.gmail.com> <1209599611.4950.88.camel@localhost> Message-ID: <4819C965.9070707@redhat.com> Callum Lerwick wrote: > > Well what should happen is flash is pulled from Adobe's own repo, and > since they're pulling from a repo anyway, yum should do what its > designed to do and pull in all the i386 deps flash needs in the same > transaction. There's no need for it to be in the default install or on > the install media, as far as flash is concerned. > I was not even referring to Flash this time. An even larger problem from stripping i386 from a x86_64 default install is you don't get i386 Input Method support. A great many 32bit software stops working properly, the user has no idea why, and there is no simple yum groupinstall command capable of fixing this. Your naive suggestion fails in this case, because there is no way you will get all of that 3rd party software to have deps on all possible language packages. Warren Togami wtogami at redhat.com From sundaram at fedoraproject.org Thu May 1 13:49:56 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 01 May 2008 19:19:56 +0530 Subject: Multilib Middle-Ground In-Reply-To: <4819C2A9.3050202@gmail.com> References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819978A.80304@city-fan.org> <4819BCFD.5070108@gmail.com> <4819BE31.9030306@city-fan.org> <4819C2A9.3050202@gmail.com> Message-ID: <4819CA84.1070004@fedoraproject.org> Les Mikesell wrote: > Paul Howarth wrote: >> Stripping of pathname-based and package-name based dependencies I can >> understand, but not the library deps. > > Are they the same across all RPM based systems? Yes, they are and the third party packages have no excuse if they are deliberately disabling the automatic dependency mechanisms. Rahul From sundaram at fedoraproject.org Thu May 1 13:50:32 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 01 May 2008 19:20:32 +0530 Subject: Check out my Facebook profile In-Reply-To: <4819C3F1.6010601@redhat.com> References: <660d6ac9e2fc8e9633b937c6bc4a2504@register.facebook.com> <1209610241.4950.89.camel@localhost> <4819C3F1.6010601@redhat.com> Message-ID: <4819CAA8.6070207@fedoraproject.org> Darryl L. Pierce wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Callum Lerwick wrote: > | New Mugshot user? > | > > Is there a Mugshot group for Fedora package maintainers? There is a general Fedora group which includes package maintainers. Rahul From lesmikesell at gmail.com Thu May 1 13:54:45 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 01 May 2008 08:54:45 -0500 Subject: Multilib Middle-Ground In-Reply-To: <1209648138.3249.17.camel@cutter> References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819978A.80304@city-fan.org> <4819BCFD.5070108@gmail.com> <4819BE31.9030306@city-fan.org> <4819C2A9.3050202@gmail.com> <1209648138.3249.17.camel@cutter> Message-ID: <4819CBA5.3010505@gmail.com> seth vidal wrote: > On Thu, 2008-05-01 at 08:16 -0500, Les Mikesell wrote: >>> Stripping of pathname-based and package-name based dependencies I can >>> understand, but not the library deps. >> Are they the same across all RPM based systems? >> > > The library deps sorta have to be. The deps come out of what the program > is linked to. > > as an example run: > ldd /usr/bin/xterm > > and look at what it outputs > VMWare-server should probably be split into two packages. Only the console portion needs the X libs and you can run it on a different machine, a different OS, or not at all, so it wouldn't make much sense for a run-time dependency for that part to prevent installation of the rest of the server. -- Les Mikesell lesmikesell at gmail.com From valent.turkovic at gmail.com Thu May 1 13:56:31 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 1 May 2008 15:56:31 +0200 Subject: My eeexperience with Fedora 9 Message-ID: <64b14b300805010656r7516d23en855b250f3616d76d@mail.gmail.com> Here is the post regarding my experience installing Fedora 9 on Asus eee: http://kernelreloaded.blog385.com/index.php/archives/my-eeexperience-with-fedora-9/ Cheers, Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic -------------- next part -------------- An HTML attachment was scrubbed... URL: From skvidal at fedoraproject.org Thu May 1 13:58:01 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 01 May 2008 09:58:01 -0400 Subject: Multilib Middle-Ground In-Reply-To: <4819CBA5.3010505@gmail.com> References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819978A.80304@city-fan.org> <4819BCFD.5070108@gmail.com> <4819BE31.9030306@city-fan.org> <4819C2A9.3050202@gmail.com> <1209648138.3249.17.camel@cutter> <4819CBA5.3010505@gmail.com> Message-ID: <1209650282.3249.19.camel@cutter> On Thu, 2008-05-01 at 08:54 -0500, Les Mikesell wrote: > seth vidal wrote: > > On Thu, 2008-05-01 at 08:16 -0500, Les Mikesell wrote: > >>> Stripping of pathname-based and package-name based dependencies I can > >>> understand, but not the library deps. > >> Are they the same across all RPM based systems? > >> > > > > The library deps sorta have to be. The deps come out of what the program > > is linked to. > > > > as an example run: > > ldd /usr/bin/xterm > > > > and look at what it outputs > > > > VMWare-server should probably be split into two packages. Only the > console portion needs the X libs and you can run it on a different > machine, a different OS, or not at all, so it wouldn't make much sense > for a run-time dependency for that part to prevent installation of the > rest of the server. umm, okay. But no one here controls the vmware package. Hell, speaking for just me, I don't even CARE about vmware. So, if you really think the above should happen, tell vmware. -sv From rdieter at math.unl.edu Thu May 1 14:13:11 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 01 May 2008 09:13:11 -0500 Subject: Multilib Middle-Ground References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819C1EF.6050009@gmail.com> Message-ID: Les Mikesell wrote: > Andrew Farris wrote: >> >> No, it doesn't, which is exactly my point... the harder, or more >> explicitly, anything must be done to distribute proprietary software... >> the more likely it will be done with a shell script which spews files >> all over the place. >> >> You don't get proprietary software to work nicely with package >> management systems by making it even harder. > > Would you mind leaving the 'p' word out of this discussion? Maybe, maybe not. 'p' to some means anything != free/oss. And if it's free/oss, what better place than to be *in* fedora. -- Rex From pertusus at free.fr Thu May 1 14:17:18 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 1 May 2008 16:17:18 +0200 Subject: Multilib Middle-Ground In-Reply-To: References: <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819C1EF.6050009@gmail.com> Message-ID: <20080501141717.GB16265@free.fr> On Thu, May 01, 2008 at 09:13:11AM -0500, Rex Dieter wrote: > > Maybe, maybe not. 'p' to some means anything != free/oss. And if it's > free/oss, what better place than to be *in* fedora. Not necessarily, all codes are not meant to be released, or, even if released are not necessarily meant to be packaged, even if they are free software. One example for this case is numerical models. -- Pat From loganjerry at gmail.com Thu May 1 14:41:28 2008 From: loganjerry at gmail.com (Jerry James) Date: Thu, 1 May 2008 08:41:28 -0600 Subject: Review swapsies In-Reply-To: <20080501124945.GA25217@amd.home.annexia.org> References: <48199C46.1070903@hhs.nl> <20080501124945.GA25217@amd.home.annexia.org> Message-ID: <870180fe0805010741y1d0d53d8w21cdc7896a46bebc@mail.gmail.com> On Thu, May 1, 2008 at 6:49 AM, Richard W.M. Jones wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=443449 (udpcast) I can take this one. Would you mind reviewing one of these? https://bugzilla.redhat.com/show_bug.cgi?id=262401 (jcip-annotations) https://bugzilla.redhat.com/show_bug.cgi?id=285551 (idw-gpl) https://bugzilla.redhat.com/show_bug.cgi?id=436033 (mona) The first one is a VERY small package, so it should be easy. If anyone is interested in findbugs (http://findbugs.sourceforge.net/), the first two are prerequisites for it. -- Jerry James http://loganjerry.googlepages.com/ From lesmikesell at gmail.com Thu May 1 14:58:09 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 01 May 2008 09:58:09 -0500 Subject: Multilib Middle-Ground In-Reply-To: References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819C1EF.6050009@gmail.com> Message-ID: <4819DA81.4010607@gmail.com> Rex Dieter wrote: > >>> No, it doesn't, which is exactly my point... the harder, or more >>> explicitly, anything must be done to distribute proprietary software... >>> the more likely it will be done with a shell script which spews files >>> all over the place. >>> >>> You don't get proprietary software to work nicely with package >>> management systems by making it even harder. >> Would you mind leaving the 'p' word out of this discussion? > > Maybe, maybe not. 'p' to some means anything != free/oss. And if it's > free/oss, what better place than to be *in* fedora. > I don't understand why anyone would have any interest in an operating system that can only run its own programs. Aside from the obvious limitations since no one could seriously expect it to include all possibilities, it has to be an enormous waste of effort to build the specialized versions and package them in repositories that few people will use anyway. -- Les Mikesell lesmikesell at gmail.com From nicolas.mailhot at laposte.net Thu May 1 14:57:22 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 01 May 2008 16:57:22 +0200 Subject: F9 installation screenshot In-Reply-To: <1209600192.30793.9.camel@valkyrie.localdomain> References: <8990327d0804290423o6bef20c0g8ab07576ea81068@mail.gmail.com> <20080429121439.GN27333@localhost.localdomain> <8990327d0804290558k5f32d775ic9ddd24b164f4744@mail.gmail.com> <8990327d0804290600x12482214s97fc57b14098f3be@mail.gmail.com> <1209481464.18191.6.camel@gibraltar.str.redhat.com> <20080429154009.GR26399@inocybe.teonanacatl.org> <1209506979.22831.121.camel@aglarond.local> <20080430025732.GV26399@inocybe.teonanacatl.org> <28979.192.54.193.59.1209541945.squirrel@rousalka.dyndns.org> <1209585473.4950.79.camel@localhost> <1209588047.29552.37.camel@rousalka.okg> <1209600192.30793.9.camel@valkyrie.localdomain> Message-ID: <1209653842.3204.32.camel@rousalka.okg> Le mercredi 30 avril 2008 ? 20:03 -0400, Matthew Saltzman a ?crit : > IIRC (maybe someone who was there can correct me), back in the early > days of Red Hat Linux (like 3.0.3 or something), the first experiment in > i18n was to create the Redneck locale (was it Donnie Barnes who was the > Carolina native who was the target of that little joke?). The staff > thought it was amusing enough that they left it in as a language option > in the installer, so you saw all the dialog boxes translated from > English to Redneck. > > I (transplanted Yankee) thought it was kind of amusing at the time, but > I suppose it doesn't really have a place in a polished, professional, > worldwide distro. The joke and even the cooked-up locale were fine. Calling attention to them in later release image trains was not. Like it or not but a core argument for Linux adoption outside the USA is to stop sending vast sums of money abroad to big American proprietary software houses. Insisting heavily on an American Fedora personality in our initial screens is thus self defeating (that is probably one reason Debian kicks our asses in all the government-sponsored non-US Linux desktop deployments BTW). Just read the grass-root reports on big Linux deployments that get regularly posted on Fedora planet (and other venues). Keeping money locally is always the first argument. When localisation, support for non latin scripts, and having a non-US-centric solution isn't. ? > My spell-checker is complaining about some of your 's''s 8^). That's probably because your spell-checker does not know my messages use the British English dialect. -- 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 billcrawford1970 at gmail.com Thu May 1 15:02:33 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Thu, 1 May 2008 16:02:33 +0100 Subject: Multilib Middle-Ground In-Reply-To: <4819C1EF.6050009@gmail.com> References: <4817FF36.10305@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819C1EF.6050009@gmail.com> Message-ID: <544eb990805010802r1168d091k6cae8fcd52f85f10@mail.gmail.com> On 01/05/2008, Les Mikesell wrote: > Would you mind leaving the 'p' word out of this discussion? The same > principle applies to all software that isn't recompiled and repackaged > between every version, including the user's own and other programs where > source is available but you don't want to have to rebuild (if we did want to > recompile every week we'd be running gentoo...). Pretending this is > specific to proprietary software puts the wrong spin on the conversation > here. The only difference being proprietary makes in this case is that > someone else needs to do this work and probably maintain specific versions > separately for each fedora version instead of every using doing that > himself. Except that ... where RPM packages are concerned, this usually happens with proprietary software. I've never built my own RPM packages that way, nor do most sane people. From paul at all-the-johnsons.co.uk Thu May 1 15:06:32 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Thu, 01 May 2008 16:06:32 +0100 Subject: libgtkmozembed.so Message-ID: <1209654392.3358.35.camel@T7.Linux> Hi, I'm still trying to find out why monodevelop is kicking up a stink over not allowing it's text editor to work. The last three things I can see is that MOZILLA_FIVE_HOME is not defined, inotify is using a smaller value and that libgtkmozembed.so is missing. From what I can see, this used to be in firefox-devel, possibly should be in thunderbird, possibly in seamonkey and maybe in xulrunner. It's in none of them. Does anyone know where is should be so that I can try and eliminate that as the cause? TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From lesmikesell at gmail.com Thu May 1 15:12:25 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 01 May 2008 10:12:25 -0500 Subject: Multilib Middle-Ground In-Reply-To: <1209650282.3249.19.camel@cutter> References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819978A.80304@city-fan.org> <4819BCFD.5070108@gmail.com> <4819BE31.9030306@city-fan.org> <4819C2A9.3050202@gmail.com> <1209648138.3249.17.camel@cutter> <4819CBA5.3010505@gmail.com> <1209650282.3249.19.camel@cutter> Message-ID: <4819DDD9.3070504@gmail.com> seth vidal wrote: > On Thu, 2008-05-01 at 08:54 -0500, Les Mikesell wrote: >> seth vidal wrote: >>> On Thu, 2008-05-01 at 08:16 -0500, Les Mikesell wrote: >>>>> Stripping of pathname-based and package-name based dependencies I can >>>>> understand, but not the library deps. >>>> Are they the same across all RPM based systems? >>>> >>> The library deps sorta have to be. The deps come out of what the program >>> is linked to. >>> >>> as an example run: >>> ldd /usr/bin/xterm >>> >>> and look at what it outputs >>> >> VMWare-server should probably be split into two packages. Only the >> console portion needs the X libs and you can run it on a different >> machine, a different OS, or not at all, so it wouldn't make much sense >> for a run-time dependency for that part to prevent installation of the >> rest of the server. > > umm, okay. But no one here controls the vmware package. Hell, speaking > for just me, I don't even CARE about vmware. I read that as "I don't care about fedora users" that want to run applications of their choice. Whether that's what you mean or not, I suspect I'm not the only one who sees that as the end result. If fedora doesn't care about its users it will simply be irrelevant. If you want a hint about how others feel, go to the distrowatch.com page and adjust the time span setting to something recent on the part that shows interest in various distributions. -- Les Mikesell lesmikesell at gmail.com From rjones at redhat.com Thu May 1 15:17:21 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 1 May 2008 16:17:21 +0100 Subject: Review swapsies In-Reply-To: <870180fe0805010741y1d0d53d8w21cdc7896a46bebc@mail.gmail.com> References: <48199C46.1070903@hhs.nl> <20080501124945.GA25217@amd.home.annexia.org> <870180fe0805010741y1d0d53d8w21cdc7896a46bebc@mail.gmail.com> Message-ID: <20080501151721.GA26900@amd.home.annexia.org> On Thu, May 01, 2008 at 08:41:28AM -0600, Jerry James wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=262401 (jcip-annotations) > https://bugzilla.redhat.com/show_bug.cgi?id=436033 (mona) OK I grabbed the two above. I'll do them by tomorrow morning. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From sundaram at fedoraproject.org Thu May 1 15:20:30 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 01 May 2008 20:50:30 +0530 Subject: Multilib Middle-Ground In-Reply-To: <4819DDD9.3070504@gmail.com> References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819978A.80304@city-fan.org> <4819BCFD.5070108@gmail.com> <4819BE31.9030306@city-fan.org> <4819C2A9.3050202@gmail.com> <1209648138.3249.17.camel@cutter> <4819CBA5.3010505@gmail.com> <1209650282.3249.19.camel@cutter> <4819DDD9.3070504@gmail.com> Message-ID: <4819DFBE.5060802@fedoraproject.org> Les Mikesell wrote: >> umm, okay. But no one here controls the vmware package. Hell, speaking >> for just me, I don't even CARE about vmware. > > I read that as "I don't care about fedora users" that want to run > applications of their choice. Whether that's what you mean or not, I > suspect I'm not the only one who sees that as the end result. This is just silly. Any advice on how VMWare should split it's package is completely offtopic for this list. Nobody here can do anything about how VMWare chooses to package anything. If fedora > doesn't care about its users it will simply be irrelevant. If you want a > hint about how others feel, go to the distrowatch.com page and adjust > the time span setting to something recent on the part that shows > interest in various distributions. Also read the distrowatch FAQ while you are at it that explains how unimportant it is. If you really believe the top most distribution in that list is the most popular globally, good luck. Rahul From aph at redhat.com Thu May 1 15:21:16 2008 From: aph at redhat.com (Andrew Haley) Date: Thu, 01 May 2008 16:21:16 +0100 Subject: Java debugging In-Reply-To: <870180fe0804301035y1be5302bm980c2cc87c0d86ab@mail.gmail.com> References: <870180fe0804281232m5740e3u4d1a47ba6bff009c@mail.gmail.com> <4816DE8B.8010102@redhat.com> <870180fe0804290938pbb73586o9033380c0eef7b52@mail.gmail.com> <481758D9.6030401@redhat.com> <870180fe0804291036v7a53caa0l2844679756abce94@mail.gmail.com> <481836E8.8010107@redhat.com> <870180fe0804301035y1be5302bm980c2cc87c0d86ab@mail.gmail.com> Message-ID: <4819DFEC.8030008@redhat.com> Jerry James wrote: > On Wed, Apr 30, 2008 at 3:07 AM, Andrew Haley wrote: >> I take your point. Does simply rebuilding that RPM fix this problem? > > For the benefit of the community at large, I'll repeat some > information I just posted to bug #434827. It seems that > java-1.5.0-gcj-devel has not been updated on F8 since the release of > F8, so the current version is 1.5.0.0-17.fc8, dated 17 Oct 2007. When > did the debuginfo fix go in? I asked the java-1.5.0-gcj-devel maintainer, and got the reply: "We generally don't do updates in Fedora except for security fixes. We fix bugs in Rawhide and if users of the latest stable Fedora badly want the bug fix they can install the Rawhide packages." It's pretty hard in this case, as that'll pull in java-1.5.0-gcj* as well. Sorry. Andrew. From aph at redhat.com Thu May 1 15:21:49 2008 From: aph at redhat.com (Andrew Haley) Date: Thu, 01 May 2008 16:21:49 +0100 Subject: Java debugging In-Reply-To: <870180fe0804300823j2f856fc1y6a020e4d7da13a5@mail.gmail.com> References: <870180fe0804281232m5740e3u4d1a47ba6bff009c@mail.gmail.com> <4816DE8B.8010102@redhat.com> <870180fe0804290938pbb73586o9033380c0eef7b52@mail.gmail.com> <481758D9.6030401@redhat.com> <870180fe0804291036v7a53caa0l2844679756abce94@mail.gmail.com> <481836E8.8010107@redhat.com> <870180fe0804300823j2f856fc1y6a020e4d7da13a5@mail.gmail.com> Message-ID: <4819E00D.6090508@redhat.com> Jerry James wrote: > On Wed, Apr 30, 2008 at 3:07 AM, Andrew Haley wrote: >> I take your point. Does simply rebuilding that RPM fix this problem? > > Rebuilding that RPM fails: > > [javac] /home/jamesjer/rpmbuild/BUILD/axis-1_2_1/src/org/apache/axis/i18n/ProjectResourceBundle.java:363: > clearCache() in org.apache.axis.i18n.ProjectResourceBundle cannot > override clearCache() in java.util.ResourceBundle; overridden method > is static final > [javac] public static void clearCache() > [javac] ^ I've looked, and I don't think it's possible to fix this for Java 1.6. In http://ws.apache.org/axis/java/apiDocs/org/apache/axis/i18n/ProjectResourceBundle.html, clearCache() is part of the public API. However, org.apache.axis.i18n.ProjectResourceBundle inherits from java.util.ResourceBundle, and that class marks clearCache() as final. We could delete clearCache() and just use the inherited method as a workaround, but it doesn't do the same thing. The only way to recompile this, or indeed to use it, is with Java < 1.6. Andrew. From jspaleta at gmail.com Thu May 1 15:23:11 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 1 May 2008 07:23:11 -0800 Subject: Multilib Middle-Ground In-Reply-To: <20080501110530.GA25448@imperial.ac.uk> References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <604aa7910804301429k472cc2bcq8f9a06c1acd70b33@mail.gmail.com> <20080501110530.GA25448@imperial.ac.uk> Message-ID: <604aa7910805010823u39dab3dvbec57e0e7a413c41@mail.gmail.com> On Thu, May 1, 2008 at 3:05 AM, Kostas Georgiou wrote: > There are 64bit versions of both so there is no need to install the > 32bit vesrions. wrong... mixed networks of 32bit and 64bit machines with network file mounts. Depending on the licensing terms and licensing server implementation you can cross the network mount boundary and run the executables at a cheaper cost than buying a copy for each and every machine to run locally if all you really need is a license to have a few simultaneous users at a time. -jef"I never said this was sane"spaleta From lesmikesell at gmail.com Thu May 1 15:46:02 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 01 May 2008 10:46:02 -0500 Subject: Multilib Middle-Ground In-Reply-To: <4819DFBE.5060802@fedoraproject.org> References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819978A.80304@city-fan.org> <4819BCFD.5070108@gmail.com> <4819BE31.9030306@city-fan.org> <4819C2A9.3050202@gmail.com> <1209648138.3249.17.camel@cutter> <4819CBA5.3010505@gmail.com> <1209650282.3249.19.camel@cutter> <4819DDD9.3070504@gmail.com> <4819DFBE.5060802@fedoraproject.org> Message-ID: <4819E5BA.6030503@gmail.com> Rahul Sundaram wrote: > > >>> umm, okay. But no one here controls the vmware package. Hell, speaking >>> for just me, I don't even CARE about vmware. >> >> I read that as "I don't care about fedora users" that want to run >> applications of their choice. Whether that's what you mean or not, I >> suspect I'm not the only one who sees that as the end result. > > This is just silly. Any advice on how VMWare should split it's package > is completely offtopic for this list. Nobody here can do anything about > how VMWare chooses to package anything. No, but you can - and do - make it difficult for 3rd party packagers to build RPMs that work across multiple distros/versions, and for users to install such packages. It is silly if you don't see that, or that Red Hat doesn't care if fedora alienates the potential users of RPM and 'system-config-xxx' based distributions. > Also read the distrowatch FAQ while you are at it that explains how > unimportant it is. If you really believe the top most distribution in > that list is the most popular globally, good luck. Where can I find better metrics? -- Les Mikesell lesmikesell at gmail.com From cjdahlin at ncsu.edu Thu May 1 15:46:42 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Thu, 01 May 2008 11:46:42 -0400 Subject: F9 installation screenshot In-Reply-To: <1209653842.3204.32.camel@rousalka.okg> References: <8990327d0804290423o6bef20c0g8ab07576ea81068@mail.gmail.com> <20080429121439.GN27333@localhost.localdomain> <8990327d0804290558k5f32d775ic9ddd24b164f4744@mail.gmail.com> <8990327d0804290600x12482214s97fc57b14098f3be@mail.gmail.com> <1209481464.18191.6.camel@gibraltar.str.redhat.com> <20080429154009.GR26399@inocybe.teonanacatl.org> <1209506979.22831.121.camel@aglarond.local> <20080430025732.GV26399@inocybe.teonanacatl.org> <28979.192.54.193.59.1209541945.squirrel@rousalka.dyndns.org> <1209585473.4950.79.camel@localhost> <1209588047.29552.37.camel@rousalka.okg> <1209600192.30793.9.camel@valkyrie.localdomain> <1209653842.3204.32.camel@rousalka.okg> Message-ID: <4819E5E2.1070804@ncsu.edu> Nicolas Mailhot wrote: > Le mercredi 30 avril 2008 ? 20:03 -0400, Matthew Saltzman a ?crit : > > >> IIRC (maybe someone who was there can correct me), back in the early >> days of Red Hat Linux (like 3.0.3 or something), the first experiment in >> i18n was to create the Redneck locale (was it Donnie Barnes who was the >> Carolina native who was the target of that little joke?). The staff >> thought it was amusing enough that they left it in as a language option >> in the installer, so you saw all the dialog boxes translated from >> English to Redneck. >> >> I (transplanted Yankee) thought it was kind of amusing at the time, but >> I suppose it doesn't really have a place in a polished, professional, >> worldwide distro. >> > > The joke and even the cooked-up locale were fine. Calling attention to > them in later release image trains was not. Like it or not but a core > argument for Linux adoption outside the USA is to stop sending vast sums > of money abroad to big American proprietary software houses. Insisting > heavily on an American Fedora personality in our initial screens is thus > self defeating (that is probably one reason Debian kicks our asses in > all the government-sponsored non-US Linux desktop deployments BTW). > > Just read the grass-root reports on big Linux deployments that get > regularly posted on Fedora planet (and other venues). Keeping money > locally is always the first argument. When localisation, support for non > latin scripts, and having a non-US-centric solution isn't. > ? > >> My spell-checker is complaining about some of your 's''s 8^). >> > > That's probably because your spell-checker does not know my messages use > the British English dialect. > > Wow. I didn't realize that participating in Fedora was such an anti-patriotic activity on my part. I thought the purpose of open source was to produce a quality product, not deprive the fat, stupid, greedy American pig-dogs of their proprietary software blood money. --CJD From lemenkov at gmail.com Thu May 1 15:51:05 2008 From: lemenkov at gmail.com (Peter Lemenkov) Date: Thu, 1 May 2008 19:51:05 +0400 Subject: How to downgrade Fedora to previous release? In-Reply-To: <1209307875.10594.3.camel@rousalka.okg> References: <4814596D.2020107@hhs.nl> <1209307875.10594.3.camel@rousalka.okg> Message-ID: 2008/4/27 Nicolas Mailhot : > BTW could you specify what xorg driver you use please? Someone posted a > mail on the xorg lists recently complaining the intel driver broke font > rendering > > http://lists.freedesktop.org/archives/xorg/2008-April/034940.html Filled a bug. https://bugzilla.redhat.com/show_bug.cgi?id=444890 -- With best regards! From sundaram at fedoraproject.org Thu May 1 16:01:31 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 01 May 2008 21:31:31 +0530 Subject: Multilib Middle-Ground In-Reply-To: <4819E5BA.6030503@gmail.com> References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819978A.80304@city-fan.org> <4819BCFD.5070108@gmail.com> <4819BE31.9030306@city-fan.org> <4819C2A9.3050202@gmail.com> <1209648138.3249.17.camel@cutter> <4819CBA5.3010505@gmail.com> <1209650282.3249.19.camel@cutter> <4819DDD9.3070504@gmail.com> <4819DFBE.5060802@fedoraproject.org> <4819E5BA.6030503@gmail.com> Message-ID: <4819E95B.4090402@fedoraproject.org> Les Mikesell wrote: > No, but you can - and do - make it difficult for 3rd party packagers to > build RPMs that work across multiple distros/versions, and for users to > install such packages. It is silly if you don't see that, or that Red > Hat doesn't care if fedora alienates the potential users of RPM and > 'system-config-xxx' based distributions. In this case, the packager is deliberately overriding the dependency mechanism and not using file based dependencies that make it work across the distribution. There is really no excuse for not using the tools provided. VMWare packaging is just broken and suggestions on what they should do should be taken to them. Not here. Save yourself the trouble. >> Also read the distrowatch FAQ while you are at it that explains how >> unimportant it is. If you really believe the top most distribution in >> that list is the most popular globally, good luck. > > Where can I find better metrics? The usual method used by research firms is to track revenue but that covers only commercial distributions. RHEL has a known majority market share there and none of the commercial distributions would ever show up very high on the distrowatch stats. You can't find any good metrics on usage of non commercial or free distributions. Fedora uses Smolt. Refer https://fedoraproject.org/wiki/Statistics Other distributions are beginning to adopt it. If it gets integrated better, it could provide more useful metrics for more distributions. Without invasive techniques likely compulsory registration or automatic phoning home options, the metrics are bound to be inherently fuzzy however. Some details on that at http://fedoraproject.org/wiki/Infrastructure/Metrics Rahul From kevin.kofler at chello.at Thu May 1 16:02:06 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 1 May 2008 16:02:06 +0000 (UTC) Subject: Multilib Middle-Ground References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819C1EF.6050009@gmail.com> <4819DA81.4010607@gmail.com> Message-ID: Les Mikesell gmail.com> writes: > I don't understand why anyone would have any interest in an operating > system that can only run its own programs. Aside from the obvious > limitations since no one could seriously expect it to include all > possibilities, it has to be an enormous waste of effort to build the > specialized versions and package them in repositories that few people > will use anyway. Yet that's exactly what's supposed to happen. Software should be packaged for Fedora, and rebuilt whenever necessary (which is not necessarily every single Fedora release, it really depends on what libraries the package uses). Free Software makes it easy because anyone interested in using the package on Fedora can package it, not just upstream. It's the proprietary stuff which you aren't allowed to redistribute and repackage which causes all the problems. Kevin Kofler From kevin.kofler at chello.at Thu May 1 16:04:53 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 1 May 2008 16:04:53 +0000 (UTC) Subject: Multilib Middle-Ground References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819C1EF.6050009@gmail.com> Message-ID: Les Mikesell gmail.com> writes: > Would you mind leaving the 'p' word out of this discussion? The same > principle applies to all software that isn't recompiled and repackaged > between every version, including the user's own and other programs where > source is available but you don't want to have to rebuild (if we did > want to recompile every week we'd be running gentoo...). Unlike on Gentoo, the user doesn't have to rebuild the packages, only one packager has to do it and all the users just get the packages from the packager, be it from the Fedora repository or a third-party repository. The 'p' word comes into play because proprietary licenses tend to disallow or at least limit (e.g. no way to rebuild from source because you don't have it) repackaging, which is the real cause of your problem. Kevin Kofler From kevin.kofler at chello.at Thu May 1 16:07:30 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 1 May 2008 16:07:30 +0000 (UTC) Subject: Multilib Middle-Ground References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819978A.80304@city-fan.org> <4819BCFD.5070108@gmail.com> <4819BE31.9030306@city-fan.org> <4819C2A9.3050202@gmail.com> <1209648138.3249.17.camel@cutter> <4819CBA5.3010505@gmail.com> <1209650282.3249.19.camel@cutter> <4819DDD9.3070504@gmail.com> Message-ID: Les Mikesell gmail.com> writes: > I read that as "I don't care about fedora users" that want to run > applications of their choice. Where have you seen "proprietary software" in the Fedora Objectives? You can't fault Fedora maintainers for not caring about the applications of your choice if said applications are proprietary. (That said, I don't speak for the Fedora project as a whole and there are maintainers like Warren Togami who _do_ care about making proprietary software work.) Kevin Kofler From jspaleta at gmail.com Thu May 1 16:14:44 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 1 May 2008 08:14:44 -0800 Subject: Multilib Middle-Ground In-Reply-To: References: <4817FF36.10305@redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819C1EF.6050009@gmail.com> Message-ID: <604aa7910805010914n987c810g4591ff3065f8844b@mail.gmail.com> On Thu, May 1, 2008 at 8:04 AM, Kevin Kofler wrote: > Unlike on Gentoo, the user doesn't have to rebuild the packages, only one > packager has to do it and all the users just get the packages from the > packager, be it from the Fedora repository or a third-party repository. The 'p' > word comes into play because proprietary licenses tend to disallow or at least > limit (e.g. no way to rebuild from source because you don't have it) > repackaging, which is the real cause of your problem. And there's always the nosrc games you can play like jpackage does/did to work around the distribution legalities for proprietary junk. Even in a perfect world where all the rpm based distributions came to an agreement on how to package everything self-consistently, we still wouldn't have a mechanism to force proprietary vendors to use best practices... not when there are tools like checkinstall out and about to short-circuit the standard rpm packaging process for proprietary distributors to abuse. -jef From kevin.kofler at chello.at Thu May 1 16:13:39 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 1 May 2008 16:13:39 +0000 (UTC) Subject: Multilib Middle-Ground References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <604aa7910804301429k472cc2bcq8f9a06c1acd70b33@mail.gmail.com> <20080501110530.GA25448@imperial.ac.uk> <1b7401870805010516k7d3c0cadp5df5c1a162ebd2d4@mail.gmail.com> Message-ID: Josef Bacik toxicpanda.com> writes: > So we as the Fedora community, who are strongly dedicated to being > open and free, are going to great lengths in order to make sure that > we can better use proprietary applications/formats? [snip] > forcing everybody to have twice the number of packages installed is a > poor answer. +1 to all your message (including the parts I snipped, and no, I don't use Flash either). Kevin Kofler From pertusus at free.fr Thu May 1 16:23:14 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 1 May 2008 18:23:14 +0200 Subject: Multilib Middle-Ground In-Reply-To: <4819E5BA.6030503@gmail.com> References: <4819978A.80304@city-fan.org> <4819BCFD.5070108@gmail.com> <4819BE31.9030306@city-fan.org> <4819C2A9.3050202@gmail.com> <1209648138.3249.17.camel@cutter> <4819CBA5.3010505@gmail.com> <1209650282.3249.19.camel@cutter> <4819DDD9.3070504@gmail.com> <4819DFBE.5060802@fedoraproject.org> <4819E5BA.6030503@gmail.com> Message-ID: <20080501162314.GC16265@free.fr> On Thu, May 01, 2008 at 10:46:02AM -0500, Les Mikesell wrote: > > No, but you can - and do - make it difficult for 3rd party packagers to > build RPMs that work across multiple distros/versions, and for users to > install such packages. It is silly if you don't see that, or that Red Hat > doesn't care if fedora alienates the potential users of RPM and > 'system-config-xxx' based distributions. It is not fedora, but upstream library maintainers (see my other mail). -- Pat From j.w.r.degoede at hhs.nl Thu May 1 16:40:21 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 01 May 2008 18:40:21 +0200 Subject: How to downgrade Fedora to previous release? In-Reply-To: References: <4814596D.2020107@hhs.nl> <1209307875.10594.3.camel@rousalka.okg> Message-ID: <4819F275.5080904@hhs.nl> Peter Lemenkov wrote: > 2008/4/27 Nicolas Mailhot : > >> BTW could you specify what xorg driver you use please? Someone posted a >> mail on the xorg lists recently complaining the intel driver broke font >> rendering >> >> http://lists.freedesktop.org/archives/xorg/2008-April/034940.html > > Filled a bug. > > https://bugzilla.redhat.com/show_bug.cgi?id=444890 > Good! Regards, Hans From lesmikesell at gmail.com Thu May 1 17:01:55 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 01 May 2008 12:01:55 -0500 Subject: Multilib Middle-Ground In-Reply-To: <4819E95B.4090402@fedoraproject.org> References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819978A.80304@city-fan.org> <4819BCFD.5070108@gmail.com> <4819BE31.9030306@city-fan.org> <4819C2A9.3050202@gmail.com> <1209648138.3249.17.camel@cutter> <4819CBA5.3010505@gmail.com> <1209650282.3249.19.camel@cutter> <4819DDD9.3070504@gmail.com> <4819DFBE.5060802@fedoraproject.org> <4819E5BA.6030503@gmail.com> <4819E95B.4090402@fedoraproject.org> Message-ID: <4819F783.7040804@gmail.com> Rahul Sundaram wrote: > >> No, but you can - and do - make it difficult for 3rd party packagers >> to build RPMs that work across multiple distros/versions, and for >> users to install such packages. It is silly if you don't see that, or >> that Red Hat doesn't care if fedora alienates the potential users of >> RPM and 'system-config-xxx' based distributions. > > In this case, the packager is deliberately overriding the dependency > mechanism and not using file based dependencies that make it work across > the distribution. There is really no excuse for not using the tools > provided. VMWare packaging is just broken and suggestions on what they > should do should be taken to them. Not here. Save yourself the trouble. But what I was trying to point out initially is that failing the install because one part has unsatisfied dependencies is counterproductive because you may not need to run that part. -- Les Mikesell lesmikesell at gmail.com From sundaram at fedoraproject.org Thu May 1 17:10:33 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 01 May 2008 22:40:33 +0530 Subject: Multilib Middle-Ground In-Reply-To: <4819F783.7040804@gmail.com> References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819978A.80304@city-fan.org> <4819BCFD.5070108@gmail.com> <4819BE31.9030306@city-fan.org> <4819C2A9.3050202@gmail.com> <1209648138.3249.17.camel@cutter> <4819CBA5.3010505@gmail.com> <1209650282.3249.19.camel@cutter> <4819DDD9.3070504@gmail.com> <4819DFBE.5060802@fedoraproject.org> <4819E5BA.6030503@gmail.com> <4819E95B.4090402@fedoraproject.org> <4819F783.7040804@gmail.com> Message-ID: <4819F989.20700@fedoraproject.org> Les Mikesell wrote: > > But what I was trying to point out initially is that failing the install > because one part has unsatisfied dependencies is counterproductive > because you may not need to run that part. If a software has optional components that are not really required to run the software, it should be split up into several sub packages so that you can run it without ignoring the dependencies. That is upto to the vendor is question since nobody else has even repackaging rights. Rahul From lesmikesell at gmail.com Thu May 1 17:18:24 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 01 May 2008 12:18:24 -0500 Subject: Multilib Middle-Ground In-Reply-To: <604aa7910805010914n987c810g4591ff3065f8844b@mail.gmail.com> References: <4817FF36.10305@redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819C1EF.6050009@gmail.com> <604aa7910805010914n987c810g4591ff3065f8844b@mail.gmail.com> Message-ID: <4819FB60.5000606@gmail.com> Jeff Spaleta wrote: > On Thu, May 1, 2008 at 8:04 AM, Kevin Kofler wrote: >> Unlike on Gentoo, the user doesn't have to rebuild the packages, only one >> packager has to do it and all the users just get the packages from the >> packager, be it from the Fedora repository or a third-party repository. The 'p' >> word comes into play because proprietary licenses tend to disallow or at least >> limit (e.g. no way to rebuild from source because you don't have it) >> repackaging, which is the real cause of your problem. > > > And there's always the nosrc games you can play like jpackage does/did > to work around the distribution legalities for proprietary junk. I'd say a more accurate description is that jpackage nosrc packages work around the peculiar packaging and PATH requirements of distributions that stubbornly refuse to standardize that crap and make it difficult for their users to install programs of their choice. > Even in a perfect world where all the rpm based distributions came to > an agreement on how to package everything self-consistently, Why just RPM based? And why hasn't even that happened in the decade+ when it has been around? > we still > wouldn't have a mechanism to force proprietary vendors to use best > practices... not when there are tools like checkinstall out and about > to short-circuit the standard rpm packaging process for proprietary > distributors to abuse. Why is there still the need to work around peculiar distribution practices? -- Les Mikesell lesmikesell at gmail.com From jspaleta at gmail.com Thu May 1 17:20:03 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 1 May 2008 09:20:03 -0800 Subject: Multilib Middle-Ground In-Reply-To: <4819FB60.5000606@gmail.com> References: <4817FF36.10305@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819C1EF.6050009@gmail.com> <604aa7910805010914n987c810g4591ff3065f8844b@mail.gmail.com> <4819FB60.5000606@gmail.com> Message-ID: <604aa7910805011020k4732d6cbv11ed7a813d9fa068@mail.gmail.com> On Thu, May 1, 2008 at 9:18 AM, Les Mikesell wrote: > I'd say a more accurate description is that jpackage nosrc packages work > around the peculiar packaging and PATH requirements of distributions that > stubbornly refuse to standardize that crap and make it difficult for their > users to install programs of their choice. Please point me to a comprehensive standardization initiative that I'm not already aware of in this area. -jef From seg at haxxed.com Thu May 1 17:24:04 2008 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 01 May 2008 12:24:04 -0500 Subject: Multilib Middle-Ground In-Reply-To: <4819DA81.4010607@gmail.com> References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819C1EF.6050009@gmail.com> <4819DA81.4010607@gmail.com> Message-ID: <1209662644.12336.1.camel@localhost> On Thu, 2008-05-01 at 09:58 -0500, Les Mikesell wrote: > I don't understand why anyone would have any interest in an operating > system that can only run its own programs. Aside from the obvious > limitations since no one could seriously expect it to include all > possibilities, it has to be an enormous waste of effort to build the > specialized versions and package them in repositories that few people > will use anyway. You clearly Don't Get It and no amount of explaining it to you is going to help. Please, just stop talking. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Thu May 1 17:27:42 2008 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 01 May 2008 12:27:42 -0500 Subject: Multilib Middle-Ground In-Reply-To: <1b7401870805010516k7d3c0cadp5df5c1a162ebd2d4@mail.gmail.com> References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <604aa7910804301429k472cc2bcq8f9a06c1acd70b33@mail.gmail.com> <20080501110530.GA25448@imperial.ac.uk> <1b7401870805010516k7d3c0cadp5df5c1a162ebd2d4@mail.gmail.com> Message-ID: <1209662862.12336.5.camel@localhost> On Thu, 2008-05-01 at 08:16 -0400, Josef Bacik wrote: > What exactly is the purpose of installing 32bit binaries on a 64bit > box? WINE, which has legitimate open source purposes. Sorry, some of us pay our rent by developing open source that runs on Windows. I'm not going to live in my car for the sake of ideological purity. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From lesmikesell at gmail.com Thu May 1 17:41:03 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 01 May 2008 12:41:03 -0500 Subject: Multilib Middle-Ground In-Reply-To: <1209662644.12336.1.camel@localhost> References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819C1EF.6050009@gmail.com> <4819DA81.4010607@gmail.com> <1209662644.12336.1.camel@localhost> Message-ID: <481A00AF.5000307@gmail.com> Callum Lerwick wrote: > On Thu, 2008-05-01 at 09:58 -0500, Les Mikesell wrote: >> I don't understand why anyone would have any interest in an operating >> system that can only run its own programs. Aside from the obvious >> limitations since no one could seriously expect it to include all >> possibilities, it has to be an enormous waste of effort to build the >> specialized versions and package them in repositories that few people >> will use anyway. > > You clearly Don't Get It and no amount of explaining it to you is going > to help. Please, just stop talking. No, I don't expect any amount of explaining to make me want something that is clearly not useful to me. This isn't the first time you've had a choice about supporting multi-arch libs though. Why the hostility when changing your own direction? -- Les Mikesell lesmikesell at gmail.com From lesmikesell at gmail.com Thu May 1 17:45:59 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 01 May 2008 12:45:59 -0500 Subject: Multilib Middle-Ground In-Reply-To: References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819978A.80304@city-fan.org> <4819BCFD.5070108@gmail.com> <4819BE31.9030306@city-fan.org> <4819C2A9.3050202@gmail.com> <1209648138.3249.17.camel@cutter> <4819CBA5.3010505@gmail.com> <1209650282.3249.19.camel@cutter> <4819DDD9.3070504@gmail.com> Message-ID: <481A01D7.3090009@gmail.com> Kevin Kofler wrote: > Les Mikesell gmail.com> writes: >> I read that as "I don't care about fedora users" that want to run >> applications of their choice. > > Where have you seen "proprietary software" in the Fedora Objectives? You can't > fault Fedora maintainers for not caring about the applications of your choice > if said applications are proprietary. As I said in the previous message, this isn't limited to proprietary software, it affects everything that you don't want to recompile and repackages for every distro/version. And more to the point, such things should be the user's choice, and the distribution either works to support users or not. -- Les Mikesell lesmikesell at gmail.com From seg at haxxed.com Thu May 1 17:52:35 2008 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 01 May 2008 12:52:35 -0500 Subject: is xorg.conf still needed In-Reply-To: <200805010556.57121.dwight@supercomputer.org> References: <1209523940.2906.136.camel@localhost.localdomain> <200804302029.10986.dwight@supercomputer.org> <1209619732.4950.96.camel@localhost> <200805010556.57121.dwight@supercomputer.org> Message-ID: <1209664355.12336.16.camel@localhost> On Thu, 2008-05-01 at 04:56 -0800, dwight at supercomputer.org wrote: > I don't believe it, but your reply doesn't answer my question. > Where's the roadmap, and what's the plan for getting there? And > who's in charge, and who's involved? Who's involved? Google is currently leading the way, especially in the "back end": http://www.google.com/a/help/intl/en/var_0.html GNOME is working on a front end: http://live.gnome.org/OnlineDesktop And Red Hat is integrating it all: http://mugshot.org/ If you're expecting roadmaps and plans, you're going to be disappointed. This is new territory, just being discovered. Who's in charge? Whoever gets there first. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mjs at clemson.edu Thu May 1 17:59:56 2008 From: mjs at clemson.edu (Matthew Saltzman) Date: Thu, 01 May 2008 17:59:56 +0000 Subject: F9 installation screenshot In-Reply-To: <1209653842.3204.32.camel@rousalka.okg> References: <8990327d0804290423o6bef20c0g8ab07576ea81068@mail.gmail.com> <20080429121439.GN27333@localhost.localdomain> <8990327d0804290558k5f32d775ic9ddd24b164f4744@mail.gmail.com> <8990327d0804290600x12482214s97fc57b14098f3be@mail.gmail.com> <1209481464.18191.6.camel@gibraltar.str.redhat.com> <20080429154009.GR26399@inocybe.teonanacatl.org> <1209506979.22831.121.camel@aglarond.local> <20080430025732.GV26399@inocybe.teonanacatl.org> <28979.192.54.193.59.1209541945.squirrel@rousalka.dyndns.org> <1209585473.4950.79.camel@localhost> <1209588047.29552.37.camel@rousalka.okg> <1209600192.30793.9.camel@valkyrie.localdomain> <1209653842.3204.32.camel@rousalka.okg> Message-ID: <1209664796.19564.35.camel@valkyrie.localdomain> On Thu, 2008-05-01 at 16:57 +0200, Nicolas Mailhot wrote: > Le mercredi 30 avril 2008 ? 20:03 -0400, Matthew Saltzman a ?crit : > > > IIRC (maybe someone who was there can correct me), back in the early > > days of Red Hat Linux (like 3.0.3 or something), the first experiment in > > i18n was to create the Redneck locale (was it Donnie Barnes who was the > > Carolina native who was the target of that little joke?). The staff > > thought it was amusing enough that they left it in as a language option > > in the installer, so you saw all the dialog boxes translated from > > English to Redneck. > > > > I (transplanted Yankee) thought it was kind of amusing at the time, but > > I suppose it doesn't really have a place in a polished, professional, > > worldwide distro. > > The joke and even the cooked-up locale were fine. Calling attention to > them in later release image trains was not. Like it or not but a core > argument for Linux adoption outside the USA is to stop sending vast sums > of money abroad to big American proprietary software houses. Insisting > heavily on an American Fedora personality in our initial screens is thus > self defeating (that is probably one reason Debian kicks our asses in > all the government-sponsored non-US Linux desktop deployments BTW). Maybe I'm just insensitive, but I haven't noticed too much US-centric stuff on the installer pages (other than the fact that, until you select a language, the messages are in US English). Really obvious chauvinism annoys me, too. I'll have to try to see the F9 installer through your eyes. But if the option is no longer there, then one might conclude that RH has caught on to your point. > > Just read the grass-root reports on big Linux deployments that get > regularly posted on Fedora planet (and other venues). Keeping money > locally is always the first argument. When localisation, support for non > latin scripts, and having a non-US-centric solution isn't. > ? > > My spell-checker is complaining about some of your 's''s 8^). > > That's probably because your spell-checker does not know my messages use > the British English dialect. That's settable with a checkbox. It complained about the French, too. But it did display the accent on the e in "?crit". Your smiley detector appears to be off... -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From cmadams at hiwaay.net Thu May 1 18:18:21 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 1 May 2008 13:18:21 -0500 Subject: Multilib Middle-Ground In-Reply-To: <1209662862.12336.5.camel@localhost> References: <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <604aa7910804301429k472cc2bcq8f9a06c1acd70b33@mail.gmail.com> <20080501110530.GA25448@imperial.ac.uk> <1b7401870805010516k7d3c0cadp5df5c1a162ebd2d4@mail.gmail.com> <1209662862.12336.5.camel@localhost> Message-ID: <20080501181821.GC1427923@hiwaay.net> Once upon a time, Callum Lerwick said: > WINE, which has legitimate open source purposes. Sorry, some of us pay > our rent by developing open source that runs on Windows. I'm not going > to live in my car for the sake of ideological purity. Is there a bug that prevents "yum install wine" from pulling in the 32 bit libraries as needed? Anything packaged properly in RPMs will get necessary dependencies installed automatically when installed with yum (or the GUI). The only reason to include 32 bit libraries in a default install of a 64 bit system is if there is a 32 bit binary in the default install. After much encouragement, Adobe has RPMs in a repo for Flash and Acrobat Reader. Java is now in the distribution (as are replacements for flash and acroread, although still less-functional at this time). You can get additional commonly-useful software from other third-party repos. For all of those, dependencies are handled automatically. You cannot anticipate what dependencies _any_ non-RPM-packaged programs may have (it doesn't really matter if the non-RPM software is open source or proprietary); trying to pre-install possible dependencies is a never-ending path to insanity. If every random dependency has to be pre-installed just in case, Fedora might as well just start requiring Blu-Ray drives, as the "default" install won't fit on a DVD anymore. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From loganjerry at gmail.com Thu May 1 19:07:03 2008 From: loganjerry at gmail.com (Jerry James) Date: Thu, 1 May 2008 13:07:03 -0600 Subject: Java debugging In-Reply-To: <4819E00D.6090508@redhat.com> References: <870180fe0804281232m5740e3u4d1a47ba6bff009c@mail.gmail.com> <4816DE8B.8010102@redhat.com> <870180fe0804290938pbb73586o9033380c0eef7b52@mail.gmail.com> <481758D9.6030401@redhat.com> <870180fe0804291036v7a53caa0l2844679756abce94@mail.gmail.com> <481836E8.8010107@redhat.com> <870180fe0804300823j2f856fc1y6a020e4d7da13a5@mail.gmail.com> <4819E00D.6090508@redhat.com> Message-ID: <870180fe0805011207t19b9269tf251507dcffab869@mail.gmail.com> On Thu, May 1, 2008 at 9:21 AM, Andrew Haley wrote: > I've looked, and I don't think it's possible to fix this for Java 1.6. > > In > http://ws.apache.org/axis/java/apiDocs/org/apache/axis/i18n/ProjectResourceBundle.html, > clearCache() is part of the public API. However, > org.apache.axis.i18n.ProjectResourceBundle inherits from > java.util.ResourceBundle, and that class marks clearCache() as final. > We could delete clearCache() and just use the inherited method as > a workaround, but it doesn't do the same thing. > > The only way to recompile this, or indeed to use it, is with > Java < 1.6. Yes. On the other hand, it's an old version of an obsolete product, with at least one serious bug that I can easily demonstrate, so I don't think we should suffer any heartburn over it. What we need to do is work on getting axis2 packaged. Jpackage already has it, which should makes things easier. Who else out there is interested in getting a modern web services platform put together for Fedora? We should coordinate efforts. I am being forced to consume an external web service that has references to the apachesoap namespace, meaning it can only be consumed by axis. My organization uses CXF to produce our own web services. I can *probably* get my boss to give me some work cycles towards getting one or both platforms packaged for Fedora, and then we can just ditch the obsolete, buggy, unrecompilable axis package. -- Jerry James http://loganjerry.googlepages.com/ From jkeating at redhat.com Thu May 1 19:06:41 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 01 May 2008 12:06:41 -0700 Subject: Multilib Middle-Ground In-Reply-To: <4819C965.9070707@redhat.com> References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <604aa7910804301429k472cc2bcq8f9a06c1acd70b33@mail.gmail.com> <1209599611.4950.88.camel@localhost> <4819C965.9070707@redhat.com> Message-ID: <1209668801.3616.2.camel@localhost.localdomain> On Thu, 2008-05-01 at 09:45 -0400, Warren Togami wrote: > A great many 32bit software stops working > properly, And what would this software be? -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From loganjerry at gmail.com Thu May 1 19:09:13 2008 From: loganjerry at gmail.com (Jerry James) Date: Thu, 1 May 2008 13:09:13 -0600 Subject: Java debugging In-Reply-To: <4819DFEC.8030008@redhat.com> References: <870180fe0804281232m5740e3u4d1a47ba6bff009c@mail.gmail.com> <4816DE8B.8010102@redhat.com> <870180fe0804290938pbb73586o9033380c0eef7b52@mail.gmail.com> <481758D9.6030401@redhat.com> <870180fe0804291036v7a53caa0l2844679756abce94@mail.gmail.com> <481836E8.8010107@redhat.com> <870180fe0804301035y1be5302bm980c2cc87c0d86ab@mail.gmail.com> <4819DFEC.8030008@redhat.com> Message-ID: <870180fe0805011209j45a41560td588fd36f98394bc@mail.gmail.com> On Thu, May 1, 2008 at 9:21 AM, Andrew Haley wrote: > I asked the java-1.5.0-gcj-devel maintainer, and got the reply: > > "We generally don't do updates in Fedora except for security fixes. > We fix bugs in Rawhide and if users of the latest stable Fedora badly > want the bug fix they can install the Rawhide packages." > > It's pretty hard in this case, as that'll pull in java-1.5.0-gcj* > as well. Sorry. Correct me if I'm wrong in reaching these conclusions: 1. No F8 Java debuginfo package includes sources. 2. This will not be fixed. -- Jerry James http://loganjerry.googlepages.com/ From lesmikesell at gmail.com Thu May 1 19:27:54 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 01 May 2008 14:27:54 -0500 Subject: Multilib Middle-Ground In-Reply-To: <604aa7910805011020k4732d6cbv11ed7a813d9fa068@mail.gmail.com> References: <4817FF36.10305@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819C1EF.6050009@gmail.com> <604aa7910805010914n987c810g4591ff3065f8844b@mail.gmail.com> <4819FB60.5000606@gmail.com> <604aa7910805011020k4732d6cbv11ed7a813d9fa068@mail.gmail.com> Message-ID: <481A19BA.6090705@gmail.com> Jeff Spaleta wrote: > >> I'd say a more accurate description is that jpackage nosrc packages work >> around the peculiar packaging and PATH requirements of distributions that >> stubbornly refuse to standardize that crap and make it difficult for their >> users to install programs of their choice. > > Please point me to a comprehensive standardization initiative that I'm > not already aware of in this area. It's just depressing that no one is interested in this sort of cooperation and would prefer to force every possible application to be rebuilt/repackaged and re-distributed for every version of every distro to deal with the weirdness they each add. What's the point? Once something works it should never have to be changed. At most, new shared libs should fix up anything it needs. -- Les Mikesell lesmikesell at gmail.com From jspaleta at gmail.com Thu May 1 19:44:55 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 1 May 2008 11:44:55 -0800 Subject: Multilib Middle-Ground In-Reply-To: <481A19BA.6090705@gmail.com> References: <4817FF36.10305@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819C1EF.6050009@gmail.com> <604aa7910805010914n987c810g4591ff3065f8844b@mail.gmail.com> <4819FB60.5000606@gmail.com> <604aa7910805011020k4732d6cbv11ed7a813d9fa068@mail.gmail.com> <481A19BA.6090705@gmail.com> Message-ID: <604aa7910805011244q78338786y956500dd55649441@mail.gmail.com> On Thu, May 1, 2008 at 11:27 AM, Les Mikesell wrote: > It's just depressing that no one is interested in this sort of cooperation > and would prefer to force every possible application to be > rebuilt/repackaged and re-distributed for every version of every distro to > deal with the weirdness they each add. What's the point? Once something > works it should never have to be changed. At most, new shared libs should > fix up anything it needs. I'm trying to give you the benefit of the doubt with regard to knowledge of a standardization initiative that I am not currently aware of. You've made some pretty firm accusations that we as a project are ignoring some sort of a longstanding cross-distro standardization effort with regard to rpm packaging. If such an effort exists that I'm am not aware of, this is your opportunity to educate me. If you succeed in squandering this opportunity, you've pretty much guaranteed that I'm going to tune you out in favor of spending my time as a board member listening and interacting with other people who have useful and constructive information which underlines their criticism. More than that in fact, if you squander this chance to education me, once I'm off the board I'll be an active detractor of every single proposal you put forward regardless of merit. -jef"the obove can be quickly translated as... vote for me in the next Board election or you'll be sorry"spaleta From csnook at redhat.com Thu May 1 19:53:45 2008 From: csnook at redhat.com (Chris Snook) Date: Thu, 01 May 2008 15:53:45 -0400 Subject: Multilib Middle-Ground In-Reply-To: References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> Message-ID: <481A1FC9.8050901@redhat.com> Colin Walters wrote: > On Wed, Apr 30, 2008 at 4:08 PM, Chris Snook wrote: >> [X] Install 32-bit libraries > > I think we want to move away from "Build your own Linux", rather than > closer; and these kinds of questions move us in the wrong direction. > > There is a more general problem at work here - we want to provide > packages so that third party software can work, even though nothing > else in the install image depends on it. For example of how this > isn't just an x86_64 issue; some things out there require > compat-libstdc++, or at least they did in the recent past. We do? A lot of people don't. > The right way to approach this I think is to target specific third > party applications which we want to work out of the box. Say for > example, Flash and VMWare Workstation. Surely there are others, but I > think we can arrive at a reasonably sane set. We then add these > packages to the default install image. NO! That is absolutely the wrong way to approach this. That encourages people to keep their software closed and out of the distribution. We should be encouraging people to include their software in the distribution, or at the very least, to package it in a manner that integrates well with the distribution. >> [ ] Install development headers > > Hmm? I don't see what you want here that's not covered by the > combination of the "Development Tools" comps group as well as > yum-builddep. > That only covers core things like glibc. There are loads of -devel packages, which a small minority of very important users (software developers) may want installed, but only when they have the corresponding library installed. I'm not wedded to this idea, but it illustrates my point about thinking of packaging associatively, rather than hierarchically. -- Chris From loganjerry at gmail.com Thu May 1 19:48:29 2008 From: loganjerry at gmail.com (Jerry James) Date: Thu, 1 May 2008 13:48:29 -0600 Subject: Review swapsies In-Reply-To: <20080501151721.GA26900@amd.home.annexia.org> References: <48199C46.1070903@hhs.nl> <20080501124945.GA25217@amd.home.annexia.org> <870180fe0805010741y1d0d53d8w21cdc7896a46bebc@mail.gmail.com> <20080501151721.GA26900@amd.home.annexia.org> Message-ID: <870180fe0805011248s9f100r5070e8503098081@mail.gmail.com> On Thu, May 1, 2008 at 9:17 AM, Richard W.M. Jones wrote: > On Thu, May 01, 2008 at 08:41:28AM -0600, Jerry James wrote: > > https://bugzilla.redhat.com/show_bug.cgi?id=262401 (jcip-annotations) > > https://bugzilla.redhat.com/show_bug.cgi?id=436033 (mona) > > OK I grabbed the two above. > > I'll do them by tomorrow morning. You took two, and I only took one. Now I feel guilty.... -- Jerry James, wallowing in guilt http://loganjerry.googlepages.com/ From skvidal at fedoraproject.org Thu May 1 20:15:21 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 01 May 2008 16:15:21 -0400 Subject: Multilib Middle-Ground In-Reply-To: <4819DDD9.3070504@gmail.com> References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819978A.80304@city-fan.org> <4819BCFD.5070108@gmail.com> <4819BE31.9030306@city-fan.org> <4819C2A9.3050202@gmail.com> <1209648138.3249.17.camel@cutter> <4819CBA5.3010505@gmail.com> <1209650282.3249.19.camel@cutter> <4819DDD9.3070504@gmail.com> Message-ID: <1209672921.3249.28.camel@cutter> On Thu, 2008-05-01 at 10:12 -0500, Les Mikesell wrote: > > umm, okay. But no one here controls the vmware package. Hell, speaking > > for just me, I don't even CARE about vmware. > > I read that as "I don't care about fedora users" that want to run > applications of their choice. Why would you read it that way? That's not at all what I said. I said "I don't even care about vmware". That's it. it's b/c I don't. I was not speaking as a policy statement for fedora, nor red hat, not even for yum. I said "I DO NOT CARE ABOUT VMWARE" Take it at face value and please do not put words in my mouth. -sv -- I only speak for me. From skvidal at fedoraproject.org Thu May 1 20:17:22 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 01 May 2008 16:17:22 -0400 Subject: Multilib Middle-Ground In-Reply-To: <481A19BA.6090705@gmail.com> References: <4817FF36.10305@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819C1EF.6050009@gmail.com> <604aa7910805010914n987c810g4591ff3065f8844b@mail.gmail.com> <4819FB60.5000606@gmail.com> <604aa7910805011020k4732d6cbv11ed7a813d9fa068@mail.gmail.com> <481A19BA.6090705@gmail.com> Message-ID: <1209673042.3249.30.camel@cutter> On Thu, 2008-05-01 at 14:27 -0500, Les Mikesell wrote: > Jeff Spaleta wrote: > > > >> I'd say a more accurate description is that jpackage nosrc packages work > >> around the peculiar packaging and PATH requirements of distributions that > >> stubbornly refuse to standardize that crap and make it difficult for their > >> users to install programs of their choice. > > > > Please point me to a comprehensive standardization initiative that I'm > > not already aware of in this area. > > It's just depressing that no one is interested in this sort of > cooperation and would prefer to force every possible application to be > rebuilt/repackaged and re-distributed for every version of every distro > to deal with the weirdness they each add. What's the point? Once > something works it should never have to be changed. At most, new shared > libs should fix up anything it needs. > Go take a look at the lsb-discuss mailing list and the packaging mailing list. -sv From mschwendt at gmail.com Thu May 1 20:29:45 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 1 May 2008 22:29:45 +0200 Subject: /etc/alternatives not quite working In-Reply-To: <1209640378.3358.6.camel@T7.Linux> References: <1209640378.3358.6.camel@T7.Linux> Message-ID: <20080501222945.58527f9e.mschwendt@gmail.com> On Thu, 01 May 2008 12:12:57 +0100, Paul wrote: > Hi, > > For some odd reason emacs has stopped working on my system. Looking at > it, there wasn't anything in /etc/alternatives for it. Adding a symlink > from /etc/alternatives to /usr/bin/emacs-22.2 is doing nothing. > > Has something broken or is there something I need to do to register an > application in alternatives? It's in bugzilla for a long time. See: https://admin.fedoraproject.org/pkgdb/packages/bugs/emacs -- Fedora release 8 (Werewolf) - Linux 2.6.23.15-137.fc8 loadavg: 2.39 2.33 2.01 From nicolas.mailhot at laposte.net Thu May 1 20:35:32 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 01 May 2008 22:35:32 +0200 Subject: F9 installation screenshot In-Reply-To: <1209664796.19564.35.camel@valkyrie.localdomain> References: <8990327d0804290423o6bef20c0g8ab07576ea81068@mail.gmail.com> <20080429121439.GN27333@localhost.localdomain> <8990327d0804290558k5f32d775ic9ddd24b164f4744@mail.gmail.com> <8990327d0804290600x12482214s97fc57b14098f3be@mail.gmail.com> <1209481464.18191.6.camel@gibraltar.str.redhat.com> <20080429154009.GR26399@inocybe.teonanacatl.org> <1209506979.22831.121.camel@aglarond.local> <20080430025732.GV26399@inocybe.teonanacatl.org> <28979.192.54.193.59.1209541945.squirrel@rousalka.dyndns.org> <1209585473.4950.79.camel@localhost> <1209588047.29552.37.camel@rousalka.okg> <1209600192.30793.9.camel@valkyrie.localdomain> <1209653842.3204.32.camel@rousalka.okg> <1209664796.19564.35.camel@valkyrie.localdomain> Message-ID: <1209674132.3789.2.camel@rousalka.okg> Le jeudi 01 mai 2008 ? 17:59 +0000, Matthew Saltzman a ?crit : > But if the option is no longer there, then one might conclude that RH > has caught on to your point. Maybe yes, maybe not, all I asked was to be more careful in the future, and you've seen the storm that started. > > > My spell-checker is complaining about some of your 's''s 8^). > > > > That's probably because your spell-checker does not know my messages use > > the British English dialect. > > That's settable with a checkbox. It complained about the French, too. > But it did display the accent on the e in "?crit". > > Your smiley detector appears to be off... Sorry about this, you did make me smile, I just forgot to add my own smiley there :p -- 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 fedora at dm.cobite.com Thu May 1 20:50:48 2008 From: fedora at dm.cobite.com (David Mansfield) Date: Thu, 01 May 2008 16:50:48 -0400 Subject: Multilib Middle-Ground In-Reply-To: References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> Message-ID: <1209675048.6942.30.camel@gandalf.cobite.com> On Thu, 2008-05-01 at 09:22 +0000, Kevin Kofler wrote: > Andrew Farris gmail.com> writes: > > Gross exaggeration... 'default install image' doesn't have to mean Live CDs. > > Also are you actually suggesting that it would be best for those proprietary > > applications to ship their own libraries because Fedora makes it difficult to > > get their applications to work on x86_64 boxes due to the company being > > forced to figure out what i386 rpms they have to explicitly require on those > > machines... in Fedora... and not in other rpm based distros? You've got to > > be kidding. > > They're not forced to explicitly require anything, just not explicitly turn off > the RPM feature which AUTOMATICALLY adds those Requires, in a way which: > * is only fulfilled by the correct architecture package of the dependency, > because RPM uses libfoo.so.1 for 32-bit and libfoo.so.1()(64bit) for 64-bit > dependencies, > * works fully across (RPM-based) distributions, because it doesn't require a > particular package name, but an soname. And the application won't run anyway if > you don't have a library with that soname (which is the whole reason why > compat-libstdc++ is needed), so if one distro has libfoo.so.1 and another has > libfoo.so.2, omitting the automatic dependencies won't solve the problem, it > will just make the application error at runtime rather than at install-time > (which sucks, why wait until runtime to report a problem which can be detected > during installation?). Not that I'm justifying it or anything, but I've definitely installed 3rd party software that had a fancy installer (veritas and oracle both, I believe) which did it's own checking of required packages, and even allowed you to install any missing dependencies using some gui interface built into the installer. In other words, the dependencies ARE getting checked, but not by RPM, because that would prevent you from installing the installer. Now, if the installer was as separate rpm... David From lesmikesell at gmail.com Thu May 1 20:58:55 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 01 May 2008 15:58:55 -0500 Subject: Multilib Middle-Ground In-Reply-To: <1209672921.3249.28.camel@cutter> References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819978A.80304@city-fan.org> <4819BCFD.5070108@gmail.com> <4819BE31.9030306@city-fan.org> <4819C2A9.3050202@gmail.com> <1209648138.3249.17.camel@cutter> <4819CBA5.3010505@gmail.com> <1209650282.3249.19.camel@cutter> <4819DDD9.3070504@gmail.com> <1209672921.3249.28.camel@cutter> Message-ID: <481A2F0F.3080408@gmail.com> seth vidal wrote: >>> umm, okay. But no one here controls the vmware package. Hell, speaking >>> for just me, I don't even CARE about vmware. >> I read that as "I don't care about fedora users" that want to run >> applications of their choice. > > > Why would you read it that way? That's not at all what I said. I said "I > don't even care about vmware". If you are talking about changes that break the ability to easily install additional software, the effect is on fedora users > That's it. > > it's b/c I don't. > > I was not speaking as a policy statement for fedora, nor red hat, not > even for yum. OK, I took it in the context of this conversation about removing 32-bit libs from fedora. -- Les Mikesell lesmikesell at gmail.com From denis at poolshark.org Thu May 1 20:54:39 2008 From: denis at poolshark.org (Denis Leroy) Date: Thu, 01 May 2008 22:54:39 +0200 Subject: Multilib Middle-Ground In-Reply-To: <4819CA84.1070004@fedoraproject.org> References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819978A.80304@city-fan.org> <4819BCFD.5070108@gmail.com> <4819BE31.9030306@city-fan.org> <4819C2A9.3050202@gmail.com> <4819CA84.1070004@fedoraproject.org> Message-ID: <481A2E0F.1030106@poolshark.org> Rahul Sundaram wrote: > Les Mikesell wrote: >> Paul Howarth wrote: > >>> Stripping of pathname-based and package-name based dependencies I can >>> understand, but not the library deps. >> >> Are they the same across all RPM based systems? > > Yes, they are and the third party packages have no excuse if they are > deliberately disabling the automatic dependency mechanisms. It's not that simple. VMware does this for a simple reason: they want a single RPM that works on *all* distros. Essentially it's like static linking (except they don't, they just ship their own dependencies). VMware would otherwise have fairly complex dependencies (gtkmm comes to mind) that would force them to provide probably a different RPM for each pair... There's simply no easy way to distribute closed-source softare for Linux, as we all know. From bruno at wolff.to Thu May 1 21:06:35 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Thu, 1 May 2008 16:06:35 -0500 Subject: is xorg.conf still needed In-Reply-To: <1209563623.15542.309.camel@localhost.localdomain> References: <1209523940.2906.136.camel@localhost.localdomain> <1209524701.22831.136.camel@aglarond.local> <870180fe0804292031o12327456v8a6af99e71de253@mail.gmail.com> <1209563623.15542.309.camel@localhost.localdomain> Message-ID: <20080501210635.GA20544@wolff.to> On Wed, Apr 30, 2008 at 09:53:43 -0400, Adam Jackson wrote: > > There's a detail here for outputs, which is that we don't always do > sensible things if we try to start X with no monitor attached, and for > some KVMs it's tough to tell the difference between not attached and > merely not active. That's just a bug though. Or even when the code knows a monitor is attached, but it doesn't do EDID. From lesmikesell at gmail.com Thu May 1 21:39:01 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 01 May 2008 16:39:01 -0500 Subject: Multilib Middle-Ground In-Reply-To: <481A2E0F.1030106@poolshark.org> References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819978A.80304@city-fan.org> <4819BCFD.5070108@gmail.com> <4819BE31.9030306@city-fan.org> <4819C2A9.3050202@gmail.com> <4819CA84.1070004@fedoraproject.org> <481A2E0F.1030106@poolshark.org> Message-ID: <481A3875.7040409@gmail.com> Denis Leroy wrote: >> >>>> Stripping of pathname-based and package-name based dependencies I >>>> can understand, but not the library deps. >>> >>> Are they the same across all RPM based systems? >> >> Yes, they are and the third party packages have no excuse if they are >> deliberately disabling the automatic dependency mechanisms. > > It's not that simple. VMware does this for a simple reason: they want a > single RPM that works on *all* distros. Essentially it's like static > linking (except they don't, they just ship their own dependencies). > VMware would otherwise have fairly complex dependencies (gtkmm comes to > mind) that would force them to provide probably a different RPM for each > pair... There's simply no easy way to distribute > closed-source softare for Linux, as we all know. I'd say that applies equally to open source software too, unless you think of building special packages for every distribution and version and arranging storage/mirrors/bandwidth for all of those variations as being easy. -- Les Mikesell lesmikesell at gmail.com From maximilianbianco at gmail.com Thu May 1 22:14:31 2008 From: maximilianbianco at gmail.com (max bianco) Date: Thu, 1 May 2008 18:14:31 -0400 Subject: Multilib Middle-Ground In-Reply-To: <604aa7910805011244q78338786y956500dd55649441@mail.gmail.com> References: <4817FF36.10305@redhat.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819C1EF.6050009@gmail.com> <604aa7910805010914n987c810g4591ff3065f8844b@mail.gmail.com> <4819FB60.5000606@gmail.com> <604aa7910805011020k4732d6cbv11ed7a813d9fa068@mail.gmail.com> <481A19BA.6090705@gmail.com> <604aa7910805011244q78338786y956500dd55649441@mail.gmail.com> Message-ID: > More than that in fact, if you squander this chance to education me, > once I'm off the board I'll be an active detractor of every single > proposal you put forward regardless of merit. > What an intelligent stance to take, this is an open project isn't it? Max From lesmikesell at gmail.com Thu May 1 22:47:13 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 01 May 2008 17:47:13 -0500 Subject: Multilib Middle-Ground In-Reply-To: <604aa7910805011244q78338786y956500dd55649441@mail.gmail.com> References: <4817FF36.10305@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819C1EF.6050009@gmail.com> <604aa7910805010914n987c810g4591ff3065f8844b@mail.gmail.com> <4819FB60.5000606@gmail.com> <604aa7910805011020k4732d6cbv11ed7a813d9fa068@mail.gmail.com> <481A19BA.6090705@gmail.com> <604aa7910805011244q78338786y956500dd55649441@mail.gmail.com> Message-ID: <481A4871.50102@gmail.com> Jeff Spaleta wrote: > > I'm trying to give you the benefit of the doubt with regard to > knowledge of a standardization initiative that I am not currently > aware of. You've made some pretty firm accusations that we as a > project are ignoring some sort of a longstanding cross-distro > standardization effort with regard to rpm packaging. Pretty much all I know about it is here: http://en.wikipedia.org/wiki/Linux_Standard_Base and it's mostly criticism. > If such an effort > exists that I'm am not aware of, this is your opportunity to educate > me. I'd think that a distribution on the bleeding edge as fedora should be the one leading this effort, not looking for something to join. -- Les Mikesell lesmikesell at gmail.com From jspaleta at gmail.com Thu May 1 22:49:32 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 1 May 2008 14:49:32 -0800 Subject: Multilib Middle-Ground In-Reply-To: References: <4817FF36.10305@redhat.com> <48198EA0.5070904@gmail.com> <4819C1EF.6050009@gmail.com> <604aa7910805010914n987c810g4591ff3065f8844b@mail.gmail.com> <4819FB60.5000606@gmail.com> <604aa7910805011020k4732d6cbv11ed7a813d9fa068@mail.gmail.com> <481A19BA.6090705@gmail.com> <604aa7910805011244q78338786y956500dd55649441@mail.gmail.com> Message-ID: <604aa7910805011549i47c6193bs177e57cea293dd75@mail.gmail.com> On Thu, May 1, 2008 at 2:14 PM, max bianco wrote: > What an intelligent stance to take, this is an open project isn't it? it was a bit tongue and cheek and very much a hollow threat meant to give Les pause to consider what it means to be a constructive participant in a dialog by providing an illustration as to where being destructive can lead. If I actually did that, would I still have the respect of others in the community when I myself put a proposal forward... extremely doubtful. I haven't work as hard as I have to move things forward just to burn through my good will to harass one poisonous person who is a drag on the process. But just thinking about doing it is a rush I haven't felt since that one year when I found my Christmas presents early and then unwrapped and rewrapped them to see what I got. But I don't really have the luxury to be selfish any longer, wallowing around in my own desires to 'win' pointless arguments with people. What Fedora as a community needs to achieve is too important for me to indulge in petty bickering. But I tell you honestly... Les's inability to answer my question straight forwardly brings out my desire to retort with passionate displeasure, as I'm somewhat sure it does to other people. But technically speaking, there's nothing stopping me from being as irrational as other people on this thread have been, nor is there anything stopping other people from ignoring me once I decide to go around making a delibrate effort to be unconstructive. Openness does not automatically make participants in the process intelligent, rational, constructive nor honest. These are all personal characteristics which we as individuals must choose to bring to a discussion. Nor does openness mandate that everyone be forced to listen to everyone else with equal weight. We each individually have to continually earn the respect of others in an open process or else we lose our seat at the table. Les is on the verge of losing his unless he makes and effort to rein in the vitriol and hyperbole and find something constructive to say. -jef"i need more coffee"spaleta From maximilianbianco at gmail.com Thu May 1 23:04:52 2008 From: maximilianbianco at gmail.com (max bianco) Date: Thu, 1 May 2008 19:04:52 -0400 Subject: Multilib Middle-Ground In-Reply-To: <604aa7910805011549i47c6193bs177e57cea293dd75@mail.gmail.com> References: <4817FF36.10305@redhat.com> <4819C1EF.6050009@gmail.com> <604aa7910805010914n987c810g4591ff3065f8844b@mail.gmail.com> <4819FB60.5000606@gmail.com> <604aa7910805011020k4732d6cbv11ed7a813d9fa068@mail.gmail.com> <481A19BA.6090705@gmail.com> <604aa7910805011244q78338786y956500dd55649441@mail.gmail.com> <604aa7910805011549i47c6193bs177e57cea293dd75@mail.gmail.com> Message-ID: On Thu, May 1, 2008 at 6:49 PM, Jeff Spaleta wrote: > On Thu, May 1, 2008 at 2:14 PM, max bianco wrote: > > What an intelligent stance to take, this is an open project isn't it? > > it was a bit tongue and cheek and very much a hollow threat meant to > give Les pause to consider what it means to be a constructive > participant in a dialog by providing an illustration as to where being > destructive can lead. If I actually did that, would I still have the > respect of others in the community when I myself put a proposal > forward... extremely doubtful. I haven't work as hard as I have to > move things forward just to burn through my good will to harass one > poisonous person who is a drag on the process. But just thinking > about doing it is a rush I haven't felt since that one year when I > found my Christmas presents early and then unwrapped and rewrapped > them to see what I got. But I don't really have the luxury to be > selfish any longer, wallowing around in my own desires to 'win' > pointless arguments with people. > What Fedora as a community needs to achieve is too important for me to > indulge in petty bickering. But I tell you honestly... Les's inability > to answer my question straight forwardly brings out my desire to > retort with passionate displeasure, as I'm somewhat sure it does to > other people. > > But technically speaking, there's nothing stopping me from being as > irrational as other people on this thread have been, nor is there > anything stopping other people from ignoring me once I decide to go > around making a delibrate effort to be unconstructive. Openness does > not automatically make participants in the process intelligent, > rational, constructive nor honest. These are all personal > characteristics which we as individuals must choose to bring to a > discussion. Nor does openness mandate that everyone be forced to > listen to everyone else with equal weight. We each individually have > to continually earn the respect of others in an open process or else > we lose our seat at the table. Les is on the verge of losing his > unless he makes and effort to rein in the vitriol and hyperbole and > find something constructive to say. > Just checking. : ) Max From valent.turkovic at gmail.com Thu May 1 23:05:24 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Fri, 2 May 2008 01:05:24 +0200 Subject: My eeexperience with Fedora 9 In-Reply-To: <64b14b300805010656r7516d23en855b250f3616d76d@mail.gmail.com> References: <64b14b300805010656r7516d23en855b250f3616d76d@mail.gmail.com> Message-ID: <64b14b300805011605g1941a630l71b238795f4f0d7c@mail.gmail.com> On Thu, May 1, 2008 at 3:56 PM, Valent Turkovic wrote: > Here is the post regarding my experience installing Fedora 9 on Asus eee: > http://kernelreloaded.blog385.com/index.php/archives/my-eeexperience-with-fedora-9/ > > Cheers, > Valent. > > -- > http://kernelreloaded.blog385.com/ > linux, blog, anime, spirituality, windsurf, wireless > registered as user #367004 with the Linux Counter, http://counter.li.org. > ICQ: 2125241, Skype: valent.turkovic Are you aware of this issues or should I post bug reports if you were unaware of these issues in Asus eee. Cheers, Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From jspaleta at gmail.com Thu May 1 23:06:44 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 1 May 2008 15:06:44 -0800 Subject: Multilib Middle-Ground In-Reply-To: <481A4871.50102@gmail.com> References: <4817FF36.10305@redhat.com> <48198EA0.5070904@gmail.com> <4819C1EF.6050009@gmail.com> <604aa7910805010914n987c810g4591ff3065f8844b@mail.gmail.com> <4819FB60.5000606@gmail.com> <604aa7910805011020k4732d6cbv11ed7a813d9fa068@mail.gmail.com> <481A19BA.6090705@gmail.com> <604aa7910805011244q78338786y956500dd55649441@mail.gmail.com> <481A4871.50102@gmail.com> Message-ID: <604aa7910805011606o702188acra39255ac25053383@mail.gmail.com> On Thu, May 1, 2008 at 2:47 PM, Les Mikesell wrote: > I'd think that a distribution on the bleeding edge as fedora should be the > one leading this effort, not looking for something to join. Here's the thing.... for cross-distribution standardization to work... multiple distributions have to be willing to do it. We just plant a flag and go our community built packaging guidance is a de-facto standard and everyone else should follow us.. but its not really gonna work. There has to be a real desire from the stakeholders who need to adopt the standard to work on it and agree to using it. You aren't adding anything to the discussion by repeatedly telling us that the situation is suboptimal. I don't really think you have any real concept as to what's going on in the space, and as such I think you need to back off from accusations that the Fedora packaging community isn't interested in collaborating with other distros on standardization. Make an effort to inform yourself more fully as to what each distro is prepared to collaborate on so next time you want to throw accusations around, you have some specific things we should be doing in terms of collaboration with willing partners. -jef From jwilliam at xmission.com Thu May 1 23:06:52 2008 From: jwilliam at xmission.com (JerryWilliams) Date: Thu, 1 May 2008 17:06:52 -0600 Subject: useradd to create home directory? Message-ID: <000901c8abe0$0af56ee0$020aa8c0@a26> I am looking for a way to create the home directory and populate it with the shell profiles. Normally I would use useradd, but it breaks when you use NIS or LDAP or winbind. It would be nice if useradd had an option that would say yes I know this account exits in LDAP, just make the home directory and fill it with the normal stuff and don't put anything in /etc/passwd or /etc/shadow. I guess I am asking for an enhancement to useradd. Is there a better way to do this? Thanks in advance! Jerry Williams -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundaram at fedoraproject.org Thu May 1 23:12:18 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 02 May 2008 04:42:18 +0530 Subject: My eeexperience with Fedora 9 In-Reply-To: <64b14b300805011605g1941a630l71b238795f4f0d7c@mail.gmail.com> References: <64b14b300805010656r7516d23en855b250f3616d76d@mail.gmail.com> <64b14b300805011605g1941a630l71b238795f4f0d7c@mail.gmail.com> Message-ID: <481A4E52.2060809@fedoraproject.org> Valent Turkovic wrote: > > Are you aware of this issues or should I post bug reports if you were > unaware of these issues in Asus eee. You should file bug reports. No requirement to post them anywhere else. Rahul From sundaram at fedoraproject.org Thu May 1 23:12:55 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 02 May 2008 04:42:55 +0530 Subject: Multilib Middle-Ground In-Reply-To: <481A4871.50102@gmail.com> References: <4817FF36.10305@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819C1EF.6050009@gmail.com> <604aa7910805010914n987c810g4591ff3065f8844b@mail.gmail.com> <4819FB60.5000606@gmail.com> <604aa7910805011020k4732d6cbv11ed7a813d9fa068@mail.gmail.com> <481A19BA.6090705@gmail.com> <604aa7910805011244q78338786y956500dd55649441@mail.gmail.com> <481A4871.50102@gmail.com> Message-ID: <481A4E77.4020200@fedoraproject.org> Les Mikesell wrote: > > I'd think that a distribution on the bleeding edge as fedora should be > the one leading this effort, not looking for something to join. LSB is a "trailing edge" standard and they aren't out there to really define anything but document existing practices of commercial distributions with a focus on the ISV market. This in practice means, look at things like RHEL and SLES, figure out what is common and bless it as a standard. Fedora doesn't really fit in there and trying to define anything like this unilaterally will fail. Loose coordination has worked well for freedesktop.org and there has been some discussions on the "distributions" mailing list recently setup there. Also see vcs-package-discuss at Debian. Rahul From sundaram at fedoraproject.org Thu May 1 23:13:07 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 02 May 2008 04:43:07 +0530 Subject: Multilib Middle-Ground In-Reply-To: <481A2E0F.1030106@poolshark.org> References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819978A.80304@city-fan.org> <4819BCFD.5070108@gmail.com> <4819BE31.9030306@city-fan.org> <4819C2A9.3050202@gmail.com> <4819CA84.1070004@fedoraproject.org> <481A2E0F.1030106@poolshark.org> Message-ID: <481A4E83.9070903@fedoraproject.org> Denis Leroy wrote: > Rahul Sundaram wrote: >> Les Mikesell wrote: >>> Paul Howarth wrote: >> >>>> Stripping of pathname-based and package-name based dependencies I >>>> can understand, but not the library deps. >>> >>> Are they the same across all RPM based systems? >> >> Yes, they are and the third party packages have no excuse if they are >> deliberately disabling the automatic dependency mechanisms. > > It's not that simple. VMware does this for a simple reason: they want a > single RPM that works on *all* distros. Essentially it's like static > linking (except they don't, they just ship their own dependencies). They might just do that. A package that ignores all dependencies isn't very useful regardless of the motivation behind it. Rahul From maximilianbianco at gmail.com Thu May 1 23:16:17 2008 From: maximilianbianco at gmail.com (max bianco) Date: Thu, 1 May 2008 19:16:17 -0400 Subject: F9 installation screenshot In-Reply-To: <4819E5E2.1070804@ncsu.edu> References: <1209506979.22831.121.camel@aglarond.local> <20080430025732.GV26399@inocybe.teonanacatl.org> <28979.192.54.193.59.1209541945.squirrel@rousalka.dyndns.org> <1209585473.4950.79.camel@localhost> <1209588047.29552.37.camel@rousalka.okg> <1209600192.30793.9.camel@valkyrie.localdomain> <1209653842.3204.32.camel@rousalka.okg> <4819E5E2.1070804@ncsu.edu> Message-ID: > > > > > > > > Wow. I didn't realize that participating in Fedora was such an > anti-patriotic activity on my part. I thought the purpose of open source was > to produce a quality product, not deprive the fat, stupid, greedy American > pig-dogs of their proprietary software blood money. > > --CJD > > I am not fat or stupid, well ok i am stupid sometimes but I refuse to be called fat, its not even in the potbelly realm. Max From a.badger at gmail.com Thu May 1 23:20:34 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 01 May 2008 16:20:34 -0700 Subject: Multilib Middle-Ground In-Reply-To: <481A2E0F.1030106@poolshark.org> References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819978A.80304@city-fan.org> <4819BCFD.5070108@gmail.com> <4819BE31.9030306@city-fan.org> <4819C2A9.3050202@gmail.com> <4819CA84.1070004@fedoraproject.org> <481A2E0F.1030106@poolshark.org> Message-ID: <481A5042.8060703@gmail.com> Denis Leroy wrote: > Rahul Sundaram wrote: >> Les Mikesell wrote: >>> Paul Howarth wrote: >> >>>> Stripping of pathname-based and package-name based dependencies I >>>> can understand, but not the library deps. >>> >>> Are they the same across all RPM based systems? >> >> Yes, they are and the third party packages have no excuse if they are >> deliberately disabling the automatic dependency mechanisms. > > It's not that simple. VMware does this for a simple reason: they want a > single RPM that works on *all* distros. Essentially it's like static > linking (except they don't, they just ship their own dependencies). > VMware would otherwise have fairly complex dependencies (gtkmm comes to > mind) that would force them to provide probably a different RPM for each > pair... There's simply no easy way to distribute > closed-source softare for Linux, as we all know. > Isn't this the basic algorithm that's needed to solve the library dependency problem? #!/usr/bin/python import os import sys app = 'PROPRIETARY_APP' missingLibs = [] if os.exists('/usr/lib64/%s' % app): libdir = '/usr/lib64/%s' % app elif os.exists('/usr/lib/%s' % app): libdir = '/usr/lib/%s' % app else: print 'Warning: Cannot find private app dir.' # Attempt to start the app. The OS might provide all the necessary # libraries. sys.exit(os.system(app)) libToPrivateDir = {'libfoo.so.1': '%s/libfoo1' % libdir, 'libbar.so.2': '%s/libbar2' % libdir} for line in os.popen(['ldd', os.path.join('/usr/bin',app)]): tokens = line.split() if '=>' not in tokens: continue if ['not', 'found'] == tokens[-2:]: missingLibs.append(tokens[0]) path = [libToPrivateDir[lib] for lib in missingLibs] current_path = os.environ('LD_LIBRARY_PATH') if current_path: path.insert(0, current_path) if path: os.environ['LD_LIBRARY_PATH'] = ':'.join(path) sys.exit(os.system(app)) From tmus at tmus.dk Thu May 1 23:40:58 2008 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Thu, 01 May 2008 21:40:58 -0200 Subject: useradd to create home directory? In-Reply-To: <000901c8abe0$0af56ee0$020aa8c0@a26> References: <000901c8abe0$0af56ee0$020aa8c0@a26> Message-ID: JerryWilliams wrote: > I am looking for a way to create the home directory and populate it with > the shell profiles. > > Normally I would use useradd, but it breaks when you use NIS or LDAP or > winbind. > > It would be nice if useradd had an option that would say yes I know this > account exits in LDAP, just make the home directory and fill it with the > normal stuff and don?t put anything in /etc/passwd or /etc/shadow. > For this to actually work, useradd would have to grow features to query those services. In order to successfully create a usable homedir, you'll have to know the UID and GID to set as owner for the directory and it's contents. Of course you could specify this too via switches, but then doing something like this might actually be easier: for i in user1 user2 user3 user4; do cp -a /etc/skel /home/$i chown -R $(getent passwd $i |cut -d: -f3,4) /home/$i done getent passwd should be able to enumerate all your users in the first place, so this should work. Disclaimer: The script is an example and might need additional checks and such to be run safely in a large environment. From kevin.kofler at chello.at Thu May 1 23:41:47 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 1 May 2008 23:41:47 +0000 (UTC) Subject: Multilib Middle-Ground References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819978A.80304@city-fan.org> <4819BCFD.5070108@gmail.com> <4819BE31.9030306@city-fan.org> <4819C2A9.3050202@gmail.com> <4819CA84.1070004@fedoraproject.org> <481A2E0F.1030106@poolshark.org> <481A3875.7040409@gmail.com> Message-ID: Les Mikesell gmail.com> writes: > I'd say that applies equally to open source software too, unless you > think of building special packages for every distribution and version > and arranging storage/mirrors/bandwidth for all of those variations as > being easy. No. Free Software developers only have to release the source tarball, and let us Fedora packagers take care of maintaining the Fedora package (and likewise, Debian packagers take care of maintaining the Debian package, Gentoo packagers take care of maintaining the Gentoo ebuild etc.). Proprietary apps specificially forbid us from doing this in their license, that's why they have a problem. Kevin Kofler From loupgaroublond at gmail.com Thu May 1 23:43:02 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Thu, 1 May 2008 19:43:02 -0400 Subject: What do these "Requires:" messages in rpmbuild mean? Message-ID: <7f692fec0805011643l5d9d79e6mbbdf307d06d19b03@mail.gmail.com> Hi list, As the subject so eloquently state, what do these messages mean? I haven't used rpmbuild in several months, so it's likely some nuance has changed. Is it some dependency I forgot to declare? Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(VersionedDependencies) <= 3.0.3-1 Requires: libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) libc.so.6(GLIBC_2.2) libc.so.6(GLIBC_2.3) libdl.so.2 libgmp.so.3 libm.so.6 libm.so.6(GLIBC_2.0) librt.so.1 librt.so.1(GLIBC_2.2) libutil.so.1 rtld(GNU_HASH) -Yaakov From stlwrt at gmail.com Fri May 2 00:26:17 2008 From: stlwrt at gmail.com (Pavel Shevchuk) Date: Fri, 2 May 2008 03:26:17 +0300 Subject: What do these "Requires:" messages in rpmbuild mean? In-Reply-To: <7f692fec0805011643l5d9d79e6mbbdf307d06d19b03@mail.gmail.com> References: <7f692fec0805011643l5d9d79e6mbbdf307d06d19b03@mail.gmail.com> Message-ID: These are automagic dependencies extracted from binary files On 5/2/08, Yaakov Nemoy wrote: > Hi list, > > As the subject so eloquently state, what do these messages mean? I > haven't used rpmbuild in several months, so it's likely some nuance > has changed. Is it some dependency I forgot to declare? > > > Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 > rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(VersionedDependencies) > <= 3.0.3-1 > Requires: libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) > libc.so.6(GLIBC_2.2) libc.so.6(GLIBC_2.3) libdl.so.2 libgmp.so.3 > libm.so.6 libm.so.6(GLIBC_2.0) librt.so.1 librt.so.1(GLIBC_2.2) > libutil.so.1 rtld(GNU_HASH) > > > -Yaakov > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- http://scwlab.com From poelstra at redhat.com Fri May 2 00:36:38 2008 From: poelstra at redhat.com (John Poelstra) Date: Thu, 01 May 2008 17:36:38 -0700 Subject: Fedora Rel-Eng Meeting Recap 2008-APR-28 Message-ID: <481A6216.8010106@redhat.com> Recap and full IRC transcript found here: http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-apr-28 == Fedora 9 == * over 300 packages in dist-f9 that are not f9-final * 50-55 bugs on the blocker list that aren't in MODIFIED * serious blocker: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=443445 * Cannot install packages from repositories from which RPM-GPG-KEYs have not been installed * See log for more details == Release Candidate == * start spinning RCs on Thursday or Friday of this week == IRC Transcript == From james at fedoraproject.com Fri May 2 00:39:00 2008 From: james at fedoraproject.com (James Antill) Date: Thu, 01 May 2008 20:39:00 -0400 Subject: Multilib Middle-Ground In-Reply-To: <481A2E0F.1030106@poolshark.org> References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819978A.80304@city-fan.org> <4819BCFD.5070108@gmail.com> <4819BE31.9030306@city-fan.org> <4819C2A9.3050202@gmail.com> <4819CA84.1070004@fedoraproject.org> <481A2E0F.1030106@poolshark.org> Message-ID: <1209688740.10286.154.camel@code.and.org> On Thu, 2008-05-01 at 22:54 +0200, Denis Leroy wrote: > Rahul Sundaram wrote: > > Les Mikesell wrote: > >> Paul Howarth wrote: > > > >>> Stripping of pathname-based and package-name based dependencies I can > >>> understand, but not the library deps. > >> > >> Are they the same across all RPM based systems? > > > > Yes, they are and the third party packages have no excuse if they are > > deliberately disabling the automatic dependency mechanisms. > > It's not that simple. VMware does this for a simple reason: they want a > single RPM that works on *all* distros. Essentially it's like static > linking (except they don't, they just ship their own dependencies). If they shipped all of their own dependencies then their rpm would just work if you installed it ... given that they have been brought up, in this thread, as a "problem that we should try and work around" I'd say their current "strategy" is not working. If they want to continue down this path of providing no deps. in their rpm, that's fine but then _they_ need to make it work, and _we_ (Fedora) have no way to fix it for them. Adding gratuitous hacks isn't going to help anyone. > VMware would otherwise have fairly complex dependencies (gtkmm comes to > mind) that would force them to provide probably a different RPM for each > pair... Being about the 3rd or 4th person to try and tell people this in this thread, but the _automatic_ dependencies don't work that way they _are the same across distributions_. Yes, to do it "as well as Fedora" atm. they might want/need package versions too ... which might mean they'd need to build per. distro. but they'd certainly fix the multilib problem, and probably the vast majority of other cases, if they just _didn't manually delete_ the automatic deps. > There's simply no easy way to distribute > closed-source softare for Linux, as we all know. That's funny, because adobe seem to be doing a pretty good job of it ... at least it's a better solution than anything else I've seen for any other OS. But even if it was "hard", it'd still be _much easier_ for the vendors to fix their packaging than for us (Fedora) to guess at what all of their users want/need and to add hacks to try and please everyone. -- James Antill Fedora From cmadams at hiwaay.net Fri May 2 00:41:39 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 1 May 2008 19:41:39 -0500 Subject: Multilib Middle-Ground In-Reply-To: <481A4871.50102@gmail.com> References: <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819C1EF.6050009@gmail.com> <604aa7910805010914n987c810g4591ff3065f8844b@mail.gmail.com> <4819FB60.5000606@gmail.com> <604aa7910805011020k4732d6cbv11ed7a813d9fa068@mail.gmail.com> <481A19BA.6090705@gmail.com> <604aa7910805011244q78338786y956500dd55649441@mail.gmail.com> <481A4871.50102@gmail.com> Message-ID: <20080502004139.GA1272043@hiwaay.net> Once upon a time, Les Mikesell said: > I'd think that a distribution on the bleeding edge as fedora should be > the one leading this effort, not looking for something to join. One problem with standardization is that it tends to freeze development in some ways. A big compatibility issue is shared library sonames. For standards to emerge, you'd have to define a complete set of compatible sonames. That would mean all compatible distributions would have to be using (essentially) the same version glibc, gcc, X, GNOME, KDE, perl, python, etc. at the same time. It would require all the major open source projects to be synchronized to the same release schedule (or at least all distributions to pick up new versions of everything at the same time of year). That just isn't going to happen. For some of these things, Linux distributions are a large part of their user base (glibc, GNOME, KDE), and you might could work with them, but for things like gcc, perl, and python, Linux is only one of many targets. Usually, if you restrict yourself to building against older versions of the libraries (e.g. pick the oldest enterprise distribution you are interested in supporting), your program should run with no problems on the latest bleeding-edge distributions. For example, Adobe Acrobat Reader is linked against a long list of system-provided libraries, including GNOME. However, they do package it with some compat libraries like OpenSSL; that's a library though that has traditionally been one of the worst at ABI compatibility in the shared libraries (and there's not much Fedora can do about that). They also include libgcc and libstdc++, also libraries that have had a moving target ABI over time. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From rcritten at redhat.com Fri May 2 01:35:31 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 01 May 2008 21:35:31 -0400 Subject: useradd to create home directory? In-Reply-To: <000901c8abe0$0af56ee0$020aa8c0@a26> References: <000901c8abe0$0af56ee0$020aa8c0@a26> Message-ID: <481A6FE3.9070807@redhat.com> JerryWilliams wrote: > I am looking for a way to create the home directory and populate it with > the shell profiles. > > Normally I would use useradd, but it breaks when you use NIS or LDAP or > winbind. > > It would be nice if useradd had an option that would say yes I know this > account exits in LDAP, just make the home directory and fill it with the > normal stuff and don?t put anything in /etc/passwd or /etc/shadow. > > > > I guess I am asking for an enhancement to useradd. > > Is there a better way to do this? You might want to investigate pam_mkhomedir. Or setup an NFS filer and look into automount. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From loupgaroublond at gmail.com Fri May 2 02:52:13 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Thu, 1 May 2008 22:52:13 -0400 Subject: What do these "Requires:" messages in rpmbuild mean? In-Reply-To: References: <7f692fec0805011643l5d9d79e6mbbdf307d06d19b03@mail.gmail.com> Message-ID: <7f692fec0805011952s6a23a137mf0a9100e14f88ab@mail.gmail.com> Ah, I was getting a random error after those lines, that I thought there might have been some relation. Turns out my rpmbuild dir was missing the SRPMS dir. -Yaakov On Thu, May 1, 2008 at 8:26 PM, Pavel Shevchuk wrote: > These are automagic dependencies extracted from binary files > > > > > On 5/2/08, Yaakov Nemoy wrote: > > Hi list, > > > > As the subject so eloquently state, what do these messages mean? I > > haven't used rpmbuild in several months, so it's likely some nuance > > has changed. Is it some dependency I forgot to declare? > > > > > > Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 > > rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(VersionedDependencies) > > <= 3.0.3-1 > > Requires: libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) > > libc.so.6(GLIBC_2.2) libc.so.6(GLIBC_2.3) libdl.so.2 libgmp.so.3 > > libm.so.6 libm.so.6(GLIBC_2.0) librt.so.1 librt.so.1(GLIBC_2.2) > > libutil.so.1 rtld(GNU_HASH) > > > > > > -Yaakov > > > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > -- > http://scwlab.com > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From tcallawa at redhat.com Fri May 2 03:18:39 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 01 May 2008 23:18:39 -0400 Subject: /etc/alternatives not quite working In-Reply-To: <1209640378.3358.6.camel@T7.Linux> References: <1209640378.3358.6.camel@T7.Linux> Message-ID: <1209698319.20913.146.camel@localhost.localdomain> On Thu, 2008-05-01 at 12:12 +0100, Paul wrote: > Hi, > > For some odd reason emacs has stopped working on my system. Looking at > it, there wasn't anything in /etc/alternatives for it. Adding a symlink > from /etc/alternatives to /usr/bin/emacs-22.2 is doing nothing. > > Has something broken or is there something I need to do to register an > application in alternatives? I'm trying to reproduce this one to troubleshoot it, but I simply can't, not even following the steps listed in bz 394131. ~spot From kevin at scrye.com Fri May 2 03:25:02 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Thu, 1 May 2008 21:25:02 -0600 Subject: source file audit - 2008-05-01 Message-ID: <20080501212502.51934fa7@ohm.scrye.com> Here's attached another run of my sources/patches url checker. - There are 660 lines in this run. Down from 666 last run. 700 sourcecheck-20070826.txt 620 sourcecheck-20070917.txt 561 sourcecheck-20071017.txt 775 sourcecheck-20080206.txt 685 sourcecheck-20080214.txt 674 sourcecheck-20080301.txt 666 sourcecheck-20080401.txt - I am going to try and run this once a month. - I am going to try and spam maintainers later this week with their packages that have issues from this list. You can find the results file at: http://www.scrye.com/~kevin/fedora/sourcecheck/sourcecheck-20080501.txt And also attached to this mail. Lines in the output are of three forms: - BADURL:base-file-name:$PACKAGENAME This means that the URI provided in the Source(s) line didn't result in a download of the source. This could be any of: URL changed, version changed and URL wasn't updated, Site is down, Site is gone, etc. Also there are a number of packages with incorrect sourceforge links. (BTW, there are still some packages with ftp://people.redhat.com/ URLs). - BADSOURCE:$SOURCENAME:$PACKAGENAME This means that the source was downloaded ok from the upstream site, but doesn't match the md5sum given in the sources file. This could be due to needing to strip out content that fedora cannot ship (but in that case you shouldn't have the full URI in the Source line). Or upstream following poor release practices and updating without changing their release. - BAD_CVS_SOURCE:$SOURCENAME:$PACKAGENAME This means that the file was downloaded from the URI given, and the md5sum did not match the file thats present in CVS (not the lookaside). This might be due to timestamps, or any of the above reasons. kevin -- abompard:BADURL:glest_data_3.1.2.zip:glest-data aconway:BADSOURCE:qpidc-0.2.tar.gz:qpidc aconway:BADSOURCE:rhm-0.2.tar.gz:rhm adalloz:BADURL:pan-0.132.tar.bz2:pan adrian:BADURL:xlockmore-5.25.tar.bz2:xlockmore afsilva:BADURL:rpmrebuild-2.2.1.tar.gz:rpmrebuild ajax:BADURL:pyxf86config-0.3.37.tar.bz2:pyxf86config akahl:BADURL:bmpx-0.40.13.tar.bz2:bmpx alexlan:BADSOURCE:coverart.py:picard alexlan:BADSOURCE:__init__.py:picard alexl:BADURL:gmime-2.2.18.tar.bz2:gmime andriy:BAD_CVS_SOURCE:fmio-gq-wrapper.py:fmio anyremote:BADSOURCE:ganyremote-2.8.tar.gz:ganyremote arozansk:BADURL:linuxwacom-0.7.9-8.tar.bz2:linuxwacom ascii:BADURL:fish-1.23.0.tar.bz2:fish athimm:BADSOURCE:po4a-0.32.tar.gz:po4a athimm:BADURL:chrpath-0.13.tar.gz:chrpath athimm:BADURL:fakeroot_1.6.4.tar.gz:fakeroot athimm:BADURL:greylistd_0.8.3.2.tar.gz:greylistd atkac:BADURL:rexec-1.5.tar.gz:rsh atkac:BADURL:vnc-4_1_2-unixsrc.tar.gz:vnc atkac:BADURL:xdelta-1.1.4.tar.gz:xdelta ausil:BADSOURCE:usb8388-5.110.22.p6.bin.md5:libertas-usb8388-firmware ausil:BADURL:mysql-gui-tools-5.0r12.tar.gz:mysql-gui-tools ausil:BADURL:snort-2.7.0.1.tar.gz:snort awjb:BADURL:atitvout_0.4-2.diff.gz:atitvout awjb:BADURL:claws-mail-3.4.0.tar.bz2:claws-mail awjb:BADURL:synce-kpm-0.11.tar.gz:synce-kpm awjb:BADURL:treecc-0.3.8.tar.gz:treecc awjb:BADURL:WindowMaker-0.92.0.tar.bz2:WindowMaker awjb:BADURL:WindowMaker-extra-0.1.tar.gz:WindowMaker behdad:BADURL:cairo-1.6.4.tar.gz:cairo belegdol:BADSOURCE:qsa-x11-free-1.1.5.tar.gz:qt-qsa belegdol:BADURL:gchempaint-0.8.7.tar.bz2:gchempaint belegdol:BADURL:gnome-chemistry-utils-0.8.7.tar.bz2:gnome-chemistry-utils belegdol:BADURL:goffice-0.4.3.tar.bz2:goffice04 ben:BADSOURCE:ketchup-0.9.8.tar.bz2:ketchup bjensen:BADSOURCE:demorse-0.9.tar.gz:demorse bjensen:BADSOURCE:lpsk31-1.1.tar.gz:lpsk31 bjensen:BADSOURCE:xnec2c-1.0b5.tar.gz:xnec2c bjensen:BADURL:fldigi-2.10.3.tar.gz:fldigi bjensen:BADURL:gpsk31-0.3.tar.gz:gpsk31 bjensen:BADURL:xfhell-1.4.tar.gz:xfhell bojan:BADURL:libapreq2-2.09.tar.gz:libapreq2 bojan:BADURL:tcpreplay-3.3.rc1.tar.gz:tcpreplay bos:BADSOURCE:gtk2hs-0.9.12.1.tar.gz:gtk2hs bouska:BADURL:kitsune2.0.tar.gz:kitsune bpeck:BADURL:conmux-493svn.tar.gz:conmux bpepple:BADURL:gaim-galago-0.5.1.tar.bz2:purple-galago bpepple:BADURL:ggz-gtk-client-0.0.14.1.tar.gz:ggz-gtk-client bpepple:BADURL:gnome-blog-0.9.1.tar.bz2:gnome-blog bpepple:BADURL:nautilus-image-converter-0.3.0.tar.bz2:nautilus-image-converter bpepple:BADURL:swfdec-gnome-2.22.0.tar.bz2:swfdec-gnome bpepple:BADURL:swfdec-mozilla-0.6.0.tar.gz:swfdec-mozilla bpostle:BADURL:hugin-0.7.0.tar.gz:hugin bpostle:BADURL:libpano13-2.9.12.tar.bz2:libpano13 buc:BADURL:dvdisaster-0.70.6.tar.bz2:dvdisaster buc:BADURL:enca-1.9.tar.bz2:enca c4chris:BADURL:seaview_2.0.tar.gz:seaview caolanm:BADSOURCE:lp_solve_5.5.0.12_source.tar.gz:lpsolve caolanm:BADSOURCE:thes_de_DE_v2.zip:mythes-de caolanm:BADURL:evolocal.odb:openoffice.org caolanm:BADURL:sjp-myspell-pl-20080407.zip:hunspell-pl cchance:BADURL:nhpf-1.42.tar.gz:nhpf cgrau:BADURL:frotz-2.43.tar.gz:frotz cgrau:BADURL:ifm-5.1.tar.gz:ifm chitlesh:BADSOURCE:crystal_project.tar.gz:crystal-project chitlesh:BADSOURCE:kpolynome-0.1-2.tar.gz:kpolynome chitlesh:BADURL:26521-kio_resources-0.2.tar.bz2:kio_resources chitlesh:BADURL:CrystalClear.tar.gz:crystal-clear chitlesh:BADURL:crystal-kwin4-1.0.5.tar.bz2:crystal chitlesh:BADURL:geda-docs-1.4.0.tar.gz:geda-docs chitlesh:BADURL:geda-examples-1.4.0.tar.gz:geda-examples chitlesh:BADURL:geda-gattrib-1.4.0.tar.gz:geda-gattrib chitlesh:BADURL:geda-gnetlist-1.4.0.tar.gz:geda-gnetlist chitlesh:BADURL:geda-gschem-1.4.0.tar.gz:geda-gschem chitlesh:BADURL:geda-gsymcheck-1.4.0.tar.gz:geda-gsymcheck chitlesh:BADURL:geda-symbols-1.4.0.tar.gz:geda-symbols chitlesh:BADURL:geda-utils-1.4.0.tar.gz:geda-utils chitlesh:BADURL:guile-1.6.7.tar.gz:compat-guile-16 chitlesh:BADURL:keurocalc-1.0.0.tgz:keurocalc chitlesh:BADURL:ktechlab-0.3.69.tar.bz2:ktechlab chitlesh:BADURL:libgeda-1.4.0.tar.gz:libgeda chitlesh:BADURL:liborigin-20071119.tar.gz:liborigin chrisw:BADSOURCE:cogito-0.18.2.tar.gz:cogito clumens:BADURL:gnu-efi-3.0d.tar.gz:gnu-efi clumens:BADURL:rhpxl-1.9.tar.gz:rhpxl coldwell:BAD_CVS_SOURCE:rpm-spec-mode.el:emacs corsepiu:BADURL:Mail-GnuPG-0.15.tar.gz:perl-Mail-GnuPG cr33dog:BADURL:fontypython-0.2.0.tar.gz:fontypython cweyl:BAD_CVS_SOURCE:apsl-2.0.txt:hfsplus-tools cweyl:BADURL:Catalyst-Manual-5.700701.tar.gz:perl-Catalyst-Manual cweyl:BADURL:Catalyst-Plugin-ConfigLoader-0.14.tar.gz:perl-Catalyst-Plugin-ConfigLoader cweyl:BADURL:diskdev_cmds-332.14.tar.gz:hfsplus-tools cweyl:BADURL:gaim-2.0.0beta4.tar.gz:gaim-gaym cweyl:BADURL:Hash-Case-1.003.tar.gz:perl-Hash-Case cweyl:BADURL:JSON-XS-2.01.tar.gz:perl-JSON-XS cweyl:BADURL:MooseX-Object-Pluggable-0.0005.tar.gz:perl-MooseX-Object-Pluggable cweyl:BADURL:Perl-Critic-1.080.tar.gz:perl-Perl-Critic cweyl:BADURL:POE-0.9999.tar.gz:perl-POE cweyl:BADURL:POE-Component-IRC-5.29.tar.gz:perl-POE-Component-IRC cweyl:BADURL:POE-Component-Server-SimpleHTTP-1.23.tar.gz:perl-POE-Component-Server-SimpleHTTP cweyl:BADURL:POE-Component-SSLify-0.08.tar.gz:perl-POE-Component-SSLify cweyl:BADURL:POE-Filter-Zlib-1.8.tar.gz:perl-POE-Filter-Zlib cweyl:BADURL:qrc-0.96-293svn.tar.gz:gaim-gaym cweyl:BADURL:WWW-Myspace-0.60.tar.gz:perl-WWW-Myspace cwickert:BADURL:xfce4-minicmd-plugin-0.4.tar.bz2:xfce4-minicmd-plugin danken:BADURL:bidiv-1.5.tgz:bidiv danken:BADURL:hspell-1.0.tar.gz:hspell davidz:BADURL:festvox_nitech_us_awb_arctic_hts.tar.bz2:festival davidz:BADURL:festvox_nitech_us_bdl_arctic_hts.tar.bz2:festival davidz:BADURL:festvox_nitech_us_clb_arctic_hts.tar.bz2:festival davidz:BADURL:festvox_nitech_us_jmk_arctic_hts.tar.bz2:festival davidz:BADURL:festvox_nitech_us_rms_arctic_hts.tar.bz2:festival davidz:BADURL:festvox_nitech_us_slt_arctic_hts.tar.bz2:festival davidz:BADURL:orca-2.23.1.tar.bz2:orca davidz:BADURL:tsclient-0.150.tar.gz:tsclient dbhole:BADURL:commons-validator-1.1.4-src.tar.gz:jakarta-commons-validator dbhole:BADURL:lucene-2.3.0-src.tar.gz:lucene dcbw:BADURL:Csound5.03.0_src-cvs20061108.tar.bz2:csound dcbw:BADURL:plague-0.4.4.1.tar.bz2:plague dchen:BADSOURCE:scim-array-0.0.4.tar.gz:scim-array dchen:BADSOURCE:WritRecogn-0.1.9.tar.gz:WritRecogn deebs:BADSOURCE:GREYCstoration-2.8.zip:GREYCstoration deji:BADURL:gparted-0.3.6.tar.gz:gparted denis:BADURL:galeon-2.0.5.tar.bz2:galeon denis:BADURL:hamlib-1.2.7.tar.gz:hamlib denis:BADURL:libpanelappletmm-2.22.0.tar.bz2:libpanelappletmm denis:BADURL:libsigc++-1.2.7.tar.bz2:libsigc++ desi:BADSOURCE:cwrite-0.1.24.tar.gz:cwrite devrim:BADSOURCE:pgpoolAdmin-1.0.0.tar.gz:postgresql-pgpoolAdmin dgoodwin:BADURL:wuja-0.0.8.tar.gz:wuja dionysos:BADURL:eurofont.tar.gz:tetex-eurofont dionysos:BADURL:kbackup-0.5.3.tar.bz2:kbackup dionysos:BADURL:kicad-sources--2007-07-09.zip:kicad drago01:BADURL:compiz-bcop-0.7.2.tar.bz2:compiz-bcop drago01:BADURL:compiz-fusion-plugins-extra-0.7.2.tar.bz2:compiz-fusion-extras drago01:BADURL:compiz-fusion-plugins-main-0.7.2.tar.bz2:compiz-fusion drfickle:BADSOURCE:libhugetlbfs-1.2.tar.gz:libhugetlbfs dwalsh:BADSOURCE:libsemanage-2.0.24.tgz:libsemanage dwalsh:BADSOURCE:selinux-doc-1.26.tgz:selinux-doc dwalsh:BADSOURCE:sepolgen-1.0.11.tgz:policycoreutils dwalsh:BADURL:checkpolicy-2.0.14.tgz:checkpolicy dwalsh:BADURL:libselinux-2.0.64.tgz:libselinux dwalsh:BADURL:libsepol-2.0.26.tgz:libsepol dwalsh:BADURL:mcstrans-0.2.8.tgz:mcstrans dwalsh:BADURL:policycoreutils-2.0.46.tgz:policycoreutils dwmw2:BADSOURCE:petitboot-0.0.1.tar.gz:petitboot dwmw2:BADSOURCE:yaboot-1.3.14.tar.gz:yaboot dwmw2:BADURL:apmud-1.0.0.tgz:apmud dwmw2:BADURL:callweaver-RC-1.1.99.20071230.tar.gz:callweaver dwmw2:BADURL:config.samples-20050415.tar.bz2:exim-doc dwmw2:BADURL:FAQ-html-20050415.tar.bz2:exim-doc dwmw2:BADURL:hfsplus_1.0.4.src.tar.bz2:hfsplusutils dwmw2:BADURL:libpng-1.2.16.tar.bz2:petitboot dwmw2:BADURL:nano-2.0.6.tar.gz:nano ecik:BADURL:kadu-tabs-1.1.5.tar.bz2:kadu ecik:BADURL:ZSI-2.0.tar.gz:python-ZSI edhill:BADSOURCE:cdo.pdf:cdo edhill:BADSOURCE:cdo_refcard.pdf:cdo edhill:BADURL:wifiroamd-1.12.tar.gz:wifiroamd ensc:BADSOURCE:ip-sentinel-0.12.tar.bz2.sig:ip-sentinel ensc:BADURL:dhcp-forwarder-0.7.tar.bz2.asc:dhcp-forwarder ensc:BADURL:dhcp-forwarder-0.7.tar.bz2:dhcp-forwarder ensc:BADURL:hunt-1.5.tgz:hunt errr:BADURL:pekwm-0.1.5.tar.bz2:pekwm errr:BADURL:tenr-de-styles-pkg-1.1.tar.bz2:tenr-de-styles-pkg faucamp:BADURL:12956-knemo-0.4.7.tar.bz2:knemo fche:BADURL:systemtap-0.6.2.tar.gz:systemtap firewing:BADSOURCE:fwfstab-0.03.tar.gz:fwfstab fitzsim:BADSOURCE:icedtea-1.6.tar.gz:java-1.7.0-icedtea fitzsim:BADURL:icedtea6-1.2-0bdd2917dfdb672402a7868206fd4ce9b2690a8c.tar.gz:java-1.6.0-openjdk fnasser:BADSOURCE:inetlib-1.1.1.tar.gz:classpathx-mail frankb:BAD_CVS_SOURCE:nasd.init:nas frankb:BADURL:nas-1.9.1.src.tar.gz:nas gemi:BADSOURCE:cook-2.30.tar.gz:cook gemi:BADSOURCE:curry-0.9.11.tar.gz:curry gemi:BADSOURCE:HTMLmanual.tar.gz:pl gemi:BADSOURCE:SmartEiffel-2-3.tar.bz2:smarteiffel gemi:BADURL:ffcall-1.10.tar.gz:ffcall gemi:BADURL:skencil-0.6.tar.gz:skencil gilboa:BAD_CVS_SOURCE:cgdb.png:cgdb gilboa:BAD_CVS_SOURCE:icewm-xdg-menu:icewm green:BADURL:libffi-3.0.1.tar.gz:libffi green:BADURL:liblo-0.24.tar.gz:liblo grenier:BADSOURCE:testdisk-6.9.tar.bz2:testdisk hadess:BADURL:gnome-audio-2.22.1.tar.bz2:gnome-audio hadess:BADURL:gnome-user-share-0.31.tar.gz:gnome-user-share hadess:BADURL:nautilus-sendto-0.14.0.tar.bz2:nautilus-sendto hadess:BADURL:totem-pl-parser-2.22.2.tar.bz2:totem-pl-parser hamzy:BADURL:sblim-cmpi-base-1.5.4.tar.bz2:sblim-cmpi-base homeless:BADSOURCE:rudecgi-5.1.0.tar.bz2:rudecgi huzaifas:BADSOURCE:libnova-0.12.1.tar.gz:libnova huzaifas:BADSOURCE:python-lzo-1.08.tar.gz:python-lzo iburrell:BADURL:Path-Class-0.16.tar.gz:perl-Path-Class icon:BADSOURCE:twitux-0.61.tar.bz2:twitux icon:BADURL:gazpacho-0.7.2.tar.bz2:gazpacho icon:BADURL:libxml++-2.22.0.tar.bz2:libxml++ icon:BADURL:verbiste-0.1.22.tar.gz:verbiste ixs:BADURL:commoncpp2-1.6.1.tar.gz:commoncpp2 ixs:BADURL:MD5-2.03.tar.gz:perl-MD5 ixs:BADURL:metapixel-1.0.2.tar.gz:metapixel ixs:BADURL:scmxx-0.9.0.tar.bz2:scmxx ixs:BADURL:ser-0.9.6_src.tar.gz:ser jafo:BADURL:python-memcached-1.39.tar.gz:python-memcached jakub:BADURL:prelink-20071009.tar.bz2:prelink jamatos:BADURL:HTMLgen.tar.gz:python-HTMLgen jamatos:BADURL:t1lib_5.1.1-3.diff.gz:t1lib james:BADURL:zsh-4.3.4.tar.gz:zsh jcm:BADSOURCE:module-init-tools-3.4.tar.bz2:module-init-tools jcm:BADSOURCE:module-init-tools-3.4.tar.bz2.sign:module-init-tools jcollie:BADURL:python-urljr-1.0.1.tar.gz:python-urljr jcollie:BADURL:python-yadis-1.1.0.tar.gz:python-yadis jeffg:BADSOURCE:pbzip2-1.0.2.tar.gz:pbzip2 jgarzik:BADURL:ethtool-6.tar.gz:ethtool jgarzik:BADURL:reiserfsprogs-3.6.19.tar.gz:reiserfs-utils jgu:BADURL:ebib-1.5.2.tar.gz:emacs-common-ebib jima:BADURL:videodog0.31.tar.gz:videodog jjohnstn:BADURL:eclipse-changelog-src-2.6.1.zip:eclipse-changelog jjohnstn:BADURL:org.python.pydev.feature-src-1_3_14.zip:eclipse-pydev jlaska:BADURL:snake-0.11-0.4.tar.bz2:snake jlayton:BADURL:ez-ipupdate_3.0.11b8-10.diff.gz:ez-ipupdate jlayton:BADURL:ez-ipupdate-3.0.11b8.tar.gz:ez-ipupdate jmoskovc:BAD_CVS_SOURCE:rdist-eu-license.txt:rdist jmoskovc:BADURL:lynx2.8.6.tar.bz2:lynx jmoskovc:BADURL:rarpd-ss981107.tar.gz:rarpd jmoskovc:BADURL:rdate-1.4.tar.gz:rdate jmoskovc:BADURL:xferstats-2.16.tar.gz:xferstats jmrcpn:BADURL:clement-2.1-241.tar.gz:clement jnovy:BADSOURCE:db-4.2.52.tar.gz:compat-db jnovy:BADSOURCE:db-4.3.29.tar.gz:compat-db jnovy:BADSOURCE:multican-0.0.5.tar.gz:multican jnovy:BADURL:dvipsk-jpatch-p1.7a.tar.bz2:texlive jnovy:BADURL:mc-4.6.2-pre1.tar.gz:mc jnovy:BADURL:platex209.tar.bz2:texlive-texmf joost:BADURL:fpc-2.2.0.compiler.bin.tar.gz:fpc jorge:BADSOURCE:mimetex.zip:mimetex jorton:BADURL:imap-2004g.tar.Z:libc-client jpmahowa:BADSOURCE:numlockx-1.0.tar.gz:numlockx jsteffan:BADURL:revisor-2.1.0.tar.gz:revisor jwb:BAD_CVS_SOURCE:squid-getlist.html:squidGuard jwb:BADSOURCE:blacklists.tar.gz:squidGuard jwboyer:BADURL:gquilt-0.20.tar.gz:gquilt jwilson:BAD_CVS_SOURCE:license.txt:cpuspeed jwilson:BADSOURCE:zabbix-1.4.5.tar.gz:zabbix jwilson:BADURL:conman-0.1.9.2.tar.bz2:conman jwilson:BADURL:cpuspeed-1.2.1.tar.gz:cpuspeed jwilson:BADURL:firecontrol-0.2.tar.gz:firecontrol kanarip:BADURL:pyjigdo-0.3.0.tar.gz:pyjigdo karlik:BADURL:warzone2100-2.1_beta2.tar.bz2:warzone2100 kasal:BADURL:Business-ISBN-Data-1.15.tar.gz:perl-Business-ISBN-Data kasal:BADURL:gdbm-1.8.0.tar.gz:gdbm kasal:BADURL:IO-Zlib-1.07.tar.gz:perl-IO-Zlib kasal:BADURL:Text-CSV_XS-0.30.tar.gz:perl-Text-CSV_XS kasal:BADURL:transfig.3.2.5.tar.gz:transfig kasal:BADURL:Xaw3d-1.3.tar.gz:Xaw3d kasal:BADURL:xfig.3.2.5.full.tar.gz:xfig kasal:BADURL:XML-Grove-0.46alpha.tar.bz2:perl-XML-Grove kevin:BADSOURCE:Inconsolata.sfd:inconsolata-fonts kevin:BADSOURCE:twinkle-1.2.tar.gz:twinkle kevin:BADURL:gdk-pixbuf-0.22.0.tar.bz2:gdk-pixbuf kwizart:BADURL:aqsis-1.2.0.tar.gz:aqsis kwizart:BADURL:oyranos-repack-0.1.7.tar.bz2:oyranos kzak:BADURL:lslk_1.29_W.tar.gz:lslk kzak:BADURL:mwords.tar.Z:words kzak:BADURL:vlock-1.3.tar.gz:vlock lennart:BADSOURCE:pavucontrol-0.9.6.tar.gz:pavucontrol leo:BADURL:pcmanx-gtk2.tar.gz:pcmanx-gtk2 linville:BADURL:b43-fwcutter-011.tar.bz2:b43-fwcutter liquidat:BADURL:Rsibreak-0.8.0.tar.bz2:rsibreak llim:BAD_CVS_SOURCE:lsb-release-2.0.tar.gz:redhat-lsb lmacken:BADSOURCE:TurboFlot-0.1.0.tar.bz2:python-turboflot lmacken:BADURL:deskbar-applet-2.23.1.tar.bz2:deskbar-applet lmacken:BADURL:TestGears-0.2.tar.gz:python-TestGears lucilanga:BADSOURCE:fuse-0.9.0.tar.gz:fuse-emulator lvm-team:BADURL:dmraid-1.0.0.rc14.tar.bz2:dmraid mattdm:BADURL:wxPython-src-2.8.7.1.tar.bz2:wxPython maxx:BADSOURCE:pdfcube-0.0.2.tar.gz:pdfcube maxx:BADURL:39179-rezlooks-0.6.tar.gz:gtk-rezlooks-engine mbarabas:BADSOURCE:system-config-vsftpd-0.4.5.tar.gz:system-config-vsftpd mbarnes:BADURL:devhelp-0.19.tar.bz2:devhelp mbarnes:BADURL:libsoup-2.23.1.tar.bz2:libsoup mbarnes:BADURL:Pyrex-0.9.5.1a.tar.gz:Pyrex mbarnes:BADURL:rarian-0.8.0.tar.bz2:rarian mccann:BADURL:gdm-2.21.10.tar.gz:gdm mclasen:BADURL:gnome-themes-2.23.1.tar.bz2:gnome-themes mclasen:BADURL:libbeagle-0.3.5.tar.bz2:libbeagle mebourne:BADSOURCE:ZoneMinder-1.22.3.tar.gz:zoneminder mebrown:BADSOURCE:libsmbios-2.0.1.tar.gz:libsmbios meme:BADSOURCE:vultures-2.1.0-full.tar.bz2:nethack-vultures mfleming:BADURL:mod-cband-0.9.7.5.tgz:mod_cband mgarski:BADSOURCE:linuxdcpp-1.0.1.tar.bz2:linuxdcpp mikeb:BADURL:python-krbV-1.0.13.tar.gz:python-krbV mikep:BADURL:fmt-ptrn-1.3.17.tar.gz:fmt-ptrn misa:BADURL:pyOpenSSL-0.6.tar.gz:pyOpenSSL mlichvar:BADSOURCE:setlayout.c:openbox mlichvar:BADURL:slrn-0.9.8.1pl1.tar.bz2:slrn mmahut:BADURL:munipack-0.3.1.tar.gz:munipack mmahut:BADURL:spacechart-0.9.5.tar.gz:spacechart mmcgrath:BADURL:nagios-2.11.tar.gz:nagios mmcgrath:BADURL:phpMyAdmin-2.11.5.2-all-languages.tar.bz2:phpMyAdmin mmcgrath:BADURL:SOAP-Lite-0.68.tar.gz:perl-SOAP-Lite mpg:BADURL:sugar-base-0.79.0.tar.bz2:sugar-base mpg:BADURL:sugar-datastore-0.6.0.tar.bz2:sugar-datastore mtasaka:BADURL:jd-2.0.0-svn2016_trunk.tgz:jd mtasaka:BADURL:manedit-0.8.1.tar.bz2:manedit mtasaka:BADURL:wallpapoz-0.4.1-svn87_trunk.tar.bz2:wallpapoz muerte:BADURL:qcomicbook-0.4.0.tar.gz:qcomicbook mwiriadi:BADURL:gnome-themes-extras-2.22.0.tar.gz:gnome-themes-extras mwiriadi:BADURL:gpicview-0.1.9.tar.gz:gpicview mwringe:BADSOURCE:jdepend-2.6-RHCLEAN.zip:jdepend mwringe:BADURL:commons-digester-1.7-src.tar.gz:jakarta-commons-digester mwringe:BADURL:commons-modeler-2.0-src.tar.gz:jakarta-commons-modeler mwringe:BADURL:nekohtml-0.9.5.tar.gz:nekohtml nalin:BADURL:nss_db-2.2.tar.gz:nss_db nalin:BADURL:nss_ldap-259.tar.gz:nss_ldap nalin:BADURL:pam_ldap-184.tar.gz:nss_ldap ngompa:BADURL:oggconvert-0.3.0.tar.gz:oggconvert nhorman:BADURL:cscope-15.6.tar.gz:cscope nigelj:BADURL:libipoddevice-0.5.3.tar.gz:libipoddevice nixaff4:BADURL:knotify-plugin_0.1.tar.gz:pidgin-knotify nmurray:BADURL:giflib-4.1.3.tar.bz2:giflib nmurray:BADURL:ImageMagick-6.4.0-10.tar.bz2:ImageMagick nomis80:BADURL:camstream-0.26.3.tar.gz:camstream nphilipp:BADSOURCE:gtkimageview-1.5.0.tar.gz:gtkimageview nsantos:BADURL:gnu.regexp-1.1.4.tar.gz:gnu-regexp ondrejj:BADSOURCE:sagator-1.0.0.tar.bz2:sagator orion:BADURL:ncarg_src-4.4.2.tar.gz:ncarg orphan:BADSOURCE:emesene-1.0.tar.gz:emesene orphan:BADSOURCE:gst-plugins-0.8.12.tar.bz2:gstreamer08-plugins orphan:BADURL:FreeWnn-1.1.1-a021.tar.bz2:FreeWnn orphan:BADURL:gnome-ppp-0.3.23.tar.bz2:gnome-ppp orphan:BADURL:gnome-yum-0.1.4.tar.gz:gnome-yum orphan:BADURL:new-1.3.9.tar.gz:new orphan:BADURL:pam-script-0.1.7.tar.gz:pam_script otaylor:BADURL:mugshot-1.1.95.tar.gz:mugshot ovasik:BADSOURCE:docbook-slides-3.4.0.tar.gz:docbook-slides ovasik:BADURL:gnome-bluetooth-0.11.0.tar.bz2:gnome-bluetooth ovasik:BADURL:passivetex-1.25.zip:passivetex ovasik:BADURL:xmltex-1.9.tar.gz:xmltex owentl:BADSOURCE:GoodWeather-0.3.tar.gz:gdesklets-goodweather pcheung:BAD_CVS_SOURCE:xmlunit-1.0.pom:xmlunit pertusus:BADURL:lesstif2_0.95.0-2.diff.gz:lesstif petersen:BADURL:ddskk-12.2.0.tar.bz2:ddskk pfj:BADSOURCE:CastPodder-5.0.tar.bz2:CastPodder pfj:BADSOURCE:db4o-6.1-mono.tar.gz:db4o pfj:BADSOURCE:mono-tools-1.9.tar.bz2:mono-tools pfj:BADSOURCE:xsp-1.9.tar.bz2:xsp pfj:BADURL:gDeskCal-1.01.tar.gz:gdeskcal pfj:BADURL:gtksourceview-sharp-2.0-0.11.tar.bz2:gtksourceview-sharp pfj:BADURL:ikvm-0.22.tar.gz:ikvm pfj:BADURL:mod_mono-1.9.tar.bz2:mod_mono pfj:BADURL:mono-debugger-0.60.tar.bz2:mono-debugger pfj:BADURL:monodoc-1.9.zip:monodoc pghmcfc:BADURL:libpng-1.0.32.tar.bz2:libpng10 pgordon:BADSOURCE:curvylooks-0.3.gtp:gnome-theme-curvylooks pgordon:BADURL:deluge-0.5.8.9.tar.gz:deluge pgordon:BADURL:empathy-0.23.1.tar.bz2:empathy pgordon:BADURL:labyrinth-0.4.0.tar.bz2:labyrinth pgordon:BADURL:libtorrent-0.12.1.tar.gz:rb_libtorrent phuang:BADSOURCE:scim-1.4.7.tar.gz:scim pingou:BADURL:Biobase_1.16.1.tar.gz:R-Biobase pingou:BADURL:DynDoc_1.17.0.tar.gz:R-DynDoc pingou:BADURL:rkward-0.5.0b-pre1.tar.gz:rkward pjones:BADSOURCE:cdparanoia-III-alpha9.8.src.tgz:cdparanoia pknirsch:BADSOURCE:ipmitool-1.8.9.tar.gz:OpenIPMI pravins:BADURL:scim-sinhala-trans-0.2.0-20060825.tar.gz:scim-sinhala pwouters:BADURL:ks3switch-0.1.tar.gz:ks3switch pwouters:BADURL:s3ssrc.zip:s3switch qspencer:BADURL:atlas3_3.6.0-20.diff.gz:atlas radford:BADURL:dkim-milter-2.5.1.tar.gz:dkim-milter rafalzaq:BADSOURCE:glob2-0.9.1.tar.gz:glob2 rafalzaq:BADURL:htop-0.7.tar.gz:htop rathann:BADURL:crm114-20070810-BlameTheSegfault.src.tar.gz:crm114 rathann:BADURL:libnemesi-0.6.4-rc2.tar.bz2:libnemesi rbhalera:BADURL:ISO8859-2-bdf.tar.gz:fonts-ISO8859-2 rbhalera:BADURL:Madan.ttf:madan-fonts rdieter:BADSOURCE:geomview-1.9.4.tar.bz2:geomview rdieter:BADURL:eric4-4.1.2.tar.gz:eric rdieter:BADURL:eric4-i18n-cs-4.1.2.tar.gz:eric rdieter:BADURL:eric4-i18n-de-4.1.2.tar.gz:eric rdieter:BADURL:eric4-i18n-fr-4.1.2.tar.gz:eric rdieter:BADURL:eric4-i18n-ru-4.1.2.tar.gz:eric rdieter:BADURL:kdetoys-4.0.3.tar.bz2:kdetoys rdieter:BADURL:libofa-0.9.3.tar.gz:libofa rdieter:BADURL:macref.pdf:maxima rdieter:BADURL:mtextralic.htm:mathml-fonts rdieter:BADURL:pinentry-0.7.4.tar.gz:pinentry rdieter:BADURL:pinentry-0.7.4.tar.gz.sig:pinentry rezso:BAD_CVS_SOURCE:proj.copyright:proj rezso:BADURL:geos-3.0.0.tar.bz2:geos rishi:BADSOURCE:httrack-3.42.tar.gz:httrack rishi:BADURL:isight-firmware-tools-1.0.2.tar.gz:isight-firmware-tools rjones:BADURL:lacaml-4.3.1.tar.bz2:ocaml-lacaml rmeggins:BADSOURCE:mozldap-6.0.5.tar.gz:mozldap rmeggins:BADURL:fedora-ds-base-1.1.0.1.tar.bz2:fedora-ds-base rmeggins:BADURL:Makefile.PL.rpm:perl-Mozilla-LDAP rmeggins:BADURL:perl-mozldap-1.5.2.tar.gz:perl-Mozilla-LDAP rnorwood:BADURL:gnome-packagekit-0.1.12-20080416git.tar.gz:gnome-packagekit rnorwood:BADURL:PackageKit-0.1.12-20080416git.tar.gz:PackageKit robert:BADURL:idn_1.2b.tar.gz:php-idn robmv:BADSOURCE:dirvish-1.2.1.tgz:dirvish rrakus:BADSOURCE:netkit-bootparamd-0.17.tar.gz:bootparamd rrakus:BADURL:cleanfeed-0.95.7b.tar.gz:cleanfeed rrelyea:BADSOURCE:ccid-1.2.1.tar.gz:ccid rrelyea:BADURL:pam_pkcs11-0.5.3.tar.gz:pam_pkcs11 rvokal:BADURL:gaim-guifications-2.13beta6.tar.bz2:gaim-guifications rvokal:BADURL:pidgin-guifications-2.14.tar.bz2:pidgin-guifications ryo:BADSOURCE:scim-skk-0.5.2.tar.gz:scim-skk s4504kr:BAD_CVS_SOURCE:import-3ds-0.7.py:blender s4504kr:BADURL:inadyn.v1.96.2.zip:inadyn s4504kr:BADURL:lightning-1.2.tar.gz:lightning s4504kr:BADURL:stellarium_user_guide-0.9.0-1.pdf:stellarium s4504kr:BADURL:suck-4.3.2.tar.gz:suck salimma:BADSOURCE:fbreader-sources-0.8.12.tgz:fbreader salimma:BADURL:Falcon-0.8.8-fc9.tar.gz:Falcon sandeen:BADURL:blktrace-git-20080103162505.tar.gz:blktrace sandeen:BADURL:e2fsprogs-1.40.9.tar.gz:e2fsprogs sconklin:BADURL:db-4.6.19.tar.gz:cyrus-sasl sconklin:BADURL:ipsec-tools-0.7.tar.bz2:ipsec-tools scop:BADSOURCE:dumpasn1.c:dumpasn1 sergiopr:BADURL:cpl-4.1.0.tar.gz:cpl sergiopr:BADURL:ds9.5.1.tar.gz:ds9 sergiopr:BADURL:esorex-3.6.8.tar.gz:esorex sergiopr:BADURL:qfits-6.2.0.tar.gz:qfits sergiopr:BADURL:wcstools-3.7.0.tar.gz:wcstools shahms:BADURL:PyProtocols-1.0a0dev-r2302.zip:python-protocols sharkcz:BADSOURCE:tinyerp-client-4.2.2.tar.gz:tinyerp sharkcz:BADSOURCE:tinyerp-server-4.2.2.tar.gz:tinyerp sheltren:BADURL:cfengine-2.2.6.tar.gz:cfengine sheltren:BADURL:fortune-hitchhiker.tgz:fortune-mod sheltren:BADURL:fortune-mod-1.99.1.tar.gz:fortune-mod sheltren:BADURL:fortune-tao.tar.gz:fortune-mod sheltren:BADURL:osfortune.tar.gz:fortune-mod silfreed:BADURL:qgis-0.9.1.tar.gz:qgis simo:BADURL:rsync-3.0.2.tar.gz:rsync simo:BADURL:rsync-patches-3.0.2.tar.gz:rsync sindrepb:BADURL:DBIx-SQLite-Simple-0.34.tar.gz:perl-DBIx-SQLite-Simple sindrepb:BADURL:gnome-do-0.4.2.0.tar.gz:gnome-do sindrepb:BADURL:nikto-1.36.tar.bz2:nikto sindrepb:BADURL:scratchpad-0.3.0.tar.bz2:scratchpad smccann:BADSOURCE:shapelib-1.2.10.tar.gz:shapelib snecker:BADURL:jokosher-20080216svn.tar.gz:jokosher snecker:BADURL:libflaim-4.9.1052.tar.gz:libflaim snirkel:BADURL:libmtp-0.2.6.1.tar.gz:libmtp snirkel:BADURL:njb-sharp-0.3.0.tar.bz2:njb-sharp splinux:BADURL:gdmap-0.7.5.tar.gz:gdmap splinux:BADURL:libgtksourceviewmm-0.3.1.tar.bz2:libgtksourceviewmm splinux:BADURL:pessulus-2.16.2.tar.bz2:pessulus spot:BADSOURCE:libsmi-0.4.8.tar.gz:libsmi spot:BADSOURCE:mpiblacs.tgz:blacs spot:BADSOURCE:ql2400_fw.bin:ql2400-firmware spot:BADSOURCE:srecord-1.39.tar.gz:srecord spot:BADURL:Class-Data-Inheritable-0.06.tar.gz:perl-Class-Data-Inheritable spot:BADURL:Class-DBI-Loader-Relationship-1.3.tar.gz:perl-Class-DBI-Loader-Relationship spot:BADURL:Class-DBI-Pg-0.09.tar.gz:perl-Class-DBI-Pg spot:BADURL:Config-IniFiles-2.39.tar.gz:perl-Config-IniFiles spot:BADURL:HTML-Tree-3.23.tar.gz:perl-HTML-Tree spot:BADURL:HTTP-Body-0.9.tar.gz:perl-HTTP-Body spot:BADURL:Ima-DBI-0.35.tar.gz:perl-Ima-DBI spot:BADURL:IO-CaptureOutput-1.06.tar.gz:perl-IO-CaptureOutput spot:BADURL:libgdamm-3.0.0.tar.bz2:libgdamm spot:BADURL:Mail-Box-2.073.tar.gz:perl-Mail-Box spot:BADURL:MARC-Record-2.0.0.tar.gz:perl-MARC-Record spot:BADURL:rx-1.5.tar.bz2:librx spot:BADURL:Scalar-Properties-0.13.tar.gz:perl-Scalar-Properties spot:BADURL:Tree-DAG_Node-1.06.tar.gz:perl-Tree-DAG_Node spot:BADURL:UNIVERSAL-isa-0.06.tar.gz:perl-UNIVERSAL-isa ssp:BADURL:libxkbfile-1.0.4.tar.bz2:libxkbfile ssp:BADURL:metacity-2.23.8.tar.bz2:metacity steve:BADURL:Data-Structure-Util-0.13.tar.gz:perl-Data-Structure-Util steve:BADURL:eperl_2.2.14-13.diff.gz:perl-eperl steved:BADURL:nfs.doc.tar.gz:nfs-utils stransky:BADURL:awesfx-0.5.0d.tar.gz:awesfx stransky:BADURL:gu11-rom.zip:awesfx svahl:BADURL:kcoloredit-4.0.3.tar.bz2:kcoloredit svahl:BADURL:kiconedit-4.0.3.tar.bz2:kiconedit sxw:BADURL:kstart-3.11.tar.gz:kstart tagoh:BAD_CVS_SOURCE:k14.patch:fonts-japanese tagoh:BADURL:anthy-9100e.tar.gz:anthy tagoh:BADURL:Canna37p3.tar.bz2:Canna tagoh:BADURL:k14-oldkanji.tar.gz:fonts-japanese tagoh:BADURL:Kappa20-0.396.tar.bz2:fonts-japanese tagoh:BADURL:mew-6.0.50.tar.gz:mew tagoh:BADURL:mplus_bitmap_fonts-2.2.4.tar.gz:fonts-japanese tagoh:BADURL:nkf-2.0.8b.tar.gz:nkf tagoh:BADURL:scim-anthy-1.2.4.tar.gz:scim-anthy tbzatek:BADURL:gnome-vfs-2.22.0.tar.bz2:gnome-vfs2 tbzatek:BADURL:xdg-user-dirs-0.10.tar.gz:xdg-user-dirs terjeros:BADURL:epplets-0.10.tar.gz:e16-epplets terjeros:BADURL:libast-0.7.1.tar.gz:libast tgl:BADSOURCE:pgtcl1.6.2.tar.gz:postgresql tgl:BADSOURCE:pgtcldocs-20070115.zip:postgresql tgl:BADURL:jpegsrc.v6b.tar.bz2:libjpeg tgl:BADURL:libpng-1.2.24.tar.bz2:libpng tgl:BADURL:mysql-5.0.51a.tar.gz:mysql tgl:BADURL:mysql-connector-odbc-3.51.24r1071.tar.gz:mysql-connector-odbc tgl:BADURL:pg_filedump-8.3.0.tar:rhdb-utils tgl:BADURL:postgresql-8.3.1-US.pdf:postgresql tgl:BADURL:psqlodbc-08.03.0100.tar.gz:postgresql-odbc than:BAD_CVS_SOURCE:French.txt:wordtrans than:BADSOURCE:css.tar.bz2:kdewebdev than:BADSOURCE:html.tar.bz2:kdewebdev than:BADSOURCE:javascript.tar.bz2:kdewebdev than:BADURL:arts-1.5.9.tar.bz2:arts than:BADURL:cyr-rfx-koi8-ub-1.1.bdfs.tar.bz2:fonts-KOI8-R than:BADURL:efax-0.9a-001114.tar.gz:efax than:BADURL:extragear-plasma-4.0.1.tar.bz2:extragear-plasma than:BADURL:isdn4k-utils-CVS-2006-07-20.tar.bz2:isdn4k-utils than:BADURL:kdeedu-4.0.3.tar.bz2:kdeedu than:BADURL:kdegames-4.0.3.tar.bz2:kdegames than:BADURL:kdegraphics-4.0.3.tar.bz2:kdegraphics than:BADURL:kde-i18n-ar-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-bg-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-bn-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-ca-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-cs-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-da-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-de-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-el-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-en_GB-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-es-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-et-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-fi-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-fr-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-he-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-hi-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-hu-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-is-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-it-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-ja-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-ko-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-lt-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-nb-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-nl-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-nn-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-pa-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-pl-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-pt-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-pt_BR-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-ro-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-ru-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-sk-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-sl-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-sr-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-sv-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-ta-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-tr-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-uk-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-zh_CN-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-i18n-zh_TW-3.5.9.tar.bz2:kde-i18n than:BADURL:kde-l10n-ar-4.0.3.tar.bz2:kde-l10n than:BADURL:kde-l10n-be-4.0.3.tar.bz2:kde-l10n than:BADURL:kde-l10n-ca-4.0.3.tar.bz2:kde-l10n than:BADURL:kde-l10n-cs-4.0.3.tar.bz2:kde-l10n than:BADURL:kde-l10n-csb-4.0.3.tar.bz2:kde-l10n than:BADURL:kde-l10n-da-4.0.3.tar.bz2:kde-l10n than:BADURL:kde-l10n-de-4.0.3.tar.bz2:kde-l10n than:BADURL:kde-l10n-el-4.0.3.tar.bz2:kde-l10n than:BADURL:kde-l10n-en_GB-4.0.3.tar.bz2:kde-l10n than:BADURL:kde-l10n-eo-4.0.3.tar.bz2:kde-l10n than:BADURL:kde-l10n-es-4.0.3.tar.bz2:kde-l10n than:BADURL:kde-l10n-et-4.0.3.tar.bz2:kde-l10n than:BADURL:kde-l10n-eu-4.0.3.tar.bz2:kde-l10n than:BADURL:kde-l10n-fi-4.0.3.tar.bz2:kde-l10n than:BADURL:kde-l10n-fr-4.0.3.tar.bz2:kde-l10n than:BADURL:kde-l10n-ga-4.0.3.tar.bz2:kde-l10n than:BADURL:kde-l10n-gl-4.0.3.tar.bz2:kde-l10n than:BADURL:kde-l10n-hi-4.0.3.tar.bz2:kde-l10n than:BADURL:kde-l10n-hu-4.0.3.tar.bz2:kde-l10n than:BADURL:kde-l10n-it-4.0.3.tar.bz2:kde-l10n than:BADURL:kde-l10n-ja-4.0.3.tar.bz2:kde-l10n than:BADURL:kde-l10n-km-4.0.3.tar.bz2:kde-l10n than:BADURL:kde-l10n-ko-4.0.3.tar.bz2:kde-l10n than:BADURL:kde-l10n-lv-4.0.3.tar.bz2:kde-l10n than:BADURL:kde-l10n-mk-4.0.3.tar.bz2:kde-l10n than:BADURL:kde-l10n-nb-4.0.3.tar.bz2:kde-l10n than:BADURL:kde-l10n-nds-4.0.3.tar.bz2:kde-l10n than:BADURL:kde-l10n-ne-4.0.3.tar.bz2:kde-l10n than:BADURL:kde-l10n-nl-4.0.3.tar.bz2:kde-l10n than:BADURL:kde-l10n-nn-4.0.3.tar.bz2:kde-l10n than:BADURL:kde-l10n-pa-4.0.3.tar.bz2:kde-l10n than:BADURL:kde-l10n-pl-4.0.3.tar.bz2:kde-l10n than:BADURL:kde-l10n-pt-4.0.3.tar.bz2:kde-l10n than:BADURL:kde-l10n-pt_BR-4.0.3.tar.bz2:kde-l10n than:BADURL:kde-l10n-ru-4.0.3.tar.bz2:kde-l10n than:BADURL:kde-l10n-se-4.0.3.tar.bz2:kde-l10n than:BADURL:kde-l10n-sl-4.0.3.tar.bz2:kde-l10n than:BADURL:kde-l10n-sv-4.0.3.tar.bz2:kde-l10n than:BADURL:kde-l10n-th-4.0.3.tar.bz2:kde-l10n than:BADURL:kde-l10n-tr-4.0.3.tar.bz2:kde-l10n than:BADURL:kde-l10n-uk-4.0.3.tar.bz2:kde-l10n than:BADURL:kde-l10n-wa-4.0.3.tar.bz2:kde-l10n than:BADURL:kde-l10n-zh_CN-4.0.3.tar.bz2:kde-l10n than:BADURL:kde-l10n-zh_TW-4.0.3.tar.bz2:kde-l10n than:BADURL:kdelibs-4.0.3.tar.bz2:kdelibs than:BADURL:kdemultimedia-4.0.3.tar.bz2:kdemultimedia than:BADURL:kdenetwork-4.0.3.tar.bz2:kdenetwork than:BADURL:kdepimlibs-4.0.3.tar.bz2:kdepimlibs than:BADURL:kdeutils-4.0.3.tar.bz2:kdeutils than:BADURL:kdevelop-3.5.1.tar.bz2:kdevelop than:BADURL:ksi-XFree86-cyrillic-fonts.tar.bz2:fonts-KOI8-R than:BADURL:mozplugger-1.10.1.tar.gz:mozplugger than:BADURL:rp-pppoe-3.8.tar.gz:rp-pppoe than:BADURL:urw-fonts-1.0.7pre44.tar.bz2:urw-fonts than:BADURL:wordtrans_1.1pre13.tar.gz:wordtrans thias:BADSOURCE:Nevow-0.9.29.tar.gz:python-nevow thias:BADURL:DirectFB-1.0.0.tar.gz:directfb thias:BADURL:glusterfs-1.3.8pre6.tar.gz:glusterfs thias:BADURL:postgrey-1.30.tar.gz:postgrey thias:BADURL:tagpy-0.94.1.tar.gz:python-tag thomasvs:BADSOURCE:libcmml-0.9.1.tar.gz:libcmml thomasvs:BADSOURCE:mod_annodex-ap20-0.2.2.tar.gz:mod_annodex thomasvs:BADURL:libannodex-0.7.3.tar.gz:libannodex thomasvs:BADURL:liboggz-0.9.5.tar.gz:liboggz timj:BADSOURCE:altermime-0.3.7.tar.gz:altermime timj:BADURL:rapidsvn-0.9.6.tar.gz:rapidsvn timj:BADURL:rpl_1.5.3.tar.gz:rpl tjanouse:BADURL:dovecot-1.0.13.tar.gz:dovecot tjikkun:BADURL:tkdnd-1.0a2.tar.gz:tkdnd tmraz:BAD_CVS_SOURCE:Linux-PAM-1.0.1.tar.bz2.sign:pam tmraz:BADURL:Linux-PAM-1.0.1.tar.bz2:pam toshio:BADURL:python-fedora-0.2.99.10.tar.gz:python-fedora tscherf:BADURL:libprelude-0.9.17.tar.gz:libprelude tscherf:BADURL:prelude-manager-0.9.12.tar.gz:prelude-manager twaugh:BADSOURCE:ppa-0.8.6.tar.gz:pnm2ppa twaugh:BADURL:cups-1.3.7-source.tar.bz2:cups twaugh:BADURL:foomatic-db-3.0-20080211.tar.gz:foomatic twaugh:BADURL:foomatic-db-engine-3.0-20080211.tar.gz:foomatic twaugh:BADURL:foomatic-db-hpijs-20080211.tar.gz:foomatic twaugh:BADURL:foomatic-filters-3.0-20080211.tar.gz:foomatic twaugh:BADURL:libieee1284-0.2.11.tar.bz2:libieee1284 varekova:BADURL:acct-6.3.2.tar.gz:psacct varekova:BADURL:gzip-1.3.12.tar.gz:gzip varekova:BADURL:mailx-8.1.1.tar.gz:mailx varekova:BADURL:manpages-ru-0.7.tar.gz:man-pages-ru varekova:BADURL:man-PL24-10-2005.tar.gz:man-pages-pl varekova:BADURL:mpfr-2.3.0.tar.bz2:mpfr varekova:BADURL:unzip552.tar.gz:unzip varekova:BADURL:zcrypt29.tar.gz:zip varekova:BADURL:zip231.tar.gz:zip vcrhonek:BADSOURCE:expect-5.43.0.tar.gz:expect vcrhonek:BADURL:pegasus-2.7.0.tar.gz:tog-pegasus veillard:BADURL:libxml2-2.6.32.tar.gz:libxml2 veillard:BADURL:libxslt-1.1.23.tar.gz:libxslt veillard:BADURL:opal-2.2.11.tar.gz:opal veillard:BADURL:pwlib-1.10.10.tar.gz:pwlib vlg:BADURL:granule-1.3.0.tar.gz:granule walters:BADURL:bigboard-0.5.33.tar.gz:bigboard walters:BADURL:desktop-data-model-1.2.4.tar.bz2:desktop-data-model walters:BADURL:online-desktop-0.2.28.tar.gz:online-desktop wtogami:BADURL:IO-Socket-INET6-2.54.tar.gz:perl-IO-Socket-INET6 xavierb:BADURL:xerces-c-src_2_7_0.tar.gz:xerces-c27 xgl-maint:BADURL:font-util-1.0.1.tar.bz2:xorg-x11-font-utils xgl-maint:BADURL:xf86-video-vesa-20080404.tar.bz2:xorg-x11-drv-vesa zkota:BADURL:bazaar_1.4.2.tar.gz:bazaar zkota:BADURL:bazaar-doc_1.4.tar.gz:bazaar zmc:BADSOURCE:pyspi-0.6.1.tar.gz:pyspi zprikryl:BADURL:eject-2.1.5.tar.gz:eject zprikryl:BADURL:vorbis-tools-1.2.0.tar.gz:vorbis-tools -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dwight at supercomputer.org Fri May 2 03:12:36 2008 From: dwight at supercomputer.org (dwight at supercomputer.org) Date: Thu, 1 May 2008 19:12:36 -0800 Subject: is xorg.conf still needed In-Reply-To: <1209664355.12336.16.camel@localhost> References: <1209523940.2906.136.camel@localhost.localdomain> <200805010556.57121.dwight@supercomputer.org> <1209664355.12336.16.camel@localhost> Message-ID: <200805012012.36277.dwight@supercomputer.org> On Thursday 01 May 2008 10:52:35 am Callum Lerwick wrote: > http://www.google.com/a/help/intl/en/var_0.html > > GNOME is working on a front end: > > http://live.gnome.org/OnlineDesktop > > And Red Hat is integrating it all: > > http://mugshot.org/ > > If you're expecting roadmaps and plans, you're going to be > disappointed. This is new territory, just being discovered. Who's > in charge? Whoever gets there first. I think you're confusing Stateless Linux with Stateless Linux Desktop. You might want to check out the Fedora Wiki regarding Stateless Linux, and see what it's actually about. It covers quite a bit more than just the Desktop. Google and Gnome are notably absent from the project. Granted, the Wiki might be out of date, as the Fedora Stateless Linux project seems to be rather dead, with no mail even being generated on its mailing list of late. The key point of interest to me is that that there are a number of issues which remain in Fedora's current Stateless Linux implementation even before you get to the Desktop, or any other apps which are built on top of the Stateless Linux functionality. Personally, I could care less about the Desktop or Google Apps in this particular regard. I'm more interested in getting the basic O.S. issues solved. If you do it right, you can kill several important birds with one stone. But it's not there yet. It also strikes me as being relatively straightforward towards ironing out these issues (and yes, I'll volunteer to do some of the work). But I'm not going to spend time on it if someone else is doing it. Or if my interpretation of what needs to be done isn't in sync with the general project. Nor if Stateless Linux (not Stateless Desktop) is dead, and has no future. -dwight- From seg at haxxed.com Fri May 2 07:01:40 2008 From: seg at haxxed.com (Callum Lerwick) Date: Fri, 02 May 2008 02:01:40 -0500 Subject: Multilib Middle-Ground In-Reply-To: <20080501181821.GC1427923@hiwaay.net> References: <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <604aa7910804301429k472cc2bcq8f9a06c1acd70b33@mail.gmail.com> <20080501110530.GA25448@imperial.ac.uk> <1b7401870805010516k7d3c0cadp5df5c1a162ebd2d4@mail.gmail.com> <1209662862.12336.5.camel@localhost> <20080501181821.GC1427923@hiwaay.net> Message-ID: <1209711700.12336.46.camel@localhost> On Thu, 2008-05-01 at 13:18 -0500, Chris Adams wrote: > Once upon a time, Callum Lerwick said: > > WINE, which has legitimate open source purposes. Sorry, some of us pay > > our rent by developing open source that runs on Windows. I'm not going > > to live in my car for the sake of ideological purity. > > Is there a bug that prevents "yum install wine" from pulling in the 32 > bit libraries as needed? That wasn't your question. I was answering your question and countering your underlying assertion that i386 compatibility is ideologically impure and only useful for closed source software. A MinGW cross-compiler toolchain and WINE provide a complete Windows development environment with absolutely no closed source involved, providing tools with which to wean people off closed source software one application at a time. Want another reason? Being able to develop and test i386 builds on my nice fast uber-RAM x86_64 box is incredibly useful. Not all of my machines are x86_64, and i386 is still the dominant architecture overall, so any sane developer HAS to make sure it works. Seriously, Fedora's ease of i386 compatibility is a *major* selling point for us. Go look around at the twisted flakey chroot hacks Debian/Ubuntu have to go through to get what we get with ease. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From valent.turkovic at gmail.com Fri May 2 07:37:57 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Fri, 2 May 2008 09:37:57 +0200 Subject: My eeexperience with Fedora 9 In-Reply-To: <481A4E52.2060809@fedoraproject.org> References: <64b14b300805010656r7516d23en855b250f3616d76d@mail.gmail.com> <64b14b300805011605g1941a630l71b238795f4f0d7c@mail.gmail.com> <481A4E52.2060809@fedoraproject.org> Message-ID: <64b14b300805020037q6a647f99mc8dbc38cd15ed294@mail.gmail.com> On Fri, May 2, 2008 at 1:12 AM, Rahul Sundaram wrote: > Valent Turkovic wrote: > > > > > > Are you aware of this issues or should I post bug reports if you were > > unaware of these issues in Asus eee. > > > > You should file bug reports. No requirement to post them anywhere else. > > Rahul > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Here are the bug reports I reported: Anaconda doesn't fit on Asus eee (800x480) screen https://bugzilla.redhat.com/show_bug.cgi?id=444943 Boot screen looks strange on Asus eee: https://bugzilla.redhat.com/show_bug.cgi?id=444944 I'm not sure which component is correct for bug 44944 so please correct it. Cheers, Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From aph at redhat.com Fri May 2 08:21:02 2008 From: aph at redhat.com (Andrew Haley) Date: Fri, 02 May 2008 09:21:02 +0100 Subject: Java debugging In-Reply-To: <870180fe0805011209j45a41560td588fd36f98394bc@mail.gmail.com> References: <870180fe0804281232m5740e3u4d1a47ba6bff009c@mail.gmail.com> <4816DE8B.8010102@redhat.com> <870180fe0804290938pbb73586o9033380c0eef7b52@mail.gmail.com> <481758D9.6030401@redhat.com> <870180fe0804291036v7a53caa0l2844679756abce94@mail.gmail.com> <481836E8.8010107@redhat.com> <870180fe0804301035y1be5302bm980c2cc87c0d86ab@mail.gmail.com> <4819DFEC.8030008@redhat.com> <870180fe0805011209j45a41560td588fd36f98394bc@mail.gmail.com> Message-ID: <481ACEEE.2060805@redhat.com> Jerry James wrote: > On Thu, May 1, 2008 at 9:21 AM, Andrew Haley wrote: >> I asked the java-1.5.0-gcj-devel maintainer, and got the reply: >> >> "We generally don't do updates in Fedora except for security fixes. >> We fix bugs in Rawhide and if users of the latest stable Fedora badly >> want the bug fix they can install the Rawhide packages." >> >> It's pretty hard in this case, as that'll pull in java-1.5.0-gcj* >> as well. Sorry. > > Correct me if I'm wrong in reaching these conclusions: > 1. No F8 Java debuginfo package includes sources. > 2. This will not be fixed. That seems likely, unless the packages are rebuilt for some reason other than missing debuginfo. We're certainly looking at backporting the fix to java-1.5.0-gcj-devel itself, though. Andrew. From j.w.r.degoede at hhs.nl Thu May 1 07:26:41 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 01 May 2008 09:26:41 +0200 Subject: Sponsor required In-Reply-To: <1209573092.2946.92.camel@vader.jdub.homelinux.org> References: <20080429101138.GA7656@redhat.com> <481779E1.70902@redhat.com> <48177FE6.7070409@hhs.nl> <1209555670.2946.85.camel@vader.jdub.homelinux.org> <481882AE.7050206@leemhuis.info> <1209573092.2946.92.camel@vader.jdub.homelinux.org> Message-ID: <481970B1.8060002@hhs.nl> Josh Boyer wrote: >> * new sponsor-nominations were not a FESCO-only thing; we tried to >> integrate the existing sponsors into the discussions and decisions, as >> they are in the best position for it (?) > Not AFAIK, I haven't seen a mail directed to the sponsors asking about the eligibility of a potential new sponsor in ages. For example where is the mail about Denis's self nomination. These mails had multiple purposes, they not only helped in getting some more input on wether someone is ready to become a sponsor, they also often lead to new nominations, as by talking about making people new sponsors people actually where thinking about it, and about who could be possible candidates. As Thorsten said, its important to keep this in people's radar, it is something that very easily gets drowned out in all the other stuff going on in Fedora. Regards, Hans From denis at poolshark.org Fri May 2 09:07:46 2008 From: denis at poolshark.org (Denis Leroy) Date: Fri, 02 May 2008 11:07:46 +0200 Subject: Sponsor required In-Reply-To: <481970B1.8060002@hhs.nl> References: <20080429101138.GA7656@redhat.com> <481779E1.70902@redhat.com> <48177FE6.7070409@hhs.nl> <1209555670.2946.85.camel@vader.jdub.homelinux.org> <481882AE.7050206@leemhuis.info> <1209573092.2946.92.camel@vader.jdub.homelinux.org> <481970B1.8060002@hhs.nl> Message-ID: <481AD9E2.3060308@poolshark.org> Hans de Goede wrote: > For example where is the mail about Denis's self nomination. Hans, I just added myself to the NewSponsors wiki. From lemenkov at gmail.com Fri May 2 09:35:26 2008 From: lemenkov at gmail.com (Peter Lemenkov) Date: Fri, 2 May 2008 13:35:26 +0400 Subject: How to downgrade Fedora to previous release? In-Reply-To: References: <4814596D.2020107@hhs.nl> <1209307875.10594.3.camel@rousalka.okg> Message-ID: 2008/5/1 Peter Lemenkov : > Filled a bug. > > https://bugzilla.redhat.com/show_bug.cgi?id=444890 Just found a solution - commenting out Option "AccelMethod" "exa" solved the issue. Since EXA is obsolete, it's not a solution but rather a workaround. See also http://bugs.freedesktop.org/show_bug.cgi?id=15611 https://bugzilla.redhat.com/show_bug.cgi?id=444890 -- With best regards! From rawhide at fedoraproject.org Fri May 2 11:33:02 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Fri, 2 May 2008 11:33:02 +0000 (UTC) Subject: rawhide report: 20080502 changes Message-ID: <20080502113303.1DA86209CFF@releng1.fedora.phx.redhat.com> Broken deps for ppc64 ---------------------------------------------------------- livecd-tools-016-1.fc9.ppc64 requires yaboot perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot From fedora at camperquake.de Fri May 2 12:31:35 2008 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 2 May 2008 14:31:35 +0200 Subject: How to downgrade Fedora to previous release? In-Reply-To: References: <4814596D.2020107@hhs.nl> <1209307875.10594.3.camel@rousalka.okg> Message-ID: <20080502143135.25522674@lain.camperquake.de> Hi. On Fri, 2 May 2008 13:35:26 +0400, Peter Lemenkov wrote > Since EXA is obsolete, it's not a solution but > rather a workaround. Where did that piece of information come from? From bpepple at fedoraproject.org Fri May 2 12:31:50 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Fri, 02 May 2008 08:31:50 -0400 Subject: Sponsor required In-Reply-To: <481970B1.8060002@hhs.nl> References: <20080429101138.GA7656@redhat.com> <481779E1.70902@redhat.com> <48177FE6.7070409@hhs.nl> <1209555670.2946.85.camel@vader.jdub.homelinux.org> <481882AE.7050206@leemhuis.info> <1209573092.2946.92.camel@vader.jdub.homelinux.org> <481970B1.8060002@hhs.nl> Message-ID: <1209731510.11031.1.camel@kennedy> On Thu, 2008-05-01 at 09:26 +0200, Hans de Goede wrote: > > For example where is the mail about Denis's self nomination. I had asked for some information from Denis before sending out the announcement, and just got a response from him last night. Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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: 197 bytes Desc: This is a digitally signed message part URL: From skvidal at fedoraproject.org Fri May 2 12:40:12 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 02 May 2008 08:40:12 -0400 Subject: Multilib Middle-Ground In-Reply-To: <1209711700.12336.46.camel@localhost> References: <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <604aa7910804301429k472cc2bcq8f9a06c1acd70b33@mail.gmail.com> <20080501110530.GA25448@imperial.ac.uk> <1b7401870805010516k7d3c0cadp5df5c1a162ebd2d4@mail.gmail.com> <1209662862.12336.5.camel@localhost> <20080501181821.GC1427923@hiwaay.net> <1209711700.12336.46.camel@localhost> Message-ID: <1209732012.3249.53.camel@cutter> On Fri, 2008-05-02 at 02:01 -0500, Callum Lerwick wrote: > On Thu, 2008-05-01 at 13:18 -0500, Chris Adams wrote: > > Once upon a time, Callum Lerwick said: > > > WINE, which has legitimate open source purposes. Sorry, some of us pay > > > our rent by developing open source that runs on Windows. I'm not going > > > to live in my car for the sake of ideological purity. > > > > Is there a bug that prevents "yum install wine" from pulling in the 32 > > bit libraries as needed? > > That wasn't your question. I was answering your question and countering > your underlying assertion that i386 compatibility is ideologically > impure and only useful for closed source software. A MinGW > cross-compiler toolchain and WINE provide a complete Windows development > environment with absolutely no closed source involved, providing tools > with which to wean people off closed source software one application at > a time. > > Want another reason? Being able to develop and test i386 builds on my > nice fast uber-RAM x86_64 box is incredibly useful. Not all of my > machines are x86_64, and i386 is still the dominant architecture > overall, so any sane developer HAS to make sure it works. Seriously, > Fedora's ease of i386 compatibility is a *major* selling point for us. > Go look around at the twisted flakey chroot hacks Debian/Ubuntu have to > go through to get what we get with ease. You realize that: 1. we just changed the default from 'install all/both arches' to 'install only the 'best' arch for this system', right 2. You can set this back by setting multilib_policy=all 3. This does not impact depsolving at all. Any package which requires an i386 dependency will get it pulled in. The concern that started this thread is that since we changed the default behavior the sky will fall down and the earth will tremble. That's the bit I don't understand. -sv From lemenkov at gmail.com Fri May 2 12:44:17 2008 From: lemenkov at gmail.com (Peter Lemenkov) Date: Fri, 2 May 2008 16:44:17 +0400 Subject: How to downgrade Fedora to previous release? In-Reply-To: <20080502143135.25522674@lain.camperquake.de> References: <4814596D.2020107@hhs.nl> <1209307875.10594.3.camel@rousalka.okg> <20080502143135.25522674@lain.camperquake.de> Message-ID: 2008/5/2 Ralf Ertzinger : > Hi. > > On Fri, 2 May 2008 13:35:26 +0400, Peter Lemenkov wrote > > > > Since EXA is obsolete, it's not a solution but > > rather a workaround. > > Where did that piece of information come from? Oops! I mean XAA. Sorry for noise. -- With best regards! From bpepple at fedoraproject.org Fri May 2 13:45:16 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Fri, 02 May 2008 09:45:16 -0400 Subject: New Sponsor Request: Denis Leroy Message-ID: <1209735916.11031.9.camel@kennedy> Hi all, Denis Leroy(1) has requested to be made a sponsor. FESCo will vote on his request at the 2008-05-08 meeting. Here are some links to some examples of his work: https://bugzilla.redhat.com/show_bug.cgi?id=250240 https://bugzilla.redhat.com/show_bug.cgi?id=209144 https://bugzilla.redhat.com/show_bug.cgi?id=206395 https://bugzilla.redhat.com/show_bug.cgi?id=226414 https://bugzilla.redhat.com/show_bug.cgi?id=205869 https://bugzilla.redhat.com/show_bug.cgi?id=441084 http://www.redhat.com/archives/fedora-devel-list/2008-April/msg00518.html http://www.redhat.com/archives/fedora-devel-list/2007-August/msg01011.html (1) http://fedoraproject.org/wiki/DenisLeroy BTW, any Fedora packager that wishes to become a sponsor, can contact me or go directly to: http://fedoraproject.org/wiki/Extras/Schedule/NewSponsors Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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: 197 bytes Desc: This is a digitally signed message part URL: From qspencer at ieee.org Fri May 2 14:06:25 2008 From: qspencer at ieee.org (Quentin Spencer) Date: Fri, 02 May 2008 09:06:25 -0500 Subject: Strange build failure Message-ID: <481B1FE1.6060500@ieee.org> I'm getting the following failure when compiling octave-forge on rawhide: usr/bin/ld: cannot find -lMagick I don't understand why this would fail because: 1. Looking at root.log, ImageMagick-devel has been installed. 2. There is a preceding configure step in which it correctly detects libMagick 3. The package compiles locally on my computer without problems. 4. This was not a problem for previous releases of octave-forge. Is there any reason why linking to libMagick might require some other dependency that I don't have installed in the buildroot? Quentin From mtasaka at ioa.s.u-tokyo.ac.jp Fri May 2 14:17:05 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Fri, 02 May 2008 23:17:05 +0900 Subject: Strange build failure In-Reply-To: <481B1FE1.6060500@ieee.org> References: <481B1FE1.6060500@ieee.org> Message-ID: <481B2261.8080008@ioa.s.u-tokyo.ac.jp> Quentin Spencer wrote, at 05/02/2008 11:06 PM +9:00: > I'm getting the following failure when compiling octave-forge on rawhide: > > usr/bin/ld: cannot find -lMagick libMagick.so is renamed on F-10 ImageMagick 6.4.0+ https://www.redhat.com/archives/fedora-devel-list/2008-April/msg02095.html Regards, Mamoru From tibbs at math.uh.edu Fri May 2 15:27:44 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 02 May 2008 10:27:44 -0500 Subject: /etc/alternatives not quite working In-Reply-To: <1209698319.20913.146.camel@localhost.localdomain> References: <1209640378.3358.6.camel@T7.Linux> <1209698319.20913.146.camel@localhost.localdomain> Message-ID: >>>>> "TC" == Tom \"spot\" Callaway writes: TC> I'm trying to reproduce this one to troubleshoot it, but I simply TC> can't, not even following the steps listed in bz 394131. I had one fresh F7 install (out of a hundred or so) where emacs was installed but the alternatives stuff just wasn't done at all. All of the installs were identical (all i386, same kickstart files/package set, though the hardware itself differs wildly). I couldn't figure out what had gone wrong, and reinstalling emacs fixed things up. I suspect there's some weird race involved. - J< From lesmikesell at gmail.com Fri May 2 15:43:11 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 02 May 2008 10:43:11 -0500 Subject: Multilib Middle-Ground In-Reply-To: <20080502004139.GA1272043@hiwaay.net> References: <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819C1EF.6050009@gmail.com> <604aa7910805010914n987c810g4591ff3065f8844b@mail.gmail.com> <4819FB60.5000606@gmail.com> <604aa7910805011020k4732d6cbv11ed7a813d9fa068@mail.gmail.com> <481A19BA.6090705@gmail.com> <604aa7910805011244q78338786y956500dd55649441@mail.gmail.com> <481A4871.50102@gmail.com> <20080502004139.GA1272043@hiwaay.net> Message-ID: <481B368F.8060107@gmail.com> Chris Adams wrote: > Once upon a time, Les Mikesell said: >> I'd think that a distribution on the bleeding edge as fedora should be >> the one leading this effort, not looking for something to join. > > One problem with standardization is that it tends to freeze development > in some ways. And encourage it in other ways. > A big compatibility issue is shared library sonames. For > standards to emerge, you'd have to define a complete set of compatible > sonames. Yes. Which would amount to each distribution doing less changes. > That would mean all compatible distributions would have to be > using (essentially) the same version glibc, gcc, X, GNOME, KDE, perl, > python, etc. at the same time. No, it would mean maintaining that standard above with required backward compatibility. You'd only have update libs to match the newest app rev you want to run. > It would require all the major open > source projects to be synchronized to the same release schedule (or at > least all distributions to pick up new versions of everything at the > same time of year). That wouldn't be a bad thing for linux distributions to do, but I don't see how there is any timing requirement inherently tied to providing standard interfaces. > That just isn't going to happen. For some of these things, Linux > distributions are a large part of their user base (glibc, GNOME, KDE), > and you might could work with them, but for things like gcc, perl, and > python, Linux is only one of many targets. I wasn't aware that perl had a lot of library version specific requirements. Can't you compile a current perl just about anywhere? > Usually, if you restrict yourself to building against older versions of > the libraries (e.g. pick the oldest enterprise distribution you are > interested in supporting), your program should run with no problems on > the latest bleeding-edge distributions. So why isn't it done this way in all cases to get distribution-agnostic application versions instead of making people with multiple distros get different flavors for each? > However, they do package it with some compat libraries like OpenSSL; > that's a library though that has traditionally been one of the worst at > ABI compatibility in the shared libraries (and there's not much Fedora > can do about that). They also include libgcc and libstdc++, also > libraries that have had a moving target ABI over time. Just because some developer writes some incompatible code doesn't mean distributions have to ship it. -- Les Mikesell lesmikesell at gmail.com From mcepl at redhat.com Fri May 2 15:41:20 2008 From: mcepl at redhat.com (Matej Cepl) Date: Fri, 02 May 2008 17:41:20 +0200 Subject: is xorg.conf still needed References: <1209523940.2906.136.camel@localhost.localdomain> <200805010556.57121.dwight@supercomputer.org> <1209664355.12336.16.camel@localhost> <200805012012.36277.dwight@supercomputer.org> Message-ID: <0apre5xc1b.ln2@ppp1053.in.ipex.cz> On 2008-05-02, 03:12 GMT, dwight at supercomputer.org wrote: > I think you're confusing Stateless Linux with Stateless Linux > Desktop. You are confusing Stateless Linux and Online Desktop. Mat?j From mcepl at redhat.com Fri May 2 15:37:52 2008 From: mcepl at redhat.com (Matej Cepl) Date: Fri, 02 May 2008 17:37:52 +0200 Subject: How to downgrade Fedora to previous release? References: <4814596D.2020107@hhs.nl> <1209307875.10594.3.camel@rousalka.okg> Message-ID: On 2008-05-02, 09:35 GMT, Peter Lemenkov wrote: > Since EXA is obsolete, it's not a solution but s/obsolete/not yet complete/ From mcepl at redhat.com Fri May 2 15:39:46 2008 From: mcepl at redhat.com (Matej Cepl) Date: Fri, 02 May 2008 17:39:46 +0200 Subject: is xorg.conf still needed References: <1209523940.2906.136.camel@localhost.localdomain> <7amle5xkvo.ln2@ppp1053.in.ipex.cz> <200804302029.10986.dwight@supercomputer.org> Message-ID: <27pre5xc1b.ln2@ppp1053.in.ipex.cz> On 2008-05-01, 03:29 GMT, dwight at supercomputer.org wrote: > Are we really? Upon what do you base that statement? I'd be > very interested in knowing more, because the Stateless Linux > mailing list looks rather inactive. Is there a roadmap? And > what's the current status? I used ?Stateless Linux? in very open meaning of the word. AFAIK it is now more state of mind, than a real project. Mat?j From lesmikesell at gmail.com Fri May 2 15:59:44 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 02 May 2008 10:59:44 -0500 Subject: Multilib Middle-Ground In-Reply-To: <604aa7910805011549i47c6193bs177e57cea293dd75@mail.gmail.com> References: <4817FF36.10305@redhat.com> <48198EA0.5070904@gmail.com> <4819C1EF.6050009@gmail.com> <604aa7910805010914n987c810g4591ff3065f8844b@mail.gmail.com> <4819FB60.5000606@gmail.com> <604aa7910805011020k4732d6cbv11ed7a813d9fa068@mail.gmail.com> <481A19BA.6090705@gmail.com> <604aa7910805011244q78338786y956500dd55649441@mail.gmail.com> <604aa7910805011549i47c6193bs177e57cea293dd75@mail.gmail.com> Message-ID: <481B3A70.6070509@gmail.com> Jeff Spaleta wrote: > > What Fedora as a community needs to achieve is too important for me to > indulge in petty bickering. But I tell you honestly... Les's inability > to answer my question straight forwardly brings out my desire to > retort with passionate displeasure, as I'm somewhat sure it does to > other people. How can I - or anyone - answer a question about something that doesn't exist? My original comment was to the effect that it was a bad thing that is doesn't. > Les is on the verge of losing his > unless he makes and effort to rein in the vitriol and hyperbole and > find something constructive to say. Nothing I've said has had any vitrol and not much hyperbole. I just have the opinion that making it difficult to run programs that aren't specifically included and modified for fedora is a bad thing for everyone, even if that opinion is unpopular here. -- Les Mikesell lesmikesell at gmail.com From jspaleta at gmail.com Fri May 2 16:07:10 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 2 May 2008 08:07:10 -0800 Subject: Multilib Middle-Ground In-Reply-To: <481B3A70.6070509@gmail.com> References: <4817FF36.10305@redhat.com> <604aa7910805010914n987c810g4591ff3065f8844b@mail.gmail.com> <4819FB60.5000606@gmail.com> <604aa7910805011020k4732d6cbv11ed7a813d9fa068@mail.gmail.com> <481A19BA.6090705@gmail.com> <604aa7910805011244q78338786y956500dd55649441@mail.gmail.com> <604aa7910805011549i47c6193bs177e57cea293dd75@mail.gmail.com> <481B3A70.6070509@gmail.com> Message-ID: <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> On Fri, May 2, 2008 at 7:59 AM, Les Mikesell wrote: > How can I - or anyone - answer a question about something that doesn't > exist? My original comment was to the effect that it was a bad thing that > is doesn't. If there is no standard you cannot claim that what we are doing internal is not appropriate. > Nothing I've said has had any vitrol and not much hyperbole. I just have > the opinion that making it difficult to run programs that aren't > specifically included and modified for fedora is a bad thing for everyone, > even if that opinion is unpopular here. Stop singling Fedora out specifically. You can single out what we are doing and say is any more non-standard that what other distros are doing. 'We' aren't making it difficult.. we have a documented set of packaging guidance. Others are free to adopt it.. why don't you go ask the other distros to adopt what we are doing as their standard? Actually no don't do that. I find someone who isn't as abrasive. -jef From dwight at supercomputer.org Fri May 2 16:20:31 2008 From: dwight at supercomputer.org (dwight at supercomputer.org) Date: Fri, 2 May 2008 08:20:31 -0800 Subject: is xorg.conf still needed In-Reply-To: <27pre5xc1b.ln2@ppp1053.in.ipex.cz> References: <1209523940.2906.136.camel@localhost.localdomain> <200804302029.10986.dwight@supercomputer.org> <27pre5xc1b.ln2@ppp1053.in.ipex.cz> Message-ID: <200805020920.31635.dwight@supercomputer.org> On Friday 02 May 2008 08:39:46 am Matej Cepl wrote: > On 2008-05-01, 03:29 GMT, dwight at supercomputer.org wrote: > > Are we really? Upon what do you base that statement? I'd be > > very interested in knowing more, because the Stateless Linux > > mailing list looks rather inactive. Is there a roadmap? And > > what's the current status? > > I used ?Stateless Linux? in very open meaning of the word. AFAIK > it is now more state of mind, than a real project. > > Mat?j Thanks for clarifying that. From my point of view, I'm talking about real code, as currently implemented. Hopefully we have that all cleared up. -dwight- From dwight at supercomputer.org Fri May 2 16:17:57 2008 From: dwight at supercomputer.org (dwight at supercomputer.org) Date: Fri, 2 May 2008 08:17:57 -0800 Subject: is xorg.conf still needed In-Reply-To: <0apre5xc1b.ln2@ppp1053.in.ipex.cz> References: <1209523940.2906.136.camel@localhost.localdomain> <200805012012.36277.dwight@supercomputer.org> <0apre5xc1b.ln2@ppp1053.in.ipex.cz> Message-ID: <200805020917.58138.dwight@supercomputer.org> On Friday 02 May 2008 08:41:20 am Matej Cepl wrote: > On 2008-05-02, 03:12 GMT, dwight at supercomputer.org wrote: > > I think you're confusing Stateless Linux with Stateless Linux > > Desktop. > > You are confusing Stateless Linux and Online Desktop. > > Mat?j Not at all. I'm using the term "Stateless Linux" as defined the Fedora Wiki, and as currently implemented in Fedora. This is a Fedora list. after all. -dwight- From pertusus at free.fr Fri May 2 17:24:38 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 2 May 2008 19:24:38 +0200 Subject: Multilib Middle-Ground In-Reply-To: <481B368F.8060107@gmail.com> References: <4819C1EF.6050009@gmail.com> <604aa7910805010914n987c810g4591ff3065f8844b@mail.gmail.com> <4819FB60.5000606@gmail.com> <604aa7910805011020k4732d6cbv11ed7a813d9fa068@mail.gmail.com> <481A19BA.6090705@gmail.com> <604aa7910805011244q78338786y956500dd55649441@mail.gmail.com> <481A4871.50102@gmail.com> <20080502004139.GA1272043@hiwaay.net> <481B368F.8060107@gmail.com> Message-ID: <20080502172438.GA2649@free.fr> On Fri, May 02, 2008 at 10:43:11AM -0500, Les Mikesell wrote: > >> A big compatibility issue is shared library sonames. For >> standards to emerge, you'd have to define a complete set of compatible >> sonames. > > Yes. Which would amount to each distribution doing less changes. And not to follow upstream changes? This is not good for fedora. I completely agree with you that incompatible ABI changes are hurting free software, but this should be fixed upstream, and not in linux distros. You could try to approach upstream projects that break ABI frequently and try to convince them to avoid breaking ABI if you want to, but fedora cannot do anything else than consuming what upstream produces. >> That would mean all compatible distributions would have to be >> using (essentially) the same version glibc, gcc, X, GNOME, KDE, perl, >> python, etc. at the same time. > > No, it would mean maintaining that standard above with required backward > compatibility. You'd only have update libs to match the newest app rev you > want to run. This is not that different than what is done in fedora. Of course we may wait for an application that use new features of an ABI modified application to be needed, but it wouldn't be very different from what we do now. You could try to push the idea that within a fedora version ABI compatibility should be kept if possible, but between fedora versions, I think that it is better to follow upstream. > Just because some developer writes some incompatible code doesn't mean > distributions have to ship it. What do you propose instead? Not following upstream? -- Pat From walters at verbum.org Fri May 2 17:45:14 2008 From: walters at verbum.org (Colin Walters) Date: Fri, 2 May 2008 13:45:14 -0400 Subject: /etc/alternatives not quite working In-Reply-To: References: <1209640378.3358.6.camel@T7.Linux> <1209698319.20913.146.camel@localhost.localdomain> Message-ID: On Fri, May 2, 2008 at 11:27 AM, Jason L Tibbitts III wrote: > > I had one fresh F7 install (out of a hundred or so) where emacs was > installed but the alternatives stuff just wasn't done at all. All of > the installs were identical (all i386, same kickstart files/package > set, though the hardware itself differs wildly). I couldn't figure > out what had gone wrong, and reinstalling emacs fixed things up. There's some sort of binary state files in /var/lib/alternatives; I once had a problem on one of our servers where the /usr/bin/java alternative was screwed up, and eventually traced it down to what appeared to be corruption of that file. I fixed it by blowing it away and reinstalling the package, attributing it to a heisenbug, but maybe there is some sort of race or periodic flaw in the alternatives system. From lesmikesell at gmail.com Fri May 2 18:14:40 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 02 May 2008 13:14:40 -0500 Subject: Multilib Middle-Ground In-Reply-To: <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> References: <4817FF36.10305@redhat.com> <604aa7910805010914n987c810g4591ff3065f8844b@mail.gmail.com> <4819FB60.5000606@gmail.com> <604aa7910805011020k4732d6cbv11ed7a813d9fa068@mail.gmail.com> <481A19BA.6090705@gmail.com> <604aa7910805011244q78338786y956500dd55649441@mail.gmail.com> <604aa7910805011549i47c6193bs177e57cea293dd75@mail.gmail.com> <481B3A70.6070509@gmail.com> <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> Message-ID: <481B5A10.9010308@gmail.com> Jeff Spaleta wrote: > On Fri, May 2, 2008 at 7:59 AM, Les Mikesell wrote: >> How can I - or anyone - answer a question about something that doesn't >> exist? My original comment was to the effect that it was a bad thing that >> is doesn't. > > If there is no standard you cannot claim that what we are doing > internal is not appropriate. > >> Nothing I've said has had any vitrol and not much hyperbole. I just have >> the opinion that making it difficult to run programs that aren't >> specifically included and modified for fedora is a bad thing for everyone, >> even if that opinion is unpopular here. > > > Stop singling Fedora out specifically. This particular thread is about a specific change proposed for fedora - which if made will make it more complicated to install VMWare and probably many other things. Others have been about how other distributions make things easier for their users. Or how it is bad that fedora no longer works with japackage.org. By nature, those things are fedora-specific. You can single out what we are > doing and say is any more non-standard that what other distros are > doing. 'We' aren't making it difficult.. Oh, please... What do you have to do in fedora to get a java working that will run most of the the available (but not packaged for fedora) open source java programs like opengrok and alfresco? It's not quite impossible but I dare you to claim its not difficult. OpenNMS and Openfire sort-of cater to this deficiency by including a JVM in their RPM distributions but if you installed both you wouldn't get shared text execution and who knows what would execute for other instances. And running applets in browsers should work out of the box even if you were once misled by lies about java being a trap. -- Les Mikesell lesmikesell at gmail.com From jspaleta at gmail.com Fri May 2 18:24:22 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 2 May 2008 10:24:22 -0800 Subject: Multilib Middle-Ground In-Reply-To: <481B5A10.9010308@gmail.com> References: <4817FF36.10305@redhat.com> <4819FB60.5000606@gmail.com> <604aa7910805011020k4732d6cbv11ed7a813d9fa068@mail.gmail.com> <481A19BA.6090705@gmail.com> <604aa7910805011244q78338786y956500dd55649441@mail.gmail.com> <604aa7910805011549i47c6193bs177e57cea293dd75@mail.gmail.com> <481B3A70.6070509@gmail.com> <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> <481B5A10.9010308@gmail.com> Message-ID: <604aa7910805021124s1997ad8erec66f2522e413bd8@mail.gmail.com> On Fri, May 2, 2008 at 10:14 AM, Les Mikesell wrote: > This particular thread is about a specific change proposed for fedora - > which if made will make it more complicated to install VMWare and probably > many other things. Others have been about how other distributions make > things easier for their users. Or how it is bad that fedora no longer works > with japackage.org. By nature, those things are fedora-specific. There no 'standard' by which to measure the value of change. If all distros are doing things differently you can't single us out for making a change that breaks cross-distro compatibility that doesn't already exist. The only thing you've pointed to so far is LSB... are you attempting to claim we are breaking LSB with this change? Things are already incompatible.. in a non-standardized way. By putting your foot down and demanding that we stop our own process to evolve you aren't solving the underlying problem. Stagnation is not standardization. No matter how we get their...cross-distro standardization is going to involve change in how each distro currently does things... so change is unavoidable no matter what happens. You are arguing for the wrong thing. -jef From aph at redhat.com Fri May 2 18:26:11 2008 From: aph at redhat.com (Andrew Haley) Date: Fri, 02 May 2008 19:26:11 +0100 Subject: Multilib Middle-Ground In-Reply-To: <481B5A10.9010308@gmail.com> References: <4817FF36.10305@redhat.com> <604aa7910805010914n987c810g4591ff3065f8844b@mail.gmail.com> <4819FB60.5000606@gmail.com> <604aa7910805011020k4732d6cbv11ed7a813d9fa068@mail.gmail.com> <481A19BA.6090705@gmail.com> <604aa7910805011244q78338786y956500dd55649441@mail.gmail.com> <604aa7910805011549i47c6193bs177e57cea293dd75@mail.gmail.com> <481B3A70.6070509@gmail.com> <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> <481B5A10.9010308@gmail.com> Message-ID: <481B5CC3.3090806@redhat.com> Les Mikesell wrote: > Jeff Spaleta wrote: > You can single out what we are >> doing and say is any more non-standard that what other distros are >> doing. 'We' aren't making it difficult.. > > Oh, please... What do you have to do in fedora to get a java working > that will run most of the the available (but not packaged for fedora) > open source java programs like opengrok and alfresco? It's not quite > impossible but I dare you to claim its not difficult. OpenNMS and > Openfire sort-of cater to this deficiency by including a JVM in their > RPM distributions but if you installed both you wouldn't get shared text > execution and who knows what would execute for other instances. If anyone ever works out what this complaint might be about and if there's any substance to it, please let me know. Andrew. From lesmikesell at gmail.com Fri May 2 18:43:39 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 02 May 2008 13:43:39 -0500 Subject: Multilib Middle-Ground In-Reply-To: <481B5CC3.3090806@redhat.com> References: <4817FF36.10305@redhat.com> <604aa7910805010914n987c810g4591ff3065f8844b@mail.gmail.com> <4819FB60.5000606@gmail.com> <604aa7910805011020k4732d6cbv11ed7a813d9fa068@mail.gmail.com> <481A19BA.6090705@gmail.com> <604aa7910805011244q78338786y956500dd55649441@mail.gmail.com> <604aa7910805011549i47c6193bs177e57cea293dd75@mail.gmail.com> <481B3A70.6070509@gmail.com> <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> <481B5A10.9010308@gmail.com> <481B5CC3.3090806@redhat.com> Message-ID: <481B60DB.90202@gmail.com> Andrew Haley wrote: > > >> You can single out what we are >>> doing and say is any more non-standard that what other distros are >>> doing. 'We' aren't making it difficult.. >> Oh, please... What do you have to do in fedora to get a java working >> that will run most of the the available (but not packaged for fedora) >> open source java programs like opengrok and alfresco? It's not quite >> impossible but I dare you to claim its not difficult. OpenNMS and >> Openfire sort-of cater to this deficiency by including a JVM in their >> RPM distributions but if you installed both you wouldn't get shared text >> execution and who knows what would execute for other instances. > > If anyone ever works out what this complaint might be about and if there's > any substance to it, please let me know. The almost-java versions included in fedora don't run most real-world java code. And it is much more difficult than necessary to install a real java version. Just including a jpackage nosrc-style package to adjust Sun Java to fedora's peculiar needs would eliminate this complaint, although I really think it would have been better to stay compatible with jpackage.org and avoid any extra work. I can't think of any functional reason why different fedora versions should even need different repositories for java packages but maybe I've missed something there. -- Les Mikesell lesmikeell at gmail.com From walters at verbum.org Fri May 2 18:58:17 2008 From: walters at verbum.org (Colin Walters) Date: Fri, 2 May 2008 14:58:17 -0400 Subject: Multilib Middle-Ground In-Reply-To: <481B60DB.90202@gmail.com> References: <4817FF36.10305@redhat.com> <481A19BA.6090705@gmail.com> <604aa7910805011244q78338786y956500dd55649441@mail.gmail.com> <604aa7910805011549i47c6193bs177e57cea293dd75@mail.gmail.com> <481B3A70.6070509@gmail.com> <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> <481B5A10.9010308@gmail.com> <481B5CC3.3090806@redhat.com> <481B60DB.90202@gmail.com> Message-ID: On Fri, May 2, 2008 at 2:43 PM, Les Mikesell wrote: > > The almost-java versions included in fedora don't run most real-world java > code. If we're talking about Fedora 8, yes, there are issues because the the OpenJDK we ship is a snapshot of JDK 7. We might consider shipping an update which doesn't replace java-1.7.0-icedtea, but that people can switch to with update-alternatives. But for Fedora 9, I don't think one can say "most" things won't run with java-1.6.0-openjdk. > And it is much more difficult than necessary to install a real java > version. Just including a jpackage nosrc-style package to adjust Sun Java > to fedora's peculiar needs would eliminate this complaint, although I really > think it would have been better to stay compatible with jpackage.org and > avoid any extra work. Basically, Fedora is a lot more interested in improving our free stack. It's been well known for years how to install the proprietary JDK; yes, jpackage makes it a lot nicer for those people aware of the system, but I think we should leave it up to jpackage rather than putting it into Fedora. From lesmikesell at gmail.com Fri May 2 19:04:58 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 02 May 2008 14:04:58 -0500 Subject: Multilib Middle-Ground In-Reply-To: <20080502172438.GA2649@free.fr> References: <4819C1EF.6050009@gmail.com> <604aa7910805010914n987c810g4591ff3065f8844b@mail.gmail.com> <4819FB60.5000606@gmail.com> <604aa7910805011020k4732d6cbv11ed7a813d9fa068@mail.gmail.com> <481A19BA.6090705@gmail.com> <604aa7910805011244q78338786y956500dd55649441@mail.gmail.com> <481A4871.50102@gmail.com> <20080502004139.GA1272043@hiwaay.net> <481B368F.8060107@gmail.com> <20080502172438.GA2649@free.fr> Message-ID: <481B65DA.6010505@gmail.com> Patrice Dumas wrote: > >>> A big compatibility issue is shared library sonames. For >>> standards to emerge, you'd have to define a complete set of compatible >>> sonames. >> Yes. Which would amount to each distribution doing less changes. > > And not to follow upstream changes? This is not good for fedora. Why? You have no qualms about trying to influence what proprietary vendors do by not shipping things you don't like. Why not do the same where its more likely to make a useful difference? > I > completely agree with you that incompatible ABI changes are hurting > free software, but this should be fixed upstream, and not in linux > distros. But as long as you keep shipping things without backwards compatibility you not only hurt your existing users whose own code will break but you encourage the practice. It's always possible to add new interfaces instead of breaking the old ones if they weren't designed to be extensible. > You could try to approach upstream projects that break ABI > frequently and try to convince them to avoid breaking ABI if you want > to, but fedora cannot do anything else than consuming what upstream > produces. If you know something hurts, why keep doing it? Why not maintain stable kernel and library versions for long periods with the current kernel and differently-named experimental libs as alternative choices? After some long interval of concurrent use and compatibility testing the no-longer-expermental libs could replace the stable versions. >> No, it would mean maintaining that standard above with required backward >> compatibility. You'd only have update libs to match the newest app rev you >> want to run. > > This is not that different than what is done in fedora. Of course we may > wait for an application that use new features of an ABI modified > application to be needed, but it wouldn't be very different from what we > do now. You could try to push the idea that within a fedora version ABI > compatibility should be kept if possible, but between fedora versions, > I think that it is better to follow upstream. I think that should depend on what upstream does. Fedora has a fast enough cycle that waiting for the next release for an incompatible change wouldn't kill anyone. >> Just because some developer writes some incompatible code doesn't mean >> distributions have to ship it. > > What do you propose instead? Not following upstream? Just not breaking anything that already works. If upstream does that, the distribution has to make a choice between bleeding-edge code and hurting its users. The code will still be there for the next release - and maybe by then it will have fixed its backwards compatibility. -- Les Mikesell lesmikesell at gmail.com From nicolas.mailhot at laposte.net Fri May 2 19:10:08 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 02 May 2008 21:10:08 +0200 Subject: Multilib Middle-Ground In-Reply-To: References: <4817FF36.10305@redhat.com> <481A19BA.6090705@gmail.com> <604aa7910805011244q78338786y956500dd55649441@mail.gmail.com> <604aa7910805011549i47c6193bs177e57cea293dd75@mail.gmail.com> <481B3A70.6070509@gmail.com> <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> <481B5A10.9010308@gmail.com> <481B5CC3.3090806@redhat.com> <481B60DB.90202@gmail.com> Message-ID: <1209755408.6004.7.camel@rousalka.okg> Le vendredi 02 mai 2008 ? 14:58 -0400, Colin Walters a ?crit : > Basically, Fedora is a lot more interested in improving our free > stack. It's been well known for years how to install the proprietary > JDK; yes, jpackage makes it a lot nicer for those people aware of the > system, but I think we should leave it up to jpackage rather than > putting it into Fedora. I don't think the jpackage developers are very interested in proprietary stuff either. JPackage is mostly about packaging the FLOSS Java universe, the proprietary bits are only there as requires, and get dropped when they have a working FLOSS replacement (and are generally speaking a PITA to manage in the meanwhile) -- 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 lesmikesell at gmail.com Fri May 2 19:16:01 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 02 May 2008 14:16:01 -0500 Subject: Multilib Middle-Ground In-Reply-To: References: <4817FF36.10305@redhat.com> <481A19BA.6090705@gmail.com> <604aa7910805011244q78338786y956500dd55649441@mail.gmail.com> <604aa7910805011549i47c6193bs177e57cea293dd75@mail.gmail.com> <481B3A70.6070509@gmail.com> <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> <481B5A10.9010308@gmail.com> <481B5CC3.3090806@redhat.com> <481B60DB.90202@gmail.com> Message-ID: <481B6871.5000101@gmail.com> Colin Walters wrote: > >> The almost-java versions included in fedora don't run most real-world java >> code. > > If we're talking about Fedora 8, yes, there are issues because the the > OpenJDK we ship is a snapshot of JDK 7. I'm talking about every version of fedora so far. We might consider shipping an > update which doesn't replace java-1.7.0-icedtea, but that people can > switch to with update-alternatives. > > But for Fedora 9, I don't think one can say "most" things won't run > with java-1.6.0-openjdk. I can say that OpenNMS won't currently work with a 1.6 version because it's developers have said so. >> And it is much more difficult than necessary to install a real java >> version. Just including a jpackage nosrc-style package to adjust Sun Java >> to fedora's peculiar needs would eliminate this complaint, although I really >> think it would have been better to stay compatible with jpackage.org and >> avoid any extra work. > > Basically, Fedora is a lot more interested in improving our free > stack. I don't understand what that has to do with making it difficult to install a compliant version. > It's been well known for years how to install the proprietary > JDK; Well known by? > yes, jpackage makes it a lot nicer for those people aware of the > system, but I think we should leave it up to jpackage rather than > putting it into Fedora. That would have been just fine, but there have been long intervals where jpackage has not had a suitable repo (and again, I don't see any reason that should even have needed to change across fedora versions since java code is pretty much independent of anything else) and in earlier conversations here I thought someone said the relationship was deliberately broken with portions moved into fedora packages and the rest ignored. -- Les Mikesell lesmikesell at gmail.com From walters at verbum.org Fri May 2 19:16:40 2008 From: walters at verbum.org (Colin Walters) Date: Fri, 2 May 2008 15:16:40 -0400 Subject: Multilib Middle-Ground In-Reply-To: <1209755408.6004.7.camel@rousalka.okg> References: <4817FF36.10305@redhat.com> <604aa7910805011549i47c6193bs177e57cea293dd75@mail.gmail.com> <481B3A70.6070509@gmail.com> <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> <481B5A10.9010308@gmail.com> <481B5CC3.3090806@redhat.com> <481B60DB.90202@gmail.com> <1209755408.6004.7.camel@rousalka.okg> Message-ID: 2008/5/2 Nicolas Mailhot : > I don't think the jpackage developers are very interested in proprietary > stuff either. Yeah, I understand; but jpackage also became the go-to place for unbreaking the proprietary JDK installs, which I don't think Fedora is very interested in doing in the core distro. From jspaleta at gmail.com Fri May 2 19:25:45 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 2 May 2008 11:25:45 -0800 Subject: Multilib Middle-Ground In-Reply-To: References: <4817FF36.10305@redhat.com> <604aa7910805011549i47c6193bs177e57cea293dd75@mail.gmail.com> <481B3A70.6070509@gmail.com> <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> <481B5A10.9010308@gmail.com> <481B5CC3.3090806@redhat.com> <481B60DB.90202@gmail.com> <1209755408.6004.7.camel@rousalka.okg> Message-ID: <604aa7910805021225w5fde6526n70f9d19d4c2773a2@mail.gmail.com> On Fri, May 2, 2008 at 11:16 AM, Colin Walters wrote: > Yeah, I understand; but jpackage also became the go-to place for > unbreaking the proprietary JDK installs, which I don't think Fedora is > very interested in doing in the core distro. Speaking as the physical manifestation of Fedora 'spirit'... I know I'm not interested in putting in hacks into our repository that smooth over the problems. I see the value in the nosrc implementation that jpackage has provided, but I'm not particularly interested in seeing those slip into Fedora's main repository. That being said, there's no reason we can't have an open dialog with vendors about packaging best practices so the packages they offer to Fedora users don't need nosrc hacks. The only long term fix lies with the vendors taking responsibility to work inside the packaging system and being willing to talk about what their problems are. -jef From pertusus at free.fr Fri May 2 19:29:57 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 2 May 2008 21:29:57 +0200 Subject: Multilib Middle-Ground In-Reply-To: <481B65DA.6010505@gmail.com> References: <604aa7910805010914n987c810g4591ff3065f8844b@mail.gmail.com> <4819FB60.5000606@gmail.com> <604aa7910805011020k4732d6cbv11ed7a813d9fa068@mail.gmail.com> <481A19BA.6090705@gmail.com> <604aa7910805011244q78338786y956500dd55649441@mail.gmail.com> <481A4871.50102@gmail.com> <20080502004139.GA1272043@hiwaay.net> <481B368F.8060107@gmail.com> <20080502172438.GA2649@free.fr> <481B65DA.6010505@gmail.com> Message-ID: <20080502192957.GE2649@free.fr> On Fri, May 02, 2008 at 02:04:58PM -0500, Les Mikesell wrote: >> >> And not to follow upstream changes? This is not good for fedora. > > Why? You have no qualms about trying to influence what proprietary vendors > do by not shipping things you don't like. Why not do the same where its > more likely to make a useful difference? If fedora doesn't use the latest upstream release it hurts Fedora, not upstream. (and I have absolutely no opinion about 'influencing what proprietary vendors do', it must be sommebody else who said that). >> I >> completely agree with you that incompatible ABI changes are hurting >> free software, but this should be fixed upstream, and not in linux >> distros. > > But as long as you keep shipping things without backwards compatibility you > not only hurt your existing users whose own code will break but you > encourage the practice. It's always possible to add new interfaces instead > of breaking the old ones if they weren't designed to be extensible. We cannot encourage or discourage upstream. We are downstream. Even RHEL don't care (unless I am wrong) about ABI compatibility between releases, it would be too much work. In fedora you can always do compat packages if you like. I would happily review them. I have always been opposed to the 'and the primary package maintainer is not against the idea' in http://fedoraproject.org/wiki/BrianPepple/DraftCompatPackages (though I agree with the remaining). So nothing is stopping you to provide old sonames in fedora, except for the amount of work (and maybe primary maintainers disagreeing, but I hope that it won't be a real issue). But backporting bugs from maintained releases to compat release unmaintained upstream and only maintained in distro is a lot of work. >> You could try to approach upstream projects that break ABI >> frequently and try to convince them to avoid breaking ABI if you want >> to, but fedora cannot do anything else than consuming what upstream >> produces. > > If you know something hurts, why keep doing it? Why not maintain stable > kernel and library versions for long periods with the current kernel and > differently-named experimental libs as alternative choices? After some > long interval of concurrent use and compatibility testing the > no-longer-expermental libs could replace the stable versions. It is possible to do the reverse, that is ship compat packages, it is even possible to ship old API. For example I maintain in parallel libnet and libnet10 for quite a long time now (both versions are unmaintained). I cannot do that for other libraries I maintain (notably libdap) it would mean too much work (in reality, I have to do it more or less for EPEL, but in that case somebody else commited to do the backports, since I won't do it). > I think that should depend on what upstream does. Fedora has a fast enough > cycle that waiting for the next release for an incompatible change wouldn't > kill anyone. I am personally in favor of that, that is, try to wait for rawhide to break ABI, except if there is a security issue in old lib, or a very problematic bug, and backporting is not easy. There has been disagreement in the past about that issue. I hope that having bodhi now reduces the amount of ABI breaking in updates. >> What do you propose instead? Not following upstream? > > Just not breaking anything that already works. If upstream does that, the > distribution has to make a choice between bleeding-edge code and hurting > its users. The code will still be there for the next release - and maybe > by then it will have fixed its backwards compatibility. I have never seen an upsteram breaking ABI reverting to a previous soname because ABI unbreaking happening later. In libdap there are frequent API/ABI breaking but I have no choice other than accepting these changes (between fedora releases) because dependent software always use the latest API. -- Pat From walters at verbum.org Fri May 2 19:33:59 2008 From: walters at verbum.org (Colin Walters) Date: Fri, 2 May 2008 15:33:59 -0400 Subject: Fedora and JPackage proprietary JDK shims Message-ID: On Fri, May 2, 2008 at 3:16 PM, Les Mikesell wrote: > > I can say that OpenNMS won't currently work with a 1.6 version because it's > developers have said so. So what you're really saying is Fedora doesn't support Java < 6 very well. I don't think anyone would disagree, but you have to understand it's not a very interesting problem; these projects should really be working to update for 6, regardless of Fedora or OpenJDK - Java 5 is in pure maintenance mode now. I'm sure there's a fair amount of software out there that doesn't work on Java 6, but it's not "most" by a long shot. > > It's been well known for years how to install the proprietary > > JDK; > > > > Well known by? Really...it's in a lot of FAQs, etc. > That would have been just fine, but there have been long intervals where > jpackage has not had a suitable repo (and again, I don't see any reason that > should even have needed to change across fedora versions since java code is > pretty much independent of anything else) Perhaps; I've personally only used the jpackage shims on RHEL (which is much closer to jpackage's target audience). > and in earlier conversations here > I thought someone said the relationship was deliberately broken with > portions moved into fedora packages and the rest ignored. If Fedora and JPackage were on Facebook, the relationship status would be "It's complicated". But we are cooperating on many levels, and I would certainly not call it broken. Bottom line - should Fedora ship the proprietary JDK shim? I don't think it's worth the user confusion over just telling people to go to JPackage, but if someone stepped up, did the work, and submitted it and was going to maintain/own it, it might happen. From smooge at gmail.com Fri May 2 19:44:04 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Fri, 2 May 2008 13:44:04 -0600 Subject: Fedora and JPackage proprietary JDK shims In-Reply-To: References: Message-ID: <80d7e4090805021244m5f1882fbwfea1a240d3bf56a5@mail.gmail.com> On Fri, May 2, 2008 at 1:33 PM, Colin Walters wrote: > On Fri, May 2, 2008 at 3:16 PM, Les Mikesell wrote: > > > > I can say that OpenNMS won't currently work with a 1.6 version because it's > > developers have said so. > > So what you're really saying is Fedora doesn't support Java < 6 very > well. I don't think anyone would disagree, but you have to understand > it's not a very interesting problem; these projects should really be > working to update for 6, regardless of Fedora or OpenJDK - Java 5 is > in pure maintenance mode now. > > I'm sure there's a fair amount of software out there that doesn't work > on Java 6, but it's not "most" by a long shot. > It depends on the sphere of software... 90% of our business software only works on 1.4.2 and the other 10% only works on 1.5. And so does all of the java apps the company programmers have written to work with the closed source stuff. When we asked when they would support 1.6.. the word was they weren't.. they would go to 1.7 when it was released or .NET because Java was just not 'stable' enough for them. While thats all closed source.. the mindset affects others who work on Java in the open. > > > It's been well known for years how to install the proprietary > > > JDK; > > > > > > > Well known by? > > Really...it's in a lot of FAQs, etc. > Agreed. > > That would have been just fine, but there have been long intervals where > > jpackage has not had a suitable repo (and again, I don't see any reason that > > should even have needed to change across fedora versions since java code is > > pretty much independent of anything else) > > Perhaps; I've personally only used the jpackage shims on RHEL (which > is much closer to jpackage's target audience). > > > and in earlier conversations here > > I thought someone said the relationship was deliberately broken with > > portions moved into fedora packages and the rest ignored. > > If Fedora and JPackage were on Facebook, the relationship status would > be "It's complicated". But we are cooperating on many levels, and I > would certainly not call it broken. > Well better than "Incestous.. keep clotting drugs close by." > Bottom line - should Fedora ship the proprietary JDK shim? I don't > think it's worth the user confusion over just telling people to go to > JPackage, but if someone stepped up, did the work, and submitted it > and was going to maintain/own it, it might happen. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From lesmikesell at gmail.com Fri May 2 19:46:49 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 02 May 2008 14:46:49 -0500 Subject: Multilib Middle-Ground In-Reply-To: <1209755408.6004.7.camel@rousalka.okg> References: <4817FF36.10305@redhat.com> <481A19BA.6090705@gmail.com> <604aa7910805011244q78338786y956500dd55649441@mail.gmail.com> <604aa7910805011549i47c6193bs177e57cea293dd75@mail.gmail.com> <481B3A70.6070509@gmail.com> <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> <481B5A10.9010308@gmail.com> <481B5CC3.3090806@redhat.com> <481B60DB.90202@gmail.com> <1209755408.6004.7.camel@rousalka.okg> Message-ID: <481B6FA9.7000300@gmail.com> Nicolas Mailhot wrote: > >> Basically, Fedora is a lot more interested in improving our free >> stack. It's been well known for years how to install the proprietary >> JDK; yes, jpackage makes it a lot nicer for those people aware of the >> system, but I think we should leave it up to jpackage rather than >> putting it into Fedora. > > I don't think the jpackage developers are very interested in proprietary > stuff either. If by proprietary stuff you mean the standard-compliant version from Sun, anyone can grab their own copy of the binary. The problem is adapting it to fedora's weirdness regarding other package dependencies and multi-symlinked paths. > JPackage is mostly about packaging the FLOSS Java > universe, the proprietary bits are only there as requires, The proprietary bits aren't there, just a sane way to fix up the fedora specific package/layout requirements. Some other distributions have included the Sun binary now that it is possible. There are reasons not to do that. I just can't think of any reasons not to supply a sane means to fix fedora when you get your own binary, though. and get > dropped when they have a working FLOSS replacement Let's put off the discussion of replacements until there is one that meets the compliance tests. >(and are generally > speaking a PITA to manage in the meanwhile) The point is that for years fedora has had a scheme of package requirements and no standard-compliant JVM that provided them. And it has a strange symlinked path scheme that needs to be fixed when installing a standard JVM. -- Les Mikesell lesmikesell at gmail.com From lesmikesell at gmail.com Fri May 2 19:52:59 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 02 May 2008 14:52:59 -0500 Subject: Multilib Middle-Ground In-Reply-To: <604aa7910805021225w5fde6526n70f9d19d4c2773a2@mail.gmail.com> References: <4817FF36.10305@redhat.com> <604aa7910805011549i47c6193bs177e57cea293dd75@mail.gmail.com> <481B3A70.6070509@gmail.com> <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> <481B5A10.9010308@gmail.com> <481B5CC3.3090806@redhat.com> <481B60DB.90202@gmail.com> <1209755408.6004.7.camel@rousalka.okg> <604aa7910805021225w5fde6526n70f9d19d4c2773a2@mail.gmail.com> Message-ID: <481B711B.30200@gmail.com> Jeff Spaleta wrote: > On Fri, May 2, 2008 at 11:16 AM, Colin Walters wrote: >> Yeah, I understand; but jpackage also became the go-to place for >> unbreaking the proprietary JDK installs, which I don't think Fedora is >> very interested in doing in the core distro. > > > Speaking as the physical manifestation of Fedora 'spirit'... I know > I'm not interested in putting in hacks into our repository that smooth > over the problems. I see the value in the nosrc implementation that > jpackage has provided, but I'm not particularly interested in seeing > those slip into Fedora's main repository. It just seems very wrong to include packages with dependencies on a jdk with no way to make a specification-compliant jdk provide them. > That being said, there's no > reason we can't have an open dialog with vendors about packaging best > practices so the packages they offer to Fedora users don't need nosrc > hacks. The only long term fix lies with the vendors taking > responsibility to work inside the packaging system and being willing > to talk about what their problems are. Or arrange the distribution so it doesn't vary from release to release and need version-specific hacks. In which case anything jpackage.org had ever done would still work. -- Les Mikesell lesmikesell at gmail.com From surenkarapetyan at gmail.com Fri May 2 20:09:05 2008 From: surenkarapetyan at gmail.com (Suren Karapetyan) Date: Sat, 03 May 2008 01:09:05 +0500 Subject: Multilib Middle-Ground In-Reply-To: <481B65DA.6010505@gmail.com> References: <4819C1EF.6050009@gmail.com> <604aa7910805010914n987c810g4591ff3065f8844b@mail.gmail.com> <4819FB60.5000606@gmail.com> <604aa7910805011020k4732d6cbv11ed7a813d9fa068@mail.gmail.com> <481A19BA.6090705@gmail.com> <604aa7910805011244q78338786y956500dd55649441@mail.gmail.com> <481A4871.50102@gmail.com> <20080502004139.GA1272043@hiwaay.net> <481B368F.8060107@gmail.com> <20080502172438.GA2649@free.fr> <481B65DA.6010505@gmail.com> Message-ID: <481B74E1.7090708@gmail.com> Les Mikesell wrote: > Patrice Dumas wrote: >> >>>> A big compatibility issue is shared library sonames. For >>>> standards to emerge, you'd have to define a complete set of compatible >>>> sonames. >>> Yes. Which would amount to each distribution doing less changes. >> >> And not to follow upstream changes? This is not good for fedora. > > Why? You have no qualms about trying to influence what proprietary > vendors do by not shipping things you don't like. Why not do the same > where its more likely to make a useful difference? > >> I >> completely agree with you that incompatible ABI changes are hurting >> free software, but this should be fixed upstream, and not in linux >> distros. > > But as long as you keep shipping things without backwards > compatibility you not only hurt your existing users whose own code > will break but you encourage the practice. It's always possible to > add new interfaces instead of breaking the old ones if they weren't > designed to be extensible. >> You could try to approach upstream projects that break ABI >> frequently and try to convince them to avoid breaking ABI if you want >> to, but fedora cannot do anything else than consuming what upstream >> produces. > > If you know something hurts, why keep doing it? Why not maintain > stable kernel and library versions for long periods with the current > kernel and differently-named experimental libs as alternative > choices? After some long interval of concurrent use and compatibility > testing the no-longer-expermental libs could replace the stable versions. Cause there is no good definition for "long periods". So if some arguments make Fedora to change the "old things" only for a new release the same arguments will also tell to preserve compatibility from release to release. And that's a bad way to go, cause compatibility issues made Microsoft keep "compatible" (read: old, weak, dumb) LM hashes from Win 3.1 till Vista (http://en.wikipedia.org/wiki/LM_hash). And Microsoft did it cause it was forced by it's partners, ISVs. Even RedHat had to keep old LinuxThreads (old, bad threading library) cause it needed to be compatible. One of the most important things I (and maybe many people) like about Free Software and Fedora is that You aren't dependent on ISVs. If I wanted an OS which is compatible from version to version, I would be using Windows. > >>> No, it would mean maintaining that standard above with required >>> backward compatibility. You'd only have update libs to match the >>> newest app rev you want to run. >> >> This is not that different than what is done in fedora. Of course we may >> wait for an application that use new features of an ABI modified >> application to be needed, but it wouldn't be very different from what we >> do now. You could try to push the idea that within a fedora version ABI >> compatibility should be kept if possible, but between fedora versions, >> I think that it is better to follow upstream. > > I think that should depend on what upstream does. Fedora has a fast > enough cycle that waiting for the next release for an incompatible > change wouldn't kill anyone. Well this is mostly true, but we would soon get people who would say "Why does Cool_app_X work with Fedora 9 but doesn't with Fedora 10? Fedora 10 is OBSOLETE/BAD/EVIL. If You don't make Fedora RUN Cool_app_X I'm gonna switch to Windows." > >>> Just because some developer writes some incompatible code doesn't >>> mean distributions have to ship it. >> >> What do you propose instead? Not following upstream? > > Just not breaking anything that already works. If upstream does that, > the distribution has to make a choice between bleeding-edge code and > hurting its users. The code will still be there for the next release > - and maybe by then it will have fixed its backwards compatibility. > After breaking backwards compatibility nobody usually cares about fixing it. From lesmikesell at gmail.com Fri May 2 20:10:23 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 02 May 2008 15:10:23 -0500 Subject: Fedora and JPackage proprietary JDK shims In-Reply-To: References: Message-ID: <481B752F.5040908@gmail.com> Colin Walters wrote: > On Fri, May 2, 2008 at 3:16 PM, Les Mikesell wrote: >> I can say that OpenNMS won't currently work with a 1.6 version because it's >> developers have said so. > > So what you're really saying is Fedora doesn't support Java < 6 very > well. Yes, as in what pretty much all existing large projects use. I actually haven't investigated this much beyond OpenNMS and would be happy to hear otherwise about opengrok, alfresco, openfire, spark etc. > I don't think anyone would disagree, but you have to understand > it's not a very interesting problem; these projects should really be > working to update for 6, regardless of Fedora or OpenJDK - Java 5 is > in pure maintenance mode now. Maintenance mode is what developers using things like. No surprises. > I'm sure there's a fair amount of software out there that doesn't work > on Java 6, but it's not "most" by a long shot. Do you have some examples of large and useful things like those above? I suppose jboss should be the canonical example. >>> It's been well known for years how to install the proprietary >>> JDK; >>> >> Well known by? > > Really...it's in a lot of FAQs, etc. Are any of them fedora-hosted where a user would likely look for this information? >> That would have been just fine, but there have been long intervals where >> jpackage has not had a suitable repo (and again, I don't see any reason that >> should even have needed to change across fedora versions since java code is >> pretty much independent of anything else) > > Perhaps; I've personally only used the jpackage shims on RHEL (which > is much closer to jpackage's target audience). But EL5 wasn't supported for long after its introduction either. >> and in earlier conversations here >> I thought someone said the relationship was deliberately broken with >> portions moved into fedora packages and the rest ignored. > > If Fedora and JPackage were on Facebook, the relationship status would > be "It's complicated". But we are cooperating on many levels, and I > would certainly not call it broken. Is this changing? I do see some stuff for f7/8 that I didn't think was there before. > Bottom line - should Fedora ship the proprietary JDK shim? I don't > think it's worth the user confusion over just telling people to go to > JPackage, but if someone stepped up, did the work, and submitted it > and was going to maintain/own it, it might happen. If jpackage has a suitable documented repo, that's fine. I just couldn't find any for fc7/8 or rhel5 for a year or so. -- Les Mikesell lesmiksell at gmail.com From roland at redhat.com Fri May 2 20:21:55 2008 From: roland at redhat.com (Roland McGrath) Date: Fri, 2 May 2008 13:21:55 -0700 (PDT) Subject: autofs no longer in default install Message-ID: <20080502202155.DA61F26FA07@magilla.localdomain> In past versions, I've always found autofs was installed by default, so /net/foo/bar works out of the box on the first boot of a new install. I just installed f9 (yesterday's rawhide) with a completely vanilla x86_64 install (minimal set of clicks, default package sets) and it was not there. What gives? Thanks, Roland From sundaram at fedoraproject.org Fri May 2 20:23:28 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 03 May 2008 01:53:28 +0530 Subject: Fedora and JPackage proprietary JDK shims In-Reply-To: <481B752F.5040908@gmail.com> References: <481B752F.5040908@gmail.com> Message-ID: <481B7840.5020304@fedoraproject.org> Les Mikesell wrote: > Colin Walters wrote: >> On Fri, May 2, 2008 at 3:16 PM, Les Mikesell >> wrote: >>> I can say that OpenNMS won't currently work with a 1.6 version >>> because it's >>> developers have said so. >> >> So what you're really saying is Fedora doesn't support Java < 6 very >> well. > > Yes, as in what pretty much all existing large projects use. I actually > haven't investigated this much beyond OpenNMS and would be happy to hear > otherwise about opengrok, alfresco, openfire, spark etc. Most of them do. Opengrok is in the Fedora repository. Alfresco claims to support Java 1.5 and above. I am sure you can do your own research for the apps you really need. Rahul From jason.corley at gmail.com Fri May 2 20:23:35 2008 From: jason.corley at gmail.com (Jason Corley) Date: Fri, 2 May 2008 16:23:35 -0400 Subject: Multilib Middle-Ground Message-ID: <3118d8de0805021323x64467a8fg911239df53a5ff0e@mail.gmail.com> > Rahul Sundaram wrote: >> Les Mikesell wrote: >>> Paul Howarth wrote: >>> Stripping of pathname-based and package-name based dependencies I can understand, but not the library deps. >> Are they the same across all RPM based systems? > Yes, they are and the third party packages have no excuse if they are deliberately disabling the automatic > dependency mechanisms. Really? No excuse at all? http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/pkgdepend.html Granted the VMware example is not LSB conformant, but the LSB Core spec specifically says: "Packages shall not depend on other system-provided dependencies." Which brings up the following question: Does anyone in Fedora-land actually work with the LSB? I see the redhat-lsb package in the distro which would seem to imply conformance, but I also see a lot of opinions like the above expressed as hard fact that clearly fly in the face of what the LSB mandates. Jason From lesmikesell at gmail.com Fri May 2 20:29:59 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 02 May 2008 15:29:59 -0500 Subject: Multilib Middle-Ground In-Reply-To: <604aa7910805021124s1997ad8erec66f2522e413bd8@mail.gmail.com> References: <4817FF36.10305@redhat.com> <4819FB60.5000606@gmail.com> <604aa7910805011020k4732d6cbv11ed7a813d9fa068@mail.gmail.com> <481A19BA.6090705@gmail.com> <604aa7910805011244q78338786y956500dd55649441@mail.gmail.com> <604aa7910805011549i47c6193bs177e57cea293dd75@mail.gmail.com> <481B3A70.6070509@gmail.com> <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> <481B5A10.9010308@gmail.com> <604aa7910805021124s1997ad8erec66f2522e413bd8@mail.gmail.com> Message-ID: <481B79C7.7000404@gmail.com> Jeff Spaleta wrote: > On Fri, May 2, 2008 at 10:14 AM, Les Mikesell wrote: >> This particular thread is about a specific change proposed for fedora - >> which if made will make it more complicated to install VMWare and probably >> many other things. Others have been about how other distributions make >> things easier for their users. Or how it is bad that fedora no longer works >> with japackage.org. By nature, those things are fedora-specific. > > There no 'standard' by which to measure the value of change. If all > distros are doing things differently you can't single us out for > making a change that breaks cross-distro compatibility that doesn't > already exist. The only thing you've pointed to so far is LSB... are > you attempting to claim we are breaking LSB with this change? No, just that LSB is currently the worst of all worlds. That is, if you've moved anything to comply with it you've broken your own backwards compatibility and not really gained anything because it doesn't go far enough to provide the real value of portable and predictable installs across versions. Until it dictates portability it is just a moving target of arbitrary locations. > Things > are already incompatible.. in a non-standardized way. By putting your > foot down and demanding that we stop our own process to evolve you > aren't solving the underlying problem. Agreed - it's not just your problem. > Stagnation is not > standardization. They aren't opposing concepts. It is always possible to maintain standards while adding new ones. > No matter how we get their...cross-distro > standardization is going to involve change in how each distro > currently does things... so change is unavoidable no matter what > happens. You are arguing for the wrong thing. Perhaps, but fedora is one of the worst distributions to keep anything working consistently for years because of its rapid internal changes. If you can't use something consistent as the example for a standard, how is it ever going to improve? -- Les Mikesell lesmikesell at gmail.com From notting at redhat.com Fri May 2 20:31:05 2008 From: notting at redhat.com (Bill Nottingham) Date: Fri, 2 May 2008 16:31:05 -0400 Subject: autofs no longer in default install In-Reply-To: <20080502202155.DA61F26FA07@magilla.localdomain> References: <20080502202155.DA61F26FA07@magilla.localdomain> Message-ID: <20080502203105.GB23239@nostromo.devel.redhat.com> Roland McGrath (roland at redhat.com) said: > In past versions, I've always found autofs was installed by default, so > /net/foo/bar works out of the box on the first boot of a new install. I > just installed f9 (yesterday's rawhide) with a completely vanilla x86_64 > install (minimal set of clicks, default package sets) and it was not there. > What gives? https://bugzilla.redhat.com/show_bug.cgi?id=427223 Bill From jason.corley at gmail.com Fri May 2 20:32:00 2008 From: jason.corley at gmail.com (Jason Corley) Date: Fri, 2 May 2008 16:32:00 -0400 Subject: Fedora and JPackage proprietary JDK shims Message-ID: <3118d8de0805021332p53bb68eascab41bb0c49f1286@mail.gmail.com> > Colin Walters wrote: > Perhaps; I've personally only used the jpackage shims on RHEL (which > is much closer to jpackage's target audience). At JPackage we support as many distros as we can that we have users and developers for. To say we focus on RHEL (or any distro) is incorrect as that absolutely is not the target of the project. Nor is exclusive support for Fedora, OpenSuSE, or Mandriva. All of those added together (and then some more thrown in) are our focus. > If Fedora and JPackage were on Facebook, the relationship status would > be "It's complicated". JPackage is on Facebook. ;-) http://www.facebook.com/group.php?gid=7643070828 Jason From sundaram at fedoraproject.org Fri May 2 20:33:14 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 03 May 2008 02:03:14 +0530 Subject: Multilib Middle-Ground In-Reply-To: <3118d8de0805021323x64467a8fg911239df53a5ff0e@mail.gmail.com> References: <3118d8de0805021323x64467a8fg911239df53a5ff0e@mail.gmail.com> Message-ID: <481B7A8A.4010802@fedoraproject.org> Jason Corley wrote: > Really? No excuse at all? > http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/pkgdepend.html > Granted the VMware example is not LSB conformant, but the LSB Core > spec specifically says: > "Packages shall not depend on other system-provided dependencies." Tell me again about insane specifications. There is a good reason pretty much no ISV follows them. VMWare cannot possibly use LSB as a excuse if they aren't certified and they can't be because LSB hasn't standardized a number of dependencies that they require. See a cycle? > Which brings up the following question: Does anyone in Fedora-land > actually work with the LSB? I see the redhat-lsb package in the > distro which would seem to imply conformance, but I also see a lot of > opinions like the above expressed as hard fact that clearly fly in the > face of what the LSB mandates. There is no effort to afaik. Rahul From jwboyer at gmail.com Fri May 2 20:33:14 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 02 May 2008 15:33:14 -0500 Subject: autofs no longer in default install In-Reply-To: <20080502203105.GB23239@nostromo.devel.redhat.com> References: <20080502202155.DA61F26FA07@magilla.localdomain> <20080502203105.GB23239@nostromo.devel.redhat.com> Message-ID: <1209760395.26179.7.camel@vader.jdub.homelinux.org> On Fri, 2008-05-02 at 16:31 -0400, Bill Nottingham wrote: > Roland McGrath (roland at redhat.com) said: > > In past versions, I've always found autofs was installed by default, so > > /net/foo/bar works out of the box on the first boot of a new install. I > > just installed f9 (yesterday's rawhide) with a completely vanilla x86_64 > > install (minimal set of clicks, default package sets) and it was not there. > > What gives? > > https://bugzilla.redhat.com/show_bug.cgi?id=427223 -ENOACCESS. Summarize for mortals please. josh From jspaleta at gmail.com Fri May 2 20:47:21 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 2 May 2008 12:47:21 -0800 Subject: Multilib Middle-Ground In-Reply-To: <481B79C7.7000404@gmail.com> References: <4817FF36.10305@redhat.com> <481A19BA.6090705@gmail.com> <604aa7910805011244q78338786y956500dd55649441@mail.gmail.com> <604aa7910805011549i47c6193bs177e57cea293dd75@mail.gmail.com> <481B3A70.6070509@gmail.com> <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> <481B5A10.9010308@gmail.com> <604aa7910805021124s1997ad8erec66f2522e413bd8@mail.gmail.com> <481B79C7.7000404@gmail.com> Message-ID: <604aa7910805021347l5e59ff9cj40146b9f1dd0672@mail.gmail.com> On Fri, May 2, 2008 at 12:29 PM, Les Mikesell wrote: > Perhaps, but fedora is one of the worst distributions to keep anything > working consistently for years because of its rapid internal changes. If you > can't use something consistent as the example for a standard, how is it ever > going to improve? Are you arguing for backwards compatibility inside Fedora.. or arguing cross-compatibility across distributions? Are are you just asking for maximal compatibility for everything? Fedora isn't going to solve the cross-distribution problem on its own. Fedora isn't going to even solve the backwards compatibility problem on its own. And its certaintly not going to solve the multi-arch compatibility problem on its own. This is only going to get solved if someone who cares gets all the stakeholders talking in a constructive forward looking conversation. You care...but I very much doubt you have the necessary skills to make a constructive dialog happen. We are only going to make headway on any of this by getting the distributions and upstream projects together and figuring out what needs and can be standardized. Just pointing to F7 or F8 or F5 as the de-facto standard in the space isn't useful. Because unless upstream developers care about backwards compatibility..we can't make them. Unless other distros care about cross-distro compatibility we can't make them. Making backwards and cross compatibility work in a meaningful way is not something we can impose on the open ecosystem. All we can do internally is to have a policy with regard to backwards compatibilty...and we do. We have a process by which compat packaging crap can be generated. But if upstream developers aren't using the symbol versioning that is needed to make it work... we can't make them use it. Here's an exercise for you. Attempt to figure out which upstream library projects care about doing backwards compatibility and are doing the necessary things so we can make use of symbol versioning and other technical measures to use in our packaging depchains. That is the starting point for a discussion for where backwards compatibility stands in the open source ecosystem. If enough upstream projects are not doing what is necessary to make backwards compatibility easy to package, then there's no point in attempting to fix the problem at the distribution level. If enough individual upstream projects are doing what it takes, then we can attempt to define a set of libraries inside Fedora which form a 'framework' that users can more readily rely on to behave when targetting their own in house code against. But unless individual upstream projects want backwards compatibility to matter...its not going to matter. -jef From nicolas.mailhot at laposte.net Fri May 2 20:47:14 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 02 May 2008 22:47:14 +0200 Subject: Multilib Middle-Ground In-Reply-To: <481B6FA9.7000300@gmail.com> References: <4817FF36.10305@redhat.com> <481A19BA.6090705@gmail.com> <604aa7910805011244q78338786y956500dd55649441@mail.gmail.com> <604aa7910805011549i47c6193bs177e57cea293dd75@mail.gmail.com> <481B3A70.6070509@gmail.com> <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> <481B5A10.9010308@gmail.com> <481B5CC3.3090806@redhat.com> <481B60DB.90202@gmail.com> <1209755408.6004.7.camel@rousalka.okg> <481B6FA9.7000300@gmail.com> Message-ID: <1209761234.6848.19.camel@rousalka.okg> Le vendredi 02 mai 2008 ? 14:46 -0500, Les Mikesell a ?crit : > The point is that for years fedora has had a scheme of package > requirements and no standard-compliant JVM that provided them. And it > has a strange symlinked path scheme that needs to be fixed when > installing a standard JVM. ROTFL SUN couldn't even keep a stable JVM naming, let alone a standard path, or agree with the other proprietary guys on common conventions, so don't invoque a "standard-compliant JVM" when this thing never existed. An archive of all the SUN, IBM and BEA jvm releases is a baroque history of inconsistent paths and name changes no sane third-party package could ever depend on (and BTW paths that contradicted existing standards like the FHS). What ISVs depend on is a fixed version that uses SUN's conventions-of-the-day, which are anything but standard. SUN's "standard" is JSR 277. It will happen in Java 1.7. Because of market pressure (.Net, OSGi and Maven). Every Java antedating 1.7 is a huge pile of paths, names and dependencies quirks, that were used to justify the fat sums Enterprises paid SUN and its partners to smooth out Java deployment. Why do you think Java has little life outside J2EE servers? Because the J2EE server guys take care of the Java environment setup the "standard" JVM makes such a mess of. -- 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 j2solutions.net Thu May 1 20:47:57 2008 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 01 May 2008 16:47:57 -0400 Subject: autofs no longer in default install In-Reply-To: <1209760395.26179.7.camel@vader.jdub.homelinux.org> References: <20080502202155.DA61F26FA07@magilla.localdomain> <20080502203105.GB23239@nostromo.devel.redhat.com> <1209760395.26179.7.camel@vader.jdub.homelinux.org> Message-ID: <1209674877.29415.11.camel@localhost.localdomain> On Fri, 2008-05-02 at 15:33 -0500, Josh Boyer wrote: > On Fri, 2008-05-02 at 16:31 -0400, Bill Nottingham wrote: > > Roland McGrath (roland at redhat.com) said: > > > In past versions, I've always found autofs was installed by default, so > > > /net/foo/bar works out of the box on the first boot of a new install. I > > > just installed f9 (yesterday's rawhide) with a completely vanilla x86_64 > > > install (minimal set of clicks, default package sets) and it was not there. > > > What gives? > > > > https://bugzilla.redhat.com/show_bug.cgi?id=427223 > > -ENOACCESS. Summarize for mortals please. > > josh > I couldn't clear all the flags, but I made it so that Fedora contributors could see it. -- Jesse Keating RHCE (jkeating.livejournal.com) Fedora Project (fedoraproject.org/wiki/JesseKeating) 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: 197 bytes Desc: This is a digitally signed message part URL: From roland at redhat.com Fri May 2 20:54:51 2008 From: roland at redhat.com (Roland McGrath) Date: Fri, 2 May 2008 13:54:51 -0700 (PDT) Subject: autofs no longer in default install In-Reply-To: Bill Nottingham's message of Friday, 2 May 2008 16:31:05 -0400 <20080502203105.GB23239@nostromo.devel.redhat.com> References: <20080502202155.DA61F26FA07@magilla.localdomain> <20080502203105.GB23239@nostromo.devel.redhat.com> Message-ID: <20080502205451.F225D26FA07@magilla.localdomain> Is it in the release notes? It can be listed under "gratuitous major aggravations". I guess there isn't a way without a million extra clicks to ask for it at install time. Another five magic commands to type after every new install before anything works right. Joy oh joy. From jkeating at j2solutions.net Thu May 1 21:00:51 2008 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 01 May 2008 17:00:51 -0400 Subject: autofs no longer in default install In-Reply-To: <20080502205451.F225D26FA07@magilla.localdomain> References: <20080502202155.DA61F26FA07@magilla.localdomain> <20080502203105.GB23239@nostromo.devel.redhat.com> <20080502205451.F225D26FA07@magilla.localdomain> Message-ID: <1209675651.29415.13.camel@localhost.localdomain> On Fri, 2008-05-02 at 13:54 -0700, Roland McGrath wrote: > Is it in the release notes? It can be listed under "gratuitous major > aggravations". I guess there isn't a way without a million extra clicks to > ask for it at install time. Another five magic commands to type after > every new install before anything works right. Joy oh joy. Perhaps the default Fedora install isn't really designed for your use case. -- Jesse Keating RHCE (jkeating.livejournal.com) Fedora Project (fedoraproject.org/wiki/JesseKeating) 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: 197 bytes Desc: This is a digitally signed message part URL: From jspaleta at gmail.com Fri May 2 21:06:56 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 2 May 2008 13:06:56 -0800 Subject: autofs no longer in default install In-Reply-To: <1209675651.29415.13.camel@localhost.localdomain> References: <20080502202155.DA61F26FA07@magilla.localdomain> <20080502203105.GB23239@nostromo.devel.redhat.com> <20080502205451.F225D26FA07@magilla.localdomain> <1209675651.29415.13.camel@localhost.localdomain> Message-ID: <604aa7910805021406q5f9b3e7lc6dec30da2256e73@mail.gmail.com> 2008/5/1 Jesse Keating : > Perhaps the default Fedora install isn't really designed for your use > case. Man i really wish we had a collection of pre-cooked kickstart files aimed at specific use case. I have this gut feeling that if people with similar server needs got together they could agree on a small finite set of kickstart offerings that helped several easily defined setups. -jef From lesmikesell at gmail.com Fri May 2 21:34:01 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 02 May 2008 16:34:01 -0500 Subject: Multilib Middle-Ground In-Reply-To: <604aa7910805021347l5e59ff9cj40146b9f1dd0672@mail.gmail.com> References: <4817FF36.10305@redhat.com> <481A19BA.6090705@gmail.com> <604aa7910805011244q78338786y956500dd55649441@mail.gmail.com> <604aa7910805011549i47c6193bs177e57cea293dd75@mail.gmail.com> <481B3A70.6070509@gmail.com> <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> <481B5A10.9010308@gmail.com> <604aa7910805021124s1997ad8erec66f2522e413bd8@mail.gmail.com> <481B79C7.7000404@gmail.com> <604aa7910805021347l5e59ff9cj40146b9f1dd0672@mail.gmail.com> Message-ID: <481B88C9.7030707@gmail.com> Jeff Spaleta wrote: > >> Perhaps, but fedora is one of the worst distributions to keep anything >> working consistently for years because of its rapid internal changes. If you >> can't use something consistent as the example for a standard, how is it ever >> going to improve? > > Are you arguing for backwards compatibility inside Fedora.. or arguing > cross-compatibility across distributions? Are are you just asking for > maximal compatibility for everything? Yes, all of the above - but it has to start somewhere. One of the reasons I've liked unix-like systems for 20+ years is that even though they misspelled the system call version of create, they never improved it by fixing the spelling and breaking everyone's subsequent work. But there are any number of changes of that nature that happen in linux distributions. > Fedora isn't going to solve the cross-distribution problem on its own. > Fedora isn't going to even solve the backwards compatibility problem > on its own. And its certaintly not going to solve the multi-arch > compatibility problem on its own. This is only going to get solved if > someone who cares gets all the stakeholders talking in a constructive > forward looking conversation. You care...but I very much doubt you > have the necessary skills to make a constructive dialog happen. No, I have some experience with things that have broken, but that's all. > We are only going to make headway on any of this by getting the > distributions and upstream projects together and figuring out what > needs and can be standardized. Is there even a space where any of this is documented? Or regression tests for existing library interfaces - or the kernel? > Making backwards and cross compatibility work in a > meaningful way is not something we can impose on the open ecosystem. You can't impose it but maybe it would help to point out regressions and give people a longer choice about upgrading. > All we can do internally is to have a policy with regard to backwards > compatibilty...and we do. We have a process by which compat packaging > crap can be generated. I'd describe this the other way around, with the thing that has regressions that require compatibility help as the crap, not the part that actually keeps things working. > Here's an exercise for you. Attempt to figure out which upstream > library projects care about doing backwards compatibility and are > doing the necessary things so we can make use of symbol versioning and > other technical measures to use in our packaging depchains. That is > the starting point for a discussion for where backwards compatibility > stands in the open source ecosystem. Can't you just always provide at least 2 versioned libraries? One essentially equivalent to the latest released RHEL or Centos version(s) and the other whatever flavor is current? And unless apps need something new, build them against the stable version. > If enough upstream projects are > not doing what is necessary to make backwards compatibility easy to > package, then there's no point in attempting to fix the problem at the > distribution level. If enough individual upstream projects are doing > what it takes, then we can attempt to define a set of libraries inside > Fedora which form a 'framework' that users can more readily rely on to > behave when targetting their own in house code against. > > But unless individual upstream projects want backwards compatibility > to matter...its not going to matter. I'd like to think of distributions as having some editorial control over what they ship. If someone writes crap you don't have to publish it. Or at least overlap old/new versions for a complete version run. -- Les Mikesell lesmikesell at gmail.com From jspaleta at gmail.com Fri May 2 21:47:09 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 2 May 2008 13:47:09 -0800 Subject: Multilib Middle-Ground In-Reply-To: <481B88C9.7030707@gmail.com> References: <4817FF36.10305@redhat.com> <604aa7910805011549i47c6193bs177e57cea293dd75@mail.gmail.com> <481B3A70.6070509@gmail.com> <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> <481B5A10.9010308@gmail.com> <604aa7910805021124s1997ad8erec66f2522e413bd8@mail.gmail.com> <481B79C7.7000404@gmail.com> <604aa7910805021347l5e59ff9cj40146b9f1dd0672@mail.gmail.com> <481B88C9.7030707@gmail.com> Message-ID: <604aa7910805021447w417a7884u23c887e84389589d@mail.gmail.com> On Fri, May 2, 2008 at 1:34 PM, Les Mikesell wrote: > I'd like to think of distributions as having some editorial control over > what they ship. If someone writes crap you don't have to publish it. Or at > least overlap old/new versions for a complete version run. And a lot of the software in the open ecosystem is under heavy development and do not need the backwards compatibility that you are expressing a need for for your in-house code. If we used editoral control in an uninformed fashion to dictate the level of stagnation you require..then we are most likely killing our ability to move the open source stack forward aggressive...which I'll remind you is the primary goal of this endeavor. Can we make space for your needs? Maybe. But you or someone else who also cares deeply about this level of backwards-compatibility will have to do the work necessary to outline the roadmap. I've laid out exactly what I think the starting point would be for the process of defining a development framework concept to be used inside the Fedora project space. But until we have a best-effort assessment as to which upstream libraries can be relied on to do deal with backwards compatibility in a mature way, we don't have a place to begin towards making substantial headway. Everything you want done..requires additional manpower and effort. And unless you're prepared to dig in and do some of the work...as the person who cares deeply about this...none of its going to get done. -jef From lesmikesell at gmail.com Fri May 2 21:47:58 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 02 May 2008 16:47:58 -0500 Subject: Multilib Middle-Ground In-Reply-To: <1209761234.6848.19.camel@rousalka.okg> References: <4817FF36.10305@redhat.com> <481A19BA.6090705@gmail.com> <604aa7910805011244q78338786y956500dd55649441@mail.gmail.com> <604aa7910805011549i47c6193bs177e57cea293dd75@mail.gmail.com> <481B3A70.6070509@gmail.com> <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> <481B5A10.9010308@gmail.com> <481B5CC3.3090806@redhat.com> <481B60DB.90202@gmail.com> <1209755408.6004.7.camel@rousalka.okg> <481B6FA9.7000300@gmail.com> <1209761234.6848.19.camel@rousalka.okg> Message-ID: <481B8C0E.5070800@gmail.com> Nicolas Mailhot wrote: > >> The point is that for years fedora has had a scheme of package >> requirements and no standard-compliant JVM that provided them. And it >> has a strange symlinked path scheme that needs to be fixed when >> installing a standard JVM. > > ROTFL SUN couldn't even keep a stable JVM naming, let alone a standard > path, or agree with the other proprietary guys on common conventions, so > don't invoque a "standard-compliant JVM" when this thing never existed. You are confusing 2 issues. By standard-compliant, I mean the language spec which does exist and as far as I know, nothing fedora has ever shipped, meets. > An archive of all the SUN, IBM and BEA jvm releases is a baroque history > of inconsistent paths and name changes no sane third-party package could > ever depend on (and BTW paths that contradicted existing standards like > the FHS). What ISVs depend on is a fixed version that uses SUN's > conventions-of-the-day, which are anything but standard. I can't argue with that, but the point is that you aren't likely to find anything more bizarre or undocumented than fedora's alternatives scheme and when you combine the two, it's not something any sysadmin should have to deal with when a simple rpm can fix it all. > Why do you think Java has little life outside J2EE > servers? I don't think that at all. In fact, I think the projects I've already mentioned (opennms, alfresco, openfire, spark) are extremely useful and moderately popular, and there's probably a lot more, plus an assortment of applets for vnc, ssh, xmpp etc., that everyone should have available on their servers. -- Les Mikesell lesmikesell at gmail.com From pertusus at free.fr Fri May 2 21:58:06 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 2 May 2008 23:58:06 +0200 Subject: Multilib Middle-Ground In-Reply-To: <604aa7910805021447w417a7884u23c887e84389589d@mail.gmail.com> References: <604aa7910805011549i47c6193bs177e57cea293dd75@mail.gmail.com> <481B3A70.6070509@gmail.com> <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> <481B5A10.9010308@gmail.com> <604aa7910805021124s1997ad8erec66f2522e413bd8@mail.gmail.com> <481B79C7.7000404@gmail.com> <604aa7910805021347l5e59ff9cj40146b9f1dd0672@mail.gmail.com> <481B88C9.7030707@gmail.com> <604aa7910805021447w417a7884u23c887e84389589d@mail.gmail.com> Message-ID: <20080502215806.GA4412@free.fr> On Fri, May 02, 2008 at 01:47:09PM -0800, Jeff Spaleta wrote: > On Fri, May 2, 2008 at 1:34 PM, Les Mikesell wrote: > > I'd like to think of distributions as having some editorial control over > > what they ship. If someone writes crap you don't have to publish it. Or at > > least overlap old/new versions for a complete version run. > > And a lot of the software in the open ecosystem is under heavy > development and do not need the backwards compatibility that you are > expressing a need for for your in-house code. If we used editoral I don't think it is true. The truce is that many developers are ignorant about ABI/API compatibility and don't even try to design API sanely. Now this could be optimal in some sense, given that it is not a very fun work, but the 'heavy development' is not the reason. -- Pat From kevin.kofler at chello.at Fri May 2 21:58:21 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 2 May 2008 21:58:21 +0000 (UTC) Subject: Multilib Middle-Ground References: <4817FF36.10305@redhat.com> <481A19BA.6090705@gmail.com> <604aa7910805011244q78338786y956500dd55649441@mail.gmail.com> <604aa7910805011549i47c6193bs177e57cea293dd75@mail.gmail.com> <481B3A70.6070509@gmail.com> <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> <481B5A10.9010308@gmail.com> <481B5CC3.3090806@redhat.com> <481B60DB.90202@gmail.com> <481B6871.5000101@gmail.com> Message-ID: Les Mikesell gmail.com> writes: > I can say that OpenNMS won't currently work with a 1.6 version because > it's developers have said so. Then surely you should blame OpenNMS for not supporting the latest version of Java! Java is almost completely backwards-compatible, they have really no excuses for still shipping something which doesn't work with the 1.5-year-old latest version. By the way, have you really tried it? My experience is that stuff often just works with IcedTea even if they claim to only support 1.5. > I don't understand what that has to do with making it difficult to > install a compliant version. s/compliant/obsolete/ Quit talking about "standards compliant" when what you really want is ancient legacy crap. The certified 1.6 implementation from Sun won't run those programs any better than OpenJDK does. > conversations here I thought someone said the relationship was > deliberately broken with portions moved into fedora packages and the > rest ignored. Are you trying to fault Fedora for including what they can include? Obviously they won't include the non-Free crap which is on JPackage, nor stuff which non-Free dependencies. Some of the incompatibilities in packaging are also due to JPackage hardcoding dependencies on non-Free crap into Free packages which aren't really necessary and which Fedora patches out. Kevin Kofler From kevin.kofler at chello.at Fri May 2 22:04:03 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 2 May 2008 22:04:03 +0000 (UTC) Subject: Multilib Middle-Ground References: <4817FF36.10305@redhat.com> <481A19BA.6090705@gmail.com> <604aa7910805011244q78338786y956500dd55649441@mail.gmail.com> <604aa7910805011549i47c6193bs177e57cea293dd75@mail.gmail.com> <481B3A70.6070509@gmail.com> <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> <481B5A10.9010308@gmail.com> <481B5CC3.3090806@redhat.com> <481B60DB.90202@gmail.com> <1209755408.6004.7.camel@rousalka.okg> <481B6FA9.7000300@gmail.com> <1209761234.6848.19.camel@rousalka.okg> <481B8C0E.5070800@gmail.com> Message-ID: Les Mikesell gmail.com> writes: > You are confusing 2 issues. By standard-compliant, I mean the language > spec which does exist and as far as I know, nothing fedora has ever > shipped, meets. Because no Free Software implements it completely (though OpenJDK is now getting close). We can't ship what doesn't exist, and we aren't going to ship proprietary stuff just because some "open source" packages have felt into the Java Trap. Kevin Kofler From kevin.kofler at chello.at Fri May 2 22:00:45 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 2 May 2008 22:00:45 +0000 (UTC) Subject: Multilib Middle-Ground References: <4817FF36.10305@redhat.com> <481A19BA.6090705@gmail.com> <604aa7910805011244q78338786y956500dd55649441@mail.gmail.com> <604aa7910805011549i47c6193bs177e57cea293dd75@mail.gmail.com> <481B3A70.6070509@gmail.com> <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> <481B5A10.9010308@gmail.com> <604aa7910805021124s1997ad8erec66f2522e413bd8@mail.gmail.com> <481B79C7.7000404@gmail.com> <604aa7910805021347l5e59ff9cj40146b9f1dd0672@mail.gmail.com> <481B88C9.7030707@gmail.com> Message-ID: Les Mikesell gmail.com> writes: > Can't you just always provide at least 2 versioned libraries? One > essentially equivalent to the latest released RHEL or Centos version(s) > and the other whatever flavor is current? And unless apps need > something new, build them against the stable version. Fedora is about CURRENT technology. They will ALWAYS prefer the CURRENT version of the libraries if it is at all possible. Why should Fedora build against an old one? You are using the wrong distribution. > I'd like to think of distributions as having some editorial control over > what they ship. If someone writes crap you don't have to publish it. > Or at least overlap old/new versions for a complete version run. We can't ship unmaintained old versions forever. Are you going to maintain the obsolete branches of things like GCC? Kevin Kofler From mark at mitre.org Fri May 2 22:05:39 2008 From: mark at mitre.org (Mark Heslep) Date: Fri, 02 May 2008 18:05:39 -0400 Subject: Multilib Middle-Ground In-Reply-To: <1209688740.10286.154.camel@code.and.org> References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819978A.80304@city-fan.org> <4819BCFD.5070108@gmail.com> <4819BE31.9030306@city-fan.org> <4819C2A9.3050202@gmail.com> <4819CA84.1070004@fedoraproject.org> <481A2E0F.1030106@poolshark.org> <1209688740.10286.154.camel@code.and.org> Message-ID: <481B9033.4060708@mitre.org> James Antill wrote: > >> There's simply no easy way to distribute >> closed-source softare for Linux, as we all know. >> > > That's funny, because adobe seem to be doing a pretty good job of > it ... at least it's a better solution than anything else I've seen for > any other OS. > But even if it was "hard", it'd still be _much easier_ for the vendors > to fix their packaging than for us (Fedora) to guess at what all of > their users want/need and to add hacks to try and please everyone. > > Plenty of other proprietary vendors have trouble: http://www.codeweavers.com/account/downloads/ *CrossOver Linux Professional 6.2.0 RPM (for Red Hat, Mandriva, or SuSE)* 21.51 MB The RPM version of CrossOver Office is used on Distributions such as RedHat, SuSE, and Mandriva, that use the RPM package management system. *CrossOver Linux Professional 6.2.0 for Debian GNU/Linux* 21.46 MB This version will operate only on Debian distributions of Linux such as Ubuntu. *CrossOver Linux Professional 6.2.0 for 64bit Debian/GNU Linux* 21.46 MB This version will operate only on Debian distributions of Linux such as Ubuntu. *CrossOver Linux Professional 6.2.0 for Xandros Linux* 21.46 MB This version will operate only on Xandros Linux only. Mark From jspaleta at gmail.com Fri May 2 22:05:45 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 2 May 2008 14:05:45 -0800 Subject: Multilib Middle-Ground In-Reply-To: <20080502215806.GA4412@free.fr> References: <481B3A70.6070509@gmail.com> <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> <481B5A10.9010308@gmail.com> <604aa7910805021124s1997ad8erec66f2522e413bd8@mail.gmail.com> <481B79C7.7000404@gmail.com> <604aa7910805021347l5e59ff9cj40146b9f1dd0672@mail.gmail.com> <481B88C9.7030707@gmail.com> <604aa7910805021447w417a7884u23c887e84389589d@mail.gmail.com> <20080502215806.GA4412@free.fr> Message-ID: <604aa7910805021505s2d335c15wfb32630deef60ce6@mail.gmail.com> On Fri, May 2, 2008 at 1:58 PM, Patrice Dumas wrote: > I don't think it is true. The truce is that many developers are > ignorant about ABI/API compatibility and don't even try to design API > sanely. Now this could be optimal in some sense, given that it is not a > very fun work, but the 'heavy development' is not the reason. Perhaps a 'framework' initative inside fedora could end up helping to change how individual developers value the issue through as part of their mandate. No matter how we describe it, its an uphill battle that has to include upstream developers or we aren't going to make backwards-compatibility bulletproof even for a well-defined subset of the fedora repository. -jef From pertusus at free.fr Fri May 2 22:10:14 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 3 May 2008 00:10:14 +0200 Subject: Multilib Middle-Ground In-Reply-To: <604aa7910805021505s2d335c15wfb32630deef60ce6@mail.gmail.com> References: <481B3A70.6070509@gmail.com> <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> <481B5A10.9010308@gmail.com> <604aa7910805021124s1997ad8erec66f2522e413bd8@mail.gmail.com> <481B79C7.7000404@gmail.com> <604aa7910805021347l5e59ff9cj40146b9f1dd0672@mail.gmail.com> <481B88C9.7030707@gmail.com> <604aa7910805021447w417a7884u23c887e84389589d@mail.gmail.com> <20080502215806.GA4412@free.fr> <604aa7910805021505s2d335c15wfb32630deef60ce6@mail.gmail.com> Message-ID: <20080502221014.GB4412@free.fr> On Fri, May 02, 2008 at 02:05:45PM -0800, Jeff Spaleta wrote: > On Fri, May 2, 2008 at 1:58 PM, Patrice Dumas wrote: > > I don't think it is true. The truce is that many developers are > > ignorant about ABI/API compatibility and don't even try to design API > > sanely. Now this could be optimal in some sense, given that it is not a > > very fun work, but the 'heavy development' is not the reason. > > Perhaps a 'framework' initative inside fedora could end up helping to > change how individual developers value the issue through as part of > their mandate. No matter how we describe it, its an uphill battle > that has to include upstream developers or we aren't going to make > backwards-compatibility bulletproof even for a well-defined subset of > the fedora repository. I was speaking about upstream maintainers myself. And honestly I don't think that fedora is the right place to do this given what the average contributor value. Doing in EPEL may be much easier for many reasons (and you are perfectly right bringing changes in upstream is the issue here). -- Pat From kevin.kofler at chello.at Fri May 2 22:11:57 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 2 May 2008 22:11:57 +0000 (UTC) Subject: Multilib Middle-Ground References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819978A.80304@city-fan.org> <4819BCFD.5070108@gmail.com> <4819BE31.9030306@city-fan.org> <4819C2A9.3050202@gmail.com> <4819CA84.1070004@fedoraproject.org> <481A2E0F.1030106@poolshark.org> <1209688740.10286.154.camel@code.and.org> <481B9033.4060708@mitre.org> Message-ID: Mark Heslep mitre.org> writes: > Plenty of other proprietary vendors have trouble: > http://www.codeweavers.com/account/downloads/ Trouble? They're able to ship a single package "for Red Hat, Mandriva, or SuSE", which isn't even expected to work (you're supposed to build separate packages for each), so this sounds like quite the opposite of "trouble" to me! Kevin Kofler From kevin.kofler at chello.at Fri May 2 22:15:49 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 2 May 2008 22:15:49 +0000 (UTC) Subject: Multilib Middle-Ground References: <3118d8de0805021323x64467a8fg911239df53a5ff0e@mail.gmail.com> Message-ID: Jason Corley gmail.com> writes: > Granted the VMware example is not LSB conformant, but the LSB Core > spec specifically says: > "Packages shall not depend on other system-provided dependencies." When the LSB says "shall not depend", they REALLY mean SHALL NOT DEPEND, not "shall hide their dependencies on ...". This means they must not use those libraries, or they have to statically link them (yuck!) or ship private copies of them (yuck!!! This is even worse because you get all the drawbacks of static linking without the advantages). Kevin Kofler From lesmikesell at gmail.com Fri May 2 22:20:32 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 02 May 2008 17:20:32 -0500 Subject: Multilib Middle-Ground In-Reply-To: References: <4817FF36.10305@redhat.com> <481A19BA.6090705@gmail.com> <604aa7910805011244q78338786y956500dd55649441@mail.gmail.com> <604aa7910805011549i47c6193bs177e57cea293dd75@mail.gmail.com> <481B3A70.6070509@gmail.com> <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> <481B5A10.9010308@gmail.com> <481B5CC3.3090806@redhat.com> <481B60DB.90202@gmail.com> <481B6871.5000101@gmail.com> Message-ID: <481B93B0.205@gmail.com> Kevin Kofler wrote: > >> I can say that OpenNMS won't currently work with a 1.6 version because >> it's developers have said so. > > Then surely you should blame OpenNMS for not supporting the latest version of > Java! Java is almost completely backwards-compatible, they have really no > excuses for still shipping something which doesn't work with the 1.5-year-old > latest version. If it's so easy, perhaps you could check out a copy and offer them the fixes. > By the way, have you really tried it? My experience is that stuff often just > works with IcedTea even if they claim to only support 1.5. No, and it's not a particular problem as far as opennms itself goes because their yummable repository includes a working JVM. >> I don't understand what that has to do with making it difficult to >> install a compliant version. > > s/compliant/obsolete/ I suppose I can accept that as a description of some happy future time. > Quit talking about "standards compliant" when what you really want is ancient > legacy crap. The certified 1.6 implementation from Sun won't run those programs > any better than OpenJDK does. Yes, I realize this will all get fixed in several more years. But our internal stuff just went to 1.5 last year and it took non-trivial changes so I don't expect everyone else to rush either. >> conversations here I thought someone said the relationship was >> deliberately broken with portions moved into fedora packages and the >> rest ignored. > > Are you trying to fault Fedora for including what they can include? Yes, both for shipping a non-conforming implementation which harms everyone involved, and for not shipping something to fix up the package dependencies and alternatives symlinks peculiar to fedora when a user installs a conforming implementation. > Obviously > they won't include the non-Free crap which is on JPackage, nor stuff which > non-Free dependencies. Some of the incompatibilities in packaging are also due > to JPackage hardcoding dependencies on non-Free crap into Free packages which > aren't really necessary and which Fedora patches out. I can't parse any of that. The jpackage nosrc packages don't include any non-free bits - they just adjust things for fedora oddness. -- Les Mikesell lesmikesell at gmail.com From lesmikesell at gmail.com Fri May 2 22:23:13 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 02 May 2008 17:23:13 -0500 Subject: Multilib Middle-Ground In-Reply-To: References: <4817FF36.10305@redhat.com> <481A19BA.6090705@gmail.com> <604aa7910805011244q78338786y956500dd55649441@mail.gmail.com> <604aa7910805011549i47c6193bs177e57cea293dd75@mail.gmail.com> <481B3A70.6070509@gmail.com> <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> <481B5A10.9010308@gmail.com> <481B5CC3.3090806@redhat.com> <481B60DB.90202@gmail.com> <1209755408.6004.7.camel@rousalka.okg> <481B6FA9.7000300@gmail.com> <1209761234.6848.19.camel@rousalka.okg> <481B8C0E.5070800@gmail.com> Message-ID: <481B9451.3020504@gmail.com> Kevin Kofler wrote: > Les Mikesell gmail.com> writes: >> You are confusing 2 issues. By standard-compliant, I mean the language >> spec which does exist and as far as I know, nothing fedora has ever >> shipped, meets. > > Because no Free Software implements it completely (though OpenJDK is now > getting close). We can't ship what doesn't exist, and we aren't going to ship > proprietary stuff just because some "open source" packages have felt into the > Java Trap. There never was a trap - just some lies about one. -- Les Mikesell lesmikesell at gmail.com From kevin.kofler at chello.at Fri May 2 22:24:25 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 2 May 2008 22:24:25 +0000 (UTC) Subject: Multilib Middle-Ground References: <4817FF36.10305@redhat.com> <481A19BA.6090705@gmail.com> <604aa7910805011244q78338786y956500dd55649441@mail.gmail.com> <604aa7910805011549i47c6193bs177e57cea293dd75@mail.gmail.com> <481B3A70.6070509@gmail.com> <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> <481B5A10.9010308@gmail.com> <481B5CC3.3090806@redhat.com> <481B60DB.90202@gmail.com> <1209755408.6004.7.camel@rousalka.okg> <481B6FA9.7000300@gmail.com> <1209761234.6848.19.camel@rousalka.okg> <481B8C0E.5070800@gmail.com> <481B9451.3020504@gmail.com> Message-ID: Les Mikesell gmail.com> writes: > There never was a trap - just some lies about one. You clearly haven't understood what Free Software is about. Kevin Kofler From kevin.kofler at chello.at Fri May 2 22:31:39 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 2 May 2008 22:31:39 +0000 (UTC) Subject: Multilib Middle-Ground References: <4817FF36.10305@redhat.com> <481A19BA.6090705@gmail.com> <604aa7910805011244q78338786y956500dd55649441@mail.gmail.com> <604aa7910805011549i47c6193bs177e57cea293dd75@mail.gmail.com> <481B3A70.6070509@gmail.com> <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> <481B5A10.9010308@gmail.com> <481B5CC3.3090806@redhat.com> <481B60DB.90202@gmail.com> <481B6871.5000101@gmail.com> <481B93B0.205@gmail.com> Message-ID: Les Mikesell gmail.com> writes: > > By the way, have you really tried it? > No Then why not try it and complain about specific things which don't work, so they can be fixed, either in OpenJDK/IcedTea if that's where the problem is, or in OpenNMS if that's at fault? > If it's so easy, perhaps you could check out a copy and offer them the > fixes. Are fixes even needed? What's broken exactly? You haven't even tried it... > > Are you trying to fault Fedora for including what they can include? > > Yes, both for shipping a non-conforming implementation which harms > everyone involved, and for not shipping something to fix up the package > dependencies and alternatives symlinks peculiar to fedora when a user > installs a conforming implementation. Then you are a lunatic who really doesn't understand what Fedora is about. Fedora will include whatever it can include without violating its guidelines. If you want proprietary crap, you're at the wrong address. If you want Fedora not to ship anything which has a proprietary equivalent, that would mean shipping essentially nothing, after all there's a proprietary kernel, a proprietary office suite etc. What you're asking for makes no sense. > I can't parse any of that. The jpackage nosrc packages don't include > any non-free bits - they just adjust things for fedora oddness. JPackage has no guideline which forbids Free packages to have dependencies (RPM "Requires:") on non-Free ones, and there are some which do, even where it is possible to build the package without that dependency. Fedora had to patch out those dependencies when importing those packages. I don't remember the exact affected packages, but I do remember there were some packages which had non-Free dependencies removed as part of the import into Fedora. Kevin Kofler From tibbs at math.uh.edu Fri May 2 22:42:09 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 02 May 2008 17:42:09 -0500 Subject: autofs no longer in default install In-Reply-To: <604aa7910805021406q5f9b3e7lc6dec30da2256e73@mail.gmail.com> References: <20080502202155.DA61F26FA07@magilla.localdomain> <20080502203105.GB23239@nostromo.devel.redhat.com> <20080502205451.F225D26FA07@magilla.localdomain> <1209675651.29415.13.camel@localhost.localdomain> <604aa7910805021406q5f9b3e7lc6dec30da2256e73@mail.gmail.com> Message-ID: >>>>> "JS" == Jeff Spaleta writes: JS> Man i really wish we had a collection of pre-cooked kickstart JS> files aimed at specific use case. Don't we have a public cobbler server providing this functionality? Or was that something folks were just talking about? - J< From lesmikesell at gmail.com Fri May 2 22:43:27 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 02 May 2008 17:43:27 -0500 Subject: Multilib Middle-Ground In-Reply-To: References: <4817FF36.10305@redhat.com> <481A19BA.6090705@gmail.com> <604aa7910805011244q78338786y956500dd55649441@mail.gmail.com> <604aa7910805011549i47c6193bs177e57cea293dd75@mail.gmail.com> <481B3A70.6070509@gmail.com> <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> <481B5A10.9010308@gmail.com> <604aa7910805021124s1997ad8erec66f2522e413bd8@mail.gmail.com> <481B79C7.7000404@gmail.com> <604aa7910805021347l5e59ff9cj40146b9f1dd0672@mail.gmail.com> <481B88C9.7030707@gmail.com> Message-ID: <481B990F.1010609@gmail.com> Kevin Kofler wrote: > Les Mikesell gmail.com> writes: >> Can't you just always provide at least 2 versioned libraries? One >> essentially equivalent to the latest released RHEL or Centos version(s) >> and the other whatever flavor is current? And unless apps need >> something new, build them against the stable version. > > Fedora is about CURRENT technology. They will ALWAYS prefer the CURRENT version > of the libraries if it is at all possible. Why should Fedora build against an > old one? You are using the wrong distribution. Yes, I probably overstated the need for long term backwards compatibility in fedora itself, although I still don't see why it is impossible or undesirable. What I really want is a smooth transition between those 'right' distibutions.... That is, assuming RHEL or Centos as stable production environments, I want to be able to have a development environment that doesn't take major work to keep running things from the current production environment and by the time of the next enterprise release also provides a smooth transition in that direction. Sort of like the old days of using RH X.0 for development/testing and by X.2 things were good to go. >> I'd like to think of distributions as having some editorial control over >> what they ship. If someone writes crap you don't have to publish it. >> Or at least overlap old/new versions for a complete version run. > > We can't ship unmaintained old versions forever. Are you going to maintain the > obsolete branches of things like GCC? Isn't that already being done elsewhere? It is only unnecessary fedora-specific incompatibilities that would keep you from using it. -- Les Mikesell lesmikesell at gmail.com From mark at mitre.org Fri May 2 22:45:25 2008 From: mark at mitre.org (Mark Heslep) Date: Fri, 02 May 2008 18:45:25 -0400 Subject: Multilib Middle-Ground In-Reply-To: References: <4817FF36.10305@redhat.com> <481815CC.8050306@redhat.com> <20080430140318.GC30581@nostromo.devel.redhat.com> <481895CE.70501@redhat.com> <20080430160158.GA8368@nostromo.devel.redhat.com> <48189F75.4070301@redhat.com> <4818D1BC.6060707@redhat.com> <48198234.4040304@gmail.com> <481989DF.30304@city-fan.org> <48198EA0.5070904@gmail.com> <4819978A.80304@city-fan.org> <4819BCFD.5070108@gmail.com> <4819BE31.9030306@city-fan.org> <4819C2A9.3050202@gmail.com> <4819CA84.1070004@fedoraproject.org> <481A2E0F.1030106@poolshark.org> <1209688740.10286.154.camel@code.and.org> <481B9033.4060708@mitre.org> Message-ID: <481B9985.2030501@mitre.org> And another one for Ubuntu, another for Xandros, .... They have just dumped other they used to support. Kevin Kofler wrote: > Mark Heslep mitre.org> writes: > >> Plenty of other proprietary vendors have trouble: >> http://www.codeweavers.com/account/downloads/ >> > > Trouble? They're able to ship a single package "for Red Hat, Mandriva, or > SuSE", which isn't even expected to work (you're supposed to build separate > packages for each), so this sounds like quite the opposite of "trouble" to me! > > Kevin Kofler > > From lesmikesell at gmail.com Fri May 2 22:46:28 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 02 May 2008 17:46:28 -0500 Subject: Multilib Middle-Ground In-Reply-To: References: <4817FF36.10305@redhat.com> <481A19BA.6090705@gmail.com> <604aa7910805011244q78338786y956500dd55649441@mail.gmail.com> <604aa7910805011549i47c6193bs177e57cea293dd75@mail.gmail.com> <481B3A70.6070509@gmail.com> <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> <481B5A10.9010308@gmail.com> <481B5CC3.3090806@redhat.com> <481B60DB.90202@gmail.com> <1209755408.6004.7.camel@rousalka.okg> <481B6FA9.7000300@gmail.com> <1209761234.6848.19.camel@rousalka.okg> <481B8C0E.5070800@gmail.com> <481B9451.3020504@gmail.com> Message-ID: <481B99C4.6030303@gmail.com> Kevin Kofler wrote: > Les Mikesell gmail.com> writes: >> There never was a trap - just some lies about one. > > You clearly haven't understood what Free Software is about. It's not that I don't understand, I just don't agree that it is the only way. Or that anything with an interface spec can ever be a trap. -- Les Mikesell lesmikesell at gmail.com From dr.diesel at gmail.com Fri May 2 22:49:26 2008 From: dr.diesel at gmail.com (Dr. Diesel) Date: Fri, 2 May 2008 18:49:26 -0400 Subject: Fixing recursive fault but reboot is needed! Message-ID: <2a28d2ab0805021549m71ac9f03g9dd0f01570aaf2f9@mail.gmail.com> Does this mean anything? Just popped up! [root at localhost ~]# dmesg | tail [] ? thread_return+0x63/0xa7 [] ? audit_syscall_exit+0x331/0x353 [] error_exit+0x0/0x51 Code: 48 ff c9 eb 62 66 0f 1f 44 00 00 65 4c 8b 04 25 10 00 00 00 49 81 e8 d8 1f 00 00 48 83 c1 03 72 0f 49 3b 48 20 73 09 48 83 e9 03 <89> 11 31 c0 c3 48 83 e9 03 eb 31 0f 1f 44 00 00 65 4c 8b 04 25 RIP [] __put_user_4+0x20/0x30 RSP ---[ end trace ef51479770fd9cdc ]--- Fixing recursive fault but reboot is needed! [root at localhost ~]# -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org From davej at redhat.com Fri May 2 22:52:54 2008 From: davej at redhat.com (Dave Jones) Date: Fri, 2 May 2008 18:52:54 -0400 Subject: Fixing recursive fault but reboot is needed! In-Reply-To: <2a28d2ab0805021549m71ac9f03g9dd0f01570aaf2f9@mail.gmail.com> References: <2a28d2ab0805021549m71ac9f03g9dd0f01570aaf2f9@mail.gmail.com> Message-ID: <20080502225254.GA7255@redhat.com> On Fri, May 02, 2008 at 06:49:26PM -0400, Dr. Diesel wrote: > Does this mean anything? yes, bad voodoo. > [root at localhost ~]# dmesg | tail please file a bugzilla with the full dmesg output. (unless you're using any binary-only modules, in which case all bets are off) thanks, Dave From lesmikesell at gmail.com Fri May 2 22:54:41 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 02 May 2008 17:54:41 -0500 Subject: Multilib Middle-Ground In-Reply-To: <20080502215806.GA4412@free.fr> References: <604aa7910805011549i47c6193bs177e57cea293dd75@mail.gmail.com> <481B3A70.6070509@gmail.com> <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> <481B5A10.9010308@gmail.com> <604aa7910805021124s1997ad8erec66f2522e413bd8@mail.gmail.com> <481B79C7.7000404@gmail.com> <604aa7910805021347l5e59ff9cj40146b9f1dd0672@mail.gmail.com> <481B88C9.7030707@gmail.com> <604aa7910805021447w417a7884u23c887e84389589d@mail.gmail.com> <20080502215806.GA4412@free.fr> Message-ID: <481B9BB1.3090108@gmail.com> Patrice Dumas wrote: > On Fri, May 02, 2008 at 01:47:09PM -0800, Jeff Spaleta wrote: >> On Fri, May 2, 2008 at 1:34 PM, Les Mikesell wrote: >>> I'd like to think of distributions as having some editorial control over >>> what they ship. If someone writes crap you don't have to publish it. Or at >>> least overlap old/new versions for a complete version run. >> And a lot of the software in the open ecosystem is under heavy >> development and do not need the backwards compatibility that you are >> expressing a need for for your in-house code. If we used editoral > > I don't think it is true. The truce is that many developers are > ignorant about ABI/API compatibility and don't even try to design API > sanely. Now this could be optimal in some sense, given that it is not a > very fun work, but the 'heavy development' is not the reason. I don't think most people understand it until there is a change in their own favorite tool or language that makes them go do all their work over again or track down obscure bugs because of a library regression that got by because nobody bothered to test the interfaces. -- Les Mikesell lesmikesell at gmail.com From dr.diesel at gmail.com Fri May 2 23:01:53 2008 From: dr.diesel at gmail.com (Dr. Diesel) Date: Fri, 2 May 2008 19:01:53 -0400 Subject: Fixing recursive fault but reboot is needed! In-Reply-To: <20080502225254.GA7255@redhat.com> References: <2a28d2ab0805021549m71ac9f03g9dd0f01570aaf2f9@mail.gmail.com> <20080502225254.GA7255@redhat.com> Message-ID: <2a28d2ab0805021601j1abc7196k466f67749fb9da5b@mail.gmail.com> On Fri, May 2, 2008 at 6:52 PM, Dave Jones wrote: > On Fri, May 02, 2008 at 06:49:26PM -0400, Dr. Diesel wrote: > > Does this mean anything? > > yes, bad voodoo. > > > [root at localhost ~]# dmesg | tail > > please file a bugzilla with the full dmesg output. > (unless you're using any binary-only modules, in which case > all bets are off) > > thanks, > > Dave No binary modules. Today's Rawhide. Wait a minute, I did just install VirtualBox 1.6 not long before? Which has a kernel module... https://bugzilla.redhat.com/show_bug.cgi?id=445049 Thanks Andy -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org From sven at lank.es Fri May 2 23:02:41 2008 From: sven at lank.es (Sven Lankes) Date: Sat, 3 May 2008 01:02:41 +0200 Subject: Wiki page - HowToGetSponsored Message-ID: <20080502230241.GA30356@killefiz> Hello, I'm slowly working my way through the available documentation around becoming a fedora packager. The wiki-Page https://fedoraproject.org/wiki/PackageMaintainers/HowToGetSponsored has a couple of things which aren't clear to me. I'll happily fix the wiki page with useful advise posted here. > Note that sponsorship is not automatic and requires that you find a > willing sponsor. It is not clear to me if it's sufficient to post one or more package review requests blocking FE-NEEDSPONSOR or if I have to hunt down possible sponsors to actually look at my requests. Is it common for sponsors to browse bugzilla for fresh FE-NEEDSPONSOR tickets? > Note also that you should not submit your sponsorship request to the > account system until after you have been given the go-ahead from a > sponsor I'm rather lost here. What is a sponsorship request and where do I submit it in the account system? > (List of Sponsors) - > The list of sponsors is only visible to > contributors with a Fedora Account. (List of Sponsors) links to https://admin.fedoraproject.org/accounts/dump-group.cgi?group=cvsextras&role_type=sponsor&format=html which results in an "Internal Server Error". Looking around I found https://admin.fedoraproject.org/accounts/group/view/cvsextras to be the closest replacement for the above link - but it doesn't allow allow to only list sponsors - is there some url-magic I'm missing that will filter the list to only show sponsors? -- sven === jabber/xmpp: sven at lankes.net From Christian.Iseli at unil.ch Fri May 2 23:07:42 2008 From: Christian.Iseli at unil.ch (Christian Iseli) Date: Sat, 3 May 2008 01:07:42 +0200 Subject: Fedora Package Status of May 3, 2008 Message-ID: <20080503010742.1b41ccab@ludwig-alpha.unil.ch> Hi folks, Yikes, 3 months have gone by already since the last time I ran this... Anyway, right before the release, here is the status... tibbs, to get a better view of non-sponsors with many reviews, I have increased the Top listings to 50. I thought this was simplest to implement. If you have other ideas, I'll gladly try them out :) Cheers, Christian ==== Fedora Package Status of May 3, 2008 The full report can be found here: http://fedoraproject.org/wiki/PackageMaintainers/PackageStatus Owners stats: - 6029 packages - 9893 binary rpms in devel - 115 orphans - 91 packages not available in devel or release Axel dot Thimm at ATrpms dot net freenx-server Axel dot Thimm at ATrpms dot net mediawiki-openid Axel dot Thimm at ATrpms dot net freenx-client Fedora at FamilleCollet dot com php-pear-Cache-Lite aaronh at garden dot org gnue-common alexl at users dot sourceforge dot net sqlite2 andreas at bawue dot net perl-HTML-CalendarMonthSimple andreas at bawue dot net ngircd bdpepple at gmail dot com gaim-galago bnocera at redhat dot com galago-filesystem bogado at bogado dot net cwiid caolanm at redhat dot com hunspell-he caolanm at redhat dot com jcommon chris at void dot printf dot net ohm cweyl at alumni dot drew dot edu perl-Catalyst-Plugin-CGI-Untaint cweyl at alumni dot drew dot edu gaim-gaym dan at danny dot cz python-openhpi dan at danny dot cz openhpi-subagent davidf at sjsoft dot com fsvs davidz at redhat dot com redhat-artwork dennis at ausil dot us prtconf dennis at ausil dot us silo dev at nigelj dot com pAgenda devrim at commandprompt dot com postgresql-pgpool-ha devrim at commandprompt dot com saxon8 esandeen at redhat dot com guilt fedora at christoph-wickert dot de lxappearance fedora at matbooth dot co dot uk brazil fedora at matbooth dot co dot uk eclipse-epic gilboad at gmail dot com idesk i at stingr dot net cuetools ivazqueznet at gmail dot com xmlroff j dot w dot r dot degoede at hhs dot nl simcoupe j dot w dot r dot degoede at hhs dot nl samcoupe-rom jafo at tummy dot com python-mechanoid jbowes at redhat dot com eg jeremy at hinegardner dot org tinyproxy jkeating at redhat dot com tux jmp at safe dot ca clement jnovy at redhat dot com libgphoto2 jonathan dot underwood at gmail dot com dvipdfm jorton at redhat dot com libc-client jorton at redhat dot com newt-perl josh dot kayse at gtri dot gatech dot edu perl-File-LibMagic konrad at tylerc dot org jvyamlb konrad at tylerc dot org jruby konrad at tylerc dot org jna-posix kushaldas at gmail dot com pem lkundrak at v3 dot sk tzdata-java lvillani at binaryhelix dot net bip matthias at rpmforge dot net csync2 maxx at krakoa dot dk hamster-applet michel dot sylvan at gmail dot com Falcon mitr at redhat dot com audit-viewer mitr at redhat dot com python-gtkextra mmahut at redhat dot com pyephem mpg at redhat dot com sugar-evince ndbecker2 at gmail dot com unuran ndbecker2 at gmail dot com Cython nikolay at vladimiroff dot com gkrellm-timestamp noah at coderanger dot net rainbow noah at coderanger dot net python-olpcgames oliver at linux-kernel dot at aboot orion at cora dot nwra dot com GMT-coastlines orion at cora dot nwra dot com R-car paul at all-the-johnsons dot co dot uk mysql-connector-net paul at all-the-johnsons dot co dot uk mono-tools pertusus at free dot fr grib_api pertusus at free dot fr ivman pknirsch at redhat dot com freeimpi ralston at pobox dot com perl-Encode-Detect rdieter at math dot unl dot edu pykdeextensions redhat at linuxnetz dot de bind-libbind rjones at redhat dot com ocaml-bitmatch rjones at redhat dot com ocaml-omake rjones at redhat dot com ocaml-gettext rjones at redhat dot com collectd rjones at redhat dot com ocaml-gsl rvokal at redhat dot com gaim-guifications sergio dot pasra at gmail dot com pyfits skvidal at linux dot duke dot edu preupgrade splinux25 at gmail dot com drapes stlwrt at gmail dot com eet terjeros at phys dot ntnu dot no e16-epplets terjeros at phys dot ntnu dot no e16-themes terjeros at phys dot ntnu dot no e16-docs terjeros at phys dot ntnu dot no perl-CSS twaugh at redhat dot com desktop-printing wart at kobold dot org compat-guichan06 wtogami at redhat dot com firefox-32 yufanyufan at gmail dot com audacious-plugins-docklet - 47 packages not available in devel but present in release Fedora at FamilleCollet dot com ocsinventory-client adel dot gadllah at gmail dot com quicksynergy andreas dot bierfert at lowlatency dot de multisync andreas dot bierfert at lowlatency dot de libopensync-plugin-synce anyremote at mail dot ru anyremote anyremote at mail dot ru ganyremote bdpepple at gmail dot com eds-feed bdpepple at gmail dot com purple-galago bdpepple at gmail dot com gnome-blog dan at danny dot cz ski fedora at christoph-wickert dot de thunar-shares fedora at theholbrooks dot org kronolith gauret at free dot fr pdftohtml gemi at bluewin dot ch ffcall huzaifas at redhat dot com psiconv huzaifas at redhat dot com python-lzo ianweller at gmail dot com mediawiki-HNP ianweller at gmail dot com ezstream katzj at redhat dot com pirut konrad at tylerc dot org bytelist lvm-team at redhat dot com device-mapper lxtnow at gmail dot com kicker-compiz lxtnow at gmail dot com cgi-util mark at fasheh dot com ocfs2-tools michel dot sylvan at gmail dot com python-nltk_lite mmahut at redhat dot com imapsync mmahut at redhat dot com libopensync-plugin-sunbird mr dot ecik at gmail dot com python-mpd paul at all-the-johnsons dot co dot uk ikvm rafalzaq at gmail dot com biloba rdieter at math dot unl dot edu kcometen3 rvinyard at cs dot nmsu dot edu idioskopos simon at sxw dot org dot uk perl-Catalyst-Model-LDAP simon at sxw dot org dot uk perl-Catalyst-Plugin-StackTrace simon at sxw dot org dot uk kstart simon at sxw dot org dot uk perl-Task-Weaken simon at sxw dot org dot uk perl-Catalyst-View-JSON tcallawa at redhat dot com pyke tim at niemueller dot de lua-posix tim at niemueller dot de lua-sql tim at niemueller dot de luadoc tim at niemueller dot de lua-logging tim at niemueller dot de lua-socket timothy dot selivanow at virtualxistenz dot com pysvn wart at kobold dot org tile xgl-maint at redhat dot com xorg-x11-drv-vermilion xgl-maint at redhat dot com xorg-x11-drv-amd - 8 packages which have not yet been FE-ACCEPT'd... https://bugzilla.redhat.com/buglist.cgi?bug_id=222191,231861 eclipse ben at bagu.org cyrus-imapd tjanouse at redhat.com https://bugzilla.redhat.com/buglist.cgi?bug_id=221717,224458,252049,431320,434880,445019 agg caolanm at redhat.com libsilc wtogami at redhat.com asm2 viveklak at gmail.com pam_usb guidolinfrancesco at email.it tanukiwrapper jesusr at redhat.com python-decorator kylev at kylev.com - 2 packages present in the development repo which have no owners entry mogilefs-server s390utils - 21 orphaned packages, yet available in devel AGReader PyOpenGL aasaver beagle emesene f-spot gnome-applet-tvn24 gnome-ppp kbiof libgringotts libical lipstik multiget nautilus-share ndesk-dbus ndesk-dbus-glib osmo pygtkglext rafkill xdms xeuphoric FE-ACCEPT packages stats: - 4422 accepted, closed package reviews - 112 accepted, closed package reviews not in repo - 19 accepted, closed package reviews not in owners - 45 accepted, open package reviews with a package already in the repo FE-REVIEW packages stats: - 222 open tickets - 55 closed tickets FE-NEW packages stats: - 776 open tickets FE-NEEDSPONSOR packages stats: - 37 open tickets FE-Legal packages stats: - 8 open tickets OPEN-BUGS packages stats: - 7620 open tickets - 11 tickets with no activity in eight weeks - 1 tickets with no activity in four weeks CVS stats: - 6039 packages with a devel directory - 4 packages with no owners entry F-8 glibc32 glibc64 tdma - 361 packages were dropped from Fedora Maintainers stats: - 505 maintainers Dropped Fedora packages: - 225 packages were dropped since Fedora 7 Comps.xml files stats: - 2804 packages in comps-f9 file - 1502 packages missing from comps-f9 file - 17 packages in comps-f9 but not in repo - 2699 packages in comps-f8 file - 1413 packages missing from comps-f8 file - 12 packages in comps-f8 but not in repo From davej at redhat.com Fri May 2 23:12:39 2008 From: davej at redhat.com (Dave Jones) Date: Fri, 2 May 2008 19:12:39 -0400 Subject: Fixing recursive fault but reboot is needed! In-Reply-To: <2a28d2ab0805021601j1abc7196k466f67749fb9da5b@mail.gmail.com> References: <2a28d2ab0805021549m71ac9f03g9dd0f01570aaf2f9@mail.gmail.com> <20080502225254.GA7255@redhat.com> <2a28d2ab0805021601j1abc7196k466f67749fb9da5b@mail.gmail.com> Message-ID: <20080502231239.GB7255@redhat.com> On Fri, May 02, 2008 at 07:01:53PM -0400, Dr. Diesel wrote: > On Fri, May 2, 2008 at 6:52 PM, Dave Jones wrote: > > On Fri, May 02, 2008 at 06:49:26PM -0400, Dr. Diesel wrote: > > > Does this mean anything? > > > > yes, bad voodoo. > > > > > [root at localhost ~]# dmesg | tail > > > > please file a bugzilla with the full dmesg output. > > (unless you're using any binary-only modules, in which case > > all bets are off) > > > > thanks, > > > > Dave > > No binary modules. Today's Rawhide. > > Wait a minute, I did just install VirtualBox 1.6 not long before? > Which has a kernel module... Which does all sorts of futzing with page tables. Chances are it can't cope with the changes done in .25 to support PAT. (Though I've seen it cause numerous cases of corruption in even before these changes). If I were a betting man, I'd put odds on that module being the cause of your problems. Dave From dr.diesel at gmail.com Fri May 2 23:17:00 2008 From: dr.diesel at gmail.com (Dr. Diesel) Date: Fri, 2 May 2008 19:17:00 -0400 Subject: Fixing recursive fault but reboot is needed! In-Reply-To: <20080502231239.GB7255@redhat.com> References: <2a28d2ab0805021549m71ac9f03g9dd0f01570aaf2f9@mail.gmail.com> <20080502225254.GA7255@redhat.com> <2a28d2ab0805021601j1abc7196k466f67749fb9da5b@mail.gmail.com> <20080502231239.GB7255@redhat.com> Message-ID: <2a28d2ab0805021617v920f16eh7702cd9e2b7d4284@mail.gmail.com> On Fri, May 2, 2008 at 7:12 PM, Dave Jones wrote: > On Fri, May 02, 2008 at 07:01:53PM -0400, Dr. Diesel wrote: > > On Fri, May 2, 2008 at 6:52 PM, Dave Jones wrote: > > > On Fri, May 02, 2008 at 06:49:26PM -0400, Dr. Diesel wrote: > > > > Does this mean anything? > > > > > > yes, bad voodoo. > > > > > > > [root at localhost ~]# dmesg | tail > > > > > > please file a bugzilla with the full dmesg output. > > > (unless you're using any binary-only modules, in which case > > > all bets are off) > > > > > > thanks, > > > > > > Dave > > > > No binary modules. Today's Rawhide. > > > > Wait a minute, I did just install VirtualBox 1.6 not long before? > > Which has a kernel module... > > Which does all sorts of futzing with page tables. > Chances are it can't cope with the changes done in .25 to support PAT. > (Though I've seen it cause numerous cases of corruption in even > before these changes). > > If I were a betting man, I'd put odds on that module being the cause > of your problems. > > > > Dave > According to their change log here http://virtualbox.org/wiki/Changelog Linux additions: compatibility ?xes with Linux 2.6.25 Give the word and I'll post a bug to them. Thanks Andy -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org From stlwrt at gmail.com Fri May 2 23:24:03 2008 From: stlwrt at gmail.com (Pavel Shevchuk) Date: Sat, 3 May 2008 02:24:03 +0300 Subject: Wiki page - HowToGetSponsored In-Reply-To: <20080502230241.GA30356@killefiz> References: <20080502230241.GA30356@killefiz> Message-ID: FE-NEEDSPONSOR worked for me =) On 5/3/08, Sven Lankes wrote: > Hello, > > I'm slowly working my way through the available documentation around > becoming a fedora packager. > > The wiki-Page https://fedoraproject.org/wiki/PackageMaintainers/HowToGetSponsored > has a couple of things which aren't clear to me. I'll happily fix the wiki page > with useful advise posted here. > > > Note that sponsorship is not automatic and requires that you find a > > willing sponsor. > > It is not clear to me if it's sufficient to post one or more package > review requests blocking FE-NEEDSPONSOR or if I have to hunt down > possible sponsors to actually look at my requests. > > Is it common for sponsors to browse bugzilla for fresh FE-NEEDSPONSOR > tickets? > > > Note also that you should not submit your sponsorship request to the > > account system until after you have been given the go-ahead from a > > sponsor > > I'm rather lost here. What is a sponsorship request and where do I > submit it in the account system? > > > (List of Sponsors) - > > The list of sponsors is only visible to > > contributors with a Fedora Account. > > (List of Sponsors) links to > https://admin.fedoraproject.org/accounts/dump-group.cgi?group=cvsextras&role_type=sponsor&format=html > which results in an "Internal Server Error". > > Looking around I found > https://admin.fedoraproject.org/accounts/group/view/cvsextras to be the > closest replacement for the above link - but it doesn't allow allow to > only list sponsors - is there some url-magic I'm missing that will > filter the list to only show sponsors? > > -- > sven === jabber/xmpp: sven at lankes.net > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- http://scwlab.com From wwoods at redhat.com Fri May 2 23:26:28 2008 From: wwoods at redhat.com (Will Woods) Date: Fri, 02 May 2008 23:26:28 +0000 Subject: [Fwd: Apport] In-Reply-To: <1209765295.8872.0.camel@localhost.localdomain> References: <1209765295.8872.0.camel@localhost.localdomain> Message-ID: <1209770788.7350.65.camel@metroid.rdu.redhat.com> On Fri, 2008-05-02 at 17:54 -0400, Tom "spot" Callaway wrote: > Passing this along for consideration. (original email ref: http://lists.freedesktop.org/archives/distributions/2008-May/000163.html) ?I worked on Apport for Fedora during (I think) the F7 release cycle: https://code.launchpad.net/~wwoods/apport/fedora http://fedoraproject.org/wiki/Releases/FeatureApport Things have matured for a year, and I think related technologies have matured to the point where this could be done right in Fedora and other distributions. Here's a braindump of some of the things involved. 1) Linux kernel support Neil Horman worked on a kernel patch that fixed some of the hackery that Ubuntu's kernel was using to make it work[1]. I don't have the commit id offhand, but the upshot is that you can use arguments with command pipes in core_pattern as of.. 2.6.24, I think. 2) packaging abstraction There were some other distro-specific bits to fill in - like looking up package name from a filename. In Fedora I believe we can easily (and more accurately) handle this by pulling BuildIDs[2] out of the core dump itself. Apport could also be using PackageKit as its packaging backend, rather than having its own private abstractions for these things. 3) Reporting format We had a discussion about the proper format for bug reports, and coordinating this with other projects. Apport is using a RFC822 (essentially email)-formatted bug report with specific "headers"/"tags" to indicate various metadata about the report[3]. GNOME's bug-buddy, as I understand it, uses Google's Breakpad[4] libs to generate its reports; Mozilla projects do the same. Kerneloops is a similar idea but (obviously) their reports are all just Linux kernel oopses. I couldn't find details on a crash-report format specific to KDE but if someone wants to point me at some existing work in this area I'd appreciate it. 4) Server-side ?Apport in Ubuntu uses launchpad as the server-side to report bugs to; python-bugzilla[5] came out of my efforts to implement that for Fedora. Mozilla's Breakpad efforts have produced a server and web client for collecting and viewing crash reports[6]. I think it makes sense for Fedora to follow the lead of GNOME and Mozilla and use Breakpad-style reports. All the pieces are there. We just need someone with the time, skills, and drive to put 'em all together. -w ?[1] http://kerneltrap.org/node/14010 ?[2] http://fedoraproject.org/wiki/Releases/FeatureBuildId ?[3] ?https://wiki.ubuntu.com/Apport#head-43f381da3ef07fd0e601265ff1c835894d77b159 [4] http://code.google.com/p/google-breakpad/ ?[5] https://fedorahosted.org/python-bugzilla/ [6] http://wiki.mozilla.org/Breakpad -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From tibbs at math.uh.edu Fri May 2 23:28:47 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 02 May 2008 18:28:47 -0500 Subject: Fedora Package Status of May 3, 2008 In-Reply-To: <20080503010742.1b41ccab@ludwig-alpha.unil.ch> References: <20080503010742.1b41ccab@ludwig-alpha.unil.ch> Message-ID: >>>>> "CI" == Christian Iseli writes: CI> tibbs, to get a better view of non-sponsors with many reviews, I CI> have increased the Top listings to 50. I thought this was CI> simplest to implement. If you have other ideas, I'll gladly try CI> them out :) It sure helps. I was thinking of either separating out the non-sponsor reviews or picking a cutoff of something like 100 reviews and sticking those above it into a Hall of Fame or semis. There's really no point in a dick size war once you get that far up into the stratosphere, and we could probably do without the hilariously huge bug lists. Clicking on the one next to my name gets me "This list is too long for Bagel's little mind". In any case, now I have plenty of people to investigate for sponsorship status. That, and 37 "nobody" tickets to clean up. Thanks for doing this. - J< From tibbs at math.uh.edu Fri May 2 23:30:58 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 02 May 2008 18:30:58 -0500 Subject: Fedora Package Status of May 3, 2008 In-Reply-To: References: <20080503010742.1b41ccab@ludwig-alpha.unil.ch> Message-ID: Note to self: don't lean on random keys while spellchecker is running. >>>>> "JLT" == Jason L Tibbitts writes: JLT> reviews and sticking those above it into a Hall of Fame or semis. ^ should be "somesuch" JLT> gets me "This list is too long for Bagel's little mind". ^ should be "Bugzilla" Jeez. - J< From kevin.kofler at chello.at Fri May 2 23:45:18 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 2 May 2008 23:45:18 +0000 (UTC) Subject: [Fwd: Apport] References: <1209765295.8872.0.camel@localhost.localdomain> <1209770788.7350.65.camel@metroid.rdu.redhat.com> Message-ID: Will Woods redhat.com> writes: > I couldn't find details on a crash-report format specific to KDE but if > someone wants to point me at some existing work in this area I'd > appreciate it. KDE has something called KCrash. KCrash intercepts crashes in KDE applications and brings up a crash window with 2 tabs. The first tab is just the usually "Sorry, I have crashed" boilerplate, the second tab is for backtraces: switching to that second tab causes KCrash to invoke GDB and attach it to the executable, obtaining a backtrace which is displayed in a text box on that tab; there are 2 buttons on the tab: one to copy the backtrace to the clipboard, one to save it to a file. And of course the dialog has a Close button. There is no special format for crash reports, it's just a GDB backtrace. If GDB is not installed, KCrash just displays an error that no backtrace could be obtained because GDB is not installed. Kevin Kofler From stuart at terminus.co.uk Fri May 2 23:52:41 2008 From: stuart at terminus.co.uk (Stuart Children) Date: Sat, 3 May 2008 00:52:41 +0100 Subject: Fedora and JPackage proprietary JDK shims In-Reply-To: <80d7e4090805021244m5f1882fbwfea1a240d3bf56a5@mail.gmail.com> References: <80d7e4090805021244m5f1882fbwfea1a240d3bf56a5@mail.gmail.com> Message-ID: <20080502235241.GA23888@urchin.earth.li> On Fri, May 02, 2008 at 01:44:04PM -0600, Stephen John Smoogen wrote: > On Fri, May 2, 2008 at 1:33 PM, Colin Walters wrote: > > On Fri, May 2, 2008 at 3:16 PM, Les Mikesell wrote: > > > > > > I can say that OpenNMS won't currently work with a 1.6 version because it's > > > developers have said so. > > > > So what you're really saying is Fedora doesn't support Java < 6 very > > well. I don't think anyone would disagree, but you have to understand > > it's not a very interesting problem; these projects should really be > > working to update for 6, regardless of Fedora or OpenJDK - Java 5 is > > in pure maintenance mode now. Surely this is the key in this discussion. I would imagine people are agreed that Fedora isn't going to stay at 1.4 or below. Once you've accepted 1.5, IME 1.6 is a small step. > > I'm sure there's a fair amount of software out there that doesn't work > > on Java 6, but it's not "most" by a long shot. I echo that from my experiences (both professional and personal). > It depends on the sphere of software... 90% of our business software > only works on 1.4.2 and the other 10% only works on 1.5. And so does > all of the java apps the company programmers have written to work with > the closed source stuff. When we asked when they would support 1.6.. > the word was they weren't.. they would go to 1.7 when it was released > or .NET because Java was just not 'stable' enough for them. > > While thats all closed source.. the mindset affects others who work on > Java in the open. Just to chime in with a very differing experience. I work for a pretty large company (whose business is not IT, but has a significant IT department) with quite a few internal Java apps. My team has been using 1.6 for all current development for some time. Most others I'm aware of are using at least 1.5. Both here and at a previous company we've moved forward major JVM versions to pick up useful new features or obscure bug/performance fixes - the latter not ideal upgrade reasons obviously. :) The JRE installed on desktops (and so what any GUI-apps will be using) is 1.5. As you say.... it depends. In my team's main product we use a lot of open sources libraries and components, and a few commercial (totally close source) ones too. IME, anyone whose product is reasonably active will not be ignoring 1.6. Cheers -- Stuart From a.badger at gmail.com Sat May 3 00:01:59 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 02 May 2008 17:01:59 -0700 Subject: Fedora and JPackage proprietary JDK shims In-Reply-To: References: Message-ID: <481BAB77.30302@gmail.com> Colin Walters wrote: > Bottom line - should Fedora ship the proprietary JDK shim? I don't > think it's worth the user confusion over just telling people to go to > JPackage, but if someone stepped up, did the work, and submitted it > and was going to maintain/own it, it might happen. > If "proprietary JDK shim" is the nosrc.rpm for the proprietary JDK's I don't think it should go into Fedora. -Toshio From rc040203 at freenet.de Fri May 2 14:11:58 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 02 May 2008 16:11:58 +0200 Subject: New Sponsor Request: Denis Leroy In-Reply-To: <1209735916.11031.9.camel@kennedy> References: <1209735916.11031.9.camel@kennedy> Message-ID: <1209737518.3203.167.camel@beck.corsepiu.local> We (the sponsors) once had a mailing list to discuss nominations, because we did not want to expose private comments on a public list. What has happened to that list? Ralf From ndbecker2 at gmail.com Sat May 3 00:16:52 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 02 May 2008 20:16:52 -0400 Subject: Fix for cvs tag issue Message-ID: I know I encountered this once before, but forgot how to fix. cvs update -d -P (creates F-9 dir) cd F-9 make tag cvs tag -c Cython-0_9_6_13_1-3_fc9 ERROR: The tag Cython-0_9_6_13_1-3_fc9 is already applied on a different branch That tag is already on devel branch. What is the process to fix this? From ndbecker2 at gmail.com Sat May 3 00:20:26 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 02 May 2008 20:20:26 -0400 Subject: Fedora Package Status of May 3, 2008 References: <20080503010742.1b41ccab@ludwig-alpha.unil.ch> Message-ID: I'm pretty sure I did make tag build in devel (and I think F-9) for unuran. should be unuran-1.2.4p1-1. From greno at verizon.net Sat May 3 00:30:28 2008 From: greno at verizon.net (Gerry Reno) Date: Fri, 02 May 2008 20:30:28 -0400 Subject: F9 installation issues Message-ID: <481BB224.3050505@verizon.net> I've had a good number of problems when installing F9 in partitioning scenarios that are more than just very simple one drive setups. So I ran a series of tests today and put some results in a bug that I have opened on these problems: https://bugzilla.redhat.com/show_bug.cgi?id=443451 For example, I have yet to get anaconda/druid to properly install using any type of RAID setup. Even a very simple, 2 drive setup fails. I can get the software to install but anaconda cannot seem to install the bootloader correctly so I either see GRUB or grub> after the Reboot. And in more complex scenario like using LVM over RAID (which I use all the time), anaconda gets a whole bunch of Unhandled Exceptions. These things should be fixed before the F9 final release. F9 needs to be able to handle all the RAIDed systems out there and right now it won't be able to do that. Gerry From dev at nigelj.com Sat May 3 00:36:26 2008 From: dev at nigelj.com (Nigel Jones) Date: Sat, 03 May 2008 12:36:26 +1200 Subject: ndesk-dbus adoption (was: Fedora Package Status of May 3, 2008) In-Reply-To: <20080503010742.1b41ccab@ludwig-alpha.unil.ch> References: <20080503010742.1b41ccab@ludwig-alpha.unil.ch> Message-ID: <481BB38A.1040500@nigelj.com> Christian Iseli wrote: > - 91 packages not available in devel or release > dev at nigelj dot com pAgenda Opps, looks like I'll have to fix this. > - 21 orphaned packages, yet available in devel > AGReader PyOpenGL aasaver beagle emesene f-spot gnome-applet-tvn24 > gnome-ppp kbiof libgringotts libical lipstik multiget nautilus-share > ndesk-dbus ndesk-dbus-glib osmo pygtkglext rafkill xdms xeuphoric > Ekkk! Podsleuth needs ndesk-dbus, so if no-one has any objections, I'll adopt the two packages (ndesk-dbus & ndesk-dbus-glib. - Nigel From tmus at tmus.dk Sat May 3 00:39:23 2008 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Fri, 02 May 2008 22:39:23 -0200 Subject: autofs no longer in default install In-Reply-To: <20080502205451.F225D26FA07@magilla.localdomain> References: <20080502202155.DA61F26FA07@magilla.localdomain> <20080502203105.GB23239@nostromo.devel.redhat.com> <20080502205451.F225D26FA07@magilla.localdomain> Message-ID: Roland McGrath wrote: > Is it in the release notes? It can be listed under "gratuitous major > aggravations". I guess there isn't a way without a million extra clicks to > ask for it at install time. Another five magic commands to type after > every new install before anything works right. Joy oh joy. > The thing is, that what is great for one may be bad for the other. Removing autofs from the default install means one less thing to kill after each install. Yet other changes may make my life more difficult and yours easier. I guess that how it always will be. Luckily it's not too hard to customize install if you need lots and lots of machines. /Thomas From dev at nigelj.com Sat May 3 00:40:39 2008 From: dev at nigelj.com (Nigel Jones) Date: Sat, 03 May 2008 12:40:39 +1200 Subject: Fix for cvs tag issue In-Reply-To: References: Message-ID: <481BB487.1040901@nigelj.com> Neal Becker wrote: > I know I encountered this once before, but forgot how to fix. > > cvs update -d -P > (creates F-9 dir) > cd F-9 > make tag > cvs tag -c Cython-0_9_6_13_1-3_fc9 > ERROR: The tag Cython-0_9_6_13_1-3_fc9 is already applied on a different > branch > > That tag is already on devel branch. > > What is the process to fix this? > > It's already tagged -fc9 because of the way the branching happens, check out http://cvs.fedoraproject.org/viewcvs/rpms/Cython/F-9/Cython.spec?rev=1.1&view=log you don't need to do anything more than a cvs update -d -P :) - N.J. From konrad at tylerc.org Sat May 3 00:40:45 2008 From: konrad at tylerc.org (Konrad Meyer) Date: Fri, 2 May 2008 17:40:45 -0700 Subject: Fedora and JPackage proprietary JDK shims In-Reply-To: <3118d8de0805021332p53bb68eascab41bb0c49f1286@mail.gmail.com> References: <3118d8de0805021332p53bb68eascab41bb0c49f1286@mail.gmail.com> Message-ID: <200805021740.45795.konrad@tylerc.org> Quoth Jason Corley: > > Colin Walters wrote: > > Perhaps; I've personally only used the jpackage shims on RHEL (which > > is much closer to jpackage's target audience). > > At JPackage we support as many distros as we can that we have users > and developers for. To say we focus on RHEL (or any distro) is > incorrect as that absolutely is not the target of the project. Nor is > exclusive support for Fedora, OpenSuSE, or Mandriva. All of those > added together (and then some more thrown in) are our focus. I believe Colin meant more that JPackage targeted EL distributions such as RHEL (or SLES, etc) more than distributions like Fedora. (I don't have any idea if this is correct or not, but I don't think he meant to say that JPackage only targets RHEL.) Regards, -- Conrad Meyer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From walters at verbum.org Sat May 3 00:41:30 2008 From: walters at verbum.org (Colin Walters) Date: Fri, 2 May 2008 20:41:30 -0400 Subject: Fedora and JPackage proprietary JDK shims In-Reply-To: <481B752F.5040908@gmail.com> References: <481B752F.5040908@gmail.com> Message-ID: On Fri, May 2, 2008 at 4:10 PM, Les Mikesell wrote: > > Yes, as in what pretty much all existing large projects use. I actually > haven't investigated this much beyond OpenNMS and would be happy to hear > otherwise about opengrok, alfresco, openfire, spark etc. OpenGrok is in Fedora. We actually use openfire on the Mugshot servers which are running OpenJDK 6, though we have some modifications. > Do you have some examples of large and useful things like those above? I > suppose jboss should be the canonical example. Besides the above, just look at all of the Java software in Fedora and JPackage now. Pretty much all of it should be JDK 6 compatible. > > Really...it's in a lot of FAQs, etc. > > > > Are any of them fedora-hosted where a user would likely look for this > information? Not "officially", but: http://www.fedorafaq.org/#java Anyways, what I'm saying is that largely the Fedora Java efforts are focused around OpenJDK 6+, and over time as those remaining projects fix their software the need for what you're asking for should go away. From notting at redhat.com Sat May 3 00:43:08 2008 From: notting at redhat.com (Bill Nottingham) Date: Fri, 2 May 2008 20:43:08 -0400 Subject: F9 installation issues In-Reply-To: <481BB224.3050505@verizon.net> References: <481BB224.3050505@verizon.net> Message-ID: <20080503004308.GA32161@nostromo.devel.redhat.com> Gerry Reno (greno at verizon.net) said: > I've had a good number of problems when installing F9 in partitioning > scenarios that are more than just very simple one drive setups. > > So I ran a series of tests today and put some results in a bug that I have > opened on these problems: > https://bugzilla.redhat.com/show_bug.cgi?id=443451 > > For example, I have yet to get anaconda/druid to properly install using any > type of RAID setup. Even a very simple, 2 drive setup fails. I can get the > software to install but anaconda cannot seem to install the bootloader > correctly so I either see GRUB or grub> after the Reboot. > > And in more complex scenario like using LVM over RAID (which I use all the > time), anaconda gets a whole bunch of Unhandled Exceptions. > > These things should be fixed before the F9 final release. F9 needs to be > able to handle all the RAIDed systems out there and right now it > won't be able to do that. >From reading the bug, it seems to be a rather specific issue with the kernel and your storage chipset, rather than a general issue. Are there other AMD 790FX users out there? Bill From a.badger at gmail.com Sat May 3 00:44:16 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 02 May 2008 17:44:16 -0700 Subject: Wiki page - HowToGetSponsored In-Reply-To: <20080502230241.GA30356@killefiz> References: <20080502230241.GA30356@killefiz> Message-ID: <481BB560.6070907@gmail.com> Sven Lankes wrote: >> (List of Sponsors) - >> The list of sponsors is only visible to >> contributors with a Fedora Account. > > (List of Sponsors) links to > https://admin.fedoraproject.org/accounts/dump-group.cgi?group=cvsextras&role_type=sponsor&format=html > which results in an "Internal Server Error". > > Looking around I found > https://admin.fedoraproject.org/accounts/group/view/cvsextras to be the > closest replacement for the above link - but it doesn't allow allow to > only list sponsors - is there some url-magic I'm missing that will > filter the list to only show sponsors? > We've recently switched to a new and improved account system. It looks like this particular magic got lost. I think that for this use, we should be pointing people at the new page https://admin.fedoraproject.org/accounts/group/view/cvsextras but add an option to filter by role_type. The other option at the moment is to download the file from this location: https://admin.fedoraproject.org/accounts/group/dump?groupname=cvsextras and grep for sponsor I'll open a ticket against FAS (Fedora Account System) to decide where to provide such a filter. If you could add some of this information to the wiki that would be appreciated. -Toshio From tmus at tmus.dk Sat May 3 00:43:23 2008 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Fri, 02 May 2008 22:43:23 -0200 Subject: autofs no longer in default install In-Reply-To: <604aa7910805021406q5f9b3e7lc6dec30da2256e73@mail.gmail.com> References: <20080502202155.DA61F26FA07@magilla.localdomain> <20080502203105.GB23239@nostromo.devel.redhat.com> <20080502205451.F225D26FA07@magilla.localdomain> <1209675651.29415.13.camel@localhost.localdomain> <604aa7910805021406q5f9b3e7lc6dec30da2256e73@mail.gmail.com> Message-ID: Jeff Spaleta wrote: > 2008/5/1 Jesse Keating : >> Perhaps the default Fedora install isn't really designed for your use >> case. > > Man i really wish we had a collection of pre-cooked kickstart files > aimed at specific use case. I have this gut feeling that if people > with similar server needs got together they could agree on a small > finite set of kickstart offerings that helped several easily defined > setups. > > -jef > That might be neat. Perhaps if it could be integrated in the installer boot menu in some way (press F6, select your auto-install mode and off-we-go...)-ish. /Thomas From bpepple at fedoraproject.org Sat May 3 01:15:18 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Fri, 2 May 2008 21:15:18 -0400 Subject: New Sponsor Request: Denis Leroy In-Reply-To: <1209737518.3203.167.camel@beck.corsepiu.local> References: <1209735916.11031.9.camel@kennedy> <1209737518.3203.167.camel@beck.corsepiu.local> Message-ID: On Fri, May 2, 2008 at 10:11 AM, Ralf Corsepius wrote: > We (the sponsors) once had a mailing list to discuss nominations, > because we did not want to expose private comments on a public list. > > What has happened to that list? I believe we used to use the fedora-maintainers-list, which was shut down in the fall. If you can think of a better list to use, I have no problem with moving the discussion there. /B From greno at verizon.net Sat May 3 01:30:55 2008 From: greno at verizon.net (Gerry Reno) Date: Fri, 02 May 2008 21:30:55 -0400 Subject: F9 installation issues In-Reply-To: <20080503004308.GA32161@nostromo.devel.redhat.com> References: <481BB224.3050505@verizon.net> <20080503004308.GA32161@nostromo.devel.redhat.com> Message-ID: <481BC04F.4020908@verizon.net> Bill Nottingham wrote: > Gerry Reno (greno at verizon.net) said: > >> I've had a good number of problems when installing F9 in partitioning >> scenarios that are more than just very simple one drive setups. >> >> So I ran a series of tests today and put some results in a bug that I have >> opened on these problems: >> https://bugzilla.redhat.com/show_bug.cgi?id=443451 >> >> For example, I have yet to get anaconda/druid to properly install using any >> type of RAID setup. Even a very simple, 2 drive setup fails. I can get the >> software to install but anaconda cannot seem to install the bootloader >> correctly so I either see GRUB or grub> after the Reboot. >> >> And in more complex scenario like using LVM over RAID (which I use all the >> time), anaconda gets a whole bunch of Unhandled Exceptions. >> >> These things should be fixed before the F9 final release. F9 needs to be >> able to handle all the RAIDed systems out there and right now it >> won't be able to do that. >> > > >From reading the bug, it seems to be a rather specific issue with the > kernel and your storage chipset, rather than a general issue. Are there > other AMD 790FX users out there? > > Bill > > I'm sure there are a lot of them but they probably aren't reading this list. The 790 chipset is just the latest of the AMD 7-series chipsets and has been out in the hands of vendors for a good while and the 790 has generally been available on m/b since last year. Once I get Fedora to load and boot the system runs just fine. I don't see any errors in /var/log/messages and I don't notice any type of drive problems. And the fact that I can get the system to install in certain scenarios tells me that the chipset is probably not the problem. So why should this chipset be a candidate for being the source of these install problems when otherwise it operates the drive system just fine? With anaconda receiving a great deal of changes lately, I suspect the installer more than this chipset. Regards, Gerry From notting at redhat.com Sat May 3 01:35:27 2008 From: notting at redhat.com (Bill Nottingham) Date: Fri, 2 May 2008 21:35:27 -0400 Subject: F9 installation issues In-Reply-To: <481BC04F.4020908@verizon.net> References: <481BB224.3050505@verizon.net> <20080503004308.GA32161@nostromo.devel.redhat.com> <481BC04F.4020908@verizon.net> Message-ID: <20080503013527.GB2469@nostromo.devel.redhat.com> Gerry Reno (greno at verizon.net) said: > So why should this chipset be a candidate for being the source of these > install problems when otherwise it operates the drive system just fine? I/O error == can't read the disk/drives. Bill From jwboyer at gmail.com Sat May 3 01:47:04 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 02 May 2008 20:47:04 -0500 Subject: New Sponsor Request: Denis Leroy In-Reply-To: References: <1209735916.11031.9.camel@kennedy> <1209737518.3203.167.camel@beck.corsepiu.local> Message-ID: <1209779225.26179.9.camel@vader.jdub.homelinux.org> On Fri, 2008-05-02 at 21:15 -0400, Brian Pepple wrote: > On Fri, May 2, 2008 at 10:11 AM, Ralf Corsepius wrote: > > We (the sponsors) once had a mailing list to discuss nominations, > > because we did not want to expose private comments on a public list. > > > > What has happened to that list? > > I believe we used to use the fedora-maintainers-list, which was shut > down in the fall. If you can think of a better list to use, I have no > problem with moving the discussion there. I thought it was cvsextras-sponsors at fedoraproject.org ? That's where all the requests come in (still), and I'm almost certain that is where the discussion took place. josh From greno at verizon.net Sat May 3 01:52:26 2008 From: greno at verizon.net (Gerry Reno) Date: Fri, 02 May 2008 21:52:26 -0400 Subject: F9 installation issues In-Reply-To: <20080503013527.GB2469@nostromo.devel.redhat.com> References: <481BB224.3050505@verizon.net> <20080503004308.GA32161@nostromo.devel.redhat.com> <481BC04F.4020908@verizon.net> <20080503013527.GB2469@nostromo.devel.redhat.com> Message-ID: <481BC55A.3060303@verizon.net> Bill Nottingham wrote: > Gerry Reno (greno at verizon.net) said: > >> So why should this chipset be a candidate for being the source of these >> install problems when otherwise it operates the drive system just fine? >> > > I/O error == can't read the disk/drives. > or: I/O error = code trying to read wrong device. Regards, Gerry From greno at verizon.net Sat May 3 02:02:17 2008 From: greno at verizon.net (Gerry Reno) Date: Fri, 02 May 2008 22:02:17 -0400 Subject: F9 installation issues In-Reply-To: <481BC55A.3060303@verizon.net> References: <481BB224.3050505@verizon.net> <20080503004308.GA32161@nostromo.devel.redhat.com> <481BC04F.4020908@verizon.net> <20080503013527.GB2469@nostromo.devel.redhat.com> <481BC55A.3060303@verizon.net> Message-ID: <481BC7A9.8070907@verizon.net> Other people are seeing a number of installer problems and they aren't using a 790 chipset. So I think it's pretty clear that my chipset has nothing to do with these installer issues. http://kernelreloaded.blog385.com/wp-content/uploads/eee-f9-4.png http://kernelreloaded.blog385.com/index.php/archives/my-eeexperience-with-fedora-9/ Regards, Gerry From bpepple at fedoraproject.org Sat May 3 02:03:58 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Fri, 2 May 2008 22:03:58 -0400 Subject: New Sponsor Request: Denis Leroy In-Reply-To: <1209779225.26179.9.camel@vader.jdub.homelinux.org> References: <1209735916.11031.9.camel@kennedy> <1209737518.3203.167.camel@beck.corsepiu.local> <1209779225.26179.9.camel@vader.jdub.homelinux.org> Message-ID: On Fri, May 2, 2008 at 9:47 PM, Josh Boyer wrote: > > I thought it was cvsextras-sponsors at fedoraproject.org ? That's where > all the requests come in (still), and I'm almost certain that is where > the discussion took place. Cool. Let me send it there then. /B From mjs at clemson.edu Sat May 3 02:05:37 2008 From: mjs at clemson.edu (Matthew Saltzman) Date: Fri, 02 May 2008 22:05:37 -0400 Subject: Fedora and JPackage proprietary JDK shims In-Reply-To: <481BAB77.30302@gmail.com> References: <481BAB77.30302@gmail.com> Message-ID: <1209780338.22699.10.camel@valkyrie.localdomain> On Fri, 2008-05-02 at 17:01 -0700, Toshio Kuratomi wrote: > Colin Walters wrote: > > Bottom line - should Fedora ship the proprietary JDK shim? I don't > > think it's worth the user confusion over just telling people to go to > > JPackage, but if someone stepped up, did the work, and submitted it > > and was going to maintain/own it, it might happen. > > > > If "proprietary JDK shim" is the nosrc.rpm for the proprietary JDK's I > don't think it should go into Fedora. Not sure, but I bet the "shim" is the java-sun-compat package that lets you install the Sun RPM, then sets up alternatives and other symlinks to make the expected incantations work. That is not a nosrc package, though it may have no actual source. It depends on the Sun RPM from java.sun.com. > > -Toshio > > -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From dtimms at iinet.net.au Sat May 3 02:18:21 2008 From: dtimms at iinet.net.au (David Timms) Date: Sat, 03 May 2008 12:18:21 +1000 Subject: Fedora Package Status of May 3, 2008 In-Reply-To: References: <20080503010742.1b41ccab@ludwig-alpha.unil.ch> Message-ID: <481BCB6D.8070400@iinet.net.au> Jason L Tibbitts III wrote: > Note to self: don't lean on random keys while spellchecker is running. I thought you might have been using some new fangled speech recognition software ... and it's friday night ;-) From jspaleta at gmail.com Sat May 3 02:31:46 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 2 May 2008 18:31:46 -0800 Subject: F9 installation issues In-Reply-To: <481BC7A9.8070907@verizon.net> References: <481BB224.3050505@verizon.net> <20080503004308.GA32161@nostromo.devel.redhat.com> <481BC04F.4020908@verizon.net> <20080503013527.GB2469@nostromo.devel.redhat.com> <481BC55A.3060303@verizon.net> <481BC7A9.8070907@verizon.net> Message-ID: <604aa7910805021931v12ee903cm1cad51449ebf7534@mail.gmail.com> On Fri, May 2, 2008 at 6:02 PM, Gerry Reno wrote: > Other people are seeing a number of installer problems and they aren't using > a 790 chipset. So I think it's pretty clear that my chipset has nothing to > do with these installer issues. > > http://kernelreloaded.blog385.com/wp-content/uploads/eee-f9-4.png > > > http://kernelreloaded.blog385.com/index.php/archives/my-eeexperience-with-fedora-9/ Uhm the eee is pretty specialized... i wouldn't necessarily hold that up as 'typical'.. -jef From notting at redhat.com Sat May 3 02:36:21 2008 From: notting at redhat.com (Bill Nottingham) Date: Fri, 2 May 2008 22:36:21 -0400 Subject: F9 installation issues In-Reply-To: <481BC7A9.8070907@verizon.net> References: <481BB224.3050505@verizon.net> <20080503004308.GA32161@nostromo.devel.redhat.com> <481BC04F.4020908@verizon.net> <20080503013527.GB2469@nostromo.devel.redhat.com> <481BC55A.3060303@verizon.net> <481BC7A9.8070907@verizon.net> Message-ID: <20080503023621.GA5190@nostromo.devel.redhat.com> Gerry Reno (greno at verizon.net) said: > Other people are seeing a number of installer problems and they aren't > using a 790 chipset. So I think it's pretty clear that my chipset has > nothing to do with these installer issues. The only thing these situations have in common is that there's a traceback. >From looking at the trace posted in that screenshot, it's a case of bug 439633, which seems unrelated to the issues you are seeing. Bill From dtimms at iinet.net.au Sat May 3 02:39:15 2008 From: dtimms at iinet.net.au (David Timms) Date: Sat, 03 May 2008 12:39:15 +1000 Subject: [Fwd: Apport] In-Reply-To: References: <1209765295.8872.0.camel@localhost.localdomain> <1209770788.7350.65.camel@metroid.rdu.redhat.com> Message-ID: <481BD053.1030201@iinet.net.au> Kevin Kofler wrote: > special format for crash reports, it's just a GDB backtrace. If GDB is not > installed, KCrash just displays an error that no backtrace could be obtained > because GDB is not installed. What would you think of that message instead stating some helpful text, with a button to invoke PackageKit to install the good stuff so that a useful backtrace could be generated ? Is it too late to get a backtrace if you didn't already have gdb and the needed -debuginfo's installed ? From walters at verbum.org Sat May 3 03:42:35 2008 From: walters at verbum.org (Colin Walters) Date: Fri, 2 May 2008 23:42:35 -0400 Subject: Fedora and JPackage proprietary JDK shims In-Reply-To: <1209780338.22699.10.camel@valkyrie.localdomain> References: <481BAB77.30302@gmail.com> <1209780338.22699.10.camel@valkyrie.localdomain> Message-ID: On Fri, May 2, 2008 at 10:05 PM, Matthew Saltzman wrote: > > Not sure, but I bet the "shim" is the java-sun-compat package that lets > you install the Sun RPM, then sets up alternatives and other symlinks to > make the expected incantations work. That is not a nosrc package, > though it may have no actual source. It depends on the Sun RPM from > java.sun.com. Yeah, that's what was under discussion, or at least it's what I thought Les wanted. From jonstanley at gmail.com Sat May 3 03:46:24 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Fri, 2 May 2008 23:46:24 -0400 Subject: New Sponsor Request: Denis Leroy In-Reply-To: References: <1209735916.11031.9.camel@kennedy> <1209737518.3203.167.camel@beck.corsepiu.local> <1209779225.26179.9.camel@vader.jdub.homelinux.org> Message-ID: On Fri, May 2, 2008 at 10:03 PM, Brian Pepple wrote: > Cool. Let me send it there then. Problem with sending it there (as the lone sponsor in 'fedorabugs') is that the administrators don't get mail that's sent there (not sure if that's a problem with cvsextras or not). I agree that such a discussion shouldn't be held in public, however. From sundaram at fedoraproject.org Sat May 3 03:49:32 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 03 May 2008 09:19:32 +0530 Subject: Multilib Middle-Ground In-Reply-To: <481B99C4.6030303@gmail.com> References: <4817FF36.10305@redhat.com> <481A19BA.6090705@gmail.com> <604aa7910805011244q78338786y956500dd55649441@mail.gmail.com> <604aa7910805011549i47c6193bs177e57cea293dd75@mail.gmail.com> <481B3A70.6070509@gmail.com> <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> <481B5A10.9010308@gmail.com> <481B5CC3.3090806@redhat.com> <481B60DB.90202@gmail.com> <1209755408.6004.7.camel@rousalka.okg> <481B6FA9.7000300@gmail.com> <1209761234.6848.19.camel@rousalka.okg> <481B8C0E.5070800@gmail.com> <481B9451.3020504@gmail.com> <481B99C4.6030303@gmail.com> Message-ID: <481BE0CC.8020705@fedoraproject.org> Les Mikesell wrote: > Kevin Kofler wrote: >> Les Mikesell gmail.com> writes: >>> There never was a trap - just some lies about one. >> >> You clearly haven't understood what Free Software is about. > > It's not that I don't understand, I just don't agree that it is the only > way. Or that anything with an interface spec can ever be a trap Except that Sun Java itself has internal non-standard and undocumented com.sun* interfaces and programs relying on it won't work on GCJ or necessarily even between different revisions of the same JVM. Pretty much ever major vendor using Java has their own VM that is atleast in part incompatible with each other: Sun, Oracle, BEA, IBM ... Rahul From walters at verbum.org Sat May 3 04:11:07 2008 From: walters at verbum.org (Colin Walters) Date: Sat, 3 May 2008 00:11:07 -0400 Subject: Multilib Middle-Ground In-Reply-To: <481B8C0E.5070800@gmail.com> References: <4817FF36.10305@redhat.com> <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> <481B5A10.9010308@gmail.com> <481B5CC3.3090806@redhat.com> <481B60DB.90202@gmail.com> <1209755408.6004.7.camel@rousalka.okg> <481B6FA9.7000300@gmail.com> <1209761234.6848.19.camel@rousalka.okg> <481B8C0E.5070800@gmail.com> Message-ID: On Fri, May 2, 2008 at 5:47 PM, Les Mikesell wrote: > > > > The point is that for years fedora has had a scheme of package > requirements and no standard-compliant JVM that provided them. And it has a > strange symlinked path scheme that needs to be fixed when installing a > standard JVM. I find the symlink/alternatives structure *so much* better than having to munge the PATH and JAVA_HOME environment variables that I don't understand why you're complaining about it. > You are confusing 2 issues. By standard-compliant, I mean the language > spec which does exist and as far as I know, nothing fedora has ever shipped, > meets. I couldn't find the status of OpenJDK 6 is with respect to the TCK in a brief search, but if Fedora's shipped package didn't pass I think it would be regarded as an important bug. From a.badger at gmail.com Sat May 3 04:40:37 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 02 May 2008 21:40:37 -0700 Subject: Fedora and JPackage proprietary JDK shims In-Reply-To: References: <481BAB77.30302@gmail.com> <1209780338.22699.10.camel@valkyrie.localdomain> Message-ID: <481BECC5.7060203@gmail.com> Colin Walters wrote: > On Fri, May 2, 2008 at 10:05 PM, Matthew Saltzman wrote: >> Not sure, but I bet the "shim" is the java-sun-compat package that lets >> you install the Sun RPM, then sets up alternatives and other symlinks to >> make the expected incantations work. That is not a nosrc package, >> though it may have no actual source. It depends on the Sun RPM from >> java.sun.com. > > Yeah, that's what was under discussion, or at least it's what I > thought Les wanted. > I know Les mentioned the nosrc rpms in the same email as he complained that Fedora wasn't shipping something that he felt was necessary for java-on-Fedora. So I thought it best to have that clarified. -Toshio From lesmikesell at gmail.com Sat May 3 06:01:56 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Sat, 03 May 2008 01:01:56 -0500 Subject: Multilib Middle-Ground In-Reply-To: References: <4817FF36.10305@redhat.com> <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> <481B5A10.9010308@gmail.com> <481B5CC3.3090806@redhat.com> <481B60DB.90202@gmail.com> <1209755408.6004.7.camel@rousalka.okg> <481B6FA9.7000300@gmail.com> <1209761234.6848.19.camel@rousalka.okg> <481B8C0E.5070800@gmail.com> Message-ID: <481BFFD4.1000909@gmail.com> Colin Walters wrote: > >>>> The point is that for years fedora has had a scheme of package >> requirements and no standard-compliant JVM that provided them. And it has a >> strange symlinked path scheme that needs to be fixed when installing a >> standard JVM. > > I find the symlink/alternatives structure *so much* better than having > to munge the PATH and JAVA_HOME environment variables that I don't > understand why you're complaining about it. One complaint is that it subverts something obviously intended to be a per-process choice into a per-machine configuration. What do you do if you, or different users, need to simultaneously run different versions of JVM's - something that seems likely during any transition where you'd want to keep the old version running until you have thoroughly tested its replacement? But, given that the alternatives structure is there even with its limitations, the real issue is that there have been long periods of time when you could not find a java-sun-compat package documented to work with the current fedora version and that's not something you want to set up by hand. >> You are confusing 2 issues. By standard-compliant, I mean the language >> spec which does exist and as far as I know, nothing fedora has ever shipped, >> meets. > > I couldn't find the status of OpenJDK 6 is with respect to the TCK in > a brief search, but if Fedora's shipped package didn't pass I think it > would be regarded as an important bug. And you'll just ignore the entire prior history of fedora? -- Les Mikesell lesmikesell at gmail.com From lesmikesell at gmail.com Sat May 3 06:03:32 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Sat, 03 May 2008 01:03:32 -0500 Subject: Fedora and JPackage proprietary JDK shims In-Reply-To: <481BECC5.7060203@gmail.com> References: <481BAB77.30302@gmail.com> <1209780338.22699.10.camel@valkyrie.localdomain> <481BECC5.7060203@gmail.com> Message-ID: <481C0034.7040304@gmail.com> Toshio Kuratomi wrote: > Colin Walters wrote: >> On Fri, May 2, 2008 at 10:05 PM, Matthew Saltzman >> wrote: >>> Not sure, but I bet the "shim" is the java-sun-compat package that lets >>> you install the Sun RPM, then sets up alternatives and other >>> symlinks to >>> make the expected incantations work. That is not a nosrc package, >>> though it may have no actual source. It depends on the Sun RPM from >>> java.sun.com. >> >> Yeah, that's what was under discussion, or at least it's what I >> thought Les wanted. >> > I know Les mentioned the nosrc rpms in the same email as he complained > that Fedora wasn't shipping something that he felt was necessary for > java-on-Fedora. So I thought it best to have that clarified. Yes the java-sun-compat package is the missing piece. Whether it's actually included in fedora or not isn't particularly important, but its location should be documented and there have been long intervals of time when no jpackage.org support existed for current fedora revisions. My impression was that this was intentional on fedora's part but perhaps that was mistaken. -- Les Mikesell lesmikesell at gmail.com From rc040203 at freenet.de Sat May 3 03:56:09 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 03 May 2008 05:56:09 +0200 Subject: New Sponsor Request: Denis Leroy In-Reply-To: References: <1209735916.11031.9.camel@kennedy> <1209737518.3203.167.camel@beck.corsepiu.local> <1209779225.26179.9.camel@vader.jdub.homelinux.org> Message-ID: <1209786970.2954.7.camel@beck.corsepiu.local> On Fri, 2008-05-02 at 23:46 -0400, Jon Stanley wrote: > On Fri, May 2, 2008 at 10:03 PM, Brian Pepple wrote: > > > Cool. Let me send it there then. > > Problem with sending it there (as the lone sponsor in 'fedorabugs') is > that the administrators Which administrators are you talking about? This list was supposed to be only visible/readable to sponsors, not to nominees nor to arbitrary admins nor to arbitrary readers. > don't get mail that's sent there (not sure if > that's a problem with cvsextras or not). We once had the convention that all sponsors were obliged to be subscribed on this "list". I don't recall if it had been an automated process. > I agree that such a > discussion shouldn't be held in public, however. Sure. The purpose of this list had been to vote on nominees before they had been presented to FESCO. Ralf PS: I wonder if the fact no sponsors have been nominated for a very long time and the fact we are discussing details of the nomination process, which actually should "just work", is a reflection of the sponsorship model having failed. From Matt_Domsch at dell.com Sat May 3 02:09:01 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 2 May 2008 21:09:01 -0500 Subject: [Fwd: Apport] In-Reply-To: References: <1209765295.8872.0.camel@localhost.localdomain> <1209770788.7350.65.camel@metroid.rdu.redhat.com> Message-ID: <20080503020901.GC29284@auslistsprd01.us.dell.com> On Fri, May 02, 2008 at 11:45:18PM +0000, Kevin Kofler wrote: > Will Woods redhat.com> writes: > > I couldn't find details on a crash-report format specific to KDE but if > > someone wants to point me at some existing work in this area I'd > > appreciate it. > > KDE has something called KCrash. KCrash intercepts crashes in KDE applications > and brings up a crash window with 2 tabs. The first tab is just the > usually "Sorry, I have crashed" boilerplate, the second tab is for backtraces: > switching to that second tab causes KCrash to invoke GDB and attach it to the > executable, obtaining a backtrace which is displayed in a text box on that tab; > there are 2 buttons on the tab: one to copy the backtrace to the clipboard, one > to save it to a file. And of course the dialog has a Close button. There is no > special format for crash reports, it's just a GDB backtrace. If GDB is not > installed, KCrash just displays an error that no backtrace could be obtained > because GDB is not installed. GDB is a 6.5MB RPM. If we're offering package group selections, such as "volunteer bug reporter", which includes these tools, we could add gdb to that group. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From surenkarapetyan at gmail.com Sat May 3 07:11:08 2008 From: surenkarapetyan at gmail.com (Suren Karapetyan) Date: Sat, 03 May 2008 12:11:08 +0500 Subject: Apt autoupdates Message-ID: <481C100C.50901@gmail.com> Hi there! Yesterday I was playing with synaptic (so I installed apt, ...) Today in the morning I received a message from fcron telling that apt has successfully upgraded my PC to the latest rawhide (Before it I kept old Xorg and Kernel to run Nvidia drivers: yum update --exclude...). IIRC yum-updatesd isn't configured to update without asking so my question is: Is it desired for apt "CHECK_ONLY=no" in default /etc/sysconfig/apt. Thanks From Christian.Iseli at unil.ch Sat May 3 07:21:30 2008 From: Christian.Iseli at unil.ch (Christian Iseli) Date: Sat, 3 May 2008 09:21:30 +0200 Subject: Fedora Package Status of May 3, 2008 In-Reply-To: References: <20080503010742.1b41ccab@ludwig-alpha.unil.ch> Message-ID: <20080503092130.6e473d01@ludwig-alpha.unil.ch> On 02 May 2008 18:28:47 -0500, Jason L Tibbitts III wrote: > I was thinking of either separating out the > non-sponsor reviews or picking a cutoff of something like 100 reviews > and sticking those above it into a Hall of Fame or semis. There's > really no point in a dick size war once you get that far up into the > stratosphere, and we could probably do without the hilariously huge > bug lists. The "Hall of Fame" idea is rather appealing. I'll look into it. I agree the bug list is probably useless there. > Clicking on the one next to my name gets me "This list is > too long for Bagel's little mind". This got me scratching my head for a little while, wondering if you had found a new cute name for BZ :-) > In any case, now I have plenty of people to investigate for > sponsorship status. That, and 37 "nobody" tickets to clean up. > Thanks for doing this. You are welcome. Cheers, C From kevin.kofler at chello.at Sat May 3 08:06:12 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 3 May 2008 08:06:12 +0000 (UTC) Subject: Multilib Middle-Ground References: <4817FF36.10305@redhat.com> <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> <481B5A10.9010308@gmail.com> <481B5CC3.3090806@redhat.com> <481B60DB.90202@gmail.com> <1209755408.6004.7.camel@rousalka.okg> <481B6FA9.7000300@gmail.com> <1209761234.6848.19.camel@rousalka.okg> <481B8C0E.5070800@gmail.com> <481BFFD4.1000909@gmail.com> Message-ID: Les Mikesell gmail.com> writes: > And you'll just ignore the entire prior history of fedora? You mean the prior history of _Java_! Fedora merely shipped the only available option which was Free Software. Blame Sun Microsystems for not having made their implementation Free Software right from the start. Kevin Kofler From j.w.r.degoede at hhs.nl Sat May 3 08:12:00 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 03 May 2008 10:12:00 +0200 Subject: Orphaned packages (was Re: ndesk-dbus adoption) In-Reply-To: <481BB38A.1040500@nigelj.com> References: <20080503010742.1b41ccab@ludwig-alpha.unil.ch> <481BB38A.1040500@nigelj.com> Message-ID: <481C1E50.9050009@hhs.nl> Nigel Jones wrote: > Christian Iseli wrote: >> - 91 packages not available in devel or release >> dev at nigelj dot com pAgenda > Opps, looks like I'll have to fix this. >> - 21 orphaned packages, yet available in devel >> AGReader PyOpenGL aasaver beagle emesene f-spot gnome-applet-tvn24 >> gnome-ppp kbiof libgringotts libical lipstik multiget nautilus-share >> ndesk-dbus ndesk-dbus-glib osmo pygtkglext rafkill xdms xeuphoric >> Good catch Nigel, PyOpenGL and pygtkglext are needed by glchess, which is part of gnome-games. These are not orphaned, I released them and rafkill for Xavier to pick them up, Xavier? Regards, Hans From laxathom at fedoraproject.org Sat May 3 08:23:07 2008 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Sat, 3 May 2008 10:23:07 +0200 Subject: Orphaned packages (was Re: ndesk-dbus adoption) In-Reply-To: <481C1E50.9050009@hhs.nl> References: <20080503010742.1b41ccab@ludwig-alpha.unil.ch> <481BB38A.1040500@nigelj.com> <481C1E50.9050009@hhs.nl> Message-ID: <62bc09df0805030123i2e5aeb6fh4bcc165f7d775af3@mail.gmail.com> 2008/5/3 Hans de Goede : > Nigel Jones wrote: > > > Christian Iseli wrote: > > > > > - 91 packages not available in devel or release > > > dev at nigelj dot com pAgenda > > > > > Opps, looks like I'll have to fix this. > > > > > - 21 orphaned packages, yet available in devel > > > AGReader PyOpenGL aasaver beagle emesene f-spot gnome-applet-tvn24 > > > gnome-ppp kbiof libgringotts libical lipstik multiget > > > nautilus-share > > > ndesk-dbus ndesk-dbus-glib osmo pygtkglext rafkill xdms xeuphoric > > > > > > > > > > > Good catch Nigel, PyOpenGL and pygtkglext are needed by glchess, which is > part of gnome-games. These are not orphaned, I released them and rafkill for > Xavier to pick them up, Xavier? Do these packages need a rebuid ? They all shoud already take over by me. I'll have a look in case i misse one of them. > > Regards, > > Hans > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From mschwendt at gmail.com Sat May 3 08:52:27 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Sat, 3 May 2008 10:52:27 +0200 Subject: bodhi questions Message-ID: <20080503105227.e21d411b.mschwendt@gmail.com> 1) Does the nvr input box work for anyone? It used to work long ago, but here no longer finds any builds. I had to cut'n'paste a build tag into it. 2) Bug numbers: bodhi says it accepts CVE aliases. Hence I entered CVE-2007-6061 which is an alias for bug 393251. It didn't reject it, but later on no bug number appeared in my request. If I had known that, I would have entered the bug number and not the alias. Instead, and possibly 3), I got internal server error 500 for two consecutive update requests, although they made it into the system. 4) Security updates: it confuses me a lot that I can choose to push to stable, but the request is modified to push to "testing" instead. Apparently, because approval from the security team is needed. The request then reads "Requested: testing" without any indication that "stable" was requested. -- Fedora release 8 (Werewolf) - Linux 2.6.23.15-137.fc8 loadavg: 1.83 1.66 1.43 From j.w.r.degoede at hhs.nl Sat May 3 09:47:30 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 03 May 2008 11:47:30 +0200 Subject: Orphaned packages (was Re: ndesk-dbus adoption) In-Reply-To: <62bc09df0805030123i2e5aeb6fh4bcc165f7d775af3@mail.gmail.com> References: <20080503010742.1b41ccab@ludwig-alpha.unil.ch> <481BB38A.1040500@nigelj.com> <481C1E50.9050009@hhs.nl> <62bc09df0805030123i2e5aeb6fh4bcc165f7d775af3@mail.gmail.com> Message-ID: <481C34B2.8070201@hhs.nl> Xavier Lamien wrote: > 2008/5/3 Hans de Goede : > >> Nigel Jones wrote: >> >>> Christian Iseli wrote: >>> >>>> - 91 packages not available in devel or release >>>> dev at nigelj dot com pAgenda >>>> >>> Opps, looks like I'll have to fix this. >>> >>>> - 21 orphaned packages, yet available in devel >>>> AGReader PyOpenGL aasaver beagle emesene f-spot gnome-applet-tvn24 >>>> gnome-ppp kbiof libgringotts libical lipstik multiget >>>> nautilus-share >>>> ndesk-dbus ndesk-dbus-glib osmo pygtkglext rafkill xdms xeuphoric >>>> >>>> >> >> >> Good catch Nigel, PyOpenGL and pygtkglext are needed by glchess, which is >> part of gnome-games. These are not orphaned, I released them and rafkill for >> Xavier to pick them up, Xavier? > > > > Do these packages need a rebuid ? Nope > They all shoud already take over by me. > I'll have a look in case i misse one of them. > If you've taken ownership of them in pkgdb all is well, maybe the script just ran in the window they were unowned? Regards, Hans From tim at niemueller.de Sat May 3 10:24:40 2008 From: tim at niemueller.de (Tim Niemueller) Date: Sat, 03 May 2008 12:24:40 +0200 Subject: Fedora Robotics SIG Message-ID: <481C3D68.8030306@niemueller.de> Hi Fedora users. Responding to Paul's blog entry that we use Fedora on our robots for autonomous robot soccer games and service robotics provoked some echoes. After making it more public what we do on Planet Fedora Jeff Spaleta asked me to start a Robotics SIG - so we do now! I ask everybody who is interested in robotics to join the effort and bring robotics related software into Fedora and make it fit to power robots, to provide educational tools for robotics starters and to make it a good distro to develop for robots in general. I have setup a wiki page at http://fedoraproject.org/wiki/SIGs/Robotics. Please visit and add yourself if you are interested. I have tentatively scheduled an IRC meeting for next Wednesday, May 7th at 15:00 UTC on IRC (see wiki page). Let us know if you want to participate but the time just happens not to be when you are awake so that we can agree on a time where we max the number of participants. If there are enough people interested we can think about creating a fedora-robotics-list. My personal interest in this is mobile robotics and embodied artificial intelligence. I think Jeff noted some specific interest in the educational sector of robotics. Robotics is a wide field so we need more people involved, maybe even with other specific interest in particluar sub-domains of the field. The plan is to start identifying interesting software projects that would be worth packaging (and license compatible, always a problem in this field), targeting some robotics-related problems (hardware support comes to my mind) and try to find solutions. Join now, robotics is a lot of fund and many robots can be built with a small budget already. Regards from Aachen, Tim -- Tim Niemueller www.niemueller.de ================================================================= Imagination is more important than knowledge. (Albert Einstein) From steve at xemacs.org Sat May 3 10:36:35 2008 From: steve at xemacs.org (SL Baur) Date: Sat, 3 May 2008 03:36:35 -0700 Subject: Multilib Middle-Ground In-Reply-To: References: <4817FF36.10305@redhat.com> <604aa7910805011549i47c6193bs177e57cea293dd75@mail.gmail.com> <481B3A70.6070509@gmail.com> <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> <481B5A10.9010308@gmail.com> <604aa7910805021124s1997ad8erec66f2522e413bd8@mail.gmail.com> <481B79C7.7000404@gmail.com> <604aa7910805021347l5e59ff9cj40146b9f1dd0672@mail.gmail.com> <481B88C9.7030707@gmail.com> Message-ID: On 5/2/08, Kevin Kofler wrote: > Les Mikesell gmail.com> writes: > > > Can't you just always provide at least 2 versioned libraries? One > > essentially equivalent to the latest released RHEL or Centos version(s) > > and the other whatever flavor is current? And unless apps need > > something new, build them against the stable version. > > > Fedora is about CURRENT technology. They will ALWAYS prefer the CURRENT version > of the libraries if it is at all possible. Why should Fedora build against an > old one? You are using the wrong distribution. There are some libraries that are never worth extinction. Berkeley DB is one of them. It's a data file format and special. I can see how the ancient 1.8.x wouldn't be loved here, but it's still *stupid* dropping it even as an option. *STUPID*. > We can't ship unmaintained old versions forever. No, but dropping stuff before they break or while there are users[1] is Just Plain Stupid. -sb (Yes, I suppose I do have an axe to grind). [1] Especially Enterprise users in the case of RHEL. From gnomeuser at gmail.com Sat May 3 11:02:37 2008 From: gnomeuser at gmail.com (David Nielsen) Date: Sat, 3 May 2008 13:02:37 +0200 Subject: ndesk-dbus adoption (was: Fedora Package Status of May 3, 2008) In-Reply-To: <481BB38A.1040500@nigelj.com> References: <20080503010742.1b41ccab@ludwig-alpha.unil.ch> <481BB38A.1040500@nigelj.com> Message-ID: <1dedbbfc0805030402t6df28630u8cc455204e2f5147@mail.gmail.com> 2008/5/3 Nigel Jones : > > - 21 orphaned packages, yet available in devel > > beagle > > I believe Adel is still a co-maintainer on beagle and he has been actively doing updates to this package. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundaram at fedoraproject.org Sat May 3 11:13:34 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 03 May 2008 16:43:34 +0530 Subject: Apt autoupdates In-Reply-To: <481C100C.50901@gmail.com> References: <481C100C.50901@gmail.com> Message-ID: <481C48DE.9010004@fedoraproject.org> Suren Karapetyan wrote: > Hi there! > Yesterday I was playing with synaptic (so I installed apt, ...) > Today in the morning I received a message from fcron telling that apt > has successfully upgraded my PC to the latest rawhide (Before it I kept > old Xorg and Kernel to run Nvidia drivers: yum update --exclude...). > IIRC yum-updatesd isn't configured to update without asking so my > question is: > Is it desired for apt "CHECK_ONLY=no" in default /etc/sysconfig/apt. Yeah. Auto updates without asking the user isn't consistent with the behaviour of the rest of the package management systems. Rahul From pertusus at free.fr Sat May 3 11:32:18 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 3 May 2008 13:32:18 +0200 Subject: Multilib Middle-Ground In-Reply-To: References: <604aa7910805011549i47c6193bs177e57cea293dd75@mail.gmail.com> <481B3A70.6070509@gmail.com> <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> <481B5A10.9010308@gmail.com> <604aa7910805021124s1997ad8erec66f2522e413bd8@mail.gmail.com> <481B79C7.7000404@gmail.com> <604aa7910805021347l5e59ff9cj40146b9f1dd0672@mail.gmail.com> <481B88C9.7030707@gmail.com> Message-ID: <20080503113218.GA2965@free.fr> On Sat, May 03, 2008 at 03:36:35AM -0700, SL Baur wrote: > > > We can't ship unmaintained old versions forever. > > No, but dropping stuff before they break or while there are users[1] > is Just Plain > Stupid. You can submit compat packages to fedora for the old berkeley db versions. If you do so, it may be wise to ask here and also contact the maintainer of the current version before, to see if there is disagreement. -- Pat From rawhide at fedoraproject.org Sat May 3 11:44:06 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Sat, 3 May 2008 11:44:06 +0000 (UTC) Subject: rawhide report: 20080503 changes Message-ID: <20080503114406.812A5209D01@releng1.fedora.phx.redhat.com> Updated Packages: PackageKit-0.1.12-9.20080502.fc9 -------------------------------- * Fri May 02 2008 Richard Hughes - 0.1.12-9.20080502 - Pull in the new snapshot from the stable PACKAGEKIT_0_1_X branch. - Fixes rh#444612, which is a release blocker. PolicyKit-gnome-0.8-4.fc9 ------------------------- * Thu May 01 2008 David Zeuthen - 0.8-4.fc9 - Don't spawn stuff under gdm fedora-release-9-1 ------------------ * Thu May 01 2008 Jesse Keating - 9-1 - Make the final package, set the release name. * Tue Apr 22 2008 Jesse Keating - 9-0.1.rc - Make version 9 for yum, rpm version clearly a pre-release. * Fri Apr 11 2008 Jesse Keating - 8.93-1 - Update for preview release - Turn off rawhide, turn on others, rely on mirrormanager redirection gnome-packagekit-0.1.12-12.20080430.fc9 --------------------------------------- * Fri May 02 2008 Richard Hughes - 0.1.12-12.20080430 - Add some more stuff to the GPG patch to fix point 3) of rh#444826 gthumb-2.10.8-3.fc9 ------------------- * Fri May 02 2008 David Zeuthen - 2.10.8-3 - Drop x-content patch and provide gthumb-importer and a desktop file for it (#444635) initscripts-8.76-1 ------------------ * Fri May 02 2008 Bill Nottingham - 8.76-1 - fix tcsh syntax error (#444998) - remove debugging cruft from rcS-sulogin kdebase-workspace-4.0.3-20.fc9 ------------------------------ * Fri May 02 2008 Rex Dieter 4.0.3-20 - Requires: kdebase , so it doesn't go missing on upgrades from kde3 (#444928) * Mon Apr 28 2008 Luk???? Tinkl 4.0.3-19 - #444141: Initial wallpaper chooser has "EOS" preselected but wallpaper is "Fedora Waves" man-pages-fr-2.79.0-4.fc9 ------------------------- * Fri May 02 2008 Alain Portal 2.79.0-4 - Remove vipw.8 already in shadow-utils. Fix #444868. nautilus-2.22.2-7.fc9 --------------------- * Fri May 02 2008 David Zeuthen - 2.22.2-7 - Default to "Ask what to do" for all actions (#444639) * Wed Apr 30 2008 Tomas Bzatek - 2.22.2-6 - Mask file moving to nautilus-cd-burner window as copy operation (#443944) - Don't allow recursive move/copy into itself (gnomebz #530720) * Thu Apr 17 2008 Matthias Clasen - 2.22.2-5 - Make "Open Folder" work as expected for media handling pungi-1.2.17-1.fc9 ------------------ * Thu May 01 2008 Jesse Keating - 1.2.17-1 - Add a config file for Fedora 9. rhgb-1:9.0.0-6.fc9 ------------------ * Fri May 02 2008 Ray Strode - 1:9.0.0-6 - Use abstract sockets by default * Fri May 02 2008 Matthias Clasen - 1:9.0.0-5 - Remove debug spew * Fri May 02 2008 Matthias Clasen - 1:9.0.0-4 - Make the splash on 800x480 (#444944) shared-mime-info-0.23-9.fc9 --------------------------- * Fri May 02 2008 David Zeuthen - 0.23-9 - Fix defaults for x-content/image-dcf (#445032) system-config-date-1.9.30-2.fc9 ------------------------------- * Fri May 02 2008 Jeremy Katz - 1.9.30-2 - Add patch to handle '_' vs ' ' mismatch for zone names (#444093) Broken deps for ppc64 ---------------------------------------------------------- livecd-tools-016-1.fc9.ppc64 requires yaboot perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot From jwboyer at gmail.com Sat May 3 12:13:13 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Sat, 03 May 2008 07:13:13 -0500 Subject: New Sponsor Request: Denis Leroy In-Reply-To: <1209786970.2954.7.camel@beck.corsepiu.local> References: <1209735916.11031.9.camel@kennedy> <1209737518.3203.167.camel@beck.corsepiu.local> <1209779225.26179.9.camel@vader.jdub.homelinux.org> <1209786970.2954.7.camel@beck.corsepiu.local> Message-ID: <1209816793.18545.2.camel@vader.jdub.homelinux.org> On Sat, 2008-05-03 at 05:56 +0200, Ralf Corsepius wrote: > PS: I wonder if the fact no sponsors have been nominated for a very long > time and the fact we are discussing details of the nomination process, > which actually should "just work", is a reflection of the sponsorship > model having failed. Maybe. Or it could also be a reflection on the fact that we don't have a lack of existing sponsors and adding more isn't going to do a whole lot. josh From eric.tanguy at univ-nantes.fr Sat May 3 14:13:39 2008 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Sat, 03 May 2008 16:13:39 +0200 Subject: bodhi questions In-Reply-To: <20080503105227.e21d411b.mschwendt@gmail.com> References: <20080503105227.e21d411b.mschwendt@gmail.com> Message-ID: <481C7313.5090902@univ-nantes.fr> Michael Schwendt a ?crit : > 1) Does the nvr input box work for anyone? It used to work long ago, but > here no longer finds any builds. I had to cut'n'paste a build tag into it. > Same here since few weeks. > 2) Bug numbers: bodhi says it accepts CVE aliases. Hence I entered > CVE-2007-6061 which is an alias for bug 393251. It didn't reject it, > but later on no bug number appeared in my request. If I had known that, > I would have entered the bug number and not the alias. > > Instead, and possibly 3), I got internal server error 500 for two > consecutive update requests, although they made it into the system. > > 4) Security updates: it confuses me a lot that I can choose to push > to stable, but the request is modified to push to "testing" instead. > Apparently, because approval from the security team is needed. > The request then reads "Requested: testing" without any indication > that "stable" was requested. > > Eric From bpepple at fedoraproject.org Sat May 3 15:15:51 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sat, 03 May 2008 11:15:51 -0400 Subject: FESCo Nominations Message-ID: <1209827751.10075.2.camel@kennedy> Hi all, It's that time of year again. Everyone that wants to run for the next FESCo needs to nominate him/herself for it by June 1st, 2008 0:00 UTC; that self-nomination should contain some information's like "Mission Statement, Past work summary and Future plans". Please place your nomination on this page in the wiki: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Nominations The actual election will start on Tuesday, June 3rd, 2008 0:01 UTC and will last until Monday, June 9th, 2008 23:59 UTC. The results will be posted to the fedora-devel list. The first meeting of the "new" FESCo will be on Thursday, June 12th, 2008 on #fedora-meeting at 17:00 UTC, and a new chair will be elected. For more information regarding the election, please refer to: http://fedoraproject.org/wiki/PackageMaintainers/Policy/FESCoElections Thanks, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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: 197 bytes Desc: This is a digitally signed message part URL: From surenkarapetyan at gmail.com Sat May 3 15:33:54 2008 From: surenkarapetyan at gmail.com (Suren Karapetyan) Date: Sat, 03 May 2008 20:33:54 +0500 Subject: Apt autoupdates In-Reply-To: <481C48DE.9010004@fedoraproject.org> References: <481C100C.50901@gmail.com> <481C48DE.9010004@fedoraproject.org> Message-ID: <481C85E2.9090607@gmail.com> Rahul Sundaram wrote: > Suren Karapetyan wrote: >> Hi there! >> Yesterday I was playing with synaptic (so I installed apt, ...) >> Today in the morning I received a message from fcron telling that apt >> has successfully upgraded my PC to the latest rawhide (Before it I >> kept old Xorg and Kernel to run Nvidia drivers: yum update >> --exclude...). >> IIRC yum-updatesd isn't configured to update without asking so my >> question is: >> Is it desired for apt "CHECK_ONLY=no" in default /etc/sysconfig/apt. > > Yeah. Auto updates without asking the user isn't consistent with the > behaviour of the rest of the package management systems. > > Rahul > Should I file a bug? Cause it's really annoying... It installs a new init script without any notice, makes it run by default and makes it update your system... without asking you. For yum at least we have seperate package yum-updatesd so even if it made autoupdates default the name makes you check for a new init script. And it can really screw the system. Today I spent an hour and ~100M traffic to bring the things back. Well traffic doesn't mean much for me (it's cool to work for an ISP) but some people may have problems with it. From walters at verbum.org Sat May 3 15:41:19 2008 From: walters at verbum.org (Colin Walters) Date: Sat, 3 May 2008 11:41:19 -0400 Subject: Multilib Middle-Ground In-Reply-To: <481BFFD4.1000909@gmail.com> References: <4817FF36.10305@redhat.com> <481B5CC3.3090806@redhat.com> <481B60DB.90202@gmail.com> <1209755408.6004.7.camel@rousalka.okg> <481B6FA9.7000300@gmail.com> <1209761234.6848.19.camel@rousalka.okg> <481B8C0E.5070800@gmail.com> <481BFFD4.1000909@gmail.com> Message-ID: On Sat, May 3, 2008 at 2:01 AM, Les Mikesell wrote: > > One complaint is that it subverts something obviously intended to be a > per-process choice into a per-machine configuration. What do you do if you, > or different users, need to simultaneously run different versions of JVM's - > something that seems likely during any transition where you'd want to keep > the old version running until you have thoroughly tested its replacement? You set PATH and JAVA_HOME, just like you did before. What the alternatives system gives you is a sane way to make one the default, which you need to have it integrated with other components of the operating system. > But, given that the alternatives structure is there even with its > limitations, the real issue is that there have been long periods of time > when you could not find a java-sun-compat package documented to work with > the current fedora version and that's not something you want to set up by > hand. I don't see a lot of value in continuing to discuss this, given that in the near future all supported Fedora releases (8 and 9) will have built-in very complete Free Java implementations. From sundaram at fedoraproject.org Sat May 3 15:41:38 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 03 May 2008 21:11:38 +0530 Subject: Apt autoupdates In-Reply-To: <481C85E2.9090607@gmail.com> References: <481C100C.50901@gmail.com> <481C48DE.9010004@fedoraproject.org> <481C85E2.9090607@gmail.com> Message-ID: <481C87B2.1000209@fedoraproject.org> Suren Karapetyan wrote: > Should I file a bug? > Cause it's really annoying... It installs a new init script without any > notice, makes it run by default and makes it update your system... > without asking you. Yeah. You should file a bug report. Rahul From lesmikesell at gmail.com Sat May 3 16:20:15 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Sat, 03 May 2008 11:20:15 -0500 Subject: Multilib Middle-Ground In-Reply-To: References: <4817FF36.10305@redhat.com> <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> <481B5A10.9010308@gmail.com> <481B5CC3.3090806@redhat.com> <481B60DB.90202@gmail.com> <1209755408.6004.7.camel@rousalka.okg> <481B6FA9.7000300@gmail.com> <1209761234.6848.19.camel@rousalka.okg> <481B8C0E.5070800@gmail.com> <481BFFD4.1000909@gmail.com> Message-ID: <481C90BF.5080805@gmail.com> Kevin Kofler wrote: > Les Mikesell gmail.com> writes: >> And you'll just ignore the entire prior history of fedora? > > You mean the prior history of _Java_! If you mean the reason it - and much of the other currently open source software exists at all, you shouldn't ignore that either. As much as I like open source and freely available code, I recognize that much would never have existed if it were not for original proprietary work - and that we are all better off as a result of everyone's participation with the proprietary version. > Fedora merely shipped the only available option which was Free Software. Blame > Sun Microsystems for not having made their implementation Free Software right > from the start. I blame fedora for not maintaining a relationship with japackage.org until their users no longer need what they provide. In fact, I don't see any reason any java code needs to be specialized for a distribution or included in its own repository. Why not just make fedora work with an external repo for java that works across distributions/versions and avoid the issue entirely instead of shipping something that isn't quite java? Even when a real java can be included, what is the point of having specialized distro/version packages of the apps that don't need specialization? -- Les Mikesell lesmikesell at gmail.com From sundaram at fedoraproject.org Sat May 3 16:41:31 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 03 May 2008 22:11:31 +0530 Subject: Multilib Middle-Ground In-Reply-To: <481C90BF.5080805@gmail.com> References: <4817FF36.10305@redhat.com> <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> <481B5A10.9010308@gmail.com> <481B5CC3.3090806@redhat.com> <481B60DB.90202@gmail.com> <1209755408.6004.7.camel@rousalka.okg> <481B6FA9.7000300@gmail.com> <1209761234.6848.19.camel@rousalka.okg> <481B8C0E.5070800@gmail.com> <481BFFD4.1000909@gmail.com> <481C90BF.5080805@gmail.com> Message-ID: <481C95BB.20203@fedoraproject.org> Les Mikesell wrote: In fact, I don't > see any reason any java code needs to be specialized for a distribution > or included in its own repository. Why not just make fedora work with > an external repo for java that works across distributions/versions and > avoid the issue entirely instead of shipping something that isn't quite > java? Even when a real java can be included, what is the point of > having specialized distro/version packages of the apps that don't need > specialization? There is no "specialization" usually necessary for including software in the repository. Fedora avoids specialization by being close to upstream usually. Relying on a external repository for Java would mean that we can't include any Java programs within Fedora. Parts of Openoffice.org, Eclipse and dozens of programs were introduced into the repository because of the work that went into GCJ, classpath etc and even OpenJDK has benefited from that now. Rahul From surenkarapetyan at gmail.com Sat May 3 17:27:33 2008 From: surenkarapetyan at gmail.com (Suren Karapetyan) Date: Sat, 03 May 2008 22:27:33 +0500 Subject: Apt autoupdates In-Reply-To: <481C87B2.1000209@fedoraproject.org> References: <481C100C.50901@gmail.com> <481C48DE.9010004@fedoraproject.org> <481C85E2.9090607@gmail.com> <481C87B2.1000209@fedoraproject.org> Message-ID: <481CA085.1010207@gmail.com> Rahul Sundaram wrote: > Suren Karapetyan wrote: > >> Should I file a bug? >> Cause it's really annoying... It installs a new init script without >> any notice, makes it run by default and makes it update your >> system... without asking you. > > Yeah. You should file a bug report. > > Rahul > Done :) https://bugzilla.redhat.com/show_bug.cgi?id=445096 From nicolas.mailhot at laposte.net Sat May 3 18:00:06 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 03 May 2008 20:00:06 +0200 Subject: Multilib Middle-Ground In-Reply-To: <481BFFD4.1000909@gmail.com> References: <4817FF36.10305@redhat.com> <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> <481B5A10.9010308@gmail.com> <481B5CC3.3090806@redhat.com> <481B60DB.90202@gmail.com> <1209755408.6004.7.camel@rousalka.okg> <481B6FA9.7000300@gmail.com> <1209761234.6848.19.camel@rousalka.okg> <481B8C0E.5070800@gmail.com> <481BFFD4.1000909@gmail.com> Message-ID: <1209837606.19169.3.camel@rousalka.okg> Le samedi 03 mai 2008 ? 01:01 -0500, Les Mikesell a ?crit : > One complaint is that it subverts something obviously intended to be a > per-process choice into a per-machine configuration. What do you do if > you, or different users, need to simultaneously run different versions > of JVM's You write the bits needed to support switching jvms at the user level via environment variables, and you submit them to jpp for merge in jpackage-utils. This has been explicitely marked as a welcome enhancement for five years http://www.jpackage.org/cgi-bin/viewvc.cgi/rpms/free/jpackage-utils/doc/jpackage-1.5-policy.xhtml?revision=1.2&root=jpackage&pathrev=MAIN#id2493509 I guess none of the people who need it want to write a line of shell script. -- 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 nicolas.mailhot at laposte.net Sat May 3 18:04:35 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 03 May 2008 20:04:35 +0200 Subject: Multilib Middle-Ground In-Reply-To: <481C95BB.20203@fedoraproject.org> References: <4817FF36.10305@redhat.com> <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> <481B5A10.9010308@gmail.com> <481B5CC3.3090806@redhat.com> <481B60DB.90202@gmail.com> <1209755408.6004.7.camel@rousalka.okg> <481B6FA9.7000300@gmail.com> <1209761234.6848.19.camel@rousalka.okg> <481B8C0E.5070800@gmail.com> <481BFFD4.1000909@gmail.com> <481C90BF.5080805@gmail.com> <481C95BB.20203@fedoraproject.org> Message-ID: <1209837875.19169.7.camel@rousalka.okg> Le samedi 03 mai 2008 ? 22:11 +0530, Rahul Sundaram a ?crit : > There is no "specialization" usually necessary for including software in > the repository. Fedora avoids specialization by being close to upstream > usually. I'm afraid a lot of the java upstreams have a long way to go before FLOSS OSes can be close to them. After drumming for years "don't think about the OS, java will hide the OS layer for you" SUN managed to create thousands of developers that actively want nothing to do with the OS problems. -- 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 nicolas.mailhot at laposte.net Sat May 3 18:14:12 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 03 May 2008 20:14:12 +0200 Subject: Multilib Middle-Ground In-Reply-To: References: <4817FF36.10305@redhat.com> <481A19BA.6090705@gmail.com> <604aa7910805011244q78338786y956500dd55649441@mail.gmail.com> <604aa7910805011549i47c6193bs177e57cea293dd75@mail.gmail.com> <481B3A70.6070509@gmail.com> <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> <481B5A10.9010308@gmail.com> <481B5CC3.3090806@redhat.com> <481B60DB.90202@gmail.com> <481B6871.5000101@gmail.com> <481B93B0.205@gmail.com> Message-ID: <1209838452.19169.15.camel@rousalka.okg> Le vendredi 02 mai 2008 ? 22:31 +0000, Kevin Kofler a ?crit : > JPackage has no guideline which forbids Free packages to have dependencies > (RPM "Requires:") on non-Free ones, and there are some which do, even where it > is possible to build the package without that dependency. Fedora had to patch > out those dependencies when importing those packages. I don't remember the > exact affected packages, but I do remember there were some packages which had > non-Free dependencies removed as part of the import into Fedora. Well the right way would have been to provide a replacement for the proprietary crap, not to remove user functionality. If you can put a FLOSS JVM under most jpp packages, that's because the deps are meant to be replaced by FLOSS stuff (and when they can't because the FLOSS project decided it would be smart not to copy the proprietary blob layout, the deps are changed at request). Many jpackage rpms were created before FLOSS replacements existed. I'm sorry we lacked the cristal ball to predict what would or would not have a FLOSS alternatives later. We knew most of it would get alternatives ? otherwise it would have been a lot less work just to hardcode a particular JVM everywhere like everyone else was doing (and still is BTW). -- 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 wwoods at redhat.com Sat May 3 18:14:35 2008 From: wwoods at redhat.com (Will Woods) Date: Sat, 3 May 2008 14:14:35 -0400 Subject: [Fwd: Apport] In-Reply-To: <20080503020901.GC29284@auslistsprd01.us.dell.com> References: <1209765295.8872.0.camel@localhost.localdomain> <1209770788.7350.65.camel@metroid.rdu.redhat.com> <20080503020901.GC29284@auslistsprd01.us.dell.com> Message-ID: <76098E9F-75D0-470A-8580-741E7ED5283B@redhat.com> On May 2, 2008, at 10:09 PM, Matt Domsch wrote: > GDB is a 6.5MB RPM. If we're offering package group selections, such > as "volunteer bug reporter", which includes these tools, we could add > gdb to that group. Since both bug-buddy and kcrash use it, gdb is already present on nearly every installed system. Having a 'QA Tools' package group is a pretty great idea. But first.. we need some tools. -w From jwboyer at gmail.com Sat May 3 18:16:18 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Sat, 03 May 2008 13:16:18 -0500 Subject: FESCo Nominations In-Reply-To: <1209827751.10075.2.camel@kennedy> References: <1209827751.10075.2.camel@kennedy> Message-ID: <1209838578.4908.4.camel@vader.jdub.homelinux.org> On Sat, 2008-05-03 at 11:15 -0400, Brian Pepple wrote: > Hi all, > > It's that time of year again. Everyone that wants to run for the next > FESCo needs to nominate him/herself for it by June 1st, 2008 0:00 UTC; > that self-nomination should contain some information's like "Mission > Statement, Past work summary and Future plans". > > Please place your nomination on this page in the wiki: > http://fedoraproject.org/wiki/Extras/SteeringCommittee/Nominations > > The actual election will start on Tuesday, June 3rd, 2008 0:01 UTC and > will last until Monday, June 9th, 2008 23:59 UTC. The results will be > posted to the fedora-devel list. The first meeting of the "new" FESCo > will be on Thursday, June 12th, 2008 on #fedora-meeting at 17:00 UTC, > and a new chair will be elected. > > For more information regarding the election, please refer to: > http://fedoraproject.org/wiki/PackageMaintainers/Policy/FESCoElections It should be noted that this is the first FESCo election that reduces the overall number of FESCo members to 9, down from 13. That's important, as the smaller number of members will hopefully produce a bit more competition for seats. So if you're interested in representing a particular group or subject matter as a FESCo member (packager, developer, Docs, etc) it would be a good idea to put that in your nomination page. Echoing Paul in the Board elections, it's very important we get a great turnout of both nominees and _voters_ in order to make the elections successful. We look forward to your participation. josh From wwoods at redhat.com Sat May 3 18:21:55 2008 From: wwoods at redhat.com (Will Woods) Date: Sat, 3 May 2008 14:21:55 -0400 Subject: [Fwd: Apport] In-Reply-To: <481BD053.1030201@iinet.net.au> References: <1209765295.8872.0.camel@localhost.localdomain> <1209770788.7350.65.camel@metroid.rdu.redhat.com> <481BD053.1030201@iinet.net.au> Message-ID: <315E41F8-541D-401E-BC75-5005C35C494F@redhat.com> On May 2, 2008, at 10:39 PM, David Timms wrote: > Kevin Kofler wrote: >> special format for crash reports, it's just a GDB backtrace. If GDB >> is not installed, KCrash just displays an error that no backtrace >> could be obtained because GDB is not installed. > What would you think of that message instead stating some helpful > text, with a button to invoke PackageKit to install the good stuff > so that a useful backtrace could be generated ? > > Is it too late to get a backtrace if you didn't already have gdb and > the needed -debuginfo's installed ? No, as long as you have the right pieces of the core dump (or, y'know, the whole thing). You can use the BuildIDs embedded in the core dump to gather the exact binaries (and associated debuginfo) used in the crash, and retrace the backtrace from there. That's part of what the server side of Apport does - takes incomplete crash dumps and retraces them. Then you can generate a hash of the trace[1] and compare that to other known crash-hashes to get automatic dup finding. Actually, if possible you'd want to generate a hash of the *un- retraced* dump too, and have the reporter app check the database of known/frequently reported crashes *before* submitting. Then the user gets: "CRASHYAPP has just crashed. This is a known problem and is being worked on by DISTRO developers. You can follow the progress of this work here: BZLINK" Wouldn't that be nice? -w [1] We'd want a special filter for the trace and/or a specialized hash function to make sure that crash dumps that are *very* similar end up with hashes that are similar or identical. From anders at trudheim.co.uk Sat May 3 18:38:38 2008 From: anders at trudheim.co.uk (Anders Karlsson) Date: Sat, 3 May 2008 20:38:38 +0200 Subject: Apt autoupdates In-Reply-To: <481C87B2.1000209@fedoraproject.org> References: <481C100C.50901@gmail.com> <481C48DE.9010004@fedoraproject.org> <481C85E2.9090607@gmail.com> <481C87B2.1000209@fedoraproject.org> Message-ID: <20080503183838.GN13403@localhost.localdomain> * Rahul Sundaram [20080503 17:47]: > Suren Karapetyan wrote: > >> Should I file a bug? >> Cause it's really annoying... It installs a new init script without any >> notice, makes it run by default and makes it update your system... without >> asking you. > > Yeah. You should file a bug report. I was under the impression that this is what 'pinning' packages was available for. I don't see this as a bug but as expected behaviour. After all, we do expect yum and it's tools up update all available packages unless we tell it not to. Now, if the packages were pinned, and the update script went ahead and updated them anyway, that would be a bug. /Anders From jspaleta at gmail.com Sat May 3 18:47:08 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 3 May 2008 10:47:08 -0800 Subject: Apt autoupdates In-Reply-To: <20080503183838.GN13403@localhost.localdomain> References: <481C100C.50901@gmail.com> <481C48DE.9010004@fedoraproject.org> <481C85E2.9090607@gmail.com> <481C87B2.1000209@fedoraproject.org> <20080503183838.GN13403@localhost.localdomain> Message-ID: <604aa7910805031147n3e16ef33r1fe9eead2165751f@mail.gmail.com> On Sat, May 3, 2008 at 10:38 AM, Anders Karlsson wrote: > I was under the impression that this is what 'pinning' packages was > available for. I don't see this as a bug but as expected > behaviour. After all, we do expect yum and it's tools up update > all available packages unless we tell it not to. AUTO updating via a scheduled cronjob is not the default behavior for yum. You should re-read the original post and the filed bugreport. -jef From surenkarapetyan at gmail.com Sat May 3 18:50:50 2008 From: surenkarapetyan at gmail.com (Suren Karapetyan) Date: Sat, 03 May 2008 23:50:50 +0500 Subject: Apt autoupdates In-Reply-To: <20080503183838.GN13403@localhost.localdomain> References: <481C100C.50901@gmail.com> <481C48DE.9010004@fedoraproject.org> <481C85E2.9090607@gmail.com> <481C87B2.1000209@fedoraproject.org> <20080503183838.GN13403@localhost.localdomain> Message-ID: <481CB40A.8080609@gmail.com> Anders Karlsson wrote: > * Rahul Sundaram [20080503 17:47]: > >> Suren Karapetyan wrote: >> >> >>> Should I file a bug? >>> Cause it's really annoying... It installs a new init script without any >>> notice, makes it run by default and makes it update your system... without >>> asking you. >>> >> Yeah. You should file a bug report. >> > > I was under the impression that this is what 'pinning' packages was > available for. I don't see this as a bug but as expected > behaviour. After all, we do expect yum and it's tools up update > all available packages unless we tell it not to. > > Now, if the packages were pinned, and the update script went ahead and > updated them anyway, that would be a bug. > > /Anders > > We expect "yum update" to update all packages. But we (or at least me) don't expect yum (nor even yum-updatesd) to update all packages nightly by default. Agree about pinning, but pinning doesn't work well for rawhide cause especially during the first half of rawhide development I would have 50%+ packages pinned. I have only one PC at home so it needs to be at least remotely stable :) From greno at verizon.net Sat May 3 18:59:31 2008 From: greno at verizon.net (Gerry Reno) Date: Sat, 03 May 2008 14:59:31 -0400 Subject: F9 installation issues In-Reply-To: <20080503023621.GA5190@nostromo.devel.redhat.com> References: <481BB224.3050505@verizon.net> <20080503004308.GA32161@nostromo.devel.redhat.com> <481BC04F.4020908@verizon.net> <20080503013527.GB2469@nostromo.devel.redhat.com> <481BC55A.3060303@verizon.net> <481BC7A9.8070907@verizon.net> <20080503023621.GA5190@nostromo.devel.redhat.com> Message-ID: <481CB613.2030406@verizon.net> Bill Nottingham wrote: > Gerry Reno (greno at verizon.net) said: > >> Other people are seeing a number of installer problems and they aren't >> using a 790 chipset. So I think it's pretty clear that my chipset has >> nothing to do with these installer issues. >> > > The only thing these situations have in common is that there's a traceback. > >From looking at the trace posted in that screenshot, it's a case of > bug 439633, which seems unrelated to the issues you are seeing. > > Bill > > I just ran a whole series of tests partitioning, creating arrays, creating volume groups, creating filesystems, writing MBR's on this machine and ran it a half dozen times - not one error. Here's the output from a session: Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. Information: You may need to update /etc/fstab. mdadm: size set to 195200K mdadm: array /dev/md0 started. mdadm: size set to 31999936K mdadm: array /dev/md1 started. mdadm: size set to 211952448K mdadm: array /dev/md2 started. mdadm: layout defaults to left-symmetric mdadm: chunk size defaults to 64K mdadm: size set to 244135616K mdadm: array /dev/md3 started. Physical volume "/dev/md1" successfully created Physical volume "/dev/md2" successfully created Physical volume "/dev/md3" successfully created Volume group "VolGroup00" successfully created Volume group "VolGroup01" successfully created Volume group "VolGroup02" successfully created Logical volume "LogVol00" created Logical volume "LogVol00" created Logical volume "LogVol00" created Setting up swapspace version 1, size = 32765898 kB LABEL=swap, UUID=f86b5d2e-0029-44bc-a18b-418a8decb840 mke2fs 1.40.8 (13-Mar-2008) Filesystem label=/boot OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) 48960 inodes, 195200 blocks 9760 blocks (5.00%) reserved for the super user First data block=1 Maximum filesystem blocks=67371008 24 block groups 8192 blocks per group, 8192 fragments per group 2040 inodes per group Superblock backups stored on blocks: 8193, 24577, 40961, 57345, 73729 Writing inode tables: done Creating journal (4096 blocks): done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 22 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. mke2fs 1.40.8 (13-Mar-2008) Warning: 256-byte inodes not usable on older systems Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) 13254656 inodes, 52987904 blocks 2649395 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=0 1618 block groups 32768 blocks per group, 32768 fragments per group 8192 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872 Writing inode tables: done Creating journal (32768 blocks): done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 35 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. mke2fs 1.40.8 (13-Mar-2008) Warning: 256-byte inodes not usable on older systems Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) 61038592 inodes, 244134912 blocks 12206745 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=0 7451 block groups 32768 blocks per group, 32768 fragments per group 8192 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 102400000, 214990848 Writing inode tables: done Creating journal (32768 blocks): done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 24 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. [root at localhost ~]# df Filesystem 1K-blocks Used Available Use% Mounted on /dev/root 4128448 2230052 1898396 55% / tmpfs 1684144 48 1684096 1% /dev/shm /dev/sr1 703812 703812 0 100% /mnt/live /dev/mapper/VolGroup01-LogVol00 208624168 191904 197834684 1% /mnt/sysimage /dev/md0 189019 5664 173595 4% /mnt/sysimage/boot /dev/mapper/VolGroup02-LogVol00 961215832 204572 912184280 1% /mnt/sysimage/var/backup [root at localhost ~]# [root at localhost ~]# dd if=/dev/zero of=/dev/sdh bs=512 count=1 1+0 records in 1+0 records out 512 bytes (512 B) copied, 0.0568583 s, 9.0 kB/s [root at localhost ~]# The problem is with Anaconda and not my system! I can load Windows, Debian, Ubuntu. I see no evidence of any problem with this machine as far as performing installation activities to include 8 drives with LVM over RAID as demonstrated with the simulated installation sessions that I just ran. This session used all of the 8 drives and created three LVM Volume Groups over three RAID arrays, created ext3 filesystems on the LV's and mounted them and wrote a MBR into the boot drive. All with no errors. So Anaconda is the problem. Regards, Gerry From lesmikesell at gmail.com Sat May 3 20:42:47 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Sat, 03 May 2008 15:42:47 -0500 Subject: Multilib Middle-Ground In-Reply-To: <481C95BB.20203@fedoraproject.org> References: <4817FF36.10305@redhat.com> <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> <481B5A10.9010308@gmail.com> <481B5CC3.3090806@redhat.com> <481B60DB.90202@gmail.com> <1209755408.6004.7.camel@rousalka.okg> <481B6FA9.7000300@gmail.com> <1209761234.6848.19.camel@rousalka.okg> <481B8C0E.5070800@gmail.com> <481BFFD4.1000909@gmail.com> <481C90BF.5080805@gmail.com> <481C95BB.20203@fedoraproject.org> Message-ID: <481CCE47.105@gmail.com> Rahul Sundaram wrote: > Les Mikesell wrote: > > In fact, I don't >> see any reason any java code needs to be specialized for a >> distribution or included in its own repository. Why not just make >> fedora work with an external repo for java that works across >> distributions/versions and avoid the issue entirely instead of >> shipping something that isn't quite java? Even when a real java can >> be included, what is the point of having specialized distro/version >> packages of the apps that don't need specialization? > > There is no "specialization" usually necessary for including software in > the repository. Why does jpackage.org have all those separate repository entries for different distros/versions if they could all be the same? > Fedora avoids specialization by being close to upstream > usually. Relying on a external repository for Java would mean that we > can't include any Java programs within Fedora. I'm very agnostic about where something comes from. Why should anyone care about that? > Parts of Openoffice.org, > Eclipse and dozens of programs were introduced into the repository > because of the work that went into GCJ, classpath etc and even OpenJDK > has benefited from that now. Being 'introduced to your repository' isn't particularly interesting to me. I'd much prefer to not be trapped by what happens to fit your policy this week. Why not include the config for the jpackage repo and let yum sort out where things come from? -- Les Mikesell lesmikesell at gmail.com From lesmikesell at gmail.com Sat May 3 20:52:02 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Sat, 03 May 2008 15:52:02 -0500 Subject: Multilib Middle-Ground In-Reply-To: <1209837606.19169.3.camel@rousalka.okg> References: <4817FF36.10305@redhat.com> <604aa7910805020907u1aa3b2b5h9630ee747f6dfeb6@mail.gmail.com> <481B5A10.9010308@gmail.com> <481B5CC3.3090806@redhat.com> <481B60DB.90202@gmail.com> <1209755408.6004.7.camel@rousalka.okg> <481B6FA9.7000300@gmail.com> <1209761234.6848.19.camel@rousalka.okg> <481B8C0E.5070800@gmail.com> <481BFFD4.1000909@gmail.com> <1209837606.19169.3.camel@rousalka.okg> Message-ID: <481CD072.5040802@gmail.com> Nicolas Mailhot wrote: > Le samedi 03 mai 2008 ? 01:01 -0500, Les Mikesell a ?crit : > >> One complaint is that it subverts something obviously intended to be a >> per-process choice into a per-machine configuration. What do you do if >> you, or different users, need to simultaneously run different versions >> of JVM's > > You write the bits needed to support switching jvms at the user level > via environment variables, and you submit them to jpp for merge in > jpackage-utils. This has been explicitely marked as a welcome > enhancement for five years > > http://www.jpackage.org/cgi-bin/viewvc.cgi/rpms/free/jpackage-utils/doc/jpackage-1.5-policy.xhtml?revision=1.2&root=jpackage&pathrev=MAIN#id2493509 > > I guess none of the people who need it want to write a line of shell > script. > Where does the alternatives system expose the information that you would need to do this? -- Les Mikesell lesmikesell at gmail.com From jspaleta at gmail.com Sat May 3 20:53:06 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 3 May 2008 12:53:06 -0800 Subject: Multilib Middle-Ground In-Reply-To: <481CCE47.105@gmail.com> References: <4817FF36.10305@redhat.com> <481B6FA9.7000300@gmail.com> <1209761234.6848.19.camel@rousalka.okg> <481B8C0E.5070800@gmail.com> <481BFFD4.1000909@gmail.com> <481C90BF.5080805@gmail.com> <481C95BB.20203@fedoraproject.org> <481CCE47.105@gmail.com> Message-ID: <604aa7910805031353n1db38bc9i9bfe82c196cafbfb@mail.gmail.com> On Sat, May 3, 2008 at 12:42 PM, Les Mikesell wrote: > Being 'introduced to your repository' isn't particularly interesting to me. > I'd much prefer to not be trapped by what happens to fit your policy this > week. Why not include the config for the jpackage repo and let yum sort out > where things come from? It is extremely doubtful that will be including any configurations for any 3rd party repositories by default based solely on legal liability issues. If the repository isn't directly under the control of the fedora project so that we can pull packages as necessary for any legal reasons which come up..then we are most lilely not going to include it by default...regardless of its contents. -jef From jonstanley at gmail.com Sat May 3 20:55:16 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Sat, 3 May 2008 16:55:16 -0400 Subject: New Sponsor Request: Denis Leroy In-Reply-To: <1209786970.2954.7.camel@beck.corsepiu.local> References: <1209735916.11031.9.camel@kennedy> <1209737518.3203.167.camel@beck.corsepiu.local> <1209779225.26179.9.camel@vader.jdub.homelinux.org> <1209786970.2954.7.camel@beck.corsepiu.local> Message-ID: On Fri, May 2, 2008 at 11:56 PM, Ralf Corsepius wrote: > Which administrators are you talking about? The following people would not receive mail sent to cvsextras-sponsors at fedoraproject.org: bpepple,bdpepple at gmail.com,Brian Pepple,administrator,7 gdk,gdk at redhat.com,Greg DeKoenigsberg,administrator,0 skvidal,skvidal at linux.duke.edu,Seth Vidal,administrator,3 sopwith,sopwith+fedora at gmail.com,Elliot Lee,administrator,21 spot,tcallawa at redhat.com,Tom Callaway,administrator,38 thl,fedora at leemhuis.info,Thorsten Leemhuis,administrator,6 wtogami,wtogami at redhat.com,Warren Togami ???,administrator,55 Are you wishing to exclude these people from the process? I think not..... > > This list was supposed to be only visible/readable to sponsors, not to > nominees nor to arbitrary admins nor to arbitrary readers. I'm not sure what other admins you're talking about. From emmanuel.seyman at club-internet.fr Sat May 3 21:25:00 2008 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Sat, 3 May 2008 23:25:00 +0200 Subject: Multilib Middle-Ground In-Reply-To: <481CCE47.105@gmail.com> References: <1209755408.6004.7.camel@rousalka.okg> <481B6FA9.7000300@gmail.com> <1209761234.6848.19.camel@rousalka.okg> <481B8C0E.5070800@gmail.com> <481BFFD4.1000909@gmail.com> <481C90BF.5080805@gmail.com> <481C95BB.20203@fedoraproject.org> <481CCE47.105@gmail.com> Message-ID: <20080503212500.GA545@orient.maison.lan> * Les Mikesell [03/05/2008 23:16] : > > I'd much prefer to not be trapped by what happens to fit your policy this > week. The only solution here is to create your own distribution. You then get to define policy and thus, that it always fits your needs to the letter. Emmanuel From jwboyer at gmail.com Sat May 3 22:23:44 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Sat, 03 May 2008 17:23:44 -0500 Subject: New Sponsor Request: Denis Leroy In-Reply-To: References: <1209735916.11031.9.camel@kennedy> <1209737518.3203.167.camel@beck.corsepiu.local> <1209779225.26179.9.camel@vader.jdub.homelinux.org> <1209786970.2954.7.camel@beck.corsepiu.local> Message-ID: <1209853425.4908.8.camel@vader.jdub.homelinux.org> On Sat, 2008-05-03 at 16:55 -0400, Jon Stanley wrote: > On Fri, May 2, 2008 at 11:56 PM, Ralf Corsepius wrote: > > > Which administrators are you talking about? > > The following people would not receive mail sent to > cvsextras-sponsors at fedoraproject.org: > > bpepple,bdpepple at gmail.com,Brian Pepple,administrator,7 > gdk,gdk at redhat.com,Greg DeKoenigsberg,administrator,0 > skvidal,skvidal at linux.duke.edu,Seth Vidal,administrator,3 > sopwith,sopwith+fedora at gmail.com,Elliot Lee,administrator,21 > spot,tcallawa at redhat.com,Tom Callaway,administrator,38 > thl,fedora at leemhuis.info,Thorsten Leemhuis,administrator,6 > wtogami,wtogami at redhat.com,Warren Togami ???,administrator,55 You didn't list what they admin. > Are you wishing to exclude these people from the process? I think not..... Well, Greg and Elliot seem to have bowed out of the packaging perspective a while ago. The rest, with the exception of Thorsten, are in FESCo and would review and discuss eventually anyway. I don't really care either way, but it seems that you're making a bit of a deal over nothing :). josh From bruno at wolff.to Sat May 3 22:46:21 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Sat, 3 May 2008 17:46:21 -0500 Subject: FESCo Nominations In-Reply-To: <1209838578.4908.4.camel@vader.jdub.homelinux.org> References: <1209827751.10075.2.camel@kennedy> <1209838578.4908.4.camel@vader.jdub.homelinux.org> Message-ID: <20080503224621.GA24868@wolff.to> On Sat, May 03, 2008 at 13:16:18 -0500, Josh Boyer wrote: > > Echoing Paul in the Board elections, it's very important we get a great > turnout of both nominees and _voters_ in order to make the elections > successful. We look forward to your participation. Is a CLA going to be enough to allow one to vote? From bpepple at fedoraproject.org Sat May 3 23:06:40 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sat, 03 May 2008 19:06:40 -0400 Subject: FESCo Nominations In-Reply-To: <20080503224621.GA24868@wolff.to> References: <1209827751.10075.2.camel@kennedy> <1209838578.4908.4.camel@vader.jdub.homelinux.org> <20080503224621.GA24868@wolff.to> Message-ID: <1209856000.19174.8.camel@kennedy> On Sat, 2008-05-03 at 17:46 -0500, Bruno Wolff III wrote: > On Sat, May 03, 2008 at 13:16:18 -0500, > Josh Boyer wrote: > > > > Echoing Paul in the Board elections, it's very important we get a great > > turnout of both nominees and _voters_ in order to make the elections > > successful. We look forward to your participation. > > Is a CLA going to be enough to allow one to vote? No, to be eligible to vote you must be a member of a fedora account group other than cla_done or cla_fedora. btw, this and other information in regard to the election can be found: http://fedoraproject.org/wiki/PackageMaintainers/Policy/FESCoElections Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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: 197 bytes Desc: This is a digitally signed message part URL: From bruno at wolff.to Sat May 3 23:30:02 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Sat, 3 May 2008 18:30:02 -0500 Subject: FESCo Nominations In-Reply-To: <1209856000.19174.8.camel@kennedy> References: <1209827751.10075.2.camel@kennedy> <1209838578.4908.4.camel@vader.jdub.homelinux.org> <20080503224621.GA24868@wolff.to> <1209856000.19174.8.camel@kennedy> Message-ID: <20080503233002.GA9890@wolff.to> On Sat, May 03, 2008 at 19:06:40 -0400, Brian Pepple wrote: > On Sat, 2008-05-03 at 17:46 -0500, Bruno Wolff III wrote: > > > > Is a CLA going to be enough to allow one to vote? > > No, to be eligible to vote you must be a member of a fedora account > group other than cla_done or cla_fedora. > > btw, this and other information in regard to the election can be found: > http://fedoraproject.org/wiki/PackageMaintainers/Policy/FESCoElections Thanks. That leaves me out of this vote, but hopefully by the time of the next one I'll be maintaining a package or two, From rodd at clarkson.id.au Sun May 4 00:18:04 2008 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Sun, 04 May 2008 10:18:04 +1000 Subject: Localisation needs to be improved Message-ID: <1209860284.3433.7.camel@localhost.localdomain> Right, time for this conversation again. I've installed f9-preview and for the most part I'm thrilled. But yet again I get to go through the hell of telling applications, printer set ups and the likes that I'm in Australia and I want to use A4, etc. In my case, this all stems from having to us US english because as a coder, most programming languages are based around US english (center, not centre, for example) and there's enough noise on the screen without underlines because I spelt something 'wrong' Regardless, there has to be plenty of people who live somewhere, but use a different language or the likes for some reason. Strangely, I get to go through this all because I picked a language and stated that I lived somewhere in the installer and the installer chooses to assume all sorts of things about where I live from the language I choose to use, rather than the location I live in. Strangely, I no loner need an xorg.conf file for X, but the installer can't seem to get something as simple as this right. I know that I can make changes to some file, and that manually I can make it work by doing this, but I shouldn't have to. ?THIS SHOULD JUST WORK! This should be a priority for f10. R. -- "It's a fine line between denial and faith. It's much better on my side" From stlwrt at gmail.com Sun May 4 00:23:44 2008 From: stlwrt at gmail.com (Pavel Shevchuk) Date: Sun, 4 May 2008 03:23:44 +0300 Subject: Localisation needs to be improved In-Reply-To: <1209860284.3433.7.camel@localhost.localdomain> References: <1209860284.3433.7.camel@localhost.localdomain> Message-ID: Could you paste "locale" output? On 5/4/08, Rodd Clarkson wrote: > Right, time for this conversation again. > > I've installed f9-preview and for the most part I'm thrilled. > > But yet again I get to go through the hell of telling applications, > printer set ups and the likes that I'm in Australia and I want to use > A4, etc. > > In my case, this all stems from having to us US english because as a > coder, most programming languages are based around US english (center, > not centre, for example) and there's enough noise on the screen without > underlines because I spelt something 'wrong' > > Regardless, there has to be plenty of people who live somewhere, but use > a different language or the likes for some reason. > > Strangely, I get to go through this all because I picked a language and > stated that I lived somewhere in the installer and the installer chooses > to assume all sorts of things about where I live from the language I > choose to use, rather than the location I live in. > > Strangely, I no loner need an xorg.conf file for X, but the installer > can't seem to get something as simple as this right. > > I know that I can make changes to some file, and that manually I can > make it work by doing this, but I shouldn't have to. ?THIS SHOULD JUST > WORK! > > This should be a priority for f10. > > > R. > -- > "It's a fine line between denial and faith. > It's much better on my side" > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- http://scwlab.com From rodd at clarkson.id.au Sun May 4 00:38:30 2008 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Sun, 04 May 2008 10:38:30 +1000 Subject: Localisation needs to be improved In-Reply-To: References: <1209860284.3433.7.camel@localhost.localdomain> Message-ID: <1209861510.12250.0.camel@localhost.localdomain> On Sun, 2008-05-04 at 03:23 +0300, Pavel Shevchuk wrote: > Could you paste "locale" output? > [rodd at localhost ~]$ locale LANG=en_US.utf8 LC_CTYPE="en_US.utf8" LC_NUMERIC="en_US.utf8" LC_TIME="en_US.utf8" LC_COLLATE="en_US.utf8" LC_MONETARY="en_US.utf8" LC_MESSAGES="en_US.utf8" LC_PAPER="en_US.utf8" LC_NAME="en_US.utf8" LC_ADDRESS="en_US.utf8" LC_TELEPHONE="en_US.utf8" LC_MEASUREMENT="en_US.utf8" LC_IDENTIFICATION="en_US.utf8" LC_ALL= [rodd at localhost ~]$ -- "It's a fine line between denial and faith. It's much better on my side" From stlwrt at gmail.com Sun May 4 00:48:45 2008 From: stlwrt at gmail.com (Pavel Shevchuk) Date: Sun, 4 May 2008 03:48:45 +0300 Subject: Localisation needs to be improved In-Reply-To: <1209861510.12250.0.camel@localhost.localdomain> References: <1209860284.3433.7.camel@localhost.localdomain> <1209861510.12250.0.camel@localhost.localdomain> Message-ID: I don't see any Australia-specific options here. You SHOULD NOT get australian currency or paper format with such locale. If i understand you correctly, you should set everything to en_AU.UTF-8, then override LC_MESSAGES with en_US.UTF-8. It will set paper and currency to Australian, but leave GUI American english On 5/4/08, Rodd Clarkson wrote: > On Sun, 2008-05-04 at 03:23 +0300, Pavel Shevchuk wrote: > > Could you paste "locale" output? > > > > > [rodd at localhost ~]$ locale > LANG=en_US.utf8 > LC_CTYPE="en_US.utf8" > LC_NUMERIC="en_US.utf8" > LC_TIME="en_US.utf8" > LC_COLLATE="en_US.utf8" > LC_MONETARY="en_US.utf8" > LC_MESSAGES="en_US.utf8" > LC_PAPER="en_US.utf8" > LC_NAME="en_US.utf8" > LC_ADDRESS="en_US.utf8" > LC_TELEPHONE="en_US.utf8" > LC_MEASUREMENT="en_US.utf8" > LC_IDENTIFICATION="en_US.utf8" > LC_ALL= > [rodd at localhost ~]$ > > > -- > > "It's a fine line between denial and faith. > It's much better on my side" > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- http://scwlab.com From jkeating at redhat.com Fri May 2 23:54:28 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 02 May 2008 19:54:28 -0400 Subject: Fedora 9 only taking blocker fixes Message-ID: <1209772468.29415.63.camel@localhost.localdomain> At this point we're trying to get Release Candidates created and as such we are only taking release blocker bugfix builds for tag requests. All other builds should be issued as updates for F9 after release. Thanks! -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From stickster at gmail.com Thu May 1 21:50:42 2008 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 01 May 2008 21:50:42 +0000 Subject: Board nominations Message-ID: <1209678642.23714.82.camel@localhost.localdomain> A few weeks after the release of Fedora 9, it will be once again time for Fedora Project Board elections[1]. This time around, as you may have heard[2], we have shifted our composition to five elected seats out of nine, instead of the previous four. Are you someone who thinks a lot about Fedora?s impact on society and the world? Do you love reading books about open standards and the free/remix culture? Do you want to work on big-picture issues as opposed to technical details? Has the time you?ve spent working in the Fedora Project brought you an appreciation for all the things our contributor community does? Then you might be just the sort of person who?s interested in a seat on the Board. The job of the Board is to advise and guide the Fedora Project, as laid out on its wiki page[3]. We try to make sure that Fedora is at all times living up to its mission of the advancement of free and open source software, and that we are doing so in an open, transparent way. Board membership carries with it a responsibility to the community to deal with thorny issues, to anticipate and serve the needs of our contributors, and to stay true to the principles on which the Project is founded. In return, you have unlimited cosmic power! That last part is not really true. In fact, the Board doesn?t really have resources of its own ? it?s the Board?s job to guide and advise, and convince other Fedora contributors of the right path to follow. It can be difficult work, but it?s rewarding to see the growth of Fedora worldwide as a reminder of how far we?ve come, and how far we?ve yet to go. If you are interested, you can simply nominate yourself by posting a message to the fedora-advisory-board list[4], and please cc: me as well. Election dates have not been set yet, but you can expect that announcement very shortly. = = = [1] http://www.redhat.com/archives/fedora-advisory-board/2008-May/msg00001.html [2] http://www.redhat.com/archives/fedora-advisory-board/2008-April/msg00083.html [3] http://fedoraproject.org/wiki/Board [4] http://www.redhat.com/mailman/listinfo/fedora-advisory-board -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From rodd at clarkson.id.au Sun May 4 00:59:47 2008 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Sun, 04 May 2008 10:59:47 +1000 Subject: Localisation needs to be improved In-Reply-To: References: <1209860284.3433.7.camel@localhost.localdomain> <1209861510.12250.0.camel@localhost.localdomain> Message-ID: <1209862787.12250.4.camel@localhost.localdomain> On Sun, 2008-05-04 at 03:48 +0300, Pavel Shevchuk wrote: > I don't see any Australia-specific options here. You SHOULD NOT get > australian currency or paper format with such locale. > > If i understand you correctly, you should set everything to > en_AU.UTF-8, then override LC_MESSAGES with en_US.UTF-8. It will set > paper and currency to Australian, but leave GUI American english > Yes, my locale output should look as you suggest. BUT, I the humble end user shouldn't have to know any of this or do anything to make it so (rather than feed the installer some appropriate information). I didn't set the setting this way, anaconda did. And anaconda has made all these assumptions because I picked a language to use on my system. I also told anaconda I live in Australia, but seemingly that information wasn't that interesting when making assumptions about where I live. R. > > On 5/4/08, Rodd Clarkson wrote: > > On Sun, 2008-05-04 at 03:23 +0300, Pavel Shevchuk wrote: > > > Could you paste "locale" output? > > > > > > > > > [rodd at localhost ~]$ locale > > LANG=en_US.utf8 > > LC_CTYPE="en_US.utf8" > > LC_NUMERIC="en_US.utf8" > > LC_TIME="en_US.utf8" > > LC_COLLATE="en_US.utf8" > > LC_MONETARY="en_US.utf8" > > LC_MESSAGES="en_US.utf8" > > LC_PAPER="en_US.utf8" > > LC_NAME="en_US.utf8" > > LC_ADDRESS="en_US.utf8" > > LC_TELEPHONE="en_US.utf8" > > LC_MEASUREMENT="en_US.utf8" > > LC_IDENTIFICATION="en_US.utf8" > > LC_ALL= > > [rodd at localhost ~]$ > > > > > > -- > > > > "It's a fine line between denial and faith. > > It's much better on my side" > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > -- > http://scwlab.com > -- "It's a fine line between denial and faith. It's much better on my side" From stlwrt at gmail.com Sun May 4 01:32:40 2008 From: stlwrt at gmail.com (Pavel Shevchuk) Date: Sun, 4 May 2008 04:32:40 +0300 Subject: Localisation needs to be improved In-Reply-To: <1209862787.12250.4.camel@localhost.localdomain> References: <1209860284.3433.7.camel@localhost.localdomain> <1209861510.12250.0.camel@localhost.localdomain> <1209862787.12250.4.camel@localhost.localdomain> Message-ID: You chose Australia on timezone selection screen. Anaconda can't handle such specific needs without making GUI obfuscated, and it works OK for most users already. Advanced users can customize locale manually. Casual users want less buttons and get work done faster. I vote for leaving it as is. On 5/4/08, Rodd Clarkson wrote: > > > On Sun, 2008-05-04 at 03:48 +0300, Pavel Shevchuk wrote: > > I don't see any Australia-specific options here. You SHOULD NOT get > > australian currency or paper format with such locale. > > > > If i understand you correctly, you should set everything to > > en_AU.UTF-8, then override LC_MESSAGES with en_US.UTF-8. It will set > > paper and currency to Australian, but leave GUI American english > > > > > Yes, my locale output should look as you suggest. > > BUT, I the humble end user shouldn't have to know any of this or do > anything to make it so (rather than feed the installer some appropriate > information). > > I didn't set the setting this way, anaconda did. And anaconda has made > all these assumptions because I picked a language to use on my system. > I also told anaconda I live in Australia, but seemingly that information > wasn't that interesting when making assumptions about where I live. > > > > R. > > > > > > > > On 5/4/08, Rodd Clarkson wrote: > > > On Sun, 2008-05-04 at 03:23 +0300, Pavel Shevchuk wrote: > > > > Could you paste "locale" output? > > > > > > > > > > > > > [rodd at localhost ~]$ locale > > > LANG=en_US.utf8 > > > LC_CTYPE="en_US.utf8" > > > LC_NUMERIC="en_US.utf8" > > > LC_TIME="en_US.utf8" > > > LC_COLLATE="en_US.utf8" > > > LC_MONETARY="en_US.utf8" > > > LC_MESSAGES="en_US.utf8" > > > LC_PAPER="en_US.utf8" > > > LC_NAME="en_US.utf8" > > > LC_ADDRESS="en_US.utf8" > > > LC_TELEPHONE="en_US.utf8" > > > LC_MEASUREMENT="en_US.utf8" > > > LC_IDENTIFICATION="en_US.utf8" > > > LC_ALL= > > > [rodd at localhost ~]$ > > > > > > > > > -- > > > > > > "It's a fine line between denial and faith. > > > It's much better on my side" > > > > > > -- > > > fedora-devel-list mailing list > > > fedora-devel-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > > > > > -- > > http://scwlab.com > > > > -- > > "It's a fine line between denial and faith. > It's much better on my side" > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- http://scwlab.com From cr33dog at gmail.com Sun May 4 02:02:15 2008 From: cr33dog at gmail.com (Chris Mohler) Date: Sat, 3 May 2008 21:02:15 -0500 Subject: Orphaning FontyPython Message-ID: Sorry folks - I either need to orphan this one or pick up a co-maintainer who is willing to babysit it for a while. I've been insanely busy and it seems I will be for weeks to come :) FontyPython is a font management program that places symlinks from arbitrary locations into ~/.fonts, and allows you to group the links. Upstream has released a new version and several (apparently unannounced) updates and the .desktop file is also a tad broken. Chris From kanarip at kanarip.com Sun May 4 02:10:38 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 04 May 2008 04:10:38 +0200 Subject: Spin SIG - Document Drafts Message-ID: <481D1B1E.3050608@kanarip.com> Hi there, it has taken me a while, but finally I've drafted up some documents for review by the Spin SIG, and other related parties such as the Release Engineering team, the current Spin maintainers, the (Advisory) Board, etc. What we needed are the following: 1) Community Spin Guidelines - DOs and DONTs for Spin concepts that are to be included in the Kickstart Pool. http://fedoraproject.org/wiki/SIGs/Spins/CommunitySpinGuidelines 2) A Kickstart Pool - A collection of kickstarts that are to be distributed to the general public using a package, and that are to be used by Release Engineering as well as the Spin SIG to create, test and release spins from. http://fedoraproject.org/wiki/SIGs/Spins/KickstartPool From what is in the livecd-tools package and source tree now, the Spin SIG has distilled a new set of kickstarts, located at http://git.fedorahosted.org/git/?p=spin-kickstarts.git 3) A Spin Submission Process - Details on how you, or anyone else, can get a spin concept into the Kickstart Pool, and how to advance from there to get an approval stamp from the board, and how to get the Spin included in the Release Cycle should that be in the Spin's scope. http://fedoraproject.org/wiki/SIGs/Spins/SpinSubmissionProcess 4) Spin Distribution - A little something about possible distribution methods for spins not included in the release, or spins targeted at only part of our community (localized spins, for example). Another document, regarding the access to the kickstart pool by the Spin SIG as well as others (Release Engineering, Spin maintainers), and it's branching and packaging policy will be drafted as soon as the above takes shape. Kind regards, Jeroen van Meeuwen -kanarip From kanarip at kanarip.com Sun May 4 02:18:15 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 04 May 2008 04:18:15 +0200 Subject: Localisation needs to be improved In-Reply-To: References: <1209860284.3433.7.camel@localhost.localdomain> <1209861510.12250.0.camel@localhost.localdomain> <1209862787.12250.4.camel@localhost.localdomain> Message-ID: <481D1CE7.1060807@kanarip.com> Pavel Shevchuk wrote: > You chose Australia on timezone selection screen. > > Anaconda can't handle such specific needs without making GUI > obfuscated, and it works OK for most users already. > True, anaconda may not be able to handle it without obfuscating the GUI, and I don't think it's something that needs to be done during the installation or even during firstboot. > Advanced users can customize locale manually. Casual users want less > buttons and get work done faster. I vote for leaving it as is. > Casual users might find themselves frustrated over not knowing how, and hence not being able to configure these settings - adjusting things time and time again. How hard would it be to make a little System > Preferences GUI tool out of this? Kind regards, Jeroen van Meeuwen -kanarip From stlwrt at gmail.com Sun May 4 02:22:21 2008 From: stlwrt at gmail.com (Pavel Shevchuk) Date: Sun, 4 May 2008 05:22:21 +0300 Subject: Localisation needs to be improved In-Reply-To: <481D1CE7.1060807@kanarip.com> References: <1209860284.3433.7.camel@localhost.localdomain> <1209861510.12250.0.camel@localhost.localdomain> <1209862787.12250.4.camel@localhost.localdomain> <481D1CE7.1060807@kanarip.com> Message-ID: s-c-language could be obfuscated =P On 5/4/08, Jeroen van Meeuwen wrote: > Pavel Shevchuk wrote: > > > You chose Australia on timezone selection screen. > > > > Anaconda can't handle such specific needs without making GUI > > obfuscated, and it works OK for most users already. > > > > > > True, anaconda may not be able to handle it without obfuscating the GUI, > and I don't think it's something that needs to be done during the > installation or even during firstboot. > > > > Advanced users can customize locale manually. Casual users want less > > buttons and get work done faster. I vote for leaving it as is. > > > > > > Casual users might find themselves frustrated over not knowing how, and > hence not being able to configure these settings - adjusting things time and > time again. > > How hard would it be to make a little System > Preferences GUI tool out of > this? > > Kind regards, > > Jeroen van Meeuwen > -kanarip > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- http://scwlab.com From kanarip at kanarip.com Sun May 4 02:58:31 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 04 May 2008 04:58:31 +0200 Subject: Localisation needs to be improved In-Reply-To: References: <1209860284.3433.7.camel@localhost.localdomain> <1209861510.12250.0.camel@localhost.localdomain> <1209862787.12250.4.camel@localhost.localdomain> <481D1CE7.1060807@kanarip.com> Message-ID: <481D2657.5030405@kanarip.com> Pavel Shevchuk wrote: > s-c-language could be obfuscated =P > Well.. that is the system administration tool setting the default language for the system; it is not a user-tool setting the defaults for the user account. But... something like s-c-language in user-land, yeah. Kind regards, Jeroen van Meeuwen -kanarip From mmcgrath at redhat.com Sun May 4 05:18:03 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 4 May 2008 00:18:03 -0500 (CDT) Subject: Spin SIG - Document Drafts In-Reply-To: <481D1B1E.3050608@kanarip.com> References: <481D1B1E.3050608@kanarip.com> Message-ID: On Sun, 4 May 2008, Jeroen van Meeuwen wrote: > 3) A Spin Submission Process - Details on how you, or anyone else, can get a > spin concept into the Kickstart Pool, and how to advance from there to get an > approval stamp from the board, and how to get the Spin included in the Release > Cycle should that be in the Spin's scope. > > http://fedoraproject.org/wiki/SIGs/Spins/SpinSubmissionProcess > Anyone against me removing this page? http://fedoraproject.org/wiki/Infrastructure/CustomSpins It was created just because nothing else existed at the time. If you want it back. Revert the delete :) -Mike From anders at trudheim.co.uk Sun May 4 08:05:50 2008 From: anders at trudheim.co.uk (Anders Karlsson) Date: Sun, 4 May 2008 10:05:50 +0200 Subject: Apt autoupdates In-Reply-To: <481CB40A.8080609@gmail.com> References: <481C100C.50901@gmail.com> <481C48DE.9010004@fedoraproject.org> <481C85E2.9090607@gmail.com> <481C87B2.1000209@fedoraproject.org> <20080503183838.GN13403@localhost.localdomain> <481CB40A.8080609@gmail.com> Message-ID: <20080504080550.GO13403@localhost.localdomain> * Suren Karapetyan [20080503 20:51]: > Anders Karlsson wrote: >> I was under the impression that this is what 'pinning' packages was >> available for. I don't see this as a bug but as expected >> behaviour. After all, we do expect yum and it's tools up update >> all available packages unless we tell it not to. >> >> Now, if the packages were pinned, and the update script went ahead and >> updated them anyway, that would be a bug. > > We expect "yum update" to update all packages. > But we (or at least me) don't expect yum (nor even yum-updatesd) to update > all packages nightly by default. > Agree about pinning, but pinning doesn't work well for rawhide cause > especially during the first half of rawhide development I would have 50%+ > packages pinned. > I have only one PC at home so it needs to be at least remotely stable :) I am not 100% sure, as I don't currently have a Debian based system to check with, but from memory, this is what a Debian based system does, have a cronjob that does the nightly updates. If so, the apt package in Fedora just does what upstream (Debian) does, and we track upstream closely, right? The setting in /etc/sysconfig/apt would be something simple to carry a separate patch for though. I'll shut up now. :) /Anders From fedora at leemhuis.info Sun May 4 08:11:11 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 04 May 2008 10:11:11 +0200 Subject: New Sponsor Request: Denis Leroy In-Reply-To: <1209853425.4908.8.camel@vader.jdub.homelinux.org> References: <1209735916.11031.9.camel@kennedy> <1209737518.3203.167.camel@beck.corsepiu.local> <1209779225.26179.9.camel@vader.jdub.homelinux.org> <1209786970.2954.7.camel@beck.corsepiu.local> <1209853425.4908.8.camel@vader.jdub.homelinux.org> Message-ID: <481D6F9F.9080206@leemhuis.info> On 04.05.2008 00:23, Josh Boyer wrote: > On Sat, 2008-05-03 at 16:55 -0400, Jon Stanley wrote: >> On Fri, May 2, 2008 at 11:56 PM, Ralf Corsepius wrote: >>> Which administrators are you talking about? >> The following people would not receive mail sent to >> cvsextras-sponsors at fedoraproject.org: >> bpepple,bdpepple at gmail.com,Brian Pepple,administrator,7 >> gdk,gdk at redhat.com,Greg DeKoenigsberg,administrator,0 >> skvidal,skvidal at linux.duke.edu,Seth Vidal,administrator,3 >> sopwith,sopwith+fedora at gmail.com,Elliot Lee,administrator,21 >> spot,tcallawa at redhat.com,Tom Callaway,administrator,38 >> thl,fedora at leemhuis.info,Thorsten Leemhuis,administrator,6 >> wtogami,wtogami at redhat.com,Warren Togami ???,administrator,55 > [...] >> Are you wishing to exclude these people from the process? I think not..... > Well, Greg and Elliot seem to have bowed out of the packaging > perspective a while ago. The rest, with the exception of Thorsten, And skvidal afaics > are in FESCo and would review and discuss eventually anyway. > > I don't really care either way, but it seems that you're making a bit of > a deal over nothing :). In case somebody cares: I received the mail Brian recently sent to cvsextras-sponsors. BTW, if somebody want's to downgrade me to a normal sponsor feel free to do so. There is afaics no reason for me to be admin in cvsextras anymore. In fact I didn't even sponsor anyone for a long time and didn't do much reviews(?) or other work in Fedora. Thus maybe I should even be downgraded to a normal contributor. But a good bunch of other sponsors from the early Fedora-days seem mostly inactive as well. Thus a general cleanup in that group (?) might be wise -- but on the other hand it likely doesn't matter much in the end so might not be worth the trouble. Cu knurd (?) -- and the last one I tried was stolen by somebody else ;-) (no, I'm not complaining -- it was no problem and the packages was fine) (?) -- and in cvsextras itself as well -- there are likely a lot of contributors in that group that left or are AWOL From opensource at till.name Sun May 4 08:24:11 2008 From: opensource at till.name (Till Maas) Date: Sun, 04 May 2008 10:24:11 +0200 Subject: New Sponsor Request: Denis Leroy In-Reply-To: <481D6F9F.9080206@leemhuis.info> References: <1209735916.11031.9.camel@kennedy> <1209853425.4908.8.camel@vader.jdub.homelinux.org> <481D6F9F.9080206@leemhuis.info> Message-ID: <200805041024.17315.opensource@till.name> On Sun May 4 2008, Thorsten Leemhuis wrote: > from the early Fedora-days seem mostly inactive as well. Thus a general > cleanup in that group (?) might be wise -- but on the other hand it > likely doesn't matter much in the end so might not be worth the trouble. > (?) -- and in cvsextras itself as well -- there are likely a lot of > contributors in that group that left or are AWOL Iirc everybody had to change his password to keep his account alive after the transition to FAS2, therefore the cvsextras group should not contain many inactive maintainers. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From lordmorgul at gmail.com Sun May 4 08:34:48 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Sun, 04 May 2008 01:34:48 -0700 Subject: Localisation needs to be improved In-Reply-To: <481D2657.5030405@kanarip.com> References: <1209860284.3433.7.camel@localhost.localdomain> <1209861510.12250.0.camel@localhost.localdomain> <1209862787.12250.4.camel@localhost.localdomain> <481D1CE7.1060807@kanarip.com> <481D2657.5030405@kanarip.com> Message-ID: <481D7528.30001@gmail.com> Jeroen van Meeuwen wrote: > Pavel Shevchuk wrote: >> s-c-language could be obfuscated =P >> > > Well.. that is the system administration tool setting the default > language for the system; it is not a user-tool setting the defaults for > the user account. But... something like s-c-language in user-land, yeah. I have a feeling anyone who submits a package review for a spanky-new python gui app called 'system-config-locale' will get a quiet golfclap, a reviewer, and probably a couple helping co-maintainer-hands in a heartbeat. Until then this discussion, once again as before, is probably wasted minutes and bytes. -- Andrew Farris www.lordmorgul.net gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29 From lsof at nodata.co.uk Sun May 4 09:22:45 2008 From: lsof at nodata.co.uk (nodata) Date: Sun, 04 May 2008 11:22:45 +0200 Subject: Localisation needs to be improved In-Reply-To: <481D7528.30001@gmail.com> References: <1209860284.3433.7.camel@localhost.localdomain> <1209861510.12250.0.camel@localhost.localdomain> <1209862787.12250.4.camel@localhost.localdomain> <481D1CE7.1060807@kanarip.com> <481D2657.5030405@kanarip.com> <481D7528.30001@gmail.com> Message-ID: <1209892965.2949.0.camel@sb-home> Am Sonntag, den 04.05.2008, 01:34 -0700 schrieb Andrew Farris: > Jeroen van Meeuwen wrote: > > Pavel Shevchuk wrote: > >> s-c-language could be obfuscated =P > >> > > > > Well.. that is the system administration tool setting the default > > language for the system; it is not a user-tool setting the defaults for > > the user account. But... something like s-c-language in user-land, yeah. > > I have a feeling anyone who submits a package review for a spanky-new python gui > app called 'system-config-locale' will get a quiet golfclap, a reviewer, and > probably a couple helping co-maintainer-hands in a heartbeat. Again, s-c tools are for the whole system. I think you mean gnome-properties- > > Until then this discussion, once again as before, is probably wasted minutes and > bytes. > > -- > Andrew Farris www.lordmorgul.net > gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29 > From rawhide at fedoraproject.org Sun May 4 10:36:27 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Sun, 4 May 2008 10:36:27 +0000 (UTC) Subject: rawhide report: 20080504 changes Message-ID: <20080504103628.0D93A209D02@releng1.fedora.phx.redhat.com> Updated Packages: audacity-1.3.2-21.fc9 --------------------- * Sat May 03 2008 Michael Schwendt - 1.3.2-21 - check ownership of temporary files directory (#436260) (CVE-2007-6061) Broken deps for ppc64 ---------------------------------------------------------- livecd-tools-016-1.fc9.ppc64 requires yaboot perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot From rodd at clarkson.id.au Sun May 4 03:16:34 2008 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Sun, 04 May 2008 13:16:34 +1000 Subject: Localisation needs to be improved In-Reply-To: <481D1CE7.1060807@kanarip.com> References: <1209860284.3433.7.camel@localhost.localdomain> <1209861510.12250.0.camel@localhost.localdomain> <1209862787.12250.4.camel@localhost.localdomain> <481D1CE7.1060807@kanarip.com> Message-ID: <1209870995.12250.16.camel@localhost.localdomain> On Sun, 2008-05-04 at 04:18 +0200, Jeroen van Meeuwen wrote: > Pavel Shevchuk wrote: > > You chose Australia on timezone selection screen. > > > > Anaconda can't handle such specific needs without making GUI > > obfuscated, and it works OK for most users already. > > Oh great. X seems to work for most people, so let's just leave it at that. It will make Ajax's work a lot easier. For that matter, the kernel seems to work for most people so let's just leave it at that. etc. > True, anaconda may not be able to handle it without obfuscating the GUI, > and I don't think it's something that needs to be done during the > installation or even during firstboot. Actually, while there needs to be tools to adjust it afterwards, this is most definitely something anaconda should be getting right. You're average (non-advanced) users they are highly unlikely to know that this can be managed some other way and will most likely just curse and groan their way through each change they have to make at the applications level to get it right. As an example, I have to change the paper settings in a number of places in cups so that it knows I use A4 paper. Add to this that evince doesn't honor this, so I have to tell it that I'm printing A4 otherwise every thing is scaled down just a little. OOo also needs to be told about my A4 habit because it doesn't seem to honor cup's settings either. And that's just a start. Temperatures set to Fahrenheit. Measurements in inches, feet and yards. Getting this right at the install reaches deeply into the entire user experience, and should be done right at the install. After all, once I customize all these settings, a change to system-config-locale is unlikely to see these settings changing accordingly. > > Advanced users can customize locale manually. Casual users want less > > buttons and get work done faster. I vote for leaving it as is. I don't know what to say about this argument. You seem to be arguing that it's okay that we get this wrong, because advanced users can work around it. Besides, while I'm not sure I'm an advanced user, I also don't want to either have to redo this every six months (with each release of fedora) or ignore something that's broken just because it can fix it easily and ignore how much it might inconvenience other less advanced users. I say it should be fixed. R. -- "It's a fine line between denial and faith. It's much better on my side" From rc040203 at freenet.de Sun May 4 10:46:41 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 04 May 2008 12:46:41 +0200 Subject: New Sponsor Request: Denis Leroy In-Reply-To: References: <1209735916.11031.9.camel@kennedy> <1209737518.3203.167.camel@beck.corsepiu.local> <1209779225.26179.9.camel@vader.jdub.homelinux.org> <1209786970.2954.7.camel@beck.corsepiu.local> Message-ID: <1209898001.2954.13.camel@beck.corsepiu.local> On Sat, 2008-05-03 at 16:55 -0400, Jon Stanley wrote: > On Fri, May 2, 2008 at 11:56 PM, Ralf Corsepius wrote: > > > Which administrators are you talking about? > > The following people would not receive mail sent to > cvsextras-sponsors at fedoraproject.org: > > bpepple,bdpepple at gmail.com,Brian Pepple,administrator,7 > gdk,gdk at redhat.com,Greg DeKoenigsberg,administrator,0 > skvidal,skvidal at linux.duke.edu,Seth Vidal,administrator,3 > sopwith,sopwith+fedora at gmail.com,Elliot Lee,administrator,21 > spot,tcallawa at redhat.com,Tom Callaway,administrator,38 > thl,fedora at leemhuis.info,Thorsten Leemhuis,administrator,6 > wtogami,wtogami at redhat.com,Warren Togami ???,administrator,55 > > Are you wishing to exclude these people from the process? I think not..... It they are sponsors, they should be subscribed - period. If not, they should not be. Ralf From fedora at leemhuis.info Sun May 4 12:02:04 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 04 May 2008 14:02:04 +0200 Subject: New Sponsor Request: Denis Leroy In-Reply-To: <1209898001.2954.13.camel@beck.corsepiu.local> References: <1209735916.11031.9.camel@kennedy> <1209737518.3203.167.camel@beck.corsepiu.local> <1209779225.26179.9.camel@vader.jdub.homelinux.org> <1209786970.2954.7.camel@beck.corsepiu.local> <1209898001.2954.13.camel@beck.corsepiu.local> Message-ID: <481DA5BC.9010905@leemhuis.info> On 04.05.2008 12:46, Ralf Corsepius wrote: > On Sat, 2008-05-03 at 16:55 -0400, Jon Stanley wrote: >> On Fri, May 2, 2008 at 11:56 PM, Ralf Corsepius wrote: >> >>> Which administrators are you talking about? >> The following people would not receive mail sent to >> cvsextras-sponsors at fedoraproject.org: >> >> bpepple,bdpepple at gmail.com,Brian Pepple,administrator,7 >> gdk,gdk at redhat.com,Greg DeKoenigsberg,administrator,0 >> skvidal,skvidal at linux.duke.edu,Seth Vidal,administrator,3 >> sopwith,sopwith+fedora at gmail.com,Elliot Lee,administrator,21 >> spot,tcallawa at redhat.com,Tom Callaway,administrator,38 >> thl,fedora at leemhuis.info,Thorsten Leemhuis,administrator,6 >> wtogami,wtogami at redhat.com,Warren Togami ???,administrator,55 >> >> Are you wishing to exclude these people from the process? I think not..... > It they are sponsors, they should be subscribed - period. Just a note, it's no real list IIRC -- it's just a alias (at least it was in the old FAS days; not sure if that changed with FAS2; maybe someone else knows?). That IIRC creates trouble for some people with advanced spam filter techniques. > If not, they should not be. As I mentioned already, I got the mail and thus I suspect other admins got it as well. CU knurd From rc040203 at freenet.de Sun May 4 12:18:57 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 04 May 2008 14:18:57 +0200 Subject: New Sponsor Request: Denis Leroy In-Reply-To: <481DA5BC.9010905@leemhuis.info> References: <1209735916.11031.9.camel@kennedy> <1209737518.3203.167.camel@beck.corsepiu.local> <1209779225.26179.9.camel@vader.jdub.homelinux.org> <1209786970.2954.7.camel@beck.corsepiu.local> <1209898001.2954.13.camel@beck.corsepiu.local> <481DA5BC.9010905@leemhuis.info> Message-ID: <1209903537.2954.20.camel@beck.corsepiu.local> On Sun, 2008-05-04 at 14:02 +0200, Thorsten Leemhuis wrote: > On 04.05.2008 12:46, Ralf Corsepius wrote: > > On Sat, 2008-05-03 at 16:55 -0400, Jon Stanley wrote: > >> On Fri, May 2, 2008 at 11:56 PM, Ralf Corsepius wrote: > >> > >>> Which administrators are you talking about? > >> The following people would not receive mail sent to > >> cvsextras-sponsors at fedoraproject.org: > >> > >> bpepple,bdpepple at gmail.com,Brian Pepple,administrator,7 > >> gdk,gdk at redhat.com,Greg DeKoenigsberg,administrator,0 > >> skvidal,skvidal at linux.duke.edu,Seth Vidal,administrator,3 > >> sopwith,sopwith+fedora at gmail.com,Elliot Lee,administrator,21 > >> spot,tcallawa at redhat.com,Tom Callaway,administrator,38 > >> thl,fedora at leemhuis.info,Thorsten Leemhuis,administrator,6 > >> wtogami,wtogami at redhat.com,Warren Togami ???,administrator,55 > >> > >> Are you wishing to exclude these people from the process? I think not..... > > It they are sponsors, they should be subscribed - period. > > Just a note, it's no real list An irrelevant implementation detail to users (sponsors). > > If not, they should not be. > > As I mentioned already, I got the mail and thus I suspect other admins > got it as well. The point behind such list is to reach a competent and qualified group to evaluate candidates + to keep related discussions confident. I would take anybody lurking on this list who does not belong to this group (rsp. public archives of such discussion) as a severe breach of confidence on whoever administers this stuff's part. Ralf From twaugh at redhat.com Sun May 4 12:21:56 2008 From: twaugh at redhat.com (Tim Waugh) Date: Sun, 04 May 2008 13:21:56 +0100 Subject: Localisation needs to be improved In-Reply-To: <1209860284.3433.7.camel@localhost.localdomain> References: <1209860284.3433.7.camel@localhost.localdomain> Message-ID: <1209903717.19797.3.camel@cyberelk.elk> On Sun, 2008-05-04 at 10:18 +1000, Rodd Clarkson wrote: > Strangely, I get to go through this all because I picked a language and > stated that I lived somewhere in the installer and the installer chooses > to assume all sorts of things about where I live from the language I > choose to use, rather than the location I live in. This is the latest bug report I filed about that: https://bugzilla.redhat.com/show_bug.cgi?id=442567 Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at leemhuis.info Sun May 4 12:29:36 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 04 May 2008 14:29:36 +0200 Subject: New Sponsor Request: Denis Leroy In-Reply-To: <200805041024.17315.opensource@till.name> References: <1209735916.11031.9.camel@kennedy> <1209853425.4908.8.camel@vader.jdub.homelinux.org> <481D6F9F.9080206@leemhuis.info> <200805041024.17315.opensource@till.name> Message-ID: <481DAC30.3000507@leemhuis.info> On 04.05.2008 10:24, Till Maas wrote: > On Sun May 4 2008, Thorsten Leemhuis wrote: > >> from the early Fedora-days seem mostly inactive as well. Thus a general >> cleanup in that group (?) might be wise -- but on the other hand it >> likely doesn't matter much in the end so might not be worth the trouble. >> (?) -- and in cvsextras itself as well -- there are likely a lot of >> contributors in that group that left or are AWOL > > Iirc everybody had to change his password to keep his account alive after the > transition to FAS2, Ohh, yeah, forgot about that. But that doesn't matter much afaics, as users or an attacker could just reactive the account by reseting the password -- at least that how I read the footnote in https://www.redhat.com/archives/fedora-devel-list/2008-March/msg00772.html > therefore the cvsextras group should not contain many > inactive maintainers. Well, it afaics does, as https://admin.fedoraproject.org/accounts/group/dump/cvsextras for example still includes Jose Pedro Oliveira -- hasn't he left long ago? Anyway: I don't care much; just tried to be helpful with my mail (which was about a totally different topic). It's up to FESCo to decide what to do with people that left with or without notice. Cu knurd From rjones at redhat.com Sun May 4 13:51:03 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Sun, 4 May 2008 14:51:03 +0100 Subject: Fedora Package Status of May 3, 2008 In-Reply-To: <20080503010742.1b41ccab@ludwig-alpha.unil.ch> References: <20080503010742.1b41ccab@ludwig-alpha.unil.ch> Message-ID: <20080504135103.GA30310@amd.home.annexia.org> On Sat, May 03, 2008 at 01:07:42AM +0200, Christian Iseli wrote: > - 91 packages not available in devel or release > rjones at redhat dot com ocaml-bitmatch > rjones at redhat dot com ocaml-omake > rjones at redhat dot com ocaml-gettext > rjones at redhat dot com collectd > rjones at redhat dot com ocaml-gsl Probably I'm being dumb, but what does 'not available in devel or release' actually mean? Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From surenkarapetyan at gmail.com Sun May 4 14:19:36 2008 From: surenkarapetyan at gmail.com (Suren Karapetyan) Date: Sun, 4 May 2008 19:19:36 +0500 Subject: Apt autoupdates In-Reply-To: <20080504080550.GO13403@localhost.localdomain> References: <481C100C.50901@gmail.com> <481C48DE.9010004@fedoraproject.org> <481C85E2.9090607@gmail.com> <481C87B2.1000209@fedoraproject.org> <20080503183838.GN13403@localhost.localdomain> <481CB40A.8080609@gmail.com> <20080504080550.GO13403@localhost.localdomain> Message-ID: On 5/4/08, Anders Karlsson wrote: > * Suren Karapetyan [20080503 20:51]: > > Anders Karlsson wrote: > >> I was under the impression that this is what 'pinning' packages was > >> available for. I don't see this as a bug but as expected > >> behaviour. After all, we do expect yum and it's tools up update > >> all available packages unless we tell it not to. > >> > >> Now, if the packages were pinned, and the update script went ahead and > >> updated them anyway, that would be a bug. > > > > We expect "yum update" to update all packages. > > But we (or at least me) don't expect yum (nor even yum-updatesd) to update > > all packages nightly by default. > > Agree about pinning, but pinning doesn't work well for rawhide cause > > especially during the first half of rawhide development I would have 50%+ > > packages pinned. > > I have only one PC at home so it needs to be at least remotely stable :) > > I am not 100% sure, as I don't currently have a Debian based system to > check with, but from memory, this is what a Debian based system > does, have a cronjob that does the nightly updates. Well I do have a Debian4 system handy. Debian has the cron jobs for apt scheduled in daily, but the default configuration (which is done in /etc/cron.daily/apt) has the auto(update/upgrade) options turned off. So it doesn't even update the package list, let alone the packages. > If so, the apt > package in Fedora just does what upstream (Debian) does, and we track > upstream closely, right? Well of course we are :) But this doesn't make sense in this case cause upstream of apt (Debian) has nothing to do with Fedora or even rpms > > The setting in /etc/sysconfig/apt would be something simple to carry a > separate patch for though. I'll shut up now. :) and it [upstream] has nothing to do with /etc/sysconfig/apt cause there is no sysconfig in Debian. So /etc/sysconfig/apt isn't a file which should be PATCHED. It's just a distro-specific configuration file which should be MODIFIED. > > /Anders > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Regards Suren From nicolas.mailhot at laposte.net Sun May 4 15:01:07 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 04 May 2008 17:01:07 +0200 Subject: Help a little, make Fedora 10 a lot better Message-ID: <1209913267.4312.89.camel@rousalka.okg> Mission accomplished? ===================== It's the half-year mark, a final package set is being spun, blocking problems have been resolved, the sky is blue? People can now focus on this version release parties right? WRONG It's time to think of the NEXT version release parties. And how to make the next Fedora version rock so much the parties will be HUGE. In particular, care of issues that will need a full release cycle to mature before the next release. We're not there (yet) ===================== Such as? fonts. Fedora inherited from Red Hat Linux an impeccable American server OS pedigree. Unfortunately it also inherited its ?American server OS limits. Massive non-English Linux desktop deployments often use Debian or Debian derivatives. Meanwhile we discuss English locales support. Why fonts? ========== More than flash or mp3 support we need more fonts, so the text that makes most of our UI renders fine. It does not matter how many cool features the Desktop team adds in the next cycle ? if the UI text screams to the user ?I hate you? he won't install better fonts manually. He'll switch to a competitor that deploys Fedora-developed features with nice fonts. Why fonts? (really) =================== ?We need more artsy fonts so the art team can produce all kinds of cool promotional Fedora material (including release party flyers). We need more international fonts so regions where the Fedora presence is currently nil can join the partying. We need more fonts so the work of all the non-server SIGs is properly appreciated. Over all, we need more fonts so users can customize their desktop to the point they can't envision using something else than Fedora. Why me? ======= The situation got a little better during the Fedora 9 cycle. But we're still badly lagging distributions that have been investing in good font experience for a long time (Debian, Mandriva). And the Fedora 9 effort was produced by few people, that can not scale indefinitely. The Fedora font wishlist has 32 entries today. Not counting the public font lists it references: only fonts someone explicitly requested. That's more than 2/3 of the total of our currently packaged fonts. The list is growing, not shrinking. Many entries have half a year (before we didn't tack them). Clearly a targeted effort by new packagers is required to fix the situation by Fedora 10 time. It's easy! ========== Font packaging is not hard: 1. we've got good official streamlined packaging guidelines http://fedoraproject.org/wiki/SIGs/Fonts/Packaging 2. most font upstreams make few releases; you don't have to track them closely A font package is perfect for would-be packagers that need to ?to learn the ropes on a simple package. A font package is perfect for experienced packagers that do not have the time to take care of another time-waster. Let's party! ============ So here's the deal: A. We need 32 packagers to adopt a font in the SIG wishlist: http://fedoraproject.org/wiki/SIGs/Fonts/Triaging/Pipeline#wishes (Including fonts best packaged locally. It's a chicken-and-egg problem: we won't get local packagers before Fedora is attractive enough for them to join) B. We need them to package their font by Fedora 10 alpha? C. *Then* we can have huge Fedora 10 parties D. For Fedora 11, repeat with ?getting better than the competition? as objective ? ?So the result can be tested and the eventual buglets resolved upstream and in fontconfig before the final release -- 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 greno at verizon.net Sun May 4 16:24:10 2008 From: greno at verizon.net (Gerry Reno) Date: Sun, 04 May 2008 12:24:10 -0400 Subject: F9 installation issues In-Reply-To: <481CB613.2030406@verizon.net> References: <481BB224.3050505@verizon.net> <20080503004308.GA32161@nostromo.devel.redhat.com> <481BC04F.4020908@verizon.net> <20080503013527.GB2469@nostromo.devel.redhat.com> <481BC55A.3060303@verizon.net> <481BC7A9.8070907@verizon.net> <20080503023621.GA5190@nostromo.devel.redhat.com> <481CB613.2030406@verizon.net> Message-ID: <481DE32A.4020605@verizon.net> I just had another new unhandled exception occur during installation. And the bug handler does not work. When you try to save to disk all you see is a weird thin line in the dropdown and when you try to save it using the network it says it cannot do it network unreachable. So I switched over to console and I can see the install log but I cannot send it over the network because it says network unreachable. Is there any way to get networking working in the console during the anaconda install? Regards, Gerry From wwoods at redhat.com Sun May 4 16:27:21 2008 From: wwoods at redhat.com (Will Woods) Date: Sun, 4 May 2008 12:27:21 -0400 Subject: F9 installation issues In-Reply-To: <481DE32A.4020605@verizon.net> References: <481BB224.3050505@verizon.net> <20080503004308.GA32161@nostromo.devel.redhat.com> <481BC04F.4020908@verizon.net> <20080503013527.GB2469@nostromo.devel.redhat.com> <481BC55A.3060303@verizon.net> <481BC7A9.8070907@verizon.net> <20080503023621.GA5190@nostromo.devel.redhat.com> <481CB613.2030406@verizon.net> <481DE32A.4020605@verizon.net> Message-ID: <4F070DD2-23D2-48DF-B781-34A19A4F5F84@redhat.com> On May 4, 2008, at 12:24 PM, Gerry Reno wrote: > I just had another new unhandled exception occur during > installation. And the bug handler does not work. When you try to > save to disk all you see is a weird thin line in the dropdown and > when you try to save it using the network it says it cannot do it > network unreachable. So I switched over to console and I can see the > install log but I cannot send it over the network because it says > network unreachable. Is there any way to get networking working in > the console during the anaconda install? sure - you can use ifconfig manually or run 'pump' to do DHCP autoconfiguration. -w From lordmorgul at gmail.com Sun May 4 16:42:04 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Sun, 04 May 2008 09:42:04 -0700 Subject: Localisation needs to be improved In-Reply-To: <1209892965.2949.0.camel@sb-home> References: <1209860284.3433.7.camel@localhost.localdomain> <1209861510.12250.0.camel@localhost.localdomain> <1209862787.12250.4.camel@localhost.localdomain> <481D1CE7.1060807@kanarip.com> <481D2657.5030405@kanarip.com> <481D7528.30001@gmail.com> <1209892965.2949.0.camel@sb-home> Message-ID: <481DE75C.5040804@gmail.com> nodata wrote: > Am Sonntag, den 04.05.2008, 01:34 -0700 schrieb Andrew Farris: >> Jeroen van Meeuwen wrote: >>> Pavel Shevchuk wrote: >>>> s-c-language could be obfuscated =P >>>> >>> Well.. that is the system administration tool setting the default >>> language for the system; it is not a user-tool setting the defaults for >>> the user account. But... something like s-c-language in user-land, yeah. >> I have a feeling anyone who submits a package review for a spanky-new python gui >> app called 'system-config-locale' will get a quiet golfclap, a reviewer, and >> probably a couple helping co-maintainer-hands in a heartbeat. > > Again, s-c tools are for the whole system. I think you mean > gnome-properties- And if I wanted to set the default locales for all my future users... (I actually did mean what I suggested). You may be right that more than one tool is needed. -- Andrew Farris www.lordmorgul.net gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29 From greno at verizon.net Sun May 4 16:53:33 2008 From: greno at verizon.net (Gerry Reno) Date: Sun, 04 May 2008 12:53:33 -0400 Subject: F9 installation issues In-Reply-To: <4F070DD2-23D2-48DF-B781-34A19A4F5F84@redhat.com> References: <481BB224.3050505@verizon.net> <20080503004308.GA32161@nostromo.devel.redhat.com> <481BC04F.4020908@verizon.net> <20080503013527.GB2469@nostromo.devel.redhat.com> <481BC55A.3060303@verizon.net> <481BC7A9.8070907@verizon.net> <20080503023621.GA5190@nostromo.devel.redhat.com> <481CB613.2030406@verizon.net> <481DE32A.4020605@verizon.net> <4F070DD2-23D2-48DF-B781-34A19A4F5F84@redhat.com> Message-ID: <481DEA0D.8090108@verizon.net> Will Woods wrote: > > sure - you can use ifconfig manually or run 'pump' to do DHCP > autoconfiguration. > Thanks Will. ifconfig worked although it complains about cannot find /etc/network/interfaces. I attached the anaconda.log showing this unhandled exception to the installer bug: https://bugzilla.redhat.com/show_bug.cgi?id=443451 Regards, Gerry From jonstanley at gmail.com Sun May 4 16:14:41 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Sun, 4 May 2008 12:14:41 -0400 Subject: More Bugzilla maintenance coming soon to an installation near you! Message-ID: As mentioned previously in various announcements about the Bugzilla actions that are being undertaken, we will begin phase 2 shortly. Instructions on how to opt-out of these changes are below, as well as links to wiki pages that contain precise information on when the actions will begin, what actions are to be taken, and the queries used to select bugs to act upon. 1) Close all bugs INSUFFICIENT_DATA that are still in NEEDINFO from the "stale rawhide" cleanup (http://fedoraproject.org/wiki/BugZappers/F9CleanUp/RunTime#stalephase2). Precautions are being taken to ensure that bugs had activity, however were never taken out of NEEDINFO from the last round of actions are not touched. OPT-OUT: Changing the status to any other than NEEDINFO.will avoid having the bugs touched, 2) Close all bugs in ANY state that are filed against an EOL version (http://fedoraproject.org/wiki/BugZappers/F9CleanUp/RunTime#eolphase2) OPT-OUT: Changing the version to '8' or 'rawhide' will avoid us making any changes to this bug. Note that the following two actions are part of the BugZappers release SOP, and are being undertaken independently of the activities above (and will take place for every subsequent release to ensure that Bugzilla remains in good working order and useful to all parties): 3) Rebase all rawhide bugs (except for those that are Package Reviews or RFE's) to Fedora 9. Note that Bugzilla notification mail will be suppressed for this change - i.e. no one will receive mail that this has occurred except for this one. This is in direct response to community feedback that we were spamming them with unnecessary notifications. (http://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora9#frebase) OPT-OUT: If this is an RFE, then add the FutureFeature keyword to the bug, and no action will be taken on it. 4) Post a warning about the impending end-of-life of Fedora 7 in all bugs filed against F7 (http://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora9#f7warning). Paul Frields recently mentioned this, this comment will merely act as a reminder and final warning of this fact - nothing is changing. 30 days from the date of this running, all remaining bugs that are opened against Fedora 7 will be CLOSED WONTFIX. No opt-out really applies to this, however, if the bug still applies to a later release, feel free to change the version to the later release and the comment will not be changed If you have many bugs to change as a result of these procedures, feel free to drop by #fedora-qa and we will guide you through changing them all at once. Also note that we have conducted a thorough post-mortem investigation of all the spam that was generated last time, and have identified and repaired the problem. There will be only one notification per bug this time around :). Rest assured the BugZappers are are not doing this on their own and this process has been carefully reviewed by the leadership of the Fedora community. If you believe this process should be changed, like all things in Fedora, feel free to propose patches to the existing process or create a new proposal which can be evaluated and discussed for the Fedora 10 release cycle. For the BugZappers, -Jon -- Jon Stanley Fedora Bug Wrangler jstanley at fedoraproject.org _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From lsof at nodata.co.uk Sun May 4 17:20:45 2008 From: lsof at nodata.co.uk (nodata) Date: Sun, 04 May 2008 19:20:45 +0200 Subject: Localisation needs to be improved In-Reply-To: <1209870995.12250.16.camel@localhost.localdomain> References: <1209860284.3433.7.camel@localhost.localdomain> <1209861510.12250.0.camel@localhost.localdomain> <1209862787.12250.4.camel@localhost.localdomain> <481D1CE7.1060807@kanarip.com> <1209870995.12250.16.camel@localhost.localdomain> Message-ID: <1209921645.2942.8.camel@sb-home> Am Sonntag, den 04.05.2008, 13:16 +1000 schrieb Rodd Clarkson: > On Sun, 2008-05-04 at 04:18 +0200, Jeroen van Meeuwen wrote: > > Pavel Shevchuk wrote: > > > You chose Australia on timezone selection screen. > > > > > > Anaconda can't handle such specific needs without making GUI > > > obfuscated, and it works OK for most users already. > > > > > Oh great. X seems to work for most people, so let's just leave it at > that. It will make Ajax's work a lot easier. For that matter, the > kernel seems to work for most people so let's just leave it at that. > etc. > > > True, anaconda may not be able to handle it without obfuscating the GUI, > > and I don't think it's something that needs to be done during the > > installation or even during firstboot. > > Actually, while there needs to be tools to adjust it afterwards, this is > most definitely something anaconda should be getting right. > > You're average (non-advanced) users they are highly unlikely to know > that this can be managed some other way and will most likely just curse > and groan their way through each change they have to make at the > applications level to get it right. > > As an example, I have to change the paper settings in a number of places > in cups so that it knows I use A4 paper. Add to this that evince > doesn't honor this, so I have to tell it that I'm printing A4 otherwise > every thing is scaled down just a little. OOo also needs to be told > about my A4 habit because it doesn't seem to honor cup's settings > either. And that's just a start. > > Temperatures set to Fahrenheit. Measurements in inches, feet and yards. > > Getting this right at the install reaches deeply into the entire user > experience, and should be done right at the install. After all, once I > customize all these settings, a change to system-config-locale is > unlikely to see these settings changing accordingly. > > > > Advanced users can customize locale manually. Casual users want less > > > buttons and get work done faster. I vote for leaving it as is. > > I don't know what to say about this argument. You seem to be arguing > that it's okay that we get this wrong, because advanced users can work > around it. > > Besides, while I'm not sure I'm an advanced user, I also don't want to > either have to redo this every six months (with each release of fedora) > or ignore something that's broken just because it can fix it easily and > ignore how much it might inconvenience other less advanced users. > > I say it should be fixed. > > > R. > -- > "It's a fine line between denial and faith. > It's much better on my side" > Are you suggesting a "firstboot" for first time user logins? From kanarip at kanarip.com Sun May 4 19:34:24 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 04 May 2008 21:34:24 +0200 Subject: Localisation needs to be improved In-Reply-To: <1209921645.2942.8.camel@sb-home> References: <1209860284.3433.7.camel@localhost.localdomain> <1209861510.12250.0.camel@localhost.localdomain> <1209862787.12250.4.camel@localhost.localdomain> <481D1CE7.1060807@kanarip.com> <1209870995.12250.16.camel@localhost.localdomain> <1209921645.2942.8.camel@sb-home> Message-ID: <481E0FC0.9080909@kanarip.com> Let's make this into a Fedora 10 Proposed Feature: - an interface for system administrators to set the default language, like s-c-language does now, but extend it to tweak `locale`. - an interface for users to tweak they're own little private `locale`. Both could use the same interface, integrate with PolicyKit, and adjust settings in a location that's dependent on a user click or privilege scheme. These would not be included in anaconda / firstboot at first, but may end up there depending on how desirable it is to obfuscate those. How does this sound? Any current s-c-language developers want to shed some light on this (package owner in CC:)? Kind regards, Jeroen van Meeuwen -kanarip From triad at df.lth.se Sun May 4 22:05:13 2008 From: triad at df.lth.se (Linus Walleij) Date: Mon, 05 May 2008 00:05:13 +0200 Subject: Localisation needs to be improved In-Reply-To: <1209860284.3433.7.camel@localhost.localdomain> References: <1209860284.3433.7.camel@localhost.localdomain> Message-ID: <1209938713.2476.1.camel@c83-254-42-36.bredband.comhem.se> s?n 2008-05-04 klockan 10:18 +1000 skrev Rodd Clarkson: > Regardless, there has to be plenty of people who live somewhere, but use > a different language or the likes for some reason. Thats bug 432887 right? https://bugzilla.redhat.com/show_bug.cgi?id=432887 Linus From jspaleta at gmail.com Sun May 4 23:12:52 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 4 May 2008 15:12:52 -0800 Subject: Apt autoupdates In-Reply-To: <20080504080550.GO13403@localhost.localdomain> References: <481C100C.50901@gmail.com> <481C48DE.9010004@fedoraproject.org> <481C85E2.9090607@gmail.com> <481C87B2.1000209@fedoraproject.org> <20080503183838.GN13403@localhost.localdomain> <481CB40A.8080609@gmail.com> <20080504080550.GO13403@localhost.localdomain> Message-ID: <604aa7910805041612h45264501g258b7520172d864a@mail.gmail.com> On Sun, May 4, 2008 at 12:05 AM, Anders Karlsson wrote: > I am not 100% sure, as I don't currently have a Debian based system to > check with, but from memory, this is what a Debian based system > does, have a cronjob that does the nightly updates. If so, the apt > package in Fedora just does what upstream (Debian) does, and we track > upstream closely, right? We follow upstream as closely as is reasonable. Whether an automated service should be turned on by default or not when a package is installed is an issue that needs consideration on a service by service basis. Some services can be quite disruptive and when they are included as part an of a more complicated package it may not make sense to turn them on by default to reduce unexpected disruptions. Having the apt autoupdate cronjob in question included in the same binary package as apt itself may mean that it should be turned off by default. But if it were packaged as a subpackage whose only purpose was to install the autoupdate service onto your system, then it maybe reasonable to turn it on by default. User intent comes into play in the calculation and if it can be argued that users commonly install apt without needing or knowing about the autoupdate service that is also included..then it should be disabled by default. -jef"I'm personally in favor of making apt's default behavior as disruptive as possible, to encourage people to stop using it on Fedora systems"spaleta From ivazqueznet at gmail.com Mon May 5 02:50:51 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Sun, 04 May 2008 22:50:51 -0400 Subject: Fedora Package Status of May 3, 2008 In-Reply-To: <20080504135103.GA30310@amd.home.annexia.org> References: <20080503010742.1b41ccab@ludwig-alpha.unil.ch> <20080504135103.GA30310@amd.home.annexia.org> Message-ID: <1209955851.24162.96.camel@ignacio.lan> On Sun, 2008-05-04 at 14:51 +0100, Richard W.M. Jones wrote: > On Sat, May 03, 2008 at 01:07:42AM +0200, Christian Iseli wrote: > > - 91 packages not available in devel or release > > rjones at redhat dot com ocaml-bitmatch > > rjones at redhat dot com ocaml-omake > > rjones at redhat dot com ocaml-gettext > > rjones at redhat dot com collectd > > rjones at redhat dot com ocaml-gsl > > Probably I'm being dumb, but what does 'not available in devel or > release' actually mean? It means that there's a module for it in cvs, but that there are no packages built for either Rawhide or a stable release. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rodd at clarkson.id.au Mon May 5 04:42:30 2008 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Mon, 05 May 2008 14:42:30 +1000 Subject: Localisation needs to be improved In-Reply-To: <1209938713.2476.1.camel@c83-254-42-36.bredband.comhem.se> References: <1209860284.3433.7.camel@localhost.localdomain> <1209938713.2476.1.camel@c83-254-42-36.bredband.comhem.se> Message-ID: <1209962550.12250.20.camel@localhost.localdomain> On Mon, 2008-05-05 at 00:05 +0200, Linus Walleij wrote: > s?n 2008-05-04 klockan 10:18 +1000 skrev Rodd Clarkson: > > > Regardless, there has to be plenty of people who live somewhere, but use > > a different language or the likes for some reason. > > Thats bug 432887 right? > https://bugzilla.redhat.com/show_bug.cgi?id=432887 Yes. R. -- "It's a fine line between denial and faith. It's much better on my side" From rodd at clarkson.id.au Mon May 5 05:37:56 2008 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Mon, 05 May 2008 15:37:56 +1000 Subject: Help a little, make Fedora 10 a lot better In-Reply-To: <1209913267.4312.89.camel@rousalka.okg> References: <1209913267.4312.89.camel@rousalka.okg> Message-ID: <1209965876.12250.25.camel@localhost.localdomain> > We're not there (yet) > ===================== > > Such as? fonts. Fedora inherited from Red Hat Linux an impeccable > American server OS pedigree. Unfortunately it also inherited > its ?American server OS limits. Massive non-English Linux desktop > deployments often use Debian or Debian derivatives. Meanwhile we discuss > English locales support. Are you talking about the fact that I've raised issues with being stuck with Letter paper because I use US english? That might be my issue, but that isn't the problem as far as I see it. This is as much a problem for anyone that wants to use some other language than english, but lives in the US and is stuff with A4 instead of letter. We might be discussing locales support, but it's got nothing to do with english. It's about the ability to use a language and live somewhere and not have assumptions about the second because of the first. R. -- "It's a fine line between denial and faith. It's much better on my side" From greno at verizon.net Mon May 5 05:48:31 2008 From: greno at verizon.net (Gerry Reno) Date: Mon, 05 May 2008 01:48:31 -0400 Subject: F9 installation issues In-Reply-To: <481DEA0D.8090108@verizon.net> References: <481BB224.3050505@verizon.net> <20080503004308.GA32161@nostromo.devel.redhat.com> <481BC04F.4020908@verizon.net> <20080503013527.GB2469@nostromo.devel.redhat.com> <481BC55A.3060303@verizon.net> <481BC7A9.8070907@verizon.net> <20080503023621.GA5190@nostromo.devel.redhat.com> <481CB613.2030406@verizon.net> <481DE32A.4020605@verizon.net> <4F070DD2-23D2-48DF-B781-34A19A4F5F84@redhat.com> <481DEA0D.8090108@verizon.net> Message-ID: <481E9FAF.6090705@verizon.net> Well, I hacked my way through lots of installer bugs to an install finally. Still does not look like all the files are there because rescue can't find a whole system to mount under /mnt/sysimage. But it only takes a few files to mess that up. Anyway, I asked for static network address and I checked ifcfg-eth0 and it is static but I can only get a dhcp assignment. I restarted the network and same thing, it pulls a dhcp ip. I went into admin/network and it's all static in there. So is there something different in f9 about getting a static ip? Regards, Gerry From greno at verizon.net Mon May 5 06:00:26 2008 From: greno at verizon.net (Gerry Reno) Date: Mon, 05 May 2008 02:00:26 -0400 Subject: F9 installation issues In-Reply-To: <481E9FAF.6090705@verizon.net> References: <481BB224.3050505@verizon.net> <20080503004308.GA32161@nostromo.devel.redhat.com> <481BC04F.4020908@verizon.net> <20080503013527.GB2469@nostromo.devel.redhat.com> <481BC55A.3060303@verizon.net> <481BC7A9.8070907@verizon.net> <20080503023621.GA5190@nostromo.devel.redhat.com> <481CB613.2030406@verizon.net> <481DE32A.4020605@verizon.net> <4F070DD2-23D2-48DF-B781-34A19A4F5F84@redhat.com> <481DEA0D.8090108@verizon.net> <481E9FAF.6090705@verizon.net> Message-ID: <481EA27A.9080303@verizon.net> Gerry Reno wrote: > Well, I hacked my way through lots of installer bugs to an install > finally. Still does not look like all the files are there because > rescue can't find a whole system to mount under /mnt/sysimage. But it > only takes a few files to mess that up. > > Anyway, I asked for static network address and I checked ifcfg-eth0 > and it is static but I can only get a dhcp assignment. I restarted the > network and same thing, it pulls a dhcp ip. I went into admin/network > and it's all static in there. So is there something different in f9 > about getting a static ip? > > Regards, > Gerry > Well, after trying about 10 times to edit ifcfg-eth0 and restart network, I finally get something. RTNETLINK: File exists. Error adding 192.168.1.15 for eth0. but it seems to have worked. I check ifconfig and now the address is static. So that was weird. Regards, Gerry From greno at verizon.net Mon May 5 06:06:23 2008 From: greno at verizon.net (Gerry Reno) Date: Mon, 05 May 2008 02:06:23 -0400 Subject: F9 installation issues In-Reply-To: <481EA27A.9080303@verizon.net> References: <481BB224.3050505@verizon.net> <20080503004308.GA32161@nostromo.devel.redhat.com> <481BC04F.4020908@verizon.net> <20080503013527.GB2469@nostromo.devel.redhat.com> <481BC55A.3060303@verizon.net> <481BC7A9.8070907@verizon.net> <20080503023621.GA5190@nostromo.devel.redhat.com> <481CB613.2030406@verizon.net> <481DE32A.4020605@verizon.net> <4F070DD2-23D2-48DF-B781-34A19A4F5F84@redhat.com> <481DEA0D.8090108@verizon.net> <481E9FAF.6090705@verizon.net> <481EA27A.9080303@verizon.net> Message-ID: <481EA3DF.1040603@verizon.net> Gerry Reno wrote: > Well, after trying about 10 times to edit ifcfg-eth0 and restart > network, I finally get something. > RTNETLINK: File exists. > Error adding 192.168.1.15 for eth0. > but it seems to have worked. > > I check ifconfig and now the address is static. So that was weird. > > Regards, > Gerry > Now when I restart the network this same error message occurs. And I hate error messages like that... what damn file exists? Is it too much to ask to print the filename in the error message? Regards, Gerry From j.w.r.degoede at hhs.nl Mon May 5 08:27:14 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 05 May 2008 10:27:14 +0200 Subject: Upstream developers mainting there own package in Fedora and nothing else Message-ID: <481EC4E2.2030807@hhs.nl> Hi All, After the sponsor discussion we recently had, I decided I've been neglecting the sponsoring and went and took a look at the FE-NEEDSPONSOR queue. One of the reviews this has got me involved in is fpm2: https://bugzilla.redhat.com/show_bug.cgi?id=444830 This review is special as the upstream developer is submitting the package, and he has stated that for now he has no interest in doing other Fedora work. I believe that it is good to have upstream maintain packages for there own software, even if that is the only thing they do within Fedora, so I've proposed the following procedure to the submitter: -- Ok, we currently don't really have any special rules for an upstream maintainer becoming a maintainer of its own software within Fedora, but this is definitely something we want. So I would like to propose the following: 1 I review fpm2, you make any necessary changes etc, until I approve fpm2 2 Once fpm2 is approved you can request cvsextras membership in the account- system and I'll sponsor you 3 Given that you're new at packaging I'll then co-maintain fpm2 with you (mostly looking over your shoulder I'm more then busy enough as is). 4 Please refrain from touching other peoples packages as you've not been through the normal showing the ropes process involved in sponsering 5 If you want to submit another package please let me know then we can continue the sponsor process there. Does this sound like a plan? -- And now I'm wondering what others think of this and if maybe we should get some kinda special procedure for this? This has lead to me thinking that we really need the special new contributer group which was proposed by I believe Jesse, which is to be a special group for new contributers which would not give them access to anything outside their own packages. Regards, Hans From stlwrt at gmail.com Mon May 5 09:40:37 2008 From: stlwrt at gmail.com (Pavel Shevchuk) Date: Mon, 5 May 2008 12:40:37 +0300 Subject: Help a little, make Fedora 10 a lot better In-Reply-To: <1209965876.12250.25.camel@localhost.localdomain> References: <1209913267.4312.89.camel@rousalka.okg> <1209965876.12250.25.camel@localhost.localdomain> Message-ID: On 5/5/08, Rodd Clarkson wrote: > > > We're not there (yet) > > ===================== > > > > Such as? fonts. Fedora inherited from Red Hat Linux an impeccable > > American server OS pedigree. Unfortunately it also inherited > > its ?American server OS limits. Massive non-English Linux desktop > > deployments often use Debian or Debian derivatives. Meanwhile we discuss > > English locales support. > > > Are you talking about the fact that I've raised issues with being stuck > with Letter paper because I use US english? Paper format is set by: LC_PAPER="en_US.UTF-8" > That might be my issue, but that isn't the problem as far as I see it. > This is as much a problem for anyone that wants to use some other > language than english, but lives in the US and is stuff with A4 instead > of letter. > > We might be discussing locales support, but it's got nothing to do with > english. It's about the ability to use a language and live somewhere > and not have assumptions about the second because of the first. > > R. > -- > "It's a fine line between denial and faith. > It's much better on my side" > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- http://scwlab.com From rjones at redhat.com Mon May 5 09:41:28 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 5 May 2008 10:41:28 +0100 Subject: Fedora Package Status of May 3, 2008 In-Reply-To: <1209955851.24162.96.camel@ignacio.lan> References: <20080503010742.1b41ccab@ludwig-alpha.unil.ch> <20080504135103.GA30310@amd.home.annexia.org> <1209955851.24162.96.camel@ignacio.lan> Message-ID: <20080505094128.GA10354@amd.home.annexia.org> On Sun, May 04, 2008 at 10:50:51PM -0400, Ignacio Vazquez-Abrams wrote: > On Sun, 2008-05-04 at 14:51 +0100, Richard W.M. Jones wrote: > > On Sat, May 03, 2008 at 01:07:42AM +0200, Christian Iseli wrote: > > > - 91 packages not available in devel or release > > > rjones at redhat dot com ocaml-bitmatch > > > rjones at redhat dot com ocaml-omake > > > rjones at redhat dot com ocaml-gettext > > > rjones at redhat dot com collectd > > > rjones at redhat dot com ocaml-gsl > > > > Probably I'm being dumb, but what does 'not available in devel or > > release' actually mean? > > It means that there's a module for it in cvs, but that there are no > packages built for either Rawhide or a stable release. These packages are all really new - just built last week. In this case 'Rawhide' can't mean Koji's dist-f10, because I built packages for dist-f10 for the above. There are also packages for F-9 but they're waiting as updates. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From mschwendt at gmail.com Mon May 5 09:59:13 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Mon, 5 May 2008 11:59:13 +0200 Subject: Upstream developers mainting there own package in Fedora and nothing else In-Reply-To: <481EC4E2.2030807@hhs.nl> References: <481EC4E2.2030807@hhs.nl> Message-ID: <20080505115913.caa57949.mschwendt@gmail.com> On Mon, 05 May 2008 10:27:14 +0200, Hans de Goede wrote: > Hi All, > > After the sponsor discussion we recently had, I decided I've been neglecting > the sponsoring and went and took a look at the FE-NEEDSPONSOR queue. > > One of the reviews this has got me involved in is fpm2: > https://bugzilla.redhat.com/show_bug.cgi?id=444830 > > This review is special as the upstream developer is submitting the package, and > he has stated that for now he has no interest in doing other Fedora work. > > I believe that it is good to have upstream maintain packages for there own > software, even if that is the only thing they do within Fedora, so I've > proposed the following procedure to the submitter: > > -- > > Ok, we currently don't really have any special rules for an upstream maintainer > becoming a maintainer of its own software within Fedora, but this is definitely > something we want. So I would like to propose the following: > > 1 I review fpm2, you make any necessary changes etc, until I approve fpm2 > 2 Once fpm2 is approved you can request cvsextras membership in the account- > system and I'll sponsor you > 3 Given that you're new at packaging I'll then co-maintain fpm2 with you > (mostly looking over your shoulder I'm more then busy enough as is). > 4 Please refrain from touching other peoples packages as you've not been > through the normal showing the ropes process involved in sponsering > 5 If you want to submit another package please let me know then we can continue > the sponsor process there. > > Does this sound like a plan? > > -- > > And now I'm wondering what others think of this and if maybe we should get some > kinda special procedure for this? My first thought was "do we really need policies for everything"? Can't we just say that the sponsors have permission to approve accounts so new contributors may join and get productive? If you agree with an upstream developer on maintaining a package in Fedora, either alone or with you as co-maintainer, does it matter how you do it? You just need to be careful with premature approval of a package+account from somebody, who only follows Fedora Packaging guidelines reluctantly during review and later drops the ball. With reasons that may or may not have to do with Fedora or its bureaucracy. Then you would need to continue maintaining the package yourself or orphan it. For temporary volunteers it's too easy to leave the project and leave behind work, which other people may need to pick up because of dependencies. As long as we have an increasing collection of guidelines and policies in a Wiki that gives the feeling of a maze, Fedora is not just another platform which you can throw at a multi-distribution spec file that doesn't adhere to the policies. Every package in Fedora demands interest in creating a package that meets the guidelines and in using the Fedora-specific tools to build and publish the rpms. It's beneficial if an upstream developer, who wants to maintain his software in Fedora, actually uses Fedora *and* the packaged software. Eexcept if Fedora gives reason to be unhappy, that bears a risk. > This has lead to me thinking that we really > need the special new contributer group which was proposed by I believe Jesse, > which is to be a special group for new contributers which would not give them > access to anything outside their own packages. Do you want to prevent accidents? Or do you want to reduce the privileges of possibly malicious users? Any packager plays with fire if he touches things other than his own packages. And even if new contributors in a special group are locked down to their own packages, access to the build system is the crucial point. -- Fedora release 8 (Werewolf) - Linux 2.6.23.15-137.fc8 loadavg: 1.02 1.12 1.14 From sundaram at fedoraproject.org Mon May 5 10:02:15 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 05 May 2008 15:32:15 +0530 Subject: Xfce SIG? In-Reply-To: <20080407143318.318b1e0a@ghistelwchlohm.scrye.com> References: <20080407143318.318b1e0a@ghistelwchlohm.scrye.com> Message-ID: <481EDB27.4040108@fedoraproject.org> Kevin Fenzi wrote: > Greetings. > > I'd like to do a bit of informal polling here and see if there is > enough interest in forming a Xfce SIG. > > Right now, I maintain the Xfce packages and help with plugins, > Christoph Wickert maintains all the plugins and helps with the main > packages, and Rahul Sundaram maintains the Xfce spin. I thought there was enough interest expressed that I went ahead and created the Xfce SIG. http://fedoraproject.org/wiki/SIGs/Xfce Feel free to join folks. If you are listed, make sure you contribute something though ;-) Rahul From christoph.wickert at googlemail.com Mon May 5 10:12:02 2008 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Mon, 05 May 2008 12:12:02 +0200 Subject: XFCE Spin: gnomebaker instead of brasero? In-Reply-To: <481EAEBC.1010306@fedoraproject.org> References: <1209942035.3511.33.camel@wicktop.localdomain> <481EAEBC.1010306@fedoraproject.org> Message-ID: <1209982323.3535.17.camel@wicktop.localdomain> Am Montag, den 05.05.2008, 12:22 +0530 schrieb Rahul Sundaram: > Christoph Wickert wrote: > > Hi, > > > > what about gnomebaker instead of brasero? This should remove > > dependencies on nautilus-burn and gnome-mount and afacs the applications > > works fine and does everything we need. It still requires gconf and some > > other gnome stuff, but us will save us some more space. > > > > Opinions? > > I am not so sure about changing the default of a fairly crucial program > this late. I haven't done any testing with gnomebaker. Perhaps you can > post to fedora-devel list and gather some opinions? That's what I did with this mail. Opinions anyone? > > Rahul Christoph From j.w.r.degoede at hhs.nl Mon May 5 10:36:49 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 05 May 2008 12:36:49 +0200 Subject: Upstream developers mainting there own package in Fedora and nothing else In-Reply-To: <20080505115913.caa57949.mschwendt@gmail.com> References: <481EC4E2.2030807@hhs.nl> <20080505115913.caa57949.mschwendt@gmail.com> Message-ID: <481EE341.6000209@hhs.nl> Michael Schwendt wrote: > On Mon, 05 May 2008 10:27:14 +0200, Hans de Goede wrote: > >> Hi All, >> >> After the sponsor discussion we recently had, I decided I've been neglecting >> the sponsoring and went and took a look at the FE-NEEDSPONSOR queue. >> >> One of the reviews this has got me involved in is fpm2: >> https://bugzilla.redhat.com/show_bug.cgi?id=444830 >> >> This review is special as the upstream developer is submitting the package, and >> he has stated that for now he has no interest in doing other Fedora work. >> >> I believe that it is good to have upstream maintain packages for there own >> software, even if that is the only thing they do within Fedora, so I've >> proposed the following procedure to the submitter: >> >> -- >> >> Ok, we currently don't really have any special rules for an upstream maintainer >> becoming a maintainer of its own software within Fedora, but this is definitely >> something we want. So I would like to propose the following: >> >> 1 I review fpm2, you make any necessary changes etc, until I approve fpm2 >> 2 Once fpm2 is approved you can request cvsextras membership in the account- >> system and I'll sponsor you >> 3 Given that you're new at packaging I'll then co-maintain fpm2 with you >> (mostly looking over your shoulder I'm more then busy enough as is). >> 4 Please refrain from touching other peoples packages as you've not been >> through the normal showing the ropes process involved in sponsering >> 5 If you want to submit another package please let me know then we can continue >> the sponsor process there. >> >> Does this sound like a plan? >> >> -- >> >> And now I'm wondering what others think of this and if maybe we should get some >> kinda special procedure for this? > > My first thought was "do we really need policies for everything"? > I hear you, and I agree less is more when it comes to policies. > Can't we just say that the sponsors have permission to approve accounts > so new contributors may join and get productive? Agreed, > If you agree with an upstream developer on maintaining a package in Fedora, > either alone or with you as co-maintainer, does it matter how you do it? > Well there always is this problem of someone becoming malicious, I guess if someone really wants to he can easily just follow the normal process, so do a couple of new packages and a couple of reviews, but this is lowering the barrier to entry, which I'm fine with, but I atleast want others to know about this and shout "NOOO" before continuing with this. > You just need to be careful with premature approval of a package+account > from somebody, who only follows Fedora Packaging guidelines reluctantly > during review and later drops the ball. With reasons that may or may not > have to do with Fedora or its bureaucracy. Then you would need to continue > maintaining the package yourself or orphan it. For temporary volunteers > it's too easy to leave the project and leave behind work, which other > people may need to pick up because of dependencies. As long as we have an > increasing collection of guidelines and policies in a Wiki that gives the > feeling of a maze, Fedora is not just another platform which you can throw > at a multi-distribution spec file that doesn't adhere to the policies. > Every package in Fedora demands interest in creating a package that > meets the guidelines and in using the Fedora-specific tools to build > and publish the rpms. It's beneficial if an upstream developer, who > wants to maintain his software in Fedora, actually uses Fedora *and* > the packaged software. Eexcept if Fedora gives reason to be unhappy, > that bears a risk. > Someone leaving again soon after joining is not my biggest worry, either someone lese picksup his/her packages, or they get orphaned and removed from the next release. >> This has lead to me thinking that we really >> need the special new contributer group which was proposed by I believe Jesse, >> which is to be a special group for new contributers which would not give them >> access to anything outside their own packages. > > Do you want to prevent accidents? Or do you want to reduce the privileges > of possibly malicious users? Both but mainly the second (malicious users). > Any packager plays with fire if he touches > things other than his own packages. And even if new contributors in a > special group are locked down to their own packages, access to the build > system is the crucial point. > True, I forgot about a number of ways to make any package wreck havoc once in the repo, so someone truely malicious can wreck havoc as soon as he/she can push packages to the repo. Which really just leaves the accident problem, and that doesn't have me worried so much. Regards, Hans From mschwendt at gmail.com Mon May 5 10:56:52 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Mon, 5 May 2008 12:56:52 +0200 Subject: Upstream developers mainting there own package in Fedora and nothing else In-Reply-To: <481EE341.6000209@hhs.nl> References: <481EC4E2.2030807@hhs.nl> <20080505115913.caa57949.mschwendt@gmail.com> <481EE341.6000209@hhs.nl> Message-ID: <20080505125652.6e85cbe8.mschwendt@gmail.com> On Mon, 05 May 2008 12:36:49 +0200, Hans de Goede wrote: > > If you agree with an upstream developer on maintaining a package in Fedora, > > either alone or with you as co-maintainer, does it matter how you do it? > > > > Well there always is this problem of someone becoming malicious, I guess if > someone really wants to he can easily just follow the normal process, so do a > couple of new packages and a couple of reviews, but this is lowering the > barrier to entry, which I'm fine with, but I atleast want others to know about > this and shout "NOOO" before continuing with this. That belongs into my [very] old series of queries related to "sponsor responsibilities", which is still unanswered because it's a complex topic. All the burden is on the shoulders of the sponsors. It's completely up to their judgement whom to sponsor, whether to interview a new contributor prior to approval, whether to collect and compare personal information retrieved from web search engines, whether to insist on seeing a demonstration of packaging skills during review of several packages, whether to serve as a proxy for a newbie packager, whether and when to trust somebody from the other side of the world, and so on. And still a contributor might become hostile after months and delete group-writable files in cvs under the umbrella of a "sorry, fat fingers" excuse. Then it's the sponsor's duty to repair the damage. [The new FAS is not nice to sponsors either. They need to load the full cvsextras members list and search for the account to sponsor. Something that resulted in time-outs the last two times I did it. For sponsors, there doesn't seem to be a list of people you sponsored.] From sundaram at fedoraproject.org Mon May 5 10:27:41 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 05 May 2008 15:57:41 +0530 Subject: Fedora Xfce SIG Message-ID: <481EE11D.9080102@fedoraproject.org> Hi, If you are a fan of Xfce and want to help improve the Xfce experience in Fedora, join the Xfce SIG (Special Interest Group) at http://fedoraproject.org/wiki/SIGs/Xfce Maintaining Xfce packages, translations, documentation, artwork and improve the Fedora Xfce Spin (installable Live CD) are some of the things you can do to help the Xfce team in Fedora. Rahul _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From laxathom at fedoraproject.org Mon May 5 11:26:00 2008 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Mon, 5 May 2008 13:26:00 +0200 Subject: Upstream developers mainting there own package in Fedora and nothing else In-Reply-To: <20080505125652.6e85cbe8.mschwendt@gmail.com> References: <481EC4E2.2030807@hhs.nl> <20080505115913.caa57949.mschwendt@gmail.com> <481EE341.6000209@hhs.nl> <20080505125652.6e85cbe8.mschwendt@gmail.com> Message-ID: <62bc09df0805050426q324a4708hb4b5a794c07bac5@mail.gmail.com> 2008/5/5 Michael Schwendt : > On Mon, 05 May 2008 12:36:49 +0200, Hans de Goede wrote: > > > > If you agree with an upstream developer on maintaining a package in > Fedora, > > > either alone or with you as co-maintainer, does it matter how you do > it? > > > > > > > Well there always is this problem of someone becoming malicious, I guess > if > > someone really wants to he can easily just follow the normal process, so > do a > > couple of new packages and a couple of reviews, but this is lowering the > > barrier to entry, which I'm fine with, but I atleast want others to know > about > > this and shout "NOOO" before continuing with this. > > That belongs into my [very] old series of queries related to "sponsor > responsibilities", which is still unanswered because it's a complex > topic. All the burden is on the shoulders of the sponsors. It's completely > up to their judgement whom to sponsor, whether to interview a new > contributor prior to approval, whether to collect and compare personal > information retrieved from web search engines, whether to insist on seeing > a demonstration of packaging skills during review of several packages, > whether to serve as a proxy for a newbie packager, whether and when to > trust somebody from the other side of the world, and so on. And still a > contributor might become hostile after months and delete group-writable > files in cvs under the umbrella of a "sorry, fat fingers" excuse. Then > it's the sponsor's duty to repair the damage. > > [The new FAS is not nice to sponsors either. They need to load the > full cvsextras members list and search for the account to sponsor. Hm...sponsor or administrator of an related group should see on its welcome FAS's page members who requested sponsorship from its "todo queue". > Something that resulted in time-outs the last two times I did it. > For sponsors, there doesn't seem to be a list of people you sponsored.] > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From rawhide at fedoraproject.org Mon May 5 11:31:47 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Mon, 5 May 2008 11:31:47 +0000 (UTC) Subject: rawhide report: 20080505 changes Message-ID: <20080505113147.C8600209D07@releng1.fedora.phx.redhat.com> Updated Packages: (none) Broken deps for ppc64 ---------------------------------------------------------- livecd-tools-016-1.fc9.ppc64 requires yaboot perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot From mschwendt at gmail.com Mon May 5 12:13:12 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Mon, 5 May 2008 14:13:12 +0200 Subject: Upstream developers mainting there own package in Fedora and nothing else In-Reply-To: <62bc09df0805050426q324a4708hb4b5a794c07bac5@mail.gmail.com> References: <481EC4E2.2030807@hhs.nl> <20080505115913.caa57949.mschwendt@gmail.com> <481EE341.6000209@hhs.nl> <20080505125652.6e85cbe8.mschwendt@gmail.com> <62bc09df0805050426q324a4708hb4b5a794c07bac5@mail.gmail.com> Message-ID: <20080505141312.19a6060d.mschwendt@gmail.com> On Mon, 5 May 2008 13:26:00 +0200, Xavier Lamien wrote: > > [The new FAS is not nice to sponsors either. They need to load the > > full cvsextras members list and search for the account to sponsor. > > > Hm...sponsor or administrator of an related group should see on its welcome > FAS's page > members who requested sponsorship from its "todo queue". Is that just a guess? Or are you a sponsor and have sponsored somebody like that? Here, that list only shows 5 new accounts and not the one I was searching for. Further, if you click the account name to load the account details, there is no "sponsor" button anywhere. It can only be found in the full group view. -- Fedora release 8 (Werewolf) - Linux 2.6.23.15-137.fc8 loadavg: 1.63 1.81 1.59 From harald at redhat.com Mon May 5 12:15:02 2008 From: harald at redhat.com (Harald Hoyer) Date: Mon, 05 May 2008 14:15:02 +0200 Subject: augeas - reading/modifying/writing system configuration files Message-ID: Hi, just want to introduce augeas to you developers. _What is augeas?_ From: http://augeas.net/ Augeas is a configuration editing tool. It parses configuration files in their native formats and transforms them into a tree. Configuration changes are made by manipulating this tree and saving it back into native config files. Augeas is: * An API provided by a C library * A command line tool to manipulate configuration from the shell (and shell scripts) * Language bindings to do the same from your favorite scripting language * Canonical tree representations of common configuration files * A domain-specific language to describe configuration file formats _What can I do with augeas?_ Example: Set the default boot entry in grub Shell: # augtool augtool> match /files/etc/grub.conf/title /files/etc/grub.conf/title[1] = Fedora (2.6.25-14.fc9.x86_64) /files/etc/grub.conf/title[2] = Linux 2.6.25-1 augtool> get /files/etc/grub.conf/default /files/etc/grub.conf/default = 0 augtool> set /files/etc/grub.conf/default 1 augtool> save augtool> quit # grep default /etc/grub.conf default=1 Python: [root ~]# python Python 2.5.1 (r251:54863, Apr 8 2008, 01:19:33) [GCC 4.3.0 20080404 (Red Hat 4.3.0-6)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import augeas >>> a = augeas.augeas() >>> a.match("/files/etc/grub.conf/title") ['/files/etc/grub.conf/title[1]', '/files/etc/grub.conf/title[2]'] >>> a.get("/files/etc/grub.conf/default") '0' >>> a.set("/files/etc/grub.conf/default", "1") True >>> a.save() True >>> # grep default /etc/grub.conf default=1 C: augeas *a = aug_init(NULL, NULL, AUG_NONE); ret = aug_match(a, "/files/etc/grub.conf/title", &matches_p); ret = aug_get(a, "/files/etc/grub.conf/default", &value); ret = aug_set(a, "/files/etc/grub.conf/default", "1"); ret = aug_save(a); Simple, isn't it? :-) See also: http://augeas.net/tour.html _What should use augeas?_ All system-config-* tools should use augeas, as well as every tool modifying system configuration files like e.g. NetworkManager. _Why should I switch my tool to use augeas?_ * not to reinvent the wheel * one source to rule them all _Where can I get augeas?_ augeas just passed the package review. https://bugzilla.redhat.com/show_bug.cgi?id=444792 python-augeas still needs someone doing the review. https://bugzilla.redhat.com/show_bug.cgi?id=444945 Meanwhile you can always download the source from: http://augeas.net/ From dtimms at iinet.net.au Mon May 5 12:19:36 2008 From: dtimms at iinet.net.au (David Timms) Date: Mon, 05 May 2008 22:19:36 +1000 Subject: Upstream developers mainting there own package in Fedora and nothing else In-Reply-To: <481EE341.6000209@hhs.nl> References: <481EC4E2.2030807@hhs.nl> <20080505115913.caa57949.mschwendt@gmail.com> <481EE341.6000209@hhs.nl> Message-ID: <481EFB58.4000904@iinet.net.au> Hans de Goede wrote: > Michael Schwendt wrote: >> On Mon, 05 May 2008 10:27:14 +0200, Hans de Goede wrote: ... >>> This review is special as the upstream developer is submitting the >>> package, and he has stated that for now he has no interest in doing >>> other Fedora work. >>> Ok, we currently don't really have any special rules for an upstream >>> maintainer becoming a maintainer of its own software within Fedora, >>> but this is definitely something we want. I think it carries huge risk. While the upstream person knows a lot about making their development work in many places {eg from rchive, deb, rpm}, becoming intimately familiar with Fedora's {solid} methods is time consuming and difficult. I would anticipate that it would also lead to such people wanting to once write the build anywhere {rpm} spec. It is clearly simpler reviewing a spec without half of the spec being "if ... not SUSE ..." sort of thing, and I feel eases QA effort. But I'm no jedi packager, nor reviewer. >> Any packager plays with fire if he touches >> things other than his own packages. And even if new contributors in a >> special group are locked down to their own packages, access to the build >> system is the crucial point. > > True, I forgot about a number of ways to make any package wreck havoc > once in the repo, so someone truely malicious can wreck havoc as soon as > he/she can push packages to the repo. So a person who could cvs commit his package spec changes but little else, could require a co-maintainer not involved with the upstream project, and preferably a long standing trusted fedora package maintainer to be able push to repo {any}, and perhaps even to request builds. Perhaps the process would be {automated by the build/push system} as: - commit cvs change - request build - build system forwards the request to co-maintainers, including commit changes. - co-maintainer approves build if sees fit, else explain {eg you are trying to introduce a root kit}. - request push - push system forwards the request to co-maintainers, including commit changes. - co-maintainer approves push if sees fit, else explain. I was thinking a scratch build could be allowed, but given that the result is accessible by others, that still leads to the potential for gaining bad rep if/when someone takes advantage, and a tester gets done {even if the build isn't signed and pushed}. Is it only trust that stops any sponsored packager pumping out accidentally or purposely bad packages ? {I forget whether there is a formal procedure involving experienced others after the commit, build to get a package pushed.} DaveT. From davehoz at gmail.com Mon May 5 12:22:56 2008 From: davehoz at gmail.com (David Hunter) Date: Mon, 5 May 2008 22:22:56 +1000 Subject: Recent update on Fedora 9 beta hosed my firefox plugins Message-ID: <6bb886180805050522w54a2b1c8odcf63472a4ccb1f0@mail.gmail.com> I think it was the installiation of mozilla-filesystem-1.9-2.fc9.i386 that caused it, how can i get them back? ls /usr/lib/mozilla/plugins gives: libflashplayer.so libtotem-cone-plugin.so libjavaplugin.so libtotem-cone-plugin.xpt librhythmbox-itms-detection-plugin.so libtotem-gmp-plugin.so libswfdecmozilla.so libtotem-gmp-plugin.xpt libtotem-basic-plugin.so libtotem-mully-plugin.so libtotem-basic-plugin.xpt libtotem-mully-plugin.xpt libtotem-complex-plugin.so libtotem-narrowspace-plugin.so libtotem-complex-plugin.xpt libtotem-narrowspace-plugin.xpt However, the about:plugins gives: No plugins are installed Find more information about browser plugins at mozilla.org . Help for installing plugins is available from plugindoc.mozdev.org. ------------------------------ firefox version firefox-3.0-0.60.beta5.fc9.i386 -- David Hunter -------------- next part -------------- An HTML attachment was scrubbed... URL: From dtimms at iinet.net.au Mon May 5 12:32:50 2008 From: dtimms at iinet.net.au (David Timms) Date: Mon, 05 May 2008 22:32:50 +1000 Subject: python packaging - icons/desktop files and /usr/bin accessibility Message-ID: <481EFE72.1030105@iinet.net.au> I'm packaging a basic python program, and request some guidance: 1. the app has three main .py programs, and another 10 or so .py modules. My installed rpm puts these in site-packages/appname which I understand the guidelines to require. Problem is these are not accessible as a user because they aren't on the path. So it works if I /usr/lib/python../site-packages/myapp/app1.py Should I be messing with the path ? Creating a shell script for each of the main programs, and dropping them in /usr/bin ? 2. The app is a gui app, but has no icon nor desktop file. I thought I might have a go at adjusting the gnome flash player icon to represent flash recording capability. I guess I would need to talk to that upstream project to see if that would be OK ? The same with the upstream of my package to see if they are happy to have there app represented in this way ? 0. Should I be submitting the package review, with queries about the above, or is it better to get this stuff sorted here first ? DaveT. From laxathom at fedoraproject.org Mon May 5 12:41:42 2008 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Mon, 5 May 2008 14:41:42 +0200 Subject: Upstream developers mainting there own package in Fedora and nothing else In-Reply-To: <20080505141312.19a6060d.mschwendt@gmail.com> References: <481EC4E2.2030807@hhs.nl> <20080505115913.caa57949.mschwendt@gmail.com> <481EE341.6000209@hhs.nl> <20080505125652.6e85cbe8.mschwendt@gmail.com> <62bc09df0805050426q324a4708hb4b5a794c07bac5@mail.gmail.com> <20080505141312.19a6060d.mschwendt@gmail.com> Message-ID: <62bc09df0805050541k49049e1aq8ebe72eb4490ef55@mail.gmail.com> 2008/5/5 Michael Schwendt : > On Mon, 5 May 2008 13:26:00 +0200, Xavier Lamien wrote: > > > > [The new FAS is not nice to sponsors either. They need to load the > > > full cvsextras members list and search for the account to sponsor. > > > > > > Hm...sponsor or administrator of an related group should see on its > welcome > > FAS's page > > members who requested sponsorship from its "todo queue". > > Is that just a guess? Or are you a sponsor and have sponsored somebody > like that? > All you have to do it's to click on the requested group and then upgrade the user from sponsor button (only available for unapproved membership) . That's what i'm actually do. > > Here, that list only shows 5 new accounts and not the one I was searching > for. Further, if you click the account name to load the account details, > there is no "sponsor" button anywhere. It can only be found in the full > group view. yeah; i think that you will wish to have a "sponsor" button in your "todo queue" or in the account page of the requested user, to avoid to browse all the group list. This could be an improvment for fas2. > > -- > Fedora release 8 (Werewolf) - Linux 2.6.23.15-137.fc8 > loadavg: 1.63 1.81 1.59 > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From fedora at matbooth.co.uk Mon May 5 12:47:46 2008 From: fedora at matbooth.co.uk (Mat Booth) Date: Mon, 05 May 2008 13:47:46 +0100 Subject: Eclipse Web Tools, Data Tools and EMF Message-ID: <481F01F2.8070209@matbooth.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I'd like to eventually get the Web Tools and Data Tools projects for Eclipse into Fedora, but I see that EMF, which is a prerequisite for both, has been orphaned in F9. Does anyone mind if I have a bash at resurrecting the EMF package? Regards, Mat - -- Mat Booth www.matbooth.co.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkgfAfIACgkQKfdzh3zDrvBL1wCfQmJ0Cu1EF8hNJSkQRS6qphHX ruIAn3CR5SMKrtp1OXRARw1arKr94KKz =QGKC -----END PGP SIGNATURE----- From dtimms at iinet.net.au Mon May 5 12:49:41 2008 From: dtimms at iinet.net.au (David Timms) Date: Mon, 05 May 2008 22:49:41 +1000 Subject: augeas - reading/modifying/writing system configuration files In-Reply-To: References: Message-ID: <481F0265.3040609@iinet.net.au> Harald Hoyer wrote: > _What is augeas?_ > > From: http://augeas.net/ > > Augeas is a configuration editing tool. It parses configuration files in > their native formats and transforms them into a tree. Configuration > changes are made by manipulating this tree and saving it back into > native config files. ... > _Why should I switch my tool to use augeas?_ > > * not to reinvent the wheel > * one source to rule them all > * expect it to be included by default in f10+ {and el6+} ? * expect it to become one of the mock build root packages ? Why not ? - is it a large library ? - is it fast and efficient ? - does it work on many arches ? - when will it be considered production ready ? From harald at redhat.com Mon May 5 12:51:23 2008 From: harald at redhat.com (Harald Hoyer) Date: Mon, 05 May 2008 14:51:23 +0200 Subject: augeas - reading/modifying/writing system configuration files In-Reply-To: References: Message-ID: _Which configuration files are supported?_ Try for yourself: # augtool augtool> ls "/files/etc/" apt/ = (none) ssh/ = (none) sysconfig/ = (none) inittab/ = (none) aliases/ = (none) grub.conf/ = (none) pam.d/ = (none) yum.repos.d/ = (none) yum.conf/ = (none) hosts/ = (none) augtool> ls "/files/etc/sysconfig" wpa_supplicant/ = (none) system-config-users/ = (none) spamassassin/ = (none) saslauthd/ = (none) samba/ = (none) rsyslog/ = (none) readonly-root/ = (none) prelink/ = (none) ntpd/ = (none) nfs = (none) network/ = (none) netconsole = (none) nasd/ = (none) libvirtd = (none) keyboard/ = (none) kernel/ = (none) irqbalance/ = (none) irda/ = (none) iptables-config/ = (none) init/ = (none) i18n/ = (none) httpd = (none) firstboot/ = (none) crontab/ = (none) crond/ = (none) cpuspeed/ = (none) clock/ = (none) autofs/ = (none) authconfig/ = (none) atd = (none) network-scripts/ = (none) augtool> From Christian.Iseli at unil.ch Mon May 5 12:54:40 2008 From: Christian.Iseli at unil.ch (Christian Iseli) Date: Mon, 5 May 2008 14:54:40 +0200 Subject: Fedora Package Status of May 3, 2008 In-Reply-To: <20080505094128.GA10354@amd.home.annexia.org> References: <20080503010742.1b41ccab@ludwig-alpha.unil.ch> <20080504135103.GA30310@amd.home.annexia.org> <1209955851.24162.96.camel@ignacio.lan> <20080505094128.GA10354@amd.home.annexia.org> Message-ID: <20080505145440.227cc0bf@ludwig-alpha.unil.ch> On Mon, 5 May 2008 10:41:28 +0100, Richard W.M. Jones wrote: > These packages are all really new - just built last week. > > In this case 'Rawhide' can't mean Koji's dist-f10, because I built > packages for dist-f10 for the above. No, it just means whatever is available in the development repo, e.g. here: http://mirrors.kernel.org/fedora/development/source/SRPMS/ > There are also packages for F-9 but they're waiting as updates. Ok. In this case, the warning will go away when the packages actually show up in the repo (and I or someone else re-runs the PackageStatus script...) Cheers, Christian From dr.diesel at gmail.com Mon May 5 12:59:17 2008 From: dr.diesel at gmail.com (Dr. Diesel) Date: Mon, 5 May 2008 07:59:17 -0500 Subject: Recent update on Fedora 9 beta hosed my firefox plugins In-Reply-To: <6bb886180805050522w54a2b1c8odcf63472a4ccb1f0@mail.gmail.com> References: <6bb886180805050522w54a2b1c8odcf63472a4ccb1f0@mail.gmail.com> Message-ID: <2a28d2ab0805050559x56c5e05eq3d68ceb14dad8aec@mail.gmail.com> 2008/5/5 David Hunter : > I think it was the installiation of mozilla-filesystem-1.9-2.fc9.i386 that > caused it, how can i get them back? > > ls /usr/lib/mozilla/plugins > > gives: > > libflashplayer.so libtotem-cone-plugin.so > libjavaplugin.so libtotem-cone-plugin.xpt > librhythmbox-itms-detection-plugin.so libtotem-gmp-plugin.so > libswfdecmozilla.so libtotem-gmp-plugin.xpt > libtotem-basic-plugin.so libtotem-mully-plugin.so > libtotem-basic-plugin.xpt libtotem-mully-plugin.xpt > libtotem-complex-plugin.so libtotem-narrowspace-plugin.so > libtotem-complex-plugin.xpt libtotem-narrowspace-plugin.xpt > > However, the about:plugins gives: > > No plugins are installed > Find more information about browser plugins at mozilla.org. > Help for installing plugins is available from plugindoc.mozdev.org. > ________________________________ I'm fairly sure I've had complete lockups with the binary Adobe-Flash plugin. -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org From mschwendt at gmail.com Mon May 5 13:04:54 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Mon, 5 May 2008 15:04:54 +0200 Subject: Upstream developers mainting there own package in Fedora and nothing else In-Reply-To: <62bc09df0805050541k49049e1aq8ebe72eb4490ef55@mail.gmail.com> References: <481EC4E2.2030807@hhs.nl> <20080505115913.caa57949.mschwendt@gmail.com> <481EE341.6000209@hhs.nl> <20080505125652.6e85cbe8.mschwendt@gmail.com> <62bc09df0805050426q324a4708hb4b5a794c07bac5@mail.gmail.com> <20080505141312.19a6060d.mschwendt@gmail.com> <62bc09df0805050541k49049e1aq8ebe72eb4490ef55@mail.gmail.com> Message-ID: <20080505150454.73ee2ba4.mschwendt@gmail.com> On Mon, 5 May 2008 14:41:42 +0200, Xavier Lamien wrote: > > > Hm...sponsor or administrator of an related group should see on its > > welcome > > > FAS's page > > > members who requested sponsorship from its "todo queue". > > > > Is that just a guess? Or are you a sponsor and have sponsored somebody > > like that? > > > > > All you have to do it's to click on the requested group and then upgrade the > user from sponsor button (only available for unapproved membership) . > That's what i'm actually do. And when you do that the page doesn't takes ages to load or time-out? It doesn't scale. The more contributors, the longer the full list of accounts. Even if it's not an operation to perform often, it is regression compared with the old account system (which displayed a list of unsponsored accounts by default). -- Fedora release 8 (Werewolf) - Linux 2.6.23.15-137.fc8 loadavg: 1.18 1.42 1.36 From atkac at redhat.com Mon May 5 13:08:10 2008 From: atkac at redhat.com (Adam Tkac) Date: Mon, 5 May 2008 15:08:10 +0200 Subject: augeas - reading/modifying/writing system configuration files In-Reply-To: References: Message-ID: <20080505130810.GA26393@evileye.atkac.englab.brq.redhat.com> On Mon, May 05, 2008 at 02:15:02PM +0200, Harald Hoyer wrote: > > C: > augeas *a = aug_init(NULL, NULL, AUG_NONE); > ret = aug_match(a, "/files/etc/grub.conf/title", &matches_p); > ret = aug_get(a, "/files/etc/grub.conf/default", &value); > ret = aug_set(a, "/files/etc/grub.conf/default", "1"); > ret = aug_save(a); > > Simple, isn't it? :-) Pretty simple :) > > See also: http://augeas.net/tour.html > > _What should use augeas?_ > > All system-config-* tools should use augeas, as well as every tool > modifying system configuration files like e.g. NetworkManager. If we are talking about modifying system-config-* packages I think it is time to think if system-config packages are good configuration utilities. I think not. In my opinion we need one tool which will load plugins and configuration files should be modified through them. Every package which has configuration file will have simple plugin for one system wide tool and package maintainer should also maintain plugin for his package (because he knows about latest options etc). I know this will need hard work but in the end things will be far more better. > > _Why should I switch my tool to use augeas?_ > > * not to reinvent the wheel > * one source to rule them all Definitely, standardization on this field is pretty good from my point of view. Adam -- Adam Tkac, Red Hat, Inc. From ndbecker2 at gmail.com Mon May 5 13:25:24 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Mon, 05 May 2008 09:25:24 -0400 Subject: augeas - reading/modifying/writing system configuration files References: <481F0265.3040609@iinet.net.au> Message-ID: David Timms wrote: > Harald Hoyer wrote: >> _What is augeas?_ >> >> From: http://augeas.net/ >> >> Augeas is a configuration editing tool. It parses configuration files in >> their native formats and transforms them into a tree. Configuration >> changes are made by manipulating this tree and saving it back into >> native config files. > ... >> _Why should I switch my tool to use augeas?_ >> >> * not to reinvent the wheel >> * one source to rule them all >> > * expect it to be included by default in f10+ {and el6+} ? > * expect it to become one of the mock build root packages ? > > Why not ? > - is it a large library ? > - is it fast and efficient ? > - does it work on many arches ? > - when will it be considered production ready ? > Nice, but I think it would be nicer to implement this directly in python (ducks...) From stlwrt at gmail.com Mon May 5 13:29:35 2008 From: stlwrt at gmail.com (Pavel Shevchuk) Date: Mon, 5 May 2008 16:29:35 +0300 Subject: python packaging - icons/desktop files and /usr/bin accessibility In-Reply-To: <481EFE72.1030105@iinet.net.au> References: <481EFE72.1030105@iinet.net.au> Message-ID: Put a tiny wrapper in /usr/bin [stalwart at delta ~]$ cat /usr/bin/pyuic4 #!/bin/sh exec /usr/bin/python /usr/lib64/python2.5/site-packages/PyQt4/uic/pyuic.py ${1+"$@"} On 5/5/08, David Timms wrote: > I'm packaging a basic python program, and request some guidance: > > 1. the app has three main .py programs, and another 10 or so .py modules. > My installed rpm puts these in site-packages/appname which I understand the > guidelines to require. Problem is these are not accessible as a user because > they aren't on the path. > So it works if I > /usr/lib/python../site-packages/myapp/app1.py > > Should I be messing with the path ? > Creating a shell script for each of the main programs, and dropping them in > /usr/bin ? > > 2. The app is a gui app, but has no icon nor desktop file. I thought I > might have a go at adjusting the gnome flash player icon to represent flash > recording capability. I guess I would need to talk to that upstream project > to see if that would be OK ? > The same with the upstream of my package to see if they are happy to have > there app represented in this way ? > > 0. Should I be submitting the package review, with queries about the above, > or is it better to get this stuff sorted here first ? > > DaveT. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- http://scwlab.com From dtimms at iinet.net.au Mon May 5 13:37:05 2008 From: dtimms at iinet.net.au (David Timms) Date: Mon, 05 May 2008 23:37:05 +1000 Subject: python packaging - /usr/bin accessibility In-Reply-To: References: <481EFE72.1030105@iinet.net.au> Message-ID: <481F0D81.9010902@iinet.net.au> Pavel Shevchuk wrote: >> 1. the app has three main .py programs, and another 10 or so .py modules. >> My installed rpm puts these in site-packages/appname which I understand the >> guidelines to require. Problem is these are not accessible as a user because >> they aren't on the path. >> So it works if I >> /usr/lib/python../site-packages/myapp/app1.py >> >> Should I be messing with the path ? >> Creating a shell script for each of the main programs, and dropping them in >> /usr/bin ? > Put a tiny wrapper in /usr/bin > > [stalwart at delta ~]$ cat /usr/bin/pyuic4 > #!/bin/sh > > exec /usr/bin/python > /usr/lib64/python2.5/site-packages/PyQt4/uic/pyuic.py ${1+"$@"} How can I auto select the appropriate lib64/lib path ? What does ${1+"$@"} mean ? Is $1 first parameter passed ? would pyuic4 --fred=bloggs -a -v freg.txt -o temp.file then call ? /usr/lib64/python2.5/site-packages/PyQt4/uic/pyuic.py --fred=bloggs -a -v freg.txt -o temp.file DaveT. From dtimms at iinet.net.au Mon May 5 13:44:24 2008 From: dtimms at iinet.net.au (David Timms) Date: Mon, 05 May 2008 23:44:24 +1000 Subject: Recent update on Fedora 9 beta hosed my firefox plugins In-Reply-To: <6bb886180805050522w54a2b1c8odcf63472a4ccb1f0@mail.gmail.com> References: <6bb886180805050522w54a2b1c8odcf63472a4ccb1f0@mail.gmail.com> Message-ID: <481F0F38.3060703@iinet.net.au> David Hunter wrote: > I think it was the installiation of mozilla-filesystem-1.9-2.fc9.i386 that > caused it, how can i get them back? > > ls /usr/lib/mozilla/plugins > > gives: > > libflashplayer.so libtotem-cone-plugin.so > libjavaplugin.so libtotem-cone-plugin.xpt > librhythmbox-itms-detection-plugin.so libtotem-gmp-plugin.so > libswfdecmozilla.so libtotem-gmp-plugin.xpt > libtotem-basic-plugin.so libtotem-mully-plugin.so > libtotem-basic-plugin.xpt libtotem-mully-plugin.xpt > libtotem-complex-plugin.so libtotem-narrowspace-plugin.so > libtotem-complex-plugin.xpt libtotem-narrowspace-plugin.xpt With xool ruling the mozilla nest, perhaps: /usr/lib/xulrunner-1.9pre/plugins is the go now ? From stlwrt at gmail.com Mon May 5 13:49:58 2008 From: stlwrt at gmail.com (Pavel Shevchuk) Date: Mon, 5 May 2008 16:49:58 +0300 Subject: python packaging - /usr/bin accessibility In-Reply-To: <481F0D81.9010902@iinet.net.au> References: <481EFE72.1030105@iinet.net.au> <481F0D81.9010902@iinet.net.au> Message-ID: You can use %{_libdir} when you generate wrapper from specfile. Not sure about ${1+"$@"}, don't know shell that well to decrypt this expression =\ On 5/5/08, David Timms wrote: > Pavel Shevchuk wrote: > > > > > > 1. the app has three main .py programs, and another 10 or so .py > modules. > > > My installed rpm puts these in site-packages/appname which I understand > the > > > guidelines to require. Problem is these are not accessible as a user > because > > > they aren't on the path. > > > So it works if I > > > /usr/lib/python../site-packages/myapp/app1.py > > > > > > Should I be messing with the path ? > > > Creating a shell script for each of the main programs, and dropping > them in > > > /usr/bin ? > > > > > > > Put a tiny wrapper in /usr/bin > > > > [stalwart at delta ~]$ cat /usr/bin/pyuic4 > > #!/bin/sh > > > > exec /usr/bin/python > > /usr/lib64/python2.5/site-packages/PyQt4/uic/pyuic.py > ${1+"$@"} > > How can I auto select the appropriate lib64/lib path ? > What does ${1+"$@"} mean ? > Is $1 first parameter passed ? > > would pyuic4 --fred=bloggs -a -v freg.txt -o temp.file > then call ? > /usr/lib64/python2.5/site-packages/PyQt4/uic/pyuic.py > --fred=bloggs -a -v freg.txt -o temp.file > > DaveT. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- http://scwlab.com From mike at cchtml.com Mon May 5 13:58:16 2008 From: mike at cchtml.com (Mike Cronenworth) Date: Mon, 05 May 2008 08:58:16 -0500 Subject: XFCE Spin: gnomebaker instead of brasero? In-Reply-To: <1209982323.3535.17.camel@wicktop.localdomain> References: <1209942035.3511.33.camel@wicktop.localdomain> <481EAEBC.1010306@fedoraproject.org> <1209982323.3535.17.camel@wicktop.localdomain> Message-ID: <481F1278.4040402@cchtml.com> -------- Original Message -------- Subject: Re: XFCE Spin: gnomebaker instead of brasero? From: Christoph Wickert To: fedora-devel-list Date: 05/05/2008 05:12 AM > Am Montag, den 05.05.2008, 12:22 +0530 schrieb Rahul Sundaram: > > That's what I did with this mail. Opinions anyone? I have used gnomebaker in association with XFCE for a few years. It's been "OK" but if I have to do any serious burning I have to use K3b. Mainly I cannot burn DVD-Video DVDs unless they are already in ISO format. Otherwise gnomebaker is a good program. I use it at my workplace to burn CDs for our updated software for customers. We've never encountered a problem. > > Christoph > From dtimms at iinet.net.au Mon May 5 14:06:06 2008 From: dtimms at iinet.net.au (David Timms) Date: Tue, 06 May 2008 00:06:06 +1000 Subject: python packaging - /usr/bin accessibility In-Reply-To: References: <481EFE72.1030105@iinet.net.au> <481F0D81.9010902@iinet.net.au> Message-ID: <481F144E.5030904@iinet.net.au> Pavel Shevchuk wrote: > You can use %{_libdir} when you generate wrapper from specfile. Not > sure about ${1+"$@"}, don't know shell that well to decrypt this > expression =\ OK, so generating it on the fly would be normal ? From stlwrt at gmail.com Mon May 5 14:16:56 2008 From: stlwrt at gmail.com (Pavel Shevchuk) Date: Mon, 5 May 2008 17:16:56 +0300 Subject: python packaging - /usr/bin accessibility In-Reply-To: <481F144E.5030904@iinet.net.au> References: <481EFE72.1030105@iinet.net.au> <481F0D81.9010902@iinet.net.au> <481F144E.5030904@iinet.net.au> Message-ID: I guess so On 5/5/08, David Timms wrote: > Pavel Shevchuk wrote: > > > You can use %{_libdir} when you generate wrapper from specfile. Not > > sure about ${1+"$@"}, don't know shell that well to decrypt this > > expression =\ > > > OK, so generating it on the fly would be normal ? > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- http://scwlab.com From overholt at redhat.com Mon May 5 14:27:13 2008 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 05 May 2008 10:27:13 -0400 Subject: Eclipse Web Tools, Data Tools and EMF In-Reply-To: <481F01F2.8070209@matbooth.co.uk> References: <481F01F2.8070209@matbooth.co.uk> Message-ID: <1209997633.8417.1.camel@blingbling> Hi, On Mon, 2008-05-05 at 13:47 +0100, Mat Booth wrote: > I'd like to eventually get the Web Tools and Data Tools projects for > Eclipse into Fedora, but I see that EMF, which is a prerequisite for > both, has been orphaned in F9. I orphaned it because I didn't have time to maintain it and it has had a tonne of upstream shuffling. we should probably re-think how we package Modelling project (at eclipse.org) stuff. I'll put you in touch with upstream's release engineer who can help clarify how we should package. Andrew From harald at redhat.com Mon May 5 14:39:51 2008 From: harald at redhat.com (Harald Hoyer) Date: Mon, 05 May 2008 16:39:51 +0200 Subject: augeas - reading/modifying/writing system configuration files In-Reply-To: References: <481F0265.3040609@iinet.net.au> Message-ID: Neal Becker wrote: > Nice, but I think it would be nicer to implement this directly in python > (ducks...) > ??? From harald at redhat.com Mon May 5 14:44:16 2008 From: harald at redhat.com (Harald Hoyer) Date: Mon, 05 May 2008 16:44:16 +0200 Subject: augeas - reading/modifying/writing system configuration files In-Reply-To: <481F0265.3040609@iinet.net.au> References: <481F0265.3040609@iinet.net.au> Message-ID: David Timms wrote: > Harald Hoyer wrote: >> _What is augeas?_ >> >> From: http://augeas.net/ >> >> Augeas is a configuration editing tool. It parses configuration files >> in their native formats and transforms them into a tree. Configuration >> changes are made by manipulating this tree and saving it back into >> native config files. > ... >> _Why should I switch my tool to use augeas?_ >> >> * not to reinvent the wheel >> * one source to rule them all >> > * expect it to be included by default in f10+ {and el6+} ? will be in rawhide soon and thus in F10 > * expect it to become one of the mock build root packages ? why should it be? BuildRequires ftw > > Why not ? > - is it a large library ? $ ls -lh /usr/lib64/libaugeas.so.0.0.0 -rwxr-xr-x 1 root root 110K 2008-05-05 14:47 /usr/lib64/libaugeas.so.0.0.0 > - is it fast and efficient ? efficient in reusability and stability fast? where do you need speed? ok, maybe with you 500k /etc/hosts file :) > - does it work on many arches ? all arches we support. > - when will it be considered production ready ? well, as of now, it is pretty stable. From tjb at unh.edu Mon May 5 14:46:44 2008 From: tjb at unh.edu (Thomas J. Baker) Date: Mon, 05 May 2008 10:46:44 -0400 Subject: Monodevelop and video card recommedations In-Reply-To: <20080429075020.M8784@all-the-johnsons.co.uk> References: <20080429075020.M8784@all-the-johnsons.co.uk> Message-ID: <1209998804.5485.26.camel@raptor.sr.unh.edu> On Tue, 2008-04-29 at 08:54 +0100, Paul F. Johnson wrote: > Hi, > > Double pronged email this... > > 1. Can anyone recommend an AGP card which will allow me to run 3D graphics > without using non-GPL drivers? I want to move away from nVidia for the time > being. Nothing against their cards, just that to use 3D, I need to use their > drivers. > I asked this same question a while back (with the added requirements of dual head and pcie) and was pointed to R300 cards. There is one rather huge caveat to watch out for though: the R300 cards have a max texture size of 2048 which means no compiz for screen resolutions > 2048. In a dual head setup, it's a deal breaker. I don't know if this will ever be addressed in compiz but it's quite limiting. (My laptop with intel graphics has the same limitation.) Thanks, tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From harald at redhat.com Mon May 5 14:54:00 2008 From: harald at redhat.com (Harald Hoyer) Date: Mon, 05 May 2008 16:54:00 +0200 Subject: python packaging - /usr/bin accessibility In-Reply-To: <481F0D81.9010902@iinet.net.au> References: <481EFE72.1030105@iinet.net.au> <481F0D81.9010902@iinet.net.au> Message-ID: David Timms wrote: > Pavel Shevchuk wrote: >>> 1. the app has three main .py programs, and another 10 or so .py >>> modules. >>> My installed rpm puts these in site-packages/appname which I >>> understand the >>> guidelines to require. Problem is these are not accessible as a user >>> because >>> they aren't on the path. >>> So it works if I >>> /usr/lib/python../site-packages/myapp/app1.py >>> >>> Should I be messing with the path ? >>> Creating a shell script for each of the main programs, and dropping >>> them in >>> /usr/bin ? > > Put a tiny wrapper in /usr/bin > > > > [stalwart at delta ~]$ cat /usr/bin/pyuic4 > > #!/bin/sh > > > > exec /usr/bin/python > > /usr/lib64/python2.5/site-packages/PyQt4/uic/pyuic.py ${1+"$@"} > > How can I auto select the appropriate lib64/lib path ? > What does ${1+"$@"} mean ? > Is $1 first parameter passed ? > > would pyuic4 --fred=bloggs -a -v freg.txt -o temp.file > then call ? > /usr/lib64/python2.5/site-packages/PyQt4/uic/pyuic.py --fred=bloggs -a > -v freg.txt -o temp.file > > DaveT. > lib64 is only needed, if you have installed binaries, which are arch specific. $ python -c "from distutils.sysconfig import get_python_lib; print get_python_lib()" /usr/lib/python2.5/site-packages $ python -c "from distutils.sysconfig import get_python_lib; print get_python_lib(1)" /usr/lib64/python2.5/site-packages From foster at in.tum.de Mon May 5 14:57:20 2008 From: foster at in.tum.de (Mary Ellen Foster) Date: Mon, 5 May 2008 15:57:20 +0100 Subject: python packaging - icons/desktop files and /usr/bin accessibility In-Reply-To: <481EFE72.1030105@iinet.net.au> References: <481EFE72.1030105@iinet.net.au> Message-ID: On Mon, May 5, 2008 at 1:32 PM, David Timms wrote: > I'm packaging a basic python program, and request some guidance: > > 1. the app has three main .py programs, and another 10 or so .py modules. > My installed rpm puts these in site-packages/appname which I understand the > guidelines to require. Problem is these are not accessible as a user because > they aren't on the path. > So it works if I /usr/lib/python../site-packages/myapp/app1.py > > Should I be messing with the path ? > Creating a shell script for each of the main programs, and dropping them in > /usr/bin ? Note that if you want the libraries to be available to Python, as far as I understand it, the standard way to do this is to a "*.pth" file and put it into site-packages. For example, for my package (which puts files into an "Ice" subdirectory), I created a file called ice.pth containing only the following: Ice For yours, you probably want to create "myapp.pth" containing the line "myapp" and install that into site-packages. This doesn't answer the question of how to run the programs, though, of course. MEF -- Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/ Informatik 6: Robotics and Embedded Systems, Technische Universit?t M?nchen and ICCS, School of Informatics, University of Edinburgh From bpepple at fedoraproject.org Mon May 5 14:59:08 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 05 May 2008 10:59:08 -0400 Subject: FESCo Proposal for blocking older version of autoconf & automake Message-ID: <1209999548.32107.11.camel@kennedy> I received the following proposal from Karsten Hopp, which he would like FESCo to make a decision on during this week's meeting (2008-05-08). I'm forwarding it to the list, so that people can weigh-in on it. --- ?We are currently shipping an insane number of compatibility autofoo packages which haven't seen any upstream maintenance for many years: autoconf213-2.13-18.fc8.noarch.rpm (9 years) automake14-1.4p6-15.fc7.noarch.rpm (6 years) automake15-1.5-23.noarch.rpm (7 years) automake16-1.6.3-14.noarch.rpm (6 years) automake17-1.7.9-11.noarch.rpm (4 1/2 years) PROPOSAL: I'd like to keep just the following packages and would like to have release engineering to block the older packages from Rawhide: autoconf-2.61-10.fc9.noarch.rpm automake-1.10.1-2.noarch.rpm This is the complete list of rawhide packages requiring those ancient autofoo packages, it is rather short and it should be doable to convert those packages to current autofoo: automake14 ax25-apps-0.0.6-2.fc9.src.rpm automake14 gdk-pixbuf-0.22.0-36.fc9.src.rpm automake14 glib-1.2.10-29.fc9.src.rpm automake14 gtk+-1.2.10-61.fc9.src.rpm automake14 sgml-common-0.6.3-23.fc9.src.rpm automake14 WindowMaker-0.92.0-17.fc9.src.rpm automake15 nss_db-2.2-40.fc9.src.rpm automake16 kyum-0.7.5-11.fc9.src.rpm automake16 qalculate-kde-0.9.6-5.fc9.src.rpm automake16 sinjdoc-0.5-6.fc9.src.rpm automake17 cegui-0.5.0b-7.fc9.src.rpm automake17 ekg2-0.1.1-4.fc9.src.rpm automake17 gtk2-2.12.9-5.fc9.src.rpm automake17 nautilus-open-terminal-0.9-2.fc9.src.rpm autoconf213 esc-1.0.1-9.fc9.src.rpm autoconf213 glib-1.2.10-29.fc9.src.rpm autoconf213 gtk+-1.2.10-61.fc9.src.rpm autoconf213 pam_smb-1.1.7-8.2.2.src.rpm autoconf213 xdvik-22.84.13-17.fc9.src.rpm Maintainers are encouraged to switch to more recent releases of the autoconf tools and/or work with upstream to get this done. They also should make sure if it is really necessary to run p.e. automake at all during the build process. Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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: 197 bytes Desc: This is a digitally signed message part URL: From nicolas.mailhot at laposte.net Mon May 5 15:04:17 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 5 May 2008 17:04:17 +0200 (CEST) Subject: [OT] Re: Help a little, make Fedora 10 a lot better In-Reply-To: <1209965876.12250.25.camel@localhost.localdomain> References: <1209913267.4312.89.camel@rousalka.okg> <1209965876.12250.25.camel@localhost.localdomain> Message-ID: <37842.192.54.193.51.1209999857.squirrel@rousalka.dyndns.org> Le Lun 5 mai 2008 07:37, Rodd Clarkson a ?crit : > Are you talking about the fact that I've raised issues with being > stuck with Letter paper because I use US english? > > That might be my issue, but that isn't the problem as far as I see it. > This is as much a problem for anyone that wants to use some other > language than english, It may be... > but lives in the US and is stuff with A4 instead of letter. however I do not think the fact it was discussed for an English locale is incidental. It is pretty symptomatic of our community bias. -- Nicolas Mailhot From j.w.r.degoede at hhs.nl Mon May 5 15:20:33 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 05 May 2008 17:20:33 +0200 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <1209999548.32107.11.camel@kennedy> References: <1209999548.32107.11.camel@kennedy> Message-ID: <481F25C1.1060001@hhs.nl> Brian Pepple wrote: > I received the following proposal from Karsten Hopp, which he would like > FESCo to make a decision on during this week's meeting (2008-05-08). > I'm forwarding it to the list, so that people can weigh-in on it. > > --- > > ?We are currently shipping an insane number of compatibility autofoo > packages which haven't seen any upstream maintenance for many years: > > autoconf213-2.13-18.fc8.noarch.rpm (9 years) > automake14-1.4p6-15.fc7.noarch.rpm (6 years) > automake15-1.5-23.noarch.rpm (7 years) > automake16-1.6.3-14.noarch.rpm (6 years) > automake17-1.7.9-11.noarch.rpm (4 1/2 years) > > PROPOSAL: I'd like to keep just the following packages and would like to > have release engineering to block the older packages from Rawhide: > autoconf-2.61-10.fc9.noarch.rpm > automake-1.10.1-2.noarch.rpm > > This is the complete list of rawhide packages requiring those ancient > autofoo packages, it is rather short and it should be doable to convert > those packages to current autofoo: > > automake14 ax25-apps-0.0.6-2.fc9.src.rpm > automake14 gdk-pixbuf-0.22.0-36.fc9.src.rpm > automake14 glib-1.2.10-29.fc9.src.rpm > automake14 gtk+-1.2.10-61.fc9.src.rpm > automake14 sgml-common-0.6.3-23.fc9.src.rpm > automake14 WindowMaker-0.92.0-17.fc9.src.rpm > > automake15 nss_db-2.2-40.fc9.src.rpm > > automake16 kyum-0.7.5-11.fc9.src.rpm > automake16 qalculate-kde-0.9.6-5.fc9.src.rpm > automake16 sinjdoc-0.5-6.fc9.src.rpm > > automake17 cegui-0.5.0b-7.fc9.src.rpm > automake17 ekg2-0.1.1-4.fc9.src.rpm > automake17 gtk2-2.12.9-5.fc9.src.rpm > automake17 nautilus-open-terminal-0.9-2.fc9.src.rpm > > autoconf213 esc-1.0.1-9.fc9.src.rpm > autoconf213 glib-1.2.10-29.fc9.src.rpm > autoconf213 gtk+-1.2.10-61.fc9.src.rpm > autoconf213 pam_smb-1.1.7-8.2.2.src.rpm > autoconf213 xdvik-22.84.13-17.fc9.src.rpm > > Maintainers are encouraged to switch to more recent releases of the > autoconf tools and/or work with upstream to get this done. They also > should make sure if it is really necessary to run p.e. automake at all > during the build process. > > Later, > /B > From j.w.r.degoede at hhs.nl Mon May 5 15:24:30 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 05 May 2008 17:24:30 +0200 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <1209999548.32107.11.camel@kennedy> References: <1209999548.32107.11.camel@kennedy> Message-ID: <481F26AE.9030809@hhs.nl> Brian Pepple wrote: > I received the following proposal from Karsten Hopp, which he would like > FESCo to make a decision on during this week's meeting (2008-05-08). > I'm forwarding it to the list, so that people can weigh-in on it. > > --- > > ?We are currently shipping an insane number of compatibility autofoo > packages which haven't seen any upstream maintenance for many years: > > autoconf213-2.13-18.fc8.noarch.rpm (9 years) > automake14-1.4p6-15.fc7.noarch.rpm (6 years) > automake15-1.5-23.noarch.rpm (7 years) > automake16-1.6.3-14.noarch.rpm (6 years) > automake17-1.7.9-11.noarch.rpm (4 1/2 years) > > PROPOSAL: I'd like to keep just the following packages and would like to > have release engineering to block the older packages from Rawhide: > autoconf-2.61-10.fc9.noarch.rpm > automake-1.10.1-2.noarch.rpm > This gets a big +1 from me > This is the complete list of rawhide packages requiring those ancient > autofoo packages, it is rather short and it should be doable to convert > those packages to current autofoo: > > automake17 cegui-0.5.0b-7.fc9.src.rpm Thats mine now a days, but I have no problem with fixing this. > They also > should make sure if it is really necessary to run p.e. automake at all > during the build process. > Yes, quite often when adding a simple -lfoo or something like that its quite easy to patch both the .ac / .am file as the generated files, which is often better as regenerating autoxxx generated files on old unmaintained .ac / .am files can often (silently) introduce all kind of interesting (new) bugs. So its really much better to try and not regenerate autoxxx files during the build ever. There is a reason why these files are part of the tarbal and not regenerated automatically during a ./configure && make even when the tools to regenerate them are present. Regards, Hans From rdieter at math.unl.edu Mon May 5 15:32:55 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 05 May 2008 10:32:55 -0500 Subject: Upstream developers mainting there own package in Fedora and nothing else References: <481EC4E2.2030807@hhs.nl> <20080505115913.caa57949.mschwendt@gmail.com> Message-ID: Michael Schwendt wrote: >> And now I'm wondering what others think of this and if maybe we should >> get some kinda special procedure for this? > > My first thought was "do we really need policies for everything"? > > Can't we just say that the sponsors have permission to approve accounts > so new contributors may join and get productive? > If you agree with an upstream developer on maintaining a package in > Fedora, either alone or with you as co-maintainer, does it matter how you > do it? big +1 -- Rex From caillon at redhat.com Mon May 5 15:36:38 2008 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 05 May 2008 11:36:38 -0400 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <1209999548.32107.11.camel@kennedy> References: <1209999548.32107.11.camel@kennedy> Message-ID: <481F2986.8010509@redhat.com> On 05/05/2008 10:59 AM, Brian Pepple wrote: > I received the following proposal from Karsten Hopp, which he would like > FESCo to make a decision on during this week's meeting (2008-05-08). > I'm forwarding it to the list, so that people can weigh-in on it. > > --- > > ?We are currently shipping an insane number of compatibility autofoo > packages which haven't seen any upstream maintenance for many years: > > autoconf213-2.13-18.fc8.noarch.rpm (9 years) > automake14-1.4p6-15.fc7.noarch.rpm (6 years) > automake15-1.5-23.noarch.rpm (7 years) > automake16-1.6.3-14.noarch.rpm (6 years) > automake17-1.7.9-11.noarch.rpm (4 1/2 years) > > PROPOSAL: I'd like to keep just the following packages and would like to > have release engineering to block the older packages from Rawhide: > autoconf-2.61-10.fc9.noarch.rpm > automake-1.10.1-2.noarch.rpm > > This is the complete list of rawhide packages requiring those ancient > autofoo packages, it is rather short and it should be doable to convert > those packages to current autofoo: This is only the complete list of packages that currently BuildRequire it in their spec. Not the packages that ever BuildRequire them. The entire mozilla stack requires autoconf213 for configure.in hacking. See bug https://bugzilla.mozilla.org/show_bug.cgi?id=104642 Unless someone steps up and does the work to get this upstream properly, I am afraid I, along with some of the mozilla upstream developers, will no longer be able to use rawhide if we drop autoconf213 from it. From jonathan.underwood at gmail.com Mon May 5 15:34:23 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 5 May 2008 16:34:23 +0100 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <1209999548.32107.11.camel@kennedy> References: <1209999548.32107.11.camel@kennedy> Message-ID: <645d17210805050834v6357770fn7680bf3a41328a31@mail.gmail.com> 2008/5/5 Brian Pepple : > This is the complete list of rawhide packages requiring those ancient > autofoo packages, it is rather short and it should be doable to convert > those packages to current autofoo: [snip] > autoconf213 xdvik-22.84.13-17.fc9.src.rpm > This one is mine. xdvik is a generally quite crufty piece of software that we still need to ship, but i am happy to get it building with newer autoconf (but it won't happen over night) as I agree with the spirit of the proposal. Jonathan. From rc040203 at freenet.de Mon May 5 15:48:30 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 05 May 2008 17:48:30 +0200 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <1209999548.32107.11.camel@kennedy> References: <1209999548.32107.11.camel@kennedy> Message-ID: <1210002510.26792.62.camel@beck.corsepiu.local> On Mon, 2008-05-05 at 10:59 -0400, Brian Pepple wrote: > I received the following proposal from Karsten Hopp, which he would like > FESCo to make a decision on during this week's meeting (2008-05-08). > I'm forwarding it to the list, so that people can weigh-in on it. > > --- > > ?We are currently shipping an insane number of compatibility autofoo > packages which haven't seen any upstream maintenance for many years: > > autoconf213-2.13-18.fc8.noarch.rpm (9 years) > automake14-1.4p6-15.fc7.noarch.rpm (6 years) > automake15-1.5-23.noarch.rpm (7 years) > automake16-1.6.3-14.noarch.rpm (6 years) > automake17-1.7.9-11.noarch.rpm (4 1/2 years) > PROPOSAL: I'd like to keep just the following packages and would like to > have release engineering to block the older packages from Rawhide: > autoconf-2.61-10.fc9.noarch.rpm > automake-1.10.1-2.noarch.rpm +1 This step is way over due. It also will teach maintainers not run the autotools while building. Ralf From notting at redhat.com Mon May 5 15:50:16 2008 From: notting at redhat.com (Bill Nottingham) Date: Mon, 5 May 2008 11:50:16 -0400 Subject: augeas - reading/modifying/writing system configuration files In-Reply-To: References: Message-ID: <20080505155016.GB3521@nostromo.devel.redhat.com> > _What should use augeas?_ > > All system-config-* tools should use augeas, as well as every tool > modifying system configuration files like e.g. NetworkManager. > > _Why should I switch my tool to use augeas?_ > > * not to reinvent the wheel > * one source to rule them all If you have an existing already-invented parser for something, what's the benefit? Bill From ndbecker2 at gmail.com Mon May 5 15:58:23 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Mon, 05 May 2008 11:58:23 -0400 Subject: **** Access denied: nbecker is not in ACL for rpms/libotf/devel Message-ID: **** Access denied: nbecker is not in ACL for rpms/libotf/devel From mclasen at redhat.com Mon May 5 15:57:48 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 05 May 2008 11:57:48 -0400 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <1210002510.26792.62.camel@beck.corsepiu.local> References: <1209999548.32107.11.camel@kennedy> <1210002510.26792.62.camel@beck.corsepiu.local> Message-ID: <1210003068.5320.10.camel@localhost.localdomain> On Mon, 2008-05-05 at 17:48 +0200, Ralf Corsepius wrote: > > This step is way over due. It also will teach maintainers not run the > autotools while building. Thats your personal preference. No need to force that on all of us. From harald at redhat.com Mon May 5 16:01:28 2008 From: harald at redhat.com (Harald Hoyer) Date: Mon, 05 May 2008 18:01:28 +0200 Subject: augeas - reading/modifying/writing system configuration files In-Reply-To: <20080505155016.GB3521@nostromo.devel.redhat.com> References: <20080505155016.GB3521@nostromo.devel.redhat.com> Message-ID: Bill Nottingham wrote: >> _What should use augeas?_ >> >> All system-config-* tools should use augeas, as well as every tool >> modifying system configuration files like e.g. NetworkManager. >> >> _Why should I switch my tool to use augeas?_ >> >> * not to reinvent the wheel >> * one source to rule them all > > If you have an existing already-invented parser for something, what's > the benefit? > > Bill > maintenance? ok, if you read only, and your parser is dead simple, then there might be no sense to switch. also, if your config file has a complicated special syntax and no augeas lens exist. From caillon at redhat.com Mon May 5 16:06:02 2008 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 05 May 2008 12:06:02 -0400 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <1210002510.26792.62.camel@beck.corsepiu.local> References: <1209999548.32107.11.camel@kennedy> <1210002510.26792.62.camel@beck.corsepiu.local> Message-ID: <481F306A.90600@redhat.com> On 05/05/2008 11:48 AM, Ralf Corsepius wrote: > This step is way over due. It also will teach maintainers not run the > autotools while building. It will also teach maintainers not to use Fedora for doing upstream work. From rc040203 at freenet.de Mon May 5 16:10:50 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 05 May 2008 18:10:50 +0200 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <1210003068.5320.10.camel@localhost.localdomain> References: <1209999548.32107.11.camel@kennedy> <1210002510.26792.62.camel@beck.corsepiu.local> <1210003068.5320.10.camel@localhost.localdomain> Message-ID: <1210003850.26792.73.camel@beck.corsepiu.local> On Mon, 2008-05-05 at 11:57 -0400, Matthias Clasen wrote: > On Mon, 2008-05-05 at 17:48 +0200, Ralf Corsepius wrote: > > > > > This step is way over due. It also will teach maintainers not run the > > autotools while building. > > Thats your personal preference. Your liberty to think this. > No need to force that on all of us. How do you call SW that relies upon x years old bugs? I call it poorly maintained. How do you call projects who stick with antiquated tools and ignore many years of development? I call them poorly maintained. Or differently: Upstream projects which stick with these antiquated versions are as poorly maintained and dead as projects written in KnR or projects staying with gtk-1. - These projects have had many years to update their code ... and failed. Now they've got to learn the hard way. Ralf From sundaram at fedoraproject.org Mon May 5 16:15:16 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 05 May 2008 21:45:16 +0530 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <1210003850.26792.73.camel@beck.corsepiu.local> References: <1209999548.32107.11.camel@kennedy> <1210002510.26792.62.camel@beck.corsepiu.local> <1210003068.5320.10.camel@localhost.localdomain> <1210003850.26792.73.camel@beck.corsepiu.local> Message-ID: <481F3294.9010304@fedoraproject.org> Ralf Corsepius wrote: > On Mon, 2008-05-05 at 11:57 -0400, Matthias Clasen wrote: >> On Mon, 2008-05-05 at 17:48 +0200, Ralf Corsepius wrote: >> >>> This step is way over due. It also will teach maintainers not run the >>> autotools while building. >> Thats your personal preference. > > Your liberty to think this. Otherwise, it would be useful to have packaging guidelines officially on to the recommended method to deal with this. Rahul From notting at redhat.com Mon May 5 16:14:54 2008 From: notting at redhat.com (Bill Nottingham) Date: Mon, 5 May 2008 12:14:54 -0400 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <1210003850.26792.73.camel@beck.corsepiu.local> References: <1209999548.32107.11.camel@kennedy> <1210002510.26792.62.camel@beck.corsepiu.local> <1210003068.5320.10.camel@localhost.localdomain> <1210003850.26792.73.camel@beck.corsepiu.local> Message-ID: <20080505161454.GA7317@nostromo.devel.redhat.com> Ralf Corsepius (rc040203 at freenet.de) said: > Or differently: Upstream projects which stick with these antiquated > versions are as poorly maintained and dead as projects written in KnR or > projects staying with gtk-1. Oh, the irony. Bill From dakingun at gmail.com Mon May 5 16:14:55 2008 From: dakingun at gmail.com (Deji Akingunola) Date: Mon, 5 May 2008 12:14:55 -0400 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <1210002510.26792.62.camel@beck.corsepiu.local> References: <1209999548.32107.11.camel@kennedy> <1210002510.26792.62.camel@beck.corsepiu.local> Message-ID: On Mon, May 5, 2008 at 11:48 AM, Ralf Corsepius wrote: > > > PROPOSAL: I'd like to keep just the following packages and would like to > > have release engineering to block the older packages from Rawhide: > > autoconf-2.61-10.fc9.noarch.rpm > > automake-1.10.1-2.noarch.rpm > +1 > > This step is way over due. It also will teach maintainers not run the > autotools while building. > Not if I (qalculate-kde) cannot avoid it. cln was updated to a version that radically changed the way it was detected, and configure.ac and some .m4 have to be patched in qalculate to make it build with the newer cln. Deji > Ralf > > > > > > -- > 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 May 5 16:17:20 2008 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 05 May 2008 12:17:20 -0400 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <1210003850.26792.73.camel@beck.corsepiu.local> References: <1209999548.32107.11.camel@kennedy> <1210002510.26792.62.camel@beck.corsepiu.local> <1210003068.5320.10.camel@localhost.localdomain> <1210003850.26792.73.camel@beck.corsepiu.local> Message-ID: <481F3310.8030007@redhat.com> On 05/05/2008 12:10 PM, Ralf Corsepius wrote: > Or differently: Upstream projects which stick with these antiquated > versions are as poorly maintained and dead as projects written in KnR or > projects staying with gtk-1. - These projects have had many years to > update their code ... and failed. Now they've got to learn the hard way. Great. I'm glad you want to provide a patch to Firefox. Please attach it to https://bugzilla.mozilla.org/show_bug.cgi?id=104642 at your earliest convenience. From rc040203 at freenet.de Mon May 5 16:21:35 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 05 May 2008 18:21:35 +0200 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <481F306A.90600@redhat.com> References: <1209999548.32107.11.camel@kennedy> <1210002510.26792.62.camel@beck.corsepiu.local> <481F306A.90600@redhat.com> Message-ID: <1210004495.26792.82.camel@beck.corsepiu.local> On Mon, 2008-05-05 at 12:06 -0400, Christopher Aillon wrote: > On 05/05/2008 11:48 AM, Ralf Corsepius wrote: > > This step is way over due. It also will teach maintainers not run the > > autotools while building. > > It will also teach maintainers not to use Fedora for doing upstream work. How comes you expect each and every tool in Fedora but the autotools to be "current". We have current compilers, current python, current perl, current ... But ... you are expecting Fedora to ship and support utterly outdated autotools? You are measuring by double standards - If upstreams were writing proper autotool files and where following upstream autotools as they apparently are doing wrt. other tools, this issues would not exist. Ralf From notting at redhat.com Mon May 5 16:29:19 2008 From: notting at redhat.com (Bill Nottingham) Date: Mon, 5 May 2008 12:29:19 -0400 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <1210004495.26792.82.camel@beck.corsepiu.local> References: <1209999548.32107.11.camel@kennedy> <1210002510.26792.62.camel@beck.corsepiu.local> <481F306A.90600@redhat.com> <1210004495.26792.82.camel@beck.corsepiu.local> Message-ID: <20080505162919.GB7317@nostromo.devel.redhat.com> > How comes you expect each and every tool in Fedora but the autotools to > be "current". That's it! OK, by Fedora 10 we need to start removing all sorts of not 'current' things that aren't up to modern standards. First, toolkits! We need to remove gtk1, qt3, and for pete's sake, Xaw and Xaw3d. All are obsolete, and users and developers are best served by upgrading to more recent toolkits such as Qt4 and GTK2. The following 258 packages need ported by Fedora 10, or they will be removed: aasaver-0.3.2-3.fc9 agistudio-1.2.3-7.fc9 amarok-1.4.8-5.fc9 amarokFS-0.5-3.fc9 apollon-1.0.1-13.fc9 aqbanking-2.3.3-3.fc9 arts-1.5.9-2.fc9 avahi-0.6.22-10.fc9 basket-1.0.2-5.fc9 bibletime-1.6.5-4.fc9 bitmap-1.0.3-4.fc9 bluecurve-kde-theme-1.0.0-3.fc9 bouml-4.2-2.fc9 brltty-3.9-2.2.fc9 bubblemon-1.46-8.fc9 camstream-0.26.3-12.fc8 cernlib-2006-29.fc9 cernlib-g77-2006-29.fc9 CGAL-3.3.1-11.fc9 clips-6.24-25.fc9 compizconfig-backend-kconfig-0.7.2-1.fc9 crossfire-1.10.0-4.fc9 crossfire-client-1.10.0-4.fc9 crossvc-1.5.2-4.fc9 crystalspace-1.2-4.fc9 dbus-qt3-0.8-5.fc9 ddd-3.3.11-18.fc9 digikam-0.9.3-2.fc9 dillo-0.8.6-7.fc9 djvulibre-3.5.20-2.fc9 doxygen-1.5.5-3.fc9 dssi-0.9.1-14.fc9 exim-4.69-4.fc9 faad2-2.6.1-3.lvn9 filelight-1.0-12.fc9 foobillard-3.0a-6 freedroidrpg-0.10.3-2.fc9 fwbuilder-2.1.16-2.fc9 gambas2-2.5.0-1.fc9 gcin-1.3.9-2.fc9 gcombust-0.1.55-13 gcx-0.9.11-3.fc9 gdk-pixbuf-0.22.0-36.fc9 genchemlab-1.0-9.fc9 gentoo-0.11.56-6 glglobe-0.2-6.fc9 gnash-0.8.2-2.fc9 gnome-libs-1.4.2-8.fc9 gpicview-0.1.9-1.fc9 gpsd-2.37-2.fc9 graphviz-2.16.1-0.5.fc9 groff-1.18.1.4-14.fc9 gsview-4.8-2.lvn6 gtk+-1.2.10-61.fc9 gxine-0.5.11-17.fc9 HippoDraw-1.21.1-4.fc9 hydrogen-0.9.3-13.fc9 imlib-1.9.15-7.fc9 isdn4k-utils-3.2-58.fc9 jabbin-2.0-0.6.beta2a.fc9 k3b-1.0.4-6.fc9 k3b-extras-nonfree-1.0.4-2.lvn9 k9copy-1.2.2-1.lvn9 kadu-0.6.0-3.fc9 kaffeine-0.8.6-4.fc9 kasablanca-0.4.0.2-12.fc9 katapult-0.3.2.1-3.fc9 kbackup-0.5.3-4.fc9 kbibtex-0.2-14.fc9 kbilliards-0.8.7b-7.fc9 kbiof-0.3-3.fc9 kcemirror-0.1.5-4.fc9 kdbg-2.1.0-2.fc9 kdeaddons-3.5.9-1.fc9 kdebase3-3.5.9-10.fc9 kdebluetooth-1.0-0.41.beta8.fc9 kdegames3-3.5.9-1.fc9 kdelibs3-3.5.9-8.fc9 kdepim-3.5.9-9.fc9 kdesvn-0.14.1-4.fc9 kdetv-0.8.9-10.fc9 kdevelop-3.5.1-4.fc9 kdewebdev-3.5.9-3.fc9 kdiff3-0.9.92-13.fc9 kdirstat-2.5.3-8.fc9 kdissert-1.0.7-4.fc9 kdocker-1.3-11.fc9 kerry-0.2.1-7.fc9 kflickr-0.9.1-2.fc9 kftpgrabber-0.8.1-6.fc9 kickpim-0.5.3-14.fc9 kile-2.0-4.fc9 kinput2-v3.1-38.fc9 kio_p7zip-0.3.1-7.fc9 kiosktool-1.0-10.fc9 kio_sword-0.3-6.fc9 kipi-plugins-0.1.5-0.6.rc2.fc9 kita-0.177.3-12.fc9.2 klamav-0.42-3.fc9 kleansweep-0.2.9-7.fc9 klear-0.7.0-1.svn113.fc9 klibido-0.2.5-10.fc9 kmobiletools-0.4.3.3-4.fc9 kmplayer-0.10.0c-4.fc9 kmymoney2-0.8.9-1.fc9 knetstats-1.6.1-8.fc9 koffice-1.6.3-15.fc9 komparator-0.9-1.fc9 kompose-0.5.3-12.fc9 konversation-1.0.1-6.fc9 kooldock-0.4.6-4.fc9 kover-3-3 koverartist-0.5-11.fc9 kphotoalbum-3.1.1-1.fc9 kplayer-0.6.2-3.lvn8 kpolynome-0.1.2-12.fc9 kpowersave-0.7.3-3.fc9 krecipes-0.9.1-9.fc9 kreetingkard-0.7.1-2.fc9.2 krename-3.0.14-4.fc9 krusader-1.80.0-5.fc9 kscope-1.6.1-4.fc9 ksensors-0.7.3-16.fc9 kshutdown-1.0.1-2.fc9 ksirk-1.7-6.fc9 ksshaskpass-0.4-2.fc9 kst-1.5.0-3.fc9 ksynaptics-0.3.3-5.fc9 ktechlab-0.3.69-5.fc8 kyum-0.7.5-11.fc9 LabPlot-1.5.1.6-4.fc8 lame-3.97-6.lvn8 libglade-0.17-21.fc9 libkdcraw-0.1.3-2.fc9 libkexif-0.2.5-4.fc9 libkexiv2-0.1.6-4.fc9 libkipi-0.1.5-4.fc9 libopensync-plugin-kdepim-0.35-2.fc9 libquicktime-1.0.2-2.lvn9 libsvm-2.86-12.fc9 libsx-2.05-15.fc9 libXaw-1.0.4-2.fc9 licq-1.3.5-1.fc9 lineak-kdeplugins-0.9-4.fc9 linpsk-0.9-3.fc9 logjam-4.5.3-22.fc9 manedit-0.8.1-3.fc9 metamonitor-0.4.5-5.fc9 moto4lin-0.3-6.fc7 museek+-0.1.13-3.fc9 MyPasswordSafe-0.6.7-4.20061216.fc9 nas-1.9.1-4.fc9 ncl-5.0.0-11.fc9 ncview-1.92e-13.fc9 netgo-0.5-10.fc9 nethack-3.4.3-17.fc9 ngspice-17-14.fc9 normalize-0.7.7-2.lvn6 ogre-1.4.7-2.fc9 ois-1.0-4.fc9 oooqs2-1.0-3.fc6 openbox-3.4.6.1-1.fc9 OpenSceneGraph-2.2.0-5.fc9 oprofile-0.9.3-17.fc9 pdfedit-0.3.2-4.fc9 pic2aa-0.2.1-3.fc9 pikdev-0.9.2-6.fc9 piklab-0.15.0-1.fc9 pikloops-0.2.5-3.fc9 pinentry-0.7.4-5.fc9 plotutils-2.5-5.fc9 plt-scheme-372-1.fc9 purple-plugin_pack-2.3.0-1.fc9 putty-0.60-3.fc9 PyKDE-3.16.1-1.fc9 PyQt-3.17.4-4.fc9 qalculate-kde-0.9.6-5.fc9 qascade-0.1-10.fc9 qca-1.0-10.fc9 qcad-2.0.5.0-8.fc9 qca-tls-1.0-13.fc9 qcomicbook-0.4.0-2.fc9 qfaxreader-0.3.1-9.fc9.3 qgo-1.5.4r2-1.fc9 qiv-2.0-9.fc9 qps-1.9.19-0.2.b.fc7 qpxtool-0.6.1-9.fc9 qstars-0.4-6.fc9 qsynth-0.2.5-7.fc9 qt3-3.3.8b-12.fc9 qt-4.3.4-11.fc9 qtparted-0.4.5-18.fc9 qt-qsa-1.1.5-5.fc9 quadkonsole-2.0.2-3.fc9 qucs-0.0.14-1.fc9 qwtplot3d-0.2.7-6.fc9 rekall-2.4.6-4.fc9 rosegarden4-1.6.1-2.fc9 rsibreak-0.8.0-5.fc9 scigraphica-2.1.0-6.fc9 scim-bridge-0.4.15-5.fc9 scim-qtimm-0.9.4-10.fc9 scribus-1.3.4-5.fc9 showimg-0.9.5-16.fc9 siril-0.8-4.fc9 six-0.5.3-9.fc9 smart-0.52-54.fc9 smb4k-0.9.3-2.fc9 smpeg-0.4.4-11.lvn6 SoQt-1.4.1-9.fc9 soundtracker-0.6.8-2.fc6 spacechart-0.9.5-1.fc9 subcommander-1.2.2-12.fc9 synce-kde-0.9.1-3.fc9 t1lib-5.1.2-2.fc9 taskjuggler-2.4.0-7.fc9 taxipilot-0.9.2-6.fc9 tellico-1.3.1-1.fc9 tideEditor-1.4.1-2.fc9 transcode-1.0.5-2.lvn9 twinkle-1.2-2.fc9 uim-1.4.2-3.fc9 unixODBC-2.2.12-7.fc9 valknut-0.3.11-4.fc9 vtk-5.0.4-21.fc9 wlassistant-0.5.7-7.fc9 wordtrans-1.1-0.5.pre13.fc9 wpa_supplicant-0.6.3-5.fc9 x3270-3.3.6-5.fc9 xarchon-0.50-7.fc9 xawtv-3.95-8.fc9 xboard-4.2.7-17.fc9 xdrawchem-1.9.9-9.fc9 xfig-3.2.5-10.fc9 xkeycaps-2.46-7.fc9.3 xmms-1.2.10-38.fc9 xmms-acme-0.4.3-9 xmms-adplug-1.2-7.fc9 xmms-alarm-0.3.7-7.fc9 xmms-flac-1.1.4-4.fc9 xmms-lirc-1.4-12 xmms-mp3-1.2.10-5.lvn6 xmms-musepack-1.2-6.fc9 xmms-sid-0.8.0-0.5.beta17.fc9 xmms-speex-0.9.1-13 xorg-x11-apps-7.3-3.fc9 xorg-x11-resutils-7.1-5.fc9 xorg-x11-server-1.4.99.901-26.20080415.fc9 xorg-x11-server-utils-7.3-3.fc9 xorg-x11-utils-7.3-3.fc9 xorg-x11-xdm-1.1.6-3.fc9 xorg-x11-xkb-utils-7.2-4.fc9 xorg-x11-xsm-1.0.2-7.fc9 xosd-2.2.14-11.fc9 xterm-234-1.fc9 xtide-2.10-2.fc9 xvattr-1.3-15 yoltia-0.22.1-2.fc9 Next step, languages. (That can follow in a different mail.) After all, who needs old stuff like tcl, fortran, or Ada when we have python, ruby, and C? Bill From berrange at redhat.com Mon May 5 16:32:25 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 5 May 2008 17:32:25 +0100 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <20080505162919.GB7317@nostromo.devel.redhat.com> References: <1209999548.32107.11.camel@kennedy> <1210002510.26792.62.camel@beck.corsepiu.local> <481F306A.90600@redhat.com> <1210004495.26792.82.camel@beck.corsepiu.local> <20080505162919.GB7317@nostromo.devel.redhat.com> Message-ID: <20080505163225.GC5881@redhat.com> On Mon, May 05, 2008 at 12:29:19PM -0400, Bill Nottingham wrote: > > How comes you expect each and every tool in Fedora but the autotools to > > be "current". > > Next step, languages. (That can follow in a different mail.) > After all, who needs old stuff like tcl, fortran, or Ada when we have > python, ruby, and C? Nah, don't even need those - Perl6 ought to be enough for anyone Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From caillon at redhat.com Mon May 5 16:33:56 2008 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 05 May 2008 12:33:56 -0400 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <1210004495.26792.82.camel@beck.corsepiu.local> References: <1209999548.32107.11.camel@kennedy> <1210002510.26792.62.camel@beck.corsepiu.local> <481F306A.90600@redhat.com> <1210004495.26792.82.camel@beck.corsepiu.local> Message-ID: <481F36F4.4060105@redhat.com> On 05/05/2008 12:21 PM, Ralf Corsepius wrote: > On Mon, 2008-05-05 at 12:06 -0400, Christopher Aillon wrote: >> On 05/05/2008 11:48 AM, Ralf Corsepius wrote: >>> This step is way over due. It also will teach maintainers not run the >>> autotools while building. >> It will also teach maintainers not to use Fedora for doing upstream work. > > How comes you expect each and every tool in Fedora but the autotools to > be "current". > > We have current compilers, current python, current perl, current ... New compilers affects what's in the package. This affects users. New python affects the behavior of the package. This affects users. New perl affects the behavior of the package. This affects users. New autotools affects next to nothing. Only what configure.in and Makefile.in look like. This has zero impact for users. > But ... you are expecting Fedora to ship and support utterly outdated > autotools? I personally don't care what shell scripts are shipped. That's all they are, shell scripts. They don't ever need to be rebuilt, just be there because they are compat packages. Upstreams expect them to be there, and that's reason enough why I think we should continue to ship them. > You are measuring by double standards - If upstreams were writing proper > autotool files and where following upstream autotools as they apparently > are doing wrt. other tools, this issues would not exist. Or if autotools maintainers would stop changing the interface so freaking often, this wouldn't be a problem either.... From dlutter at redhat.com Mon May 5 16:27:07 2008 From: dlutter at redhat.com (David Lutterkort) Date: Mon, 05 May 2008 09:27:07 -0700 Subject: augeas - reading/modifying/writing system configuration files In-Reply-To: References: <481F0265.3040609@iinet.net.au> Message-ID: <1210004827.23255.3.camel@localhost.localdomain> On Mon, 2008-05-05 at 09:25 -0400, Neal Becker wrote: > Nice, but I think it would be nicer to implement this directly in python > (ducks...) Not sure how serious you are with that; the reason it is _not_ written in python (or perl or ruby or ...) is that I want it to be language neutral so that config file descriptions can be reused in python and ruby (and perl and ...) David From dlutter at redhat.com Mon May 5 16:37:25 2008 From: dlutter at redhat.com (David Lutterkort) Date: Mon, 05 May 2008 09:37:25 -0700 Subject: augeas - reading/modifying/writing system configuration files In-Reply-To: <20080505155016.GB3521@nostromo.devel.redhat.com> References: <20080505155016.GB3521@nostromo.devel.redhat.com> Message-ID: <1210005445.23255.12.camel@localhost.localdomain> On Mon, 2008-05-05 at 11:50 -0400, Bill Nottingham wrote: > If you have an existing already-invented parser for something, what's > the benefit? Uniformity ... there are lots of parsers for editing config files hidden in various tools; they all give you a completely different "API" for changing config files. And usually you can't get to them for any other purpose than what the tool is written for. Case in point: Webmin has a _ton_ of these config file editors in it. Good luck trying to use those, even assuming you are working from a Perl script (and better luck keeping that working across Webmin releases) David From lmacken at redhat.com Mon May 5 16:39:14 2008 From: lmacken at redhat.com (Luke Macken) Date: Mon, 5 May 2008 12:39:14 -0400 Subject: bodhi questions In-Reply-To: <20080503105227.e21d411b.mschwendt@gmail.com> References: <20080503105227.e21d411b.mschwendt@gmail.com> Message-ID: <20080505163914.GB3718@x300.redhat.com> On Sat, May 03, 2008 at 10:52:27AM +0200, Michael Schwendt wrote: > 1) Does the nvr input box work for anyone? It used to work long ago, but > here no longer finds any builds. I had to cut'n'paste a build tag into it. Yep, known issue[0]. We hit a regression with the AutoCompleteField widget with TurboGears-1.0.4.4, which has since been fixed upstream. > 2) Bug numbers: bodhi says it accepts CVE aliases. Hence I entered > CVE-2007-6061 which is an alias for bug 393251. It didn't reject it, > but later on no bug number appeared in my request. If I had known that, > I would have entered the bug number and not the alias. > > Instead, and possibly 3), I got internal server error 500 for two > consecutive update requests, although they made it into the system. Yeah, sounds like bugs with regard to handling bug aliases[1]. This stuff should be fixed in my git repo. > 4) Security updates: it confuses me a lot that I can choose to push > to stable, but the request is modified to push to "testing" instead. > Apparently, because approval from the security team is needed. > The request then reads "Requested: testing" without any indication > that "stable" was requested. I agree that this behavior is confusing, and will most likely change soon. I'm hoping to have all of the above, and more[2], fixed and deployed by F9. Thanks, luke [0]: https://fedorahosted.org/bodhi/ticket/119 [1]: https://fedorahosted.org/bodhi/ticket/172 [2]: https://fedorahosted.org/bodhi/query?status=new&status=assigned&status=reopened&milestone=Fedora+9+Release From rc040203 at freenet.de Mon May 5 16:39:05 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 05 May 2008 18:39:05 +0200 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <20080505162919.GB7317@nostromo.devel.redhat.com> References: <1209999548.32107.11.camel@kennedy> <1210002510.26792.62.camel@beck.corsepiu.local> <481F306A.90600@redhat.com> <1210004495.26792.82.camel@beck.corsepiu.local> <20080505162919.GB7317@nostromo.devel.redhat.com> Message-ID: <1210005545.26792.96.camel@beck.corsepiu.local> On Mon, 2008-05-05 at 12:29 -0400, Bill Nottingham wrote: > > How comes you expect each and every tool in Fedora but the autotools to > > be "current". > > That's it! > > OK, by Fedora 10 we need to start removing all sorts of not 'current' > things that aren't up to modern standards. > > First, toolkits! > > We need to remove gtk1, qt3, and for pete's sake, Xaw and Xaw3d. All > are obsolete, and users and developers are best served by upgrading > to more recent toolkits such as Qt4 and GTK2. > > The following 258 packages need ported by Fedora 10, or they will > be removed: I know you know, you are being ridiculous. BTW: I want to see gcc-4.2.x added to FC9 because gcc-4.3.0 breaks certain packages I am using and I do not want to change the code it breaks (in autoconf term: I need a bugwise compatible toolset). Unlike autoconf-2.13, gcc-4.2.x has an active upstream. Ralf From dlutter at redhat.com Mon May 5 16:46:37 2008 From: dlutter at redhat.com (David Lutterkort) Date: Mon, 05 May 2008 09:46:37 -0700 Subject: augeas - reading/modifying/writing system configuration files In-Reply-To: <20080505130810.GA26393@evileye.atkac.englab.brq.redhat.com> References: <20080505130810.GA26393@evileye.atkac.englab.brq.redhat.com> Message-ID: <1210005997.23255.23.camel@localhost.localdomain> On Mon, 2008-05-05 at 15:08 +0200, Adam Tkac wrote: > In my opinion we need one tool which will load plugins and > configuration files should be modified through them. That's kinda where I started from (with "plugin" meaning fairly arbitrary code that gets loaded and executed) Since I wanted Augeas to be language neutral (fancy way of saying "written in C"), that would mean plugins written in C - and everybody loves writing text processing code in C :( Two big goals for Augeas for me are 1. has to be useful without any support from upstream (i.e., no "it will work great if project X takes our patches") 2. describing a new config file format should be reasonably easy The second one eventually got me to implement a domain-specific language for file format descriptions. The description for /etc/hosts is at [1], and a more detailed explanation of what is happening is at [2]. So, the "plugin" that needs to be shipped to enable Augeas to process some config file X is a text file; right now, they are all shipped as part of Augeas, but eventually, I'd hope that they can be maintained closer to the source. David [1] http://hg.et.redhat.com/misc/augeas?f=58bdfbc2e031;file=lenses/hosts.aug [2] http://augeas.net/docs/writing-schemas.html From ricky at fedoraproject.org Mon May 5 16:47:42 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Mon, 5 May 2008 12:47:42 -0400 Subject: Upstream developers mainting there own package in Fedora and nothing else In-Reply-To: <62bc09df0805050541k49049e1aq8ebe72eb4490ef55@mail.gmail.com> References: <481EC4E2.2030807@hhs.nl> <20080505115913.caa57949.mschwendt@gmail.com> <481EE341.6000209@hhs.nl> <20080505125652.6e85cbe8.mschwendt@gmail.com> <62bc09df0805050426q324a4708hb4b5a794c07bac5@mail.gmail.com> <20080505141312.19a6060d.mschwendt@gmail.com> <62bc09df0805050541k49049e1aq8ebe72eb4490ef55@mail.gmail.com> Message-ID: <20080505164742.GB8989@Max> On 2008-05-05 02:41:42 PM, Xavier Lamien wrote: > yeah; i think that you will wish to have a "sponsor" button in your "todo > queue" or in the account page of the requested user, to avoid to browse all > the group list. > This could be an improvment for fas2. Ah, good point - could you file a ticket at https://fedorahosted.org/fas/ for this and any other FAS improvements? Thanks a lot, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dlutter at redhat.com Mon May 5 16:49:32 2008 From: dlutter at redhat.com (David Lutterkort) Date: Mon, 05 May 2008 09:49:32 -0700 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <20080505163225.GC5881@redhat.com> References: <1209999548.32107.11.camel@kennedy> <1210002510.26792.62.camel@beck.corsepiu.local> <481F306A.90600@redhat.com> <1210004495.26792.82.camel@beck.corsepiu.local> <20080505162919.GB7317@nostromo.devel.redhat.com> <20080505163225.GC5881@redhat.com> Message-ID: <1210006172.23255.25.camel@localhost.localdomain> On Mon, 2008-05-05 at 17:32 +0100, Daniel P. Berrange wrote: > Nah, don't even need those - Perl6 ought to be enough for anyone Sounds like we're skipping F10, and continue the regularly scheduled releases with F12 or so ;) David From aph at redhat.com Mon May 5 16:50:30 2008 From: aph at redhat.com (Andrew Haley) Date: Mon, 05 May 2008 17:50:30 +0100 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <481F306A.90600@redhat.com> References: <1209999548.32107.11.camel@kennedy> <1210002510.26792.62.camel@beck.corsepiu.local> <481F306A.90600@redhat.com> Message-ID: <481F3AD6.9030407@redhat.com> Christopher Aillon wrote: > On 05/05/2008 11:48 AM, Ralf Corsepius wrote: >> This step is way over due. It also will teach maintainers not run the >> autotools while building. > > It will also teach maintainers not to use Fedora for doing upstream work. I agree. This proposal seems to be all pain for no gain. Andrew. From rc040203 at freenet.de Mon May 5 16:53:59 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 05 May 2008 18:53:59 +0200 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <481F36F4.4060105@redhat.com> References: <1209999548.32107.11.camel@kennedy> <1210002510.26792.62.camel@beck.corsepiu.local> <481F306A.90600@redhat.com> <1210004495.26792.82.camel@beck.corsepiu.local> <481F36F4.4060105@redhat.com> Message-ID: <1210006440.26792.109.camel@beck.corsepiu.local> On Mon, 2008-05-05 at 12:33 -0400, Christopher Aillon wrote: > On 05/05/2008 12:21 PM, Ralf Corsepius wrote: > > On Mon, 2008-05-05 at 12:06 -0400, Christopher Aillon wrote: > >> On 05/05/2008 11:48 AM, Ralf Corsepius wrote: > >>> This step is way over due. It also will teach maintainers not run the > >>> autotools while building. > >> It will also teach maintainers not to use Fedora for doing upstream work. > > > > How comes you expect each and every tool in Fedora but the autotools to > > be "current". > > > > We have current compilers, current python, current perl, current ... > > New compilers affects what's in the package. This affects users. > New python affects the behavior of the package. This affects users. > New perl affects the behavior of the package. This affects users. > > New autotools affects next to nothing. The autotools are in the same boat as compilers. Compiler changes break existing code, autotools changes break existing code. Both issues affect source code (configure.in/ac, rsp. *.c/*.c++) and need to be fixed therein. > Only what configure.in and > Makefile.in look like. This has zero impact for users. Both, a compilers user as well as an autotool's users, is the developer. In an ideal world, a Fedora package maintainer should not have to touch any of these sources, neither *.c, *.c++ nor *.am or *.ac. > > You are measuring by double standards - If upstreams were writing proper > > autotool files and where following upstream autotools as they apparently > > are doing wrt. other tools, this issues would not exist. > > Or if autotools maintainers would stop changing the interface so > freaking often, this wouldn't be a problem either.... Apparently you don't have much clues about the autotools. They did not change the "interface so often". There has been one big interface change: It occurred between autoconf-2.13 and autoconf-2.50 - Many years ago. All other changes since then had been minor. In the same time, gcc has changed incompatibly many more times, not worth mentioning g++/libstdc++ or even c++ standards having changed. Do you remember the gcc-4.3.0 recompilation campaign in Fedora some months ago? If people had adjusted their autotool's source files with the same engagement and submitted their changes upstream, for years ... this issue would not exist .... Ralf From a.badger at gmail.com Mon May 5 16:55:53 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 05 May 2008 09:55:53 -0700 Subject: **** Access denied: nbecker is not in ACL for rpms/libotf/devel In-Reply-To: References: Message-ID: <481F3C19.8030907@gmail.com> Neal Becker wrote: > **** Access denied: nbecker is not in ACL for rpms/libotf/devel > > The acl for libotf was set to allow cvsextras commits this morning. Perhaps you tried it before the new acls were synced to the cvs server? (This is currently performed by an hourly cron job.) Does it work now? -Toshio From alan at clueserver.org Mon May 5 17:02:01 2008 From: alan at clueserver.org (Alan) Date: Mon, 5 May 2008 10:02:01 -0700 (PDT) Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <1210006172.23255.25.camel@localhost.localdomain> References: <1209999548.32107.11.camel@kennedy> <1210002510.26792.62.camel@beck.corsepiu.local> <481F306A.90600@redhat.com> <1210004495.26792.82.camel@beck.corsepiu.local> <20080505162919.GB7317@nostromo.devel.redhat.com> <20080505163225.GC5881@redhat.com> <1210006172.23255.25.camel@localhost.localdomain> Message-ID: <53913.75.164.221.130.1210006921.squirrel@clueserver.org> > > On Mon, 2008-05-05 at 17:32 +0100, Daniel P. Berrange wrote: >> Nah, don't even need those - Perl6 ought to be enough for anyone > > Sounds like we're skipping F10, and continue the regularly scheduled > releases with F12 or so ;) Soon we will run out of function keys entirely. I propose that F13 be named either "scroll lock" or "num lock". From jkeating at redhat.com Mon May 5 17:10:47 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 05 May 2008 13:10:47 -0400 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <53913.75.164.221.130.1210006921.squirrel@clueserver.org> References: <1209999548.32107.11.camel@kennedy> <1210002510.26792.62.camel@beck.corsepiu.local> <481F306A.90600@redhat.com> <1210004495.26792.82.camel@beck.corsepiu.local> <20080505162919.GB7317@nostromo.devel.redhat.com> <20080505163225.GC5881@redhat.com> <1210006172.23255.25.camel@localhost.localdomain> <53913.75.164.221.130.1210006921.squirrel@clueserver.org> Message-ID: <1210007447.29415.93.camel@localhost.localdomain> On Mon, 2008-05-05 at 10:02 -0700, Alan wrote: > > Soon we will run out of function keys entirely. > > I propose that F13 be named either "scroll lock" or "num lock". The keyboard in my cube that I do most testing on goes up to f19. I think we're OK for a while. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From caillon at redhat.com Mon May 5 17:11:02 2008 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 05 May 2008 13:11:02 -0400 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <1210006440.26792.109.camel@beck.corsepiu.local> References: <1209999548.32107.11.camel@kennedy> <1210002510.26792.62.camel@beck.corsepiu.local> <481F306A.90600@redhat.com> <1210004495.26792.82.camel@beck.corsepiu.local> <481F36F4.4060105@redhat.com> <1210006440.26792.109.camel@beck.corsepiu.local> Message-ID: <481F3FA6.2050508@redhat.com> On 05/05/2008 12:53 PM, Ralf Corsepius wrote: > Do you remember the gcc-4.3.0 recompilation campaign in Fedora some > months ago? If people had adjusted their autotool's source files with > the same engagement and submitted their changes upstream, for years ... > this issue would not exist .... If you want to bring up the gcc 4.3 switch, let's make this easy then: I personally did a bunch of the gcc 4.3 porting for other people's packages including patching, rebuilding, etc. How about someone return the favor and port mine to use new autotools? Again, the bug is https://bugzilla.mozilla.org/show_bug.cgi?id=104642 Someone posted a patch to the aforementioned bug which was rejected because it broke several requirements for Mozilla. If someone fixes those and gets it committed upstream (I have commit access and can help do so once it is approved by the build team upstream), I am more than happy to consider withdrawing my objections to this proposal. But, the likelihood of it happening for Firefox 3 is remote being that we're on the cusp of releasing it. And since I doubt the next major release of Firefox will be out by F10, or even F11, we'll still need to support autoconf213 for a few more cycles. From mjs at clemson.edu Mon May 5 17:15:54 2008 From: mjs at clemson.edu (Matthew Saltzman) Date: Mon, 05 May 2008 13:15:54 -0400 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <481F36F4.4060105@redhat.com> References: <1209999548.32107.11.camel@kennedy> <1210002510.26792.62.camel@beck.corsepiu.local> <481F306A.90600@redhat.com> <1210004495.26792.82.camel@beck.corsepiu.local> <481F36F4.4060105@redhat.com> Message-ID: <1210007755.26358.34.camel@valkyrie.localdomain> On Mon, 2008-05-05 at 12:33 -0400, Christopher Aillon wrote: > Or if autotools maintainers would stop changing the interface so > freaking often, this wouldn't be a problem either.... Wow, for a second there, you seemed to be channeling Les M... -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From berrange at redhat.com Mon May 5 17:17:15 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 5 May 2008 18:17:15 +0100 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <53913.75.164.221.130.1210006921.squirrel@clueserver.org> References: <1209999548.32107.11.camel@kennedy> <1210002510.26792.62.camel@beck.corsepiu.local> <481F306A.90600@redhat.com> <1210004495.26792.82.camel@beck.corsepiu.local> <20080505162919.GB7317@nostromo.devel.redhat.com> <20080505163225.GC5881@redhat.com> <1210006172.23255.25.camel@localhost.localdomain> <53913.75.164.221.130.1210006921.squirrel@clueserver.org> Message-ID: <20080505171715.GE5881@redhat.com> On Mon, May 05, 2008 at 10:02:01AM -0700, Alan wrote: > > > > On Mon, 2008-05-05 at 17:32 +0100, Daniel P. Berrange wrote: > >> Nah, don't even need those - Perl6 ought to be enough for anyone > > > > Sounds like we're skipping F10, and continue the regularly scheduled > > releases with F12 or so ;) > > Soon we will run out of function keys entirely. > > I propose that F13 be named either "scroll lock" or "num lock". The next is SysRq on my keyboard :-) Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From ssorce at redhat.com Mon May 5 17:31:31 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 05 May 2008 13:31:31 -0400 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <20080505171715.GE5881@redhat.com> References: <1209999548.32107.11.camel@kennedy> <1210002510.26792.62.camel@beck.corsepiu.local> <481F306A.90600@redhat.com> <1210004495.26792.82.camel@beck.corsepiu.local> <20080505162919.GB7317@nostromo.devel.redhat.com> <20080505163225.GC5881@redhat.com> <1210006172.23255.25.camel@localhost.localdomain> <53913.75.164.221.130.1210006921.squirrel@clueserver.org> <20080505171715.GE5881@redhat.com> Message-ID: <1210008691.12808.229.camel@localhost.localdomain> On Mon, 2008-05-05 at 18:17 +0100, Daniel P. Berrange wrote: > On Mon, May 05, 2008 at 10:02:01AM -0700, Alan wrote: > > > > > > On Mon, 2008-05-05 at 17:32 +0100, Daniel P. Berrange wrote: > > >> Nah, don't even need those - Perl6 ought to be enough for anyone > > > > > > Sounds like we're skipping F10, and continue the regularly scheduled > > > releases with F12 or so ;) > > > > Soon we will run out of function keys entirely. > > > > I propose that F13 be named either "scroll lock" or "num lock". > > The next is SysRq on my keyboard :-) On the laptop i have "Delete", on the external keyboard I have a key named "Wake" ... then a "Suspend" key that I just discovered is actually working ... :-) Simo. -- Simo Sorce * Red Hat, Inc * New York From ndbecker2 at gmail.com Mon May 5 17:33:57 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Mon, 05 May 2008 13:33:57 -0400 Subject: **** Access denied: nbecker is not in ACL for rpms/libotf/devel References: <481F3C19.8030907@gmail.com> Message-ID: Toshio Kuratomi wrote: > Neal Becker wrote: >> **** Access denied: nbecker is not in ACL for rpms/libotf/devel >> >> > The acl for libotf was set to allow cvsextras commits this morning. > Perhaps you tried it before the new acls were synced to the cvs server? > (This is currently performed by an hourly cron job.) Does it work now? > > -Toshio > OK now, thanks. From dmalcolm at redhat.com Mon May 5 17:38:26 2008 From: dmalcolm at redhat.com (David Malcolm) Date: Mon, 05 May 2008 13:38:26 -0400 Subject: augeas - reading/modifying/writing system configuration files In-Reply-To: <1210005445.23255.12.camel@localhost.localdomain> References: <20080505155016.GB3521@nostromo.devel.redhat.com> <1210005445.23255.12.camel@localhost.localdomain> Message-ID: <1210009106.3871.3.camel@dhcp-100-2-213.bos.redhat.com> On Mon, 2008-05-05 at 09:37 -0700, David Lutterkort wrote: > On Mon, 2008-05-05 at 11:50 -0400, Bill Nottingham wrote: > > If you have an existing already-invented parser for something, what's > > the benefit? > > Uniformity ... there are lots of parsers for editing config files hidden > in various tools; they all give you a completely different "API" for > changing config files. And usually you can't get to them for any other > purpose than what the tool is written for. > > Case in point: Webmin has a _ton_ of these config file editors in it. > Good luck trying to use those, even assuming you are working from a Perl > script (and better luck keeping that working across Webmin releases) The other thing that doesn't seem to have been mentioned yet: how well does augeas preserve whitespace/comments etc when writing changes back out? (to play well with hand-edited config files) I got the impression reading the web site that it does this "for free" once you've written the input lens. (how well does it work?) I suspect that a hand-coded parser typically won't do as good a job of this. Hope this helps Dave From skvidal at fedoraproject.org Mon May 5 17:39:18 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 05 May 2008 13:39:18 -0400 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <20080505162919.GB7317@nostromo.devel.redhat.com> References: <1209999548.32107.11.camel@kennedy> <1210002510.26792.62.camel@beck.corsepiu.local> <481F306A.90600@redhat.com> <1210004495.26792.82.camel@beck.corsepiu.local> <20080505162919.GB7317@nostromo.devel.redhat.com> Message-ID: <1210009158.12284.11.camel@cutter> On Mon, 2008-05-05 at 12:29 -0400, Bill Nottingham wrote: > > How comes you expect each and every tool in Fedora but the autotools to > > be "current". > > That's it! > > OK, by Fedora 10 we need to start removing all sorts of not 'current' > things that aren't up to modern standards. > > First, toolkits! > > We need to remove gtk1, qt3, and for pete's sake, Xaw and Xaw3d. All > are obsolete, and users and developers are best served by upgrading > to more recent toolkits such as Qt4 and GTK2. > > The following 258 packages need ported by Fedora 10, or they will > be removed: +1 > Next step, languages. (That can follow in a different mail.) > After all, who needs old stuff like tcl, fortran, or Ada when we have > python, ruby, and C? +1 Sadly, you're joking. But I would love to get rid of the libraries you mentioned before. -sv From greno at verizon.net Mon May 5 18:03:27 2008 From: greno at verizon.net (Gerry Reno) Date: Mon, 05 May 2008 14:03:27 -0400 Subject: F9 nfs, rpcbind, NetworkManager Message-ID: <481F4BEF.8030004@verizon.net> On the machines I put all my nfs mounting into rc.local so that nfs mounts are available at login. With F9 I notice that all the nfs mount requests in rc.local die with 'mount.nfs: internal error'. When I look at the log during the bootup sequence I see that rpcbind says that it cannot access the machines IP. Right after that NetworkManager starts. And shortly after that rc.local runs. Somehow this sequence is causing problems for mounting nfs directories. Once I get logged in, I can run the mount commands manually and they succeed but the same commands fail from rc.local. Regards, Gerry From dlutter at redhat.com Mon May 5 18:05:10 2008 From: dlutter at redhat.com (David Lutterkort) Date: Mon, 05 May 2008 11:05:10 -0700 Subject: augeas - reading/modifying/writing system configuration files In-Reply-To: <1210009106.3871.3.camel@dhcp-100-2-213.bos.redhat.com> References: <20080505155016.GB3521@nostromo.devel.redhat.com> <1210005445.23255.12.camel@localhost.localdomain> <1210009106.3871.3.camel@dhcp-100-2-213.bos.redhat.com> Message-ID: <1210010710.23255.47.camel@localhost.localdomain> On Mon, 2008-05-05 at 13:38 -0400, David Malcolm wrote: > The other thing that doesn't seem to have been mentioned yet: how well > does augeas preserve whitespace/comments etc when writing changes back > out? (to play well with hand-edited config files) Heh .. yeah, forgot to mention the point that caused most of the pain in implementing: keeping comments, formatting detail etc. is incredibly important and Augeas works very hard to meet an intutitve notion of "minimal edit". At the same time, it does not rely on any Augeas-specific annotation in the files, so that you can freely interleave changing a file with Augeas with any other means of changing it (from vi to your favorite Perl script) > I got the impression reading the web site that it does this "for free" > once you've written the input lens. (how well does it work?) The files tests/*.rb[1] in the mercurial repo contain examples of how changes to the tree correspond to changes in files. Diffs in those files are against files in tests/root/ from the mercurial repo. > I suspect that a hand-coded parser typically won't do as good a job of this. Yeah, it's painful (I tried) It's also where the "original" parser from whatever consumes those config files becomes useless for editing: they typically discard all that information (as they should; there's no need to hang on to that information if you're only reading config data) David [1] http://hg.et.redhat.com/misc/augeas?cmd=manifest;manifest=04452485c2e89a718d09bfa6fe377da1fb9244b1;path=/tests/ From rc040203 at freenet.de Mon May 5 12:34:10 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 05 May 2008 14:34:10 +0200 Subject: Upstream developers mainting there own package in Fedora and nothing else In-Reply-To: <481EC4E2.2030807@hhs.nl> References: <481EC4E2.2030807@hhs.nl> Message-ID: <1209990850.2954.113.camel@beck.corsepiu.local> On Mon, 2008-05-05 at 10:27 +0200, Hans de Goede wrote: > Hi All, > > After the sponsor discussion we recently had, I decided I've been neglecting > the sponsoring and went and took a look at the FE-NEEDSPONSOR queue. > > One of the reviews this has got me involved in is fpm2: > https://bugzilla.redhat.com/show_bug.cgi?id=444830 > > This review is special as the upstream developer is submitting the package, and > he has stated that for now he has no interest in doing other Fedora work. Our policy has always been: For a package to be part of Fedora, it must be maintained as part of Fedora. It's completely irrelevant whether this person is upstream or whether somebody else volunteers. I for one consider cases like the one you describe above to be "drive by submissions", and consider playing nice to them to be counter productive to Fedora. Ralf From alan at clueserver.org Mon May 5 18:14:07 2008 From: alan at clueserver.org (Alan) Date: Mon, 5 May 2008 11:14:07 -0700 (PDT) Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <1210008691.12808.229.camel@localhost.localdomain> References: <1209999548.32107.11.camel@kennedy> <1210002510.26792.62.camel@beck.corsepiu.local> <481F306A.90600@redhat.com> <1210004495.26792.82.camel@beck.corsepiu.local> <20080505162919.GB7317@nostromo.devel.redhat.com> <20080505163225.GC5881@redhat.com> <1210006172.23255.25.camel@localhost.localdomain> <53913.75.164.221.130.1210006921.squirrel@clueserver.org> <20080505171715.GE5881@redhat.com> <1210008691.12808.229.camel@localhost.localdomain> Message-ID: <39478.75.164.221.130.1210011247.squirrel@clueserver.org> > > On Mon, 2008-05-05 at 18:17 +0100, Daniel P. Berrange wrote: >> On Mon, May 05, 2008 at 10:02:01AM -0700, Alan wrote: >> > > >> > > On Mon, 2008-05-05 at 17:32 +0100, Daniel P. Berrange wrote: >> > >> Nah, don't even need those - Perl6 ought to be enough for anyone >> > > >> > > Sounds like we're skipping F10, and continue the regularly scheduled >> > > releases with F12 or so ;) >> > >> > Soon we will run out of function keys entirely. >> > >> > I propose that F13 be named either "scroll lock" or "num lock". >> >> The next is SysRq on my keyboard :-) > > On the laptop i have "Delete", on the external keyboard I have a key > named "Wake" ... then a "Suspend" key that I just discovered is actually > working ... :-) On my system "wake" is an accurate description of what happens after "suspend". A funeral with lots of drinking. I have yet to get X to come back after suspend on an x86_64 system. (Both laptops have problems with this. Not certain if it just an HP problem or what.) From jbarnes at virtuousgeek.org Mon May 5 18:21:54 2008 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Mon, 5 May 2008 11:21:54 -0700 Subject: Help with hal-acl-tool crashes? Message-ID: <200805051121.54629.jbarnes@virtuousgeek.org> I filed 439938 awhile ago, which reports a problem with permissions not being set correctly on /dev/snd and other devices at login time. If I restart the HAL daemon after I login, the acls are updated and things work, but in trying to find a workaround I discovered that hal-acl-tool was crashing (info in the bug). Anyone have ideas about this? The bug hasn't seen any updates, so I figured I'd try to get some more eyes on it... Thanks, Jesse From greno at verizon.net Mon May 5 18:21:53 2008 From: greno at verizon.net (Gerry Reno) Date: Mon, 05 May 2008 14:21:53 -0400 Subject: F9 nfs, rpcbind, NetworkManager In-Reply-To: <481F4BEF.8030004@verizon.net> References: <481F4BEF.8030004@verizon.net> Message-ID: <481F5041.4050005@verizon.net> Gerry Reno wrote: > On the machines I put all my nfs mounting into rc.local so that nfs > mounts are available at login. With F9 I notice that all the nfs > mount requests in rc.local die with 'mount.nfs: internal error'. When > I look at the log during the bootup sequence I see that rpcbind says > that it cannot access the machines IP. Right after that > NetworkManager starts. And shortly after that rc.local runs. Somehow > this sequence is causing problems for mounting nfs directories. Once > I get logged in, I can run the mount commands manually and they > succeed but the same commands fail from rc.local. > > Regards, > Gerry > I found that the network is not being started until NetworkManager runs. This is way late in the boot sequence. If I have the network start normally by 'chkconfig network on' and reboot then I see the network start early in the sequence with NetworkManager at the end of the sequence and all the nfs mounts succeed but by the time I get logged in there is no network connection (the little net icon at the top has an X) and the mounts hang. How do I get the network started early enough in the boot with this NetworkManager in the picture? Regards, Gerry From tibbs at math.uh.edu Mon May 5 18:24:27 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 05 May 2008 13:24:27 -0500 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <1209999548.32107.11.camel@kennedy> References: <1209999548.32107.11.camel@kennedy> Message-ID: I'm not sure I can go along with this. I'm sure we'd all agree that there's no point in carrying old versions of various pieces of software for no reason, but we shouldn't drop them all just because they're not current. Instead we should (periodically) evaluate why we have those in the distro and decide if we want to continue to have them. So autoconf213 is needed for firefox development. That's certainly a valid reason, and it should be documented somewhere (in the autoconf213 spec, maybe) so that we won't forget next year when someone again asks why we still have autoconf213 around. Perhaps we can port a few packages over to a recent automake and get rid of some of the old versions. It certainly wouldn't be a bad thing. - J< From notting at redhat.com Mon May 5 18:26:26 2008 From: notting at redhat.com (Bill Nottingham) Date: Mon, 5 May 2008 14:26:26 -0400 Subject: F9 nfs, rpcbind, NetworkManager In-Reply-To: <481F5041.4050005@verizon.net> References: <481F4BEF.8030004@verizon.net> <481F5041.4050005@verizon.net> Message-ID: <20080505182626.GA14432@nostromo.devel.redhat.com> Gerry Reno (greno at verizon.net) said: > hang. How do I get the network started early enough in the boot with this > NetworkManager in the picture? for service in messagebus haldaemon NetworkManager ; do chkconfig $service resetpriorities done Bill From a.badger at gmail.com Mon May 5 18:26:46 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 05 May 2008 11:26:46 -0700 Subject: python packaging - icons/desktop files and /usr/bin accessibility In-Reply-To: References: <481EFE72.1030105@iinet.net.au> Message-ID: <481F5166.8070201@gmail.com> Mary Ellen Foster wrote: > On Mon, May 5, 2008 at 1:32 PM, David Timms wrote: >> I'm packaging a basic python program, and request some guidance: >> >> 1. the app has three main .py programs, and another 10 or so .py modules. >> My installed rpm puts these in site-packages/appname which I understand the >> guidelines to require. Problem is these are not accessible as a user because >> they aren't on the path. >> So it works if I /usr/lib/python../site-packages/myapp/app1.py >> >> Should I be messing with the path ? >> Creating a shell script for each of the main programs, and dropping them in >> /usr/bin ? > > Note that if you want the libraries to be available to Python, as far > as I understand it, the standard way to do this is to a "*.pth" file > and put it into site-packages. For example, for my package (which puts > files into an "Ice" subdirectory), I created a file called ice.pth > containing only the following: > Ice > For yours, you probably want to create "myapp.pth" containing the line > "myapp" and install that into site-packages. > > This doesn't answer the question of how to run the programs, though, of course. > Personally, I avoid .pth files when possible because of the performance hit that they cause. I'd much rather set PYTHONPATH individually for each application that needs to know about a special path. For doing this in python, you can look at /usr/bin/yum. For doing it in bourne shell /usr/bin/gramps (from the gramps package.) ice may be a special case because it is a module requiring another module although I need to look a little closer at that. Something looks fishy about what python-ice is doing. Also note that this particular case doesn't seem to need a .pth file/PYTHONPATH changes as, if I'm reading it correctly, the module is being installed into site-packages which python searches under normal circumstances. It's just that the application file itself is also being installed into site-packages so invoking the application fails to find /usr/bin/APPNAME. -Toshio From alan at clueserver.org Mon May 5 18:33:11 2008 From: alan at clueserver.org (Alan) Date: Mon, 5 May 2008 11:33:11 -0700 (PDT) Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: References: <1209999548.32107.11.camel@kennedy> Message-ID: <52564.75.164.221.130.1210012391.squirrel@clueserver.org> > I'm not sure I can go along with this. I'm sure we'd all agree that > there's no point in carrying old versions of various pieces of > software for no reason, but we shouldn't drop them all just because > they're not current. Instead we should (periodically) evaluate why we > have those in the distro and decide if we want to continue to have > them. So autoconf213 is needed for firefox development. That's > certainly a valid reason, and it should be documented somewhere (in > the autoconf213 spec, maybe) so that we won't forget next year when > someone again asks why we still have autoconf213 around. > > Perhaps we can port a few packages over to a recent automake and get > rid of some of the old versions. It certainly wouldn't be a bad > thing. I have a bit of a problem with this. I build a fair amount of software that is not in the repository. Some of it requires crufty old versions of various toolkits. Having those toolkits go away makes it much harder to get this packages to run. If I have an older version that does compile, I can determine if it even works at all. (Which happens far too often for me. *cough* *cough* numerix *cough*) It is not just the things in the distro you need to worry about. It is also the things that others may want to build using the distro. From rc040203 at freenet.de Mon May 5 15:51:09 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 05 May 2008 17:51:09 +0200 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <481F2986.8010509@redhat.com> References: <1209999548.32107.11.camel@kennedy> <481F2986.8010509@redhat.com> Message-ID: <1210002669.26792.65.camel@beck.corsepiu.local> On Mon, 2008-05-05 at 11:36 -0400, Christopher Aillon wrote: > On 05/05/2008 10:59 AM, Brian Pepple wrote: > Unless someone steps up and does the work to get this upstream properly, > I am afraid I, along with some of the mozilla upstream developers, will > no longer be able to use rawhide if we drop autoconf213 from it. This is a non-issue if upstream uses the autotools properly, i.e. is shipping pre-generated files and doesn't run them while building. Ralf From dr.diesel at gmail.com Mon May 5 18:37:42 2008 From: dr.diesel at gmail.com (Dr. Diesel) Date: Mon, 5 May 2008 13:37:42 -0500 Subject: Kerneloops? Message-ID: <2a28d2ab0805051137v3ce04bb9y54bce09b06b427f6@mail.gmail.com> Had a Kerneloops message pop up today, said something about a critical error, didn't bother to tell me what the error was! Where is this stored, doesn't seem to be in the normal log locations? -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org From optimizationkit at gmail.com Mon May 5 18:44:30 2008 From: optimizationkit at gmail.com (Optimization Kit) Date: Mon, 5 May 2008 20:44:30 +0200 Subject: Kerneloops? In-Reply-To: <2a28d2ab0805051137v3ce04bb9y54bce09b06b427f6@mail.gmail.com> References: <2a28d2ab0805051137v3ce04bb9y54bce09b06b427f6@mail.gmail.com> Message-ID: <58a220fa0805051144g788d9f1g84ae213b2e22c6c9@mail.gmail.com> On 05/05/2008, Dr. Diesel wrote: > Had a Kerneloops message pop up today, said something about a critical > error, didn't bother to tell me what the error was! > > Where is this stored, doesn't seem to be in the normal log locations? Should be in /var/log/messages If you want to read more about kernel bugs http://www.stardust.webpages.pl/files/handbook/handbook-en-0.3-rc1.pdf From sandeen at redhat.com Mon May 5 18:51:44 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Mon, 05 May 2008 13:51:44 -0500 Subject: Kerneloops? In-Reply-To: <2a28d2ab0805051137v3ce04bb9y54bce09b06b427f6@mail.gmail.com> References: <2a28d2ab0805051137v3ce04bb9y54bce09b06b427f6@mail.gmail.com> Message-ID: <481F5740.5070104@redhat.com> Dr. Diesel wrote: > Had a Kerneloops message pop up today, said something about a critical > error, didn't bother to tell me what the error was! > > Where is this stored, doesn't seem to be in the normal log locations? kerneloops sends oopses to kerneloops.org, if you let it (did it ask?) I've never actually seen the kerneloops-applet in action, dunno what it says or looks like... if it's not helpful or confusing I suppose that should be fixed. :) It should also be in the "normal" places, /var/log/messages or at least the console. -Eric From tibbs at math.uh.edu Mon May 5 18:56:58 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 05 May 2008 13:56:58 -0500 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <1210002669.26792.65.camel@beck.corsepiu.local> References: <1209999548.32107.11.camel@kennedy> <481F2986.8010509@redhat.com> <1210002669.26792.65.camel@beck.corsepiu.local> Message-ID: >>>>> "RC" == Ralf Corsepius writes: RC> This is a non-issue if upstream uses the autotools properly, RC> i.e. is shipping pre-generated files and doesn't run them while RC> building. The upstream developers still need to have autoconf213 in order to actually develop the package, though. Hence they still need to get that old version of the package from somewhere. I see no reason why Fedora shouldn't simply provide it for them. - J< From tibbs at math.uh.edu Mon May 5 18:59:32 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 05 May 2008 13:59:32 -0500 Subject: Upstream developers mainting there own package in Fedora and nothing else In-Reply-To: <481EC4E2.2030807@hhs.nl> References: <481EC4E2.2030807@hhs.nl> Message-ID: >>>>> "HdG" == Hans de Goede writes: HdG> This review is special as the upstream developer is submitting HdG> the package, and he has stated that for now he has no interest in HdG> doing other Fedora work. That's fine; if I came across such a ticket, I'd simply sponsor the person. I simply didn't see it. It's probably better if they can get a real co-maintainer, though. In the future, sure, the maintainer containment stuff works great for this. But we simply can't wait for it to appear. - J< From dr.diesel at gmail.com Mon May 5 19:01:22 2008 From: dr.diesel at gmail.com (Dr. Diesel) Date: Mon, 5 May 2008 14:01:22 -0500 Subject: Kerneloops? In-Reply-To: <481F5740.5070104@redhat.com> References: <2a28d2ab0805051137v3ce04bb9y54bce09b06b427f6@mail.gmail.com> <481F5740.5070104@redhat.com> Message-ID: <2a28d2ab0805051201r61008ebcrff6f07ec4aeff05d@mail.gmail.com> On Mon, May 5, 2008 at 1:51 PM, Eric Sandeen wrote: > Dr. Diesel wrote: > > Had a Kerneloops message pop up today, said something about a critical > > error, didn't bother to tell me what the error was! > > > > Where is this stored, doesn't seem to be in the normal log locations? > > kerneloops sends oopses to kerneloops.org, if you let it (did it ask?) > > I've never actually seen the kerneloops-applet in action, dunno what it > says or looks like... if it's not helpful or confusing I suppose that > should be fixed. :) > > It should also be in the "normal" places, /var/log/messages or at least > the console. > > -Eric Guess I thought there would have been a /var/log/kerneloops or something! Kerneloops --help and man kerneloops don't exist! Nothing kerneloops specific in /var/log/messages Tons of GDM debug though... I let it submit to Kerneloops.org, GUI looked nice, just wanted to know what the error was. -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org From rdieter at math.unl.edu Mon May 5 19:07:23 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 05 May 2008 14:07:23 -0500 Subject: FESCo Proposal for blocking older version of autoconf & automake References: <1209999548.32107.11.camel@kennedy> Message-ID: Jason L Tibbitts III wrote: > I'm not sure I can go along with this. Nod, -1 here. If folks exist that want to maintain (and use) these crufty autofoo pkgs, let 'em continue to do their thing. Am I missing something? Are these older packages causing some harm? Are the primary autoconf/automake maintainers objecting to these compat pkgs? -- Rex From greno at verizon.net Mon May 5 19:07:44 2008 From: greno at verizon.net (Gerry Reno) Date: Mon, 05 May 2008 15:07:44 -0400 Subject: F9 nfs, rpcbind, NetworkManager In-Reply-To: <20080505182626.GA14432@nostromo.devel.redhat.com> References: <481F4BEF.8030004@verizon.net> <481F5041.4050005@verizon.net> <20080505182626.GA14432@nostromo.devel.redhat.com> Message-ID: <481F5B00.6030707@verizon.net> Bill Nottingham wrote: > Gerry Reno (greno at verizon.net) said: > >> hang. How do I get the network started early enough in the boot with this >> NetworkManager in the picture? >> > > for service in messagebus haldaemon NetworkManager ; do > chkconfig $service resetpriorities > done > > Bill > > Thanks Bill. I did this and I see that in 2 3 4 5 it goes from K90 network to S10 network. I then did 'chkconfig network on' and rebooted and the mounts work from rc.local but when I get logged in there is no network. Somehow the network service and the NetworkManager service get in conflict. How to fix this? Regards, Gerry From aaronh at garden.org Mon May 5 19:27:01 2008 From: aaronh at garden.org (Aaron S. Hawley) Date: Mon, 05 May 2008 15:27:01 -0400 Subject: Bodhi documentation for new packages Message-ID: <481F5F85.7080203@garden.org> [Please, Cc me replies, thanks.] The directions for joining Fedora as a package maintainer[1] are really great. Unfortunately, they trail off at the end when it comes to important tasks of making the package live using the Bodhi system, section "Request updates to released Fedoras for your new package". I ran into this roadblock last month, and it hasn't improved since. As a new maintainer, I know very little about the updates infrastructure of Fedora, which I predict is assumed knowledge about using Bodhi. This is probably unfair to new maintainers. Here's my proposal for what this section should say. It is also what I did, so I'm sure it needs correction, and let me know so I can get my new package (gnue-common) live. Thanks for Fedora, /a -- BEGIN -- The first field asks for the name of the "Package". This will feature a name completion system, but is currently broken. It uses the tag used in Fedora CVS and the Koji build system, e.g. --.fc9. For new packages, choose "enhancement" as the "type" of update. Keep the "Request" as "testing". There are no bugs that are related to any new package, so leave the "Bugs" field blank. For new packages, add a copy of the package's description in the "Notes" section so end users will know what it is.[2] -- END -- 1. 2. Taken from "Bodhi workflow and Q&A", . From kanarip at kanarip.com Mon May 5 19:37:45 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 05 May 2008 21:37:45 +0200 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: References: <1209999548.32107.11.camel@kennedy> Message-ID: <481F6209.2010802@kanarip.com> Jason L Tibbitts III wrote: [...snip...] > them. So autoconf213 is needed for firefox development. That's > certainly a valid reason, and it should be documented somewhere (in > the autoconf213 spec, maybe) so that we won't forget next year when > someone again asks why we still have autoconf213 around. > > Perhaps we can port a few packages over to a recent automake and get > rid of some of the old versions. It certainly wouldn't be a bad > thing. > *cough* HackFest *cough* -Jeroen From notting at redhat.com Mon May 5 19:42:02 2008 From: notting at redhat.com (Bill Nottingham) Date: Mon, 5 May 2008 15:42:02 -0400 Subject: F9 nfs, rpcbind, NetworkManager In-Reply-To: <481F5B00.6030707@verizon.net> References: <481F4BEF.8030004@verizon.net> <481F5041.4050005@verizon.net> <20080505182626.GA14432@nostromo.devel.redhat.com> <481F5B00.6030707@verizon.net> Message-ID: <20080505194202.GA5506@nostromo.devel.redhat.com> Gerry Reno (greno at verizon.net) said: >>> hang. How do I get the network started early enough in the boot with >>> this NetworkManager in the picture? >> >> for service in messagebus haldaemon NetworkManager ; do >> chkconfig $service resetpriorities >> done > > Thanks Bill. I did this and I see that in 2 3 4 5 it goes from K90 network > to S10 network. No, you need to reset the priorities of NetworkManager, et. al., not network. Where is NetworkManager starting? > Somehow the network service and the NetworkManager service get in conflict. > How to fix this? That depends on your configuration. What do your /etc/sysconfig/network-scripts/ifcfg-eth* files look like? Bill From davej at redhat.com Mon May 5 19:47:24 2008 From: davej at redhat.com (Dave Jones) Date: Mon, 5 May 2008 15:47:24 -0400 Subject: Kerneloops? In-Reply-To: <2a28d2ab0805051201r61008ebcrff6f07ec4aeff05d@mail.gmail.com> References: <2a28d2ab0805051137v3ce04bb9y54bce09b06b427f6@mail.gmail.com> <481F5740.5070104@redhat.com> <2a28d2ab0805051201r61008ebcrff6f07ec4aeff05d@mail.gmail.com> Message-ID: <20080505194724.GA6018@redhat.com> On Mon, May 05, 2008 at 02:01:22PM -0500, Dr. Diesel wrote: > On Mon, May 5, 2008 at 1:51 PM, Eric Sandeen wrote: > > Dr. Diesel wrote: > > > Had a Kerneloops message pop up today, said something about a critical > > > error, didn't bother to tell me what the error was! > > > > > > Where is this stored, doesn't seem to be in the normal log locations? > > > > kerneloops sends oopses to kerneloops.org, if you let it (did it ask?) > > > > I've never actually seen the kerneloops-applet in action, dunno what it > > says or looks like... if it's not helpful or confusing I suppose that > > should be fixed. :) > > > > It should also be in the "normal" places, /var/log/messages or at least > > the console. > > > > -Eric > > Guess I thought there would have been a /var/log/kerneloops or something! > > Kerneloops --help and man kerneloops don't exist! > > Nothing kerneloops specific in /var/log/messages Tons of GDM debug though... grep for kernel: in there, and you should turn up something. > I let it submit to Kerneloops.org, GUI looked nice good to know we at least look good when we fail :) Dave -- http://www.codemonkey.org.uk From greno at verizon.net Mon May 5 19:57:54 2008 From: greno at verizon.net (Gerry Reno) Date: Mon, 05 May 2008 15:57:54 -0400 Subject: F9 nfs, rpcbind, NetworkManager In-Reply-To: <20080505194202.GA5506@nostromo.devel.redhat.com> References: <481F4BEF.8030004@verizon.net> <481F5041.4050005@verizon.net> <20080505182626.GA14432@nostromo.devel.redhat.com> <481F5B00.6030707@verizon.net> <20080505194202.GA5506@nostromo.devel.redhat.com> Message-ID: <481F66C2.90508@verizon.net> Bill Nottingham wrote: > Gerry Reno (greno at verizon.net) said: > >>>> hang. How do I get the network started early enough in the boot with >>>> this NetworkManager in the picture? >>>> >>> for service in messagebus haldaemon NetworkManager ; do >>> chkconfig $service resetpriorities >>> done >>> >> Thanks Bill. I did this and I see that in 2 3 4 5 it goes from K90 network >> to S10 network. >> > > No, you need to reset the priorities of NetworkManager, et. al., not network. > Where is NetworkManager starting? > > >> Somehow the network service and the NetworkManager service get in conflict. >> How to fix this? >> > > That depends on your configuration. What do your > /etc/sysconfig/network-scripts/ifcfg-eth* files look like? > > Bill > > The whole /etc/sysconfig/network-scripts/ directory looks like this: ifcfg-eth0 ifdown-ippp ifdown-ppp ifup ifup-ipsec ifup-plusb ifup-sl network-functions ifcfg-lo ifdown-ipsec ifdown-routes ifup-aliases ifup-ipv6 ifup-post ifup-tunnel network-functions-ipv6 ifdown ifdown-ipv6 ifdown-sit ifup-bnep ifup-ipx ifup-ppp ifup-wireless ifdown-bnep ifdown-isdn ifdown-sl ifup-eth ifup-isdn ifup-routes init.ipv6-global ifdown-eth ifdown-post ifdown-tunnel ifup-ippp ifup-plip ifup-sit net.hotplug Here is my ifcfg-eth0: # Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller DEVICE=eth0 BOOTPROTO=none BROADCAST=192.168.1.255 HWADDR=00:1a:4d:5e:f6:36 IPADDR=192.168.1.15 IPV6INIT=yes IPV6_AUTOCONF=yes NETMASK=255.255.255.0 NETWORK=192.168.1.0 ONBOOT=yes GATEWAY=192.168.1.1 TYPE=Ethernet as a side-note: I don't know why this NetworkManager keeps setting BOOTPROTO=none, I keep resetting it to BOOTPROTO=static but the NetworkManager always overwrites this. Right now NetworkManager is set at S99 in 2 3 4 5. In it's file it has: # chkconfig - 27 73 And how do I undo the messagebus haldaemon NetworkManager resetpriorities thing if that isn't what's needed? Regards, Gerry From notting at redhat.com Mon May 5 20:01:29 2008 From: notting at redhat.com (Bill Nottingham) Date: Mon, 5 May 2008 16:01:29 -0400 Subject: F9 nfs, rpcbind, NetworkManager In-Reply-To: <481F66C2.90508@verizon.net> References: <481F4BEF.8030004@verizon.net> <481F5041.4050005@verizon.net> <20080505182626.GA14432@nostromo.devel.redhat.com> <481F5B00.6030707@verizon.net> <20080505194202.GA5506@nostromo.devel.redhat.com> <481F66C2.90508@verizon.net> Message-ID: <20080505200129.GC5506@nostromo.devel.redhat.com> Gerry Reno (greno at verizon.net) said: > Right now NetworkManager is set at S99 in 2 3 4 5. In it's file it has: # > chkconfig - 27 73 > > > And how do I undo the messagebus haldaemon NetworkManager resetpriorities > thing if that isn't what's needed? Well, it apparently didn't take. I'm assuming haldaemon is starting at 98? Bill From greno at verizon.net Mon May 5 20:04:43 2008 From: greno at verizon.net (Gerry Reno) Date: Mon, 05 May 2008 16:04:43 -0400 Subject: F9 nfs, rpcbind, NetworkManager In-Reply-To: <20080505200129.GC5506@nostromo.devel.redhat.com> References: <481F4BEF.8030004@verizon.net> <481F5041.4050005@verizon.net> <20080505182626.GA14432@nostromo.devel.redhat.com> <481F5B00.6030707@verizon.net> <20080505194202.GA5506@nostromo.devel.redhat.com> <481F66C2.90508@verizon.net> <20080505200129.GC5506@nostromo.devel.redhat.com> Message-ID: <481F685B.9010207@verizon.net> Bill Nottingham wrote: > Gerry Reno (greno at verizon.net) said: > >> Right now NetworkManager is set at S99 in 2 3 4 5. In it's file it has: # >> chkconfig - 27 73 >> >> >> And how do I undo the messagebus haldaemon NetworkManager resetpriorities >> thing if that isn't what's needed? >> > > Well, it apparently didn't take. I'm assuming haldaemon is starting at 98? > > Bill > > Yes, haldaemon is at 98. Regards, Gerry From notting at redhat.com Mon May 5 20:09:32 2008 From: notting at redhat.com (Bill Nottingham) Date: Mon, 5 May 2008 16:09:32 -0400 Subject: F9 nfs, rpcbind, NetworkManager In-Reply-To: <481F685B.9010207@verizon.net> References: <481F4BEF.8030004@verizon.net> <481F5041.4050005@verizon.net> <20080505182626.GA14432@nostromo.devel.redhat.com> <481F5B00.6030707@verizon.net> <20080505194202.GA5506@nostromo.devel.redhat.com> <481F66C2.90508@verizon.net> <20080505200129.GC5506@nostromo.devel.redhat.com> <481F685B.9010207@verizon.net> Message-ID: <20080505200932.GD5506@nostromo.devel.redhat.com> Gerry Reno (greno at verizon.net) said: >> Well, it apparently didn't take. I'm assuming haldaemon is starting at 98? > > Yes, haldaemon is at 98. What version of hal and NetworkManager do you have? Bill From greno at verizon.net Mon May 5 20:09:17 2008 From: greno at verizon.net (Gerry Reno) Date: Mon, 05 May 2008 16:09:17 -0400 Subject: F9 nfs, rpcbind, NetworkManager In-Reply-To: <481F685B.9010207@verizon.net> References: <481F4BEF.8030004@verizon.net> <481F5041.4050005@verizon.net> <20080505182626.GA14432@nostromo.devel.redhat.com> <481F5B00.6030707@verizon.net> <20080505194202.GA5506@nostromo.devel.redhat.com> <481F66C2.90508@verizon.net> <20080505200129.GC5506@nostromo.devel.redhat.com> <481F685B.9010207@verizon.net> Message-ID: <481F696D.3000600@verizon.net> Gerry Reno wrote: > Bill Nottingham wrote: >> Gerry Reno (greno at verizon.net) said: >>> Right now NetworkManager is set at S99 in 2 3 4 5. In it's file it >>> has: # chkconfig - 27 73 >>> >>> >>> And how do I undo the messagebus haldaemon NetworkManager >>> resetpriorities thing if that isn't what's needed? >> >> Well, it apparently didn't take. I'm assuming haldaemon is starting >> at 98? >> >> Bill >> > Yes, haldaemon is at 98. > > Regards, > Gerry > rpcbind is starting at S13 so NetworkManager would need to start ahead of this. Regards, Gerry From greno at verizon.net Mon May 5 20:13:47 2008 From: greno at verizon.net (Gerry Reno) Date: Mon, 05 May 2008 16:13:47 -0400 Subject: F9 nfs, rpcbind, NetworkManager In-Reply-To: <20080505200932.GD5506@nostromo.devel.redhat.com> References: <481F4BEF.8030004@verizon.net> <481F5041.4050005@verizon.net> <20080505182626.GA14432@nostromo.devel.redhat.com> <481F5B00.6030707@verizon.net> <20080505194202.GA5506@nostromo.devel.redhat.com> <481F66C2.90508@verizon.net> <20080505200129.GC5506@nostromo.devel.redhat.com> <481F685B.9010207@verizon.net> <20080505200932.GD5506@nostromo.devel.redhat.com> Message-ID: <481F6A7B.2070203@verizon.net> Bill Nottingham wrote: > Gerry Reno (greno at verizon.net) said: > >>> Well, it apparently didn't take. I'm assuming haldaemon is starting at 98? >>> >> Yes, haldaemon is at 98. >> > > What version of hal and NetworkManager do you have? > > Bill > > ]# yum list hal NetworkManager Loaded plugins: fastestmirror, refresh-packagekit Loading mirror speeds from cached hostfile * rawhide: mirror.hiwaay.net rawhide | 2.4 kB 00:00 Installed Packages NetworkManager.i386 1:0.7.0-0.9.2.svn3566. installed hal.i386 0.5.11-0.5.rc2.fc9 installed Available Packages NetworkManager.i386 1:0.7.0-0.9.3.svn3623. rawhide hal.i386 0.5.11-0.7.rc2.fc9 rawhide [root at grp-01-10-01 network-scripts]# Also, NetworkManager keeps erasing /etc/resolv.conf. I go into Network and define all the DNS. I check /etc/resolv.conf to make sure it gets there. And then some time later when I'm doing some network operation DNS fails and I look and /etc/resolv.conf is empty except for the line that says generated by NetworkManager. Regards, Gerry -------------- next part -------------- An HTML attachment was scrubbed... URL: From notting at redhat.com Mon May 5 20:16:57 2008 From: notting at redhat.com (Bill Nottingham) Date: Mon, 5 May 2008 16:16:57 -0400 Subject: F9 nfs, rpcbind, NetworkManager In-Reply-To: <481F6A7B.2070203@verizon.net> References: <481F4BEF.8030004@verizon.net> <481F5041.4050005@verizon.net> <20080505182626.GA14432@nostromo.devel.redhat.com> <481F5B00.6030707@verizon.net> <20080505194202.GA5506@nostromo.devel.redhat.com> <481F66C2.90508@verizon.net> <20080505200129.GC5506@nostromo.devel.redhat.com> <481F685B.9010207@verizon.net> <20080505200932.GD5506@nostromo.devel.redhat.com> <481F6A7B.2070203@verizon.net> Message-ID: <20080505201657.GA10128@nostromo.devel.redhat.com> Gerry Reno (greno at verizon.net) said: > rawhide | 2.4 kB 00:00 > Installed Packages > NetworkManager.i386 1:0.7.0-0.9.2.svn3566. installed > hal.i386 0.5.11-0.5.rc2.fc9 > installed You need to upgrade. Bill From mike at miketc.com Mon May 5 20:27:12 2008 From: mike at miketc.com (Mike Chambers) Date: Mon, 05 May 2008 15:27:12 -0500 Subject: F9 nfs, rpcbind, NetworkManager In-Reply-To: <481F6A7B.2070203@verizon.net> References: <481F4BEF.8030004@verizon.net> <481F5041.4050005@verizon.net> <20080505182626.GA14432@nostromo.devel.redhat.com> <481F5B00.6030707@verizon.net> <20080505194202.GA5506@nostromo.devel.redhat.com> <481F66C2.90508@verizon.net> <20080505200129.GC5506@nostromo.devel.redhat.com> <481F685B.9010207@verizon.net> <20080505200932.GD5506@nostromo.devel.redhat.com> <481F6A7B.2070203@verizon.net> Message-ID: <1210019232.2554.1.camel@scrappy.miketc.com> On Mon, 2008-05-05 at 16:13 -0400, Gerry Reno wrote: > Also, NetworkManager keeps erasing /etc/resolv.conf. I go into > Network and define all the DNS. I check /etc/resolv.conf to make sure > it gets there. And then some time later when I'm doing some network > operation DNS fails and I look and /etc/resolv.conf is empty except > for the line that says generated by NetworkManager. Edit your /etc/sysconfig/network-scripts/ifcfg-eth0 (or wlan0 or whatever your using) and put in your DNS1= (DNS2, DNS3, etc) and search= info and that should help fix it unless your using dhcp. -- Mike Chambers Fedora Project - Ambassador, Bug Zapper, Tester, User, etc.. mikec302 at fedoraproject.org From tcallawa at redhat.com Mon May 5 20:40:30 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 05 May 2008 16:40:30 -0400 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <39478.75.164.221.130.1210011247.squirrel@clueserver.org> References: <1209999548.32107.11.camel@kennedy> <1210002510.26792.62.camel@beck.corsepiu.local> <481F306A.90600@redhat.com> <1210004495.26792.82.camel@beck.corsepiu.local> <20080505162919.GB7317@nostromo.devel.redhat.com> <20080505163225.GC5881@redhat.com> <1210006172.23255.25.camel@localhost.localdomain> <53913.75.164.221.130.1210006921.squirrel@clueserver.org> <20080505171715.GE5881@redhat.com> <1210008691.12808.229.camel@localhost.localdomain> <39478.75.164.221.130.1210011247.squirrel@clueserver.org> Message-ID: <1210020031.8872.47.camel@localhost.localdomain> On Mon, 2008-05-05 at 11:14 -0700, Alan wrote: > I have yet to get X to come back after suspend on an x86_64 system. > (Both > laptops have problems with this. Not certain if it just an HP problem > or > what.) FWIW, my Lenovo T60 (x86_64) comes back after suspend in X, and has for six suspend/resumes in a row, running F-9. ~spot From ssorce at redhat.com Mon May 5 20:43:39 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 05 May 2008 16:43:39 -0400 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <1210020031.8872.47.camel@localhost.localdomain> References: <1209999548.32107.11.camel@kennedy> <1210002510.26792.62.camel@beck.corsepiu.local> <481F306A.90600@redhat.com> <1210004495.26792.82.camel@beck.corsepiu.local> <20080505162919.GB7317@nostromo.devel.redhat.com> <20080505163225.GC5881@redhat.com> <1210006172.23255.25.camel@localhost.localdomain> <53913.75.164.221.130.1210006921.squirrel@clueserver.org> <20080505171715.GE5881@redhat.com> <1210008691.12808.229.camel@localhost.localdomain> <39478.75.164.221.130.1210011247.squirrel@clueserver.org> <1210020031.8872.47.camel@localhost.localdomain> Message-ID: <1210020219.12808.254.camel@localhost.localdomain> On Mon, 2008-05-05 at 16:40 -0400, Tom "spot" Callaway wrote: > On Mon, 2008-05-05 at 11:14 -0700, Alan wrote: > > I have yet to get X to come back after suspend on an x86_64 system. > > (Both > > laptops have problems with this. Not certain if it just an HP problem > > or > > what.) > > FWIW, my Lenovo T60 (x86_64) comes back after suspend in X, and has for > six suspend/resumes in a row, running F-9. My T60 works perfectly in F8 wrt suspend (Intel graphics) (Although as the keyboard is an external USB one, the WAKE button does not work, I have to press the power button :-) Simo. -- Simo Sorce * Red Hat, Inc * New York From dr.diesel at gmail.com Mon May 5 20:47:00 2008 From: dr.diesel at gmail.com (Dr. Diesel) Date: Mon, 5 May 2008 16:47:00 -0400 Subject: Kerneloops? In-Reply-To: <20080505194724.GA6018@redhat.com> References: <2a28d2ab0805051137v3ce04bb9y54bce09b06b427f6@mail.gmail.com> <481F5740.5070104@redhat.com> <2a28d2ab0805051201r61008ebcrff6f07ec4aeff05d@mail.gmail.com> <20080505194724.GA6018@redhat.com> Message-ID: <2a28d2ab0805051347u479822a2r66a8c4766004786@mail.gmail.com> On Mon, May 5, 2008 at 3:47 PM, Dave Jones wrote: > On Mon, May 05, 2008 at 02:01:22PM -0500, Dr. Diesel wrote: > > On Mon, May 5, 2008 at 1:51 PM, Eric Sandeen wrote: > > > Dr. Diesel wrote: > > > > Had a Kerneloops message pop up today, said something about a critical > > > > error, didn't bother to tell me what the error was! > > > > > > > > Where is this stored, doesn't seem to be in the normal log locations? > > > > > > kerneloops sends oopses to kerneloops.org, if you let it (did it ask?) > > > > > > I've never actually seen the kerneloops-applet in action, dunno what it > > > says or looks like... if it's not helpful or confusing I suppose that > > > should be fixed. :) > > > > > > It should also be in the "normal" places, /var/log/messages or at least > > > the console. > > > > > > -Eric > > > > Guess I thought there would have been a /var/log/kerneloops or something! > > > > Kerneloops --help and man kerneloops don't exist! > > > > Nothing kerneloops specific in /var/log/messages Tons of GDM debug though... > > grep for kernel: in there, and you should turn up something. > > > > I let it submit to Kerneloops.org, GUI looked nice > > good to know we at least look good when we fail :) > > Dave > [root at localhost ~]# grep -i "kernel" /var/log/messages May 4 04:10:31 localhost kernel: imklog 3.14.1, log source = /proc/kmsg started. May 4 04:10:31 localhost kernel: Inspecting /boot/System.map-2.6.25-14.fc9.x86_64 May 4 04:10:31 localhost kernel: Loaded 28121 symbols from /boot/System.map-2.6.25-14.fc9.x86_64. May 4 04:10:31 localhost kernel: Symbols match kernel version 2.6.25. May 4 04:10:31 localhost kernel: No module symbols loaded - kernel modules not enabled. May 5 12:44:56 localhost kerneloops: Submitted 2 kernel oopses to www.kerneloops.org The only kernel module I have is VirtualBox. Andy -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org From greno at verizon.net Mon May 5 20:52:23 2008 From: greno at verizon.net (Gerry Reno) Date: Mon, 05 May 2008 16:52:23 -0400 Subject: F9 nfs, rpcbind, NetworkManager In-Reply-To: <20080505201657.GA10128@nostromo.devel.redhat.com> References: <481F4BEF.8030004@verizon.net> <481F5041.4050005@verizon.net> <20080505182626.GA14432@nostromo.devel.redhat.com> <481F5B00.6030707@verizon.net> <20080505194202.GA5506@nostromo.devel.redhat.com> <481F66C2.90508@verizon.net> <20080505200129.GC5506@nostromo.devel.redhat.com> <481F685B.9010207@verizon.net> <20080505200932.GD5506@nostromo.devel.redhat.com> <481F6A7B.2070203@verizon.net> <20080505201657.GA10128@nostromo.devel.redhat.com> Message-ID: <481F7387.4050104@verizon.net> Bill Nottingham wrote: > Gerry Reno (greno at verizon.net) said: > >> rawhide | 2.4 kB 00:00 >> Installed Packages >> NetworkManager.i386 1:0.7.0-0.9.2.svn3566. installed >> hal.i386 0.5.11-0.5.rc2.fc9 >> installed >> > > You need to upgrade. > > Bill > > Ok, I did a 'yum upgrade' but that broke LVM. Now the boot gets to Starting Logical Volume Management, it says VG0 active, VG1 active and then it goes and tries to do a filesystem check on VG2 but it never activated VG2! So I get dropped to a repair filesystem prompt. Aaarghhhh. Regards, Gerry -------------- next part -------------- An HTML attachment was scrubbed... URL: From loganjerry at gmail.com Mon May 5 20:52:32 2008 From: loganjerry at gmail.com (Jerry James) Date: Mon, 5 May 2008 14:52:32 -0600 Subject: MultilibTricks Message-ID: <870180fe0805051352v886f900p5712981d974c7721@mail.gmail.com> I tried to use the approach outlined here: http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks to make a package containing both some binaries and a library. The binaries are linked against the library. The library provides functionality used by other open source projects. However, as the reviewer pointed out, the -libs subpackage described on that page conflicts with the Packaging Guidelines. In particular, all subpackages are supposed to Require the main package, but that gets turned into all packages, including the main package, Require the -libs subpackage. I thought about this approach. foo: main package, contains the .so.* files foo-devel: contains the .h and .so files foo-bin: contains the binaries The only downside I can see to that approach is that some people might be confused when they install just foo and don't get the binaries. How have others addressed this issue? Also, shoud I read anything into the age of that packaging draft? Thanks, -- Jerry James http://loganjerry.googlepages.com/ From j.w.r.degoede at hhs.nl Mon May 5 20:59:12 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 05 May 2008 22:59:12 +0200 Subject: MultilibTricks In-Reply-To: <870180fe0805051352v886f900p5712981d974c7721@mail.gmail.com> References: <870180fe0805051352v886f900p5712981d974c7721@mail.gmail.com> Message-ID: <481F7520.3020808@hhs.nl> Jerry James wrote: > I tried to use the approach outlined here: > > http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks > > to make a package containing both some binaries and a library. The > binaries are linked against the library. The library provides > functionality used by other open source projects. However, as the > reviewer pointed out, the -libs subpackage described on that page > conflicts with the Packaging Guidelines. In particular, all > subpackages are supposed to Require the main package AFAIk that is not what the guidelines say, and if they do say that then they should be fixed, a foo-libs package does not need to Require the main package, and I'm sure I can come up with more examples where a sub package does not need to require the main package. , but that gets > turned into all packages, including the main package, Require the > -libs subpackage. I thought about this approach. > > foo: main package, contains the .so.* files > foo-devel: contains the .h and .so files > foo-bin: contains the binaries > > The only downside I can see to that approach is that some people might > be confused when they install just foo and don't get the binaries. > How have others addressed this issue? Also, shoud I read anything > into the age of that packaging draft? Thanks, Just use the -libs approach and don't make -libs Require the main package, there is no need for it to require the main package. Regards, Hans From greno at verizon.net Mon May 5 21:09:34 2008 From: greno at verizon.net (Gerry Reno) Date: Mon, 05 May 2008 17:09:34 -0400 Subject: F9 nfs, rpcbind, NetworkManager In-Reply-To: <481F7387.4050104@verizon.net> References: <481F4BEF.8030004@verizon.net> <481F5041.4050005@verizon.net> <20080505182626.GA14432@nostromo.devel.redhat.com> <481F5B00.6030707@verizon.net> <20080505194202.GA5506@nostromo.devel.redhat.com> <481F66C2.90508@verizon.net> <20080505200129.GC5506@nostromo.devel.redhat.com> <481F685B.9010207@verizon.net> <20080505200932.GD5506@nostromo.devel.redhat.com> <481F6A7B.2070203@verizon.net> <20080505201657.GA10128@nostromo.devel.redhat.com> <481F7387.4050104@verizon.net> Message-ID: <481F778E.4040209@verizon.net> Gerry Reno wrote: > Bill Nottingham wrote: >> Gerry Reno (greno at verizon.net) said: >> >>> rawhide | 2.4 kB 00:00 >>> Installed Packages >>> NetworkManager.i386 1:0.7.0-0.9.2.svn3566. installed >>> hal.i386 0.5.11-0.5.rc2.fc9 >>> installed >>> >> >> You need to upgrade. >> >> Bill >> >> > Ok, I did a 'yum upgrade' but that broke LVM. Now the boot gets to > Starting Logical Volume Management, it says VG0 active, VG1 active and > then it goes and tries to do a filesystem check on VG2 but it never > activated VG2! So I get dropped to a repair filesystem prompt. > Aaarghhhh. > > Regards, > Gerry > I checked under /dev and there are only two VolGroups listed: VolGroup00 and VolGroup01 Regards, Gerry From jspaleta at gmail.com Mon May 5 21:11:11 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 5 May 2008 13:11:11 -0800 Subject: MultilibTricks In-Reply-To: <481F7520.3020808@hhs.nl> References: <870180fe0805051352v886f900p5712981d974c7721@mail.gmail.com> <481F7520.3020808@hhs.nl> Message-ID: <604aa7910805051411t10a66753m1c5e2276fa4797d0@mail.gmail.com> On Mon, May 5, 2008 at 12:59 PM, Hans de Goede wrote: > Just use the -libs approach and don't make -libs Require the main package, > there is no need for it to require the main package. Active repository example: xmms xmms package requires xmms-libs package xmms-libs package does not require xmms package both are packaged as part of the xmms srpm. even better several other components require xmms-libs which dont require xmms. -jef From greno at verizon.net Mon May 5 21:16:04 2008 From: greno at verizon.net (Gerry Reno) Date: Mon, 05 May 2008 17:16:04 -0400 Subject: F9 nfs, rpcbind, NetworkManager In-Reply-To: <481F778E.4040209@verizon.net> References: <481F4BEF.8030004@verizon.net> <481F5041.4050005@verizon.net> <20080505182626.GA14432@nostromo.devel.redhat.com> <481F5B00.6030707@verizon.net> <20080505194202.GA5506@nostromo.devel.redhat.com> <481F66C2.90508@verizon.net> <20080505200129.GC5506@nostromo.devel.redhat.com> <481F685B.9010207@verizon.net> <20080505200932.GD5506@nostromo.devel.redhat.com> <481F6A7B.2070203@verizon.net> <20080505201657.GA10128@nostromo.devel.redhat.com> <481F7387.4050104@verizon.net> <481F778E.4040209@verizon.net> Message-ID: <481F7914.1040000@verizon.net> Gerry Reno wrote: > Gerry Reno wrote: >> Bill Nottingham wrote: >>> Gerry Reno (greno at verizon.net) said: >>>> rawhide | 2.4 >>>> kB 00:00 Installed Packages >>>> NetworkManager.i386 1:0.7.0-0.9.2.svn3566. >>>> installed hal.i386 >>>> 0.5.11-0.5.rc2.fc9 installed >>> >>> You need to upgrade. >>> >>> Bill >>> >>> >> Ok, I did a 'yum upgrade' but that broke LVM. Now the boot gets to >> Starting Logical Volume Management, it says VG0 active, VG1 active >> and then it goes and tries to do a filesystem check on VG2 but it >> never activated VG2! So I get dropped to a repair filesystem >> prompt. Aaarghhhh. >> >> Regards, >> Gerry >> > I checked under /dev and there are only two VolGroups listed: > VolGroup00 and VolGroup01 > > Regards, > Gerry > It will not let me issue any lvm commands at the repair filesystem prompt. It always says "Locking type 1 initialisation failed." So how are you supposed to do a vgchange -ay and get all you VG's activated when you cannot even issue an LVM command? Regards, Gerry From a.badger at gmail.com Mon May 5 21:18:33 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 05 May 2008 14:18:33 -0700 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: References: <1209999548.32107.11.camel@kennedy> Message-ID: <481F79A9.9000206@gmail.com> Jason L Tibbitts III wrote: > I'm not sure I can go along with this. I'm sure we'd all agree that > there's no point in carrying old versions of various pieces of > software for no reason, but we shouldn't drop them all just because > they're not current. Instead we should (periodically) evaluate why we > have those in the distro and decide if we want to continue to have > them. So autoconf213 is needed for firefox development. That's > certainly a valid reason, and it should be documented somewhere (in > the autoconf213 spec, maybe) so that we won't forget next year when > someone again asks why we still have autoconf213 around. > > Perhaps we can port a few packages over to a recent automake and get > rid of some of the old versions. It certainly wouldn't be a bad > thing. > +1 OTOH, if Karsten doesn't want to maintain all of the compat auto* packages anymore he should certainly feel free to orphan them and let people who need them take them over. -Toshio From greno at verizon.net Mon May 5 21:28:05 2008 From: greno at verizon.net (Gerry Reno) Date: Mon, 05 May 2008 17:28:05 -0400 Subject: F9 nfs, rpcbind, NetworkManager In-Reply-To: <481F7914.1040000@verizon.net> References: <481F4BEF.8030004@verizon.net> <481F5041.4050005@verizon.net> <20080505182626.GA14432@nostromo.devel.redhat.com> <481F5B00.6030707@verizon.net> <20080505194202.GA5506@nostromo.devel.redhat.com> <481F66C2.90508@verizon.net> <20080505200129.GC5506@nostromo.devel.redhat.com> <481F685B.9010207@verizon.net> <20080505200932.GD5506@nostromo.devel.redhat.com> <481F6A7B.2070203@verizon.net> <20080505201657.GA10128@nostromo.devel.redhat.com> <481F7387.4050104@verizon.net> <481F778E.4040209@verizon.net> <481F7914.1040000@verizon.net> Message-ID: <481F7BE5.8080502@verizon.net> Gerry Reno wrote: > It will not let me issue any lvm commands at the repair filesystem > prompt. It always says "Locking type 1 initialisation failed." So > how are you supposed to do a vgchange -ay and get all you VG's > activated when you cannot even issue an LVM command? > > Regards, > Gerry > Ok, I rebooted the system again and this time LVM started all the VG's. Whew!! So back to the original problem: After upgrading, now network is not running during boot. NetworkManager starts *after* rc.local now. So of course no nfs mounts. Where from here? Regards, Gerry From a.badger at gmail.com Mon May 5 21:54:06 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 05 May 2008 14:54:06 -0700 Subject: python packaging - icons/desktop files and /usr/bin accessibility In-Reply-To: References: <481EFE72.1030105@iinet.net.au> Message-ID: <481F81FE.5020500@gmail.com> Mary Ellen Foster wrote: > Note that if you want the libraries to be available to Python, as far > as I understand it, the standard way to do this is to a "*.pth" file > and put it into site-packages. For example, for my package (which puts > files into an "Ice" subdirectory), I created a file called ice.pth > containing only the following: > Ice > For yours, you probably want to create "myapp.pth" containing the line > "myapp" and install that into site-packages. > > This doesn't answer the question of how to run the programs, though, of course. > I took a closer look at Ice and I think there's a few things that should change. 1) AFAICS there's no reason for the python bindings to be part of the Ice package. It comes in a separate tarball and appears to build on its own. I can't find a mention of this in the review so I don't know if there's something special about it that I'm missing. [1]_ 2) The .pth file looks like it's being used to compensate for bad imports and upstream packaging. * There should be an __init__.py file in %{_libdir}/pythonX.Y/site-packages/Ice * The following files have imports that need to be changed: IceBox/__init__.py Glacier2/__init__.py IceGrid/__init__.py IceStorm/__init__.py IcePatch2/__init__.py change imports like:: import IceBox_IceBox_ice to this:: from Ice import IceBox_IceBox_ice 3) Additionally, on x86_64, the python module is spread over two directories: /usr/lib64/python2.5/site-packages/Ice and /usr/lib/python2.5/site-packages/Ice. Python doesn't handle that very well. All the files of a module should be in a single directory. Since this module builds an ELF shared object (IcePy.so/IcePy.so.3.2.1) all files should be installed into %{python_sitearch}/ (This is what lead to BZ #392751). With fixes in #2 and #3 I think the .pth file becomes unnecessary. .. _[1]: I can do the review for python-Ice if you'd like. Just add me to the CC list once you have it broken out into its own package. -Toshio From lmacken at redhat.com Mon May 5 21:55:02 2008 From: lmacken at redhat.com (Luke Macken) Date: Mon, 5 May 2008 17:55:02 -0400 Subject: bodhi questions In-Reply-To: <20080505163914.GB3718@x300.redhat.com> References: <20080503105227.e21d411b.mschwendt@gmail.com> <20080505163914.GB3718@x300.redhat.com> Message-ID: <20080505215502.GF3718@x300.redhat.com> On Mon, May 05, 2008 at 12:39:14PM -0400, Luke Macken wrote: > On Sat, May 03, 2008 at 10:52:27AM +0200, Michael Schwendt wrote: > > 1) Does the nvr input box work for anyone? It used to work long ago, but > > here no longer finds any builds. I had to cut'n'paste a build tag into it. > > Yep, known issue[0]. We hit a regression with the AutoCompleteField > widget with TurboGears-1.0.4.4, which has since been fixed upstream. I fixed the package auto-completion widget, and pushed the fix to production. Let me know if you have any problems with it! Cheers, luke From rjones at redhat.com Mon May 5 22:21:32 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 5 May 2008 23:21:32 +0100 Subject: augeas - reading/modifying/writing system configuration files In-Reply-To: References: <481F0265.3040609@iinet.net.au> Message-ID: <20080505222132.GA12512@amd.home.annexia.org> On Mon, May 05, 2008 at 09:25:24AM -0400, Neal Becker wrote: > Nice, but I think it would be nicer to implement this directly in python > (ducks...) So we can get all the advantages of consuming huge amounts of memory, being really slow, and not responding to the ^C key? Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From rjones at redhat.com Mon May 5 22:34:22 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 5 May 2008 23:34:22 +0100 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <1210003850.26792.73.camel@beck.corsepiu.local> References: <1209999548.32107.11.camel@kennedy> <1210002510.26792.62.camel@beck.corsepiu.local> <1210003068.5320.10.camel@localhost.localdomain> <1210003850.26792.73.camel@beck.corsepiu.local> Message-ID: <20080505223422.GB12512@amd.home.annexia.org> On Mon, May 05, 2008 at 06:10:50PM +0200, Ralf Corsepius wrote: > How do you call projects who stick with antiquated tools and ignore many > years of development? I call them poorly maintained. 'Mature'? Actually while I personally tend to use whatever version of autoconf is installed for my own stuff, I have found a couple of upstream projects that use autoconf 2.13 and are opposed to upgrading, so that is going to be a problem. Unfortunately I can't find the packages in question at the moment, but I'll try to dig them up tomorrow when I'm reunited with my laptop. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From rjones at redhat.com Mon May 5 22:47:13 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 5 May 2008 23:47:13 +0100 Subject: MultilibTricks In-Reply-To: <870180fe0805051352v886f900p5712981d974c7721@mail.gmail.com> References: <870180fe0805051352v886f900p5712981d974c7721@mail.gmail.com> Message-ID: <20080505224713.GC12512@amd.home.annexia.org> On Mon, May 05, 2008 at 02:52:32PM -0600, Jerry James wrote: > I tried to use the approach outlined here: > > http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks [...] > foo: main package, contains the .so.* files > foo-devel: contains the .h and .so files > foo-bin: contains the binaries This is the review in question (which I did): https://bugzilla.redhat.com/show_bug.cgi?id=436033 I was largely unaware of the 'MultilibTricks' page when I did the review, so I was going on what was in the main guidelines. Anyhow if anyone has specific comments, please add them to this BZ. I was going to approve the package right away, but instead I'm going to take a good look at the link above tomorrow morning ... Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From jspaleta at gmail.com Mon May 5 23:02:38 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 5 May 2008 15:02:38 -0800 Subject: MultilibTricks In-Reply-To: <481F7520.3020808@hhs.nl> References: <870180fe0805051352v886f900p5712981d974c7721@mail.gmail.com> <481F7520.3020808@hhs.nl> Message-ID: <604aa7910805051602t5bcb6e3fi15390a7ead0292a6@mail.gmail.com> On Mon, May 5, 2008 at 12:59 PM, Hans de Goede wrote: > AFAIk that is not what the guidelines say, and if they do say that then > they should be fixed, a foo-libs package does not need to Require the main > package, I found where the confusion is http://fedoraproject.org/wiki/Packaging/ReviewGuidelines: SHOULD: Usually, subpackages other than devel should require the base package using a fully versioned dependency. Note its a should and not a must. I think a -libs subpackage is a clear counter example that doesn't fall in the 'usual' wording. I would daresay that usually, -libs subpackages don;t require the base package. Do we really need that SHOULD? Or do we need to expand on it a little? -jef From che666 at gmail.com Mon May 5 23:05:37 2008 From: che666 at gmail.com (Rudolf Kastl) Date: Tue, 6 May 2008 01:05:37 +0200 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <1209999548.32107.11.camel@kennedy> References: <1209999548.32107.11.camel@kennedy> Message-ID: 2008/5/5 Brian Pepple : > I received the following proposal from Karsten Hopp, which he would like > FESCo to make a decision on during this week's meeting (2008-05-08). > I'm forwarding it to the list, so that people can weigh-in on it. > > --- > > ?We are currently shipping an insane number of compatibility autofoo > packages which haven't seen any upstream maintenance for many years: > > autoconf213-2.13-18.fc8.noarch.rpm (9 years) > automake14-1.4p6-15.fc7.noarch.rpm (6 years) > automake15-1.5-23.noarch.rpm (7 years) > automake16-1.6.3-14.noarch.rpm (6 years) > automake17-1.7.9-11.noarch.rpm (4 1/2 years) > > PROPOSAL: I'd like to keep just the following packages and would like to > have release engineering to block the older packages from Rawhide: > autoconf-2.61-10.fc9.noarch.rpm > automake-1.10.1-2.noarch.rpm > > This is the complete list of rawhide packages requiring those ancient > autofoo packages, it is rather short and it should be doable to convert > those packages to current autofoo: > > automake14 ax25-apps-0.0.6-2.fc9.src.rpm > automake14 gdk-pixbuf-0.22.0-36.fc9.src.rpm > automake14 glib-1.2.10-29.fc9.src.rpm > automake14 gtk+-1.2.10-61.fc9.src.rpm > automake14 sgml-common-0.6.3-23.fc9.src.rpm > automake14 WindowMaker-0.92.0-17.fc9.src.rpm > > automake15 nss_db-2.2-40.fc9.src.rpm > > automake16 kyum-0.7.5-11.fc9.src.rpm > automake16 qalculate-kde-0.9.6-5.fc9.src.rpm > automake16 sinjdoc-0.5-6.fc9.src.rpm > > automake17 cegui-0.5.0b-7.fc9.src.rpm > automake17 ekg2-0.1.1-4.fc9.src.rpm > automake17 gtk2-2.12.9-5.fc9.src.rpm > automake17 nautilus-open-terminal-0.9-2.fc9.src.rpm > > autoconf213 esc-1.0.1-9.fc9.src.rpm > autoconf213 glib-1.2.10-29.fc9.src.rpm > autoconf213 gtk+-1.2.10-61.fc9.src.rpm > autoconf213 pam_smb-1.1.7-8.2.2.src.rpm > autoconf213 xdvik-22.84.13-17.fc9.src.rpm > > Maintainers are encouraged to switch to more recent releases of the > autoconf tools and/or work with upstream to get this done. They also > should make sure if it is really necessary to run p.e. automake at all > during the build process. > > Later, > /B > -- > Brian Pepple > > http://fedoraproject.org/wiki/BrianPepple > gpg --keyserver pgp.mit.edu --recv-keys 810CC15E > BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > It would really be nice to encourage people to fix the cruft. backwards compat packages (workarounds) usually just slow down the process of getting that fixed properly. sure one can question the priority of that change but i am also the opinion that it would be something that could be cleaned up in a single iteration. just my opinion, Rudolf Kastl From greno at verizon.net Mon May 5 23:16:07 2008 From: greno at verizon.net (Gerry Reno) Date: Mon, 05 May 2008 19:16:07 -0400 Subject: F9 nfs, rpcbind, NetworkManager In-Reply-To: <481F7BE5.8080502@verizon.net> References: <481F4BEF.8030004@verizon.net> <481F5041.4050005@verizon.net> <20080505182626.GA14432@nostromo.devel.redhat.com> <481F5B00.6030707@verizon.net> <20080505194202.GA5506@nostromo.devel.redhat.com> <481F66C2.90508@verizon.net> <20080505200129.GC5506@nostromo.devel.redhat.com> <481F685B.9010207@verizon.net> <20080505200932.GD5506@nostromo.devel.redhat.com> <481F6A7B.2070203@verizon.net> <20080505201657.GA10128@nostromo.devel.redhat.com> <481F7387.4050104@verizon.net> <481F778E.4040209@verizon.net> <481F7914.1040000@verizon.net> <481F7BE5.8080502@verizon.net> Message-ID: <481F9537.5000607@verizon.net> I finally got the priorities on NetworkManager to reset to 27 73. So I reboot and I finally have nfs mounts and network at login. But now the shutdown hangs. It throws you out to the black 'login:' prompt screen and then it hangs there forever. I pressed Ctrl-Alt-Del and it says it killed init and then I see it send all process TERM and KILL and then a little further it gets to 'Turning off quotas' and hangs again. So I wait a while and hit Ctrl-Alt-Del again and it just goes through the same cycle of killing init, sending TERM and KILL, then turning off the quotas and gets hung again. So need to push the power button at this point. Regards, Gerry From wjhns174 at hardakers.net Tue May 6 00:17:41 2008 From: wjhns174 at hardakers.net (Wes Hardaker) Date: Mon, 05 May 2008 17:17:41 -0700 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <1209999548.32107.11.camel@kennedy> (Brian Pepple's message of "Mon, 05 May 2008 10:59:08 -0400") References: <1209999548.32107.11.camel@kennedy> Message-ID: >>>>> On Mon, 05 May 2008 10:59:08 -0400, Brian Pepple said: BP> PROPOSAL: I'd like to keep just the following packages and would like to BP> have release engineering to block the older packages from Rawhide: BP> autoconf-2.61-10.fc9.noarch.rpm BP> automake-1.10.1-2.noarch.rpm I don't think this is helpful to developers. Those packages aren't just used by Fedora packaging developers. They're used by anyone anywhere who needs to maintain a build system. Different software components require older versions of autoconf to successfully work on. Sad, but very true. I have multiple installations of autoconf in place and I use them all. Not because I want to, but because the base package I'm working on doesn't work with newer versions (this is particularly true from autoconf < 2.5 to anything > 2.5 and also true for 2.58 > 2.59 or beyond). Fixing a configure.in file to make it portable is often a ton of work for a big package. If it wasn't, XEmacs would have updated it's configure.in file from 2.13 to something more recent a long long time ago ;-) -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett From rc040203 at freenet.de Mon May 5 16:22:57 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 05 May 2008 18:22:57 +0200 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <481F3294.9010304@fedoraproject.org> References: <1209999548.32107.11.camel@kennedy> <1210002510.26792.62.camel@beck.corsepiu.local> <1210003068.5320.10.camel@localhost.localdomain> <1210003850.26792.73.camel@beck.corsepiu.local> <481F3294.9010304@fedoraproject.org> Message-ID: <1210004577.26792.84.camel@beck.corsepiu.local> On Mon, 2008-05-05 at 21:45 +0530, Rahul Sundaram wrote: > Ralf Corsepius wrote: > > On Mon, 2008-05-05 at 11:57 -0400, Matthias Clasen wrote: > >> On Mon, 2008-05-05 at 17:48 +0200, Ralf Corsepius wrote: > >> > >>> This step is way over due. It also will teach maintainers not run the > >>> autotools while building. > >> Thats your personal preference. > > > > Your liberty to think this. > > Otherwise, it would be useful to have packaging guidelines officially on > to the recommended method to deal with this. The key to avoid autotool compatibility issues is simple: Do not generate autotool generated files while building. Generate them off-line. Ralf From mclasen at redhat.com Tue May 6 00:36:04 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 05 May 2008 20:36:04 -0400 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <1210004577.26792.84.camel@beck.corsepiu.local> References: <1209999548.32107.11.camel@kennedy> <1210002510.26792.62.camel@beck.corsepiu.local> <1210003068.5320.10.camel@localhost.localdomain> <1210003850.26792.73.camel@beck.corsepiu.local> <481F3294.9010304@fedoraproject.org> <1210004577.26792.84.camel@beck.corsepiu.local> Message-ID: <1210034164.4658.2.camel@localhost.localdomain> On Mon, 2008-05-05 at 18:22 +0200, Ralf Corsepius wrote: > On Mon, 2008-05-05 at 21:45 +0530, Rahul Sundaram wrote: > > Ralf Corsepius wrote: > > > On Mon, 2008-05-05 at 11:57 -0400, Matthias Clasen wrote: > > >> On Mon, 2008-05-05 at 17:48 +0200, Ralf Corsepius wrote: > > >> > > >>> This step is way over due. It also will teach maintainers not run the > > >>> autotools while building. > > >> Thats your personal preference. > > > > > > Your liberty to think this. > > > > Otherwise, it would be useful to have packaging guidelines officially on > > to the recommended method to deal with this. > The key to avoid autotool compatibility issues is simple: Do not > generate autotool generated files while building. > Generate them off-line. ...which won't be easy if the autotool versions you need to generate them are kicked out. From jwboyer at gmail.com Tue May 6 00:52:12 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Mon, 5 May 2008 19:52:12 -0500 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <1210020219.12808.254.camel@localhost.localdomain> References: <1209999548.32107.11.camel@kennedy> <1210002510.26792.62.camel@beck.corsepiu.local> <481F306A.90600@redhat.com> <1210004495.26792.82.camel@beck.corsepiu.local> <20080505162919.GB7317@nostromo.devel.redhat.com> <20080505163225.GC5881@redhat.com> <1210006172.23255.25.camel@localhost.localdomain> <53913.75.164.221.130.1210006921.squirrel@clueserver.org> <20080505171715.GE5881@redhat.com> <1210008691.12808.229.camel@localhost.localdomain> <39478.75.164.221.130.1210011247.squirrel@clueserver.org> <1210020031.8872.47.camel@localhost.localdomain> <1210020219.12808.254.camel@localhost.localdomain> Message-ID: <20080505195212.530512b3@vader.jdub.homelinux.org> On Mon, 05 May 2008 16:43:39 -0400 Simo Sorce wrote: > > On Mon, 2008-05-05 at 16:40 -0400, Tom "spot" Callaway wrote: > > On Mon, 2008-05-05 at 11:14 -0700, Alan wrote: > > > I have yet to get X to come back after suspend on an x86_64 system. > > > (Both > > > laptops have problems with this. Not certain if it just an HP problem > > > or > > > what.) > > > > FWIW, my Lenovo T60 (x86_64) comes back after suspend in X, and has for > > six suspend/resumes in a row, running F-9. > > My T60 works perfectly in F8 wrt suspend (Intel graphics) > > (Although as the keyboard is an external USB one, the WAKE button does > not work, I have to press the power button :-) None of this has anything to do with the thread. Please just report bugs instead. josh From bpepple at fedoraproject.org Tue May 6 01:01:35 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 05 May 2008 21:01:35 -0400 Subject: Maintainer Responsibility Policy Message-ID: <1210035695.6297.25.camel@kennedy> Hi all, I'm looking for some feedback on what I've got so far for the Maintainer Responsibility Policy. http://fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy -- == Maintainer Responsibility Policy == === How long to maintain? === 13 months from initial release. === Belong to the appropriate low-traffic mailing list === * Package maintainers will receive important announcements through the moderated fedora-devel-announce ?mailing list. Maintainers will be automatically subscribed to this list. Everyone that is a primary maintainer of a package in Fedora is also strongly encouraged to subscribe to the fedora-devel list, though this is not mandatory. * http://www.redhat.com/mailman/listinfo/fedora-devel-announce * http://www.redhat.com/mailman/listinfo/fedora-devel-list === Manage security issues === * Package maintainer should handle security issues quickly, and if they need help they should contact the Security Response Team. * http://fedoraproject.org/wiki/Security/ResponseTeam === Deal with reported bugs in a timely manner ==== * 'Nuff said. === Maintain stability for users === * Package maintainers should limit updates within a single Fedora release to those which do not require special user action. Many users update automatically, and if their applications stop working from no action of their own then they will be upset. This goes doubly for services which may break overnight. === Track dependency issues in a timely manner === * In the development tree, and to a small degree in the release trees as well, updates to packages may cause other packages to have broken dependencies. Maintainers will be alerted when this happens, and should work to rebuild their packages with all due haste. Broken dependencies may leave end user systems in a state where no updates will be applied. In order to keep the distribution in a reasonable state, someone will step in and rebuild packages that have had dependency issues for some time, but package maintainers should not rely on these rebuilds. === Notify others of changes that may affect their packages === * Some packages are depended upon by others; in this case, changes to one package may cause issues for others. Maintainers should be aware of the effects that changes to their packages may have, and should alert to the fedora-devel-announce mailing list of updates which contain ABI or API changes which may cause dependency problems for other packages. The announcement should occur a week before the packages update, so all maintainers affected are notified. The announcement should include the following information: * Nature of the change. * Branches (devel, F9, etc.) which will be affected by the change. * Expected date of the change. * List of packages which are affected by the change. Generally, this is merely the list of packages which depend directly on the package which is being updated, and can be found with "repoquery --whatrequires package" where "package" is the package being updated. * If your package upgrade breaks other packages in Rawhide, you should try to help fix the packages affected. For example, when Python-2.5 was integrated into Rawhide, Jeremy Katz at least fixed the important packages and queued a rebuild for all the other packages affected. === Miscellaneous Items === * Maintainers need to maintain an upgrade path for their packages. * F(current-1) -> F(current) -> Rawhide * Packages should be pushed to the Rawhide branch first. If it builds and works fine for a few days, then it can be pushed to F(current). If there is a good reason to push it to F(current-1), it should be done after a few days of being in F(current). --- Thanks, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Tue May 6 01:25:11 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 05 May 2008 21:25:11 -0400 Subject: Maintainer Responsibility Policy In-Reply-To: <1210035695.6297.25.camel@kennedy> References: <1210035695.6297.25.camel@kennedy> Message-ID: <1210037111.29415.119.camel@localhost.localdomain> On Mon, 2008-05-05 at 21:01 -0400, Brian Pepple wrote: > == Maintainer Responsibility Policy == > === How long to maintain? === > 13 months from initial release. From initial Fedora release right? If you bring a package in around F10 Beta, you're expected to stick around for 13 months after F10 final goes out. > === Belong to the appropriate low-traffic mailing list === > * Package maintainers will receive important announcements through > the moderated fedora-devel-announce ?mailing list. Maintainers > will be automatically subscribed to this list. Do we have this hooked up now, or is that a future item (the autosubscribing) > Everyone that is > a primary maintainer of a package in Fedora is also strongly > encouraged to subscribe to the fedora-devel list, though this is > not mandatory. > * http://www.redhat.com/mailman/listinfo/fedora-devel-announce > * http://www.redhat.com/mailman/listinfo/fedora-devel-list > > === Manage security issues === > * Package maintainer should handle security issues quickly, and if > they need help they should contact the Security Response Team. > * http://fedoraproject.org/wiki/Security/ResponseTeam > > === Deal with reported bugs in a timely manner ==== > * 'Nuff said. I would note here that putting a comment in the bug letting folks know when you're going to be too busy to look at the bug immediately would help. > === Maintain stability for users === > * Package maintainers should limit updates within a single Fedora > release to those which do not require special user action. Many > users update automatically, and if their applications stop > working from no action of their own then they will be upset. > This goes doubly for services which may break overnight. > > === Track dependency issues in a timely manner === > * In the development tree, and to a small degree in the release > trees as well, updates to packages may cause other packages to > have broken dependencies. Maintainers will be alerted when this > happens, and should work to rebuild their packages with all due > haste. Broken dependencies may leave end user systems in a state > where no updates will be applied. In order to keep the > distribution in a reasonable state, someone will step in and > rebuild packages that have had dependency issues for some time, > but package maintainers should not rely on these rebuilds. > > === Notify others of changes that may affect their packages === > * Some packages are depended upon by others; in this case, changes > to one package may cause issues for others. Maintainers should > be aware of the effects that changes to their packages may have, > and should alert to the fedora-devel-announce mailing list of > updates which contain ABI or API changes which may cause > dependency problems for other packages. The announcement should > occur a week before the packages update, so all maintainers > affected are notified. The announcement should include the > following information: > * Nature of the change. > * Branches (devel, F9, etc.) which will be affected by the > change. > * Expected date of the change. > * List of packages which are affected by the change. > Generally, this is merely the list of packages which > depend directly on the package which is being updated, > and can be found with "repoquery --whatrequires package" > where "package" is the package being updated. Shouldn't there be an --all there, as well as looking at what packages BuildRequire yours? > * If your package upgrade breaks other packages in Rawhide, you > should try to help fix the packages affected. For example, when > Python-2.5 was integrated into Rawhide, Jeremy Katz at least > fixed the important packages and queued a rebuild for all the > other packages affected. > > === Miscellaneous Items === > * Maintainers need to maintain an upgrade path for their > packages. > * F(current-1) -> F(current) -> Rawhide > * Packages should be pushed to the Rawhide branch first. If it > builds and works fine for a few days, then it can be pushed to > F(current). If there is a good reason to push it to > F(current-1), it should be done after a few days of being in > F(current). -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From bpepple at fedoraproject.org Tue May 6 01:40:42 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 05 May 2008 21:40:42 -0400 Subject: Maintainer Responsibility Policy In-Reply-To: <1210037111.29415.119.camel@localhost.localdomain> References: <1210035695.6297.25.camel@kennedy> <1210037111.29415.119.camel@localhost.localdomain> Message-ID: <1210038042.14143.3.camel@kennedy> On Mon, 2008-05-05 at 21:25 -0400, Jesse Keating wrote: > On Mon, 2008-05-05 at 21:01 -0400, Brian Pepple wrote: > > == Maintainer Responsibility Policy == > > === How long to maintain? === > > 13 months from initial release. > > From initial Fedora release right? If you bring a package in around F10 > Beta, you're expected to stick around for 13 months after F10 final goes > out. Correct. I'll clarify that. > > > === Belong to the appropriate low-traffic mailing list === > > * Package maintainers will receive important announcements through > > the moderated fedora-devel-announce ?mailing list. Maintainers > > will be automatically subscribed to this list. > > Do we have this hooked up now, or is that a future item (the > autosubscribing) I thought that was already hooked up, but I could be mistaken on that point. Is anyone aware of the status of this? > > > > === Deal with reported bugs in a timely manner ==== > > * 'Nuff said. > > I would note here that putting a comment in the bug letting folks know > when you're going to be too busy to look at the bug immediately would > help. Agreed. I'll add it. > > === Notify others of changes that may affect their packages === > > * Some packages are depended upon by others; in this case, changes > > to one package may cause issues for others. Maintainers should > > be aware of the effects that changes to their packages may have, > > and should alert to the fedora-devel-announce mailing list of > > updates which contain ABI or API changes which may cause > > dependency problems for other packages. The announcement should > > occur a week before the packages update, so all maintainers > > affected are notified. The announcement should include the > > following information: > > * Nature of the change. > > * Branches (devel, F9, etc.) which will be affected by the > > change. > > * Expected date of the change. > > * List of packages which are affected by the change. > > Generally, this is merely the list of packages which > > depend directly on the package which is being updated, > > and can be found with "repoquery --whatrequires package" > > where "package" is the package being updated. > > Shouldn't there be an --all there, as well as looking at what packages > BuildRequire yours? Yeah, I think your right. Thanks for the feedback, Jesse. Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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: 197 bytes Desc: This is a digitally signed message part URL: From kevin at scrye.com Tue May 6 02:10:36 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Mon, 5 May 2008 20:10:36 -0600 Subject: Maintainer Responsibility Policy In-Reply-To: <1210035695.6297.25.camel@kennedy> References: <1210035695.6297.25.camel@kennedy> Message-ID: <20080505201036.64d44d6c@ohm.scrye.com> On Mon, 05 May 2008 21:01:35 -0400 bpepple at fedoraproject.org (Brian Pepple) wrote: > Hi all, > > I'm looking for some feedback on what I've got so far for the > Maintainer Responsibility Policy. > > http://fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy > > -- > > == Maintainer Responsibility Policy == > === How long to maintain? === > 13 months from initial release. > > === Belong to the appropriate low-traffic mailing list === > * Package maintainers will receive important announcements > through the moderated fedora-devel-announce ?mailing list. Maintainers > will be automatically subscribed to this list. Everyone that > is a primary maintainer of a package in Fedora is also strongly > encouraged to subscribe to the fedora-devel list, though this > is not mandatory. > * > http://www.redhat.com/mailman/listinfo/fedora-devel-announce > * > http://www.redhat.com/mailman/listinfo/fedora-devel-list > === Manage security issues === > * Package maintainer should handle security issues quickly, and > if they need help they should contact the Security Response Team. > * http://fedoraproject.org/wiki/Security/ResponseTeam > > === Deal with reported bugs in a timely manner ==== > * 'Nuff said. I think this needs expanding... I would add: "If you find yourself unable to handle the load of bugs from your package(s), please ask for assistance on the fedora-devel and/or fedora-test lists. Teaching triagers about how to triage your bugs or getting help from other maintainers can not only reduce your load, but improve Fedora. Consider reaching out for some (more) co-maintainers to assist as well". > === Maintain stability for users === > * Package maintainers should limit updates within a single > Fedora release to those which do not require special user action. Many > users update automatically, and if their applications stop > working from no action of their own then they will be upset. > This goes doubly for services which may break overnight. I would add additionally: "Maintainers should not push every single upstream update to all branches. Examine the changes in each upstream release and ask if the update is worth download and update time for many users. For upstreams that update very often with many small updates, consider waiting and updated only when the amount of changes is worth updating. > === Track dependency issues in a timely manner === > * In the development tree, and to a small degree in the release > trees as well, updates to packages may cause other packages to > have broken dependencies. Maintainers will be alerted when > this happens, and should work to rebuild their packages with all due > haste. Broken dependencies may leave end user systems in a > state where no updates will be applied. In order to keep the > distribution in a reasonable state, someone will step in and > rebuild packages that have had dependency issues for some > time, but package maintainers should not rely on these rebuilds. Bodhi should prevent this in released branches now... so might need a bit of re-wording. > === Notify others of changes that may affect their packages === > * Some packages are depended upon by others; in this case, > changes to one package may cause issues for others. Maintainers > should be aware of the effects that changes to their packages may > have, and should alert to the fedora-devel-announce mailing list of > updates which contain ABI or API changes which may cause > dependency problems for other packages. The announcement > should occur a week before the packages update, so all maintainers > affected are notified. The announcement should include the > following information: > * Nature of the change. > * Branches (devel, F9, etc.) which will be affected by > the change. > * Expected date of the change. > * List of packages which are affected by the change. > Generally, this is merely the list of packages which > depend directly on the package which is being updated, > and can be found with "repoquery --whatrequires > package" where "package" is the package being updated. > * If your package upgrade breaks other packages in Rawhide, you > should try to help fix the packages affected. For example, > when Python-2.5 was integrated into Rawhide, Jeremy Katz at least > fixed the important packages and queued a rebuild for all the > other packages affected. Might be worth mentioning the gcc and/or perl updates... where they were done entirely in another tag and fixes were made until the landing of the updates were pretty painless overall. > === Miscellaneous Items === > * Maintainers need to maintain an upgrade path for their > packages. > * F(current-1) -> F(current) -> Rawhide > * Packages should be pushed to the Rawhide branch first. If it > builds and works fine for a few days, then it can be pushed to > F(current). If there is a good reason to push it to > F(current-1), it should be done after a few days of being in > F(current). Looks like a good start... ;) > Thanks, Thanks for looking at this. > /B kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bpepple at fedoraproject.org Tue May 6 02:22:14 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 05 May 2008 22:22:14 -0400 Subject: Maintainer Responsibility Policy In-Reply-To: <20080505201036.64d44d6c@ohm.scrye.com> References: <1210035695.6297.25.camel@kennedy> <20080505201036.64d44d6c@ohm.scrye.com> Message-ID: <1210040534.14415.4.camel@kennedy> On Mon, 2008-05-05 at 20:10 -0600, Kevin Fenzi wrote: > On Mon, 05 May 2008 21:01:35 -0400 > bpepple at fedoraproject.org (Brian Pepple) wrote: > > > > === Deal with reported bugs in a timely manner ==== > > * 'Nuff said. > > "If you find yourself unable to handle the load of bugs from your > package(s), please ask for assistance on the fedora-devel and/or > fedora-test lists. Teaching triagers about how to triage your bugs or > getting help from other maintainers can not only reduce your load, but > improve Fedora. Consider reaching out for some (more) co-maintainers > to assist as well". Added. > > === Maintain stability for users === > > * Package maintainers should limit updates within a single > > Fedora release to those which do not require special user action. Many > > users update automatically, and if their applications stop > > working from no action of their own then they will be upset. > > This goes doubly for services which may break overnight. > > I would add additionally: > > "Maintainers should not push every single upstream update to all > branches. Examine the changes in each upstream release and ask if the > update is worth download and update time for many users. For upstreams > that update very often with many small updates, consider waiting and > updated only when the amount of changes is worth updating. Added. > > === Track dependency issues in a timely manner === > > * In the development tree, and to a small degree in the release > > trees as well, updates to packages may cause other packages to > > have broken dependencies. Maintainers will be alerted when > > this happens, and should work to rebuild their packages with all due > > haste. Broken dependencies may leave end user systems in a > > state where no updates will be applied. In order to keep the > > distribution in a reasonable state, someone will step in and > > rebuild packages that have had dependency issues for some > > time, but package maintainers should not rely on these rebuilds. > > Bodhi should prevent this in released branches now... so might need a > bit of re-wording. Good suggestion. I changed that to refer to Rawhide only, since that should be the only branch affected. Thanks, Kevin! Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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: 197 bytes Desc: This is a digitally signed message part URL: From skvidal at fedoraproject.org Tue May 6 02:25:49 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 05 May 2008 22:25:49 -0400 Subject: augeas - reading/modifying/writing system configuration files In-Reply-To: <20080505222132.GA12512@amd.home.annexia.org> References: <481F0265.3040609@iinet.net.au> <20080505222132.GA12512@amd.home.annexia.org> Message-ID: <1210040749.12284.27.camel@cutter> On Mon, 2008-05-05 at 23:21 +0100, Richard W.M. Jones wrote: > On Mon, May 05, 2008 at 09:25:24AM -0400, Neal Becker wrote: > > Nice, but I think it would be nicer to implement this directly in python > > (ducks...) > > So we can get all the advantages of consuming huge amounts of memory, > being really slow, and not responding to the ^C key? > Wow, You're really talking out of your element. So let's cruise through some of these: 1. consuming huge amounts of memory: the 64bit memory doubling/tripling effect isn't fun. That's true. On 32bit it is just fine, though. 2. I think you'll need to come up with a good example case for 'being really slow'. 3. the ctrl-c problem (I assume you're speaking of yum here) is directly related to rpm, written in C. Not anything to do with python. -sv From cjdahlin at ncsu.edu Tue May 6 03:28:36 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Mon, 05 May 2008 23:28:36 -0400 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: References: <1209999548.32107.11.camel@kennedy> <481F2986.8010509@redhat.com> <1210002669.26792.65.camel@beck.corsepiu.local> Message-ID: <481FD064.6050307@ncsu.edu> Jason L Tibbitts III wrote: >>>>>> "RC" == Ralf Corsepius writes: >>>>>> > > RC> This is a non-issue if upstream uses the autotools properly, > RC> i.e. is shipping pre-generated files and doesn't run them while > RC> building. > > The upstream developers still need to have autoconf213 in order to > actually develop the package, though. Hence they still need to get > that old version of the package from somewhere. I see no reason why > Fedora shouldn't simply provide it for them. > > - J< > > In light of this, I have a proposal: We fix our specs to not use autoconf, and remove the old versions as stated, but we keep them around, perhaps in another branch in CVS or simply removed from the F10 tag. Then we just wait for complaints. If someone comes in and says "I was actively using that" we can just slap it back in. After one release cycle we can flush the rest. --CJD From mclasen at redhat.com Tue May 6 03:38:01 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 05 May 2008 23:38:01 -0400 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <481FD064.6050307@ncsu.edu> References: <1209999548.32107.11.camel@kennedy> <481F2986.8010509@redhat.com> <1210002669.26792.65.camel@beck.corsepiu.local> <481FD064.6050307@ncsu.edu> Message-ID: <1210045081.4658.7.camel@localhost.localdomain> On Mon, 2008-05-05 at 23:28 -0400, Casey Dahlin wrote: > In light of this, I have a proposal: > > We fix our specs to not use autoconf, and remove the old versions as > stated, but we keep them around, perhaps in another branch in CVS or > simply removed from the F10 tag. Then we just wait for complaints. If > someone comes in and says "I was actively using that" we can just slap > it back in. After one release cycle we can flush the rest. > And we do all this work because we have nothing better to do ? Whats the gain, again ? From cjdahlin at ncsu.edu Tue May 6 03:43:17 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Mon, 05 May 2008 23:43:17 -0400 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <1210045081.4658.7.camel@localhost.localdomain> References: <1209999548.32107.11.camel@kennedy> <481F2986.8010509@redhat.com> <1210002669.26792.65.camel@beck.corsepiu.local> <481FD064.6050307@ncsu.edu> <1210045081.4658.7.camel@localhost.localdomain> Message-ID: <481FD3D5.5070206@ncsu.edu> Matthias Clasen wrote: > On Mon, 2008-05-05 at 23:28 -0400, Casey Dahlin wrote: > > >> In light of this, I have a proposal: >> >> We fix our specs to not use autoconf, and remove the old versions as >> stated, but we keep them around, perhaps in another branch in CVS or >> simply removed from the F10 tag. Then we just wait for complaints. If >> someone comes in and says "I was actively using that" we can just slap >> it back in. After one release cycle we can flush the rest. >> >> > > And we do all this work because we have nothing better to do ? > Whats the gain, again ? > > The gain is we decide what to keep and what not to keep based on who actually is willing to fight to keep it around rather than whoever feels like complaining on devel list. Its a corollary to "its easier to apologize than to ask permission," the people who notice the change are a tiny and far more important subset than the people who will complain ahead of time. --CJD From mclasen at redhat.com Tue May 6 03:44:42 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 05 May 2008 23:44:42 -0400 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <481FD3D5.5070206@ncsu.edu> References: <1209999548.32107.11.camel@kennedy> <481F2986.8010509@redhat.com> <1210002669.26792.65.camel@beck.corsepiu.local> <481FD064.6050307@ncsu.edu> <1210045081.4658.7.camel@localhost.localdomain> <481FD3D5.5070206@ncsu.edu> Message-ID: <1210045482.4658.10.camel@localhost.localdomain> On Mon, 2008-05-05 at 23:43 -0400, Casey Dahlin wrote: > > > The gain is we decide what to keep and what not to keep based on who > actually is willing to fight to keep it around rather than whoever feels > like complaining on devel list. Its a corollary to "its easier to > apologize than to ask permission," the people who notice the change are > a tiny and far more important subset than the people who will complain > ahead of time. I don't see any gain here. Just make-work. And I don't see why one should have to fight for keeping necessary build tools around. From loganjerry at gmail.com Tue May 6 03:50:30 2008 From: loganjerry at gmail.com (Jerry James) Date: Mon, 5 May 2008 21:50:30 -0600 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: References: <1209999548.32107.11.camel@kennedy> Message-ID: <870180fe0805052050pcac64e2x6377a65a59dce11c@mail.gmail.com> On Mon, May 5, 2008 at 6:17 PM, Wes Hardaker wrote: > beyond). Fixing a configure.in file to make it portable is often a ton > of work for a big package. If it wasn't, XEmacs would have updated it's > configure.in file from 2.13 to something more recent a long long time > ago ;-) Actually, we did update it on the 21.5 (beta) branch quite awhile ago. It's true that the 21.4 (stable) branch has never been updated, though. -- Jerry James, also known as james at xemacs.org http://loganjerry.googlepages.com/ From tgl at redhat.com Tue May 6 03:57:29 2008 From: tgl at redhat.com (Tom Lane) Date: Mon, 05 May 2008 23:57:29 -0400 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <1210034164.4658.2.camel@localhost.localdomain> References: <1209999548.32107.11.camel@kennedy> <1210002510.26792.62.camel@beck.corsepiu.local> <1210003068.5320.10.camel@localhost.localdomain> <1210003850.26792.73.camel@beck.corsepiu.local> <481F3294.9010304@fedoraproject.org> <1210004577.26792.84.camel@beck.corsepiu.local> <1210034164.4658.2.camel@localhost.localdomain> Message-ID: <7652.1210046249@sss.pgh.pa.us> Matthias Clasen writes: > On Mon, 2008-05-05 at 18:22 +0200, Ralf Corsepius wrote: >> The key to avoid autotool compatibility issues is simple: Do not >> generate autotool generated files while building. >> Generate them off-line. > ...which won't be easy if the autotool versions you need to generate > them are kicked out. Yeah. We have a rule against shipping binary blobs. A binary blob can fairly be defined as a derived file that you lack the source to, or lack the tools to get from the source to the derived file. How is it different if we ship an autotools-derived file that the recipient cannot regenerate from source? Smells like a GPL violation to me. regards, tom lane From tgl at redhat.com Tue May 6 04:24:54 2008 From: tgl at redhat.com (Tom Lane) Date: Tue, 06 May 2008 00:24:54 -0400 Subject: MultilibTricks In-Reply-To: <604aa7910805051602t5bcb6e3fi15390a7ead0292a6@mail.gmail.com> References: <870180fe0805051352v886f900p5712981d974c7721@mail.gmail.com> <481F7520.3020808@hhs.nl> <604aa7910805051602t5bcb6e3fi15390a7ead0292a6@mail.gmail.com> Message-ID: <7932.1210047894@sss.pgh.pa.us> "Jeff Spaleta" writes: > I found where the confusion is > http://fedoraproject.org/wiki/Packaging/ReviewGuidelines: > SHOULD: Usually, subpackages other than devel should require the base > package using a fully versioned dependency. > Note its a should and not a must. I think a -libs subpackage is a > clear counter example that doesn't fall in the 'usual' wording. I > would daresay that usually, -libs subpackages don;t require the base > package. > Do we really need that SHOULD? Or do we need to expand on it a little? Indeed, in my experience the entire POINT of a -libs subpackage is that it doesn't pull in the whole base package. If it does, why are you bothering to create a separate libs subpackage? So the review guidelines are indisputably broken here. See also this closely-related thread on fedora-packaging, which I just started today: https://www.redhat.com/archives/fedora-packaging/2008-May/msg00002.html regards, tom lane From arjan at infradead.org Tue May 6 04:30:45 2008 From: arjan at infradead.org (Arjan van de Ven) Date: Mon, 5 May 2008 21:30:45 -0700 Subject: Kerneloops? In-Reply-To: <2a28d2ab0805051137v3ce04bb9y54bce09b06b427f6@mail.gmail.com> References: <2a28d2ab0805051137v3ce04bb9y54bce09b06b427f6@mail.gmail.com> Message-ID: <20080505213045.27ddcf0e@infradead.org> On Mon, 5 May 2008 13:37:42 -0500 "Dr. Diesel" wrote: > Had a Kerneloops message pop up today, said something about a critical > error, didn't bother to tell me what the error was! > > Where is this stored, doesn't seem to be in the normal log locations? > > > the latest version of kerneloops will give you an URL you can visit your crash at after it has been submitted and processed... From shadowjksp at yahoo.se Tue May 6 04:43:45 2008 From: shadowjksp at yahoo.se (Jan Knutar) Date: Tue, 06 May 2008 07:43:45 +0300 Subject: Help a little, make Fedora 10 a lot better References: <1209913267.4312.89.camel@rousalka.okg> Message-ID: <2945f5-ss2.ln1@ludicrous.enivax.net> Nicolas Mailhot wrote: > Over all, we need more fonts so users can customize their desktop to the > point they can't envision using something else than Fedora. I would like Vista-style modal dialog accompanied with warning sounds and grayscaling of the rest of the screen, telling me that "Warning, you just upgraded package X through yum, and X wants to modify your font settings slightly, additionally you're currently running KDE and completing the upgrade of X will launch a gnome application which will launch the gnome settings daemon, which will also slightly change your current font hinting and antialising settings, and possibly also adjust your DPI by one or two units. Are you sure you want to continue?" There's nothing more unsettling than having something about the fonts change slightly, it's the same font but something's not right, but you can't quite tell what it is. It's blurrier/softer than before, or rougher / grottier / blockier than before, the size might be just slightly different too. You enter new data in openoffice calc, and rows mysteriously become one or two pixels higher as you press enter, but yet you're typing with the same font and size that the rest of the cells are, or atleast that's what ooo claims. You're feeling discomfort and perhaps a bit nauseous at first, a sensation somewhat similar to motion-sickness. Application after application succumb, either immediately or the next time you run them. Even konsole and gnome-terminal that usually are so benign and rarely try to stab you in the eyes turn evil! But they're often easier to get back on your side, and if all else fails you've still got xterm, hopefully. For the rest, you spend hours trying one font after another (or in the case of firefox, combinations of 5 fonts) in different sizes, but you just can't make it look the way it looked before... Heck, by now even if you'd stumbled on to the original settings, you've changed so much else that it's still not the same. I wonder if I'm the only one who's wrestled with this :) (And in this typing moment I just managed to get kmail and knode to look like they used to, but then xchat went bad, and I had already made it look like it used to... Or maybe I didn't get it to look like it did, just close enough, and I got used to that close-enough version, and now that it's really back to normal i'm getting discomfort from the slight change again?) Sorry for this long rant :) From james at fedoraproject.com Tue May 6 05:12:47 2008 From: james at fedoraproject.com (James Antill) Date: Tue, 06 May 2008 01:12:47 -0400 Subject: Python eats lots of memory on x86_64 In-Reply-To: <20080505222132.GA12512@amd.home.annexia.org> References: <481F0265.3040609@iinet.net.au> <20080505222132.GA12512@amd.home.annexia.org> Message-ID: <1210050767.17108.45.camel@code.and.org> On Mon, 2008-05-05 at 23:21 +0100, Richard W.M. Jones wrote: > On Mon, May 05, 2008 at 09:25:24AM -0400, Neal Becker wrote: > > Nice, but I think it would be nicer to implement this directly in python > > (ducks...) > > So we can get all the advantages of consuming huge amounts of memory, So I've actually had a look at this, recently, mainly due to yum resource usage on .i386 vs. x86_64 and this troll response to a troll response is a good a place as any to put it, I think. So first I wrote a simplish program which just created new yum.YumBase() objects and appended them to a list (numbers got from parsing /proc/self/status) which gave me: .x86_64 0 peak 219.90MB size 219.90MB rss 13.30MB .x86_64 1 peak 219.90MB size 219.90MB rss 13.33MB .x86_64 90001 peak 610.46MB size 610.46MB rss 403.75MB .i386 0 peak 20.65MB size 20.65MB rss 9.61MB .i386 1 peak 20.65MB size 20.65MB rss 9.63MB .i386 90001 peak 212.77MB size 212.77MB rss 201.82MB ...which is about what we've seen when profiling yum itself, 2x for RSS and much more for VSZ (10x to start with above, which is nice). Then I added a "pmap" call right at the end, the most interesting bit of which shows: 0000000000601000 449696K rw--- [ anon ] [...] 00002aaaaab5a000 76136K r---- /usr/lib/locale/locale-archive [...] 00002aaaafa8d000 20K r-x-- /usr/lib64/python2.5/lib-dynload/stropmodule.so 00002aaaafa92000 2044K ----- /usr/lib64/python2.5/lib-dynload/stropmodule.so 00002aaaafc91000 8K rw--- /usr/lib64/python2.5/lib-dynload/stropmodule.so ...on .x86_64, and taking single shared object as an example vs .i386: 00c58000 16K r-x-- /usr/lib/python2.5/lib-dynload/stropmodule.so 00c5c000 8K rwx-- /usr/lib/python2.5/lib-dynload/stropmodule.so [...] 09290000 222296K rwx-- [ anon ] [...] b7d23000 2048K r---- /usr/lib/locale/locale-archive ...the locale archive x38 resource usage is explained by these lines from glibc/locale/loadarchive.c: /* Map an initial window probably large enough to cover the header and the first locale's data. With a large address space, we can just map the whole file and be sure everything is covered. */ mapsize = (sizeof (void *) > 4 ? archive_stat.st_size : MIN (archive_stat.st_size, ARCHIVE_MAPPING_WINDOW)); result = __mmap64 (NULL, mapsize, PROT_READ, MAP_FILE|MAP_COPY, fd, 0); ...which means any locale using C program gets an extra ~73MB of VSZ at startup on .x86_64. And that any C program gets ~2MB VSZ per. shared object it loads[1]. The next interesting bit is that there are roughly 24 "anon" mappings for .x86_64 and only 20 for .i386, a little investigation shows that glibc is again the reason as the default M_MMAP_THRESHOLD doesn't expand with size_t/time_t/etc. ... and setting MALLOC_MMAP_MAX_=0 produces the same number of anon mappings on x86_64. At which point the numbers then add up as "simple doubling" as you go from 4 byte size_t/time_t/intptr_t/etc. to 8 bytes for the same. HTH. HAND. [1] I assume this dead space is for a reason (alignment?), and isn't wasting any real memory (RSS implies this is true) ... although it is far from obvious what is happening in both cases. -- James Antill -- "Please, no. Let's not pull in a dependency for something as simple as a string library." -- Kristian H?gsberg From rc040203 at freenet.de Tue May 6 05:13:27 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 06 May 2008 07:13:27 +0200 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <20080505223422.GB12512@amd.home.annexia.org> References: <1209999548.32107.11.camel@kennedy> <1210002510.26792.62.camel@beck.corsepiu.local> <1210003068.5320.10.camel@localhost.localdomain> <1210003850.26792.73.camel@beck.corsepiu.local> <20080505223422.GB12512@amd.home.annexia.org> Message-ID: <1210050807.26792.131.camel@beck.corsepiu.local> On Mon, 2008-05-05 at 23:34 +0100, Richard W.M. Jones wrote: > On Mon, May 05, 2008 at 06:10:50PM +0200, Ralf Corsepius wrote: > > How do you call projects who stick with antiquated tools and ignore many > > years of development? I call them poorly maintained. > > 'Mature'? That would be OK, if these packages "just work", i.e. not force users to using their > Actually while I personally tend to use whatever version of > autoconf is installed for my own stuff, Hear, hear! That's the way the autotools are supposed to be used by _developers_. It may surprise some folks, but it really works without major problems when packages are using the autotools properly (1000s of packages are doing so). One occasionally trips a minor issue when one of the autotools is being upgraded, but nothing actually serious. It really is simple as: You once need to take the plunge, then things are really simple. > I have found a couple of > upstream projects that use autoconf 2.13 and are opposed to upgrading, > so that is going to be a problem. Yes, you will always be able to find projects sticking to antiquated tools and refusing to accept that they are doing something stupid. So far, most packages I have come across sticking with autoconf-2.13 are simply relying on exploiting bugs and undocumented features from autoconf-2.13 (In autoconf-terms: bugwise-compatible configure scripts). Several larger packages suffered from such issues, but if maintainers are willing, these issues can be overcome. Even GCC and almost everything in src/ (aka. ueberbaum, binutils, newlib, gdb, gdb etc.) has managed to do so. Another class of issues is people mixing up "minimum required versions" with "version to use". This causes some developers to use autoconf-2.13, even though it would be suitable for autoconf > 2.13 (Popular in Debian). Ralf From nikhil.bbharadwaj at yahoo.com Tue May 6 05:31:12 2008 From: nikhil.bbharadwaj at yahoo.com (nikhil bharadwaj) Date: Mon, 5 May 2008 22:31:12 -0700 (PDT) Subject: Windows Data/Settings migration tool Message-ID: <761766.88344.qm@web38902.mail.mud.yahoo.com> hi, I am looking forward for a feature in F10 which is the "Windows Data Migration Tool". This idea I had already proposed a month earlier but it was through the GSoC program. Due to some reasons, my project wasnt selected. But I felt the urge to release this tool so am proposing the same idea as a feature for F10. Please find the link below and suggest some ideas. http://fedoraproject.org/wiki/Features/WindowsDataMigrationTool http://nikhilbharadwaj.wordpress.com/fedora-project-soc-2008/ Feel free to ideate/suggest/criticise. Regards, Nikhil --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rc040203 at freenet.de Tue May 6 06:03:18 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 06 May 2008 08:03:18 +0200 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <481F3AD6.9030407@redhat.com> References: <1209999548.32107.11.camel@kennedy> <1210002510.26792.62.camel@beck.corsepiu.local> <481F306A.90600@redhat.com> <481F3AD6.9030407@redhat.com> Message-ID: <1210053798.26792.136.camel@beck.corsepiu.local> On Mon, 2008-05-05 at 17:50 +0100, Andrew Haley wrote: > Christopher Aillon wrote: > > On 05/05/2008 11:48 AM, Ralf Corsepius wrote: > >> This step is way over due. It also will teach maintainers not run the > >> autotools while building. > > > > It will also teach maintainers not to use Fedora for doing upstream work. > > I agree. This proposal seems to be all pain for no gain. The fact Fedora ships gcc-4.3.0 is all pain for no gain. Please add versions of gcc of all active GCC-branches, such that people can continue to use f77 and c++'s backward stuff. Also consider adding a version of gcc which ships still supports libg++. Do you sense the insanity? Ralf From mike at miketc.com Tue May 6 06:24:09 2008 From: mike at miketc.com (Mike Chambers) Date: Tue, 06 May 2008 01:24:09 -0500 Subject: F9 nfs, rpcbind, NetworkManager In-Reply-To: <481F9537.5000607@verizon.net> References: <481F4BEF.8030004@verizon.net> <481F5041.4050005@verizon.net> <20080505182626.GA14432@nostromo.devel.redhat.com> <481F5B00.6030707@verizon.net> <20080505194202.GA5506@nostromo.devel.redhat.com> <481F66C2.90508@verizon.net> <20080505200129.GC5506@nostromo.devel.redhat.com> <481F685B.9010207@verizon.net> <20080505200932.GD5506@nostromo.devel.redhat.com> <481F6A7B.2070203@verizon.net> <20080505201657.GA10128@nostromo.devel.redhat.com> <481F7387.4050104@verizon.net> <481F778E.4040209@verizon.net> <481F7914.1040000@verizon.net> <481F7BE5.8080502@verizon.net> <481F9537.5000607@verizon.net> Message-ID: <1210055049.3297.7.camel@scrappy.miketc.com> On Mon, 2008-05-05 at 19:16 -0400, Gerry Reno wrote: > I finally got the priorities on NetworkManager to reset to 27 73. So I > reboot and I finally have nfs mounts and network at login. But now the > shutdown hangs. It throws you out to the black 'login:' prompt screen > and then it hangs there forever. I pressed Ctrl-Alt-Del and it says it > killed init and then I see it send all process TERM and KILL and then a > little further it gets to 'Turning off quotas' and hangs again. So I > wait a while and hit Ctrl-Alt-Del again and it just goes through the > same cycle of killing init, sending TERM and KILL, then turning off the > quotas and gets hung again. So need to push the power button at this point. I run into this turn, and still haven't figured out how to get past that point. NM would start up fine, and even my nfs stuff got mounted (if I remember correctly), but I would hang at the exact point you did. Had to push the power button to get it to proceed any further. -- Mike Chambers Fedora Project - Ambassador, Bug Zapper, Tester, User, etc.. mikec302 at fedoraproject.org From mschwendt at gmail.com Tue May 6 07:43:58 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 6 May 2008 09:43:58 +0200 Subject: MultilibTricks In-Reply-To: <7932.1210047894@sss.pgh.pa.us> References: <870180fe0805051352v886f900p5712981d974c7721@mail.gmail.com> <481F7520.3020808@hhs.nl> <604aa7910805051602t5bcb6e3fi15390a7ead0292a6@mail.gmail.com> <7932.1210047894@sss.pgh.pa.us> Message-ID: <20080506094358.ef8befe3.mschwendt@gmail.com> On Tue, 06 May 2008 00:24:54 -0400, Tom Lane wrote: > > I found where the confusion is > > http://fedoraproject.org/wiki/Packaging/ReviewGuidelines: > > > SHOULD: Usually, subpackages other than devel should require the base > > package using a fully versioned dependency. > > > Note its a should and not a must. I think a -libs subpackage is a > > clear counter example that doesn't fall in the 'usual' wording. I > > would daresay that usually, -libs subpackages don;t require the base > > package. > > > Do we really need that SHOULD? Or do we need to expand on it a little? > > Indeed, in my experience the entire POINT of a -libs subpackage is that > it doesn't pull in the whole base package. If it does, why are you > bothering to create a separate libs subpackage? So the review guidelines > are indisputably broken here. The guidelines say SHOULD, not MUST. And I believe that guideline has its origin in the "explicit %epoch era" and is a bit misleading nowadays. The foo-libs case is special, because it simulates a stand-alone libfoo package, which may be used by other programs/packages. A missing dependency between a sub-package and the main package is one source of packaging mistakes. The sub-package *is* optional, but programs [tools, scripts or other files] from the main package often are needed at run-time. This is something to check carefully. And it applies also to add-on packages created from a separate src.rpm. -- Fedora release 8 (Werewolf) - Linux 2.6.23.15-137.fc8 loadavg: 1.02 1.13 0.73 From petersen at redhat.com Tue May 6 08:31:29 2008 From: petersen at redhat.com (Jens Petersen) Date: Tue, 06 May 2008 18:31:29 +1000 Subject: Localisation needs to be improved In-Reply-To: <481E0FC0.9080909@kanarip.com> References: <1209860284.3433.7.camel@localhost.localdomain> <1209861510.12250.0.camel@localhost.localdomain> <1209862787.12250.4.camel@localhost.localdomain> <481D1CE7.1060807@kanarip.com> <1209870995.12250.16.camel@localhost.localdomain> <1209921645.2942.8.camel@sb-home> <481E0FC0.9080909@kanarip.com> Message-ID: <48201761.9000505@redhat.com> Jeroen van Meeuwen ????????: > Let's make this into a Fedora 10 Proposed Feature: > > - an interface for system administrators to set the default language, > like s-c-language does now, but extend it to tweak `locale`. > > - an interface for users to tweak they're own little private `locale`. Sounds like a good idea, I agree. Jens From petersen at redhat.com Tue May 6 08:31:57 2008 From: petersen at redhat.com (Jens Petersen) Date: Tue, 06 May 2008 18:31:57 +1000 Subject: Localisation needs to be improved In-Reply-To: <1209862787.12250.4.camel@localhost.localdomain> References: <1209860284.3433.7.camel@localhost.localdomain> <1209861510.12250.0.camel@localhost.localdomain> <1209862787.12250.4.camel@localhost.localdomain> Message-ID: <4820177D.3000106@redhat.com> Rodd Clarkson ????????: > > On Sun, 2008-05-04 at 03:48 +0300, Pavel Shevchuk wrote: >> I don't see any Australia-specific options here. You SHOULD NOT get >> australian currency or paper format with such locale. >> >> If i understand you correctly, you should set everything to >> en_AU.UTF-8, then override LC_MESSAGES with en_US.UTF-8. It will set >> paper and currency to Australian, but leave GUI American english Hmm, if I run "LANG=en_AU.UTF-8 gedit" and look at preferences I see "Fonts and Colors" not "Fonts and Colours" (like for en_GB)? > BUT, I the humble end user shouldn't have to know any of this or do > anything to make it so (rather than feed the installer some appropriate > information). Well the timezone approach sounds nice but is probably not practical as others have pointed out. I think a simple solution for now would be to allow choosing "English (country)" as the install language. At least until we work out a better approach in the longer term. I agree it would be nice to be able to configure LC_PAPER system wide or for users. system-config-language would be a natural place to do that currently, but a desktop interface would be good too. Jens From aph at redhat.com Tue May 6 08:54:42 2008 From: aph at redhat.com (Andrew Haley) Date: Tue, 06 May 2008 09:54:42 +0100 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <1210053798.26792.136.camel@beck.corsepiu.local> References: <1209999548.32107.11.camel@kennedy> <1210002510.26792.62.camel@beck.corsepiu.local> <481F306A.90600@redhat.com> <481F3AD6.9030407@redhat.com> <1210053798.26792.136.camel@beck.corsepiu.local> Message-ID: <48201CD2.9000109@redhat.com> Ralf Corsepius wrote: > On Mon, 2008-05-05 at 17:50 +0100, Andrew Haley wrote: >> Christopher Aillon wrote: >>> On 05/05/2008 11:48 AM, Ralf Corsepius wrote: >>>> This step is way over due. It also will teach maintainers not run the >>>> autotools while building. >>> It will also teach maintainers not to use Fedora for doing upstream work. >> I agree. This proposal seems to be all pain for no gain. > The fact Fedora ships gcc-4.3.0 is all pain for no gain. Certainly not! There's been a bunch of useful improvements, as you'll see on the gcc web page. > Please add versions of gcc of all active GCC-branches, such that people > can continue to use f77 and c++'s backward stuff. > > Also consider adding a version of gcc which ships still supports libg++. > > Do you sense the insanity? I don't think this is a relevant comparison. Most importantly, gcc is a large package, so there is a considerable cost to shipping more than one version. As has been pointed out, this FESCo proposal is mere make-work for no purpose. It serves only to distract maintainers from doing something useful. Andrew. From andy at warmcat.com Tue May 6 09:10:51 2008 From: andy at warmcat.com (Andy Green) Date: Tue, 06 May 2008 10:10:51 +0100 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <48201CD2.9000109@redhat.com> References: <1209999548.32107.11.camel@kennedy> <1210002510.26792.62.camel@beck.corsepiu.local> <481F306A.90600@redhat.com> <481F3AD6.9030407@redhat.com> <1210053798.26792.136.camel@beck.corsepiu.local> <48201CD2.9000109@redhat.com> Message-ID: <4820209B.2030704@warmcat.com> Somebody in the thread at some point said: > As has been pointed out, this FESCo proposal is mere make-work for no purpose. > It serves only to distract maintainers from doing something useful. Another way to look at this is the large amount of havoc old auto* dependency causes in the wider world... success with cross compile for example is pretty seriously adversely affected the older the auto* is. I don't know it should particularly be Fedora maintainers' problem, although it likely makes trouble there too, but any effort to encourage the upstreams to work with recent autostuffs is definitely not for "no purpose" in the bigger-than-Fedora sense. -Andy From rc040203 at freenet.de Tue May 6 09:35:47 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 06 May 2008 11:35:47 +0200 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <48201CD2.9000109@redhat.com> References: <1209999548.32107.11.camel@kennedy> <1210002510.26792.62.camel@beck.corsepiu.local> <481F306A.90600@redhat.com> <481F3AD6.9030407@redhat.com> <1210053798.26792.136.camel@beck.corsepiu.local> <48201CD2.9000109@redhat.com> Message-ID: <1210066547.26792.152.camel@beck.corsepiu.local> On Tue, 2008-05-06 at 09:54 +0100, Andrew Haley wrote: > Ralf Corsepius wrote: > > On Mon, 2008-05-05 at 17:50 +0100, Andrew Haley wrote: > >> Christopher Aillon wrote: > >>> On 05/05/2008 11:48 AM, Ralf Corsepius wrote: > >>>> This step is way over due. It also will teach maintainers not run the > >>>> autotools while building. > >>> It will also teach maintainers not to use Fedora for doing upstream work. > >> I agree. This proposal seems to be all pain for no gain. > > The fact Fedora ships gcc-4.3.0 is all pain for no gain. > > Certainly not! There's been a bunch of useful improvements, as you'll see > on the gcc web page. No disagreement, but .. there also are a lot of changes, which require developers to change/update/rework their sources. > > Please add versions of gcc of all active GCC-branches, such that people > > can continue to use f77 and c++'s backward stuff. > > > > Also consider adding a version of gcc which ships still supports libg++. > > > > Do you sense the insanity? > > I don't think this is a relevant comparison. Why? You are using a dead piece of SW called autoconf-2.13, others are using a dead piece of SW called gcc-2.7.2/egcs or libg++ or gcc-3.x.- The only difference is RH playing nice to people using outdated autotools and pushing around people using outdated c/c++ code or features/miss-features from older gcc's. In fact, you are aggressively forcing Fedora based developers to rework their c/c++/fortran-code or to quit using Fedora, but you refuse to fix your autotools-code? Double-standards! > Most importantly, gcc is a large > package, so there is a considerable cost to shipping more than one version. > > As has been pointed out, this FESCo proposal is mere make-work for no purpose. > It serves only to distract maintainers from doing something useful. To the same extend as gcc-4.3.0 does - It might have escaped you, but other distros do have alternative toolchains. Of cause their would be middle-grounds ... but I don't sense any interest on your (@RH) part to develope/find one. Ralf From kanarip at kanarip.com Tue May 6 10:18:37 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 06 May 2008 12:18:37 +0200 Subject: Localisation needs to be improved In-Reply-To: <48201761.9000505@redhat.com> References: <1209860284.3433.7.camel@localhost.localdomain> <1209861510.12250.0.camel@localhost.localdomain> <1209862787.12250.4.camel@localhost.localdomain> <481D1CE7.1060807@kanarip.com> <1209870995.12250.16.camel@localhost.localdomain> <1209921645.2942.8.camel@sb-home> <481E0FC0.9080909@kanarip.com> <48201761.9000505@redhat.com> Message-ID: <4820307D.3070704@kanarip.com> Jens Petersen wrote: > Jeroen van Meeuwen ????????????????????????: >> Let's make this into a Fedora 10 Proposed Feature: >> >> - an interface for system administrators to set the default language, >> like s-c-language does now, but extend it to tweak `locale`. >> >> - an interface for users to tweak they're own little private `locale`. > > Sounds like a good idea, I agree. > *doing* http://fedoraproject.org/wiki/Features/LocalePreferences Enlist and add your comments, ideas, proposals and changes! Kind regards, Jeroen van Meeuwen -kanarip From jkeating at redhat.com Tue May 6 10:57:53 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 06 May 2008 06:57:53 -0400 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <481FD3D5.5070206@ncsu.edu> References: <1209999548.32107.11.camel@kennedy> <481F2986.8010509@redhat.com> <1210002669.26792.65.camel@beck.corsepiu.local> <481FD064.6050307@ncsu.edu> <1210045081.4658.7.camel@localhost.localdomain> <481FD3D5.5070206@ncsu.edu> Message-ID: <1210071473.29415.128.camel@localhost.localdomain> On Mon, 2008-05-05 at 23:43 -0400, Casey Dahlin wrote: > The gain is we decide what to keep and what not to keep based on who > actually is willing to fight to keep it around rather than whoever feels > like complaining on devel list. Its a corollary to "its easier to > apologize than to ask permission," the people who notice the change are > a tiny and far more important subset than the people who will complain > ahead of time. It doesn't account for the developers who will have failures, notice we don't package a version of autoconf anymore and say "Screw that" and move to some other development platform which does support what they need. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kanarip at kanarip.com Tue May 6 11:24:32 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 06 May 2008 13:24:32 +0200 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <1210071473.29415.128.camel@localhost.localdomain> References: <1209999548.32107.11.camel@kennedy> <481F2986.8010509@redhat.com> <1210002669.26792.65.camel@beck.corsepiu.local> <481FD064.6050307@ncsu.edu> <1210045081.4658.7.camel@localhost.localdomain> <481FD3D5.5070206@ncsu.edu> <1210071473.29415.128.camel@localhost.localdomain> Message-ID: <48203FF0.70205@kanarip.com> Jesse Keating wrote: > On Mon, 2008-05-05 at 23:43 -0400, Casey Dahlin wrote: >> The gain is we decide what to keep and what not to keep based on who >> actually is willing to fight to keep it around rather than whoever feels >> like complaining on devel list. Its a corollary to "its easier to >> apologize than to ask permission," the people who notice the change are >> a tiny and far more important subset than the people who will complain >> ahead of time. > > It doesn't account for the developers who will have failures, notice we > don't package a version of autoconf anymore and say "Screw that" and > move to some other development platform which does support what they > need. > > My $.02 worth of thoughts: One could imagine a policy in which new packages using these tools would not be accepted per-se, while the tools would still be available, packaged, for those other packages and developers that need it. Does such, or something similar, make sense? Kind regards, Jeroen van Meeuwen -kanarip From rawhide at fedoraproject.org Tue May 6 11:34:22 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Tue, 6 May 2008 11:34:22 +0000 (UTC) Subject: rawhide report: 20080506 changes Message-ID: <20080506113422.63F63209D01@releng1.fedora.phx.redhat.com> Updated Packages: NetworkManager-openvpn-1:0.7.0-10.svn3632.fc9 --------------------------------------------- * Mon May 05 2008 Dan Williams 1:0.7.0-10.svn3632 - Fix issue with location of the VPN plugin PackageKit-0.1.12-10.20080505.fc9 --------------------------------- * Mon May 05 2008 Richard Hughes - 0.1.12-10.20080505 - Pull in the new snapshot from the stable PACKAGEKIT_0_1_X branch. - Fixes rh#445086, which should be a release blocker IMO. allegro-4.2.2-10.fc9 -------------------- * Mon May 05 2008 Hans de Goede 4.2.2-10 - Look for /etc/timidity.cfg instead of /usr/share/timidity/timidity.cfg, as the latter is no longer available now that Fedora has switched from timidity++-patches to PersonalCopy-Lite-patches glibc-2.8-3 ----------- * Mon May 05 2008 Jakub Jelinek 2.8-3 - don't run telinit u in %post if both /dev/initctl and /sbin/initctl exist (#444978) - workaround GCC ppc64 miscompilation of c{log{,10},acosh,atan}l (#444996) mesa-7.1-0.29.fc9 ----------------- * Mon May 05 2008 Dave Airlie 7.1-0.29 - mesa-7.1-f9-intel-and-radeon-fixes.patch - Update mesa package with cherrypicked fixes from master. - Fixes numerous i965 3D issues - Fixes compiz on rs48x and rs690 radeon chipsets ntfs-3g-2:1.2506-1.fc9 ---------------------- * Mon May 05 2008 Tom "spot" Callaway - 2:1.2506-1 - update to 1.2506 texlive-2007-30.fc9 ------------------- * Mon May 05 2008 Jindrich Novy - 2007-30 - fix SELinux contexts everywhere possible, don't allow restorecon to fail (#444922) - add missing post/postun scriptlets for subpackages * Mon Apr 21 2008 Jindrich Novy - 2007-29 - run restorecon on /var/lib/texmf to avoid access denials if SELinux is in enforcing mode (#443286, #442161) * Tue Mar 18 2008 Jindrich Novy - 2007-28 - xelatex requires xdvipdfmx texlive-texmf-2007-22.fc9 ------------------------- * Mon May 05 2008 Jindrich Novy - 2007-22 - release++ to fix tagging issues * Mon May 05 2008 Jindrich Novy - 2007-21 - fix SELinux contexts everywhere possible, don't allow restorecon to fail (#444922) xorg-x11-drv-i810-2.2.1-24.fc9 ------------------------------ * Tue May 06 2008 Dave Airlie 2.2.1-24 - fix xinf file to include IGD xorg-x11-server-1.4.99.901-28.20080415.fc9 ------------------------------------------ * Mon May 05 2008 Adam Jackson 1.4.99.901-28.20080415 - xserver-1.5.0-compiz-clip-fix.patch: Make compiz stop blinking every so often. (#441219) * Mon May 05 2008 Adam Jackson 1.4.99.901-27.20080415 - xserver-1.5.0-hal-closedown.patch: Fix a crash in the hal code when closing a device. Broken deps for ppc64 ---------------------------------------------------------- livecd-tools-016-1.fc9.ppc64 requires yaboot perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot sectool-gui-0.6.0-1.noarch requires sectool = 0:0.6.0-1 From karsten at redhat.com Tue May 6 11:44:47 2008 From: karsten at redhat.com (Karsten Hopp) Date: Tue, 06 May 2008 13:44:47 +0200 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <48203FF0.70205@kanarip.com> References: <1209999548.32107.11.camel@kennedy> <481F2986.8010509@redhat.com> <1210002669.26792.65.camel@beck.corsepiu.local> <481FD064.6050307@ncsu.edu> <1210045081.4658.7.camel@localhost.localdomain> <481FD3D5.5070206@ncsu.edu> <1210071473.29415.128.camel@localhost.localdomain> <48203FF0.70205@kanarip.com> Message-ID: <482044AF.8040109@redhat.com> Jeroen van Meeuwen wrote: > Jesse Keating wrote: >> On Mon, 2008-05-05 at 23:43 -0400, Casey Dahlin wrote: >>> The gain is we decide what to keep and what not to keep based on who >>> actually is willing to fight to keep it around rather than whoever >>> feels like complaining on devel list. Its a corollary to "its easier >>> to apologize than to ask permission," the people who notice the >>> change are a tiny and far more important subset than the people who >>> will complain ahead of time. >> >> It doesn't account for the developers who will have failures, notice we >> don't package a version of autoconf anymore and say "Screw that" and >> move to some other development platform which does support what they >> need. >> >> > > My $.02 worth of thoughts: > > One could imagine a policy in which new packages using these tools would > not be accepted per-se, while the tools would still be available, > packaged, for those other packages and developers that need it. > > Does such, or something similar, make sense? > Such a policy would be ok with me. The whole intention for this proposal was to disencourage usage of the old tools, not to force maintainers to rewrite their configure scripts immediately or use another distribution. Nonetheless maintainers of forementioned packages should check if it is necessary to run autofoo during the build. Most of the times it isn't and if I remember correctly even I am guilty of doing this due to laziness and/or time constraints. Karsten From redhat at olen.net Tue May 6 12:01:00 2008 From: redhat at olen.net (Ola Thoresen) Date: Tue, 06 May 2008 14:01:00 +0200 Subject: Localisation needs to be improved In-Reply-To: <4820307D.3070704@kanarip.com> References: <1209860284.3433.7.camel@localhost.localdomain> <1209861510.12250.0.camel@localhost.localdomain> <1209862787.12250.4.camel@localhost.localdomain> <481D1CE7.1060807@kanarip.com> <1209870995.12250.16.camel@localhost.localdomain> <1209921645.2942.8.camel@sb-home> <481E0FC0.9080909@kanarip.com> <48201761.9000505@redhat.com> <4820307D.3070704@kanarip.com> Message-ID: <4820487C.70005@olen.net> Jeroen van Meeuwen wrote: > Jens Petersen wrote: >> Jeroen van Meeuwen ????????????????????????: >>> Let's make this into a Fedora 10 Proposed Feature: >>> >>> - an interface for system administrators to set the default language, >>> like s-c-language does now, but extend it to tweak `locale`. >>> >>> - an interface for users to tweak they're own little private `locale`. >> >> Sounds like a good idea, I agree. >> > > *doing* > > http://fedoraproject.org/wiki/Features/LocalePreferences > > Enlist and add your comments, ideas, proposals and changes! I think the main issue is to separate "language" from "locale". I believe this is the main thing for most of us. So if LANG and LC_MESSAGES is set from the language-selection and the rest of LC_* is set from the location/timezone-selection I think we have a reasonable default. This should be a quite simple fix, as both these dialogs are already in firstboot or anaconda. It will at least give me the right clock (24 hour) first day of week (monday) and paper (A4) while still keeping all errors and other messages in english. Then we can think about some way the user can change the values of the specific elements, if someone still wants another currency or paper size than the default for their locale. Rgds. /Ola (T) -- _,--', _._.--._____ .--.--';_'-.', ";_ _.,-' Ola Thoresen .'--'. _.' {`'-;_ .-.>.' '-:_ ) / `' '=. It is easier to fix Unix ) > {_/, /~) than to live with Windows |/ `^ .' From aph at redhat.com Tue May 6 12:12:32 2008 From: aph at redhat.com (Andrew Haley) Date: Tue, 06 May 2008 13:12:32 +0100 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <1210066547.26792.152.camel@beck.corsepiu.local> References: <1209999548.32107.11.camel@kennedy> <1210002510.26792.62.camel@beck.corsepiu.local> <481F306A.90600@redhat.com> <481F3AD6.9030407@redhat.com> <1210053798.26792.136.camel@beck.corsepiu.local> <48201CD2.9000109@redhat.com> <1210066547.26792.152.camel@beck.corsepiu.local> Message-ID: <48204B30.2060801@redhat.com> Ralf Corsepius wrote: > On Tue, 2008-05-06 at 09:54 +0100, Andrew Haley wrote: >> Ralf Corsepius wrote: >>> On Mon, 2008-05-05 at 17:50 +0100, Andrew Haley wrote: >>>> Christopher Aillon wrote: >>>>> On 05/05/2008 11:48 AM, Ralf Corsepius wrote: >>>>>> This step is way over due. It also will teach maintainers not run the >>>>>> autotools while building. >>>>> It will also teach maintainers not to use Fedora for doing upstream work. >>>> I agree. This proposal seems to be all pain for no gain. >>> The fact Fedora ships gcc-4.3.0 is all pain for no gain. >> Certainly not! There's been a bunch of useful improvements, as you'll see >> on the gcc web page. > No disagreement, but .. there also are a lot of changes, which require > developers to change/update/rework their sources. > >>> Please add versions of gcc of all active GCC-branches, such that people >>> can continue to use f77 and c++'s backward stuff. >>> >>> Also consider adding a version of gcc which ships still supports libg++. >>> >>> Do you sense the insanity? >> I don't think this is a relevant comparison. > Why? It's in the following sentence. It really helps to read a message before beginning to reply. > You are using a dead piece of SW called autoconf-2.13, others are > using a dead piece of SW called gcc-2.7.2/egcs or libg++ or gcc-3.x.- > > The only difference is RH playing nice to people using outdated > autotools and pushing around people using outdated c/c++ code or > features/miss-features from older gcc's. > > In fact, you are aggressively forcing Fedora based developers to rework > their c/c++/fortran-code or to quit using Fedora, but you refuse to fix > your autotools-code? Double-standards! Even if all of that were true, it wouldn't change the fact that this proposal is all pain for no gain. >> Most importantly, gcc is a large >> package, so there is a considerable cost to shipping more than one version. Andrew. From rjones at redhat.com Tue May 6 12:21:18 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 6 May 2008 13:21:18 +0100 Subject: augeas - reading/modifying/writing system configuration files In-Reply-To: <1210040749.12284.27.camel@cutter> References: <481F0265.3040609@iinet.net.au> <20080505222132.GA12512@amd.home.annexia.org> <1210040749.12284.27.camel@cutter> Message-ID: <20080506122118.GA21114@amd.home.annexia.org> On Mon, May 05, 2008 at 10:25:49PM -0400, seth vidal wrote: > On Mon, 2008-05-05 at 23:21 +0100, Richard W.M. Jones wrote: > > So we can get all the advantages of consuming huge amounts of memory, > > being really slow, and not responding to the ^C key? > > > > Wow, You're really talking out of your element. So let's cruise through > some of these: > 1. consuming huge amounts of memory: the 64bit memory doubling/tripling > effect isn't fun. That's true. On 32bit it is just fine, though. I'm not talking about some memory doubling effect, I'm talking about a memory multiplication by large integer effect! Take a look at the stats if you don't believe me: http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=python&lang2=python compared to say, C: http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=python&lang2=gcc or if you prefer a language with a similar ease of use, OCaml: http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=python&lang2=ocaml Some of these Python programs are using > 10 x more memory and > 15 x more CPU! > 2. I think you'll need to come up with a good example case for 'being > really slow'. > > 3. the ctrl-c problem (I assume you're speaking of yum here) is > directly related to rpm, written in C. Not anything to do with python. koji watch-task Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From rc040203 at freenet.de Tue May 6 12:24:39 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 06 May 2008 14:24:39 +0200 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: References: <1209999548.32107.11.camel@kennedy> <481F2986.8010509@redhat.com> <1210002669.26792.65.camel@beck.corsepiu.local> Message-ID: <1210076680.26792.169.camel@beck.corsepiu.local> On Mon, 2008-05-05 at 13:56 -0500, Jason L Tibbitts III wrote: > >>>>> "RC" == Ralf Corsepius writes: > > RC> This is a non-issue if upstream uses the autotools properly, > RC> i.e. is shipping pre-generated files and doesn't run them while > RC> building. > > The upstream developers still need to have autoconf213 in order to > actually develop the package, though. Correct - Either they will have to distribute "their autotools themselves" (Which, for example GCC does.) or switch the version of autotools they are using. On a wider scale, as long as vendors ship modified autotools, major projects will have to do so in any case. > Hence they still need to get > that old version of the package from somewhere. I see no reason why > Fedora shouldn't simply provide it for them. cf. above. From an upstream perspective, unless these tools are 100% genuine FSF sources, these tools are useless. Ralf From rdieter at math.unl.edu Tue May 6 12:24:40 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 06 May 2008 07:24:40 -0500 Subject: MultilibTricks References: <870180fe0805051352v886f900p5712981d974c7721@mail.gmail.com> <481F7520.3020808@hhs.nl> <604aa7910805051602t5bcb6e3fi15390a7ead0292a6@mail.gmail.com> <7932.1210047894@sss.pgh.pa.us> Message-ID: Tom Lane wrote: > Indeed, in my experience the entire POINT of a -libs subpackage is that > it doesn't pull in the whole base package. If it does, why are you > bothering to create a separate libs subpackage? So the review guidelines > are indisputably broken here. -libs, even if Require'ing the base pkg, helps multilib-wise. -- Rex From mschwendt at gmail.com Tue May 6 12:46:45 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 6 May 2008 14:46:45 +0200 Subject: MultilibTricks In-Reply-To: References: <870180fe0805051352v886f900p5712981d974c7721@mail.gmail.com> <481F7520.3020808@hhs.nl> <604aa7910805051602t5bcb6e3fi15390a7ead0292a6@mail.gmail.com> <7932.1210047894@sss.pgh.pa.us> Message-ID: <20080506144645.77b84cb7.mschwendt@gmail.com> On Tue, 06 May 2008 07:24:40 -0500, Rex Dieter wrote: > Tom Lane wrote: > > > > Indeed, in my experience the entire POINT of a -libs subpackage is that > > it doesn't pull in the whole base package. If it does, why are you > > bothering to create a separate libs subpackage? So the review guidelines > > are indisputably broken here. > > -libs, even if Require'ing the base pkg, helps multilib-wise. If -libs requires base pkg, there's no need to split the two. And it cannot help multilib-wise, because the -devel => -libs => base pkg chain is still intact. -- Fedora release 8 (Werewolf) - Linux 2.6.23.15-137.fc8 loadavg: 1.09 1.31 1.38 From mschwendt at gmail.com Tue May 6 12:55:23 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 6 May 2008 14:55:23 +0200 Subject: MultilibTricks In-Reply-To: <20080506144645.77b84cb7.mschwendt@gmail.com> References: <870180fe0805051352v886f900p5712981d974c7721@mail.gmail.com> <481F7520.3020808@hhs.nl> <604aa7910805051602t5bcb6e3fi15390a7ead0292a6@mail.gmail.com> <7932.1210047894@sss.pgh.pa.us> <20080506144645.77b84cb7.mschwendt@gmail.com> Message-ID: <20080506145523.df548b07.mschwendt@gmail.com> On Tue, 6 May 2008 14:46:45 +0200, Michael Schwendt wrote: > On Tue, 06 May 2008 07:24:40 -0500, Rex Dieter wrote: > > > Tom Lane wrote: > > > > > > > Indeed, in my experience the entire POINT of a -libs subpackage is that > > > it doesn't pull in the whole base package. If it does, why are you > > > bothering to create a separate libs subpackage? So the review guidelines > > > are indisputably broken here. > > > > -libs, even if Require'ing the base pkg, helps multilib-wise. > > If -libs requires base pkg, there's no need to split the two. > > And it cannot help multilib-wise, because the -devel => -libs => base pkg > chain is still intact. Unless RPM doesn't care about the arch of the base pkg... and takes either one, ... oh well... From hun at n-dimensional.de Tue May 6 13:01:50 2008 From: hun at n-dimensional.de (Hans Ulrich Niedermann) Date: Tue, 06 May 2008 15:01:50 +0200 Subject: Maintainer Responsibility Policy In-Reply-To: <1210035695.6297.25.camel@kennedy> References: <1210035695.6297.25.camel@kennedy> Message-ID: <482056BE.90100@n-dimensional.de> Brian Pepple wrote: > === Deal with reported bugs in a timely manner ==== > * 'Nuff said. "Deal with" meaning what, exactly? When the maintainer has reported the bug to upstream in a timely manner, his job is done and he can patiently wait for years until upstream fixes the bug or not? -- Hans Ulrich Niedermann -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From kanarip at kanarip.com Tue May 6 13:07:48 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 06 May 2008 15:07:48 +0200 Subject: Localisation needs to be improved In-Reply-To: <4820487C.70005@olen.net> References: <1209860284.3433.7.camel@localhost.localdomain> <1209861510.12250.0.camel@localhost.localdomain> <1209862787.12250.4.camel@localhost.localdomain> <481D1CE7.1060807@kanarip.com> <1209870995.12250.16.camel@localhost.localdomain> <1209921645.2942.8.camel@sb-home> <481E0FC0.9080909@kanarip.com> <48201761.9000505@redhat.com> <4820307D.3070704@kanarip.com> <4820487C.70005@olen.net> Message-ID: <48205824.9090901@kanarip.com> Ola Thoresen wrote: > Jeroen van Meeuwen wrote: >> Jens Petersen wrote: >>> Jeroen van Meeuwen ????????????????????????: >>>> Let's make this into a Fedora 10 Proposed Feature: >>>> >>>> - an interface for system administrators to set the default language, >>>> like s-c-language does now, but extend it to tweak `locale`. >>>> >>>> - an interface for users to tweak they're own little private `locale`. >>> Sounds like a good idea, I agree. >>> >> *doing* >> >> http://fedoraproject.org/wiki/Features/LocalePreferences >> >> Enlist and add your comments, ideas, proposals and changes! > > > I think the main issue is to separate "language" from "locale". I > believe this is the main thing for most of us. > So if LANG and LC_MESSAGES is set from the language-selection and the > rest of LC_* is set from the location/timezone-selection I think we have > a reasonable default. > This should be a quite simple fix, as both these dialogs are already in > firstboot or anaconda. > Yes; 1) System (global) defaults 1a) Language selection now implies locale, and maybe it shouldn't 1b) Timezone selection does not impact locale, while maybe it should 2) End-User Preferences == 1) makes for a good use-case to implement anything different from the current situation; whether it goes into anaconda or firstboot or "System > Administration" -I'm sorry I'm a GNOME user, rest assured it should be available to _all_ desktop environments and the console. Setting system locale defaults from the timezone selected in anaconda/firstboot makes perfect sense. I'm thinking this may also imply some sort of 'locale --messages=nl_NL.utf8 --paper=de_DE.utf8' (or something similar) in kickstart. 2) requires something _outside_ anaconda and firstboot, possibly in "System > Preferences" (sorry for that, again). I'll update the wiki feature page to reflect these things, soon. Kind regards, Jeroen van Meeuwen -kanarip From laxathom at fedoraproject.org Tue May 6 13:10:49 2008 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Tue, 6 May 2008 15:10:49 +0200 Subject: Maintainer Responsibility Policy In-Reply-To: <1210035695.6297.25.camel@kennedy> References: <1210035695.6297.25.camel@kennedy> Message-ID: <62bc09df0805060610n742c3bf4j15a751cfcb2c1b8f@mail.gmail.com> 2008/5/6 Brian Pepple : > Hi all, > > I'm looking for some feedback on what I've got so far for the Maintainer > Responsibility Policy. > > > http://fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy > > -- > > == Maintainer Responsibility Policy == > === How long to maintain? === > 13 months from initial release. > > === Belong to the appropriate low-traffic mailing list === > * Package maintainers will receive important announcements through > the moderated fedora-devel-announce ?mailing list. Maintainers > will be automatically subscribed to this list. Everyone that is > a primary maintainer of a package in Fedora is also strongly > encouraged to subscribe to the fedora-devel list, though this is > not mandatory. > * > http://www.redhat.com/mailman/listinfo/fedora-devel-announce > * http://www.redhat.com/mailman/listinfo/fedora-devel-list > > === Manage security issues === > * Package maintainer should handle security issues quickly, and if > they need help they should contact the Security Response Team. > * http://fedoraproject.org/wiki/Security/ResponseTeam > > === Deal with reported bugs in a timely manner ==== > * 'Nuff said. > > === Maintain stability for users === > * Package maintainers should limit updates within a single Fedora > release to those which do not require special user action. Many > users update automatically, and if their applications stop > working from no action of their own then they will be upset. > This goes doubly for services which may break overnight. > > === Track dependency issues in a timely manner === > * In the development tree, and to a small degree in the release > trees as well, updates to packages may cause other packages to > have broken dependencies. Maintainers will be alerted when this > happens, and should work to rebuild their packages with all due > haste. Broken dependencies may leave end user systems in a state > where no updates will be applied. In order to keep the > distribution in a reasonable state, someone will step in and > rebuild packages that have had dependency issues for some time, > but package maintainers should not rely on these rebuilds. > > === Notify others of changes that may affect their packages === > * Some packages are depended upon by others; in this case, changes > to one package may cause issues for others. Maintainers should > be aware of the effects that changes to their packages may have, > and should alert to the fedora-devel-announce mailing list of > updates which contain ABI or API changes which may cause > dependency problems for other packages. The announcement should > occur a week before the packages update, so all maintainers > affected are notified. The announcement should include the > following information: > * Nature of the change. > * Branches (devel, F9, etc.) which will be affected by the > change. > * Expected date of the change. > * List of packages which are affected by the change. > Generally, this is merely the list of packages which > depend directly on the package which is being updated, > and can be found with "repoquery --whatrequires package" > where "package" is the package being updated. > * If your package upgrade breaks other packages in Rawhide, you > should try to help fix the packages affected. For example, when > Python-2.5 was integrated into Rawhide, Jeremy Katz at least > fixed the important packages and queued a rebuild for all the > other packages affected. > > === Miscellaneous Items === > * Maintainers need to maintain an upgrade path for their > packages. > * F(current-1) -> F(current) -> Rawhide > * Packages should be pushed to the Rawhide branch first. If it > builds and works fine for a few days, then it can be pushed to > F(current). If there is a good reason to push it to > F(current-1), it should be done after a few days of being in > F(current). I think you should also mention the act of "pushing to testing" repo for each current fedora release. > --- > > Thanks, > /B > -- > Brian Pepple > > http://fedoraproject.org/wiki/BrianPepple > gpg --keyserver pgp.mit.edu --recv-keys 810CC15E > BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.underwood at gmail.com Tue May 6 13:41:16 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 6 May 2008 14:41:16 +0100 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <481FD064.6050307@ncsu.edu> References: <1209999548.32107.11.camel@kennedy> <481F2986.8010509@redhat.com> <1210002669.26792.65.camel@beck.corsepiu.local> <481FD064.6050307@ncsu.edu> Message-ID: <645d17210805060641p13a04d44s9aaa0a221df5093a@mail.gmail.com> 2008/5/6 Casey Dahlin : > In light of this, I have a proposal: > > We fix our specs to not use autoconf, and remove the old versions as > stated, but we keep them around, perhaps in another branch in CVS or simply > removed from the F10 tag. Then we just wait for complaints. If someone comes > in and says "I was actively using that" we can just slap it back in. After > one release cycle we can flush the rest. *I was actively using that* Building xdvik and also a patched version to add in japanese support, and also to force the build to use system installed libraries rather than to build against locally bundled versions requires some hacking and autoconfery. Yes, I am getting upstream fixing aspects of this, and yes I will look at moving to a later autoconf, but please don't remove the previous versions of autoconf or ban autotools from the spec files. From dcbw at redhat.com Tue May 6 13:38:25 2008 From: dcbw at redhat.com (Dan Williams) Date: Tue, 06 May 2008 09:38:25 -0400 Subject: F9 nfs, rpcbind, NetworkManager In-Reply-To: <481F6A7B.2070203@verizon.net> References: <481F4BEF.8030004@verizon.net> <481F5041.4050005@verizon.net> <20080505182626.GA14432@nostromo.devel.redhat.com> <481F5B00.6030707@verizon.net> <20080505194202.GA5506@nostromo.devel.redhat.com> <481F66C2.90508@verizon.net> <20080505200129.GC5506@nostromo.devel.redhat.com> <481F685B.9010207@verizon.net> <20080505200932.GD5506@nostromo.devel.redhat.com> <481F6A7B.2070203@verizon.net> Message-ID: <1210081105.21415.3.camel@localhost.localdomain> On Mon, 2008-05-05 at 16:13 -0400, Gerry Reno wrote: > Bill Nottingham wrote: > > Gerry Reno (greno at verizon.net) said: > > > > > > Well, it apparently didn't take. I'm assuming haldaemon is starting at 98? > > > > > > > Yes, haldaemon is at 98. > > > > > > > What version of hal and NetworkManager do you have? > > > > Bill > > > > > ]# yum list hal NetworkManager > Loaded plugins: fastestmirror, refresh-packagekit > Loading mirror speeds from cached hostfile > * rawhide: mirror.hiwaay.net > rawhide | 2.4 kB > 00:00 > Installed Packages > NetworkManager.i386 1:0.7.0-0.9.2.svn3566. Yeah; you'll want latest F9 bits for NM at least. > Also, NetworkManager keeps erasing /etc/resolv.conf. I go into > Network and define all the DNS. I check /etc/resolv.conf to make sure > it gets there. And then some time later when I'm doing some network > operation DNS fails and I look and /etc/resolv.conf is empty except > for the line that says generated by NetworkManager. Since the DNS info is not necessarily global to the entire machine, but can be per-device, you probably want to define DNS servers and search domains directly in the ifcfg files as is done for PPP connections already. Updated versions of NetworkManager will place a note in /etc/resolv.conf pointing this out if it can't find any DNS servers. The problem is that resolv.conf is transient. It's created from a _composite_ of the DNS information from multiple connections. For example, if I'm on a VPN, I need the nameservers for both my normal (eth0) connection and the VPN connection, but the VPN may only resolve names for the private network, not the internet as a whole. But I certainly don't want the VPN nameserver listed in resolv.conf when I'm not connected to the VPN. That sort of thing. Dan > > Regards, > Gerry > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From wwoods at redhat.com Tue May 6 13:44:23 2008 From: wwoods at redhat.com (Will Woods) Date: Tue, 6 May 2008 09:44:23 -0400 Subject: F9 nfs, rpcbind, NetworkManager In-Reply-To: <481F9537.5000607@verizon.net> References: <481F4BEF.8030004@verizon.net> <481F5041.4050005@verizon.net> <20080505182626.GA14432@nostromo.devel.redhat.com> <481F5B00.6030707@verizon.net> <20080505194202.GA5506@nostromo.devel.redhat.com> <481F66C2.90508@verizon.net> <20080505200129.GC5506@nostromo.devel.redhat.com> <481F685B.9010207@verizon.net> <20080505200932.GD5506@nostromo.devel.redhat.com> <481F6A7B.2070203@verizon.net> <20080505201657.GA10128@nostromo.devel.redhat.com> <481F7387.4050104@verizon.net> <481F778E.4040209@verizon.net> <481F7914.1040000@verizon.net> <481F7BE5.8080502@verizon.net> <481F9537.5000607@verizon.net> Message-ID: <40FD5026-FD1A-4152-9877-17AC2B411968@redhat.com> On May 5, 2008, at 7:16 PM, Gerry Reno wrote: > I finally got the priorities on NetworkManager to reset to 27 73. > So I reboot and I finally have nfs mounts and network at login. But > now the shutdown hangs. It throws you out to the black 'login:' > prompt screen and then it hangs there forever. Does it? Hit Alt-F7 - the shutdown messages are on VT7. -w From bpepple at fedoraproject.org Tue May 6 13:44:09 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Tue, 06 May 2008 09:44:09 -0400 Subject: Maintainer Responsibility Policy In-Reply-To: <62bc09df0805060610n742c3bf4j15a751cfcb2c1b8f@mail.gmail.com> References: <1210035695.6297.25.camel@kennedy> <62bc09df0805060610n742c3bf4j15a751cfcb2c1b8f@mail.gmail.com> Message-ID: <1210081449.18413.2.camel@kennedy> On Tue, 2008-05-06 at 15:10 +0200, Xavier Lamien wrote: > 2008/5/6 Brian Pepple : > > === Miscellaneous Items === > * Maintainers need to maintain an upgrade path for their > packages. > * F(current-1) -> F(current) -> Rawhide > * Packages should be pushed to the Rawhide branch first. > If it > builds and works fine for a few days, then it can be > pushed to > F(current). If there is a good reason to push it to > F(current-1), it should be done after a few days of > being in > F(current). > > I think you should also mention the act of "pushing to testing" repo > for each current fedora release. Yeah, that's not a bad idea. I believe when that section was written, Bodhi wasn't even around (which tells you how long this proposal has been around). I'll add a note. Thanks, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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: 197 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Tue May 6 13:54:43 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 06 May 2008 06:54:43 -0700 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <48203FF0.70205@kanarip.com> References: <1209999548.32107.11.camel@kennedy> <481F2986.8010509@redhat.com> <1210002669.26792.65.camel@beck.corsepiu.local> <481FD064.6050307@ncsu.edu> <1210045081.4658.7.camel@localhost.localdomain> <481FD3D5.5070206@ncsu.edu> <1210071473.29415.128.camel@localhost.localdomain> <48203FF0.70205@kanarip.com> Message-ID: <48206323.9060300@gmail.com> Jeroen van Meeuwen wrote: > Jesse Keating wrote: >> On Mon, 2008-05-05 at 23:43 -0400, Casey Dahlin wrote: >>> The gain is we decide what to keep and what not to keep based on who >>> actually is willing to fight to keep it around rather than whoever >>> feels like complaining on devel list. Its a corollary to "its easier >>> to apologize than to ask permission," the people who notice the >>> change are a tiny and far more important subset than the people who >>> will complain ahead of time. >> >> It doesn't account for the developers who will have failures, notice we >> don't package a version of autoconf anymore and say "Screw that" and >> move to some other development platform which does support what they >> need. >> >> > > My $.02 worth of thoughts: > > One could imagine a policy in which new packages using these tools would > not be accepted per-se, while the tools would still be available, > packaged, for those other packages and developers that need it. > > Does such, or something similar, make sense? > No. The packager should not have to use the autotools normally. So during package review, what version of autotools is necessary might not come up. Only when a problem is discovered that requires changing the configure.in/ac or Makefile.am will the version of autotools start mattering to the packager. -Toshio From buc at odusz.so-cdu.ru Tue May 6 13:58:57 2008 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Tue, 06 May 2008 17:58:57 +0400 Subject: Maintainer Responsibility Policy In-Reply-To: <1210081449.18413.2.camel@kennedy> References: <1210035695.6297.25.camel@kennedy> <62bc09df0805060610n742c3bf4j15a751cfcb2c1b8f@mail.gmail.com> <1210081449.18413.2.camel@kennedy> Message-ID: <48206421.8090907@odu.neva.ru> Brian Pepple wrote: > On Tue, 2008-05-06 at 15:10 +0200, Xavier Lamien wrote: > >> * Packages should be pushed to the Rawhide branch first. >> If it >> builds and works fine for a few days, then it can be >> pushed to >> F(current). If there is a good reason to push it to >> F(current-1), it should be done after a few days of >> being in >> F(current). >> >> I think you should also mention the act of "pushing to testing" repo >> for each current fedora release. >> > > Yeah, that's not a bad idea. I believe when that section was written, > Bodhi wasn't even around (which tells you how long this proposal has > been around). I'll add a note. > A restriction of "few days" might complicate the maintainer work. It is much more easy to compile for all the branches at one time, rather than to plan it for 3 different days. IMO it would be better if such a delaying will be performed automatically at "updates-testing-->updates" stage... ~buc http://www.fedoraproject.org/wiki/DmitryButskoy From foster at in.tum.de Tue May 6 14:01:34 2008 From: foster at in.tum.de (Mary Ellen Foster) Date: Tue, 6 May 2008 15:01:34 +0100 Subject: python packaging - icons/desktop files and /usr/bin accessibility In-Reply-To: <481F81FE.5020500@gmail.com> References: <481EFE72.1030105@iinet.net.au> <481F81FE.5020500@gmail.com> Message-ID: [ NB: I sent this to fedora-packaging as well as fedora-devel, and it's probably better to follow up there because this thread is shifting focus ... ] On Mon, May 5, 2008 at 10:54 PM, Toshio Kuratomi wrote: > I took a closer look at Ice and I think there's a few things that should > change. > > 1) AFAICS there's no reason for the python bindings to be part of the Ice > package. It comes in a separate tarball and appears to build on its own. I > can't find a mention of this in the review so I don't know if there's > something special about it that I'm missing. [1]_ Actually, upstream is very soon releasing a new version of Ice where all of the language bindings are in a single tarball, so I think I'll stick with the monolithic SRPM. > 2) The .pth file looks like it's being used to compensate for bad imports > and upstream packaging. > * There should be an __init__.py file in > %{_libdir}/pythonX.Y/site-packages/Ice > > * The following files have imports that need to be changed: > IceBox/__init__.py > Glacier2/__init__.py > IceGrid/__init__.py > IceStorm/__init__.py > IcePatch2/__init__.py > > change imports like:: > import IceBox_IceBox_ice > to this:: > from Ice import IceBox_IceBox_ice The problem is, those files are automatically generated using other parts of the Ice program (using slice2py, to be specific). There's a documented way that slice2py deals with packages and modules (http://zeroc.com/doc/Ice-3.2.1/manual/Python.23.15.html#75777) that I'm reluctant to touch. I could remove the "Ice.pth" file and require people to set PYTHONPATH, but unfortunately I don't think I can go changing the actual (generated) __init__.py files. :( > 3) Additionally, on x86_64, the python module is spread over two > directories: /usr/lib64/python2.5/site-packages/Ice and > /usr/lib/python2.5/site-packages/Ice. Python doesn't handle that very well. > All the files of a module should be in a single directory. Since this > module builds an ELF shared object (IcePy.so/IcePy.so.3.2.1) all files > should be installed into %{python_sitearch}/ (This is what lead to BZ > #392751). Okay, sure, that's easy to fix. So I should put *.py* into site_arch always, and put nothing into site_lib? The Python packaging guidelines aren't amazingly clear on this point to a non-Python programmer like me. :) MEF -- Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/ Informatik 6: Robotics and Embedded Systems, Technische Universit?t M?nchen and ICCS, School of Informatics, University of Edinburgh From a.badger at gmail.com Tue May 6 14:02:21 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 06 May 2008 07:02:21 -0700 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <482044AF.8040109@redhat.com> References: <1209999548.32107.11.camel@kennedy> <481F2986.8010509@redhat.com> <1210002669.26792.65.camel@beck.corsepiu.local> <481FD064.6050307@ncsu.edu> <1210045081.4658.7.camel@localhost.localdomain> <481FD3D5.5070206@ncsu.edu> <1210071473.29415.128.camel@localhost.localdomain> <48203FF0.70205@kanarip.com> <482044AF.8040109@redhat.com> Message-ID: <482064ED.7040506@gmail.com> Karsten Hopp wrote: > Jeroen van Meeuwen wrote: >> Jesse Keating wrote: >>> On Mon, 2008-05-05 at 23:43 -0400, Casey Dahlin wrote: >>>> The gain is we decide what to keep and what not to keep based on who >>>> actually is willing to fight to keep it around rather than whoever >>>> feels like complaining on devel list. Its a corollary to "its easier >>>> to apologize than to ask permission," the people who notice the >>>> change are a tiny and far more important subset than the people who >>>> will complain ahead of time. >>> >>> It doesn't account for the developers who will have failures, notice we >>> don't package a version of autoconf anymore and say "Screw that" and >>> move to some other development platform which does support what they >>> need. >>> >>> >> >> My $.02 worth of thoughts: >> >> One could imagine a policy in which new packages using these tools >> would not be accepted per-se, while the tools would still be >> available, packaged, for those other packages and developers that need >> it. >> >> Does such, or something similar, make sense? >> > > Such a policy would be ok with me. The whole intention for this proposal > was > to disencourage usage of the old tools, not to force maintainers to > rewrite their > configure scripts immediately or use another distribution. > Nonetheless maintainers of forementioned packages should check if it is > necessary to run autofoo during the build. Most of the times it isn't > and if I > remember correctly even I am guilty of doing this due to laziness and/or > time > constraints. > The problem with talking about removing these packages is that the packages may not need to run the autotools during build at present but that doesn't mean they don't have to be run at some indefinite point in the future. For release 1.0-1.4 of libfoo, upstream didn't require any patching so everything worked fine. In release 1.5, upstream made a mess of how they create and deploy some utilities built with libfoo. In order to fix this, you have to patch the configure.ac and Makefile.am. Suddenly you need to have the autotools to be able to build. (Note: whether you run the autotools from within the spec file or run them locally and then include the diff with the SRPM, you may still need to have matching versions of the autotools available to make everything work. Getting this right needs to do a lot of upstream education before it can be removed from the distro.) -Toshio From wjhns174 at hardakers.net Tue May 6 14:07:52 2008 From: wjhns174 at hardakers.net (Wes Hardaker) Date: Tue, 06 May 2008 07:07:52 -0700 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <870180fe0805052050pcac64e2x6377a65a59dce11c@mail.gmail.com> (Jerry James's message of "Mon, 5 May 2008 21:50:30 -0600") References: <1209999548.32107.11.camel@kennedy> <870180fe0805052050pcac64e2x6377a65a59dce11c@mail.gmail.com> Message-ID: >>>>> On Mon, 5 May 2008 21:50:30 -0600, "Jerry James" said: JJ> Actually, we did update it on the 21.5 (beta) branch quite awhile ago. JJ> It's true that the 21.4 (stable) branch has never been updated, JJ> though. Which means anyone working on the stable version and adding patches to that still needs the older autoconf (which was my point). 21.4 has been the stable branch for a very very long time... -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett From a.badger at gmail.com Tue May 6 14:10:50 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 06 May 2008 07:10:50 -0700 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <7652.1210046249@sss.pgh.pa.us> References: <1209999548.32107.11.camel@kennedy> <1210002510.26792.62.camel@beck.corsepiu.local> <1210003068.5320.10.camel@localhost.localdomain> <1210003850.26792.73.camel@beck.corsepiu.local> <481F3294.9010304@fedoraproject.org> <1210004577.26792.84.camel@beck.corsepiu.local> <1210034164.4658.2.camel@localhost.localdomain> <7652.1210046249@sss.pgh.pa.us> Message-ID: <482066EA.1010801@gmail.com> Tom Lane wrote: > Matthias Clasen writes: >> On Mon, 2008-05-05 at 18:22 +0200, Ralf Corsepius wrote: >>> The key to avoid autotool compatibility issues is simple: Do not >>> generate autotool generated files while building. >>> Generate them off-line. > >> ...which won't be easy if the autotool versions you need to generate >> them are kicked out. > > Yeah. We have a rule against shipping binary blobs. A binary blob can > fairly be defined as a derived file that you lack the source to, or lack > the tools to get from the source to the derived file. How is it > different if we ship an autotools-derived file that the recipient > cannot regenerate from source? Smells like a GPL violation to me. > The idea is to ship both the patch for configure.ac/Makefile.am which can go upstream and the diff between the old version of the generated configure/Makefile/Makefile.in's and the new. So source is being provided. -Toshio From wjhns174 at hardakers.net Tue May 6 14:09:54 2008 From: wjhns174 at hardakers.net (Wes Hardaker) Date: Tue, 06 May 2008 07:09:54 -0700 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <870180fe0805052050pcac64e2x6377a65a59dce11c@mail.gmail.com> (Jerry James's message of "Mon, 5 May 2008 21:50:30 -0600") References: <1209999548.32107.11.camel@kennedy> <870180fe0805052050pcac64e2x6377a65a59dce11c@mail.gmail.com> Message-ID: >>>>> On Mon, 5 May 2008 21:50:30 -0600, "Jerry James" said: JJ> Actually, we did update it on the 21.5 (beta) branch quite awhile ago. JJ> It's true that the 21.4 (stable) branch has never been updated, JJ> though. In second thought, that really brings up one of my primary points: People don't like upgrading autoconf version usage on old branches because it brings about unknown effects a lot of the time. IE, it's simply not safe to do without heavy understanding and testing. It's like adding a feature; you don't do it on stable releases because it can't be trusted. And thus, if we want developers to use fedora we should distribute multiple versions of the development tools when version updates have potentially large ramifications. -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett From rdieter at math.unl.edu Tue May 6 14:17:34 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 06 May 2008 09:17:34 -0500 Subject: MultilibTricks References: <870180fe0805051352v886f900p5712981d974c7721@mail.gmail.com> <481F7520.3020808@hhs.nl> <604aa7910805051602t5bcb6e3fi15390a7ead0292a6@mail.gmail.com> <7932.1210047894@sss.pgh.pa.us> <20080506144645.77b84cb7.mschwendt@gmail.com> <20080506145523.df548b07.mschwendt@gmail.com> Message-ID: Michael Schwendt wrote: > On Tue, 6 May 2008 14:46:45 +0200, Michael Schwendt wrote: > >> On Tue, 06 May 2008 07:24:40 -0500, Rex Dieter wrote: >> >> > Tom Lane wrote: >> > >> > >> > > Indeed, in my experience the entire POINT of a -libs subpackage is >> > > that >> > > it doesn't pull in the whole base package. If it does, why are you >> > > bothering to create a separate libs subpackage? So the review >> > > guidelines are indisputably broken here. >> > >> > -libs, even if Require'ing the base pkg, helps multilib-wise. >> >> If -libs requires base pkg, there's no need to split the two. >> >> And it cannot help multilib-wise, because the -devel => -libs => base pkg >> chain is still intact. > > Unless RPM doesn't care about the arch of the base pkg... and takes > either one, ... oh well... ah ha! ;) (yes, that is the case). -- Rex From a.badger at gmail.com Tue May 6 14:26:27 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 06 May 2008 07:26:27 -0700 Subject: Maintainer Responsibility Policy In-Reply-To: <482056BE.90100@n-dimensional.de> References: <1210035695.6297.25.camel@kennedy> <482056BE.90100@n-dimensional.de> Message-ID: <48206A93.7020807@gmail.com> Hans Ulrich Niedermann wrote: > Brian Pepple wrote: > >> === Deal with reported bugs in a timely manner ==== >> * 'Nuff said. > > "Deal with" meaning what, exactly? When the maintainer has reported the > bug to upstream in a timely manner, his job is done and he can patiently > wait for years until upstream fixes the bug or not? > A little more than that: 1) Someone who can work on the bug should know about it. - If the package maintainer is capable and willing, they can be working on fixing it. - If not, the package maintainer should have tried at least some of the following options: * reported it upstream. * asked for help on fedora-devel (there are people who volunteer their time to work on code/autotools problems that other package maintainers have) * checked if other distributions have patches for the problem already (google often finds patches in Debian, for instance.) 2) Let the bug reporter know what's going on with the bug report. If that happens to be that they reported it upstream and upstream has proven disinterested in fixing it, having an upstream bug#, etc is very useful. Then the bug reporter can try to get upstream to fix the bug themselves. Brian, we probably want to list the ways to deal with bug reports in the policy as many maintainers don't realize how many options there are for getting help fixing a bug. -Toshio From mike at miketc.com Tue May 6 14:40:45 2008 From: mike at miketc.com (Mike Chambers) Date: Tue, 06 May 2008 09:40:45 -0500 Subject: F9 nfs, rpcbind, NetworkManager In-Reply-To: <40FD5026-FD1A-4152-9877-17AC2B411968@redhat.com> References: <481F4BEF.8030004@verizon.net> <481F5041.4050005@verizon.net> <20080505182626.GA14432@nostromo.devel.redhat.com> <481F5B00.6030707@verizon.net> <20080505194202.GA5506@nostromo.devel.redhat.com> <481F66C2.90508@verizon.net> <20080505200129.GC5506@nostromo.devel.redhat.com> <481F685B.9010207@verizon.net> <20080505200932.GD5506@nostromo.devel.redhat.com> <481F6A7B.2070203@verizon.net> <20080505201657.GA10128@nostromo.devel.redhat.com> <481F7387.4050104@verizon.net> <481F778E.4040209@verizon.net> <481F7914.1040000@verizon.net> <481F7BE5.8080502@verizon.net> <481F9537.5000607@verizon.net> <40FD5026-FD1A-4152-9877-17AC2B411968@redhat.com> Message-ID: <1210084845.2716.0.camel@scrappy.miketc.com> On Tue, 2008-05-06 at 09:44 -0400, Will Woods wrote: > On May 5, 2008, at 7:16 PM, Gerry Reno wrote: > > > I finally got the priorities on NetworkManager to reset to 27 73. > > So I reboot and I finally have nfs mounts and network at login. But > > now the shutdown hangs. It throws you out to the black 'login:' > > prompt screen and then it hangs there forever. > > Does it? Hit Alt-F7 - the shutdown messages are on VT7. I see the same thing. It hangs on "shutting down quotas" and you have to hit the power button to get it to shut off or reboot. I believe in another email and/or thread this problem was also brought up. -- Mike Chambers Fedora Project - Ambassador, Bug Zapper, Tester, User, etc.. mikec302 at fedoraproject.org From mcepl at redhat.com Tue May 6 14:37:44 2008 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 06 May 2008 16:37:44 +0200 Subject: FESCo Proposal for blocking older version of autoconf & automake References: <1209999548.32107.11.camel@kennedy> <52564.75.164.221.130.1210012391.squirrel@clueserver.org> Message-ID: On Mon, 05 May 2008 11:33:11 -0700, Alan scripst: > I build a fair amount of software that is not in the repository. Some > of it requires crufty old versions of various toolkits. Having those > toolkits go away makes it much harder to get this packages to run. If I > have an older version that does compile, I can determine if it even > works at all. (Which happens far too often for me. *cough* *cough* > numerix *cough*) So, OK, why don't we carry gcc 2.95? There are still many pieces of software which needs it. Mat?j -- The content of this message is licensed under a Creative Commons Attribution 3.0 License, Some Rights Reserved. http://creativecommons.org/licenses/by/3.0/us/ From skasal at redhat.com Tue May 6 14:46:22 2008 From: skasal at redhat.com (Stepan Kasal) Date: Tue, 6 May 2008 16:46:22 +0200 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <1210006440.26792.109.camel@beck.corsepiu.local> References: <1209999548.32107.11.camel@kennedy> <1210002510.26792.62.camel@beck.corsepiu.local> <481F306A.90600@redhat.com> <1210004495.26792.82.camel@beck.corsepiu.local> <481F36F4.4060105@redhat.com> <1210006440.26792.109.camel@beck.corsepiu.local> Message-ID: <20080506144622.GA1823@camelia.ucw.cz> Hi, On Mon, May 05, 2008 at 06:53:59PM +0200, Ralf Corsepius wrote: > On Mon, 2008-05-05 at 12:33 -0400, Christopher Aillon wrote: > > Or if autotools maintainers would stop changing the interface so > > freaking often, this wouldn't be a problem either.... > Apparently you don't have much clues about the autotools. > > They did not change the "interface so often". > > There has been one big interface change: It occurred between > autoconf-2.13 and autoconf-2.50 - Many years ago. well, there was also the change in Automake 1.4 -> 1.5, which happened after that, and then the "stabilization period" for "new" automake until, say, 1.8. So it is about 7 years ago since the last interface change and we can say that Autotools are really stable and mature for at least 4 years. What _is_ the problem, is that many projects use an undocumented internals, instead of requesting an enhancement. And _that_ kind of hacks break very easily with a new release. Stepan From caillon at redhat.com Tue May 6 14:57:41 2008 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 06 May 2008 10:57:41 -0400 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <481FD064.6050307@ncsu.edu> References: <1209999548.32107.11.camel@kennedy> <481F2986.8010509@redhat.com> <1210002669.26792.65.camel@beck.corsepiu.local> <481FD064.6050307@ncsu.edu> Message-ID: <482071E5.7080300@redhat.com> On 05/05/2008 11:28 PM, Casey Dahlin wrote: > In light of this, I have a proposal: > > We fix our specs to not use autoconf, and remove the old versions as > stated, but we keep them around, perhaps in another branch in CVS or > simply removed from the F10 tag. Then we just wait for complaints. If > someone comes in and says "I was actively using that" we can just slap > it back in. After one release cycle we can flush the rest. I *am* actively using them. In order to fix the compilation errors with -Werror-implicit-function-declaration which we want to enable at some point, I had to modify some .m4 files which meant re-generating configure. With autoconf213. In order to fix compilation with some arches like ia64, s390, and sparc, configure needed to be regenerated. With autoconf213. In order to write and test new configure args for --enable-system-foo, configure needs to be regenerated. With autoconf213. etc. etc. From greno at verizon.net Tue May 6 14:59:46 2008 From: greno at verizon.net (Gerry Reno) Date: Tue, 06 May 2008 10:59:46 -0400 Subject: F9 nfs, rpcbind, NetworkManager In-Reply-To: <1210081105.21415.3.camel@localhost.localdomain> References: <481F4BEF.8030004@verizon.net> <481F5041.4050005@verizon.net> <20080505182626.GA14432@nostromo.devel.redhat.com> <481F5B00.6030707@verizon.net> <20080505194202.GA5506@nostromo.devel.redhat.com> <481F66C2.90508@verizon.net> <20080505200129.GC5506@nostromo.devel.redhat.com> <481F685B.9010207@verizon.net> <20080505200932.GD5506@nostromo.devel.redhat.com> <481F6A7B.2070203@verizon.net> <1210081105.21415.3.camel@localhost.localdomain> Message-ID: <48207262.5010903@verizon.net> Dan Williams wrote: > > Since the DNS info is not necessarily global to the entire machine, but > can be per-device, you probably want to define DNS servers and search > domains directly in the ifcfg files as is done for PPP connections > already. Updated versions of NetworkManager will place a note > in /etc/resolv.conf pointing this out if it can't find any DNS servers. > > The problem is that resolv.conf is transient. It's created from a > _composite_ of the DNS information from multiple connections. For > example, if I'm on a VPN, I need the nameservers for both my normal > (eth0) connection and the VPN connection, but the VPN may only resolve > names for the private network, not the internet as a whole. But I > certainly don't want the VPN nameserver listed in resolv.conf when I'm > not connected to the VPN. That sort of thing. > > Dan > > Well, I would think in this scenario of supporting per-device name resolution that /etc/resolv.conf would act as a 'global' db and the /etc/sysconfig/network-scripts/ifcfg* files would be the per-device db. But NM should not just erase your /etc/resolv.conf. That's just wrong. You fill in all the info it its gui and then save and then sometime later at some random time it just decides its going to erase /etc/resolv.conf. Very bad. Besides, I have many tools/scripts that work against /etc/resolv.conf and of course I would have to rewrite these if I wanted them to support per-device dns. But I shouldn't have to if I only want a global dns nameserver db in /etc/resolv.conf. Regards, Gerry -------------- next part -------------- An HTML attachment was scrubbed... URL: From caillon at redhat.com Tue May 6 15:02:33 2008 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 06 May 2008 11:02:33 -0400 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <481FD3D5.5070206@ncsu.edu> References: <1209999548.32107.11.camel@kennedy> <481F2986.8010509@redhat.com> <1210002669.26792.65.camel@beck.corsepiu.local> <481FD064.6050307@ncsu.edu> <1210045081.4658.7.camel@localhost.localdomain> <481FD3D5.5070206@ncsu.edu> Message-ID: <48207309.3040403@redhat.com> On 05/05/2008 11:43 PM, Casey Dahlin wrote: > Matthias Clasen wrote: >> On Mon, 2008-05-05 at 23:28 -0400, Casey Dahlin wrote: >> >> >>> In light of this, I have a proposal: >>> >>> We fix our specs to not use autoconf, and remove the old versions as >>> stated, but we keep them around, perhaps in another branch in CVS or >>> simply removed from the F10 tag. Then we just wait for complaints. If >>> someone comes in and says "I was actively using that" we can just >>> slap it back in. After one release cycle we can flush the rest. >>> >>> >> >> And we do all this work because we have nothing better to do ? >> Whats the gain, again ? >> >> > The gain is we decide what to keep and what not to keep based on who > actually is willing to fight to keep it around rather than whoever feels > like complaining on devel list. Its a corollary to "its easier to > apologize than to ask permission," the people who notice the change are > a tiny and far more important subset than the people who will complain > ahead of time. If you'd have read the thread, you'd have noticed I already pointed out multiple times, if you want to keep Firefox in the distro, you need to keep autoconf213 for the forseeable future. The path to removing autoconf213 lies in someone patching upstream Firefox (along with whatever other packages still uses autoconf213) to use newer autotools and then waiting several Fedora release cycles, because this change is almost certainly not going to happen ever in Firefox 3. Get it changed for Firefox 4 and when that rolls around in F13??, we can talk about dropping it. Even then, there are likely other packages not in our distro that want it, and we'd be breaking them. But to do so now is folly. From caillon at redhat.com Tue May 6 15:04:37 2008 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 06 May 2008 11:04:37 -0400 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <482044AF.8040109@redhat.com> References: <1209999548.32107.11.camel@kennedy> <481F2986.8010509@redhat.com> <1210002669.26792.65.camel@beck.corsepiu.local> <481FD064.6050307@ncsu.edu> <1210045081.4658.7.camel@localhost.localdomain> <481FD3D5.5070206@ncsu.edu> <1210071473.29415.128.camel@localhost.localdomain> <48203FF0.70205@kanarip.com> <482044AF.8040109@redhat.com> Message-ID: <48207385.2060909@redhat.com> On 05/06/2008 07:44 AM, Karsten Hopp wrote: > Jeroen van Meeuwen wrote: >> Jesse Keating wrote: >>> On Mon, 2008-05-05 at 23:43 -0400, Casey Dahlin wrote: >>>> The gain is we decide what to keep and what not to keep based on who >>>> actually is willing to fight to keep it around rather than whoever >>>> feels like complaining on devel list. Its a corollary to "its easier >>>> to apologize than to ask permission," the people who notice the >>>> change are a tiny and far more important subset than the people who >>>> will complain ahead of time. >>> >>> It doesn't account for the developers who will have failures, notice we >>> don't package a version of autoconf anymore and say "Screw that" and >>> move to some other development platform which does support what they >>> need. >>> >>> >> >> My $.02 worth of thoughts: >> >> One could imagine a policy in which new packages using these tools >> would not be accepted per-se, while the tools would still be >> available, packaged, for those other packages and developers that need >> it. >> >> Does such, or something similar, make sense? >> > > Such a policy would be ok with me. The whole intention for this proposal > was > to disencourage usage of the old tools, not to force maintainers to > rewrite their > configure scripts immediately or use another distribution. > Nonetheless maintainers of forementioned packages should check if it is > necessary to run autofoo during the build. Most of the times it isn't > and if I > remember correctly even I am guilty of doing this due to laziness and/or > time > constraints. Doing it during the build is not the issue. You can't even generate a patch to configure if the tool to do regenerate it is not available in the distro. From mike at miketc.com Tue May 6 15:12:25 2008 From: mike at miketc.com (Mike Chambers) Date: Tue, 06 May 2008 10:12:25 -0500 Subject: Flash on rawhide Message-ID: <1210086745.2716.6.camel@scrappy.miketc.com> Installed rawhide this morning (err, very late last night and configured it this morning), and it seems flash OR pulseaudio isn't working. I can hear normal system sounds just fine. But if I go to a flash site, such as http://espn.go.com and play the sportscenter video, it plays fine but can't hear anything. While that is going on, I called up the Menu/Sound & Video/PulseAudio Volume Control menu and it shows no streaming. But you keep seeing a flashed menu that keeps coming up, but it seems transparent? Probably doesn't sound right but if someone would try it, maybe they will see the same thing. I will say before I did the install, that it had been working fine on a previous install from days/weeks ago and had been doing just updates. So if there is something not installed that needs to be, I cant' think of what it is. The flash-plugin came straight from adobe via yum. Any ideas? -- Mike Chambers Fedora Project - Ambassador, Bug Zapper, Tester, User, etc.. mikec302 at fedoraproject.org From notting at redhat.com Tue May 6 15:22:22 2008 From: notting at redhat.com (Bill Nottingham) Date: Tue, 6 May 2008 11:22:22 -0400 Subject: Flash on rawhide In-Reply-To: <1210086745.2716.6.camel@scrappy.miketc.com> References: <1210086745.2716.6.camel@scrappy.miketc.com> Message-ID: <20080506152222.GA21258@nostromo.devel.redhat.com> Mike Chambers (mike at miketc.com) said: > Installed rawhide this morning (err, very late last night and configured > it this morning), and it seems flash OR pulseaudio isn't working. I can > hear normal system sounds just fine. But if I go to a flash site, such > as http://espn.go.com and play the sportscenter video, it plays fine but > can't hear anything. > > While that is going on, I called up the Menu/Sound & Video/PulseAudio > Volume Control menu and it shows no streaming. But you keep seeing a > flashed menu that keeps coming up, but it seems transparent? Probably > doesn't sound right but if someone would try it, maybe they will see the > same thing. > > I will say before I did the install, that it had been working fine on a > previous install from days/weeks ago and had been doing just updates. > So if there is something not installed that needs to be, I cant' think > of what it is. The flash-plugin came straight from adobe via yum. > > Any ideas? You probably need libflashsupport.i386. Bill From kanarip at kanarip.com Tue May 6 15:24:55 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 06 May 2008 17:24:55 +0200 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <48206323.9060300@gmail.com> References: <1209999548.32107.11.camel@kennedy> <481F2986.8010509@redhat.com> <1210002669.26792.65.camel@beck.corsepiu.local> <481FD064.6050307@ncsu.edu> <1210045081.4658.7.camel@localhost.localdomain> <481FD3D5.5070206@ncsu.edu> <1210071473.29415.128.camel@localhost.localdomain> <48203FF0.70205@kanarip.com> <48206323.9060300@gmail.com> Message-ID: <48207847.70308@kanarip.com> Toshio Kuratomi wrote: > Jeroen van Meeuwen wrote: >> One could imagine a policy in which new packages using these tools >> would not be accepted per-se, while the tools would still be >> available, packaged, for those other packages and developers that need >> it. >> >> Does such, or something similar, make sense? >> > No. > > The packager should not have to use the autotools normally. So during > package review, what version of autotools is necessary might not come > up. Only when a problem is discovered that requires changing the > configure.in/ac or Makefile.am will the version of autotools start > mattering to the packager. > While the "problem" may not be apparent at first, one can tell from any configure.in/ac or Makefile.am whether it needs one of the older autofoo tools though, right? If so, I can only conclude the reviewer would be able to raise this (but, possibly, not block approval?). If not so, forget what I said -I'm no guru in autofoo ;-) BTW... Given your statement: > The packager should not have to use the autotools normally. I "never" *cough* the two packages that I'm upstream for *cough* ship any autofoo output files, only autofoo input files; it's excluded from the source tree and excluded in tarballs... Should I reconsider this? Is it gonna give trouble at some point? Kind regards, Jeroen van Meeuwen -kanarip From mike at miketc.com Tue May 6 15:29:42 2008 From: mike at miketc.com (Mike Chambers) Date: Tue, 06 May 2008 10:29:42 -0500 Subject: Flash on rawhide In-Reply-To: <20080506152222.GA21258@nostromo.devel.redhat.com> References: <1210086745.2716.6.camel@scrappy.miketc.com> <20080506152222.GA21258@nostromo.devel.redhat.com> Message-ID: <1210087782.2716.8.camel@scrappy.miketc.com> On Tue, 2008-05-06 at 11:22 -0400, Bill Nottingham wrote: > Mike Chambers (mike at miketc.com) said: > > Installed rawhide this morning (err, very late last night and configured > > it this morning), and it seems flash OR pulseaudio isn't working. I can > > hear normal system sounds just fine. But if I go to a flash site, such > > as http://espn.go.com and play the sportscenter video, it plays fine but > > can't hear anything. > > > > While that is going on, I called up the Menu/Sound & Video/PulseAudio > > Volume Control menu and it shows no streaming. But you keep seeing a > > flashed menu that keeps coming up, but it seems transparent? Probably > > doesn't sound right but if someone would try it, maybe they will see the > > same thing. > > > > I will say before I did the install, that it had been working fine on a > > previous install from days/weeks ago and had been doing just updates. > > So if there is something not installed that needs to be, I cant' think > > of what it is. The flash-plugin came straight from adobe via yum. > > > > Any ideas? > > You probably need libflashsupport.i386. That did the trick, thanks notting. Hrm, should that be installed by default by chance? Otherwise, think adobe needs to require that package I would think? -- Mike Chambers Fedora Project - Ambassador, Bug Zapper, Tester, User, etc.. mikec302 at fedoraproject.org From zprikryl at redhat.com Tue May 6 15:39:49 2008 From: zprikryl at redhat.com (Zdenek Prikryl) Date: Tue, 06 May 2008 17:39:49 +0200 Subject: New system-config-acpid Message-ID: <48207BC5.3060105@redhat.com> Hello, the new system config tool was born. This time it is the tool which tries to make a configuration of acpid easier. So, by this tool you can catch acpi events or acpi hotkeys events and then you can assign actions to them. If you find a bug, please send a description of the bug or a patch directly to me. Enjoy :-) tarball ------- http://fedorapeople.org/~zprikryl/system-config-acpid-0.1.1.tar.bz2 src.rpm ------- http://fedorapeople.org/~zprikryl/system-config-acpid-0.1.1-1.fc9.src.rpm -- Zdenek Prikryl From notting at redhat.com Tue May 6 15:44:07 2008 From: notting at redhat.com (Bill Nottingham) Date: Tue, 6 May 2008 11:44:07 -0400 Subject: New system-config-acpid In-Reply-To: <48207BC5.3060105@redhat.com> References: <48207BC5.3060105@redhat.com> Message-ID: <20080506154407.GA21822@nostromo.devel.redhat.com> Zdenek Prikryl (zprikryl at redhat.com) said: > Hello, > the new system config tool was born. This time it is the tool which tries to > make a configuration of acpid easier. So, by this tool you can catch acpi events > or acpi hotkeys events and then you can assign actions to them. Not to be a killjoy, but why a config tool for a program which should probably die? Aren't these all better handled by user-specific policy agents such as gnome-power-manager or kpowersave? Bill From stlwrt at gmail.com Tue May 6 15:46:10 2008 From: stlwrt at gmail.com (Pavel Shevchuk) Date: Tue, 6 May 2008 18:46:10 +0300 Subject: New system-config-acpid In-Reply-To: <20080506154407.GA21822@nostromo.devel.redhat.com> References: <48207BC5.3060105@redhat.com> <20080506154407.GA21822@nostromo.devel.redhat.com> Message-ID: To make laptop custom buttons work in gdm/kdm? On 5/6/08, Bill Nottingham wrote: > Zdenek Prikryl (zprikryl at redhat.com) said: > > Hello, > > the new system config tool was born. This time it is the tool which tries to > > make a configuration of acpid easier. So, by this tool you can catch acpi events > > or acpi hotkeys events and then you can assign actions to them. > > > Not to be a killjoy, but why a config tool for a program which should > probably die? Aren't these all better handled by user-specific policy > agents such as gnome-power-manager or kpowersave? > > > Bill > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- http://scwlab.com From paul at all-the-johnsons.co.uk Tue May 6 15:47:02 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Tue, 06 May 2008 16:47:02 +0100 Subject: ext3 problem - help! Message-ID: <1210088822.12045.6.camel@T7.Linux> Hi, When I booted up my PC this morning, it came up with an ext3 problem. It first made the drive ext2, repaired the drive as journal system and then set it to be ext3. Only problem is that the files on the drive have vanished. Is there any way to get them back or should I consign the problem to the big question mark in the sky, shrug my shoulders and walk... TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From wwoods at redhat.com Tue May 6 15:54:40 2008 From: wwoods at redhat.com (Will Woods) Date: Tue, 06 May 2008 11:54:40 -0400 Subject: Flash on rawhide In-Reply-To: <1210087782.2716.8.camel@scrappy.miketc.com> References: <1210086745.2716.6.camel@scrappy.miketc.com> <20080506152222.GA21258@nostromo.devel.redhat.com> <1210087782.2716.8.camel@scrappy.miketc.com> Message-ID: <1210089280.594.3.camel@metroid.rdu.redhat.com> On Tue, 2008-05-06 at 10:29 -0500, Mike Chambers wrote: > On Tue, 2008-05-06 at 11:22 -0400, Bill Nottingham wrote: > > > > You probably need libflashsupport.i386. > > That did the trick, thanks notting. Hrm, should that be installed by > default by chance? Otherwise, think adobe needs to require that package > I would think? You'd think that, but they refuse. And you can't currently require an i386 package on an x86_64 system. It's a bit of a pickle. -w -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From bpepple at fedoraproject.org Tue May 6 15:54:21 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Tue, 06 May 2008 11:54:21 -0400 Subject: Maintainer Responsibility Policy In-Reply-To: <48206A93.7020807@gmail.com> References: <1210035695.6297.25.camel@kennedy> <482056BE.90100@n-dimensional.de> <48206A93.7020807@gmail.com> Message-ID: <1210089261.2961.3.camel@kennedy> On Tue, 2008-05-06 at 07:26 -0700, Toshio Kuratomi wrote: > Brian, we probably want to list the ways to deal with bug reports in the > policy as many maintainers don't realize how many options there are for > getting help fixing a bug. Here's what I've got right now (from Kevin's suggestion) in the section regarding bugs: "If you find yourself unable to handle the load of bugs from your package(s), please ask for assistance on the fedora-devel and/or fedora-test lists. Teaching triagers about how to triage your bugs or getting help from other maintainers can not only reduce your load, but improve Fedora. Consider reaching out for some (more) co-maintainers to assist as well." Do we want to expand on that? Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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: 197 bytes Desc: This is a digitally signed message part URL: From sandeen at redhat.com Tue May 6 15:56:53 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Tue, 06 May 2008 10:56:53 -0500 Subject: ext3 problem - help! In-Reply-To: <1210088822.12045.6.camel@T7.Linux> References: <1210088822.12045.6.camel@T7.Linux> Message-ID: <48207FC5.7060803@redhat.com> Paul wrote: > Hi, > > When I booted up my PC this morning, it came up with an ext3 problem. It > first made the drive ext2, repaired the drive as journal system and then > set it to be ext3. > > Only problem is that the files on the drive have vanished. > > Is there any way to get them back or should I consign the problem to the > big question mark in the sky, shrug my shoulders and walk... > > TTFN > > Paul > Not nearly enough info here, and probably not the right list. I'd gather up system logs, dmesg, repair output, contents of lost+found/ etc and send a note to the ext3-users list. Thanks, -Eric From ville.skytta at iki.fi Tue May 6 15:56:49 2008 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Tue, 6 May 2008 18:56:49 +0300 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: References: <1209999548.32107.11.camel@kennedy> <870180fe0805052050pcac64e2x6377a65a59dce11c@mail.gmail.com> Message-ID: <200805061856.50029.ville.skytta@iki.fi> On Tuesday 06 May 2008, Wes Hardaker wrote: > >>>>> On Mon, 5 May 2008 21:50:30 -0600, "Jerry James" > >>>>> said: > > JJ> Actually, we did update it on the 21.5 (beta) branch quite awhile ago. > JJ> It's true that the 21.4 (stable) branch has never been updated, > JJ> though. > > Which means anyone working on the stable version and adding patches to > that still needs the older autoconf (which was my point). Not really; only those who change things that require autoconf to be re-run. The generated "configure" for 21.4 is not only in the dist tarballs, but also in hg. From jkeating at redhat.com Tue May 6 16:00:19 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 06 May 2008 12:00:19 -0400 Subject: New system-config-acpid In-Reply-To: References: <48207BC5.3060105@redhat.com> <20080506154407.GA21822@nostromo.devel.redhat.com> Message-ID: <1210089619.17842.2.camel@localhost.localdomain> On Tue, 2008-05-06 at 18:46 +0300, Pavel Shevchuk wrote: > To make laptop custom buttons work in gdm/kdm? gdm at least runs session agents like gnome-power-manager so that you can get events like this. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Tue May 6 16:04:59 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 06 May 2008 09:04:59 -0700 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <48207847.70308@kanarip.com> References: <1209999548.32107.11.camel@kennedy> <481F2986.8010509@redhat.com> <1210002669.26792.65.camel@beck.corsepiu.local> <481FD064.6050307@ncsu.edu> <1210045081.4658.7.camel@localhost.localdomain> <481FD3D5.5070206@ncsu.edu> <1210071473.29415.128.camel@localhost.localdomain> <48203FF0.70205@kanarip.com> <48206323.9060300@gmail.com> <48207847.70308@kanarip.com> Message-ID: <482081AB.4020804@gmail.com> Jeroen van Meeuwen wrote: > Toshio Kuratomi wrote: >> Jeroen van Meeuwen wrote: >>> One could imagine a policy in which new packages using these tools >>> would not be accepted per-se, while the tools would still be >>> available, packaged, for those other packages and developers that >>> need it. >>> >>> Does such, or something similar, make sense? >>> >> No. >> >> The packager should not have to use the autotools normally. So during >> package review, what version of autotools is necessary might not come >> up. Only when a problem is discovered that requires changing the >> configure.in/ac or Makefile.am will the version of autotools start >> mattering to the packager. >> > > While the "problem" may not be apparent at first, one can tell from any > configure.in/ac or Makefile.am whether it needs one of the older autofoo > tools though, right? If so, I can only conclude the reviewer would be > able to raise this (but, possibly, not block approval?). If not so, > forget what I said -I'm no guru in autofoo ;-) > Not really. You an tell which version of autoconf was used to create the configure script and which version of automake was used to create the Makefile.in's just by looking at the comments at the top of the generated files. For instance, from configure:: # Generated by GNU Autoconf 2.61 for giflib 4.1.6. and from Makefile.in:: # Makefile.in generated by automake 1.10 from Makefile.am. However, this only tells you which versions of autoconf and automake were used to create these files. It doesn't tell you which versions could possibly have been used. Despite incompatibilities, some packages will generate correct Makefiles whether you use automake-1.4 or automake-1.9. Of course, if you know which constructs cause problems between versions of autoconf/automake you can look at the source of the configure.ac and Makefile.ams to determine which require older versions... but that's the same as requiring all reviewers to know which constructs in C are no longer supported by gcc-4.3... with one major difference: we compile the packages with gcc so many of the problematic constructs are caught by the compiler. By and large we do not "compile" the configure.ac and Makefile.am's with autoconf and automake so we don't catch these problems via the toolchain. > BTW... Given your statement: > > > The packager should not have to use the autotools normally. > > I "never" *cough* the two packages that I'm upstream for *cough* ship > any autofoo output files, only autofoo input files; it's excluded from > the source tree and excluded in tarballs... Should I reconsider this? Is > it gonna give trouble at some point? > Yes! It's quite common to exclude from the source tree (in the VCS). This is the theory that only source files go in the VCS and they are regenerated from there. This is fine. However, autotools were designed to not be needed by the users of a package. You, the upstream developer use autotools to create a configure script (and Makefile.ins) that gets included in your release tarball. The user (or distro packager in the majority of cases these days) runs the configure script (which is a bourne script) to configure the program for their system and generate proper Makefiles. This way, if you've written your configure.ac and Makefile.ams correctly the user's don't need to have the autotools installed on their system at all. If you're using automake to create your tarballs, there's a great make target: make dist (also make distcheck which will also run any unittests you have configured) that can help you create tarballs that have configure and Makefile.in created and ready for your user's to consume. -Toshio From aph at redhat.com Tue May 6 16:08:09 2008 From: aph at redhat.com (Andrew Haley) Date: Tue, 06 May 2008 17:08:09 +0100 Subject: APIC and Fedora 9 pre on AMD 64 Message-ID: <48208269.6010902@redhat.com> Fedora 9pre i686 won't boot without noapic. This is an ASUS M2N with AMD Athlon(tm) 64 X2 Dual Core Processor 4800+. x86_64 kernel works without noapic; it's only the i686 that needs it. So, does this sound familiar? BIOS bug, perhaps? Andrew. From a.badger at gmail.com Tue May 6 16:12:29 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 06 May 2008 09:12:29 -0700 Subject: Maintainer Responsibility Policy In-Reply-To: <1210089261.2961.3.camel@kennedy> References: <1210035695.6297.25.camel@kennedy> <482056BE.90100@n-dimensional.de> <48206A93.7020807@gmail.com> <1210089261.2961.3.camel@kennedy> Message-ID: <4820836D.7070008@gmail.com> Brian Pepple wrote: > On Tue, 2008-05-06 at 07:26 -0700, Toshio Kuratomi wrote: > >> Brian, we probably want to list the ways to deal with bug reports in the >> policy as many maintainers don't realize how many options there are for >> getting help fixing a bug. > > Here's what I've got right now (from Kevin's suggestion) in the section > regarding bugs: > > "If you find yourself unable to handle the load of bugs from your > package(s), please ask for assistance on the fedora-devel and/or > fedora-test lists. Teaching triagers about how to triage your bugs or > getting help from other maintainers can not only reduce your load, but > improve Fedora. Consider reaching out for some (more) co-maintainers to > assist as well." > Yeah. I think it's worthwhile to mention something like this: "Even bugs that you aren't capable of fixing yourself because they deal with intricacies of the source code that you don't have the knowledge to fix deserve a few moments of your time. You can report the bug upstream for the user, ask for help from more code-oriented people on fedora-devel, or check whether other distros have patches for the problem. Always be sure to post to the bug report what you have done so that the reporter has a proper expectation of whether you're working on a fix or if it's something that has to wait on upstream action." -Toshio From mike at miketc.com Tue May 6 16:14:32 2008 From: mike at miketc.com (Mike Chambers) Date: Tue, 06 May 2008 11:14:32 -0500 Subject: Flash on rawhide In-Reply-To: <1210089280.594.3.camel@metroid.rdu.redhat.com> References: <1210086745.2716.6.camel@scrappy.miketc.com> <20080506152222.GA21258@nostromo.devel.redhat.com> <1210087782.2716.8.camel@scrappy.miketc.com> <1210089280.594.3.camel@metroid.rdu.redhat.com> Message-ID: <1210090472.2716.11.camel@scrappy.miketc.com> On Tue, 2008-05-06 at 11:54 -0400, Will Woods wrote: > On Tue, 2008-05-06 at 10:29 -0500, Mike Chambers wrote: > > On Tue, 2008-05-06 at 11:22 -0400, Bill Nottingham wrote: > > > > > > You probably need libflashsupport.i386. > > > > That did the trick, thanks notting. Hrm, should that be installed by > > default by chance? Otherwise, think adobe needs to require that package > > I would think? > > You'd think that, but they refuse. And you can't currently require an > i386 package on an x86_64 system. It's a bit of a pickle. You would be correct I guess. Hrm, wonder if release notes should have info on that or worth it? Anywho, probably won't forget to install that again since I had the problem. -- Mike Chambers Fedora Project - Ambassador, Bug Zapper, Tester, User, etc.. mikec302 at fedoraproject.org From tibbs at math.uh.edu Tue May 6 16:15:23 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 06 May 2008 11:15:23 -0500 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <482081AB.4020804@gmail.com> References: <1209999548.32107.11.camel@kennedy> <481F2986.8010509@redhat.com> <1210002669.26792.65.camel@beck.corsepiu.local> <481FD064.6050307@ncsu.edu> <1210045081.4658.7.camel@localhost.localdomain> <481FD3D5.5070206@ncsu.edu> <1210071473.29415.128.camel@localhost.localdomain> <48203FF0.70205@kanarip.com> <48206323.9060300@gmail.com> <48207847.70308@kanarip.com> <482081AB.4020804@gmail.com> Message-ID: >>>>> "TK" == Toshio Kuratomi writes: TK> Despite incompatibilities, some packages will generate correct TK> Makefiles whether you use automake-1.4 or automake-1.9. I guess the real question, then, is how to tell that the shiny new automake version has produced an incorrect makefile. Are the failures obvious, or do you build it and hope that it doesn't fail silently later? - J< From bpepple at fedoraproject.org Tue May 6 16:25:17 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Tue, 06 May 2008 12:25:17 -0400 Subject: Maintainer Responsibility Policy In-Reply-To: <4820836D.7070008@gmail.com> References: <1210035695.6297.25.camel@kennedy> <482056BE.90100@n-dimensional.de> <48206A93.7020807@gmail.com> <1210089261.2961.3.camel@kennedy> <4820836D.7070008@gmail.com> Message-ID: <1210091117.2961.4.camel@kennedy> On Tue, 2008-05-06 at 09:12 -0700, Toshio Kuratomi wrote: > Yeah. I think it's worthwhile to mention something like this: > > "Even bugs that you aren't capable of fixing yourself because they deal > with intricacies of the source code that you don't have the knowledge to > fix deserve a few moments of your time. You can report the bug upstream > for the user, ask for help from more code-oriented people on > fedora-devel, or check whether other distros have patches for the > problem. Always be sure to post to the bug report what you have done so > that the reporter has a proper expectation of whether you're working on > a fix or if it's something that has to wait on upstream action." Added. Thanks for the suggestion, Toshio. Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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: 197 bytes Desc: This is a digitally signed message part URL: From mzerqung at 0pointer.de Tue May 6 16:44:48 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 6 May 2008 18:44:48 +0200 Subject: New system-config-acpid In-Reply-To: <48207BC5.3060105@redhat.com> References: <48207BC5.3060105@redhat.com> Message-ID: <20080506164446.GA14833@tango.0pointer.de> On Tue, 06.05.08 17:39, Zdenek Prikryl (zprikryl at redhat.com) wrote: > Hello, > the new system config tool was born. This time it is the tool which tries to > make a configuration of acpid easier. So, by this tool you can catch acpi events > or acpi hotkeys events and then you can assign actions to them. Uh? Actually the plan is to pass all ACPI key events through the Linux input system, like any other keypresses, so that they can handled like any other keypresses. If you look closely at /proc/bus/input/devices you'll notice that this actually is alredy case. I am sorry, but what you are suggesting is, uh, kind of out-of-date. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From greno at verizon.net Tue May 6 16:50:56 2008 From: greno at verizon.net (Gerry Reno) Date: Tue, 06 May 2008 12:50:56 -0400 Subject: F9 nfs, rpcbind, NetworkManager In-Reply-To: <1210084845.2716.0.camel@scrappy.miketc.com> References: <481F4BEF.8030004@verizon.net> <481F5041.4050005@verizon.net> <20080505182626.GA14432@nostromo.devel.redhat.com> <481F5B00.6030707@verizon.net> <20080505194202.GA5506@nostromo.devel.redhat.com> <481F66C2.90508@verizon.net> <20080505200129.GC5506@nostromo.devel.redhat.com> <481F685B.9010207@verizon.net> <20080505200932.GD5506@nostromo.devel.redhat.com> <481F6A7B.2070203@verizon.net> <20080505201657.GA10128@nostromo.devel.redhat.com> <481F7387.4050104@verizon.net> <481F778E.4040209@verizon.net> <481F7914.1040000@verizon.net> <481F7BE5.8080502@verizon.net> <481F9537.5000607@verizon.net> <40FD5026-FD1A-4152-9877-17AC2B411968@redhat.com> <1210084845.2716.0.camel@scrappy.miketc.com> Message-ID: <48208C70.7040003@verizon.net> Mike Chambers wrote: > On Tue, 2008-05-06 at 09:44 -0400, Will Woods wrote: > >> On May 5, 2008, at 7:16 PM, Gerry Reno wrote: >> >> >>> I finally got the priorities on NetworkManager to reset to 27 73. >>> So I reboot and I finally have nfs mounts and network at login. But >>> now the shutdown hangs. It throws you out to the black 'login:' >>> prompt screen and then it hangs there forever. >>> >> Does it? Hit Alt-F7 - the shutdown messages are on VT7. >> > > I see the same thing. It hangs on "shutting down quotas" and you have > to hit the power button to get it to shut off or reboot. I believe in > another email and/or thread this problem was also brought up. > > I just verified this looking at the shutdown messages in alt-f7. It goes through the shutdown sequence just fine until it hits 'Turning off quotas' and then it just hangs there. I left it for an hour and it was still hung. Regards, Gerry From mclasen at redhat.com Tue May 6 16:56:47 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 06 May 2008 12:56:47 -0400 Subject: Localisation needs to be improved In-Reply-To: <4820307D.3070704@kanarip.com> References: <1209860284.3433.7.camel@localhost.localdomain> <1209861510.12250.0.camel@localhost.localdomain> <1209862787.12250.4.camel@localhost.localdomain> <481D1CE7.1060807@kanarip.com> <1209870995.12250.16.camel@localhost.localdomain> <1209921645.2942.8.camel@sb-home> <481E0FC0.9080909@kanarip.com> <48201761.9000505@redhat.com> <4820307D.3070704@kanarip.com> Message-ID: <1210093007.8680.45.camel@localhost.localdomain> On Tue, 2008-05-06 at 12:18 +0200, Jeroen van Meeuwen wrote: > Jens Petersen wrote: > > Jeroen van Meeuwen ?????????????????: > >> Let's make this into a Fedora 10 Proposed Feature: > >> > >> - an interface for system administrators to set the default language, > >> like s-c-language does now, but extend it to tweak `locale`. > >> > >> - an interface for users to tweak they're own little private `locale`. > > > > Sounds like a good idea, I agree. > > > > *doing* > > http://fedoraproject.org/wiki/Features/LocalePreferences > > Enlist and add your comments, ideas, proposals and changes! > I started doing so, but I think I'd rather send my comments here, since a discussion is easier via mail. 1. '[...] will end up in all LC_* environment variables being set' - I don't quite follow here. env | grep LC_ comes up empty for me, only LANG is sent. Who is setting all the LC_ variables for you ? 2. 'Users should be able to adjust their LC_* preferences [...]' is far to vague imo. What users can be expected to set, reasonably, is their language and location. Anything beyond that, like picking a default paper size or time format, seems to be much to specialized for a general purpose capplet, and is much better done where it is needed (ie paper size in the print dialog, time format in the clock). 3. Note that we are aiming more or less at obsoleting s-c-date with the intlclock work. 4. There is some existing, unfinished code in gnome-control-center for a 'Locale' capplet, see http://svn.gnome.org/viewvc/gnome-control-center/trunk/capplets/localization/ Matthias From ivazqueznet at gmail.com Tue May 6 16:59:19 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Tue, 06 May 2008 12:59:19 -0400 Subject: Localisation needs to be improved In-Reply-To: <4820177D.3000106@redhat.com> References: <1209860284.3433.7.camel@localhost.localdomain> <1209861510.12250.0.camel@localhost.localdomain> <1209862787.12250.4.camel@localhost.localdomain> <4820177D.3000106@redhat.com> Message-ID: <1210093159.28402.40.camel@ignacio.lan> On Tue, 2008-05-06 at 18:31 +1000, Jens Petersen wrote: > Hmm, if I run "LANG=en_AU.UTF-8 gedit" and look at preferences I see > "Fonts and Colors" not "Fonts and Colours" (like for en_GB)? gedit doesn't have l10n for en_AU. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From greno at verizon.net Tue May 6 16:56:42 2008 From: greno at verizon.net (Gerry Reno) Date: Tue, 06 May 2008 12:56:42 -0400 Subject: ext3 problem - help! In-Reply-To: <1210088822.12045.6.camel@T7.Linux> References: <1210088822.12045.6.camel@T7.Linux> Message-ID: <48208DCA.5050405@verizon.net> Paul wrote: > Hi, > > When I booted up my PC this morning, it came up with an ext3 problem. It > first made the drive ext2, repaired the drive as journal system and then > set it to be ext3. > > Only problem is that the files on the drive have vanished. > > Is there any way to get them back or should I consign the problem to the > big question mark in the sky, shrug my shoulders and walk... > > TTFN > > Paul > unmount filesystem run e2fsck or boot rescue and run e2fsck check log for smart messages (failing drive?) Regards, Gerry From sgrubb at redhat.com Tue May 6 17:08:24 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Tue, 6 May 2008 13:08:24 -0400 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <48207309.3040403@redhat.com> References: <1209999548.32107.11.camel@kennedy> <481FD3D5.5070206@ncsu.edu> <48207309.3040403@redhat.com> Message-ID: <200805061308.24635.sgrubb@redhat.com> On Tuesday 06 May 2008 11:02:33 Christopher Aillon wrote: > he path to removing autoconf213 lies in someone patching upstream Firefox > (along with whatever other packages still uses autoconf213) to use newer > autotools and then waiting several Fedora release cycles, because this > change is almost certainly not going to happen ever in Firefox 3. ?Get it > changed for Firefox 4 and when that rolls around in F13??, we can talk about > dropping it. I agree with this. Maybe we should have a project in F10 that does the migration work so that a future Fedora can remove the old packages. About 4 years ago, I noticed a lot of redundancy and took it upon myself to migrate packages to newer tools. I was able to move all of the core packages, in about a day, off of old autoconf and automake to the current releases. I also took the liberty of moving things to bison as there was no need for byacc. I never ran into a package that could not be ported. I did run into packages that took some effort. :) -Steve From mike at miketc.com Tue May 6 17:42:05 2008 From: mike at miketc.com (Mike Chambers) Date: Tue, 06 May 2008 12:42:05 -0500 Subject: F9 nfs, rpcbind, NetworkManager In-Reply-To: <48208C70.7040003@verizon.net> References: <481F4BEF.8030004@verizon.net> <481F5041.4050005@verizon.net> <20080505182626.GA14432@nostromo.devel.redhat.com> <481F5B00.6030707@verizon.net> <20080505194202.GA5506@nostromo.devel.redhat.com> <481F66C2.90508@verizon.net> <20080505200129.GC5506@nostromo.devel.redhat.com> <481F685B.9010207@verizon.net> <20080505200932.GD5506@nostromo.devel.redhat.com> <481F6A7B.2070203@verizon.net> <20080505201657.GA10128@nostromo.devel.redhat.com> <481F7387.4050104@verizon.net> <481F778E.4040209@verizon.net> <481F7914.1040000@verizon.net> <481F7BE5.8080502@verizon.net> <481F9537.5000607@verizon.net> <40FD5026-FD1A-4152-9877-17AC2B411968@redhat.com> <1210084845.2716.0.camel@scrappy.miketc.com> <48208C70.7040003@verizon.net> Message-ID: <1210095725.2716.14.camel@scrappy.miketc.com> On Tue, 2008-05-06 at 12:50 -0400, Gerry Reno wrote: > I just verified this looking at the shutdown messages in alt-f7. It > goes through the shutdown sequence just fine until it hits 'Turning off > quotas' and then it just hangs there. I left it for an hour and it was > still hung. I'd had filed a bug, but truthfully, not sure what against. NM may have something to do with it, but it could just be some type of network issue at that point of shutdown, but don't know what. Wondering why no one else has seen it, even developers of NM, during testing or why they don't run into it, and we do? -- Mike Chambers Fedora Project - Ambassador, Bug Zapper, Tester, User, etc.. mikec302 at fedoraproject.org From alan at clueserver.org Tue May 6 17:49:39 2008 From: alan at clueserver.org (Alan) Date: Tue, 6 May 2008 10:49:39 -0700 (PDT) Subject: Flash on rawhide In-Reply-To: <1210086745.2716.6.camel@scrappy.miketc.com> References: <1210086745.2716.6.camel@scrappy.miketc.com> Message-ID: <54872.75.164.221.130.1210096179.squirrel@clueserver.org> > Installed rawhide this morning (err, very late last night and configured > it this morning), and it seems flash OR pulseaudio isn't working. I can > hear normal system sounds just fine. But if I go to a flash site, such > as http://espn.go.com and play the sportscenter video, it plays fine but > can't hear anything. > > While that is going on, I called up the Menu/Sound & Video/PulseAudio > Volume Control menu and it shows no streaming. But you keep seeing a > flashed menu that keeps coming up, but it seems transparent? Probably > doesn't sound right but if someone would try it, maybe they will see the > same thing. > > I will say before I did the install, that it had been working fine on a > previous install from days/weeks ago and had been doing just updates. > So if there is something not installed that needs to be, I cant' think > of what it is. The flash-plugin came straight from adobe via yum. > > Any ideas? Check your volume control. Flash uses PCM. Check if that is muted. From greno at verizon.net Tue May 6 18:09:34 2008 From: greno at verizon.net (Gerry Reno) Date: Tue, 06 May 2008 14:09:34 -0400 Subject: F9 nfs, rpcbind, NetworkManager In-Reply-To: <1210095725.2716.14.camel@scrappy.miketc.com> References: <481F4BEF.8030004@verizon.net> <481F5041.4050005@verizon.net> <20080505182626.GA14432@nostromo.devel.redhat.com> <481F5B00.6030707@verizon.net> <20080505194202.GA5506@nostromo.devel.redhat.com> <481F66C2.90508@verizon.net> <20080505200129.GC5506@nostromo.devel.redhat.com> <481F685B.9010207@verizon.net> <20080505200932.GD5506@nostromo.devel.redhat.com> <481F6A7B.2070203@verizon.net> <20080505201657.GA10128@nostromo.devel.redhat.com> <481F7387.4050104@verizon.net> <481F778E.4040209@verizon.net> <481F7914.1040000@verizon.net> <481F7BE5.8080502@verizon.net> <481F9537.5000607@verizon.net> <40FD5026-FD1A-4152-9877-17AC2B411968@redhat.com> <1210084845.2716.0.camel@scrappy.miketc.com> <48208C70.7040003@verizon.net> <1210095725.2716.14.camel@scrappy.miketc.com> Message-ID: <48209EDE.5010100@verizon.net> Mike Chambers wrote: > On Tue, 2008-05-06 at 12:50 -0400, Gerry Reno wrote: > > >> I just verified this looking at the shutdown messages in alt-f7. It >> goes through the shutdown sequence just fine until it hits 'Turning off >> quotas' and then it just hangs there. I left it for an hour and it was >> still hung. >> > > I'd had filed a bug, but truthfully, not sure what against. NM may have > something to do with it, but it could just be some type of network issue > at that point of shutdown, but don't know what. > > Wondering why no one else has seen it, even developers of NM, during > testing or why they don't run into it, and we do? > > What I noticed when my nfs mounts would not work from rc.local was that NM was set at S99 which means it started almost last. When I resetpriorities on it so that it became S27 as shown in its init file then the shutdown hang occurred. Regards, Gerry From caillon at redhat.com Tue May 6 18:29:10 2008 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 06 May 2008 14:29:10 -0400 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <200805061308.24635.sgrubb@redhat.com> References: <1209999548.32107.11.camel@kennedy> <481FD3D5.5070206@ncsu.edu> <48207309.3040403@redhat.com> <200805061308.24635.sgrubb@redhat.com> Message-ID: <4820A376.70104@redhat.com> On 05/06/2008 01:08 PM, Steve Grubb wrote: > On Tuesday 06 May 2008 11:02:33 Christopher Aillon wrote: >> he path to removing autoconf213 lies in someone patching upstream Firefox >> (along with whatever other packages still uses autoconf213) to use newer >> autotools and then waiting several Fedora release cycles, because this >> change is almost certainly not going to happen ever in Firefox 3. Get it >> changed for Firefox 4 and when that rolls around in F13??, we can talk about >> dropping it. > > I agree with this. Maybe we should have a project in F10 that does the > migration work so that a future Fedora can remove the old packages. > > About 4 years ago, I noticed a lot of redundancy and took it upon myself to > migrate packages to newer tools. I was able to move all of the core packages, > in about a day, off of old autoconf and automake to the current releases. I > also took the liberty of moving things to bison as there was no need for > byacc. > > I never ran into a package that could not be ported. I did run into packages > that took some effort. :) Firefox will probably take some effort :-) If someone with the knowledge and ambition wants to do the work, I will help as best I can. The bug once again is https://bugzilla.mozilla.org/show_bug.cgi?id=104642 From bruno at wolff.to Tue May 6 18:50:52 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Tue, 6 May 2008 13:50:52 -0500 Subject: ext3 problem - help! In-Reply-To: <1210088822.12045.6.camel@T7.Linux> References: <1210088822.12045.6.camel@T7.Linux> Message-ID: <20080506185052.GA30362@wolff.to> On Tue, May 06, 2008 at 16:47:02 +0100, Paul wrote: > > Only problem is that the files on the drive have vanished. > > Is there any way to get them back or should I consign the problem to the > big question mark in the sky, shrug my shoulders and walk... You might take a look at the etx3grep project. I don't know if it can get back files under these circumstances, but its probably the best ext3 recovery program available. From wjhns174 at hardakers.net Tue May 6 19:15:25 2008 From: wjhns174 at hardakers.net (Wes Hardaker) Date: Tue, 06 May 2008 12:15:25 -0700 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <200805061856.50029.ville.skytta@iki.fi> (Ville Skytt's message of "Tue, 6 May 2008 18:56:49 +0300") References: <1209999548.32107.11.camel@kennedy> <870180fe0805052050pcac64e2x6377a65a59dce11c@mail.gmail.com> <200805061856.50029.ville.skytta@iki.fi> Message-ID: >>>>> On Tue, 6 May 2008 18:56:49 +0300, Ville Skytt? said: VS> Not really; only those who change things that require autoconf to be VS> re-run. The generated "configure" for 21.4 is not only in the dist VS> tarballs, but also in hg. Yep. My only point was that developers need to be able to call older autoconfs to work on a package. (the number of times I've had to hack configure.in in order to get a package to build on a modern system is more than the number of fingers I own) -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett From joe at devzero.dk Tue May 6 19:26:17 2008 From: joe at devzero.dk (Jens Falsmar Oechsler) Date: Tue, 6 May 2008 21:26:17 +0200 Subject: APIC and Fedora 9 pre on AMD 64 In-Reply-To: References: <48208269.6010902@redhat.com> Message-ID: <20080506212617.1ddfb646@devzero0.devzero.loc> > > ________________________________________ > From: fedora-devel-list-bounces at redhat.com > [fedora-devel-list-bounces at redhat.com] On Behalf Of Andrew Haley > [aph at redhat.com] Sent: 06 May 2008 18:08 To: Development discussions > related to Fedora Subject: APIC and Fedora 9 pre on AMD 64 > > Fedora 9pre i686 won't boot without noapic. > > This is an ASUS M2N with AMD Athlon(tm) 64 X2 Dual Core Processor > 4800+. x86_64 kernel works without noapic; it's only the i686 that > needs it. > > So, does this sound familiar? BIOS bug, perhaps? > > Andrew. > > -- My ASUS M2NPV had APIC troubles as well. A BIOS update solved the booting problems for me. From nicolas.mailhot at laposte.net Tue May 6 19:27:12 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 06 May 2008 21:27:12 +0200 Subject: Maintainer Responsibility Policy In-Reply-To: <1210040534.14415.4.camel@kennedy> References: <1210035695.6297.25.camel@kennedy> <20080505201036.64d44d6c@ohm.scrye.com> <1210040534.14415.4.camel@kennedy> Message-ID: <1210102032.29476.15.camel@rousalka.okg> Le lundi 05 mai 2008 ? 22:22 -0400, Brian Pepple a ?crit : > On Mon, 2008-05-05 at 20:10 -0600, Kevin Fenzi wrote: > > On Mon, 05 May 2008 21:01:35 -0400 > > bpepple at fedoraproject.org (Brian Pepple) wrote: > > > > === Maintain stability for users === > > > * Package maintainers should limit updates within a single > > > Fedora release to those which do not require special user action. Many > > > users update automatically, and if their applications stop > > > working from no action of their own then they will be upset. > > > This goes doubly for services which may break overnight. > > > > I would add additionally: > > > > "Maintainers should not push every single upstream update to all > > branches. Examine the changes in each upstream release and ask if the > > update is worth download and update time for many users. For upstreams > > that update very often with many small updates, consider waiting and > > updated only when the amount of changes is worth updating. > > Added. ***Except for fedora devel*** Maintainers that only update devel a few days before the freeze and ignore intermediary versions (where problems in the package or in its interaction with others could be identified and reported upstream) are as time-wasting as maintainers who push everything everywhere. Fedora devel has a limited number of users (except just before a release). That does not mean ignoring it is ok for a maintainer. -- 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 ivazqueznet at gmail.com Tue May 6 19:47:00 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Tue, 06 May 2008 15:47:00 -0400 Subject: augeas - reading/modifying/writing system configuration files In-Reply-To: <20080505130810.GA26393@evileye.atkac.englab.brq.redhat.com> References: <20080505130810.GA26393@evileye.atkac.englab.brq.redhat.com> Message-ID: <1210103220.28402.46.camel@ignacio.lan> On Mon, 2008-05-05 at 15:08 +0200, Adam Tkac wrote: > On Mon, May 05, 2008 at 02:15:02PM +0200, Harald Hoyer wrote: > > _What should use augeas?_ > > > > All system-config-* tools should use augeas, as well as every tool > > modifying system configuration files like e.g. NetworkManager. > > If we are talking about modifying system-config-* packages I think it > is time to think if system-config packages are good configuration > utilities. I think not. > > In my opinion we need one tool which will load plugins and > configuration files should be modified through them. Every package which > has configuration file will have simple plugin for one system wide > tool and package maintainer should also maintain plugin for his > package (because he knows about latest options etc). > > I know this will need hard work but in the end things will be far more > better. +1 One of the good things to come out of MS is MSC (even if some of the consoles themselves are awful). -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From orion at cora.nwra.com Tue May 6 20:17:08 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 06 May 2008 14:17:08 -0600 Subject: Removing hdf5 from ppc64 Message-ID: <4820BCC4.2040103@cora.nwra.com> The hdf5 1.8.0 does not build on ppc64 (or it builds, but it fails its tests). I've put in an ExcludeArch: ppc64 for now and filed a bug: https://bugzilla.redhat.com/show_bug.cgi?id=445423 I really don't have any more time to work on this at the moment. If you do and you care about this, all help is appreciated. Packages (directly) affected: gdal LabPlot octave paraview R-hdf5 Downstream: gdal -> grass, mapserver, qgis octave -> octave-forge, plplot plplot -> gdl, perl-PDL -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From dr.diesel at gmail.com Tue May 6 21:55:38 2008 From: dr.diesel at gmail.com (Dr. Diesel) Date: Tue, 6 May 2008 17:55:38 -0400 Subject: Anyone else with hard freezes? Message-ID: <2a28d2ab0805061455l9afae56p8a86218d08bc4b92@mail.gmail.com> Currently running Fedora 9 Release to date. Doesn't happen very often, maybe once every 3-4 days. Twice I've caught it at idle with the screen saver (picture viewer) frozen and twice while browsing in Gnome. Not really noticing anything weird in the logs? -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org From alan at clueserver.org Tue May 6 22:21:54 2008 From: alan at clueserver.org (Alan) Date: Tue, 6 May 2008 15:21:54 -0700 (PDT) Subject: Anyone else with hard freezes? In-Reply-To: <2a28d2ab0805061455l9afae56p8a86218d08bc4b92@mail.gmail.com> References: <2a28d2ab0805061455l9afae56p8a86218d08bc4b92@mail.gmail.com> Message-ID: <34809.75.164.221.130.1210112514.squirrel@clueserver.org> > Currently running Fedora 9 Release to date. Doesn't happen very > often, maybe once every 3-4 days. Twice I've caught it at idle with > the screen saver (picture viewer) frozen and twice while browsing in > Gnome. > > Not really noticing anything weird in the logs? I have had this happen with Fedora 8 on my x86_64 machine. Nothing recorded in the logs. I have not had the time to debug it. What kind of motherboard, video card and processor? Maybe there is something in common with my system. From greno at verizon.net Tue May 6 22:24:54 2008 From: greno at verizon.net (Gerry Reno) Date: Tue, 06 May 2008 18:24:54 -0400 Subject: Anyone else with hard freezes? In-Reply-To: <2a28d2ab0805061455l9afae56p8a86218d08bc4b92@mail.gmail.com> References: <2a28d2ab0805061455l9afae56p8a86218d08bc4b92@mail.gmail.com> Message-ID: <4820DAB6.1030402@verizon.net> Dr. Diesel wrote: > Currently running Fedora 9 Release to date. Doesn't happen very > often, maybe once every 3-4 days. Twice I've caught it at idle with > the screen saver (picture viewer) frozen and twice while browsing in > Gnome. > > Not really noticing anything weird in the logs? > > Haven't had a freeze yet but I have seen a couple weird things with X. Twice now my cursor just went to either the upper right corner or the lower right corner. If you try to move it somewhere it just goes back to the corner in a jerky motion. Very strange. Regards, Gerry From airlied at redhat.com Tue May 6 22:25:48 2008 From: airlied at redhat.com (Dave Airlie) Date: Wed, 07 May 2008 08:25:48 +1000 Subject: Anyone else with hard freezes? In-Reply-To: <2a28d2ab0805061455l9afae56p8a86218d08bc4b92@mail.gmail.com> References: <2a28d2ab0805061455l9afae56p8a86218d08bc4b92@mail.gmail.com> Message-ID: <1210112748.6222.7.camel@optimus> On Tue, 2008-05-06 at 17:55 -0400, Dr. Diesel wrote: > Currently running Fedora 9 Release to date. Doesn't happen very > often, maybe once every 3-4 days. Twice I've caught it at idle with > the screen saver (picture viewer) frozen and twice while browsing in > Gnome. > > Not really noticing anything weird in the logs? AMD 64-bit + ATI AGP card? please open a bug and attach some lspci and /var/log/Xorg.0.log stuff as my mind reading abilities suck this morning. Dave. From dr.diesel at gmail.com Tue May 6 22:26:57 2008 From: dr.diesel at gmail.com (Dr. Diesel) Date: Tue, 6 May 2008 18:26:57 -0400 Subject: Anyone else with hard freezes? In-Reply-To: <34809.75.164.221.130.1210112514.squirrel@clueserver.org> References: <2a28d2ab0805061455l9afae56p8a86218d08bc4b92@mail.gmail.com> <34809.75.164.221.130.1210112514.squirrel@clueserver.org> Message-ID: <2a28d2ab0805061526o55c58b80y5fceed9375555ffa@mail.gmail.com> Abit 35 Pro , Intel E8400 etc. Attached is lscpi -vvv On Tue, May 6, 2008 at 6:21 PM, Alan wrote: > > Currently running Fedora 9 Release to date. Doesn't happen very > > often, maybe once every 3-4 days. Twice I've caught it at idle with > > the screen saver (picture viewer) frozen and twice while browsing in > > Gnome. > > > > Not really noticing anything weird in the logs? > > I have had this happen with Fedora 8 on my x86_64 machine. Nothing > recorded in the logs. I have not had the time to debug it. > > What kind of motherboard, video card and processor? Maybe there is > something in common with my system. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org -------------- next part -------------- A non-text attachment was scrubbed... Name: hardware.log Type: application/octet-stream Size: 24870 bytes Desc: not available URL: From airlied at redhat.com Tue May 6 22:28:41 2008 From: airlied at redhat.com (Dave Airlie) Date: Wed, 07 May 2008 08:28:41 +1000 Subject: Anyone else with hard freezes? In-Reply-To: <2a28d2ab0805061526o55c58b80y5fceed9375555ffa@mail.gmail.com> References: <2a28d2ab0805061455l9afae56p8a86218d08bc4b92@mail.gmail.com> <34809.75.164.221.130.1210112514.squirrel@clueserver.org> <2a28d2ab0805061526o55c58b80y5fceed9375555ffa@mail.gmail.com> Message-ID: <1210112921.6222.9.camel@optimus> On Tue, 2008-05-06 at 18:26 -0400, Dr. Diesel wrote: > Abit 35 Pro , Intel E8400 etc. > > Attached is lscpi -vvv Oh wierd an nvidia card... are you running the binary driver? or just the normal nv one? Dave. > > > > On Tue, May 6, 2008 at 6:21 PM, Alan wrote: > > > Currently running Fedora 9 Release to date. Doesn't happen very > > > often, maybe once every 3-4 days. Twice I've caught it at idle with > > > the screen saver (picture viewer) frozen and twice while browsing in > > > Gnome. > > > > > > Not really noticing anything weird in the logs? > > > > I have had this happen with Fedora 8 on my x86_64 machine. Nothing > > recorded in the logs. I have not had the time to debug it. > > > > What kind of motherboard, video card and processor? Maybe there is > > something in common with my system. > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From stlwrt at gmail.com Tue May 6 22:29:26 2008 From: stlwrt at gmail.com (Pavel Shevchuk) Date: Wed, 7 May 2008 01:29:26 +0300 Subject: Anyone else with hard freezes? In-Reply-To: <1210112748.6222.7.camel@optimus> References: <2a28d2ab0805061455l9afae56p8a86218d08bc4b92@mail.gmail.com> <1210112748.6222.7.camel@optimus> Message-ID: [stalwart at delta ~]$ uptime 01:27:18 up 19 days, 1:06, 14 users, load average: 0.32, 0.29, 0.26 [stalwart at delta ~]$ cat /etc/fedora-release Fedora release 9 (Sulphur) [stalwart at delta ~]$ uname -a Linux delta 2.6.25-0.218.rc8.git7.fc9.x86_64 #1 SMP Wed Apr 9 19:55:19 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux 19 days of web development, movies, music, web browsing, packaging, patching, hacking and what not. System is rock stable. CPU: Intel Core2Quad Q6600 Video: NVIDIA GeForce 8600GT, driver - nouveau On 5/7/08, Dave Airlie wrote: > On Tue, 2008-05-06 at 17:55 -0400, Dr. Diesel wrote: > > Currently running Fedora 9 Release to date. Doesn't happen very > > often, maybe once every 3-4 days. Twice I've caught it at idle with > > the screen saver (picture viewer) frozen and twice while browsing in > > Gnome. > > > > Not really noticing anything weird in the logs? > > > AMD 64-bit + ATI AGP card? > > please open a bug and attach some lspci and /var/log/Xorg.0.log stuff as > my mind reading abilities suck this morning. > > > > Dave. > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- http://scwlab.com From dr.diesel at gmail.com Tue May 6 22:30:22 2008 From: dr.diesel at gmail.com (Dr. Diesel) Date: Tue, 6 May 2008 18:30:22 -0400 Subject: Anyone else with hard freezes? In-Reply-To: <1210112921.6222.9.camel@optimus> References: <2a28d2ab0805061455l9afae56p8a86218d08bc4b92@mail.gmail.com> <34809.75.164.221.130.1210112514.squirrel@clueserver.org> <2a28d2ab0805061526o55c58b80y5fceed9375555ffa@mail.gmail.com> <1210112921.6222.9.camel@optimus> Message-ID: <2a28d2ab0805061530j3a8aa79ehb51d96afedaad644@mail.gmail.com> Just nv since Nvidia's drivers don't yet support xorg 1.5. The only kernel module I have loaded is VirtualBox 1.6's. Filing a bug now.. On Tue, May 6, 2008 at 6:28 PM, Dave Airlie wrote: > On Tue, 2008-05-06 at 18:26 -0400, Dr. Diesel wrote: > > Abit 35 Pro , Intel E8400 etc. > > > > Attached is lscpi -vvv > > Oh wierd an nvidia card... are you running the binary driver? or just > the normal nv one? > > Dave. > > > > > > > > > > > On Tue, May 6, 2008 at 6:21 PM, Alan wrote: > > > > Currently running Fedora 9 Release to date. Doesn't happen very > > > > often, maybe once every 3-4 days. Twice I've caught it at idle with > > > > the screen saver (picture viewer) frozen and twice while browsing in > > > > Gnome. > > > > > > > > Not really noticing anything weird in the logs? > > > > > > I have had this happen with Fedora 8 on my x86_64 machine. Nothing > > > recorded in the logs. I have not had the time to debug it. > > > > > > What kind of motherboard, video card and processor? Maybe there is > > > something in common with my system. > > > > > > -- > > > fedora-devel-list mailing list > > > fedora-devel-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > > > > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org From stlwrt at gmail.com Tue May 6 22:32:17 2008 From: stlwrt at gmail.com (Pavel Shevchuk) Date: Wed, 7 May 2008 01:32:17 +0300 Subject: Anyone else with hard freezes? In-Reply-To: References: <2a28d2ab0805061455l9afae56p8a86218d08bc4b92@mail.gmail.com> <1210112748.6222.7.camel@optimus> Message-ID: Ah yes, my mobo is P35. Dr., is yours too? On 5/7/08, Pavel Shevchuk wrote: > [stalwart at delta ~]$ uptime > 01:27:18 up 19 days, 1:06, 14 users, load average: 0.32, 0.29, 0.26 > [stalwart at delta ~]$ cat /etc/fedora-release > Fedora release 9 (Sulphur) > [stalwart at delta ~]$ uname -a > Linux delta 2.6.25-0.218.rc8.git7.fc9.x86_64 #1 SMP Wed Apr 9 19:55:19 > EDT 2008 x86_64 x86_64 x86_64 GNU/Linux > > 19 days of web development, movies, music, web browsing, packaging, > patching, hacking and what not. System is rock stable. > > CPU: Intel Core2Quad Q6600 > Video: NVIDIA GeForce 8600GT, driver - nouveau > > > On 5/7/08, Dave Airlie wrote: > > On Tue, 2008-05-06 at 17:55 -0400, Dr. Diesel wrote: > > > Currently running Fedora 9 Release to date. Doesn't happen very > > > often, maybe once every 3-4 days. Twice I've caught it at idle with > > > the screen saver (picture viewer) frozen and twice while browsing in > > > Gnome. > > > > > > Not really noticing anything weird in the logs? > > > > > > AMD 64-bit + ATI AGP card? > > > > please open a bug and attach some lspci and /var/log/Xorg.0.log stuff as > > my mind reading abilities suck this morning. > > > > > > > > Dave. > > > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > > -- > http://scwlab.com > -- http://scwlab.com From stlwrt at gmail.com Tue May 6 22:34:50 2008 From: stlwrt at gmail.com (Pavel Shevchuk) Date: Wed, 7 May 2008 01:34:50 +0300 Subject: Anyone else with hard freezes? In-Reply-To: References: <2a28d2ab0805061455l9afae56p8a86218d08bc4b92@mail.gmail.com> <1210112748.6222.7.camel@optimus> Message-ID: I also have VBox 1.6 installed for few days already (didn't reboot since installation), run linux and windows in it, no problems at all On 5/7/08, Pavel Shevchuk wrote: > Ah yes, my mobo is P35. Dr., is yours too? > > > > On 5/7/08, Pavel Shevchuk wrote: > > [stalwart at delta ~]$ uptime > > 01:27:18 up 19 days, 1:06, 14 users, load average: 0.32, 0.29, 0.26 > > [stalwart at delta ~]$ cat /etc/fedora-release > > Fedora release 9 (Sulphur) > > [stalwart at delta ~]$ uname -a > > Linux delta 2.6.25-0.218.rc8.git7.fc9.x86_64 #1 SMP Wed Apr 9 19:55:19 > > EDT 2008 x86_64 x86_64 x86_64 GNU/Linux > > > > 19 days of web development, movies, music, web browsing, packaging, > > patching, hacking and what not. System is rock stable. > > > > CPU: Intel Core2Quad Q6600 > > Video: NVIDIA GeForce 8600GT, driver - nouveau > > > > > > On 5/7/08, Dave Airlie wrote: > > > On Tue, 2008-05-06 at 17:55 -0400, Dr. Diesel wrote: > > > > Currently running Fedora 9 Release to date. Doesn't happen very > > > > often, maybe once every 3-4 days. Twice I've caught it at idle with > > > > the screen saver (picture viewer) frozen and twice while browsing in > > > > Gnome. > > > > > > > > Not really noticing anything weird in the logs? > > > > > > > > > AMD 64-bit + ATI AGP card? > > > > > > please open a bug and attach some lspci and /var/log/Xorg.0.log stuff as > > > my mind reading abilities suck this morning. > > > > > > > > > > > > Dave. > > > > > > > > > -- > > > fedora-devel-list mailing list > > > fedora-devel-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > > > > > > > -- > > http://scwlab.com > > > > > > -- > http://scwlab.com > -- http://scwlab.com From dr.diesel at gmail.com Tue May 6 22:35:37 2008 From: dr.diesel at gmail.com (Dr. Diesel) Date: Tue, 6 May 2008 18:35:37 -0400 Subject: Anyone else with hard freezes? In-Reply-To: References: <2a28d2ab0805061455l9afae56p8a86218d08bc4b92@mail.gmail.com> <1210112748.6222.7.camel@optimus> Message-ID: <2a28d2ab0805061535n5b53eb4eo17ebd299cd038e0e@mail.gmail.com> Yea, Abit IP35 Pro, https://bugzilla.redhat.com/show_bug.cgi?id=445458 On Tue, May 6, 2008 at 6:32 PM, Pavel Shevchuk wrote: > Ah yes, my mobo is P35. Dr., is yours too? > > > > > On 5/7/08, Pavel Shevchuk wrote: > > [stalwart at delta ~]$ uptime > > 01:27:18 up 19 days, 1:06, 14 users, load average: 0.32, 0.29, 0.26 > > [stalwart at delta ~]$ cat /etc/fedora-release > > Fedora release 9 (Sulphur) > > [stalwart at delta ~]$ uname -a > > Linux delta 2.6.25-0.218.rc8.git7.fc9.x86_64 #1 SMP Wed Apr 9 19:55:19 > > EDT 2008 x86_64 x86_64 x86_64 GNU/Linux > > > > 19 days of web development, movies, music, web browsing, packaging, > > patching, hacking and what not. System is rock stable. > > > > CPU: Intel Core2Quad Q6600 > > Video: NVIDIA GeForce 8600GT, driver - nouveau > > > > > > On 5/7/08, Dave Airlie wrote: > > > On Tue, 2008-05-06 at 17:55 -0400, Dr. Diesel wrote: > > > > Currently running Fedora 9 Release to date. Doesn't happen very > > > > often, maybe once every 3-4 days. Twice I've caught it at idle with > > > > the screen saver (picture viewer) frozen and twice while browsing in > > > > Gnome. > > > > > > > > Not really noticing anything weird in the logs? > > > > > > > > > AMD 64-bit + ATI AGP card? > > > > > > please open a bug and attach some lspci and /var/log/Xorg.0.log stuff as > > > my mind reading abilities suck this morning. > > > > > > > > > > > > Dave. > > > > > > > > > -- From lmacken at redhat.com Tue May 6 22:42:47 2008 From: lmacken at redhat.com (Luke Macken) Date: Tue, 6 May 2008 18:42:47 -0400 Subject: Bodhi documentation for new packages In-Reply-To: <481F5F85.7080203@garden.org> References: <481F5F85.7080203@garden.org> Message-ID: <20080506224247.GA3372@x300> On Mon, May 05, 2008 at 03:27:01PM -0400, Aaron S. Hawley wrote: > [Please, Cc me replies, thanks.] > > The directions for joining Fedora as a package maintainer[1] are really > great. Unfortunately, they trail off at the end when it comes to important > tasks of making the package live using the Bodhi system, section "Request > updates to released Fedoras for your new package". I ran into this > roadblock last month, and it hasn't improved since. > > As a new maintainer, I know very little about the updates infrastructure of > Fedora, which I predict is assumed knowledge about using Bodhi. This is > probably unfair to new maintainers. Here's my proposal for what this > section should say. It is also what I did, so I'm sure it needs > correction, and let me know so I can get my new package (gnue-common) live. > Thanks for Fedora, /a Thanks for taking the time to give feedback and help improve our documentation. I completely agree that the updates/bodhi docs need some work. Come F9, I hope to have a lot of new bodhi features and changes to existing workflow deployed, so I'll be tweaking the documentation a lot then. > -- BEGIN -- > > The first field asks for the name of the "Package". This will feature a > name completion system, but is currently broken. It uses the tag used in > Fedora CVS and the Koji build system, e.g. > --.fc9. The build completion is no longer broken. It doesn't not query by tag (yet, at least), it simply offers all builds for the given package. > For new packages, choose "enhancement" as the "type" of update. Correct, for now. Spot and I discussed this yesterday and we thought it would probably be a good idea to add another type of update specifically for new packages. This would allow tools like PackageKit to say "Hey, check out the newest packages in Fedora that you could possibly install!" > Keep the "Request" as "testing". It's probably best to leave this up to the developer pushing the update. I originally made bodhi force packages to go through testing first, but many people complained and had their reasons for wanting pushing directly to stable. > There are no bugs that are related to any new package, so leave the "Bugs" > field blank. New packages could possibly add their Review Request bug to the update, which will have bodhi automatically close it when it gets pushed. > For new packages, add a copy of the package's description in the "Notes" > section so end users will know what it is.[2] This sounds fine. Cheers, luke From airlied at redhat.com Tue May 6 23:21:38 2008 From: airlied at redhat.com (Dave Airlie) Date: Wed, 07 May 2008 09:21:38 +1000 Subject: Anyone else with hard freezes? In-Reply-To: <2a28d2ab0805061530j3a8aa79ehb51d96afedaad644@mail.gmail.com> References: <2a28d2ab0805061455l9afae56p8a86218d08bc4b92@mail.gmail.com> <34809.75.164.221.130.1210112514.squirrel@clueserver.org> <2a28d2ab0805061526o55c58b80y5fceed9375555ffa@mail.gmail.com> <1210112921.6222.9.camel@optimus> <2a28d2ab0805061530j3a8aa79ehb51d96afedaad644@mail.gmail.com> Message-ID: <1210116098.6222.11.camel@optimus> On Tue, 2008-05-06 at 18:30 -0400, Dr. Diesel wrote: > Just nv since Nvidia's drivers don't yet support xorg 1.5. The only > kernel module I have loaded is VirtualBox 1.6's. > > Filing a bug now.. can you try without virtualbox? I've seen oops reports from it around the place. Dave. > > On Tue, May 6, 2008 at 6:28 PM, Dave Airlie wrote: > > On Tue, 2008-05-06 at 18:26 -0400, Dr. Diesel wrote: > > > Abit 35 Pro , Intel E8400 etc. > > > > > > Attached is lscpi -vvv > > > > Oh wierd an nvidia card... are you running the binary driver? or just > > the normal nv one? > > > > Dave. > > > > > > > > > > > > > > > > > > On Tue, May 6, 2008 at 6:21 PM, Alan wrote: > > > > > Currently running Fedora 9 Release to date. Doesn't happen very > > > > > often, maybe once every 3-4 days. Twice I've caught it at idle with > > > > > the screen saver (picture viewer) frozen and twice while browsing in > > > > > Gnome. > > > > > > > > > > Not really noticing anything weird in the logs? > > > > > > > > I have had this happen with Fedora 8 on my x86_64 machine. Nothing > > > > recorded in the logs. I have not had the time to debug it. > > > > > > > > What kind of motherboard, video card and processor? Maybe there is > > > > something in common with my system. > > > > > > > > -- > > > > fedora-devel-list mailing list > > > > fedora-devel-list at redhat.com > > > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > > > > > > > > > > > > -- > > > fedora-devel-list mailing list > > > fedora-devel-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > > -- > projecthuh.com > All of my bits are free, are yours? Fedoraproject.org > From dr.diesel at gmail.com Tue May 6 23:25:28 2008 From: dr.diesel at gmail.com (Dr. Diesel) Date: Tue, 6 May 2008 19:25:28 -0400 Subject: Anyone else with hard freezes? In-Reply-To: <1210116098.6222.11.camel@optimus> References: <2a28d2ab0805061455l9afae56p8a86218d08bc4b92@mail.gmail.com> <34809.75.164.221.130.1210112514.squirrel@clueserver.org> <2a28d2ab0805061526o55c58b80y5fceed9375555ffa@mail.gmail.com> <1210112921.6222.9.camel@optimus> <2a28d2ab0805061530j3a8aa79ehb51d96afedaad644@mail.gmail.com> <1210116098.6222.11.camel@optimus> Message-ID: <2a28d2ab0805061625l53999979ocbb0fd19bb775e13@mail.gmail.com> On Tue, May 6, 2008 at 7:21 PM, Dave Airlie wrote: > On Tue, 2008-05-06 at 18:30 -0400, Dr. Diesel wrote: > > Just nv since Nvidia's drivers don't yet support xorg 1.5. The only > > kernel module I have loaded is VirtualBox 1.6's. > > > > Filing a bug now.. > > can you try without virtualbox? > > I've seen oops reports from it around the place. > > > > Dave. > Yup, sure can, removed! From kanarip at kanarip.com Tue May 6 23:29:29 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 07 May 2008 01:29:29 +0200 Subject: Localisation needs to be improved In-Reply-To: <1210093007.8680.45.camel@localhost.localdomain> References: <1209860284.3433.7.camel@localhost.localdomain> <1209861510.12250.0.camel@localhost.localdomain> <1209862787.12250.4.camel@localhost.localdomain> <481D1CE7.1060807@kanarip.com> <1209870995.12250.16.camel@localhost.localdomain> <1209921645.2942.8.camel@sb-home> <481E0FC0.9080909@kanarip.com> <48201761.9000505@redhat.com> <4820307D.3070704@kanarip.com> <1210093007.8680.45.camel@localhost.localdomain> Message-ID: <4820E9D9.8080203@kanarip.com> Matthias Clasen wrote: > On Tue, 2008-05-06 at 12:18 +0200, Jeroen van Meeuwen wrote: >> http://fedoraproject.org/wiki/Features/LocalePreferences >> >> Enlist and add your comments, ideas, proposals and changes! >> > > I started doing so, but I think I'd rather send my comments here, since > a discussion is easier via mail. > > 1. '[...] will end up in all LC_* environment variables being set' - I > don't quite follow here. env | grep LC_ comes up empty for me, only LANG > is sent. Who is setting all the LC_ variables for you ? > Try: locale. It'll match LANG unless you've tweaked it. > 2. 'Users should be able to adjust their LC_* preferences [...]' is far > to vague imo. What users can be expected to set, reasonably, is their > language and location. Anything beyond that, like picking a default > paper size or time format, seems to be much to specialized for a general > purpose capplet, and is much better done where it is needed (ie paper > size in the print dialog, time format in the clock). > Well, actually all these printer dialogs and clocks (including those in thunderbird, or the top right corner of the average GNOME desktop), afaik, get their default from LC_TIME. Setting LC_TIME means you do not have to change from 12 to 24 hour clocks and back in each and every application. The same goes for paper dimensions. > 3. Note that we are aiming more or less at obsoleting s-c-date with the > intlclock work. > No we're not. One is to create a very simple interface to adjust various locales with whether in user space or as system defaults, which is completely separate from s-c-date, the other is to softly imply or suggest defaults from timezone configuration in s-c-date and/or anaconda, rather then imply defaults from s-c-language. Note that s-c-language of course will still need to be able to control LC_* as well - it might need a little enhancement. Kind regards, Jeroen van meeuwen -kanarip From greno at verizon.net Tue May 6 23:31:09 2008 From: greno at verizon.net (Gerry Reno) Date: Tue, 06 May 2008 19:31:09 -0400 Subject: Anyone else with hard freezes? In-Reply-To: <1210116098.6222.11.camel@optimus> References: <2a28d2ab0805061455l9afae56p8a86218d08bc4b92@mail.gmail.com> <34809.75.164.221.130.1210112514.squirrel@clueserver.org> <2a28d2ab0805061526o55c58b80y5fceed9375555ffa@mail.gmail.com> <1210112921.6222.9.camel@optimus> <2a28d2ab0805061530j3a8aa79ehb51d96afedaad644@mail.gmail.com> <1210116098.6222.11.camel@optimus> Message-ID: <4820EA3D.3080105@verizon.net> I've had a lot of freeze problems on my F7 machines. A lot of times it turns out to be X. If I log in from another machine and run 'top' I can see X taking 99% cpu. So I kill X and then the system recovers. Regards, Gerry From dr.diesel at gmail.com Tue May 6 23:31:37 2008 From: dr.diesel at gmail.com (Dr. Diesel) Date: Tue, 6 May 2008 19:31:37 -0400 Subject: Anyone else with hard freezes? In-Reply-To: <2a28d2ab0805061625l53999979ocbb0fd19bb775e13@mail.gmail.com> References: <2a28d2ab0805061455l9afae56p8a86218d08bc4b92@mail.gmail.com> <34809.75.164.221.130.1210112514.squirrel@clueserver.org> <2a28d2ab0805061526o55c58b80y5fceed9375555ffa@mail.gmail.com> <1210112921.6222.9.camel@optimus> <2a28d2ab0805061530j3a8aa79ehb51d96afedaad644@mail.gmail.com> <1210116098.6222.11.camel@optimus> <2a28d2ab0805061625l53999979ocbb0fd19bb775e13@mail.gmail.com> Message-ID: <2a28d2ab0805061631i3fe359d4t27031fffd5444d9c@mail.gmail.com> On Tue, May 6, 2008 at 7:25 PM, Dr. Diesel wrote: > On Tue, May 6, 2008 at 7:21 PM, Dave Airlie wrote: > > On Tue, 2008-05-06 at 18:30 -0400, Dr. Diesel wrote: > > > Just nv since Nvidia's drivers don't yet support xorg 1.5. The only > > > kernel module I have loaded is VirtualBox 1.6's. > > > > > > Filing a bug now.. > > > > can you try without virtualbox? > > > > I've seen oops reports from it around the place. > > > > > > > > Dave. > > > > Yup, sure can, removed! > BTW, the module was loaded, but Virtualbox was not running on any of the cases.. -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org From mclasen at redhat.com Tue May 6 23:56:04 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 06 May 2008 19:56:04 -0400 Subject: Localisation needs to be improved In-Reply-To: <4820E9D9.8080203@kanarip.com> References: <1209860284.3433.7.camel@localhost.localdomain> <1209861510.12250.0.camel@localhost.localdomain> <1209862787.12250.4.camel@localhost.localdomain> <481D1CE7.1060807@kanarip.com> <1209870995.12250.16.camel@localhost.localdomain> <1209921645.2942.8.camel@sb-home> <481E0FC0.9080909@kanarip.com> <48201761.9000505@redhat.com> <4820307D.3070704@kanarip.com> <1210093007.8680.45.camel@localhost.localdomain> <4820E9D9.8080203@kanarip.com> Message-ID: <1210118164.5002.11.camel@localhost.localdomain> On Wed, 2008-05-07 at 01:29 +0200, Jeroen van Meeuwen wrote: > Matthias Clasen wrote: > > On Tue, 2008-05-06 at 12:18 +0200, Jeroen van Meeuwen wrote: > >> http://fedoraproject.org/wiki/Features/LocalePreferences > >> > >> Enlist and add your comments, ideas, proposals and changes! > >> > > > > I started doing so, but I think I'd rather send my comments here, since > > a discussion is easier via mail. > > > > 1. '[...] will end up in all LC_* environment variables being set' - I > > don't quite follow here. env | grep LC_ comes up empty for me, only LANG > > is sent. Who is setting all the LC_ variables for you ? > > > > Try: locale. It'll match LANG unless you've tweaked it. Of course, I know that. But the feature page makes it sound as if LC_* are explicitly set. From jkeating at redhat.com Wed May 7 00:15:26 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 06 May 2008 20:15:26 -0400 Subject: Fedora 9 Release Candidate being created Message-ID: <1210119326.5112.10.camel@localhost.localdomain> We are now creating the Fedora 9 Release Candidate. We think we've fixed all the bugs we aim to for Fedora 9 and unless something terrible happens during the compose it will become Fedora 9. Tomorrow's rawhide will match the package set we're composing right now. Rawhide will be stale for a few days while we smoke test the RC and start syncing it to the mirrors. Then we'll pre-push some Fedora 9 updates that have been queued up and start putting Fedora 10 content in rawhide. Stay tuned for announcements as these events happen. Thanks for all the help in making this release happen! -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From poelstra at redhat.com Wed May 7 02:43:29 2008 From: poelstra at redhat.com (John Poelstra) Date: Tue, 06 May 2008 19:43:29 -0700 Subject: FESCo Nominations In-Reply-To: <20080503233002.GA9890@wolff.to> References: <1209827751.10075.2.camel@kennedy> <1209838578.4908.4.camel@vader.jdub.homelinux.org> <20080503224621.GA24868@wolff.to> <1209856000.19174.8.camel@kennedy> <20080503233002.GA9890@wolff.to> Message-ID: <48211751.5040809@redhat.com> Bruno Wolff III said the following on 05/03/2008 04:30 PM Pacific Time: > On Sat, May 03, 2008 at 19:06:40 -0400, > Brian Pepple wrote: >> On Sat, 2008-05-03 at 17:46 -0500, Bruno Wolff III wrote: >>> Is a CLA going to be enough to allow one to vote? >> No, to be eligible to vote you must be a member of a fedora account >> group other than cla_done or cla_fedora. >> >> btw, this and other information in regard to the election can be found: >> http://fedoraproject.org/wiki/PackageMaintainers/Policy/FESCoElections > > Thanks. That leaves me out of this vote, but hopefully by the time of the > next one I'll be maintaining a package or two, > Does the FedoraBugs group count? The BugZappers are always looking for more help :) John From rc040203 at freenet.de Wed May 7 02:49:39 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 07 May 2008 04:49:39 +0200 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: References: <1209999548.32107.11.camel@kennedy> <870180fe0805052050pcac64e2x6377a65a59dce11c@mail.gmail.com> Message-ID: <1210128579.26792.254.camel@beck.corsepiu.local> On Tue, 2008-05-06 at 07:09 -0700, Wes Hardaker wrote: > >>>>> On Mon, 5 May 2008 21:50:30 -0600, "Jerry James" said: > > JJ> Actually, we did update it on the 21.5 (beta) branch quite awhile ago. > JJ> It's true that the 21.4 (stable) branch has never been updated, > JJ> though. > > In second thought, that really brings up one of my primary points: > People don't like upgrading autoconf version usage on old branches > because it brings about unknown effects a lot of the time. IE, it's > simply not safe to do without heavy understanding and testing. Correct - but ... ask yourself ... If wanting to be pedantic, this applies to any tool. Any tool upgrade/change may silently break your once "functional code" without any warning. The autotools actually aren't substantially different wrt. this. > It's > like adding a feature; you don't do it on stable releases because it > can't be trusted. Correct ... That's one reason why this job should be left to upstreams and not to distributions or casual packagers. > And thus, if we want developers to use fedora we should distribute > multiple versions of the development tools when version updates have > potentially large ramifications. If you are serious about this, Fedora will have to ship alternatives for all development tools. The alternative is to push upstreams to "release often, release early" and to keep the pace with tool development. It's what Fedora does otherwise, e.g. wrt. GCC, python, perl, gtk, X11, etc. Ralf From rc040203 at freenet.de Wed May 7 03:25:37 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 07 May 2008 05:25:37 +0200 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <48207385.2060909@redhat.com> References: <1209999548.32107.11.camel@kennedy> <481F2986.8010509@redhat.com> <1210002669.26792.65.camel@beck.corsepiu.local> <481FD064.6050307@ncsu.edu> <1210045081.4658.7.camel@localhost.localdomain> <481FD3D5.5070206@ncsu.edu> <1210071473.29415.128.camel@localhost.localdomain> <48203FF0.70205@kanarip.com> <482044AF.8040109@redhat.com> <48207385.2060909@redhat.com> Message-ID: <1210130737.26792.275.camel@beck.corsepiu.local> On Tue, 2008-05-06 at 11:04 -0400, Christopher Aillon wrote: > On 05/06/2008 07:44 AM, Karsten Hopp wrote: > > Jeroen van Meeuwen wrote: > >> Jesse Keating wrote: > >>> On Mon, 2008-05-05 at 23:43 -0400, Casey Dahlin wrote: > >>>> The gain is we decide what to keep and what not to keep based on who > >>>> actually is willing to fight to keep it around rather than whoever > >>>> feels like complaining on devel list. Its a corollary to "its easier > >>>> to apologize than to ask permission," the people who notice the > >>>> change are a tiny and far more important subset than the people who > >>>> will complain ahead of time. > >>> > >>> It doesn't account for the developers who will have failures, notice we > >>> don't package a version of autoconf anymore and say "Screw that" and > >>> move to some other development platform which does support what they > >>> need. > >>> > >>> > >> > >> My $.02 worth of thoughts: > >> > >> One could imagine a policy in which new packages using these tools > >> would not be accepted per-se, while the tools would still be > >> available, packaged, for those other packages and developers that need > >> it. > >> > >> Does such, or something similar, make sense? > >> > > > > Such a policy would be ok with me. The whole intention for this proposal > > was > > to disencourage usage of the old tools, not to force maintainers to > > rewrite their > > configure scripts immediately or use another distribution. > > Nonetheless maintainers of forementioned packages should check if it is > > necessary to run autofoo during the build. Most of the times it isn't > > and if I > > remember correctly even I am guilty of doing this due to laziness and/or > > time > > constraints. > > Doing it during the build is not the issue. You can't even generate a > patch to configure if the tool to do regenerate it is not available in > the distro. Wrong. Of cause - you can. Ralf From rc040203 at freenet.de Wed May 7 03:39:23 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 07 May 2008 05:39:23 +0200 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <48207847.70308@kanarip.com> References: <1209999548.32107.11.camel@kennedy> <481F2986.8010509@redhat.com> <1210002669.26792.65.camel@beck.corsepiu.local> <481FD064.6050307@ncsu.edu> <1210045081.4658.7.camel@localhost.localdomain> <481FD3D5.5070206@ncsu.edu> <1210071473.29415.128.camel@localhost.localdomain> <48203FF0.70205@kanarip.com> <48206323.9060300@gmail.com> <48207847.70308@kanarip.com> Message-ID: <1210131563.26792.287.camel@beck.corsepiu.local> On Tue, 2008-05-06 at 17:24 +0200, Jeroen van Meeuwen wrote: > Toshio Kuratomi wrote: > > Jeroen van Meeuwen wrote: > > The packager should not have to use the autotools normally. > > I "never" *cough* the two packages that I'm upstream for *cough* ship > any autofoo output files, only autofoo input files; it's excluded from > the source tree and excluded in tarballs... Should I reconsider this? Yes. You improperly using the autotools. In case you are using automake, you should cut your tarballs using "make dist". Such tarballs normally include the generated files. > Is it gonna give trouble at some point? Depends. If your autotool-input files are properly written, compliant to modern autotools syntax, and being tested with modern autotools by upstream (i.e. you) this should not impose much problems to packagers/casual installers on mainstream platforms (such as Fedora). If not, upstream (i.e. you) will likely be facing problems sooner or later, esp. on "more exotic platforms" (MacOSX, Cygwin, MinGW, Solaris, HPUX, ...). Ralf From petersen at redhat.com Wed May 7 04:27:59 2008 From: petersen at redhat.com (Jens Petersen) Date: Wed, 07 May 2008 14:27:59 +1000 Subject: Localisation needs to be improved In-Reply-To: <1210093159.28402.40.camel@ignacio.lan> References: <1209860284.3433.7.camel@localhost.localdomain> <1209861510.12250.0.camel@localhost.localdomain> <1209862787.12250.4.camel@localhost.localdomain> <4820177D.3000106@redhat.com> <1210093159.28402.40.camel@ignacio.lan> Message-ID: <48212FCF.3080307@redhat.com> Ignacio Vazquez-Abrams ????????: > On Tue, 2008-05-06 at 18:31 +1000, Jens Petersen wrote: >> Hmm, if I run "LANG=en_AU.UTF-8 gedit" and look at preferences I see >> "Fonts and Colors" not "Fonts and Colours" (like for en_GB)? > > gedit doesn't have l10n for en_AU. Yes, I guessed that but shouldn't it fallback to en_GB? Jens From rc040203 at freenet.de Wed May 7 04:39:35 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 07 May 2008 06:39:35 +0200 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <1210045081.4658.7.camel@localhost.localdomain> References: <1209999548.32107.11.camel@kennedy> <481F2986.8010509@redhat.com> <1210002669.26792.65.camel@beck.corsepiu.local> <481FD064.6050307@ncsu.edu> <1210045081.4658.7.camel@localhost.localdomain> Message-ID: <1210135175.26792.313.camel@beck.corsepiu.local> On Mon, 2008-05-05 at 23:38 -0400, Matthias Clasen wrote: > On Mon, 2008-05-05 at 23:28 -0400, Casey Dahlin wrote: > > > In light of this, I have a proposal: > > > > We fix our specs to not use autoconf, and remove the old versions as > > stated, but we keep them around, perhaps in another branch in CVS or > > simply removed from the F10 tag. Then we just wait for complaints. If > > someone comes in and says "I was actively using that" we can just slap > > it back in. After one release cycle we can flush the rest. > > > > And we do all this work because we have nothing better to do ? > Whats the gain, again ? Improved portability of your packages, improved robustness of your configury and much simpler Makefiles (wrt. automake). That's the core points the autotools are after and upstreams should be after - Of cause, these aspects are not of much importance if your target audience is Linux-only. Ralf From lordmorgul at gmail.com Wed May 7 04:43:23 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Tue, 06 May 2008 21:43:23 -0700 Subject: Anyone else with hard freezes? In-Reply-To: <4820DAB6.1030402@verizon.net> References: <2a28d2ab0805061455l9afae56p8a86218d08bc4b92@mail.gmail.com> <4820DAB6.1030402@verizon.net> Message-ID: <4821336B.9060100@gmail.com> Gerry Reno wrote: > Dr. Diesel wrote: >> Currently running Fedora 9 Release to date. Doesn't happen very >> often, maybe once every 3-4 days. Twice I've caught it at idle with >> the screen saver (picture viewer) frozen and twice while browsing in >> Gnome. >> >> Not really noticing anything weird in the logs? >> >> > Haven't had a freeze yet but I have seen a couple weird things with X. > Twice now my cursor just went to either the upper right corner or the > lower right corner. If you try to move it somewhere it just goes back > to the corner in a jerky motion. Very strange. I think that could be several mouse or input devices sending core events, fighting each other for where the cursor should go. Do you have more than one mouse attached? Do you have more input devices (maybe pseudo devices) showing up in the Xorg.0.log? Maybe that issue is an auto-configured input problem. -- Andrew Farris www.lordmorgul.net gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29 From rc040203 at freenet.de Wed May 7 05:13:42 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 07 May 2008 07:13:42 +0200 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <20080506144622.GA1823@camelia.ucw.cz> References: <1209999548.32107.11.camel@kennedy> <1210002510.26792.62.camel@beck.corsepiu.local> <481F306A.90600@redhat.com> <1210004495.26792.82.camel@beck.corsepiu.local> <481F36F4.4060105@redhat.com> <1210006440.26792.109.camel@beck.corsepiu.local> <20080506144622.GA1823@camelia.ucw.cz> Message-ID: <1210137222.26792.344.camel@beck.corsepiu.local> On Tue, 2008-05-06 at 16:46 +0200, Stepan Kasal wrote: > Hi, > > On Mon, May 05, 2008 at 06:53:59PM +0200, Ralf Corsepius wrote: > > On Mon, 2008-05-05 at 12:33 -0400, Christopher Aillon wrote: > > > Or if autotools maintainers would stop changing the interface so > > > freaking often, this wouldn't be a problem either.... > > Apparently you don't have much clues about the autotools. > > > > They did not change the "interface so often". > > > > There has been one big interface change: It occurred between > > autoconf-2.13 and autoconf-2.50 - Many years ago. > > well, there was also the change in Automake 1.4 -> 1.5, which > happened after that, and then the "stabilization period" for "new" > automake until, say, 1.8. Yep, all this took place such a long time ago, I forgot about this. Probably because, from my experience, this change had been less intrusive. It either broke existing configurations hard and explicit or didn't break them at all. > So it is about 7 years ago since the last interface change and > we can say that Autotools are really stable and mature for at least 4 > years. Matches entirely with my experience. > What _is_ the problem, is that many projects use an undocumented > internals, instead of requesting an enhancement. > And _that_ kind of hacks break very easily with a new release. Fully agreed. If mainstream Linux distros had been a little more aggressive about abandoning support for outdated/discontinued autotools (like they are doing with other tools), people would have learned about their mistakes on autotool usage earlier and would take autotool upgrades with a much more relaxed attitude. Ralf From ruben at rubenkerkhof.com Wed May 7 07:06:50 2008 From: ruben at rubenkerkhof.com (Ruben Kerkhof) Date: Wed, 7 May 2008 09:06:50 +0200 Subject: Fedora Package Status of May 3, 2008 In-Reply-To: <20080503010742.1b41ccab@ludwig-alpha.unil.ch> References: <20080503010742.1b41ccab@ludwig-alpha.unil.ch> Message-ID: <90203CE9-21FF-45FC-8201-CEA068C8E06C@rubenkerkhof.com> On 3 mei 2008, at 01:07, Christian Iseli wrote: > - 2 packages present in the development repo which have no owners > entry > mogilefs-server s390utils mogilefs-server was renamed in cvs to perl-mogilefs-server, so I'm not sure why this shows up. Ruben From zprikryl at redhat.com Wed May 7 07:29:03 2008 From: zprikryl at redhat.com (Zdenek Prikryl) Date: Wed, 07 May 2008 09:29:03 +0200 Subject: New system-config-acpid In-Reply-To: <20080506154407.GA21822@nostromo.devel.redhat.com> References: <48207BC5.3060105@redhat.com> <20080506154407.GA21822@nostromo.devel.redhat.com> Message-ID: <48215A3F.10806@redhat.com> Bill Nottingham napsal(a): > Not to be a killjoy, but why a config tool for a program which should > probably die? Aren't these all better handled by user-specific policy > agents such as gnome-power-manager or kpowersave? Simple reason :-)... if you don't use gnome or kde or this applets, the simplest way how to get things work is configure this daemon. On the other hand I agree, that better way is catch this events via HAL and then send it to d-bus. But in this case, again, you have to have this applets. AFAIK there is no "acpid" for dbus which you can configure for any acpi events (like Fn5 which should enable bluetooth). -- Zdenek Prikryl From tnorth at fedoraproject.org Wed May 7 07:30:28 2008 From: tnorth at fedoraproject.org (Thibault North) Date: Wed, 7 May 2008 09:30:28 +0200 Subject: Removing hdf5 from ppc64 In-Reply-To: <4820BCC4.2040103@cora.nwra.com> References: <4820BCC4.2040103@cora.nwra.com> Message-ID: <8e967d910805070030l4cbf70ccj317e7344e7d98ed9@mail.gmail.com> On Tue, May 6, 2008 at 10:17 PM, Orion Poplawski wrote: > The hdf5 1.8.0 does not build on ppc64 (or it builds, but it fails its > tests). I've put in an ExcludeArch: ppc64 for now and filed a bug: > > https://bugzilla.redhat.com/show_bug.cgi?id=445423 > > I really don't have any more time to work on this at the moment. If you do > and you care about this, all help is appreciated. > > Packages (directly) affected: > > gdal > LabPlot > octave > paraview > R-hdf5 > > Downstream: > > gdal -> grass, mapserver, qgis > octave -> octave-forge, plplot > plplot -> gdl, perl-PDL > LabPlot already excludes ppc64, so there is no regression for it after hdf5 1.8.0. > -- > Orion Poplawski > Technical Manager 303-415-9701 x222 > NWRA/CoRA Division FAX: 303-415-9702 > 3380 Mitchell Lane orion at cora.nwra.com > Boulder, CO 80301 http://www.cora.nwra.com > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From dan at danny.cz Wed May 7 07:32:26 2008 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Wed, 07 May 2008 09:32:26 +0200 Subject: Fedora Package Status of May 3, 2008 In-Reply-To: <90203CE9-21FF-45FC-8201-CEA068C8E06C@rubenkerkhof.com> References: <20080503010742.1b41ccab@ludwig-alpha.unil.ch> <90203CE9-21FF-45FC-8201-CEA068C8E06C@rubenkerkhof.com> Message-ID: <1210145546.3071.8.camel@localhost.localdomain> On 3 mei 2008, at 01:07, Christian Iseli wrote: > - 2 packages present in the development repo which have no owners > entry > mogilefs-server s390utils I think s390utils were removed from Fedora (and I cannot find them in pkgdb), but as there is some work being done on the s390/s390x as a secondary architecture, they should be included again. And I can be the owner because I going to be the owner for RHEL too. Dan From kanarip at kanarip.com Wed May 7 07:51:27 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 07 May 2008 09:51:27 +0200 Subject: Localisation needs to be improved In-Reply-To: <1210118164.5002.11.camel@localhost.localdomain> References: <1209860284.3433.7.camel@localhost.localdomain> <1209861510.12250.0.camel@localhost.localdomain> <1209862787.12250.4.camel@localhost.localdomain> <481D1CE7.1060807@kanarip.com> <1209870995.12250.16.camel@localhost.localdomain> <1209921645.2942.8.camel@sb-home> <481E0FC0.9080909@kanarip.com> <48201761.9000505@redhat.com> <4820307D.3070704@kanarip.com> <1210093007.8680.45.camel@localhost.localdomain> <4820E9D9.8080203@kanarip.com> <1210118164.5002.11.camel@localhost.localdomain> Message-ID: <48215F7F.3070804@kanarip.com> Matthias Clasen wrote: > On Wed, 2008-05-07 at 01:29 +0200, Jeroen van Meeuwen wrote: >> Matthias Clasen wrote: >>> On Tue, 2008-05-06 at 12:18 +0200, Jeroen van Meeuwen wrote: >>>> http://fedoraproject.org/wiki/Features/LocalePreferences >>>> >>>> Enlist and add your comments, ideas, proposals and changes! >>>> >>> I started doing so, but I think I'd rather send my comments here, since >>> a discussion is easier via mail. >>> >>> 1. '[...] will end up in all LC_* environment variables being set' - I >>> don't quite follow here. env | grep LC_ comes up empty for me, only LANG >>> is sent. Who is setting all the LC_ variables for you ? >>> >> Try: locale. It'll match LANG unless you've tweaked it. > > Of course, I know that. But the feature page makes it sound as if LC_* > are explicitly set. > Ah, right! I'll make changes and try to choose a more appropriate wording. Thanks :-) -Jeroen From alexl at users.sourceforge.net Wed May 7 07:59:22 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Wed, 07 May 2008 00:59:22 -0700 Subject: Maintainer Responsibility Policy In-Reply-To: <1210035695.6297.25.camel@kennedy> (Brian Pepple's message of "Mon\, 05 May 2008 21\:01\:35 -0400") References: <1210035695.6297.25.camel@kennedy> Message-ID: <9w4p9a7det.fsf@allele2.eebweb.arizona.edu> >>>>> "BP" == Brian Pepple writes: BP> Hi all, I'm looking for some feedback on what I've got so far for BP> the Maintainer Responsibility Policy. BP> http://fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy As Extras is defunct, all the wiki pages under the namespace: Extras/Schedule should probably be moved under the new namespace: Development/Schedule I made a start by moving: http://fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy to: http://fedoraproject.org/wiki/Development/Schedule/MaintainerResponsibilityPolicy I think I got all the places that also linked to it (I also created a redirect so that people who only have the old URL from previous messages will be redirected to it fine). Let me know if not. Alex From kanarip at kanarip.com Wed May 7 08:01:35 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 07 May 2008 10:01:35 +0200 Subject: Localisation needs to be improved In-Reply-To: <48212FCF.3080307@redhat.com> References: <1209860284.3433.7.camel@localhost.localdomain> <1209861510.12250.0.camel@localhost.localdomain> <1209862787.12250.4.camel@localhost.localdomain> <4820177D.3000106@redhat.com> <1210093159.28402.40.camel@ignacio.lan> <48212FCF.3080307@redhat.com> Message-ID: <482161DF.3070405@kanarip.com> Jens Petersen wrote: > Ignacio Vazquez-Abrams ????????????????????????: >> On Tue, 2008-05-06 at 18:31 +1000, Jens Petersen wrote: >>> Hmm, if I run "LANG=en_AU.UTF-8 gedit" and look at preferences I see >>> "Fonts and Colors" not "Fonts and Colours" (like for en_GB)? >> >> gedit doesn't have l10n for en_AU. > > Yes, I guessed that but shouldn't it fallback to en_GB? > en_US - or more accurately the untranslated upstream language, I think? -Jeroen From dwmw2 at infradead.org Wed May 7 09:07:23 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 07 May 2008 10:07:23 +0100 Subject: Removing hdf5 from ppc64 In-Reply-To: <8e967d910805070030l4cbf70ccj317e7344e7d98ed9@mail.gmail.com> References: <4820BCC4.2040103@cora.nwra.com> <8e967d910805070030l4cbf70ccj317e7344e7d98ed9@mail.gmail.com> Message-ID: <1210151243.25560.859.camel@pmac.infradead.org> On Wed, 2008-05-07 at 09:30 +0200, Thibault North wrote: > LabPlot already excludes ppc64, so there is no regression for it after > hdf5 1.8.0. What's the bug number? I don't see it on the FE-ExcludeArch-ppc64 tracker. -- dwmw2 From alan at redhat.com Wed May 7 09:11:24 2008 From: alan at redhat.com (Alan Cox) Date: Wed, 7 May 2008 05:11:24 -0400 Subject: Localisation needs to be improved In-Reply-To: <482161DF.3070405@kanarip.com> References: <1209860284.3433.7.camel@localhost.localdomain> <1209861510.12250.0.camel@localhost.localdomain> <1209862787.12250.4.camel@localhost.localdomain> <4820177D.3000106@redhat.com> <1210093159.28402.40.camel@ignacio.lan> <48212FCF.3080307@redhat.com> <482161DF.3070405@kanarip.com> Message-ID: <20080507091124.GC21867@devserv.devel.redhat.com> On Wed, May 07, 2008 at 10:01:35AM +0200, Jeroen van Meeuwen wrote: > >>gedit doesn't have l10n for en_AU. > > > >Yes, I guessed that but shouldn't it fallback to en_GB? > > > en_US - or more accurately the untranslated upstream language, I think? en_GB. en_US is a dialect of the base language and aussie is probably closer to en_GB than en_US. This is one area open office has a nice model for fallbacks that would be nice elsewhere. Alan From Christian.Iseli at unil.ch Wed May 7 09:21:03 2008 From: Christian.Iseli at unil.ch (Christian Iseli) Date: Wed, 7 May 2008 11:21:03 +0200 Subject: Fedora Package Status of May 3, 2008 In-Reply-To: <90203CE9-21FF-45FC-8201-CEA068C8E06C@rubenkerkhof.com> References: <20080503010742.1b41ccab@ludwig-alpha.unil.ch> <90203CE9-21FF-45FC-8201-CEA068C8E06C@rubenkerkhof.com> Message-ID: <20080507112103.7ef5a90e@ludwig-alpha.unil.ch> On Wed, 7 May 2008 09:06:50 +0200, Ruben Kerkhof wrote: > mogilefs-server was renamed in cvs to perl-mogilefs-server, so I'm > not sure why this shows up. You should file a request with rel-eng that they remove the old version from the repo. Cheers, C From mschwendt at gmail.com Wed May 7 09:23:18 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 7 May 2008 11:23:18 +0200 Subject: bodhi questions In-Reply-To: <20080505215502.GF3718@x300.redhat.com> References: <20080503105227.e21d411b.mschwendt@gmail.com> <20080505163914.GB3718@x300.redhat.com> <20080505215502.GF3718@x300.redhat.com> Message-ID: <20080507112318.3c8602b6.mschwendt@gmail.com> On Mon, 5 May 2008 17:55:02 -0400, Luke Macken wrote: > On Mon, May 05, 2008 at 12:39:14PM -0400, Luke Macken wrote: > > On Sat, May 03, 2008 at 10:52:27AM +0200, Michael Schwendt wrote: > > > 1) Does the nvr input box work for anyone? It used to work long ago, but > > > here no longer finds any builds. I had to cut'n'paste a build tag into it. > > > > Yep, known issue[0]. We hit a regression with the AutoCompleteField > > widget with TurboGears-1.0.4.4, which has since been fixed upstream. > > I fixed the package auto-completion widget, and pushed the fix to > production. Let me know if you have any problems with it! Thanks! It works again, albeit requires slow and careful typing, as else it would attempt completion at odd times. Sorting the results (by name and by RPM evr) would be a great feature addition. -- Fedora release 8 (Werewolf) - Linux 2.6.23.15-137.fc8 loadavg: 1.07 1.15 1.17 From dwmw2 at infradead.org Wed May 7 10:07:01 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 07 May 2008 11:07:01 +0100 Subject: Maintainer Responsibility Policy In-Reply-To: <4820836D.7070008@gmail.com> References: <1210035695.6297.25.camel@kennedy> <482056BE.90100@n-dimensional.de> <48206A93.7020807@gmail.com> <1210089261.2961.3.camel@kennedy> <4820836D.7070008@gmail.com> Message-ID: <1210154821.25560.865.camel@pmac.infradead.org> On Tue, 2008-05-06 at 09:12 -0700, Toshio Kuratomi wrote: > Yeah. I think it's worthwhile to mention something like this: > > "Even bugs that you aren't capable of fixing yourself because they deal > with intricacies of the source code that you don't have the knowledge to > fix deserve a few moments of your time. You can report the bug upstream > for the user, ask for help from more code-oriented people on > fedora-devel, or check whether other distros have patches for the > problem. Always be sure to post to the bug report what you have done so > that the reporter has a proper expectation of whether you're working on > a fix or if it's something that has to wait on upstream action." I'm not sure that's strong enough. It should clearly state that the package maintainer is responsible for getting bugs fixed -- if the package maintainer isn't a coder, then they need to take a more managerial r?le; working with upstream or with code-monkeys within Fedora to get things fixed. How about this: If there are bugs which you aren't capable of fixing yourself because they deal with intricacies of the source code which you don't fully understand, then you still need to address these bugs. It can be helpful to work with the upstream maintainer of the code, obtain help from more code-oriented people on fedora-devel, or check other distributions for patches. Always be sure to post to the bug report what you have done so that the reporter knows what it happening and what to expect. It is recommended that non-coder packagers should find co-maintainers who are familiar with the programming language used by their package(s), and can help with such bugs as a kind of 'second line support'. -- dwmw2 From dwmw2 at infradead.org Wed May 7 10:08:42 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 07 May 2008 11:08:42 +0100 Subject: Removing hdf5 from ppc64 In-Reply-To: <4820BCC4.2040103@cora.nwra.com> References: <4820BCC4.2040103@cora.nwra.com> Message-ID: <1210154922.25560.868.camel@pmac.infradead.org> On Tue, 2008-05-06 at 14:17 -0600, Orion Poplawski wrote: > The hdf5 1.8.0 does not build on ppc64 (or it builds, but it fails its > tests). I've put in an ExcludeArch: ppc64 for now and filed a bug: All the test failures are precision/rounding errors with 'long double'. My first guess would be that it's assuming that 'long double' is 64-bit. That's not a valid assumption, in the general case. -- dwmw2 From dtimms at iinet.net.au Wed May 7 10:15:16 2008 From: dtimms at iinet.net.au (David Timms) Date: Wed, 07 May 2008 20:15:16 +1000 Subject: Fedora 9 Release Candidate being created In-Reply-To: <1210119326.5112.10.camel@localhost.localdomain> References: <1210119326.5112.10.camel@localhost.localdomain> Message-ID: <48218134.8020404@iinet.net.au> Jesse Keating wrote: > Rawhide will be stale for a few days while we smoke test the RC and > start syncing it to the mirrors. Then we'll pre-push some Fedora 9 You could set it all up so that if a program so much as mentions backtrace, DEBUG, oops, unexpected, error or dump, it turns on the attached USB smoke generator - so you can quickly point out which machine is having a problem. And i this get really bad there is always the napalm option to lay the test lab to waste. == Presidential hopeful: "in my younger days we rolled some F9 RC's, but we never inhaled..." DaveT. From ml at deadbabylon.de Wed May 7 10:34:15 2008 From: ml at deadbabylon.de (Sebastian Vahl) Date: Wed, 7 May 2008 12:34:15 +0200 Subject: KDE-SIG weekly report (19/2008) Message-ID: <200805071234.19547.ml@deadbabylon.de> This is a report of the weekly KDE-SIG-Meeting with a summary of the topics that were discussed. If you want to add a comment please reply ?to this email or add it to the related meeting page. ---------------------------------------------------------------------------------- = Weekly KDE Summary = Week: 19/2008 Time: 2008-05-06 16:00 UTC Meeting page: http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-05-06 Meeting log: http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-05-06?action=AttachFile&do=get&target=fedora-kde-sig-2008-05-06.txt ---------------------------------------------------------------------------------- = Participants = GeraldCox KevinKofler LorenzoVillani PavelShevchuk (Stalwart) RexDieter SebastianVahl ShawnStarr StevenParrish ---------------------------------------------------------------------------------- = Agenda = * KDE 4.0.4 updates * Include F-7? * KDE 4.1alpha in rawhide * F7 updates awol * Upstreaming patches = Summary = o KDE 4.0.4 updates: - RexDieter started to work on updates for upcoming KDE 4.0.4. - Also Fedora 7 will get these updates (for the "KDE 4.0 Developing Platfom") before it becomes EOL. - These updates will stay in updates-testing until Fedora 9 gets released to don't break upgrade paths. o KDE 4.1 Alpha in Rawhide: - KevinKofler is working on getting KDE 4-1 (Alpha 1) in Rawhide (for F10). - RexDieter will also update qt to 4.4.0. - We'll need avogadro to get reviewed and imported since it is splitted out of Kalzium 4.1 o F7 updates awol: This is just a notification because KDE-SIG can't to anthing about that: f7 mash is segfaulting and holding up updates push. [1] o Upstreaming patches: - RexDieter wanted to remind everyone to try to integrate the patches for Fedora's KDE upstream. - Besides others this should be done for ConsoleKit, PolicyKit, Pulseaudio. ---------------------------------------------------------------------------------- = Next Meeting = http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-05-13 ---------------------------------------------------------------------------------- = Links = [1] https://admin.fedoraproject.org/updates/F7/FEDORA-2008-3379 -------------- next part -------------- A non-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 all-the-johnsons.co.uk Wed May 7 10:43:33 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Wed, 07 May 2008 11:43:33 +0100 Subject: Monodevelop Message-ID: <1210157013.7291.2.camel@T7.Linux> Hi, I'm trying to find out why the texteditor from monodevelop has vanished and have tried plenty of things, none of which seem to be working. If you have a working copy of monodevelop, could you email me and tell me the version number and which Fedora your using (8, 9, rawhide etc) and the platform (x86, ppc, x86_64)? I really need to get this working so I can import it into F9 when F9 becomes open again. TTFN Paul monodevelop maintainer -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From bnocera at redhat.com Wed May 7 10:50:50 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Wed, 07 May 2008 11:50:50 +0100 Subject: New system-config-acpid In-Reply-To: <48215A3F.10806@redhat.com> References: <48207BC5.3060105@redhat.com> <20080506154407.GA21822@nostromo.devel.redhat.com> <48215A3F.10806@redhat.com> Message-ID: <1210157450.2755.102.camel@cookie.hadess.net> On Wed, 2008-05-07 at 09:29 +0200, Zdenek Prikryl wrote: > Bill Nottingham napsal(a): > > Not to be a killjoy, but why a config tool for a program which should > > probably die? Aren't these all better handled by user-specific policy > > agents such as gnome-power-manager or kpowersave? > > Simple reason :-)... if you don't use gnome or kde or this applets, the simplest > way how to get things work is configure this daemon. Not really. With HAL running, it should push the ACPI key events through D-Bus. There's no need for a system-config-acpid or even using acpid. > On the other hand I agree, that better way is catch this events via HAL and then > send it to d-bus. But in this case, again, you have to have this applets. AFAIK > there is no "acpid" for dbus which you can configure for any acpi events (like > Fn5 which should enable bluetooth). With the right keymap, all those events already trickle to X, so there shouldn't ever be a need for acpid or a system-config-acpid, as there's already enough hot-key handlers in X (such as the ones builtin to GNOME and KDE). Do we still install acpid by default? From dwmw2 at infradead.org Wed May 7 10:51:16 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 07 May 2008 11:51:16 +0100 Subject: Removing hdf5 from ppc64 In-Reply-To: <1210154922.25560.868.camel@pmac.infradead.org> References: <4820BCC4.2040103@cora.nwra.com> <1210154922.25560.868.camel@pmac.infradead.org> Message-ID: <1210157476.25560.880.camel@pmac.infradead.org> On Wed, 2008-05-07 at 11:08 +0100, David Woodhouse wrote: > On Tue, 2008-05-06 at 14:17 -0600, Orion Poplawski wrote: > > The hdf5 1.8.0 does not build on ppc64 (or it builds, but it fails its > > tests). I've put in an ExcludeArch: ppc64 for now and filed a bug: > > All the test failures are precision/rounding errors with 'long double'. > My first guess would be that it's assuming that 'long double' is 64-bit. > That's not a valid assumption, in the general case. Hm, seems like it's _expecting_ rounding errors. But only handles them by ignoring the last few bytes of the mantissa. But in these cases, the mantissa and the exponent are both quite different, although the total error is small: Testing soft long -> long double conversions *FAILED* elmt 107: src = 00 3f ff ff ff ff ff ff 18014398509481983 dst = 43 4f ff ff ff ff ff ff 80 00 00 00 00 00 00 00 18014398509481982.000000 ans = 43 50 00 00 00 00 00 00 bf f0 00 00 00 00 00 00 18014398509481983.000000 Here, I think that 'dst' is the result of the routine under test, while 'ans' is the result of letting the hardware/compiler do the conversion with a simple cast. I'm not sure if this is a real error which it intended to catch, or whether it's considered acceptable lack of precision. As ever, I can give accounts on suitable machines to more knowledgeable people who want to investigate further. Just let me have a SSH public key. -- dwmw2 From gnomeuser at gmail.com Wed May 7 11:11:45 2008 From: gnomeuser at gmail.com (David Nielsen) Date: Wed, 7 May 2008 13:11:45 +0200 Subject: Monodevelop In-Reply-To: <1210157013.7291.2.camel@T7.Linux> References: <1210157013.7291.2.camel@T7.Linux> Message-ID: <1dedbbfc0805070411g61f99bb3uf871968752e791a1@mail.gmail.com> 7. maj. 2008 12.43 skrev Paul : > Hi, > > I'm trying to find out why the texteditor from monodevelop has vanished > and have tried plenty of things, none of which seem to be working. > > If you have a working copy of monodevelop, could you email me and tell > me the version number and which Fedora your using (8, 9, rawhide etc) > and the platform (x86, ppc, x86_64)? > > I really need to get this working so I can import it into F9 when F9 > becomes open again. > > TTFN > > Paul > monodevelop maintainer The editor seems to be working here and I am using the RPMs in the F9 repo on my x86_64. monodevelop-0.19-6.fc9.x86_64 - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From laxathom at fedoraproject.org Wed May 7 11:24:59 2008 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Wed, 7 May 2008 13:24:59 +0200 Subject: Monodevelop In-Reply-To: <1dedbbfc0805070411g61f99bb3uf871968752e791a1@mail.gmail.com> References: <1210157013.7291.2.camel@T7.Linux> <1dedbbfc0805070411g61f99bb3uf871968752e791a1@mail.gmail.com> Message-ID: <62bc09df0805070424m5b5e1b93ia96dd946d27b12c@mail.gmail.com> 2008/5/7 David Nielsen : > > > 7. maj. 2008 12.43 skrev Paul : > > > Hi, > > > > I'm trying to find out why the texteditor from monodevelop has vanished > > and have tried plenty of things, none of which seem to be working. > > > > If you have a working copy of monodevelop, could you email me and tell > > me the version number and which Fedora your using (8, 9, rawhide etc) > > and the platform (x86, ppc, x86_64)? > > > > I really need to get this working so I can import it into F9 when F9 > > becomes open again. > > > > TTFN > > > > Paul > > monodevelop maintainer > > > The editor seems to be working here and I am using the RPMs in the F9 repo > on my x86_64. > monodevelop-0.19-6.fc9.x86_64 > Same on F-8 with : monodevelop-0.13.1-1.fc8.x86_64 > > > - David > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From stickster at gmail.com Wed May 7 04:29:25 2008 From: stickster at gmail.com (Paul Frields) Date: Wed, 7 May 2008 00:29:25 -0400 Subject: Nomination information for Fedora Board Message-ID: Re: http://paul.frields.org/?p=990 Basically, if you're a nominee for the Fedora Project Board elections, you should fill out an entry on the wiki's nominations page: http://fedoraproject.org/wiki/Board/Elections/Nominations Tell us a little about yourself and why you think the community ought to cast votes for you! Please complete your entry by May 30th. Paul W. Frields Fedora Project Leader _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From walters at verbum.org Wed May 7 11:58:01 2008 From: walters at verbum.org (Colin Walters) Date: Wed, 7 May 2008 07:58:01 -0400 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <1210135175.26792.313.camel@beck.corsepiu.local> References: <1209999548.32107.11.camel@kennedy> <481F2986.8010509@redhat.com> <1210002669.26792.65.camel@beck.corsepiu.local> <481FD064.6050307@ncsu.edu> <1210045081.4658.7.camel@localhost.localdomain> <1210135175.26792.313.camel@beck.corsepiu.local> Message-ID: On Wed, May 7, 2008 at 12:39 AM, Ralf Corsepius wrote: > > That's the core points the autotools are after and upstreams should be > after - Of cause, these aspects are not of much importance if your > target audience is Linux-only. Ralf, there are many more important things to work on. End user visible impact of everyone spending time mucking with build systems: 0 From williams at redhat.com Wed May 7 12:56:59 2008 From: williams at redhat.com (Clark Williams) Date: Wed, 07 May 2008 07:56:59 -0500 Subject: Anyone else with hard freezes? In-Reply-To: <2a28d2ab0805061455l9afae56p8a86218d08bc4b92@mail.gmail.com> References: <2a28d2ab0805061455l9afae56p8a86218d08bc4b92@mail.gmail.com> Message-ID: <4821A71B.2000500@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dr. Diesel wrote: > Currently running Fedora 9 Release to date. Doesn't happen very > often, maybe once every 3-4 days. Twice I've caught it at idle with > the screen saver (picture viewer) frozen and twice while browsing in > Gnome. > > Not really noticing anything weird in the logs? > I had one last night, running jaaa (spectrum analyzer) on the input from a USB sound device, so lots of 2d graphics activity. System just locked, power button time. Lenovo T60 Core2 Duo T7200 2.00GHz 3GB Ram $ uname -a Linux torg 2.6.25-14.fc9.x86_64 #1 SMP Thu May 1 06:06:21 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux I'd suspended to RAM and resumed a number of times before this happened. Nothing readily apparent in my logs. I'll try and get some better info if it happens again. Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkghpxsACgkQHyuj/+TTEp0RQgCdHmy2ufkvaDCxwhcJUr/T6grc VUEAnjZ/XLovWwZlQb8a+eWKh+cYPzpg =9eYg -----END PGP SIGNATURE----- From mclasen at redhat.com Wed May 7 12:58:56 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 07 May 2008 08:58:56 -0400 Subject: Localisation needs to be improved In-Reply-To: <48212FCF.3080307@redhat.com> References: <1209860284.3433.7.camel@localhost.localdomain> <1209861510.12250.0.camel@localhost.localdomain> <1209862787.12250.4.camel@localhost.localdomain> <4820177D.3000106@redhat.com> <1210093159.28402.40.camel@ignacio.lan> <48212FCF.3080307@redhat.com> Message-ID: <1210165136.4641.4.camel@localhost.localdomain> On Wed, 2008-05-07 at 14:27 +1000, Jens Petersen wrote: > Ignacio Vazquez-Abrams ????????: > > On Tue, 2008-05-06 at 18:31 +1000, Jens Petersen wrote: > >> Hmm, if I run "LANG=en_AU.UTF-8 gedit" and look at preferences I see > >> "Fonts and Colors" not "Fonts and Colours" (like for en_GB)? > > > > gedit doesn't have l10n for en_AU. > > Yes, I guessed that but shouldn't it fallback to en_GB? > Setting LANGUAGE allows you to specify fallbacks, iirc, but setting LANG does not. LANGUAGE=en_AU:en_GB should do what you expect. From rawhide at fedoraproject.org Wed May 7 13:00:55 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Wed, 7 May 2008 13:00:55 +0000 (UTC) Subject: rawhide report: 20080507 changes Message-ID: <20080507130055.4EEED209D07@releng1.fedora.phx.redhat.com> Updated Packages: anaconda-11.4.0.82-1 -------------------- * Tue May 06 2008 Chris Lumens - 11.4.0.82-1 - Look in the right place when ISO images are in a subdirectory (#443580). (clumens) - Don't crash when given URLs of the form ftp://user at host/path (#445295). (dlehman) - And run in the root (#374921) (katzj) fedora-release-9-2 ------------------ * Tue May 06 2008 Jesse Keating - 9-2 - Update compose files with changes needed during release candidates * Thu May 01 2008 Jesse Keating - 9-1 - Make the final package, set the release name. * Tue Apr 22 2008 Jesse Keating - 9-0.1.rc - Make version 9 for yum, rpm version clearly a pre-release. gnome-audio-2.22.2-1 -------------------- * Tue May 06 2008 - Bastien Nocera - 2.22.2-1 - Update to 2.22.2 livecd-tools-017-1.fc9 ---------------------- * Tue May 06 2008 Bill Nottingham - 017-1 - fix F9 final configs mkinitrd-6.0.52-2.fc9 --------------------- * Tue May 06 2008 Jeremy Katz - 6.0.52-2 - Require isomd5sum so that live images can be verified (#445284) pungi-1.2.18-1.fc9 ------------------ * Tue May 06 2008 Jesse Keating - 1.2.18-1 - Manifest change for F9, drop syslog-ng system-config-printer-0.7.82.2-4.fc9 ------------------------------------ * Tue May 06 2008 Tim Waugh 0.7.82.2-4 - Removed other upstream fixes introduced in 0.7.82.2-2. * Fri May 02 2008 Tim Waugh 0.7.82.2-3 - Back-ported authconn dialog for better authentication when running as a non-root user (bug #444306). - Don't install consolehelper bits any more as they are no longer needed. * Tue Apr 15 2008 Tim Waugh 0.7.82.2-2 - Some fixes from upstream: - Mark bad pt translation fuzzy. - applet: prevent duplicate error notifications (bug #442491). - applet: don't check for errors when starting. - my-default-printer: Prevent traceback (Ubuntu #214579). - main app: make the About dialog appear in the right place. udev-120-5.20080421git.fc9 -------------------------- * Tue May 06 2008 Harald Hoyer 120-5.20080421git - remove /dev/.udev in start_udev (bug #442827) xorg-x11-server-1.4.99.901-29.20080415.fc9 ------------------------------------------ * Tue May 06 2008 Bill Nottingham 1.4.99.901-29.20080415 - rebuild against new xorg-x11-xtrans-devel (#445303) * Mon May 05 2008 Adam Jackson 1.4.99.901-28.20080415 - xserver-1.5.0-compiz-clip-fix.patch: Make compiz stop blinking every so often. (#441219) * Mon May 05 2008 Adam Jackson 1.4.99.901-27.20080415 - xserver-1.5.0-hal-closedown.patch: Fix a crash in the hal code when closing a device. xorg-x11-xtrans-devel-1.1-2.fc9 ------------------------------- * Tue May 06 2008 Bill Nottingham 1.1-2 - xtrans-1.1-abstract.patch: Don't worry about making /tmp/.X11-unix (or failure to do so) if you're using an abstract socket (#445303) Broken deps for ppc64 ---------------------------------------------------------- livecd-tools-017-1.fc9.ppc64 requires yaboot perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot From hughsient at gmail.com Wed May 7 13:26:43 2008 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 07 May 2008 14:26:43 +0100 Subject: New system-config-acpid In-Reply-To: <20080506164446.GA14833@tango.0pointer.de> References: <48207BC5.3060105@redhat.com> <20080506164446.GA14833@tango.0pointer.de> Message-ID: <1210166803.4250.28.camel@hughsie-work> On Tue, 2008-05-06 at 18:44 +0200, Lennart Poettering wrote: > Uh? Actually the plan is to pass all ACPI key events through the Linux > input system, like any other keypresses, so that they can handled like > any other keypresses. If you look closely at /proc/bus/input/devices > you'll notice that this actually is alredy case. > > I am sorry, but what you are suggesting is, uh, kind of out-of-date. Agreed. I've been working hard on getting kernel drivers to push up key presses up through INPUT, rather than using ACPI or other insane files to report this to userspace. acpid has no role in a modern desktop; you shouldn't need to configure anything - it should just work. I really don't see the need for such a tool. Richard. From walters at verbum.org Wed May 7 14:02:59 2008 From: walters at verbum.org (Colin Walters) Date: Wed, 7 May 2008 10:02:59 -0400 Subject: maintainer groups Message-ID: Hi, I'd like to see more explicit support in Fedora for maintainership "groups". For example, I would love if I could have some of my random dependency Java packages be owned by something like "java-maint at fedoraproject.org". We already have some existing teams (gecko-maint, etc.) How do the current groups work? What's the process for creating new ones? From skvidal at fedoraproject.org Wed May 7 14:10:52 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 07 May 2008 10:10:52 -0400 Subject: maintainer groups In-Reply-To: References: Message-ID: <1210169452.12284.54.camel@cutter> On Wed, 2008-05-07 at 10:02 -0400, Colin Walters wrote: > Hi, > > I'd like to see more explicit support in Fedora for maintainership > "groups". For example, I would love if I could have some of my random > dependency Java packages be owned by something like > "java-maint at fedoraproject.org". We already have some existing teams > (gecko-maint, etc.) > > How do the current groups work? What's the process for creating new ones? All packages will be owned by an alias after F9 is released. We'll have packagename-owner at fedoraproject.org setup in the mail aliases which will expand out to all maintainer/co-maintainers of the package. -sv From zprikryl at redhat.com Wed May 7 14:14:11 2008 From: zprikryl at redhat.com (Zdenek Prikryl) Date: Wed, 07 May 2008 16:14:11 +0200 Subject: New system-config-acpid In-Reply-To: <1210157450.2755.102.camel@cookie.hadess.net> References: <48207BC5.3060105@redhat.com> <20080506154407.GA21822@nostromo.devel.redhat.com> <48215A3F.10806@redhat.com> <1210157450.2755.102.camel@cookie.hadess.net> Message-ID: <4821B933.2030001@redhat.com> Bastien Nocera napsal(a): >> Simple reason :-)... if you don't use gnome or kde or this applets, the >> simplest way how to get things work is configure this daemon. > > Not really. With HAL running, it should push the ACPI key events through > D-Bus. There's no need for a system-config-acpid or even using acpid. That is true, but you have to have an application or a daemon which would be listening on d-bus, don't you? >> On the other hand I agree, that better way is catch this events via HAL and then >> send it to d-bus. But in this case, again, you have to have this applets. AFAIK >> there is no "acpid" for dbus which you can configure for any acpi events (like >> Fn5 which should enable bluetooth). > > With the right keymap, all those events already trickle to X, so there > shouldn't ever be a need for acpid or a system-config-acpid, as there's > already enough hot-key handlers in X (such as the ones builtin to GNOME > and KDE). That is it "builtin to GNOME and KDE"... but there are a lot of users who don't use gnome or kde and it this case, as a user, you have two option a) try to install {gnome, kde}-applets b) configure it via other daemon like acpid (it could be other daemon or an application, but it has to be independent on a desktop environment). The question is, what is better, force users to use {gnome, kde}-applets or give then a choice to configure an action on an acpi events or hotkeys. > > Do we still install acpid by default? > These days, if you use gnome or kde I think that it is not necessary to install acpid. If you have another desktop environment, then you need a choice to get acpi thinks work. -- Zdenek Prikryl From berrange at redhat.com Wed May 7 14:15:38 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 7 May 2008 15:15:38 +0100 Subject: maintainer groups In-Reply-To: <1210169452.12284.54.camel@cutter> References: <1210169452.12284.54.camel@cutter> Message-ID: <20080507141538.GD2963@redhat.com> On Wed, May 07, 2008 at 10:10:52AM -0400, seth vidal wrote: > On Wed, 2008-05-07 at 10:02 -0400, Colin Walters wrote: > > Hi, > > > > I'd like to see more explicit support in Fedora for maintainership > > "groups". For example, I would love if I could have some of my random > > dependency Java packages be owned by something like > > "java-maint at fedoraproject.org". We already have some existing teams > > (gecko-maint, etc.) > > > > How do the current groups work? What's the process for creating new ones? > > All packages will be owned by an alias after F9 is released. > > We'll have packagename-owner at fedoraproject.org setup in the mail aliases > which will expand out to all maintainer/co-maintainers of the package. I hope that the BZ setup will still use explicit maintainer email addresses and not the alias - or at least automatically add all maintainers on the CC list for new bugs. If you have only the alias address on the BZ and a security bug is entered, then you as the maintainer won't have permission to see it, because BZ doesn't know the alias maps to your account. Your email address needs to be explicitly on the assigned / cc list to see such bugs. Regards, Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From zprikryl at redhat.com Wed May 7 14:20:23 2008 From: zprikryl at redhat.com (Zdenek Prikryl) Date: Wed, 07 May 2008 16:20:23 +0200 Subject: New system-config-acpid In-Reply-To: <20080506164446.GA14833@tango.0pointer.de> References: <48207BC5.3060105@redhat.com> <20080506164446.GA14833@tango.0pointer.de> Message-ID: <4821BAA7.3040602@redhat.com> Lennart Poettering napsal(a): > Uh? Actually the plan is to pass all ACPI key events through the Linux > input system, like any other keypresses, so that they can handled like > any other keypresses. If you look closely at /proc/bus/input/devices > you'll notice that this actually is alredy case. > > I am sorry, but what you are suggesting is, uh, kind of out-of-date. I don't suggest that everyone has to use acpid and s-c-a, I just tried to make a configuration of this daemon easier for users, who are using this daemon because they want to or they have to. -- Zdenek Prikryl From wjhns174 at hardakers.net Wed May 7 14:34:09 2008 From: wjhns174 at hardakers.net (Wes Hardaker) Date: Wed, 07 May 2008 07:34:09 -0700 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <1210128579.26792.254.camel@beck.corsepiu.local> (Ralf Corsepius's message of "Wed, 07 May 2008 04:49:39 +0200") References: <1209999548.32107.11.camel@kennedy> <870180fe0805052050pcac64e2x6377a65a59dce11c@mail.gmail.com> <1210128579.26792.254.camel@beck.corsepiu.local> Message-ID: >>>>> On Wed, 07 May 2008 04:49:39 +0200, Ralf Corsepius said: >> And thus, if we want developers to use fedora we should distribute >> multiple versions of the development tools when version updates have >> potentially large ramifications. RC> If you are serious about this, Fedora will have to ship alternatives for RC> all development tools. I think we're at an impasse. RC> The alternative is to push upstreams to "release often, release RC> early" and to keep the pace with tool development. Unless the upstream dies (which is one of the reasons for needing to start a forward port in the first place) or is simply slow (wayyy too common). I think someone else already made the point of all the packages we'd have to remove if we wanted to stick to your policy of removing everything old. There is a line to walk and unfortunately each of those 1000+ packages could probably generate a long-winded discussion like this one has become. -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett From bpepple at fedoraproject.org Wed May 7 14:30:12 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 07 May 2008 10:30:12 -0400 Subject: Maintainer Responsibility Policy In-Reply-To: <1210154821.25560.865.camel@pmac.infradead.org> References: <1210035695.6297.25.camel@kennedy> <482056BE.90100@n-dimensional.de> <48206A93.7020807@gmail.com> <1210089261.2961.3.camel@kennedy> <4820836D.7070008@gmail.com> <1210154821.25560.865.camel@pmac.infradead.org> Message-ID: <1210170612.27834.0.camel@kennedy> On Wed, 2008-05-07 at 11:07 +0100, David Woodhouse wrote: > I'm not sure that's strong enough. It should clearly state that the > package maintainer is responsible for getting bugs fixed -- if the > package maintainer isn't a coder, then they need to take a more > managerial r?le; working with upstream or with code-monkeys within > Fedora to get things fixed. How about this: > > If there are bugs which you aren't capable of fixing yourself because > they deal with intricacies of the source code which you don't fully > understand, then you still need to address these bugs. It can be helpful > to work with the upstream maintainer of the code, obtain help from more > code-oriented people on fedora-devel, or check other distributions for > patches. Always be sure to post to the bug report what you have done so > that the reporter knows what it happening and what to expect. > It is recommended that non-coder packagers should find co-maintainers > who are familiar with the programming language used by their package(s), > and can help with such bugs as a kind of 'second line support'. Added your suggestion. Thanks, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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: 197 bytes Desc: This is a digitally signed message part URL: From tim at niemueller.de Wed May 7 15:01:52 2008 From: tim at niemueller.de (Tim Niemueller) Date: Wed, 07 May 2008 17:01:52 +0200 Subject: Fedora Robotics SIG In-Reply-To: <481C3D68.8030306@niemueller.de> References: <481C3D68.8030306@niemueller.de> Message-ID: <4821C460.2010008@niemueller.de> Initial meeting starts now. If you want to join meet us on irc.freenode.org in channel #fedora-robotics. Tim -- Tim Niemueller www.niemueller.de ================================================================= Imagination is more important than knowledge. (Albert Einstein) From walters at verbum.org Wed May 7 15:02:19 2008 From: walters at verbum.org (Colin Walters) Date: Wed, 7 May 2008 11:02:19 -0400 Subject: maintainer groups In-Reply-To: <1210169452.12284.54.camel@cutter> References: <1210169452.12284.54.camel@cutter> Message-ID: On Wed, May 7, 2008 at 10:10 AM, seth vidal wrote: > > All packages will be owned by an alias after F9 is released. > > We'll have packagename-owner at fedoraproject.org setup in the mail aliases > which will expand out to all maintainer/co-maintainers of the package. That is useful, though I was looking for something that lets me operate on groups of packages rather than individual ones; again so the example is I'd like my Java packages to be owned by something like tag-java at packages.fp.o, and anyone in that group would get CC'd on bugs, could upload, etc. I guess this would require a tagging system for packages. From a.badger at gmail.com Wed May 7 15:06:22 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 07 May 2008 08:06:22 -0700 Subject: maintainer groups In-Reply-To: References: Message-ID: <4821C56E.9090102@gmail.com> Colin Walters wrote: > Hi, > > I'd like to see more explicit support in Fedora for maintainership > "groups". For example, I would love if I could have some of my random > dependency Java packages be owned by something like > "java-maint at fedoraproject.org". We already have some existing teams > (gecko-maint, etc.) > > How do the current groups work? What's the process for creating new ones? > The current implementation is that these groups are pseudo-users in the account system. It basically buys you an email alias that you can use for assigning bugzilla bugs to. To get one setup, ask me and I'll create it in FAS and migrate the pkgdb ownership. In the future we need to make these into true groups so that cvs acls can be applied to them. However, there's a few things that make that an invasive change: 1) have to teach the pkgdb that groups can own packages (since the reason for the current implementation is so bz ownership can be to a mailing list). 2) Create UI that allows people within a group to add the group as owner/comaintainer on a package. 3) Audit pkgdb and pkgdb dependent scripts to make sure they can handle groups as owners. -Toshio From a.badger at gmail.com Wed May 7 15:12:31 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 07 May 2008 08:12:31 -0700 Subject: maintainer groups In-Reply-To: References: <1210169452.12284.54.camel@cutter> Message-ID: <4821C6DF.8060400@gmail.com> Colin Walters wrote: > On Wed, May 7, 2008 at 10:10 AM, seth vidal wrote: >> All packages will be owned by an alias after F9 is released. >> >> We'll have packagename-owner at fedoraproject.org setup in the mail aliases >> which will expand out to all maintainer/co-maintainers of the package. > > That is useful, though I was looking for something that lets me > operate on groups of packages rather than individual ones; again so > the example is I'd like my Java packages to be owned by something like > tag-java at packages.fp.o, and anyone in that group would get CC'd on > bugs, could upload, etc. I guess this would require a tagging system > for packages. > I think a tagging system for packages and the specific operations you enumerate are separate. Having a tagging system would be useful as well. Or even a query language:: please set all packages named=java-* owned_by=user:walters to owned_by=group:java-maint This is a bit of blue sky, though, unless someone's interested in working on it. -Toshio From twoerner at redhat.com Wed May 7 15:17:57 2008 From: twoerner at redhat.com (Thomas Woerner) Date: Wed, 07 May 2008 17:17:57 +0200 Subject: New system-config-acpid In-Reply-To: <1210157450.2755.102.camel@cookie.hadess.net> References: <48207BC5.3060105@redhat.com> <20080506154407.GA21822@nostromo.devel.redhat.com> <48215A3F.10806@redhat.com> <1210157450.2755.102.camel@cookie.hadess.net> Message-ID: <4821C825.6060204@redhat.com> Bastien Nocera wrote: > On Wed, 2008-05-07 at 09:29 +0200, Zdenek Prikryl wrote: >> Bill Nottingham napsal(a): >>> Not to be a killjoy, but why a config tool for a program which should >>> probably die? Aren't these all better handled by user-specific policy >>> agents such as gnome-power-manager or kpowersave? >> Simple reason :-)... if you don't use gnome or kde or this applets, the simplest >> way how to get things work is configure this daemon. > > Not really. With HAL running, it should push the ACPI key events through > D-Bus. There's no need for a system-config-acpid or even using acpid. > >> On the other hand I agree, that better way is catch this events via HAL and then >> send it to d-bus. But in this case, again, you have to have this applets. AFAIK >> there is no "acpid" for dbus which you can configure for any acpi events (like >> Fn5 which should enable bluetooth). > > With the right keymap, all those events already trickle to X, so there > shouldn't ever be a need for acpid or a system-config-acpid, as there's > already enough hot-key handlers in X (such as the ones builtin to GNOME > and KDE). > Please also think about systems without a running X server: Yes, there are still some server installations out there. Fedora might be some kind of desktop system, but keep in mind that we also need a solution for EL. > Do we still install acpid by default? > Yes, and we should not drop it without having a replacement, which is 1) working without X 2) not contingent on any desktop environment 3) only configurable if you use a special desktop environment We need a solution for this, the machine has to react in the same manner on acpi events with and without a desktop environment. There should also be a configuration tool for a server environment: A tray-applet is not a solution here, because there is no X and no tray. Thomas From ruben at rubenkerkhof.com Wed May 7 15:33:37 2008 From: ruben at rubenkerkhof.com (Ruben Kerkhof) Date: Wed, 7 May 2008 17:33:37 +0200 Subject: Fedora Package Status of May 3, 2008 In-Reply-To: <20080507112103.7ef5a90e@ludwig-alpha.unil.ch> References: <20080503010742.1b41ccab@ludwig-alpha.unil.ch> <90203CE9-21FF-45FC-8201-CEA068C8E06C@rubenkerkhof.com> <20080507112103.7ef5a90e@ludwig-alpha.unil.ch> Message-ID: <1F2D94E4-84FC-44F3-A6A1-0D1E114559FD@rubenkerkhof.com> On 7 mei 2008, at 11:21, Christian Iseli wrote: > On Wed, 7 May 2008 09:06:50 +0200, Ruben Kerkhof wrote: >> mogilefs-server was renamed in cvs to perl-mogilefs-server, so I'm >> not sure why this shows up. > > You should file a request with rel-eng that they remove the old > version > from the repo. > > Cheers, > C It's gone now, thanks. -Ruben From notting at redhat.com Wed May 7 15:58:33 2008 From: notting at redhat.com (Bill Nottingham) Date: Wed, 7 May 2008 11:58:33 -0400 Subject: New system-config-acpid In-Reply-To: <1210157450.2755.102.camel@cookie.hadess.net> References: <48207BC5.3060105@redhat.com> <20080506154407.GA21822@nostromo.devel.redhat.com> <48215A3F.10806@redhat.com> <1210157450.2755.102.camel@cookie.hadess.net> Message-ID: <20080507155833.GC8734@nostromo.devel.redhat.com> Bastien Nocera (bnocera at redhat.com) said: > Do we still install acpid by default? Not on the Desktop livecd; yes on some other installs. Bill From hughsient at gmail.com Wed May 7 16:48:52 2008 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 07 May 2008 17:48:52 +0100 Subject: New system-config-acpid In-Reply-To: <4821B933.2030001@redhat.com> References: <48207BC5.3060105@redhat.com> <20080506154407.GA21822@nostromo.devel.redhat.com> <48215A3F.10806@redhat.com> <1210157450.2755.102.camel@cookie.hadess.net> <4821B933.2030001@redhat.com> Message-ID: <1210178932.4250.68.camel@hughsie-work> On Wed, 2008-05-07 at 16:14 +0200, Zdenek Prikryl wrote: > That is true, but you have to have an application or a daemon which > would be listening on d-bus, don't you? Yes, and it's a few lines of python. This would also work on PPC - where acpid won't work for obvious reasons. Richard. From nicolas.mailhot at laposte.net Wed May 7 17:07:16 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 07 May 2008 19:07:16 +0200 Subject: maintainer groups In-Reply-To: References: <1210169452.12284.54.camel@cutter> Message-ID: <1210180036.24805.6.camel@rousalka.okg> Le mercredi 07 mai 2008 ? 11:02 -0400, Colin Walters a ?crit : > That is useful, though I was looking for something that lets me > operate on groups of packages rather than individual ones; again so > the example is I'd like my Java packages to be owned by something like > tag-java at packages.fp.o, and anyone in that group would get CC'd on > bugs, could upload, etc. I guess this would require a tagging system > for packages. For the font SIG, we have a somewhat weaker setup where a mailing list is CC-ed on a lot of package activity by default. That's somewhat sufficient for interested packagers to keep in touch without needing to collect the info all over the place themselves (still need to find out how to CC this list on all changes in the SIG wiki place, esp. the WishList changes) http://news.gmane.org/gmane.linux.redhat.fedora.fonts.bugs http://fedoraproject.org/wiki/SIGs/Fonts/QA/Bugs Amazing what you can do with just a list address. -- 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 Wed May 7 17:10:22 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 7 May 2008 09:10:22 -0800 Subject: Maintainer Responsibility Policy In-Reply-To: <1210154821.25560.865.camel@pmac.infradead.org> References: <1210035695.6297.25.camel@kennedy> <482056BE.90100@n-dimensional.de> <48206A93.7020807@gmail.com> <1210089261.2961.3.camel@kennedy> <4820836D.7070008@gmail.com> <1210154821.25560.865.camel@pmac.infradead.org> Message-ID: <604aa7910805071010u411b4bd0h4932981766d525ee@mail.gmail.com> On Wed, May 7, 2008 at 2:07 AM, David Woodhouse wrote: > I'm not sure that's strong enough. It should clearly state that the > package maintainer is responsible for getting bugs fixed -- if the > package maintainer isn't a coder, then they need to take a more > managerial r?le; working with upstream or with code-monkeys within > Fedora to get things fixed. How about this: Do we need to make an effort to catalog skillsets in the contributor base? to make it easier to help maintainers find a particular sort of code-monkey? For example I know you are one of the people I can come to with ppc oddness that I can't fix myself, but I'd have no idea how to turn to for say ruby-ness. But generally speaking would it be worthwhile if 'we' made it easier for maintainers to find other contributors who could help with specific bugs based on skillset needed? -jef"And yes i realize we can't really call people code-monkeys"spaleta From rc040203 at freenet.de Wed May 7 04:53:10 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 07 May 2008 06:53:10 +0200 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: References: <1209999548.32107.11.camel@kennedy> <481F2986.8010509@redhat.com> <1210002669.26792.65.camel@beck.corsepiu.local> <481FD064.6050307@ncsu.edu> <1210045081.4658.7.camel@localhost.localdomain> <481FD3D5.5070206@ncsu.edu> <1210071473.29415.128.camel@localhost.localdomain> <48203FF0.70205@kanarip.com> <48206323.9060300@gmail.com> <48207847.70308@kanarip.com> <482081AB.4020804@gmail.com> Message-ID: <1210135990.26792.327.camel@beck.corsepiu.local> On Tue, 2008-05-06 at 11:15 -0500, Jason L Tibbitts III wrote: > >>>>> "TK" == Toshio Kuratomi writes: > > TK> Despite incompatibilities, some packages will generate correct > TK> Makefiles whether you use automake-1.4 or automake-1.9. > > I guess the real question, then, is how to tell that the shiny new > automake version has produced an incorrect makefile. Correct. > Are the failures > obvious, or do you build it and hope that it doesn't fail silently > later? All of it. Fact is, automake breakdowns are _rare_, because automake is pretty strict about its input files. More common are cases where modern automakes complain and diagnose issues in input files, older automakes silently had swallowed (Sometimes these are real bugs, sometimes these are side-effects from automake having tightened its syntax). Much more critical is autoconf ... There have been quite a few cases of it silently breaking "once known to work" configure scripts during autoconf-2.13 -> autoconf-2.50 transition. Ralf From dbhole at redhat.com Wed May 7 18:29:19 2008 From: dbhole at redhat.com (Deepak Bhole) Date: Wed, 7 May 2008 14:29:19 -0400 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: References: Message-ID: <20080507182919.GB8099@redhat.com> * Jason L Tibbitts III [2008-04-09 12:37]: > Meeting minutes and full logs of the packaging committee meeting which > occurred on 2008-04-08 are online: > > http://fedoraproject.org/wiki/Packaging/Minutes > http://fedoraproject.org/wiki/Packaging/Minutes20080408 > > > * Revisiting the jpackagage naming exception > * The original exception is at > http://fedoraproject.org/wiki/Packaging/JPackagePolicy; the > committee is revisiting the exception. > * The committee requests from the Java group "a list of information > as to why they need the jpp tag, specifically, how they're using > it, by May 8th." The committee will revisit the issue then. > * Accepted (5 - 0) > * Voting for: tibbs abadger1999 spot rdieter hansg > A page detailing the reasons for keeping the exception is now up on the wiki: http://fedoraproject.org/wiki/DeepakBhole/ReasonsForKeepingJPP Deepak From tibbs at math.uh.edu Wed May 7 18:42:57 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 07 May 2008 13:42:57 -0500 Subject: Summary of the 2008-05-06 Packaging Committee meeting Message-ID: Meeting minutes and full logs of the packaging committee meeting which occurred on 2008-05-06 are online: http://fedoraproject.org/wiki/Packaging/Minutes http://fedoraproject.org/wiki/Packaging/Minutes20080506 Issues pending FESCO ratification: * Tracking the upstream status of patches * http://fedoraproject.org/wiki/PackagingDrafts/PatchUpstreamStatus * A new draft this week. * Accepted (5 - 1) * Mandatory verification of desktop files * http://fedoraproject.org/wiki/PackagingDrafts/DesktopVerify * A new draft this week, modifying the existing guidelines. * Accepted (6 - 0) Misc business: We're still trying to work out a meeting time that works well for all committee members. The current proposal is to move it two hours earlier, but subsequent discussion via email has shown that not to be viable. - J< From rjones at redhat.com Wed May 7 19:38:15 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 7 May 2008 20:38:15 +0100 Subject: maintainer groups In-Reply-To: <1210180036.24805.6.camel@rousalka.okg> References: <1210169452.12284.54.camel@cutter> <1210180036.24805.6.camel@rousalka.okg> Message-ID: <20080507193815.GA26401@amd.home.annexia.org> On Wed, May 07, 2008 at 07:07:16PM +0200, Nicolas Mailhot wrote: > Le mercredi 07 mai 2008 ? 11:02 -0400, Colin Walters a ?crit : > > That is useful, though I was looking for something that lets me > > operate on groups of packages rather than individual ones; again so > > the example is I'd like my Java packages to be owned by something like > > tag-java at packages.fp.o, and anyone in that group would get CC'd on > > bugs, could upload, etc. I guess this would require a tagging system > > for packages. > > For the font SIG, we have a somewhat weaker setup where a mailing list > is CC-ed on a lot of package activity by default. That's somewhat > sufficient for interested packagers to keep in touch without needing to > collect the info all over the place themselves (still need to find out > how to CC this list on all changes in the SIG wiki place, esp. the > WishList changes) > > http://news.gmane.org/gmane.linux.redhat.fedora.fonts.bugs > http://fedoraproject.org/wiki/SIGs/Fonts/QA/Bugs That's interesting, thanks. OCaml needs the same. FWIW Debian's OCaml group has a mailing list where all bugs for those packages get assigned by default to the mailing list address. It works well. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From greno at verizon.net Wed May 7 20:58:14 2008 From: greno at verizon.net (Gerry Reno) Date: Wed, 07 May 2008 16:58:14 -0400 Subject: F9 and bridged networking Message-ID: <482217E6.3050100@verizon.net> Is there some new-fangled way to get bridged networking working with F9? I put my bridge in /etc/network/interfaces and restart networking and no bridge. ============== if auto, lo iface lo ... auto br0 ... iface eth0 ... ============== ???? Regards, Gerry From mark.bidewell at alumni.clemson.edu Wed May 7 21:01:43 2008 From: mark.bidewell at alumni.clemson.edu (Mark Bidewell) Date: Wed, 7 May 2008 17:01:43 -0400 Subject: F9 and bridged networking In-Reply-To: <482217E6.3050100@verizon.net> References: <482217E6.3050100@verizon.net> Message-ID: On Wed, May 7, 2008 at 4:58 PM, Gerry Reno wrote: > Is there some new-fangled way to get bridged networking working with F9? > > I put my bridge in /etc/network/interfaces and restart networking and no > bridge. > > ============== > if auto, lo > > iface lo > ... > > auto br0 > ... > > iface eth0 > ... > ============== > > > ???? > > Regards, > Gerry > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Make sure NetworkManager is disabled and you use the old "network" service. This is how I got it working. -------------- next part -------------- An HTML attachment was scrubbed... URL: From surenkarapetyan at gmail.com Wed May 7 21:06:46 2008 From: surenkarapetyan at gmail.com (Suren Karapetyan) Date: Thu, 08 May 2008 02:06:46 +0500 Subject: F9 and bridged networking In-Reply-To: <482217E6.3050100@verizon.net> References: <482217E6.3050100@verizon.net> Message-ID: <482219E6.6020403@gmail.com> Gerry Reno wrote: > Is there some new-fangled way to get bridged networking working with F9? > > I put my bridge in /etc/network/interfaces and restart networking and > no bridge. Where? :) > > ============== > if auto, lo > > iface lo > ... > > auto br0 > ... > > iface eth0 > ... > ============== > I see You come from Debian land. I had the same problem as You a few days ago when I tried to install a Debian router for the first time in my life. I just couldn't understand where should I put iptables rules and where is /etc/network-scripts/ifcfg-eth0 :) It took me 30 minutes of googling and reading to gain some good understanding of how Debian does network. You can do the same (google). Here is how to do bridging RedHat-way: http://tomdeb.org/node/1181 > > ???? > > Regards, > Gerry > From greno at verizon.net Wed May 7 21:07:35 2008 From: greno at verizon.net (Gerry Reno) Date: Wed, 07 May 2008 17:07:35 -0400 Subject: F9 and bridged networking In-Reply-To: References: <482217E6.3050100@verizon.net> Message-ID: <48221A17.7080805@verizon.net> Mark Bidewell wrote: > > Make sure NetworkManager is disabled and you use the old "network" > service. This is how I got it working. I'm really beginning to hate this NetworkManager. First, it randomly wipes out /etc/resolv.conf, then if fails to run early enough during boot sequence so that you can mount remote NFS directories from /etc/rc.local, so I resetpriorities on it so that it takes its priorities from its init file and after that then the shutdown hangs at 'Turning off quotas', and now NetworkManager wrecks network bridging. yum removeforever NetworkManager Regards, Gerry From rdieter at math.unl.edu Wed May 7 21:11:56 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 07 May 2008 16:11:56 -0500 Subject: F9 and bridged networking References: <482217E6.3050100@verizon.net> <48221A17.7080805@verizon.net> Message-ID: Gerry Reno wrote: > Mark Bidewell wrote: >> >> Make sure NetworkManager is disabled and you use the old "network" >> service. This is how I got it working. > I'm really beginning to hate this NetworkManager. First, it randomly > wipes out /etc/resolv.conf, then if fails to run early enough during > boot sequence so that you can mount remote NFS directories from > /etc/rc.local, Add to /etc/sysconfig/network: NETWORKWAIT=yes -- Rex From greno at verizon.net Wed May 7 21:30:48 2008 From: greno at verizon.net (Gerry Reno) Date: Wed, 07 May 2008 17:30:48 -0400 Subject: F9 and bridged networking In-Reply-To: <482219E6.6020403@gmail.com> References: <482217E6.3050100@verizon.net> <482219E6.6020403@gmail.com> Message-ID: <48221F88.90305@verizon.net> Ok, I put the bridge in ifcfg-br0, and create ifcfg-eth0/1 files as shown and still it does not work with NetworkManager. I have no br0 device. Going to try removing NetworkManager next. Regards, Gerry From wtogami at redhat.com Wed May 7 21:42:22 2008 From: wtogami at redhat.com (Warren Togami) Date: Wed, 07 May 2008 17:42:22 -0400 Subject: F9 and bridged networking In-Reply-To: <48221F88.90305@verizon.net> References: <482217E6.3050100@verizon.net> <482219E6.6020403@gmail.com> <48221F88.90305@verizon.net> Message-ID: <4822223E.80407@redhat.com> Gerry Reno wrote: > Ok, I put the bridge in ifcfg-br0, and create ifcfg-eth0/1 files as > shown and still it does not work with NetworkManager. I have no br0 > device. Going to try removing NetworkManager next. > > Regards, > Gerry > I'm pretty upset NetworkManager doesn't handle bridge interfaces yet too. I'm told that NetworkManager will eventually need to support this and everything else service network used to do. During this transitional phase if you really want missing features then you need to turn on service network. It is possible with the right configuration options to use both service network and NetworkManager simultaneously. Warren From czar at czarc.net Wed May 7 21:56:03 2008 From: czar at czarc.net (Gene C.) Date: Wed, 7 May 2008 17:56:03 -0400 Subject: F9 and bridged networking In-Reply-To: <4822223E.80407@redhat.com> References: <482217E6.3050100@verizon.net> <48221F88.90305@verizon.net> <4822223E.80407@redhat.com> Message-ID: <200805071756.03171.czar@czarc.net> On Wednesday 07 May 2008 17:42:22 Warren Togami wrote: > Gerry Reno wrote: > > Ok, I put the bridge in ifcfg-br0, and create ifcfg-eth0/1 files as > > shown and still it does not work with NetworkManager. ?I have no br0 > > device. ?Going to try removing NetworkManager next. > > > > Regards, > > Gerry > > I'm pretty upset NetworkManager doesn't handle bridge interfaces yet > too. ?I'm told that NetworkManager will eventually need to support this > and everything else service network used to do. ?During this > transitional phase if you really want missing features then you need to > turn on service network. > > It is possible with the right configuration options to use both service > network and NetworkManager simultaneously. Yes, I have been able to run both NetworkManager and "the old way" at the same time. Unless the ifcfg file for a device is marked NM_CONTROLLED=yes, NetworkManager leaves it alone and the "old" system seems to leave NM_CONTROLLED=yes devices alone but you can use it to manage the other devices. There seems to have been a spurt of development/fix activity recently and (to me) NetworkManager is looking better (but still has some work to do). The only problem I have had is that using s-c-network to turn NM_CONTROLLED on or off (yes or no) is NOT detected by nm-system-settings whereas using vi to make the change is detected. Yes, this is bz'ed and I am waiting to see what the package manager/developer wants me to do ... https://bugzilla.redhat.com/show_bug.cgi?id=444502 -- Gene From greno at verizon.net Wed May 7 22:14:18 2008 From: greno at verizon.net (Gerry Reno) Date: Wed, 07 May 2008 18:14:18 -0400 Subject: F9 and bridged networking In-Reply-To: <200805071756.03171.czar@czarc.net> References: <482217E6.3050100@verizon.net> <48221F88.90305@verizon.net> <4822223E.80407@redhat.com> <200805071756.03171.czar@czarc.net> Message-ID: <482229BA.5030706@verizon.net> Gene C. wrote: >> It is possible with the right configuration options to use both service >> network and NetworkManager simultaneously. >> I tried this already and I was not able to make the two services work together. eg: when I put my NFS mounting into rc.local and had both services chkconfig on when it would boot up my NFS mounts would succeed but then at login NM would have no connections. I played with this for quite a while and never could get it working with both of them. So eventually I saw that NM was S99 by default so I reset priorities to what is in its init file and then I could shut off network service and just use NM. But now without bridging, I think I might have to go back to old network service especially because NM is randomly erasing /etc/resolv.conf and then apps fail. Regards, Gerry From bpepple at fedoraproject.org Wed May 7 22:53:45 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 07 May 2008 18:53:45 -0400 Subject: Plan for tomorrows (20080508) FESCO meeting Message-ID: <1210200825.6018.3.camel@kennedy> Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC in #fedora-meeting on irc.freenode.org: /topic FESCo meeting -- Any objection to this week's report from FPC at https://www.redhat.com/archives/fedora-devel-list/2008-May/msg00637.html /topic FESCO-Meeting -- sponsor nominations - Denis Leroy (denis) /topic FESCo-Meeting -- sponsor nominations - Jef Spaleta (spoleeba) /topic FESCo-Meeting -- sponsor nominations - Douglas Warner (silfreed) /topic FESCo-Meeting -- Proposal to block old version of automake & autoconf - Karsten Hopp /topic FESCo meeting -- http://fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy -- bpepple /topic FESCo-Meeting -- F9 - any issues needing discussion? - all /topic FESCo meeting -- Free discussion around Fedora You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule. You can also propose topics in the meeting while it is in the "Free discussion around Fedora" phase. If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing... Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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: 197 bytes Desc: This is a digitally signed message part URL: From ndbecker2 at gmail.com Thu May 8 01:17:12 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Wed, 07 May 2008 21:17:12 -0400 Subject: nscd missing from bugzilla? Message-ID: I can't find an entry for nscd: rpm -qf /usr/sbin/nscd nscd-2.8-3.x86_64 I wanted to report frequent segfaults: May 7 21:07:21 nbecker1 kernel: nscd[10373]: segfault at 14 ip 7fbad1c8160b sp 41d36bc0 error 4 in nscd[7fbad1c6f000+1e000] From wtogami at redhat.com Thu May 8 01:19:39 2008 From: wtogami at redhat.com (Warren Togami) Date: Wed, 07 May 2008 21:19:39 -0400 Subject: nscd missing from bugzilla? In-Reply-To: References: Message-ID: <4822552B.8020209@redhat.com> Neal Becker wrote: > I can't find an entry for nscd: > rpm -qf /usr/sbin/nscd > nscd-2.8-3.x86_64 > > I wanted to report frequent segfaults: > May 7 21:07:21 nbecker1 kernel: nscd[10373]: segfault at 14 ip 7fbad1c8160b > sp 41d36bc0 error 4 in nscd[7fbad1c6f000+1e000] > rpm -qi nscd From greno at verizon.net Thu May 8 01:33:03 2008 From: greno at verizon.net (Gerry Reno) Date: Wed, 07 May 2008 21:33:03 -0400 Subject: F9 and KVM Message-ID: <4822584F.4010504@verizon.net> I tried getting one of my KVM VM's running under F9 but I'm getting this error: libvir: QEMU error : internal error Cannot find QEMU binary /usr/bin/kvm: No such file or directory error: Failed to start domain MX_1 ====================================================== [root at grp-01-10-01 MX_1]# virsh Welcome to virsh, the virtualization interactive terminal. Type: 'help' for help with commands 'quit' to quit virsh # list --all Id Name State ---------------------------------- - MX_1 shut off virsh # start MX_1 libvir: QEMU error : internal error Cannot find QEMU binary /usr/bin/kvm: No such file or directory error: Failed to start domain MX_1 virsh # quit [root at grp-01-10-01 MX_1]# yum list '*kvm*' Loaded plugins: fastestmirror, refresh-packagekit Loading mirror speeds from cached hostfile * updates: www.gtlib.gatech.edu * fedora: www.gtlib.gatech.edu Installed Packages kvm.i386 65-1.fc9 installed [root at grp-01-10-01 MX_1]# which kvm /usr/bin/which: no kvm in (/usr/kerberos/sbin:/usr/kerberos/bin:/usr/lib/ccache:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin) ====================================================== Is there another package that has the kvm binary? Regards, Gerry From a.badger at gmail.com Thu May 8 01:49:27 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 07 May 2008 18:49:27 -0700 Subject: nscd missing from bugzilla? In-Reply-To: References: Message-ID: <48225C27.1020105@gmail.com> Neal Becker wrote: > I can't find an entry for nscd: nscd is built from glibc so report it under glibc. rpm -qif /usr/sbin/nscd |grep -i 'Source RPM' Group : System Environment/Daemons Source RPM: glibc-2.7-2.src.rpm -Toshio From tcallawa at redhat.com Thu May 8 01:57:16 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 07 May 2008 21:57:16 -0400 Subject: Plan for tomorrows (20080508) FESCO meeting In-Reply-To: <1210200825.6018.3.camel@kennedy> References: <1210200825.6018.3.camel@kennedy> Message-ID: <1210211836.15217.148.camel@localhost.localdomain> On Wed, 2008-05-07 at 18:53 -0400, Brian Pepple wrote: > Please find below the list of topics that are likely to come up in the > next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC > in #fedora-meeting on irc.freenode.org: Unfortunately, I will be absent for tomorrows meeting, I will be in transit to North Carolina. ~spot From jkeating at redhat.com Thu May 8 01:59:11 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 07 May 2008 21:59:11 -0400 Subject: F9 and KVM In-Reply-To: <4822584F.4010504@verizon.net> References: <4822584F.4010504@verizon.net> Message-ID: <1210211951.5112.48.camel@localhost.localdomain> On Wed, 2008-05-07 at 21:33 -0400, Gerry Reno wrote: > Is there another package that has the kvm binary? Kvm package provides qemu-kvm, nothing provides /usr/bin/kvm What's looking for it again? -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From greno at verizon.net Thu May 8 02:02:42 2008 From: greno at verizon.net (Gerry Reno) Date: Wed, 07 May 2008 22:02:42 -0400 Subject: F9 and KVM In-Reply-To: <1210211951.5112.48.camel@localhost.localdomain> References: <4822584F.4010504@verizon.net> <1210211951.5112.48.camel@localhost.localdomain> Message-ID: <48225F42.1080203@verizon.net> Jesse Keating wrote: > On Wed, 2008-05-07 at 21:33 -0400, Gerry Reno wrote: > >> Is there another package that has the kvm binary? >> > > Kvm package provides qemu-kvm, nothing provides /usr/bin/kvm What's > looking for it again? > > Both virt-manager and virsh error out when trying to start a KVM image. Regards, Gerry From jkeating at redhat.com Thu May 8 02:11:00 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 07 May 2008 22:11:00 -0400 Subject: F9 and KVM In-Reply-To: <48225F42.1080203@verizon.net> References: <4822584F.4010504@verizon.net> <1210211951.5112.48.camel@localhost.localdomain> <48225F42.1080203@verizon.net> Message-ID: <1210212660.5112.50.camel@localhost.localdomain> On Wed, 2008-05-07 at 22:02 -0400, Gerry Reno wrote: > Both virt-manager and virsh error out when trying to start a KVM > image. That's... strange. I use virt-install and virt-manager all the time to start kvm guests... What version of libvirt do you have installed and running? -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From greno at verizon.net Thu May 8 02:14:53 2008 From: greno at verizon.net (Gerry Reno) Date: Wed, 07 May 2008 22:14:53 -0400 Subject: F9 and KVM In-Reply-To: <1210212660.5112.50.camel@localhost.localdomain> References: <4822584F.4010504@verizon.net> <1210211951.5112.48.camel@localhost.localdomain> <48225F42.1080203@verizon.net> <1210212660.5112.50.camel@localhost.localdomain> Message-ID: <4822621D.9050007@verizon.net> Jesse Keating wrote: > On Wed, 2008-05-07 at 22:02 -0400, Gerry Reno wrote: > >> Both virt-manager and virsh error out when trying to start a KVM >> image. >> > > That's... strange. I use virt-install and virt-manager all the time to > start kvm guests... What version of libvirt do you have installed and > running? > > [root at grp-01-10-01 ~]# yum list libvirt Loaded plugins: fastestmirror, refresh-packagekit Loading mirror speeds from cached hostfile * updates: www.gtlib.gatech.edu * fedora: www.gtlib.gatech.edu updates | 2.4 kB 00:00 Not using downloaded repomd.xml because it is older than what we have fedora | 2.4 kB 00:00 Not using downloaded repomd.xml because it is older than what we have Installed Packages libvirt.i386 0.4.2-1.fc9 installed Regards, Gerry -------------- next part -------------- An HTML attachment was scrubbed... URL: From greno at verizon.net Thu May 8 02:21:01 2008 From: greno at verizon.net (Gerry Reno) Date: Wed, 07 May 2008 22:21:01 -0400 Subject: F9 and KVM In-Reply-To: <4822621D.9050007@verizon.net> References: <4822584F.4010504@verizon.net> <1210211951.5112.48.camel@localhost.localdomain> <48225F42.1080203@verizon.net> <1210212660.5112.50.camel@localhost.localdomain> <4822621D.9050007@verizon.net> Message-ID: <4822638D.4020008@verizon.net> kernel looks ok: [root at grp-01-10-01 ~]# modprobe -l | grep kvm /lib/modules/2.6.25-14.fc9.i686/kernel/arch/x86/kvm/kvm-amd.ko /lib/modules/2.6.25-14.fc9.i686/kernel/arch/x86/kvm/kvm-intel.ko /lib/modules/2.6.25-14.fc9.i686/kernel/arch/x86/kvm/kvm.ko Regards, Gerry From jkeating at redhat.com Thu May 8 02:40:32 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 07 May 2008 22:40:32 -0400 Subject: F9 and KVM In-Reply-To: <4822584F.4010504@verizon.net> References: <4822584F.4010504@verizon.net> Message-ID: <1210214432.5112.53.camel@localhost.localdomain> On Wed, 2008-05-07 at 21:33 -0400, Gerry Reno wrote: > I tried getting one of my KVM VM's running under F9 but I'm getting > this > error: > > libvir: QEMU error : internal error Cannot find QEMU binary > /usr/bin/kvm: No such file or directory > error: Failed to start domain MX_1 When/where was this vm created? I'd imagine that the xml file describing it in /etc/libvirt/* incorrectly lists the emulator. /etc/libvirt/qemu/rawhide.xml: /etc/libvirt/qemu/rawhide.xml: /usr/bin/qemu-kvm -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From greno at verizon.net Thu May 8 02:51:41 2008 From: greno at verizon.net (Gerry Reno) Date: Wed, 07 May 2008 22:51:41 -0400 Subject: F9 and KVM In-Reply-To: <1210214432.5112.53.camel@localhost.localdomain> References: <4822584F.4010504@verizon.net> <1210214432.5112.53.camel@localhost.localdomain> Message-ID: <48226ABD.6000302@verizon.net> Jesse Keating wrote: > On Wed, 2008-05-07 at 21:33 -0400, Gerry Reno wrote: > >> I tried getting one of my KVM VM's running under F9 but I'm getting >> this >> error: >> >> libvir: QEMU error : internal error Cannot find QEMU binary >> /usr/bin/kvm: No such file or directory >> error: Failed to start domain MX_1 >> > > When/where was this vm created? I'd imagine that the xml file > describing it in /etc/libvirt/* incorrectly lists the emulator. > > /etc/libvirt/qemu/rawhide.xml: > /etc/libvirt/qemu/rawhide.xml: /usr/bin/qemu-kvm > > > I checked and yes, the emulator lists /usr/bin/kvm: /usr/bin/kvm What should emulator be now if not kvm? The xml was built from an original vmware vmx file using a utility that I have, vmware2libvirt. The string in it for emulator is: emulator = "kvm" Regards, Gerry From greno at verizon.net Thu May 8 02:54:10 2008 From: greno at verizon.net (Gerry Reno) Date: Wed, 07 May 2008 22:54:10 -0400 Subject: F9 and KVM In-Reply-To: <48226ABD.6000302@verizon.net> References: <4822584F.4010504@verizon.net> <1210214432.5112.53.camel@localhost.localdomain> <48226ABD.6000302@verizon.net> Message-ID: <48226B52.7090907@verizon.net> Gerry Reno wrote: > Jesse Keating wrote: >> On Wed, 2008-05-07 at 21:33 -0400, Gerry Reno wrote: >> >>> I tried getting one of my KVM VM's running under F9 but I'm getting >>> this error: >>> >>> libvir: QEMU error : internal error Cannot find QEMU binary >>> /usr/bin/kvm: No such file or directory >>> error: Failed to start domain MX_1 >>> >> >> When/where was this vm created? I'd imagine that the xml file >> describing it in /etc/libvirt/* incorrectly lists the emulator. >> >> /etc/libvirt/qemu/rawhide.xml: >> /etc/libvirt/qemu/rawhide.xml: /usr/bin/qemu-kvm >> >> >> > I checked and yes, the emulator lists /usr/bin/kvm: > /usr/bin/kvm > > What should emulator be now if not kvm? Oops, I see it: qemu-kvm. Regards, Gerry From greno at verizon.net Thu May 8 03:12:49 2008 From: greno at verizon.net (Gerry Reno) Date: Wed, 07 May 2008 23:12:49 -0400 Subject: F9 and KVM In-Reply-To: <48226B52.7090907@verizon.net> References: <4822584F.4010504@verizon.net> <1210214432.5112.53.camel@localhost.localdomain> <48226ABD.6000302@verizon.net> <48226B52.7090907@verizon.net> Message-ID: <48226FB1.9060401@verizon.net> Thanks Jesse, that got it running. I gave it 4 vcpus but it is running at near 0% cpu at snail's pace so I need to investigate what the problem is with the multi-cpus. Regards, Gerry From greno at verizon.net Thu May 8 03:43:13 2008 From: greno at verizon.net (Gerry Reno) Date: Wed, 07 May 2008 23:43:13 -0400 Subject: F9 and KVM In-Reply-To: <48226FB1.9060401@verizon.net> References: <4822584F.4010504@verizon.net> <1210214432.5112.53.camel@localhost.localdomain> <48226ABD.6000302@verizon.net> <48226B52.7090907@verizon.net> <48226FB1.9060401@verizon.net> Message-ID: <482276D1.9000502@verizon.net> KVM is not usable under F9. I tried with 1 to 4 cpus and they all run incredibly slow. Like 10 mins. between each step in the boot sequence. Something is really wrong. Regards, Gerry From jkeating at redhat.com Thu May 8 03:48:18 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 07 May 2008 23:48:18 -0400 Subject: F9 and KVM In-Reply-To: <482276D1.9000502@verizon.net> References: <4822584F.4010504@verizon.net> <1210214432.5112.53.camel@localhost.localdomain> <48226ABD.6000302@verizon.net> <48226B52.7090907@verizon.net> <48226FB1.9060401@verizon.net> <482276D1.9000502@verizon.net> Message-ID: <1210218498.5112.57.camel@localhost.localdomain> On Wed, 2008-05-07 at 23:43 -0400, Gerry Reno wrote: > KVM is not usable under F9. I tried with 1 to 4 cpus and they all run > incredibly slow. Like 10 mins. between each step in the boot sequence. > Something is really wrong. You should really stop making claims like "not usable in F9" when you haven't gotten any conformation that anybody other than you are experiencing these issues. A) Are you sure the kvm module is loaded into your kernel? B) Have you tried creating a new guest directly via lib-virt rather than using a conversion tool? C) Using a fresh virtual disk image for B I and many other people have been using KVM with Fedora 9 for well the entirety of the development cycle. It is extremely usable. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From rc040203 at freenet.de Wed May 7 12:37:00 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 07 May 2008 14:37:00 +0200 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: References: <1209999548.32107.11.camel@kennedy> <481F2986.8010509@redhat.com> <1210002669.26792.65.camel@beck.corsepiu.local> <481FD064.6050307@ncsu.edu> <1210045081.4658.7.camel@localhost.localdomain> <1210135175.26792.313.camel@beck.corsepiu.local> Message-ID: <1210163820.26792.413.camel@beck.corsepiu.local> On Wed, 2008-05-07 at 07:58 -0400, Colin Walters wrote: > On Wed, May 7, 2008 at 12:39 AM, Ralf Corsepius wrote: > > > > That's the core points the autotools are after and upstreams should be > > after - Of cause, these aspects are not of much importance if your > > target audience is Linux-only. > > Ralf, there are many more important things to work on. End user > visible impact of everyone spending time mucking with build systems: 0 May-be on the isolate island planet of RH ... It might be inconvenient news to you, but there is more than Fedora. From greno at verizon.net Thu May 8 03:57:55 2008 From: greno at verizon.net (Gerry Reno) Date: Wed, 07 May 2008 23:57:55 -0400 Subject: F9 and KVM In-Reply-To: <1210218498.5112.57.camel@localhost.localdomain> References: <4822584F.4010504@verizon.net> <1210214432.5112.53.camel@localhost.localdomain> <48226ABD.6000302@verizon.net> <48226B52.7090907@verizon.net> <48226FB1.9060401@verizon.net> <482276D1.9000502@verizon.net> <1210218498.5112.57.camel@localhost.localdomain> Message-ID: <48227A43.6010409@verizon.net> Jesse Keating wrote: > On Wed, 2008-05-07 at 23:43 -0400, Gerry Reno wrote: > >> KVM is not usable under F9. I tried with 1 to 4 cpus and they all run >> incredibly slow. Like 10 mins. between each step in the boot sequence. >> Something is really wrong. >> > > You should really stop making claims like "not usable in F9" when you > haven't gotten any conformation that anybody other than you are > experiencing these issues. > > A) Are you sure the kvm module is loaded into your kernel? > > B) Have you tried creating a new guest directly via lib-virt rather than > using a conversion tool? > > C) Using a fresh virtual disk image for B > > I and many other people have been using KVM with Fedora 9 for well the > entirety of the development cycle. It is extremely usable. > > Point taken. I'll try creating some fresh images. Regards, Gerry From seg at haxxed.com Thu May 8 04:57:28 2008 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 07 May 2008 23:57:28 -0500 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <4820A376.70104@redhat.com> References: <1209999548.32107.11.camel@kennedy> <481FD3D5.5070206@ncsu.edu> <48207309.3040403@redhat.com> <200805061308.24635.sgrubb@redhat.com> <4820A376.70104@redhat.com> Message-ID: <1210222648.4287.1.camel@localhost> On Tue, 2008-05-06 at 14:29 -0400, Christopher Aillon wrote: > Firefox will probably take some effort :-) > > If someone with the knowledge and ambition wants to do the work, I will > help as best I can. The bug once again is > https://bugzilla.mozilla.org/show_bug.cgi?id=104642 Has there been any talk of switching Firefox to cmake? cmake is actually cross platform... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From greno at verizon.net Thu May 8 06:22:51 2008 From: greno at verizon.net (Gerry Reno) Date: Thu, 08 May 2008 02:22:51 -0400 Subject: F9 and KVM In-Reply-To: <48227A43.6010409@verizon.net> References: <4822584F.4010504@verizon.net> <1210214432.5112.53.camel@localhost.localdomain> <48226ABD.6000302@verizon.net> <48226B52.7090907@verizon.net> <48226FB1.9060401@verizon.net> <482276D1.9000502@verizon.net> <1210218498.5112.57.camel@localhost.localdomain> <48227A43.6010409@verizon.net> Message-ID: <48229C3B.9080209@verizon.net> Ok, I tried creating some fresh images using virt-manager. I'm not having much luck. I try creating a f7 and f9 vm. On both installs the installer runs slow. Much slower than equivalent vm in vmware under F7. Also both installs get stuck at prompt to initialize /dev/sda. When you answer 'yes' it takes almost 10 minutes for a prompt to come back and say it had some error and retry,ignore,cancel. I'm wondering if the speed issue is related to this being a quad-core machine? Regards, Gerry From billcrawford1970 at gmail.com Thu May 8 07:48:33 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Thu, 8 May 2008 08:48:33 +0100 Subject: Plan for tomorrows (20080508) FESCO meeting In-Reply-To: <1210211836.15217.148.camel@localhost.localdomain> References: <1210200825.6018.3.camel@kennedy> <1210211836.15217.148.camel@localhost.localdomain> Message-ID: <544eb990805080048u7ddf05fanf2cf1ece13cb5e08@mail.gmail.com> 2008/5/8 Tom spot Callaway : > Unfortunately, I will be absent for tomorrows meeting, I will be in > transit to North Carolina. Make sure they leave you plenty of air holes ;o) > ~spot From rawhide at fedoraproject.org Thu May 8 10:30:34 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Thu, 8 May 2008 10:30:34 +0000 (UTC) Subject: rawhide report: 20080508 changes Message-ID: <20080508103034.D5D4E209D0D@releng1.fedora.phx.redhat.com> Updated Packages: gpredict-0.9.0-3.fc9 -------------------- * Wed May 07 2008 Jesse Keating - 0.9.0-3 - Rebuild for file corruption paraview-3.2.1-6.fc9 -------------------- * Wed May 07 2008 Jesse Keating - 3.2.1-6 - Rebuild for file corruption Broken deps for ppc64 ---------------------------------------------------------- livecd-tools-017-1.fc9.ppc64 requires yaboot perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot From dominik at greysector.net Thu May 8 10:41:37 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 8 May 2008 12:41:37 +0200 Subject: nscd missing from bugzilla? In-Reply-To: <48225C27.1020105@gmail.com> References: <48225C27.1020105@gmail.com> Message-ID: <20080508104136.GB31941@onizuka.greysector.net> On Thursday, 08 May 2008 at 03:49, Toshio Kuratomi wrote: > Neal Becker wrote: > >I can't find an entry for nscd: > > nscd is built from glibc so report it under glibc. > > rpm -qif /usr/sbin/nscd |grep -i 'Source RPM' > Group : System Environment/Daemons Source RPM: glibc-2.7-2.src.rpm $ rpm -q --qf '%{sourcerpm}\n' nscd glibc-2.8-3.src.rpm ;) Regards, R. -- Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From rjones at redhat.com Thu May 8 11:24:44 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 8 May 2008 12:24:44 +0100 Subject: F9 and KVM In-Reply-To: <48229C3B.9080209@verizon.net> References: <4822584F.4010504@verizon.net> <1210214432.5112.53.camel@localhost.localdomain> <48226ABD.6000302@verizon.net> <48226B52.7090907@verizon.net> <48226FB1.9060401@verizon.net> <482276D1.9000502@verizon.net> <1210218498.5112.57.camel@localhost.localdomain> <48227A43.6010409@verizon.net> <48229C3B.9080209@verizon.net> Message-ID: <20080508112444.GA29692@amd.home.annexia.org> On Thu, May 08, 2008 at 02:22:51AM -0400, Gerry Reno wrote: > Ok, I tried creating some fresh images using virt-manager. I'm not having > much luck. I try creating a f7 and f9 vm. On both installs the installer > runs slow. Much slower than equivalent vm in vmware under F7. Also both > installs get stuck at prompt to initialize /dev/sda. When you answer 'yes' > it takes almost 10 minutes for a prompt to come back and say it had some > error and retry,ignore,cancel. I'm wondering if the speed issue is > related to this being a quad-core machine? It's more likely down to your hardware either not supporting hardware virtualization, or supporting it really badly. Is the kvm-intel or kvm-amd module loaded into the kernel? Did 'dmesg' say anything when it was loaded? What is in /proc/cpuinfo flags? Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From dbhole at redhat.com Thu May 8 13:32:02 2008 From: dbhole at redhat.com (Deepak Bhole) Date: Thu, 8 May 2008 09:32:02 -0400 Subject: Plan for tomorrows (20080508) FESCO meeting In-Reply-To: <1210200825.6018.3.camel@kennedy> References: <1210200825.6018.3.camel@kennedy> Message-ID: <20080508133202.GC7927@redhat.com> * Brian Pepple [2008-05-07 18:55]: > Please find below the list of topics that are likely to come up in the > next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC > in #fedora-meeting on irc.freenode.org: > > /topic FESCo meeting -- Any objection to this week's report from FPC at > https://www.redhat.com/archives/fedora-devel-list/2008-May/msg00637.html > > /topic FESCO-Meeting -- sponsor nominations - Denis Leroy (denis) > > /topic FESCo-Meeting -- sponsor nominations - Jef Spaleta (spoleeba) > > /topic FESCo-Meeting -- sponsor nominations - Douglas Warner (silfreed) > > /topic FESCo-Meeting -- Proposal to block old version of automake & > autoconf - Karsten Hopp > > /topic FESCo meeting -- > http://fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy -- bpepple > > /topic FESCo-Meeting -- F9 - any issues needing discussion? - all > > /topic FESCo meeting -- Free discussion around Fedora > As per the original mail here which requested information before May 8th: https://www.redhat.com/archives/fedora-devel-list/2008-April/msg00802.html (Second item under "other business"), I'd like to see discussion about the JPackage naming exception added to the agenda. /adding spot to cc since he won't be able to make it, and may want it rescheduled Cheers, Deepak > You want something to be discussed? Send a note to the list in reply to > this mail and I'll add it to the schedule. You can also propose topics > in the meeting while it is in the "Free discussion around Fedora" phase. > > If your name/nick is on above list please update the status on the > Extras schedule pages in the wiki ahead of the meeting. That way all the > other FESCo members and interested contributors know what up ahead of > the meeting. And we will avoid long delays in the meeting -- those often > arise if someone describes the recent happenings on a topic directly in > the meeting while all the others have to wait for his slow typing... > > Later, > /B > -- > Brian Pepple > > http://fedoraproject.org/wiki/BrianPepple > gpg --keyserver pgp.mit.edu --recv-keys 810CC15E > BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From pp at ee.oulu.fi Thu May 8 14:09:10 2008 From: pp at ee.oulu.fi (Pekka Pietikainen) Date: Thu, 8 May 2008 17:09:10 +0300 Subject: Anyone else with hard freezes? In-Reply-To: <2a28d2ab0805061455l9afae56p8a86218d08bc4b92@mail.gmail.com> References: <2a28d2ab0805061455l9afae56p8a86218d08bc4b92@mail.gmail.com> Message-ID: <20080508140910.GA27576@ee.oulu.fi> On Tue, May 06, 2008 at 05:55:38PM -0400, Dr. Diesel wrote: > Currently running Fedora 9 Release to date. Doesn't happen very > often, maybe once every 3-4 days. Twice I've caught it at idle with > the screen saver (picture viewer) frozen and twice while browsing in > Gnome. > > Not really noticing anything weird in the logs? I've been running into hangs for a long time on my laptop. Seems to be related to something in the utrace patchset (not totally proven though). nohz=off makes the problem go away (25 days uptime with 2.6.25-0.218.rc8.git7.fc9 :-) ) Would be nice to see SOMEONE being able to reproduce the same issue, it's only this one laptop I've seen it on, nearly identical X31 didn't show any issues. https://bugzilla.redhat.com/show_bug.cgi?id=283161 for the details. -- Pekka Pietikainen From jwilson at redhat.com Thu May 8 14:25:35 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 8 May 2008 10:25:35 -0400 Subject: Anyone else with hard freezes? In-Reply-To: <20080508140910.GA27576@ee.oulu.fi> References: <2a28d2ab0805061455l9afae56p8a86218d08bc4b92@mail.gmail.com> <20080508140910.GA27576@ee.oulu.fi> Message-ID: <200805081025.35447.jwilson@redhat.com> On Thursday 08 May 2008 10:09:10 am Pekka Pietikainen wrote: > On Tue, May 06, 2008 at 05:55:38PM -0400, Dr. Diesel wrote: > > Currently running Fedora 9 Release to date. Doesn't happen very > > often, maybe once every 3-4 days. Twice I've caught it at idle with > > the screen saver (picture viewer) frozen and twice while browsing in > > Gnome. > > > > Not really noticing anything weird in the logs? > > I've been running into hangs for a long time on my laptop. > Seems to be related to something in the utrace patchset (not totally proven > though). nohz=off makes the problem go away (25 days uptime with > 2.6.25-0.218.rc8.git7.fc9 :-) ) > > Would be nice to see SOMEONE being able to reproduce the same issue, > it's only this one laptop I've seen it on, nearly identical X31 > didn't show any issues. > > https://bugzilla.redhat.com/show_bug.cgi?id=283161 for the details. Might be worth trying out a 2.6.25.2 build, there are a number of scheduler fixes that went in post-2.6.25. There's a 2.6.25.2 (plus what's in the queue for 2.6.25.3) build that was done in dist-f10 last night. Right now, dist-f10 is still mostly the same thing as dist-f9, so there shouldn't be any issues running this kernel on an F9 system -- I'm running it on my own otherwise f9 laptop w/o a problem (but then again, I didn't have any problems with prior kernels either). http://koji.fedoraproject.org/packages/kernel/2.6.25.2/5.fc10/ -- Jarod Wilson jwilson at redhat.com From tibbs at math.uh.edu Thu May 8 14:27:35 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 08 May 2008 09:27:35 -0500 Subject: Plan for tomorrows (20080508) FESCO meeting In-Reply-To: <20080508133202.GC7927@redhat.com> References: <1210200825.6018.3.camel@kennedy> <20080508133202.GC7927@redhat.com> Message-ID: >>>>> "DB" == Deepak Bhole writes: DB> (Second item under "other business"), I'd like to see discussion DB> about the JPackage naming exception added to the agenda. That's a packaging committee thing, though. Next FPC meeting is scheduled for May 20th. - J< From dbhole at redhat.com Thu May 8 14:32:27 2008 From: dbhole at redhat.com (Deepak Bhole) Date: Thu, 8 May 2008 10:32:27 -0400 Subject: Plan for tomorrows (20080508) FESCO meeting In-Reply-To: References: <1210200825.6018.3.camel@kennedy> <20080508133202.GC7927@redhat.com> Message-ID: <20080508143227.GE7927@redhat.com> * Jason L Tibbitts III [2008-05-08 10:28]: > >>>>> "DB" == Deepak Bhole writes: > > DB> (Second item under "other business"), I'd like to see discussion > DB> about the JPackage naming exception added to the agenda. > > That's a packaging committee thing, though. Next FPC meeting is > scheduled for May 20th. > Ah okay, never mind then. I had thought that the plan was to escalate it to the FESCO board and have it resolved in that meeting. Deepak From greno at verizon.net Thu May 8 14:47:38 2008 From: greno at verizon.net (Gerry Reno) Date: Thu, 08 May 2008 10:47:38 -0400 Subject: F9 and KVM In-Reply-To: <20080508112444.GA29692@amd.home.annexia.org> References: <4822584F.4010504@verizon.net> <1210214432.5112.53.camel@localhost.localdomain> <48226ABD.6000302@verizon.net> <48226B52.7090907@verizon.net> <48226FB1.9060401@verizon.net> <482276D1.9000502@verizon.net> <1210218498.5112.57.camel@localhost.localdomain> <48227A43.6010409@verizon.net> <48229C3B.9080209@verizon.net> <20080508112444.GA29692@amd.home.annexia.org> Message-ID: <4823128A.3030003@verizon.net> Richard W.M. Jones wrote: > On Thu, May 08, 2008 at 02:22:51AM -0400, Gerry Reno wrote: > >> Ok, I tried creating some fresh images using virt-manager. I'm not having >> much luck. I try creating a f7 and f9 vm. On both installs the installer >> runs slow. Much slower than equivalent vm in vmware under F7. Also both >> installs get stuck at prompt to initialize /dev/sda. When you answer 'yes' >> it takes almost 10 minutes for a prompt to come back and say it had some >> error and retry,ignore,cancel. I'm wondering if the speed issue is >> related to this being a quad-core machine? >> > > It's more likely down to your hardware either not supporting hardware > virtualization, or supporting it really badly. Is the kvm-intel or > kvm-amd module loaded into the kernel? Did 'dmesg' say anything when > it was loaded? What is in /proc/cpuinfo flags? > > Rich. > > Rich, The hardware appears to support hardware virtualization: ====================================================== # grep svm /proc/cpuinfo flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs ts ttp tm stc 100mhzsteps hwpstate flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs ts ttp tm stc 100mhzsteps hwpstate flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs ts ttp tm stc 100mhzsteps hwpstate flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs ts ttp tm stc 100mhzsteps hwpstate Here's what is in /proc/cpuinfo: ====================================================== [root at grp-01-10-01 MX_1]# cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 16 model : 2 model name : AMD Phenom(tm) 9850 Quad-Core Processor stepping : 3 cpu MHz : 1250.000 cache size : 512 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 4 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs ts ttp tm stc 100mhzsteps hwpstate bogomips : 2512.94 clflush size : 64 processor : 1 vendor_id : AuthenticAMD cpu family : 16 model : 2 model name : AMD Phenom(tm) 9850 Quad-Core Processor stepping : 3 cpu MHz : 1250.000 cache size : 512 KB physical id : 0 siblings : 4 core id : 2 cpu cores : 4 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs ts ttp tm stc 100mhzsteps hwpstate bogomips : 2512.94 clflush size : 64 processor : 2 vendor_id : AuthenticAMD cpu family : 16 model : 2 model name : AMD Phenom(tm) 9850 Quad-Core Processor stepping : 3 cpu MHz : 1250.000 cache size : 512 KB physical id : 0 siblings : 4 core id : 1 cpu cores : 4 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs ts ttp tm stc 100mhzsteps hwpstate bogomips : 2512.94 clflush size : 64 processor : 3 vendor_id : AuthenticAMD cpu family : 16 model : 2 model name : AMD Phenom(tm) 9850 Quad-Core Processor stepping : 3 cpu MHz : 1250.000 cache size : 512 KB physical id : 0 siblings : 4 core id : 3 cpu cores : 4 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs ts ttp tm stc 100mhzsteps hwpstate bogomips : 2512.94 clflush size : 64 ====================================================== But I notice from dmesg that it reports different capability for cpus (notice the bogomips): ====================================================== CPU0: AMD Phenom(tm) 9850 Quad-Core Processor stepping 03 Booting processor 1/1 ip 4000 CPU 1 irqstacks, hard=c07ba000 soft=c079a000 Initializing CPU#1 Calibrating delay using timer specific routine.. 5022.86 BogoMIPS (lpj=2511432) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) CPU 1(4) -> Core 2 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#1. CPU1: AMD Phenom(tm) 9850 Quad-Core Processor stepping 03 Booting processor 2/2 ip 4000 CPU 2 irqstacks, hard=c07bb000 soft=c079b000 Initializing CPU#2 Calibrating delay using timer specific routine.. 5022.84 BogoMIPS (lpj=2511421) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) CPU 2(4) -> Core 1 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#2. CPU2: AMD Phenom(tm) 9850 Quad-Core Processor stepping 03 Booting processor 3/3 ip 4000 CPU 3 irqstacks, hard=c07bc000 soft=c079c000 Initializing CPU#3 Calibrating delay using timer specific routine.. 5022.85 BogoMIPS (lpj=2511426) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) CPU 3(4) -> Core 3 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#3. CPU3: AMD Phenom(tm) 9850 Quad-Core Processor stepping 03 Total of 4 processors activated (20094.44 BogoMIPS). ENABLING IO-APIC IRQs ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 Brought up 4 CPUs sizeof(vma)=84 bytes sizeof(page)=32 bytes sizeof(inode)=340 bytes sizeof(dentry)=132 bytes sizeof(ext3inode)=492 bytes sizeof(buffer_head)=56 bytes sizeof(skbuff)=176 bytes sizeof(task_struct)=3728 bytes CPU0 attaching sched-domain: domain 0: span 0000000f groups: 00000001 00000002 00000004 00000008 CPU1 attaching sched-domain: domain 0: span 0000000f groups: 00000002 00000004 00000008 00000001 CPU2 attaching sched-domain: domain 0: span 0000000f groups: 00000004 00000008 00000001 00000002 CPU3 attaching sched-domain: domain 0: span 0000000f groups: 00000008 00000001 00000002 00000004 net_namespace: 548 bytes Booting paravirtualized kernel on bare hardware Time: 16:44:18 Date: 05/06/08 ====================================================== [root at grp-01-10-01 MX_1]# modprobe -l | grep -i kvm /lib/modules/2.6.25-14.fc9.i686/kernel/arch/x86/kvm/kvm-amd.ko /lib/modules/2.6.25-14.fc9.i686/kernel/arch/x86/kvm/kvm-intel.ko /lib/modules/2.6.25-14.fc9.i686/kernel/arch/x86/kvm/kvm.ko ====================================================== # dmesg | grep -i kvm # ====================================================== I see no messages in dmesg about any problem related to kvm. The cpu speed looks to be half in /proc/cpuinfo as compared with dmesg. That's a little strange. Regards, Gerry -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwmw2 at infradead.org Thu May 8 14:55:04 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 08 May 2008 15:55:04 +0100 Subject: Maintainer Responsibility Policy In-Reply-To: <604aa7910805071010u411b4bd0h4932981766d525ee@mail.gmail.com> References: <1210035695.6297.25.camel@kennedy> <482056BE.90100@n-dimensional.de> <48206A93.7020807@gmail.com> <1210089261.2961.3.camel@kennedy> <4820836D.7070008@gmail.com> <1210154821.25560.865.camel@pmac.infradead.org> <604aa7910805071010u411b4bd0h4932981766d525ee@mail.gmail.com> Message-ID: <1210258504.25560.1107.camel@pmac.infradead.org> On Wed, 2008-05-07 at 09:10 -0800, Jeff Spaleta wrote: > On Wed, May 7, 2008 at 2:07 AM, David Woodhouse wrote: > > I'm not sure that's strong enough. It should clearly state that the > > package maintainer is responsible for getting bugs fixed -- if the > > package maintainer isn't a coder, then they need to take a more > > managerial r?le; working with upstream or with code-monkeys within > > Fedora to get things fixed. How about this: > > Do we need to make an effort to catalog skillsets in the contributor > base? to make it easier to help maintainers find a particular sort of > code-monkey? Yes, perhaps. Or maybe it would be better to have a code-monkey sign up as co-maintainer for the package, where the primary maintainer isn't capable of actually..., well, maintaining the package. -- dwmw2 From mark.bidewell at alumni.clemson.edu Thu May 8 14:57:53 2008 From: mark.bidewell at alumni.clemson.edu (Mark Bidewell) Date: Thu, 8 May 2008 10:57:53 -0400 Subject: F9 and KVM In-Reply-To: <4823128A.3030003@verizon.net> References: <4822584F.4010504@verizon.net> <48226ABD.6000302@verizon.net> <48226B52.7090907@verizon.net> <48226FB1.9060401@verizon.net> <482276D1.9000502@verizon.net> <1210218498.5112.57.camel@localhost.localdomain> <48227A43.6010409@verizon.net> <48229C3B.9080209@verizon.net> <20080508112444.GA29692@amd.home.annexia.org> <4823128A.3030003@verizon.net> Message-ID: 2008/5/8 Gerry Reno : > Richard W.M. Jones wrote: > > On Thu, May 08, 2008 at 02:22:51AM -0400, Gerry Reno wrote: > > > Ok, I tried creating some fresh images using virt-manager. I'm not having > much luck. I try creating a f7 and f9 vm. On both installs the installer > runs slow. Much slower than equivalent vm in vmware under F7. Also both > installs get stuck at prompt to initialize /dev/sda. When you answer 'yes' > it takes almost 10 minutes for a prompt to come back and say it had some > error and retry,ignore,cancel. I'm wondering if the speed issue is > related to this being a quad-core machine? > > > It's more likely down to your hardware either not supporting hardware > virtualization, or supporting it really badly. Is the kvm-intel or > kvm-amd module loaded into the kernel? Did 'dmesg' say anything when > it was loaded? What is in /proc/cpuinfo flags? > > Rich. > > > > Rich, > The hardware appears to support hardware virtualization: > > ====================================================== > # grep svm /proc/cpuinfo > flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov > pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb > rdtscp lm 3dnowext 3dnow constant_tsc pni monitor cx16 popcnt lahf_lm > cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw > ibs ts ttp tm stc 100mhzsteps hwpstate > flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov > pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb > rdtscp lm 3dnowext 3dnow constant_tsc pni monitor cx16 popcnt lahf_lm > cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw > ibs ts ttp tm stc 100mhzsteps hwpstate > flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov > pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb > rdtscp lm 3dnowext 3dnow constant_tsc pni monitor cx16 popcnt lahf_lm > cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw > ibs ts ttp tm stc 100mhzsteps hwpstate > flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov > pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb > rdtscp lm 3dnowext 3dnow constant_tsc pni monitor cx16 popcnt lahf_lm > cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw > ibs ts ttp tm stc 100mhzsteps hwpstate > > > Here's what is in /proc/cpuinfo: > > ====================================================== > [root at grp-01-10-01 MX_1]# cat /proc/cpuinfo > processor : 0 > vendor_id : AuthenticAMD > cpu family : 16 > model : 2 > model name : AMD Phenom(tm) 9850 Quad-Core Processor > stepping : 3 > cpu MHz : 1250.000 > cache size : 512 KB > physical id : 0 > siblings : 4 > core id : 0 > cpu cores : 4 > fdiv_bug : no > hlt_bug : no > f00f_bug : no > coma_bug : no > fpu : yes > fpu_exception : yes > cpuid level : 5 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov > pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb > rdtscp lm 3dnowext 3dnow constant_tsc pni monitor cx16 popcnt lahf_lm > cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw > ibs ts ttp tm stc 100mhzsteps hwpstate > bogomips : 2512.94 > clflush size : 64 > > processor : 1 > vendor_id : AuthenticAMD > cpu family : 16 > model : 2 > model name : AMD Phenom(tm) 9850 Quad-Core Processor > stepping : 3 > cpu MHz : 1250.000 > cache size : 512 KB > physical id : 0 > siblings : 4 > core id : 2 > cpu cores : 4 > fdiv_bug : no > hlt_bug : no > f00f_bug : no > coma_bug : no > fpu : yes > fpu_exception : yes > cpuid level : 5 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov > pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb > rdtscp lm 3dnowext 3dnow constant_tsc pni monitor cx16 popcnt lahf_lm > cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw > ibs ts ttp tm stc 100mhzsteps hwpstate > bogomips : 2512.94 > clflush size : 64 > > processor : 2 > vendor_id : AuthenticAMD > cpu family : 16 > model : 2 > model name : AMD Phenom(tm) 9850 Quad-Core Processor > stepping : 3 > cpu MHz : 1250.000 > cache size : 512 KB > physical id : 0 > siblings : 4 > core id : 1 > cpu cores : 4 > fdiv_bug : no > hlt_bug : no > f00f_bug : no > coma_bug : no > fpu : yes > fpu_exception : yes > cpuid level : 5 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov > pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb > rdtscp lm 3dnowext 3dnow constant_tsc pni monitor cx16 popcnt lahf_lm > cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw > ibs ts ttp tm stc 100mhzsteps hwpstate > bogomips : 2512.94 > clflush size : 64 > > processor : 3 > vendor_id : AuthenticAMD > cpu family : 16 > model : 2 > model name : AMD Phenom(tm) 9850 Quad-Core Processor > stepping : 3 > cpu MHz : 1250.000 > cache size : 512 KB > physical id : 0 > siblings : 4 > core id : 3 > cpu cores : 4 > fdiv_bug : no > hlt_bug : no > f00f_bug : no > coma_bug : no > fpu : yes > fpu_exception : yes > cpuid level : 5 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov > pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb > rdtscp lm 3dnowext 3dnow constant_tsc pni monitor cx16 popcnt lahf_lm > cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw > ibs ts ttp tm stc 100mhzsteps hwpstate > bogomips : 2512.94 > clflush size : 64 > > ====================================================== > > But I notice from dmesg that it reports different capability for cpus > (notice the bogomips): > > ====================================================== > CPU0: AMD Phenom(tm) 9850 Quad-Core Processor stepping 03 > Booting processor 1/1 ip 4000 > CPU 1 irqstacks, hard=c07ba000 soft=c079a000 > Initializing CPU#1 > Calibrating delay using timer specific routine.. 5022.86 BogoMIPS > (lpj=2511432) > CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) > CPU: L2 Cache: 512K (64 bytes/line) > CPU 1(4) -> Core 2 > Intel machine check architecture supported. > Intel machine check reporting enabled on CPU#1. > CPU1: AMD Phenom(tm) 9850 Quad-Core Processor stepping 03 > Booting processor 2/2 ip 4000 > CPU 2 irqstacks, hard=c07bb000 soft=c079b000 > Initializing CPU#2 > Calibrating delay using timer specific routine.. 5022.84 BogoMIPS > (lpj=2511421) > CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) > CPU: L2 Cache: 512K (64 bytes/line) > CPU 2(4) -> Core 1 > Intel machine check architecture supported. > Intel machine check reporting enabled on CPU#2. > CPU2: AMD Phenom(tm) 9850 Quad-Core Processor stepping 03 > Booting processor 3/3 ip 4000 > CPU 3 irqstacks, hard=c07bc000 soft=c079c000 > Initializing CPU#3 > Calibrating delay using timer specific routine.. 5022.85 BogoMIPS > (lpj=2511426) > CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) > CPU: L2 Cache: 512K (64 bytes/line) > CPU 3(4) -> Core 3 > Intel machine check architecture supported. > Intel machine check reporting enabled on CPU#3. > CPU3: AMD Phenom(tm) 9850 Quad-Core Processor stepping 03 > Total of 4 processors activated (20094.44 BogoMIPS). > ENABLING IO-APIC IRQs > ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 > Brought up 4 CPUs > sizeof(vma)=84 bytes > sizeof(page)=32 bytes > sizeof(inode)=340 bytes > sizeof(dentry)=132 bytes > sizeof(ext3inode)=492 bytes > sizeof(buffer_head)=56 bytes > sizeof(skbuff)=176 bytes > sizeof(task_struct)=3728 bytes > CPU0 attaching sched-domain: > domain 0: span 0000000f > groups: 00000001 00000002 00000004 00000008 > CPU1 attaching sched-domain: > domain 0: span 0000000f > groups: 00000002 00000004 00000008 00000001 > CPU2 attaching sched-domain: > domain 0: span 0000000f > groups: 00000004 00000008 00000001 00000002 > CPU3 attaching sched-domain: > domain 0: span 0000000f > groups: 00000008 00000001 00000002 00000004 > net_namespace: 548 bytes > Booting paravirtualized kernel on bare hardware > Time: 16:44:18 Date: 05/06/08 > > ====================================================== > > [root at grp-01-10-01 MX_1]# modprobe -l | grep -i kvm > /lib/modules/2.6.25-14.fc9.i686/kernel/arch/x86/kvm/kvm-amd.ko > /lib/modules/2.6.25-14.fc9.i686/kernel/arch/x86/kvm/kvm-intel.ko > /lib/modules/2.6.25-14.fc9.i686/kernel/arch/x86/kvm/kvm.ko > > ====================================================== > > # dmesg | grep -i kvm > # > > ====================================================== > > > I see no messages in dmesg about any problem related to kvm. The cpu speed > looks to be half in /proc/cpuinfo as compared with dmesg. That's a little > strange. > > > Regards, > Gerry > > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Check your BIOS. some mainboards ship with HW virtualization disabled. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattdm at mattdm.org Thu May 8 15:06:50 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 8 May 2008 11:06:50 -0400 Subject: Flash on rawhide In-Reply-To: <1210087782.2716.8.camel@scrappy.miketc.com> References: <1210086745.2716.6.camel@scrappy.miketc.com> <20080506152222.GA21258@nostromo.devel.redhat.com> <1210087782.2716.8.camel@scrappy.miketc.com> Message-ID: <20080508150650.GA18366@jadzia.bu.edu> On Tue, May 06, 2008 at 10:29:42AM -0500, Mike Chambers wrote: > > > Any ideas? > > You probably need libflashsupport.i386. > That did the trick, thanks notting. Hrm, should that be installed by So, didn't work for me. I had both the x86_64 and i386 versions installed; no sound. I removed them both, and the flash plugin itself, and reinstalled just the flash plugin and libflashsupport.i386, and still no sound. Hmmm. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From lmacken at redhat.com Thu May 8 15:30:06 2008 From: lmacken at redhat.com (Luke Macken) Date: Thu, 8 May 2008 11:30:06 -0400 Subject: bodhi questions In-Reply-To: <20080507112318.3c8602b6.mschwendt@gmail.com> References: <20080503105227.e21d411b.mschwendt@gmail.com> <20080505163914.GB3718@x300.redhat.com> <20080505215502.GF3718@x300.redhat.com> <20080507112318.3c8602b6.mschwendt@gmail.com> Message-ID: <20080508153006.GB5157@x300> On Wed, May 07, 2008 at 11:23:18AM +0200, Michael Schwendt wrote: > On Mon, 5 May 2008 17:55:02 -0400, Luke Macken wrote: > > > On Mon, May 05, 2008 at 12:39:14PM -0400, Luke Macken wrote: > > > On Sat, May 03, 2008 at 10:52:27AM +0200, Michael Schwendt wrote: > > > > 1) Does the nvr input box work for anyone? It used to work long ago, but > > > > here no longer finds any builds. I had to cut'n'paste a build tag into it. > > > > > > Yep, known issue[0]. We hit a regression with the AutoCompleteField > > > widget with TurboGears-1.0.4.4, which has since been fixed upstream. > > > > I fixed the package auto-completion widget, and pushed the fix to > > production. Let me know if you have any problems with it! > > Thanks! It works again, albeit requires slow and careful typing, as else > it would attempt completion at odd times. > > Sorting the results (by name and by RPM evr) would be a great > feature addition. I agree. It's on my "bodhi usability enhancements that I would like to implement before F9" list. https://fedorahosted.org/bodhi/ticket/173 luke From greno at verizon.net Thu May 8 15:32:19 2008 From: greno at verizon.net (Gerry Reno) Date: Thu, 08 May 2008 11:32:19 -0400 Subject: F9 and KVM In-Reply-To: References: <4822584F.4010504@verizon.net> <48226ABD.6000302@verizon.net> <48226B52.7090907@verizon.net> <48226FB1.9060401@verizon.net> <482276D1.9000502@verizon.net> <1210218498.5112.57.camel@localhost.localdomain> <48227A43.6010409@verizon.net> <48229C3B.9080209@verizon.net> <20080508112444.GA29692@amd.home.annexia.org> <4823128A.3030003@verizon.net> Message-ID: <48231D03.6030004@verizon.net> Mark Bidewell wrote: > Check your BIOS. some mainboards ship with HW virtualization disabled. That's only on Intel boards. This is an AMD board. Regards, Gerry From bpepple at fedoraproject.org Thu May 8 15:32:44 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Thu, 08 May 2008 11:32:44 -0400 Subject: Plan for tomorrows (20080508) FESCO meeting In-Reply-To: <20080508133202.GC7927@redhat.com> References: <1210200825.6018.3.camel@kennedy> <20080508133202.GC7927@redhat.com> Message-ID: <1210260764.26754.3.camel@nixon> On Thu, 2008-05-08 at 09:32 -0400, Deepak Bhole wrote: > > As per the original mail here which requested information before May > 8th: > > https://www.redhat.com/archives/fedora-devel-list/2008-April/msg00802.html > > (Second item under "other business"), I'd like to see discussion about > the JPackage naming exception added to the agenda. > > /adding spot to cc since he won't be able to make it, and may want it > rescheduled This sounds like it was going to the next Packaging Committee meeting, before being escalated to FESCo. Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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 rjones at redhat.com Thu May 8 15:51:50 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 8 May 2008 16:51:50 +0100 Subject: F9 and KVM In-Reply-To: <4823128A.3030003@verizon.net> References: <1210214432.5112.53.camel@localhost.localdomain> <48226ABD.6000302@verizon.net> <48226B52.7090907@verizon.net> <48226FB1.9060401@verizon.net> <482276D1.9000502@verizon.net> <1210218498.5112.57.camel@localhost.localdomain> <48227A43.6010409@verizon.net> <48229C3B.9080209@verizon.net> <20080508112444.GA29692@amd.home.annexia.org> <4823128A.3030003@verizon.net> Message-ID: <20080508155150.GA32379@amd.home.annexia.org> On Thu, May 08, 2008 at 10:47:38AM -0400, Gerry Reno wrote: > # dmesg | grep -i kvm > # Yeah, I was a bit confused here. KVM used to print a kernel message when it was loaded, but I've noticed that the latest version doesn't. Is the kvm module loaded? eg. on my Intel system: # /sbin/lsmod | grep kvm kvm_intel 30784 0 kvm 108376 1 kvm_intel As for why it's slow ... Try a single virtual CPU to start with, since support for SMP guests in KVM is pretty new (less than 8 months old IIRC). Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From poelstra at redhat.com Thu May 8 16:22:49 2008 From: poelstra at redhat.com (John Poelstra) Date: Thu, 08 May 2008 09:22:49 -0700 Subject: Fedora Rel-Eng Meeting Recap 2008-05-04 Message-ID: <482328D9.5030108@redhat.com> Recap and full IRC transcript found here: http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-may-05 Please make corrections and clarifications to the wiki page. == F9 Release Candidate == * A few things holding up the release candidate * texlive * X crashing on evdev removal during installer (kvms) * packagekit that just got built. * emacs has broken alternatives and is still on the blocker list * conflict between rsyslog and syslog-ng == Posting F9 Release Candidate == * Once we have RC spun and are testing it we should pre-process the pending F9 updates and get them pushed into directories * We should also have tickets filed for releases tasks that we need to make sure happen like export approval filing, etc. == Rawhide Switch to F10 == * BugZappers want to coridnate with Bugzilla versioning and rawhide rebase * Most likely rawhide composes starting on May 8th or 9th will become F10 * f13 to keep poelcat updated == IRC Transcript == From greno at verizon.net Thu May 8 16:42:06 2008 From: greno at verizon.net (Gerry Reno) Date: Thu, 08 May 2008 12:42:06 -0400 Subject: F9 and KVM In-Reply-To: <20080508155150.GA32379@amd.home.annexia.org> References: <1210214432.5112.53.camel@localhost.localdomain> <48226ABD.6000302@verizon.net> <48226B52.7090907@verizon.net> <48226FB1.9060401@verizon.net> <482276D1.9000502@verizon.net> <1210218498.5112.57.camel@localhost.localdomain> <48227A43.6010409@verizon.net> <48229C3B.9080209@verizon.net> <20080508112444.GA29692@amd.home.annexia.org> <4823128A.3030003@verizon.net> <20080508155150.GA32379@amd.home.annexia.org> Message-ID: <48232D5E.1030800@verizon.net> Richard W.M. Jones wrote: > On Thu, May 08, 2008 at 10:47:38AM -0400, Gerry Reno wrote: > >> # dmesg | grep -i kvm >> # >> > > Yeah, I was a bit confused here. KVM used to print a kernel message > when it was loaded, but I've noticed that the latest version doesn't. > Is the kvm module loaded? eg. on my Intel system: > > # /sbin/lsmod | grep kvm > kvm_intel 30784 0 > kvm 108376 1 kvm_intel > > As for why it's slow ... Try a single virtual CPU to start with, since > support for SMP guests in KVM is pretty new (less than 8 months old > IIRC). > > Rich. > > Here's what I found so far: In BIOS there is a setting "AMD Cool n Quiet". I thought this was some type of fan thing. It is not. It controls the cpu speed. So I disable this and now dmesg and /proc/cpuinfo both show same at 2510 MHz. And I try creating a new F9 VM with 1 VCPU. The install now seems to run at a normal speed but still I cannot get F9 to install in VM. It says partition table on /dev/sda is unreadable and it needs to initialize. So I say yes and it sits there for about 10 mins until it give you an error (i/o error on device) retry,ignore,cancel. No choice helps. So I try with F7 as well and same thing, it cannot initialize the virtual drive (mine is file-based). Regards, Gerry -------------- next part -------------- An HTML attachment was scrubbed... URL: From greno at verizon.net Thu May 8 17:37:34 2008 From: greno at verizon.net (Gerry Reno) Date: Thu, 08 May 2008 13:37:34 -0400 Subject: F9 and KVM In-Reply-To: <48232D5E.1030800@verizon.net> References: <1210214432.5112.53.camel@localhost.localdomain> <48226ABD.6000302@verizon.net> <48226B52.7090907@verizon.net> <48226FB1.9060401@verizon.net> <482276D1.9000502@verizon.net> <1210218498.5112.57.camel@localhost.localdomain> <48227A43.6010409@verizon.net> <48229C3B.9080209@verizon.net> <20080508112444.GA29692@amd.home.annexia.org> <4823128A.3030003@verizon.net> <20080508155150.GA32379@amd.home.annexia.org> <48232D5E.1030800@verizon.net> Message-ID: <48233A5E.5080006@verizon.net> Gerry Reno wrote: > Here's what I found so far: > In BIOS there is a setting "AMD Cool n Quiet". I thought this was > some type of fan thing. It is not. It controls the cpu speed. So I > disable this and now dmesg and /proc/cpuinfo both show same at 2510 > MHz. And I try creating a new F9 VM with 1 VCPU. The install now > seems to run at a normal speed but still I cannot get F9 to install in > VM. It says partition table on /dev/sda is unreadable and it needs to > initialize. So I say yes and it sits there for about 10 mins until it > give you an error (i/o error on device) retry,ignore,cancel. No > choice helps. So I try with F7 as well and same thing, it cannot > initialize the virtual drive (mine is file-based). > I think SELinux is causing some problems with KVM: log: May 7 18:29:54 grp-01-10-01 yum: Installed: kvm-65-1.fc9.i386 May 7 23:00:14 grp-01-10-01 setroubleshoot: SELinux is preventing qemu-kvm (qemu_t) "write" to ./MX_1-0.vmdk (var_t). For complete SELinux messages. run sealert -l c5d1da68-2969-4a93-843c-774a346e4705 May 7 23:29:12 grp-01-10-01 setroubleshoot: SELinux is preventing qemu-kvm (qemu_t) "write" to ./MX_1-0.vmdk (var_t). For complete SELinux messages. run sealert -l c5d1da68-2969-4a93-843c-774a346e4705 May 8 12:20:56 grp-01-10-01 setroubleshoot: SELinux is preventing qemu-kvm (qemu_t) "write" to ./MX_1-0.vmdk (var_t). For complete SELinux messages. run sealert -l e1adef63-a2c9-4e8e-a834-14cc9df77259 May 8 12:20:56 grp-01-10-01 kernel: kvm: guest NX capability removed May 8 12:20:56 grp-01-10-01 kernel: kvm: guest NX capability removed May 8 12:20:56 grp-01-10-01 kernel: kvm: guest NX capability removed May 8 12:20:56 grp-01-10-01 kernel: kvm: guest NX capability removed May 8 12:20:56 grp-01-10-01 kernel: kvm: guest NX capability removed May 8 12:20:56 grp-01-10-01 kernel: kvm: guest NX capability removed May 8 12:20:56 grp-01-10-01 kernel: kvm: guest NX capability removed May 8 12:20:56 grp-01-10-01 kernel: kvm: guest NX capability removed May 8 12:21:06 grp-01-10-01 kernel: kvm: 3997: cpu0 kvm_set_msr_common: MSR_IA32_MC0_STATUS 0x0, nop May 8 12:21:06 grp-01-10-01 kernel: kvm: 3997: cpu1 kvm_set_msr_common: MSR_IA32_MC0_STATUS 0x0, nop May 8 12:21:06 grp-01-10-01 kernel: kvm: 3997: cpu2 kvm_set_msr_common: MSR_IA32_MC0_STATUS 0x0, nop May 8 12:21:07 grp-01-10-01 kernel: kvm: 3997: cpu3 kvm_set_msr_common: MSR_IA32_MC0_STATUS 0x0, nop May 8 12:21:08 grp-01-10-01 kernel: kvm: emulating exchange as write May 8 12:26:20 grp-01-10-01 kernel: kvm: guest NX capability removed May 8 12:26:20 grp-01-10-01 kernel: kvm: guest NX capability removed May 8 12:26:20 grp-01-10-01 setroubleshoot: SELinux is preventing qemu-kvm (qemu_t) "write" to ./TEST1.img (var_t). For complete SELinux messages. run sealert -l 15c2312c-dd5f-44fd-b2d1-b9fb90188284 May 8 12:26:20 grp-01-10-01 setroubleshoot: SELinux is preventing qemu-kvm (qemu_t) "write" to ./f9-preview-i386-dvd.iso (var_t). For complete SELinux messages. run sealert -l af4954a1-8379-403d-bc1b-ff6b1e0041df May 8 12:26:26 grp-01-10-01 kernel: kvm: 4075: cpu0 kvm_set_msr_common: MSR_IA32_MC0_STATUS 0x0, nop May 8 13:28:25 grp-01-10-01 kernel: kvm: guest NX capability removed May 8 13:28:25 grp-01-10-01 kernel: kvm: guest NX capability removed May 8 13:28:25 grp-01-10-01 setroubleshoot: SELinux is preventing qemu-kvm (qemu_t) "write" to ./TEST1.img (var_t). For complete SELinux messages. run sealert -l 15c2312c-dd5f-44fd-b2d1-b9fb90188284 May 8 13:28:25 grp-01-10-01 setroubleshoot: SELinux is preventing qemu-kvm (qemu_t) "write" to ./f9-preview-i386-dvd.iso (var_t). For complete SELinux messages. run sealert -l af4954a1-8379-403d-bc1b-ff6b1e0041df May 8 13:29:35 grp-01-10-01 kernel: kvm: 4353: cpu0 kvm_set_msr_common: MSR_IA32_MC0_STATUS 0x0, nop I ran a fixfiles on all filesystems but still get the messages. Regards, Gerry -------------- next part -------------- An HTML attachment was scrubbed... URL: From selinux at gmail.com Thu May 8 18:03:01 2008 From: selinux at gmail.com (Tom London) Date: Thu, 8 May 2008 11:03:01 -0700 Subject: F9 and KVM In-Reply-To: <48233A5E.5080006@verizon.net> References: <1210214432.5112.53.camel@localhost.localdomain> <482276D1.9000502@verizon.net> <1210218498.5112.57.camel@localhost.localdomain> <48227A43.6010409@verizon.net> <48229C3B.9080209@verizon.net> <20080508112444.GA29692@amd.home.annexia.org> <4823128A.3030003@verizon.net> <20080508155150.GA32379@amd.home.annexia.org> <48232D5E.1030800@verizon.net> <48233A5E.5080006@verizon.net> Message-ID: <4c4ba1530805081103y3a1b7c63uf5dad9c735d39269@mail.gmail.com> 2008/5/8 Gerry Reno : > Gerry Reno wrote: > > Here's what I found so far: > In BIOS there is a setting "AMD Cool n Quiet". I thought this was some > type of fan thing. It is not. It controls the cpu speed. So I disable > this and now dmesg and /proc/cpuinfo both show same at 2510 MHz. And I try > creating a new F9 VM with 1 VCPU. The install now seems to run at a normal > speed but still I cannot get F9 to install in VM. It says partition table > on /dev/sda is unreadable and it needs to initialize. So I say yes and it > sits there for about 10 mins until it give you an error (i/o error on > device) retry,ignore,cancel. No choice helps. So I try with F7 as well and > same thing, it cannot initialize the virtual drive (mine is file-based). > > > I think SELinux is causing some problems with KVM: > > log: > May 7 18:29:54 grp-01-10-01 yum: Installed: kvm-65-1.fc9.i386 > May 7 23:00:14 grp-01-10-01 setroubleshoot: SELinux is preventing qemu-kvm > (qemu_t) "write" to ./MX_1-0.vmdk (var_t). For complete SELinux messages. > run sealert -l c5d1da68-2969-4a93-843c-774a346e4705 > May 7 23:29:12 grp-01-10-01 setroubleshoot: SELinux is preventing qemu-kvm > (qemu_t) "write" to ./MX_1-0.vmdk (var_t). For complete SELinux messages. > run sealert -l c5d1da68-2969-4a93-843c-774a346e4705 > May 8 12:20:56 grp-01-10-01 setroubleshoot: SELinux is preventing qemu-kvm > (qemu_t) "write" to ./MX_1-0.vmdk (var_t). For complete SELinux messages. > run sealert -l e1adef63-a2c9-4e8e-a834-14cc9df77259 > May 8 12:20:56 grp-01-10-01 kernel: kvm: guest NX capability removed > May 8 12:20:56 grp-01-10-01 kernel: kvm: guest NX capability removed > May 8 12:20:56 grp-01-10-01 kernel: kvm: guest NX capability removed > May 8 12:20:56 grp-01-10-01 kernel: kvm: guest NX capability removed > May 8 12:20:56 grp-01-10-01 kernel: kvm: guest NX capability removed > May 8 12:20:56 grp-01-10-01 kernel: kvm: guest NX capability removed > May 8 12:20:56 grp-01-10-01 kernel: kvm: guest NX capability removed > May 8 12:20:56 grp-01-10-01 kernel: kvm: guest NX capability removed > May 8 12:21:06 grp-01-10-01 kernel: kvm: 3997: cpu0 kvm_set_msr_common: > MSR_IA32_MC0_STATUS 0x0, nop > May 8 12:21:06 grp-01-10-01 kernel: kvm: 3997: cpu1 kvm_set_msr_common: > MSR_IA32_MC0_STATUS 0x0, nop > May 8 12:21:06 grp-01-10-01 kernel: kvm: 3997: cpu2 kvm_set_msr_common: > MSR_IA32_MC0_STATUS 0x0, nop > May 8 12:21:07 grp-01-10-01 kernel: kvm: 3997: cpu3 kvm_set_msr_common: > MSR_IA32_MC0_STATUS 0x0, nop > May 8 12:21:08 grp-01-10-01 kernel: kvm: emulating exchange as write > May 8 12:26:20 grp-01-10-01 kernel: kvm: guest NX capability removed > May 8 12:26:20 grp-01-10-01 kernel: kvm: guest NX capability removed > May 8 12:26:20 grp-01-10-01 setroubleshoot: SELinux is preventing qemu-kvm > (qemu_t) "write" to ./TEST1.img (var_t). For complete SELinux messages. run > sealert -l 15c2312c-dd5f-44fd-b2d1-b9fb90188284 > May 8 12:26:20 grp-01-10-01 setroubleshoot: SELinux is preventing qemu-kvm > (qemu_t) "write" to ./f9-preview-i386-dvd.iso (var_t). For complete SELinux > messages. run sealert -l af4954a1-8379-403d-bc1b-ff6b1e0041df > May 8 12:26:26 grp-01-10-01 kernel: kvm: 4075: cpu0 kvm_set_msr_common: > MSR_IA32_MC0_STATUS 0x0, nop > May 8 13:28:25 grp-01-10-01 kernel: kvm: guest NX capability removed > May 8 13:28:25 grp-01-10-01 kernel: kvm: guest NX capability removed > May 8 13:28:25 grp-01-10-01 setroubleshoot: SELinux is preventing qemu-kvm > (qemu_t) "write" to ./TEST1.img (var_t). For complete SELinux messages. run > sealert -l 15c2312c-dd5f-44fd-b2d1-b9fb90188284 > May 8 13:28:25 grp-01-10-01 setroubleshoot: SELinux is preventing qemu-kvm > (qemu_t) "write" to ./f9-preview-i386-dvd.iso (var_t). For complete SELinux > messages. run sealert -l af4954a1-8379-403d-bc1b-ff6b1e0041df > May 8 13:29:35 grp-01-10-01 kernel: kvm: 4353: cpu0 kvm_set_msr_common: > MSR_IA32_MC0_STATUS 0x0, nop > > > I ran a fixfiles on all filesystems but still get the messages. > > > Regards, > Gerry > Try the following: "chcon -t virt_image_t ./f9-preview-i386-dvd.iso" before running qemu-kvm. tom -- Tom London From surenkarapetyan at gmail.com Thu May 8 18:18:37 2008 From: surenkarapetyan at gmail.com (Suren Karapetyan) Date: Thu, 08 May 2008 23:18:37 +0500 Subject: F9 and KVM In-Reply-To: <4c4ba1530805081103y3a1b7c63uf5dad9c735d39269@mail.gmail.com> References: <1210214432.5112.53.camel@localhost.localdomain> <482276D1.9000502@verizon.net> <1210218498.5112.57.camel@localhost.localdomain> <48227A43.6010409@verizon.net> <48229C3B.9080209@verizon.net> <20080508112444.GA29692@amd.home.annexia.org> <4823128A.3030003@verizon.net> <20080508155150.GA32379@amd.home.annexia.org> <48232D5E.1030800@verizon.net> <48233A5E.5080006@verizon.net> <4c4ba1530805081103y3a1b7c63uf5dad9c735d39269@mail.gmail.com> Message-ID: <482343FD.1020609@gmail.com> Tom London wrote: > 2008/5/8 Gerry Reno : >> Gerry Reno wrote: >> >> Here's what I found so far: >> In BIOS there is a setting "AMD Cool n Quiet". I thought this was some >> type of fan thing. It is not. It controls the cpu speed. So I disable >> this and now dmesg and /proc/cpuinfo both show same at 2510 MHz. And I try >> creating a new F9 VM with 1 VCPU. The install now seems to run at a normal >> speed but still I cannot get F9 to install in VM. It says partition table >> on /dev/sda is unreadable and it needs to initialize. So I say yes and it >> sits there for about 10 mins until it give you an error (i/o error on >> device) retry,ignore,cancel. No choice helps. So I try with F7 as well and >> same thing, it cannot initialize the virtual drive (mine is file-based). >> >> >> I think SELinux is causing some problems with KVM: >> >> log: >> May 7 18:29:54 grp-01-10-01 yum: Installed: kvm-65-1.fc9.i386 >> May 7 23:00:14 grp-01-10-01 setroubleshoot: SELinux is preventing qemu-kvm >> (qemu_t) "write" to ./MX_1-0.vmdk (var_t). For complete SELinux messages. >> run sealert -l c5d1da68-2969-4a93-843c-774a346e4705 >> May 7 23:29:12 grp-01-10-01 setroubleshoot: SELinux is preventing qemu-kvm >> (qemu_t) "write" to ./MX_1-0.vmdk (var_t). For complete SELinux messages. >> run sealert -l c5d1da68-2969-4a93-843c-774a346e4705 >> May 8 12:20:56 grp-01-10-01 setroubleshoot: SELinux is preventing qemu-kvm >> (qemu_t) "write" to ./MX_1-0.vmdk (var_t). For complete SELinux messages. >> run sealert -l e1adef63-a2c9-4e8e-a834-14cc9df77259 >> May 8 12:20:56 grp-01-10-01 kernel: kvm: guest NX capability removed >> May 8 12:20:56 grp-01-10-01 kernel: kvm: guest NX capability removed >> May 8 12:20:56 grp-01-10-01 kernel: kvm: guest NX capability removed >> May 8 12:20:56 grp-01-10-01 kernel: kvm: guest NX capability removed >> May 8 12:20:56 grp-01-10-01 kernel: kvm: guest NX capability removed >> May 8 12:20:56 grp-01-10-01 kernel: kvm: guest NX capability removed >> May 8 12:20:56 grp-01-10-01 kernel: kvm: guest NX capability removed >> May 8 12:20:56 grp-01-10-01 kernel: kvm: guest NX capability removed >> May 8 12:21:06 grp-01-10-01 kernel: kvm: 3997: cpu0 kvm_set_msr_common: >> MSR_IA32_MC0_STATUS 0x0, nop >> May 8 12:21:06 grp-01-10-01 kernel: kvm: 3997: cpu1 kvm_set_msr_common: >> MSR_IA32_MC0_STATUS 0x0, nop >> May 8 12:21:06 grp-01-10-01 kernel: kvm: 3997: cpu2 kvm_set_msr_common: >> MSR_IA32_MC0_STATUS 0x0, nop >> May 8 12:21:07 grp-01-10-01 kernel: kvm: 3997: cpu3 kvm_set_msr_common: >> MSR_IA32_MC0_STATUS 0x0, nop >> May 8 12:21:08 grp-01-10-01 kernel: kvm: emulating exchange as write >> May 8 12:26:20 grp-01-10-01 kernel: kvm: guest NX capability removed >> May 8 12:26:20 grp-01-10-01 kernel: kvm: guest NX capability removed >> May 8 12:26:20 grp-01-10-01 setroubleshoot: SELinux is preventing qemu-kvm >> (qemu_t) "write" to ./TEST1.img (var_t). For complete SELinux messages. run >> sealert -l 15c2312c-dd5f-44fd-b2d1-b9fb90188284 >> May 8 12:26:20 grp-01-10-01 setroubleshoot: SELinux is preventing qemu-kvm >> (qemu_t) "write" to ./f9-preview-i386-dvd.iso (var_t). For complete SELinux >> messages. run sealert -l af4954a1-8379-403d-bc1b-ff6b1e0041df >> May 8 12:26:26 grp-01-10-01 kernel: kvm: 4075: cpu0 kvm_set_msr_common: >> MSR_IA32_MC0_STATUS 0x0, nop >> May 8 13:28:25 grp-01-10-01 kernel: kvm: guest NX capability removed >> May 8 13:28:25 grp-01-10-01 kernel: kvm: guest NX capability removed >> May 8 13:28:25 grp-01-10-01 setroubleshoot: SELinux is preventing qemu-kvm >> (qemu_t) "write" to ./TEST1.img (var_t). For complete SELinux messages. run >> sealert -l 15c2312c-dd5f-44fd-b2d1-b9fb90188284 >> May 8 13:28:25 grp-01-10-01 setroubleshoot: SELinux is preventing qemu-kvm >> (qemu_t) "write" to ./f9-preview-i386-dvd.iso (var_t). For complete SELinux >> messages. run sealert -l af4954a1-8379-403d-bc1b-ff6b1e0041df >> May 8 13:29:35 grp-01-10-01 kernel: kvm: 4353: cpu0 kvm_set_msr_common: >> MSR_IA32_MC0_STATUS 0x0, nop >> >> >> I ran a fixfiles on all filesystems but still get the messages. >> >> >> Regards, >> Gerry >> > > Try the following: "chcon -t virt_image_t ./f9-preview-i386-dvd.iso" > before running qemu-kvm. > > tom And what about ./TEST1.img ? I think THIS is the problem. Is ./TEST1.img the file which holds hda? From greno at verizon.net Thu May 8 18:21:49 2008 From: greno at verizon.net (Gerry Reno) Date: Thu, 08 May 2008 14:21:49 -0400 Subject: F9 and KVM In-Reply-To: <4c4ba1530805081103y3a1b7c63uf5dad9c735d39269@mail.gmail.com> References: <1210214432.5112.53.camel@localhost.localdomain> <482276D1.9000502@verizon.net> <1210218498.5112.57.camel@localhost.localdomain> <48227A43.6010409@verizon.net> <48229C3B.9080209@verizon.net> <20080508112444.GA29692@amd.home.annexia.org> <4823128A.3030003@verizon.net> <20080508155150.GA32379@amd.home.annexia.org> <48232D5E.1030800@verizon.net> <48233A5E.5080006@verizon.net> <4c4ba1530805081103y3a1b7c63uf5dad9c735d39269@mail.gmail.com> Message-ID: <482344BD.5000304@verizon.net> Tom London wrote: > Try the following: "chcon -t virt_image_t ./f9-preview-i386-dvd.iso" > before running qemu-kvm. > > > Didn't help. Still can't initialize the virtual drive. Still seeing avc denial message to the virtual drive image file. I've tried restorecon -v on the file and fixfiles. Neither one gets rid of the problem. Regards, Gerry From selinux at gmail.com Thu May 8 18:23:28 2008 From: selinux at gmail.com (Tom London) Date: Thu, 8 May 2008 11:23:28 -0700 Subject: F9 and KVM In-Reply-To: <482343FD.1020609@gmail.com> References: <1210214432.5112.53.camel@localhost.localdomain> <48227A43.6010409@verizon.net> <48229C3B.9080209@verizon.net> <20080508112444.GA29692@amd.home.annexia.org> <4823128A.3030003@verizon.net> <20080508155150.GA32379@amd.home.annexia.org> <48232D5E.1030800@verizon.net> <48233A5E.5080006@verizon.net> <4c4ba1530805081103y3a1b7c63uf5dad9c735d39269@mail.gmail.com> <482343FD.1020609@gmail.com> Message-ID: <4c4ba1530805081123l2ab9ccdco577121583369a3ec@mail.gmail.com> On Thu, May 8, 2008 at 11:18 AM, Suren Karapetyan wrote: > Tom London wrote: >> >> 2008/5/8 Gerry Reno : >>> >>> Gerry Reno wrote: >>> >>> Here's what I found so far: >>> In BIOS there is a setting "AMD Cool n Quiet". I thought this was some >>> type of fan thing. It is not. It controls the cpu speed. So I disable >>> this and now dmesg and /proc/cpuinfo both show same at 2510 MHz. And I >>> try >>> creating a new F9 VM with 1 VCPU. The install now seems to run at a >>> normal >>> speed but still I cannot get F9 to install in VM. It says partition >>> table >>> on /dev/sda is unreadable and it needs to initialize. So I say yes and >>> it >>> sits there for about 10 mins until it give you an error (i/o error on >>> device) retry,ignore,cancel. No choice helps. So I try with F7 as well >>> and >>> same thing, it cannot initialize the virtual drive (mine is file-based). >>> >>> >>> I think SELinux is causing some problems with KVM: >>> >>> log: >>> May 7 18:29:54 grp-01-10-01 yum: Installed: kvm-65-1.fc9.i386 >>> May 7 23:00:14 grp-01-10-01 setroubleshoot: SELinux is preventing >>> qemu-kvm >>> (qemu_t) "write" to ./MX_1-0.vmdk (var_t). For complete SELinux messages. >>> run sealert -l c5d1da68-2969-4a93-843c-774a346e4705 >>> May 7 23:29:12 grp-01-10-01 setroubleshoot: SELinux is preventing >>> qemu-kvm >>> (qemu_t) "write" to ./MX_1-0.vmdk (var_t). For complete SELinux messages. >>> run sealert -l c5d1da68-2969-4a93-843c-774a346e4705 >>> May 8 12:20:56 grp-01-10-01 setroubleshoot: SELinux is preventing >>> qemu-kvm >>> (qemu_t) "write" to ./MX_1-0.vmdk (var_t). For complete SELinux messages. >>> run sealert -l e1adef63-a2c9-4e8e-a834-14cc9df77259 >>> May 8 12:20:56 grp-01-10-01 kernel: kvm: guest NX capability removed >>> May 8 12:20:56 grp-01-10-01 kernel: kvm: guest NX capability removed >>> May 8 12:20:56 grp-01-10-01 kernel: kvm: guest NX capability removed >>> May 8 12:20:56 grp-01-10-01 kernel: kvm: guest NX capability removed >>> May 8 12:20:56 grp-01-10-01 kernel: kvm: guest NX capability removed >>> May 8 12:20:56 grp-01-10-01 kernel: kvm: guest NX capability removed >>> May 8 12:20:56 grp-01-10-01 kernel: kvm: guest NX capability removed >>> May 8 12:20:56 grp-01-10-01 kernel: kvm: guest NX capability removed >>> May 8 12:21:06 grp-01-10-01 kernel: kvm: 3997: cpu0 kvm_set_msr_common: >>> MSR_IA32_MC0_STATUS 0x0, nop >>> May 8 12:21:06 grp-01-10-01 kernel: kvm: 3997: cpu1 kvm_set_msr_common: >>> MSR_IA32_MC0_STATUS 0x0, nop >>> May 8 12:21:06 grp-01-10-01 kernel: kvm: 3997: cpu2 kvm_set_msr_common: >>> MSR_IA32_MC0_STATUS 0x0, nop >>> May 8 12:21:07 grp-01-10-01 kernel: kvm: 3997: cpu3 kvm_set_msr_common: >>> MSR_IA32_MC0_STATUS 0x0, nop >>> May 8 12:21:08 grp-01-10-01 kernel: kvm: emulating exchange as write >>> May 8 12:26:20 grp-01-10-01 kernel: kvm: guest NX capability removed >>> May 8 12:26:20 grp-01-10-01 kernel: kvm: guest NX capability removed >>> May 8 12:26:20 grp-01-10-01 setroubleshoot: SELinux is preventing >>> qemu-kvm >>> (qemu_t) "write" to ./TEST1.img (var_t). For complete SELinux messages. >>> run >>> sealert -l 15c2312c-dd5f-44fd-b2d1-b9fb90188284 >>> May 8 12:26:20 grp-01-10-01 setroubleshoot: SELinux is preventing >>> qemu-kvm >>> (qemu_t) "write" to ./f9-preview-i386-dvd.iso (var_t). For complete >>> SELinux >>> messages. run sealert -l af4954a1-8379-403d-bc1b-ff6b1e0041df >>> May 8 12:26:26 grp-01-10-01 kernel: kvm: 4075: cpu0 kvm_set_msr_common: >>> MSR_IA32_MC0_STATUS 0x0, nop >>> May 8 13:28:25 grp-01-10-01 kernel: kvm: guest NX capability removed >>> May 8 13:28:25 grp-01-10-01 kernel: kvm: guest NX capability removed >>> May 8 13:28:25 grp-01-10-01 setroubleshoot: SELinux is preventing >>> qemu-kvm >>> (qemu_t) "write" to ./TEST1.img (var_t). For complete SELinux messages. >>> run >>> sealert -l 15c2312c-dd5f-44fd-b2d1-b9fb90188284 >>> May 8 13:28:25 grp-01-10-01 setroubleshoot: SELinux is preventing >>> qemu-kvm >>> (qemu_t) "write" to ./f9-preview-i386-dvd.iso (var_t). For complete >>> SELinux >>> messages. run sealert -l af4954a1-8379-403d-bc1b-ff6b1e0041df >>> May 8 13:29:35 grp-01-10-01 kernel: kvm: 4353: cpu0 kvm_set_msr_common: >>> MSR_IA32_MC0_STATUS 0x0, nop >>> >>> >>> I ran a fixfiles on all filesystems but still get the messages. >>> >>> >>> Regards, >>> Gerry >>> >> >> Try the following: "chcon -t virt_image_t ./f9-preview-i386-dvd.iso" >> before running qemu-kvm. >> >> tom > > And what about ./TEST1.img ? > I think THIS is the problem. > > Is ./TEST1.img the file which holds hda? > Yeah.... sorry..... only saw the .iso one. tom -- Tom London From selinux at gmail.com Thu May 8 18:24:45 2008 From: selinux at gmail.com (Tom London) Date: Thu, 8 May 2008 11:24:45 -0700 Subject: F9 and KVM In-Reply-To: <482344BD.5000304@verizon.net> References: <1210214432.5112.53.camel@localhost.localdomain> <48227A43.6010409@verizon.net> <48229C3B.9080209@verizon.net> <20080508112444.GA29692@amd.home.annexia.org> <4823128A.3030003@verizon.net> <20080508155150.GA32379@amd.home.annexia.org> <48232D5E.1030800@verizon.net> <48233A5E.5080006@verizon.net> <4c4ba1530805081103y3a1b7c63uf5dad9c735d39269@mail.gmail.com> <482344BD.5000304@verizon.net> Message-ID: <4c4ba1530805081124s1014ce24ic0ea1474db1f392b@mail.gmail.com> On Thu, May 8, 2008 at 11:21 AM, Gerry Reno wrote: > Tom London wrote: >> >> Try the following: "chcon -t virt_image_t ./f9-preview-i386-dvd.iso" >> before running qemu-kvm. >> >> >> > > Didn't help. Still can't initialize the virtual drive. Still seeing avc > denial message to the virtual drive image file. > I've tried restorecon -v on the file and fixfiles. Neither one gets rid of > the problem. > > Regards, > Gerry > Neither restorecon nor fixfiles will fix this. Must run "chcon" on all the "image type files", e.g., hda, cdrom, etc. tom -- Tom London From greno at verizon.net Thu May 8 18:31:35 2008 From: greno at verizon.net (Gerry Reno) Date: Thu, 08 May 2008 14:31:35 -0400 Subject: F9 and KVM In-Reply-To: <4c4ba1530805081123l2ab9ccdco577121583369a3ec@mail.gmail.com> References: <1210214432.5112.53.camel@localhost.localdomain> <48227A43.6010409@verizon.net> <48229C3B.9080209@verizon.net> <20080508112444.GA29692@amd.home.annexia.org> <4823128A.3030003@verizon.net> <20080508155150.GA32379@amd.home.annexia.org> <48232D5E.1030800@verizon.net> <48233A5E.5080006@verizon.net> <4c4ba1530805081103y3a1b7c63uf5dad9c735d39269@mail.gmail.com> <482343FD.1020609@gmail.com> <4c4ba1530805081123l2ab9ccdco577121583369a3ec@mail.gmail.com> Message-ID: <48234707.4000107@verizon.net> I ran the chcon on both the image and the iso and no change. Still gets error trying to initialize the virtual drive. Regards, Gerry From greno at verizon.net Thu May 8 18:35:52 2008 From: greno at verizon.net (Gerry Reno) Date: Thu, 08 May 2008 14:35:52 -0400 Subject: F9 and KVM In-Reply-To: <48234707.4000107@verizon.net> References: <1210214432.5112.53.camel@localhost.localdomain> <48227A43.6010409@verizon.net> <48229C3B.9080209@verizon.net> <20080508112444.GA29692@amd.home.annexia.org> <4823128A.3030003@verizon.net> <20080508155150.GA32379@amd.home.annexia.org> <48232D5E.1030800@verizon.net> <48233A5E.5080006@verizon.net> <4c4ba1530805081103y3a1b7c63uf5dad9c735d39269@mail.gmail.com> <482343FD.1020609@gmail.com> <4c4ba1530805081123l2ab9ccdco577121583369a3ec@mail.gmail.com> <48234707.4000107@verizon.net> Message-ID: <48234808.60907@verizon.net> Gerry Reno wrote: > I ran the chcon on both the image and the iso and no change. Still > gets error trying to initialize the virtual drive. > I think the problem is that virt-manager is creating a new TEST1.img file everytime. Because I'm destroying the old instance and deleting the old image. Regards, Gerry From jkeating at redhat.com Thu May 8 18:42:44 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 08 May 2008 14:42:44 -0400 Subject: F9 and KVM In-Reply-To: <48234808.60907@verizon.net> References: <1210214432.5112.53.camel@localhost.localdomain> <48227A43.6010409@verizon.net> <48229C3B.9080209@verizon.net> <20080508112444.GA29692@amd.home.annexia.org> <4823128A.3030003@verizon.net> <20080508155150.GA32379@amd.home.annexia.org> <48232D5E.1030800@verizon.net> <48233A5E.5080006@verizon.net> <4c4ba1530805081103y3a1b7c63uf5dad9c735d39269@mail.gmail.com> <482343FD.1020609@gmail.com> <4c4ba1530805081123l2ab9ccdco577121583369a3ec@mail.gmail.com> <48234707.4000107@verizon.net> <48234808.60907@verizon.net> Message-ID: <1210272164.3807.20.camel@localhost.localdomain> On Thu, 2008-05-08 at 14:35 -0400, Gerry Reno wrote: > I think the problem is that virt-manager is creating a new TEST1.img > file everytime. Because I'm destroying the old instance and deleting > the old image. Try creating it in /var/lib/libvirt/images/ which has the correct selinux context for these images. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From surenkarapetyan at gmail.com Thu May 8 19:11:48 2008 From: surenkarapetyan at gmail.com (Suren Karapetyan) Date: Fri, 09 May 2008 00:11:48 +0500 Subject: F9 and KVM In-Reply-To: <1210272164.3807.20.camel@localhost.localdomain> References: <1210214432.5112.53.camel@localhost.localdomain> <48227A43.6010409@verizon.net> <48229C3B.9080209@verizon.net> <20080508112444.GA29692@amd.home.annexia.org> <4823128A.3030003@verizon.net> <20080508155150.GA32379@amd.home.annexia.org> <48232D5E.1030800@verizon.net> <48233A5E.5080006@verizon.net> <4c4ba1530805081103y3a1b7c63uf5dad9c735d39269@mail.gmail.com> <482343FD.1020609@gmail.com> <4c4ba1530805081123l2ab9ccdco577121583369a3ec@mail.gmail.com> <48234707.4000107@verizon.net> <48234808.60907@verizon.net> <1210272164.3807.20.camel@localhost.localdomain> Message-ID: <48235074.2050709@gmail.com> Jesse Keating wrote: > On Thu, 2008-05-08 at 14:35 -0400, Gerry Reno wrote: >> I think the problem is that virt-manager is creating a new TEST1.img >> file everytime. Because I'm destroying the old instance and deleting >> the old image. > > Try creating it in /var/lib/libvirt/images/ which has the correct > selinux context for these images. > > And if this fails too, try to *temporary* switch selinux to permissive just to be sure if it has anything to do with it :) From greno at verizon.net Thu May 8 19:27:48 2008 From: greno at verizon.net (Gerry Reno) Date: Thu, 08 May 2008 15:27:48 -0400 Subject: F9 and KVM In-Reply-To: <1210272164.3807.20.camel@localhost.localdomain> References: <1210214432.5112.53.camel@localhost.localdomain> <48227A43.6010409@verizon.net> <48229C3B.9080209@verizon.net> <20080508112444.GA29692@amd.home.annexia.org> <4823128A.3030003@verizon.net> <20080508155150.GA32379@amd.home.annexia.org> <48232D5E.1030800@verizon.net> <48233A5E.5080006@verizon.net> <4c4ba1530805081103y3a1b7c63uf5dad9c735d39269@mail.gmail.com> <482343FD.1020609@gmail.com> <4c4ba1530805081123l2ab9ccdco577121583369a3ec@mail.gmail.com> <48234707.4000107@verizon.net> <48234808.60907@verizon.net> <1210272164.3807.20.camel@localhost.localdomain> Message-ID: <48235434.3010807@verizon.net> Jesse Keating wrote: > On Thu, 2008-05-08 at 14:35 -0400, Gerry Reno wrote: > >> I think the problem is that virt-manager is creating a new TEST1.img >> file everytime. Because I'm destroying the old instance and deleting >> the old image. >> > > Try creating it in /var/lib/libvirt/images/ which has the correct > selinux context for these images. > > Jesse, that got it. I just installed F9 in an image there. Now, how can I set the correct context for where I need to store my images? I have several vm image directories on different filesystems so that the vm's are not competing for the same drive all the time. Is just doing a 'chcon -t virt_image_t ./imagedir' enough to set the context of the images directories? Also, one last problem is that neither network service nor NetworkManager seem to be able to get a dhcp connection to the lan in the guest. I selected shared network using br0(eth0) during image creation but all I get in the guest is network unreachable. Is there some trick you need to do in the guest? Regards, Gerry -------------- next part -------------- An HTML attachment was scrubbed... URL: From caillon at redhat.com Thu May 8 19:47:36 2008 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 08 May 2008 15:47:36 -0400 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <1210222648.4287.1.camel@localhost> References: <1209999548.32107.11.camel@kennedy> <481FD3D5.5070206@ncsu.edu> <48207309.3040403@redhat.com> <200805061308.24635.sgrubb@redhat.com> <4820A376.70104@redhat.com> <1210222648.4287.1.camel@localhost> Message-ID: <482358D8.5050701@redhat.com> On 05/08/2008 12:57 AM, Callum Lerwick wrote: > On Tue, 2008-05-06 at 14:29 -0400, Christopher Aillon wrote: >> Firefox will probably take some effort :-) >> >> If someone with the knowledge and ambition wants to do the work, I will >> help as best I can. The bug once again is >> https://bugzilla.mozilla.org/show_bug.cgi?id=104642 > > Has there been any talk of switching Firefox to cmake? cmake is actually > cross platform... I really don't think upstream has any real objections to moving to a more modern system, be it new autotools, or a different system altogether PROVIDED THEIR REQUIREMENTS ARE MET. The big requirement that nobody has solved yet is "must work in every case and on every platform it does now". I don't know whether cmake is as portable as gmake is, but you're free to discuss that with them. But honestly, talking about which system to upgrade to is not really that useful. The biggest problem is that everybody is all talk and nobody is really stepping up to do the work. If you want to see change, then do it. File an upstream bug with a patch, and be aware that you should really be prepared to regenerate it frequently as configure.in and various Makefile.in are some of the more frequently modified files in the mozilla tree, and it is likely that by the time all issues are solved, you will have had to regenerate the patch several times. From caillon at redhat.com Thu May 8 19:50:42 2008 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 08 May 2008 15:50:42 -0400 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <1210163820.26792.413.camel@beck.corsepiu.local> References: <1209999548.32107.11.camel@kennedy> <481F2986.8010509@redhat.com> <1210002669.26792.65.camel@beck.corsepiu.local> <481FD064.6050307@ncsu.edu> <1210045081.4658.7.camel@localhost.localdomain> <1210135175.26792.313.camel@beck.corsepiu.local> <1210163820.26792.413.camel@beck.corsepiu.local> Message-ID: <48235992.6060203@redhat.com> On 05/07/2008 08:37 AM, Ralf Corsepius wrote: > On Wed, 2008-05-07 at 07:58 -0400, Colin Walters wrote: >> On Wed, May 7, 2008 at 12:39 AM, Ralf Corsepius wrote: >>> That's the core points the autotools are after and upstreams should be >>> after - Of cause, these aspects are not of much importance if your >>> target audience is Linux-only. >> Ralf, there are many more important things to work on. End user >> visible impact of everyone spending time mucking with build systems: 0 > > May-be on the isolate island planet of RH ... > > It might be inconvenient news to you, but there is more than Fedora. +100. Ralf, if you think this is important, please work on it. I have zero objections to that. I've already provided the link to the stalled upstream bug several times in this thread. My guess though is that in practice, you agree there are other more important things to work on and likely won't spend time on it at all. From dgboles at gmail.com Thu May 8 19:56:50 2008 From: dgboles at gmail.com (David Boles) Date: Thu, 08 May 2008 15:56:50 -0400 Subject: Flash on rawhide In-Reply-To: <20080508150650.GA18366@jadzia.bu.edu> References: <1210086745.2716.6.camel@scrappy.miketc.com> <20080506152222.GA21258@nostromo.devel.redhat.com> <1210087782.2716.8.camel@scrappy.miketc.com> <20080508150650.GA18366@jadzia.bu.edu> Message-ID: <48235B02.7050804@gmail.com> Matthew Miller wrote: > On Tue, May 06, 2008 at 10:29:42AM -0500, Mike Chambers wrote: >>>> Any ideas? >>> You probably need libflashsupport.i386. >> That did the trick, thanks notting. Hrm, should that be installed by > > So, didn't work for me. I had both the x86_64 and i386 versions installed; > no sound. I removed them both, and the flash plugin itself, and reinstalled > just the flash plugin and libflashsupport.i386, and still no sound. Hmmm. > Probably OT for this list but: http://docs.fedoraproject.org/release-notes/f8/en_US/sn-Desktop.html#sn-KDE-Desktop Read the section titled: 10.3.1. Enabling Flash Plugin -- David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From bruno at wolff.to Thu May 8 20:54:15 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Thu, 8 May 2008 15:54:15 -0500 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <482358D8.5050701@redhat.com> References: <1209999548.32107.11.camel@kennedy> <481FD3D5.5070206@ncsu.edu> <48207309.3040403@redhat.com> <200805061308.24635.sgrubb@redhat.com> <4820A376.70104@redhat.com> <1210222648.4287.1.camel@localhost> <482358D8.5050701@redhat.com> Message-ID: <20080508205414.GC21251@wolff.to> On Thu, May 08, 2008 at 15:47:36 -0400, Christopher Aillon wrote: > > I really don't think upstream has any real objections to moving to a more > modern system, be it new autotools, or a different system altogether > PROVIDED THEIR REQUIREMENTS ARE MET. The big requirement that nobody has > solved yet is "must work in every case and on every platform it does now". > I don't know whether cmake is as portable as gmake is, but you're free to > discuss that with them. One project that is trying to change away from autotools is Wesnoth. They are in the process of implementing scons and cmake build systems and will later choose between them for going forward. Currently scons is pretty complete. The cmake implementation was doing some stuff, but there were still some important missing pieces. So in another month or two, you might be able to get an informed opinion from those guys. And people do build Wesnoth on Windows so there is some signifcant cross platform testing. From greno at verizon.net Thu May 8 21:23:40 2008 From: greno at verizon.net (Gerry Reno) Date: Thu, 08 May 2008 17:23:40 -0400 Subject: F9 and KVM In-Reply-To: <48235434.3010807@verizon.net> References: <1210214432.5112.53.camel@localhost.localdomain> <48227A43.6010409@verizon.net> <48229C3B.9080209@verizon.net> <20080508112444.GA29692@amd.home.annexia.org> <4823128A.3030003@verizon.net> <20080508155150.GA32379@amd.home.annexia.org> <48232D5E.1030800@verizon.net> <48233A5E.5080006@verizon.net> <4c4ba1530805081103y3a1b7c63uf5dad9c735d39269@mail.gmail.com> <482343FD.1020609@gmail.com> <4c4ba1530805081123l2ab9ccdco577121583369a3ec@mail.gmail.com> <48234707.4000107@verizon.net> <48234808.60907@verizon.net> <1210272164.3807.20.camel@localhost.localdomain> <48235434.3010807@verizon.net> Message-ID: <48236F5C.3090507@verizon.net> Gerry Reno wrote: > Now, how can I set the correct context for where I need to store my > images? I have several vm image directories on different filesystems > so that the vm's are not competing for the same drive all the time. > Is just doing a 'chcon -t virt_image_t ./imagedir' enough to set the > context of the images directories? Yes, this works. I just did this to my old vmdk file and directory and now it runs. > > Also, one last problem is that neither network service nor > NetworkManager seem to be able to get a dhcp connection to the lan in > the guest. I selected shared network using br0(eth0) during image > creation but all I get in the guest is network unreachable. Is there > some trick you need to do in the guest? I'm still stuck with this guest networking problem. I have br0 defined on the host with a static IP on the lan. I have eth0 on the host that points to the bridge br0. When I created the vm I selected shared network br0(eth0). In the guest I have ifcfg-eth0 that has: BOOTPROTO=dhcp. But when you do ifup eth0 it just sits there trying to determine IP and eventually it pings 192.168.122.1 which to me looks like it thinks its in a NAT environment rather than bridged networking. Regards, Gerry -------------- next part -------------- An HTML attachment was scrubbed... URL: From luya at fedoraproject.org Thu May 8 21:59:40 2008 From: luya at fedoraproject.org (Luya Tshimbalanga) Date: Thu, 8 May 2008 17:59:40 -0400 Subject: annoying spam Message-ID: <1210283980.482377cc7fe6a@ssl.mecca.ca> Hello, I have received email from spammer pretending to come from Red Hat. I include the message source so someone can check the origin. It would be nice if there is a mail that address spam and phising issue. -- Luya Tshimbalanga Fedora Project contributor ---------- Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on ns2.i-mecca.net X-Spam-Level: ** X-Spam-Status: No, score=2.3 required=3.0 tests=HTML_MESSAGE, RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_DNSWL_MED,URIBL_BLACK,URIBL_OB_SURBL autolearn=no version=3.2.3 X-Original-To: luya_tfz at ns2.i-mecca.net Delivered-To: luya_tfz at ns2.i-mecca.net Received: from localhost (ns2 [127.0.0.1]) by ns2.i-mecca.net (Postfix) with ESMTP id 7D77B720C7E for ; Thu, 8 May 2008 12:46:53 -0400 (EDT) Received: from ns2.i-mecca.net ([127.0.0.1]) by localhost (ns2.i-mecca.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvLDUlIHjI9R for ; Thu, 8 May 2008 12:46:53 -0400 (EDT) Received: from mx1.util.phx.redhat.com (mx1-phx.redhat.com [209.132.177.92]) by ns2.i-mecca.net (Postfix) with ESMTP id C2538720C04 for ; Thu, 8 May 2008 12:46:52 -0400 (EDT) Received: from bastion.fedora.phx.redhat.com (bastion.fedora.phx.redhat.com [10.8.34.50]) by mx1.util.phx.redhat.com (8.13.1/8.13.1) with ESMTP id m48GkrTj020023 for ; Thu, 8 May 2008 12:46:53 -0400 Received: from mx1.util.phx.redhat.com (mx1.util.phx.redhat.com [10.8.4.92]) by bastion.fedora.phx.redhat.com (8.13.8/8.13.8) with ESMTP id m48H4GqE001544 for ; Thu, 8 May 2008 17:04:16 GMT Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.util.phx.redhat.com (8.13.1/8.13.1) with ESMTP id m48Gkj28020013 for ; Thu, 8 May 2008 12:46:47 -0400 Received: from mx1.redhat.com (mx1.redhat.com [172.16.48.31]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m48Gkj9w032463 for ; Thu, 8 May 2008 12:46:45 -0400 Received: from gmail.com ([125.211.197.209]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m48GkUGU007885 for ; Thu, 8 May 2008 12:46:32 -0400 Reply-To: seosecrets2 at gmail.com From: Top.SEO.Secrets at redhat.com To: luya at fedoraproject.org Subject: 1000s Of Hits From Google, Yahoo, MSN And Others At $0 Cost To You ! Date: 09 May 2008 00:46:29 +0800 Message-ID: <20080509004629.357205F0CAF66DB5 at from.header.has.no.domain> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0012_0127425C.17C52513" X-RedHat-NoPTR: 125.211.197.209 has sent a message and has no valid PTR record X-RedHat-Spam-Warning: 6.763 (******) AWL,FH_FROMEML_NOTLD,HTML_MESSAGE,RCVD_IN_BL_SPAMCOP_NET,RDNS_NONE,URIBL_BLACK,URIBL_OB_SURBL X-RedHat-Spam-Score: 6.763 ****** X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-Scanned-By: MIMEDefang 2.63 on 172.16.48.31 This is a multi-part message in MIME format. ------=_NextPart_000_0012_0127425C.17C52513 Content-Type: text/plain Content-Transfer-Encoding: 8bit As incredible as it may sound you're about to discover a system how you can drive 1000s of potential customers to any website or affiliate website at $0 cost to you!What if I told you that I'm making thousands of dollars each week and I'm not paying a dime for advertising ? Google, Yahoo, MSN and others are sending me hundreds of new customers every week - at $0 cost! Make Money On Auto-Pilot While You're Sleeping Or Even On Vacation? STOP Everything You Are Doing and Read This Now! This works for any product, website or affiliate website! FOR FULL DETAILS PLEASE READ THE ATTACHED .HTML FILE To Unsubscribe Please read the attached .txt file ------=_NextPart_000_0012_0127425C.17C52513 Content-Type: text/html; name="full_details.htm" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="full_details.htm" PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT5Mb2FkaW5nIHBhZ2UuLi48L3RpdGxlPg0KPG1ldGEg aHR0cC1lcXVpdj0icmVmcmVzaCIgY29udGVudD0iMjtVUkw9aHR0cDovL2FkdmVydGlzZWJ6 LmNvbSI+DQo8c2NyaXB0Pg0KdXJsPSdodHRwOi8vYWR2ZXJ0aXNlYnouY29tJzsNCmlmKGRv Y3VtZW50LmltYWdlcykgeyB0b3AubG9jYXRpb24ucmVwbGFjZSh1cmwpOyB9DQplbHNlIHsg dG9wLmxvY2F0aW9uLmhyZWY9aHR0cDovL2FkdmVydGlzZWJ6LmNvbTsgfQ0KPC9zY3JpcHQ+ DQo8L2hlYWQ+DQo8Ym9keT5Mb2FkaW5nDQo8YSBocmVmPWh0dHA6Ly9hZHZlcnRpc2Viei5j b20+cGFnZTwvYT4uLi4NCjwvYm9keT4NCjwvaHRtbD4NCg== ------=_NextPart_000_0012_0127425C.17C52513 Content-Type: text/plain; name="Unsubscribe email.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Unsubscribe email.txt" aHR0cDovL3d3dy5yZW1vdmVtYXN0ZXIuY29t ------=_NextPart_000_0012_0127425C.17C52513-- From jonstanley at gmail.com Thu May 8 22:07:40 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Thu, 8 May 2008 18:07:40 -0400 Subject: annoying spam In-Reply-To: <1210283980.482377cc7fe6a@ssl.mecca.ca> References: <1210283980.482377cc7fe6a@ssl.mecca.ca> Message-ID: On Thu, May 8, 2008 at 5:59 PM, Luya Tshimbalanga wrote: > Hello, > > I have received email from spammer pretending to come from Red Hat. I include > the message source so someone can check the origin. It would be nice if there > is a mail that address spam and phising issue. This came to your fedoraproject.org address, and was thus handled by Red Hat. No news here, move on :). You can use abuse@ pretty much any domain and it should reach a person. From dr.diesel at gmail.com Thu May 8 22:58:05 2008 From: dr.diesel at gmail.com (Dr. Diesel) Date: Thu, 8 May 2008 18:58:05 -0400 Subject: Anyone else with hard freezes? In-Reply-To: <1210116098.6222.11.camel@optimus> References: <2a28d2ab0805061455l9afae56p8a86218d08bc4b92@mail.gmail.com> <34809.75.164.221.130.1210112514.squirrel@clueserver.org> <2a28d2ab0805061526o55c58b80y5fceed9375555ffa@mail.gmail.com> <1210112921.6222.9.camel@optimus> <2a28d2ab0805061530j3a8aa79ehb51d96afedaad644@mail.gmail.com> <1210116098.6222.11.camel@optimus> Message-ID: <2a28d2ab0805081558q3fdb4b94hf41f40db0253f015@mail.gmail.com> Still happens without the vboxdrv kernel module.... On Tue, May 6, 2008 at 7:21 PM, Dave Airlie wrote: > On Tue, 2008-05-06 at 18:30 -0400, Dr. Diesel wrote: >> Just nv since Nvidia's drivers don't yet support xorg 1.5. The only >> kernel module I have loaded is VirtualBox 1.6's. >> >> Filing a bug now.. > > can you try without virtualbox? > > I've seen oops reports from it around the place. > > Dave. > >> >> On Tue, May 6, 2008 at 6:28 PM, Dave Airlie wrote: >> > On Tue, 2008-05-06 at 18:26 -0400, Dr. Diesel wrote: >> > > Abit 35 Pro , Intel E8400 etc. >> > > >> > > Attached is lscpi -vvv >> > >> > Oh wierd an nvidia card... are you running the binary driver? or just >> > the normal nv one? >> > >> > Dave. >> > >> > >> > >> > > >> > > >> > > >> > > On Tue, May 6, 2008 at 6:21 PM, Alan wrote: >> > > > > Currently running Fedora 9 Release to date. Doesn't happen very >> > > > > often, maybe once every 3-4 days. Twice I've caught it at idle with >> > > > > the screen saver (picture viewer) frozen and twice while browsing in >> > > > > Gnome. >> > > > > >> > > > > Not really noticing anything weird in the logs? >> > > > >> > > > I have had this happen with Fedora 8 on my x86_64 machine. Nothing >> > > > recorded in the logs. I have not had the time to debug it. >> > > > >> > > > What kind of motherboard, video card and processor? Maybe there is >> > > > something in common with my system. >> > > > >> > > > -- >> > > > fedora-devel-list mailing list >> > > > fedora-devel-list at redhat.com >> > > > https://www.redhat.com/mailman/listinfo/fedora-devel-list >> > > > >> > > >> > > >> > > >> > > -- >> > > fedora-devel-list mailing list >> > > fedora-devel-list at redhat.com >> > > https://www.redhat.com/mailman/listinfo/fedora-devel-list >> > >> > -- >> > fedora-devel-list mailing list >> > fedora-devel-list at redhat.com >> > https://www.redhat.com/mailman/listinfo/fedora-devel-list >> > >> >> >> >> -- >> projecthuh.com >> All of my bits are free, are yours? Fedoraproject.org >> > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org From jspaleta at gmail.com Thu May 8 23:03:37 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 8 May 2008 15:03:37 -0800 Subject: Maintainer Responsibility Policy In-Reply-To: <1210258504.25560.1107.camel@pmac.infradead.org> References: <1210035695.6297.25.camel@kennedy> <482056BE.90100@n-dimensional.de> <48206A93.7020807@gmail.com> <1210089261.2961.3.camel@kennedy> <4820836D.7070008@gmail.com> <1210154821.25560.865.camel@pmac.infradead.org> <604aa7910805071010u411b4bd0h4932981766d525ee@mail.gmail.com> <1210258504.25560.1107.camel@pmac.infradead.org> Message-ID: <604aa7910805081603h12dda806v18a3952a6c4f6944@mail.gmail.com> On Thu, May 8, 2008 at 6:55 AM, David Woodhouse wrote: > Yes, perhaps. Or maybe it would be better to have a code-monkey sign up > as co-maintainer for the package, where the primary maintainer isn't > capable of actually..., well, maintaining the package. Generally, I would agree that the maintainer needs to be able to diagnose breakage in the dominant language of the package in question. Hence why I don't touch mono or java packages. But, there are times when an application might provide mixed language or toolkit bindings which are harder to adequately account for based on accumulated personal experience. And we certainly can't expect everyone to have direct experience nor access to both big and little endian arches. And well, it'd be sort of nice to know how our contributor skillset breaks down, from a project resources point of view. -jef"Though in just a couple more years, we could probably expect everyone to have access to some sort of 64bit arch"spaleta From smooge at gmail.com Thu May 8 23:25:06 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 8 May 2008 17:25:06 -0600 Subject: Anyone else with hard freezes? In-Reply-To: <2a28d2ab0805081558q3fdb4b94hf41f40db0253f015@mail.gmail.com> References: <2a28d2ab0805061455l9afae56p8a86218d08bc4b92@mail.gmail.com> <34809.75.164.221.130.1210112514.squirrel@clueserver.org> <2a28d2ab0805061526o55c58b80y5fceed9375555ffa@mail.gmail.com> <1210112921.6222.9.camel@optimus> <2a28d2ab0805061530j3a8aa79ehb51d96afedaad644@mail.gmail.com> <1210116098.6222.11.camel@optimus> <2a28d2ab0805081558q3fdb4b94hf41f40db0253f015@mail.gmail.com> Message-ID: <80d7e4090805081625m111b7955v2c96d864275334b2@mail.gmail.com> On Thu, May 8, 2008 at 4:58 PM, Dr. Diesel wrote: > Still happens without the vboxdrv kernel module.... > was it a rmmod or a reboot of the system without the module? Sometimes loading a module will much with the kernel enough that removing it is not enough to make a problem not occur. You might also want to run sar at 1 minute intervals and see if something like 100% CPU usage etc is occuring? -- Stephen J Smoogen. -- How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From mark.bidewell at alumni.clemson.edu Fri May 9 00:03:01 2008 From: mark.bidewell at alumni.clemson.edu (Mark Bidewell) Date: Thu, 8 May 2008 20:03:01 -0400 Subject: F9 and KVM In-Reply-To: <48236F5C.3090507@verizon.net> References: <1210214432.5112.53.camel@localhost.localdomain> <48233A5E.5080006@verizon.net> <4c4ba1530805081103y3a1b7c63uf5dad9c735d39269@mail.gmail.com> <482343FD.1020609@gmail.com> <4c4ba1530805081123l2ab9ccdco577121583369a3ec@mail.gmail.com> <48234707.4000107@verizon.net> <48234808.60907@verizon.net> <1210272164.3807.20.camel@localhost.localdomain> <48235434.3010807@verizon.net> <48236F5C.3090507@verizon.net> Message-ID: > I'm still stuck with this guest networking problem. I have br0 defined > on the host with a static IP on the lan. I have eth0 on the host that > points to the bridge br0. When I created the vm I selected shared > network br0(eth0). In the guest I have ifcfg-eth0 that has: > BOOTPROTO=dhcp. > But when you do ifup eth0 it just sits there trying to determine IP and > eventually it pings 192.168.122.1 which to me looks like it thinks its > in a NAT environment rather than bridged networking. > > Regards, > Gerry > > > have you looked here? http://kvm.qumranet.com/kvmwiki/Networking Mark Bidewell From dr.diesel at gmail.com Fri May 9 00:23:27 2008 From: dr.diesel at gmail.com (Dr. Diesel) Date: Thu, 8 May 2008 20:23:27 -0400 Subject: Anyone else with hard freezes? In-Reply-To: <80d7e4090805081625m111b7955v2c96d864275334b2@mail.gmail.com> References: <2a28d2ab0805061455l9afae56p8a86218d08bc4b92@mail.gmail.com> <34809.75.164.221.130.1210112514.squirrel@clueserver.org> <2a28d2ab0805061526o55c58b80y5fceed9375555ffa@mail.gmail.com> <1210112921.6222.9.camel@optimus> <2a28d2ab0805061530j3a8aa79ehb51d96afedaad644@mail.gmail.com> <1210116098.6222.11.camel@optimus> <2a28d2ab0805081558q3fdb4b94hf41f40db0253f015@mail.gmail.com> <80d7e4090805081625m111b7955v2c96d864275334b2@mail.gmail.com> Message-ID: <2a28d2ab0805081723q6a3537d7n93db59501cf23b16@mail.gmail.com> On Thu, May 8, 2008 at 7:25 PM, Stephen John Smoogen wrote: > On Thu, May 8, 2008 at 4:58 PM, Dr. Diesel wrote: >> Still happens without the vboxdrv kernel module.... >> > > was it a rmmod or a reboot of the system without the module? Sometimes > loading a module will much with the kernel enough that removing it is > not enough to make a problem not occur. You might also want to run sar > at 1 minute intervals and see if something like 100% CPU usage etc is > occuring? > Ok, vboxdrv now disabled at boot, not just rmmod. I don't think it was a 100% CPU issue, I was not able to loggin via SSH either. The number lock and caps lock keys were also non-responsive also. -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org From greno at verizon.net Fri May 9 03:05:29 2008 From: greno at verizon.net (Gerry Reno) Date: Thu, 08 May 2008 23:05:29 -0400 Subject: F9 and KVM In-Reply-To: References: <1210214432.5112.53.camel@localhost.localdomain> <48233A5E.5080006@verizon.net> <4c4ba1530805081103y3a1b7c63uf5dad9c735d39269@mail.gmail.com> <482343FD.1020609@gmail.com> <4c4ba1530805081123l2ab9ccdco577121583369a3ec@mail.gmail.com> <48234707.4000107@verizon.net> <48234808.60907@verizon.net> <1210272164.3807.20.camel@localhost.localdomain> <48235434.3010807@verizon.net> <48236F5C.3090507@verizon.net> Message-ID: <4823BF79.8040208@verizon.net> Mark Bidewell wrote: >> I'm still stuck with this guest networking problem. I have br0 defined >> on the host with a static IP on the lan. I have eth0 on the host that >> points to the bridge br0. When I created the vm I selected shared >> network br0(eth0). In the guest I have ifcfg-eth0 that has: >> BOOTPROTO=dhcp. >> But when you do ifup eth0 it just sits there trying to determine IP and >> eventually it pings 192.168.122.1 which to me looks like it thinks its >> in a NAT environment rather than bridged networking. >> >> Regards, >> Gerry >> >> >> >> > > > have you looked here? > > http://kvm.qumranet.com/kvmwiki/Networking > > Mark Bidewell > > Yes, but that is for doing everything from the command line. I was expecting that virt-manager was setting all that up. I mean I see vnet0 and vnet1 for my VM's on the host. This has all been created by virt-manager and virsh define. I didn't set any of that up manually except for setting up the host bridge br0. So how much of this networking setup is virt-manager actually doing if not all of it? The picture with virt-manager and networking is not exactly clear. Regards, Gerry -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattdm at mattdm.org Fri May 9 03:23:48 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 8 May 2008 23:23:48 -0400 Subject: Flash on rawhide In-Reply-To: <48235B02.7050804@gmail.com> References: <1210086745.2716.6.camel@scrappy.miketc.com> <20080506152222.GA21258@nostromo.devel.redhat.com> <1210087782.2716.8.camel@scrappy.miketc.com> <20080508150650.GA18366@jadzia.bu.edu> <48235B02.7050804@gmail.com> Message-ID: <20080509032348.GA13836@jadzia.bu.edu> On Thu, May 08, 2008 at 03:56:50PM -0400, David Boles wrote: >> So, didn't work for me. I had both the x86_64 and i386 versions installed; >> no sound. I removed them both, and the flash plugin itself, and reinstalled >> just the flash plugin and libflashsupport.i386, and still no sound. Hmmm. > Probably OT for this list but: > http://docs.fedoraproject.org/release-notes/f8/en_US/sn-Desktop.html#sn-KDE-Desktop > Read the section titled: 10.3.1. Enabling Flash Plugin Thanks, but, yeah, I'd done all that. I've got another x86_64 rawhide machine where it all works fine -- I'm not really sure what the difference is or really where to begin looking. Oh, and also: after I did the above remove-and-reinstall, youtube movies seem to play at about 10x speed (still with no sound). Even after I also re-added 64-bit libflashsupport out of superstition. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Fri May 9 03:46:34 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 8 May 2008 23:46:34 -0400 Subject: Flash on rawhide In-Reply-To: <20080509032348.GA13836@jadzia.bu.edu> References: <1210086745.2716.6.camel@scrappy.miketc.com> <20080506152222.GA21258@nostromo.devel.redhat.com> <1210087782.2716.8.camel@scrappy.miketc.com> <20080508150650.GA18366@jadzia.bu.edu> <48235B02.7050804@gmail.com> <20080509032348.GA13836@jadzia.bu.edu> Message-ID: <20080509034634.GA15035@jadzia.bu.edu> On Thu, May 08, 2008 at 11:23:48PM -0400, Matthew Miller wrote: > I've got another x86_64 rawhide machine where it all works fine -- I'm not > really sure what the difference is or really where to begin looking. > > Oh, and also: after I did the above remove-and-reinstall, youtube movies > seem to play at about 10x speed (still with no sound). Even after I also > re-added 64-bit libflashsupport out of superstition. I thought I'd figured it out when I found that swfdec-mozilla had gotten installed too, but no, removing that didn't fix anything. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From wtogami at redhat.com Fri May 9 04:06:21 2008 From: wtogami at redhat.com (Warren Togami) Date: Fri, 09 May 2008 00:06:21 -0400 Subject: F9 and KVM In-Reply-To: <4823BF79.8040208@verizon.net> References: <1210214432.5112.53.camel@localhost.localdomain> <48233A5E.5080006@verizon.net> <4c4ba1530805081103y3a1b7c63uf5dad9c735d39269@mail.gmail.com> <482343FD.1020609@gmail.com> <4c4ba1530805081123l2ab9ccdco577121583369a3ec@mail.gmail.com> <48234707.4000107@verizon.net> <48234808.60907@verizon.net> <1210272164.3807.20.camel@localhost.localdomain> <48235434.3010807@verizon.net> <48236F5C.3090507@verizon.net> <4823BF79.8040208@verizon.net> Message-ID: <4823CDBD.3070103@redhat.com> Gerry Reno wrote: > Yes, but that is for doing everything from the command line. I was > expecting that virt-manager was setting all that up. I mean I see vnet0 > and vnet1 for my VM's on the host. This has all been created by > virt-manager and virsh define. I didn't set any of that up manually > except for setting up the host bridge br0. So how much of this > networking setup is virt-manager actually doing if not all of it? The > picture with virt-manager and networking is not exactly clear. > > > Regards, > Gerry > libvirt is supposed to come with virbr0 automatically configured, and anything started by libvirt will auto-add itself to the virbr0 bridge. This works out of the box. You must have configured it in some non-default way. Warren From luya_tfz at thefinalzone.com Fri May 9 05:28:33 2008 From: luya_tfz at thefinalzone.com (Luya Tshimbalanga) Date: Fri, 9 May 2008 01:28:33 -0400 Subject: annoying spam In-Reply-To: References: <1210283980.482377cc7fe6a@ssl.mecca.ca> Message-ID: <1210310913.4823e10161b1d@ssl.mecca.ca> Quoting Jon Stanley : > This came to your fedoraproject.org address, and was thus handled by > Red Hat. No news here, move on :). You can use abuse@ pretty much > any domain and it should reach a person. Good to know. Thanks -- Luya Tshimbalanga Fedora Project contributor http://www.fedoraproject.org/wiki/LuyaTshimbalanga Written from XO laptop From rc040203 at freenet.de Fri May 9 06:13:03 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 09 May 2008 08:13:03 +0200 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <20080508205414.GC21251@wolff.to> References: <1209999548.32107.11.camel@kennedy> <481FD3D5.5070206@ncsu.edu> <48207309.3040403@redhat.com> <200805061308.24635.sgrubb@redhat.com> <4820A376.70104@redhat.com> <1210222648.4287.1.camel@localhost> <482358D8.5050701@redhat.com> <20080508205414.GC21251@wolff.to> Message-ID: <1210313583.26792.777.camel@beck.corsepiu.local> On Thu, 2008-05-08 at 15:54 -0500, Bruno Wolff III wrote: > On Thu, May 08, 2008 at 15:47:36 -0400, > Christopher Aillon wrote: > > > > I really don't think upstream has any real objections to moving to a more > > modern system, be it new autotools, or a different system altogether > > PROVIDED THEIR REQUIREMENTS ARE MET. The big requirement that nobody has > > solved yet is "must work in every case and on every platform it does now". >From what I say from a "short and hasty glance" into mozilla's configure.in is them exploiting autoconf-2.13 internals, incorrectly using certain some autoconf details and having overloaded it with details which do not belong into configure script. I.e. the first step to do would be to clean up their configure script and remove the historic ballast. > > I don't know whether cmake is as portable as gmake is, but you're free to > > discuss that with them. It isn't. It essentially is imake in new clothes and suffers from the same fundamental backdraws. cmake is nice for simple stuff and when Windows<->Linux support is important, but that's it. For more complex stuff things very easily grow nasty. > One project that is trying to change away from autotools is Wesnoth. They > are in the process of implementing scons and cmake build systems and will > later choose between them for going forward. Currently scons is pretty > complete. The cmake implementation was doing some stuff, but there were still > some important missing pieces. Matches with my experience. In particular, for my work, cross-compilation is essential and there neither cmake nor scons are competitive > So in another month or two, you might be able to get an informed opinion > from those guys. And people do build Wesnoth on Windows so there is some > signifcant cross platform testing. Native Windows support is one domain, the autotools have deficiencies, but supporting MinGW, Cygwin and MacOS support comes along as almost "no-cost" side-effect in many cases. scons is a whole set of problems on its own. Their number one problem is it being a script-based buildsystem and not a make-based system, which makes it hardly comparable to the autotools, cmake etc. Ralf From dwmw2 at infradead.org Fri May 9 06:59:45 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 09 May 2008 07:59:45 +0100 Subject: annoying spam In-Reply-To: References: <1210283980.482377cc7fe6a@ssl.mecca.ca> Message-ID: <1210316385.25560.1169.camel@pmac.infradead.org> On Thu, 2008-05-08 at 18:07 -0400, Jon Stanley wrote: > On Thu, May 8, 2008 at 5:59 PM, Luya Tshimbalanga > wrote: > > Hello, > > > > I have received email from spammer pretending to come from Red Hat. I include > > the message source so someone can check the origin. It would be nice if there > > is a mail that address spam and phising issue. > > This came to your fedoraproject.org address, and was thus handled by > Red Hat. No news here, move on :). You can use abuse@ pretty much > any domain and it should reach a person. I don't think the spammer was pretending to come from Red Hat. I'm fairly sure that '@redhat.com' you see in the From: address was added by Red Hat's machines -- the original just said 'From: Top.SEO.Secrets'. The Red Hat machines probably should have rejected the RFC2822-invalid mail, but instead they accepted it and even qualified the address 'Top.SEO.Secrets', rewriting it to appear 'Top.SEO.Secrets at redhat.com'. And then sent it on to you, since it was sent to your @fedoraproject.org address. -- dwmw2 From martin.sourada at gmail.com Fri May 9 07:53:48 2008 From: martin.sourada at gmail.com (Martin Sourada) Date: Fri, 09 May 2008 09:53:48 +0200 Subject: annoying spam In-Reply-To: <1210283980.482377cc7fe6a@ssl.mecca.ca> References: <1210283980.482377cc7fe6a@ssl.mecca.ca> Message-ID: <1210319628.3282.28.camel@pc-notebook> On Thu, 2008-05-08 at 17:59 -0400, Luya Tshimbalanga wrote: > Hello, > > I have received email from spammer pretending to come from Red Hat. I include > the message source so someone can check the origin. It would be nice if there > is a mail that address spam and phising issue. > > -- > Luya Tshimbalanga > Fedora Project contributor > BTW. I've got this mail too and evolution shows only Top SEO Secrets in the Form field. I think it's because it didn't come through redhat, because I received it on my gmail account (and into the Spam folder). The message header is totally crap, I wonder how came that redhat mailers resend it to you... Martin Message header: Delivered-To: martin.sourada at gmail.com Received: by 10.141.146.9 with SMTP id y9cs30569rvn; Thu, 8 May 2008 12:15:40 -0700 (PDT) Received: by 10.114.103.1 with SMTP id a1mr3424005wac.190.1210274140503; Thu, 08 May 2008 12:15:40 -0700 (PDT) Return-Path: Received: from gmail.com ([125.211.197.209]) by mx.google.com with ESMTP id j21si8034447wah.6.2008.05.08.12.15.36; Thu, 08 May 2008 12:15:40 -0700 (PDT) Received-SPF: neutral (google.com: 125.211.197.209 is neither permitted nor denied by domain of seosecrets2 at gmail.com) client-ip=125.211.197.209; Authentication-Results: mx.google.com; spf=neutral (google.com: 125.211.197.209 is neither permitted nor denied by domain of seosecrets2 at gmail.com) smtp.mail=seosecrets2 at gmail.com Reply-To: seosecrets2 at gmail.com To: martin.sourada at gmail.com Subject: 1000s Of Hits From Google, Yahoo, MSN And Others At $0 Cost To You ! Date: 09 May 2008 03:15:35 +0800 Message-ID: <20080509031535.EBACFD50FABCF620 at from.header.has.no.domain> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0012_B37D026D.8238B6D5" X-Evolution-Source: imap://martin.sourada% 40gmail.com at imap.gmail.com:993/ From: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From rc040203 at freenet.de Fri May 9 08:32:12 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 09 May 2008 10:32:12 +0200 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <48207309.3040403@redhat.com> References: <1209999548.32107.11.camel@kennedy> <481F2986.8010509@redhat.com> <1210002669.26792.65.camel@beck.corsepiu.local> <481FD064.6050307@ncsu.edu> <1210045081.4658.7.camel@localhost.localdomain> <481FD3D5.5070206@ncsu.edu> <48207309.3040403@redhat.com> Message-ID: <1210321932.26792.817.camel@beck.corsepiu.local> On Tue, 2008-05-06 at 11:02 -0400, Christopher Aillon wrote: > On 05/05/2008 11:43 PM, Casey Dahlin wrote: > > Matthias Clasen wrote: > >> On Mon, 2008-05-05 at 23:28 -0400, Casey Dahlin wrote: > If you'd have read the thread, you'd have noticed I already pointed out > multiple times, if you want to keep Firefox in the distro, you need to > keep autoconf213 for the forseeable future. Not at all. The firefox project should ship their infrastructure, such that developers can install it into their development environments. Many other major projects do so (e.g. GCC) - It would also help upstream firefox to avoid divergences being caused by vendors shipping modified version of the autotools. Ralf From surenkarapetyan at gmail.com Fri May 9 08:53:27 2008 From: surenkarapetyan at gmail.com (Suren Karapetyan) Date: Fri, 09 May 2008 13:53:27 +0500 Subject: F9 and KVM In-Reply-To: <48236F5C.3090507@verizon.net> References: <1210214432.5112.53.camel@localhost.localdomain> <48227A43.6010409@verizon.net> <48229C3B.9080209@verizon.net> <20080508112444.GA29692@amd.home.annexia.org> <4823128A.3030003@verizon.net> <20080508155150.GA32379@amd.home.annexia.org> <48232D5E.1030800@verizon.net> <48233A5E.5080006@verizon.net> <4c4ba1530805081103y3a1b7c63uf5dad9c735d39269@mail.gmail.com> <482343FD.1020609@gmail.com> <4c4ba1530805081123l2ab9ccdco577121583369a3ec@mail.gmail.com> <48234707.4000107@verizon.net> <48234808.60907@verizon.net> <1210272164.3807.20.camel@localhost.localdomain> <48235434.3010807@verizon.net> <48236F5C.3090507@verizon.net> Message-ID: <48241107.5070406@gmail.com> Gerry Reno wrote: > Gerry Reno wrote: >> Now, how can I set the correct context for where I need to store my >> images? I have several vm image directories on different filesystems >> so that the vm's are not competing for the same drive all the time. >> Is just doing a 'chcon -t virt_image_t ./imagedir' enough to set the >> context of the images directories? > Yes, this works. I just did this to my old vmdk file and directory and > now it runs. > >> >> Also, one last problem is that neither network service nor >> NetworkManager seem to be able to get a dhcp connection to the lan in >> the guest. I selected shared network using br0(eth0) during image >> creation but all I get in the guest is network unreachable. Is there >> some trick you need to do in the guest? > I'm still stuck with this guest networking problem. I have br0 defined > on the host with a static IP on the lan. I have eth0 on the host that > points to the bridge br0. When I created the vm I selected shared > network br0(eth0). In the guest I have ifcfg-eth0 that has: > BOOTPROTO=dhcp. > But when you do ifup eth0 it just sits there trying to determine IP and > eventually it pings 192.168.122.1 which to me looks like it thinks its > in a NAT environment rather than bridged networking. > > Regards, > Gerry > > It would help if You did "ifconfig" and "brctl show" on the host PC while guest is running and posted it here. That way we could find out what's happening. BTW: Is eth0 on host configured via DHCPD or static? From karsten at redhat.com Fri May 9 09:24:26 2008 From: karsten at redhat.com (Karsten Hopp) Date: Fri, 09 May 2008 11:24:26 +0200 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <1210321932.26792.817.camel@beck.corsepiu.local> References: <1209999548.32107.11.camel@kennedy> <481F2986.8010509@redhat.com> <1210002669.26792.65.camel@beck.corsepiu.local> <481FD064.6050307@ncsu.edu> <1210045081.4658.7.camel@localhost.localdomain> <481FD3D5.5070206@ncsu.edu> <48207309.3040403@redhat.com> <1210321932.26792.817.camel@beck.corsepiu.local> Message-ID: <4824184A.1010508@redhat.com> Ralf Corsepius schrieb: > On Tue, 2008-05-06 at 11:02 -0400, Christopher Aillon wrote: >> On 05/05/2008 11:43 PM, Casey Dahlin wrote: >>> Matthias Clasen wrote: >>>> On Mon, 2008-05-05 at 23:28 -0400, Casey Dahlin wrote: > >> If you'd have read the thread, you'd have noticed I already pointed out >> multiple times, if you want to keep Firefox in the distro, you need to >> keep autoconf213 for the forseeable future. > Not at all. The firefox project should ship their infrastructure, such > that developers can install it into their development environments. > They do. Our Firefox rpm rebuilds just fine without autoconf213. The autoconf213 package is required to build the necessary files when the tarballs are created. FYI: I've canceled my request to block the older autofoo packages as the discussion here showed that we just can't do that. I'd like to see a reviewer guideline instead that new packages should be checked if they really need to run autofoo during the build and if they really require to be built with ancient autofoo. Karsten From aph at redhat.com Fri May 9 09:27:05 2008 From: aph at redhat.com (Andrew Haley) Date: Fri, 09 May 2008 10:27:05 +0100 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <4824184A.1010508@redhat.com> References: <1209999548.32107.11.camel@kennedy> <481F2986.8010509@redhat.com> <1210002669.26792.65.camel@beck.corsepiu.local> <481FD064.6050307@ncsu.edu> <1210045081.4658.7.camel@localhost.localdomain> <481FD3D5.5070206@ncsu.edu> <48207309.3040403@redhat.com> <1210321932.26792.817.camel@beck.corsepiu.local> <4824184A.1010508@redhat.com> Message-ID: <482418E9.7030800@redhat.com> Karsten Hopp wrote: > FYI: I've canceled my request to block the older autofoo packages as the > discussion here showed that we just can't do that. Excellent. This long thread wasn't a total waste of time, then. Andrew. From bojan at rexursive.com Fri May 9 10:31:49 2008 From: bojan at rexursive.com (Bojan Smojver) Date: Fri, 09 May 2008 20:31:49 +1000 Subject: Kernel updates? Message-ID: <1210329109.10161.5.camel@shrek.rexursive.com> Any chance of pushing the F-8 kernel with that security fix (CVE-2008-1669) into stable? -- Bojan From dr.diesel at gmail.com Fri May 9 10:36:04 2008 From: dr.diesel at gmail.com (Dr. Diesel) Date: Fri, 9 May 2008 05:36:04 -0500 Subject: Anyone else with hard freezes? In-Reply-To: <2a28d2ab0805081723q6a3537d7n93db59501cf23b16@mail.gmail.com> References: <2a28d2ab0805061455l9afae56p8a86218d08bc4b92@mail.gmail.com> <34809.75.164.221.130.1210112514.squirrel@clueserver.org> <2a28d2ab0805061526o55c58b80y5fceed9375555ffa@mail.gmail.com> <1210112921.6222.9.camel@optimus> <2a28d2ab0805061530j3a8aa79ehb51d96afedaad644@mail.gmail.com> <1210116098.6222.11.camel@optimus> <2a28d2ab0805081558q3fdb4b94hf41f40db0253f015@mail.gmail.com> <80d7e4090805081625m111b7955v2c96d864275334b2@mail.gmail.com> <2a28d2ab0805081723q6a3537d7n93db59501cf23b16@mail.gmail.com> Message-ID: <2a28d2ab0805090336j78fe2772q1df6283e3c5d38cf@mail.gmail.com> Ok, that wasn't it either! Log files don't seem to be showing me anything! Here is messages about that time: May 8 21:13:06 localhost dhclient: bound to 192.168.2.37 -- renewal in 1670 seconds. May 8 21:40:56 localhost dhclient: DHCPREQUEST on eth1 to 192.168.2.10 port 67 May 8 21:40:56 localhost dhclient: DHCPACK from 192.168.2.10 May 8 21:40:56 localhost dhclient: bound to 192.168.2.37 -- renewal in 1577 seconds. May 8 22:07:13 localhost dhclient: DHCPREQUEST on eth1 to 192.168.2.10 port 67 May 8 22:07:13 localhost dhclient: DHCPACK from 192.168.2.10 May 8 22:07:13 localhost dhclient: bound to 192.168.2.37 -- renewal in 1684 seconds. May 8 22:35:17 localhost dhclient: DHCPREQUEST on eth1 to 192.168.2.10 port 67 May 8 22:35:17 localhost dhclient: DHCPACK from 192.168.2.10 May 8 22:35:17 localhost dhclient: bound to 192.168.2.37 -- renewal in 1547 seconds. May 8 23:01:04 localhost dhclient: DHCPREQUEST on eth1 to 192.168.2.10 port 67 May 8 23:01:04 localhost dhclient: DHCPACK from 192.168.2.10 May 8 23:01:04 localhost dhclient: bound to 192.168.2.37 -- renewal in 1541 seconds. May 8 23:08:28 localhost ntpd[1889]: synchronized to 209.193.103.214, stratum 2 May 8 23:26:45 localhost dhclient: DHCPREQUEST on eth1 to 192.168.2.10 port 67 May 8 23:26:45 localhost dhclient: DHCPACK from 192.168.2.10 May 8 23:26:45 localhost dhclient: bound to 192.168.2.37 -- renewal in 1398 seconds. May 9 06:26:29 localhost kernel: imklog 3.14.1, log source = /proc/kmsg started. On Thu, May 8, 2008 at 7:23 PM, Dr. Diesel wrote: > On Thu, May 8, 2008 at 7:25 PM, Stephen John Smoogen wrote: > > On Thu, May 8, 2008 at 4:58 PM, Dr. Diesel wrote: > >> Still happens without the vboxdrv kernel module.... > >> > > > > was it a rmmod or a reboot of the system without the module? Sometimes > > loading a module will much with the kernel enough that removing it is > > not enough to make a problem not occur. You might also want to run sar > > at 1 minute intervals and see if something like 100% CPU usage etc is > > occuring? > > > > Ok, vboxdrv now disabled at boot, not just rmmod. > > I don't think it was a 100% CPU issue, I was not able to loggin via > SSH either. The number lock and caps lock keys were also > non-responsive also. > > > > > -- > > > projecthuh.com > All of my bits are free, are yours? Fedoraproject.org > -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org From rawhide at fedoraproject.org Fri May 9 10:37:30 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Fri, 9 May 2008 10:37:30 +0000 (UTC) Subject: rawhide report: 20080509 changes Message-ID: <20080509103730.2D0B1209D12@releng1.fedora.phx.redhat.com> Updated Packages: (none) Broken deps for ppc64 ---------------------------------------------------------- livecd-tools-017-1.fc9.ppc64 requires yaboot perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot From mackay_d at bellsouth.net Fri May 9 12:11:08 2008 From: mackay_d at bellsouth.net (David G. Mackay) Date: Fri, 09 May 2008 07:11:08 -0500 Subject: F9 and KVM In-Reply-To: <4823CDBD.3070103@redhat.com> References: <1210214432.5112.53.camel@localhost.localdomain> <48233A5E.5080006@verizon.net> <4c4ba1530805081103y3a1b7c63uf5dad9c735d39269@mail.gmail.com> <482343FD.1020609@gmail.com> <4c4ba1530805081123l2ab9ccdco577121583369a3ec@mail.gmail.com> <48234707.4000107@verizon.net> <48234808.60907@verizon.net> <1210272164.3807.20.camel@localhost.localdomain> <48235434.3010807@verizon.net> <48236F5C.3090507@verizon.net> <4823BF79.8040208@verizon.net> <4823CDBD.3070103@redhat.com> Message-ID: <1210335068.15178.130.camel@vorpal.macdev.com> On Fri, 2008-05-09 at 00:06 -0400, Warren Togami wrote: > Gerry Reno wrote: > > Yes, but that is for doing everything from the command line. I was > > expecting that virt-manager was setting all that up. I mean I see vnet0 > > and vnet1 for my VM's on the host. This has all been created by > > virt-manager and virsh define. I didn't set any of that up manually > > except for setting up the host bridge br0. So how much of this > > networking setup is virt-manager actually doing if not all of it? The > > picture with virt-manager and networking is not exactly clear. > > > > > > Regards, > > Gerry > > > > libvirt is supposed to come with virbr0 automatically configured, and > anything started by libvirt will auto-add itself to the virbr0 bridge. > This works out of the box. You must have configured it in some > non-default way. There was another thread on this list recently about bridging not being handled yet by NetworkManager. You might want to check that in this context. Dave From ndbecker2 at gmail.com Fri May 9 13:35:11 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 09 May 2008 09:35:11 -0400 Subject: python packaging, paver Message-ID: This 'paver' sounds interesting. Anyone looked at this? http://www.blueskyonmars.com/projects/paver/getting_started.html#gettingstarted From caolanm at redhat.com Fri May 9 13:56:12 2008 From: caolanm at redhat.com (Caolan McNamara) Date: Fri, 09 May 2008 14:56:12 +0100 Subject: what's the brief grand-plan for java ? Message-ID: <1210341372.7436.276.camel@vain.rhgalway> What's the three liner for java openjdk/icedtea/libgcj in the fedora future ? is it... Port icedtea to all platforms that libgcj supports, move to icedtea as default when stable and drop ahead-of-time-gcj-compiling ? Or is it planned to always aot compile stuff by default and continue to support using gij as java ? C. From bpepple at fedoraproject.org Fri May 9 13:59:49 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Fri, 09 May 2008 09:59:49 -0400 Subject: FESCo Meeting Summary for 2008-05-08 Message-ID: <1210341589.26087.4.camel@kennedy> == Members Present == * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Bill Nottingham (notting) * Kevin Fenzi (nirik) * Jeremy Katz (jeremy) * Christopher Aillon (caillon) * Dennis Gilmore (dgilmore) * Warren Togami (warren) * Christian Iseli (c4chris) * David Woodhouse (dwmw2) * Jesse Keating (f13) * Josh Boyer (jwb) == Absent == * Tom Callaway (spot) == Summary == === New Package Maintainer Sponsor === * FESCo approved the following sponsor requests: * Denis Leroy (denis) * Jef Spaleta (spoleeba) * Matthias Clasen (mclasen) * Any Fedora packager that wishes to become a sponsor, can contact the FESCo chair or go directly to: http://fedoraproject.org/wiki/Extras/Schedule/NewSponsors === Maintainer Responsibility Policy === * FESCo approved the Maintainer Responsibility Policy. http://fedoraproject.org/wiki/Development/Schedule/MaintainerResponsibilityPolicy IRC log can be found at: http://bpepple.fedorapeople.org/fesco/FESCo-2008-05-08.html Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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: 197 bytes Desc: This is a digitally signed message part URL: From aph at redhat.com Fri May 9 14:03:18 2008 From: aph at redhat.com (Andrew Haley) Date: Fri, 09 May 2008 15:03:18 +0100 Subject: what's the brief grand-plan for java ? In-Reply-To: <1210341372.7436.276.camel@vain.rhgalway> References: <1210341372.7436.276.camel@vain.rhgalway> Message-ID: <482459A6.7060109@redhat.com> Caolan McNamara wrote: > What's the three liner for java openjdk/icedtea/libgcj in the fedora > future ? is it... > > Port icedtea to all platforms that libgcj supports, move to icedtea as > default when stable and drop ahead-of-time-gcj-compiling ? Eventually, yes. The most interesting option is to use LLVM to jit-compile; see http://gbenson.net/ for the current status. > Or is it planned to always aot compile stuff by default and continue to > support using gij as java ? It all depends on how well the LLVM-based jit works. For example, gcj is currently between 1.6 and 10 times faster than Sun's C++ interpreter on ARM systems, so it's worth keeping gcj alive there until we get something better. Only desktop systems fully- supported by a custom JIT, there is little need for gcj. Andrew. From fedora at matbooth.co.uk Fri May 9 14:03:21 2008 From: fedora at matbooth.co.uk (Mat Booth) Date: Fri, 9 May 2008 15:03:21 +0100 Subject: what's the brief grand-plan for java ? In-Reply-To: <1210341372.7436.276.camel@vain.rhgalway> References: <1210341372.7436.276.camel@vain.rhgalway> Message-ID: <9497e9990805090703s342da405k842436477204c548@mail.gmail.com> On Fri, May 9, 2008 at 2:56 PM, Caolan McNamara wrote: > What's the three liner for java openjdk/icedtea/libgcj in the fedora > future ? is it... > > Port icedtea to all platforms that libgcj supports, move to icedtea as > default when stable and drop ahead-of-time-gcj-compiling ? > > Or is it planned to always aot compile stuff by default and continue to > support using gij as java ? > > C. > Or secret option number three: Getting openjdk to support compiling aot before dropping support for gij? -- Mat Booth www.matbooth.co.uk From aph at redhat.com Fri May 9 14:05:52 2008 From: aph at redhat.com (Andrew Haley) Date: Fri, 09 May 2008 15:05:52 +0100 Subject: what's the brief grand-plan for java ? In-Reply-To: <9497e9990805090703s342da405k842436477204c548@mail.gmail.com> References: <1210341372.7436.276.camel@vain.rhgalway> <9497e9990805090703s342da405k842436477204c548@mail.gmail.com> Message-ID: <48245A40.4020505@redhat.com> Mat Booth wrote: > On Fri, May 9, 2008 at 2:56 PM, Caolan McNamara wrote: >> What's the three liner for java openjdk/icedtea/libgcj in the fedora >> future ? is it... >> >> Port icedtea to all platforms that libgcj supports, move to icedtea as >> default when stable and drop ahead-of-time-gcj-compiling ? >> >> Or is it planned to always aot compile stuff by default and continue to >> support using gij as java ? > > Or secret option number three: Getting openjdk to support compiling > aot before dropping support for gij? That's right. On some systems the advantage of precompilation could be considerable. At the moment, though, LLVM looks more promising. Andrew. From silfreed at silfreed.net Fri May 9 14:39:33 2008 From: silfreed at silfreed.net (Douglas E. Warner) Date: Fri, 9 May 2008 10:39:33 -0400 Subject: Evil download URL Message-ID: <200805091039.33613.silfreed@silfreed.net> I'm working on updating gpsbabel to the new version but upstream has removed all direct download links to the source. Through watching HTTP headers I was able to find the a download URL like this: http://www.gpsbabel.org/plan9.php?dl=gpsbabel-1.3.5.tar.gz This makes rpmbuild unhappy if I include it as the Source0 since it thinks the file is "plan9.php?dl=gpsbabel-1.3.5.tar.gz", and moreover I'm subverting upstream's distribution system by using this (and it could easily be changed again). What are people's recommendations for dealing with this? I've asked the dev if there is a direct download link but they said that there wasn't; they wanted to present the "project" rather than "a pile of bits". Should I just put a comment in the docs as to where the source can be downloaded and point at the local source? -Doug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From tcallawa at redhat.com Fri May 9 14:43:09 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 09 May 2008 10:43:09 -0400 Subject: Evil download URL In-Reply-To: <200805091039.33613.silfreed@silfreed.net> References: <200805091039.33613.silfreed@silfreed.net> Message-ID: <1210344189.4894.22.camel@localhost.localdomain> On Fri, 2008-05-09 at 10:39 -0400, Douglas E. Warner wrote: > Should I just put a comment in the docs as to where the source can be > downloaded and point at the local source? If by "comment in the docs" you mean "comment in the spec file", then yes. :) ~spot From tibbs at math.uh.edu Fri May 9 14:57:27 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 09 May 2008 09:57:27 -0500 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <4824184A.1010508@redhat.com> References: <1209999548.32107.11.camel@kennedy> <481F2986.8010509@redhat.com> <1210002669.26792.65.camel@beck.corsepiu.local> <481FD064.6050307@ncsu.edu> <1210045081.4658.7.camel@localhost.localdomain> <481FD3D5.5070206@ncsu.edu> <48207309.3040403@redhat.com> <1210321932.26792.817.camel@beck.corsepiu.local> <4824184A.1010508@redhat.com> Message-ID: >>>>> "KH" == Karsten Hopp writes: KH> I'd like to see a reviewer guideline instead that new packages KH> should be checked if they really need to run autofoo during the KH> build and if they really require to be built with ancient autofoo. Could you write a draft for consideration by the packaging committee? List it in http://fedoraproject.org/wiki/PackagingDrafts/DraftsTodo and the committee will take a look. Please be sure that the draft provides sufficient information on how reviewers can detect and how packagers can avoid the behavior you would like to discourage. - J< From silfreed at silfreed.net Fri May 9 15:11:32 2008 From: silfreed at silfreed.net (Douglas E. Warner) Date: Fri, 9 May 2008 11:11:32 -0400 Subject: Evil download URL In-Reply-To: <1210344189.4894.22.camel@localhost.localdomain> References: <200805091039.33613.silfreed@silfreed.net> <1210344189.4894.22.camel@localhost.localdomain> Message-ID: <200805091111.33048.silfreed@silfreed.net> On Friday 09 May 2008 10:43:09 Tom "spot" Callaway wrote: > If by "comment in the docs" you mean "comment in the spec file", then > yes. :) Yes, that's what I meant. -Doug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From greno at verizon.net Fri May 9 15:16:21 2008 From: greno at verizon.net (Gerry Reno) Date: Fri, 09 May 2008 11:16:21 -0400 Subject: F9 and KVM In-Reply-To: <48241107.5070406@gmail.com> References: <1210214432.5112.53.camel@localhost.localdomain> <48227A43.6010409@verizon.net> <48229C3B.9080209@verizon.net> <20080508112444.GA29692@amd.home.annexia.org> <4823128A.3030003@verizon.net> <20080508155150.GA32379@amd.home.annexia.org> <48232D5E.1030800@verizon.net> <48233A5E.5080006@verizon.net> <4c4ba1530805081103y3a1b7c63uf5dad9c735d39269@mail.gmail.com> <482343FD.1020609@gmail.com> <4c4ba1530805081123l2ab9ccdco577121583369a3ec@mail.gmail.com> <48234707.4000107@verizon.net> <48234808.60907@verizon.net> <1210272164.3807.20.camel@localhost.localdomain> <48235434.3010807@verizon.net> <48236F5C.3090507@verizon.net> <48241107.5070406@gmail.com> Message-ID: <48246AC5.9030506@verizon.net> Suren Karapetyan wrote: > It would help if You did "ifconfig" and "brctl show" on the host PC > while guest is running and posted it here. That way we could find out > what's happening. > > BTW: Is eth0 on host configured via DHCPD or static? > I made some small progress. I had an existing bridge br0 and virt-manager created a second bridge virbr0. vnet0 and vnet1 became attached to my br0 bridge and not virbr0. Now I don't see why that should be a problem but apparently it is. So I destroyed my bridge. Changed the vm defines to reflect virbr0 and restarted everything. So now in the guest I can ping 192.168.122.1 which is the virbr0. But that's all I cannot get access to the lan. When I originally had setup the images via virt-manager gui I selected shared networking and it was showing br0(eth0) which was my original bridge. I was expecting it would slave to this and then I would have a bridge to my lan address space. But this did not work and I had access to nothing. So how can I define a bridge on my lan and have the guests slave to it so that they can get either a lan dhcp address or a static lan address? Here are the current conditions: eth0 Link encap:Ethernet HWaddr 00:1A:4D:5E:F6:36 inet addr:192.168.1.15 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::21a:4dff:fe5e:f636/64 Scope:Link UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:27833013 errors:0 dropped:0 overruns:0 frame:0 TX packets:36339801 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:3841204956 (3.5 GiB) TX bytes:1079379274 (1.0 GiB) Interrupt:19 Base address:0xc000 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:142210 errors:0 dropped:0 overruns:0 frame:0 TX packets:142210 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:286289024 (273.0 MiB) TX bytes:286289024 (273.0 MiB) virbr0 Link encap:Ethernet HWaddr 00:FF:12:85:0F:D0 inet addr:192.168.122.1 Bcast:192.168.122.255 Mask:255.255.255.0 inet6 addr: fe80::1cc7:34ff:fe82:fdbc/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:5925 errors:0 dropped:0 overruns:0 frame:0 TX packets:5228 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:432804 (422.6 KiB) TX bytes:4295659 (4.0 MiB) vnet0 Link encap:Ethernet HWaddr 00:FF:12:85:0F:D0 inet6 addr: fe80::2ff:12ff:fe85:fd0/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:105 errors:0 dropped:0 overruns:0 frame:0 TX packets:269 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:17377 (16.9 KiB) TX bytes:17621 (17.2 KiB) vnet1 Link encap:Ethernet HWaddr 00:FF:16:0F:7D:A0 inet6 addr: fe80::2ff:16ff:fe0f:7da0/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:150 errors:0 dropped:0 overruns:0 frame:0 TX packets:147590 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:41461 (40.4 KiB) TX bytes:8863921 (8.4 MiB) [root at grp-01-10-01 TEST1]# brctl show bridge name bridge id STP enabled interfaces pan0 8000.000000000000 no virbr0 8000.00ff12850fd0 yes vnet0 vnet1 Regards, Gerry From greno at verizon.net Fri May 9 15:56:04 2008 From: greno at verizon.net (Gerry Reno) Date: Fri, 09 May 2008 11:56:04 -0400 Subject: Anyone else with hard freezes? In-Reply-To: <2a28d2ab0805090336j78fe2772q1df6283e3c5d38cf@mail.gmail.com> References: <2a28d2ab0805061455l9afae56p8a86218d08bc4b92@mail.gmail.com> <34809.75.164.221.130.1210112514.squirrel@clueserver.org> <2a28d2ab0805061526o55c58b80y5fceed9375555ffa@mail.gmail.com> <1210112921.6222.9.camel@optimus> <2a28d2ab0805061530j3a8aa79ehb51d96afedaad644@mail.gmail.com> <1210116098.6222.11.camel@optimus> <2a28d2ab0805081558q3fdb4b94hf41f40db0253f015@mail.gmail.com> <80d7e4090805081625m111b7955v2c96d864275334b2@mail.gmail.com> <2a28d2ab0805081723q6a3537d7n93db59501cf23b16@mail.gmail.com> <2a28d2ab0805090336j78fe2772q1df6283e3c5d38cf@mail.gmail.com> Message-ID: <48247414.9090407@verizon.net> On one of my machines that was experiencing hard freezes I would notice that the last thing in the log before the hang was a ntpd time synch. Don't know why a time synch would cause a hang but every time it was the last thing before it would hang. Regards, Gerry From kevin.kofler at chello.at Fri May 9 16:12:53 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 9 May 2008 16:12:53 +0000 (UTC) Subject: what's the brief grand-plan for java ? References: <1210341372.7436.276.camel@vain.rhgalway> <9497e9990805090703s342da405k842436477204c548@mail.gmail.com> <48245A40.4020505@redhat.com> Message-ID: Andrew Haley redhat.com> writes: > That's right. On some systems the advantage of precompilation could > be considerable. At the moment, though, LLVM looks more promising. Couldn't LLVM be used for AOT-compilation too? Kevin Kofler From aph at redhat.com Fri May 9 16:43:39 2008 From: aph at redhat.com (Andrew Haley) Date: Fri, 09 May 2008 17:43:39 +0100 Subject: what's the brief grand-plan for java ? In-Reply-To: References: <1210341372.7436.276.camel@vain.rhgalway> <9497e9990805090703s342da405k842436477204c548@mail.gmail.com> <48245A40.4020505@redhat.com> Message-ID: <48247F3B.50602@redhat.com> Kevin Kofler wrote: > Andrew Haley redhat.com> writes: >> That's right. On some systems the advantage of precompilation could >> be considerable. At the moment, though, LLVM looks more promising. > > Couldn't LLVM be used for AOT-compilation too? Sure could. I don't know if it would work as well, though, and gcj is a very well-proven stable compiler. Andrew. From surenkarapetyan at gmail.com Fri May 9 16:50:04 2008 From: surenkarapetyan at gmail.com (Suren Karapetyan) Date: Fri, 09 May 2008 21:50:04 +0500 Subject: F9 and KVM In-Reply-To: <48246AC5.9030506@verizon.net> References: <1210214432.5112.53.camel@localhost.localdomain> <48227A43.6010409@verizon.net> <48229C3B.9080209@verizon.net> <20080508112444.GA29692@amd.home.annexia.org> <4823128A.3030003@verizon.net> <20080508155150.GA32379@amd.home.annexia.org> <48232D5E.1030800@verizon.net> <48233A5E.5080006@verizon.net> <4c4ba1530805081103y3a1b7c63uf5dad9c735d39269@mail.gmail.com> <482343FD.1020609@gmail.com> <4c4ba1530805081123l2ab9ccdco577121583369a3ec@mail.gmail.com> <48234707.4000107@verizon.net> <48234808.60907@verizon.net> <1210272164.3807.20.camel@localhost.localdomain> <48235434.3010807@verizon.net> <48236F5C.3090507@verizon.net> <48241107.5070406@gmail.com> <48246AC5.9030506@verizon.net> Message-ID: <482480BC.1000503@gmail.com> Gerry Reno wrote: > Suren Karapetyan wrote: >> It would help if You did "ifconfig" and "brctl show" on the host PC >> while guest is running and posted it here. That way we could find out >> what's happening. >> >> BTW: Is eth0 on host configured via DHCPD or static? >> > > I made some small progress. I had an existing bridge br0 and > virt-manager created a second bridge virbr0. vnet0 and vnet1 became > attached to my br0 bridge and not virbr0. Now I don't see why that > should be a problem but apparently it is. So I destroyed my bridge. > Changed the vm defines to reflect virbr0 and restarted everything. So > now in the guest I can ping 192.168.122.1 which is the virbr0. But > that's all I cannot get access to the lan. When I originally had setup > the images via virt-manager gui I selected shared networking and it was > showing br0(eth0) which was my original bridge. I was expecting it > would slave to this and then I would have a bridge to my lan address > space. But this did not work and I had access to nothing. So how can I > define a bridge on my lan and have the guests slave to it so that they > can get either a lan dhcp address or a static lan address? > > Here are the current conditions: > > eth0 Link encap:Ethernet HWaddr 00:1A:4D:5E:F6:36 inet > addr:192.168.1.15 Bcast:192.168.1.255 Mask:255.255.255.0 > inet6 addr: fe80::21a:4dff:fe5e:f636/64 Scope:Link > UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 > RX packets:27833013 errors:0 dropped:0 overruns:0 frame:0 > TX packets:36339801 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:3841204956 (3.5 GiB) TX bytes:1079379274 (1.0 GiB) > Interrupt:19 Base address:0xc000 > > 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:142210 errors:0 dropped:0 overruns:0 frame:0 > TX packets:142210 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:286289024 (273.0 MiB) TX bytes:286289024 (273.0 MiB) > > virbr0 Link encap:Ethernet HWaddr 00:FF:12:85:0F:D0 inet > addr:192.168.122.1 Bcast:192.168.122.255 Mask:255.255.255.0 > inet6 addr: fe80::1cc7:34ff:fe82:fdbc/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:5925 errors:0 dropped:0 overruns:0 frame:0 > TX packets:5228 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:432804 (422.6 KiB) TX bytes:4295659 (4.0 MiB) > > vnet0 Link encap:Ethernet HWaddr 00:FF:12:85:0F:D0 inet6 > addr: fe80::2ff:12ff:fe85:fd0/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:105 errors:0 dropped:0 overruns:0 frame:0 > TX packets:269 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:500 > RX bytes:17377 (16.9 KiB) TX bytes:17621 (17.2 KiB) > > vnet1 Link encap:Ethernet HWaddr 00:FF:16:0F:7D:A0 inet6 > addr: fe80::2ff:16ff:fe0f:7da0/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:150 errors:0 dropped:0 overruns:0 frame:0 > TX packets:147590 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:500 > RX bytes:41461 (40.4 KiB) TX bytes:8863921 (8.4 MiB) > > [root at grp-01-10-01 TEST1]# brctl show > bridge name bridge id STP enabled interfaces > pan0 8000.000000000000 no > virbr0 8000.00ff12850fd0 yes vnet0 > > vnet1 > > > > Regards, > Gerry > Your initial configuration was right. I don't have much skills with bridges so maybe someone more experienced could correct me but maybe You need ip_forwarding. And also, bridged packets travel through iptables so You may need some rules (libvirtd adds some but I don't remember if they are enough). Could You switch to Your previews settings and post outputs for ifconfig, brctl show, iptables -L -n -v? From mark.bidewell at alumni.clemson.edu Fri May 9 16:52:20 2008 From: mark.bidewell at alumni.clemson.edu (Mark Bidewell) Date: Fri, 9 May 2008 12:52:20 -0400 Subject: F9 and KVM In-Reply-To: <482480BC.1000503@gmail.com> References: <1210214432.5112.53.camel@localhost.localdomain> <4c4ba1530805081123l2ab9ccdco577121583369a3ec@mail.gmail.com> <48234707.4000107@verizon.net> <48234808.60907@verizon.net> <1210272164.3807.20.camel@localhost.localdomain> <48235434.3010807@verizon.net> <48236F5C.3090507@verizon.net> <48241107.5070406@gmail.com> <48246AC5.9030506@verizon.net> <482480BC.1000503@gmail.com> Message-ID: On Fri, May 9, 2008 at 12:50 PM, Suren Karapetyan wrote: > Gerry Reno wrote: > >> Suren Karapetyan wrote: >> >>> It would help if You did "ifconfig" and "brctl show" on the host PC while >>> guest is running and posted it here. That way we could find out what's >>> happening. >>> >>> BTW: Is eth0 on host configured via DHCPD or static? >>> >>> >> I made some small progress. I had an existing bridge br0 and virt-manager >> created a second bridge virbr0. vnet0 and vnet1 became attached to my br0 >> bridge and not virbr0. Now I don't see why that should be a problem but >> apparently it is. So I destroyed my bridge. Changed the vm defines to >> reflect virbr0 and restarted everything. So now in the guest I can ping >> 192.168.122.1 which is the virbr0. But that's all I cannot get access to >> the lan. When I originally had setup the images via virt-manager gui I >> selected shared networking and it was showing br0(eth0) which was my >> original bridge. I was expecting it would slave to this and then I would >> have a bridge to my lan address space. But this did not work and I had >> access to nothing. So how can I define a bridge on my lan and have the >> guests slave to it so that they can get either a lan dhcp address or a >> static lan address? >> >> Here are the current conditions: >> >> eth0 Link encap:Ethernet HWaddr 00:1A:4D:5E:F6:36 inet >> addr:192.168.1.15 Bcast:192.168.1.255 Mask:255.255.255.0 >> inet6 addr: fe80::21a:4dff:fe5e:f636/64 Scope:Link >> UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 >> RX packets:27833013 errors:0 dropped:0 overruns:0 frame:0 >> TX packets:36339801 errors:0 dropped:0 overruns:0 carrier:0 >> collisions:0 txqueuelen:1000 >> RX bytes:3841204956 (3.5 GiB) TX bytes:1079379274 (1.0 GiB) >> Interrupt:19 Base address:0xc000 >> >> 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:142210 errors:0 dropped:0 overruns:0 frame:0 >> TX packets:142210 errors:0 dropped:0 overruns:0 carrier:0 >> collisions:0 txqueuelen:0 >> RX bytes:286289024 (273.0 MiB) TX bytes:286289024 (273.0 MiB) >> >> virbr0 Link encap:Ethernet HWaddr 00:FF:12:85:0F:D0 inet >> addr:192.168.122.1 Bcast:192.168.122.255 Mask:255.255.255.0 >> inet6 addr: fe80::1cc7:34ff:fe82:fdbc/64 Scope:Link >> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 >> RX packets:5925 errors:0 dropped:0 overruns:0 frame:0 >> TX packets:5228 errors:0 dropped:0 overruns:0 carrier:0 >> collisions:0 txqueuelen:0 >> RX bytes:432804 (422.6 KiB) TX bytes:4295659 (4.0 MiB) >> >> vnet0 Link encap:Ethernet HWaddr 00:FF:12:85:0F:D0 inet6 >> addr: fe80::2ff:12ff:fe85:fd0/64 Scope:Link >> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 >> RX packets:105 errors:0 dropped:0 overruns:0 frame:0 >> TX packets:269 errors:0 dropped:0 overruns:0 carrier:0 >> collisions:0 txqueuelen:500 >> RX bytes:17377 (16.9 KiB) TX bytes:17621 (17.2 KiB) >> >> vnet1 Link encap:Ethernet HWaddr 00:FF:16:0F:7D:A0 inet6 >> addr: fe80::2ff:16ff:fe0f:7da0/64 Scope:Link >> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 >> RX packets:150 errors:0 dropped:0 overruns:0 frame:0 >> TX packets:147590 errors:0 dropped:0 overruns:0 carrier:0 >> collisions:0 txqueuelen:500 >> RX bytes:41461 (40.4 KiB) TX bytes:8863921 (8.4 MiB) >> >> [root at grp-01-10-01 TEST1]# brctl show >> bridge name bridge id STP enabled interfaces >> pan0 8000.000000000000 no >> virbr0 8000.00ff12850fd0 yes vnet0 >> >> vnet1 >> >> >> >> Regards, >> Gerry >> >> > Your initial configuration was right. > I don't have much skills with bridges so maybe someone more experienced > could correct me but maybe You need ip_forwarding. > And also, bridged packets travel through iptables so You may need some > rules (libvirtd adds some but I don't remember if they are enough). > > Could You switch to Your previews settings and post outputs for ifconfig, > brctl show, iptables -L -n -v? > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Here is some more info which includes IPTables. http://www.watzmann.net/blog/index.php/2007/04/27/networking_with_kvm_and_libvirt Mark Bidewell -------------- next part -------------- An HTML attachment was scrubbed... URL: From walters at verbum.org Fri May 9 16:52:48 2008 From: walters at verbum.org (Colin Walters) Date: Fri, 9 May 2008 12:52:48 -0400 Subject: what's the brief grand-plan for java ? In-Reply-To: <48245A40.4020505@redhat.com> References: <1210341372.7436.276.camel@vain.rhgalway> <9497e9990805090703s342da405k842436477204c548@mail.gmail.com> <48245A40.4020505@redhat.com> Message-ID: On Fri, May 9, 2008 at 10:05 AM, Andrew Haley wrote: > > That's right. On some systems the advantage of precompilation could > be considerable. At the moment, though, LLVM looks more promising. More important than compilation model in my mind is if we want to continue supporting GCJ, is for it to use the OpenJDK class library; when I tried GCJ in the past I had problems with incompleteness or bugs in Classpath, I never had an issue with the way code was generated. From aph at redhat.com Fri May 9 16:59:06 2008 From: aph at redhat.com (Andrew Haley) Date: Fri, 09 May 2008 17:59:06 +0100 Subject: what's the brief grand-plan for java ? In-Reply-To: References: <1210341372.7436.276.camel@vain.rhgalway> <9497e9990805090703s342da405k842436477204c548@mail.gmail.com> <48245A40.4020505@redhat.com> Message-ID: <482482DA.305@redhat.com> Colin Walters wrote: > On Fri, May 9, 2008 at 10:05 AM, Andrew Haley wrote: >> That's right. On some systems the advantage of precompilation could >> be considerable. At the moment, though, LLVM looks more promising. > > More important than compilation model in my mind is if we want to > continue supporting GCJ, is for it to use the OpenJDK class library; That is a big task. The simplest way to do it, I suspect, is to enable the OpenJDK runtime to load gcj classes rather than to adapt the OpenJDK class library to gcj. This sounds rather counter-intuitive, but the interface between class library and virtual machine is not at all portable or well-documented, and it is complex. > when I tried GCJ in the past I had problems with incompleteness or > bugs in Classpath, I never had an issue with the way code was > generated. I agree. Andrew. From a.badger at gmail.com Fri May 9 17:10:06 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 09 May 2008 10:10:06 -0700 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <4824184A.1010508@redhat.com> References: <1209999548.32107.11.camel@kennedy> <481F2986.8010509@redhat.com> <1210002669.26792.65.camel@beck.corsepiu.local> <481FD064.6050307@ncsu.edu> <1210045081.4658.7.camel@localhost.localdomain> <481FD3D5.5070206@ncsu.edu> <48207309.3040403@redhat.com> <1210321932.26792.817.camel@beck.corsepiu.local> <4824184A.1010508@redhat.com> Message-ID: <4824856E.3080109@gmail.com> Karsten Hopp wrote: > Ralf Corsepius schrieb: >> On Tue, 2008-05-06 at 11:02 -0400, Christopher Aillon wrote: >>> On 05/05/2008 11:43 PM, Casey Dahlin wrote: >>>> Matthias Clasen wrote: >>>>> On Mon, 2008-05-05 at 23:28 -0400, Casey Dahlin wrote: >> >>> If you'd have read the thread, you'd have noticed I already pointed >>> out multiple times, if you want to keep Firefox in the distro, you >>> need to keep autoconf213 for the forseeable future. >> Not at all. The firefox project should ship their infrastructure, such >> that developers can install it into their development environments. >> > > They do. Our Firefox rpm rebuilds just fine without autoconf213. The > autoconf213 > package is required to build the necessary files when the tarballs are > created. > > FYI: I've canceled my request to block the older autofoo packages as the > discussion > here showed that we just can't do that. > I'd like to see a reviewer guideline instead that new packages should be > checked > if they really need to run autofoo during the build and if they really > require to > be built with ancient autofoo. > So I have a few things against my initial impression of how this draft could turn out (Note: draft unseen of course so you might intend something entirely different: 1) It's micro-managing. Packagers should know whether they have to regenerate configure/Makefile.in based on the patches that they're applying. If we're seeing widespread use of the autotools when there's no need to do it then it seems like a candidate to add... but is that the case? The list of packages which presently BuildRequire the autotools is very small so I'm not sure this is the case. 2) Having the packager and reviewer know that the package requires older autotools to build raises the barrier to entry significantly. If you can give us a checklist of items to look for in configure.in that limit the package to ancient autotools then we are in business. This is something better done upstream. Combining these and asking people who know enough to patch configure.in/Makefile.am to try to decide whether they can use current autoconf/automake instead of the compat packages could be a compromise solution but even there, you run into issues where the packager knows enough to patch: - GTKHTML_MAX_VER=3.9 + GTKHTML_MAX_VER=3.10 but not enough to recognize when older autoconf is arequirement. If we really and truly want to get upstreams off of older versions of autoconf/automake, we need to introduce it into our toolchain and have every package that uses autotools invoke the current autoconf/automake in the build. This will bring errors to the surface so we can fix them and submit the changes upstream. Note that I think this is a horrendous idea as it completely disregards one of the core tenets of the autotools (the system that builds the package does not need to have the autotools installed) but if we want to have our packagers actively hunting for incompatibilities with the new autotools, then it seems like a necessary step. -Toshio From christoph.wickert at googlemail.com Fri May 9 17:44:28 2008 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Fri, 09 May 2008 19:44:28 +0200 Subject: Orphaned package still in the repo Message-ID: <1210355068.13439.11.camel@wicktop.localdomain> Hi everybody, I orphaned gnome-ppp on April, 5th, nevertheless it was copied to the F9 and Rawhide repos on April 15th. Why? The program is dead upstream and I'd like to get rid of this package ASAP, if possible before F9. Regards Christoph From rdieter at math.unl.edu Fri May 9 17:48:26 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 09 May 2008 12:48:26 -0500 Subject: Orphaned package still in the repo References: <1210355068.13439.11.camel@wicktop.localdomain> Message-ID: Christoph Wickert wrote: > I orphaned gnome-ppp on April, 5th, nevertheless it was copied to the F9 > and Rawhide repos on April 15th. Why? The program is dead upstream and > I'd like to get rid of this package ASAP, if possible before F9. Did you ask rel-eng to block it per EOL procedure? http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife -- Rex From christoph.wickert at googlemail.com Fri May 9 20:06:54 2008 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Fri, 09 May 2008 22:06:54 +0200 Subject: Orphaned package still in the repo In-Reply-To: References: <1210355068.13439.11.camel@wicktop.localdomain> Message-ID: <1210363614.13439.13.camel@wicktop.localdomain> Am Freitag, den 09.05.2008, 12:48 -0500 schrieb Rex Dieter: > Christoph Wickert wrote: > > > I orphaned gnome-ppp on April, 5th, nevertheless it was copied to the F9 > > and Rawhide repos on April 15th. Why? The program is dead upstream and > > I'd like to get rid of this package ASAP, if possible before F9. > > Did you ask rel-eng to block it per EOL procedure? > http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife > No I did not, because I thought the EOL procedure was obsoleted by pkgDB. > -- Rex Christoph From notting at redhat.com Fri May 9 20:13:18 2008 From: notting at redhat.com (Bill Nottingham) Date: Fri, 9 May 2008 16:13:18 -0400 Subject: Orphaned package still in the repo In-Reply-To: <1210363614.13439.13.camel@wicktop.localdomain> References: <1210355068.13439.11.camel@wicktop.localdomain> <1210363614.13439.13.camel@wicktop.localdomain> Message-ID: <20080509201318.GA22330@nostromo.devel.redhat.com> > > Did you ask rel-eng to block it per EOL procedure? > > http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife > > No I did not, because I thought the EOL procedure was obsoleted by > pkgDB. pkgDB does not now (and may not ever) know how to block packages from koji. Bill From caillon at redhat.com Fri May 9 20:49:37 2008 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 09 May 2008 16:49:37 -0400 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <4824856E.3080109@gmail.com> References: <1209999548.32107.11.camel@kennedy> <481F2986.8010509@redhat.com> <1210002669.26792.65.camel@beck.corsepiu.local> <481FD064.6050307@ncsu.edu> <1210045081.4658.7.camel@localhost.localdomain> <481FD3D5.5070206@ncsu.edu> <48207309.3040403@redhat.com> <1210321932.26792.817.camel@beck.corsepiu.local> <4824184A.1010508@redhat.com> <4824856E.3080109@gmail.com> Message-ID: <4824B8E1.30406@redhat.com> On 05/09/2008 01:10 PM, Toshio Kuratomi wrote: > If we really and truly want to get upstreams off of older versions of > autoconf/automake, we need to introduce it into our toolchain and have > every package that uses autotools invoke the current autoconf/automake > in the build. This will bring errors to the surface so we can fix them > and submit the changes upstream. Toshio, this thread is dead. I already brought one application that doesn't build with current autotools to the surface: Firefox. (Well, plus Thunderbird, SeaMonkey, etc). Yet, as popular as Firefox is, I don't see anyone fixing it. I've been asking multiple times on this thread for people that care about this issue to fix it. There have been no takers as of yet. That should speak volumes about how important this really is. From kevin.kofler at chello.at Fri May 9 21:22:12 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 9 May 2008 21:22:12 +0000 (UTC) Subject: Orphaned package still in the repo References: <1210355068.13439.11.camel@wicktop.localdomain> Message-ID: Christoph Wickert googlemail.com> writes: > I orphaned gnome-ppp on April, 5th, nevertheless it was copied to the F9 > and Rawhide repos on April 15th. Why? The program is dead upstream and > I'd like to get rid of this package ASAP, if possible before F9. You can't remove packages from released versions, and as far as I know it's too late to get the package blocked from F9 too now (you can ask rel-eng for confirmation, but I believe the Everything repo is already being synced to mirrors), you can only get it blocked from F10 on. Blocking packages (i.e. making them disappear from Rawhide and future releases) can only be done by Release Engineering, you have to request it from them. Kevin Kofler From airlied at redhat.com Sat May 10 05:47:12 2008 From: airlied at redhat.com (Dave Airlie) Date: Sat, 10 May 2008 15:47:12 +1000 Subject: Anyone else with hard freezes? In-Reply-To: <2a28d2ab0805090336j78fe2772q1df6283e3c5d38cf@mail.gmail.com> References: <2a28d2ab0805061455l9afae56p8a86218d08bc4b92@mail.gmail.com> <34809.75.164.221.130.1210112514.squirrel@clueserver.org> <2a28d2ab0805061526o55c58b80y5fceed9375555ffa@mail.gmail.com> <1210112921.6222.9.camel@optimus> <2a28d2ab0805061530j3a8aa79ehb51d96afedaad644@mail.gmail.com> <1210116098.6222.11.camel@optimus> <2a28d2ab0805081558q3fdb4b94hf41f40db0253f015@mail.gmail.com> <80d7e4090805081625m111b7955v2c96d864275334b2@mail.gmail.com> <2a28d2ab0805081723q6a3537d7n93db59501cf23b16@mail.gmail.com> <2a28d2ab0805090336j78fe2772q1df6283e3c5d38cf@mail.gmail.com> Message-ID: <1210398432.17530.0.camel@optimus> On Fri, 2008-05-09 at 05:36 -0500, Dr. Diesel wrote: > Ok, that wasn't it either! try booting with nohz maybe. crazy but worth a go. Dave. From mschwendt at gmail.com Sat May 10 08:13:44 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Sat, 10 May 2008 10:13:44 +0200 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <20080505162919.GB7317@nostromo.devel.redhat.com> References: <1209999548.32107.11.camel@kennedy> <1210002510.26792.62.camel@beck.corsepiu.local> <481F306A.90600@redhat.com> <1210004495.26792.82.camel@beck.corsepiu.local> <20080505162919.GB7317@nostromo.devel.redhat.com> Message-ID: <20080510101344.2aab18f6.mschwendt@gmail.com> On Mon, 5 May 2008 12:29:19 -0400, Bill Nottingham wrote: > > How comes you expect each and every tool in Fedora but the autotools to > > be "current". > > That's it! > > OK, by Fedora 10 we need to start removing all sorts of not 'current' > things that aren't up to modern standards. > > First, toolkits! > > We need to remove gtk1, qt3, and for pete's sake, Xaw and Xaw3d. All > are obsolete, and users and developers are best served by upgrading > to more recent toolkits such as Qt4 and GTK2. > > The following 258 packages need ported by Fedora 10, or they will > be removed: > k3b-1.0.4-6.fc9 > k3b-extras-nonfree-1.0.4-2.lvn9 Because of Qt 3.x based KDE 3.x? Funny decision so far. > qt3-3.3.8b-12.fc9 > qt-4.3.4-11.fc9 ??? Qt 4.x is current, isn't it? From rawhide at fedoraproject.org Sat May 10 13:18:27 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Sat, 10 May 2008 13:18:27 +0000 (UTC) Subject: rawhide report: 20080510 changes Message-ID: <20080510131827.62CA1209D16@releng1.fedora.phx.redhat.com> Updated Packages: (none) Broken deps for ppc64 ---------------------------------------------------------- livecd-tools-017-1.fc9.ppc64 requires yaboot perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot From mike at miketc.com Sat May 10 14:11:08 2008 From: mike at miketc.com (Mike Chambers) Date: Sat, 10 May 2008 09:11:08 -0500 Subject: Dell Laptop Message-ID: <1210428668.3864.2.camel@scrappy.miketc.com> Would anyone care to take a quick look at the laptop below to see if they think OK bargain and works fine with Fedora, esp. F9 that is coming out? It looks like it might work just fine, but not in tune with how good/bad suspend/resume/hibernate works on it with linux. http://www.staples.com/office/supplies/p4_Dell-Inspiron-1526-Notebook-PC %27s_220198_Business_Supplies_1_10051_FEATURED:SC3:CG71:DP4118 -- Mike Chambers Fedora Project - Ambassador, Bug Zapper, Tester, User, etc.. mikec302 at fedoraproject.org From ville.skytta at iki.fi Sat May 10 15:48:43 2008 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sat, 10 May 2008 18:48:43 +0300 Subject: Maintainer Responsibility Policy In-Reply-To: <1210038042.14143.3.camel@kennedy> References: <1210035695.6297.25.camel@kennedy> <1210037111.29415.119.camel@localhost.localdomain> <1210038042.14143.3.camel@kennedy> Message-ID: <200805101848.43911.ville.skytta@iki.fi> On Tuesday 06 May 2008, Brian Pepple wrote: > On Mon, 2008-05-05 at 21:25 -0400, Jesse Keating wrote: > > On Mon, 2008-05-05 at 21:01 -0400, Brian Pepple wrote: > > > * List of packages which are affected by the change. > > > Generally, this is merely the list of packages which > > > depend directly on the package which is being updated, > > > and can be found with "repoquery --whatrequires > > > package" where "package" is the package being updated. > > > > Shouldn't there be an --all there, as well as looking at what packages > > BuildRequire yours? > > Yeah, I think your right. I believe Jesse meant --alldeps. --all in this context does not make much sense to me, but --alldeps does very much. I already went ahead and changed this in Wiki. The bit about checking what packages BuildRequire the updated package from Jesse's suggestion above seems to be missing still, was that intentionally omitted? From jonstanley at gmail.com Sat May 10 17:12:12 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Sat, 10 May 2008 13:12:12 -0400 Subject: Dell Laptop In-Reply-To: <1210428668.3864.2.camel@scrappy.miketc.com> References: <1210428668.3864.2.camel@scrappy.miketc.com> Message-ID: On Sat, May 10, 2008 at 10:11 AM, Mike Chambers wrote: > http://www.staples.com/office/supplies/p4_Dell-Inspiron-1526-Notebook-PC > %27s_220198_Business_Supplies_1_10051_FEATURED:SC3:CG71:DP4118 Not 100% the right place to talk about this, but looking there, I noticed that it had the "Dell Wireless" (read: Broadcom) wifi chipset. This will likely give you no end of trouble from what I've seen (note that I have no personal experience, just horror stories that I've heard). If you go with something with an Intel chipset, it should Just Work(TM). Something along the same lines and price range from a local retailer (that does most of their business via the Internet, actually) here in NYC is: http://www.jr.com/JRProductPage.process?Product=4218347 This is also a good deal lighter, and you have the advantage of not paying sales tax if you're not in New York State. I *hihgly* recommend J&R - they're wondeful. From maximilianbianco at gmail.com Sat May 10 17:33:18 2008 From: maximilianbianco at gmail.com (max bianco) Date: Sat, 10 May 2008 13:33:18 -0400 Subject: Dell Laptop In-Reply-To: References: <1210428668.3864.2.camel@scrappy.miketc.com> Message-ID: On Sat, May 10, 2008 at 1:12 PM, Jon Stanley wrote: > On Sat, May 10, 2008 at 10:11 AM, Mike Chambers wrote: > >> http://www.staples.com/office/supplies/p4_Dell-Inspiron-1526-Notebook-PC >> %27s_220198_Business_Supplies_1_10051_FEATURED:SC3:CG71:DP4118 > > Not 100% the right place to talk about this, but looking there, I > noticed that it had the "Dell Wireless" (read: Broadcom) wifi chipset. > This will likely give you no end of trouble from what I've seen (note > that I have no personal experience, just horror stories that I've > heard). If you go with something with an Intel chipset, it should > Just Work(TM). > Yes, Dell seems to include the broadcom chipset by default with many of its offerings. I specifically requested the intel wireless and haven't had any trouble out of it. Definitely go Intel wireless over Broadcom. Just my 2 cents. Max From txtoth at gmail.com Sat May 10 18:06:56 2008 From: txtoth at gmail.com (Xavier Toth) Date: Sat, 10 May 2008 13:06:56 -0500 Subject: macbook pro xorg.conf modeline problem Message-ID: I had been using this mode line along with the vesa driver on previous versions of fedora: Modeline "1440x900x60" 108.84 1440 1472 1880 1912 900 918 927 946 However with FC9 preview it no longer works and the xserver fails to start complaining "No matching modes". I've also tried using gtf to build a modeline but that doesn't work either. Anyone got a working modeline? -------------- next part -------------- An HTML attachment was scrubbed... URL: From maillist at diffingo.com Sat May 10 18:47:49 2008 From: maillist at diffingo.com (Stewart Adam) Date: Sat, 10 May 2008 14:47:49 -0400 Subject: macbook pro xorg.conf modeline problem In-Reply-To: References: Message-ID: <1210445269.29014.3.camel@Diffingo.localdomain> Well, I don't have a working *modeline* - just a lack of one. I used the stock xorg.conf and it works fine here. What version MBP do you have? Stewart On Sat, 2008-05-10 at 13:06 -0500, Xavier Toth wrote: > I had been using this mode line along with the vesa driver on previous > versions of fedora: > Modeline "1440x900x60" 108.84 1440 1472 1880 1912 900 918 > 927 946 > > > However with FC9 preview it no longer works and the xserver fails to > start complaining "No matching modes". I've also tried using gtf to > build a modeline but that doesn't work either. Anyone got a working > modeline? > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From lordmorgul at gmail.com Sat May 10 19:05:14 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Sat, 10 May 2008 12:05:14 -0700 Subject: macbook pro xorg.conf modeline problem In-Reply-To: References: Message-ID: <4825F1EA.1080106@gmail.com> Xavier Toth wrote: > I had been using this mode line along with the vesa driver Why are you using the vesa driver? -- Andrew Farris www.lordmorgul.net gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29 From txtoth at gmail.com Sat May 10 19:18:19 2008 From: txtoth at gmail.com (Xavier Toth) Date: Sat, 10 May 2008 14:18:19 -0500 Subject: macbook pro xorg.conf modeline problem In-Reply-To: <4825F1EA.1080106@gmail.com> References: <4825F1EA.1080106@gmail.com> Message-ID: On Sat, May 10, 2008 at 2:05 PM, Andrew Farris wrote: > Xavier Toth wrote: > >> I had been using this mode line along with the vesa driver >> > > Why are you using the vesa driver? > > -- > Andrew Farris www.lordmorgul.net > gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 > BF29 > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Because in the past it has worked. Which do you think I should use and can you include the xorg.conf. On other thing I might mention is that I'm running Fedora in a Parallels vm not sure if that makes a difference. -------------- next part -------------- An HTML attachment was scrubbed... URL: From txtoth at gmail.com Sat May 10 19:21:55 2008 From: txtoth at gmail.com (Xavier Toth) Date: Sat, 10 May 2008 14:21:55 -0500 Subject: macbook pro xorg.conf modeline problem In-Reply-To: <1210445269.29014.3.camel@Diffingo.localdomain> References: <1210445269.29014.3.camel@Diffingo.localdomain> Message-ID: On Sat, May 10, 2008 at 1:47 PM, Stewart Adam wrote: > Well, I don't have a working *modeline* - just a lack of one. I used the > stock xorg.conf and it works fine here. What version MBP do you have? > > Stewart it's about a year old intel dual core not sure what video, is there a way to get hardware info in OSX? > > > > On Sat, 2008-05-10 at 13:06 -0500, Xavier Toth wrote: > > I had been using this mode line along with the vesa driver on previous > > versions of fedora: > > Modeline "1440x900x60" 108.84 1440 1472 1880 1912 900 918 > > 927 946 > > > > > > However with FC9 preview it no longer works and the xserver fails to > > start complaining "No matching modes". I've also tried using gtf to > > build a modeline but that doesn't work either. Anyone got a working > > modeline? > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > -- > 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 gbillios at gmail.com Sat May 10 19:32:04 2008 From: gbillios at gmail.com (George Billios) Date: Sat, 10 May 2008 22:32:04 +0300 Subject: Xorg 1.5 missed the train? Message-ID: <4825F834.1020001@gmail.com> Hi All, It seems that Xorg 1.5 will not be part of F9 - how could it since it is not even released yet. This raises the (theoretical - fedora 9 will ship either way) question, should fedora ship with an development version of Xorg ? What went wrong here ? Even Adam Jackson's move to become the release manager of Xorg didn't make it possible to release 1.5 faster - and possible "buggier"! Now its too late to change anything but I would appreciate some input here because it's a big deal to ship with a development version of one of the most important components. Regards From jspaleta at gmail.com Sat May 10 20:17:37 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 10 May 2008 12:17:37 -0800 Subject: Xorg 1.5 missed the train? In-Reply-To: <4825F834.1020001@gmail.com> References: <4825F834.1020001@gmail.com> Message-ID: <604aa7910805101317y43a31235gd83221657a4d1eaa@mail.gmail.com> On Sat, May 10, 2008 at 11:32 AM, George Billios wrote: > Hi All, > > It seems that Xorg 1.5 will not be part of F9 - how could it since it is not > even released yet. > > This raises the (theoretical - fedora 9 will ship either way) question, > should fedora ship with an development version of Xorg ? I think you mean Xorg 7.4... which xorg-server 1.5 will be one component of. This is a non-issue. We've released pre-release components before for other important components. And we will continue doing it as long as their is trust that the maintainers on the components are working closely and actively with upstream with regard to patching the bugs. Did you happen to have a specific upstream Xorg release 7.4 blocker bug in mind that you are particularly concerned about? Somehow I doubt its important for us to slip a major component like xorg-server over something like an alpha architecture compiling bug which isn't relevant to Fedora's ability to ship a usable xorg-server to our users...at all. And you have to also concede that Xorg bugs dating to up to a year prior to the release of X11R7.3 probably aren't going to be hard blockers on X11R7.4 either. Even upstream realizes that you can't fix all the bugs before you make a release. > Now its too late to change anything but I would appreciate some input here > because it's a big deal to ship with a development version of one of the > most important components. it's less of a big deal than you make it out to be. We've done this before with 'major' componetns.... we'll do it again. You have to accept the fact we are never going to be able to ship 100% bug-free code on release day.. no matter how much we slip any particular release deadline. Bugs will exist, and decisions have to be made concern the severity and impact of those bugs individually. All bugs are not made equal. It's the same process upstream projects go through. And it may very well be that the important bugs blocking an upstream release are out of scope for a Fedora release specifically. if you are not watching the upstream process closely then you are not in a position to make an informed judgment. We put a significant amount of integration testing into the new the xorg components as they haven been coming along, and if the maintainer in question felt things were not in good shape in terms where upstream was at we would have regressed by now. -jef"wonders when you'll notice how far away from current upstream 'release' our F9 gdm is"spaleta From gbillios at gmail.com Sat May 10 20:53:45 2008 From: gbillios at gmail.com (George Billios) Date: Sat, 10 May 2008 23:53:45 +0300 Subject: Xorg 1.5 missed the train? In-Reply-To: <604aa7910805101317y43a31235gd83221657a4d1eaa@mail.gmail.com> References: <4825F834.1020001@gmail.com> <604aa7910805101317y43a31235gd83221657a4d1eaa@mail.gmail.com> Message-ID: <48260B59.1090400@gmail.com> -------- Original Message -------- Subject: Xorg 1.5 missed the train? From: Jeff Spaleta To: Development discussions related to Fedora Date: Sat 10 May 2008 11:17:37 PM EEST > On Sat, May 10, 2008 at 11:32 AM, George Billios wrote: >> Hi All, >> >> It seems that Xorg 1.5 will not be part of F9 - how could it since it is not >> even released yet. >> >> This raises the (theoretical - fedora 9 will ship either way) question, >> should fedora ship with an development version of Xorg ? > > I think you mean Xorg 7.4... which xorg-server 1.5 will be one component of. So you mean that you can ship one without the other ? ;| > This is a non-issue. We've released pre-release components before for > other important components. And we will continue doing it as long as > their is trust that the maintainers on the components are working > closely and actively with upstream with regard to patching the bugs. > Did you happen to have a specific upstream Xorg release 7.4 blocker > bug in mind that you are particularly concerned about? > Somehow I doubt its important for us to slip a major component like > xorg-server over something like an alpha architecture compiling bug > which isn't relevant to Fedora's ability to ship a usable xorg-server > to our users...at all. And you have to also concede that Xorg bugs > dating to up to a year prior to the release of X11R7.3 probably aren't > going to be hard blockers on X11R7.4 either. Even upstream realizes > that you can't fix all the bugs before you make a release. > >> Now its too late to change anything but I would appreciate some input here >> because it's a big deal to ship with a development version of one of the >> most important components. > > it's less of a big deal than you make it out to be. We've done this > before with 'major' componetns.... we'll do it again. You have to > accept the fact we are never going to be able to ship 100% bug-free > code on release day.. no matter how much we slip any particular > release deadline. Bugs will exist, and decisions have to be made > concern the severity and impact of those bugs individually. All bugs > are not made equal. It's the same process upstream projects go > through. And it may very well be that the important bugs blocking an > upstream release are out of scope for a Fedora release specifically. > if you are not watching the upstream process closely then you are not > in a position to make an informed judgment. > > We put a significant amount of integration testing into the new the > xorg components as they haven been coming along, and if the maintainer > in question felt things were not in good shape in terms where upstream > was at we would have regressed by now. > I'm not reffering to any bug in particular but to the whole 'trying to release Xorg 7.4 based on F9 release schedule' concept that happened here. True, I don't know and monitor every bug that has been reported in fedora bugzilla or upstream but taking into account that Xorg 7.4 doesn't even have a RC and that 2 months ago everything was supposed to be going as scheduled, I had to ask. Besides searching the mail list I found zero issues about this in the last 2 months! > > -jef"wonders when you'll notice how far away from current upstream > 'release' our F9 gdm is"spaleta > Don't let me start on gdm.... From mark.bidewell at alumni.clemson.edu Sat May 10 20:54:02 2008 From: mark.bidewell at alumni.clemson.edu (Mark Bidewell) Date: Sat, 10 May 2008 16:54:02 -0400 Subject: Xorg 1.5 missed the train? In-Reply-To: <604aa7910805101317y43a31235gd83221657a4d1eaa@mail.gmail.com> References: <4825F834.1020001@gmail.com> <604aa7910805101317y43a31235gd83221657a4d1eaa@mail.gmail.com> Message-ID: On Sat, May 10, 2008 at 4:17 PM, Jeff Spaleta wrote: > On Sat, May 10, 2008 at 11:32 AM, George Billios > wrote: > > Hi All, > > > > It seems that Xorg 1.5 will not be part of F9 - how could it since it is > not > > even released yet. > > > > This raises the (theoretical - fedora 9 will ship either way) question, > > should fedora ship with an development version of Xorg ? > > I think you mean Xorg 7.4... which xorg-server 1.5 will be one component > of. > > This is a non-issue. We've released pre-release components before for > other important components. And we will continue doing it as long as > their is trust that the maintainers on the components are working > closely and actively with upstream with regard to patching the bugs. > Did you happen to have a specific upstream Xorg release 7.4 blocker > bug in mind that you are particularly concerned about? > > Somehow I doubt its important for us to slip a major component like > xorg-server over something like an alpha architecture compiling bug > which isn't relevant to Fedora's ability to ship a usable xorg-server > to our users...at all. And you have to also concede that Xorg bugs > dating to up to a year prior to the release of X11R7.3 probably aren't > going to be hard blockers on X11R7.4 either. Even upstream realizes > that you can't fix all the bugs before you make a release. > > > Now its too late to change anything but I would appreciate some input > here > > because it's a big deal to ship with a development version of one of the > > most important components. > > it's less of a big deal than you make it out to be. We've done this > before with 'major' componetns.... we'll do it again. You have to > accept the fact we are never going to be able to ship 100% bug-free > code on release day.. no matter how much we slip any particular > release deadline. Bugs will exist, and decisions have to be made > concern the severity and impact of those bugs individually. All bugs > are not made equal. It's the same process upstream projects go > through. And it may very well be that the important bugs blocking an > upstream release are out of scope for a Fedora release specifically. > if you are not watching the upstream process closely then you are not > in a position to make an informed judgment. > > We put a significant amount of integration testing into the new the > xorg components as they haven been coming along, and if the maintainer > in question felt things were not in good shape in terms where upstream > was at we would have regressed by now. > > > -jef"wonders when you'll notice how far away from current upstream > 'release' our F9 gdm is"spaleta > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > As a side question to this - Will fedora continue to push xorg updates for F9 after release? Mark Bidewell -------------- next part -------------- An HTML attachment was scrubbed... URL: From jspaleta at gmail.com Sat May 10 21:01:23 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 10 May 2008 13:01:23 -0800 Subject: Xorg 1.5 missed the train? In-Reply-To: <48260B59.1090400@gmail.com> References: <4825F834.1020001@gmail.com> <604aa7910805101317y43a31235gd83221657a4d1eaa@mail.gmail.com> <48260B59.1090400@gmail.com> Message-ID: <604aa7910805101401n5587c7d0h54bbbf3c58766d79@mail.gmail.com> On Sat, May 10, 2008 at 12:53 PM, George Billios wrote: > True, I don't know and monitor every bug that has been reported in fedora > bugzilla or upstream but taking into account that Xorg 7.4 doesn't even have > a RC and that 2 months ago everything was supposed to be going as scheduled, > I had to ask. Besides searching the mail list I found zero issues about this > in the last 2 months! So the fact that there are no communicated issues makes you think there's a problem? Isn't that sort of backwards? And shouldn't be asking specifically on the upstream lists what the current roadmap for them looks like? The Fedora distribution release schedule has been clearly communicated, even the slips have been. If the upstream process is opaque, then perhaps you should go stomping around on the upstream list asking for some clarity on where their release plans stand. Even if ajax is wearing multiple hats... communications about Xorg's 7.4 release schedule should be done in the Xorg communication channels so everyone who is waiting for it can find the information. Having this discussion here, is just going to make it more difficult for the other distributors to find. -jef From ruben at rubenkerkhof.com Sat May 10 21:07:32 2008 From: ruben at rubenkerkhof.com (Ruben Kerkhof) Date: Sat, 10 May 2008 23:07:32 +0200 Subject: macbook pro xorg.conf modeline problem In-Reply-To: References: <1210445269.29014.3.camel@Diffingo.localdomain> Message-ID: <91A84635-0E53-4975-92A9-8C78B1E2704E@rubenkerkhof.com> On 10 mei 2008, at 21:21, Xavier Toth wrote: > it's about a year old intel dual core not sure what video, is there > a way > to get hardware info in OSX? Run system-profiler from Terminal, or click on "About This Mac", and then "More Info". Regards, Ruben From jspaleta at gmail.com Sat May 10 21:23:59 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 10 May 2008 13:23:59 -0800 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <4825F834.1020001@gmail.com> <604aa7910805101317y43a31235gd83221657a4d1eaa@mail.gmail.com> Message-ID: <604aa7910805101423n561f3dc0y6029e4e870be9493@mail.gmail.com> 2008/5/10 Mark Bidewell : > As a side question to this - Will fedora continue to push xorg updates for > F9 after release? I simply cannot fathom why this question even needs to be asked. Haven't we seen updates for the X11 components in F8 through the F8 release cycle to date? Didn't we just see an F8 update for xorg-x11-server-Xorg in March? There is absolutely no evidence to suggest X hasn't been actively updated in the recent past, so I don't see the point in asking the question. And more to the point. The whole reason why the monolithic codebase was converted to individual components was to make it easier to roll up updates as individual libraries and drivers needed to be patched, rebuilt and distributed to users. I think we've made adequate use of that modularity so far in how we are updating, and I don't see a reason to expect that to change. -jef From email.ahmedkamal at googlemail.com Sat May 10 21:39:08 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Sun, 11 May 2008 00:39:08 +0300 Subject: F9 (bug?) Superblock features different from backup Message-ID: <3da3b5b40805101439y56886e24h2c2a2b36681e7783@mail.gmail.com> Hi, Just installed F9 preview and updated to latest. Rebooted everything was fine. Today, I booted the system again, played with it for a few hours, then I rebooted to test the "i915.modeset" (which is hyper cool thanks:) Now when the machine came up, I got: Primary superblock features different from backup: Check forced This was on the root filesystem. It checked the FS, and finally said "** Rebooting Linux **", at this stage I was fairly scared .. it looked like a serious problem! However, Fedora rebooted and it came up just fine! Well, I have no idea what just happened PS: Why did F9 disable Synaptics touchpad tapping!! This is going to make a lot of Laptop owners angry! At least it made me. Considering Windows and older Fedoras had it enabled, everyone is going to be not too happy about the change I guess. Anyway, if there's infinite wisdom about this, could we at least get release note tips on how to enable it back ? Thanks for the awesome work .. wifi works out of the box, Alsa too, correct wide screen, kernel mode setting ... etc Fedora is getting too good :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From sandeen at redhat.com Sat May 10 21:59:38 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Sat, 10 May 2008 16:59:38 -0500 Subject: F9 (bug?) Superblock features different from backup In-Reply-To: <3da3b5b40805101439y56886e24h2c2a2b36681e7783@mail.gmail.com> References: <3da3b5b40805101439y56886e24h2c2a2b36681e7783@mail.gmail.com> Message-ID: <48261ACA.1030907@redhat.com> Ahmed Kamal wrote: > Hi, > Just installed F9 preview and updated to latest. Rebooted everything was > fine. Today, I booted the system again, played with it for a few hours, > then I rebooted to test the "i915.modeset" (which is hyper cool thanks:) > Now when the machine came up, I got: > Primary superblock features different from backup: Check forced > This was on the root filesystem. It checked the FS, and finally said "** > Rebooting Linux **", at this stage I was fairly scared .. it looked like > a serious problem! > However, Fedora rebooted and it came up just fine! > > Well, I have no idea what just happened It should be fine. Most recent e2fsprogs enforces that feature flags in backups match those on the primary. Problem is, the kernel sets things on the fly, but does not update the backups. This is ... annoying... because then it causes the full fsck. I'm a little surprised that it did check though, because for now I have F9 carrying a patch to actually *disable* this test, because otherwise any F8->F9 upgrade would cause a full fsck just for this reason, which I think is overly aggressive. But, anyway, you should be fine now, and it shouldn't happen again. :) -Eric From email.ahmedkamal at googlemail.com Sat May 10 22:03:05 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Sun, 11 May 2008 01:03:05 +0300 Subject: F9 (bug?) Superblock features different from backup In-Reply-To: <48261ACA.1030907@redhat.com> References: <3da3b5b40805101439y56886e24h2c2a2b36681e7783@mail.gmail.com> <48261ACA.1030907@redhat.com> Message-ID: <3da3b5b40805101503k24bd9afbi53bd4ffd8553caf@mail.gmail.com> Just out of curiosity, could you let me know what kind of changes the kernel makes to the superblock without asking first! That sounds interesting On Sun, May 11, 2008 at 12:59 AM, Eric Sandeen wrote: > Ahmed Kamal wrote: > > Hi, > > Just installed F9 preview and updated to latest. Rebooted everything was > > fine. Today, I booted the system again, played with it for a few hours, > > then I rebooted to test the "i915.modeset" (which is hyper cool thanks:) > > Now when the machine came up, I got: > > Primary superblock features different from backup: Check forced > > This was on the root filesystem. It checked the FS, and finally said "** > > Rebooting Linux **", at this stage I was fairly scared .. it looked like > > a serious problem! > > However, Fedora rebooted and it came up just fine! > > > > Well, I have no idea what just happened > > It should be fine. > > Most recent e2fsprogs enforces that feature flags in backups match those > on the primary. > > Problem is, the kernel sets things on the fly, but does not update the > backups. This is ... annoying... because then it causes the full fsck. > > I'm a little surprised that it did check though, because for now I have > F9 carrying a patch to actually *disable* this test, because otherwise > any F8->F9 upgrade would cause a full fsck just for this reason, which I > think is overly aggressive. > > But, anyway, you should be fine now, and it shouldn't happen again. :) > > -Eric > > -- > 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 sandeen at redhat.com Sat May 10 22:15:45 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Sat, 10 May 2008 17:15:45 -0500 Subject: F9 (bug?) Superblock features different from backup In-Reply-To: <3da3b5b40805101503k24bd9afbi53bd4ffd8553caf@mail.gmail.com> References: <3da3b5b40805101439y56886e24h2c2a2b36681e7783@mail.gmail.com> <48261ACA.1030907@redhat.com> <3da3b5b40805101503k24bd9afbi53bd4ffd8553caf@mail.gmail.com> Message-ID: <48261E91.9040203@redhat.com> Ahmed Kamal wrote: > Just out of curiosity, could you let me know what kind of changes the > kernel makes to the superblock without asking first! That sounds interesting sure, things like the first time a "large" (> 2G file) is written it will set a flag to that effect. Or the first time an extent-based file is created on ext4. We've talked about removing these, actually, and requiring the flags to be set at mkfs time, or via tune2fs, if you wish to use the feature, rather than silently turning them on. -Eric From email.ahmedkamal at googlemail.com Sat May 10 22:18:33 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Sun, 11 May 2008 01:18:33 +0300 Subject: F9 (bug?) Superblock features different from backup In-Reply-To: <48261E91.9040203@redhat.com> References: <3da3b5b40805101439y56886e24h2c2a2b36681e7783@mail.gmail.com> <48261ACA.1030907@redhat.com> <3da3b5b40805101503k24bd9afbi53bd4ffd8553caf@mail.gmail.com> <48261E91.9040203@redhat.com> Message-ID: <3da3b5b40805101518w97e9263x5c437debb276494e@mail.gmail.com> bingo, I had created a virtualbox VM, which created a 8G file, that must have triggered the superblock changes. I feel much calmer now. Thank you :) On Sun, May 11, 2008 at 1:15 AM, Eric Sandeen wrote: > Ahmed Kamal wrote: > > Just out of curiosity, could you let me know what kind of changes the > > kernel makes to the superblock without asking first! That sounds > interesting > > sure, things like the first time a "large" (> 2G file) is written it > will set a flag to that effect. > > Or the first time an extent-based file is created on ext4. > > We've talked about removing these, actually, and requiring the flags to > be set at mkfs time, or via tune2fs, if you wish to use the feature, > rather than silently turning them on. > > -Eric > > -- > 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 lordmorgul at gmail.com Sat May 10 22:50:10 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Sat, 10 May 2008 15:50:10 -0700 Subject: macbook pro xorg.conf modeline problem In-Reply-To: References: <4825F1EA.1080106@gmail.com> Message-ID: <482626A2.2000506@gmail.com> Xavier Toth wrote: > On Sat, May 10, 2008 at 2:05 PM, Andrew Farris wrote: > >> Xavier Toth wrote: >> >>> I had been using this mode line along with the vesa driver >>> >> Why are you using the vesa driver? > > Because in the past it has worked. Which do you think I should use and can > you include the xorg.conf. On other thing I might mention is that I'm > running Fedora in a Parallels vm not sure if that makes a difference. I use the 'vmware' driver on my system since I'm running vmware fusion for that. I'm not sure if there is a better choice for running on parallels or not. -- Andrew Farris www.lordmorgul.net gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29 From greno at verizon.net Sat May 10 23:08:17 2008 From: greno at verizon.net (Gerry Reno) Date: Sat, 10 May 2008 19:08:17 -0400 Subject: F9 and KVM In-Reply-To: References: <1210214432.5112.53.camel@localhost.localdomain> <4c4ba1530805081123l2ab9ccdco577121583369a3ec@mail.gmail.com> <48234707.4000107@verizon.net> <48234808.60907@verizon.net> <1210272164.3807.20.camel@localhost.localdomain> <48235434.3010807@verizon.net> <48236F5C.3090507@verizon.net> <48241107.5070406@gmail.com> <48246AC5.9030506@verizon.net> <482480BC.1000503@gmail.com> Message-ID: <48262AE1.3050605@verizon.net> I'm looking at VDE now and I have it compiled and running on an old fc6 box but I have not been able to get it compiled for my f9 box. It complains about libpcap even though I have it and then it looks as though it can't find limits.h. First it complains about libpcap being too old yet it is the latest version available: Configure results: vde_cryptcab : enabled tuntap support : enabled pcap support : disabled configure: WARNING: VDE packet dump plugin has been disabled because libpcap is not installed on your system, or because it's too old. Please install it if you want pdump to be compiled and installed. experimental features : disabled ]$ su - -c "yum list libpcap" Password: Loaded plugins: fastestmirror, refresh-packagekit Loading mirror speeds from cached hostfile * updates: ftp.ndlug.nd.edu * adobe-linux-i386: linuxdownload.adobe.com * fedora: ftp.ndlug.nd.edu updates | 2.4 kB 00:00 primary.sqlite.bz2 | 6.1 MB 00:06 adobe-linux-i386 | 951 B 00:00 fedora | 2.4 kB 00:00 primary.sqlite.bz2 | 6.1 MB 00:06 Installed Packages libpcap.i386 14:0.9.8-2.fc9 installed Next there are some variable issues: tcp_subr.c: In function 'tcp_fconnect': tcp_subr.c:412: warning: unused variable 'opt' depbase=`echo tcp2unix.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ gcc -DHAVE_CONFIG_H -I. -I.. -DVDE -g -O2 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -MT tcp2unix.o -MD -MP -MF $depbase.Tpo -c -o tcp2unix.o tcp2unix.c &&\ mv -f $depbase.Tpo $depbase.Po depbase=`echo slirpvde.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ gcc -DHAVE_CONFIG_H -I. -I.. -DVDE -g -O2 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -MT slirpvde.o -MD -MP -MF $depbase.Tpo -c -o slirpvde.o slirpvde.c &&\ mv -f $depbase.Tpo $depbase.Po bootp.c: In function 'bootp_reply': bootp.c:267: warning: implicit declaration of function 'client_eth_register' slirpvde.c:54: error: '_POSIX_PATH_MAX' undeclared here (not in a function) slirpvde.c: In function 'save_pidfile': slirpvde.c:79: error: 'PATH_MAX' undeclared (first use in this function) slirpvde.c:79: error: (Each undeclared identifier is reported only once slirpvde.c:79: error: for each function it appears in.) slirpvde.c: In function 'main': slirpvde.c:417: error: 'PATH_MAX' undeclared (first use in this function) slirpvde.c:372: warning: unused variable 'i' make[2]: *** [slirpvde.o] Error 1 Regards, Gerry From ajackson at redhat.com Sat May 10 23:54:02 2008 From: ajackson at redhat.com (Adam Jackson) Date: Sat, 10 May 2008 19:54:02 -0400 Subject: macbook pro xorg.conf modeline problem In-Reply-To: References: Message-ID: <1210463642.4543.2.camel@localhost.localdomain> On Sat, 2008-05-10 at 13:06 -0500, Xavier Toth wrote: > I had been using this mode line along with the vesa driver on previous > versions of fedora: > Modeline "1440x900x60" 108.84 1440 1472 1880 1912 900 918 > 927 946 > > However with FC9 preview it no longer works and the xserver fails to > start complaining "No matching modes". I've also tried using gtf to > build a modeline but that doesn't work either. Anyone got a working > modeline? I'm almost certain you have misdiagnosed the problem. Broadly speaking, the vesa driver ignores modelines, and always has. The X log should at least show you what candidate modes are being considered. It may be that we're throwing away a perfectly valid one. Comparing the log output between F8 and F9 would probably be informative. - ajax From greno at verizon.net Sun May 11 00:05:54 2008 From: greno at verizon.net (Gerry Reno) Date: Sat, 10 May 2008 20:05:54 -0400 Subject: macbook pro xorg.conf modeline problem In-Reply-To: <1210463642.4543.2.camel@localhost.localdomain> References: <1210463642.4543.2.camel@localhost.localdomain> Message-ID: <48263862.3050200@verizon.net> I don't know if this will help you but here is what is in my xorg.conf on F9 running with nvidia on x86: Section "Device" Identifier "Videocard0" Driver "nv" EndSection Section "Screen" Identifier "Screen0" Device "Videocard0" DefaultDepth 24 SubSection "Display" Viewport 0 0 Depth 24 EndSubSection EndSection Regards, Gerry From jwboyer at gmail.com Sun May 11 00:36:22 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Sat, 10 May 2008 19:36:22 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: <604aa7910805101423n561f3dc0y6029e4e870be9493@mail.gmail.com> References: <4825F834.1020001@gmail.com> <604aa7910805101317y43a31235gd83221657a4d1eaa@mail.gmail.com> <604aa7910805101423n561f3dc0y6029e4e870be9493@mail.gmail.com> Message-ID: <20080510193622.509d2146@vader.jdub.homelinux.org> On Sat, 10 May 2008 13:23:59 -0800 "Jeff Spaleta" wrote: > 2008/5/10 Mark Bidewell : > > As a side question to this - Will fedora continue to push xorg updates for > > F9 after release? > > I simply cannot fathom why this question even needs to be asked. Maybe, just maybe, the asker doesn't follow Fedora regularly. Maybe they don't understand our update policies and infrastructures. Maybe they're coming directly from a different operating system and this is their first exposure to Fedora and Linux. So, rather than monologue about past history and examples and give them a dictation of why xorg is packaged they way it is and generally treat them as if they were simpletons, maybe you could just answer: "Yes. We continue to push updates after a release based on several factors. This includes many things like Xorg and the kernel." And then maybe you would have been helpful enough with that answer that the asker would see Fedora is a welcoming place. And maybe we would have garnered another user. So next time you're fathoming, maybe you can fathom that not everyone uses Linux on a daily basis, and new users do come along. Maybe. josh From jspaleta at gmail.com Sun May 11 00:56:04 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 10 May 2008 16:56:04 -0800 Subject: Xorg 1.5 missed the train? In-Reply-To: <20080510193622.509d2146@vader.jdub.homelinux.org> References: <4825F834.1020001@gmail.com> <604aa7910805101317y43a31235gd83221657a4d1eaa@mail.gmail.com> <604aa7910805101423n561f3dc0y6029e4e870be9493@mail.gmail.com> <20080510193622.509d2146@vader.jdub.homelinux.org> Message-ID: <604aa7910805101756o28d0c8fdk84e10564e2e98508@mail.gmail.com> On Sat, May 10, 2008 at 4:36 PM, Josh Boyer wrote: > On Sat, 10 May 2008 13:23:59 -0800 > "Jeff Spaleta" wrote: > >> 2008/5/10 Mark Bidewell : >> > As a side question to this - Will fedora continue to push xorg updates for >> > F9 after release? >> >> I simply cannot fathom why this question even needs to be asked. > > Maybe, just maybe, the asker doesn't follow Fedora regularly. Maybe > they don't understand our update policies and infrastructures. Maybe > they're coming directly from a different operating system and this is > their first exposure to Fedora and Linux. In the particular case of this particular person...what you are suggesting isn't the issue. This particular person has posted on -devel-list...about f8 issues... more than six months ago. In a thread I was active and civil in no less! So no, there's no maybe about it, in this particular case this person should have a working understanding of how updates have been going out. -jef"poster appears in my -devel-list cache on 8/3/07 and in my fedora-list cache as early as 7/1/05"spaleta From mark.bidewell at alumni.clemson.edu Sun May 11 01:28:42 2008 From: mark.bidewell at alumni.clemson.edu (Mark Bidewell) Date: Sat, 10 May 2008 21:28:42 -0400 Subject: Xorg 1.5 missed the train? In-Reply-To: <604aa7910805101756o28d0c8fdk84e10564e2e98508@mail.gmail.com> References: <4825F834.1020001@gmail.com> <604aa7910805101317y43a31235gd83221657a4d1eaa@mail.gmail.com> <604aa7910805101423n561f3dc0y6029e4e870be9493@mail.gmail.com> <20080510193622.509d2146@vader.jdub.homelinux.org> <604aa7910805101756o28d0c8fdk84e10564e2e98508@mail.gmail.com> Message-ID: On Sat, May 10, 2008 at 8:56 PM, Jeff Spaleta wrote: > On Sat, May 10, 2008 at 4:36 PM, Josh Boyer wrote: > > On Sat, 10 May 2008 13:23:59 -0800 > > "Jeff Spaleta" wrote: > > > >> 2008/5/10 Mark Bidewell : > >> > As a side question to this - Will fedora continue to push xorg updates > for > >> > F9 after release? > >> > >> I simply cannot fathom why this question even needs to be asked. > > > > Maybe, just maybe, the asker doesn't follow Fedora regularly. Maybe > > they don't understand our update policies and infrastructures. Maybe > > they're coming directly from a different operating system and this is > > their first exposure to Fedora and Linux. > > In the particular case of this particular person...what you are > suggesting isn't the issue. This particular person has posted on > -devel-list...about f8 issues... more than six months ago. In a thread > I was active and civil in no less! > > So no, there's no maybe about it, in this particular case this person > should have a working understanding of how updates have been going > out. > > -jef"poster appears in my -devel-list cache on 8/3/07 and in my > fedora-list cache as early as 7/1/05"spaleta > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > I apologize for any offense. I had not followed the Xorg updates until now. Mark Bidewell -------------- next part -------------- An HTML attachment was scrubbed... URL: From jspaleta at gmail.com Sun May 11 01:48:50 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 10 May 2008 17:48:50 -0800 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <4825F834.1020001@gmail.com> <604aa7910805101317y43a31235gd83221657a4d1eaa@mail.gmail.com> <604aa7910805101423n561f3dc0y6029e4e870be9493@mail.gmail.com> <20080510193622.509d2146@vader.jdub.homelinux.org> <604aa7910805101756o28d0c8fdk84e10564e2e98508@mail.gmail.com> Message-ID: <604aa7910805101848r22a3a3bfg5efb284f3d47e68b@mail.gmail.com> 2008/5/10 Mark Bidewell : > I apologize for any offense. I had not followed the Xorg updates until > now. No offense taken, more like low blood sugar on my part. Josh sort of has a point, i have to be reminded to watch my tone sometimes, especially just before a meal. But the question did catch be off guard, because so far I haven't seen suggestion that we've failed to meet expectations with Xorg updates...once we split the monolithic package into seperate drivers and libraries. -jef"mental note...eat lunch/dinner before posting"spaleta From greno at verizon.net Sun May 11 03:27:47 2008 From: greno at verizon.net (Gerry Reno) Date: Sat, 10 May 2008 23:27:47 -0400 Subject: F9 and KVM In-Reply-To: <48262AE1.3050605@verizon.net> References: <1210214432.5112.53.camel@localhost.localdomain> <4c4ba1530805081123l2ab9ccdco577121583369a3ec@mail.gmail.com> <48234707.4000107@verizon.net> <48234808.60907@verizon.net> <1210272164.3807.20.camel@localhost.localdomain> <48235434.3010807@verizon.net> <48236F5C.3090507@verizon.net> <48241107.5070406@gmail.com> <48246AC5.9030506@verizon.net> <482480BC.1000503@gmail.com> <48262AE1.3050605@verizon.net> Message-ID: <482667B3.4090203@verizon.net> Gerry Reno wrote: > I'm looking at VDE now and I have it compiled and running on an old > fc6 box but I have not been able to get it compiled for my f9 box. I was surprised that there was no package for VDE. It looks pretty useful. Anyway, I'm not getting anywhere trying to get it to compile on F9. Did something change regarding limits.h? I run the exact same compile on FC6 and it works. But on F9 it fails. Was some header file including limits.h before and is not including it now? Regards, Gerry From mike at miketc.com Sun May 11 06:17:34 2008 From: mike at miketc.com (Mike Chambers) Date: Sun, 11 May 2008 01:17:34 -0500 Subject: Realtek RTL8187B Message-ID: <1210486654.5317.4.camel@scrappy.miketc.com> Have installed F9 (er, well, rawhide anyway as of today) is why asking on this list. This wireless driver is in my laptop that I bought from Best Buy, which is a Gateway laptop. I thought Realtek drivers were opensourced? Or at least I guess maybe only wired drivers are? I can't seem to get the laptop to recognize the wireless driver. It's connected in there somehow via usb, which lsusb does show the driver. Do I have to use ndiswrapper to make this work or should it work out of the box? If out of the box, what steps to get it to load and be recognized? Thanks, -- Mike Chambers Fedora Project - Ambassador, Bug Zapper, Tester, User, etc.. mikec302 at fedoraproject.org From gbillios at gmail.com Sun May 11 07:43:45 2008 From: gbillios at gmail.com (George Billios) Date: Sun, 11 May 2008 10:43:45 +0300 Subject: Xorg 1.5 missed the train? In-Reply-To: <604aa7910805101401n5587c7d0h54bbbf3c58766d79@mail.gmail.com> References: <4825F834.1020001@gmail.com> <604aa7910805101317y43a31235gd83221657a4d1eaa@mail.gmail.com> <48260B59.1090400@gmail.com> <604aa7910805101401n5587c7d0h54bbbf3c58766d79@mail.gmail.com> Message-ID: <4826A3B1.70900@gmail.com> -------- Original Message -------- Subject: Xorg 1.5 missed the train? From: Jeff Spaleta To: Development discussions related to Fedora Date: Sun 11 May 2008 12:01:23 AM EEST > On Sat, May 10, 2008 at 12:53 PM, George Billios wrote: >> True, I don't know and monitor every bug that has been reported in fedora >> bugzilla or upstream but taking into account that Xorg 7.4 doesn't even have >> a RC and that 2 months ago everything was supposed to be going as scheduled, >> I had to ask. Besides searching the mail list I found zero issues about this >> in the last 2 months! > > So the fact that there are no communicated issues makes you think > there's a problem? Isn't that sort of backwards? This isn't exactly what I'm writing here, better read again. >And shouldn't be > asking specifically on the upstream lists what the current roadmap for > them looks like? I'm talking about the fedora release decisions which belongs to this list not to the Xorg list. Again you don't read! >The Fedora distribution release schedule has been > clearly communicated, even the slips have been. If the upstream > process is opaque, then perhaps you should go stomping around on the > upstream list asking for some clarity on where their release plans > stand. Even if ajax is wearing multiple hats... communications about > Xorg's 7.4 release schedule should be done in the Xorg communication > channels so everyone who is waiting for it can find the information. > Having this discussion here, is just going to make it more difficult > for the other distributors to find. > Jeff, better cool off, eat something, get some sleep and come back later with less attitude. > -jef > From sundaram at fedoraproject.org Sun May 11 08:01:29 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 11 May 2008 13:31:29 +0530 Subject: Xorg 1.5 missed the train? In-Reply-To: <4825F834.1020001@gmail.com> References: <4825F834.1020001@gmail.com> Message-ID: <4826A7D9.3070200@fedoraproject.org> George Billios wrote: > Hi All, > > Now its too late to change anything but I would appreciate some input > here because it's a big deal to ship with a development version of one > of the most important components. Addressing the broader topic, it is not really a big deal to ship "development" versions of core components (along with backported patches). Fedora has in the past included development versions of OpenOffice.org and even the kernel Fedora 9 will also include a "beta" version/ development snapshot of Firefox 3 and so has other distributions with similar release cycles . Even enterprise releases include alpha/beta components if they are deemed stable enough by the developers maintainers and upstream projects themselves advice that in various occasions. Combining upstream input, maintainer experience with the amount of feedback from users/testers that we get from including these components early in the release cycle, we can sufficiently gauge whether to include them in the general release or not. What really matters is not the alpha/beta/development labels but the actual stability of the release which can be measured by the number of bugs reported, specific patches etc. So unless you have reported major issues, I wouldn't worry. Rahul From behdad at behdad.org Sun May 11 07:38:39 2008 From: behdad at behdad.org (Behdad Esfahbod) Date: Sun, 11 May 2008 09:38:39 +0200 Subject: Xorg 1.5 missed the train? In-Reply-To: <4825F834.1020001@gmail.com> References: <4825F834.1020001@gmail.com> Message-ID: <1210491519.10397.9.camel@behdad.behdad.org> On Sat, 2008-05-10 at 22:32 +0300, George Billios wrote: > > What went wrong here ? Even Adam Jackson's move to become the release > manager of Xorg didn't make it possible to release 1.5 faster - and > possible "buggier"! Release numbers are for the ignorant. Upstream maintainer and people closely following development think of a module as a list of new features and current bugs, shrinking and growing by time. If Adam thinks it's fine to include a prerelease of xorg in Fedora, then, well, it's fine. Just because we called it cairo 1.6.0 didn't make it any better than 1.5.20. In fact it was worse. We had to release 1.6.2 the day after to fix a bad bug introduced in 1.6.0, and yes, had to release 1.6.4 on the same day, to fix a really bad bug introduced in 1.6.2. 1.5.20 on the other hand, was in release-candidate state for a week with no major issues reported... behdad From gbillios at gmail.com Sun May 11 08:37:30 2008 From: gbillios at gmail.com (George Billios) Date: Sun, 11 May 2008 11:37:30 +0300 Subject: Xorg 1.5 missed the train? In-Reply-To: <1210491519.10397.9.camel@behdad.behdad.org> References: <4825F834.1020001@gmail.com> <1210491519.10397.9.camel@behdad.behdad.org> Message-ID: <4826B04A.8020703@gmail.com> -------- Original Message -------- Subject: Re:Xorg 1.5 missed the train? From: Behdad Esfahbod To: Development discussions related to Fedora Date: Sun 11 May 2008 10:38:39 AM EEST > On Sat, 2008-05-10 at 22:32 +0300, George Billios wrote: >> What went wrong here ? Even Adam Jackson's move to become the release >> manager of Xorg didn't make it possible to release 1.5 faster - and >> possible "buggier"! > > Release numbers are for the ignorant. And I thought they were for a purpose. Please name the next version of Xorg in Fedora 1.4.X.Y.Z . Besides you are not an 'ignorant', you will always know the real version right? >Upstream maintainer and people > closely following development think of a module as a list of new > features and current bugs, shrinking and growing by time. If Adam > thinks it's fine to include a prerelease of xorg in Fedora, then, well, > it's fine. You (and others here) miss the point, that not everybody is a developer, not everybody monitors the bug list but almost everybody can notice the word 'prerelease' in the F9 release notes and would like a reason why this happened. Take this for example: http://fedoraproject.org/wiki/Features/XserverOnePointFive It mentions that it is a prelease version but it doesn't justify why including a prelease version is ok. > > Just because we called it cairo 1.6.0 didn't make it any better than > 1.5.20. In fact it was worse. We had to release 1.6.2 the day after to > fix a bad bug introduced in 1.6.0, and yes, had to release 1.6.4 on the > same day, to fix a really bad bug introduced in 1.6.2. 1.5.20 on the > other hand, was in release-candidate state for a week with no major > issues reported... > Well that is the problem of the developer not the user. > behdad > From ville.skytta at iki.fi Sun May 11 08:44:40 2008 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sun, 11 May 2008 11:44:40 +0300 Subject: Fedora and JPackage proprietary JDK shims In-Reply-To: <481C0034.7040304@gmail.com> References: <481BECC5.7060203@gmail.com> <481C0034.7040304@gmail.com> Message-ID: <200805111144.40471.ville.skytta@iki.fi> On Saturday 03 May 2008, Les Mikesell wrote: > > Yes the java-sun-compat package is the missing piece. On the subject of java-sun-compat in JPackage, it has been the last package I've maintained there for the last several months. But it has also been quite a while since I've actually used it myself and as always, I don't plan to maintain stuff I don't use in the long term, and I've actually announced my retirement from JPackage a few minutes ago. I gather there are quite a few users of the java-*-sun-compat packages, they're a pretty trivial bunch to maintain, and there hasn't been much interest among active JPackage contributors towards them in the past (no idea if that has changed since). So I'd encourage people who like to see them available and up to date and who have time to help out with them to get in touch with the JPackage folks. > Whether it's > actually included in fedora or not isn't particularly important, but its > location should be documented and there have been long intervals of time > when no jpackage.org support existed for current fedora revisions. java-*-sun-compat should be unaffected by that as they live in the "generic" JPackage repositories. From surenkarapetyan at gmail.com Sun May 11 08:45:12 2008 From: surenkarapetyan at gmail.com (Suren Karapetyan) Date: Sun, 11 May 2008 13:45:12 +0500 Subject: F9 and KVM In-Reply-To: <48262AE1.3050605@verizon.net> References: <1210214432.5112.53.camel@localhost.localdomain> <4c4ba1530805081123l2ab9ccdco577121583369a3ec@mail.gmail.com> <48234707.4000107@verizon.net> <48234808.60907@verizon.net> <1210272164.3807.20.camel@localhost.localdomain> <48235434.3010807@verizon.net> <48236F5C.3090507@verizon.net> <48241107.5070406@gmail.com> <48246AC5.9030506@verizon.net> <482480BC.1000503@gmail.com> <48262AE1.3050605@verizon.net> Message-ID: <4826B218.4020506@gmail.com> Gerry Reno wrote: > I'm looking at VDE now and I have it compiled and running on an old fc6 > box but I have not been able to get it compiled for my f9 box. It > complains about libpcap even though I have it and then it looks as > though it can't find limits.h. > > First it complains about libpcap being too old yet it is the latest > version available: > > Configure results: > > vde_cryptcab : enabled > tuntap support : enabled > pcap support : disabled > configure: WARNING: VDE packet dump plugin has been disabled because > libpcap is > not installed on your system, or because it's too old. > Please install it if you want pdump to be compiled and installed. > experimental features : disabled > > ]$ su - -c "yum list libpcap" > Password: > Loaded plugins: fastestmirror, refresh-packagekit > Loading mirror speeds from cached hostfile > * updates: ftp.ndlug.nd.edu > * adobe-linux-i386: linuxdownload.adobe.com > * fedora: ftp.ndlug.nd.edu > updates | 2.4 kB 00:00 > primary.sqlite.bz2 | 6.1 MB 00:06 > adobe-linux-i386 | 951 B 00:00 > fedora | 2.4 kB 00:00 > primary.sqlite.bz2 | 6.1 MB 00:06 > Installed Packages > libpcap.i386 14:0.9.8-2.fc9 installed > > Next there are some variable issues: > > tcp_subr.c: In function 'tcp_fconnect': > tcp_subr.c:412: warning: unused variable 'opt' > depbase=`echo tcp2unix.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ > gcc -DHAVE_CONFIG_H -I. -I.. -DVDE -g -O2 -O2 -g -pipe -Wall > -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector > --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic > -fasynchronous-unwind-tables -MT tcp2unix.o -MD -MP -MF $depbase.Tpo -c -o > tcp2unix.o tcp2unix.c &&\ > mv -f $depbase.Tpo $depbase.Po > depbase=`echo slirpvde.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ > gcc -DHAVE_CONFIG_H -I. -I.. -DVDE -g -O2 -O2 -g -pipe -Wall > -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector > --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic > -fasynchronous-unwind-tables -MT slirpvde.o -MD -MP -MF $depbase.Tpo -c -o > slirpvde.o slirpvde.c &&\ > mv -f $depbase.Tpo $depbase.Po > bootp.c: In function 'bootp_reply': > bootp.c:267: warning: implicit declaration of function > 'client_eth_register' > slirpvde.c:54: error: '_POSIX_PATH_MAX' undeclared here (not in a function) > > slirpvde.c: In function 'save_pidfile': > slirpvde.c:79: error: 'PATH_MAX' undeclared (first use in this function) > slirpvde.c:79: error: (Each undeclared identifier is reported only once > slirpvde.c:79: error: for each function it appears in.) > slirpvde.c: In function 'main': > slirpvde.c:417: error: 'PATH_MAX' undeclared (first use in this function) > slirpvde.c:372: warning: unused variable 'i' > make[2]: *** [slirpvde.o] Error 1 > > > Regards, > Gerry > You should have libpcap-devel installed :) From surenkarapetyan at gmail.com Sun May 11 09:04:48 2008 From: surenkarapetyan at gmail.com (Suren Karapetyan) Date: Sun, 11 May 2008 14:04:48 +0500 Subject: F9 and KVM In-Reply-To: <482667B3.4090203@verizon.net> References: <1210214432.5112.53.camel@localhost.localdomain> <4c4ba1530805081123l2ab9ccdco577121583369a3ec@mail.gmail.com> <48234707.4000107@verizon.net> <48234808.60907@verizon.net> <1210272164.3807.20.camel@localhost.localdomain> <48235434.3010807@verizon.net> <48236F5C.3090507@verizon.net> <48241107.5070406@gmail.com> <48246AC5.9030506@verizon.net> <482480BC.1000503@gmail.com> <48262AE1.3050605@verizon.net> <482667B3.4090203@verizon.net> Message-ID: <4826B6B0.2040201@gmail.com> Gerry Reno wrote: > Gerry Reno wrote: >> I'm looking at VDE now and I have it compiled and running on an old >> fc6 box but I have not been able to get it compiled for my f9 box. > I was surprised that there was no package for VDE. It looks pretty > useful. Anyway, I'm not getting anywhere trying to get it to compile on > F9. Did something change regarding limits.h? I run the exact same > compile on FC6 and it works. But on F9 it fails. Was some header file > including limits.h before and is not including it now? > > Regards, > Gerry > Not quite sure what broke it, but adding "#include " in src/slirpvde/slirpvde.c solves it for me From surenkarapetyan at gmail.com Sun May 11 09:07:25 2008 From: surenkarapetyan at gmail.com (Suren Karapetyan) Date: Sun, 11 May 2008 14:07:25 +0500 Subject: F9 and KVM In-Reply-To: <482667B3.4090203@verizon.net> References: <1210214432.5112.53.camel@localhost.localdomain> <4c4ba1530805081123l2ab9ccdco577121583369a3ec@mail.gmail.com> <48234707.4000107@verizon.net> <48234808.60907@verizon.net> <1210272164.3807.20.camel@localhost.localdomain> <48235434.3010807@verizon.net> <48236F5C.3090507@verizon.net> <48241107.5070406@gmail.com> <48246AC5.9030506@verizon.net> <482480BC.1000503@gmail.com> <48262AE1.3050605@verizon.net> <482667B3.4090203@verizon.net> Message-ID: <4826B74D.9030803@gmail.com> Gerry Reno wrote: > Gerry Reno wrote: >> I'm looking at VDE now and I have it compiled and running on an old >> fc6 box but I have not been able to get it compiled for my f9 box. > I was surprised that there was no package for VDE. It looks pretty > useful. Anyway, I'm not getting anywhere trying to get it to compile on > F9. Did something change regarding limits.h? I run the exact same > compile on FC6 and it works. But on F9 it fails. Was some header file > including limits.h before and is not including it now? > > Regards, > Gerry > Ooop... Not just there but to every file which fails to compile :) From rawhide at fedoraproject.org Sun May 11 12:11:24 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Sun, 11 May 2008 12:11:24 +0000 (UTC) Subject: rawhide report: 20080511 changes Message-ID: <20080511121124.E0FA1209D0F@releng1.fedora.phx.redhat.com> Updated Packages: (none) Broken deps for ppc64 ---------------------------------------------------------- livecd-tools-017-1.fc9.ppc64 requires yaboot perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot From stlwrt at gmail.com Sun May 11 17:25:16 2008 From: stlwrt at gmail.com (Pavel Shevchuk) Date: Sun, 11 May 2008 20:25:16 +0300 Subject: Dell Laptop In-Reply-To: References: <1210428668.3864.2.camel@scrappy.miketc.com> Message-ID: AMD-based Dells include Broadcom WiFi, which is neverending nightmare. Intel-based Inspirons work out of box On 5/10/08, max bianco wrote: > On Sat, May 10, 2008 at 1:12 PM, Jon Stanley wrote: > > On Sat, May 10, 2008 at 10:11 AM, Mike Chambers wrote: > > > >> http://www.staples.com/office/supplies/p4_Dell-Inspiron-1526-Notebook-PC > >> %27s_220198_Business_Supplies_1_10051_FEATURED:SC3:CG71:DP4118 > > > > Not 100% the right place to talk about this, but looking there, I > > noticed that it had the "Dell Wireless" (read: Broadcom) wifi chipset. > > This will likely give you no end of trouble from what I've seen (note > > that I have no personal experience, just horror stories that I've > > heard). If you go with something with an Intel chipset, it should > > Just Work(TM). > > > > Yes, Dell seems to include the broadcom chipset by default with many > of its offerings. I specifically requested the intel wireless and > haven't had any trouble out of it. Definitely go Intel wireless over > Broadcom. Just my 2 cents. > > > Max > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- http://scwlab.com From email.ahmedkamal at googlemail.com Sun May 11 17:36:34 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Sun, 11 May 2008 20:36:34 +0300 Subject: Dell Laptop In-Reply-To: References: <1210428668.3864.2.camel@scrappy.miketc.com> Message-ID: <3da3b5b40805111036vd11dbd3y9e29e886631f802c@mail.gmail.com> Since we're on the topic, when getting laptops, I can easily identify the "specs" I need. But I am totally lost as to which brand I should be getting! I just have no idea about the quality of Dell vs HP vs Acer ... blah. I end up getting a toshiba, just because my previous one was a toshiba as well! Is there some website/database, that provides statistical data about the reliability and/or performance of similarly spec'ed different brands of laptops? So I can have a good estimation of which brand is the current king On Sun, May 11, 2008 at 8:25 PM, Pavel Shevchuk wrote: > AMD-based Dells include Broadcom WiFi, which is neverending nightmare. > Intel-based Inspirons work out of box > > > On 5/10/08, max bianco wrote: > > On Sat, May 10, 2008 at 1:12 PM, Jon Stanley > wrote: > > > On Sat, May 10, 2008 at 10:11 AM, Mike Chambers > wrote: > > > > > >> > http://www.staples.com/office/supplies/p4_Dell-Inspiron-1526-Notebook-PC > > >> %27s_220198_Business_Supplies_1_10051_FEATURED:SC3:CG71:DP4118 > > > > > > Not 100% the right place to talk about this, but looking there, I > > > noticed that it had the "Dell Wireless" (read: Broadcom) wifi > chipset. > > > This will likely give you no end of trouble from what I've seen > (note > > > that I have no personal experience, just horror stories that I've > > > heard). If you go with something with an Intel chipset, it should > > > Just Work(TM). > > > > > > > Yes, Dell seems to include the broadcom chipset by default with many > > of its offerings. I specifically requested the intel wireless and > > haven't had any trouble out of it. Definitely go Intel wireless over > > Broadcom. Just my 2 cents. > > > > > > Max > > > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > -- > http://scwlab.com > > -- > 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 stlwrt at gmail.com Sun May 11 19:22:02 2008 From: stlwrt at gmail.com (Pavel Shevchuk) Date: Sun, 11 May 2008 22:22:02 +0300 Subject: Dell Laptop In-Reply-To: <3da3b5b40805111036vd11dbd3y9e29e886631f802c@mail.gmail.com> References: <1210428668.3864.2.camel@scrappy.miketc.com> <3da3b5b40805111036vd11dbd3y9e29e886631f802c@mail.gmail.com> Message-ID: Intel-based Dell Inspirons, IBMs Thinkpads (and their legacy under Lenovo brand) and ASUS business series usually work well. AMD lappys in most cases are packed with broadcom WiFi which causes nothing that PITA. On 5/11/08, Ahmed Kamal wrote: > Since we're on the topic, when getting laptops, I can easily identify the > "specs" I need. But I am totally lost as to which brand I should be getting! > I just have no idea about the quality of Dell vs HP vs Acer ... blah. I end > up getting a toshiba, just because my previous one was a toshiba as well! > Is there some website/database, that provides statistical data about the > reliability and/or performance of similarly spec'ed different brands of > laptops? So I can have a good estimation of which brand is the current king > > > On Sun, May 11, 2008 at 8:25 PM, Pavel Shevchuk wrote: > > AMD-based Dells include Broadcom WiFi, which is neverending nightmare. > > Intel-based Inspirons work out of box > > > > > > > > > > > > On 5/10/08, max bianco wrote: > > > On Sat, May 10, 2008 at 1:12 PM, Jon Stanley > wrote: > > > > On Sat, May 10, 2008 at 10:11 AM, Mike Chambers > wrote: > > > > > > > >> > http://www.staples.com/office/supplies/p4_Dell-Inspiron-1526-Notebook-PC > > > >> > %27s_220198_Business_Supplies_1_10051_FEATURED:SC3:CG71:DP4118 > > > > > > > > Not 100% the right place to talk about this, but looking there, I > > > > noticed that it had the "Dell Wireless" (read: Broadcom) wifi > chipset. > > > > This will likely give you no end of trouble from what I've seen > (note > > > > that I have no personal experience, just horror stories that I've > > > > heard). If you go with something with an Intel chipset, it should > > > > Just Work(TM). > > > > > > > > > > Yes, Dell seems to include the broadcom chipset by default with many > > > of its offerings. I specifically requested the intel wireless and > > > haven't had any trouble out of it. Definitely go Intel wireless over > > > Broadcom. Just my 2 cents. > > > > > > > > > Max > > > > > > > > > -- > > > fedora-devel-list mailing list > > > fedora-devel-list at redhat.com > > > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > > > > > -- > > http://scwlab.com > > > > > > > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- http://scwlab.com From angray at beeb.net Sun May 11 19:54:25 2008 From: angray at beeb.net (Aaron Gray) Date: Sun, 11 May 2008 20:54:25 +0100 Subject: Mylex DAC960 and LSI legacy SCSI controllers on Fedora 9 Beta Message-ID: <01f701c8b3a0$d0ffe670$0700a8c0@ze4427wm> The Mylex DAC960 and LSI sym53c8xx SCSI controllers do not seem to be detected at install time on Fedora 9 Beta, where they are on FC6. On FC6 and below text mode boxes display the loading of the two drivers. This does not happen on Fedora 9 Beta. Are legacy SCSI devices no longer supported or do I have a beta bug or local problem ? Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From greno at verizon.net Sun May 11 20:46:09 2008 From: greno at verizon.net (Gerry Reno) Date: Sun, 11 May 2008 16:46:09 -0400 Subject: F9 and KVM In-Reply-To: <4826B6B0.2040201@gmail.com> References: <1210214432.5112.53.camel@localhost.localdomain> <4c4ba1530805081123l2ab9ccdco577121583369a3ec@mail.gmail.com> <48234707.4000107@verizon.net> <48234808.60907@verizon.net> <1210272164.3807.20.camel@localhost.localdomain> <48235434.3010807@verizon.net> <48236F5C.3090507@verizon.net> <48241107.5070406@gmail.com> <48246AC5.9030506@verizon.net> <482480BC.1000503@gmail.com> <48262AE1.3050605@verizon.net> <482667B3.4090203@verizon.net> <4826B6B0.2040201@gmail.com> Message-ID: <48275B11.2060605@verizon.net> Suren Karapetyan wrote: > Gerry Reno wrote: >> Gerry Reno wrote: >>> I'm looking at VDE now and I have it compiled and running on an old >>> fc6 box but I have not been able to get it compiled for my f9 box. >> I was surprised that there was no package for VDE. It looks pretty >> useful. Anyway, I'm not getting anywhere trying to get it to compile >> on F9. Did something change regarding limits.h? I run the exact >> same compile on FC6 and it works. But on F9 it fails. Was some >> header file including limits.h before and is not including it now? >> >> Regards, >> Gerry >> > > Not quite sure what broke it, but adding "#include " in > src/slirpvde/slirpvde.c solves it for me > I was able to get VDE to compile on F9 by adding "#include " to the following files: slirpvde/slirpvde.c wirefilter/wirefilter.c vde_plug2tap/vde_plug2tap.c vde_autolink/vde_autolink.c vdetaplib/libvdetap.c Left a message about this in the VDE forum on sourceforge.net. Regards, Gerry From bpepple at fedoraproject.org Sun May 11 21:15:38 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sun, 11 May 2008 17:15:38 -0400 Subject: [Reminder] FESCo Nominations Message-ID: <1210540538.6813.2.camel@kennedy> Hi, This is a reminder that the nomination period for the upcoming FESCo election is currently underway, and lasts until June 1st, 2008 0:00 UTC. If you wish to run for FESCo, please place your nomination on this page in the wiki: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Nominations For more information regarding the election, please refer to: http://fedoraproject.org/wiki/PackageMaintainers/Policy/FESCoElections Thanks, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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: 197 bytes Desc: This is a digitally signed message part URL: From davej at redhat.com Sun May 11 23:28:11 2008 From: davej at redhat.com (Dave Jones) Date: Sun, 11 May 2008 19:28:11 -0400 Subject: Mylex DAC960 and LSI legacy SCSI controllers on Fedora 9 Beta In-Reply-To: <01f701c8b3a0$d0ffe670$0700a8c0@ze4427wm> References: <01f701c8b3a0$d0ffe670$0700a8c0@ze4427wm> Message-ID: <20080511232811.GA28606@redhat.com> On Sun, May 11, 2008 at 08:54:25PM +0100, Aaron Gray wrote: > The Mylex DAC960 and LSI sym53c8xx SCSI controllers do not seem to be detected at install time on Fedora 9 Beta, where they are on FC6. > > On FC6 and below text mode boxes display the loading of the two drivers. This does not happen on Fedora 9 Beta. > > Are legacy SCSI devices no longer supported or do I have a beta bug or local problem ? Definitely wasn't intentional. Dave -- http://www.codemonkey.org.uk From jspaleta at gmail.com Mon May 12 01:08:38 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 11 May 2008 17:08:38 -0800 Subject: Xorg 1.5 missed the train? In-Reply-To: <4826B04A.8020703@gmail.com> References: <4825F834.1020001@gmail.com> <1210491519.10397.9.camel@behdad.behdad.org> <4826B04A.8020703@gmail.com> Message-ID: <604aa7910805111808t54bfa328yfec68936e0230d4b@mail.gmail.com> On Sun, May 11, 2008 at 12:37 AM, George Billios wrote: > Take this for example: > > http://fedoraproject.org/wiki/Features/XserverOnePointFive > > It mentions that it is a prelease version but it doesn't justify why > including a prelease version is ok. Benefits are detailed on that page. Or you saying the listed details concerning the benefits of including the pre-release of the of 1.5 are not detailed enough for you? And even more importantly this has gone through the Features process and has been reviewed...by FESCO..via a transparent and open review process that requires status updates to be performed. If there was a significant problem with the proposed feature, there have been multiple points in the release process where people could have raised a red flag before the Feature Freeze deadline For reference: http://fedoraproject.org/wiki/Releases/9/FeatureList http://fedoraproject.org/wiki/Features/Policy http://fedoraproject.org/wiki/Releases/9/Schedule We have an open and transparent Feature process, I see no evidence that the process was misused for this particular feature. The decision to change to pre-release was made in the FESCO april 10th meeting as part of the Feature completeness agenda item. Here is the irc log for reference: http://bpepple.fedorapeople.org/fesco/FESCo-2008-04-10.html In the future for Fedora 10, I hope that you will watch the FESCO meeting agenda posts to -devel-list, and will participate in the irc meetings when the Feature process discussion is on the agenda so that any concerns you have can be addressed as part of the discussion. -jef From ivazqueznet at gmail.com Mon May 12 02:31:31 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Sun, 11 May 2008 22:31:31 -0400 Subject: Dell Laptop In-Reply-To: <3da3b5b40805111036vd11dbd3y9e29e886631f802c@mail.gmail.com> References: <1210428668.3864.2.camel@scrappy.miketc.com> <3da3b5b40805111036vd11dbd3y9e29e886631f802c@mail.gmail.com> Message-ID: <1210559491.26278.41.camel@ignacio.lan> On Sun, 2008-05-11 at 20:36 +0300, Ahmed Kamal wrote: > Since we're on the topic, when getting laptops, I can easily identify > the "specs" I need. But I am totally lost as to which brand I should > be getting! I just have no idea about the quality of Dell vs HP vs > Acer ... blah. I end up getting a toshiba, just because my previous > one was a toshiba as well! > Is there some website/database, that provides statistical data about > the reliability and/or performance of similarly spec'ed different > brands of laptops? So I can have a good estimation of which brand is > the current king Personally, my cheapo Acer TM 5720 (Intel-based) was a great deal short of a couple of minor problems (Del key doesn't work with hal info for hotkeys in place, idle brightness behavior is slightly wonky, PSTN modem support is "lacking"). -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jonstanley at gmail.com Mon May 12 02:50:08 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Sun, 11 May 2008 22:50:08 -0400 Subject: Call for savior - ikvm Message-ID: There's a package that failed the mass rebuild for GCC 4.3 due to the fact that it's shipping binary blobs, in violation of the packaging guidelines. The package will not build with the binary blobs removed, therefore it will need to be blocked if the situation cannot be quickly remedied. There is an active upstream and our package is out of date, however, the current upstream tarball also contains binary blobs, however. it's not clear to me not being a mono developer whether those are required or not - there's a lot more in the upstream tarball than ours. It also seems, but is not clear to me again, that the current upstream tarball is in violation of http://fedoraproject.org/wiki/Packaging/Mono#head-6635c736011474fcbbc900285de0d9b0977cde1b as well. Any takers? -- Jon Stanley Fedora Bug Wrangler jstanley at fedoraproject.org From greno at verizon.net Mon May 12 02:53:33 2008 From: greno at verizon.net (Gerry Reno) Date: Sun, 11 May 2008 22:53:33 -0400 Subject: F9 and KVM In-Reply-To: <48275B11.2060605@verizon.net> References: <1210214432.5112.53.camel@localhost.localdomain> <4c4ba1530805081123l2ab9ccdco577121583369a3ec@mail.gmail.com> <48234707.4000107@verizon.net> <48234808.60907@verizon.net> <1210272164.3807.20.camel@localhost.localdomain> <48235434.3010807@verizon.net> <48236F5C.3090507@verizon.net> <48241107.5070406@gmail.com> <48246AC5.9030506@verizon.net> <482480BC.1000503@gmail.com> <48262AE1.3050605@verizon.net> <482667B3.4090203@verizon.net> <4826B6B0.2040201@gmail.com> <48275B11.2060605@verizon.net> Message-ID: <4827B12D.6000207@verizon.net> I have my VM's running under KVM and I am following a wiki page at linux-kvm for hotplugging pci devices. I need to put the commands in the monitor console but I have typed Ctrl-Alt and still I cannot find the monitor console. It is supposed to be on Ctrl-Alt-2 but that is where the serial console is located. Can someone give me a pointer as to how you get to the monitor console in KVM? Regards, Gerry From cjdahlin at ncsu.edu Mon May 12 04:20:50 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Mon, 12 May 2008 00:20:50 -0400 Subject: F9 and KVM In-Reply-To: <4826B6B0.2040201@gmail.com> References: <1210214432.5112.53.camel@localhost.localdomain> <4c4ba1530805081123l2ab9ccdco577121583369a3ec@mail.gmail.com> <48234707.4000107@verizon.net> <48234808.60907@verizon.net> <1210272164.3807.20.camel@localhost.localdomain> <48235434.3010807@verizon.net> <48236F5C.3090507@verizon.net> <48241107.5070406@gmail.com> <48246AC5.9030506@verizon.net> <482480BC.1000503@gmail.com> <48262AE1.3050605@verizon.net> <482667B3.4090203@verizon.net> <4826B6B0.2040201@gmail.com> Message-ID: <4827C5A2.3080406@ncsu.edu> Suren Karapetyan wrote: > Gerry Reno wrote: >> Gerry Reno wrote: >>> I'm looking at VDE now and I have it compiled and running on an old >>> fc6 box but I have not been able to get it compiled for my f9 box. >> I was surprised that there was no package for VDE. It looks pretty >> useful. Anyway, I'm not getting anywhere trying to get it to compile >> on F9. Did something change regarding limits.h? I run the exact >> same compile on FC6 and it works. But on F9 it fails. Was some >> header file including limits.h before and is not including it now? >> >> Regards, >> Gerry >> > > Not quite sure what broke it, but adding "#include " in > src/slirpvde/slirpvde.c solves it for me > Probably something to do with the wave of gcc43 incompatibilities that have hit hundreds of less-than-standards-prudent codebases. --CJD From cjdahlin at ncsu.edu Mon May 12 04:59:09 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Mon, 12 May 2008 00:59:09 -0400 Subject: JahShaka Message-ID: <4827CE9D.5020409@ncsu.edu> I'd been hoping there was good video editing software for linux, and it looks like this may be it: http://jahshaka.org/ Before I go through the review process: - Has anyone tried to package it? Why didn't you? - Is there any obvious reason anyone knows of now that it could not be packaged? --CJD From nicu_fedora at nicubunu.ro Mon May 12 07:26:09 2008 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Mon, 12 May 2008 10:26:09 +0300 Subject: JahShaka In-Reply-To: <4827CE9D.5020409@ncsu.edu> References: <4827CE9D.5020409@ncsu.edu> Message-ID: <4827F111.1070604@nicubunu.ro> Casey Dahlin wrote: > I'd been hoping there was good video editing software for linux, and it > looks like this may be it: > > http://jahshaka.org/ > > Before I go through the review process: > > - Has anyone tried to package it? Why didn't you? > - Is there any obvious reason anyone knows of now that it could not be > packaged? At a first glance at their website is not clear to me: what video/audio codecs are they using? Can the application be built with multimedia codecs we are legally allowed to include into Fedora? (that means OGG Theora/Vorbis but *not* libavcodec). -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From paul at all-the-johnsons.co.uk Mon May 12 07:53:58 2008 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Mon, 12 May 2008 08:53:58 +0100 Subject: Call for savior - ikvm In-Reply-To: References: Message-ID: <20080512075124.M17539@all-the-johnsons.co.uk> Hi, > It also seems, but is not clear to me again, that the current > upstream tarball is in violation of > http://fedoraproject.org/wiki/Packaging/Mono#head-6635c736011474fcbbc900285de0d9b0977cde1b > as well. I've tried, on many occassions to get ikvm to build using gcj et al, but it always fails. I have some time today and will try again. If it works, I'll get it into rawhide ASAP. Over the upstream violations, we've seen this happen with monodevelop and a few other packages within the mono framework and it's not really a show stopper as they can be usually removed. TTFN Paul -- Programmer, GirlGamer www.girlgamer.com From pertusus at free.fr Mon May 12 07:57:12 2008 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 12 May 2008 09:57:12 +0200 Subject: old redhat rpms list/mirrors Message-ID: <20080512075712.GA2582@free.fr> Hello, To have proper versionned obsolete while allowing for upgrade paths from very old redhat distro, sometime I need the list of the packages in pre-fedora era, to find the latest version. I have browsed through the net, but haven't found that (or a mirror still mirroring old releases). Are you aware of such resource? Ideally it would date back to redhat 5, I don't think older releases are worth it. This is not only a theoretical issue, since having obsoletes for old fedora/redhat releases may help for upgrades from RHEL versions to fedora (I know it is not supported, but it would help packagers trying to have it work). -- Pat From mike at cchtml.com Mon May 12 08:06:41 2008 From: mike at cchtml.com (Mike Cronenworth) Date: Mon, 12 May 2008 03:06:41 -0500 Subject: JahShaka In-Reply-To: <4827F111.1070604@nicubunu.ro> References: <4827CE9D.5020409@ncsu.edu> <4827F111.1070604@nicubunu.ro> Message-ID: <4827FA91.9060009@cchtml.com> -------- Original Message -------- Subject: Re:JahShaka From: Nicu Buculei To: Development discussions related to Fedora Date: 05/12/2008 02:26 AM > Casey Dahlin wrote: >> I'd been hoping there was good video editing software for linux, and >> it looks like this may be it: >> >> http://jahshaka.org/ >> >> Before I go through the review process: >> >> - Has anyone tried to package it? Why didn't you? >> - Is there any obvious reason anyone knows of now that it could not >> be packaged? > > At a first glance at their website is not clear to me: what > video/audio codecs are they using? > Can the application be built with multimedia codecs we are legally > allowed to include into Fedora? (that means OGG Theora/Vorbis but > *not* libavcodec). > Jahsaka 0.2 (current stable) requires FFMPEG Jahsaka 0.3 (early development) OpenLibraries. includes MPEG/WMA stuff. All around looks bad. A video editor would have to use gstreamer to get into Fedora. Example: http://www.pitivi.org/wiki/Main_Page From wolfy at nobugconsulting.ro Mon May 12 08:09:54 2008 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Mon, 12 May 2008 11:09:54 +0300 Subject: old redhat rpms list/mirrors In-Reply-To: <20080512075712.GA2582@free.fr> References: <20080512075712.GA2582@free.fr> Message-ID: <4827FB52.4040307@nobugconsulting.ro> Patrice Dumas wrote: > Hello, > > To have proper versionned obsolete while allowing for upgrade paths from > very old redhat distro, sometime I need the list of the packages in > pre-fedora era, to find the latest version. I have browsed through the > net, but haven't found that (or a mirror still mirroring old releases). > Are you aware of such resource? Ideally it would date back to redhat 5, > I don't think older releases are worth it. > > This is not only a theoretical issue, since having obsoletes for old > fedora/redhat releases may help for upgrades from RHEL versions to > fedora (I know it is not supported, but it would help packagers trying > to have it work). > > -- > Pat > > Theoretically, they should be available at ftp://archive.download.redhat.com/pub/redhat/linux/ From pertusus at free.fr Mon May 12 08:16:32 2008 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 12 May 2008 10:16:32 +0200 Subject: old redhat rpms list/mirrors In-Reply-To: <4827FB52.4040307@nobugconsulting.ro> References: <20080512075712.GA2582@free.fr> <4827FB52.4040307@nobugconsulting.ro> Message-ID: <20080512081632.GB2582@free.fr> On Mon, May 12, 2008 at 11:09:54AM +0300, Manuel Wolfshant wrote: > > Theoretically, they should be available at > ftp://archive.download.redhat.com/pub/redhat/linux/ It looks empty. -- Pat From wolfy at nobugconsulting.ro Mon May 12 08:25:47 2008 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Mon, 12 May 2008 11:25:47 +0300 Subject: old redhat rpms list/mirrors In-Reply-To: <20080512081632.GB2582@free.fr> References: <20080512075712.GA2582@free.fr> <4827FB52.4040307@nobugconsulting.ro> <20080512081632.GB2582@free.fr> Message-ID: <4827FF0B.8050803@nobugconsulting.ro> Patrice Dumas wrote: > On Mon, May 12, 2008 at 11:09:54AM +0300, Manuel Wolfshant wrote: > >> Theoretically, they should be available at >> ftp://archive.download.redhat.com/pub/redhat/linux/ >> > > It looks empty. > > -- > Pat > > lftp archive.download.redhat.com:/pub/redhat/linux/5.0/en> ls os/i386 -rw-r--r-- 2 ftp ftp 19686 May 28 1997 COPYING -rw-r--r-- 1 ftp ftp 3020 Nov 10 1997 README -rw-r--r-- 2 ftp ftp 2751 Sep 19 1997 RPM-PGP-KEY drwxr-xr-x 5 ftp ftp 4096 Jul 13 2002 RedHat drwxr-xr-x 2 ftp ftp 20480 Jul 13 2002 SRPMS drwxr-xr-x 5 ftp ftp 4096 Jul 15 2002 doc drwxr-xr-x 4 ftp ftp 4096 Jul 15 2002 dosutils drwxr-xr-x 2 ftp ftp 4096 Jul 13 2002 images drwxr-xr-x 4 ftp ftp 4096 Jul 13 2002 misc in other words, works for me... From gnomeuser at gmail.com Mon May 12 08:45:03 2008 From: gnomeuser at gmail.com (David Nielsen) Date: Mon, 12 May 2008 10:45:03 +0200 Subject: Call for savior - ikvm In-Reply-To: <20080512075124.M17539@all-the-johnsons.co.uk> References: <20080512075124.M17539@all-the-johnsons.co.uk> Message-ID: <1dedbbfc0805120145k2a8d2dfas280920ed651afe97@mail.gmail.com> 2008/5/12 Paul F. Johnson : > Hi, > > > It also seems, but is not clear to me again, that the current > > upstream tarball is in violation of > > > > http://fedoraproject.org/wiki/Packaging/Mono#head-6635c736011474fcbbc900285de0d9b0977cde1b > > as well. > > I've tried, on many occassions to get ikvm to build using gcj et al, but > it > always fails. I have some time today and will try again. If it works, I'll > get > it into rawhide ASAP. > > Over the upstream violations, we've seen this happen with monodevelop and > a > few other packages within the mono framework and it's not really a show > stopper as they can be usually removed. Have you filed a bug with upstream on the issue, normally they are responsive to such issues when they understand the implications. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at all-the-johnsons.co.uk Mon May 12 09:17:05 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Mon, 12 May 2008 10:17:05 +0100 Subject: Getting ikvm back into rawhide correctly Message-ID: <1210583825.25428.5.camel@T7.Linux> Hi, I'm part way there with a little bit of force! There seems to be two main problems, one is a show stopper, the other a pain which can be worked around. The showstopper is that the build script requires javac. I can fix that if I knew what the java byte compiler that is shipped with Fedora is. I know we have gcj and the open sourced java compiler, but I'm not sure if they ship with javac (or an implementation thereof). The second which can be worked around is that ikvm ships with prebuilt binaries bits. Okay, not a biggie, as the documentation says that it doesn't need it, but refers to it, so I just need to put the class library into a Requires field and that should do it. Any help on these would be appreciated. TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From pertusus at free.fr Mon May 12 09:27:15 2008 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 12 May 2008 11:27:15 +0200 Subject: Getting ikvm back into rawhide correctly In-Reply-To: <1210583825.25428.5.camel@T7.Linux> References: <1210583825.25428.5.camel@T7.Linux> Message-ID: <20080512092715.GA2617@free.fr> On Mon, May 12, 2008 at 10:17:05AM +0100, Paul wrote: > Hi, > > I'm part way there with a little bit of force! There seems to be two > main problems, one is a show stopper, the other a pain which can be > worked around. > > The showstopper is that the build script requires javac. I can fix that > if I knew what the java byte compiler that is shipped with Fedora is. I > know we have gcj and the open sourced java compiler, but I'm not sure if > they ship with javac (or an implementation thereof). If you don't care which javac is used, and if I remember well, you can have BuildRequires: java-devel The java packages use the alternative system to provide both javac and other commands. -- Pat From paul at all-the-johnsons.co.uk Mon May 12 09:47:23 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Mon, 12 May 2008 10:47:23 +0100 Subject: Getting ikvm back into rawhide correctly In-Reply-To: <20080512092715.GA2617@free.fr> References: <1210583825.25428.5.camel@T7.Linux> <20080512092715.GA2617@free.fr> Message-ID: <1210585643.25428.6.camel@T7.Linux> Hi, > > The showstopper is that the build script requires javac. I can fix that > > if I knew what the java byte compiler that is shipped with Fedora is. I > > know we have gcj and the open sourced java compiler, but I'm not sure if > > they ship with javac (or an implementation thereof). > > If you don't care which javac is used, and if I remember well, you can > have > BuildRequires: java-devel > The java packages use the alternative system to provide both javac and > other commands. Given the workaround is not to build the classpath stuff, just have it as Requires, the need for javac goes! Now to work out what goes where! TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From dhollis at davehollis.com Mon May 12 11:30:48 2008 From: dhollis at davehollis.com (David Hollis) Date: Mon, 12 May 2008 07:30:48 -0400 Subject: Realtek RTL8187B In-Reply-To: <1210486654.5317.4.camel@scrappy.miketc.com> References: <1210486654.5317.4.camel@scrappy.miketc.com> Message-ID: <1210591848.3494.10.camel@dhollis-lnx> On Sun, 2008-05-11 at 01:17 -0500, Mike Chambers wrote: > Have installed F9 (er, well, rawhide anyway as of today) is why asking > on this list. > > This wireless driver is in my laptop that I bought from Best Buy, which > is a Gateway laptop. I thought Realtek drivers were opensourced? Or at > least I guess maybe only wired drivers are? I can't seem to get the > laptop to recognize the wireless driver. It's connected in there > somehow via usb, which lsusb does show the driver. > > Do I have to use ndiswrapper to make this work or should it work out of > the box? If out of the box, what steps to get it to load and be > recognized? Unfortunately, this device isn't supported by current kernels. I just purchased a couple of these off NewEgg for $15 because the device was listed as well supported by the zd1211rw driver but it turns out that the manufacturer has changed the chip used which is now the RTL8187B, and alas, unsupported. The rtl8187 driver currently in the kernel has a decent portion of the bits to support the device but not all of them. I managed to add the proper device IDs, it detects the device but is unable to bring up the PHYs since there are apparently a number of changes from the RTL8187 chip and the RTL8187B chip. I would suspect that support ought to land in-kernel in the next few months so either a later F9 kernel update or F10 should bring in full support. Until then, you are sadly stuck with ndiswrapper. Oh, there is a hacked-up driver available to seems to work for some folks, I can't remember the URL off-hand. Apparently, it may work but doesn't seem to support encryption well, or a bunch of quirky things. From rc040203 at freenet.de Mon May 12 06:14:48 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 12 May 2008 08:14:48 +0200 Subject: FC10: strange cmake error Message-ID: <1210572888.26792.913.camel@beck.corsepiu.local> Hi, I am facing a strange cmake-related error when trying to upgrade OpenSceneGraph to version 2.4.0 on FC10: ... -- Looking for pthread_yield CMake Error at CMakeLists.txt:9 (ADD_EXECUTABLE): Target "cmTryCompileExec" links to item " -lpthread" which has leading or trailing whitespace. This is now an error according to policy CMP0004. ... Full logs: http://koji.fedoraproject.org/koji/getfile?taskID=604094&name=build.log http://koji.fedoraproject.org/koji/getfile?taskID=604094&name=root.log http://koji.fedoraproject.org/koji/getfile?taskID=604094&name=state.log Local mock-building the srpm for fc8 and fc9 works without problems, which makes me think something in cmake-2.6.0 on FC10 is broken. Any ideas? Ralf From rawhide at fedoraproject.org Mon May 12 12:07:11 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Mon, 12 May 2008 12:07:11 +0000 (UTC) Subject: rawhide report: 20080512 changes Message-ID: <20080512120711.B20E0209D16@releng1.fedora.phx.redhat.com> Updated Packages: (none) Broken deps for ppc64 ---------------------------------------------------------- livecd-tools-017-1.fc9.ppc64 requires yaboot perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot From giallu at gmail.com Mon May 12 12:15:17 2008 From: giallu at gmail.com (Gianluca Sforna) Date: Mon, 12 May 2008 14:15:17 +0200 Subject: FC10: strange cmake error In-Reply-To: <1210572888.26792.913.camel@beck.corsepiu.local> References: <1210572888.26792.913.camel@beck.corsepiu.local> Message-ID: On Mon, May 12, 2008 at 8:14 AM, Ralf Corsepius wrote: > -- Looking for pthread_yield > CMake Error at CMakeLists.txt:9 (ADD_EXECUTABLE): > Target "cmTryCompileExec" links to item " -lpthread" which has leading > or > trailing whitespace. This is now an error according to policy > CMP0004. It seems related to: http://www.cmake.org/pipermail/cmake-commits/2008-March/003605.html so you probably just need to find out where in OSG cmakefiles " -lpthread" was added that leading whitespace and get rid of it. From kevin.kofler at chello.at Mon May 12 12:16:53 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 12 May 2008 12:16:53 +0000 (UTC) Subject: FC10: strange cmake error References: <1210572888.26792.913.camel@beck.corsepiu.local> Message-ID: Ralf Corsepius freenet.de> writes: > I am facing a strange cmake-related error when trying to upgrade > OpenSceneGraph to version 2.4.0 on FC10: That's cmake 2.6.0 being stricter than 2.4.x. The solutions probably include either locating and removing the offending extra space or turning that policy off. If you can't figure it out, I can help you fix this (having accumulated cmake experience from comaintaining KDE 4 ;-) ). Kevin Kofler From rc040203 at freenet.de Mon May 12 12:38:49 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 12 May 2008 14:38:49 +0200 Subject: FC10: strange cmake error In-Reply-To: References: <1210572888.26792.913.camel@beck.corsepiu.local> Message-ID: <1210595929.26792.921.camel@beck.corsepiu.local> On Mon, 2008-05-12 at 12:16 +0000, Kevin Kofler wrote: > Ralf Corsepius freenet.de> writes: > > I am facing a strange cmake-related error when trying to upgrade > > OpenSceneGraph to version 2.4.0 on FC10: > > That's cmake 2.6.0 being stricter than 2.4.x. > > The solutions probably include either locating and removing the offending extra > space or turning that policy off. > > If you can't figure it out, I can help you fix this (having accumulated cmake > experience from comaintaining KDE 4 ;-) ). Please do so, ... I can't spot any offending extra space related to pthread in the entire source tree: # find \( -name 'CMake*' -o -name '*.cmake' \) -exec grep -H pthread {} \; ./CMakeLists.txt:# library is not necessary. We currently don't case for pthreads on Windows ./src/OpenThreads/CMakeLists.txt: OPTION(OPENTHREADS_USE_SPROC_INSTEAD_OF_PTHREADS "Set to ON to build OpenThreads against sproc instead of pthreads" OFF) ./src/OpenThreads/CMakeLists.txt: # So I think Cygwin wants to use pthreads ./src/OpenThreads/CMakeLists.txt: SUBDIRS(pthreads) ./src/OpenThreads/CMakeLists.txt: SUBDIRS(pthreads) ./src/OpenThreads/pthreads/CMakeLists.txt:CHECK_FUNCTION_EXISTS(pthread_yield HAVE_PTHREAD_YIELD) ./src/OpenThreads/pthreads/CMakeLists.txt: # sched_yield appears not in libc, pthreads or whatever on some systems ./src/OpenThreads/pthreads/CMakeLists.txt: # need to have that for pthread_setaffinity_np on linux ./src/OpenThreads/pthreads/CMakeLists.txt:CHECK_FUNCTION_EXISTS(pthread_setconcurrency HAVE_PTHREAD_SETCONCURRENCY) ./src/OpenThreads/pthreads/CMakeLists.txt:CHECK_FUNCTION_EXISTS(pthread_getconcurrency HAVE_PTHREAD_GETCONCURRENCY) ./src/OpenThreads/pthreads/CMakeLists.txt:CHECK_FUNCTION_EXISTS(pthread_setaffinity_np HAVE_PTHREAD_SETAFFINITY_NP) Sources can be found in Fedora's CVS (OpenSceneGraph/devel). Ralf From paul at all-the-johnsons.co.uk Mon May 12 12:47:53 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Mon, 12 May 2008 13:47:53 +0100 Subject: ikvm and gnu classpath Message-ID: <1210596473.25428.33.camel@T7.Linux> Hi, Looking more into the problems in getting ikvm to build from source and it looks like it won't be as simple as I thought as it does need to build against the sources of gnu-classpath (which is a pain to be honest!) to build it's main application. Is there a problem with a spec file pulling in the sources from another tarball, decompressing, moving the required files across and then building correctly? TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mike at miketc.com Mon May 12 13:04:58 2008 From: mike at miketc.com (Mike Chambers) Date: Mon, 12 May 2008 08:04:58 -0500 Subject: Realtek RTL8187B In-Reply-To: <1210591848.3494.10.camel@dhollis-lnx> References: <1210486654.5317.4.camel@scrappy.miketc.com> <1210591848.3494.10.camel@dhollis-lnx> Message-ID: <1210597498.3271.6.camel@scrappy.miketc.com> On Mon, 2008-05-12 at 07:30 -0400, David Hollis wrote: > Oh, there is a hacked-up driver available to seems to work for some > folks, I can't remember the URL off-hand. Apparently, it may work but > doesn't seem to support encryption well, or a bunch of quirky things. atrpms has that driver packaged to rpm and have it installed so I don't have to use ndiswrapper. It has worked, but very seldom and hardly connects, for whatever reason. It seems that it's like it won't keep the key you put in, memorized or whatever, I don't know. Bout ready to go back to windows on it until better supported. -- Mike Chambers Fedora Project - Ambassador, Bug Zapper, Tester, User, etc.. mikec302 at fedoraproject.org From cjdahlin at ncsu.edu Mon May 12 13:10:04 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Mon, 12 May 2008 09:10:04 -0400 Subject: JahShaka In-Reply-To: <4827FA91.9060009@cchtml.com> References: <4827CE9D.5020409@ncsu.edu> <4827F111.1070604@nicubunu.ro> <4827FA91.9060009@cchtml.com> Message-ID: <482841AC.8060705@ncsu.edu> Mike Cronenworth wrote: > -------- Original Message -------- > Subject: Re:JahShaka > From: Nicu Buculei > To: Development discussions related to Fedora > > Date: 05/12/2008 02:26 AM >> Casey Dahlin wrote: >>> I'd been hoping there was good video editing software for linux, and >>> it looks like this may be it: >>> >>> http://jahshaka.org/ >>> >>> Before I go through the review process: >>> >>> - Has anyone tried to package it? Why didn't you? >>> - Is there any obvious reason anyone knows of now that it could not >>> be packaged? >> >> At a first glance at their website is not clear to me: what >> video/audio codecs are they using? >> Can the application be built with multimedia codecs we are legally >> allowed to include into Fedora? (that means OGG Theora/Vorbis but >> *not* libavcodec). >> > Jahsaka 0.2 (current stable) requires FFMPEG > Jahsaka 0.3 (early development) OpenLibraries. includes MPEG/WMA stuff. > > All around looks bad. A video editor would have to use gstreamer to > get into Fedora. > > Example: > http://www.pitivi.org/wiki/Main_Page > Why would it have to be GStreamer? Wouldn't anything un-patent-encumbered do? (Not that this isn't un-patent-encumbered, but in the general case). --CJD From mclasen at redhat.com Mon May 12 13:12:10 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 12 May 2008 09:12:10 -0400 Subject: JahShaka In-Reply-To: <482841AC.8060705@ncsu.edu> References: <4827CE9D.5020409@ncsu.edu> <4827F111.1070604@nicubunu.ro> <4827FA91.9060009@cchtml.com> <482841AC.8060705@ncsu.edu> Message-ID: <1210597930.4648.3.camel@localhost.localdomain> On Mon, 2008-05-12 at 09:10 -0400, Casey Dahlin wrote: > > > Why would it have to be GStreamer? Wouldn't anything > un-patent-encumbered do? (Not that this isn't un-patent-encumbered, but > in the general case). It wouldn't have to be gstreamer. From sundaram at fedoraproject.org Mon May 12 13:21:55 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 12 May 2008 18:51:55 +0530 Subject: JahShaka In-Reply-To: <482841AC.8060705@ncsu.edu> References: <4827CE9D.5020409@ncsu.edu> <4827F111.1070604@nicubunu.ro> <4827FA91.9060009@cchtml.com> <482841AC.8060705@ncsu.edu> Message-ID: <48284473.2070701@fedoraproject.org> Casey Dahlin wrote: > Why would it have to be GStreamer? Wouldn't anything > un-patent-encumbered do? (Not that this isn't un-patent-encumbered, but > in the general case). It doesn't have to be gstreamer. We have both gstreamer and xine (the free parts) in Fedora but gstreamer does make it easy to add support back for the other codecs that we don't include. Rahul From mike at cchtml.com Mon May 12 13:25:11 2008 From: mike at cchtml.com (Mike Cronenworth) Date: Mon, 12 May 2008 08:25:11 -0500 Subject: JahShaka In-Reply-To: <48284473.2070701@fedoraproject.org> References: <4827CE9D.5020409@ncsu.edu> <4827F111.1070604@nicubunu.ro> <4827FA91.9060009@cchtml.com> <482841AC.8060705@ncsu.edu> <48284473.2070701@fedoraproject.org> Message-ID: <48284537.3020008@cchtml.com> -------- Original Message -------- Subject: Re: JahShaka From: Rahul Sundaram To: Development discussions related to Fedora Cc: mike at cchtml.com Date: 05/12/2008 08:21 AM > Casey Dahlin wrote: > >> Why would it have to be GStreamer? Wouldn't anything >> un-patent-encumbered do? (Not that this isn't un-patent-encumbered, >> but in the general case). > > It doesn't have to be gstreamer. We have both gstreamer and xine (the > free parts) in Fedora but gstreamer does make it easy to add support > back for the other codecs that we don't include. > > Rahul That's the point I was trying to make. Most people who would want to use a video editor for "realistic work" wouldn't find much value in an Ogg-only output format. They'd expect to be able to output in MPEG-2, MPEG-4, or h.264 to display on their televisions and/or share with customers or friends through the Internet. Sure, you could output into a non-patent encumbered format and then re-encode the video, but that's a two step process. Not very user friendly; plus if it is a lossy codec it's a degrading process. From stickster at gmail.com Mon May 12 13:28:53 2008 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 12 May 2008 13:28:53 +0000 Subject: Ekiga + opal rebuild? Message-ID: <1210598933.2508.62.camel@victoria> So this very nasty Ekiga bug in at least the F-9 branch: https://bugzilla.redhat.com/show_bug.cgi?id=441202 ...can be fixed by rebuilding opal followed by ekiga (which depends on opal-devel). I've tested and confirmed that fix locally. Brian Pepple and others tell me that it's OK to help out by rebuilding these, and also that the chain building process that works in the devel branch doesn't work in the F-9 branch. I'm going to take care of that this morning, in the hopes we can have a working Ekiga for a zero-day update to Fedora 9. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From cjdahlin at ncsu.edu Mon May 12 13:47:07 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Mon, 12 May 2008 09:47:07 -0400 Subject: Fedora and JPackage proprietary JDK shims In-Reply-To: <481C0034.7040304@gmail.com> References: <481BAB77.30302@gmail.com> <1209780338.22699.10.camel@valkyrie.localdomain> <481BECC5.7060203@gmail.com> <481C0034.7040304@gmail.com> Message-ID: <48284A5B.8000401@ncsu.edu> Les Mikesell wrote: > Toshio Kuratomi wrote: >> Colin Walters wrote: >>> On Fri, May 2, 2008 at 10:05 PM, Matthew Saltzman >>> wrote: >>>> Not sure, but I bet the "shim" is the java-sun-compat package that >>>> lets >>>> you install the Sun RPM, then sets up alternatives and other >>>> symlinks to >>>> make the expected incantations work. That is not a nosrc package, >>>> though it may have no actual source. It depends on the Sun RPM from >>>> java.sun.com. >>> >>> Yeah, that's what was under discussion, or at least it's what I >>> thought Les wanted. >>> >> I know Les mentioned the nosrc rpms in the same email as he >> complained that Fedora wasn't shipping something that he felt was >> necessary for java-on-Fedora. So I thought it best to have that >> clarified. > > Yes the java-sun-compat package is the missing piece. Whether it's > actually included in fedora or not isn't particularly important, but > its location should be documented and there have been long intervals > of time when no jpackage.org support existed for current fedora > revisions. My impression was that this was intentional on fedora's > part but perhaps that was mistaken. > I think we need to re-gage this after we're a bit into F9 general availability. The open source alternatives to Java have gotten much, much better this go round, and many of the early adopters I've talked to have said their java issues have gone completely away. We need to figure out what role proprietary java will now play in the lives of our users. --CJD From paul at all-the-johnsons.co.uk Mon May 12 13:53:34 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Mon, 12 May 2008 14:53:34 +0100 Subject: ikvm and prepackaged libs Message-ID: <1210600414.21971.4.camel@T7.Linux> Hi, Getting ikvm to build is proving to be a hideous problem. 1. classpath needs to be rebuilt 2. ecj needs to be built with ikvm The only reason for this is that there is one dll required which is prebuilt. Given the amount of problems this one dll will cause, can ikvm be given special consideration and be allowed the dll? It is not causing problems on my x86 or x86_64 boxes. TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From aph at redhat.com Mon May 12 13:57:22 2008 From: aph at redhat.com (Andrew Haley) Date: Mon, 12 May 2008 14:57:22 +0100 Subject: ikvm and prepackaged libs In-Reply-To: <1210600414.21971.4.camel@T7.Linux> References: <1210600414.21971.4.camel@T7.Linux> Message-ID: <48284CC2.3020703@redhat.com> Paul wrote: > Hi, > > Getting ikvm to build is proving to be a hideous problem. > > 1. classpath needs to be rebuilt I don't get it. Building classpath requires java-devel, which is a standard part of Fedora. > 2. ecj needs to be built with ikvm Err, why? ecj is also a standard prt of Fedora. Andrew. From angray at beeb.net Mon May 12 14:15:37 2008 From: angray at beeb.net (Aaron Gray) Date: Mon, 12 May 2008 15:15:37 +0100 Subject: Mylex DAC960 and LSI legacy SCSI controllers on Fedora 9 Beta References: <01f701c8b3a0$d0ffe670$0700a8c0@ze4427wm> <20080511232811.GA28606@redhat.com> Message-ID: <02b501c8b43a$a72bfd80$0700a8c0@ze4427wm> > On Sun, May 11, 2008 at 08:54:25PM +0100, Aaron Gray wrote: > > The Mylex DAC960 and LSI sym53c8xx SCSI controllers do not seem to be > > detected at install time on Fedora 9 Beta, where they are on FC6. > > > > On FC6 and below text mode boxes display the loading of the two drivers. > > This does not happen on Fedora 9 Beta. > > > > Are legacy SCSI devices no longer supported or do I have a beta bug or > > local problem ? > > Definitely wasn't intentional. Thanks Dave, I will try again once back on site, also I will try FC 7 & 8. Cheers, Aaron From dpierce at redhat.com Mon May 12 14:17:36 2008 From: dpierce at redhat.com (Darryl L. Pierce) Date: Mon, 12 May 2008 10:17:36 -0400 Subject: Unable to check out one of my packages... Message-ID: <48285180.6030101@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 When I try to checkout one of my packages (rubygem-activeldap), I'm getting: [mcpierce at mcpierce-laptop rubygem-hoe]$ fedora-cvs rubygem-activeldap Checking out rubygem-activeldap from fedora cvs: Error: cvs server: cannot find module `rubygem-activeldap' - ignored cvs [checkout aborted]: cannot expand modules My other packages are fine. Who do I contact to fix this? - -- Darryl L. Pierce - Phone: (919) 754-4383 "In matters of style, swim with the current; In matters of principle, stand like a rock." - Thomas Jefferson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFIKFGAjaT4DmxOfxsRArYTAKDVWv97/ZauRQZNCH+yO8jCTQ0cewCdELLM R+qgaQI2iiSeMt7Mxfrt4qQ= =PtSB -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: dpierce.vcf Type: text/x-vcard Size: 265 bytes Desc: not available URL: From paul at all-the-johnsons.co.uk Mon May 12 14:36:50 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Mon, 12 May 2008 15:36:50 +0100 Subject: ikvm and prepackaged libs In-Reply-To: <48284CC2.3020703@redhat.com> References: <1210600414.21971.4.camel@T7.Linux> <48284CC2.3020703@redhat.com> Message-ID: <1210603010.21971.7.camel@T7.Linux> Hi, > > Getting ikvm to build is proving to be a hideous problem. > > > > 1. classpath needs to be rebuilt > > > I don't get it. Building classpath requires java-devel, which is a > standard part of Fedora. Yep - I know that. ikvm builds classpath for itself. That really isn't a problem, the tarball can be extracted within the ikvm directories and the script fiddled with. It does add almost 10Mb to the src.rpm size > > 2. ecj needs to be built with ikvm > > Err, why? ecj is also a standard prt of Fedora. To build part of ikvm, ecj is rebuilt by ikvm which means another package being brought in to build a 80k dll! TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From aph at redhat.com Mon May 12 14:38:18 2008 From: aph at redhat.com (Andrew Haley) Date: Mon, 12 May 2008 15:38:18 +0100 Subject: ikvm and prepackaged libs In-Reply-To: <1210603010.21971.7.camel@T7.Linux> References: <1210600414.21971.4.camel@T7.Linux> <48284CC2.3020703@redhat.com> <1210603010.21971.7.camel@T7.Linux> Message-ID: <4828565A.3070806@redhat.com> Paul wrote: > Hi, > >>> Getting ikvm to build is proving to be a hideous problem. >>> >>> 1. classpath needs to be rebuilt >> >> I don't get it. Building classpath requires java-devel, which is a >> standard part of Fedora. > > Yep - I know that. ikvm builds classpath for itself. That really isn't a > problem, the tarball can be extracted within the ikvm directories and > the script fiddled with. It does add almost 10Mb to the src.rpm size Ok. >>> 2. ecj needs to be built with ikvm >> Err, why? ecj is also a standard prt of Fedora. > > To build part of ikvm, ecj is rebuilt by ikvm which means another > package being brought in to build a 80k dll! OK, so what are you complaining about? What is this hideous problem? Doesn't seem there is any problem at all. Andrew. From a.badger at gmail.com Mon May 12 14:41:41 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 12 May 2008 07:41:41 -0700 Subject: Unable to check out one of my packages... In-Reply-To: <48285180.6030101@redhat.com> References: <48285180.6030101@redhat.com> Message-ID: <48285725.2080701@gmail.com> Darryl L. Pierce wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > When I try to checkout one of my packages (rubygem-activeldap), I'm > getting: > > [mcpierce at mcpierce-laptop rubygem-hoe]$ fedora-cvs rubygem-activeldap > Checking out rubygem-activeldap from fedora cvs: > Error: cvs server: cannot find module `rubygem-activeldap' - ignored > cvs [checkout aborted]: cannot expand modules > > My other packages are fine. Who do I contact to fix this? > This is the right place. It looks like this is a recently reviewed and imported package that was entered into the packagedb but not branched on the cvs server. I fixed that so you should be good to go now. -Toshio From j.w.r.degoede at hhs.nl Mon May 12 14:49:49 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 12 May 2008 16:49:49 +0200 Subject: ikvm and gnu classpath In-Reply-To: <1210596473.25428.33.camel@T7.Linux> References: <1210596473.25428.33.camel@T7.Linux> Message-ID: <4828590D.9000004@hhs.nl> Paul wrote: > Hi, > > Looking more into the problems in getting ikvm to build from source and > it looks like it won't be as simple as I thought as it does need to > build against the sources of gnu-classpath (which is a pain to be > honest!) to build it's main application. > > Is there a problem with a spec file pulling in the sources from another > tarball, decompressing, moving the required files across and then > building correctly? > There are a few other cases like this in Fedora AFAIk, that is for example why we have a mesa-sources packages. The correct solution would be to ask the classpath package maintainer to add a classpath-sources packages, and then to builddepend classpath-sources Regards, Hans From linville at redhat.com Mon May 12 15:19:01 2008 From: linville at redhat.com (John W. Linville) Date: Mon, 12 May 2008 11:19:01 -0400 Subject: Realtek RTL8187B In-Reply-To: <1210486654.5317.4.camel@scrappy.miketc.com> References: <1210486654.5317.4.camel@scrappy.miketc.com> Message-ID: <20080512151901.GA7411@redhat.com> On Sun, May 11, 2008 at 01:17:34AM -0500, Mike Chambers wrote: > Have installed F9 (er, well, rawhide anyway as of today) is why asking > on this list. > > This wireless driver is in my laptop that I bought from Best Buy, which > is a Gateway laptop. I thought Realtek drivers were opensourced? Or at > least I guess maybe only wired drivers are? I can't seem to get the > laptop to recognize the wireless driver. It's connected in there > somehow via usb, which lsusb does show the driver. > > Do I have to use ndiswrapper to make this work or should it work out of > the box? If out of the box, what steps to get it to load and be > recognized? This is being worked-on, but it is not there yet: https://bugzilla.redhat.com/show_bug.cgi?id=432280 Hth! John -- John W. Linville linville at redhat.com From tcallawa at redhat.com Mon May 12 15:44:31 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 12 May 2008 11:44:31 -0400 Subject: Call for savior - ikvm In-Reply-To: <20080512075124.M17539@all-the-johnsons.co.uk> References: <20080512075124.M17539@all-the-johnsons.co.uk> Message-ID: <1210607072.12520.27.camel@localhost.localdomain> On Mon, 2008-05-12 at 08:53 +0100, Paul F. Johnson wrote: > I've tried, on many occassions to get ikvm to build using gcj et al, > but it > always fails. I have some time today and will try again. If it works, > I'll get > it into rawhide ASAP. > ikvm scares the hell out of me. I spent more than a day trying to get any version of it to build from source, and failing. ~spot From walters at verbum.org Mon May 12 15:54:35 2008 From: walters at verbum.org (Colin Walters) Date: Mon, 12 May 2008 11:54:35 -0400 Subject: Fedora and JPackage proprietary JDK shims In-Reply-To: <48284A5B.8000401@ncsu.edu> References: <481BAB77.30302@gmail.com> <1209780338.22699.10.camel@valkyrie.localdomain> <481BECC5.7060203@gmail.com> <481C0034.7040304@gmail.com> <48284A5B.8000401@ncsu.edu> Message-ID: On Mon, May 12, 2008 at 9:47 AM, Casey Dahlin wrote: > > I think we need to re-gage this after we're a bit into F9 general > availability. The open source alternatives to Java have gotten much, much > better this go round, and many of the early adopters I've talked to have > said their java issues have gone completely away. We need to figure out what > role proprietary java will now play in the lives of our users. Going forward, I think very little to none. Apps which only support Java 5 will be a pain point for a while, but there are some Red Hat hackers working on more complete generic architecture support with a LLVM-based JIT. From mike at miketc.com Mon May 12 16:02:04 2008 From: mike at miketc.com (Mike Chambers) Date: Mon, 12 May 2008 11:02:04 -0500 Subject: Realtek RTL8187B In-Reply-To: <20080512151901.GA7411@redhat.com> References: <1210486654.5317.4.camel@scrappy.miketc.com> <20080512151901.GA7411@redhat.com> Message-ID: <1210608124.3271.10.camel@scrappy.miketc.com> On Mon, 2008-05-12 at 11:19 -0400, John W. Linville wrote: > This is being worked-on, but it is not there yet: > > https://bugzilla.redhat.com/show_bug.cgi?id=432280 Thanks John, am cc'd on it and added some input. Be nice to get this working so I don't have to use wired (have to share that with other computer), or windows. -- Mike Chambers Fedora Project - Ambassador, Bug Zapper, Tester, User, etc.. mikec302 at fedoraproject.org From jwilson at redhat.com Mon May 12 16:07:25 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 12 May 2008 12:07:25 -0400 Subject: Xorg 1.5 missed the train? In-Reply-To: <4826B04A.8020703@gmail.com> References: <4825F834.1020001@gmail.com> <1210491519.10397.9.camel@behdad.behdad.org> <4826B04A.8020703@gmail.com> Message-ID: <200805121207.25104.jwilson@redhat.com> On Sunday 11 May 2008 04:37:30 am George Billios wrote: > And I thought they were for a purpose. Please name the next version of > Xorg in Fedora 1.4.X.Y.Z Uh... $ rpm -q xorg-x11-server-Xorg xorg-x11-server-Xorg-1.4.99.901-29.20080415.fc9.x86_64 -- Jarod Wilson jwilson at redhat.com From blc at redhat.com Mon May 12 16:31:51 2008 From: blc at redhat.com (Brendan Conoboy) Date: Mon, 12 May 2008 10:31:51 -0600 Subject: JahShaka In-Reply-To: <48284537.3020008@cchtml.com> References: <4827CE9D.5020409@ncsu.edu> <4827F111.1070604@nicubunu.ro> <4827FA91.9060009@cchtml.com> <482841AC.8060705@ncsu.edu> <48284473.2070701@fedoraproject.org> <48284537.3020008@cchtml.com> Message-ID: <482870F7.70902@redhat.com> Mike Cronenworth wrote: > Most people who would want to use a video editor for "realistic work" > wouldn't find much value in an Ogg-only output format. They'd expect to > be able to output in MPEG-2, MPEG-4, or h.264 to display on their > televisions and/or share with customers or friends through the Internet. > Sure, you could output into a non-patent encumbered format and then > re-encode the video, but that's a two step process. Not very user > friendly; plus if it is a lossy codec it's a degrading process. If you can output any format that youtube/flickr/etc can consume you have something that is useful to a lot of people. If they're not currently accepting ogg, this would be a worthwhile effort to campaign for. -- Brendan Conoboy / Red Hat, Inc. / blc at redhat.com From nicolas.mailhot at laposte.net Mon May 12 16:44:53 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 12 May 2008 18:44:53 +0200 Subject: ikvm and prepackaged libs In-Reply-To: <1210603010.21971.7.camel@T7.Linux> References: <1210600414.21971.4.camel@T7.Linux> <48284CC2.3020703@redhat.com> <1210603010.21971.7.camel@T7.Linux> Message-ID: <1210610693.4921.1.camel@rousalka.okg> Le lundi 12 mai 2008 ? 15:36 +0100, Paul a ?crit : > > > 2. ecj needs to be built with ikvm > > > > Err, why? ecj is also a standard prt of Fedora. > > To build part of ikvm, ecj is rebuilt by ikvm which means another > package being brought in to build a 80k dll! That's the free software way, sorry :( Same rule for everyone. Be sure to relay all your issues to ikvm upstream so it fixes its build options -- 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 gbillios at gmail.com Mon May 12 16:51:35 2008 From: gbillios at gmail.com (George Billios) Date: Mon, 12 May 2008 19:51:35 +0300 Subject: Xorg 1.5 missed the train? In-Reply-To: <200805121207.25104.jwilson@redhat.com> References: <4825F834.1020001@gmail.com> <1210491519.10397.9.camel@behdad.behdad.org> <4826B04A.8020703@gmail.com> <200805121207.25104.jwilson@redhat.com> Message-ID: <48287597.2030804@gmail.com> -------- Original Message -------- Subject: Re:Xorg 1.5 missed the train? From: Jarod Wilson To: fedora-devel-list at redhat.com Date: Mon 12 May 2008 07:07:25 PM EEST > On Sunday 11 May 2008 04:37:30 am George Billios wrote: >> And I thought they were for a purpose. Please name the next version of >> Xorg in Fedora 1.4.X.Y.Z > > Uh... > > $ rpm -q xorg-x11-server-Xorg > xorg-x11-server-Xorg-1.4.99.901-29.20080415.fc9.x86_64 > > No you missed the irony, since 'revision numbers are for ignorants' they should really use X Y Z !!! From tcallawa at redhat.com Mon May 12 17:03:18 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 12 May 2008 13:03:18 -0400 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <20080507182919.GB8099@redhat.com> References: <20080507182919.GB8099@redhat.com> Message-ID: <1210611798.12520.41.camel@localhost.localdomain> On Wed, 2008-05-07 at 14:29 -0400, Deepak Bhole wrote: > A page detailing the reasons for keeping the exception is now up on the > wiki: > > http://fedoraproject.org/wiki/DeepakBhole/ReasonsForKeepingJPP Deepak, thanks for writing that up. Seth Vidal has helped me come up with a technical solution that should meet the requirements described in your document. http://skvidal.fedorapeople.org/misc/exclude-by-group/ This is a very simple yum plugin that enables the user to exclude by RPM Group tag. Since the RPM Group tag is not standardized in any way in Fedora packages (aside from the fact that it must be present), it should be possible for all JPackage RPMs in Fedora to have a unique string in the Group field (it could be JPackage, Java, jpp, Java/JPackage or GiantGilaMonster). To address your reasons: * This plugin enables the grouping operations to exclude JPackage RPMs in Fedora * This enables JPackage to use Fedora as their development OS * This enables people wishing to deploy an entire JPackage stack * By identifying JPackage in the Group field, it gives credit to the JPackage origin of these packages. * Without *jpp* in Fedora Release tags, it becomes very obvious whether a package came from Fedora repositories or JPackage repositories. Hopefully, you will agree that this plugin obsoletes the need for the JPackage naming exception in Fedora. I look forward to your feedback. Thanks, ~spot From nicolas.mailhot at laposte.net Mon May 12 17:17:23 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 12 May 2008 19:17:23 +0200 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <1210611798.12520.41.camel@localhost.localdomain> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> Message-ID: <1210612643.6285.5.camel@rousalka.okg> Le lundi 12 mai 2008 ? 13:03 -0400, Tom "spot" Callaway a ?crit : > On Wed, 2008-05-07 at 14:29 -0400, Deepak Bhole wrote: > > > A page detailing the reasons for keeping the exception is now up on the > > wiki: > > > > http://fedoraproject.org/wiki/DeepakBhole/ReasonsForKeepingJPP > > Deepak, thanks for writing that up. Seth Vidal has helped me come up > with a technical solution that should meet the requirements described in > your document. > > http://skvidal.fedorapeople.org/misc/exclude-by-group/ > > This is a very simple yum plugin that enables the user to exclude by RPM > Group tag. Uh, that's pretty hideous, I thought we were working hard at killing the group tag altogether, not adding new deps on it. Plus before it works it would require a full rebuild of the java repository to put the right group on every package. Can't yum use the Vendor tag instead? That wouldn't be such a kludge, and I think Vendor already identifies a unique repository provider in existing packages. -- 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 jwilson at redhat.com Mon May 12 17:21:16 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 12 May 2008 13:21:16 -0400 Subject: Xorg 1.5 missed the train? In-Reply-To: <48287597.2030804@gmail.com> References: <4825F834.1020001@gmail.com> <200805121207.25104.jwilson@redhat.com> <48287597.2030804@gmail.com> Message-ID: <200805121321.16641.jwilson@redhat.com> On Monday 12 May 2008 12:51:35 pm George Billios wrote: > > On Sunday 11 May 2008 04:37:30 am George Billios wrote: > >> And I thought they were for a purpose. Please name the next version of > >> Xorg in Fedora 1.4.X.Y.Z > > > > Uh... > > > > $ rpm -q xorg-x11-server-Xorg > > xorg-x11-server-Xorg-1.4.99.901-29.20080415.fc9.x86_64 > > No you missed the irony, since 'revision numbers are for ignorants' they > should really use X Y Z !!! Ill-conceived irony then, shouldn't have been 1.4.X.Y.Z, that still includes numbers. -- Jarod Wilson jwilson at redhat.com From tcallawa at redhat.com Mon May 12 17:31:51 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 12 May 2008 13:31:51 -0400 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <1210612643.6285.5.camel@rousalka.okg> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <1210612643.6285.5.camel@rousalka.okg> Message-ID: <1210613511.12520.46.camel@localhost.localdomain> On Mon, 2008-05-12 at 19:17 +0200, Nicolas Mailhot wrote: > Le lundi 12 mai 2008 ? 13:03 -0400, Tom "spot" Callaway a ?crit : > > On Wed, 2008-05-07 at 14:29 -0400, Deepak Bhole wrote: > > > > > A page detailing the reasons for keeping the exception is now up on the > > > wiki: > > > > > > http://fedoraproject.org/wiki/DeepakBhole/ReasonsForKeepingJPP > > > > Deepak, thanks for writing that up. Seth Vidal has helped me come up > > with a technical solution that should meet the requirements described in > > your document. > > > > http://skvidal.fedorapeople.org/misc/exclude-by-group/ > > > > This is a very simple yum plugin that enables the user to exclude by RPM > > Group tag. > > Uh, that's pretty hideous, I thought we were working hard at killing the > group tag altogether, not adding new deps on it. Plus before it works it > would require a full rebuild of the java repository to put the right > group on every package. Yeah, but we'd want that rebuild anyways to drop the .jpp tag. I'm not convinced that this is any more "hideous" than the .jpp release naming exception (in fact, I think it is far nicer). > Can't yum use the Vendor tag instead? That wouldn't be such a kludge, > and I think Vendor already identifies a unique repository provider in > existing packages. Unfortunately, in Fedora packages, Vendor gets set to Fedora Project for everything, which wouldn't help in excluding the Java JPackage derived packages living in Fedora. ~spot From skvidal at fedoraproject.org Mon May 12 17:31:46 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 12 May 2008 13:31:46 -0400 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <1210613511.12520.46.camel@localhost.localdomain> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <1210612643.6285.5.camel@rousalka.okg> <1210613511.12520.46.camel@localhost.localdomain> Message-ID: <1210613506.10395.7.camel@localhost.localdomain> On Mon, 2008-05-12 at 13:31 -0400, Tom "spot" Callaway wrote: > On Mon, 2008-05-12 at 19:17 +0200, Nicolas Mailhot wrote: > > Le lundi 12 mai 2008 ? 13:03 -0400, Tom "spot" Callaway a ?crit : > > > On Wed, 2008-05-07 at 14:29 -0400, Deepak Bhole wrote: > > > > > > > A page detailing the reasons for keeping the exception is now up on the > > > > wiki: > > > > > > > > http://fedoraproject.org/wiki/DeepakBhole/ReasonsForKeepingJPP > > > > > > Deepak, thanks for writing that up. Seth Vidal has helped me come up > > > with a technical solution that should meet the requirements described in > > > your document. > > > > > > http://skvidal.fedorapeople.org/misc/exclude-by-group/ > > > > > > This is a very simple yum plugin that enables the user to exclude by RPM > > > Group tag. > > > > Uh, that's pretty hideous, I thought we were working hard at killing the > > group tag altogether, not adding new deps on it. Plus before it works it > > would require a full rebuild of the java repository to put the right > > group on every package. > > Yeah, but we'd want that rebuild anyways to drop the .jpp tag. I'm not > convinced that this is any more "hideous" than the .jpp release naming > exception (in fact, I think it is far nicer). > > > Can't yum use the Vendor tag instead? That wouldn't be such a kludge, > > and I think Vendor already identifies a unique repository provider in > > existing packages. > > Unfortunately, in Fedora packages, Vendor gets set to Fedora Project for > everything, which wouldn't help in excluding the Java JPackage derived > packages living in Fedora. > If it is helpful I can modify the plugin to do exclude-by-provides or other such nonsense. -sv From ajax at redhat.com Mon May 12 18:30:55 2008 From: ajax at redhat.com (Adam Jackson) Date: Mon, 12 May 2008 14:30:55 -0400 Subject: Xorg 1.5 missed the train? In-Reply-To: <4826B04A.8020703@gmail.com> References: <4825F834.1020001@gmail.com> <1210491519.10397.9.camel@behdad.behdad.org> <4826B04A.8020703@gmail.com> Message-ID: <1210617055.1248.46.camel@localhost.localdomain> On Sun, 2008-05-11 at 11:37 +0300, George Billios wrote: > > Upstream maintainer and people > > closely following development think of a module as a list of new > > features and current bugs, shrinking and growing by time. If Adam > > thinks it's fine to include a prerelease of xorg in Fedora, then, well, > > it's fine. > > You (and others here) miss the point, that not everybody is a developer, > not everybody monitors the bug list but almost everybody can notice the > word 'prerelease' in the F9 release notes and would like a reason why > this happened. > > Take this for example: > > http://fedoraproject.org/wiki/Features/XserverOnePointFive > > It mentions that it is a prelease version but it doesn't justify why > including a prelease version is ok. It's the least buggy X server branch with the features we want. I admit, it's not a release, and that's entirely process failure on my part. Having lots of masters to obey is not easy, and in this case my time got chewed up by other business obligations. Thanks RHEL, you're awesome. So the thing I chose to sacrifice was the (actually fairly labor-intensive) process of badging the tarball as a release. It still got bug fixes. It's ABI-stable. Leaving it in was way less disruptive than reverting back to 1.3 would have been. It just isn't 1.5.0. I actually went on a long rant about this at xdevconf: http://xorg.freedesktop.org/wiki/Events/XDC2008/Notes The essential problem is that we're a victim of our own success. There's lots of great stuff happening in X and unfortunately the thing to suffer there is the stabilisation effort. I do the best I can but I'm not a superhero. Nor, really, should I have to be. And come to that, I'm actually quite bad at the release management job. I don't communicate effectively, I don't delegate enough, and I don't deliver on the schedules I promise. Mea maxima freakin' culpa. If someone else steps up to the job, huzzah. Until then we're sort of stuck. My question to the gallery is how do I fix this? How do _we_ fix this? X needs more people. It's way less scary than you've been led to believe. How do we get more people involved? How do we step up the testing effort? How do we get to a culture of frequent releases and incremental improvement? Without these things, release management is going to continue to be bursts of heroic effort that almost certainly misses deadlines, as it has been ever since Xorg 6.7. I mean, in some sense, it's fine. It's software just like any other, the number on the side of the box is merely a talisman, a dusting of holy penguin pee. But the release is also the primary artifact of the development process. Skipping that obligation is a disservice both to ourselves and our consumers. I hope we find an answer, but I just don't have one right now. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From dr.diesel at gmail.com Mon May 12 18:43:11 2008 From: dr.diesel at gmail.com (Dr. Diesel) Date: Mon, 12 May 2008 13:43:11 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: <1210617055.1248.46.camel@localhost.localdomain> References: <4825F834.1020001@gmail.com> <1210491519.10397.9.camel@behdad.behdad.org> <4826B04A.8020703@gmail.com> <1210617055.1248.46.camel@localhost.localdomain> Message-ID: <2a28d2ab0805121143m7a5bf719yde1a441cbb5faf1d@mail.gmail.com> 2008/5/12 Adam Jackson : > > It's the least buggy X server branch with the features we want. > > I admit, it's not a release, and that's entirely process failure on my > part. Having lots of masters to obey is not easy, and in this case my > time got chewed up by other business obligations. Thanks RHEL, you're > awesome. So the thing I chose to sacrifice was the (actually fairly > labor-intensive) process of badging the tarball as a release. It still > got bug fixes. It's ABI-stable. Leaving it in was way less disruptive > than reverting back to 1.3 would have been. It just isn't 1.5.0. > > I actually went on a long rant about this at xdevconf: > > http://xorg.freedesktop.org/wiki/Events/XDC2008/Notes > > The essential problem is that we're a victim of our own success. > There's lots of great stuff happening in X and unfortunately the thing > to suffer there is the stabilisation effort. I do the best I can but > I'm not a superhero. Nor, really, should I have to be. And come to > that, I'm actually quite bad at the release management job. I don't > communicate effectively, I don't delegate enough, and I don't deliver on > the schedules I promise. Mea maxima freakin' culpa. > > If someone else steps up to the job, huzzah. Until then we're sort of > stuck. > > My question to the gallery is how do I fix this? How do _we_ fix this? > X needs more people. It's way less scary than you've been led to > believe. How do we get more people involved? How do we step up the > testing effort? How do we get to a culture of frequent releases and > incremental improvement? Without these things, release management is > going to continue to be bursts of heroic effort that almost certainly > misses deadlines, as it has been ever since Xorg 6.7. > > I mean, in some sense, it's fine. It's software just like any other, > the number on the side of the box is merely a talisman, a dusting of > holy penguin pee. But the release is also the primary artifact of the > development process. Skipping that obligation is a disservice both to > ourselves and our consumers. > > I hope we find an answer, but I just don't have one right now. > > - ajax > I for one think your doing a great job and will happily wait till your ready with 1.5! Thanks for all your hard work. Andy -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org From jspaleta at gmail.com Mon May 12 18:45:50 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 12 May 2008 10:45:50 -0800 Subject: Xorg 1.5 missed the train? In-Reply-To: <1210617055.1248.46.camel@localhost.localdomain> References: <4825F834.1020001@gmail.com> <1210491519.10397.9.camel@behdad.behdad.org> <4826B04A.8020703@gmail.com> <1210617055.1248.46.camel@localhost.localdomain> Message-ID: <604aa7910805121145q21632f76j1413b104be1392ed@mail.gmail.com> 2008/5/12 Adam Jackson : > I actually went on a long rant about this at xdevconf: > > http://xorg.freedesktop.org/wiki/Events/XDC2008/Notes > > The essential problem is that we're a victim of our own success. > There's lots of great stuff happening in X and unfortunately the thing > to suffer there is the stabilisation effort. I do the best I can but > I'm not a superhero. Nor, really, should I have to be. And come to > that, I'm actually quite bad at the release management job. I don't > communicate effectively, I don't delegate enough, and I don't deliver on > the schedules I promise. Mea maxima freakin' culpa. > > If someone else steps up to the job, huzzah. Until then we're sort of > stuck. > > My question to the gallery is how do I fix this? How do _we_ fix this? > X needs more people. It's way less scary than you've been led to > believe. How do we get more people involved? How do we step up the > testing effort? How do we get to a culture of frequent releases and > incremental improvement? Without these things, release management is > going to continue to be bursts of heroic effort that almost certainly > misses deadlines, as it has been ever since Xorg 6.7. I don't know, but if Fedora is serious about being THE conduit to connect upstream project development and downstream consumers, then these sort of questions are exactly the sort of thing the Board should be chewing on. Luckily enough, I've got a big mouth and I enjoy the taste and mouth-feel of broken glass. -jef From cmadams at hiwaay.net Mon May 12 18:48:07 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 12 May 2008 13:48:07 -0500 Subject: Changing things in long-closed bugs? Message-ID: <20080512184807.GI1139409@hiwaay.net> I've received several emails from bugzilla now about the severity, product, etc. being changed on bugs I'm the reporter or a CC on. These are bugs that have been closed for a while (1-2 years or more). Does this (a) really need to be changed and (b) really need to send email? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jkeating at redhat.com Mon May 12 18:54:11 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 12 May 2008 14:54:11 -0400 Subject: Changing things in long-closed bugs? In-Reply-To: <20080512184807.GI1139409@hiwaay.net> References: <20080512184807.GI1139409@hiwaay.net> Message-ID: <1210618451.19805.88.camel@localhost.localdomain> On Mon, 2008-05-12 at 13:48 -0500, Chris Adams wrote: > I've received several emails from bugzilla now about the severity, > product, etc. being changed on bugs I'm the reporter or a CC on. These > are bugs that have been closed for a while (1-2 years or more). Does > this (a) really need to be changed and (b) really need to send email? Here is what happened. The Triage folks are closing out old trackers, for say Fedora Core 4/5/etc... These trackers are done, not used anymore, and should be closed. However in bugzilla code, whenever you modify a tracker bug (IE a bug that depends on other bugs) it will send mail to the people attached to every bug it depends upon. Add to that some staged changes that are in place for Bugzilla so that the next time some bugs are poked it'll do the conversions of priorities and products, you wind up triggering that for a number of older bugs. Yes this is bothersome, and yes it's some spam. But it's somewhat unavoidable due to how we use bugzilla and just the built up cruft of unclosed trackers and constantly being a bit schizophrenic about priorities, severity, and the name of Red Hat Linux/Fedora Core/Fedora. This will only get "better" in the future as we manage our tracker bugs better and hopefully don't go about renaming the product again. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Mon May 12 19:00:23 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 13 May 2008 00:30:23 +0530 Subject: Changing things in long-closed bugs? In-Reply-To: <1210618451.19805.88.camel@localhost.localdomain> References: <20080512184807.GI1139409@hiwaay.net> <1210618451.19805.88.camel@localhost.localdomain> Message-ID: <482893C7.7070909@fedoraproject.org> Jesse Keating wrote: > > This will only get "better" in the future as we manage our tracker bugs > better and hopefully don't go about renaming the product again. Bugzilla upstream seem to be advocating using flags instead of tracker bugs these days. I don't whether that is going to solve this problem in any way but it is worth considering. Rahul From nicolas.mailhot at laposte.net Mon May 12 19:11:27 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 12 May 2008 21:11:27 +0200 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <1210613511.12520.46.camel@localhost.localdomain> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <1210612643.6285.5.camel@rousalka.okg> <1210613511.12520.46.camel@localhost.localdomain> Message-ID: <1210619487.6844.48.camel@rousalka.okg> Le lundi 12 mai 2008 ? 13:31 -0400, Tom "spot" Callaway a ?crit : > On Mon, 2008-05-12 at 19:17 +0200, Nicolas Mailhot wrote: > > Le lundi 12 mai 2008 ? 13:03 -0400, Tom "spot" Callaway a ?crit : > > > On Wed, 2008-05-07 at 14:29 -0400, Deepak Bhole wrote: > > > > > > > A page detailing the reasons for keeping the exception is now up on the > > > > wiki: > > > > > > > > http://fedoraproject.org/wiki/DeepakBhole/ReasonsForKeepingJPP > > > > > > Deepak, thanks for writing that up. Seth Vidal has helped me come up > > > with a technical solution that should meet the requirements described in > > > your document. > > > > > > http://skvidal.fedorapeople.org/misc/exclude-by-group/ > > > > > > This is a very simple yum plugin that enables the user to exclude by RPM > > > Group tag. > > > > Uh, that's pretty hideous, I thought we were working hard at killing the > > group tag altogether, not adding new deps on it. Plus before it works it > > would require a full rebuild of the java repository to put the right > > group on every package. > > Yeah, but we'd want that rebuild anyways to drop the .jpp tag. The fedora rebuilds won't change the group tag of the existing jpackage rpms. And there's a lot more of those (with a lot less human and non-human resources) JPackage-side. > I'm not > convinced that this is any more "hideous" than the .jpp release naming > exception (in fact, I think it is far nicer). Just shows you're hopelessly biased. The only value of this proposal is to kill the .foo tag (others have been using with no harm done), by replacing it with a kludge (which only merit is it's so convoluted and backwards it won't probably survive a month after its announce). Seth delivered but I'm not sure the requirement level was to his usual standard. > > Can't yum use the Vendor tag instead? That wouldn't be such a kludge, > > and I think Vendor already identifies a unique repository provider in > > existing packages. > > Unfortunately, in Fedora packages, Vendor gets set to Fedora Project for > everything, In other words, expediency prevailed over solid long-term design. > which wouldn't help in excluding the Java JPackage derived > packages living in Fedora. I'm disappointed by the way this problem was handled. I'd like the people who were so quick to ?repeatedly diss the Java people in public, and who are asking of them a lot of work, to do them the courtesy of applying the same high standards to themselves, that is to say: ??? reach out to their communication forums (why should the effort always be one-way) ? document properly in the wiki what are the exact drawbacks of using .jpp (it's *still* nebulous to me at least) ? propose a solid long-term technical solution (pot, kettle, black, all this public outrage to propose a kludgy kludge as 'solution') We're not so quick to mandate mass rebuilds when we have to do them ourselves. -- 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 Mon May 12 19:14:17 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 12 May 2008 15:14:17 -0400 Subject: Changing things in long-closed bugs? In-Reply-To: <482893C7.7070909@fedoraproject.org> References: <20080512184807.GI1139409@hiwaay.net> <1210618451.19805.88.camel@localhost.localdomain> <482893C7.7070909@fedoraproject.org> Message-ID: <1210619657.19805.92.camel@localhost.localdomain> On Tue, 2008-05-13 at 00:30 +0530, Rahul Sundaram wrote: > > Bugzilla upstream seem to be advocating using flags instead of tracker > bugs these days. I don't whether that is going to solve this problem in > any way but it is worth considering. We do use flags in some places, but I'm not convinced that flags are a more user friendly way of doing trackers. Querying flags becomes non-obvious, especially when clicking on a list of dependant bugs is dead easy. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From nicolas.mailhot at laposte.net Mon May 12 19:15:55 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 12 May 2008 21:15:55 +0200 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <1210613506.10395.7.camel@localhost.localdomain> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <1210612643.6285.5.camel@rousalka.okg> <1210613511.12520.46.camel@localhost.localdomain> <1210613506.10395.7.camel@localhost.localdomain> Message-ID: <1210619755.6844.52.camel@rousalka.okg> Le lundi 12 mai 2008 ? 13:31 -0400, seth vidal a ?crit : > If it is helpful I can modify the plugin to do exclude-by-provides or > other such nonsense. Can you propose a sensical way to do it instead? People may spend months of packaging rebuilds as a result of all this. They deserve a solid solution. -- 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 tcallawa at redhat.com Mon May 12 19:17:58 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 12 May 2008 15:17:58 -0400 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <1210619755.6844.52.camel@rousalka.okg> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <1210612643.6285.5.camel@rousalka.okg> <1210613511.12520.46.camel@localhost.localdomain> <1210613506.10395.7.camel@localhost.localdomain> <1210619755.6844.52.camel@rousalka.okg> Message-ID: <1210619878.12520.55.camel@localhost.localdomain> On Mon, 2008-05-12 at 21:15 +0200, Nicolas Mailhot wrote: > People may spend months of packaging rebuilds as a result of all this. It won't take months. A week, maybe. And yes, I'm volunteering to actually do the work here. ~spot From eparis at redhat.com Mon May 12 19:22:39 2008 From: eparis at redhat.com (Eric Paris) Date: Mon, 12 May 2008 15:22:39 -0400 Subject: upcoming selinux ioctl permission changes Message-ID: <1210620159.3228.39.camel@localhost.localdomain> I'm planning on pushing a patch to try to simplify ioctl permission checks in SELinux. This won't be upstreamed until the 2.6.27 merge window and we would like to see some more widespread testing first. So I plan to push this into the rawhide kernel in the next day or two. We certainly don't expect it to cause any problem so I'm really only mentioning it just in case and to put people on the lookout. If you happen to notice strange denials on ioctls please file a bug and cc me or send me an e-mail! http://marc.info/?l=selinux&m=121033736222066&w=2 -Eric From jonstanley at gmail.com Mon May 12 19:39:52 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Mon, 12 May 2008 15:39:52 -0400 Subject: Changing things in long-closed bugs? In-Reply-To: <1210618451.19805.88.camel@localhost.localdomain> References: <20080512184807.GI1139409@hiwaay.net> <1210618451.19805.88.camel@localhost.localdomain> Message-ID: 2008/5/12 Jesse Keating : > The Triage folks are closing out old trackers, for say Fedora Core > 4/5/etc... These trackers are done, not used anymore, and should be > closed. However in bugzilla code, whenever you modify a tracker bug (IE This is me, totally sorry. I've started using python-bugzilla which can suppress mail notifications to close trackers. Not entirely sure the effect of that flag on dependent bugs, but with some luck, the mailbomb is over :) *goes and sits in the corner* From pertusus at free.fr Mon May 12 19:45:19 2008 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 12 May 2008 21:45:19 +0200 Subject: old redhat rpms list/mirrors In-Reply-To: <4827FF0B.8050803@nobugconsulting.ro> References: <20080512075712.GA2582@free.fr> <4827FB52.4040307@nobugconsulting.ro> <20080512081632.GB2582@free.fr> <4827FF0B.8050803@nobugconsulting.ro> Message-ID: <20080512194519.GB3153@free.fr> On Mon, May 12, 2008 at 11:25:47AM +0300, Manuel Wolfshant wrote: > > lftp archive.download.redhat.com:/pub/redhat/linux/5.0/en> ls os/i386 > > in other words, works for me... Indeed, for me too with lftp, but not with firefox. Strange. -- Pat From tcallawa at redhat.com Mon May 12 19:48:16 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 12 May 2008 15:48:16 -0400 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <1210619487.6844.48.camel@rousalka.okg> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <1210612643.6285.5.camel@rousalka.okg> <1210613511.12520.46.camel@localhost.localdomain> <1210619487.6844.48.camel@rousalka.okg> Message-ID: <1210621696.12520.62.camel@localhost.localdomain> On Mon, 2008-05-12 at 21:11 +0200, Nicolas Mailhot wrote: > I'm disappointed by the way this problem was handled. I'd like the > people who were so quick to ?repeatedly diss the Java people in > public, > and who are asking of them a lot of work, to do them the courtesy of > applying the same high standards to themselves, that is to say: > ??? reach out to their communication forums (why should the effort > always be one-way) > ? document properly in the wiki what are the exact drawbacks of > using .jpp (it's *still* nebulous to me at least) > ? propose a solid long-term technical solution (pot, kettle, black, > all > this public outrage to propose a kludgy kludge as 'solution') > > We're not so quick to mandate mass rebuilds when we have to do them > ourselves. A few points: * I'm not mandating that JPackage change anything. This is specifically targeted on handling the Fedora packages which are derived from JPackage packages. * We don't permit repotags in Release normally, because adding "noise" characters into that field significantly complicates RPM package ordering. They never should have been there in the first place, and we're trying to work a solution for this. * I'm willing to maintain this plugin as a long-term technical solution. * I'm willing to rebuild all of the affected Fedora packages to resolve this situation. The approved JPackage naming exception says that when a technical solution is found to make .jpp tagging obsolete for the purposes of grouping excludes, the exception will vanish. I think we've done that, insults and flames aside. ~spot From skvidal at fedoraproject.org Mon May 12 19:41:35 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 12 May 2008 15:41:35 -0400 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <1210619755.6844.52.camel@rousalka.okg> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <1210612643.6285.5.camel@rousalka.okg> <1210613511.12520.46.camel@localhost.localdomain> <1210613506.10395.7.camel@localhost.localdomain> <1210619755.6844.52.camel@rousalka.okg> Message-ID: <1210621295.10395.12.camel@localhost.localdomain> On Mon, 2008-05-12 at 21:15 +0200, Nicolas Mailhot wrote: > Le lundi 12 mai 2008 ? 13:31 -0400, seth vidal a ?crit : > > > If it is helpful I can modify the plugin to do exclude-by-provides or > > other such nonsense. > > Can you propose a sensical way to do it instead? People may spend months > of packaging rebuilds as a result of all this. They deserve a solid > solution. > Well, I think the whole 'exclude this set of pkgs b/c they're kinda-sorta-this-groups' thing to be pretty nonsensical. Spot asked me for a way to solve the requested need for the users which is what exclude-by-rpm-group or exclude-by-vendor or exclude-by-provides or exclude-by-other-arbitrary-tag is about. But I don't have a dog in this fight. If you don't like the plugin, that's fine, propose another solution and I'll see what I can do. -sv From cmadams at hiwaay.net Mon May 12 19:52:45 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 12 May 2008 14:52:45 -0500 Subject: Changing things in long-closed bugs? In-Reply-To: References: <20080512184807.GI1139409@hiwaay.net> <1210618451.19805.88.camel@localhost.localdomain> Message-ID: <20080512195245.GJ1139409@hiwaay.net> Once upon a time, Jon Stanley said: > This is me, totally sorry. I've started using python-bugzilla which > can suppress mail notifications to close trackers. Not entirely sure > the effect of that flag on dependent bugs, but with some luck, the > mailbomb is over :) I don't have a problem; I just didn't know where they were coming from (and I didn't realize I was on that many bugs that had been attached to trackers :-) ). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From notting at redhat.com Mon May 12 20:22:46 2008 From: notting at redhat.com (Bill Nottingham) Date: Mon, 12 May 2008 16:22:46 -0400 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <1210611798.12520.41.camel@localhost.localdomain> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> Message-ID: <20080512202246.GA11400@nostromo.devel.redhat.com> Tom spot Callaway (tcallawa at redhat.com) said: > On Wed, 2008-05-07 at 14:29 -0400, Deepak Bhole wrote: > > > A page detailing the reasons for keeping the exception is now up on the > > wiki: > > > > http://fedoraproject.org/wiki/DeepakBhole/ReasonsForKeepingJPP > > Deepak, thanks for writing that up. Seth Vidal has helped me come up > with a technical solution that should meet the requirements described in > your document. > > http://skvidal.fedorapeople.org/misc/exclude-by-group/ This seems very wrong. What I'm reading is that JPackage developers want to not use anything in Fedora that also exists in JPackage. Isn't this better done by repo costs and similar plugins, rather than hacks either in the package version or vendor which can be easily fooled? Bill From skvidal at fedoraproject.org Mon May 12 20:18:31 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 12 May 2008 16:18:31 -0400 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <20080512202246.GA11400@nostromo.devel.redhat.com> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <20080512202246.GA11400@nostromo.devel.redhat.com> Message-ID: <1210623511.10395.17.camel@localhost.localdomain> On Mon, 2008-05-12 at 16:22 -0400, Bill Nottingham wrote: > Tom spot Callaway (tcallawa at redhat.com) said: > > On Wed, 2008-05-07 at 14:29 -0400, Deepak Bhole wrote: > > > > > A page detailing the reasons for keeping the exception is now up on the > > > wiki: > > > > > > http://fedoraproject.org/wiki/DeepakBhole/ReasonsForKeepingJPP > > > > Deepak, thanks for writing that up. Seth Vidal has helped me come up > > with a technical solution that should meet the requirements described in > > your document. > > > > http://skvidal.fedorapeople.org/misc/exclude-by-group/ > > This seems very wrong. > > What I'm reading is that JPackage developers want to not use anything > in Fedora that also exists in JPackage. > > Isn't this better done by repo costs and similar plugins, rather > than hacks either in the package version or vendor which can > be easily fooled? repo costs only work for exact-matches of the package nevra - not partial matches. So one way or another you have to do this via a plugin. -sv From notting at redhat.com Mon May 12 20:38:16 2008 From: notting at redhat.com (Bill Nottingham) Date: Mon, 12 May 2008 16:38:16 -0400 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <1210623511.10395.17.camel@localhost.localdomain> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <20080512202246.GA11400@nostromo.devel.redhat.com> <1210623511.10395.17.camel@localhost.localdomain> Message-ID: <20080512203816.GB26850@nostromo.devel.redhat.com> seth vidal (skvidal at fedoraproject.org) said: > > What I'm reading is that JPackage developers want to not use anything > > in Fedora that also exists in JPackage. > > > > Isn't this better done by repo costs and similar plugins, rather > > than hacks either in the package version or vendor which can > > be easily fooled? > > repo costs only work for exact-matches of the package nevra - not > partial matches. > > So one way or another you have to do this via a plugin. Sure, but using the *actual* data they want (which repository it came from) versus an approximation of that data (using a 'jpp' release tag, a specific 'Group' tag, or a specific 'Vendor' tag) seems to be the appropriate answer. You may need something like 'protectbase', or repository priorities, instead of cost, but the repository seems to be the better place to solve it rather than the individual packages. That being said, wanting to swap out large portions of the releases' stack willy-nilly is still kind of nuts. Bill From loganjerry at gmail.com Mon May 12 20:42:02 2008 From: loganjerry at gmail.com (Jerry James) Date: Mon, 12 May 2008 14:42:02 -0600 Subject: jsr-305 Message-ID: <870180fe0805121342p29660c25m3672d71c5d39b67c@mail.gmail.com> I'm *still* working on getting findbugs [1] into Fedora. Thanks very much to all who reviewed the prerequisites ... and now there's another. The jsr-305 [2] package is a new prerequisite, and is now the sole prerequisite before I can submit findbugs itself. I'd like some advice on how to tackle an issue with this package. The license under which it is distributed (BSD) is specified on the project web pages, but is nowhere referred to in the actual source distribution. There is not a single file I can find that refers to the license in any way. I have asked upstream to fix this issue [3], along with the 2 patches I needed to build the package, and a query as to whether there is anybody there. A month has gone by with no response to any of those messages. Can I proceed with this package, or do I need to keep shouting until somebody upstream wakes up and adds the licensing terms? How about if I include a copy of the project web page that states the license terms? My current efforts are here [4], by the way. References: [1] http://findbugs.sourceforge.net/ [2] http://jsr-305.googlecode.com/ [3] http://groups.google.com/group/jsr-305/msg/959fee95941a8743 [4] http://jjames.fedorapeople.org/jsr-305/ -- Jerry James http://loganjerry.googlepages.com/ From orion at cora.nwra.com Mon May 12 20:58:37 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 12 May 2008 14:58:37 -0600 Subject: FC10: strange cmake error In-Reply-To: <1210572888.26792.913.camel@beck.corsepiu.local> References: <1210572888.26792.913.camel@beck.corsepiu.local> Message-ID: <4828AF7D.6080707@cora.nwra.com> Ralf Corsepius wrote: > Hi, > > I am facing a strange cmake-related error when trying to upgrade > OpenSceneGraph to version 2.4.0 on FC10: > > ... > -- Looking for pthread_yield > CMake Error at CMakeLists.txt:9 (ADD_EXECUTABLE): > Target "cmTryCompileExec" links to item " -lpthread" which has leading > or > trailing whitespace. This is now an error according to policy > CMP0004. I think attached patch is what you need. I think a lot of cmake users (including myself) are confused about using lists. Build: http://koji.fedoraproject.org/koji/taskinfo?taskID=605508 Still get a cmake warning, that probably needs to get fixed in cmake. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenSceneGraph-2.4.0-cmake260.patch Type: text/x-patch Size: 1082 bytes Desc: not available URL: From tcallawa at redhat.com Mon May 12 21:12:05 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 12 May 2008 17:12:05 -0400 Subject: jsr-305 In-Reply-To: <870180fe0805121342p29660c25m3672d71c5d39b67c@mail.gmail.com> References: <870180fe0805121342p29660c25m3672d71c5d39b67c@mail.gmail.com> Message-ID: <1210626725.1920.0.camel@localhost.localdomain> On Mon, 2008-05-12 at 14:42 -0600, Jerry James wrote: > Can I proceed with this package, or do I need to > keep shouting until somebody upstream wakes up and adds the licensing > terms? How about if I include a copy of the project web page that > states the license terms? Please include a copy of the project web page and comment in the spec file as to where you determined the license from. This is not a blocker as far as I'm concerned. ~spot From poelstra at redhat.com Mon May 12 21:12:50 2008 From: poelstra at redhat.com (John Poelstra) Date: Mon, 12 May 2008 14:12:50 -0700 Subject: Fedora Release Engineering Meeting Recap 2008-05-12 Message-ID: <4828B2D2.5050605@redhat.com> Recap and full IRC transcript found here: http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-may-12 Please make corrections and clarifications to the wiki page. == Preparing Fedora 9 == * The x86_64 DVD jigdo is busted due to our last minute respins on Friday--need to hand edit newly created files * Consider making jigdo tree verification an F10 feature * Change permissions 40 minutes before release time--https://fedorahosted.org/rel-eng/ticket/20 * Change the inheritance of ''dist-rawhide'' from ''f9-final'' to ''dist-f10''--https://fedorahosted.org/rel-eng/ticket/21 * Create .ini files for torrent creator--https://fedorahosted.org/fedora-infrastructure/ticket/526 == Post Fedora 9 == * During our short "down" time before F10 alpha f13 would like to get some things going 1. Better use of our Trac space * closing out tickets on time * tracking milestones and tasks 1. Start scoping tasks for summer intern * Casey Dahlin (he's worked with notting in the past on things like upstart) * work on things lik new maintainer containment, tooling around non-responsive maintainers, Trac gateway, and other potential things like Kopers (Koji Personal Repos) 1. Tools * sigul--signing server needs work and connection with koji * pungi is going to inherit splittree and pkgorder from anaconda-runtime; need to integrate the functionality of those into pungi code * more tooling around releng tasks and tree validation 1. Upgrade releng1 to RHEL5 from FC6 1. What to cover at FUDCon Boston a. Start conversation about generation SCM (Source Control Management) * primary focus on requirements gathering and work flow possibilities a. SELinux vs. chroots discussion--see fedora-selinux-list * f13 is planning to run for Fedora Board and if he secures a position he would no longer represent Release Engineering on FESCo--would need a replacement == IRC Transcript == From seg at haxxed.com Mon May 12 21:40:21 2008 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 12 May 2008 16:40:21 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: <4826B04A.8020703@gmail.com> References: <4825F834.1020001@gmail.com> <1210491519.10397.9.camel@behdad.behdad.org> <4826B04A.8020703@gmail.com> Message-ID: <1210628422.27459.10.camel@localhost> On Sun, 2008-05-11 at 11:37 +0300, George Billios wrote: > And I thought they were for a purpose. Please name the next version of > Xorg in Fedora 1.4.X.Y.Z . Besides you are not an 'ignorant', you will > always know the real version right? > You (and others here) miss the point, that not everybody is a developer, > not everybody monitors the bug list but almost everybody can notice the > word 'prerelease' in the F9 release notes and would like a reason why > this happened. The bikeshed should be blue. You are an idiot if you don't like blue. Also I demand a pony. It can live in the shed. Why aren't you giving me my pony? You clearly don't care about the community. I demand a 4000 page printed report detailing why you have not given me my pony, delivered in person to my doorstep. I have a right to know! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From loganjerry at gmail.com Mon May 12 21:43:23 2008 From: loganjerry at gmail.com (Jerry James) Date: Mon, 12 May 2008 15:43:23 -0600 Subject: jsr-305 In-Reply-To: <1210626725.1920.0.camel@localhost.localdomain> References: <870180fe0805121342p29660c25m3672d71c5d39b67c@mail.gmail.com> <1210626725.1920.0.camel@localhost.localdomain> Message-ID: <870180fe0805121443r10a78d4dj13201d006dcabf11@mail.gmail.com> On Mon, May 12, 2008 at 3:12 PM, Tom spot Callaway wrote: > Please include a copy of the project web page and comment in the spec > file as to where you determined the license from. This is not a blocker > as far as I'm concerned. Great. Thank you! -- Jerry James http://loganjerry.googlepages.com/ From seg at haxxed.com Mon May 12 21:55:02 2008 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 12 May 2008 16:55:02 -0500 Subject: JahShaka In-Reply-To: <48284473.2070701@fedoraproject.org> References: <4827CE9D.5020409@ncsu.edu> <4827F111.1070604@nicubunu.ro> <4827FA91.9060009@cchtml.com> <482841AC.8060705@ncsu.edu> <48284473.2070701@fedoraproject.org> Message-ID: <1210629302.27459.19.camel@localhost> On Mon, 2008-05-12 at 18:51 +0530, Rahul Sundaram wrote: > Casey Dahlin wrote: > > > Why would it have to be GStreamer? Wouldn't anything > > un-patent-encumbered do? (Not that this isn't un-patent-encumbered, but > > in the general case). > > It doesn't have to be gstreamer. We have both gstreamer and xine (the > free parts) in Fedora but gstreamer does make it easy to add support > back for the other codecs that we don't include. It has to be gstreamer. 1) Xine doesn't handle encoding, only decode. 2) Gstreamer does both encoding and decoding 3) Gstreamer provides a nice standard way to plug in the proprietary codecs people inevitably want/need without compromising the Fedora project. 4) Stop reinventing the wheel. 5) Seriously, stop it. 6) Mplayer supports encoding, but: 7) Mplayer sucks. 8) So it has to be gstreamer. QED -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From walters at verbum.org Mon May 12 21:58:36 2008 From: walters at verbum.org (Colin Walters) Date: Mon, 12 May 2008 17:58:36 -0400 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <20080512203816.GB26850@nostromo.devel.redhat.com> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <20080512202246.GA11400@nostromo.devel.redhat.com> <1210623511.10395.17.camel@localhost.localdomain> <20080512203816.GB26850@nostromo.devel.redhat.com> Message-ID: On Mon, May 12, 2008 at 4:38 PM, Bill Nottingham wrote: > > Sure, but using the *actual* data they want (which repository > it came from) versus an approximation of that data (using > a 'jpp' release tag, a specific 'Group' tag, or a specific > 'Vendor' tag) seems to be the appropriate answer. This makes sense to me too. > That being said, wanting to swap out large portions of the > releases' stack willy-nilly is still kind of nuts. Well, largely our "core" stack (and by this I mean comps) does not (yet) have dependencies on many Java libraries. So there's not a big deal swapping out say our objectweb-asm for JPackage's. However, this is most definitely not a sustainable system in the long term. I sort of view JPackage as just a specific instance of the cross-distribution collaboration problem. Most distributions tend to focus primarily on dependencies driven by desktop apps or their own internal needs, but the general free software world is far larger than that, even before OpenJDK opened up a lot of Java software to us. From jkeating at redhat.com Mon May 12 21:59:19 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 12 May 2008 17:59:19 -0400 Subject: Rawhide moving on to Fedora 10 Message-ID: <1210629559.24771.8.camel@localhost.localdomain> In preparation of the Fedora 9 release tomorrow, we've flipped the configuration bit that will allow "rawhide" to be composed from Fedora 10 content tomorrow. This will likely fail in spectacular ways due to all the pent up builds so it should be interesting. Those of you that have installed rawhide starting from Fedora 9 Preview or later, or have updated yourself to rawhide at any point post Preview, your default yum configuration will have you set for staying on Fedora 9. If you've modified your config files you may not have picked up this change and will want to verify what repos are enabled before you get hit with a lot of Fedora 10 packages. The updates repos for Fedora 9 are currently empty, but I'm working on an updates push that will populate the updates and updates-testing with some 0-day updates that have been prepared. Theoretically these updates will hit mirrors sometime tonight. Keep all body parts inside the cart at all times. Buckle up and enjoy the ride! -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From loganjerry at gmail.com Mon May 12 22:05:53 2008 From: loganjerry at gmail.com (Jerry James) Date: Mon, 12 May 2008 16:05:53 -0600 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <20080512202246.GA11400@nostromo.devel.redhat.com> <1210623511.10395.17.camel@localhost.localdomain> <20080512203816.GB26850@nostromo.devel.redhat.com> Message-ID: <870180fe0805121505h1eb29c87i6a312b54cd82f49d@mail.gmail.com> On Mon, May 12, 2008 at 3:58 PM, Colin Walters wrote: > Well, largely our "core" stack (and by this I mean comps) does not > (yet) have dependencies on many Java libraries. So there's not a big > deal swapping out say our objectweb-asm for JPackage's. > > However, this is most definitely not a sustainable system in the long term. > > I sort of view JPackage as just a specific instance of the > cross-distribution collaboration problem. Most distributions tend to > focus primarily on dependencies driven by desktop apps or their own > internal needs, but the general free software world is far larger than > that, even before OpenJDK opened up a lot of Java software to us. So there are a bunch of Java packages that I use that I would like to drive into *some* repository where they can get picked up and used by others with similar needs. I've been driving towards Fedora so far. What's a good long-term solution, then? Should I keep that up, focus on JPackage, help figure out how the two are going to cooperate, ...? -- Jerry James http://loganjerry.googlepages.com/ From walters at verbum.org Mon May 12 22:13:13 2008 From: walters at verbum.org (Colin Walters) Date: Mon, 12 May 2008 18:13:13 -0400 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <870180fe0805121505h1eb29c87i6a312b54cd82f49d@mail.gmail.com> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <20080512202246.GA11400@nostromo.devel.redhat.com> <1210623511.10395.17.camel@localhost.localdomain> <20080512203816.GB26850@nostromo.devel.redhat.com> <870180fe0805121505h1eb29c87i6a312b54cd82f49d@mail.gmail.com> Message-ID: On Mon, May 12, 2008 at 6:05 PM, Jerry James wrote: > > So there are a bunch of Java packages that I use that I would like to > drive into *some* repository where they can get picked up and used by > others with similar needs. I've been driving towards Fedora so far. > What's a good long-term solution, then? Should I keep that up, focus > on JPackage, help figure out how the two are going to cooperate, ...? If we keep making sure Fedora and JPackage are cooperating on the level of Java package policy (as I believe we mostly are now), then largely any work you do in Fedora should translate into JPackage, and vice versa. So I think if you've been working in the Fedora context, it makes sense to continue to do so. From nicolas.mailhot at laposte.net Mon May 12 22:36:24 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 13 May 2008 00:36:24 +0200 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <1210619878.12520.55.camel@localhost.localdomain> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <1210612643.6285.5.camel@rousalka.okg> <1210613511.12520.46.camel@localhost.localdomain> <1210613506.10395.7.camel@localhost.localdomain> <1210619755.6844.52.camel@rousalka.okg> <1210619878.12520.55.camel@localhost.localdomain> Message-ID: <1210631784.12173.2.camel@rousalka.okg> Le lundi 12 mai 2008 ? 15:17 -0400, Tom "spot" Callaway a ?crit : > On Mon, 2008-05-12 at 21:15 +0200, Nicolas Mailhot wrote: > > People may spend months of packaging rebuilds as a result of all this. > > It won't take months. A week, maybe. And yes, I'm volunteering to > actually do the work here. Again you're totally ignoring the work that happens jpp-side. The project does not have a nice koji build farm with 24/24 sysadmins (and that's not counting the surprises you always have in mass rebuilds) -- 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 nicolas.mailhot at laposte.net Mon May 12 22:49:47 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 13 May 2008 00:49:47 +0200 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <1210621696.12520.62.camel@localhost.localdomain> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <1210612643.6285.5.camel@rousalka.okg> <1210613511.12520.46.camel@localhost.localdomain> <1210619487.6844.48.camel@rousalka.okg> <1210621696.12520.62.camel@localhost.localdomain> Message-ID: <1210632587.12173.15.camel@rousalka.okg> Le lundi 12 mai 2008 ? 15:48 -0400, Tom "spot" Callaway a ?crit : > * I'm not mandating that JPackage change anything. This is specifically > targeted on handling the Fedora packages which are derived from JPackage > packages. That's not realistic, if you want your matching to work you need the tagging implemented both sides. The Fedora side is the easy one. Fedora has still not merged the bulk of the JPackage repository. > * We don't permit repotags in Release normally, because adding "noise" > characters into that field significantly complicates RPM package > ordering. They never should have been there in the first place, and > we're trying to work a solution for this. That still awfully nebulous for the kind of effort you're requesting and besides the first people impacted by ordering problems (the packagers of the aforementioned packages) didn't report any particular problem nor did they request a fix. I'm not saying it should not be fixed eventually but there is a huge disproportion between the trumpeted criticity of this problem, its actual impacts and the work you're forcing on other packagers. > * I'm willing to maintain this plugin as a long-term technical solution. > * I'm willing to rebuild all of the affected Fedora packages to resolve > this situation. > > The approved JPackage naming exception says that when a technical > solution is found to make .jpp tagging obsolete for the purposes of > grouping excludes, the exception will vanish. I think we've done that, > insults and flames aside. It looks like it's going to be done, not for correctness but only because of this lobbying. You're strong-harming everyone for no good reason I see. -- 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 kevin.kofler at chello.at Mon May 12 22:56:40 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 12 May 2008 22:56:40 +0000 (UTC) Subject: FC10: strange cmake error References: <1210572888.26792.913.camel@beck.corsepiu.local> <1210595929.26792.921.camel@beck.corsepiu.local> Message-ID: Ralf Corsepius freenet.de> writes: > Please do so, ... I can't spot any offending extra space related to > pthread in the entire source tree: Looks like Orion fixed it already, see his reply. :-) Kevin Kofler From lesmikesell at gmail.com Mon May 12 23:19:27 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 12 May 2008 18:19:27 -0500 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <870180fe0805121505h1eb29c87i6a312b54cd82f49d@mail.gmail.com> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <20080512202246.GA11400@nostromo.devel.redhat.com> <1210623511.10395.17.camel@localhost.localdomain> <20080512203816.GB26850@nostromo.devel.redhat.com> <870180fe0805121505h1eb29c87i6a312b54cd82f49d@mail.gmail.com> Message-ID: <4828D07F.9030800@gmail.com> Jerry James wrote: > On Mon, May 12, 2008 at 3:58 PM, Colin Walters wrote: >> Well, largely our "core" stack (and by this I mean comps) does not >> (yet) have dependencies on many Java libraries. So there's not a big >> deal swapping out say our objectweb-asm for JPackage's. >> >> However, this is most definitely not a sustainable system in the long term. >> >> I sort of view JPackage as just a specific instance of the >> cross-distribution collaboration problem. Most distributions tend to >> focus primarily on dependencies driven by desktop apps or their own >> internal needs, but the general free software world is far larger than >> that, even before OpenJDK opened up a lot of Java software to us. > > So there are a bunch of Java packages that I use that I would like to > drive into *some* repository where they can get picked up and used by > others with similar needs. I've been driving towards Fedora so far. > What's a good long-term solution, then? Should I keep that up, focus > on JPackage, help figure out how the two are going to cooperate, ...? If they run on other distributions (and I can hardly imagine a java package that wouldn't) they will be more widely useful in jpackage. -- Les Mikesell lesmikesell at gmail.com From sundaram at fedoraproject.org Mon May 12 23:25:21 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 13 May 2008 04:55:21 +0530 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <870180fe0805121505h1eb29c87i6a312b54cd82f49d@mail.gmail.com> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <20080512202246.GA11400@nostromo.devel.redhat.com> <1210623511.10395.17.camel@localhost.localdomain> <20080512203816.GB26850@nostromo.devel.redhat.com> <870180fe0805121505h1eb29c87i6a312b54cd82f49d@mail.gmail.com> Message-ID: <4828D1E1.8000300@fedoraproject.org> Jerry James wrote: > On Mon, May 12, 2008 at 3:58 PM, Colin Walters wrote: >> Well, largely our "core" stack (and by this I mean comps) does not >> (yet) have dependencies on many Java libraries. So there's not a big >> deal swapping out say our objectweb-asm for JPackage's. >> >> However, this is most definitely not a sustainable system in the long term. >> >> I sort of view JPackage as just a specific instance of the >> cross-distribution collaboration problem. Most distributions tend to >> focus primarily on dependencies driven by desktop apps or their own >> internal needs, but the general free software world is far larger than >> that, even before OpenJDK opened up a lot of Java software to us. > > So there are a bunch of Java packages that I use that I would like to > drive into *some* repository where they can get picked up and used by > others with similar needs. I've been driving towards Fedora so far. > What's a good long-term solution, then? Should I keep that up, focus > on JPackage, help figure out how the two are going to cooperate, ...? If people need some software in Fedora, they are going to look for it in the Fedora repository first. Since Openjdk/icedtea is in Fedora, more java programs would build in Fedora now than before. End users shouldn't have to work through conflicting repositories or care about the language a software is written in to use it. Changes can and should be shared with other repositories and upstream software projects however. Rahul From petersen at redhat.com Tue May 13 03:10:55 2008 From: petersen at redhat.com (Jens Petersen) Date: Tue, 13 May 2008 13:10:55 +1000 Subject: [Reminder] FESCo Nominations In-Reply-To: <1210540538.6813.2.camel@kennedy> References: <1210540538.6813.2.camel@kennedy> Message-ID: <482906BF.9000708@redhat.com> > This is a reminder that the nomination period for the upcoming FESCo > election is currently underway, and lasts until June 1st, 2008 0:00 UTC. Thanks for the announcement. Are there any possibilities of rotating the FESCo meeting time? The current time is rather late for people in Asia-Pacific timezones. Perhaps if someone from this region got elected? Jens From jspaleta at gmail.com Tue May 13 03:36:29 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 12 May 2008 19:36:29 -0800 Subject: JahShaka In-Reply-To: <4827FA91.9060009@cchtml.com> References: <4827CE9D.5020409@ncsu.edu> <4827F111.1070604@nicubunu.ro> <4827FA91.9060009@cchtml.com> Message-ID: <604aa7910805122036q7657c788o734d2bee29aa99fd@mail.gmail.com> > Example: > http://www.pitivi.org/wiki/Main_Page Let me chime in for a second. I've been spending some time on looking at the options for a while now. Pitivi is THE solution that Fedora needs to support. Its feature-set is minimal at the moment but it is workable out-of-the-box when it comes to theora and raw dv editting. I've been working towards hosting a miro channel for Fedora and a set of short tutorials on how to make use of pitivi. Sadly i just didnt get it done before F9 release. I haven't been talking about it much because i wanted to surprise everyone...but my freetime didn't live up to the deadline. What this project really needs to do is find a way to drive more effort into pitivi, in terms of creating really good plugins that w can use out of the box. The parts of gstreamer that we can ship includes so very interesting things like video effects that pitivi could use... cheese uses them. Pitivi just needs developer love and its this projects best interest to try to find that love. -jef From a.badger at gmail.com Tue May 13 05:59:09 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 12 May 2008 22:59:09 -0700 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <870180fe0805121505h1eb29c87i6a312b54cd82f49d@mail.gmail.com> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <20080512202246.GA11400@nostromo.devel.redhat.com> <1210623511.10395.17.camel@localhost.localdomain> <20080512203816.GB26850@nostromo.devel.redhat.com> <870180fe0805121505h1eb29c87i6a312b54cd82f49d@mail.gmail.com> Message-ID: <48292E2D.1090702@gmail.com> Jerry James wrote: > On Mon, May 12, 2008 at 3:58 PM, Colin Walters wrote: >> Well, largely our "core" stack (and by this I mean comps) does not >> (yet) have dependencies on many Java libraries. So there's not a big >> deal swapping out say our objectweb-asm for JPackage's. >> >> However, this is most definitely not a sustainable system in the long term. >> >> I sort of view JPackage as just a specific instance of the >> cross-distribution collaboration problem. Most distributions tend to >> focus primarily on dependencies driven by desktop apps or their own >> internal needs, but the general free software world is far larger than >> that, even before OpenJDK opened up a lot of Java software to us. > > So there are a bunch of Java packages that I use that I would like to > drive into *some* repository where they can get picked up and used by > others with similar needs. I've been driving towards Fedora so far. > What's a good long-term solution, then? Should I keep that up, focus > on JPackage, help figure out how the two are going to cooperate, ...? It depends on who your target audience is. If it's Fedora, then just get them into Fedora. If it's the Linux community, then get them into JPackage and from there get them into Fedora. -Toshio From a.badger at gmail.com Tue May 13 06:26:26 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 12 May 2008 23:26:26 -0700 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <1210632587.12173.15.camel@rousalka.okg> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <1210612643.6285.5.camel@rousalka.okg> <1210613511.12520.46.camel@localhost.localdomain> <1210619487.6844.48.camel@rousalka.okg> <1210621696.12520.62.camel@localhost.localdomain> <1210632587.12173.15.camel@rousalka.okg> Message-ID: <48293492.4020905@gmail.com> Nicolas Mailhot wrote: > Le lundi 12 mai 2008 ? 15:48 -0400, Tom "spot" Callaway a ?crit : > >> * I'm not mandating that JPackage change anything. This is specifically >> targeted on handling the Fedora packages which are derived from JPackage >> packages. > > That's not realistic, if you want your matching to work you need the > tagging implemented both sides. The Fedora side is the easy one. Fedora > has still not merged the bulk of the JPackage repository. > Either I'm reading this page wrong: http://fedoraproject.org/wiki/DeepakBhole/ReasonsForKeepingJPP or there's additional rationale for .jpp that's not on that page. The only thing I'm seeing from that page is that people want to select the Fedora packages on their system that have a companion package in JPackage so that they can either remove the Fedora package in favor of the JPackage version or in order to see which packages originated in JPackage. There's no reason that I see listed on that page for JPackage to rebuild with a new group/vendor. In fact, if JPackage were to rebuild with the same group it would defeat the purpose of including that group. I'm not saying that .jpp has to go, but I will say the .jpp-in-Fedora exception was explicitly given a limit when it was voted in that revolved around the selection issue being resolved in another manner. I don't mind debating the merits of the new selection method, but changing the rules of what the requirements are once the old requirements are met does make me a bit upset. Some of the base assumptions on the ReasonsForKeepingJPP also don't seem to be in line with past thinking about third party repositories. We don't support people installing an rpm provided by an upstream on sourceforge if it's newer than the one in Fedora and back and forth. We don't support people getting packages from Mandrake if they aren't available in Fedora. We don't support people installing a python stack from pyvault to replace the one in Fedora. We should either ship repodata for JPackage in the repo, officially support JPackage packages, and stop repackaging JPackage packages for Fedora or we should stop pretending that it's a goal of ours for people to be able to switch out the Java stack provided by Fedora with the Java stack provided by JPackage, interleave versions with whichever has the newer version, and etc. (Note that this paragraph is not about packaging guidelines so it's not an option that the Packaging Committee can consider. It's probably a FESCo discussion much as the repotag discussion was an EPEL Steering Committee discussion.) -Toshio From bojan at rexursive.com Tue May 13 06:42:48 2008 From: bojan at rexursive.com (Bojan Smojver) Date: Tue, 13 May 2008 06:42:48 +0000 (UTC) Subject: Kernel updates? References: <1210329109.10161.5.camel@shrek.rexursive.com> Message-ID: Bojan Smojver rexursive.com> writes: > Any chance of pushing the F-8 kernel with that security fix > (CVE-2008-1669) into stable? I will officially stop caring about this tomorrow (he, he :-), however, this doesn't look any better: https://admin.fedoraproject.org/updates/F9/security According to this: http://lwn.net/Articles/281689/ We should all be on 2.6.25.3. Can someone confirm F9 kernels are not affected by these unspecified security issues fixed in .3? -- Bojan From A.J.Delaney at brighton.ac.uk Tue May 13 07:00:47 2008 From: A.J.Delaney at brighton.ac.uk (A.J.Delaney at brighton.ac.uk) Date: Tue, 13 May 2008 08:00:47 +0100 Subject: Ekiga + opal rebuild? In-Reply-To: <1210598933.2508.62.camel@victoria> References: <1210598933.2508.62.camel@victoria> Message-ID: <1210662047.2949.3.camel@ScaryMonster> On Mon, 2008-05-12 at 13:28 +0000, Paul W. Frields wrote: > So this very nasty Ekiga bug in at least the F-9 branch: > https://bugzilla.redhat.com/show_bug.cgi?id=441202 I can confirm this bug, which I reported upstream http://bugzilla.gnome.org/show_bug.cgi?id=532525 It's certainly an F9 specific issue and is easily fixed by the suggested opal rebuild. It would be a shame to ship Ekiga in its current unusable state.. -- Aidan Delaney From dev at nigelj.com Tue May 13 07:04:28 2008 From: dev at nigelj.com (Nigel Jones) Date: Tue, 13 May 2008 19:04:28 +1200 Subject: Kernel updates? In-Reply-To: References: <1210329109.10161.5.camel@shrek.rexursive.com> Message-ID: <48293D7C.60709@nigelj.com> Bojan Smojver wrote: > Bojan Smojver rexursive.com> writes: > > >> Any chance of pushing the F-8 kernel with that security fix >> (CVE-2008-1669) into stable? >> > > I will officially stop caring about this tomorrow (he, he :-), however, this > doesn't look any better: > > https://admin.fedoraproject.org/updates/F9/security > https://admin.fedoraproject.org/updates/search/CVE-2008-1669 shows nothing. The crazy thing is all the bugs that the CVE tracking bug depends on, are embargo'd (most likely for EL-3-5+update releases or something). Can't see anything in koji etc. Now I'm not saying that there is no reason to worry, but it (cuse the pun) bugs me that that as soon as a CVE comes out, it must be patched yesterday. The embargo on the tracker bug wasn't open to Fedora contributors and was only released on the 7th. It's a pity we live in a society of fear, but I understand. - Nigel From bojan at rexursive.com Tue May 13 07:21:31 2008 From: bojan at rexursive.com (Bojan Smojver) Date: Tue, 13 May 2008 07:21:31 +0000 (UTC) Subject: Kernel updates? References: <1210329109.10161.5.camel@shrek.rexursive.com> <48293D7C.60709@nigelj.com> Message-ID: Nigel Jones nigelj.com> writes: > https://admin.fedoraproject.org/updates/search/CVE-2008-1669 shows nothing. Although that particular one has been fixed by building 2.6.24.7: http://lwn.net/Articles/281225/ http://koji.fedoraproject.org/koji/buildinfo?buildID=48407 However, F9 is 2.6.25 based, so that isn't going to apply. And, 2.6.24 isn't getting any more updates either and this says that everyone on 2.6.24 should go to 2.6.25.3, which has fixes to yet another two security problems: http://lwn.net/Articles/281689/ I would think these kernel rebuilds shouldn't be all that difficult to do and I don't know what the holdup is. When build time is added to push to stable time, it all adds up to significant number of days for Fedora having an unpatched kernel containing known security problems. -- Bojan From nicolas.mailhot at laposte.net Tue May 13 07:47:42 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 13 May 2008 09:47:42 +0200 (CEST) Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <48293492.4020905@gmail.com> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <1210612643.6285.5.camel@rousalka.okg> <1210613511.12520.46.camel@localhost.localdomain> <1210619487.6844.48.camel@rousalka.okg> <1210621696.12520.62.camel@localhost.localdomain> <1210632587.12173.15.camel@rousalka.okg> <48293492.4020905@gmail.com> Message-ID: <41074.192.54.193.59.1210664862.squirrel@rousalka.dyndns.org> Le Mar 13 mai 2008 08:26, Toshio Kuratomi a ?crit : > Nicolas Mailhot wrote: >> Le lundi 12 mai 2008 ? 15:48 -0400, Tom "spot" Callaway a ?crit : >> >>> * I'm not mandating that JPackage change anything. This is >>> specifically >>> targeted on handling the Fedora packages which are derived from >>> JPackage >>> packages. >> >> That's not realistic, if you want your matching to work you need the >> tagging implemented both sides. The Fedora side is the easy one. >> Fedora >> has still not merged the bulk of the JPackage repository. >> > Either I'm reading this page wrong: > > http://fedoraproject.org/wiki/DeepakBhole/ReasonsForKeepingJPP > > or there's additional rationale for .jpp that's not on that page. > > The only thing I'm seeing from that page is that people want to select > the Fedora packages on their system that have a companion package in > JPackage so that they can either remove the Fedora package in favor of > the JPackage version or in order to see which packages originated in > JPackage. The selection process is of course symetric, like any rpm/yum op. Users basically switch back and forth between the two java stacks till they find the one that works best for them. > There's no reason that I see listed on that page for > JPackage > to rebuild with a new group/vendor. In fact, if JPackage were to > rebuild with the same group it would defeat the purpose of including > that group. If you want to select on group as it is proposed now you need to put a unique group in the specs jpp-side too (group that won't be the same as the fedora one). > I'm not saying that .jpp has to go, but I will say the .jpp-in-Fedora > exception was explicitly given a limit when it was voted in that > revolved around the selection issue being resolved in another manner. I think the java group has already said it would implement changes when a solution is presented. (not because the technical arguments presented were convincing, just to have Fedora instances grind some other axes). And I'd be the first to advocate expending energy just to make some packages a bit cleaner. However, sitting on the fence there and having worked both sides I'm just a bit affronted that we're happy asking a lot of efforts of others to replace a harmless kludge, and the solution presented scores no better in the cleanliness scale (in fact since it's very new and quirks bits no one touched before it could very possibly end up much worse). a lot of efforts is asked of others in the name of purity, an > Some of the base assumptions on the ReasonsForKeepingJPP also don't > seem > to be in line with past thinking about third party repositories. We > don't support people installing an rpm provided by an upstream on > sourceforge if it's newer than the one in Fedora and back and forth. > We don't support people ... We don't reuse extensively the work done in those repositories. So wrong comparison here. > We should either ship repodata for JPackage in the repo, officially > support JPackage packages, and stop repackaging JPackage packages for > Fedora or we should stop pretending that it's a goal of ours for > people to be able to switch out the Java stack provided by Fedora > with the Java stack provided by JPackage, And I want a pony. The current situation is that way because there are not enough Java packagers both Fedora and JPackage-side, so we share efforts, and any alternative that requires more manpower we don't have is going to result in a worse situation for our users. I mean, we have not even managed to package major eclipse plugins like WTP so far, and eclipse is a important but very small part of the FLOSS java code out there. -- Nicolas Mailhot From nicolas.mailhot at laposte.net Tue May 13 07:49:44 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 13 May 2008 09:49:44 +0200 (CEST) Subject: Kernel updates? In-Reply-To: References: <1210329109.10161.5.camel@shrek.rexursive.com> <48293D7C.60709@nigelj.com> Message-ID: <47297.192.54.193.59.1210664984.squirrel@rousalka.dyndns.org> Le Mar 13 mai 2008 09:21, Bojan Smojver a ?crit : > > However, F9 is 2.6.25 based, so that isn't going to apply. And, 2.6.24 > isn't > getting any more updates either and this says that everyone on 2.6.24 > should go > to 2.6.25.3, which has fixes to yet another two security problems: At least one of the 2.6.25.3 is already in the F9 kernel (it was a F9 blocker). Don't know if it's one of the two security bits though. -- Nicolas Mailhot From rc040203 at freenet.de Tue May 13 07:57:42 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 13 May 2008 09:57:42 +0200 Subject: FC10: strange cmake error In-Reply-To: <4828AF7D.6080707@cora.nwra.com> References: <1210572888.26792.913.camel@beck.corsepiu.local> <4828AF7D.6080707@cora.nwra.com> Message-ID: <1210665462.26792.934.camel@beck.corsepiu.local> On Mon, 2008-05-12 at 14:58 -0600, Orion Poplawski wrote: > Ralf Corsepius wrote: > > Hi, > > > > I am facing a strange cmake-related error when trying to upgrade > > OpenSceneGraph to version 2.4.0 on FC10: > > > > ... > > -- Looking for pthread_yield > > CMake Error at CMakeLists.txt:9 (ADD_EXECUTABLE): > > Target "cmTryCompileExec" links to item " -lpthread" which has leading > > or > > trailing whitespace. This is now an error according to policy > > CMP0004. > > I think attached patch is what you need. I think a lot of cmake users > (including myself) are confused about using lists. > > Build: http://koji.fedoraproject.org/koji/taskinfo?taskID=605508 > > Still get a cmake warning, that probably needs to get fixed in cmake. Thanks, everyone. This patch at least gets building this package going again ;) Ralf From bojan at rexursive.com Tue May 13 08:28:01 2008 From: bojan at rexursive.com (Bojan Smojver) Date: Tue, 13 May 2008 08:28:01 +0000 (UTC) Subject: Kernel updates? References: <1210329109.10161.5.camel@shrek.rexursive.com> <48293D7C.60709@nigelj.com> <47297.192.54.193.59.1210664984.squirrel@rousalka.dyndns.org> Message-ID: Nicolas Mailhot laposte.net> writes: > At least one of the 2.6.25.3 is already in the F9 kernel (it was a F9 > blocker). I'm guessing you are referring to CVE-2008-1675, which was fixed in 2.6.25-14.fc9: http://koji.fedoraproject.org/koji/buildinfo?buildID=47791 > Don't know if it's one of the two security bits though. I think not. They were discover after that build. -- Bojan From markmc at redhat.com Tue May 13 08:45:00 2008 From: markmc at redhat.com (Mark McLoughlin) Date: Tue, 13 May 2008 09:45:00 +0100 Subject: KVM and the new virtio drivers In-Reply-To: <47EA3DBC.8000701@conversis.de> References: <47EA3DBC.8000701@conversis.de> Message-ID: <1210668300.27471.4.camel@muff> Hi, (Replying to an old post just for the record) On Wed, 2008-03-26 at 13:12 +0100, Dennis Jacobfeuerborn wrote: > I'm trying to get a F9 guest running using the new virtio block device but > seem to run into trouble with LVM. I rebuilt the initrd in the guest adding > the options "--with=virtio_pci --with=virtio_blk" and after booting the > kernel correctly detects vd1 and vd2 but then fails to find any volume > groups. Using "media=disk" instead of "if=virtio" brings the guest up fine. > Is there a special option needed to make the kernel/initrd find the volume > group on these virtual block devices? lvm got a patch to make it recognise "virtblk" in /proc/devices not long after you posted: * Wed Apr 2 2008 Jeremy Katz - 2.02.33-11 - Adjust for new name for vio disks (from danpb) - And fix the build (also from danpb) > Are these drivers stable enough to maybe put them into the initrd by > default? I would be nice to be able to boot a F9 guest with the > paravirtualized drivers out of the box without having to build a custom > initrd image. If you install the guest using virtio, then the drivers will automatically be included in the initrd created during the install. If you switch to virtio post-install, you need to use --with=virtio_blk and --with=virtio_pci initially, but will then be automatically included in any new initrds created while you're running the guest with virtio. Cheers, Mark. From nicolas.mailhot at laposte.net Tue May 13 09:19:09 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 13 May 2008 11:19:09 +0200 (CEST) Subject: Kernel updates? In-Reply-To: References: <1210329109.10161.5.camel@shrek.rexursive.com> <48293D7C.60709@nigelj.com> <47297.192.54.193.59.1210664984.squirrel@rousalka.dyndns.org> Message-ID: <51523.192.54.193.59.1210670349.squirrel@rousalka.dyndns.org> Le Mar 13 mai 2008 10:28, Bojan Smojver a ?crit : > Nicolas Mailhot laposte.net> writes: > >> At least one of the 2.6.25.3 is already in the F9 kernel (it was a >> F9 >> blocker). > > I'm guessing you are referring to CVE-2008-1675, which was fixed in > 2.6.25-14.fc9: I'm refering to the 2.6.25-13.fc9 Oops fix:p -- Nicolas Mailhot From oliver at linux-kernel.at Tue May 13 09:30:39 2008 From: oliver at linux-kernel.at (Oliver Falk) Date: Tue, 13 May 2008 11:30:39 +0200 Subject: smolts.org 's broken... In-Reply-To: <48172E41.9030804@redhat.com> References: <4816DA04.1010303@linux-kernel.at> <48172E41.9030804@redhat.com> Message-ID: <48295FBF.2010300@linux-kernel.at> Eric Sandeen wrote: > Oliver Falk wrote: >> Hi! >> >> Just want to mention that smolts.org static pages (at least >> http://smolts.org/static/stats/stats.html) is broken. If you reload the >> page a few times, you'll see the date jumping around (Apr 23, Apr 9, Apr >> 17)... Seems it's loadbalanced and not all servers have the same content >> and even the latest content you can get (Apr 23) is not up2date. :-( >> >> -of >> >> PS: Keep me posted CC:... >> > > Ya. I've been harping on this too, for weeks. ;) Nothing changed yet!!! -of From oliver at linux-kernel.at Tue May 13 09:30:39 2008 From: oliver at linux-kernel.at (Oliver Falk) Date: Tue, 13 May 2008 11:30:39 +0200 Subject: smolts.org 's broken... In-Reply-To: <48172E41.9030804@redhat.com> References: <4816DA04.1010303@linux-kernel.at> <48172E41.9030804@redhat.com> Message-ID: <48295FBF.2010300@linux-kernel.at> Eric Sandeen wrote: > Oliver Falk wrote: >> Hi! >> >> Just want to mention that smolts.org static pages (at least >> http://smolts.org/static/stats/stats.html) is broken. If you reload the >> page a few times, you'll see the date jumping around (Apr 23, Apr 9, Apr >> 17)... Seems it's loadbalanced and not all servers have the same content >> and even the latest content you can get (Apr 23) is not up2date. :-( >> >> -of >> >> PS: Keep me posted CC:... >> > > Ya. I've been harping on this too, for weeks. ;) Nothing changed yet!!! -of From optimizationkit at gmail.com Tue May 13 10:35:11 2008 From: optimizationkit at gmail.com (M) Date: Tue, 13 May 2008 12:35:11 +0200 Subject: question about GRUB and Ext4dev Message-ID: <58a220fa0805130335t6c8c7ce8tc136002b80ce6208@mail.gmail.com> Hi, I installed F9 on an ext4 partition (/ and /home) - GRUB does not start properly, it stops after printing "GRUB" on the screen. Does F9 GRUB support such configuration? Regards, Michal From nphilipp at redhat.com Tue May 13 10:50:03 2008 From: nphilipp at redhat.com (Nils Philippsen) Date: Tue, 13 May 2008 12:50:03 +0200 Subject: F9 (bug?) Superblock features different from backup In-Reply-To: <48261E91.9040203@redhat.com> References: <3da3b5b40805101439y56886e24h2c2a2b36681e7783@mail.gmail.com> <48261ACA.1030907@redhat.com> <3da3b5b40805101503k24bd9afbi53bd4ffd8553caf@mail.gmail.com> <48261E91.9040203@redhat.com> Message-ID: <1210675803.4565.53.camel@gibraltar.str.redhat.com> On Sat, 2008-05-10 at 17:15 -0500, Eric Sandeen wrote: > Ahmed Kamal wrote: > > Just out of curiosity, could you let me know what kind of changes the > > kernel makes to the superblock without asking first! That sounds interesting > > sure, things like the first time a "large" (> 2G file) is written it > will set a flag to that effect. > > Or the first time an extent-based file is created on ext4. > > We've talked about removing these, actually, and requiring the flags to > be set at mkfs time, or via tune2fs, if you wish to use the feature, > rather than silently turning them on. But make that the default for new filesystems pretty please kthxbye ;-). Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From jwboyer at gmail.com Tue May 13 10:52:47 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 13 May 2008 05:52:47 -0500 Subject: [Reminder] FESCo Nominations In-Reply-To: <482906BF.9000708@redhat.com> References: <1210540538.6813.2.camel@kennedy> <482906BF.9000708@redhat.com> Message-ID: <20080513055247.11361275@vader.jdub.homelinux.org> On Tue, 13 May 2008 13:10:55 +1000 Jens Petersen wrote: > > This is a reminder that the nomination period for the upcoming FESCo > > election is currently underway, and lasts until June 1st, 2008 0:00 UTC. > > Thanks for the announcement. > > Are there any possibilities of rotating the FESCo meeting time? > The current time is rather late for people in Asia-Pacific timezones. > Perhaps if someone from this region got elected? Sure, the new FESCo can address that if needed. josh From mcepl at redhat.com Tue May 13 10:55:39 2008 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 13 May 2008 12:55:39 +0200 Subject: Changing things in long-closed bugs? References: <20080512184807.GI1139409@hiwaay.net> Message-ID: On Mon, 12 May 2008 13:48:07 -0500, Chris Adams scripst: > I've received several emails from bugzilla now about the severity, > product, etc. being changed on bugs I'm the reporter or a CC on. These > are bugs that have been closed for a while (1-2 years or more). Does > this (a) really need to be changed and (b) really need to send email? Several? I've got 350+ of them! Holy crap. Mat?j -- The content of this message is licensed under a Creative Commons Attribution 3.0 License, Some Rights Reserved. http://creativecommons.org/licenses/by/3.0/us/ From bpepple at fedoraproject.org Tue May 13 11:14:29 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Tue, 13 May 2008 07:14:29 -0400 Subject: [Reminder] FESCo Nominations In-Reply-To: <482906BF.9000708@redhat.com> References: <1210540538.6813.2.camel@kennedy> <482906BF.9000708@redhat.com> Message-ID: <1210677269.9037.2.camel@nixon> On Tue, 2008-05-13 at 13:10 +1000, Jens Petersen wrote: > > This is a reminder that the nomination period for the upcoming FESCo > > election is currently underway, and lasts until June 1st, 2008 0:00 UTC. > > Thanks for the announcement. > > Are there any possibilities of rotating the FESCo meeting time? > The current time is rather late for people in Asia-Pacific timezones. > Perhaps if someone from this region got elected? Yeah, some of the first items the newly elected FESCo will decide will be the meeting time they want to use, and electing a new chair. Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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 mcepl at redhat.com Tue May 13 11:02:50 2008 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 13 May 2008 13:02:50 +0200 Subject: Xorg 1.5 missed the train? References: <4825F834.1020001@gmail.com> <1210491519.10397.9.camel@behdad.behdad.org> <4826B04A.8020703@gmail.com> <1210617055.1248.46.camel@localhost.localdomain> Message-ID: > I do the best I can but I'm not a superhero. As a superhero, you shouldn't lie :-)! Mat?j -- The content of this message is licensed under a Creative Commons Attribution 3.0 License, Some Rights Reserved. http://creativecommons.org/licenses/by/3.0/us/ From mcepl at redhat.com Tue May 13 11:08:09 2008 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 13 May 2008 13:08:09 +0200 Subject: Dell Laptop References: <1210428668.3864.2.camel@scrappy.miketc.com> Message-ID: On Sat, 10 May 2008 13:12:12 -0400, Jon Stanley scripst: > On Sat, May 10, 2008 at 10:11 AM, Mike Chambers wrote: > >> http://www.staples.com/office/supplies/p4_Dell-Inspiron-1526-Notebook-PC >> %27s_220198_Business_Supplies_1_10051_FEATURED:SC3:CG71:DP4118 > > Not 100% the right place to talk about this, but looking there, I > noticed that it had the "Dell Wireless" (read: Broadcom) wifi chipset. > This will likely give you no end of trouble from what I've seen (note > that I have no personal experience, just horror stories that I've > heard). Actually, to make this thread at least a little bit on topic (you know, this is fedora-devel, not fedora list), I have to continue on my line about superheros -- to my biggest satisfaction John Linville made my BCM4318 working in the late F8 (or was it really early F9/Rawhide; I am not sure). I am quite sure it needs a lot more stabilization and testing (which makes it a topic here) but I think you can try to get it. Of course, if you prefer your notebook to be more likely to just work (and I had my fair chance of problems with iwl3945 as well), then Intel chips are much more supported. Mat?j -- The content of this message is licensed under a Creative Commons Attribution 3.0 License, Some Rights Reserved. http://creativecommons.org/licenses/by/3.0/us/ From mcepl at redhat.com Tue May 13 11:09:07 2008 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 13 May 2008 13:09:07 +0200 Subject: Dell Laptop References: <1210428668.3864.2.camel@scrappy.miketc.com> <3da3b5b40805111036vd11dbd3y9e29e886631f802c@mail.gmail.com> Message-ID: On Sun, 11 May 2008 20:36:34 +0300, Ahmed Kamal scripst: > Since we're on the topic, when getting laptops, I can easily identify > the "specs" I need. But I am totally lost as to which brand I should be > getting! I just have no idea about the quality of Dell vs HP vs Acer ... > blah. I end up getting a toshiba, just because my previous one was a > toshiba as well! Is there some website/database, that provides > statistical data about the reliability and/or performance of similarly > spec'ed different brands of laptops? So I can have a good estimation of > which brand is the current king I am quite happy with HP Compaq -- intel wifi and i965GM graphics (that's actually much bigger problem than wifi). Mat?j -- The content of this message is licensed under a Creative Commons Attribution 3.0 License, Some Rights Reserved. http://creativecommons.org/licenses/by/3.0/us/ From mcepl at redhat.com Tue May 13 11:15:15 2008 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 13 May 2008 13:15:15 +0200 Subject: FESCo Proposal for blocking older version of autoconf & automake References: <1209999548.32107.11.camel@kennedy> <481F2986.8010509@redhat.com> <1210002669.26792.65.camel@beck.corsepiu.local> <481FD064.6050307@ncsu.edu> <1210045081.4658.7.camel@localhost.localdomain> <481FD3D5.5070206@ncsu.edu> <48207309.3040403@redhat.com> <1210321932.26792.817.camel@beck.corsepiu.local> <4824184A.1010508@redhat.com> <4824856E.3080109@gmail.com> Message-ID: <3r9of5xq9c.ln2@ppp1053.in.ipex.cz> On Fri, 09 May 2008 10:10:06 -0700, Toshio Kuratomi scripst: > The list of packages which presently BuildRequire the > autotools is very small so I'm not sure this is the case. You are missing the point -- package which is based on the upstream tarball using autotools doesn't BuildRequire them. Only in the hopeless situation when there is a need of configure rebuild, you need to BuildRequire them. Your finding says unfortunately absolutely nothing. Mat?j -- The content of this message is licensed under a Creative Commons Attribution 3.0 License, Some Rights Reserved. http://creativecommons.org/licenses/by/3.0/us/ From mcepl at redhat.com Tue May 13 11:27:30 2008 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 13 May 2008 13:27:30 +0200 Subject: Flash on rawhide References: <1210086745.2716.6.camel@scrappy.miketc.com> <20080506152222.GA21258@nostromo.devel.redhat.com> <1210087782.2716.8.camel@scrappy.miketc.com> <20080508150650.GA18366@jadzia.bu.edu> Message-ID: <2iaof5xq9c.ln2@ppp1053.in.ipex.cz> On Thu, 08 May 2008 11:06:50 -0400, Matthew Miller scripst: > On Tue, May 06, 2008 at 10:29:42AM -0500, Mike Chambers wrote: >> > > Any ideas? >> > You probably need libflashsupport.i386. >> That did the trick, thanks notting. Hrm, should that be installed by > > So, didn't work for me. I had both the x86_64 and i386 versions > installed; no sound. I removed them both, and the flash plugin itself, > and reinstalled just the flash plugin and libflashsupport.i386, and > still no sound. Hmmm. So, you have installed something like this? [matej at hubmaier ~]$ rpm -qa firefox\* nsplugin\* \*flash\* | sort firefox-debuginfo-3.0-0.60.beta5.fc9.x86_64 firefox-3.0-0.60.beta5.fc9.x86_64 flash-plugin-9.0.124.0-release.i386 libflashsupport-000-0.5.svn20070904.i386 libflashsupport-000-0.5.svn20070904.x86_64 nspluginwrapper-debuginfo-0.9.91.5-28.fc9.i386 nspluginwrapper-debuginfo-0.9.91.5-28.fc9.x86_64 nspluginwrapper-0.9.91.5-28.fc9.i386 nspluginwrapper-0.9.91.5-28.fc9.x86_64 [matej at hubmaier ~]$ no swfdec-mozilla, you have restarted firefox and you cannot play http://www.youtube.com/watch?v=NkOuLZ2zcY0&feature=related ? Mat?j -- The content of this message is licensed under a Creative Commons Attribution 3.0 License, Some Rights Reserved. http://creativecommons.org/licenses/by/3.0/us/ From dr.diesel at gmail.com Tue May 13 11:48:41 2008 From: dr.diesel at gmail.com (Dr. Diesel) Date: Tue, 13 May 2008 06:48:41 -0500 Subject: Anyone else with hard freezes? In-Reply-To: <1210398432.17530.0.camel@optimus> References: <2a28d2ab0805061455l9afae56p8a86218d08bc4b92@mail.gmail.com> <2a28d2ab0805061526o55c58b80y5fceed9375555ffa@mail.gmail.com> <1210112921.6222.9.camel@optimus> <2a28d2ab0805061530j3a8aa79ehb51d96afedaad644@mail.gmail.com> <1210116098.6222.11.camel@optimus> <2a28d2ab0805081558q3fdb4b94hf41f40db0253f015@mail.gmail.com> <80d7e4090805081625m111b7955v2c96d864275334b2@mail.gmail.com> <2a28d2ab0805081723q6a3537d7n93db59501cf23b16@mail.gmail.com> <2a28d2ab0805090336j78fe2772q1df6283e3c5d38cf@mail.gmail.com> <1210398432.17530.0.camel@optimus> Message-ID: <2a28d2ab0805130448s2b3e8c8aw5e526bd04949d60a@mail.gmail.com> I'm on my longest run without a crash, the only thing different is I disabled ntpd and avahi-daemon. Andy On Sat, May 10, 2008 at 12:47 AM, Dave Airlie wrote: > > > On Fri, 2008-05-09 at 05:36 -0500, Dr. Diesel wrote: > > Ok, that wasn't it either! > > try booting with nohz maybe. > > crazy but worth a go. > > Dave. > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org From gnomeuser at gmail.com Tue May 13 12:00:57 2008 From: gnomeuser at gmail.com (David Nielsen) Date: Tue, 13 May 2008 14:00:57 +0200 Subject: question about GRUB and Ext4dev In-Reply-To: <58a220fa0805130335t6c8c7ce8tc136002b80ce6208@mail.gmail.com> References: <58a220fa0805130335t6c8c7ce8tc136002b80ce6208@mail.gmail.com> Message-ID: <1dedbbfc0805130500l3cd8e12crdb9ebe498ed382ec@mail.gmail.com> 2008/5/13 M : > Hi, > > I installed F9 on an ext4 partition (/ and /home) - GRUB does not > start properly, it stops after printing "GRUB" on the screen. Does F9 > GRUB support such configuration? > > Regards, > Michal > Grub doesn't support ext4, you need to have a seperate /boot that is in a supported format such as ext3. Our friends in the openSUSE camp have a Google Summer of Code student working on this: http://code.google.com/soc/2008/suse/appinfo.html?csaid=91DC4C762E7EE6D7 - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From stickster at gmail.com Tue May 13 12:03:27 2008 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 13 May 2008 12:03:27 +0000 Subject: Ekiga + opal rebuild? In-Reply-To: <1210662047.2949.3.camel@ScaryMonster> References: <1210598933.2508.62.camel@victoria> <1210662047.2949.3.camel@ScaryMonster> Message-ID: <1210680207.10256.245.camel@victoria> On Tue, 2008-05-13 at 08:00 +0100, A.J.Delaney at brighton.ac.uk wrote: > On Mon, 2008-05-12 at 13:28 +0000, Paul W. Frields wrote: > > So this very nasty Ekiga bug in at least the F-9 branch: > > https://bugzilla.redhat.com/show_bug.cgi?id=441202 > I can confirm this bug, which I reported upstream > http://bugzilla.gnome.org/show_bug.cgi?id=532525 > > It's certainly an F9 specific issue and is easily fixed by the suggested > opal rebuild. > > It would be a shame to ship Ekiga in its current unusable state.. The fixed packages are in koji and bodhi now. Ekiga was removed from the default environment in the Live CD (and, I think, from the default installation package set) because of this problem. If you truly care about this package, please show it: 1. Visit bodhi, and try the updates with Fedora 9 2. Once you've tried it out and find it works, cast a karma vote in favor of it being pushed to stable It *is* unfortunate that this wasn't fixed in time to ship on the default media, but thanks to the software update tools, the new persistent Live capabilities, and the huge array of tools like livecd-tools and pungi to make runnable or installable media, it's not an all-or-nothing game. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From optimizationkit at gmail.com Tue May 13 12:21:26 2008 From: optimizationkit at gmail.com (M) Date: Tue, 13 May 2008 14:21:26 +0200 Subject: question about GRUB and Ext4dev In-Reply-To: <1dedbbfc0805130500l3cd8e12crdb9ebe498ed382ec@mail.gmail.com> References: <58a220fa0805130335t6c8c7ce8tc136002b80ce6208@mail.gmail.com> <1dedbbfc0805130500l3cd8e12crdb9ebe498ed382ec@mail.gmail.com> Message-ID: <58a220fa0805130521x1207f75coe577328f1007378b@mail.gmail.com> 2008/5/13 David Nielsen : > > > 2008/5/13 M : > > > > Hi, > > > > I installed F9 on an ext4 partition (/ and /home) - GRUB does not > > start properly, it stops after printing "GRUB" on the screen. Does F9 > > GRUB support such configuration? > > > > Regards, > > Michal > > > > Grub doesn't support ext4, you need to have a seperate /boot Ok, thanks for the information. > that is in a > supported format such as ext3. Our friends in the openSUSE camp have a > Google Summer of Code student working on this: > > > http://code.google.com/soc/2008/suse/appinfo.html?csaid=91DC4C762E7EE6D7 > > - David > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From sandeen at redhat.com Tue May 13 12:50:09 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Tue, 13 May 2008 07:50:09 -0500 Subject: question about GRUB and Ext4dev In-Reply-To: <58a220fa0805130335t6c8c7ce8tc136002b80ce6208@mail.gmail.com> References: <58a220fa0805130335t6c8c7ce8tc136002b80ce6208@mail.gmail.com> Message-ID: <48298E81.604@redhat.com> M wrote: > Hi, > > I installed F9 on an ext4 partition (/ and /home) - GRUB does not > start properly, it stops after printing "GRUB" on the screen. Does F9 > GRUB support such configuration? > > Regards, > Michal Grub won't work on an ext4dev filesystem, and I thought anaconda would prevent you from putting /boot on ext4. It didn't? You'll need to make /boot ext2 or ext3. -Eric From sandeen at redhat.com Tue May 13 12:50:55 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Tue, 13 May 2008 07:50:55 -0500 Subject: F9 (bug?) Superblock features different from backup In-Reply-To: <1210675803.4565.53.camel@gibraltar.str.redhat.com> References: <3da3b5b40805101439y56886e24h2c2a2b36681e7783@mail.gmail.com> <48261ACA.1030907@redhat.com> <3da3b5b40805101503k24bd9afbi53bd4ffd8553caf@mail.gmail.com> <48261E91.9040203@redhat.com> <1210675803.4565.53.camel@gibraltar.str.redhat.com> Message-ID: <48298EAF.6020606@redhat.com> Nils Philippsen wrote: > On Sat, 2008-05-10 at 17:15 -0500, Eric Sandeen wrote: >> Ahmed Kamal wrote: >>> Just out of curiosity, could you let me know what kind of changes the >>> kernel makes to the superblock without asking first! That sounds interesting >> sure, things like the first time a "large" (> 2G file) is written it >> will set a flag to that effect. >> >> Or the first time an extent-based file is created on ext4. >> >> We've talked about removing these, actually, and requiring the flags to >> be set at mkfs time, or via tune2fs, if you wish to use the feature, >> rather than silently turning them on. > > But make that the default for new filesystems pretty please kthxbye ;-). Make which the default? :) But of course sane defaults would be chosen for mkfs... -Eric From cjdahlin at ncsu.edu Tue May 13 13:01:02 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Tue, 13 May 2008 09:01:02 -0400 Subject: JahShaka In-Reply-To: <604aa7910805122036q7657c788o734d2bee29aa99fd@mail.gmail.com> References: <4827CE9D.5020409@ncsu.edu> <4827F111.1070604@nicubunu.ro> <4827FA91.9060009@cchtml.com> <604aa7910805122036q7657c788o734d2bee29aa99fd@mail.gmail.com> Message-ID: <4829910E.6070108@ncsu.edu> Jeff Spaleta wrote: >> Example: >> http://www.pitivi.org/wiki/Main_Page >> > > > Let me chime in for a second. I've been spending some time on looking > at the options for a while now. Pitivi is THE solution that Fedora > needs to support. Its feature-set is minimal at the moment but it is > workable out-of-the-box when it comes to theora and raw dv editting. > I've been working towards hosting a miro channel for Fedora and a set > of short tutorials on how to make use of pitivi. Sadly i just didnt > get it done before F9 release. I haven't been talking about it much > because i wanted to surprise everyone...but my freetime didn't live up > to the deadline. > > What this project really needs to do is find a way to drive more > effort into pitivi, in terms of creating really good plugins that w > can use out of the box. The parts of gstreamer that we can ship > includes so very interesting things like video effects that pitivi > could use... cheese uses them. Pitivi just needs developer love and > its this projects best interest to try to find that love. > > -jef > > Pitivi is nice for little home movies, but it is NOT an industrial strength NLE and I think it would do more harm to itself than good if it tried to be. It will keep Joe User very happy, but not the prosumer crowd. And trying to give Cinelerra to those people is just embarrassing. Its about as stable as win98 and kludgey as hell. --CJD From karsten at redhat.com Tue May 13 13:35:32 2008 From: karsten at redhat.com (Karsten Hopp) Date: Tue, 13 May 2008 15:35:32 +0200 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: References: <1209999548.32107.11.camel@kennedy> <481F2986.8010509@redhat.com> <1210002669.26792.65.camel@beck.corsepiu.local> <481FD064.6050307@ncsu.edu> <1210045081.4658.7.camel@localhost.localdomain> <481FD3D5.5070206@ncsu.edu> <48207309.3040403@redhat.com> <1210321932.26792.817.camel@beck.corsepiu.local> <4824184A.1010508@redhat.com> Message-ID: <48299924.2070704@redhat.com> Jason L Tibbitts III schrieb: >>>>>> "KH" == Karsten Hopp writes: > > KH> I'd like to see a reviewer guideline instead that new packages > KH> should be checked if they really need to run autofoo during the > KH> build and if they really require to be built with ancient autofoo. > > Could you write a draft for consideration by the packaging committee? > List it in http://fedoraproject.org/wiki/PackagingDrafts/DraftsTodo > and the committee will take a look. > > Please be sure that the draft provides sufficient information on how > reviewers can detect and how packagers can avoid the behavior you > would like to discourage. > > - J< > The initial version is at http://fedoraproject.org/wiki/PackagingDrafts/AutoConf. Karsten From nicu_fedora at nicubunu.ro Tue May 13 13:39:38 2008 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Tue, 13 May 2008 16:39:38 +0300 Subject: JahShaka In-Reply-To: <4829910E.6070108@ncsu.edu> References: <4827CE9D.5020409@ncsu.edu> <4827F111.1070604@nicubunu.ro> <4827FA91.9060009@cchtml.com> <604aa7910805122036q7657c788o734d2bee29aa99fd@mail.gmail.com> <4829910E.6070108@ncsu.edu> Message-ID: <48299A1A.5040501@nicubunu.ro> Casey Dahlin wrote: > Pitivi is nice for little home movies, but it is NOT an industrial > strength NLE and I think it would do more harm to itself than good if it > tried to be. It will keep Joe User very happy, but not the prosumer But we are not allowed (by law) to include something that, according to your definition, will make the prosumer crowd happy. What to do? > crowd. And trying to give Cinelerra to those people is just > embarrassing. Its about as stable as win98 and kludgey as hell. Well, in my experience Cinelerra is worse than Win98, maybe like Windows Me :p But, again, due to the codecs, Cinelerra is not included in Fedora either... You may consider packaging JahShaka at Livna/Rpmfusion. Ptitivi in Fedora proper for everyone and JahShaka in Livna for those who are allowed by local law. -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From cjdahlin at ncsu.edu Tue May 13 13:49:13 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Tue, 13 May 2008 09:49:13 -0400 Subject: JahShaka In-Reply-To: <48299A1A.5040501@nicubunu.ro> References: <4827CE9D.5020409@ncsu.edu> <4827F111.1070604@nicubunu.ro> <4827FA91.9060009@cchtml.com> <604aa7910805122036q7657c788o734d2bee29aa99fd@mail.gmail.com> <4829910E.6070108@ncsu.edu> <48299A1A.5040501@nicubunu.ro> Message-ID: <48299C59.20300@ncsu.edu> Nicu Buculei wrote: > Casey Dahlin wrote: >> Pitivi is nice for little home movies, but it is NOT an industrial >> strength NLE and I think it would do more harm to itself than good if >> it tried to be. It will keep Joe User very happy, but not the prosumer > > But we are not allowed (by law) to include something that, according > to your definition, will make the prosumer crowd happy. What to do? > This is in practice. The key issue here is the nature of the interface and kinds of features exposed, not the codecs. It just so happens that all the good prosumer options are a bit less than patent-friendly, its not because it must be that way. >> crowd. And trying to give Cinelerra to those people is just >> embarrassing. Its about as stable as win98 and kludgey as hell. > > Well, in my experience Cinelerra is worse than Win98, maybe like > Windows Me :p But, again, due to the codecs, Cinelerra is not included > in Fedora either... > > You may consider packaging JahShaka at Livna/Rpmfusion. Ptitivi in > Fedora proper for everyone and JahShaka in Livna for those who are > allowed by local law. > Or I could hike upstream and make JahShaka use gstreamer.... hmm.... --CJD From jkeating at redhat.com Tue May 13 14:01:24 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 13 May 2008 10:01:24 -0400 Subject: The Prophecy of the 9 comes true (Fedora 9 walks the earth!) Message-ID: <1210687284.3170.30.camel@localhost.localdomain> An ancient text prophesised this day would come, detailing the fate of all who are willing to accept what is offered to them: http://docs.fedoraproject.org/release-notes/f9/index.html And that day has come: the Computer said "I will convert these unbelievers, and now that I have Sulphur it will be easy." At that, the heavens opened and burning Sulphur descended upon all the world, taking on many different forms. First to hit were the live USB keys. The heathens cried out for mercy, but were powerless to resist. The sticks were damn persistent and non-destructively formatted - non-destructively! They showed up everywhere, casting out demons from computers infected by the dark one of the interwebs and rescuing lost data from the influence of the evil crackers. Then, when they thought it couldn't get any worse, the whole world was cast into shadow. Lit only by the dim light from their computer screens, they discovered a mysterious message scrolling across: "K K K K K K K K 4 4 4 4 4 4". The screens flickered, and the light flooded out so that the shadow was lifted. After their eyes had adjusted they saw something so beautiful, teeming with so much potential that they began to break down. KDE 4 was on their desktops! The descent gathered pace; next to hit the ground was FreeIPA. At first this puzzled what remained of the heathens, but then they realized...they realized that it was going to make system administrators lives a lot easier! A web interface and command line tools, interacting with Windows domains and Active Directories? It was all getting too much for them. Conversions were happening faster and faster, only aided by mobile broadband, static IP addresses, and much much more in NetworkManager. Now, only a few doubters remained and what pushed them over the edge? The community, stupid! Tirelessly working to push out great code, great documentation and great artwork, inviting everyone to join where ever they were in the name of freedom. http://join.fedoraproject.org And the Computer, seeing that his work was accomplished and it was good, decided to rest. Pointing his browser at the Fedora mirrors, he switched off his monitor and waited for his Sulphur to return to him through the internet tubes, ready to enjoy another great release from the Fedora Project. http://get.fedoraproject.org http://fedoraproject.org/wiki/Releases/9/ReleaseSummary (this message brought to you by the Fedora Documentation Team http://docs.fedoraproject.org/) -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From ndbecker2 at gmail.com Tue May 13 14:15:02 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Tue, 13 May 2008 10:15:02 -0400 Subject: ipa-server conflicts with mod_ssl Message-ID: ipa-server-1.0.0-4.fc9.x86_64 from updates has depsolving problems --> ipa-server conflicts with mod_ssl From jwilson at redhat.com Tue May 13 14:19:20 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 13 May 2008 10:19:20 -0400 Subject: Kernel updates? In-Reply-To: <47297.192.54.193.59.1210664984.squirrel@rousalka.dyndns.org> References: <1210329109.10161.5.camel@shrek.rexursive.com> <47297.192.54.193.59.1210664984.squirrel@rousalka.dyndns.org> Message-ID: <200805131019.20120.jwilson@redhat.com> On Tuesday 13 May 2008 03:49:44 am Nicolas Mailhot wrote: > Le Mar 13 mai 2008 09:21, Bojan Smojver a ?crit : > > However, F9 is 2.6.25 based, so that isn't going to apply. And, 2.6.24 > > isn't > > getting any more updates either and this says that everyone on 2.6.24 > > should go > > to 2.6.25.3, which has fixes to yet another two security problems: > > At least one of the 2.6.25.3 is already in the F9 kernel (it was a F9 > blocker). Don't know if it's one of the two security bits though. A 2.6.25.3 kernel is already built and waiting in the wings. http://koji.fedoraproject.org/packages/kernel/2.6.25.3/18.fc9 -- Jarod Wilson jwilson at redhat.com From ssorce at redhat.com Tue May 13 14:19:29 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 13 May 2008 10:19:29 -0400 Subject: ipa-server conflicts with mod_ssl In-Reply-To: References: Message-ID: <1210688369.4575.11.camel@localhost.localdomain> On Tue, 2008-05-13 at 10:15 -0400, Neal Becker wrote: > ipa-server-1.0.0-4.fc9.x86_64 from updates has depsolving problems > --> ipa-server conflicts with mod_ssl Not a problem, the conflict is there on purpose. Uninstall mod_ssl. Simo. -- Simo Sorce * Red Hat, Inc * New York From bdwheele at indiana.edu Tue May 13 14:19:39 2008 From: bdwheele at indiana.edu (Brian Wheeler) Date: Tue, 13 May 2008 10:19:39 -0400 Subject: Did preupgrade make it in? Message-ID: <1210688379.8342.10.camel@nibbler.dlib.indiana.edu> I don't see any references in the release notes, and I can't find the rpm anywhere... Thanks Brian From dennis at ausil.us Tue May 13 14:22:06 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 13 May 2008 09:22:06 -0500 Subject: ipa-server conflicts with mod_ssl In-Reply-To: References: Message-ID: <200805130922.07993.dennis@ausil.us> On Tuesday 13 May 2008, Neal Becker wrote: > ipa-server-1.0.0-4.fc9.x86_64 from updates has depsolving problems > --> ipa-server conflicts with mod_ssl Yes it uses mod_nss for ssl http://directory.fedoraproject.org/wiki/Mod_nss Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From tcallawa at redhat.com Tue May 13 14:26:54 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 13 May 2008 10:26:54 -0400 Subject: Did preupgrade make it in? In-Reply-To: <1210688379.8342.10.camel@nibbler.dlib.indiana.edu> References: <1210688379.8342.10.camel@nibbler.dlib.indiana.edu> Message-ID: <1210688814.1920.19.camel@localhost.localdomain> On Tue, 2008-05-13 at 10:19 -0400, Brian Wheeler wrote: > I don't see any references in the release notes, and I can't find the > rpm anywhere... https://admin.fedoraproject.org/updates/F7/FEDORA-2008-3481 https://admin.fedoraproject.org/updates/F8/FEDORA-2008-3443 ~spot From bdwheele at indiana.edu Tue May 13 14:29:05 2008 From: bdwheele at indiana.edu (Brian Wheeler) Date: Tue, 13 May 2008 10:29:05 -0400 Subject: Did preupgrade make it in? In-Reply-To: <1210688814.1920.19.camel@localhost.localdomain> References: <1210688379.8342.10.camel@nibbler.dlib.indiana.edu> <1210688814.1920.19.camel@localhost.localdomain> Message-ID: <1210688945.8342.12.camel@nibbler.dlib.indiana.edu> On Tue, 2008-05-13 at 10:26 -0400, Tom "spot" Callaway wrote: > On Tue, 2008-05-13 at 10:19 -0400, Brian Wheeler wrote: > > I don't see any references in the release notes, and I can't find the > > rpm anywhere... > > https://admin.fedoraproject.org/updates/F7/FEDORA-2008-3481 > https://admin.fedoraproject.org/updates/F8/FEDORA-2008-3443 > > ~spot > Thanks! From mike at miketc.com Tue May 13 14:29:59 2008 From: mike at miketc.com (Mike Chambers) Date: Tue, 13 May 2008 09:29:59 -0500 Subject: Dell Laptop In-Reply-To: References: <1210428668.3864.2.camel@scrappy.miketc.com> Message-ID: <1210688999.2583.2.camel@shaggy.miketc.com> On Tue, 2008-05-13 at 13:08 +0200, Matej Cepl wrote: > Actually, to make this thread at least a little bit on topic (you know, > this is fedora-devel, not fedora list), I have to continue on my line > about superheros -- to my biggest satisfaction John Linville made my > BCM4318 working in the late F8 (or was it really early F9/Rawhide; I am > not sure). I am quite sure it needs a lot more stabilization and testing > (which makes it a topic here) but I think you can try to get it. Of > course, if you prefer your notebook to be more likely to just work (and I > had my fair chance of problems with iwl3945 as well), then Intel chips are > much more supported. Might have made a different choice if had known more about what was better supported than I knew. I ended up getting a Gateway M-1625 Sat night, and seems fine. Cept it uses Realtek for wired and wireless. Wired works like a champ, but wireless is hit and miss. I got a built module from atrpms.net and it works OK, but not continuous like in Vista or a more supported one. Although I think from a bug I was shown, that it's getting better supported and hopefully soon will be in kernel and working fine. I am on wireless so far as I type (not holding my breath though). -- Mike Chambers Fedora Project - Ambassador, Bug Zapper, Tester, User, etc.. mikec302 at fedoraproject.org From skvidal at fedoraproject.org Tue May 13 14:23:29 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 13 May 2008 10:23:29 -0400 Subject: Did preupgrade make it in? In-Reply-To: <1210688379.8342.10.camel@nibbler.dlib.indiana.edu> References: <1210688379.8342.10.camel@nibbler.dlib.indiana.edu> Message-ID: <1210688609.10395.49.camel@localhost.localdomain> On Tue, 2008-05-13 at 10:19 -0400, Brian Wheeler wrote: > I don't see any references in the release notes, and I can't find the > rpm anywhere... > > Thanks > Brian You can get preupgrade-0.9.3-2 from koji. It has the Fedora9 final release enabled as an upgrade target: For Fedora8: http://koji.fedoraproject.org/koji/buildinfo?buildID=48882 For Fedora7: http://koji.fedoraproject.org/koji/buildinfo?buildID=48885 -sv From jorton at redhat.com Tue May 13 14:51:37 2008 From: jorton at redhat.com (Joe Orton) Date: Tue, 13 May 2008 15:51:37 +0100 Subject: ipa-server conflicts with mod_ssl In-Reply-To: <1210688369.4575.11.camel@localhost.localdomain> References: <1210688369.4575.11.camel@localhost.localdomain> Message-ID: <20080513145137.GA6737@redhat.com> On Tue, May 13, 2008 at 10:19:29AM -0400, Simo Sorce wrote: > > On Tue, 2008-05-13 at 10:15 -0400, Neal Becker wrote: > > ipa-server-1.0.0-4.fc9.x86_64 from updates has depsolving problems > > --> ipa-server conflicts with mod_ssl > > Not a problem, the conflict is there on purpose. What purpose? The mod_ssl and mod_nss packages themselves do not conflict (nor the default configurations thereof) joe From ssorce at redhat.com Tue May 13 15:07:32 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 13 May 2008 11:07:32 -0400 Subject: ipa-server conflicts with mod_ssl In-Reply-To: <20080513145137.GA6737@redhat.com> References: <1210688369.4575.11.camel@localhost.localdomain> <20080513145137.GA6737@redhat.com> Message-ID: <1210691252.4575.15.camel@localhost.localdomain> On Tue, 2008-05-13 at 15:51 +0100, Joe Orton wrote: > On Tue, May 13, 2008 at 10:19:29AM -0400, Simo Sorce wrote: > > > > On Tue, 2008-05-13 at 10:15 -0400, Neal Becker wrote: > > > ipa-server-1.0.0-4.fc9.x86_64 from updates has depsolving problems > > > --> ipa-server conflicts with mod_ssl > > > > Not a problem, the conflict is there on purpose. > > What purpose? The mod_ssl and mod_nss packages themselves do not > conflict (nor the default configurations thereof) mod_proxy can use only one or the other, not both, we need to fix mod_proxy. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Tue May 13 15:17:09 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 13 May 2008 11:17:09 -0400 Subject: ipa-server conflicts with mod_ssl In-Reply-To: <20080513145137.GA6737@redhat.com> References: <1210688369.4575.11.camel@localhost.localdomain> <20080513145137.GA6737@redhat.com> Message-ID: <4829B0F5.9030507@redhat.com> Joe Orton wrote: > On Tue, May 13, 2008 at 10:19:29AM -0400, Simo Sorce wrote: >> On Tue, 2008-05-13 at 10:15 -0400, Neal Becker wrote: >>> ipa-server-1.0.0-4.fc9.x86_64 from updates has depsolving problems >>> --> ipa-server conflicts with mod_ssl >> Not a problem, the conflict is there on purpose. > > What purpose? The mod_ssl and mod_nss packages themselves do not > conflict (nor the default configurations thereof) > > joe > The problem is mod_proxy. It has only one set of symbols for doing SSL. mod_nss provides those symbols but defers to mod_ssl if both are loaded. But this means that if both are loaded mod_proxy will try to use the wrong SSL engine. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From jason.corley at gmail.com Tue May 13 15:21:29 2008 From: jason.corley at gmail.com (Jason Corley) Date: Tue, 13 May 2008 11:21:29 -0400 Subject: Summary of the 2008-04-08 Packaging Committee meeting Message-ID: <3118d8de0805130821p795309c4r7c80ab63dfca1e6a@mail.gmail.com> Tom "spot" Callaway wrote: > The approved JPackage naming exception says that when a technical > solution is found to make .jpp tagging obsolete for the purposes of > grouping excludes, the exception will vanish. I think we've done that, > insults and flames aside. The portion of that agreement that you are glossing over nicely was that the solution needed to be in rpm, not yum, apt, smart, up2date, or anywhere else. Plain and simple a yum plugin has zero to do with the exception and conditions as understood on the JPackage side. Jason From jspaleta at gmail.com Tue May 13 15:23:18 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 13 May 2008 07:23:18 -0800 Subject: JahShaka In-Reply-To: <4829910E.6070108@ncsu.edu> References: <4827CE9D.5020409@ncsu.edu> <4827F111.1070604@nicubunu.ro> <4827FA91.9060009@cchtml.com> <604aa7910805122036q7657c788o734d2bee29aa99fd@mail.gmail.com> <4829910E.6070108@ncsu.edu> Message-ID: <604aa7910805130823r4832fc57r6a5b701f6d6cfe5b@mail.gmail.com> On Tue, May 13, 2008 at 5:01 AM, Casey Dahlin wrote: > Pitivi is nice for little home movies, but it is NOT an industrial strength > NLE and I think it would do more harm to itself than good if it tried to be. > It will keep Joe User very happy, but not the prosumer crowd. And trying to > give Cinelerra to those people is just embarrassing. Its about as stable as > win98 and kludgey as hell. If wishes were fishes. Right now.. pitivi what we can ship. And I plan to beat the drum quite loudly about its potential as a piece of technology that this project can make use of to produce video by and for this community. Regardless of the quality of its featureset, it is what we have. I'm tired of holding my breath waiting for something else to come along that isn't mired the codec problem. If pitivi never "grows up" so what.... nothing says that its interface can't be forked and features can't be added over what is fundamentally the only framework we can ship. I've known about JahShaka for over a year now, If you can get them to dig in and switch to a gstreamer framework that does NOT directly depend on gstreamer-ffmpeg for most if not all of its magic.. more power to you. It's not just about switching to gstreamer. You can end up with an application that uses gstreamer but still relies on gstreamer-ffmpeg or other forbidden gstreamer plugins for all the useful features and STILL not have an application that we can ship. The real problem is that ffmpeg conglomerates a lot of useful things together, beyond just the codec stuff that we can't touch. So you reach for ffmpeg through gstreamer for deinterlace support or best effort raw dv footage handling and you are back to where you started. It's much more complicated than just moving to gstreamer. I think it's going to be much easier to start from an ffmpeg clean implementation of a video editor like pitivi and build on it, even if it ends up being a fork. Because everything else that I have seen ultimately relies on ffmpeg for important functionality and that simply has to stop or we can't ship it. -jef From tcallawa at redhat.com Tue May 13 15:40:55 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 13 May 2008 11:40:55 -0400 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <3118d8de0805130821p795309c4r7c80ab63dfca1e6a@mail.gmail.com> References: <3118d8de0805130821p795309c4r7c80ab63dfca1e6a@mail.gmail.com> Message-ID: <1210693255.1920.27.camel@localhost.localdomain> On Tue, 2008-05-13 at 11:21 -0400, Jason Corley wrote: > Tom "spot" Callaway wrote: > > The approved JPackage naming exception says that when a technical > > solution is found to make .jpp tagging obsolete for the purposes of > > grouping excludes, the exception will vanish. I think we've done that, > > insults and flames aside. > > The portion of that agreement that you are glossing over nicely was > that the solution needed to be in rpm, not yum, apt, smart, up2date, > or anywhere else. Plain and simple a yum plugin has zero to do with > the exception and conditions as understood on the JPackage side. > Jason Given that I wrote the exception, I can rather confidently say that it doesn't say that. It lists both rpm and yum's inability to do the grouping ops, but nowhere does it require that we solve it with rpm. We can solve this, rather trivially, with yum. ~spot, who isn't sure why he's arguing with you, as he know no good will come from it. From a.badger at gmail.com Tue May 13 15:47:15 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 13 May 2008 08:47:15 -0700 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <3r9of5xq9c.ln2@ppp1053.in.ipex.cz> References: <1209999548.32107.11.camel@kennedy> <481F2986.8010509@redhat.com> <1210002669.26792.65.camel@beck.corsepiu.local> <481FD064.6050307@ncsu.edu> <1210045081.4658.7.camel@localhost.localdomain> <481FD3D5.5070206@ncsu.edu> <48207309.3040403@redhat.com> <1210321932.26792.817.camel@beck.corsepiu.local> <4824184A.1010508@redhat.com> <4824856E.3080109@gmail.com> <3r9of5xq9c.ln2@ppp1053.in.ipex.cz> Message-ID: <4829B803.3080802@gmail.com> Matej Cepl wrote: > On Fri, 09 May 2008 10:10:06 -0700, Toshio Kuratomi scripst: >> The list of packages which presently BuildRequire the >> autotools is very small so I'm not sure this is the case. > > You are missing the point -- package which is based on the upstream > tarball using autotools doesn't BuildRequire them. Only in the hopeless > situation when there is a need of configure rebuild, you need to > BuildRequire them. Your finding says unfortunately absolutely nothing. > You're quoting out of context:: ''' 1) It's micro-managing. Packagers should know whether they have to regenerate configure/Makefile.in based on the patches that they're applying. If we're seeing widespread use of the autotools when there's no need to do it then it seems like a candidate to add... but is that the case? The list of packages which presently BuildRequire the autotools is very small so I'm not sure this is the case. ''' I'm arguing that the problem Karsten thinks he's addressing is "widespread use of the autotools when there's no need to do it". If there are few packages that BuildRequire autotools in the first place, then there can't be a widespread use of autotools in package building, let alone a widespread use that is unnecessary. -Toshio From billcrawford1970 at gmail.com Tue May 13 15:48:47 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Tue, 13 May 2008 16:48:47 +0100 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <3118d8de0805130821p795309c4r7c80ab63dfca1e6a@mail.gmail.com> References: <3118d8de0805130821p795309c4r7c80ab63dfca1e6a@mail.gmail.com> Message-ID: <544eb990805130848m94c5f17pace849f4671379e5@mail.gmail.com> 2008/5/13 Jason Corley : > The portion of that agreement that you are glossing over nicely was > that the solution needed to be in rpm, not yum, apt, smart, up2date, > or anywhere else. Plain and simple a yum plugin has zero to do with > the exception and conditions as understood on the JPackage side. ... changing from a tag in the package version, to a "group" tag, means that you can query it and if you like, decide to not install it. Trying to insist that "rpm" should handle it is ... disingenuous, since rpm will do what it's told, and if you don't tell it to install such a package, it won't. From a.badger at gmail.com Tue May 13 15:50:47 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 13 May 2008 08:50:47 -0700 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <41074.192.54.193.59.1210664862.squirrel@rousalka.dyndns.org> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <1210612643.6285.5.camel@rousalka.okg> <1210613511.12520.46.camel@localhost.localdomain> <1210619487.6844.48.camel@rousalka.okg> <1210621696.12520.62.camel@localhost.localdomain> <1210632587.12173.15.camel@rousalka.okg> <48293492.4020905@gmail.com> <41074.192.54.193.59.1210664862.squirrel@rousalka.dyndns.org> Message-ID: <4829B8D7.7010501@gmail.com> Nicolas Mailhot wrote: > Le Mar 13 mai 2008 08:26, Toshio Kuratomi a ?crit : >> Nicolas Mailhot wrote: >>> Le lundi 12 mai 2008 ? 15:48 -0400, Tom "spot" Callaway a ?crit : >>> >>>> * I'm not mandating that JPackage change anything. This is >>>> specifically >>>> targeted on handling the Fedora packages which are derived from >>>> JPackage >>>> packages. >>> That's not realistic, if you want your matching to work you need the >>> tagging implemented both sides. The Fedora side is the easy one. >>> Fedora >>> has still not merged the bulk of the JPackage repository. >>> >> Either I'm reading this page wrong: >> >> http://fedoraproject.org/wiki/DeepakBhole/ReasonsForKeepingJPP >> >> or there's additional rationale for .jpp that's not on that page. >> >> The only thing I'm seeing from that page is that people want to select >> the Fedora packages on their system that have a companion package in >> JPackage so that they can either remove the Fedora package in favor of >> the JPackage version or in order to see which packages originated in >> JPackage. > > The selection process is of course symetric, like any rpm/yum op. > Users basically switch back and forth between the two java stacks till > they find the one that works best for them. > That's interesting because it would be a place that the current use of .jpp fails, then. .jpp can't be used to differentiate between the Fedora provided stack and the JPackage provided stack as they're both using it. >> There's no reason that I see listed on that page for >> JPackage >> to rebuild with a new group/vendor. In fact, if JPackage were to >> rebuild with the same group it would defeat the purpose of including >> that group. > > If you want to select on group as it is proposed now you need to put a > unique group in the specs jpp-side too (group that won't be the same > as the fedora one). > Well, if you just want to tell where a package came from vendor would certainly work. But the page doesn't say that. It says it wants to tell where a package came from before it came to Fedora. Or where it's provided in addition to Fedora. Or even, where we support you mixing with an additional repository. >> I'm not saying that .jpp has to go, but I will say the .jpp-in-Fedora >> exception was explicitly given a limit when it was voted in that >> revolved around the selection issue being resolved in another manner. > > I think the java group has already said it would implement changes > when a solution is presented. (not because the technical arguments > presented were convincing, just to have Fedora instances grind some > other axes). And I'd be the first to advocate expending energy just to > make some packages a bit cleaner. However, sitting on the fence there > and having worked both sides I'm just a bit affronted that we're happy > asking a lot of efforts of others to replace a harmless kludge, and > the solution presented scores no better in the cleanliness scale (in > fact since it's very new and quirks bits no one touched before it > could very possibly end up much worse). > > a lot of efforts is asked of others in the name of purity, an > Yeah, using Groups for this strokes me the wrong way too. However, nothing is being asked of other people as the .jpp tag currently does not allow you to select only the packages which are from JPackage. If that's something that is desired, a plugin that uses the Vendor tag will certainly work. But just because it is used for the JPackage packages selection doesn't mean it must be used for the "Fedora packages derived from JPackage packages" selection. >> Some of the base assumptions on the ReasonsForKeepingJPP also don't >> seem >> to be in line with past thinking about third party repositories. We >> don't support people installing an rpm provided by an upstream on >> sourceforge if it's newer than the one in Fedora and back and forth. >> We don't support people ... > > We don't reuse extensively the work done in those repositories. So > wrong comparison here. > Not really. The argument seems to be that there's not enough java packagers to fill both JPackage and Fedora with rpms. But this is no different than anyone else who says, there's only a few of us who care about packaging OCaml programs/Lisp programs/vim plugins and there's too many useful pieces of software written in that language that users want for us to handle. Make accomodations for us so that users can decide to make use of this third party repository where upstream/other distros can help us with the packaging effort. Either we decide that JPackage is special because it has guidelines for packaging that we agree with, our java packagers mostly work in that repository anyway, (to re-emphasise what you've said) "we reuse extensively the work done [in the JPackage repository]", and we have a presence there that allows us to make changes to JPackage guidelines and policies when there is a need or we stop saying that it should be a goal that our users can switch out the Fedora stack with the JPackage stack on any arbitrary update. What we have now makes no sense: 1) JPackage derived packages are supposed to be switchable with Fedora packages on a per package basis (per the original justifications for the .jpp exception) 2) JPackage derived packages are supposed to be switchable with Fedora packages on a whole stack basis (per ReasonsForKeepingJPP). 3) We could have packages in Fedora that have a counterpart in JPackage but are not derived from the JPackage package with no rhyme or reason beyond whether the packager was active in JPackage when they made the submission. This will cause problems for people attempting to mix JPackage and Fedora stacks as per #1. 4) JPackage Guidelines only have a few points of divergence with the Fedora Guidelines and the stated goal of our java packagers is to make those divergences disappear. 5) The attitude that our users can find a package in JPackage if it's not in Fedora is detrimental to us. Where ever possible, we don't want user's to have to *find* packages, we want them to be able to yum install the package out of the box. -Toshio From diegobz at gmail.com Tue May 13 15:56:07 2008 From: diegobz at gmail.com (=?ISO-8859-1?Q?Diego_B=FArigo_Zacar=E3o?=) Date: Tue, 13 May 2008 12:56:07 -0300 Subject: Did preupgrade make it in? In-Reply-To: <1210688609.10395.49.camel@localhost.localdomain> References: <1210688379.8342.10.camel@nibbler.dlib.indiana.edu> <1210688609.10395.49.camel@localhost.localdomain> Message-ID: <6600c1b10805130856w745f347t6d657523c5c79be5@mail.gmail.com> On Tue, May 13, 2008 at 11:23 AM, seth vidal wrote: > > You can get preupgrade-0.9.3-2 from koji. > > It has the Fedora9 final release enabled as an upgrade target: > For Fedora8: > http://koji.fedoraproject.org/koji/buildinfo?buildID=48882 > For Fedora7: > http://koji.fedoraproject.org/koji/buildinfo?buildID=48885 > > So, we can use it without problems or we can have issues like that[1]? I hope that everything is ok. :) [1] https://fedorahosted.org/preupgrade/ticket/19 -- Diego B?rigo Zacar?o Linux User #402589 USE SOFTWARE LIVRE -------------- next part -------------- An HTML attachment was scrubbed... URL: From rawhide at fedoraproject.org Tue May 13 15:57:43 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Tue, 13 May 2008 15:57:43 +0000 (UTC) Subject: rawhide report: 20080513 changes Message-ID: <20080513155744.1FA46209D1E@releng1.fedora.phx.redhat.com> Broken deps for i386 ---------------------------------------------------------- FlightGear-1.0.0-2.fc9.i386 requires libplibssgaux.so.1.8.4 FlightGear-1.0.0-2.fc9.i386 requires libplibfnt.so.1.8.4 FlightGear-1.0.0-2.fc9.i386 requires libplibssg.so.1.8.4 FlightGear-1.0.0-2.fc9.i386 requires libplibpuaux.so.1.8.4 FlightGear-1.0.0-2.fc9.i386 requires libplibpu.so.1.8.4 FlightGear-1.0.0-2.fc9.i386 requires libplibjs.so.1.8.4 FlightGear-1.0.0-2.fc9.i386 requires libplibnet.so.1.8.4 FlightGear-1.0.0-2.fc9.i386 requires libplibsg.so.1.8.4 FlightGear-1.0.0-2.fc9.i386 requires libplibul.so.1.8.4 LabPlot-1.5.1.6-4.fc8.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libMagick.so.10 SimGear-1.0.0-3.fc9.i386 requires libplibul.so.1.8.4 SimGear-1.0.0-3.fc9.i386 requires libplibssg.so.1.8.4 SimGear-1.0.0-3.fc9.i386 requires libplibnet.so.1.8.4 SimGear-1.0.0-3.fc9.i386 requires libplibsg.so.1.8.4 autotrace-0.31.1-16.fc9.i386 requires libWand.so.10 autotrace-0.31.1-16.fc9.i386 requires libMagick.so.10 brasero-0.7.1-3.fc9.i386 requires libtotem-plparser.so.10 1:bug-buddy-2.22.0-2.fc9.i386 requires libedataserver-1.2.so.9 cheese-2.23.1-1.fc10.i386 requires libedataserver-1.2.so.9 contact-lookup-applet-0.16-5.fc9.i386 requires libedataserver-1.2.so.9 contacts-0.8-3.fc9.i386 requires libedataserver-1.2.so.9 1:control-center-2.23.1-2.fc10.i386 requires libedataserver-1.2.so.9 1:control-center-2.23.1-2.fc10.i386 requires libgnomekbdui.so.2 1:control-center-2.23.1-2.fc10.i386 requires libgnomekbd.so.2 dates-0.4.5-2.fc9.i386 requires libedataserver-1.2.so.9 drawtiming-0.6.2-3.fc9.i386 requires libMagick++.so.10 drawtiming-0.6.2-3.fc9.i386 requires libWand.so.10 drawtiming-0.6.2-3.fc9.i386 requires libMagick.so.10 dx-4.4.4-6.fc9.i386 requires libWand.so.10 dx-4.4.4-6.fc9.i386 requires libMagick.so.10 dx-libs-4.4.4-6.fc9.i386 requires libWand.so.10 dx-libs-4.4.4-6.fc9.i386 requires libMagick.so.10 empathy-0.23.1-2.fc10.i386 requires libedataserver-1.2.so.9 empathy-libs-0.23.1-2.fc10.i386 requires libedataserver-1.2.so.9 evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-python-0.0.4-3.fc9.i386 requires libedataserver-1.2.so.9 evolution-sharp-0.16.0-1.fc9.i386 requires libedataserver-1.2.so.9 evolution-webcal-2.21.92-1.fc9.i386 requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.i386 requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-1.2.so.11 fgfs-Atlas-0.3.1-8.fc9.i386 requires libplibul.so.1.8.4 fgfs-Atlas-0.3.1-8.fc9.i386 requires libplibfnt.so.1.8.4 fgfs-Atlas-0.3.1-8.fc9.i386 requires libplibpu.so.1.8.4 fgfs-Atlas-0.3.1-8.fc9.i386 requires libplibnet.so.1.8.4 fgfs-Atlas-0.3.1-8.fc9.i386 requires libplibsg.so.1.8.4 gdl-0.9-0.rc1.1.fc9.i386 requires libMagick++.so.10 glabels-2.2.2-1.fc9.i386 requires libedataserver-1.2.so.9 1:gnome-applets-2.22.1-3.fc10.i386 requires libgnomekbdui.so.2 1:gnome-applets-2.22.1-3.fc10.i386 requires libgnomekbd.so.2 gnome-launch-box-0.4-8.fc9.i386 requires libedataserver-1.2.so.9 gnome-panel-2.23.1-1.fc10.i386 requires libedataserver-1.2.so.9 gnome-phone-manager-0.51-1.fc9.i386 requires libedataserver-1.2.so.9 gnome-python2-evolution-2.22.0-2.fc9.i386 requires libedataserver-1.2.so.9 gnome-python2-totem-2.22.0-2.fc9.i386 requires libtotem-plparser.so.10 gnome-screensaver-2.22.1-1.fc9.i386 requires libgnomekbdui.so.2 gnome-screensaver-2.22.1-1.fc9.i386 requires libgnomekbd.so.2 gnome-settings-daemon-2.23.1.1-4.fc10.i386 requires libgnomekbd.so.2 gossip-0.29-1.fc10.i386 requires libedataserver-1.2.so.9 imageinfo-0.05-3.fc9.i386 requires libWand.so.10 imageinfo-0.05-3.fc9.i386 requires libMagick.so.10 k3d-0.6.7.0-6.fc9.i386 requires libMagick++.so.10 k3d-0.6.7.0-6.fc9.i386 requires libMagick.so.10 k3d-0.6.7.0-6.fc9.i386 requires libWand.so.10 kismet-extras-0.0.2007.10.R1-3.fc9.i386 requires libMagick.so.10 koffice-karbon-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-karbon-1.6.3-15.fc9.i386 requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libMagick.so.10 libfprint-0.0.5-3.fc9.i386 requires libWand.so.10 libfprint-0.0.5-3.fc9.i386 requires libMagick.so.10 libopensync-plugin-evolution2-0.35-3.fc9.i386 requires libedataserver-1.2.so.9 nautilus-sendto-0.14.0-1.fc9.i386 requires libedataserver-1.2.so.9 nip2-7.14.1-1.fc9.i386 requires libWand.so.10 nip2-7.14.1-1.fc9.i386 requires libMagick.so.10 1:openoffice.org-core-2.4.0-12.8.fc9.i386 requires libhunspell.so.1 oxine-0.7.0-2.fc9.i386 requires libWand.so.10 oxine-0.7.0-2.fc9.i386 requires libMagick.so.10 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) php-magickwand-1.0.7-1.fc10.i386 requires libWand.so.10 php-magickwand-1.0.7-1.fc10.i386 requires libMagick.so.10 pidgin-2.4.1-2.fc9.i386 requires libedataserver-1.2.so.9 planner-eds-0.14.3-1.fc10.i386 requires libcamel-provider-1.2.so.11 planner-eds-0.14.3-1.fc10.i386 requires libedataserver-1.2.so.9 planner-eds-0.14.3-1.fc10.i386 requires libcamel-1.2.so.11 psiconv-0.9.8-1.fc8.i386 requires libWand.so.10 psiconv-0.9.8-1.fc8.i386 requires libMagick.so.10 pstoedit-3.45-2.fc9.i386 requires libMagick++.so.10 pstoedit-3.45-2.fc9.i386 requires libWand.so.10 pstoedit-3.45-2.fc9.i386 requires libMagick.so.10 q-7.10-3.fc9.i386 requires libMagick.so.10 qgis-0.9.1-5.fc9.i386 requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.i386 requires libgeos.so.2 rhythmbox-0.11.5-9.fc9.i386 requires libtotem-plparser.so.10 stormbaancoureur-2.1.2-1.fc9.i386 requires libplibssgaux.so.1.8.4 stormbaancoureur-2.1.2-1.fc9.i386 requires libplibssg.so.1.8.4 stormbaancoureur-2.1.2-1.fc9.i386 requires libplibpu.so.1.8.4 stormbaancoureur-2.1.2-1.fc9.i386 requires libplibfnt.so.1.8.4 stormbaancoureur-2.1.2-1.fc9.i386 requires libplibsg.so.1.8.4 stormbaancoureur-2.1.2-1.fc9.i386 requires libplibul.so.1.8.4 sunbird-0.8-3.fc9.i386 requires libhunspell.so.1 supertuxkart-0.4-1.fc9.i386 requires libplibssgaux.so.1.8.4 supertuxkart-0.4-1.fc9.i386 requires libplibsg.so.1.8.4 supertuxkart-0.4-1.fc9.i386 requires libplibjs.so.1.8.4 supertuxkart-0.4-1.fc9.i386 requires libplibssg.so.1.8.4 supertuxkart-0.4-1.fc9.i386 requires libplibpu.so.1.8.4 supertuxkart-0.4-1.fc9.i386 requires libplibfnt.so.1.8.4 supertuxkart-0.4-1.fc9.i386 requires libplibsl.so.1.8.4 supertuxkart-0.4-1.fc9.i386 requires libplibul.so.1.8.4 syncevolution-0.7-2.fc9.i386 requires libedataserver-1.2.so.9 tasks-0.12-2.fc9.i386 requires libedataserver-1.2.so.9 theora-tools-1.0beta3-1.fc10.i386 requires libtheoraenc.so.1(libtheoraenc_1.0) theora-tools-1.0beta3-1.fc10.i386 requires libtheoraenc.so.1 thunderbird-lightning-0.8-3.fc9.i386 requires libhunspell.so.1 2:tog-pegasus-2.7.0-6.fc9.i386 requires SysVinit 2:tog-pegasus-2.7.0-6.fc9.i386 requires SysVinit torcs-1.3.0-6.fc9.i386 requires libplibssgaux.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibssg.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibsl.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibsm.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibsg.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibul.so.1.8.4 totem-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 totem-mozplugin-2.23.2-2.fc9.i386 requires libtotem-plparser-mini.so.10 totem-mozplugin-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 totem-nautilus-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 totem-pl-parser-2.23.1-1.fc10.i386 requires libedataserver-1.2.so.9 vips-7.14.1-1.fc9.i386 requires libWand.so.10 vips-7.14.1-1.fc9.i386 requires libMagick.so.10 vips-python-7.14.1-1.fc9.i386 requires libWand.so.10 vips-python-7.14.1-1.fc9.i386 requires libMagick.so.10 vips-tools-7.14.1-1.fc9.i386 requires libWand.so.10 vips-tools-7.14.1-1.fc9.i386 requires libMagick.so.10 xastir-1.9.2-4.fc9.i386 requires libWand.so.10 xastir-1.9.2-4.fc9.i386 requires libMagick.so.10 xulrunner-1.9-0.60.cvs20080414.fc10.i386 requires libhunspell.so.1 Broken deps for x86_64 ---------------------------------------------------------- FlightGear-1.0.0-2.fc9.x86_64 requires libplibul.so.1.8.4()(64bit) FlightGear-1.0.0-2.fc9.x86_64 requires libplibssgaux.so.1.8.4()(64bit) FlightGear-1.0.0-2.fc9.x86_64 requires libplibnet.so.1.8.4()(64bit) FlightGear-1.0.0-2.fc9.x86_64 requires libplibjs.so.1.8.4()(64bit) FlightGear-1.0.0-2.fc9.x86_64 requires libplibsg.so.1.8.4()(64bit) FlightGear-1.0.0-2.fc9.x86_64 requires libplibpuaux.so.1.8.4()(64bit) FlightGear-1.0.0-2.fc9.x86_64 requires libplibpu.so.1.8.4()(64bit) FlightGear-1.0.0-2.fc9.x86_64 requires libplibssg.so.1.8.4()(64bit) FlightGear-1.0.0-2.fc9.x86_64 requires libplibfnt.so.1.8.4()(64bit) LabPlot-1.5.1.6-4.fc8.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libMagick.so.10 LabPlot-1.5.1.6-4.fc8.x86_64 requires libMagick++.so.10()(64bit) LabPlot-1.5.1.6-4.fc8.x86_64 requires libMagick.so.10()(64bit) LabPlot-1.5.1.6-4.fc8.x86_64 requires libWand.so.10()(64bit) SimGear-1.0.0-3.fc9.i386 requires libplibul.so.1.8.4 SimGear-1.0.0-3.fc9.i386 requires libplibssg.so.1.8.4 SimGear-1.0.0-3.fc9.i386 requires libplibnet.so.1.8.4 SimGear-1.0.0-3.fc9.i386 requires libplibsg.so.1.8.4 SimGear-1.0.0-3.fc9.x86_64 requires libplibul.so.1.8.4()(64bit) SimGear-1.0.0-3.fc9.x86_64 requires libplibnet.so.1.8.4()(64bit) SimGear-1.0.0-3.fc9.x86_64 requires libplibsg.so.1.8.4()(64bit) SimGear-1.0.0-3.fc9.x86_64 requires libplibssg.so.1.8.4()(64bit) autotrace-0.31.1-16.fc9.i386 requires libWand.so.10 autotrace-0.31.1-16.fc9.i386 requires libMagick.so.10 autotrace-0.31.1-16.fc9.x86_64 requires libWand.so.10()(64bit) autotrace-0.31.1-16.fc9.x86_64 requires libMagick.so.10()(64bit) brasero-0.7.1-3.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) 1:bug-buddy-2.22.0-2.fc9.i386 requires libedataserver-1.2.so.9 1:bug-buddy-2.22.0-2.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) cheese-2.23.1-1.fc10.x86_64 requires libedataserver-1.2.so.9()(64bit) contact-lookup-applet-0.16-5.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) contacts-0.8-3.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) 1:control-center-2.23.1-2.fc10.i386 requires libedataserver-1.2.so.9 1:control-center-2.23.1-2.fc10.i386 requires libgnomekbdui.so.2 1:control-center-2.23.1-2.fc10.i386 requires libgnomekbd.so.2 1:control-center-2.23.1-2.fc10.x86_64 requires libgnomekbd.so.2()(64bit) 1:control-center-2.23.1-2.fc10.x86_64 requires libgnomekbdui.so.2()(64bit) 1:control-center-2.23.1-2.fc10.x86_64 requires libedataserver-1.2.so.9()(64bit) dates-0.4.5-2.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) drawtiming-0.6.2-3.fc9.x86_64 requires libWand.so.10()(64bit) drawtiming-0.6.2-3.fc9.x86_64 requires libMagick++.so.10()(64bit) drawtiming-0.6.2-3.fc9.x86_64 requires libMagick.so.10()(64bit) dx-4.4.4-6.fc9.x86_64 requires libMagick.so.10()(64bit) dx-4.4.4-6.fc9.x86_64 requires libWand.so.10()(64bit) dx-libs-4.4.4-6.fc9.i386 requires libWand.so.10 dx-libs-4.4.4-6.fc9.i386 requires libMagick.so.10 dx-libs-4.4.4-6.fc9.x86_64 requires libMagick.so.10()(64bit) dx-libs-4.4.4-6.fc9.x86_64 requires libWand.so.10()(64bit) empathy-0.23.1-2.fc10.x86_64 requires libedataserver-1.2.so.9()(64bit) empathy-libs-0.23.1-2.fc10.i386 requires libedataserver-1.2.so.9 empathy-libs-0.23.1-2.fc10.x86_64 requires libedataserver-1.2.so.9()(64bit) evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libWand.so.10()(64bit) evolution-python-0.0.4-3.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) evolution-sharp-0.16.0-1.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) evolution-webcal-2.21.92-1.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) fgfs-Atlas-0.3.1-8.fc9.x86_64 requires libplibul.so.1.8.4()(64bit) fgfs-Atlas-0.3.1-8.fc9.x86_64 requires libplibnet.so.1.8.4()(64bit) fgfs-Atlas-0.3.1-8.fc9.x86_64 requires libplibsg.so.1.8.4()(64bit) fgfs-Atlas-0.3.1-8.fc9.x86_64 requires libplibpu.so.1.8.4()(64bit) fgfs-Atlas-0.3.1-8.fc9.x86_64 requires libplibfnt.so.1.8.4()(64bit) freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx gdl-0.9-0.rc1.1.fc9.x86_64 requires libMagick++.so.10()(64bit) glabels-2.2.2-1.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) 1:gnome-applets-2.22.1-3.fc10.x86_64 requires libgnomekbd.so.2()(64bit) 1:gnome-applets-2.22.1-3.fc10.x86_64 requires libgnomekbdui.so.2()(64bit) gnome-launch-box-0.4-8.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) gnome-panel-2.23.1-1.fc10.x86_64 requires libedataserver-1.2.so.9()(64bit) gnome-phone-manager-0.51-1.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) gnome-python2-evolution-2.22.0-2.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) gnome-python2-totem-2.22.0-2.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) gnome-screensaver-2.22.1-1.fc9.x86_64 requires libgnomekbd.so.2()(64bit) gnome-screensaver-2.22.1-1.fc9.x86_64 requires libgnomekbdui.so.2()(64bit) gnome-settings-daemon-2.23.1.1-4.fc10.x86_64 requires libgnomekbd.so.2()(64bit) gossip-0.29-1.fc10.x86_64 requires libedataserver-1.2.so.9()(64bit) imageinfo-0.05-3.fc9.x86_64 requires libWand.so.10()(64bit) imageinfo-0.05-3.fc9.x86_64 requires libMagick.so.10()(64bit) k3d-0.6.7.0-6.fc9.i386 requires libMagick++.so.10 k3d-0.6.7.0-6.fc9.i386 requires libMagick.so.10 k3d-0.6.7.0-6.fc9.i386 requires libWand.so.10 k3d-0.6.7.0-6.fc9.x86_64 requires libMagick.so.10()(64bit) k3d-0.6.7.0-6.fc9.x86_64 requires libWand.so.10()(64bit) k3d-0.6.7.0-6.fc9.x86_64 requires libMagick++.so.10()(64bit) kismet-extras-0.0.2007.10.R1-3.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.x86_64 requires libWand.so.10()(64bit) koffice-libs-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.x86_64 requires libWand.so.10()(64bit) libfprint-0.0.5-3.fc9.i386 requires libWand.so.10 libfprint-0.0.5-3.fc9.i386 requires libMagick.so.10 libfprint-0.0.5-3.fc9.x86_64 requires libWand.so.10()(64bit) libfprint-0.0.5-3.fc9.x86_64 requires libMagick.so.10()(64bit) libopensync-plugin-evolution2-0.35-3.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) nautilus-sendto-0.14.0-1.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) nip2-7.14.1-1.fc9.x86_64 requires libMagick.so.10()(64bit) nip2-7.14.1-1.fc9.x86_64 requires libWand.so.10()(64bit) 1:openoffice.org-core-2.4.0-12.8.fc9.x86_64 requires libhunspell.so.1()(64bit) oxine-0.7.0-2.fc9.x86_64 requires libMagick.so.10()(64bit) oxine-0.7.0-2.fc9.x86_64 requires libWand.so.10()(64bit) perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) php-magickwand-1.0.7-1.fc10.x86_64 requires libWand.so.10()(64bit) php-magickwand-1.0.7-1.fc10.x86_64 requires libMagick.so.10()(64bit) pidgin-2.4.1-2.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) planner-eds-0.14.3-1.fc10.x86_64 requires libcamel-provider-1.2.so.11()(64bit) planner-eds-0.14.3-1.fc10.x86_64 requires libcamel-1.2.so.11()(64bit) planner-eds-0.14.3-1.fc10.x86_64 requires libedataserver-1.2.so.9()(64bit) psiconv-0.9.8-1.fc8.i386 requires libWand.so.10 psiconv-0.9.8-1.fc8.i386 requires libMagick.so.10 psiconv-0.9.8-1.fc8.x86_64 requires libWand.so.10()(64bit) psiconv-0.9.8-1.fc8.x86_64 requires libMagick.so.10()(64bit) pstoedit-3.45-2.fc9.i386 requires libMagick++.so.10 pstoedit-3.45-2.fc9.i386 requires libWand.so.10 pstoedit-3.45-2.fc9.i386 requires libMagick.so.10 pstoedit-3.45-2.fc9.x86_64 requires libMagick++.so.10()(64bit) pstoedit-3.45-2.fc9.x86_64 requires libMagick.so.10()(64bit) pstoedit-3.45-2.fc9.x86_64 requires libWand.so.10()(64bit) q-7.10-3.fc9.i386 requires libMagick.so.10 qgis-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) rhythmbox-0.11.5-9.fc9.i386 requires libtotem-plparser.so.10 rhythmbox-0.11.5-9.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) stormbaancoureur-2.1.2-1.fc9.x86_64 requires libplibul.so.1.8.4()(64bit) stormbaancoureur-2.1.2-1.fc9.x86_64 requires libplibssgaux.so.1.8.4()(64bit) stormbaancoureur-2.1.2-1.fc9.x86_64 requires libplibpu.so.1.8.4()(64bit) stormbaancoureur-2.1.2-1.fc9.x86_64 requires libplibsg.so.1.8.4()(64bit) stormbaancoureur-2.1.2-1.fc9.x86_64 requires libplibssg.so.1.8.4()(64bit) stormbaancoureur-2.1.2-1.fc9.x86_64 requires libplibfnt.so.1.8.4()(64bit) sunbird-0.8-3.fc9.x86_64 requires libhunspell.so.1()(64bit) supertuxkart-0.4-1.fc9.x86_64 requires libplibul.so.1.8.4()(64bit) supertuxkart-0.4-1.fc9.x86_64 requires libplibssgaux.so.1.8.4()(64bit) supertuxkart-0.4-1.fc9.x86_64 requires libplibjs.so.1.8.4()(64bit) supertuxkart-0.4-1.fc9.x86_64 requires libplibpu.so.1.8.4()(64bit) supertuxkart-0.4-1.fc9.x86_64 requires libplibsg.so.1.8.4()(64bit) supertuxkart-0.4-1.fc9.x86_64 requires libplibssg.so.1.8.4()(64bit) supertuxkart-0.4-1.fc9.x86_64 requires libplibfnt.so.1.8.4()(64bit) supertuxkart-0.4-1.fc9.x86_64 requires libplibsl.so.1.8.4()(64bit) syncevolution-0.7-2.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) tasks-0.12-2.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) theora-tools-1.0beta3-1.fc10.x86_64 requires libtheoraenc.so.1(libtheoraenc_1.0)(64bit) theora-tools-1.0beta3-1.fc10.x86_64 requires libtheoraenc.so.1()(64bit) thunderbird-lightning-0.8-3.fc9.x86_64 requires libhunspell.so.1()(64bit) 2:tog-pegasus-2.7.0-6.fc9.i386 requires SysVinit 2:tog-pegasus-2.7.0-6.fc9.i386 requires SysVinit 2:tog-pegasus-2.7.0-6.fc9.x86_64 requires SysVinit 2:tog-pegasus-2.7.0-6.fc9.x86_64 requires SysVinit torcs-1.3.0-6.fc9.x86_64 requires libplibsg.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibul.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibssgaux.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibsm.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibssg.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibsl.so.1.8.4()(64bit) totem-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 totem-2.23.2-2.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.x86_64 requires libtotem-plparser-mini.so.10()(64bit) totem-nautilus-2.23.2-2.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) totem-pl-parser-2.23.1-1.fc10.i386 requires libedataserver-1.2.so.9 totem-pl-parser-2.23.1-1.fc10.x86_64 requires libedataserver-1.2.so.9()(64bit) vips-7.14.1-1.fc9.i386 requires libWand.so.10 vips-7.14.1-1.fc9.i386 requires libMagick.so.10 vips-7.14.1-1.fc9.x86_64 requires libMagick.so.10()(64bit) vips-7.14.1-1.fc9.x86_64 requires libWand.so.10()(64bit) vips-python-7.14.1-1.fc9.x86_64 requires libMagick.so.10()(64bit) vips-python-7.14.1-1.fc9.x86_64 requires libWand.so.10()(64bit) vips-tools-7.14.1-1.fc9.x86_64 requires libMagick.so.10()(64bit) vips-tools-7.14.1-1.fc9.x86_64 requires libWand.so.10()(64bit) xastir-1.9.2-4.fc9.x86_64 requires libMagick.so.10()(64bit) xastir-1.9.2-4.fc9.x86_64 requires libWand.so.10()(64bit) xulrunner-1.9-0.60.cvs20080414.fc10.i386 requires libhunspell.so.1 xulrunner-1.9-0.60.cvs20080414.fc10.x86_64 requires libhunspell.so.1()(64bit) Broken deps for ppc ---------------------------------------------------------- FlightGear-1.0.0-2.fc9.ppc requires libplibssgaux.so.1.8.4 FlightGear-1.0.0-2.fc9.ppc requires libplibfnt.so.1.8.4 FlightGear-1.0.0-2.fc9.ppc requires libplibssg.so.1.8.4 FlightGear-1.0.0-2.fc9.ppc requires libplibpuaux.so.1.8.4 FlightGear-1.0.0-2.fc9.ppc requires libplibpu.so.1.8.4 FlightGear-1.0.0-2.fc9.ppc requires libplibjs.so.1.8.4 FlightGear-1.0.0-2.fc9.ppc requires libplibnet.so.1.8.4 FlightGear-1.0.0-2.fc9.ppc requires libplibsg.so.1.8.4 FlightGear-1.0.0-2.fc9.ppc requires libplibul.so.1.8.4 LabPlot-1.5.1.6-4.fc8.ppc requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.ppc requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.ppc requires libMagick.so.10 SimGear-1.0.0-3.fc9.ppc requires libplibul.so.1.8.4 SimGear-1.0.0-3.fc9.ppc requires libplibssg.so.1.8.4 SimGear-1.0.0-3.fc9.ppc requires libplibnet.so.1.8.4 SimGear-1.0.0-3.fc9.ppc requires libplibsg.so.1.8.4 SimGear-1.0.0-3.fc9.ppc64 requires libplibul.so.1.8.4()(64bit) SimGear-1.0.0-3.fc9.ppc64 requires libplibnet.so.1.8.4()(64bit) SimGear-1.0.0-3.fc9.ppc64 requires libplibsg.so.1.8.4()(64bit) SimGear-1.0.0-3.fc9.ppc64 requires libplibssg.so.1.8.4()(64bit) autotrace-0.31.1-16.fc9.ppc requires libWand.so.10 autotrace-0.31.1-16.fc9.ppc requires libMagick.so.10 autotrace-0.31.1-16.fc9.ppc64 requires libWand.so.10()(64bit) autotrace-0.31.1-16.fc9.ppc64 requires libMagick.so.10()(64bit) brasero-0.7.1-3.fc9.ppc requires libtotem-plparser.so.10 1:bug-buddy-2.22.0-2.fc9.ppc requires libedataserver-1.2.so.9 1:bug-buddy-2.22.0-2.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) cheese-2.23.1-1.fc10.ppc requires libedataserver-1.2.so.9 contact-lookup-applet-0.16-5.fc9.ppc requires libedataserver-1.2.so.9 contacts-0.8-3.fc9.ppc requires libedataserver-1.2.so.9 1:control-center-2.23.1-2.fc10.ppc requires libedataserver-1.2.so.9 1:control-center-2.23.1-2.fc10.ppc requires libgnomekbdui.so.2 1:control-center-2.23.1-2.fc10.ppc requires libgnomekbd.so.2 1:control-center-2.23.1-2.fc10.ppc64 requires libgnomekbd.so.2()(64bit) 1:control-center-2.23.1-2.fc10.ppc64 requires libgnomekbdui.so.2()(64bit) 1:control-center-2.23.1-2.fc10.ppc64 requires libedataserver-1.2.so.9()(64bit) dap-netcdf_handler-3.7.8-3.fc9.ppc64 requires libnetcdf.so.4()(64bit) dates-0.4.5-2.fc9.ppc requires libedataserver-1.2.so.9 drawtiming-0.6.2-3.fc9.ppc requires libMagick++.so.10 drawtiming-0.6.2-3.fc9.ppc requires libWand.so.10 drawtiming-0.6.2-3.fc9.ppc requires libMagick.so.10 dx-4.4.4-6.fc9.ppc requires libWand.so.10 dx-4.4.4-6.fc9.ppc requires libMagick.so.10 dx-libs-4.4.4-6.fc9.ppc requires libWand.so.10 dx-libs-4.4.4-6.fc9.ppc requires libMagick.so.10 dx-libs-4.4.4-6.fc9.ppc64 requires libnetcdf.so.4()(64bit) dx-libs-4.4.4-6.fc9.ppc64 requires libMagick.so.10()(64bit) dx-libs-4.4.4-6.fc9.ppc64 requires libWand.so.10()(64bit) empathy-0.23.1-2.fc10.ppc requires libedataserver-1.2.so.9 empathy-libs-0.23.1-2.fc10.ppc requires libedataserver-1.2.so.9 empathy-libs-0.23.1-2.fc10.ppc64 requires libedataserver-1.2.so.9()(64bit) evolution-brutus-1.2.11-2.fc9.ppc requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.ppc requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.ppc requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-python-0.0.4-3.fc9.ppc requires libedataserver-1.2.so.9 evolution-sharp-0.16.0-1.fc9.ppc requires libedataserver-1.2.so.9 evolution-webcal-2.21.92-1.fc9.ppc requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.ppc requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-1.2.so.11 fgfs-Atlas-0.3.1-8.fc9.ppc requires libplibul.so.1.8.4 fgfs-Atlas-0.3.1-8.fc9.ppc requires libplibfnt.so.1.8.4 fgfs-Atlas-0.3.1-8.fc9.ppc requires libplibpu.so.1.8.4 fgfs-Atlas-0.3.1-8.fc9.ppc requires libplibnet.so.1.8.4 fgfs-Atlas-0.3.1-8.fc9.ppc requires libplibsg.so.1.8.4 gdal-1.5.1-5.fc9.ppc64 requires libhdf5.so.5()(64bit) gdal-1.5.1-5.fc9.ppc64 requires libnetcdf.so.4()(64bit) gdl-0.9-0.rc1.1.fc9.ppc requires libMagick++.so.10 glabels-2.2.2-1.fc9.ppc requires libedataserver-1.2.so.9 1:gnome-applets-2.22.1-3.fc10.ppc requires libgnomekbdui.so.2 1:gnome-applets-2.22.1-3.fc10.ppc requires libgnomekbd.so.2 gnome-launch-box-0.4-8.fc9.ppc requires libedataserver-1.2.so.9 gnome-panel-2.23.1-1.fc10.ppc requires libedataserver-1.2.so.9 gnome-phone-manager-0.51-1.fc9.ppc requires libedataserver-1.2.so.9 gnome-python2-evolution-2.22.0-2.fc9.ppc requires libedataserver-1.2.so.9 gnome-python2-totem-2.22.0-2.fc9.ppc requires libtotem-plparser.so.10 gnome-screensaver-2.22.1-1.fc9.ppc requires libgnomekbdui.so.2 gnome-screensaver-2.22.1-1.fc9.ppc requires libgnomekbd.so.2 gnome-settings-daemon-2.23.1.1-4.fc10.ppc requires libgnomekbd.so.2 gossip-0.29-1.fc10.ppc requires libedataserver-1.2.so.9 imageinfo-0.05-3.fc9.ppc requires libWand.so.10 imageinfo-0.05-3.fc9.ppc requires libMagick.so.10 k3d-0.6.7.0-6.fc9.ppc requires libMagick++.so.10 k3d-0.6.7.0-6.fc9.ppc requires libMagick.so.10 k3d-0.6.7.0-6.fc9.ppc requires libWand.so.10 k3d-0.6.7.0-6.fc9.ppc64 requires libMagick.so.10()(64bit) k3d-0.6.7.0-6.fc9.ppc64 requires libWand.so.10()(64bit) k3d-0.6.7.0-6.fc9.ppc64 requires libMagick++.so.10()(64bit) kismet-extras-0.0.2007.10.R1-3.fc9.ppc requires libMagick.so.10 koffice-karbon-1.6.3-15.fc9.ppc requires libWand.so.10 koffice-karbon-1.6.3-15.fc9.ppc requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.ppc requires libWand.so.10 koffice-libs-1.6.3-15.fc9.ppc requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) libfprint-0.0.5-3.fc9.ppc requires libWand.so.10 libfprint-0.0.5-3.fc9.ppc requires libMagick.so.10 libfprint-0.0.5-3.fc9.ppc64 requires libWand.so.10()(64bit) libfprint-0.0.5-3.fc9.ppc64 requires libMagick.so.10()(64bit) libopensync-plugin-evolution2-0.35-3.fc9.ppc requires libedataserver-1.2.so.9 nautilus-sendto-0.14.0-1.fc9.ppc requires libedataserver-1.2.so.9 nip2-7.14.1-1.fc9.ppc requires libWand.so.10 nip2-7.14.1-1.fc9.ppc requires libMagick.so.10 6:octave-3.0.1-1.fc10.ppc64 requires libhdf5.so.5()(64bit) 1:openoffice.org-core-2.4.0-12.8.fc9.ppc requires libhunspell.so.1 oxine-0.7.0-2.fc9.ppc requires libWand.so.10 oxine-0.7.0-2.fc9.ppc requires libMagick.so.10 paraview-3.2.1-6.fc9.ppc64 requires libhdf5.so.5()(64bit) paraview-mpi-3.2.1-6.fc9.ppc64 requires libhdf5.so.5()(64bit) perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) php-magickwand-1.0.7-1.fc10.ppc requires libWand.so.10 php-magickwand-1.0.7-1.fc10.ppc requires libMagick.so.10 pidgin-2.4.1-2.fc9.ppc requires libedataserver-1.2.so.9 planner-eds-0.14.3-1.fc10.ppc requires libcamel-provider-1.2.so.11 planner-eds-0.14.3-1.fc10.ppc requires libedataserver-1.2.so.9 planner-eds-0.14.3-1.fc10.ppc requires libcamel-1.2.so.11 psiconv-0.9.8-1.fc8.ppc requires libWand.so.10 psiconv-0.9.8-1.fc8.ppc requires libMagick.so.10 psiconv-0.9.8-1.fc8.ppc64 requires libWand.so.10()(64bit) psiconv-0.9.8-1.fc8.ppc64 requires libMagick.so.10()(64bit) pstoedit-3.45-2.fc9.ppc requires libMagick++.so.10 pstoedit-3.45-2.fc9.ppc requires libWand.so.10 pstoedit-3.45-2.fc9.ppc requires libMagick.so.10 pstoedit-3.45-2.fc9.ppc64 requires libMagick++.so.10()(64bit) pstoedit-3.45-2.fc9.ppc64 requires libMagick.so.10()(64bit) pstoedit-3.45-2.fc9.ppc64 requires libWand.so.10()(64bit) q-7.10-3.fc9.ppc requires libMagick.so.10 q-7.10-3.fc9.ppc64 requires libMagick.so.10()(64bit) qgis-0.9.1-5.fc9.ppc requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.ppc requires libgeos.so.2 rhythmbox-0.11.5-9.fc9.ppc requires libtotem-plparser.so.10 rhythmbox-0.11.5-9.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) stormbaancoureur-2.1.2-1.fc9.ppc requires libplibssgaux.so.1.8.4 stormbaancoureur-2.1.2-1.fc9.ppc requires libplibssg.so.1.8.4 stormbaancoureur-2.1.2-1.fc9.ppc requires libplibpu.so.1.8.4 stormbaancoureur-2.1.2-1.fc9.ppc requires libplibfnt.so.1.8.4 stormbaancoureur-2.1.2-1.fc9.ppc requires libplibsg.so.1.8.4 stormbaancoureur-2.1.2-1.fc9.ppc requires libplibul.so.1.8.4 sunbird-0.8-3.fc9.ppc requires libhunspell.so.1 supertuxkart-0.4-1.fc9.ppc requires libplibssgaux.so.1.8.4 supertuxkart-0.4-1.fc9.ppc requires libplibsg.so.1.8.4 supertuxkart-0.4-1.fc9.ppc requires libplibjs.so.1.8.4 supertuxkart-0.4-1.fc9.ppc requires libplibssg.so.1.8.4 supertuxkart-0.4-1.fc9.ppc requires libplibpu.so.1.8.4 supertuxkart-0.4-1.fc9.ppc requires libplibfnt.so.1.8.4 supertuxkart-0.4-1.fc9.ppc requires libplibsl.so.1.8.4 supertuxkart-0.4-1.fc9.ppc requires libplibul.so.1.8.4 syncevolution-0.7-2.fc9.ppc requires libedataserver-1.2.so.9 tasks-0.12-2.fc9.ppc requires libedataserver-1.2.so.9 theora-tools-1.0beta3-1.fc10.ppc requires libtheoraenc.so.1(libtheoraenc_1.0) theora-tools-1.0beta3-1.fc10.ppc requires libtheoraenc.so.1 thunderbird-lightning-0.8-3.fc9.ppc requires libhunspell.so.1 2:tog-pegasus-2.7.0-6.fc9.ppc requires SysVinit 2:tog-pegasus-2.7.0-6.fc9.ppc requires SysVinit 2:tog-pegasus-2.7.0-6.fc9.ppc64 requires SysVinit 2:tog-pegasus-2.7.0-6.fc9.ppc64 requires SysVinit torcs-1.3.0-6.fc9.ppc requires libplibssgaux.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibssg.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibsl.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibsm.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibsg.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibul.so.1.8.4 totem-2.23.2-2.fc9.ppc requires libtotem-plparser.so.10 totem-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.ppc requires libtotem-plparser-mini.so.10 totem-mozplugin-2.23.2-2.fc9.ppc requires libtotem-plparser.so.10 totem-nautilus-2.23.2-2.fc9.ppc requires libtotem-plparser.so.10 totem-pl-parser-2.23.1-1.fc10.ppc requires libedataserver-1.2.so.9 totem-pl-parser-2.23.1-1.fc10.ppc64 requires libedataserver-1.2.so.9()(64bit) vips-7.14.1-1.fc9.ppc requires libWand.so.10 vips-7.14.1-1.fc9.ppc requires libMagick.so.10 vips-7.14.1-1.fc9.ppc64 requires libMagick.so.10()(64bit) vips-7.14.1-1.fc9.ppc64 requires libWand.so.10()(64bit) vips-python-7.14.1-1.fc9.ppc requires libWand.so.10 vips-python-7.14.1-1.fc9.ppc requires libMagick.so.10 vips-tools-7.14.1-1.fc9.ppc requires libWand.so.10 vips-tools-7.14.1-1.fc9.ppc requires libMagick.so.10 xastir-1.9.2-4.fc9.ppc requires libWand.so.10 xastir-1.9.2-4.fc9.ppc requires libMagick.so.10 xulrunner-1.9-0.60.cvs20080414.fc10.ppc requires libhunspell.so.1 xulrunner-1.9-0.60.cvs20080414.fc10.ppc64 requires libhunspell.so.1()(64bit) Broken deps for ppc64 ---------------------------------------------------------- FlightGear-1.0.0-2.fc9.ppc64 requires libplibul.so.1.8.4()(64bit) FlightGear-1.0.0-2.fc9.ppc64 requires libplibssgaux.so.1.8.4()(64bit) FlightGear-1.0.0-2.fc9.ppc64 requires libplibnet.so.1.8.4()(64bit) FlightGear-1.0.0-2.fc9.ppc64 requires libplibjs.so.1.8.4()(64bit) FlightGear-1.0.0-2.fc9.ppc64 requires libplibsg.so.1.8.4()(64bit) FlightGear-1.0.0-2.fc9.ppc64 requires libplibpuaux.so.1.8.4()(64bit) FlightGear-1.0.0-2.fc9.ppc64 requires libplibpu.so.1.8.4()(64bit) FlightGear-1.0.0-2.fc9.ppc64 requires libplibssg.so.1.8.4()(64bit) FlightGear-1.0.0-2.fc9.ppc64 requires libplibfnt.so.1.8.4()(64bit) R-hdf5-1.6.6-4.fc9.ppc64 requires libhdf5.so.5()(64bit) ScientificPython-2.6-12.fc9.ppc64 requires libnetcdf.so.4()(64bit) SimGear-1.0.0-3.fc9.ppc64 requires libplibul.so.1.8.4()(64bit) SimGear-1.0.0-3.fc9.ppc64 requires libplibnet.so.1.8.4()(64bit) SimGear-1.0.0-3.fc9.ppc64 requires libplibsg.so.1.8.4()(64bit) SimGear-1.0.0-3.fc9.ppc64 requires libplibssg.so.1.8.4()(64bit) autotrace-0.31.1-16.fc9.ppc64 requires libWand.so.10()(64bit) autotrace-0.31.1-16.fc9.ppc64 requires libMagick.so.10()(64bit) brasero-0.7.1-3.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) 1:bug-buddy-2.22.0-2.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) cdo-1.0.8-2.fc9.ppc64 requires libnetcdf.so.4()(64bit) cheese-2.23.1-1.fc10.ppc64 requires libedataserver-1.2.so.9()(64bit) contact-lookup-applet-0.16-5.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) contacts-0.8-3.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) 1:control-center-2.23.1-2.fc10.ppc64 requires libgnomekbd.so.2()(64bit) 1:control-center-2.23.1-2.fc10.ppc64 requires libgnomekbdui.so.2()(64bit) 1:control-center-2.23.1-2.fc10.ppc64 requires libedataserver-1.2.so.9()(64bit) dap-netcdf_handler-3.7.8-3.fc9.ppc64 requires libnetcdf.so.4()(64bit) dates-0.4.5-2.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) drawtiming-0.6.2-3.fc9.ppc64 requires libWand.so.10()(64bit) drawtiming-0.6.2-3.fc9.ppc64 requires libMagick++.so.10()(64bit) drawtiming-0.6.2-3.fc9.ppc64 requires libMagick.so.10()(64bit) dx-4.4.4-6.fc9.ppc64 requires libnetcdf.so.4()(64bit) dx-4.4.4-6.fc9.ppc64 requires libMagick.so.10()(64bit) dx-4.4.4-6.fc9.ppc64 requires libWand.so.10()(64bit) dx-libs-4.4.4-6.fc9.ppc64 requires libnetcdf.so.4()(64bit) dx-libs-4.4.4-6.fc9.ppc64 requires libMagick.so.10()(64bit) dx-libs-4.4.4-6.fc9.ppc64 requires libWand.so.10()(64bit) empathy-0.23.1-2.fc10.ppc64 requires libedataserver-1.2.so.9()(64bit) empathy-libs-0.23.1-2.fc10.ppc64 requires libedataserver-1.2.so.9()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-python-0.0.4-3.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) evolution-webcal-2.21.92-1.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) fgfs-Atlas-0.3.1-8.fc9.ppc64 requires libplibul.so.1.8.4()(64bit) fgfs-Atlas-0.3.1-8.fc9.ppc64 requires libplibnet.so.1.8.4()(64bit) fgfs-Atlas-0.3.1-8.fc9.ppc64 requires libplibsg.so.1.8.4()(64bit) fgfs-Atlas-0.3.1-8.fc9.ppc64 requires libplibpu.so.1.8.4()(64bit) fgfs-Atlas-0.3.1-8.fc9.ppc64 requires libplibfnt.so.1.8.4()(64bit) gdal-1.5.1-5.fc9.ppc64 requires libhdf5.so.5()(64bit) gdal-1.5.1-5.fc9.ppc64 requires libnetcdf.so.4()(64bit) gdl-0.9-0.rc1.1.fc9.ppc64 requires libhdf5.so.5()(64bit) gdl-0.9-0.rc1.1.fc9.ppc64 requires libMagick++.so.10()(64bit) gdl-0.9-0.rc1.1.fc9.ppc64 requires libnetcdf.so.4()(64bit) glabels-2.2.2-1.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) 1:gnome-applets-2.22.1-3.fc10.ppc64 requires libgnomekbd.so.2()(64bit) 1:gnome-applets-2.22.1-3.fc10.ppc64 requires libgnomekbdui.so.2()(64bit) gnome-launch-box-0.4-8.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) gnome-panel-2.23.1-1.fc10.ppc64 requires libedataserver-1.2.so.9()(64bit) gnome-phone-manager-0.51-1.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) gnome-python2-evolution-2.22.0-2.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) gnome-python2-totem-2.22.0-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) gnome-screensaver-2.22.1-1.fc9.ppc64 requires libgnomekbd.so.2()(64bit) gnome-screensaver-2.22.1-1.fc9.ppc64 requires libgnomekbdui.so.2()(64bit) gnome-settings-daemon-2.23.1.1-4.fc10.ppc64 requires libgnomekbd.so.2()(64bit) gossip-0.29-1.fc10.ppc64 requires libedataserver-1.2.so.9()(64bit) grace-5.1.21-9.fc9.ppc64 requires libnetcdf.so.4()(64bit) grads-1.9b4-23.fc9.ppc64 requires libnetcdf.so.4()(64bit) imageinfo-0.05-3.fc9.ppc64 requires libWand.so.10()(64bit) imageinfo-0.05-3.fc9.ppc64 requires libMagick.so.10()(64bit) k3d-0.6.7.0-6.fc9.ppc64 requires libMagick.so.10()(64bit) k3d-0.6.7.0-6.fc9.ppc64 requires libWand.so.10()(64bit) k3d-0.6.7.0-6.fc9.ppc64 requires libMagick++.so.10()(64bit) kismet-extras-0.0.2007.10.R1-3.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) kst-netcdf-1.6.0-2.fc10.ppc64 requires libnetcdf_c++.so.4()(64bit) kst-netcdf-1.6.0-2.fc10.ppc64 requires libnetcdf.so.4()(64bit) libfprint-0.0.5-3.fc9.ppc64 requires libWand.so.10()(64bit) libfprint-0.0.5-3.fc9.ppc64 requires libMagick.so.10()(64bit) libopensync-plugin-evolution2-0.35-3.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot nautilus-sendto-0.14.0-1.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) ncview-1.92e-13.fc9.ppc64 requires libnetcdf.so.4()(64bit) netcdf-decoders-5.0.0-1.fc9.ppc64 requires libnetcdf.so.4()(64bit) netcdf-perl-1.2.3-7.fc9.ppc64 requires libnetcdf.so.4()(64bit) nip2-7.14.1-1.fc9.ppc64 requires libMagick.so.10()(64bit) nip2-7.14.1-1.fc9.ppc64 requires libWand.so.10()(64bit) 6:octave-3.0.1-1.fc10.ppc64 requires libhdf5.so.5()(64bit) 6:octave-devel-3.0.1-1.fc10.ppc64 requires hdf5-devel octave-forge-20080429-6.fc10.ppc64 requires libhdf5.so.5()(64bit) 1:openoffice.org-core-2.4.0-12.8.fc9.ppc64 requires libhunspell.so.1()(64bit) oxine-0.7.0-2.fc9.ppc64 requires libMagick.so.10()(64bit) oxine-0.7.0-2.fc9.ppc64 requires libWand.so.10()(64bit) paraview-3.2.1-6.fc9.ppc64 requires libhdf5.so.5()(64bit) paraview-mpi-3.2.1-6.fc9.ppc64 requires libhdf5.so.5()(64bit) perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 php-magickwand-1.0.7-1.fc10.ppc64 requires libWand.so.10()(64bit) php-magickwand-1.0.7-1.fc10.ppc64 requires libMagick.so.10()(64bit) pidgin-2.4.1-2.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) planner-eds-0.14.3-1.fc10.ppc64 requires libcamel-provider-1.2.so.11()(64bit) planner-eds-0.14.3-1.fc10.ppc64 requires libcamel-1.2.so.11()(64bit) planner-eds-0.14.3-1.fc10.ppc64 requires libedataserver-1.2.so.9()(64bit) ppc64-utils-0.14-2.fc9.ppc64 requires yaboot psiconv-0.9.8-1.fc8.ppc64 requires libWand.so.10()(64bit) psiconv-0.9.8-1.fc8.ppc64 requires libMagick.so.10()(64bit) pstoedit-3.45-2.fc9.ppc64 requires libMagick++.so.10()(64bit) pstoedit-3.45-2.fc9.ppc64 requires libMagick.so.10()(64bit) pstoedit-3.45-2.fc9.ppc64 requires libWand.so.10()(64bit) q-7.10-3.fc9.ppc64 requires libMagick.so.10()(64bit) qgis-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) rhythmbox-0.11.5-9.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) scrip-1.4-9.fc8.ppc64 requires libnetcdf.so.4()(64bit) scrip-1.4-9.fc8.ppc64 requires libnetcdff.so.4()(64bit) stormbaancoureur-2.1.2-1.fc9.ppc64 requires libplibul.so.1.8.4()(64bit) stormbaancoureur-2.1.2-1.fc9.ppc64 requires libplibssgaux.so.1.8.4()(64bit) stormbaancoureur-2.1.2-1.fc9.ppc64 requires libplibpu.so.1.8.4()(64bit) stormbaancoureur-2.1.2-1.fc9.ppc64 requires libplibsg.so.1.8.4()(64bit) stormbaancoureur-2.1.2-1.fc9.ppc64 requires libplibssg.so.1.8.4()(64bit) stormbaancoureur-2.1.2-1.fc9.ppc64 requires libplibfnt.so.1.8.4()(64bit) sunbird-0.8-3.fc9.ppc64 requires libhunspell.so.1()(64bit) supertuxkart-0.4-1.fc9.ppc64 requires libplibul.so.1.8.4()(64bit) supertuxkart-0.4-1.fc9.ppc64 requires libplibssgaux.so.1.8.4()(64bit) supertuxkart-0.4-1.fc9.ppc64 requires libplibjs.so.1.8.4()(64bit) supertuxkart-0.4-1.fc9.ppc64 requires libplibpu.so.1.8.4()(64bit) supertuxkart-0.4-1.fc9.ppc64 requires libplibsg.so.1.8.4()(64bit) supertuxkart-0.4-1.fc9.ppc64 requires libplibssg.so.1.8.4()(64bit) supertuxkart-0.4-1.fc9.ppc64 requires libplibfnt.so.1.8.4()(64bit) supertuxkart-0.4-1.fc9.ppc64 requires libplibsl.so.1.8.4()(64bit) syncevolution-0.7-2.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) tasks-0.12-2.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) theora-tools-1.0beta3-1.fc10.ppc64 requires libtheoraenc.so.1(libtheoraenc_1.0)(64bit) theora-tools-1.0beta3-1.fc10.ppc64 requires libtheoraenc.so.1()(64bit) thunderbird-lightning-0.8-3.fc9.ppc64 requires libhunspell.so.1()(64bit) 2:tog-pegasus-2.7.0-6.fc9.ppc64 requires SysVinit 2:tog-pegasus-2.7.0-6.fc9.ppc64 requires SysVinit torcs-1.3.0-6.fc9.ppc64 requires libplibsg.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibul.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibsm.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibssgaux.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibssg.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibsl.so.1.8.4()(64bit) totem-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.ppc64 requires libtotem-plparser-mini.so.10()(64bit) totem-nautilus-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) totem-pl-parser-2.23.1-1.fc10.ppc64 requires libedataserver-1.2.so.9()(64bit) vips-7.14.1-1.fc9.ppc64 requires libMagick.so.10()(64bit) vips-7.14.1-1.fc9.ppc64 requires libWand.so.10()(64bit) vips-python-7.14.1-1.fc9.ppc64 requires libMagick.so.10()(64bit) vips-python-7.14.1-1.fc9.ppc64 requires libWand.so.10()(64bit) vips-tools-7.14.1-1.fc9.ppc64 requires libMagick.so.10()(64bit) vips-tools-7.14.1-1.fc9.ppc64 requires libWand.so.10()(64bit) xastir-1.9.2-4.fc9.ppc64 requires libMagick.so.10()(64bit) xastir-1.9.2-4.fc9.ppc64 requires libWand.so.10()(64bit) xulrunner-1.9-0.60.cvs20080414.fc10.ppc64 requires libhunspell.so.1()(64bit) From a.badger at gmail.com Tue May 13 15:58:10 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 13 May 2008 08:58:10 -0700 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <48299924.2070704@redhat.com> References: <1209999548.32107.11.camel@kennedy> <481F2986.8010509@redhat.com> <1210002669.26792.65.camel@beck.corsepiu.local> <481FD064.6050307@ncsu.edu> <1210045081.4658.7.camel@localhost.localdomain> <481FD3D5.5070206@ncsu.edu> <48207309.3040403@redhat.com> <1210321932.26792.817.camel@beck.corsepiu.local> <4824184A.1010508@redhat.com> <48299924.2070704@redhat.com> Message-ID: <4829BA92.1090507@gmail.com> Karsten Hopp wrote: > Jason L Tibbitts III schrieb: >>>>>>> "KH" == Karsten Hopp writes: >> >> KH> I'd like to see a reviewer guideline instead that new packages >> KH> should be checked if they really need to run autofoo during the >> KH> build and if they really require to be built with ancient autofoo. >> >> Could you write a draft for consideration by the packaging committee? >> List it in http://fedoraproject.org/wiki/PackagingDrafts/DraftsTodo >> and the committee will take a look. >> >> Please be sure that the draft provides sufficient information on how >> reviewers can detect and how packagers can avoid the behavior you >> would like to discourage. >> >> - J< >> > > The initial version is at > http://fedoraproject.org/wiki/PackagingDrafts/AutoConf. > """ The resulting configure scripts and Makefiles might be different on systems with a different set of installed packages and thus might lead to unpredictable results. """ The buildroot will be the same across runs, therefore the results should be predictable right? """ Package maintainers should work with upstream to port the scripts to recent autoconf /automake. Sometimes this won't work due to time constraints or due to compatibility concerns for multi-platform packages such as p.e. Firefox, but at least an attempt should be made. """ How does the reviewer and package maintainer know that the scripts need to be ported? Should the package maintainer be moving the build scripts to newer versions in the Fedora package? -Toshio From sundaram at fedoraproject.org Tue May 13 16:00:33 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 13 May 2008 21:30:33 +0530 Subject: Did preupgrade make it in? In-Reply-To: <6600c1b10805130856w745f347t6d657523c5c79be5@mail.gmail.com> References: <1210688379.8342.10.camel@nibbler.dlib.indiana.edu> <1210688609.10395.49.camel@localhost.localdomain> <6600c1b10805130856w745f347t6d657523c5c79be5@mail.gmail.com> Message-ID: <4829BB21.2020609@fedoraproject.org> Diego B?rigo Zacar?o wrote: > So, we can use it without problems or we can have issues like that[1]? > > I hope that everything is ok. :) > > [1] https://fedorahosted.org/preupgrade/ticket/19 It is in the updates-testing repository for interested people to test and provide real world feedback. There has been ongoing fixes based on that feedback so that's more of what we need now. Rahul From jorton at redhat.com Tue May 13 16:00:06 2008 From: jorton at redhat.com (Joe Orton) Date: Tue, 13 May 2008 17:00:06 +0100 Subject: ipa-server conflicts with mod_ssl In-Reply-To: <1210691252.4575.15.camel@localhost.localdomain> References: <1210688369.4575.11.camel@localhost.localdomain> <20080513145137.GA6737@redhat.com> <1210691252.4575.15.camel@localhost.localdomain> Message-ID: <20080513160006.GA9679@redhat.com> On Tue, May 13, 2008 at 11:07:32AM -0400, Simo Sorce wrote: > > On Tue, 2008-05-13 at 15:51 +0100, Joe Orton wrote: > > On Tue, May 13, 2008 at 10:19:29AM -0400, Simo Sorce wrote: > > > > > > On Tue, 2008-05-13 at 10:15 -0400, Neal Becker wrote: > > > > ipa-server-1.0.0-4.fc9.x86_64 from updates has depsolving problems > > > > --> ipa-server conflicts with mod_ssl > > > > > > Not a problem, the conflict is there on purpose. > > > > What purpose? The mod_ssl and mod_nss packages themselves do not > > conflict (nor the default configurations thereof) > > mod_proxy can use only one or the other, not both, we need to fix > mod_proxy. Oh, that, right. No, the fix for that is to stop shipping two SSL modules which have the same purpose as far as the rest of the server (and userbase) cares. joe From jkeating at redhat.com Tue May 13 16:08:00 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 13 May 2008 12:08:00 -0400 Subject: ipa-server conflicts with mod_ssl In-Reply-To: <20080513160006.GA9679@redhat.com> References: <1210688369.4575.11.camel@localhost.localdomain> <20080513145137.GA6737@redhat.com> <1210691252.4575.15.camel@localhost.localdomain> <20080513160006.GA9679@redhat.com> Message-ID: <1210694880.3170.45.camel@localhost.localdomain> On Tue, 2008-05-13 at 17:00 +0100, Joe Orton wrote: > Oh, that, right. No, the fix for that is to stop shipping two SSL > modules which have the same purpose as far as the rest of the server > (and userbase) cares. So when can I block mod_ssl? -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jorton at redhat.com Tue May 13 16:17:10 2008 From: jorton at redhat.com (Joe Orton) Date: Tue, 13 May 2008 17:17:10 +0100 Subject: ipa-server conflicts with mod_ssl In-Reply-To: <1210694880.3170.45.camel@localhost.localdomain> References: <1210688369.4575.11.camel@localhost.localdomain> <20080513145137.GA6737@redhat.com> <1210691252.4575.15.camel@localhost.localdomain> <20080513160006.GA9679@redhat.com> <1210694880.3170.45.camel@localhost.localdomain> Message-ID: <20080513161710.GA9905@redhat.com> On Tue, May 13, 2008 at 12:08:00PM -0400, Jesse Keating wrote: > On Tue, 2008-05-13 at 17:00 +0100, Joe Orton wrote: > > Oh, that, right. No, the fix for that is to stop shipping two SSL > > modules which have the same purpose as far as the rest of the server > > (and userbase) cares. > > So when can I block mod_ssl? Well technically never, since it's a subpackage of httpd not a source package, but, the answer is: when mod_nss is supported upstream at the ASF, rather than being based on a fork of an old copy of mod_ssl. joe From rawhide at fedoraproject.org Tue May 13 16:22:13 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Tue, 13 May 2008 16:22:13 +0000 (UTC) Subject: rawhide report: 20080513 changes (resend) Message-ID: <20080513162213.4468E209D1D@releng1.fedora.phx.redhat.com> New package openhpi-subagent NetSNMP subagent for OpenHPI New package ocaml-pgocaml OCaml library for type-safe access to PostgreSQL databases New package anyremote Remote control through bluetooth or IR connection New package e16-epplets Epplets for Enlightenment, DR16 New package R-car Companion to Applied Regression package for R New package ganyremote GTK frontend for anyRemote New package sac Java standard interface for CSS parser New package tinyproxy A small, efficient HTTP/SSL proxy daemon New package perl-Catalyst-View-JSON JSON view for your data New package librelp The Reliable Event Logging Protocol library New package ezstream Command line source client for Icecast media streaming servers New package python-mpd Python MPD client library New package ocfs2-tools Tools for managing the Ocfs2 cluster file system New package dvipdfm A DVI to PDF translator New package perl-CGI-SpeedyCGI Speed up perl scripts by running them persistently New package psiconv A conversion utility for Psion files New package idesk Light desktop manager for minimal WMs New package Cython A language for writing Python extension modules New package perl-Catalyst-Plugin-StackTrace Display a stack trace on the debug screen New package concordance Software to program the Logitech?? Harmony?? remote control New package fpm2 Password manager with GTK2 GUI New package ocaml-res OCaml library for resizing arrays and strings New package jcip-annotations Java annotations for multithreaded software New package lxappearance Feature-rich GTK+ theme switcher for LXDE New package freenx-server Free Software (GPL) Implementation of the NX Server New package brettfont-fonts A handwriting font New package udpcast UDP broadcast file distribution and installation New package guilt Scripts to manage quilt-like patches on top of git New package ocaml-gettext OCaml library for i18n New package php-pdb PHP classes for manipulating Palm OS databases New package bpython Fancy curses interface to the Python interactive interpreter New package idw-gpl A Java Swing-based docking windows framework New package jvyamlb YAML processor for JRuby New package ocaml-gsl Interface to GSL (GNU scientific library) for OCaml New package simcoupe SAM Coupe emulator (spectrum compatible) New package pyke Knowledge-based inference engine New package lua-socket Network support for the Lua language New package ruby-augeas Ruby bindings for Augeas New package mona A decision procedure for the WS1S and WS2S logics New package html2ps HTML to PostScript converter New package php-pear-Cache-Lite Fast and Safe little cache system for PHP New package biloba A tactical board game New package augeas A library for changing configuration files New package cwiid Wiimote interface library New package thunar-shares Thunar file manager extension to share files using Samba New package eet Library for speedy data storage, retrieval, and compression New package lua-logging A simple API to use logging features in Lua New package lua-sql Database connectivity for the Lua programming language New package evas Hardware-accelerated state-aware canvas API New package bytelist A java library for lists of bytes New package mediawiki-HNP An extension to provide a hierarchical namespace permissions system New package ocaml-bitmatch OCaml library for matching and constructing bitstrings New package disktype Detect the content format of a disk or disk image New package cuetools Utilities to work with cue and TOC files New package libconcord Library to talk to Logitech?? Harmony?? universal remote controls New package perl-Catalyst-Model-LDAP LDAP model class for Catalyst New package OpenEXR_Viewers Viewers programs for OpenEXR New package python-augeas Python bindings to augeas New package akonadi PIM Storage Service New package edje A graphical layout and animation library New package jcommon JFree Java utility classes New package kstart Daemon version of kinit for Kerberos v5 New package gnue-common GNU Enterprise Common Base New package perl-CSS Object oriented access to Cascading Style Sheets (CSS) New package brazil Extremely small footprint Java HTTP stack New package libotf A Library for handling OpenType Font New package ocaml-ounit Unit test framework for OCaml New package pysvn Pythonic style bindings for Subversion New package imapsync Tool to migrate email between IMAP servers New package eclipse-epic Perl Eclipse plugin New package freenx-client Free client libraries and binaries for the NX protocol New package unuran Universal Non-Uniform Random number generator New package jruby Pure Java implementation of the Ruby interpreter New package jna-posix POSIX APIs for Java New package python-gtkextra Python bindings for gtkextra New package lsnipes A text-mode maze game New package quicksynergy Share keyboard and mouse between computers New package bip IRC Bouncer New package ocaml-omake OCaml build system with automated dependency analysis New package pyephem The astronomy library for Python New package geeqie Image browser and viewer New package xsettings-kde XSettings Daemon for KDE New package pyfits Python interface to FITS New package ffcall Libraries for foreign function call interfaces New package parcellite A lightweight GTK+ clipboard manager New package python-lzo LZO bindings for Python New package preupgrade Preresolves dependencies and prepares a system for an upgrade New package comedilib Data Acquisition library for the Comedi driver New package e16-docs Documentation for Enlightenment, DR16 New package epeg Immensely fast JPEG thumbnailer New package luadoc Documentation Generator Tool for the Lua language New package perl-Catalyst-Plugin-CGI-Untaint CGI::Untaint Plugin for Catalyst New package jcommon-serializer JFree Java General Serialization Framework New package python-openhpi Python interface for OpenHPI New package ecore Event/X abstraction layer New package gtksourceview2-sharp A C sharp binder for gtksourceview2 New package gstreamer-plugins-flumpegdemux MPEG demuxer for GStreamer New package lua-posix A POSIX library for Lua New package pAgenda A cross platform calendar and scheduler New package hamster-applet Time tracking applet New package collectd Statistics collection daemon for filling RRD files New package roadstencil-fonts Roadstencil Fonts New package ncdu Text-based disk usage viewer New package perl-Task-Weaken Ensure that a platform has weaken support New package ocaml-augeas OCaml bindings for Augeas configuration API New package samcoupe-rom SAM Coup?? (Spectrum compatible homecomputer) ROM file New package audit-viewer Audit event viewer New package embryo Easy to use library for running compiled PAWN programs New package GMT-coastlines Coastline data for GMT New package kanyremote KDE frontend for anyRemote New package wordwarvi Side-scrolling shoot 'em up '80s style arcade game New package e16-themes Themes for Enlightenment, DR16 New package ski IA-64 user and system mode simulator New package ocaml-sexplib OCaml library for converting OCaml values to S-expressions New package fsvs Fast System VerSioning versioning for file trees using subversion Removed package dragonplayer Removed package mogilefs-server Removed package gail Removed package okteta Updated Packages: netcdf-4.0.0-0.3.beta2.fc10 --------------------------- * Thu May 8 18:00:00 2008 Ed Hill - 4.0.0-0.3.beta2 - make package compliant with bz # 373861 * Thu May 8 18:00:00 2008 Ed Hill - 4.0.0-0.2.beta2 - ExcludeArch: ppc64 since it doesn't (for now) have hdf5 * Wed May 7 18:00:00 2008 Ed Hill - 4.0.0-0.1.beta2 - try out upstream 4.0.0-beta2 zoneminder-1.22.3-14.fc10 ------------------------- * Tue May 6 18:00:00 2008 Martin Ebourne - 1.22.3-14 - Remove default runlevel, bz #441315 * Mon Apr 28 18:00:00 2008 Jason L Tibbitts III - 1.22.3-13 - Backport patch for CVE-2008-1381 from 1.23.3 to 1.22.3. libid3tag-0.15.1b-6.fc10 ------------------------ * Fri May 9 18:00:00 2008 Todd Zullinger - 0.15.1b-6 - fix for CVE-2008-2109 (#445812) libxslt-1.1.23-3.fc10 --------------------- gridengine-6.1u4-1.fc10 ----------------------- * Fri Apr 11 18:00:00 2008 - Orion Poplawski - 6.1u4-1 - Update to 6.1u4 podsleuth-0.6.0-5.fc10 ---------------------- * Mon May 5 18:00:00 2008 Nigel Jones - 0.6.0-5 - Fix iPod detection w/ hal-info >= 20080313 (Closes: Bug #445611) - Correct last changelog entry prewikka-0.9.14-1.fc10 ---------------------- * Thu Apr 24 18:00:00 2008 Steve Grubb 0.9.14-1 - new upstream release checkpolicy-2.0.14-2.fc10 ------------------------- * Fri May 2 18:00:00 2008 Dan Walsh - 2.0.14-2 - Allow modules with 4 sections or more fio-1.20-1.fc10 --------------- * Fri Apr 25 18:00:00 2008 Eric Sandeen 1.20-1 - New upstream version * Thu Apr 10 18:00:00 2008 Eric Sandeen 1.19-1 - New upstream version gvfs-0.2.3-10.fc10 ------------------ python-gdata-1.0.13-1.fc10 -------------------------- * Mon May 12 18:00:00 2008 - Bastien Nocera - 1.0.13-1 - Update to 1.0.13 (#446000) konq-plugins-4.0.3-0.3.20080409svn.fc9 -------------------------------------- * Sun May 4 18:00:00 2008 Kevin Kofler - 4.0.3-0.3.20080409svn - fix searchbar plugin crash (#445144) cpanspec-1.75-1.fc10 -------------------- * Mon May 5 18:00:00 2008 Steven Pritchard 1.75-1 - Update to 1.75 (which really fixes BZ#437804). - Require curl instead of wget (BZ#438245). - Update description. gnome-packagekit-0.2.1-2.20080508.fc10 -------------------------------------- * Thu May 8 18:00:00 2008 Richard Hughes - 0.2.1-2.20080508 - Pull in a new snapshot from the unstable branch. * Tue May 6 18:00:00 2008 Richard Hughes - 0.2.1-1.20080506 - Pull in a new snapshot from the unstable branch. * Tue May 6 18:00:00 2008 Richard Hughes - 0.2.0-1 - Update to the latest _UNSTABLE_ upstream source latencytop-0.4-1.fc10 --------------------- * Thu Apr 24 18:00:00 2008 Michal Schmidt - 0.4-1 - Upstream release 0.4. sigscheme-0.8.3-1.fc10 ---------------------- * Wed May 7 18:00:00 2008 Akira TAGOH - 0.8.3-1 - New upstream release. tree-1.5.1.1-1.fc10 ------------------- * Fri Apr 25 18:00:00 2008 Tim Waugh 1.5.1.1-1 - 1.5.1.1. echo-icon-theme-0.3.89.0-0.1.git51c57605.fc10 --------------------------------------------- * Sat May 10 18:00:00 2008 Martin Sourada - 0.3.89.0-0.1.git51c57605 - New git snapshot - Introduce Autotools into Echo icon theme - Use icon-naming-utils to create symlinks - New icons mono-nunit22-2.2.10-3.fc10 -------------------------- kdelibs-4.0.72-2.fc10 --------------------- * Sun May 4 18:00:00 2008 Kevin Kofler - 4.0.72-2 - BR new minimum versions of qt4-devel and soprano-devel * Fri May 2 18:00:00 2008 Kevin Kofler - 4.0.72-1 - update to 4.0.72 (4.1 alpha 1) - parallel_devel patch ported by Lorenzo Villani - update file list (Lorenzo Villani) - drop upstreamed khtml-security, kconfig_sync_crash and klauncher-crash patches - update xdg-menu (Administration menu) patch ocaml-libvirt-0.4.1.1-2.fc10 ---------------------------- * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 0.4.1.1-2 - Rebuild for OCaml 3.10.2 libupnp-1.6.6-1.fc10 -------------------- * Thu May 1 18:00:00 2008 Eric Tanguy - 1.6.6-1 - Update to version 1.6.6 python-tag-0.94.1-1.fc10 ------------------------ * Tue Apr 22 18:00:00 2008 Matthias Saou 0.94.1-1 - Update to 0.94.1, which includes Notting's patch. - Remove separate LICENSE file, since the BSD license is now inside the README. * Tue Apr 22 18:00:00 2008 Matthias Saou 0.93-2 - Include taglib1.5 patch from Bill Nottingham. - Include everything under sitearch, egg file or not (easier). - Re-add dist tag, the package changed more than I thought. * Sun Feb 24 17:00:00 2008 Matthias Saou 0.93-1 - Update to 0.93. - Include new egg file. * Tue Feb 19 17:00:00 2008 Fedora Release Engineering - Autorebuild for GCC 4.3 zabbix-1.4.5-3.fc10 ------------------- * Fri May 2 18:00:00 2008 Jarod Wilson - 1.4.5-3 - Seems the zabbix folks replaced the original 1.4.5 tarball with an updated tarball or something -- it actually does contain a tiny bit of additional code... So update to newer 1.4.5. * Tue Apr 8 18:00:00 2008 Jarod Wilson - 1.4.5-2 - Fix building w/postgresql (#441456) clex-3.18-2.fc10 ---------------- * Mon Apr 28 18:00:00 2008 Kairo Araujo - 3.18-2 - added clex-3.18-configure.patch for fedora (thanks dwmw2) * Sat Apr 26 18:00:00 2008 Kairo Araujo - 3.18-1 - Update 3.18 libsmbios-2.0.1-2.fc10.1 ------------------------ libprelude-0.9.17.1-1.fc10 -------------------------- * Fri May 2 18:00:00 2008 Steve Grubb 0.9.17.1-1 - New upstream version * Thu Apr 24 18:00:00 2008 Steve Grubb 0.9.17-1 - New upstream version planner-0.14.3-1.fc10 --------------------- * Thu Apr 17 18:00:00 2008 Caolan McNamara - 0.14.3-1 - next version libselinux-2.0.64-2.fc10 ------------------------ * Wed May 7 18:00:00 2008 Dan Walsh - 2.0.64-2 - Add sedefaultcon and setconlist commands to dump login context * Tue Apr 22 18:00:00 2008 Dan Walsh - 2.0.64-1 - Update to Upstream * Fixed selinux_set_callback man page. * Try loading the max of the kernel-supported version and the libsepol-supported version when no manipulation of the binary policy is needed from Stephen Smalley. * Fix memory leaks in matchpathcon from Eamon Walsh. * Wed Apr 16 18:00:00 2008 Dan Walsh - 2.0.61-4 - Add Xavior Toth patch for security_id_t in swig * Thu Apr 10 18:00:00 2008 Dan Walsh - 2.0.61-3 - Add avc.h to swig code * Wed Apr 9 18:00:00 2008 Dan Walsh - 2.0.61-2 - Grab the latest policy for the kernel texlive-2007-31.fc10 -------------------- * Mon May 12 18:00:00 2008 Jindrich Novy - 2007-31 - don't build/package dvipdfm, it's now packaged separately (#445983), thanks to Jonathan Underwood - remove F8 related chunks from spec pioneers-0.12.2-1.fc10 ---------------------- * Fri May 2 18:00:00 2008 Hans de Goede 0.12.2-1 - New upstream release 0.12.2 * Mon Apr 28 18:00:00 2008 Hans de Goede 0.12.1-1 - New upstream release 0.12.1 gnome-utils-2.20.0.1-5.fc10 --------------------------- bzr-gtk-0.94.0-1.fc10 --------------------- * Mon May 5 18:00:00 2008 Toshio Kuratomi 0.94-1 - Update to 0.94. - Merge olive package into bzr-gtk to fix BZ#441139. - Remove patches that were merged into 0.94. hal-0.5.11-1.fc10 ----------------- * Fri May 9 18:00:00 2008 Richard Hughes - 0.5.11-1 - Update to latest upstream release python-virtinst-0.300.3-6.fc10 ------------------------------ * Fri May 9 18:00:00 2008 Daniel P. Berrange - 0.300.3-6.fc10 - Use /var/lib/libvirt/boot for kernel/initrd images (rhbz #445854) WebKit-1.0.0-0.10.svn32531.fc10 ------------------------------- * Tue Apr 29 18:00:00 2008 Peter Gordon 1.0.0-0.10.svn32531 - Remove the -Qt subpackage stuff. QtWebKit is now included in Qt proper, as of qt-4.4.0-0.6.rc1. (We no longer need separate build-qt and build-gtk subdirectories either.) - Reference: bug 442200 (RFE: WebKit Migration) - Add libjpeg dependency (was previously pulled in by the qt4-devel dependency tree). * Mon Apr 28 18:00:00 2008 Mamoru Tasaka - 1.0.0-0.9.svn32531 - Update to new upstream snapshot (SVN 32531). - Fix bug 443048 and hopefully fix bug 444445 - Modify the process of building GTK+ port a bit - on qt port WebKit/qt/Plugins is not built for qt >= 4.4.0 libast-0.7.1-0.6.20080502cvs.fc10 --------------------------------- * Fri May 2 18:00:00 2008 Terje R??sten - 0.7.1-0.6.20080502cvs - Fix source url fuse-encfs-1.4.2-2.fc10 ----------------------- * Mon May 5 18:00:00 2008 Tomas Hoger - 1.4.2-2 - Work-around broken boost library path auto detection causing build failures on 64-bit architectures. * Mon Apr 14 18:00:00 2008 Peter Lemenkov 1.4.2-1 - Ver. 1.4.2 - add option to pass-through file 'holes'. Only available in expert mode - config file format changed to XML via boost serialization (config file is now .encfs6.xml) - remove ulockmgr support, caused numerous locking issues. (bz# 440483) - fix symlink handling in encfsctl export - fix stdinpass option parsing, reported by Scott Hendrickson - fix path suffix in encfsctl wordpress-2.5.1-1.fc10 ---------------------- libxklavier-3.6-1.fc10 ---------------------- * Wed Apr 30 18:00:00 2008 Matthias Clasen - 3.6-1 - Update to 3.6 libtheora-1.0beta3-1.fc10 ------------------------- * Thu Apr 17 18:00:00 2008 Hans de Goede 1.0beta3-1 - New upstream release 1.0beta3 asterisk-1.6.0-0.13.beta8.fc10 ------------------------------ solfege-3.10.4-1.fc10 --------------------- monodoc-1.9-1.fc10 ------------------ * Mon Apr 21 18:00:00 2008 Paul F. Johnson 1.9-1 - bump octave-forge-20080429-6.fc10 ---------------------------- * Fri May 2 18:00:00 2008 Quentin Spencer 20080429-6 - Add patch for new ImageMagick. * Thu May 1 18:00:00 2008 Quentin Spencer 20080429-5 - Modify the patch to fix compile flags in a subpackage. * Thu May 1 18:00:00 2008 Quentin Spencer 20080429-4 - Extend the gcc 4.3 patch to more files. * Thu May 1 18:00:00 2008 Quentin Spencer 20080429-3 - Fix the gcc 4.3 patch. * Thu May 1 18:00:00 2008 Quentin Spencer 20080429-2 - Patch so it will compile with gcc 4.3. * Wed Apr 30 18:00:00 2008 Quentin Spencer 20080429-1 - New release. - Add ftplib-devel as dependency. - Remove obsolete dependencies and obsolete build steps. im-chooser-0.99.6-3.fc10 ------------------------ dbmail-2.2.9-1.fc10 ------------------- * Thu Apr 24 18:00:00 2008 Bernard Johnson - 2.2.9-1 - v 2.2.9 ocaml-cil-1.3.6-5.fc10 ---------------------- * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 1.3.6-5 - Rebuild for OCaml 3.10.2 tcpflow-0.21-4.fc10 ------------------- * Fri May 2 18:00:00 2008 Terje Rosten - 0.21-4 - fix color patch (bz #444833) fpc-2.2.0-12.fc10 ----------------- * Wed Apr 16 18:00:00 2008 Joost van der Sluis 2.2.0-12 - Fix for DWARF-debug generation - fixes some more build problems on x86_64 and F9, bugzilla 337051 * Tue Feb 19 17:00:00 2008 Fedora Release Engineering - 2.2.0-11 - Autorebuild for GCC 4.3 ocaml-ulex-1.1-2.fc10 --------------------- * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 1.1-2 - Rebuild for OCaml 3.10.2 * Mon Apr 21 18:00:00 2008 Richard W.M. Jones - 1.1-1 - New upstream version 1.1. - Fixed upstream URL. ntfsprogs-2.0.0-7.fc10 ---------------------- eog-2.23.1-1.fc10 ----------------- * Fri Apr 25 18:00:00 2008 Matthias Clasen - 2.23.1-1 - Update to 2.23.1 emacs-common-ess-5.3.7-1.fc10 ----------------------------- * Tue Apr 29 18:00:00 2008 Alex Lancaster - 5.3.7-1 - Update to new upstream release (5.3.7) system-config-printer-0.9.90-1.fc10 ----------------------------------- compiz-0.7.2-4.fc10 ------------------- * Wed May 7 18:00:00 2008 Kevin Kofler - 0.7.2-4 - Backport upstream patch to port kde4-window-decorator to KDE 4.1 libplasma fuse-python-0.2-8.fc10 ---------------------- * Sun Apr 27 18:00:00 2008 Peter Lemenkov 0.2-8 - Fix issue with libewf conman-0.2.1-1.fc10 ------------------- * Fri May 2 18:00:00 2008 Jarod Wilson 0.2.1-1 - New upstream release xorg-x11-drv-savage-2.2.0-2.fc9 ------------------------------- * Sat May 10 18:00:00 2008 Dave Airlie 2.2.0-2 - Fix aperture mapping issue (#426994) - fix EXA bug from upstream ocaml-3.10.2-2.fc10 ------------------- * Thu May 8 18:00:00 2008 Richard W.M. Jones - 3.10.2-2 - Pass MAP_32BIT to mmap (bz #445545). * Mon Apr 21 18:00:00 2008 Richard W.M. Jones - 3.10.2-1 - New upstream version 3.10.2 for Fedora 10. - Cleaned up several rpmlint errors & warnings. ovaldi-5.4.2-1.fc10 ------------------- * Mon Apr 21 18:00:00 2008 Lubomir Kundrak 5.4.2-1 - New upstream release, all patches got merged - Add /usr/share/ovaldi/xml symlink, to be compatible with Debian lucene-2.3.1-2jpp.0.fc10 ------------------------ * Mon May 5 18:00:00 2008 Lubomir Rintel - 0:2.3.1-2jpp.0 - Unbreak build by repacing the version patch with and -Dversion * Mon May 5 18:00:00 2008 Lubomir Rintel - 0:2.3.1-1jpp.0 - 2.3.1, bugfixes only control-center-2.23.1-2.fc10 ---------------------------- * Fri May 2 18:00:00 2008 Matthias Clasen - 2.23.1-2 - Add a button to change the default background libbonobo-2.22.0-3.fc10 ----------------------- * Tue May 6 18:00:00 2008 Ray Strode - 2.22.0-3 - Tie bonobo-activation-server more closely to session bgo #530615 batik-1.7-0.5.beta1 ------------------- * Mon Apr 28 18:00:00 2008 Lillian Angel - 1.7-0.3.beta1 - Fixed BASE_JARS in batik-squiggle.script. - Resolves: rhbz#444358 * Mon Mar 31 18:00:00 2008 Lillian Angel - 1.7-0.2.beta1 - Updated sources. - Updated release. - Added CLASSPATH to build. - Removed codecs patch. iproute-2.6.25-1.fc10 --------------------- * Mon Apr 21 18:00:00 2008 Marcela Maslanova - 2.6.25-1 - update - remove patch for backward compatibility - add patch for AEAD compatibility ragel-6.2-1.fc10 ---------------- * Mon May 12 18:00:00 2008 Jeremy Hinegardner - 6.2-1 - update to 6.2 * Mon Apr 14 18:00:00 2008 Jeremy Hinegardner - 6.1-1 - update to 6.1 ocaml-dbus-0.06-2.fc10 ---------------------- * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 0.06-2 - Rebuild for OCaml 3.10.2 hunspell-ar-0.20080110-1.fc10 ----------------------------- * Mon Apr 28 18:00:00 2008 Caolan McNamara - 0.20080110-1 - use the much lighter ayaspell data instead of Buckwalter policycoreutils-2.0.47-3.fc10 ----------------------------- * Wed May 7 18:00:00 2008 Dan Walsh 2.0.47-2 - Add rm -rf /tmp/gconfd-* /tmp/pulse-* /tmp/orbit-* to fixfiles restore - So that mislabeled files will get removed on full relabel * Wed May 7 18:00:00 2008 Dan Walsh 2.0.47-1 - Make restorecond not start by default - Fix polgengui to allow defining of confined roles. - Add patches from Lubomir Rintel * Add necessary runtime dependencies on setools-console for -gui * separate stderr when run seinfo commands - Update to upstream * Update semanage man page for booleans from Dan Walsh. * Add further error checking to seobject.py for setting booleans. openldap-2.4.8-4.fc10 --------------------- * Thu Apr 10 18:00:00 2008 Jan Safranek 2.4.8-4 - bdb upgraded to 4.6.21 - reworked upgrade logic again to run db_upgrade when bdb version changes java-1.6.0-openjdk-1.6.0.0-0.12.b09.fc9 --------------------------------------- * Mon May 5 18:00:00 2008 Lillian Angel - 1:1.6.0.0-0.12.b09 - Updated release. - Updated icedteasnapshot. - Resolves: rhbz#445182 - Resolves: rhbz#445183 * Tue Apr 29 18:00:00 2008 Lillian Angel - 1:1.6.0.0-0.11.b09 - Updated release. - Added archbuild and archinstall definitions for ia64. - Resolves: rhbz#433843 * Tue Apr 29 18:00:00 2008 Lillian Angel - 1:1.6.0.0-0.11.b09 - Updated icedteasnapshot. - Removed java-1.6.0-openjdk-jconsole.desktop and java-1.6.0-openjdk-policytool.desktop files. * Tue Apr 29 18:00:00 2008 Lillian Angel - 1:1.6.0.0-0.11.b09 - Fixed javaws.desktop installation. gnuplot-4.2.3-1.fc10 -------------------- * Fri May 9 18:00:00 2008 Ivana Varekova - 4.2.3-1 - update to 4.2.3 gdb-6.8-5.fc10 -------------- * Sun Apr 27 18:00:00 2008 Jan Kratochvil - 6.8-5 - Remove the kernel VDSO workaround (`no loadable ...') (kernel BZ 312011). * Wed Apr 23 18:00:00 2008 Jan Kratochvil - 6.8-4 - Backport fix on various forms of threads tracking across exec() (BZ 442765). - Testsuite: Include more biarch libraries on %{multilib_64_archs}. - Disable the build-id warnings for the testsuite run as they cause some FAILs. - Fix PIE support for 32bit inferiors on 64bit debugger. - Fix trashing memory on one ada/gnat testcase. - Make the testsuite results on ada more stable. * Wed Apr 16 18:00:00 2008 Jan Kratochvil - 6.8-3 - Fix ia64 compilation errors (Yi Zhan, BZ 442684). - Fix build on non-standard rpm-devel includes (Robert Scheck, BZ 442449). - Do not run the PIE mode for the testsuite during `--with upstream'. - Fix test of the crash on a sw watchpoint condition getting out of the scope. * Fri Apr 11 18:00:00 2008 Jan Kratochvil - 6.8-2 - Fix a regression due to PIE of reloading a changed exec file (BZ 433410). - Include also biarch libgcc on %{multilib_64_archs} for the testsuite. - Cosmetic fix of a testcase sanity breakpoint setting (part of BZ 233852). - New test of hiding unexpected breakpoints on intentional step commands. - New test of GCORE for shmid 0 shared memory mappings. - New test of a crash on `focus cmd', `focus prev' commands. - Fix a minor test race of the hardware watchpoints after the fork call. - Test crash on a sw watchpoint condition getting out of the scope. libsamplerate-0.1.3-1.fc10 -------------------------- * Mon Apr 14 18:00:00 2008 Hans de Goede 0.1.3-1 - New upstream release 0.1.3 gdm-2.22.0-6.fc10 ----------------- * Thu May 8 18:00:00 2008 Matthias Clasen - 1:2.22.0-6 - Add a GConf key to disable the user list * Mon May 5 18:00:00 2008 Matthias Clasen - 1:2.22.0-5 - Autoreconf - Bump rev * Mon May 5 18:00:00 2008 Matthias Clasen - 1:2.22.0-4 - Add a keyboard chooser to the greeter * Sun May 4 18:00:00 2008 Matthias Clasen - 1:2.22.0-3 - Fix source url wesnoth-1.4.2-1.fc10 -------------------- * Thu May 8 18:00:00 2008 Jon Ciesla - 1.4.2-1 - New upstream maintenance release. numactl-2.0.0-1.fc10 -------------------- * Thu May 8 18:00:00 2008 Neil Horman - 2.0.0-1 - Move to numactl 2.0.0 * Fri Apr 25 18:00:00 2008 Neil Horman - 1.0.2-6 - Fix buffer size passing and arg sanity check for physcpubind (bz 442521) udev-120-5.20080421git.fc10 --------------------------- exim-4.69-5.fc10 ---------------- * Sat Apr 19 18:00:00 2008 David Woodhouse 4.69-5 - Add dynamic lookup patch, split into subpackages (#199256) libkdcraw-0.1.4-1.fc10 ---------------------- * Wed Mar 12 18:00:00 2008 Rex Dieter 0.1.4-1 - libkdcraw-0.1.4 libsemanage-2.0.25-1.fc10 ------------------------- uim-1.4.2-3.fc10 ---------------- subcommander-1.2.3-1.fc10 ------------------------- * Sun Apr 20 18:00:00 2008 Jochen Schmitt 1.2.4-1 - New upstream release e2fsprogs-1.40.9-2.fc10 ----------------------- * Mon May 12 18:00:00 2008 Eric Sandeen 1.40.9-2 - Fix blkid swap recognition on big-endian boxes (#445786) * Sun Apr 27 18:00:00 2008 Eric Sandeen 1.40.9-1 - New upstream version tk-8.5.1-4.fc10 --------------- * Fri May 9 18:00:00 2008 Marcela Maslanova - 1:8.5.1-4 - 445836 added BR (thanks to jamatos) nexuiz-2.4-1.fc10 ----------------- * Tue Apr 29 18:00:00 2008 Jon Ciesla - 2.4-1 - New upstream release. - Dropped nostrip patch. - Added libXpm-devel BR. tesseract-2.03-1.fc10 --------------------- * Sun May 4 18:00:00 2008 Karol Trzcionka - 2.03-1 - Update to v2.03 python-genshi-0.5-0.1.svn847.fc10 --------------------------------- * Thu Apr 24 18:00:00 2008 Jeffrey C. Ollie - 0.5-0.1.svn847 - Update to snapshot of 0.5 libtwin-0.0.2-8.fc10 -------------------- * Wed Apr 23 18:00:00 2008 David Woodhouse - 0.0.2-8 - Add -flax-vector-conversions to CFLAGS * Mon Feb 18 17:00:00 2008 Fedora Release Engineering - 0.0.2-7 - Autorebuild for GCC 4.3 perl-Catalyst-Plugin-ConfigLoader-0.20-1.fc10 --------------------------------------------- * Sat May 10 18:00:00 2008 Chris Weyl 0.20-1 - update to 0.20 pyPdf-1.10-4.fc10 ----------------- allegro-4.2.2-10.fc10 --------------------- perl-SNMP_Session-1.12-1.fc10 ----------------------------- python-crypto-2.0.1-13.1 ------------------------ * Sun May 4 18:00:00 2008 Thorsten Leemhuis - 2.0.1-13 - provide pycrypto nexuiz-data-2.4-1.fc10 ---------------------- * Tue Apr 29 18:00:00 2008 Jon Ciesla - 2.4-1 - New upstream release. * Tue Aug 21 18:00:00 2007 Jon Ciesla - 2.3-3 - License tag correction. ftp-0.17-48.fc10 ---------------- * Wed Apr 23 18:00:00 2008 Martin Nagy - 0.17-48 - fix mget when using case - Resolves: #442712 R-DynDoc-1.18.0-1.fc10 ---------------------- * Fri May 2 18:00:00 2008 Pingou 1.18.0-1 - Update to bioconductor 2.2 gnome-applets-2.22.1-3.fc10 --------------------------- * Tue May 6 18:00:00 2008 Matthias Clasen - 1:2.22.1-3 - Drop gnome-netstatus dependency (#445059) libvoikko-1.7-0.1.rc2.fc10 -------------------------- * Sun May 11 18:00:00 2008 - Ville-Pekka Vainio 1.7-0.1.rc2 - New release candidate dumpasn1-20080414-1.fc10 ------------------------ * Fri May 2 18:00:00 2008 Ville Skytt?? - 20080414-1 - Update to 20080414. pycairo-1.4.12-3.fc10 --------------------- * Wed May 7 18:00:00 2008 Matthew Barnes - 1.4.12-3 - Add more documentation files to the package (RH bug #445519). blender-2.46-0.3.fc10 --------------------- * Tue May 6 18:00:00 2008 Jochen Schmitt 2.46-0.3 - Release Canditate for 2.46 * Sun Apr 27 18:00:00 2008 Jochen Schmitt 2.45-13 - More generic patch for scons issue R-BufferedMatrix-1.4.0-1.fc10 ----------------------------- * Fri May 2 18:00:00 2008 Pingou 1.4.0-1 - Update to bioconductor 2.2 mono-basic-1.9-4.fc10 --------------------- * Tue Apr 29 18:00:00 2008 Paul F. Johnson 1.9-4 - spec file changelog fix - added BR pkgconfig * Mon Apr 21 18:00:00 2008 Paul F. Johnson 1.9-3 - added devel subpackage - removed debug package mrtg-2.16.1-2.fc10 ------------------ * Tue Apr 22 18:00:00 2008 Vitezslav Crhonek - 2.16.1-2 - Rebuild Resolves: #443116 gfs-bodoni-classic-fonts-20070415-6.fc10 ---------------------------------------- * Wed Apr 30 18:00:00 2008 Nicolas Mailhot - 20070415-6 ??? Yet another prep fix?? opal-2.2.11-4.fc10 ------------------ * Mon May 12 18:00:00 2008 Paul W. Frields - 2.2.11-4 - Rebuild in service of ekiga (#441202) upstart-0.3.9-18.fc10 --------------------- metacity-2.23.13-1.fc10 ----------------------- * Mon May 5 18:00:00 2008 Matthias Clasen - 2.23.13-1 - Update to 2.23.13 gqview-2.0.4-7 -------------- * Thu May 8 18:00:00 2008 Michael Schwendt - 2.0.4-7 - scriptlets: run update-desktop-database without path - drop dependency on desktop-file-utils - update spec file with more dir macros - include GQ_HELPDIR and GQ_HTMLDIR via _docdir python-lxml-2.0.5-1.fc10 ------------------------ * Thu May 8 18:00:00 2008 Jeffrey C. Ollie - 2.0.5-1 - Update to 2.0.5 taskjuggler-2.4.1-0.1.beta2.fc10 -------------------------------- * Mon Apr 28 18:00:00 2008 Ondrej Vasik - 2.4.1-0.1.beta2 - upstream beta2 release candidate wget-1.11.2-1.fc10 ------------------ * Fri May 9 18:00:00 2008 Karsten Hopp 1.11.2-1 - wget-1.11.2, fixes #179962 cman-2.0.60-6.fc10 ------------------ * Wed Apr 23 18:00:00 2008 Chris Feist - 2.0.60.6 - Turn off scsi_reserve script by default. (bz#441277) cmucl-19e-0.3.pre2.fc10 ----------------------- * Mon Apr 21 18:00:00 2008 Rex Dieter 19e-0.3.pre2 - cmucl-19e-pre2 * Fri Mar 14 18:00:00 2008 Rex Dieter 19e-0.2.pre1 - gcc43 patch * Thu Mar 13 18:00:00 2008 Rex Dieter 19e-0.1.pre1 - cmucl-19e-pre1 * Tue Feb 19 17:00:00 2008 Fedora Release Engineering - 19d-6 - Autorebuild for GCC 4.3 malaga-suomi-voikko-1.1-1.fc10 ------------------------------ * Mon Apr 28 18:00:00 2008 - Ville-Pekka Vainio 1.1-1 - Suomi-malaga 1.1 atop-1.23-7.fc10 ---------------- * Mon May 5 18:00:00 2008 Kairo Araujo - 1.23-7 - add bug fixes for #445174 file-roller-2.23.1-1.fc10 ------------------------- * Thu Apr 24 18:00:00 2008 Matthias Clasen - 2.23.1-1 - Update to 2.23.1 kdemultimedia-4.0.72-1.fc10 --------------------------- * Sat May 10 18:00:00 2008 Kevin Kofler 4.0.72-1 - update to 4.0.72 - drop backported kmix-systray patch - Obsoletes/Provides dragonplayer, add it to description and file list - add BR xine-lib-devel for dragonplayer dstat-0.6.7-3.fc10 ------------------ * Fri Apr 25 18:00:00 2008 Radek Brich - 0.6.7-3 - fix dbus module (new dbus-python interface since FC4) gossip-0.29-1.fc10 ------------------ * Thu May 8 18:00:00 2008 Brian Pepple - 0.29-1 - Update to 0.29. - Add BR on eds-devel. php-pecl-mailparse-2.1.4-1.fc9 ------------------------------ * Mon Apr 14 18:00:00 2008 Remi Collet 2.1.4-1 - update to 2.1.4 (bugfix) - package2.xml is now provided gtk2-2.13.0-2.fc10 ------------------ * Thu May 1 18:00:00 2008 Christopher Aillon - 2.13.0-2 - Remove trailing comma from the enum so -pedantic compiles work * Thu Apr 24 18:00:00 2008 Matthias Clasen - 2.13.0-1 - Update to 2.13.0 mozilla-filesystem-1.9-2.fc10 ----------------------------- transmission-1.11-2.fc10 ------------------------ * Tue May 6 18:00:00 2008 Denis Leroy - 1.11-2 - Patch to fix opening issue from browser (#431769) - Patch to fix hardcoded optimize compile flags * Fri May 2 18:00:00 2008 Denis Leroy - 1.11-1 - Update to upstream 1.11, many bug fixes glusterfs-1.3.8-1.fc10 ---------------------- * Fri May 9 18:00:00 2008 Matthias Saou 1.3.8-1 - Update to 1.3.8 final. * Wed Apr 23 18:00:00 2008 Matthias Saou 1.3.8-0.10 - Include short patch to include fixes from latest TLA 751. * Tue Apr 22 18:00:00 2008 Matthias Saou 1.3.8-0.9 - Update to 1.3.8pre6. - Include glusterfs binary in both the client and server packages, now that glusterfsd is a symlink to it instead of a separate binary. octave-3.0.1-1.fc10 ------------------- * Mon Apr 21 18:00:00 2008 Quentin Spencer 3.0.1-1 - New release of octave. Remove gcc 4.3 patch. device-mapper-multipath-0.4.7-15.fc10 ------------------------------------- * Tue May 6 18:00:00 2008 Alasdair Kergon - 0.4.7-15 - Remove unnecessary multipath & kpartx static binaries. (bz 234928) * Fri Feb 29 17:00:00 2008 Tom "spot" Callaway - 0.4.7-14 - fix sparc64 - fix license tag * Tue Feb 19 17:00:00 2008 Fedora Release Engineering - 0.4.7-13 - Autorebuild for GCC 4.3 * Wed Nov 14 17:00:00 2007 Benjamin Marzinski - 0.4.7-12 - Fixed the dist tag so building will work properly. firefox-3.0-0.59.cvs20080408.fc10 --------------------------------- gcalctool-5.23.1-1.fc10 ----------------------- * Thu Apr 24 18:00:00 2008 Matthias Clasen - 5.23.1-1 - Update to 5.23.1 evolution-2.23.2-1.fc10 ----------------------- * Mon May 12 18:00:00 2008 Matthew Barnes - 2.23.2-1.fc10 - Update to 2.23.2 - Remove enchant-devel requirement. - Remove patch for RH bug #437208 (fixed upstream). smb4k-0.9.4-1.fc10 ------------------ * Tue Apr 29 18:00:00 2008 Marcin Garski 0.9.4-1 - Update to 0.9.4 lzo-2.03-1.fc10 --------------- * Thu May 1 18:00:00 2008 Lubomir Rintel 2.03-1 - New upstream release - Changed the license to GPLv2+ * Wed Apr 2 18:00:00 2008 Hans de Goede 2.02-5 - Fix configure failure with -Werror-implicit-function-declaration in CFLAGS - Add a minilzo subpackage which contains a shared version of minilzo, to be used by all applications which ship with their own copy of it (bz 439979) ocaml-pcre-5.14.0-2.fc10 ------------------------ * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 5.14.0-2 - Rebuild for OCaml 3.10.2 * Mon Apr 21 18:00:00 2008 Richard W.M. Jones - 5.14.0-1 - New upstream release 5.14.0. - -devel subpackage should depend on pcre-devel. - Fixed upstream URL. - Changed to use .bz2 package. pinot-0.85-1.fc10 ----------------- * Mon May 12 18:00:00 2008 Adel Gadllah 0.85-1 - Update to 0.85 libepc-0.3.5-1.fc10 ------------------- * Tue Apr 22 18:00:00 2008 Brian Pepple - 0.3.5-1 - Update to 0.3.5. SIBsim4-0.17-1.fc10 ------------------- * Wed May 7 18:00:00 2008 Christian Iseli 0.17-1 - Version 0.17. gjots2-2.3.4-8.fc10 ------------------- * Tue May 6 18:00:00 2008 Radek Vok??l 2.3.4-8 - rebuilt pdns-recursor-3.1.6-1.fc10 -------------------------- * Sun May 11 18:00:00 2008 Ruben Kerkhof - 3.1.6 - Upstream released new version OpenEXR-1.6.1-4.fc10 -------------------- * Fri May 9 18:00:00 2008 Rex Dieter 1.6.1-4 - drop: Obsoletes: OpenEXR-utils (see OpenEXR_Viewers review, bug #428228c3) gtk-doc-1.10-1.fc10 ------------------- * Thu Apr 24 18:00:00 2008 Matthias Clasen - 1.10-1 - Update to 1.10 xdvik-22.84.13-20.fc10 ---------------------- * Sat May 10 18:00:00 2008 Jonathan G. Underwood - 22.84.13-20 - Update Japanese patch to xdvik-22.84.13-j1.40.patch.gz - Rework patch to allow simultaneous building of xdvik and pxdvik - now called xdvik-22.84.13-pxdvi.patch - Rename vfontmap to xdvi-ptex.map - Rework patch to build pxdvik against system installed libraries - now called xdvik-22.84.13-pxdvi-use-system-libs.patch * Mon Apr 28 18:00:00 2008 Jonathan G. Underwood - 22.84.13-19 - Add more commentary about upstream status of patches - No longer apply the texlive-xdvi-maxchar.patch patch * Mon Apr 28 18:00:00 2008 Jonathan G. Underwood - 22.84.13-18 - Remove extraneous -r from cp command - Add commentary about upstream status of patches - Re-enable _texmf_main macro - Add patch to fix window ID detection - BZ 442445 gnome-menus-2.23.1-1.fc10 ------------------------- * Fri Apr 25 18:00:00 2008 Matthias Clasen - 2.23.1-1 - Update to 2.23.1 pychecker-0.8.17-4 ------------------ * Tue Apr 29 18:00:00 2008 Vitezslav Crhonek - 0.8.17-4 - Add minor improvements to pychecker2/main.py (patch by Stani's Python Editor folks) Resolves: #443416 * Thu Apr 10 18:00:00 2008 Vitezslav Crhonek - 0.8.17-3 - Spec file cleanup (fix Buildroot, fix License, fix %files) perl-Net-DNS-0.63-4.fc10 ------------------------ * Mon May 12 18:00:00 2008 Marcela Maslanova - 0.63-4 - 437681 remove previous patch and use upstream patch, which should solve all problems with noisy logs. gtk2-engines-2.15.0-1.fc10 -------------------------- * Fri Apr 25 18:00:00 2008 Matthias Clasen - 2.15.0-1 - Update to 2.15.0 nntpgrab-0.2.5-1.fc9 -------------------- * Tue Apr 29 18:00:00 2008 Erik van Pienbroek - 0.2.5-1 - Update to version 0.2.5 - Small packaging fix audit-1.7.3-1.fc10 ------------------ * Fri May 9 18:00:00 2008 Steve Grubb 1.7.3-1 - Fix output of keys in ausearch interpretted mode - Fix ausearch/report --start now to not be reset to midnight - audispd now has a priority boost config option - Look for laddr in avcs reported via prelude - Detect page 0 mmaps and alert via prelude phpMyAdmin-2.11.6-1.fc10 ------------------------ * Tue Apr 29 18:00:00 2008 Robert Scheck 2.11.6 - Upstream released 2.11.6 sonata-1.5.1-1.fc10 ------------------- * Fri May 9 18:00:00 2008 Micha?? Bentkowski - 1.5.1-1 - 1.5.1 * Sun Apr 13 18:00:00 2008 Micha?? Bentkowski - 1.5-2 - Now sonata requires python-mpd (bug 441114) uncrustify-0.46-1.fc10 ---------------------- * Thu Apr 24 18:00:00 2008 Neal Becker - 0.46-1 - Update to 0.46 inn-2.4.3-14.fc10 ----------------- * Thu Apr 24 18:00:00 2008 Ondrej Vasik - 2.4.3-14 - make /var/spool/news/incoming writable for news group (#426760) - changes because of /sbin/nologin shell for news user * Wed Apr 9 18:00:00 2008 Ondrej Vasik - 2.4.3-13 - few documentation changes because of /sbin/nologin shell for news user (su - news -c will not work in that case ) #233738 Pyrex-0.9.6.4-2.fc10 -------------------- * Tue May 6 18:00:00 2008 Matthew Barnes - 0:0.9.6.4-2 - Require pkgconfig for building. * Mon May 5 18:00:00 2008 Kyle VanderBeek - 0:0.9.6.4-1 - Update to 0.9.6.4 - Add sub-package for emacs mode. perl-XML-Entities-0.03-1.fc9 ---------------------------- * Thu Apr 10 18:00:00 2008 Remi Collet 0.03-1 - update to 0.03 python-simplejson-1.9.1-1.fc10 ------------------------------ * Tue May 6 18:00:00 2008 Luke Macken - 1.9.1-1 - Update to 1.9.1 ocsinventory-agent-0.0.9.2-1.fc10 --------------------------------- * Sun Apr 20 18:00:00 2008 Remi Collet 0.0.9.2-1 - update to 0.0.9.2 (minor bug fix) VLGothic-fonts-20080429-1.fc10 ------------------------------ * Wed May 7 18:00:00 2008 Jens Petersen - 20080429-1 - update to 20080429 release - rename 59-VLGothic-sans.conf to 59-VLGothic-proportional.conf mono-cecil-flowanalysis-0.1-0.5.20080409svn100264.fc10 ------------------------------------------------------ NetworkManager-openvpn-0.7.0-10.svn3632.fc10 -------------------------------------------- foomatic-3.0.2-60.fc10 ---------------------- * Thu May 8 18:00:00 2008 Tim Waugh 3.0.2-60 - Updated filters to 3.0-20080507. * Wed May 7 18:00:00 2008 Tim Waugh - Avoid busy-looping when the CUPS backend stops (bug #445555). ocaml-camlimages-2.2.0-11.fc10 ------------------------------ * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 2.2.0-11 - Rebuild for OCaml 3.10.2 freeciv-2.1.4-1.fc10 -------------------- * Tue Apr 29 18:00:00 2008 Brian Pepple - 2.1.4-1 - Update to 2.1.4. gnome-media-2.23.1.1-2.fc10 --------------------------- * Fri Apr 25 18:00:00 2008 Matthias Clasen - 2.23.1.1-1 - Update to 2.23.1.1 NetworkManager-0.7.0-0.9.3.svn3623.fc10 --------------------------------------- xfsprogs-2.9.8-1.fc10 --------------------- * Wed Apr 23 18:00:00 2008 Eric Sandeen 2.9.8-1 - Update to xfsprogs 2.9.8 - Add support for sb_features2 in wrong location - Add -c option to xfs_admin to turn lazy-counters on/off - Added support for mdp in libdisk/mkfs.xfs eel2-2.23.1-1.fc10 ------------------ * Wed Apr 23 18:00:00 2008 Tomas Bzatek - 2.23.1-1 - Update to 2.23.1 mono-sharpcvslib-0.35-2.fc10 ---------------------------- findutils-4.4.0-1.fc10 ---------------------- * Wed Apr 30 18:00:00 2008 Vitezslav Crhonek - 1:4.4.0-1 - Update to findutils-4.4.0 Resolves: #437733 gnome-applet-music-2.3.1-1.fc10 ------------------------------- * Sat May 3 18:00:00 2008 Peter Gordon - 2.3.1-1 - Update to new upstream release (2.3.1), which fixes an Amarok plugin crasher and contains several updated translations. - Drop external Spanish translation and patch (both applied upstream): - es.po - add-es-translation.patch ocaml-camlp5-5.08-3.fc10 ------------------------ * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 5.08-3 - Rebuild for OCaml 3.10.2. irqbalance-0.55-9.fc10 ---------------------- gfs-bodoni-fonts-20070415-5.fc10 -------------------------------- * Wed Apr 30 18:00:00 2008 Nicolas Mailhot - 20070415-5 ??? Yet another prep fix?? kdesdk-4.0.72-1.fc10 -------------------- * Tue May 13 18:00:00 2008 Kevin Kofler 4.0.72-1 - update to 4.0.72 - Obsoletes/Provides kaider (now part of kdesdk, renamed to lokalize) - add lokalize to description and file list - add BR strigi-devel for lokalize - add BR boost-devel (now needed by Umbrello) xine-plugin-1.0.1-2.fc10 ------------------------ * Wed Apr 23 18:00:00 2008 Martin Sourada - 1.0.1-2 - remove the dropped patch from spec file completely * Tue Apr 22 18:00:00 2008 Martin Sourada - 1.0.1-1 - new upstream release - drop the xine-lib version patch - fixed in upstream plib-1.8.5-1.fc10 ----------------- * Sun Apr 13 18:00:00 2008 Hans de Goede 1.8.5-1 - New upstream release 1.8.5 rrdtool-1.3-0.14.beta4.fc10 --------------------------- * Wed Apr 30 18:00:00 2008 Jarod Wilson 1.3.0-0.14.beta4 - Drop some conditional flags, they're not working at the moment... * Wed Apr 30 18:00:00 2008 Jarod Wilson 1.3.0-0.13.beta4 - Fix problem with cairo_save/cairo_restore (#444827) totem-pl-parser-2.23.1-1.fc10 ----------------------------- * Fri May 9 18:00:00 2008 - Bastien Nocera - 2.23.1-1 - Update to 2.23.1 - Remove gnome-vfs2 dependencies * Wed May 7 18:00:00 2008 - Bastien Nocera - 2.22.2-3 - Rebuild for new libcamel * Sun May 4 18:00:00 2008 Matthias Clasen - 2.22.2-2 - Fix source url ocaml-lacaml-4.3.2-1.fc10 ------------------------- * Fri May 2 18:00:00 2008 Richard W.M. Jones - 4.3.2-1 - New upstream version 4.3.2. * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 4.3.1-2 - Rebuild for OCaml 3.10.2 * Mon Apr 21 18:00:00 2008 Richard W.M. Jones - 4.3.1-1 - New upstream release 4.3.1. - Fix upstream URL. opencv-1.0.0-8.fc10 ------------------- * Sun May 11 18:00:00 2008 Ralf Cors??pius - 1.0.0-8 - Adjust library order in opencv.pc.in (BZ 445937). python-alsa-1.0.16-1.fc10 ------------------------- * Sun May 4 18:00:00 2008 Andy Shevchenko - 1.0.16-1 - update to release 1.0.16 libpfm-3.4-1.fc10 ----------------- * Fri May 2 18:00:00 2008 Will Cohen - 3.4-1 - Update to libpfm-3.4. fedora-release-9.90-1 --------------------- waf-1.4.1-1.fc10 ---------------- * Sun May 4 18:00:00 2008 Thomas Moschny - 1.4.1-1 - Update to upstream version 1.4.1. * Sat Apr 19 18:00:00 2008 Thomas Moschny - 1.4.0-1 - Update to upstream version 1.4.0. * Wed Apr 9 18:00:00 2008 Thomas Moschny - 1.3.2-6 - Upstream patch to fix latex dependency scanning: trunk rev 2340. autofs-5.0.3-14 --------------- * Mon May 12 18:00:00 2008 Ian Kent - 5.0.3-14 - check for nohide mounts (bz 442618). - ignore nsswitch sources that aren't supported (bz 445880). * Thu Apr 17 18:00:00 2008 Ian Kent - 5.0.3-13 - fix typo in patch for incorrect pthreads condition handling patch. * Mon Apr 14 18:00:00 2008 Ian Kent - 5.0.3-12 - fix incorrect pthreads condition handling for mount requests. kvm-68-1.fc10 ------------- * Mon May 5 18:00:00 2008 Daniel P. Berrange - 68-1 - Update to kvm-68 - Put text console PTY in rawmode * Tue Apr 29 18:00:00 2008 Mark McLoughlin - 65-2 - Fix -kernel with virtio/extboot drives (#444578) system-config-date-1.9.31-1.fc10 -------------------------------- * Mon May 5 18:00:00 2008 Nils Philippsen - 1.9.31-1 - translate underscores to spaces when reading in zone names (#444093, patch by Jeremy Katz) xenner-0.33-1.fc10 ------------------ * Thu May 8 18:00:00 2008 Gerd Hoffmann - 0.33-1.fc10 - update to version 0.33 - implement correct iopl handling (uncrash kudzu). - misc fixes. * Mon May 5 18:00:00 2008 Gerd Hoffmann - 0.32-1.fc10 - update to version 0.32 - guest irq balancing. - misc fixes. * Wed Apr 23 18:00:00 2008 Gerd Hoffmann - 0.31-1.fc10 - update to version 0.31 - smp guest support. - fixed tcp/udp checksumming. - misc minor fixes. kdenetwork-4.0.72-2.fc10 ------------------------ * Wed May 7 18:00:00 2008 Kevin Kofler 4.0.72-2 - add BR gmp-devel, libotr-devel, soprano-devel * Wed May 7 18:00:00 2008 Kevin Kofler 4.0.72-1 - update to 4.0.72 - drop backported kde#160728 patch - update file list qscintilla-2.2-1.fc10 --------------------- * Mon May 5 18:00:00 2008 Rex Dieter - 2.2-1 - Qscintilla-gpl-2.2 - License: GPLv3 or GPLv2 with exceptions hdf5-1.8.0.snap5-1.fc10 ----------------------- * Mon May 5 18:00:00 2008 Orion Poplawski 1.8.0.snap5-1 - Update to 1.8.0-snap5 - Remove --enable-threadsafe, incompatible with --enable-cxx and --enable-fortran - ExcludeArch ppc64 until we can get it to build (bug #445423) * Tue Mar 4 17:00:00 2008 Orion Poplawski 1.8.0-2 - Remove failing test for now libgweather-2.23.1-1.fc10 ------------------------- * Thu Apr 24 18:00:00 2008 Matthias Clasen 2.23.1-1 - Update to 2.23.1 filezilla-3.0.9.3-1.fc9 ----------------------- * Wed May 7 18:00:00 2008 kwizart < kwizart at gmail.com > - 3.0.9.3-1 - Update to 3.0.9.3 cvs2svn-2.1.1-1.fc10 -------------------- * Sat May 10 18:00:00 2008 Konstantin Ryabitsev - 2.1.1-1 - Upstream 2.1.1 ocaml-newt-0.9-2.fc10 --------------------- * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 0.9-2 - Rebuild for OCaml 3.10.2 prelude-manager-0.9.12.1-1.fc10 ------------------------------- * Fri May 2 18:00:00 2008 Steve Grubb 0.9.12.1-1 - new upstream version 0.9.12.1 * Thu Apr 24 18:00:00 2008 Steve Grubb 0.9.12-1 - new upstream version 0.9.12 logwatch-7.3.6-22.fc10 ---------------------- * Wed Apr 30 18:00:00 2008 Ivana Varekova 7.3.6-22 - Resolves: #436719 Logwatch doesn't show any usable sendmail section kexec-tools-1.102pre-10.fc10 ---------------------------- * Thu Apr 24 18:00:00 2008 Neil Horman - 1.102pre-10 - Fix mkdumprd to properly pull in libs for lvm/mdadm (bz 443878) * Wed Apr 16 18:00:00 2008 Neil Horman - 1.102pre-9 - Fix cmdline length issue eggdrop-1.6.19-1.fc10 --------------------- poppler-0.8.1-1.fc10 -------------------- * Mon Apr 28 18:00:00 2008 Matthias Clasen - 0.8.1-1 - Update to 0.8.1 claws-mail-3.4.0-1.fc10 ----------------------- * Wed Apr 23 18:00:00 2008 Andreas Bierfert - 3.4.0-1 - version upgrade texmaker-1.7-1.fc10 ------------------- * Mon Apr 28 18:00:00 2008 Deji Akingunola - 1.7-1 - New Release ekiga-2.0.12-2.fc10 ------------------- * Mon May 12 18:00:00 2008 Paul W. Frields - 2.0.12-2 - Rebuild against new opal (#441202) * Thu Mar 13 18:00:00 2008 Daniel Veillard - 2.0.12-1.fc9 - Upgrade to ekiga-2.0.12 * Thu Feb 28 17:00:00 2008 Daniel Veillard - 2.0.11-4 - rebuild after applying some fo the cleanups of #160727 python-kiwi-1.9.21-1.fc10 ------------------------- * Sat May 10 18:00:00 2008 Konstantin Ryabitsev - 1.9.21-1 - Upstream 1.9.21 perl-File-Copy-Recursive-0.36-1.fc10 ------------------------------------ * Wed Apr 23 18:00:00 2008 Ralf Cors??pius - 0.36-1 - Upstream update. pm-utils-1.1.1-2.fc10 --------------------- * Mon May 12 18:00:00 2008 Richard Hughes - 1.1.1-2 - Add missing BR for docbook-utils * Mon May 12 18:00:00 2008 Richard Hughes - 1.1.1-1 - Update to 1.1.1, and drop patches that no longer apply. * Wed Apr 30 18:00:00 2008 Richard Hughes - 1.1.0-9 - Remove the usermode dep on the advice of Till Maas. * Wed Apr 30 18:00:00 2008 Richard Hughes - 1.1.0-8 - Rip out all the consolehelper and PAM stuff - users are not meant to be running these tools directly and it's a massive change from upstream. crontabs-1.10-21.fc10 --------------------- * Mon May 5 18:00:00 2008 Marcela Maslanova 1.10-21 - 445079 delay script failed in case DELAY is zero * Fri Apr 4 18:00:00 2008 Marcela Maslanova 1.10-20 - 440410 log pid of process instead of logger's pid mono-1.9.1-2.fc10 ----------------- biosdevname-0.2.4-5.fc10 ------------------------ * Tue May 6 18:00:00 2008 Matt Domsch 0.2.4-5 - use policy=all_names to find breakage netpbm-10.35.43-1.fc10 ---------------------- * Mon May 12 18:00:00 2008 Jindrich Novy 10.35.43-1 - update to 10.35.43 - fixes pbmtext and documentation of pamthreshold * Mon Apr 14 18:00:00 2008 Jindrich Novy 10.35.42-1 - update to 10.35.42 - fixes pnmnorm, resolution of conflicting -wpercent and -wvalue dhcpv6-1.0.15-1.fc10 -------------------- * Wed Apr 23 18:00:00 2008 David Cantrell - 1.0.15-1 - Upgrade to dhcpv6-1.0.15, major changes: Check DUID and IAID for duplicate host entries Do not include Interface-ID option in RELAY-REPL messages Use the last 4 bytes of the MAC address to generate new IAIDs Handle multiple nameservers in option 23 in DHCPv6 reply Do not modify /etc/radvd.conf from dhcp6c(8) ipw2200-firmware-3.0-10 ----------------------- * Thu Apr 24 18:00:00 2008 Matthias Saou 3.0-10 - Remove LICENSE file from %doc (was +x), mark the other as %doc (#440553). - Remove the included older 2.4 firmware, since 3.0 has been required by all kernels for a long while now. zenity-2.23.1-1.fc10 -------------------- * Fri Apr 25 18:00:00 2008 Matthias Clasen - 2.23.1-1 - Update to 2.23.1 mono-addins-0.3.1-1.fc10 ------------------------ * Mon Apr 21 18:00:00 2008 Paul F. Johnson - 0.3.1-1 - bump (should fix the monodevelop problems) gfs-olga-fonts-20060908-5.fc10 ------------------------------ * Wed Apr 30 18:00:00 2008 Nicolas Mailhot - 20060908-5 ??? Yet another prep fix?? kphotoalbum-3.1.1-2.fc10 ------------------------ * Thu May 8 18:00:00 2008 Rex Dieter 3.1.1-2 - respin cduce-0.5.2.1-9.fc10 -------------------- * Thu Apr 24 18:00:00 2008 Richard W.M. Jones - 0.5.2.1-9 - Problem with the previous import to Koji - reimport. * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 0.5.2.1-8 - Forgot to change the OCaml version number in the header. * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 0.5.2.1-7 - Rebuild for OCaml 3.10.2 speex-1.2-0.8.beta3 ------------------- * Fri Apr 25 18:00:00 2008 Marcela Maslanova - 1.2-0.8.beta3 - 226428 review swig-1.3.35-1.fc10 ------------------ * Mon May 5 18:00:00 2008 Adam Tkac 1.3.35-1 - updated to latest upstream release WritRecogn-0.1.9-0.fc10 ----------------------- * Wed Apr 23 18:00:00 2008 Ding-Yi Chen - 0.1.9-0 - For users: - WritRecogn-manager options changes: - InputMethod: from -I to -i - Language: from -L to -l - Remove export option (-Q), as import option (-I) can cover its functionality. - [New] Import option (-I). It can import from either SQLite, XML or tomoe XML. The destination can be either SQLite, XML or tomoe XML as well. - Fix the bug of Sqlite database rebuild - Multiple debug (-D) flags indicate more debug level now. - Help -> About now available. - For developers: - Stroke recognizer is replaced by Radical recognizer. - WirtRecogn.xml updated to support relative box - WritRecogn.dtd becomes Writrecogn-.dtd - Gtk Doc is available in doc sub-package. nmh-1.3-RC1.1.fc10 ------------------ * Wed Apr 30 18:00:00 2008 Josh Bressers 0:1.3-RC1.1 - Update nmh to 1.3-RC1 vegastrike-data-0.5.0-2 ----------------------- * Thu May 8 18:00:00 2008 Hans de Goede 0.5.0-2 - Release bump for build in F-9 instead of F-10 (F-10 will inherit this, bump needed due to deliberately not using disttag) * Sat May 3 18:00:00 2008 Hans de Goede 0.5.0-1 - New upstream release 0.5.0 online-desktop-0.2.28-1.fc10 ---------------------------- idm-console-framework-1.1.1-3.fc8 --------------------------------- * Tue Apr 15 18:00:00 2008 Rich Megginson 1.1.1-3 - use java > 1.5.0 for the requirements * Mon Apr 14 18:00:00 2008 Rich Megginson 1.1.1-2 - install jar files with mode 644 scim-chewing-0.3.1-15.fc10 -------------------------- * Wed Apr 9 18:00:00 2008 Caius Chance 0.3.1-15.fc10 - Resolves: rhbz#195416 (Initial input mode configuration.) - Modified patch naming in .spec file. * Tue Apr 8 18:00:00 2008 Caius Chance 0.3.1-14.fc9 - Resolves: rhbz#228428 (Ctrl-v during preedit appears in buffer on Qt XIM.) ocaml-SDL-0.7.2-12.fc10 ----------------------- * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 0.7.2-12 - Rebuild for OCaml 3.10.2. * Sat Apr 19 18:00:00 2008 Richard W.M. Jones - 0.7.2-11 - Add commas in dependencies & rebuild. blobAndConquer-0.92-1.fc10 -------------------------- * Mon Apr 28 18:00:00 2008 Hans de Goede 0.92-1 - New upstream release 0.92 nautilus-2.23.1-4.fc10 ---------------------- fuse-s3fs-0.4-10.fc10 --------------------- * Thu Apr 24 18:00:00 2008 Neil Horman 0.4-9 - Backport noargs abort patch (bz 443965) ocaml-fileutils-0.3.0-5.fc10 ---------------------------- * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 0.3.0-5 - Rebuild for OCaml 3.10.2 deluge-0.5.9.0-1.fc10 --------------------- * Fri May 2 18:00:00 2008 Peter Gordon - 0.5.9.0-1 - Update to new upstream release (0.5.9.0) - Drop upstreamed default-preferences patch for disabling new version notifications: - default-prefs-no-release-notifications.patch * Tue Apr 15 18:00:00 2008 Peter Gordon - 0.5.8.9-1 - Update to new upstream release (0.5.8.9) * Wed Mar 26 18:00:00 2008 Peter Gordon - 0.5.8.7-1 - Update to new upstream release (0.5.8.7) libgnomekbd-2.23.2-1.fc10 ------------------------- * Sun May 11 18:00:00 2008 Matthias Clasen - 2.23.2-1 - Update to 2.23.2 gfs-porson-fonts-20060908-7.fc10 -------------------------------- * Wed Apr 30 18:00:00 2008 Nicolas Mailhot - 20060908-7 ??? Yet another prep fix?? lirc-0.8.3-1.fc10 ----------------- * Sun May 4 18:00:00 2008 Jarod Wilson - 0.8.3-1 - Update to 0.8.3 release * Sun Apr 27 18:00:00 2008 Jarod Wilson - 0.8.3-0.4.pre3 - Update to 0.8.3pre3 evolution-exchange-2.23.2-1.fc10 -------------------------------- * Mon May 12 18:00:00 2008 Matthew Barnes - 2.23.2-1.fc10 - Update to 2.23.2 * Mon Apr 21 18:00:00 2008 Matthew Barnes - 2.23.1-1.fc10 - Update to 2.23.1 - Bump evo_major to 2.24. - Bump evo_version to 2.23.1. - Bump eds_version to 2.23.1. libnova-0.12.1-3.fc10 --------------------- asc-2.1.0.0-1.fc10 ------------------ * Mon Apr 14 18:00:00 2008 Hans de Goede 2.1.0.0-1 - New upstream version 2.1.0.0 perl-Image-ExifTool-7.25-1.fc10 ------------------------------- * Fri Apr 25 18:00:00 2008 Tom "spot" Callaway 7.25-1 - update to 7.25 anaconda-11.4.1.0-1 ------------------- * Mon May 12 18:00:00 2008 Jeremy Katz - 11.4.0.79-1 - Stop neutering DRI (notting) - make scripts/buildinstall take multiple repos (wwoods) - Don't worry about telling people that interactive text mode is in wrong lang (katzj) - Allow cpio updates.img in the tree for URL installs. (dlehman) - Declare unpackCpioBall for use from within urlinstall.c. (dlehman) - Don't unlink an image we retrieved but could not mount as it could be .cgz. (dlehman) - Don't run lspci with an explicit path (katzj) - Include lspci on all images (#445974) (katzj) - Add support for attaching gdbserver to the loader early on. (clumens) - Add virtio max partition count (markmc) - Sort virtio devices first (markmc) - Merge branch 'master' of ssh://git.fedorahosted.org/git/anaconda (andrewm) - 2008-05-08 Andrew Martynov 3.16-1 - own directory of rpcsvc headers(#442143) - new upstream release bzr-1.4-1.fc10 -------------- * Mon May 5 18:00:00 2008 Toshio Kuratomi - 1.4-1 - Update to 1.4. themonospot-0.7.0.1-1.fc10 -------------------------- * Thu May 1 18:00:00 2008 hman 0.7.0.1-1 - new feature: Issue 009 - add Matroska (mkv) file type support - bug fixed: open avi,divx,xvid files with extention (Avi,AVI,DivX,Divx,DIVX,Xvid,XviD,XVID) <> avi,divx,xvid - bug fixed: minor bugs python-boto-1.2a-1.fc10 ----------------------- * Wed May 7 18:00:00 2008 Robert Scheck 1.2a-1 - Upgrade to 1.2a ocaml-xmlrpc-light-0.6-3.fc10 ----------------------------- * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 0.6-3 - Rebuild for OCaml 3.10.2 nfs-utils-1.1.2-5.fc10 ---------------------- * Thu May 8 18:00:00 2008 Steve Dickson 1.1.2-5 - Added 10 (101 thru 110) upstream patches that fixed things mostly in the mount and gssd code. * Wed May 7 18:00:00 2008 Steve Dickson 1.1.2-4 - Added ppc arch to the all_32bit_archs list (bz 442847) * Wed Apr 23 18:00:00 2008 Steve Dickson 1.1.2-3 - Documented how to turn off/on protocol support for rpc.nfsd in /etc/sysconfig/nfs (bz443625) - Corrected the nfslock initscript 'status' return code (bz 441605) - Removed obsolete code from the nfslock initscript (bz 441604) libkexiv2-0.1.7-1.fc10 ---------------------- * Thu May 8 18:00:00 2008 Rex Dieter 1.1.7-1 - libkexiv2-0.1.7 dbench-4.0-2.fc10 ----------------- * Mon Apr 14 18:00:00 2008 Rahul Sundaram - 4.0-2 - Fix BR's * Mon Apr 14 18:00:00 2008 Rahul Sundaram - 4.0-1 - Fix patch * Mon Apr 14 18:00:00 2008 Rahul Sundaram - 4.0-0 - New upstream release 4.0 ocaml-pxp-1.2.0test2-3.fc10 --------------------------- * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 1.2.0test2-3 - ExcludeArch ppc64 (bz #443899). * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 1.2.0test2-2 - Rebuild for OCaml 3.10.2 * Wed Apr 2 18:00:00 2008 Richard W.M. Jones - 1.2.0test2-1 - New upstream version 1.2.0test2. - New upstream URL. - Re-enabled camlp4 extension. ipa-1.0.0-4.fc10 ---------------- * Tue Apr 29 18:00:00 2008 Rob Crittenden - 1.0.0-4 - Add missing entry for /var/cache/ipa/kpasswd (444624) - Added patch to fix permissions problems with the Apache NSS database. - Added patch to fix problem with DNS querying where the query could be returned as the answer. - Fix spec error where patch1 was in the wrong section xterm-235-1.fc10 ---------------- * Tue Apr 22 18:00:00 2008 Miroslav Lichvar 235-1 - update to 235 nginx-0.6.31-1.fc10 ------------------- * Mon May 12 18:00:00 2008 Jeremy Hinegardner - 0.6.31-2 - update to 0.6.31 * Sun May 11 18:00:00 2008 Jeremy Hinegardner - 0.6.30-2 - upate to new upstream stable branch 0.6 - added 3rd party module nginx-upstream-fair - added default webpages * Sun Apr 20 18:00:00 2008 Jeremy Hinegardner - 0.5.35-2 - update init script to match recommended guidelines - add /etc/nginx/conf.d support [#443280] - use /etc/sysconfig/nginx to determine nginx.conf [#442708] GConf2-2.22.0-6.fc10 -------------------- * Mon May 12 18:00:00 2008 Ray Strode - 2.22.0-6 - If the session bus isn't running, don't autolaunch it unless we also want to autostart gconfd. * Thu May 8 18:00:00 2008 Ray Strode - 2.22.0-5 - Tie gconf to session bus. This means it will exit when the session exits and won't leave /tmp/gconf-$USER DoS possibilities * Sun May 4 18:00:00 2008 Matthias Clasen - 2.22.0-4 - Apply some patches: - Don't spam syslog - Handle unsetting mandatory keys without critical warnings * Fri May 2 18:00:00 2008 Matthias Clasen - 2.22.0-3 - Add a dbus service to set defaults * Fri May 2 18:00:00 2008 Matthias Clasen - 2.22.0-2 - Use g_timeout_add_seconds for long timeouts sugar-toolkit-0.79.6-1.fc10 --------------------------- * Thu Apr 24 18:00:00 2008 Simon Schampijer - 0.79.6-1 - Fix activity installation nvclock-0.8-0.6.b3a.fc10 ------------------------ * Mon May 12 18:00:00 2008 Adel Gadllah 0.8-0.6.b3a - Fix possible crasher freetennis-0.4.8-11.fc10 ------------------------ * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 0.4.8-11 - Rebuild for OCaml 3.10.2 conmux-0.0-7.493svn.fc10 ------------------------ * Wed May 7 18:00:00 2008 Michal Schmidt 0.0-7.493svn - "GPL" is ambiguous, the license is GPLv2 specifically - conmux-client ships a perl module, so it must require MODULE_COMPAT as described in the packaging guidelines. Fixes bug 443273. kdepimlibs-4.0.72-2.fc10 ------------------------ * Mon May 5 18:00:00 2008 Kevin Kofler - 4.0.72-2 - add BR akonadi-devel - update file list * Fri May 2 18:00:00 2008 Kevin Kofler - 4.0.72-1 - update to 4.0.72 (4.1 alpha 1) dasher-4.9.0-1.fc10 ------------------- * Fri Apr 25 18:00:00 2008 Matthias Clasen - 4.9.0-1 - Update to 4.9.0 - Build with --enable-japanese and --enable-chinese (#444131) warzone2100-2.1.0-0.5.beta2.fc10 -------------------------------- * Tue Apr 22 18:00:00 2008 Karol Trzcionka - 2.1.0-0.5.beta2 - Update to v2.1.0-beta2 - Add requires * Mon Mar 3 17:00:00 2008 Karol Trzcionka - 2.1.0-0.4.beta1 - Fix ppc build * Sun Mar 2 17:00:00 2008 Karol Trzcionka - 2.1.0-0.3.beta1 - add translations * Sun Mar 2 17:00:00 2008 Karol Trzcionka - 2.1.0-0.2.beta1 - Fix BRs * Sun Mar 2 17:00:00 2008 Karol Trzcionka - 2.1.0-0.1.beta1 - Update to v2.1.0-beta1 - Remove ExcludeArch hal-info-20080508-1.fc10 ------------------------ * Fri May 9 18:00:00 2008 Richard Hughes - 20080508-1 - Update to latest upstream release gc-7.1-1.fc10 ------------- * Sun May 4 18:00:00 2008 Rex Dieter 7.1-1 - gc-7.1 - purge rpaths uudeview-0.5.20-16 ------------------ * Sun Apr 27 18:00:00 2008 Patrice Dumas - 0.5.20-16 - rename uulib-static to uulib-devel - use tex(latex) provides kdebase-runtime-4.0.72-2.fc10 ----------------------------- * Tue May 6 18:00:00 2008 Kevin Kofler 4.0.72-2 - BR new minimum version of soprano-devel * Tue May 6 18:00:00 2008 Kevin Kofler 4.0.72-1 - update to 4.0.72 (4.1 alpha 1) - drop upstreamed deinterlace-crash patch - drop khelpcenter patch (fixed upstream) - update Phonon PulseAudio patch - drop Fedora 7 support - update file list * Mon Apr 28 18:00:00 2008 Rex Dieter 4.0.3-10.1 - omit conflicting icons (kde3_desktop=1 case) ocaml-zip-1.03-4.fc10 --------------------- * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 1.03-4 - Rebuild for OCaml 3.10.2 logrotate-3.7.6-4.fc10 ---------------------- * Wed Apr 23 18:00:00 2008 Tomas Smetana 3.7.6-4 - improve patch for #432330 - fix #437748 - don't forget to close log files alsa-utils-1.0.16-3.fc10 ------------------------ * Mon Apr 28 18:00:00 2008 Martin Stransky 1.0.16-3 - Added alsa-info.sh script to /usr/bin/alsa-info gnome-themes-2.23.1-1.fc10 -------------------------- * Thu Apr 24 18:00:00 2008 Matthias Clasen - 2.23.1-1 - Update to 2.23.1 jna-3.0.2-7.fc10 ---------------- gpsbabel-1.3.5-1.fc10 --------------------- * Sat May 9 18:00:00 2009 Douglas E. Warner - 1.3.5-1 - update to 1.3.5 - switching out variables for macros; adding macros for commands - fixing license to be GPLv2+ - adding patch to fix re-running autoconf - perserving times when installing gpsbabel mono-ndoc-1.3.1-2.fc10 ---------------------- perl-Socket6-0.20-1.fc10 ------------------------ cowbell-0.2.7.1-10.fc10 ----------------------- * Wed Apr 23 18:00:00 2008 Sindre Pedersen Bj??rdal - 0.2.7.1-10 - Fix x86_64 patch glob2-0.9.3-1.fc10 ------------------ * Sun May 4 18:00:00 2008 Rafa?? Psota - 0.9.3-1 - update to 0.9.3 lshw-B.02.12.01-5.fc9 --------------------- * Tue Apr 15 18:00:00 2008 Terje Rosten - B.02.12.01-5 - rebuild * Tue Apr 15 18:00:00 2008 Terje Rosten - B.02.12.01-4 - add patch to fix bz #442501 rsh-0.17-50.fc10 ---------------- * Fri May 9 18:00:00 2008 Adam Tkac 0.17-50 - fixed typos in arg_max and audit patches (#445606) - use pam_rhosts, not pam_rhosts_auth (#445606) hippo-canvas-0.2.31-1.fc10 -------------------------- R-2.7.0-1.fc10 -------------- * Mon Apr 28 18:00:00 2008 Tom "spot" Callaway 2.7.0-1 - update to 2.70 - rcompgen is no longer a standalone package - redirect javareconf to /dev/null (bz 442366) NetworkManager-vpnc-0.7.0-0.7.7.svn3627.fc10 -------------------------------------------- gtkhtml3-3.23.2-3.fc10 ---------------------- * Mon May 12 18:00:00 2008 Matthew Barnes - 3.23.2-3.fc10 - Add iso-codes-devel requirement to devel subpackage. * Mon May 12 18:00:00 2008 Matthew Barnes - 3.23.2-2.fc10 - Add enchant-devel requirement to devel subpackage. * Mon May 12 18:00:00 2008 Matthew Barnes - 3.23.2-1.fc10 - Update to 2.23.2 * Tue Apr 22 18:00:00 2008 Matthew Barnes - 3.23.1-2.fc10 - Forgot the enchant-devel and iso-codes-devel requirements. * Mon Apr 21 18:00:00 2008 Matthew Barnes - 3.23.1-1.fc10 - Update to 3.23.1 - Drop libbonobo requirement. bluez-utils-3.31-1.fc10 ----------------------- * Tue May 6 18:00:00 2008 - Bastien Nocera - 3.31-1 - Update to 3.31 python-urlgrabber-3.0.0-7.fc10 ------------------------------ * Fri May 2 18:00:00 2008 James Antill 3.0.0-7 - Fix reget's against servers that don't allow Range requests, also tweaks - reget == check_timestamp, if anyone/thing uses that. - Resolves: bug#435156 - Fix minor typo in progress for single instance. xfce4-diskperf-plugin-2.2.0-1.fc10 ---------------------------------- * Sun Apr 27 18:00:00 2008 Christoph Wickert - 2.2.0-1 - Update to 2.2.0 qtpfsgui-1.9.2-1.fc10 --------------------- * Fri May 9 18:00:00 2008 Douglas E. Warner 1.9.2-1 - update to 1.9.2 - cleanup spec file hunspell-fr-2.3.1-1.fc10 ------------------------ * Tue Apr 22 18:00:00 2008 Caolan McNamara - 2.3.1-1 - latest version libdockapp-0.6.2-1.fc10 ----------------------- * Mon May 5 18:00:00 2008 Patrice Dumas 0.6.2-1 - update to 0.6.2 yaz-3.0.26-1.fc10 ----------------- * Sat May 10 18:00:00 2008 Konstantin Ryabitsev - 3.0.26-1 - Upstream 3.0.26 radvd-1.1-3.fc10 ---------------- * Fri Apr 11 18:00:00 2008 Martin Nagy - 1.1-3 - remove stale pid file on start gmime-2.2.19-1.fc10 ------------------- * Sun May 4 18:00:00 2008 Matthias Clasen - 2.2.19-1 - Update to 2.2.19 - Fix source url kdetoys-4.0.72-1.fc10 --------------------- * Tue May 13 18:00:00 2008 Kevin Kofler 4.0.72-1 - update to 4.0.72 - add BR qimageblitz-devel - update file list and scriptlets for new kworldclock files xsp-1.9.1-2.fc10 ---------------- * Mon Apr 21 18:00:00 2008 Paul F. Johnson 1.9.1-1 - bump * Thu Feb 21 17:00:00 2008 Paul F. Johnson 1.9-2 - fix for problem with the test makefile * Thu Feb 21 17:00:00 2008 Paul F. Johnson 1.9-1 - bump * Thu Dec 20 17:00:00 2007 Paul F. Johnson 1.2.6-1.2 - remove arch ppc64 - add br mono-data-sqlite * Thu Nov 22 17:00:00 2007 Paul F. Johnson 1.2.6-1 - bump - spec file fixes - added new tests subpackage * Sun Nov 11 17:00:00 2007 Paul F. Johnson 1.2.5-1 - bump * Sun Apr 22 18:00:00 2007 Paul F. Johnson 1.2.4-1 - bump * Sun Mar 25 18:00:00 2007 Paul F. Johnson 1.2.3-2 - fix for un-owned directories * Thu Feb 15 17:00:00 2007 Paul F. Johnson 1.2.3-1 - bump shared-mime-info-0.30-1.fc10 ---------------------------- * Mon May 12 18:00:00 2008 - Bastien Nocera - 0.30-1 - Update to 0.30 ocaml-camlidl-1.05-5.fc10 ------------------------- * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 1.05-5 - Rebuild for OCaml 3.10.2. gnome-games-2.23.1-1.fc10 ------------------------- * Fri Apr 25 18:00:00 2008 Matthias Clasen - 1:2.23.1-1 - Update to 2.23.1 w3m-0.5.2-10.fc10 ----------------- gfs-artemisia-fonts-20070415-6.fc10 ----------------------------------- * Wed Apr 30 18:00:00 2008 Nicolas Mailhot - 20070415-6 ??? Yet another prep fix?? winpdb-1.3.8-1.fc10 ------------------- * Wed Apr 23 18:00:00 2008 Tom "spot" Callaway - 1.3.8-1 - update to 1.3.8 star-1.5a84-5.fc10 ------------------ * Mon May 12 18:00:00 2008 Peter Vrabec 1.5a84-5 - add super-H(sh3,4) architecture support (#442883) gtk-vnc-0.3.6-1.fc10 -------------------- * Wed May 7 18:00:00 2008 Daniel P. Berrange - 0.3.6-1.fc10 - Updated to 0.3.6 release * Fri Apr 25 18:00:00 2008 Matthias Clasen - 0.3.5-1.fc9 - Update to 0.3.5 gnome-audio-2.22.2-1.fc10 ------------------------- upx-3.03-1.fc10 --------------- * Thu May 8 18:00:00 2008 Jon Ciesla - 3.03-1 - 3.03. telepathy-gabble-0.7.5-1.fc10 ----------------------------- * Mon May 5 18:00:00 2008 Brian Pepple - 0.7.5-1 - Update to 0.7.5. * Fri May 2 18:00:00 2008 Brian Pepple - 0.7.4-1 - Update to 0.7.4. - Package new documentation. bluez-libs-3.31-1.fc10 ---------------------- * Tue May 6 18:00:00 2008 - Bastien Nocera - 3.31-1 - Update to 3.31 * Fri Apr 18 18:00:00 2008 Peter Jones - Make bluez-libs-devel own /usr/include/bluetooth/ kipi-plugins-0.1.5-2.fc10 ------------------------- * Thu May 8 18:00:00 2008 Rex Dieter 0.1.5-2 - respin * Fri Mar 14 18:00:00 2008 Rex Dieter 0.1.5-1 - kipi-plugins-0.1.5 hunspell-da-1.7.20-1.fc10 ------------------------- * Thu Apr 24 18:00:00 2008 Caolan McNamara - 1.7.20-1 - latest version uniconvertor-1.1.2-2.fc10 ------------------------- * Sun May 4 18:00:00 2008 Andy Shevchenko 1.1.2-2 - update to 1.1.2 - apply two useful patches from Debian digikam-doc-0.9.4-2.fc10 ------------------------ * Sun May 11 18:00:00 2008 Marcin Garski 0.9.4-2 - Update to 0.9.4 fuse-smb-0.8.7-3.fc10 --------------------- * Sat May 10 18:00:00 2008 Marcin Zajaczkowski - 0.8.7-3 - fixed conditional statement for better handle Fedora 10 version number * Sat May 10 18:00:00 2008 Marcin Zajaczkowski - 0.8.7-2 - added explicit dependency on fuse package (thanks to Mikel Ward - #445316) digikam-0.9.4-0.1.beta4.fc10 ---------------------------- * Thu May 8 18:00:00 2008 Rex Dieter - 0.9.4-0.1.beta4 - digikam-0.9.4-beta4 * Fri Mar 14 18:00:00 2008 Rex Dieter - 0.9.3-3 - respin (for libkdcraw) tkimg-1.3-0.10.20080505svn.fc10 ------------------------------- * Mon May 5 18:00:00 2008 Sergio Pascual - 1.3-0.10.20080505svn - New upstream source - Including fooConfig.sh files in -devel - Making symlinks of shared libraries in libdir - Removing file in ld.so.conf.d - Fixing bug #444872 PolicyKit-gnome-0.8-5.fc10 -------------------------- usermode-1.97-1 --------------- * Thu May 1 18:00:00 2008 Miloslav Trma?? - 1.97-1 - Fix display of '_' in prompts Resolves: #444545 kdegraphics-4.0.72-2.fc10 ------------------------- * Sat May 10 18:00:00 2008 Kevin Kofler 4.0.72-2 - add BR qca2-devel (for encrypted ODF documents in Okular) * Sat May 10 18:00:00 2008 Kevin Kofler 4.0.72-1 - update to 4.0.72 - drop backported system-libspectre patch ImageMagick-6.4.0.10-1.fc10 --------------------------- * Sat Apr 26 18:00:00 2008 Hans de Goede 6.4.0.10-1 - New upstream release 6.4.0.10 - This fixes conversion of 24 bpp windows icons (bz 440136) - Don't reuse GError structs, that upsets glib2 (bz 325211) - Use the system ltdl, not the included copy (bz 237475) - Fix various multilib conflicts (bz 341561) - Use xdg-open instead of htmlview (bz 388451) - Some small specfile cleanups (utf-8 stuff & others) fixing rpmlint warnings lighttpd-1.4.19-4.fc10 ---------------------- * Thu Apr 24 18:00:00 2008 Matthias Saou 1.4.19-4 - Merge in second changest from upstream fix for upstream bug #285. * Thu Mar 27 18:00:00 2008 Matthias Saou 1.4.19-3 - Include sslshutdown patch, upstream fix to upstream bug #285 (#439066). gstreamer-plugins-good-0.10.8-1.fc10 ------------------------------------ * Thu Apr 24 18:00:00 2008 - Bastien Nocera - 0.10.8-1 - Update to 0.10.8 * Thu Apr 10 18:00:00 2008 - Bastien Nocera - 0.10.7-2 - Add patch to unbreak the QuickTime demuxer plugin SDL_sound-1.0.3-1.fc10 ---------------------- * Mon Apr 21 18:00:00 2008 Hans de Goede 1.0.3-1 - New upstream release 1.0.3 php-pecl-radius-1.2.5-5.fc10 ---------------------------- * Sat Apr 19 18:00:00 2008 Christopher Stone 1.2.5-5 - Fix Requires for post/postun sections (bz #442699) kdeutils-4.0.72-1.fc10 ---------------------- * Wed May 7 18:00:00 2008 Kevin Kofler 4.0.72-1 - update to 4.0.72 - Obsoletes/Provides: okteta, update file list and description for okteta - remove .so symlinks which should not be in a non-devel package sugar-0.79.4-2.fc10 ------------------- kdeedu-4.0.72-2.fc10 -------------------- * Thu May 8 18:00:00 2008 Rex Dieter 4.0.72-2 - -kstars subpkg (#432317) * Thu May 8 18:00:00 2008 Kevin Kofler 4.0.72-1 - update to 4.0.72 - use pkgconfig for cfitsio patch now that cfitsio.pc has been fixed - add BR kdebase-workspace-devel for plasmoids - add BR libxml2-devel, libxslt-devel for Parley HTML export - BR new minimum version of openbabel-devel * Wed Apr 23 18:00:00 2008 Kevin Kofler 4.0.3-4 - rebuild for new ocaml (3.10.2) enchant-1.3.0-4.fc10 -------------------- php-pear-PHP-CompatInfo-1.7.0-1.fc10 ------------------------------------ * Fri Apr 18 18:00:00 2008 Remi Collet 1.7.0-1 - update to 1.7.0 - new Requires File_Find and XML_Beautifier boinc-client-5.10.45-12.20080315svn.fc10 ---------------------------------------- * Mon May 12 18:00:00 2008 Milos Jakubicek - 5.10.45-12.20080315svn - Do not ship ca-bundle.crt as it is already included in curl. - Fixed the almost empty debuginfo package (do not strip anything). - Patches documented according to the guidelines (PatchUpstreamStatus) * Sun May 4 18:00:00 2008 Milos Jakubicek - 5.10.45-11.20080315svn - Fixed find command because starting with findutils-4.4.0-1.fc10, find returns a non-zero value when "-delete" fails. (for more details on this see bug #20802 on savannah.gnu.org) * Sat May 3 18:00:00 2008 Milos Jakubicek - 5.10.45-10.20080315svn - Fixed handling stale lockfiles (#444936). - Initscript fixed to be compliant with current SysVInit guidelines (added condrestart, try-restart, force-reload actions). vdr-tvonscreen-1.0.141-4.fc10 ----------------------------- * Sun May 4 18:00:00 2008 - Ville-Pekka Vainio 1.0.141-4 - Add a combined patch from e-tobi, fixes segfaults - Add I18n patch from Mandriva, adds fi and de translations, thanks to Anssi Hannula redhat-rpm-config-9.0.3-1.fc10 ------------------------------ * Tue May 6 18:00:00 2008 Jon Masters - 9.0.3-1 - Ensure Java Jar files have readable files within. - Remove overwritten config.guess|sub files (testing). - Fix Fortran flags for building using _fmoddir. - Pull in objdump fix to upstream find-requires. kdesvn-0.14.3-1.fc10 -------------------- * Tue May 6 18:00:00 2008 - Orion Poplawski - 0.14.3-1 - Update to 0.14.3 kdeadmin-4.0.72-1.fc10 ---------------------- * Wed May 7 18:00:00 2008 Kevin Kofler 4.0.72-1 - update to 4.0.72 - add files and description for ksystemlog - kcron is now a KCM (update file list) - remove secpolicy from file list and description (dropped upstream) kdebase-4.0.72-2.fc10 --------------------- * Sun May 11 18:00:00 2008 Kevin Kofler 4.0.72-2 - quote semicolon in fix for #442834 - only do the echo when konquerorsu.desktop is actually shipped (#445989) * Tue May 6 18:00:00 2008 Kevin Kofler 4.0.72-1 - update to 4.0.72 (4.1 alpha 1) - drop backported kde#160422 and nspluginviewer patches - add minimum versions to soprano-devel and strigi-devel BRs vdr-1.6.0-3.fc9 --------------- * Sat May 10 18:00:00 2008 Ville Skytt?? - 1.6.0-3 - Update liemikuutio patch to 1.21. - Change timercmd patch to the one shipped with epgsearch 0.9.24. - Include vdr-i18n-to-gettext in -devel. - Own (%ghost) videodir/.update. * Sun Apr 13 18:00:00 2008 Ville Skytt?? - 1.6.0-2 - Apply upstream 1.6.0-1 maintenance patch. - Update timer info patch to 0.5 (fixes the "??" sign). banshee-0.99.1-1.1.fc10 ----------------------- * Mon May 5 18:00:00 2008 Nigel Jones - 0.99.1-1.1 - Fix brainfart... Comment out the cp for Source1 which I moved out of the way * Mon May 5 18:00:00 2008 Nigel Jones - 0.99.1-1 - New Upstream Release (0.99.1) - Beta 1 (Closes: Bug# 445449) - boo doesn't work quite yet for us, this will most likely be enabled in a -2 build (README.Fedora hence removed from sources) - Spec file improvements per guidelines - Put .pc files in their proper place postgresql-8.3.1-3.fc10 ----------------------- * Mon Apr 28 18:00:00 2008 Tom Lane 8.3.1-3 - Fix build breakage on PPC due to incorrect configure test Related: #444317 * Sat Apr 26 18:00:00 2008 Tom Lane 8.3.1-2 - Clean up cross-subpackage Requires: to ensure that updating any one subpackage brings in the matching versions of others. Resolves: #444271 evolution-data-server-2.23.2-1.fc10 ----------------------------------- * Mon May 12 18:00:00 2008 Matthew Barnes - 2.23.2-1.fc10 - Update to 2.23.2 - Add files for new libebackend library. - Remove patch for RH bug #202309 (fixed upstream). PackageKit-0.2.1-2.20080508.fc10 -------------------------------- * Thu May 8 18:00:00 2008 Richard Hughes - 0.2.1-2.20080508 - Pull in a new snapshot from the unstable branch. * Tue May 6 18:00:00 2008 Richard Hughes - 0.2.1-1.20080506 - Pull in a new snapshot from the unstable branch. * Tue May 6 18:00:00 2008 Richard Hughes - 0.2.0-1 - Update to the latest _UNSTABLE_ upstream source hunspell-bg-4.1-2.fc10 ---------------------- * Mon Apr 21 18:00:00 2008 Caolan McNamara - 4.1-2 - rhbz#443297 recode .aff and .dic into UTF-8 m4-1.4.11-1.fc10 ---------------- * Wed Apr 23 18:00:00 2008 Vitezslav Crhonek - 1.4.11-1 - Update to m4-1.4.11 (removed vasnprintf patch, it's included in upstream source) Resolves: #443589 gfs-baskerville-fonts-20070327-7.fc10 ------------------------------------- * Wed Apr 30 18:00:00 2008 Nicolas Mailhot - 20070327-7 ??? Yet another prep fix?? textflow-0.2.3.1-1.fc10 ----------------------- * Mon May 5 18:00:00 2008 Mads Villadsen - 0.2.3.1-1 - Update to latest upstream release smartmontools-5.38-4.1.fc10 --------------------------- * Mon May 5 18:00:00 2008 Tomas Smetana - 1:5.38-4.1 - add libselinux-devel to BR * Mon May 5 18:00:00 2008 Tomas Smetana - 1:5.38-4 - fix #232218 character devices /dev/twa* for 3ware 9000 series RAID controllers are not created * Thu Mar 27 18:00:00 2008 Tomas Smetana - 1:5.38-3 - don't attempt to query DELL PERC controllers -- they'd go offline sylpheed-2.5.0-0.1.beta3 ------------------------ * Fri Apr 25 18:00:00 2008 Michael Schwendt - 2.5.0-0.1.beta3 - Update to 2.5.0beta3 (two minor features added). * Mon Apr 14 18:00:00 2008 Michael Schwendt - 2.5.0-0.1.beta2 - Update to 2.5.0beta2 (several added features, few bug-fixes). scidavis-0.1.3-2.fc10 --------------------- dia-0.96.1-6.fc10 ----------------- a2ps-4.14-2.fc10 ---------------- * Sun Apr 27 18:00:00 2008 Patrice Dumas 4.14-2 - update to 4.14 - don't obsolete the provided version of a2ps-i18n - use html2ps for the html delegation - BuildRequires gperf man-pages-ja-20080415-2.fc10 ---------------------------- * Wed Apr 30 18:00:00 2008 Akira TAGOH - 20080415-2 - correct the description of --dscp option in iptables(8). - correct the description of the syntax for octadecimal and hexadecimal in printf(1). * Mon Apr 28 18:00:00 2008 Akira TAGOH - 20080415-1 - updates to 20080415. - correct the description of the error section in connect(2). wxsvg-1.0-0.8.b10.fc10 ---------------------- * Wed Mar 5 17:00:00 2008 Ville Skytt?? - 1.0-0.8.b10 - Update to 1.0b10. - Build with dependency tracking disabled. labyrinth-0.4.0-1.fc10 ---------------------- * Wed Apr 2 18:00:00 2008 Peter Gordon - 0.4.0-1 - Update to new upstream release (0.4.0); Yay! - Drop the interpreter patch (fixed upstream): - fix-interpreters.patch - Add Spanish translation (to the %description and Summary, also): + es.po, add-es-translation.patch gstreamer-plugins-pulse-0.9.7-1.fc10 ------------------------------------ * Sat Apr 19 18:00:00 2008 Lubomir Kundrak - 0.9.7-1 - Update to latest upstream - Fix license tag perl-DBIx-SearchBuilder-1.53-1.fc10 ----------------------------------- * Fri Apr 25 18:00:00 2008 Ralf Cors??pius - 1.53-1 - Upstream update. kdegames-4.0.72-1.fc10 ---------------------- * Sat May 10 18:00:00 2008 Kevin Kofler 4.0.72-1 - update to 4.0.72 - update description to list new games (kblocks, kdiamond, kollision, kubrick) - handle new ksquares GGZ module.dsc system-config-language-1.2.15-3.fc10 ------------------------------------ asymptote-1.42-3.fc10 --------------------- * Fri Apr 25 18:00:00 2008 Tom "spot" Callaway - 1.42-3 - explicitly call "make asymptote.pdf" in doc/ cheese-2.23.1-1.fc10 -------------------- * Fri Apr 25 18:00:00 2008 Matthias Clasen 2.23.1-1 - Update to 2.23.1 * Tue Apr 22 18:00:00 2008 Matthias Clasen 2.22.1-2 - Fix an invalid free hedgewars-0.9.3-1.fc10 ---------------------- * Thu May 1 18:00:00 2008 Hans de Goede 0.9.3-1 - New upstream release 0.9.3 ocaml-expat-0.9.1-11.fc10 ------------------------- * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 0.9.1-11 - Rebuild for OCaml 3.10.2 licq-1.3.5-2.fc10 ----------------- * Mon May 12 18:00:00 2008 Jiri Moskovcak 1.3.5-2 - fixed possible DoS vulnerability CVE-2008-1996 ocaml-lablgtk-2.10.1-2.fc10 --------------------------- * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 2.10.1-2 - Rebuild for OCaml 3.10.2 * Mon Apr 21 18:00:00 2008 Richard W.M. Jones - 2.10.1-0 - New upstream release 2.10.1. libsvm-2.86-13.fc10 ------------------- * Tue Apr 29 18:00:00 2008 Ding-Yi Chen - 2.86-13 - Fix svm-toy-qt clear button does not clear. (from Hsiang-Fu Yu in National Taiwan University) k3b-1.0.4-9.fc10 ---------------- * Wed May 7 18:00:00 2008 Roman Rakus - 0:1.0.4-9 - Fix doc dir (#238070), patch by Alain PORTAL (aportal at univ-montp2.fr) * Tue Apr 22 18:00:00 2008 Roman Rakus - 0:1.0.4-8 - Use manual buffer size by default * Tue Feb 19 17:00:00 2008 Rex Dieter - 0:1.0.4-7 - f9+: Obsoletes: k3b-devel (#429613) ruby-RMagick-2.3.0-2.fc10 ------------------------- * Mon Apr 28 18:00:00 2008 Mamoru Tasaka - 2.3.0-2 - Rebuild against ImageMagick 6.4.0+ (F-10) - BR: libwmf (actually %_bindir/wmf2eps) explicitly ( related to bug 432651 ) ocaml-cryptokit-1.3-4.fc10 -------------------------- * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 1.3-4 - Rebuild for OCaml 3.10.2 jd-2.0.0-0.4.svn2049_trunk.fc10 ------------------------------- * Tue May 13 18:00:00 2008 Mamoru Tasaka - 2.0.0-0.4.svn2049_trunk - 2.0.0 trunk 2049 * Fri Apr 18 18:00:00 2008 Mamoru Tasaka - 2.0.0-0.4.beta080418 - 2.0.0 beta 080418 * Tue Apr 15 18:00:00 2008 Mamoru Tasaka - 1.9.9-1 - 1.9.9 * Wed Apr 9 18:00:00 2008 Mamoru Tasaka - 1.9.9-0.3.rc080408 - 1.9.9 rc 080408 ocaml-sqlite-1.0.3-2.fc10 ------------------------- * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 1.0.3-2 - Rebuild for OCaml 3.10.2 * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 1.0.3-1 - Jump in upstream version to 1.0.3. - New upstream URL. gfs-didot-classic-fonts-20070415-5.fc10 --------------------------------------- * Wed Apr 30 18:00:00 2008 Nicolas Mailhot - 20070415-5 ??? Yet another prep fix?? ocaml-camomile-0.7.1-7.fc10 --------------------------- * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 0.7.1-7 - Rebuild for OCaml 3.10.2 pam-1.0.1-2.fc10 ---------------- texlive-texmf-2007-21.fc10 -------------------------- gnome-settings-daemon-2.23.1.1-4.fc10 ------------------------------------- * Mon May 5 18:00:00 2008 Matthias Clasen - 2.23.1-1-4 - Pick up the keyboard layout from the login screen * Mon May 5 18:00:00 2008 Matthias Clasen - 2.23.1-1-3 - Fix background drawing without nautilus * Tue Apr 29 18:00:00 2008 - Bastien Nocera - 2.23.1.1-2 - Add patch from upstream to avoid the Stop button triggering an Eject (#346201) referencer-1.1.2-1.fc10 ----------------------- * Sat Apr 26 18:00:00 2008 Deji Akingunola - 1.1.2-1 - New release taglib-sharp-2.0.3.0-4.fc10 --------------------------- istanbul-0.2.2-7.fc10 --------------------- * Fri May 2 18:00:00 2008 Jef Spaleta - 0.2.2-7 - patch from upstream svn for gst audio stream closure. libewf-20080501-1.fc10 ---------------------- * Thu May 1 18:00:00 2008 kwizart < kwizart at gmail.com > - 20080501-1 - Update to 20080501 (bugfix) - Patch for pkg-config was merged with this release - Improve ewftools description. * Tue Apr 29 18:00:00 2008 kwizart < kwizart at gmail.com > - 20080322-3 - Add disktype Requires for ewftools (required for mount.ewf support). - Patch libewf.pc to export only the needed libs * Tue Apr 22 18:00:00 2008 kwizart < kwizart at gmail.com > - 20080322-2 - Add support for mount.ewf with fuse-python desktop-data-model-1.2.4-1.fc10 ------------------------------- i8kutils-1.25-15 ---------------- * Thu Apr 24 18:00:00 2008 Matthias Saou 1.25-15 - Don't enable service by default (#441287). busybox-1.10.1-1.fc10 --------------------- * Fri May 9 18:00:00 2008 Ivana Varekova - 1:1.10.1-1 - update to 1.10.1 php-pear-Console-Table-1.1.1-1.fc9 ---------------------------------- * Thu Apr 10 18:00:00 2008 Remi Collet 1.1.1-1 - update to 1.1.1 libkipi-0.1.6-1.fc10 -------------------- * Thu May 8 18:00:00 2008 Rex Dieter 0.1.6-1 - libkipi-0.1.6 sepostgresql-8.3.1-2.197.fc10 ----------------------------- * Wed Apr 30 18:00:00 2008 - 8.3.1-2.197 - Inconsistent version number format at Changelogs * Wed Apr 30 18:00:00 2008 - 8.3.1-2.196 - BUGFIX: ROW-level control did not work correctly on TRUNCATE dictd-1.10.11-2 --------------- * Wed May 7 18:00:00 2008 Karsten Hopp 1.10.11-2 - update to 1.10.11 * Tue Apr 1 18:00:00 2008 Karsten Hopp 1.10.10-1 - fix typo (#281981) - update ocaml-cairo-1.2.0.cvs20080301-3.fc10 ------------------------------------ * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 1.2.0.cvs20080301-3 - Rebuild for OCaml 3.10.2 php-pear-Log-1.10.1-1.fc10 -------------------------- * Thu May 8 18:00:00 2008 Remi Collet 1.10.1-1 - update to 1.10.1 tzclock-2.6.1-3.fc9 ------------------- * Sat Apr 12 18:00:00 2008 Mamoru Tasaka - 2.6.1-3 - "New" 2.6.1 (modified tarball with the same version) * Fri Apr 11 18:00:00 2008 Mamoru Tasaka - 2.6.1-2 - 2.6.1 man-pages-fr-2.79.0-5.fc10 -------------------------- gparted-0.3.7-1.fc10 -------------------- * Wed Apr 30 18:00:00 2008 Deji Akingunola - 0.3.7-1 - New upstream version * Fri Mar 28 18:00:00 2008 Deji Akingunola - 0.3.6-1 - New upstream version python-metar-1.3.0-3.fc10 ------------------------- * Thu Apr 24 18:00:00 2008 Matthias Saou 1.3.0-3 - Include everything under sitelib, to include egg files if present (F-9+). ocaml-mysql-1.0.4-3.fc10 ------------------------ * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 1.0.4-3 - Rebuild for OCaml 3.10.2 shorewall-4.0.10-2.fc10 ----------------------- * Sun May 4 18:00:00 2008 Jonathan G. Underwood - 4.0.10-2 - Add upstream patches patch-perl-4.0.10-1.diff and patch-common-4.0.10-1.diff libHX-1.15-1.fc10 ----------------- * Mon May 5 18:00:00 2008 Till Maas - 1.15-1 - Update to latest version - Update description farsight-0.1.28-1.fc10 ---------------------- * Fri May 9 18:00:00 2008 Brian Pepple - 0.1.28-1 - Update to 0.1.28. - Drop darth vader patch. Fixed upstream. * Fri May 2 18:00:00 2008 Brian Pepple - 0.1.27-2 - Add patch to fix speex voip to not sound like Dart Vader. * Tue Apr 22 18:00:00 2008 Brian Pepple - 0.1.27-1 - Update to 0.1.27. audacity-1.3.2-21.fc10 ---------------------- geany-0.14-1.fc10 ----------------- * Sun May 11 18:00:00 2008 Jonathan G. Underwood - 0.14-1 - Update to 0.14 - New -devel sub-package for header files - Corectly remove the .la libtool files - Remove hack relating to finding the system installed html files - No longer correct the desktop file cups-1.3.7-2.fc10 ----------------- * Fri May 9 18:00:00 2008 Tim Waugh 1:1.3.7-2 - Applied patch to fix CVE-2008-1722 (integer overflow in image filter, bug #441692, STR #2790). * Thu Apr 3 18:00:00 2008 Tim Waugh - Main package requires exactly-matching libs package. tokyocabinet-1.2.5-1.fc10 ------------------------- * Mon Apr 28 18:00:00 2008 Deji Akingunola - 1.2.5-1 - Update to 1.2.5 util-linux-ng-2.13.1-9.fc10 --------------------------- * Tue Apr 22 18:00:00 2008 Karel Zak 2.13.1-9 - fix audit log injection attack via login * Thu Apr 17 18:00:00 2008 Karel Zak 2.13.1-8 - fix location of the command raw(8) * Tue Apr 15 18:00:00 2008 Karel Zak 2.13.1-7 - fix 244383 - libblkid uses TYPE="swsuspend" for S1SUSPEND/S2SUSPEND system-config-netboot-0.1.45.2-1.fc10 ------------------------------------- * Tue May 6 18:00:00 2008 Radek Brich - 0.1.45.2-1 - remove '/home' from snapshot files (add it to files.custom if needed) - do not create '.oldroot' in diskless root, it's not needed anymore * Tue Apr 8 18:00:00 2008 Radek Brich - 0.1.45.1-1 - Repackage with updated translations - Add missing languages to configure.in kdebase-workspace-4.0.72-3.fc10 ------------------------------- * Thu May 8 18:00:00 2008 Rex Dieter 4.0.72-3 - ksysguardd subpkg (#426543) - %config(noreplace) systemsettingsrc * Thu May 8 18:00:00 2008 Rex Dieter 4.0.72-2 - gtkrc patch (rh#443309, kde#146779) * Wed May 7 18:00:00 2008 Kevin Kofler 4.0.72-1 - update to 4.0.72 - update file list (Lorenzo Villani) - port plasma-konsole, ck-shutdown, rootprivs, plasma-default-wallpaper patches - remove NoDisplay=true in systemsettings onlyshowkde patch (still add OnlyShowIn=KDE), rename to show-systemsettings - drop upstreamed suspend patch - drop backported kde#155362 and menu-switch patches - drop rh#443610 patch, "Zoom Out" should be working in 4.1 - disable kde#158301 patch for now (fails to apply, looks hard to port) vnc-4.1.2-30.fc10 ----------------- desktop-file-utils-0.15-3.fc10 ------------------------------ * Fri May 2 18:00:00 2008 Richard Hughes - 0.15-3 - Add desktop-mime-type.prov so that we can automatically generate mimetype provides for packages at build time. This lets us do some cool things with PackageKit in the future. * Wed Mar 19 18:00:00 2008 Ray Strode - 0.15-2 - Drop old unneeded obsoletes on desktop-file-validator (bug 225681) orca-2.23.1-1.fc10 ------------------ * Fri Apr 25 18:00:00 2008 Matthias Clasen - 2.23.1-1 - Update to 2.23.1 gfs-gazis-fonts-20080318-2.fc10 ------------------------------- * Wed Apr 30 18:00:00 2008 Nicolas Mailhot - 20080318-2 ??? Yet another prep fix?? keepalived-1.1.15-5.fc10 ------------------------ * Thu Apr 24 18:00:00 2008 Matthias Saou 1.1.15-5 - Add glob to the kerneldir location, since it contains the arch for F9+. sysstat-8.0.4-4.fc10 -------------------- * Wed Apr 23 18:00:00 2008 Ivana Varekova - 8.0.4-4 - Resolves: #442801 mpstat shows one extra cpu thanks Chris Wright gfs2-utils-2.03.00-4.fc10 ------------------------- * Wed Apr 30 18:00:00 2008 Steven Whitehouse 2.03.00-4 - Stop service in preun script as per final review comments - Can now close the review bz #225792 ocaml-curl-0.2.1-8.fc10 ----------------------- * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 0.2.1-8 - Rebuild for OCaml 3.10.2 pyjigdo-0.3.0-1.fc10 -------------------- * Thu Apr 24 18:00:00 2008 Jonathan Steffan 0.3.0-1 - Update Requires for fuseiso - Update to version 0.3.0 - This release is a complete rewrite, too much to list here bzrtools-1.4.0-1.fc10 --------------------- * Mon May 5 18:00:00 2008 Toshio Kuratomi 1.4.0-1 - Update to 1.4.0 coreutils-6.11-2.fc10 --------------------- * Wed Apr 23 18:00:00 2008 Ondrej Vasik - 6.11-2 - Do not show misleading scontext in id command when user is specified (#443485) - Avoid possible test failures on non-english locales * Mon Apr 21 18:00:00 2008 Ondrej Vasik - 6.11-1 - New upstream release 6.11 - removed accepted patches + few minor patch changes * Fri Apr 18 18:00:00 2008 Ondrej Vasik - 6.10-21 - fix wrong checksum line handling in sha1sum -c command(#439531) * Tue Apr 15 18:00:00 2008 Ondrej Vasik - 6.10-20 - fix possible segfault in sha1sum/md5sum command * Mon Apr 14 18:00:00 2008 Ondrej Vasik - 6.10-19 - fix possible build-failure typo in i18n patch(#442205) kbibtex-0.2.1-19.fc9 -------------------- * Sun May 4 18:00:00 2008 Christian Nolte - 0.2.1-19 - Updated to latest upstream version 0.2.1 gstreamer-plugins-farsight-0.12.8-1.fc10 ---------------------------------------- * Fri May 9 18:00:00 2008 Brian Pepple - 0.12.8-1 - Update to 0.12.8. * Tue Apr 22 18:00:00 2008 Brian Pepple - 0.12.7-1 - Update to 0.12.7. gdevilspie-0.31-2.fc10 ---------------------- gnome-panel-2.23.1-1.fc10 ------------------------- * Fri Apr 25 18:00:00 2008 Matthias Clasen - 2.23.1-1 - Update to 2.23.1 gnome-volume-manager-2.22.5-1.fc10 ---------------------------------- * Sat Apr 26 18:00:00 2008 Matthias Clasen - 2.22.5-1 - Update to 2.22.5 * Fri Apr 25 18:00:00 2008 Matthias Clasen - 2.22.3-1 - Update to 2.22.3 linuxwacom-0.7.9.8-7.fc10 ------------------------- * Fri Apr 25 18:00:00 2008 Aristeu Rozanski 0.7.9.8-7 - updating udev rules gthumb-2.10.8-3.fc10 -------------------- xine-lib-1.1.12-3.fc10 ---------------------- * Sun Apr 27 18:00:00 2008 Kevin Kofler - 1.1.12-3 - rebuild for new ImageMagick (6.4.0.10) lyx-1.5.5-1.fc10 ---------------- * Mon May 12 18:00:00 2008 Rex Dieter 1.5.5-1 - lyx-1.5.5 curl-7.18.1-2.fc10 ------------------ * Wed May 7 18:00:00 2008 Jindrich Novy 7.18.1-2 - spec cleanup, thanks to Paul Howarth (#225671) - drop BR: libtool - convert CHANGES and README to UTF-8 - _GNU_SOURCE in CFLAGS is no more needed - remove bogus rpath cmake-2.6.0-1.fc10 ------------------ * Tue May 6 18:00:00 2008 Orion Poplawski - 2.6.0-1 - Update to 2.6.0 * Mon May 5 18:00:00 2008 Orion Poplawski - 2.6.0-0.rc10.1 - Update to 2.6.0-RC-10 * Thu Apr 24 18:00:00 2008 Orion Poplawski - 2.6.0-0.rc9.1 - Update to 2.6.0-RC-9 * Fri Apr 11 18:00:00 2008 Orion Poplawski - 2.6.0-0.rc8.1 - Update to 2.6.0-RC-8 * Thu Apr 3 18:00:00 2008 Orion Poplawski - 2.6.0-0.rc6.1 - Update to 2.6.0-RC-6 * Fri Mar 28 18:00:00 2008 Orion Poplawski - 2.6.0-0.rc5.1 - Update to 2.6.0-RC-5 - Add gui sub-package for Qt frontend * Fri Mar 7 17:00:00 2008 Orion Poplawski - 2.4.8-3 - Add macro for bootstrapping new release/architecture - Add %check section kdeartwork-4.0.72-1.fc10 ------------------------ * Wed May 7 18:00:00 2008 Kevin Kofler 4.0.72-1 - update to 4.0.72 * Fri Apr 18 18:00:00 2008 Rex Dieter 4.0.3-6 - revert icons noarch hack (wasn't working anyway, rel-eng veto) * Thu Apr 17 18:00:00 2008 Rex Dieter 4.0.3-5 - -icons: build noarch ocaml-csv-1.1.6-8.fc10 ---------------------- * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 1.1.6-8 - Rebuild for OCaml 3.10.2 glpi-0.70.2-3.fc10 ------------------ glpk-4.28-1.fc10 ---------------- * Tue May 6 18:00:00 2008 Quentin Spencer 4.28-1 - Update to release 4.28. - Add LIBS definition to configure step so it compiles correctly. ocaml-ocamlnet-2.2.9-6.fc10 --------------------------- * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 2.2.9-6 - Rebuild for OCaml 3.10.2 * Mon Apr 21 18:00:00 2008 Richard W.M. Jones - 2.2.9-5 - New upstream URL. ocaml-ssl-0.4.2-9.fc10 ---------------------- * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 0.4.2-9 - Rebuild for OCaml 3.10.2 atlas-3.6.0-15.fc10 ------------------- * Thu Feb 28 17:00:00 2008 Quentin Spencer 3.6.0-15 - Disable altivec package--it is causing illegal instructions during build. * Thu Feb 28 17:00:00 2008 Quentin Spencer 3.6.0-14 - Enable compilation on alpha (bug 426086). - Patch for compilation on ia64 (bug 432744). * Tue Feb 19 17:00:00 2008 Fedora Release Engineering - 3.6.0-13 - Autorebuild for GCC 4.3 openvrml-0.17.5-5.fc9 --------------------- * Fri Apr 25 18:00:00 2008 Braden McDaniel - 0.17.5-5 - Append -O0 after optflags on ppc64 to work around gcc segfault. * Tue Apr 22 18:00:00 2008 Braden McDaniel - 0.17.5-4 - Patch to fix missing std qualification that gcc 4.3 complains about. * Wed Mar 26 18:00:00 2008 Braden McDaniel - 0.17.5-3 - Fixed patch to use -p0. * Wed Mar 26 18:00:00 2008 Braden McDaniel - 0.17.5-2 - Patch for crash in openvrml-xembed (bug 437611). lftp-3.7.1-1.fc10 ----------------- * Wed Apr 23 18:00:00 2008 Martin Nagy - 3.7.1-1 - update to upstream version 3.7.1 openarena-0.7.6-1.fc10 ---------------------- * Wed Apr 23 18:00:00 2008 Micha?? Bentkowski - 0.7.6-1 - New release - Fix desktop file a bit ocaml-findlib-1.2.1-3.fc10 -------------------------- * Mon Apr 21 18:00:00 2008 Richard W.M. Jones - 1.2.1-3 - New upstream URLs. ocaml-postgresql-1.8.2-4.fc10 ----------------------------- * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 1.8.2-4 - Rebuild for OCaml 3.10.2 xfwm4-theme-nodoka-0.1-1.fc10 ----------------------------- sqlite-3.5.8-1.fc10 ------------------- * Wed Apr 23 18:00:00 2008 Panu Matilainen - 3.5.8-1 - update to 3.5.8 - provide full version in pkg-config (#443692) htdig-3.2.0-0.1.b6.fc10 ----------------------- bind-9.5.0-31.b3.fc10 --------------------- * Mon May 5 18:00:00 2008 Adam Tkac 32:9.5.0-31.b3 - readded bind-9.5-libcap.patch - added bind-9.5-recv-race.patch from F8 branch (#400461) * Wed Apr 23 18:00:00 2008 Adam Tkac 32:9.5.0-30.1.b3 - build Berkeley DB DLZ backend * Mon Apr 21 18:00:00 2008 Adam Tkac 32:9.5.0-30.b3 - 9.5.0b3 release - dropped patches (upstream) - bind-9.5-transfer-segv.patch - bind-9.5-mudflap.patch - bind-9.5.0-generate-xml.patch - bind-9.5-libcap.patch * Wed Apr 2 18:00:00 2008 Adam Tkac 32:9.5.0-29.3.b2 - fixed named.conf.sample file (#437569) * Fri Mar 14 18:00:00 2008 Adam Tkac 32:9.5.0-29.2.b2 - fixed URLs * Mon Feb 25 17:00:00 2008 Adam Tkac 32:9.5.0-29.1.b2 - BuildRequires cleanup xfce4-session-4.4.2-3.fc10 -------------------------- pango-1.21.0-1.fc10 ------------------- * Fri Apr 25 18:00:00 2008 Matthias Clasen - 1.21.0-1 - Update to 1.21.0 dbus-1.2.1-3.fc10 ----------------- * Mon May 12 18:00:00 2008 Ray Strode - 1.2.1-3 - drop last patch after discussion on dbus list * Mon May 12 18:00:00 2008 Ray Strode - 1.2.1-2 - ensure uuid is created at post time ginac-1.4.3-1.fc10 ------------------ * Tue Apr 29 18:00:00 2008 Quentin Spencer 1.4.3-1 - Update to 1.4.3. Remove old patch. gfs-didot-fonts-20070616-6.fc10 ------------------------------- * Wed Apr 30 18:00:00 2008 Nicolas Mailhot - 20070616-6 ??? Yet another prep fix?? sound-juicer-2.22.0-3.fc10 -------------------------- * Tue Apr 29 18:00:00 2008 - Bastien Nocera - 2.22.0-3 - Handle URIs from gvfs * Wed Mar 12 18:00:00 2008 - Bastien Nocera - 2.22.0-2 - Remove the ExcludeArch python-turboflot-0.1.1-1.fc10 ----------------------------- * Sun May 11 18:00:00 2008 Luke Macken - 0.1.1-1 - Call flot only when the document is ready - Properly instantiate the TurboFlot widget thunderbird-2.0.0.14-1.fc10 --------------------------- kst-1.6.0-2.fc10 ---------------- * Thu Apr 24 18:00:00 2008 Matthew Truch - 1.6.0-2 - Also remove PlanckIDEF datasoure. * Thu Apr 24 18:00:00 2008 Matthew Truch - 1.6.0-1 - New version of kst. - Re-add gsl-devel as qt is now compatable with GPLv3. empathy-0.23.1-2.fc10 --------------------- * Sun May 4 18:00:00 2008 Brian Pepple - 0.23.1-2 - Drop multiple copies of COPYING file. - Drop BR on gnome-vfs2-devel. - Require telepathy-stream-engine for VOIP support. - Add BR on iso-codes-devel, so spell-checking is enabled. * Wed Apr 23 18:00:00 2008 Peter Gordon - 0.23.1-1 - Update to new upstream release (0.23.1) - Drop libtelepathy dependencies; upstream switched fully to telepathy-glib. asunder-1.5-1.fc10 ------------------ * Sun May 4 18:00:00 2008 Marcin Zajaczkowski - 1.5-1 - updated to 1.5 - added (commented for now) wavpack dependency at-spi-1.22.1-2.fc10 -------------------- * Mon May 5 18:00:00 2008 Matthias Clasen - 1.22.1-2 - Bump rev atanks-2.9-1.fc10 ----------------- * Sat Apr 12 18:00:00 2008 Konstantin Ryabitsev - 2.9-1 - Upstream 2.9 ruby-revolution-0.5-1.svn210.fc10.3 ----------------------------------- * Tue May 13 18:00:00 2008 Mamoru Tasaka - F-10: rebuild against new e-d-s flex-2.5.35-2.fc10 ------------------ * Mon May 12 18:00:00 2008 Petr Machata - 2.5.35-2 - Resolves: #445950 kernel-2.6.25.2-5.fc10 ---------------------- * Wed May 7 18:00:00 2008 Kyle McMartin 2.6.25.2-3 - Linux 2.6.25.2 * Wed May 7 18:00:00 2008 Chuck Ebbert 2.6.25.2-5 - Add the patches queued for 2.6.25.3 * Mon May 5 18:00:00 2008 Roland McGrath 2.6.25.1-3 - Fix testing of %fedora macro. * Fri May 2 18:00:00 2008 Jarod Wilson 2.6.25.1-1 - Linux 2.6.25.1 - Drop patches merged in 2.6.25.1: * linux-2.6-netdev-tehuti-check-register-size.patch * linux-2.6-netdev-tehuti-move-ioctl-perm-check-closer-to-function-start.patch * linux-2.6-selinux-ssinitialized-bugon.patch * bits of wireless patches squid-3.0.STABLE5-2.fc10 ------------------------ * Fri May 9 18:00:00 2008 Martin Nagy - 7:3.0.STABLE5-2 - fix configure detection of netfilter kernel headers (#435499), patch by aoliva at redhat.com - add support for negotiate authentication (#445337) * Fri May 2 18:00:00 2008 Martin Nagy - 7:3.0.STABLE5-1 - upgrade to latest upstream * Tue Apr 8 18:00:00 2008 Martin Nagy - 7:3.0.STABLE4-1 - upgrade to latest upstream crash-4.0-6.3 ------------- * Fri Aug 29 18:00:00 2008 Dave Anderson - 4.0-6.3 - Added crash-devel subpackage - Updated crash.patch to match upstream version 4.0-6.3 xfwm4-4.4.2-3.fc10 ------------------ gfs-neohellenic-fonts-20070415-5.fc10 ------------------------------------- * Wed Apr 30 18:00:00 2008 Nicolas Mailhot - 20070415-5 ??? Yet another prep fix?? php-magickwand-1.0.7-1.fc10 --------------------------- * Sun Apr 27 18:00:00 2008 Robert Scheck 1.0.7-1 - Upgrade to 1.0.7 * Thu Feb 14 17:00:00 2008 Robert Scheck 1.0.6-2 - Require ImageMagick >= 6.3.7.10 to avoid breakage (#432794) gnome-do-0.4.2.0-1.fc10 ----------------------- * Tue Apr 22 18:00:00 2008 Sindre Pedersen Bj??rdal - 0.4.2.0-1 - New upstrean release * Tue Apr 1 18:00:00 2008 David Nielsen - 0.4.0.1-2 - #439793 - correct URL gallery2-2.2.4-4.fc10 --------------------- * Tue Apr 22 18:00:00 2008 John Berninger - 2.2.4-4 - don't create or own any dirs in /srv vegastrike-0.5.0-1.fc10 ----------------------- * Sat May 3 18:00:00 2008 Hans de Goede 0.5.0-1 - New upstream release 0.5.0 * Sun Apr 13 18:00:00 2008 Hans de Goede 0.4.3-9 - Use xdg-open instead of gedit to show the user the readme (bz 442063) python-fedora-0.2.99.10-1.fc10 ------------------------------ * Wed Apr 23 18:00:00 2008 Toshio Kuratomi - 0.2.99.10-1 - New upstream release. libvncserver-0.9.1-3.fc10 ------------------------- * Thu Apr 10 18:00:00 2008 Manuel Wolfshant 0.9.1-3 - do not use bundled copy of minilzo rkward-0.5.0b-2.fc10 -------------------- * Thu May 1 18:00:00 2008 Pingou 0.5.0b-2 - Update to release 0.5.0b * Tue Apr 15 18:00:00 2008 Pingou 0.5.0b-pre1-1 - Update to release 0.5.0b-pre1 mod_nss-1.0.7-4.fc10 -------------------- bigboard-0.5.33-2.fc10 ---------------------- elfutils-0.135-1.fc10 --------------------- * Mon May 12 18:00:00 2008 Roland McGrath - 0.135-1 - Update to 0.135 - libdwfl: bug fixes - eu-strip: changed handling of ET_REL files wrt symbol tables and relocs * Wed Apr 9 18:00:00 2008 Roland McGrath - 0.134-1 - Update to 0.134 - elflint: backend improvements for sparc, alpha (#204170) - libdwfl, libelf: bug fixes (#439344, #438867, #438263, #438190) - Remove Conflicts: libelf-devel from elfutils-libelf-devel. (#435742) ntfs-3g-1.2506-1.fc10 --------------------- mysql++-3.0.2-1.fc9 ------------------- * Tue Apr 15 18:00:00 2008 Remi Collet 3.0.2-1 - update to 3.0.2 telepathy-stream-engine-0.5.2-1.fc10 ------------------------------------ * Tue Apr 22 18:00:00 2008 Brian Pepple - 0.5.2-1 - Update to 0.5.2. audio-convert-mod-3.45.4-1.fc10 ------------------------------- * Sun May 11 18:00:00 2008 Stewart Adam 3.45.4-1 - Update to 3.45.4 (see CHANGELOG file for details on version changes) * Fri Apr 25 18:00:00 2008 Stewart Adam 3.45.3-1 - Update to 3.45.3 (see CHANGELOG file for details on version changes) - Fixes RH#442502 moin-1.6.3-1.fc10 ----------------- cln-1.2.2-1.fc10 ---------------- * Tue Apr 29 18:00:00 2008 Quentin Spencer 1.2.2-1 - Update to 1.2.2. xorg-x11-drv-ati-6.8.0-14.fc9 ----------------------------- * Mon May 12 18:00:00 2008 Dave Airlie 6.8.0-14 - add initial cloning support for RN50 (#439879) * Wed May 7 18:00:00 2008 Dave Airlie 6.8.0-13 - more upstream fixes for EXA accel + zaphod mode ocaml-curses-0.1-8.20020319.fc10 -------------------------------- * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 0.1-8 - Rebuild for OCaml 3.10.2 flam3-2.7.11-1.fc10 ------------------- * Wed Apr 9 18:00:00 2008 Ian Weller 2.7.11-1 - Upstream updated telepathy-glib-0.7.8-1.fc10 --------------------------- * Fri May 9 18:00:00 2008 Brian Pepple - 0.7.8-1 - Update to 0.7.8. * Tue Apr 22 18:00:00 2008 Brian Pepple - 0.7.6-1 - Update to 0.7.6. glom-1.6.15-1.fc9 ----------------- * Tue May 6 18:00:00 2008 Denis Leroy - 1.6.15-1 - Update to upstream 1.6.15, fixes connection issue nut-2.2.2-1.fc10 ---------------- * Mon May 12 18:00:00 2008 Tomas Smetana 2.2.2-1 - new upstream version ladspa-mcp-plugins-0.4.0-1.fc9 ------------------------------ * Sun Apr 13 18:00:00 2008 Hans de Goede 1:0.4.0-1 - New upstream release 0.4.0 rpmrebuild-2.2.2-1.fc10 ----------------------- * Sun May 11 18:00:00 2008 Anderson Silva 2.2.2-1 - New package from upstream. - Removed dependency on rpm-rebuild, it is not available under EPEL. quesoglc-0.7.1-1.fc10 --------------------- * Tue Apr 22 18:00:00 2008 Karol Trzcionka - 0.7.1-1 - Update to v0.7.1 - Using original tarball aplus-fsf-4.22.1-3.fc10 ----------------------- * Tue Apr 22 18:00:00 2008 Jochen Schmitt 4.22.1-3 - Font packaging cleanup (#443442, #443444) pcmanfm-0.4.1.1-1.fc10 ---------------------- * Sun May 11 18:00:00 2008 Mamoru Tasaka - 0.4.1.1-1 - 0.4.1 - 0.4.1.1 * Mon May 5 18:00:00 2008 Mamoru Tasaka - 0.4.0-1 - 0.4.0 * Sun Apr 13 18:00:00 2008 Mamoru Tasaka - 0.3.9.98-2 - First trial to suppress compilation warning (containing fix for crash on an occasion) * Wed Apr 9 18:00:00 2008 Mamoru Tasaka - 0.3.9.98-1 - 0.3.9.98 libsoup-2.23.1-1.fc10 --------------------- * Mon Apr 21 18:00:00 2008 Matthew Barnes - 2.23.1-1 - Update to 2.23.1 bugzilla-3.0.4-1.fc10 --------------------- * Fri May 9 18:00:00 2008 John Berninger - 3.0.4-1 - Update to upstream 3.0.4 to fix multiple security vulns - Change perms on /etc/bugzilla for bz 427981 * Sun May 4 18:00:00 2008 John Berninger - 3.0.3-0 - Update to upstream 3.0.3 - bz 444669 extragear-plasma-4.0.72-0.1.20080506svn804581.fc10 -------------------------------------------------- * Wed May 7 18:00:00 2008 Kevin Kofler 4.0.72-0.1.20080506svn804581 - update to revision 804581 from KDE SVN (to match KDE 4.0.72) - add COPYING and COPYING.LIB as %doc - update file list mcstrans-0.2.11-1.fc10 ---------------------- * Wed May 7 18:00:00 2008 Dan Walsh 0.2.11-1 - More fixes from Jim Meyering * Tue May 6 18:00:00 2008 Dan Walsh 0.2.9-1 - Start mcstrans before netlabel * Tue May 6 18:00:00 2008 Dan Walsh 0.2.10-1 - More error checking on failed strdup git-1.5.5.1-1.fc10 ------------------ * Mon Apr 21 18:00:00 2008 James Bowes 1.5.5.1-1 - git-1.5.5.1 * Wed Apr 9 18:00:00 2008 James Bowes 1.5.5-1 - git-1.5.5 gnome-desktop-2.23.1-1.fc10 --------------------------- selinux-policy-3.3.1-45.fc10 ---------------------------- * Wed Apr 30 18:00:00 2008 Dan Walsh 3.3.1-45 - Remove dmesg boolean - Allow user domains to read/write game data * Mon Apr 28 18:00:00 2008 Dan Walsh 3.3.1-44 - Change unconfined_t to transition to unconfined_mono_t when running mono - Change XXX_mono_t to transition to XXX_t when executing bin_t files, so gnome-do will work * Mon Apr 28 18:00:00 2008 Dan Walsh 3.3.1-43 - Remove old booleans from targeted-booleans.conf file nmap-4.62-1.fc10 ---------------- * Mon May 12 18:00:00 2008 Tomas Smetana - 2:4.62-1 - new upstream version kdeaccessibility-4.0.72-1.fc10 ------------------------------ * Wed May 7 18:00:00 2008 Kevin Kofler 4.0.72-1 - update to 4.0.72 kernel-xen-2.6-2.6.25.2-2.fc10 ------------------------------ * Sun May 11 18:00:00 2008 Mark McLoughlin - Fix oops during prelink (ehabkost, #442949) * Thu May 8 18:00:00 2008 Mark McLoughlin - Rebase to kernel-2_6_25_2-5_fc10 xulrunner-1.9-0.60.cvs20080414.fc10 ----------------------------------- qt-4.4.0-1.fc10 --------------- * Tue May 6 18:00:00 2008 Rex Dieter 4.4.0-1 - qt-4.4.0 * Tue Apr 29 18:00:00 2008 Rex Dieter 4.4.0-0.6.rc1 - -webkit (include in -x11 subpkg), drop separate -webkit-devel - omit qt4-wrapper.sh deps (since it's not used atm) - qt-copy-patches-20080429 - Obsoletes/Provides: WebKit-qt(-devel) <|= 1.0.0-1 (#442200) * Thu Apr 24 18:00:00 2008 Rex Dieter 4.4.0-0.5.rc1 - strip -lssl -lcrypto from *.pc files too vdr-wapd-0.9-5.patch1.fc10 -------------------------- * Sun Apr 20 18:00:00 2008 Ville Skytt?? - 0.9-5.patch1 - Update to 0.9-patch1; i18n, signedness and headers patches applied upstream. ocaml-lablgl-1.03-3.fc10 ------------------------ * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 1.03-3 - Rebuild for OCaml 3.10.2. gnome-session-2.23.1.1-1.fc10 ----------------------------- * Fri Apr 25 18:00:00 2008 Matthias Clasen - 2.23.1-1 - Update to 2.23.1 fedora-logos-9.0.0-3.fc10 ------------------------- lua-5.1.3-6.fc10 ---------------- * Mon May 12 18:00:00 2008 Tim Niemueller - 5.1.3-6 - Add -static subpackage with static liblua, fixes rh bug #445939 * Sun Apr 13 18:00:00 2008 Tim Niemueller - 5.1.3-5 - Provide lua = 5.1, this way add-on packages can easily depend on the Lua base version and expect certain paths for packages gfs-complutum-fonts-20070413-7.fc10 ----------------------------------- * Wed Apr 30 18:00:00 2008 Nicolas Mailhot - 20070413-7 ??? Yet another prep fix?? system-config-vsftpd-0.5.1-1.fc10 --------------------------------- * Thu May 1 18:00:00 2008 Maros Barabas - 0.5.1-1 - rebase from upstream AcetoneISO2-2.0.2-3.fc10 ------------------------ * Fri May 9 18:00:00 2008 Tom "spot" Callaway - 2.0.2-3 - actually apply patch2 - get rid of requires on nautilus, this application works fine without it, it is simply enhanced by the presense of nautilus/konqueror * Fri May 9 18:00:00 2008 Tom "spot" Callaway - 2.0.2-2 - fix requires, get rid of kdebase, cdrecord, k3b, xbiso, arts - add requires on nautilus (really, it should be nautilus or konqueror, but there is no good way to do that) * Wed May 7 18:00:00 2008 Tom "spot" Callaway - 2.0.2-1 - 2.0.2 libdhcp-1.99.8-1.fc10 --------------------- pfmon-3.4-1.fc10 ---------------- * Fri May 2 18:00:00 2008 Will Cohen - 3.4-1 - Update to pfmon-3.4. iso-codes-2.1-1.fc10 -------------------- * Wed May 7 18:00:00 2008 Christopher Aillon 2.1-1 - Update to 2.1 kile-2.0.1-1.fc10 ----------------- * Sun May 11 18:00:00 2008 Rex Dieter 2.0.1-1 - kile-2.0.1 (#445975) - kile should require: kdebase3 (#445933) - kpdf preview is broken (#445934) - drop deprecated kile-i18n references samba-3.2.0-1.pre3.10.fc10 -------------------------- * Fri May 9 18:00:00 2008 Guenther Deschner - 3.2.0-1.pre3.10 - Add smbclient fix (BZO #5452) mgetty-1.1.36-1.fc10 -------------------- * Thu Apr 10 18:00:00 2008 Martin Nagy - 1.1.36-1 - update to new upstream release - use our own faxq-helper man page now that we updated - fix -t flag of faxspool so it now accepts time ranges as it should (#171280) - fix mgetty and vgetty logrotate configuration files (#436727) - faxspool will handle spaces in file names better (#46697) qemu-0.9.1-7.fc10 ----------------- * Mon May 5 18:00:00 2008 Daniel P. Berrange - 0.9.1-7.fc10 - Fix text console PTYs to be in rawmode * Sun Apr 27 18:00:00 2008 Lubomir Kundrak - 0.9.1-6 - Register binary handler for SuperH-4 CPU pavucontrol-0.9.6-1.fc10 ------------------------ ocaml-calendar-2.0.2-2.fc10 --------------------------- * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 2.0.2-2 - Rebuild for OCaml 3.10.2 soprano-2.0.98-1.fc10 --------------------- * Thu May 1 18:00:00 2008 Kevin Kofler 2.0.98-1 - update to 2.0.98 (2.1 alpha 1) ocaml-facile-1.1-3.fc10 ----------------------- * Wed Apr 23 18:00:00 2008 Kevin Kofler - 1.1-3 - rebuild for new ocaml (3.10.2) * Fri Mar 21 18:00:00 2008 Kevin Kofler - 1.1-2.1 - ExcludeArch: ppc64 on Fedora < 9 (no ocaml, #438562) R-affyio-1.8.0-1.fc10 --------------------- * Fri May 2 18:00:00 2008 Pingou 1.8.0-1 - Update to bioconductor 2.2 liborigin-20071119-3.fc10 ------------------------- * Sat Apr 26 18:00:00 2008 Thibault North - 20070119-3 - now uses again version 20070119 - patch for successful rebuild with gcc4.3 * Mon Apr 21 18:00:00 2008 Thibault North - 20070115-2 - rebuild for F9 with optimized gcc4.3 extensions * Fri Jan 18 17:00:00 2008 Chitlesh Goorah - 20071119-1 - New upstream release - fix for hardcoded path of %{_libdir} - opted cmake during the build process gettext-0.17-5.fc10 ------------------- * Thu Apr 24 18:00:00 2008 Jens Petersen - 0.17-5 - fix autopoint messing up CVS files with upstream patch (#441481) zaptel-1.4.10.1-1.fc10 ---------------------- * Thu May 8 18:00:00 2008 Jeffrey C. Ollie - 1.4.10.1-1 - Update to 1.4.10.1 * Wed Apr 9 18:00:00 2008 Jeffrey C. Ollie - 1.4.10-1 - Update to 1.4.10 perl-Imager-0.64-2.fc10 ----------------------- * Thu Apr 24 18:00:00 2008 Steven Pritchard 0.64-2 - Rebuild. * Thu Apr 24 18:00:00 2008 Steven Pritchard 0.64-1 - Update to 0.64 (CVE-2008-1928). - Add versioned Test::More BR. rawstudio-1.0-1.fc10 -------------------- * Thu May 1 18:00:00 2008 Gianluca Sforna - 1.0-1 - new upstream release - drop upstreamed patch - slightly improved summary nagios-plugins-1.4.11-4.fc10 ---------------------------- wqy-bitmap-fonts-0.9.9-6.fc10 ----------------------------- * Sun May 11 18:00:00 2008 Qianqian Fang 0.9.9-6 - remove bold font files, as Xft can do fake-emboldening byitself * Sun May 11 18:00:00 2008 Qianqian Fang 0.9.9-5 - remove 61-wqy-bitmapsong.conf from source, add to cvs instead - replace DejaVu LGC to DejaVu as LCG variants are not default anymore emacs-common-tuareg-1.45.6-6.fc10 --------------------------------- * Wed Apr 30 18:00:00 2008 Richard W.M. Jones - 1.45.6-6 - Add runtime requires ocaml-emacs, because tuareg mode uses the file caml-types.el in order to do type annotation (C-c C-t). * Sat Apr 19 18:00:00 2008 Richard W.M. Jones - 1.45.6-5 - Add commas in dependencies & rebuild. pykickstart-1.34-1.fc10 ----------------------- * Wed May 7 18:00:00 2008 Chris Lumens - 1.34-1 - Load the handler module automatically. (clumens) - Add support for F10. (clumens) - Initialize cmd.handler earlier; fixes repo.methodToRepo() (markmc) - Don't shadow builtin function names. (clumens) - Running check is now required before pykickstart can be packaged. (clumens) - Reorganize code a little bit to pass pychecker. (clumens) * Tue Apr 8 18:00:00 2008 Chris Lumens - 1.33-1 - Fix whitespace when printing out the bootloader command (pmeyers). - Fix the type on bootloader --timeout processing. (clumens) cfengine-2.2.6-1.fc10 --------------------- * Tue Apr 22 18:00:00 2008 Jeff Sheltren 2.2.6-1 - Update to upstream 2.2.6 - Redirect cfkey output to /dev/null - Manpages now included (again) in upstream package, remove unneeded patch * Sat Mar 22 18:00:00 2008 Jeff Sheltren 2.2.5-1 - Update to upstream 2.2.5 - Remove variable expansion patch - Add patch for manpages which are missing from this release - Remove documentation files which are no longer included (no more info files) - Buildreqs for texinfo, tetex, tetex-dvips no longer needed htop-0.7-2.fc10 --------------- * Sun Apr 27 18:00:00 2008 Rafa?? Psota - 0.7-2 - desktop file fix tcpreplay-3.3.0-1.fc10 ---------------------- * Tue May 6 18:00:00 2008 Bojan Smojver - 3.3.0-1 - bump up to 3.3.0 * Thu May 1 18:00:00 2008 Bojan Smojver - 3.3-0.rc2.1 - bump up to 3.3.rc2 * Mon Apr 28 18:00:00 2008 Bojan Smojver - 3.3-0.rc1.1 - bump up to 3.3.rc1 gpa-0.7.6-5.fc10 ---------------- * Mon May 5 18:00:00 2008 Rex Dieter - 0.7.6-5 - BR: gnupg (#440849) - validate .desktop file ocaml-extlib-1.5.1-3.fc10 ------------------------- * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 1.5.1-3 - Rebuild for OCaml 3.10.2 libtar-1.2.11-11.fc10 --------------------- python-psycopg2-2.0.7-1.fc10 ---------------------------- * Wed Apr 30 18:00:00 2008 Devrim GUNDUZ 2.0.7-1 - Update to 2.0.7 e16-0.16.8.13-2.fc10 -------------------- * Fri May 2 18:00:00 2008 Terje Rosten - 0.16.8.13-2 - Rebuild * Fri May 2 18:00:00 2008 Terje Rosten - 0.16.8.13-1 - 0.16.8.13 gfs-solomos-fonts-20071114-6.fc10 --------------------------------- * Wed Apr 30 18:00:00 2008 Nicolas Mailhot - 20071114-6 ??? Yet another prep fix?? system-config-users-1.2.80-1.fc10 --------------------------------- * Thu May 8 18:00:00 2008 Nils Philippsen - 1.2.80-1 - handle invalid UTF-8 in passwd information more gracefully (#235533) * Tue Apr 22 18:00:00 2008 Nils Philippsen - fix duplicate shortcut (#439717) kdebindings-4.0.72-1.fc10 ------------------------- * Wed May 7 18:00:00 2008 Kevin Kofler 4.0.72-1 - update to 4.0.72 - add BR soprano-devel - update file list to include plasma-ruby stuff duplicity-0.4.11-1.fc10 ----------------------- * Mon May 5 18:00:00 2008 Robert Scheck 0.4.11-1 - Upgrade to 0.4.11 (#440346) timidity++-2.13.2-16.fc10 ------------------------- * Sat May 3 18:00:00 2008 Hans de Goede 2.13.2-16 - Some small fixes to ipv6 support from upstream libpng10-1.0.37-1.fc10 ---------------------- * Fri May 9 18:00:00 2008 Paul Howarth 1.0.37-1 - update to 1.0.37 - autotools patch no longer needed - explicitly specify the library filename in %files as a consistency check * Wed Apr 30 18:00:00 2008 Paul Howarth 1.0.34-1 - update to 1.0.34 - update autotools patch * Wed Apr 30 18:00:00 2008 Paul Howarth 1.0.33-1 - update to 1.0.33 (CVE-2008-1382, #441839) - add patch to fix broken autotools build scripts sabayon-2.22.0-3.fc10 --------------------- lua-filesystem-1.4.1-1.fc10 --------------------------- * Thu May 8 18:00:00 2008 Tim Niemueller - 1.4.1-1 - Upgrade to latest stable release deskbar-applet-2.23.2-1.fc10 ---------------------------- * Mon May 12 18:00:00 2008 Luke Macken - 2.23.2-1 - Update to 2.23.2 * Wed Apr 23 18:00:00 2008 Luke Macken - 2.23.1-1 - Update to the first release of the 2.23 unstable series * Sun Apr 20 18:00:00 2008 Luke Macken - 2.22.1-1 - Update to latest upstream release proj-4.6.0-1.fc10 ----------------- * Sun Apr 20 18:00:00 2008 Balint Cristian - 4.6.0-1 - new branch ocaml-perl4caml-0.9.5-5.fc10 ---------------------------- * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 0.9.5-5 - Rebuild for OCaml 3.10.2. prelude-lml-0.9.12.2-1.fc10 --------------------------- * Thu Apr 24 18:00:00 2008 Steve Grubb 0.9.12.2-1 - new upstream release glib2-2.16.3-5.fc10 ------------------- cellwriter-1.3.3-1.fc10 ----------------------- highlight-2.6.10-1.fc10 ----------------------- * Mon May 12 18:00:00 2008 Jochen Schmitt 2.6.10-1 - New upstream release php-pear-HTML-QuickForm-advmultiselect-1.4.1-1.fc10 --------------------------------------------------- * Sun Apr 27 18:00:00 2008 Remi Collet 1.4.1-1 - update to 1.4.1 - add generated CHANGELOG mock-0.9.9-1.fc10 ----------------- strigi-0.5.9-2.fc10 ------------------- * Sat May 10 18:00:00 2008 Deji Akingunola - 0.5.9-2 - Disable 'make test' for now, seems the buildroot cannot find java * Sat May 3 18:00:00 2008 Deji Akingunola - 0.5.9-1 - Update to 0.5.9 (bugfix release) liferea-1.4.13-3.fc9 -------------------- * Tue May 6 18:00:00 2008 Alex Lancaster - 1.4.13-3 - Bump release to fix upgrade path (again). openbabel-2.2.0-0.3.b4.fc10 --------------------------- * Thu May 8 18:00:00 2008 Kevin Kofler 2.2.0-0.3.b4 - generate Python binding with -fastdispatch on F9+ ppc64 (#427700) - add -mno-sum-in-toc to optflags on F9+ ppc64 (#427700) * Sun Mar 2 17:00:00 2008 Dominik Mierzejewski 2.2.0-0.2.b4 - updated to 2.2.0 beta4 - enable CML tests again (fixed upstream) chkrootkit-0.48-7.fc9 --------------------- * Wed Apr 9 18:00:00 2008 Michael Schwendt - 0.48-7 - Build with large file API (#441638). vinagre-2.23.1-1.fc10 --------------------- * Fri Apr 25 18:00:00 2008 Matthias Clasen - 2.23.1-1 - Update to 2.23.1 sectool-0.7.3-1.fc10 -------------------- * Mon Apr 28 18:00:00 2008 Peter Vrabec - 0.7.3-1 - new upstream release - better test integration * Fri Apr 25 18:00:00 2008 Peter Vrabec - 0.7.2-1 - new upstream release - Support overriding level configuration in ~/.sectoolrc - Add saving level configuration in GUI: * Mon Apr 21 18:00:00 2008 Peter Vrabec - 0.7.1-1 - new upstream release * Tue Apr 8 18:00:00 2008 Peter Vrabec - 0.7.0-1 - new upstream release * Mon Mar 31 18:00:00 2008 Maros Barabas - 0.6.0-4 - improved killing system in gui * Fri Mar 28 18:00:00 2008 Maros Barabas - 0.6.0-3 - code review: cleaning code in OuputFormatter adding comments migrating public formatter methods to private * Tue Mar 25 18:00:00 2008 Maros Barabas - 0.6.0-2 - repaired sensitivity of popup buttons - code review: migrating public methods to private more comments lxpanel-0.3.5.4-1.fc10 ---------------------- * Mon May 5 18:00:00 2008 Sebastian Vahl 0.3.5.4-1 - new upstream version: 0.3.5.4 - update lxpanel-default.patch gfs-theokritos-fonts-20070415-6.fc10 ------------------------------------ * Wed Apr 30 18:00:00 2008 Nicolas Mailhot - 20070415-6 ??? Yet another prep fix?? python-tgcaptcha-0.11-3.fc10 ---------------------------- * Wed Apr 23 18:00:00 2008 Luke Macken 0.11-3 - Require python-imaging aspell-0.60.6-1.fc10 -------------------- * Wed May 7 18:00:00 2008 Ivana Varekova - 12:0.60.6-1 - update to 0.60.6 geos-3.0.0-3.fc10 ----------------- * Wed Apr 23 18:00:00 2008 Balint Cristian - 3.0.0-3 - require ruby too * Wed Apr 23 18:00:00 2008 Balint Cristian - 3.0.0-2 - remove python-abi request, koji fails * Sun Apr 20 18:00:00 2008 Balint Cristian - 3.0.0-1 - New branch upstream - Fix gcc43 build - Avoid r-path hardcoding - Enable and include python module - Enable and include ruby module - Enable and run testsuite during build * Tue Feb 19 17:00:00 2008 Fedora Release Engineering - 2.2.3-2 - Autorebuild for GCC 4.3 javasqlite-20080420-1.fc10 -------------------------- * Tue Apr 22 18:00:00 2008 Ville Skytt?? - 20080420-1 - 20080420; all upstreamable patches applied upstream. ruby-aws-0.2.0-1.fc10 --------------------- * Wed Apr 30 18:00:00 2008 Mamoru Tasaka - 0.2.0-1 - 0.2.0 * Tue Apr 15 18:00:00 2008 Mamoru Tasaka - 0.1.0-1 - 0.1.0 - Description, etc, synced to upstream sipp-3.1-1.fc10 --------------- * Wed Apr 30 18:00:00 2008 Peter Lemenkov 3.1-1 - Ver 3.1 scponly-4.8-1.fc10 ------------------ * Mon May 5 18:00:00 2008 Toshio Kuratomi - 4.8-1 - Update to 4.8 which has its own version of. scponly-4.6-CVE-2007-6415. gnome-speech-0.4.19-1.fc10 -------------------------- * Fri Apr 25 18:00:00 2008 Matthias Clasen - 0.4.19-1 - Update to 0.4.19 net-snmp-5.4.1-15.fc10 ---------------------- * Mon Apr 21 18:00:00 2008 Jan Safranek 5.4.1-15 - explicitly require lm_sensor > 3 for build (#442718) - create multilib net-snmp-config on multilib architectures only scons-0.98.3-2.fc10 ------------------- * Sun May 4 18:00:00 2008 Gerard Milmeister - 0.98.3-2 - changed shebang line of scripts * Sun May 4 18:00:00 2008 Gerard Milmeister - 0.98.3-1 - new release 0.98.3 * Sat Apr 19 18:00:00 2008 Gerard Milmeister - 0.98.1-1 - new release 0.98.1 ocaml-json-wheel-1.0.4-5.fc10 ----------------------------- * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 1.0.4-5 - Rebuild for OCaml 3.10.2 php-pear-Net-SMTP-1.3.0-1.fc10 ------------------------------ * Sun Apr 27 18:00:00 2008 Remi Collet 1.3.0-1 - update to 1.3.0 jomolhari-fonts-0.003-5.fc10 ---------------------------- * Tue Apr 29 18:00:00 2008 Marcin Garski 0.003-5 - Update URL perl-Text-Template-1.45-1.fc10 ------------------------------ * Wed Apr 23 18:00:00 2008 Ralf Cors??pius - 1.45-1 - Upstream update. - Abandon perl-Text-Template-perl510-fixtest09.patch. rpy-1.0.2-1.fc10 ---------------- * Tue Apr 29 18:00:00 2008 Tom "spot" Callaway - 1.0.2-1 - update to 1.0.2 - R 2.7.0 hyphen-2.4-1.fc10 ----------------- * Fri May 2 18:00:00 2008 Caolan McNamara - 2.4-1 - latest version revisor-2.1.0-2.fc10 -------------------- * Thu May 1 18:00:00 2008 Jeroen van Meeuwen 2.1.0-2 - Latest rebuild - Bugfixes in live media creation - F-9 Release ocaml-type-conv-1.5.0-2.fc10 ---------------------------- * Mon May 5 18:00:00 2008 Richard W.M. Jones - 1.5.0-2 - Ignore Asttypes/Parsetree. * Sat May 3 18:00:00 2008 Richard W.M. Jones - 1.5.0-1 - New upstream version 1.5.0. * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 1.4.0-2 - Rebuild for OCaml 3.10.2 * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 1.4.0-1 - New version 1.4.0. - Fixed upstream URL. twitux-0.62-1.fc10 ------------------ * Tue Apr 29 18:00:00 2008 Brian Pepple - 0.62-1 - Update to 0.62. ocaml-openin-20070524-3.fc10 ---------------------------- * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 20070524-3 - Rebuild for OCaml 3.10.2 openais-0.83-2.fc10 ------------------- * Mon May 12 18:00:00 2008 Steven Dake - 0.83-2 - Fix DOA on source tarball. * Mon May 12 18:00:00 2008 Steven Dake - 0.83-1 - Release 0.83. Tue Apr 29 2008 Fabio M. Di Nitto - 0.82-1.svn1528 - Update to latest svn trunk in preparation for 0.83. - Fix a bunch of rpmlint warnings/errors. - Merge bits from the fedora package. - Remove all unrequired patches. - Update default config patch. * Tue Apr 1 18:00:00 2008 Steven Dake - 0.80.3-15 - Resolves: rhbz#432531 - Add upstream revision 1514 - Remove extra log_printf. - Add upstream revision 1513 - Remove comparison with zero and replace with comparison with NULL in handle database code. - Add upstream revision 1512 - Remove early commit of synchronization data when a synchronization in progress is followed by a node leaving or joining the cluster. - Add upstream revision 1511 - Remove double pthread_mutex_destroy from evt service. - Add upstream revision 1510 - Remove double pthread_mutex_destroy from evs service. - Add upstream revision 1509 - Remove double pthread_mutex_destroy from cpg service. - Add upstream revision 1508 - Remove double pthread_mutex_destroy from clm service. - Add upstream revision 1507 - Remove double pthread_mutex_destroy from checkpoint service. * Sat Mar 15 18:00:00 2008 Steven Dake - 0.80.3-14 - Resolves: rhbz#432531 - Add upstream revision 1506 - Resolves incomplete checkpoing synchronization when totem queue is full. * Thu Mar 6 17:00:00 2008 Steven Dake - 0.80.3-13 - Resolves: rhbz#432531 - Add upstream revision 1504 - Fixes checkpoint synchronization issue when a new node is started. - Add upstream revision 1503 - backport -f foreground option. - Add upstream revision 1502 - Revert revision 1477 which exhibits problems with cman. - Add revision 1477 - This was reverted in a previous version but cherrypicked. Now the patch has been applied and reverted in the rpm build process to match upstream. mousetweaks-2.22.1-1.fc10 ------------------------- libvirt-0.4.2-4.fc10 -------------------- * Fri May 9 18:00:00 2008 Daniel P. Berrange - 0.4.2-4.fc10 - Added directory for initrd/kernel images for SELinux policy * Mon Apr 28 18:00:00 2008 Mark McLoughlin - 0.4.2-3.fc10 - Simplify the way arch conditionals are handled * Mon Apr 28 18:00:00 2008 Mark McLoughlin - 0.4.2-2.fc10 - Enable lokkit support (#443796) swfdec-0.6.6-1.fc10 ------------------- * Wed Apr 23 18:00:00 2008 Brian Pepple - 0.6.6-1 - Update to 0.6.6. - Drop memory-overwrite patch. Fixed upstream. - Drop alsa patch. Fixed upstream. * Thu Apr 10 18:00:00 2008 Brian Pepple - 0.6.4-3 - Add patch to fix memory overwrite error. (#441614) * Thu Apr 10 18:00:00 2008 Brian Pepple - 0.6.4-2 - Build w/ alsa backend instead of pulse audio. - Add patch to fix alsa support. (#441617). - Drop unnecessary BR on js-devel and gnome-vfs2-devel. - Add BR on glib2-devel. xorg-x11-drv-radeonhd-1.2.1-1.1.20080429git.fc9 ----------------------------------------------- * Tue Apr 29 18:00:00 2008 Hans Ulrich Niedermann - 1.2.1-1.1.20080429git - Fix segfault in some configurations (commit 71ec0c90) (#439046) - New snapshot (upstream commit 45fdec79e523f3f9637c35a3d84c1fd9e61b9b21): - 45fdec79: R5xx TMDSA: Power: don't clobber UNKNOWN when going in RESET. - c2a844ca: LVTMA: always use IDCLK for transmitter. - 9d489911: Add proper fallbacks for I2C timing if clock information from AtomBIOS isn't available. - 71ec0c90: Limit mapped fb size to available VRAM, clamp VGA save/restore to mapped fb size. - 0697b366: Add a test for __GLIBC__ to CD_Common_Types.h. - 19e4011e: Add connector table for 0x7183, 0x1092, 0x3000. - e3d1a63a: Fix flickering thru DPMS on TMDSA, improve debug messages for output Power(). - 686fd334: Add fallback to rhd_conntest to work when AtomBIOS isn't available. - 38e7a912: Add better debugging output for VGASave(). - 6f34607b: Fix mapping flags for FB when using libpciaccess. - 10ebfdbc: Adapt to API changes in current upstream X. - db8aa081: Add register write to dumper. - 0dd39c82: Clamp the size of VGA memory to read to not read past the end of the framebuffer. - 0442f2d5: Don't use chipset based backlight control when not enabled at startup. - df83b56a: Improve DAC load detection. - 420a4b10: Fix backlight and coherent property for RandR 1.3. - 84bf6a2a: Remove debugging code that was accidentally committed. - 0ffd41e0: Remove call to alloca(). - bdea7eba: Fix up function name for RHDReadPCIBios(). - b6bec02e: Replace reverse engineered PCI BIOS ROM enable code for R6xx. - e65e6c00: Fall back to reading the PCI VBIOS when reading from legacy location fails. - cf87d316: Fix a segfault in the DIG block. - b6be09ff: Save/Restore backlight controls, obtain initial brightness from text mode. - 3893c621: Add backlight support to RV620/635 DIG transmitter blocks. - 5fccf420: Add support for coherent mode for digital outputs to rhd_randr.c. - d401bf8f: Add 'coherent' property for DIG (UNIPHY/LVTMA), R5/6xx LVTMA and TMDSA. - 54a74878: Change backlight controls to new property model. - 01e9dd1d: Add general output property callback. - a751128b: Backlight control: change some debugging output to only show in verbose log. - b7a2fa25: Add support to control backlight brightness thru RandR properties. - e4d846c9: Include alloca.h in rhd_conntest.c, fix messages in rhd_dump. - 725ea553: Reorder TMDSA setup/power on code. Improve TMDS PLL reset. - bf267c11: Add connector quirk table for Visiontek C1550. - a60e01c8: Fixed name "RHD_DDC_NONE" printed out to log message. - 6a19b519: Add missing support for HDP_FB_BASE on r5xx and rs690. * Tue Apr 15 18:00:00 2008 Hans Ulrich Niedermann - 1.2.1-1 - 1.2.1 release (upstream commit 761940fde7fef72bff18a8b8e840540452cf675a) - New RV670 devices added: HD 3960, FireStream 9170 - Unsupported M86 device removed: HD3650 - assert() -> ASSERT() fixes * Fri Apr 11 18:00:00 2008 Hans Ulrich Niedermann - 1.2.0-2 - Fix spec file snapshot/no-snapshot conditionals - 1.2.0 release (upstream commit 9d131f9035b3b0ff7755dda708e16326aa156e83): - 9d131f90: Bump to 1.2.0. Add changes to README. - 7560240b: Update + fix supported chips list, both in source and manpage. - 59505016: Add a very basic register dump utility. - b0563cbd: Add a very basic register dump utility. - 89c10062: Minor cleanups. - bb652740: git_version scripts: add licensing information. - 60dc7e04: Add a hard coded connector table for an MSI HD2600PRO AGP. - 8048353d: Remove unneeded use of pciTag when using libpciaccess. - 3076447f: Fix MC access for RS 690. - 01bc57b1: Add initial support for talking to IGP northbridges. - 46367d61: Add IGP flag to chipset map. - 338eb58b: In verbose 7 debug mode dump present mode line. - c0c8fbed: Mark PCI subsystem 0x94C1, 0x1002, 0x0D02 DMS-59. - 5a8138e8: Treat RV635 as a separate family. - 954fd01c: Provide more information on HPD detection and mode programming in verbose log. - 4733547b: Add support for the full RS690 family including RS740. - 580ad5bf: Enable RS690 MC support. - decf3554: Treat all RV515 chips as such in MC code. - 2c2d1320: Add a workaround to make interlaced mode work. - 783b5ab4: Add support for interlaced modes. - 6d5ef116: Add better support for LVTMA TMDS macro control values on R5xx and RS600/RS690. - 38efb27c: Add MC idle testing for RV515, add MC support for RV550. - f64aba20: Use proper temporal dither reset bits depending on chip generation. tcl-8.5.1-4.fc10 ---------------- * Wed Apr 23 18:00:00 2008 Marcela Maslanova - 1:8.5.1-4 - #443246 configure with disabled threads. Threads could lead to segfaults of dependent programme. SAASound-3.2-5.fc10 ------------------- cupsddk-1.2.3-5.fc10 -------------------- * Mon May 12 18:00:00 2008 Tim Waugh 1.2.3-5 - Move defs files to drivers subpackage (bug #446054). libsmi-0.4.8-1.fc10 ------------------- initscripts-8.76.1-1 -------------------- * Wed May 7 18:00:00 2008 Bill Nottingham - 8.76.1-1 - NMDispatcher/05-netfs: fix check for default route (#445509) hunspell-1.2.2-1.fc10 --------------------- * Fri Apr 18 18:00:00 2008 Caolan McNamara - 1.2.2-1 - latest version - drop integrated hunspell-1.2.1-1863239.badstructs.patch ocaml-xml-light-2.2.cvs20070817-8.fc10 -------------------------------------- * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 2.2.cvs20070817-8 - Rebuild for OCaml 3.10.2 gtkwave-3.1.9-1.fc10 -------------------- * Tue Apr 22 18:00:00 2008 Paul Howarth 3.1.9-1 - update to 3.1.9 scim-1.4.7-23.fc10 ------------------ libchewing-0.3.0-11.fc10 ------------------------ * Tue Apr 22 18:00:00 2008 Caius Chance - 0.3.0-11.fc10 - Resolves: rhbz195416 (Initial input mode between Chinese and English.) Summary: Added Packages: 115 Removed Packages: 4 Modified Packages: 588 Broken deps for i386 ---------------------------------------------------------- FlightGear-1.0.0-2.fc9.i386 requires libplibssgaux.so.1.8.4 FlightGear-1.0.0-2.fc9.i386 requires libplibfnt.so.1.8.4 FlightGear-1.0.0-2.fc9.i386 requires libplibssg.so.1.8.4 FlightGear-1.0.0-2.fc9.i386 requires libplibpuaux.so.1.8.4 FlightGear-1.0.0-2.fc9.i386 requires libplibpu.so.1.8.4 FlightGear-1.0.0-2.fc9.i386 requires libplibjs.so.1.8.4 FlightGear-1.0.0-2.fc9.i386 requires libplibnet.so.1.8.4 FlightGear-1.0.0-2.fc9.i386 requires libplibsg.so.1.8.4 FlightGear-1.0.0-2.fc9.i386 requires libplibul.so.1.8.4 LabPlot-1.5.1.6-4.fc8.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libMagick.so.10 SimGear-1.0.0-3.fc9.i386 requires libplibul.so.1.8.4 SimGear-1.0.0-3.fc9.i386 requires libplibssg.so.1.8.4 SimGear-1.0.0-3.fc9.i386 requires libplibnet.so.1.8.4 SimGear-1.0.0-3.fc9.i386 requires libplibsg.so.1.8.4 autotrace-0.31.1-16.fc9.i386 requires libWand.so.10 autotrace-0.31.1-16.fc9.i386 requires libMagick.so.10 brasero-0.7.1-3.fc9.i386 requires libtotem-plparser.so.10 1:bug-buddy-2.22.0-2.fc9.i386 requires libedataserver-1.2.so.9 cheese-2.23.1-1.fc10.i386 requires libedataserver-1.2.so.9 contact-lookup-applet-0.16-5.fc9.i386 requires libedataserver-1.2.so.9 contacts-0.8-3.fc9.i386 requires libedataserver-1.2.so.9 1:control-center-2.23.1-2.fc10.i386 requires libedataserver-1.2.so.9 1:control-center-2.23.1-2.fc10.i386 requires libgnomekbdui.so.2 1:control-center-2.23.1-2.fc10.i386 requires libgnomekbd.so.2 dates-0.4.5-2.fc9.i386 requires libedataserver-1.2.so.9 drawtiming-0.6.2-3.fc9.i386 requires libMagick++.so.10 drawtiming-0.6.2-3.fc9.i386 requires libWand.so.10 drawtiming-0.6.2-3.fc9.i386 requires libMagick.so.10 dx-4.4.4-6.fc9.i386 requires libWand.so.10 dx-4.4.4-6.fc9.i386 requires libMagick.so.10 dx-libs-4.4.4-6.fc9.i386 requires libWand.so.10 dx-libs-4.4.4-6.fc9.i386 requires libMagick.so.10 empathy-0.23.1-2.fc10.i386 requires libedataserver-1.2.so.9 empathy-libs-0.23.1-2.fc10.i386 requires libedataserver-1.2.so.9 evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-python-0.0.4-3.fc9.i386 requires libedataserver-1.2.so.9 evolution-sharp-0.16.0-1.fc9.i386 requires libedataserver-1.2.so.9 evolution-webcal-2.21.92-1.fc9.i386 requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.i386 requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-1.2.so.11 fgfs-Atlas-0.3.1-8.fc9.i386 requires libplibul.so.1.8.4 fgfs-Atlas-0.3.1-8.fc9.i386 requires libplibfnt.so.1.8.4 fgfs-Atlas-0.3.1-8.fc9.i386 requires libplibpu.so.1.8.4 fgfs-Atlas-0.3.1-8.fc9.i386 requires libplibnet.so.1.8.4 fgfs-Atlas-0.3.1-8.fc9.i386 requires libplibsg.so.1.8.4 gdl-0.9-0.rc1.1.fc9.i386 requires libMagick++.so.10 glabels-2.2.2-1.fc9.i386 requires libedataserver-1.2.so.9 1:gnome-applets-2.22.1-3.fc10.i386 requires libgnomekbdui.so.2 1:gnome-applets-2.22.1-3.fc10.i386 requires libgnomekbd.so.2 gnome-launch-box-0.4-8.fc9.i386 requires libedataserver-1.2.so.9 gnome-panel-2.23.1-1.fc10.i386 requires libedataserver-1.2.so.9 gnome-phone-manager-0.51-1.fc9.i386 requires libedataserver-1.2.so.9 gnome-python2-evolution-2.22.0-2.fc9.i386 requires libedataserver-1.2.so.9 gnome-python2-totem-2.22.0-2.fc9.i386 requires libtotem-plparser.so.10 gnome-screensaver-2.22.1-1.fc9.i386 requires libgnomekbdui.so.2 gnome-screensaver-2.22.1-1.fc9.i386 requires libgnomekbd.so.2 gnome-settings-daemon-2.23.1.1-4.fc10.i386 requires libgnomekbd.so.2 gossip-0.29-1.fc10.i386 requires libedataserver-1.2.so.9 imageinfo-0.05-3.fc9.i386 requires libWand.so.10 imageinfo-0.05-3.fc9.i386 requires libMagick.so.10 k3d-0.6.7.0-6.fc9.i386 requires libMagick++.so.10 k3d-0.6.7.0-6.fc9.i386 requires libMagick.so.10 k3d-0.6.7.0-6.fc9.i386 requires libWand.so.10 kismet-extras-0.0.2007.10.R1-3.fc9.i386 requires libMagick.so.10 koffice-karbon-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-karbon-1.6.3-15.fc9.i386 requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libMagick.so.10 libfprint-0.0.5-3.fc9.i386 requires libWand.so.10 libfprint-0.0.5-3.fc9.i386 requires libMagick.so.10 libopensync-plugin-evolution2-0.35-3.fc9.i386 requires libedataserver-1.2.so.9 nautilus-sendto-0.14.0-1.fc9.i386 requires libedataserver-1.2.so.9 nip2-7.14.1-1.fc9.i386 requires libWand.so.10 nip2-7.14.1-1.fc9.i386 requires libMagick.so.10 1:openoffice.org-core-2.4.0-12.8.fc9.i386 requires libhunspell.so.1 oxine-0.7.0-2.fc9.i386 requires libWand.so.10 oxine-0.7.0-2.fc9.i386 requires libMagick.so.10 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) php-magickwand-1.0.7-1.fc10.i386 requires libWand.so.10 php-magickwand-1.0.7-1.fc10.i386 requires libMagick.so.10 pidgin-2.4.1-2.fc9.i386 requires libedataserver-1.2.so.9 planner-eds-0.14.3-1.fc10.i386 requires libcamel-provider-1.2.so.11 planner-eds-0.14.3-1.fc10.i386 requires libedataserver-1.2.so.9 planner-eds-0.14.3-1.fc10.i386 requires libcamel-1.2.so.11 psiconv-0.9.8-1.fc8.i386 requires libWand.so.10 psiconv-0.9.8-1.fc8.i386 requires libMagick.so.10 pstoedit-3.45-2.fc9.i386 requires libMagick++.so.10 pstoedit-3.45-2.fc9.i386 requires libWand.so.10 pstoedit-3.45-2.fc9.i386 requires libMagick.so.10 q-7.10-3.fc9.i386 requires libMagick.so.10 qgis-0.9.1-5.fc9.i386 requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.i386 requires libgeos.so.2 rhythmbox-0.11.5-9.fc9.i386 requires libtotem-plparser.so.10 stormbaancoureur-2.1.2-1.fc9.i386 requires libplibssgaux.so.1.8.4 stormbaancoureur-2.1.2-1.fc9.i386 requires libplibssg.so.1.8.4 stormbaancoureur-2.1.2-1.fc9.i386 requires libplibpu.so.1.8.4 stormbaancoureur-2.1.2-1.fc9.i386 requires libplibfnt.so.1.8.4 stormbaancoureur-2.1.2-1.fc9.i386 requires libplibsg.so.1.8.4 stormbaancoureur-2.1.2-1.fc9.i386 requires libplibul.so.1.8.4 sunbird-0.8-3.fc9.i386 requires libhunspell.so.1 supertuxkart-0.4-1.fc9.i386 requires libplibssgaux.so.1.8.4 supertuxkart-0.4-1.fc9.i386 requires libplibsg.so.1.8.4 supertuxkart-0.4-1.fc9.i386 requires libplibjs.so.1.8.4 supertuxkart-0.4-1.fc9.i386 requires libplibssg.so.1.8.4 supertuxkart-0.4-1.fc9.i386 requires libplibpu.so.1.8.4 supertuxkart-0.4-1.fc9.i386 requires libplibfnt.so.1.8.4 supertuxkart-0.4-1.fc9.i386 requires libplibsl.so.1.8.4 supertuxkart-0.4-1.fc9.i386 requires libplibul.so.1.8.4 syncevolution-0.7-2.fc9.i386 requires libedataserver-1.2.so.9 tasks-0.12-2.fc9.i386 requires libedataserver-1.2.so.9 theora-tools-1.0beta3-1.fc10.i386 requires libtheoraenc.so.1(libtheoraenc_1.0) theora-tools-1.0beta3-1.fc10.i386 requires libtheoraenc.so.1 thunderbird-lightning-0.8-3.fc9.i386 requires libhunspell.so.1 2:tog-pegasus-2.7.0-6.fc9.i386 requires SysVinit 2:tog-pegasus-2.7.0-6.fc9.i386 requires SysVinit torcs-1.3.0-6.fc9.i386 requires libplibssgaux.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibssg.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibsl.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibsm.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibsg.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibul.so.1.8.4 totem-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 totem-mozplugin-2.23.2-2.fc9.i386 requires libtotem-plparser-mini.so.10 totem-mozplugin-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 totem-nautilus-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 totem-pl-parser-2.23.1-1.fc10.i386 requires libedataserver-1.2.so.9 vips-7.14.1-1.fc9.i386 requires libWand.so.10 vips-7.14.1-1.fc9.i386 requires libMagick.so.10 vips-python-7.14.1-1.fc9.i386 requires libWand.so.10 vips-python-7.14.1-1.fc9.i386 requires libMagick.so.10 vips-tools-7.14.1-1.fc9.i386 requires libWand.so.10 vips-tools-7.14.1-1.fc9.i386 requires libMagick.so.10 xastir-1.9.2-4.fc9.i386 requires libWand.so.10 xastir-1.9.2-4.fc9.i386 requires libMagick.so.10 xulrunner-1.9-0.60.cvs20080414.fc10.i386 requires libhunspell.so.1 Broken deps for x86_64 ---------------------------------------------------------- FlightGear-1.0.0-2.fc9.x86_64 requires libplibul.so.1.8.4()(64bit) FlightGear-1.0.0-2.fc9.x86_64 requires libplibssgaux.so.1.8.4()(64bit) FlightGear-1.0.0-2.fc9.x86_64 requires libplibnet.so.1.8.4()(64bit) FlightGear-1.0.0-2.fc9.x86_64 requires libplibjs.so.1.8.4()(64bit) FlightGear-1.0.0-2.fc9.x86_64 requires libplibsg.so.1.8.4()(64bit) FlightGear-1.0.0-2.fc9.x86_64 requires libplibpuaux.so.1.8.4()(64bit) FlightGear-1.0.0-2.fc9.x86_64 requires libplibpu.so.1.8.4()(64bit) FlightGear-1.0.0-2.fc9.x86_64 requires libplibssg.so.1.8.4()(64bit) FlightGear-1.0.0-2.fc9.x86_64 requires libplibfnt.so.1.8.4()(64bit) LabPlot-1.5.1.6-4.fc8.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libMagick.so.10 LabPlot-1.5.1.6-4.fc8.x86_64 requires libMagick++.so.10()(64bit) LabPlot-1.5.1.6-4.fc8.x86_64 requires libMagick.so.10()(64bit) LabPlot-1.5.1.6-4.fc8.x86_64 requires libWand.so.10()(64bit) SimGear-1.0.0-3.fc9.i386 requires libplibul.so.1.8.4 SimGear-1.0.0-3.fc9.i386 requires libplibssg.so.1.8.4 SimGear-1.0.0-3.fc9.i386 requires libplibnet.so.1.8.4 SimGear-1.0.0-3.fc9.i386 requires libplibsg.so.1.8.4 SimGear-1.0.0-3.fc9.x86_64 requires libplibul.so.1.8.4()(64bit) SimGear-1.0.0-3.fc9.x86_64 requires libplibnet.so.1.8.4()(64bit) SimGear-1.0.0-3.fc9.x86_64 requires libplibsg.so.1.8.4()(64bit) SimGear-1.0.0-3.fc9.x86_64 requires libplibssg.so.1.8.4()(64bit) autotrace-0.31.1-16.fc9.i386 requires libWand.so.10 autotrace-0.31.1-16.fc9.i386 requires libMagick.so.10 autotrace-0.31.1-16.fc9.x86_64 requires libWand.so.10()(64bit) autotrace-0.31.1-16.fc9.x86_64 requires libMagick.so.10()(64bit) brasero-0.7.1-3.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) 1:bug-buddy-2.22.0-2.fc9.i386 requires libedataserver-1.2.so.9 1:bug-buddy-2.22.0-2.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) cheese-2.23.1-1.fc10.x86_64 requires libedataserver-1.2.so.9()(64bit) contact-lookup-applet-0.16-5.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) contacts-0.8-3.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) 1:control-center-2.23.1-2.fc10.i386 requires libedataserver-1.2.so.9 1:control-center-2.23.1-2.fc10.i386 requires libgnomekbdui.so.2 1:control-center-2.23.1-2.fc10.i386 requires libgnomekbd.so.2 1:control-center-2.23.1-2.fc10.x86_64 requires libgnomekbd.so.2()(64bit) 1:control-center-2.23.1-2.fc10.x86_64 requires libgnomekbdui.so.2()(64bit) 1:control-center-2.23.1-2.fc10.x86_64 requires libedataserver-1.2.so.9()(64bit) dates-0.4.5-2.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) drawtiming-0.6.2-3.fc9.x86_64 requires libWand.so.10()(64bit) drawtiming-0.6.2-3.fc9.x86_64 requires libMagick++.so.10()(64bit) drawtiming-0.6.2-3.fc9.x86_64 requires libMagick.so.10()(64bit) dx-4.4.4-6.fc9.x86_64 requires libMagick.so.10()(64bit) dx-4.4.4-6.fc9.x86_64 requires libWand.so.10()(64bit) dx-libs-4.4.4-6.fc9.i386 requires libWand.so.10 dx-libs-4.4.4-6.fc9.i386 requires libMagick.so.10 dx-libs-4.4.4-6.fc9.x86_64 requires libMagick.so.10()(64bit) dx-libs-4.4.4-6.fc9.x86_64 requires libWand.so.10()(64bit) empathy-0.23.1-2.fc10.x86_64 requires libedataserver-1.2.so.9()(64bit) empathy-libs-0.23.1-2.fc10.i386 requires libedataserver-1.2.so.9 empathy-libs-0.23.1-2.fc10.x86_64 requires libedataserver-1.2.so.9()(64bit) evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libWand.so.10()(64bit) evolution-python-0.0.4-3.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) evolution-sharp-0.16.0-1.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) evolution-webcal-2.21.92-1.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) fgfs-Atlas-0.3.1-8.fc9.x86_64 requires libplibul.so.1.8.4()(64bit) fgfs-Atlas-0.3.1-8.fc9.x86_64 requires libplibnet.so.1.8.4()(64bit) fgfs-Atlas-0.3.1-8.fc9.x86_64 requires libplibsg.so.1.8.4()(64bit) fgfs-Atlas-0.3.1-8.fc9.x86_64 requires libplibpu.so.1.8.4()(64bit) fgfs-Atlas-0.3.1-8.fc9.x86_64 requires libplibfnt.so.1.8.4()(64bit) freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx gdl-0.9-0.rc1.1.fc9.x86_64 requires libMagick++.so.10()(64bit) glabels-2.2.2-1.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) 1:gnome-applets-2.22.1-3.fc10.x86_64 requires libgnomekbd.so.2()(64bit) 1:gnome-applets-2.22.1-3.fc10.x86_64 requires libgnomekbdui.so.2()(64bit) gnome-launch-box-0.4-8.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) gnome-panel-2.23.1-1.fc10.x86_64 requires libedataserver-1.2.so.9()(64bit) gnome-phone-manager-0.51-1.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) gnome-python2-evolution-2.22.0-2.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) gnome-python2-totem-2.22.0-2.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) gnome-screensaver-2.22.1-1.fc9.x86_64 requires libgnomekbd.so.2()(64bit) gnome-screensaver-2.22.1-1.fc9.x86_64 requires libgnomekbdui.so.2()(64bit) gnome-settings-daemon-2.23.1.1-4.fc10.x86_64 requires libgnomekbd.so.2()(64bit) gossip-0.29-1.fc10.x86_64 requires libedataserver-1.2.so.9()(64bit) imageinfo-0.05-3.fc9.x86_64 requires libWand.so.10()(64bit) imageinfo-0.05-3.fc9.x86_64 requires libMagick.so.10()(64bit) k3d-0.6.7.0-6.fc9.i386 requires libMagick++.so.10 k3d-0.6.7.0-6.fc9.i386 requires libMagick.so.10 k3d-0.6.7.0-6.fc9.i386 requires libWand.so.10 k3d-0.6.7.0-6.fc9.x86_64 requires libMagick.so.10()(64bit) k3d-0.6.7.0-6.fc9.x86_64 requires libWand.so.10()(64bit) k3d-0.6.7.0-6.fc9.x86_64 requires libMagick++.so.10()(64bit) kismet-extras-0.0.2007.10.R1-3.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.x86_64 requires libWand.so.10()(64bit) koffice-libs-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.x86_64 requires libWand.so.10()(64bit) libfprint-0.0.5-3.fc9.i386 requires libWand.so.10 libfprint-0.0.5-3.fc9.i386 requires libMagick.so.10 libfprint-0.0.5-3.fc9.x86_64 requires libWand.so.10()(64bit) libfprint-0.0.5-3.fc9.x86_64 requires libMagick.so.10()(64bit) libopensync-plugin-evolution2-0.35-3.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) nautilus-sendto-0.14.0-1.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) nip2-7.14.1-1.fc9.x86_64 requires libMagick.so.10()(64bit) nip2-7.14.1-1.fc9.x86_64 requires libWand.so.10()(64bit) 1:openoffice.org-core-2.4.0-12.8.fc9.x86_64 requires libhunspell.so.1()(64bit) oxine-0.7.0-2.fc9.x86_64 requires libMagick.so.10()(64bit) oxine-0.7.0-2.fc9.x86_64 requires libWand.so.10()(64bit) perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) php-magickwand-1.0.7-1.fc10.x86_64 requires libWand.so.10()(64bit) php-magickwand-1.0.7-1.fc10.x86_64 requires libMagick.so.10()(64bit) pidgin-2.4.1-2.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) planner-eds-0.14.3-1.fc10.x86_64 requires libcamel-provider-1.2.so.11()(64bit) planner-eds-0.14.3-1.fc10.x86_64 requires libcamel-1.2.so.11()(64bit) planner-eds-0.14.3-1.fc10.x86_64 requires libedataserver-1.2.so.9()(64bit) psiconv-0.9.8-1.fc8.i386 requires libWand.so.10 psiconv-0.9.8-1.fc8.i386 requires libMagick.so.10 psiconv-0.9.8-1.fc8.x86_64 requires libWand.so.10()(64bit) psiconv-0.9.8-1.fc8.x86_64 requires libMagick.so.10()(64bit) pstoedit-3.45-2.fc9.i386 requires libMagick++.so.10 pstoedit-3.45-2.fc9.i386 requires libWand.so.10 pstoedit-3.45-2.fc9.i386 requires libMagick.so.10 pstoedit-3.45-2.fc9.x86_64 requires libMagick++.so.10()(64bit) pstoedit-3.45-2.fc9.x86_64 requires libMagick.so.10()(64bit) pstoedit-3.45-2.fc9.x86_64 requires libWand.so.10()(64bit) q-7.10-3.fc9.i386 requires libMagick.so.10 qgis-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) rhythmbox-0.11.5-9.fc9.i386 requires libtotem-plparser.so.10 rhythmbox-0.11.5-9.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) stormbaancoureur-2.1.2-1.fc9.x86_64 requires libplibul.so.1.8.4()(64bit) stormbaancoureur-2.1.2-1.fc9.x86_64 requires libplibssgaux.so.1.8.4()(64bit) stormbaancoureur-2.1.2-1.fc9.x86_64 requires libplibpu.so.1.8.4()(64bit) stormbaancoureur-2.1.2-1.fc9.x86_64 requires libplibsg.so.1.8.4()(64bit) stormbaancoureur-2.1.2-1.fc9.x86_64 requires libplibssg.so.1.8.4()(64bit) stormbaancoureur-2.1.2-1.fc9.x86_64 requires libplibfnt.so.1.8.4()(64bit) sunbird-0.8-3.fc9.x86_64 requires libhunspell.so.1()(64bit) supertuxkart-0.4-1.fc9.x86_64 requires libplibul.so.1.8.4()(64bit) supertuxkart-0.4-1.fc9.x86_64 requires libplibssgaux.so.1.8.4()(64bit) supertuxkart-0.4-1.fc9.x86_64 requires libplibjs.so.1.8.4()(64bit) supertuxkart-0.4-1.fc9.x86_64 requires libplibpu.so.1.8.4()(64bit) supertuxkart-0.4-1.fc9.x86_64 requires libplibsg.so.1.8.4()(64bit) supertuxkart-0.4-1.fc9.x86_64 requires libplibssg.so.1.8.4()(64bit) supertuxkart-0.4-1.fc9.x86_64 requires libplibfnt.so.1.8.4()(64bit) supertuxkart-0.4-1.fc9.x86_64 requires libplibsl.so.1.8.4()(64bit) syncevolution-0.7-2.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) tasks-0.12-2.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) theora-tools-1.0beta3-1.fc10.x86_64 requires libtheoraenc.so.1(libtheoraenc_1.0)(64bit) theora-tools-1.0beta3-1.fc10.x86_64 requires libtheoraenc.so.1()(64bit) thunderbird-lightning-0.8-3.fc9.x86_64 requires libhunspell.so.1()(64bit) 2:tog-pegasus-2.7.0-6.fc9.i386 requires SysVinit 2:tog-pegasus-2.7.0-6.fc9.i386 requires SysVinit 2:tog-pegasus-2.7.0-6.fc9.x86_64 requires SysVinit 2:tog-pegasus-2.7.0-6.fc9.x86_64 requires SysVinit torcs-1.3.0-6.fc9.x86_64 requires libplibsg.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibul.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibssgaux.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibsm.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibssg.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibsl.so.1.8.4()(64bit) totem-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 totem-2.23.2-2.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.x86_64 requires libtotem-plparser-mini.so.10()(64bit) totem-nautilus-2.23.2-2.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) totem-pl-parser-2.23.1-1.fc10.i386 requires libedataserver-1.2.so.9 totem-pl-parser-2.23.1-1.fc10.x86_64 requires libedataserver-1.2.so.9()(64bit) vips-7.14.1-1.fc9.i386 requires libWand.so.10 vips-7.14.1-1.fc9.i386 requires libMagick.so.10 vips-7.14.1-1.fc9.x86_64 requires libMagick.so.10()(64bit) vips-7.14.1-1.fc9.x86_64 requires libWand.so.10()(64bit) vips-python-7.14.1-1.fc9.x86_64 requires libMagick.so.10()(64bit) vips-python-7.14.1-1.fc9.x86_64 requires libWand.so.10()(64bit) vips-tools-7.14.1-1.fc9.x86_64 requires libMagick.so.10()(64bit) vips-tools-7.14.1-1.fc9.x86_64 requires libWand.so.10()(64bit) xastir-1.9.2-4.fc9.x86_64 requires libMagick.so.10()(64bit) xastir-1.9.2-4.fc9.x86_64 requires libWand.so.10()(64bit) xulrunner-1.9-0.60.cvs20080414.fc10.i386 requires libhunspell.so.1 xulrunner-1.9-0.60.cvs20080414.fc10.x86_64 requires libhunspell.so.1()(64bit) Broken deps for ppc ---------------------------------------------------------- FlightGear-1.0.0-2.fc9.ppc requires libplibssgaux.so.1.8.4 FlightGear-1.0.0-2.fc9.ppc requires libplibfnt.so.1.8.4 FlightGear-1.0.0-2.fc9.ppc requires libplibssg.so.1.8.4 FlightGear-1.0.0-2.fc9.ppc requires libplibpuaux.so.1.8.4 FlightGear-1.0.0-2.fc9.ppc requires libplibpu.so.1.8.4 FlightGear-1.0.0-2.fc9.ppc requires libplibjs.so.1.8.4 FlightGear-1.0.0-2.fc9.ppc requires libplibnet.so.1.8.4 FlightGear-1.0.0-2.fc9.ppc requires libplibsg.so.1.8.4 FlightGear-1.0.0-2.fc9.ppc requires libplibul.so.1.8.4 LabPlot-1.5.1.6-4.fc8.ppc requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.ppc requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.ppc requires libMagick.so.10 SimGear-1.0.0-3.fc9.ppc requires libplibul.so.1.8.4 SimGear-1.0.0-3.fc9.ppc requires libplibssg.so.1.8.4 SimGear-1.0.0-3.fc9.ppc requires libplibnet.so.1.8.4 SimGear-1.0.0-3.fc9.ppc requires libplibsg.so.1.8.4 SimGear-1.0.0-3.fc9.ppc64 requires libplibul.so.1.8.4()(64bit) SimGear-1.0.0-3.fc9.ppc64 requires libplibnet.so.1.8.4()(64bit) SimGear-1.0.0-3.fc9.ppc64 requires libplibsg.so.1.8.4()(64bit) SimGear-1.0.0-3.fc9.ppc64 requires libplibssg.so.1.8.4()(64bit) autotrace-0.31.1-16.fc9.ppc requires libWand.so.10 autotrace-0.31.1-16.fc9.ppc requires libMagick.so.10 autotrace-0.31.1-16.fc9.ppc64 requires libWand.so.10()(64bit) autotrace-0.31.1-16.fc9.ppc64 requires libMagick.so.10()(64bit) brasero-0.7.1-3.fc9.ppc requires libtotem-plparser.so.10 1:bug-buddy-2.22.0-2.fc9.ppc requires libedataserver-1.2.so.9 1:bug-buddy-2.22.0-2.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) cheese-2.23.1-1.fc10.ppc requires libedataserver-1.2.so.9 contact-lookup-applet-0.16-5.fc9.ppc requires libedataserver-1.2.so.9 contacts-0.8-3.fc9.ppc requires libedataserver-1.2.so.9 1:control-center-2.23.1-2.fc10.ppc requires libedataserver-1.2.so.9 1:control-center-2.23.1-2.fc10.ppc requires libgnomekbdui.so.2 1:control-center-2.23.1-2.fc10.ppc requires libgnomekbd.so.2 1:control-center-2.23.1-2.fc10.ppc64 requires libgnomekbd.so.2()(64bit) 1:control-center-2.23.1-2.fc10.ppc64 requires libgnomekbdui.so.2()(64bit) 1:control-center-2.23.1-2.fc10.ppc64 requires libedataserver-1.2.so.9()(64bit) dap-netcdf_handler-3.7.8-3.fc9.ppc64 requires libnetcdf.so.4()(64bit) dates-0.4.5-2.fc9.ppc requires libedataserver-1.2.so.9 drawtiming-0.6.2-3.fc9.ppc requires libMagick++.so.10 drawtiming-0.6.2-3.fc9.ppc requires libWand.so.10 drawtiming-0.6.2-3.fc9.ppc requires libMagick.so.10 dx-4.4.4-6.fc9.ppc requires libWand.so.10 dx-4.4.4-6.fc9.ppc requires libMagick.so.10 dx-libs-4.4.4-6.fc9.ppc requires libWand.so.10 dx-libs-4.4.4-6.fc9.ppc requires libMagick.so.10 dx-libs-4.4.4-6.fc9.ppc64 requires libnetcdf.so.4()(64bit) dx-libs-4.4.4-6.fc9.ppc64 requires libMagick.so.10()(64bit) dx-libs-4.4.4-6.fc9.ppc64 requires libWand.so.10()(64bit) empathy-0.23.1-2.fc10.ppc requires libedataserver-1.2.so.9 empathy-libs-0.23.1-2.fc10.ppc requires libedataserver-1.2.so.9 empathy-libs-0.23.1-2.fc10.ppc64 requires libedataserver-1.2.so.9()(64bit) evolution-brutus-1.2.11-2.fc9.ppc requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.ppc requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.ppc requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-python-0.0.4-3.fc9.ppc requires libedataserver-1.2.so.9 evolution-sharp-0.16.0-1.fc9.ppc requires libedataserver-1.2.so.9 evolution-webcal-2.21.92-1.fc9.ppc requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.ppc requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-1.2.so.11 fgfs-Atlas-0.3.1-8.fc9.ppc requires libplibul.so.1.8.4 fgfs-Atlas-0.3.1-8.fc9.ppc requires libplibfnt.so.1.8.4 fgfs-Atlas-0.3.1-8.fc9.ppc requires libplibpu.so.1.8.4 fgfs-Atlas-0.3.1-8.fc9.ppc requires libplibnet.so.1.8.4 fgfs-Atlas-0.3.1-8.fc9.ppc requires libplibsg.so.1.8.4 gdal-1.5.1-5.fc9.ppc64 requires libhdf5.so.5()(64bit) gdal-1.5.1-5.fc9.ppc64 requires libnetcdf.so.4()(64bit) gdl-0.9-0.rc1.1.fc9.ppc requires libMagick++.so.10 glabels-2.2.2-1.fc9.ppc requires libedataserver-1.2.so.9 1:gnome-applets-2.22.1-3.fc10.ppc requires libgnomekbdui.so.2 1:gnome-applets-2.22.1-3.fc10.ppc requires libgnomekbd.so.2 gnome-launch-box-0.4-8.fc9.ppc requires libedataserver-1.2.so.9 gnome-panel-2.23.1-1.fc10.ppc requires libedataserver-1.2.so.9 gnome-phone-manager-0.51-1.fc9.ppc requires libedataserver-1.2.so.9 gnome-python2-evolution-2.22.0-2.fc9.ppc requires libedataserver-1.2.so.9 gnome-python2-totem-2.22.0-2.fc9.ppc requires libtotem-plparser.so.10 gnome-screensaver-2.22.1-1.fc9.ppc requires libgnomekbdui.so.2 gnome-screensaver-2.22.1-1.fc9.ppc requires libgnomekbd.so.2 gnome-settings-daemon-2.23.1.1-4.fc10.ppc requires libgnomekbd.so.2 gossip-0.29-1.fc10.ppc requires libedataserver-1.2.so.9 imageinfo-0.05-3.fc9.ppc requires libWand.so.10 imageinfo-0.05-3.fc9.ppc requires libMagick.so.10 k3d-0.6.7.0-6.fc9.ppc requires libMagick++.so.10 k3d-0.6.7.0-6.fc9.ppc requires libMagick.so.10 k3d-0.6.7.0-6.fc9.ppc requires libWand.so.10 k3d-0.6.7.0-6.fc9.ppc64 requires libMagick.so.10()(64bit) k3d-0.6.7.0-6.fc9.ppc64 requires libWand.so.10()(64bit) k3d-0.6.7.0-6.fc9.ppc64 requires libMagick++.so.10()(64bit) kismet-extras-0.0.2007.10.R1-3.fc9.ppc requires libMagick.so.10 koffice-karbon-1.6.3-15.fc9.ppc requires libWand.so.10 koffice-karbon-1.6.3-15.fc9.ppc requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.ppc requires libWand.so.10 koffice-libs-1.6.3-15.fc9.ppc requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) libfprint-0.0.5-3.fc9.ppc requires libWand.so.10 libfprint-0.0.5-3.fc9.ppc requires libMagick.so.10 libfprint-0.0.5-3.fc9.ppc64 requires libWand.so.10()(64bit) libfprint-0.0.5-3.fc9.ppc64 requires libMagick.so.10()(64bit) libopensync-plugin-evolution2-0.35-3.fc9.ppc requires libedataserver-1.2.so.9 nautilus-sendto-0.14.0-1.fc9.ppc requires libedataserver-1.2.so.9 nip2-7.14.1-1.fc9.ppc requires libWand.so.10 nip2-7.14.1-1.fc9.ppc requires libMagick.so.10 6:octave-3.0.1-1.fc10.ppc64 requires libhdf5.so.5()(64bit) 1:openoffice.org-core-2.4.0-12.8.fc9.ppc requires libhunspell.so.1 oxine-0.7.0-2.fc9.ppc requires libWand.so.10 oxine-0.7.0-2.fc9.ppc requires libMagick.so.10 paraview-3.2.1-6.fc9.ppc64 requires libhdf5.so.5()(64bit) paraview-mpi-3.2.1-6.fc9.ppc64 requires libhdf5.so.5()(64bit) perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) php-magickwand-1.0.7-1.fc10.ppc requires libWand.so.10 php-magickwand-1.0.7-1.fc10.ppc requires libMagick.so.10 pidgin-2.4.1-2.fc9.ppc requires libedataserver-1.2.so.9 planner-eds-0.14.3-1.fc10.ppc requires libcamel-provider-1.2.so.11 planner-eds-0.14.3-1.fc10.ppc requires libedataserver-1.2.so.9 planner-eds-0.14.3-1.fc10.ppc requires libcamel-1.2.so.11 psiconv-0.9.8-1.fc8.ppc requires libWand.so.10 psiconv-0.9.8-1.fc8.ppc requires libMagick.so.10 psiconv-0.9.8-1.fc8.ppc64 requires libWand.so.10()(64bit) psiconv-0.9.8-1.fc8.ppc64 requires libMagick.so.10()(64bit) pstoedit-3.45-2.fc9.ppc requires libMagick++.so.10 pstoedit-3.45-2.fc9.ppc requires libWand.so.10 pstoedit-3.45-2.fc9.ppc requires libMagick.so.10 pstoedit-3.45-2.fc9.ppc64 requires libMagick++.so.10()(64bit) pstoedit-3.45-2.fc9.ppc64 requires libMagick.so.10()(64bit) pstoedit-3.45-2.fc9.ppc64 requires libWand.so.10()(64bit) q-7.10-3.fc9.ppc requires libMagick.so.10 q-7.10-3.fc9.ppc64 requires libMagick.so.10()(64bit) qgis-0.9.1-5.fc9.ppc requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.ppc requires libgeos.so.2 rhythmbox-0.11.5-9.fc9.ppc requires libtotem-plparser.so.10 rhythmbox-0.11.5-9.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) stormbaancoureur-2.1.2-1.fc9.ppc requires libplibssgaux.so.1.8.4 stormbaancoureur-2.1.2-1.fc9.ppc requires libplibssg.so.1.8.4 stormbaancoureur-2.1.2-1.fc9.ppc requires libplibpu.so.1.8.4 stormbaancoureur-2.1.2-1.fc9.ppc requires libplibfnt.so.1.8.4 stormbaancoureur-2.1.2-1.fc9.ppc requires libplibsg.so.1.8.4 stormbaancoureur-2.1.2-1.fc9.ppc requires libplibul.so.1.8.4 sunbird-0.8-3.fc9.ppc requires libhunspell.so.1 supertuxkart-0.4-1.fc9.ppc requires libplibssgaux.so.1.8.4 supertuxkart-0.4-1.fc9.ppc requires libplibsg.so.1.8.4 supertuxkart-0.4-1.fc9.ppc requires libplibjs.so.1.8.4 supertuxkart-0.4-1.fc9.ppc requires libplibssg.so.1.8.4 supertuxkart-0.4-1.fc9.ppc requires libplibpu.so.1.8.4 supertuxkart-0.4-1.fc9.ppc requires libplibfnt.so.1.8.4 supertuxkart-0.4-1.fc9.ppc requires libplibsl.so.1.8.4 supertuxkart-0.4-1.fc9.ppc requires libplibul.so.1.8.4 syncevolution-0.7-2.fc9.ppc requires libedataserver-1.2.so.9 tasks-0.12-2.fc9.ppc requires libedataserver-1.2.so.9 theora-tools-1.0beta3-1.fc10.ppc requires libtheoraenc.so.1(libtheoraenc_1.0) theora-tools-1.0beta3-1.fc10.ppc requires libtheoraenc.so.1 thunderbird-lightning-0.8-3.fc9.ppc requires libhunspell.so.1 2:tog-pegasus-2.7.0-6.fc9.ppc requires SysVinit 2:tog-pegasus-2.7.0-6.fc9.ppc requires SysVinit 2:tog-pegasus-2.7.0-6.fc9.ppc64 requires SysVinit 2:tog-pegasus-2.7.0-6.fc9.ppc64 requires SysVinit torcs-1.3.0-6.fc9.ppc requires libplibssgaux.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibssg.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibsl.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibsm.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibsg.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibul.so.1.8.4 totem-2.23.2-2.fc9.ppc requires libtotem-plparser.so.10 totem-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.ppc requires libtotem-plparser-mini.so.10 totem-mozplugin-2.23.2-2.fc9.ppc requires libtotem-plparser.so.10 totem-nautilus-2.23.2-2.fc9.ppc requires libtotem-plparser.so.10 totem-pl-parser-2.23.1-1.fc10.ppc requires libedataserver-1.2.so.9 totem-pl-parser-2.23.1-1.fc10.ppc64 requires libedataserver-1.2.so.9()(64bit) vips-7.14.1-1.fc9.ppc requires libWand.so.10 vips-7.14.1-1.fc9.ppc requires libMagick.so.10 vips-7.14.1-1.fc9.ppc64 requires libMagick.so.10()(64bit) vips-7.14.1-1.fc9.ppc64 requires libWand.so.10()(64bit) vips-python-7.14.1-1.fc9.ppc requires libWand.so.10 vips-python-7.14.1-1.fc9.ppc requires libMagick.so.10 vips-tools-7.14.1-1.fc9.ppc requires libWand.so.10 vips-tools-7.14.1-1.fc9.ppc requires libMagick.so.10 xastir-1.9.2-4.fc9.ppc requires libWand.so.10 xastir-1.9.2-4.fc9.ppc requires libMagick.so.10 xulrunner-1.9-0.60.cvs20080414.fc10.ppc requires libhunspell.so.1 xulrunner-1.9-0.60.cvs20080414.fc10.ppc64 requires libhunspell.so.1()(64bit) Broken deps for ppc64 ---------------------------------------------------------- FlightGear-1.0.0-2.fc9.ppc64 requires libplibul.so.1.8.4()(64bit) FlightGear-1.0.0-2.fc9.ppc64 requires libplibssgaux.so.1.8.4()(64bit) FlightGear-1.0.0-2.fc9.ppc64 requires libplibnet.so.1.8.4()(64bit) FlightGear-1.0.0-2.fc9.ppc64 requires libplibjs.so.1.8.4()(64bit) FlightGear-1.0.0-2.fc9.ppc64 requires libplibsg.so.1.8.4()(64bit) FlightGear-1.0.0-2.fc9.ppc64 requires libplibpuaux.so.1.8.4()(64bit) FlightGear-1.0.0-2.fc9.ppc64 requires libplibpu.so.1.8.4()(64bit) FlightGear-1.0.0-2.fc9.ppc64 requires libplibssg.so.1.8.4()(64bit) FlightGear-1.0.0-2.fc9.ppc64 requires libplibfnt.so.1.8.4()(64bit) R-hdf5-1.6.6-4.fc9.ppc64 requires libhdf5.so.5()(64bit) ScientificPython-2.6-12.fc9.ppc64 requires libnetcdf.so.4()(64bit) SimGear-1.0.0-3.fc9.ppc64 requires libplibul.so.1.8.4()(64bit) SimGear-1.0.0-3.fc9.ppc64 requires libplibnet.so.1.8.4()(64bit) SimGear-1.0.0-3.fc9.ppc64 requires libplibsg.so.1.8.4()(64bit) SimGear-1.0.0-3.fc9.ppc64 requires libplibssg.so.1.8.4()(64bit) autotrace-0.31.1-16.fc9.ppc64 requires libWand.so.10()(64bit) autotrace-0.31.1-16.fc9.ppc64 requires libMagick.so.10()(64bit) brasero-0.7.1-3.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) 1:bug-buddy-2.22.0-2.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) cdo-1.0.8-2.fc9.ppc64 requires libnetcdf.so.4()(64bit) cheese-2.23.1-1.fc10.ppc64 requires libedataserver-1.2.so.9()(64bit) contact-lookup-applet-0.16-5.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) contacts-0.8-3.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) 1:control-center-2.23.1-2.fc10.ppc64 requires libgnomekbd.so.2()(64bit) 1:control-center-2.23.1-2.fc10.ppc64 requires libgnomekbdui.so.2()(64bit) 1:control-center-2.23.1-2.fc10.ppc64 requires libedataserver-1.2.so.9()(64bit) dap-netcdf_handler-3.7.8-3.fc9.ppc64 requires libnetcdf.so.4()(64bit) dates-0.4.5-2.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) drawtiming-0.6.2-3.fc9.ppc64 requires libWand.so.10()(64bit) drawtiming-0.6.2-3.fc9.ppc64 requires libMagick++.so.10()(64bit) drawtiming-0.6.2-3.fc9.ppc64 requires libMagick.so.10()(64bit) dx-4.4.4-6.fc9.ppc64 requires libnetcdf.so.4()(64bit) dx-4.4.4-6.fc9.ppc64 requires libMagick.so.10()(64bit) dx-4.4.4-6.fc9.ppc64 requires libWand.so.10()(64bit) dx-libs-4.4.4-6.fc9.ppc64 requires libnetcdf.so.4()(64bit) dx-libs-4.4.4-6.fc9.ppc64 requires libMagick.so.10()(64bit) dx-libs-4.4.4-6.fc9.ppc64 requires libWand.so.10()(64bit) empathy-0.23.1-2.fc10.ppc64 requires libedataserver-1.2.so.9()(64bit) empathy-libs-0.23.1-2.fc10.ppc64 requires libedataserver-1.2.so.9()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-python-0.0.4-3.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) evolution-webcal-2.21.92-1.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) fgfs-Atlas-0.3.1-8.fc9.ppc64 requires libplibul.so.1.8.4()(64bit) fgfs-Atlas-0.3.1-8.fc9.ppc64 requires libplibnet.so.1.8.4()(64bit) fgfs-Atlas-0.3.1-8.fc9.ppc64 requires libplibsg.so.1.8.4()(64bit) fgfs-Atlas-0.3.1-8.fc9.ppc64 requires libplibpu.so.1.8.4()(64bit) fgfs-Atlas-0.3.1-8.fc9.ppc64 requires libplibfnt.so.1.8.4()(64bit) gdal-1.5.1-5.fc9.ppc64 requires libhdf5.so.5()(64bit) gdal-1.5.1-5.fc9.ppc64 requires libnetcdf.so.4()(64bit) gdl-0.9-0.rc1.1.fc9.ppc64 requires libhdf5.so.5()(64bit) gdl-0.9-0.rc1.1.fc9.ppc64 requires libMagick++.so.10()(64bit) gdl-0.9-0.rc1.1.fc9.ppc64 requires libnetcdf.so.4()(64bit) glabels-2.2.2-1.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) 1:gnome-applets-2.22.1-3.fc10.ppc64 requires libgnomekbd.so.2()(64bit) 1:gnome-applets-2.22.1-3.fc10.ppc64 requires libgnomekbdui.so.2()(64bit) gnome-launch-box-0.4-8.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) gnome-panel-2.23.1-1.fc10.ppc64 requires libedataserver-1.2.so.9()(64bit) gnome-phone-manager-0.51-1.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) gnome-python2-evolution-2.22.0-2.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) gnome-python2-totem-2.22.0-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) gnome-screensaver-2.22.1-1.fc9.ppc64 requires libgnomekbd.so.2()(64bit) gnome-screensaver-2.22.1-1.fc9.ppc64 requires libgnomekbdui.so.2()(64bit) gnome-settings-daemon-2.23.1.1-4.fc10.ppc64 requires libgnomekbd.so.2()(64bit) gossip-0.29-1.fc10.ppc64 requires libedataserver-1.2.so.9()(64bit) grace-5.1.21-9.fc9.ppc64 requires libnetcdf.so.4()(64bit) grads-1.9b4-23.fc9.ppc64 requires libnetcdf.so.4()(64bit) imageinfo-0.05-3.fc9.ppc64 requires libWand.so.10()(64bit) imageinfo-0.05-3.fc9.ppc64 requires libMagick.so.10()(64bit) k3d-0.6.7.0-6.fc9.ppc64 requires libMagick.so.10()(64bit) k3d-0.6.7.0-6.fc9.ppc64 requires libWand.so.10()(64bit) k3d-0.6.7.0-6.fc9.ppc64 requires libMagick++.so.10()(64bit) kismet-extras-0.0.2007.10.R1-3.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) kst-netcdf-1.6.0-2.fc10.ppc64 requires libnetcdf_c++.so.4()(64bit) kst-netcdf-1.6.0-2.fc10.ppc64 requires libnetcdf.so.4()(64bit) libfprint-0.0.5-3.fc9.ppc64 requires libWand.so.10()(64bit) libfprint-0.0.5-3.fc9.ppc64 requires libMagick.so.10()(64bit) libopensync-plugin-evolution2-0.35-3.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot nautilus-sendto-0.14.0-1.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) ncview-1.92e-13.fc9.ppc64 requires libnetcdf.so.4()(64bit) netcdf-decoders-5.0.0-1.fc9.ppc64 requires libnetcdf.so.4()(64bit) netcdf-perl-1.2.3-7.fc9.ppc64 requires libnetcdf.so.4()(64bit) nip2-7.14.1-1.fc9.ppc64 requires libMagick.so.10()(64bit) nip2-7.14.1-1.fc9.ppc64 requires libWand.so.10()(64bit) 6:octave-3.0.1-1.fc10.ppc64 requires libhdf5.so.5()(64bit) 6:octave-devel-3.0.1-1.fc10.ppc64 requires hdf5-devel octave-forge-20080429-6.fc10.ppc64 requires libhdf5.so.5()(64bit) 1:openoffice.org-core-2.4.0-12.8.fc9.ppc64 requires libhunspell.so.1()(64bit) oxine-0.7.0-2.fc9.ppc64 requires libMagick.so.10()(64bit) oxine-0.7.0-2.fc9.ppc64 requires libWand.so.10()(64bit) paraview-3.2.1-6.fc9.ppc64 requires libhdf5.so.5()(64bit) paraview-mpi-3.2.1-6.fc9.ppc64 requires libhdf5.so.5()(64bit) perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 php-magickwand-1.0.7-1.fc10.ppc64 requires libWand.so.10()(64bit) php-magickwand-1.0.7-1.fc10.ppc64 requires libMagick.so.10()(64bit) pidgin-2.4.1-2.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) planner-eds-0.14.3-1.fc10.ppc64 requires libcamel-provider-1.2.so.11()(64bit) planner-eds-0.14.3-1.fc10.ppc64 requires libcamel-1.2.so.11()(64bit) planner-eds-0.14.3-1.fc10.ppc64 requires libedataserver-1.2.so.9()(64bit) ppc64-utils-0.14-2.fc9.ppc64 requires yaboot psiconv-0.9.8-1.fc8.ppc64 requires libWand.so.10()(64bit) psiconv-0.9.8-1.fc8.ppc64 requires libMagick.so.10()(64bit) pstoedit-3.45-2.fc9.ppc64 requires libMagick++.so.10()(64bit) pstoedit-3.45-2.fc9.ppc64 requires libMagick.so.10()(64bit) pstoedit-3.45-2.fc9.ppc64 requires libWand.so.10()(64bit) q-7.10-3.fc9.ppc64 requires libMagick.so.10()(64bit) qgis-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) rhythmbox-0.11.5-9.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) scrip-1.4-9.fc8.ppc64 requires libnetcdf.so.4()(64bit) scrip-1.4-9.fc8.ppc64 requires libnetcdff.so.4()(64bit) stormbaancoureur-2.1.2-1.fc9.ppc64 requires libplibul.so.1.8.4()(64bit) stormbaancoureur-2.1.2-1.fc9.ppc64 requires libplibssgaux.so.1.8.4()(64bit) stormbaancoureur-2.1.2-1.fc9.ppc64 requires libplibpu.so.1.8.4()(64bit) stormbaancoureur-2.1.2-1.fc9.ppc64 requires libplibsg.so.1.8.4()(64bit) stormbaancoureur-2.1.2-1.fc9.ppc64 requires libplibssg.so.1.8.4()(64bit) stormbaancoureur-2.1.2-1.fc9.ppc64 requires libplibfnt.so.1.8.4()(64bit) sunbird-0.8-3.fc9.ppc64 requires libhunspell.so.1()(64bit) supertuxkart-0.4-1.fc9.ppc64 requires libplibul.so.1.8.4()(64bit) supertuxkart-0.4-1.fc9.ppc64 requires libplibssgaux.so.1.8.4()(64bit) supertuxkart-0.4-1.fc9.ppc64 requires libplibjs.so.1.8.4()(64bit) supertuxkart-0.4-1.fc9.ppc64 requires libplibpu.so.1.8.4()(64bit) supertuxkart-0.4-1.fc9.ppc64 requires libplibsg.so.1.8.4()(64bit) supertuxkart-0.4-1.fc9.ppc64 requires libplibssg.so.1.8.4()(64bit) supertuxkart-0.4-1.fc9.ppc64 requires libplibfnt.so.1.8.4()(64bit) supertuxkart-0.4-1.fc9.ppc64 requires libplibsl.so.1.8.4()(64bit) syncevolution-0.7-2.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) tasks-0.12-2.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) theora-tools-1.0beta3-1.fc10.ppc64 requires libtheoraenc.so.1(libtheoraenc_1.0)(64bit) theora-tools-1.0beta3-1.fc10.ppc64 requires libtheoraenc.so.1()(64bit) thunderbird-lightning-0.8-3.fc9.ppc64 requires libhunspell.so.1()(64bit) 2:tog-pegasus-2.7.0-6.fc9.ppc64 requires SysVinit 2:tog-pegasus-2.7.0-6.fc9.ppc64 requires SysVinit torcs-1.3.0-6.fc9.ppc64 requires libplibsg.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibul.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibsm.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibssgaux.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibssg.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibsl.so.1.8.4()(64bit) totem-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.ppc64 requires libtotem-plparser-mini.so.10()(64bit) totem-nautilus-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) totem-pl-parser-2.23.1-1.fc10.ppc64 requires libedataserver-1.2.so.9()(64bit) vips-7.14.1-1.fc9.ppc64 requires libMagick.so.10()(64bit) vips-7.14.1-1.fc9.ppc64 requires libWand.so.10()(64bit) vips-python-7.14.1-1.fc9.ppc64 requires libMagick.so.10()(64bit) vips-python-7.14.1-1.fc9.ppc64 requires libWand.so.10()(64bit) vips-tools-7.14.1-1.fc9.ppc64 requires libMagick.so.10()(64bit) vips-tools-7.14.1-1.fc9.ppc64 requires libWand.so.10()(64bit) xastir-1.9.2-4.fc9.ppc64 requires libMagick.so.10()(64bit) xastir-1.9.2-4.fc9.ppc64 requires libWand.so.10()(64bit) xulrunner-1.9-0.60.cvs20080414.fc10.ppc64 requires libhunspell.so.1()(64bit) From jkeating at redhat.com Tue May 13 16:24:48 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 13 May 2008 12:24:48 -0400 Subject: ipa-server conflicts with mod_ssl In-Reply-To: <20080513161710.GA9905@redhat.com> References: <1210688369.4575.11.camel@localhost.localdomain> <20080513145137.GA6737@redhat.com> <1210691252.4575.15.camel@localhost.localdomain> <20080513160006.GA9679@redhat.com> <1210694880.3170.45.camel@localhost.localdomain> <20080513161710.GA9905@redhat.com> Message-ID: <1210695888.3170.49.camel@localhost.localdomain> On Tue, 2008-05-13 at 17:17 +0100, Joe Orton wrote: > > So when can I block mod_ssl? > > Well technically never, since it's a subpackage of httpd not a source > package, but, the answer is: when mod_nss is supported upstream at the > ASF, rather than being based on a fork of an old copy of mod_ssl. This is what I love about Fedora. Our own initiatives can't be agreed upon by our own developers. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jorton at redhat.com Tue May 13 16:44:48 2008 From: jorton at redhat.com (Joe Orton) Date: Tue, 13 May 2008 17:44:48 +0100 Subject: ipa-server conflicts with mod_ssl In-Reply-To: <1210695888.3170.49.camel@localhost.localdomain> References: <1210688369.4575.11.camel@localhost.localdomain> <20080513145137.GA6737@redhat.com> <1210691252.4575.15.camel@localhost.localdomain> <20080513160006.GA9679@redhat.com> <1210694880.3170.45.camel@localhost.localdomain> <20080513161710.GA9905@redhat.com> <1210695888.3170.49.camel@localhost.localdomain> Message-ID: <20080513164448.GA10608@redhat.com> On Tue, May 13, 2008 at 12:24:48PM -0400, Jesse Keating wrote: > On Tue, 2008-05-13 at 17:17 +0100, Joe Orton wrote: > > > So when can I block mod_ssl? > > > > Well technically never, since it's a subpackage of httpd not a source > > package, but, the answer is: when mod_nss is supported upstream at the > > ASF, rather than being based on a fork of an old copy of mod_ssl. > > This is what I love about Fedora. Our own initiatives can't be agreed > upon by our own developers. I'm not sure that anybody would disagree that the above is the right end-goal; "do work upstream" has always been key to the crypto consolidation project AFAIK. joe From jason.corley at gmail.com Tue May 13 16:56:52 2008 From: jason.corley at gmail.com (Jason Corley) Date: Tue, 13 May 2008 12:56:52 -0400 Subject: Summary of the 2008-04-08 Packaging Committee meeting Message-ID: <3118d8de0805130956i6b9e782dyb7980a1e09025101@mail.gmail.com> > On Tue, 2008-05-13 at 11:21 -0400, Jason Corley wrote: > > Tom "spot" Callaway wrote: > > > The approved JPackage naming exception says that when a technical > > > solution is found to make .jpp tagging obsolete for the purposes of > > > grouping excludes, the exception will vanish. I think we've done that, > > > insults and flames aside. > > > > The portion of that agreement that you are glossing over nicely was > > that the solution needed to be in rpm, not yum, apt, smart, up2date, > > or anywhere else. Plain and simple a yum plugin has zero to do with > > the exception and conditions as understood on the JPackage side. > > Jason > > Given that I wrote the exception, I can rather confidently say that it > doesn't say that. What was agreed to on the JPackage side is what I wrote. Feel free to hop on Red Hat internal IRC and ask fnasser if that was his understanding at the time as well. What you have written in no way changes what we were attempting to get at with the original agreement, regardless of their divergence at this point. > ~spot, who isn't sure why he's arguing with you, as he know no good will > come from it. Productive. If it makes you feel any better I think any and all interaction with you is also downright painful. You're pedantic on issues you care about, flippant for all others. Truth be told I expected exactly this sort of reaction from the person who said: [12:33] jpackage is no more of an upstream than Fedora is. The above quote comes from the Fedora Packaging minutes for those that didn't read them (http://fedoraproject.org/wiki/Packaging/Minutes20080408). I find that position curious given that there is zero debate that the packages in question are derived from JPackage. You appear to think of Fedora as upstream and RHEL as downstream -- or at least that's the impression I've gotten from email, IRC, and other snippets I've read in passing -- yet for an external repository that you have no control over (but which you base a deliverable upon) you change your tune. I think if RHEL used Fedora packages and didn't submit patches and improvements back to the Fedora project you'd have a very different outlook on the problem. "Upstream! Upstream! Upstream!" is a selectively applied mantra I guess. As an illustrative example, let's look at Fedora's tomcat5. It's based upon a package which I wrote and introduced into JPackage (which in turn was based upon the tomcat4 JPackage work done by Henri Gomez, and others). http://koji.fedoraproject.org/koji/buildinfo?buildID=35821 >From 5.5.23-9jpp.4 the following was never submitted back to JPackage (even as a patch sent by email): - Add jasper-eclipse subpackage which is needed for eclipse 3.3. - Inject OSGi manifest into servlet api jar and jsp api jar. >From 5.5.25-2jpp.2 the following was never submitted back to JPackage (even as a patch sent by email): - Fix init script for bz #380921 - Fix tomcat5.conf and spec file for bz #253605 - Fix for bz #426850 - Fix for bz #312561 - Fix init script, per bz #247077 - Fix builds on alpha, per bz #253827 I could go on if you'd like, I have many, many more examples. Jason From halfline at gmail.com Tue May 13 17:07:51 2008 From: halfline at gmail.com (Ray Strode) Date: Tue, 13 May 2008 13:07:51 -0400 Subject: rhgb no more Message-ID: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> Hi guys, One thing you will soon notice in F10 rawhide is that rhgb is no longer around. We've blocked it and plan on replacing it for F10. This is a continuation of our "BetterStartup" feature from a few Fedoras ago (I would post a link but the wiki seems to be down). The replacement for rhgb will be a mixture of two things: 1) Starting gdm as early as possible and fitting it to give boot progress before asking for login. This is somewhat in line with the early-login prototype feature some of you may remember from several fedora releases ago. 2) Hiding boot messages before gdm unless escape key is pressed. For graphics hardware that has drm modesetting, we'll be able to show some sort of pretty graphics, and for everyone else we'll show a very simple text mode progress. Just a heads up, Ray From tcallawa at redhat.com Tue May 13 17:08:50 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 13 May 2008 13:08:50 -0400 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <3118d8de0805130956i6b9e782dyb7980a1e09025101@mail.gmail.com> References: <3118d8de0805130956i6b9e782dyb7980a1e09025101@mail.gmail.com> Message-ID: <1210698530.1920.36.camel@localhost.localdomain> On Tue, 2008-05-13 at 12:56 -0400, Jason Corley wrote: > [12:33] jpackage is no more of an upstream than Fedora is. Yes. JPackage isn't upstream for the Tomcat software, and neither is Fedora. How wonderful it is, when quotes are taken out of context. :) ~spot From cjdahlin at ncsu.edu Tue May 13 17:14:26 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Tue, 13 May 2008 13:14:26 -0400 Subject: JahShaka In-Reply-To: <604aa7910805130823r4832fc57r6a5b701f6d6cfe5b@mail.gmail.com> References: <4827CE9D.5020409@ncsu.edu> <4827F111.1070604@nicubunu.ro> <4827FA91.9060009@cchtml.com> <604aa7910805122036q7657c788o734d2bee29aa99fd@mail.gmail.com> <4829910E.6070108@ncsu.edu> <604aa7910805130823r4832fc57r6a5b701f6d6cfe5b@mail.gmail.com> Message-ID: <4829CC72.3050104@ncsu.edu> Jeff Spaleta wrote: > On Tue, May 13, 2008 at 5:01 AM, Casey Dahlin wrote: > >> Pitivi is nice for little home movies, but it is NOT an industrial strength >> NLE and I think it would do more harm to itself than good if it tried to be. >> It will keep Joe User very happy, but not the prosumer crowd. And trying to >> give Cinelerra to those people is just embarrassing. Its about as stable as >> win98 and kludgey as hell. >> > > If wishes were fishes. Right now.. pitivi what we can ship. And I > plan to beat the drum quite loudly about its potential as a piece of > technology that this project can make use of to produce video by and > for this community. Regardless of the quality of its featureset, it is > what we have. I'm tired of holding my breath waiting for something > else to come along that isn't mired the codec problem. > > If pitivi never "grows up" so what.... nothing says that its interface > can't be forked and features can't be added over what is fundamentally > the only framework we can ship. > > I've known about JahShaka for over a year now, If you can get them to > dig in and switch to a gstreamer framework that does NOT directly > depend on gstreamer-ffmpeg for most if not all of its magic.. more > power to you. > > It's not just about switching to gstreamer. You can end up with an > application that uses gstreamer but still relies on gstreamer-ffmpeg > or other forbidden gstreamer plugins for all the useful features and > STILL not have an application that we can ship. The real problem is > that ffmpeg conglomerates a lot of useful things together, beyond just > the codec stuff that we can't touch. So you reach for ffmpeg through > gstreamer for deinterlace support or best effort raw dv footage > handling and you are back to where you started. It's much more > complicated than just moving to gstreamer. > > I think it's going to be much easier to start from an ffmpeg clean > implementation of a video editor like pitivi and build on it, even if > it ends up being a fork. Because everything else that I have seen > ultimately relies on ffmpeg for important functionality and that > simply has to stop or we can't ship it. > > -jef > > Don't misunderstand me, pitivi is a great little editor that should serve a lot of needs very well, including the ones of this project which you mentioned. Directly adding the necessary features to pitivi would just spoil it. It would lose touch with the fast and easy crowd it serves so well now and feel awkward and cobbled together for the high-end folk. A fork could do well though, although the changes would be very deep. Linux has already seen lots of popularity from places like Disney, and we would do well to feed those kinds of relationships. --CJD From jason.corley at gmail.com Tue May 13 17:21:01 2008 From: jason.corley at gmail.com (Jason Corley) Date: Tue, 13 May 2008 13:21:01 -0400 Subject: Summary of the 2008-04-08 Packaging Committee meeting Message-ID: <3118d8de0805131021k6261696bmdf28d92ce6a2939a@mail.gmail.com> > [12:33] jpackage is no more of an upstream than Fedora is. > > Yes. JPackage isn't upstream for the Tomcat software, and neither is Fedora. We are, however, upstream for your Tomcat RPMS, a distinction you seem incapable of grasping sadly. Patches to Tomcat's code base should clearly go to the ASF. > How wonderful it is, when quotes are taken out of context. :) You mean like how you removed the part of my email where I pointed out PACKAGING bugfixes that were never submitted back to the package authors at JPackage? Jason From jspaleta at gmail.com Tue May 13 17:23:13 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 13 May 2008 09:23:13 -0800 Subject: JahShaka In-Reply-To: <4829CC72.3050104@ncsu.edu> References: <4827CE9D.5020409@ncsu.edu> <4827F111.1070604@nicubunu.ro> <4827FA91.9060009@cchtml.com> <604aa7910805122036q7657c788o734d2bee29aa99fd@mail.gmail.com> <4829910E.6070108@ncsu.edu> <604aa7910805130823r4832fc57r6a5b701f6d6cfe5b@mail.gmail.com> <4829CC72.3050104@ncsu.edu> Message-ID: <604aa7910805131023g11d1c57ame53bb92b66e66251@mail.gmail.com> On Tue, May 13, 2008 at 9:14 AM, Casey Dahlin wrote: > Linux has already seen lots of popularity from places like Disney, and we > would do well to feed those kinds of relationships. I would be more than happy to have a high level discussion with aggressive open source users in the area of video and animation. If you know people that the Fedora Board should be having a conversation with... let me know. This is exactly the community that needs to get involved and contribute a clean solution that we can ship, for their own needs. But if they don't value a fully open solution, and are okay with the fractured nature of a/v due to the patent issues in the space, then its going to be harder to convince them involved and working on the problem we know needs to be solved. -jef From sundaram at fedoraproject.org Tue May 13 17:26:02 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 13 May 2008 22:56:02 +0530 Subject: rhgb no more In-Reply-To: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> Message-ID: <4829CF2A.7070106@fedoraproject.org> Ray Strode wrote: > Hi guys, > > One thing you will soon notice in F10 rawhide is that rhgb is no > longer around. We've blocked it and plan on replacing it for F10. > > This is a continuation of our "BetterStartup" feature from a few > Fedoras ago (I would post a link but the wiki seems to be down) http://fedoraproject.org/wiki/Releases/FeatureBetterStartup Rahul From cjdahlin at ncsu.edu Tue May 13 17:26:17 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Tue, 13 May 2008 13:26:17 -0400 Subject: rhgb no more In-Reply-To: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> Message-ID: <4829CF39.10606@ncsu.edu> Ray Strode wrote: > Hi guys, > > One thing you will soon notice in F10 rawhide is that rhgb is no > longer around. We've blocked it and plan on replacing it for F10. > > This is a continuation of our "BetterStartup" feature from a few > Fedoras ago (I would post a link but the wiki seems to be down). The > replacement for rhgb will be a mixture of two things: > > 1) Starting gdm as early as possible and fitting it to give boot > progress before asking for login. This is somewhat in line with the > early-login prototype feature some of you may remember from several > fedora releases ago. > > 2) Hiding boot messages before gdm unless escape key is pressed. For > graphics hardware that has drm modesetting, we'll be able to show some > sort of pretty graphics, and for everyone else we'll show a very > simple text mode progress. > > Just a heads up, > Ray > > This summer I'll be dedicated fulltime to Upstart. I wouldn't mind contributing quite a bit to the new graphical boot as part of this. I have some rough ideas on how we might visualize the upstart boot process, rather than just displaying a progress bar or little ping-ponger. --CJD From a.badger at gmail.com Tue May 13 17:29:01 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 13 May 2008 10:29:01 -0700 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <3118d8de0805130956i6b9e782dyb7980a1e09025101@mail.gmail.com> References: <3118d8de0805130956i6b9e782dyb7980a1e09025101@mail.gmail.com> Message-ID: <4829CFDD.70202@gmail.com> Jason Corley wrote: > As an illustrative example, let's look at Fedora's tomcat5. It's > based upon a package which I wrote and introduced into JPackage (which > in turn was based upon the tomcat4 JPackage work done by Henri Gomez, > and others). > > http://koji.fedoraproject.org/koji/buildinfo?buildID=35821 > >>From 5.5.23-9jpp.4 the following was never submitted back to JPackage > (even as a patch sent by email): > - Add jasper-eclipse subpackage which is needed for eclipse 3.3. > - Inject OSGi manifest into servlet api jar and jsp api jar. > >>From 5.5.25-2jpp.2 the following was never submitted back to JPackage > (even as a patch sent by email): > - Fix init script for bz #380921 > - Fix tomcat5.conf and spec file for bz #253605 > - Fix for bz #426850 > - Fix for bz #312561 > - Fix init script, per bz #247077 > - Fix builds on alpha, per bz #253827 > Which I think illustrates the point that JPackage isn't the upstream for the tomcat5 package, yes? If you're trying to show that JPackage is an upstream for the tomcat5 package you should be showing that work is being done in JPackage and then backported to our packages if it's necessary to pick up the fix before JPackage releases a new version. -Toshio From tcallawa at redhat.com Tue May 13 17:32:51 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 13 May 2008 13:32:51 -0400 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <3118d8de0805131021k6261696bmdf28d92ce6a2939a@mail.gmail.com> References: <3118d8de0805131021k6261696bmdf28d92ce6a2939a@mail.gmail.com> Message-ID: <1210699971.1920.41.camel@localhost.localdomain> On Tue, 2008-05-13 at 13:21 -0400, Jason Corley wrote: > You mean like how you removed the part of my email where I pointed out > PACKAGING bugfixes that were never submitted back to the package > authors at JPackage? As Toshio points out, this seems to undermine the argument that JPackage is the "upstream" for the Fedora package. It seems far more appropriate to say that the Fedora package is derived from JPackage. I didn't quote your email in whole because: A) You made my point better than I did. (Thanks!) B) I was simply pointing out how far out of context you were taking my quote. Now, I will get out of the mud. Wrestling with pigs and whatnot. ~spot From blc at redhat.com Tue May 13 17:33:31 2008 From: blc at redhat.com (Brendan Conoboy) Date: Tue, 13 May 2008 11:33:31 -0600 Subject: JahShaka In-Reply-To: <604aa7910805131023g11d1c57ame53bb92b66e66251@mail.gmail.com> References: <4827CE9D.5020409@ncsu.edu> <4827F111.1070604@nicubunu.ro> <4827FA91.9060009@cchtml.com> <604aa7910805122036q7657c788o734d2bee29aa99fd@mail.gmail.com> <4829910E.6070108@ncsu.edu> <604aa7910805130823r4832fc57r6a5b701f6d6cfe5b@mail.gmail.com> <4829CC72.3050104@ncsu.edu> <604aa7910805131023g11d1c57ame53bb92b66e66251@mail.gmail.com> Message-ID: <4829D0EB.2070605@redhat.com> Jeff Spaleta wrote: > This is exactly the community that needs to get involved and > contribute a clean solution that we can ship, for their own needs. > But if they don't value a fully open solution, and are okay with the > fractured nature of a/v due to the patent issues in the space, then > its going to be harder to convince them involved and working on the > problem we know needs to be solved. Some of the community members who support Cinelerra CV (IE, not Heroine Virtual) have recently taken an initiative to rewrite Cinelerra using modern widgets. If people in the Fedora community are interested in a ground-up high-end editor, this is a good time to get involved before proprietary decisions are made. The new project is called Lumiera and hosted at lumiera.org. -- Brendan Conoboy / Red Hat, Inc. / blc at redhat.com From a.badger at gmail.com Tue May 13 17:47:48 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 13 May 2008 10:47:48 -0700 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <3118d8de0805131021k6261696bmdf28d92ce6a2939a@mail.gmail.com> References: <3118d8de0805131021k6261696bmdf28d92ce6a2939a@mail.gmail.com> Message-ID: <4829D444.9010707@gmail.com> Jason Corley wrote: >> [12:33] jpackage is no more of an upstream than Fedora is. >> >> Yes. JPackage isn't upstream for the Tomcat software, and neither is Fedora. > > We are, however, upstream for your Tomcat RPMS, a distinction you seem > incapable of grasping sadly. Patches to Tomcat's code base should > clearly go to the ASF. > And why are the jpackage tomcat RPMS upstream for our RPMS? It seems quite plain from the changelog you quoted that they are not. >> How wonderful it is, when quotes are taken out of context. :) > > You mean like how you removed the part of my email where I pointed out > PACKAGING bugfixes that were never submitted back to the package > authors at JPackage? Replied to that email that these logs seem to prove the opposite. There's no Packaging Guidelines or FESCo policies that specify that JPackage is the upstream for Fedora java packages. So there is nothing to separate tomcat from any other package that was submitted to review in Fedora, was packaged for a time, orphaned, and is presently being well maintained by a fedora contributor. If the contributor chooses to watch how other distributions are packaging the software, they can do so. If they don't, they do not have to. JPackage and Fedora are currently both competitors and collaborators. In some ways and some cases JPackage provides packages that Fedora consumes but in other cases and other ways JPackage and Fedora provide packages that have some overlap between them. Some maintainers are involved in both projects and the guidelines at both projects allow the packages to be built for both with little or no change. Other maintainers are involved with Fedora but are utilizing the work done at JPackage to help make better packages -- they would hopefully be feeding that information back to JPackage but there's no policy mandating this (just as we don't have a policy mandating constant dialogue with Mandrake, SuSE, Debian, ATRPMs, etc). Still other maintainers treat their packages as they would any non-java package by maintaining the packaging while upstream maintains the source code (this seems to be the case with present-day tomcat). Does there need to be a stronger connection between Fedora and JPackage with a policy? Something that states that all Fedora java packages must be in JPackage first and be based off of them? The results of this discussion will probably influence that. Once again, though, that's a shift in policy that needs to be decided on by FESCo. The choice to give JPackage a different status than other third-party repositories needs to be made at that level and Packaging Guidelines will then need to be adapted where appropriate. -Toshio From bdwheele at indiana.edu Tue May 13 17:51:06 2008 From: bdwheele at indiana.edu (Brian Wheeler) Date: Tue, 13 May 2008 13:51:06 -0400 Subject: Did preupgrade make it in? In-Reply-To: <1210688609.10395.49.camel@localhost.localdomain> References: <1210688379.8342.10.camel@nibbler.dlib.indiana.edu> <1210688609.10395.49.camel@localhost.localdomain> Message-ID: <1210701066.8342.24.camel@nibbler.dlib.indiana.edu> Well, it worked for a while... It got to "Downloading installer metadata" and then hung. The python backtrace looks like this: No package matched to remove Traceback (most recent call last): File "/usr/share/preupgrade/preupgrade-gtk.py", line 198, in on_assistant_apply self._do_main() File "/usr/share/preupgrade/preupgrade-gtk.py", line 206, in _do_main self.main_preupgrade() File "/usr/share/preupgrade/preupgrade-gtk.py", line 349, in main_preupgrade self.pu.retrieve_treeinfo() File "/usr/lib/python2.5/site-packages/preupgrade/__init__.py", line 390, in retrieve_treeinfo raise PUError, "Cannot find any kernel/initrd section for this arch in treeinfo" preupgrade.PUError: Cannot find any kernel/initrd section for this arch in treeinfo This happened on two machines using preupgrade-0.9.3-2.fc8 looks like I got bit by bug 446244. Brian On Tue, 2008-05-13 at 10:23 -0400, seth vidal wrote: > On Tue, 2008-05-13 at 10:19 -0400, Brian Wheeler wrote: > > I don't see any references in the release notes, and I can't find the > > rpm anywhere... > > > > Thanks > > Brian > > You can get preupgrade-0.9.3-2 from koji. > > It has the Fedora9 final release enabled as an upgrade target: > For Fedora8: > http://koji.fedoraproject.org/koji/buildinfo?buildID=48882 > For Fedora7: > http://koji.fedoraproject.org/koji/buildinfo?buildID=48885 > > -sv > > From wwoods at redhat.com Tue May 13 17:55:58 2008 From: wwoods at redhat.com (Will Woods) Date: Tue, 13 May 2008 13:55:58 -0400 Subject: Did preupgrade make it in? In-Reply-To: <1210701066.8342.24.camel@nibbler.dlib.indiana.edu> References: <1210688379.8342.10.camel@nibbler.dlib.indiana.edu> <1210688609.10395.49.camel@localhost.localdomain> <1210701066.8342.24.camel@nibbler.dlib.indiana.edu> Message-ID: <1210701358.29438.26.camel@metroid.rdu.redhat.com> On Tue, 2008-05-13 at 13:51 -0400, Brian Wheeler wrote: > Well, it worked for a while... It got to "Downloading installer > metadata" and then hung. The python backtrace looks like this: > > No package matched to remove > Traceback (most recent call last): > File "/usr/share/preupgrade/preupgrade-gtk.py", line 198, in on_assistant_apply > self._do_main() > File "/usr/share/preupgrade/preupgrade-gtk.py", line 206, in _do_main > self.main_preupgrade() > File "/usr/share/preupgrade/preupgrade-gtk.py", line 349, in main_preupgrade > self.pu.retrieve_treeinfo() > File "/usr/lib/python2.5/site-packages/preupgrade/__init__.py", line 390, in retrieve_treeinfo > raise PUError, "Cannot find any kernel/initrd section for this arch in treeinfo" > preupgrade.PUError: Cannot find any kernel/initrd section for this arch in treeinfo > > > This happened on two machines using preupgrade-0.9.3-2.fc8 looks like I > got bit by bug 446244. What the heck? What arch is this machine? Is it a xen guest or anything weird? Actually, I'm guessing it got a 0-byte file for treeinfo, and that's why it failed. The mirrors are, not surprisingly, a little busy right now. -w -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3153 bytes Desc: not available URL: From jason.corley at gmail.com Tue May 13 17:56:45 2008 From: jason.corley at gmail.com (Jason Corley) Date: Tue, 13 May 2008 13:56:45 -0400 Subject: Summary of the 2008-04-08 Packaging Committee meeting Message-ID: <3118d8de0805131056h62c29c27j84a468b8200b0e10@mail.gmail.com> > Toshio Kuratomi wrote: > Which I think illustrates the point that JPackage isn't the upstream for the tomcat5 package, yes? > Tom "spot" Callaway wrote: > It seems far more appropriate to say that the Fedora package is derived from JPackage. Perhaps you two can explain to me the difference between what you consider package derivation vs. upstream in the context of packaging... In my mind if you base your package off of the packaging work of others, those others are (or in this instance should be) upstream for the package. Again the Fedora/RHEL analogy seems to fit. It feels like splitting semantic hairs to me but you may have a real distinction which I'd like to hear. If there is debate there that is likely the part I'm not understanding, but then I'm just a pig wallowing in mud so what do I know. Jason From kevin.kofler at chello.at Tue May 13 17:57:31 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 13 May 2008 17:57:31 +0000 (UTC) Subject: rhgb no more References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> Message-ID: Ray Strode gmail.com> writes: > 1) Starting gdm as early as possible and fitting it to give boot > progress before asking for login. This is somewhat in line with the > early-login prototype feature some of you may remember from several > fedora releases ago. Unfortunately, starting up GDM early and adding progress report there isn't going to help even a little bit for us KDM users. :-( Kevin Kofler From bdwheele at indiana.edu Tue May 13 17:58:24 2008 From: bdwheele at indiana.edu (Brian Wheeler) Date: Tue, 13 May 2008 13:58:24 -0400 Subject: Did preupgrade make it in? In-Reply-To: <1210701358.29438.26.camel@metroid.rdu.redhat.com> References: <1210688379.8342.10.camel@nibbler.dlib.indiana.edu> <1210688609.10395.49.camel@localhost.localdomain> <1210701066.8342.24.camel@nibbler.dlib.indiana.edu> <1210701358.29438.26.camel@metroid.rdu.redhat.com> Message-ID: <1210701504.8342.27.camel@nibbler.dlib.indiana.edu> On Tue, 2008-05-13 at 13:55 -0400, Will Woods wrote: > On Tue, 2008-05-13 at 13:51 -0400, Brian Wheeler wrote: > > Well, it worked for a while... It got to "Downloading installer > > metadata" and then hung. The python backtrace looks like this: > > > > No package matched to remove > > Traceback (most recent call last): > > File "/usr/share/preupgrade/preupgrade-gtk.py", line 198, in on_assistant_apply > > self._do_main() > > File "/usr/share/preupgrade/preupgrade-gtk.py", line 206, in _do_main > > self.main_preupgrade() > > File "/usr/share/preupgrade/preupgrade-gtk.py", line 349, in main_preupgrade > > self.pu.retrieve_treeinfo() > > File "/usr/lib/python2.5/site-packages/preupgrade/__init__.py", line 390, in retrieve_treeinfo > > raise PUError, "Cannot find any kernel/initrd section for this arch in treeinfo" > > preupgrade.PUError: Cannot find any kernel/initrd section for this arch in treeinfo > > > > > > This happened on two machines using preupgrade-0.9.3-2.fc8 looks like I > > got bit by bug 446244. > > What the heck? What arch is this machine? Is it a xen guest or anything > weird? > Nope. It was a fresh install of F8, I believe. This also failed on an F8 which was an F7 update. > Actually, I'm guessing it got a 0-byte file for treeinfo, and that's why > it failed. The mirrors are, not surprisingly, a little busy right now. > I did get "no more mirrors to try" once, but this failed differently. There is a patch attached to the bug, but I've not tried it out yet. Brian > -w > -- > 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 Tue May 13 18:02:58 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 13 May 2008 23:32:58 +0530 Subject: rhgb no more In-Reply-To: References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> Message-ID: <4829D7D2.8050904@fedoraproject.org> Kevin Kofler wrote: > Ray Strode gmail.com> writes: >> 1) Starting gdm as early as possible and fitting it to give boot >> progress before asking for login. This is somewhat in line with the >> early-login prototype feature some of you may remember from several >> fedora releases ago. > > Unfortunately, starting up GDM early and adding progress report there isn't > going to help even a little bit for us KDM users. :-( If you want to do the same thing with KDM for the KDE spin, just go ahead and do that. I see nothing to complain about. Rahul From cjdahlin at ncsu.edu Tue May 13 18:07:43 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Tue, 13 May 2008 14:07:43 -0400 Subject: rhgb no more In-Reply-To: References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> Message-ID: <4829D8EF.9050101@ncsu.edu> Kevin Kofler wrote: > Ray Strode gmail.com> writes: > >> 1) Starting gdm as early as possible and fitting it to give boot >> progress before asking for login. This is somewhat in line with the >> early-login prototype feature some of you may remember from several >> fedora releases ago. >> > > Unfortunately, starting up GDM early and adding progress report there isn't > going to help even a little bit for us KDM users. :-( > > Kevin Kofler > > Not sure we're still planning on architecting it that way. GDM has enough on its mind with the fresh rewrite. --CJD From nicolas.mailhot at laposte.net Tue May 13 18:11:12 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 13 May 2008 20:11:12 +0200 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <4829B8D7.7010501@gmail.com> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <1210612643.6285.5.camel@rousalka.okg> <1210613511.12520.46.camel@localhost.localdomain> <1210619487.6844.48.camel@rousalka.okg> <1210621696.12520.62.camel@localhost.localdomain> <1210632587.12173.15.camel@rousalka.okg> <48293492.4020905@gmail.com> <41074.192.54.193.59.1210664862.squirrel@rousalka.dyndns.org> <4829B8D7.7010501@gmail.com> Message-ID: <1210702272.3494.13.camel@rousalka.okg> Le mardi 13 mai 2008 ? 08:50 -0700, Toshio Kuratomi a ?crit : > Nicolas Mailhot wrote: > Not really. The argument seems to be that there's not enough java > packagers to fill both JPackage and Fedora with rpms. But this is no > different than anyone else who says, there's only a few of us who care > about packaging OCaml programs/Lisp programs/vim plugins and there's too > many useful pieces of software written in that language that users want > for us to handle. Make accomodations for us so that users can decide to > make use of this third party repository where upstream/other distros can > help us with the packaging effort. Well, organise yourself and prove this third-party repository value. JPP has nothing to prove. It antedates Fedora. > Either we decide that JPackage is special because it has guidelines for > packaging that we agree with, our java packagers mostly work in that > repository anyway, (to re-emphasise what you've said) "we reuse > extensively the work done [in the JPackage repository]", > and we have a > presence there that allows us to make changes to JPackage guidelines and > policies when there is a need This has always been the case. FLOSS project, contributors decide, some Red Hat/Fedora people are major JPackage contributors. The problem is not there is no presence, or that this presence is ignored, but that this presence is not used at all by the Fedora instances. You'd be hard-pressed to find one message on this subject by the people that want to force this change on the public jpackage list where most of the people needing convincing are. You do have a few messages by Red Hat people who are hard pressed to defend a change they didn't propose or adhere with. > or we stop saying that it should be a goal > that our users can switch out the Fedora stack with the JPackage stack > on any arbitrary update. We can stop saying that that won't magically create alternative packages Fedora side. > What we have now makes no sense: > > 1) JPackage derived packages are supposed to be switchable with Fedora > packages on a per package basis (per the original justifications for the > .jpp exception) > > 2) JPackage derived packages are supposed to be switchable with Fedora > packages on a whole stack basis (per ReasonsForKeepingJPP). > > 3) We could have packages in Fedora that have a counterpart in JPackage > but are not derived from the JPackage package with no rhyme or reason > beyond whether the packager was active in JPackage when they made the > submission. This will cause problems for people attempting to mix > JPackage and Fedora stacks as per #1. Sure it's a danger but is it worse than having to reinvent the wheel twice as a complete fork and separation would lead to? (assuming both branches do not deperish for lack of contributors) > 4) JPackage Guidelines only have a few points of divergence with the > Fedora Guidelines and the stated goal of our java packagers is to make > those divergences disappear. > > 5) The attitude that our users can find a package in JPackage if it's > not in Fedora is detrimental to us. Where ever possible, we don't want > user's to have to *find* packages, we want them to be able to yum > install the package out of the box. Note it has never been the goal to "hoard" packages jpp-side. They can flow Fedora-way as long as Fedora changes are pushed back where non-Fedora packagers may use them and the two repositories do not painfully diverge. -- 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 tcallawa at redhat.com Tue May 13 18:12:55 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 13 May 2008 14:12:55 -0400 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <3118d8de0805131056h62c29c27j84a468b8200b0e10@mail.gmail.com> References: <3118d8de0805131056h62c29c27j84a468b8200b0e10@mail.gmail.com> Message-ID: <1210702375.1920.54.camel@localhost.localdomain> On Tue, 2008-05-13 at 13:56 -0400, Jason Corley wrote: > derivation vs. upstream Derivation: When you start with something and make changes specific to me. The end result is a derived work. In the derived work, the maintainer doesn't look to the original for all improvements, but rather, makes their own changes on top of this state . Upstream: The place where the developers of software live, where they take bugs on their software and publish source code. ~spot From stlwrt at gmail.com Tue May 13 18:15:59 2008 From: stlwrt at gmail.com (Pavel Shevchuk) Date: Tue, 13 May 2008 21:15:59 +0300 Subject: rhgb no more In-Reply-To: <4829D8EF.9050101@ncsu.edu> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> <4829D8EF.9050101@ncsu.edu> Message-ID: I hope you'll leave a gap to allow classic scheme with separate bootsplash and login manager. For E17 i could hook up excuisite+entrance easily On 5/13/08, Casey Dahlin wrote: > Kevin Kofler wrote: > > > Ray Strode gmail.com> writes: > > > > > > > 1) Starting gdm as early as possible and fitting it to give boot > > > progress before asking for login. This is somewhat in line with the > > > early-login prototype feature some of you may remember from several > > > fedora releases ago. > > > > > > > > > > Unfortunately, starting up GDM early and adding progress report there > isn't going to help even a little bit for us KDM users. :-( > > > > Kevin Kofler > > > > > > > Not sure we're still planning on architecting it that way. GDM has enough > on its mind with the fresh rewrite. > --CJD > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- http://scwlab.com From nicolas.mailhot at laposte.net Tue May 13 18:17:27 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 13 May 2008 20:17:27 +0200 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <4829D444.9010707@gmail.com> References: <3118d8de0805131021k6261696bmdf28d92ce6a2939a@mail.gmail.com> <4829D444.9010707@gmail.com> Message-ID: <1210702647.3494.20.camel@rousalka.okg> Le mardi 13 mai 2008 ? 10:47 -0700, Toshio Kuratomi a ?crit : > > And why are the jpackage tomcat RPMS upstream for our RPMS? It seems > quite plain from the changelog you quoted that they are not. So the kernel packages are not downstreamed from kernel.org? They have a lot more fedora-specific patches. The fedora packages are rebased every once in a while. That's why it's an upstream/downstream thing. The parts which are shared and reused are bigger than the parts Fedora-specific (very often because the changes have not been bushed jpp-side) > Does there need to be a stronger connection between Fedora and JPackage > with a policy? Something that states that all Fedora java packages must > be in JPackage first and be based off of them? The results of this > discussion will probably influence that. Note that has never been a demand. The demand has been to avoid needlessly making the package flow and collaboration harder. -- 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 nicolas.mailhot at laposte.net Tue May 13 18:20:14 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 13 May 2008 20:20:14 +0200 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <1210702375.1920.54.camel@localhost.localdomain> References: <3118d8de0805131056h62c29c27j84a468b8200b0e10@mail.gmail.com> <1210702375.1920.54.camel@localhost.localdomain> Message-ID: <1210702815.3494.23.camel@rousalka.okg> Le mardi 13 mai 2008 ? 14:12 -0400, Tom "spot" Callaway a ?crit : > On Tue, 2008-05-13 at 13:56 -0400, Jason Corley wrote: > > derivation vs. upstream > > Derivation: When you start with something and make changes specific to > me. The end result is a derived work. In the derived work, the > maintainer doesn't look to the original for all improvements, but > rather, makes their own changes on top of this state > . > Upstream: The place where the developers of software live, where they > take bugs on their software and publish source code. A. Derivation: something you take, modify without looking back B. Upstream/downstream: ecosystem where changes flow back and forth and are consolidated upstream. For the packages I know we are not in case A. You may wish it but it is not so. Stop playing with words. -- 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 tcallawa at redhat.com Tue May 13 18:25:22 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 13 May 2008 14:25:22 -0400 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <1210702815.3494.23.camel@rousalka.okg> References: <3118d8de0805131056h62c29c27j84a468b8200b0e10@mail.gmail.com> <1210702375.1920.54.camel@localhost.localdomain> <1210702815.3494.23.camel@rousalka.okg> Message-ID: <1210703122.1920.56.camel@localhost.localdomain> On Tue, 2008-05-13 at 20:20 +0200, Nicolas Mailhot wrote: > A. Derivation: something you take, modify without looking back I would say that the Fedora Java packages fall rather squarely here. Tomcat is a rather good example. ~spot From jason.corley at gmail.com Tue May 13 18:26:07 2008 From: jason.corley at gmail.com (Jason Corley) Date: Tue, 13 May 2008 14:26:07 -0400 Subject: Summary of the 2008-04-08 Packaging Committee meeting Message-ID: <3118d8de0805131126k64d614bbp8c662490202b6335@mail.gmail.com> > Tom "spot" Callaway wrote: > Derivation: When you start with something and make changes specific to > me. The end result is a derived work. In the derived work, the > maintainer doesn't look to the original for all improvements, but > rather, makes their own changes on top of this state I think this is more commonly referred to as a fork in the OSS world. > Upstream: The place where the developers of software live, where they > take bugs on their software and publish source code. Ah, there's the important distinction, an upstream can only be publishers of source code in your world view. Good to know. Jason From mike at cchtml.com Tue May 13 18:25:40 2008 From: mike at cchtml.com (Mike Cronenworth) Date: Tue, 13 May 2008 13:25:40 -0500 Subject: rhgb no more In-Reply-To: References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> <4829D8EF.9050101@ncsu.edu> Message-ID: <4829DD24.6030608@cchtml.com> -------- Original Message -------- Subject: Re: rhgb no more From: Pavel Shevchuk To: Development discussions related to Fedora Date: 05/13/2008 01:15 PM > I hope you'll leave a gap to allow classic scheme with separate > bootsplash and login manager. For E17 i could hook up > excuisite+entrance easily > > Meaning: You *want* a slower booting system? Why? I don't see the removal of rhgb becoming an *enforcement* of gdm. Look at initng for a practical example of different startup procedures. From sundaram at fedoraproject.org Tue May 13 18:27:31 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 13 May 2008 23:57:31 +0530 Subject: rhgb no more In-Reply-To: References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> <4829D8EF.9050101@ncsu.edu> Message-ID: <4829DD93.30204@fedoraproject.org> Pavel Shevchuk wrote: > I hope you'll leave a gap to allow classic scheme with separate > bootsplash and login manager. For E17 i could hook up > excuisite+entrance easily Are you planning on bringing in E17 into the repository. If so, you might want to coordinate with a third party repository which already has all the packages. Maintained CC'ed now. Rahul From a.badger at gmail.com Tue May 13 18:32:23 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 13 May 2008 11:32:23 -0700 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <3118d8de0805131056h62c29c27j84a468b8200b0e10@mail.gmail.com> References: <3118d8de0805131056h62c29c27j84a468b8200b0e10@mail.gmail.com> Message-ID: <4829DEB7.2080403@gmail.com> Jason Corley wrote: >> Toshio Kuratomi wrote: >> Which I think illustrates the point that JPackage isn't the upstream for the tomcat5 package, yes? > >> Tom "spot" Callaway wrote: >> It seems far more appropriate to say that the Fedora package is derived from JPackage. > > Perhaps you two can explain to me the difference between what you > consider package derivation vs. upstream in the context of > packaging... In my mind if you base your package off of the packaging > work of others, those others are (or in this instance should be) > upstream for the package. Again the Fedora/RHEL analogy seems to fit. > It feels like splitting semantic hairs to me but you may have a real > distinction which I'd like to hear. If there is debate there that is > likely the part I'm not understanding, but then I'm just a pig > wallowing in mud so what do I know. If we were talking about source code it would be the difference between having an upstream and having a fork. Even though xorg and XFree86 started with the same code base, one is not the upstream for the other. So in this context, derivation would be if I took a package from JPackage, Mandriva, etc, had it reviewed for Fedora and then proceeded to maintain the package in Fedora, syncing against new upstream releases of the source, fixing bugs reported in the Fedora bugzilla, and generally, considering the package I'm maintaining in Fedora to be independent of the package the original work was based on. Upstream in this context would be when I take a package from an upstream repository and submit it for Fedora review. Changes implemented in the review would be pushed back into the upstream package unless they were truly Fedora-only changes. Once imported and built the normal flow of events for the package would be to wait for changes from the new upstream package release (or aid in making new upstream package releases) and then syncing those to the Fedora package. As packaging bugs were filed with Fedora, the changes could be made locally and pushed to the upstream repository's packages or made in the upstream's packages and then backported to the Fedora package until the next upstream release. So using the term upstream says there's an ongoing relationship between the packages where the Fedora package tracks the changes made in the upstream package. The grey area is when a Fedora package tracks changes in another repository but the packager still thinks of it as an independent work. This happens more often when a bug occurs in source code and the packager looks for patches in other distros/repos that can fix the problem. It could happen in the context we care about here but I don't think it will happen as often. A package maintainer is used to looking for help with source code upstream but doing all the work of packaging themselves -- so a packager who is deriving from JPackage would be more likely to rely on their own resources or by asking fedora-devel list for advice while a packager that is using JPackage as an upstream would look to JPackage's cvs for ideas. -Toshio From stlwrt at gmail.com Tue May 13 18:32:10 2008 From: stlwrt at gmail.com (Pavel Shevchuk) Date: Tue, 13 May 2008 21:32:10 +0300 Subject: rhgb no more In-Reply-To: <4829DD93.30204@fedoraproject.org> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> <4829D8EF.9050101@ncsu.edu> <4829DD93.30204@fedoraproject.org> Message-ID: I already brought most of EFL into F10, and some packages are in F8 and F9 updates. All 3rd-party repos i've seen package cvs snapshots, but i package snapshots to have stable API/ABI On 5/13/08, Rahul Sundaram wrote: > Pavel Shevchuk wrote: > > > I hope you'll leave a gap to allow classic scheme with separate > > bootsplash and login manager. For E17 i could hook up > > excuisite+entrance easily > > > > Are you planning on bringing in E17 into the repository. If so, you might > want to coordinate with a third party repository which already has all the > packages. Maintained CC'ed now. > > Rahul > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- http://scwlab.com From lesmikesell at gmail.com Tue May 13 18:42:50 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 13 May 2008 13:42:50 -0500 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <4829B8D7.7010501@gmail.com> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <1210612643.6285.5.camel@rousalka.okg> <1210613511.12520.46.camel@localhost.localdomain> <1210619487.6844.48.camel@rousalka.okg> <1210621696.12520.62.camel@localhost.localdomain> <1210632587.12173.15.camel@rousalka.okg> <48293492.4020905@gmail.com> <41074.192.54.193.59.1210664862.squirrel@rousalka.dyndns.org> <4829B8D7.7010501@gmail.com> Message-ID: <4829E12A.7060901@gmail.com> Toshio Kuratomi wrote: > > 5) The attitude that our users can find a package in JPackage if it's > not in Fedora is detrimental to us. Where ever possible, we don't want > user's to have to *find* packages, we want them to be able to yum > install the package out of the box. From a user's perspective, the best way to not have to 'find' jpackage packages - or worry about conflicts - would be for the yum configuration for the jpackage repo to be installed out of the box in fedora and have no duplication at all. -- Les Mikesell lesmikesell at gmail.com From lesmikesell at gmail.com Tue May 13 18:48:10 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 13 May 2008 13:48:10 -0500 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <4828D1E1.8000300@fedoraproject.org> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <20080512202246.GA11400@nostromo.devel.redhat.com> <1210623511.10395.17.camel@localhost.localdomain> <20080512203816.GB26850@nostromo.devel.redhat.com> <870180fe0805121505h1eb29c87i6a312b54cd82f49d@mail.gmail.com> <4828D1E1.8000300@fedoraproject.org> Message-ID: <4829E26A.7040701@gmail.com> Rahul Sundaram wrote: > >> So there are a bunch of Java packages that I use that I would like to >> drive into *some* repository where they can get picked up and used by >> others with similar needs. I've been driving towards Fedora so far. >> What's a good long-term solution, then? Should I keep that up, focus >> on JPackage, help figure out how the two are going to cooperate, ...? > > If people need some software in Fedora, they are going to look for it in > the Fedora repository first. Sorry, but that's not always true. I wouldn't. > Since Openjdk/icedtea is in Fedora, more > java programs would build in Fedora now than before. End users shouldn't > have to work through conflicting repositories or care about the language > a software is written in to use it. The way to avoid conflicting repositories is to _not duplicate them with differences_! The more stuff you have that's not quite like jpackage the worse you make this problem. Plus making things different on different platforms that don't have to be. > Changes can and should be shared > with other repositories and upstream software projects however. Just eliminate the reason you need those changes and sharing can just happen. -- Les Mikesell lesmikesell at gmail.com From a.badger at gmail.com Tue May 13 18:49:48 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 13 May 2008 11:49:48 -0700 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <1210702272.3494.13.camel@rousalka.okg> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <1210612643.6285.5.camel@rousalka.okg> <1210613511.12520.46.camel@localhost.localdomain> <1210619487.6844.48.camel@rousalka.okg> <1210621696.12520.62.camel@localhost.localdomain> <1210632587.12173.15.camel@rousalka.okg> <48293492.4020905@gmail.com> <41074.192.54.193.59.1210664862.squirrel@rousalka.dyndns.org> <4829B8D7.7010501@gmail.com> <1210702272.3494.13.camel@rousalka.okg> Message-ID: <4829E2CC.6070805@gmail.com> Nicolas Mailhot wrote: > Le mardi 13 mai 2008 ? 08:50 -0700, Toshio Kuratomi a ?crit : >> Nicolas Mailhot wrote: > >> Not really. The argument seems to be that there's not enough java >> packagers to fill both JPackage and Fedora with rpms. But this is no >> different than anyone else who says, there's only a few of us who care >> about packaging OCaml programs/Lisp programs/vim plugins and there's too >> many useful pieces of software written in that language that users want >> for us to handle. Make accomodations for us so that users can decide to >> make use of this third party repository where upstream/other distros can >> help us with the packaging effort. > > Well, organise yourself and prove this third-party repository value. JPP > has nothing to prove. It antedates Fedora. > >> Either we decide that JPackage is special because it has guidelines for >> packaging that we agree with, our java packagers mostly work in that >> repository anyway, (to re-emphasise what you've said) "we reuse >> extensively the work done [in the JPackage repository]", > >> and we have a >> presence there that allows us to make changes to JPackage guidelines and >> policies when there is a need > > This has always been the case. FLOSS project, contributors decide, some > Red Hat/Fedora people are major JPackage contributors. The problem is > not there is no presence, or that this presence is ignored, but that > this presence is not used at all by the Fedora instances. > > You'd be hard-pressed to find one message on this subject by the people > that want to force this change on the public jpackage list where most of > the people needing convincing are. You do have a few messages by Red Hat > people who are hard pressed to defend a change they didn't propose or > adhere with. > >> or we stop saying that it should be a goal >> that our users can switch out the Fedora stack with the JPackage stack >> on any arbitrary update. > > We can stop saying that that won't magically create alternative packages > Fedora side. > >> What we have now makes no sense: >> >> 1) JPackage derived packages are supposed to be switchable with Fedora >> packages on a per package basis (per the original justifications for the >> .jpp exception) >> >> 2) JPackage derived packages are supposed to be switchable with Fedora >> packages on a whole stack basis (per ReasonsForKeepingJPP). >> >> 3) We could have packages in Fedora that have a counterpart in JPackage >> but are not derived from the JPackage package with no rhyme or reason >> beyond whether the packager was active in JPackage when they made the >> submission. This will cause problems for people attempting to mix >> JPackage and Fedora stacks as per #1. > > Sure it's a danger but is it worse than having to reinvent the wheel > twice as a complete fork and separation would lead to? (assuming both > branches do not deperish for lack of contributors) > >> 4) JPackage Guidelines only have a few points of divergence with the >> Fedora Guidelines and the stated goal of our java packagers is to make >> those divergences disappear. >> >> 5) The attitude that our users can find a package in JPackage if it's >> not in Fedora is detrimental to us. Where ever possible, we don't want >> user's to have to *find* packages, we want them to be able to yum >> install the package out of the box. > > Note it has never been the goal to "hoard" packages jpp-side. They can > flow Fedora-way as long as Fedora changes are pushed back where > non-Fedora packagers may use them and the two repositories do not > painfully diverge. > > Yep. And I'm just saying that divergence is inevitable (as seen by the tomcat package) if we keep going forward in the way we are now. We need to either get closer to JPackage or farther away. We have a choice right now of which way to go. We should think about which direction makes the most sense and form policy that commits us to that. -Toshio "Grape in the middle of the road get squashed" Kuratomi From mrmazda at ij.net Tue May 13 18:50:34 2008 From: mrmazda at ij.net (Felix Miata) Date: Tue, 13 May 2008 14:50:34 -0400 Subject: The Prophecy of the 9 comes true (Fedora 9 walks the earth!) In-Reply-To: <1210687284.3170.30.camel@localhost.localdomain> References: <1210687284.3170.30.camel@localhost.localdomain> Message-ID: <4829E2FA.8050700@ij.net> On 2008/05/13 10:01 (GMT-0400) Jesse Keating apparently typed: > An ancient text prophesised this day would come, detailing the fate of > all who are willing to accept what is offered to them: > http://docs.fedoraproject.org/release-notes/f9/index.html Would be nice if http://docs.fedoraproject.org/release-notes/f9/en_US/sn-Installer.html#sn-scsi-partition-limit was considerably less subtle about the risk of uninstallability in the absence of a new disk or disk wipe to put it on: https://bugzilla.redhat.com/show_bug.cgi?id=430836 -- ". . . . in everything, do to others what you would have them do to you . . . ." Matthew 7:12 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ From a.badger at gmail.com Tue May 13 18:50:30 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 13 May 2008 11:50:30 -0700 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <1210702647.3494.20.camel@rousalka.okg> References: <3118d8de0805131021k6261696bmdf28d92ce6a2939a@mail.gmail.com> <4829D444.9010707@gmail.com> <1210702647.3494.20.camel@rousalka.okg> Message-ID: <4829E2F6.7020207@gmail.com> Nicolas Mailhot wrote: > Le mardi 13 mai 2008 ? 10:47 -0700, Toshio Kuratomi a ?crit : >> >> And why are the jpackage tomcat RPMS upstream for our RPMS? It seems >> quite plain from the changelog you quoted that they are not. > > So the kernel packages are not downstreamed from kernel.org? They have a > lot more fedora-specific patches. > 1) Last I looked, kernel.org didn't release SRPMS. 2) The Fedora Tomcat package does not currently seem to be syncing against JPackage. So JPackage is not the upstream for the tomcat package. The source code in the kernel package, otoh, is being synced against the source code on upstream kernel.org. > The fedora packages are rebased every once in a while. That's why it's > an upstream/downstream thing. The parts which are shared and reused are > bigger than the parts Fedora-specific (very often because the changes > have not been bushed jpp-side) > But that's not the case with the current tomcat package. The current tomcat is a derivation of JPackage because it was started from the JPackage package (by a different maintainer) but is not syncing changes back and forth now. And there's nothing in FESCo policy or Packaging Guidelines that mandate that this must happen. >> Does there need to be a stronger connection between Fedora and JPackage >> with a policy? Something that states that all Fedora java packages must >> be in JPackage first and be based off of them? The results of this >> discussion will probably influence that. > > Note that has never been a demand. The demand has been to avoid > needlessly making the package flow and collaboration harder. > Very true. I'm saying that our current process is falling down. We aren't to the point where we're getting the worst of both worlds (the two worlds being: making packages which are totally separate from JPackage and making packages which are only rebuilds of JPackage [or even just including the JPackage repo]) but we're definitely not getting the best of them. I think we need to swing the pendulum one way or the other. -Toshio From sundaram at redhat.com Tue May 13 18:53:36 2008 From: sundaram at redhat.com (Rahul Sundaram) Date: Wed, 14 May 2008 00:23:36 +0530 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <4829E12A.7060901@gmail.com> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <1210612643.6285.5.camel@rousalka.okg> <1210613511.12520.46.camel@localhost.localdomain> <1210619487.6844.48.camel@rousalka.okg> <1210621696.12520.62.camel@localhost.localdomain> <1210632587.12173.15.camel@rousalka.okg> <48293492.4020905@gmail.com> <41074.192.54.193.59.1210664862.squirrel@rousalka.dyndns.org> <4829B8D7.7010501@gmail.com> <4829E12A.7060901@gmail.com> Message-ID: <4829E3B0.9090108@redhat.com> Les Mikesell wrote: > Toshio Kuratomi wrote: >> >> 5) The attitude that our users can find a package in JPackage if it's >> not in Fedora is detrimental to us. Where ever possible, we don't >> want user's to have to *find* packages, we want them to be able to yum >> install the package out of the box. > > From a user's perspective, the best way to not have to 'find' jpackage > packages - or worry about conflicts - would be for the yum configuration > for the jpackage repo to be installed out of the box in fedora and have > no duplication at all. As indicated earlier, that wouldn't really work either. It would bring in all the problems in separating Fedora Core and Fedora Extras with the additional legal liability of linking to a third party repository. All programs including Openoffice.org which has some Java dependencies would have to moved out of the primary repository into a third party one. Not going to fly. Rahul From a.badger at gmail.com Tue May 13 18:56:44 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 13 May 2008 11:56:44 -0700 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <4829E12A.7060901@gmail.com> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <1210612643.6285.5.camel@rousalka.okg> <1210613511.12520.46.camel@localhost.localdomain> <1210619487.6844.48.camel@rousalka.okg> <1210621696.12520.62.camel@localhost.localdomain> <1210632587.12173.15.camel@rousalka.okg> <48293492.4020905@gmail.com> <41074.192.54.193.59.1210664862.squirrel@rousalka.dyndns.org> <4829B8D7.7010501@gmail.com> <4829E12A.7060901@gmail.com> Message-ID: <4829E46C.9010606@gmail.com> Les Mikesell wrote: > Toshio Kuratomi wrote: >> >> 5) The attitude that our users can find a package in JPackage if it's >> not in Fedora is detrimental to us. Where ever possible, we don't >> want user's to have to *find* packages, we want them to be able to yum >> install the package out of the box. > > From a user's perspective, the best way to not have to 'find' jpackage > packages - or worry about conflicts - would be for the yum configuration > for the jpackage repo to be installed out of the box in fedora and have > no duplication at all. > Excellent! This is exactly what I'm getting at. We either have to swing towards this view of JPackage or the opposite view. The middle path is just going to cause more and more pain as time goes on. -Toshio From nicolas.mailhot at laposte.net Tue May 13 19:15:27 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 13 May 2008 21:15:27 +0200 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <1210703122.1920.56.camel@localhost.localdomain> References: <3118d8de0805131056h62c29c27j84a468b8200b0e10@mail.gmail.com> <1210702375.1920.54.camel@localhost.localdomain> <1210702815.3494.23.camel@rousalka.okg> <1210703122.1920.56.camel@localhost.localdomain> Message-ID: <1210706127.3494.29.camel@rousalka.okg> Le mardi 13 mai 2008 ? 14:25 -0400, Tom "spot" Callaway a ?crit : > On Tue, 2008-05-13 at 20:20 +0200, Nicolas Mailhot wrote: > > A. Derivation: something you take, modify without looking back > > I would say that the Fedora Java packages fall rather squarely here. > Tomcat is a rather good example. If you had bothered to read and understand the meaning of the Xjpp_Yfc convention, and then looked at the versions in http://cvs.fedoraproject.org/viewcvs/devel/tomcat5/tomcat5.spec?rev=1.111&view=log you'd have seen the Fedora log is littered with Fedora<=> jpp resyncs (it's easy look at when the jpp numbering part changes) Tomcat6 was imported from jpp 6 weeks ago. Try again. -- 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 a.badger at gmail.com Tue May 13 19:45:31 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 13 May 2008 12:45:31 -0700 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <1210706127.3494.29.camel@rousalka.okg> References: <3118d8de0805131056h62c29c27j84a468b8200b0e10@mail.gmail.com> <1210702375.1920.54.camel@localhost.localdomain> <1210702815.3494.23.camel@rousalka.okg> <1210703122.1920.56.camel@localhost.localdomain> <1210706127.3494.29.camel@rousalka.okg> Message-ID: <4829EFDB.1080005@gmail.com> Nicolas Mailhot wrote: > Le mardi 13 mai 2008 ? 14:25 -0400, Tom "spot" Callaway a ?crit : >> On Tue, 2008-05-13 at 20:20 +0200, Nicolas Mailhot wrote: >>> A. Derivation: something you take, modify without looking back >> I would say that the Fedora Java packages fall rather squarely here. >> Tomcat is a rather good example. > > If you had bothered to read and understand the meaning of the Xjpp_Yfc > convention, and then looked at the versions in > > http://cvs.fedoraproject.org/viewcvs/devel/tomcat5/tomcat5.spec?rev=1.111&view=log > > you'd have seen the Fedora log is littered with Fedora<=> jpp resyncs > (it's easy look at when the jpp numbering part changes) > Nicolas, I believe you're wrong. I can't find a single revision by devrim that syncs from the JPackage spec[1]_ to the Fedora spec. > Tomcat6 was imported from jpp 6 weeks ago. > Different maintainer, different package, different methodology for maintaining that package. .. _[1]: http://www.jpackage.org/cgi-bin/viewvc.cgi/rpms/free/tomcat5/tomcat5.spec?root=jpackage&view=log -Toshio From lesmikesell at gmail.com Tue May 13 19:48:43 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 13 May 2008 14:48:43 -0500 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <4829E3B0.9090108@redhat.com> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <1210612643.6285.5.camel@rousalka.okg> <1210613511.12520.46.camel@localhost.localdomain> <1210619487.6844.48.camel@rousalka.okg> <1210621696.12520.62.camel@localhost.localdomain> <1210632587.12173.15.camel@rousalka.okg> <48293492.4020905@gmail.com> <41074.192.54.193.59.1210664862.squirrel@rousalka.dyndns.org> <4829B8D7.7010501@gmail.com> <4829E12A.7060901@gmail.com> <4829E3B0.9090108@redhat.com> Message-ID: <4829F09B.5040500@gmail.com> Rahul Sundaram wrote: > Les Mikesell wrote: >> Toshio Kuratomi wrote: >>> >>> 5) The attitude that our users can find a package in JPackage if it's >>> not in Fedora is detrimental to us. Where ever possible, we don't >>> want user's to have to *find* packages, we want them to be able to >>> yum install the package out of the box. >> >> From a user's perspective, the best way to not have to 'find' >> jpackage packages - or worry about conflicts - would be for the yum >> configuration for the jpackage repo to be installed out of the box in >> fedora and have no duplication at all. > > As indicated earlier, that wouldn't really work either. It would bring > in all the problems in separating Fedora Core and Fedora Extras with the > additional legal liability of linking to a third party repository. All > programs including Openoffice.org which has some Java dependencies would > have to moved out of the primary repository into a third party one. Not > going to fly. Then just admit that the duplication causes more harm than good and make the user set up his own yum configuration if pointing to jpackage is a problem for you. Do the same with openoffice if you can't support it without badly duplicating packages with better upstreams. What's the point of making things worse for your users? -- Les Mikesell lesmikesell at gmail.com From lesmikesell at gmail.com Tue May 13 19:54:41 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 13 May 2008 14:54:41 -0500 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <4829E2F6.7020207@gmail.com> References: <3118d8de0805131021k6261696bmdf28d92ce6a2939a@mail.gmail.com> <4829D444.9010707@gmail.com> <1210702647.3494.20.camel@rousalka.okg> <4829E2F6.7020207@gmail.com> Message-ID: <4829F201.3060306@gmail.com> Toshio Kuratomi wrote: > > Very true. I'm saying that our current process is falling down. It fell down at the point where you copied _some_ of the jpackage packages, offering less than the original. How could anyone think that was a good idea, particularly considering that for a long interval there was no jpackage repo support for current versions of fedora? -- Les Mikesell lesmikesell at gmail.com From devrim at CommandPrompt.com Tue May 13 19:55:18 2008 From: devrim at CommandPrompt.com (Devrim =?ISO-8859-1?Q?G=DCND=DCZ?=) Date: Tue, 13 May 2008 22:55:18 +0300 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <4829EFDB.1080005@gmail.com> References: <3118d8de0805131056h62c29c27j84a468b8200b0e10@mail.gmail.com> <1210702375.1920.54.camel@localhost.localdomain> <1210702815.3494.23.camel@rousalka.okg> <1210703122.1920.56.camel@localhost.localdomain> <1210706127.3494.29.camel@rousalka.okg> <4829EFDB.1080005@gmail.com> Message-ID: <1210708518.2658.73.camel@localhost.localdomain> Hi, On Tue, 2008-05-13 at 12:45 -0700, Toshio Kuratomi wrote: > > > Nicolas, I believe you're wrong. I can't find a single revision by > devrim that syncs from the JPackage spec[1]_ to the Fedora spec. Yeah, I did not even see JPackage spec after I began packaging Tomcat5. Regards, -- Devrim G?ND?Z , RHCE PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pemboa at gmail.com Tue May 13 20:02:11 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Tue, 13 May 2008 15:02:11 -0500 Subject: rhgb no more In-Reply-To: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> Message-ID: <16de708d0805131302h791eb159m62941408fe18ec76@mail.gmail.com> On Tue, May 13, 2008 at 12:07 PM, Ray Strode wrote: > Hi guys, > > One thing you will soon notice in F10 rawhide is that rhgb is no > longer around. We've blocked it and plan on replacing it for F10. > > This is a continuation of our "BetterStartup" feature from a few > Fedoras ago (I would post a link but the wiki seems to be down). The > replacement for rhgb will be a mixture of two things: > > 1) Starting gdm as early as possible and fitting it to give boot > progress before asking for login. This is somewhat in line with the > early-login prototype feature some of you may remember from several > fedora releases ago. > > 2) Hiding boot messages before gdm unless escape key is pressed. For > graphics hardware that has drm modesetting, we'll be able to show some > sort of pretty graphics, and for everyone else we'll show a very > simple text mode progress. > > Just a heads up, > Ray How will this interact with non GDM greeters? -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From sundaram at fedoraproject.org Tue May 13 20:03:10 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 14 May 2008 01:33:10 +0530 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <4829F09B.5040500@gmail.com> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <1210612643.6285.5.camel@rousalka.okg> <1210613511.12520.46.camel@localhost.localdomain> <1210619487.6844.48.camel@rousalka.okg> <1210621696.12520.62.camel@localhost.localdomain> <1210632587.12173.15.camel@rousalka.okg> <48293492.4020905@gmail.com> <41074.192.54.193.59.1210664862.squirrel@rousalka.dyndns.org> <4829B8D7.7010501@gmail.com> <4829E12A.7060901@gmail.com> <4829E3B0.9090108@redhat.com> <4829F09B.5040500@gmail.com> Message-ID: <4829F3FE.6070203@fedoraproject.org> Les Mikesell wrote: > > Then just admit that the duplication causes more harm than good and make > the user set up his own yum configuration if pointing to jpackage is a > problem for you. Do the same with openoffice if you can't support it > without badly duplicating packages with better upstreams. What's the > point of making things worse for your users? Repository conflicts have always existed. As long as there is more than one repository that is not perfectly complimentary, that is just a fact of life. We just learn to work with it in a way we can. If that doesn't suit you, do your own thing instead. Good luck. Rahul From nicolas.mailhot at laposte.net Tue May 13 20:06:31 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 13 May 2008 22:06:31 +0200 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <4829EFDB.1080005@gmail.com> References: <3118d8de0805131056h62c29c27j84a468b8200b0e10@mail.gmail.com> <1210702375.1920.54.camel@localhost.localdomain> <1210702815.3494.23.camel@rousalka.okg> <1210703122.1920.56.camel@localhost.localdomain> <1210706127.3494.29.camel@rousalka.okg> <4829EFDB.1080005@gmail.com> Message-ID: <1210709191.3494.36.camel@rousalka.okg> Le mardi 13 mai 2008 ? 12:45 -0700, Toshio Kuratomi a ?crit : > Nicolas, I believe you're wrong. I can't find a single revision by > devrim that syncs from the JPackage spec[1]_ to the Fedora spec. It's difficult to say since devrim took over tomcat fedora-side 5 months ago and the last jpackage package release of tomcat5 was 7 months ago (there are more recent jpp tomcat6 package releases, which have been pushed fedora-side recently). What Jason complains about is that after taking all the jpp changes for a long time, when some problems were identified fedora side jpp was not notified of the fixes (aka downstream patch hoarding). -- 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 a.badger at gmail.com Tue May 13 20:15:53 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 13 May 2008 13:15:53 -0700 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <1210709191.3494.36.camel@rousalka.okg> References: <3118d8de0805131056h62c29c27j84a468b8200b0e10@mail.gmail.com> <1210702375.1920.54.camel@localhost.localdomain> <1210702815.3494.23.camel@rousalka.okg> <1210703122.1920.56.camel@localhost.localdomain> <1210706127.3494.29.camel@rousalka.okg> <4829EFDB.1080005@gmail.com> <1210709191.3494.36.camel@rousalka.okg> Message-ID: <4829F6F9.9050006@gmail.com> Nicolas Mailhot wrote: > Le mardi 13 mai 2008 ? 12:45 -0700, Toshio Kuratomi a ?crit : > >> Nicolas, I believe you're wrong. I can't find a single revision by >> devrim that syncs from the JPackage spec[1]_ to the Fedora spec. > > It's difficult to say since devrim took over tomcat fedora-side 5 months > ago and the last jpackage package release of tomcat5 was 7 months ago > (there are more recent jpp tomcat6 package releases, which have been > pushed fedora-side recently). What Jason complains about is that after > taking all the jpp changes for a long time, when some problems were > identified fedora side jpp was not notified of the fixes (aka downstream > patch hoarding). > Yes, and that is perfectly fine under our current system. Different maintainers can treat the same package as having a JPackage upstream or disregarding it. Even a single maintainer of a single package can change their mind after having maintained in one style for a while. That's why I'm saying our current approach has problems. We aren't committed to following JPackage as upstream and we aren't committed to not following JPackage as upstream. So we will see flip-flopping and we'll eventually see places where a Fedora maintainer wants to diverge from JPackage and it causes issues for other packagers who don't want to diverge from JPackage. -Toshio From jason.corley at gmail.com Tue May 13 20:16:34 2008 From: jason.corley at gmail.com (Jason Corley) Date: Tue, 13 May 2008 16:16:34 -0400 Subject: Summary of the 2008-04-08 Packaging Committee meeting Message-ID: <3118d8de0805131316h55374c5di2b6ad5ed5c4f1b68@mail.gmail.com> > Nicolas, I believe you're wrong. I can't find a single revision by devrim that syncs from the JPackage spec[1]_ to the Fedora spec. Yes if you focus only on the current maintainer's history of collaboration with JPackage you won't find any. However the following shows what used to happen: http://cvs.fedoraproject.org/viewcvs/devel/tomcat5/tomcat5.spec?rev=1.97&view=markup "Import and merge 0:5.5.23-9jpp from JPP." http://cvs.fedoraproject.org/viewcvs/devel/tomcat5/tomcat5.spec?rev=1.95&view=markup "Merge with latest from JPP" http://cvs.fedoraproject.org/viewcvs/devel/tomcat5/tomcat5.spec?rev=1.94&view=markup "Merge with upstream" http://cvs.fedoraproject.org/viewcvs/devel/tomcat5/tomcat5.spec?rev=1.91&view=markup "Merge with upstream" There are many more where I know a merge occurred that wasn't explicitly stated because I worked with Fernando, Vivek, etc. to make the change happen (one example is the jump from 5.0.x to 5.5.x that occurred between revisions 1.58 and 1.59). On the JPackage side here is an example of getting those updates from Fedora back into JPackage to benefit a wider audience: http://www.jpackage.org/cgi-bin/viewvc.cgi/rpms/free/tomcat5/tomcat5.spec?revision=1.3.2.24&root=jpackage&view=markup&pathrev=r5_5_25-1jpp "bug 276: broken admin webapp (Vivek Lakshmanan)" Granted I probably could have phrased that in a more explicit manner, I just didn't know back then I'd be having this discussion. Jason From a.badger at gmail.com Tue May 13 20:20:14 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 13 May 2008 13:20:14 -0700 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <1210709191.3494.36.camel@rousalka.okg> References: <3118d8de0805131056h62c29c27j84a468b8200b0e10@mail.gmail.com> <1210702375.1920.54.camel@localhost.localdomain> <1210702815.3494.23.camel@rousalka.okg> <1210703122.1920.56.camel@localhost.localdomain> <1210706127.3494.29.camel@rousalka.okg> <4829EFDB.1080005@gmail.com> <1210709191.3494.36.camel@rousalka.okg> Message-ID: <4829F7FE.2060101@gmail.com> Nicolas Mailhot wrote: > What Jason complains about is that after > taking all the jpp changes for a long time, when some problems were > identified fedora side jpp was not notified of the fixes (aka downstream > patch hoarding). > Just one further note, since I didn't make it clear in the last email. It's not downstream patch hoarding if JPackage is not upstream. Since there's no syncing between the packages since devrim took over, I'd be hard pressed to say there is an upstream-downstream relationship between the currently maintained package and the JPackage one. There was a historical relationship but the package went the derived route instead of the upstream-downstream route when the new maintainer took over. -Toshio From jason.corley at gmail.com Tue May 13 20:23:59 2008 From: jason.corley at gmail.com (Jason Corley) Date: Tue, 13 May 2008 16:23:59 -0400 Subject: Summary of the 2008-04-08 Packaging Committee meeting Message-ID: <3118d8de0805131323k28aa5db5jac4f3054a5a1c168@mail.gmail.com> Nicolas Mailhot wrote: > What Jason complains about is that after taking all the jpp changes for a long time, when some problems were > identified fedora side jpp was not notified of the fixes (aka downstream patch hoarding). Exactly! I wish I had worded it that clearly, thanks Nicolas. Jason From a.badger at gmail.com Tue May 13 20:38:51 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 13 May 2008 13:38:51 -0700 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <3118d8de0805131316h55374c5di2b6ad5ed5c4f1b68@mail.gmail.com> References: <3118d8de0805131316h55374c5di2b6ad5ed5c4f1b68@mail.gmail.com> Message-ID: <4829FC5B.5030000@gmail.com> Jason Corley wrote: >> Nicolas, I believe you're wrong. I can't find a single revision by devrim that syncs from the JPackage spec[1]_ to the Fedora spec. > > Yes if you focus only on the current maintainer's history of > collaboration with JPackage you won't find any. However the following > shows what used to happen: > I don't dispute that. But I am saying that a new maintainer took over the package. So there was no history of sharing changes with JPackage there. Continuity doesn't follow the package because there is no policy or guideline that says that java packages have a special relationship with JPackage. the maintainer was just following the best practices that they had established by working on other packages in Fedora. Fedora is a community of packagers. Those packagers have different styles of packaging and working. Where we need to, we unite those styles with Packaging Guidelines and FESCo Policies. Until we have a policy that specifies that certain classes of packages must use JPackage as upstream this kind of thing will happen as packages go through different maintainers. -Toshio From lesmikesell at gmail.com Tue May 13 20:40:42 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 13 May 2008 15:40:42 -0500 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <4829F3FE.6070203@fedoraproject.org> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <1210612643.6285.5.camel@rousalka.okg> <1210613511.12520.46.camel@localhost.localdomain> <1210619487.6844.48.camel@rousalka.okg> <1210621696.12520.62.camel@localhost.localdomain> <1210632587.12173.15.camel@rousalka.okg> <48293492.4020905@gmail.com> <41074.192.54.193.59.1210664862.squirrel@rousalka.dyndns.org> <4829B8D7.7010501@gmail.com> <4829E12A.7060901@gmail.com> <4829E3B0.9090108@redhat.com> <4829F09B.5040500@gmail.com> <4829F3FE.6070203@fedoraproject.org> Message-ID: <4829FCCA.50505@gmail.com> Rahul Sundaram wrote: > Les Mikesell wrote: > >> >> Then just admit that the duplication causes more harm than good and >> make the user set up his own yum configuration if pointing to jpackage >> is a problem for you. Do the same with openoffice if you can't >> support it without badly duplicating packages with better upstreams. >> What's the point of making things worse for your users? > > Repository conflicts have always existed. As long as there is more than > one repository that is not perfectly complimentary, that is just a fact > of life. We just learn to work with it in a way we can. But the way we work around that problem is to not use the one that conflicts. I think you are suggesting not using fedora unless you provide a straightforward exclusion method for the conflicting packages. is that really what you want people to do? > If that doesn't > suit you, do your own thing instead. Good luck. Everyone doing their own thing is the problem here. Encouraging it is absolutely the wrong thing. -- Les Mikesell lesmikesell at gmail.com From dr.diesel at gmail.com Tue May 13 20:41:14 2008 From: dr.diesel at gmail.com (Dr. Diesel) Date: Tue, 13 May 2008 16:41:14 -0400 Subject: Anyone else with hard freezes? In-Reply-To: <2a28d2ab0805130448s2b3e8c8aw5e526bd04949d60a@mail.gmail.com> References: <2a28d2ab0805061455l9afae56p8a86218d08bc4b92@mail.gmail.com> <1210112921.6222.9.camel@optimus> <2a28d2ab0805061530j3a8aa79ehb51d96afedaad644@mail.gmail.com> <1210116098.6222.11.camel@optimus> <2a28d2ab0805081558q3fdb4b94hf41f40db0253f015@mail.gmail.com> <80d7e4090805081625m111b7955v2c96d864275334b2@mail.gmail.com> <2a28d2ab0805081723q6a3537d7n93db59501cf23b16@mail.gmail.com> <2a28d2ab0805090336j78fe2772q1df6283e3c5d38cf@mail.gmail.com> <1210398432.17530.0.camel@optimus> <2a28d2ab0805130448s2b3e8c8aw5e526bd04949d60a@mail.gmail.com> Message-ID: <2a28d2ab0805131341x6d4d6332nd89e1252839f3866@mail.gmail.com> Finally caught something useful!!! Happened again earlier today! May 13 11:50:44 localhost dhclient: bound to 192.168.2.37 -- renewal in 1574 seconds. May 13 12:11:50 localhost kernel: slideshow[16311]: segfault at 14 ip 3c69238d5f sp 7fff73f4f31f error 6 in libX11.so.6.2.0[3c69200000+106000] May 13 12:15:07 localhost kernel: slideshow[16576]: segfault at 14 ip 3c69238d5f sp 7fff680a647f error 6 in libX11.so.6.2.0[3c69200000+106000] May 13 12:16:58 localhost dhclient: DHCPREQUEST on eth1 to 192.168.2.10 port 67 May 13 12:16:58 localhost dhclient: DHCPACK from 192.168.2.10 May 13 12:16:58 localhost dhclient: bound to 192.168.2.37 -- renewal in 1544 seconds. May 13 12:25:07 localhost kernel: slideshow[16842]: segfault at 14 ip 3c69238d5f sp 7fff52abbe8f error 6 in libX11.so.6.2.0[3c69200000+106000] May 13 12:35:07 localhost kernel: slideshow[17107]: segfault at 14 ip 3c69238d5f sp 7fff907edbcf error 6 in libX11.so.6.2.0[3c69200000+106000] May 13 14:11:42 localhost kernel: imklog 3.14.1, log source = /proc/kmsg started. Andy On Tue, May 13, 2008 at 7:48 AM, Dr. Diesel wrote: > I'm on my longest run without a crash, the only thing different is I > disabled ntpd and avahi-daemon. > > Andy > > > > On Sat, May 10, 2008 at 12:47 AM, Dave Airlie wrote: > > > > > > On Fri, 2008-05-09 at 05:36 -0500, Dr. Diesel wrote: > > > Ok, that wasn't it either! > > > > try booting with nohz maybe. > > > > crazy but worth a go. > > > > Dave. > > > > > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > > -- > > > projecthuh.com > All of my bits are free, are yours? Fedoraproject.org > -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org From jkeating at redhat.com Tue May 13 20:45:43 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 13 May 2008 16:45:43 -0400 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <4829F201.3060306@gmail.com> References: <3118d8de0805131021k6261696bmdf28d92ce6a2939a@mail.gmail.com> <4829D444.9010707@gmail.com> <1210702647.3494.20.camel@rousalka.okg> <4829E2F6.7020207@gmail.com> <4829F201.3060306@gmail.com> Message-ID: <1210711543.3170.69.camel@localhost.localdomain> On Tue, 2008-05-13 at 14:54 -0500, Les Mikesell wrote: > It fell down at the point where you copied _some_ of the jpackage > packages, offering less than the original. How could anyone think that > was a good idea, particularly considering that for a long interval there > was no jpackage repo support for current versions of fedora? Fedora is a community effort, and a product of scratching ones own itch. It seems that the only packages brought over were the ones that were explicitly needed by somebody, and the dependencies thereof. If somebody wanted to make a project out of bringing everything jpackage has to offer that we can ship in Fedora, that would be awesome. It'd take a lot of work, but it could perhaps help out this situation where people want interleaving or intermixing. If we have everything, there isn't any reason to intermix. Perhaps the proposal I'm working on to have jpackage make use of Fedora provided infrastructure will make it easier to bring jpackage things into Fedora, and make it easier to keep the change flows continuing. One wonders what the likes of Novell does for their java stuff, like OpenOffice and such. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From orion at cora.nwra.com Tue May 13 20:48:06 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 13 May 2008 14:48:06 -0600 Subject: HDF5 re-enable on ppc64 Message-ID: <4829FE86.8010907@cora.nwra.com> I've determined that the failing tests are for experimental long double support, so I've (hopefully temporarily) disabled them and rebuilt HDF5 in rawhide including ppc64. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From sundaram at fedoraproject.org Tue May 13 20:50:23 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 14 May 2008 02:20:23 +0530 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <4829FCCA.50505@gmail.com> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <1210612643.6285.5.camel@rousalka.okg> <1210613511.12520.46.camel@localhost.localdomain> <1210619487.6844.48.camel@rousalka.okg> <1210621696.12520.62.camel@localhost.localdomain> <1210632587.12173.15.camel@rousalka.okg> <48293492.4020905@gmail.com> <41074.192.54.193.59.1210664862.squirrel@rousalka.dyndns.org> <4829B8D7.7010501@gmail.com> <4829E12A.7060901@gmail.com> <4829E3B0.9090108@redhat.com> <4829F09B.5040500@gmail.com> <4829F3FE.6070203@fedoraproject.org> <4829FCCA.50505@gmail.com> Message-ID: <4829FF0F.7050808@fedoraproject.org> Les Mikesell wrote: > But the way we work around that problem is to not use the one that > conflicts. I think you are suggesting not using fedora unless you > provide a straightforward exclusion method for the conflicting packages. > is that really what you want people to do? You have a bad habit of trying to put words into other people's mouths. Just stop doing that. All distributions have conflicting repositories. You can avoid choosing conflicting repositories or workaround them by assigning a priority or any number of other methods. That's your choice. I have suggested nothing one way or another and implying that I did is just plain lying. Rahul From bojan at rexursive.com Tue May 13 21:28:47 2008 From: bojan at rexursive.com (Bojan Smojver) Date: Tue, 13 May 2008 21:28:47 +0000 (UTC) Subject: Kernel updates? References: <1210329109.10161.5.camel@shrek.rexursive.com> <47297.192.54.193.59.1210664984.squirrel@rousalka.dyndns.org> <200805131019.20120.jwilson@redhat.com> Message-ID: Jarod Wilson redhat.com> writes: > A 2.6.25.3 kernel is already built and waiting in the wings. > > http://koji.fedoraproject.org/packages/kernel/2.6.25.3/18.fc9 Wonderful! Thanks. -- Bojan From lesmikesell at gmail.com Tue May 13 21:42:28 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 13 May 2008 16:42:28 -0500 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <4829FF0F.7050808@fedoraproject.org> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <1210612643.6285.5.camel@rousalka.okg> <1210613511.12520.46.camel@localhost.localdomain> <1210619487.6844.48.camel@rousalka.okg> <1210621696.12520.62.camel@localhost.localdomain> <1210632587.12173.15.camel@rousalka.okg> <48293492.4020905@gmail.com> <41074.192.54.193.59.1210664862.squirrel@rousalka.dyndns.org> <4829B8D7.7010501@gmail.com> <4829E12A.7060901@gmail.com> <4829E3B0.9090108@redhat.com> <4829F09B.5040500@gmail.com> <4829F3FE.6070203@fedoraproject.org> <4829FCCA.50505@gmail.com> <4829FF0F.7050808@fedoraproject.org> Message-ID: <482A0B44.6050905@gmail.com> Rahul Sundaram wrote: > Les Mikesell wrote: > >> But the way we work around that problem is to not use the one that >> conflicts. I think you are suggesting not using fedora unless you >> provide a straightforward exclusion method for the conflicting >> packages. is that really what you want people to do? > > You have a bad habit of trying to put words into other people's mouths. > Just stop doing that. All distributions have conflicting repositories. > You can avoid choosing conflicting repositories or workaround them by > assigning a priority or any number of other methods. That's your choice. > I have suggested nothing one way or another and implying that I did is > just plain lying. OK, please supply your own words. Jpackage.org has a perfectly fine repository. Fedora copies some, but not all of those packages into a potentially conflicting repository. Any argument so far? You did say we learn to work with repository conflicts. If you don't want me to guess what you meant about that, please be specific as to what you think someone should do who wants the jpackage versions and their additional content now. How do you work around a distribution's base repository, particularly when there are dependencies embedded in other packages? -- Les Mikesell lesmikesell at gmail.com From sundaram at fedoraproject.org Tue May 13 21:59:03 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 14 May 2008 03:29:03 +0530 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <482A0B44.6050905@gmail.com> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <1210612643.6285.5.camel@rousalka.okg> <1210613511.12520.46.camel@localhost.localdomain> <1210619487.6844.48.camel@rousalka.okg> <1210621696.12520.62.camel@localhost.localdomain> <1210632587.12173.15.camel@rousalka.okg> <48293492.4020905@gmail.com> <41074.192.54.193.59.1210664862.squirrel@rousalka.dyndns.org> <4829B8D7.7010501@gmail.com> <4829E12A.7060901@gmail.com> <4829E3B0.9090108@redhat.com> <4829F09B.5040500@gmail.com> <4829F3FE.6070203@fedoraproject.org> <4829FCCA.50505@gmail.com> <4829FF0F.7050808@fedoraproject.org> <482A0B44.6050905@gmail.com> Message-ID: <482A0F27.401@fedoraproject.org> Les Mikesell wrote: > OK, please supply your own words. Jpackage.org has a perfectly fine > repository. Nobody has "perfect" repositories. Fedora copies some, but not all of those packages into a > potentially conflicting repository. Any argument so far? You are over-simplying. Things aren't merely "copied" over as you can read about in other mails in the thread. There are developers involved from Red Hat and otherwise working across both these repositories. There are frequently changes in the packages in various directions. You did say > we learn to work with repository conflicts. Yes, the way I deal with it is by not using any third party repositories that conflict with the official repository or with each other. I also suggested some other workarounds in a earlier mail if you choose to install conflicting repositories. Rahul From lesmikesell at gmail.com Tue May 13 22:12:14 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 13 May 2008 17:12:14 -0500 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <482A0F27.401@fedoraproject.org> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <1210612643.6285.5.camel@rousalka.okg> <1210613511.12520.46.camel@localhost.localdomain> <1210619487.6844.48.camel@rousalka.okg> <1210621696.12520.62.camel@localhost.localdomain> <1210632587.12173.15.camel@rousalka.okg> <48293492.4020905@gmail.com> <41074.192.54.193.59.1210664862.squirrel@rousalka.dyndns.org> <4829B8D7.7010501@gmail.com> <4829E12A.7060901@gmail.com> <4829E3B0.9090108@redhat.com> <4829F09B.5040500@gmail.com> <4829F3FE.6070203@fedoraproject.org> <4829FCCA.50505@gmail.com> <4829FF0F.7050808@fedoraproject.org> <482A0B44.6050905@gmail.com> <482A0F27.401@fedoraproject.org> Message-ID: <482A123E.6010100@gmail.com> Rahul Sundaram wrote: > >> OK, please supply your own words. Jpackage.org has a perfectly fine >> repository. > > Nobody has "perfect" repositories. > > Fedora copies some, but not all of those packages into a >> potentially conflicting repository. Any argument so far? > > You are over-simplying. Things aren't merely "copied" over as you can > read about in other mails in the thread. There are developers involved > from Red Hat and otherwise working across both these repositories. There > are frequently changes in the packages in various directions. > > You did say >> we learn to work with repository conflicts. > > Yes, the way I deal with it is by not using any third party repositories > that conflict with the official repository or with each other. But the point of having hardware and an operating system distribution is to run the applications you want. What do you do when the application(s) you want are in those third party repositories? -- Les Mikesell lesmikesell at gmail.com From kevin.kofler at chello.at Tue May 13 22:15:09 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 13 May 2008 22:15:09 +0000 (UTC) Subject: The Prophecy of the 9 comes true (Fedora 9 walks the earth!) References: <1210687284.3170.30.camel@localhost.localdomain> <4829E2FA.8050700@ij.net> Message-ID: Felix Miata ij.net> writes: > Would be nice if >http://docs.fedoraproject.org/release-notes/f9/en_US/sn-Installer.html#sn-scsi-partition-limit > was considerably less subtle about the risk of uninstallability in the > absence of a new disk or disk wipe to put it on: > https://bugzilla.redhat.com/show_bug.cgi?id=430836 You're overdramatizing here: as you say in the bug report, this only hits people with more than 15 partitions on a PATA disk. This hasn't been supported ever since libata was introduced in Fedora 7. There's a big margin between an empty disk and a disk with 16+ partitions, so claiming it will only install on an empty disk is misleading. Kevin Kofler From michael.wiktowy at gmail.com Tue May 13 22:16:14 2008 From: michael.wiktowy at gmail.com (Michael Wiktowy) Date: Tue, 13 May 2008 18:16:14 -0400 Subject: Did preupgrade make it in? In-Reply-To: <1210701504.8342.27.camel@nibbler.dlib.indiana.edu> References: <1210688379.8342.10.camel@nibbler.dlib.indiana.edu> <1210688609.10395.49.camel@localhost.localdomain> <1210701066.8342.24.camel@nibbler.dlib.indiana.edu> <1210701358.29438.26.camel@metroid.rdu.redhat.com> <1210701504.8342.27.camel@nibbler.dlib.indiana.edu> Message-ID: <3e4ec4600805131516r531beeabwb891bfb09983d4d7@mail.gmail.com> On Tue, May 13, 2008 at 1:58 PM, Brian Wheeler wrote: > I did get "no more mirrors to try" once, but this failed differently. > There is a patch attached to the bug, but I've not tried it out yet. Link to the latest one for those looking: https://admin.fedoraproject.org/updates/F8/pending/preupgrade-0.9.3-3.fc8 I am going to give it a go ... wish me luck. I'm guessing my Livna stuff will blow up horribly. /Mike From sundaram at fedoraproject.org Tue May 13 22:23:16 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 14 May 2008 03:53:16 +0530 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <482A123E.6010100@gmail.com> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <1210612643.6285.5.camel@rousalka.okg> <1210613511.12520.46.camel@localhost.localdomain> <1210619487.6844.48.camel@rousalka.okg> <1210621696.12520.62.camel@localhost.localdomain> <1210632587.12173.15.camel@rousalka.okg> <48293492.4020905@gmail.com> <41074.192.54.193.59.1210664862.squirrel@rousalka.dyndns.org> <4829B8D7.7010501@gmail.com> <4829E12A.7060901@gmail.com> <4829E3B0.9090108@redhat.com> <4829F09B.5040500@gmail.com> <4829F3FE.6070203@fedoraproject.org> <4829FCCA.50505@gmail.com> <4829FF0F.7050808@fedoraproject.org> <482A0B44.6050905@gmail.com> <482A0F27.401@fedoraproject.org> <482A123E.6010100@gmail.com> Message-ID: <482A14D4.4080304@fedoraproject.org> Les Mikesell wrote: > > But the point of having hardware and an operating system distribution is > to run the applications you want. What do you do when the > application(s) you want are in those third party repositories? As I said already, there has several workarounds suggested by me and other people. Fedora is a community supported distribution. If you are merely a consumer, you get to live with what the project provides or choose a alternative that better suits what you need. When people step up to be contributions, they can work with the project to bring in those applications and integrate it with the Fedora repository and/or work with the third party repositories on other potential solutions. What you can't do is badge into a development list of a community project and demand things be changed for free according to your convenience. Well you can. People will just ignore that. Rahul From a.badger at gmail.com Tue May 13 22:24:59 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 13 May 2008 15:24:59 -0700 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <482A123E.6010100@gmail.com> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <1210612643.6285.5.camel@rousalka.okg> <1210613511.12520.46.camel@localhost.localdomain> <1210619487.6844.48.camel@rousalka.okg> <1210621696.12520.62.camel@localhost.localdomain> <1210632587.12173.15.camel@rousalka.okg> <48293492.4020905@gmail.com> <41074.192.54.193.59.1210664862.squirrel@rousalka.dyndns.org> <4829B8D7.7010501@gmail.com> <4829E12A.7060901@gmail.com> <4829E3B0.9090108@redhat.com> <4829F09B.5040500@gmail.com> <4829F3FE.6070203@fedoraproject.org> <4829FCCA.50505@gmail.com> <4829FF0F.7050808@fedoraproject.org> <482A0B44.6050905@gmail.com> <482A0F27.401@fedoraproject.org> <482A123E.6010100@gmail.com> Message-ID: <482A153B.3090606@gmail.com> Les Mikesell wrote: > > But the point of having hardware and an operating system distribution is > to run the applications you want. What do you do when the > application(s) you want are in those third party repositories? > Submit a review ticket? :-) -Toshio From michael.wiktowy at gmail.com Tue May 13 22:26:41 2008 From: michael.wiktowy at gmail.com (Michael Wiktowy) Date: Tue, 13 May 2008 18:26:41 -0400 Subject: Did preupgrade make it in? In-Reply-To: <3e4ec4600805131516r531beeabwb891bfb09983d4d7@mail.gmail.com> References: <1210688379.8342.10.camel@nibbler.dlib.indiana.edu> <1210688609.10395.49.camel@localhost.localdomain> <1210701066.8342.24.camel@nibbler.dlib.indiana.edu> <1210701358.29438.26.camel@metroid.rdu.redhat.com> <1210701504.8342.27.camel@nibbler.dlib.indiana.edu> <3e4ec4600805131516r531beeabwb891bfb09983d4d7@mail.gmail.com> Message-ID: <3e4ec4600805131526n25dbde25w801376439ef673d4@mail.gmail.com> On Tue, May 13, 2008 at 6:16 PM, Michael Wiktowy wrote: > On Tue, May 13, 2008 at 1:58 PM, Brian Wheeler wrote: > > I did get "no more mirrors to try" once, but this failed differently. > > There is a patch attached to the bug, but I've not tried it out yet. > > Link to the latest one for those looking: > https://admin.fedoraproject.org/updates/F8/pending/preupgrade-0.9.3-3.fc8 > > I am going to give it a go ... wish me luck. > I'm guessing my Livna stuff will blow up horribly. One bit of feedback while things download: The tip at the bottom mentions "If you need to cancel right now, your downloads will pick up from where they left off the next time you run this assistant." Which is great ... except that the Cancel button is greyed out. /Mike From gnomeuser at gmail.com Tue May 13 22:45:34 2008 From: gnomeuser at gmail.com (David Nielsen) Date: Wed, 14 May 2008 00:45:34 +0200 Subject: rhgb no more In-Reply-To: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> Message-ID: <1dedbbfc0805131545j758171c0p8b2fa1dff71c3e3a@mail.gmail.com> 2008/5/13 Ray Strode : > Hi guys, > > One thing you will soon notice in F10 rawhide is that rhgb is no > longer around. We've blocked it and plan on replacing it for F10. > > This is a continuation of our "BetterStartup" feature from a few > Fedoras ago (I would post a link but the wiki seems to be down). The > replacement for rhgb will be a mixture of two things: > > 1) Starting gdm as early as possible and fitting it to give boot > progress before asking for login. This is somewhat in line with the > early-login prototype feature some of you may remember from several > fedora releases ago. > > 2) Hiding boot messages before gdm unless escape key is pressed. For > graphics hardware that has drm modesetting, we'll be able to show some > sort of pretty graphics, and for everyone else we'll show a very > simple text mode progress. Would we get a slightly more graphical way to unlock our encrypted root partitions than the current fairly inelegant text prompt. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From giallu at gmail.com Tue May 13 22:53:57 2008 From: giallu at gmail.com (Gianluca Sforna) Date: Wed, 14 May 2008 00:53:57 +0200 Subject: rhgb no more In-Reply-To: <1dedbbfc0805131545j758171c0p8b2fa1dff71c3e3a@mail.gmail.com> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> <1dedbbfc0805131545j758171c0p8b2fa1dff71c3e3a@mail.gmail.com> Message-ID: 2008/5/14 David Nielsen : > > Would we get a slightly more graphical way to unlock our encrypted root > partitions than the current fairly inelegant text prompt. I guess that's going to be pretty hard to do... For what I'm concerned, I'd love to use my fingerprint reader for the task :) From bojan at rexursive.com Tue May 13 23:09:52 2008 From: bojan at rexursive.com (Bojan Smojver) Date: Wed, 14 May 2008 09:09:52 +1000 Subject: The Prophecy of the 9 comes true (Fedora 9 walks the earth!) In-Reply-To: <1210687284.3170.30.camel@localhost.localdomain> References: <1210687284.3170.30.camel@localhost.localdomain> Message-ID: <1210720192.13657.53.camel@shrek.rexursive.com> On Tue, 2008-05-13 at 10:01 -0400, Jesse Keating wrote: > And that day has come: the Computer said "I will convert these > unbelievers, and now that I have Sulphur it will be easy." At that, > the heavens opened and burning Sulphur descended upon all the world, > taking on many different forms. Sorry, but this is such a boring release - upgraded my first box and everything just worked ;-) Seriously, nice work folks and thanks! -- Bojan From lesmikesell at gmail.com Tue May 13 23:23:42 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 13 May 2008 18:23:42 -0500 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <482A14D4.4080304@fedoraproject.org> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <1210612643.6285.5.camel@rousalka.okg> <1210613511.12520.46.camel@localhost.localdomain> <1210619487.6844.48.camel@rousalka.okg> <1210621696.12520.62.camel@localhost.localdomain> <1210632587.12173.15.camel@rousalka.okg> <48293492.4020905@gmail.com> <41074.192.54.193.59.1210664862.squirrel@rousalka.dyndns.org> <4829B8D7.7010501@gmail.com> <4829E12A.7060901@gmail.com> <4829E3B0.9090108@redhat.com> <4829F09B.5040500@gmail.com> <4829F3FE.6070203@fedoraproject.org> <4829FCCA.50505@gmail.com> <4829FF0F.7050808@fedoraproject.org> <482A0B44.6050905@gmail.com> <482A0F27.401@fedoraproject.org> <482A123E.6010100@gmail.com> <482A14D4.4080304@fedoraproject.org> Message-ID: <482A22FE.2010509@gmail.com> Rahul Sundaram wrote: > > When people step up to be contributions, they can work with the project > to bring in those applications and integrate it with the Fedora > repository and/or work with the third party repositories on other > potential solutions. What you can't do is badge into a development list > of a community project and demand things be changed for free according > to your convenience. Well you can. People will just ignore that. I'm not demanding anything, I am just presenting a user's perspective and from here it looks like you are currently doing extra work to make things different and incompatible. Feel free to ignore it, but I thought I detected some interest in this conversation in making things better. -- Les Mikesell lesmikesell at gmail.com From sundaram at fedoraproject.org Tue May 13 23:31:54 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 14 May 2008 05:01:54 +0530 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <482A22FE.2010509@gmail.com> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <1210612643.6285.5.camel@rousalka.okg> <1210613511.12520.46.camel@localhost.localdomain> <1210619487.6844.48.camel@rousalka.okg> <1210621696.12520.62.camel@localhost.localdomain> <1210632587.12173.15.camel@rousalka.okg> <48293492.4020905@gmail.com> <41074.192.54.193.59.1210664862.squirrel@rousalka.dyndns.org> <4829B8D7.7010501@gmail.com> <4829E12A.7060901@gmail.com> <4829E3B0.9090108@redhat.com> <4829F09B.5040500@gmail.com> <4829F3FE.6070203@fedoraproject.org> <4829FCCA.50505@gmail.com> <4829FF0F.7050808@fedoraproject.org> <482A0B44.6050905@gmail.com> <482A0F27.401@fedoraproject.org> <482A123E.6010100@gmail.com> <482A14D4.4080304@fedoraproject.org> <482A22FE.2010509@gmail.com> Message-ID: <482A24EA.7040002@fedoraproject.org> Les Mikesell wrote: > > I'm not demanding anything, I am just presenting a user's perspective > and from here it looks like you are currently doing extra work to make > things different and incompatible. It doesn't look anything like that if you are paying any attention at all. Again, cut the drama. Constantly throwing insults at a project just because you have different opinions on how it should be done isn't the way to present anything much less act as a user representative. Besides you can't really be a user representative without being a real regular user yourself. Rahul From mclasen at redhat.com Tue May 13 23:29:52 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 13 May 2008 19:29:52 -0400 Subject: rhgb no more In-Reply-To: <16de708d0805131302h791eb159m62941408fe18ec76@mail.gmail.com> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> <16de708d0805131302h791eb159m62941408fe18ec76@mail.gmail.com> Message-ID: <1210721392.4519.9.camel@localhost.localdomain> On Tue, 2008-05-13 at 15:02 -0500, Arthur Pemberton wrote: > On Tue, May 13, 2008 at 12:07 PM, Ray Strode wrote: > > Hi guys, > > > > One thing you will soon notice in F10 rawhide is that rhgb is no > > longer around. We've blocked it and plan on replacing it for F10. > > > > This is a continuation of our "BetterStartup" feature from a few > > Fedoras ago (I would post a link but the wiki seems to be down). The > > replacement for rhgb will be a mixture of two things: > > > > 1) Starting gdm as early as possible and fitting it to give boot > > progress before asking for login. This is somewhat in line with the > > early-login prototype feature some of you may remember from several > > fedora releases ago. > > > > 2) Hiding boot messages before gdm unless escape key is pressed. For > > graphics hardware that has drm modesetting, we'll be able to show some > > sort of pretty graphics, and for everyone else we'll show a very > > simple text mode progress. > > > > Just a heads up, > > Ray > > > How will this interact with non GDM greeters? > The details have to be worked out, but I assume there will some way for display managers to opt out of the early start, in which case plymouth (the rhgb replacement) will hang around until the boot sequence is over. Or something like that. We hope to have a first, rough cut at this new startup in demoable form by FUDcon, so that would be a good time to discuss how alternative greeters fit into the picture. Matthias From wolfy at nobugconsulting.ro Wed May 14 00:15:12 2008 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Wed, 14 May 2008 03:15:12 +0300 Subject: old redhat rpms list/mirrors In-Reply-To: <20080512194519.GB3153@free.fr> References: <20080512075712.GA2582@free.fr> <4827FB52.4040307@nobugconsulting.ro> <20080512081632.GB2582@free.fr> <4827FF0B.8050803@nobugconsulting.ro> <20080512194519.GB3153@free.fr> Message-ID: <482A2F10.5060303@nobugconsulting.ro> On 05/12/2008 10:45 PM, Patrice Dumas wrote: > On Mon, May 12, 2008 at 11:25:47AM +0300, Manuel Wolfshant wrote: > >> lftp archive.download.redhat.com:/pub/redhat/linux/5.0/en> ls os/i386 >> >> in other words, works for me... >> > > Indeed, for me too with lftp, but not with firefox. Strange. > I have the disks for some old distros (6.1, 6.2, 7.x, IIRC). If it is useful for you, I can try a ls -Rl on them (assuming the disks can still be read...) and send you the results. From notting at redhat.com Wed May 14 00:32:33 2008 From: notting at redhat.com (Bill Nottingham) Date: Tue, 13 May 2008 20:32:33 -0400 Subject: rhgb no more In-Reply-To: <1dedbbfc0805131545j758171c0p8b2fa1dff71c3e3a@mail.gmail.com> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> <1dedbbfc0805131545j758171c0p8b2fa1dff71c3e3a@mail.gmail.com> Message-ID: <20080514003233.GA15598@nostromo.devel.redhat.com> David Nielsen (gnomeuser at gmail.com) said: > Would we get a slightly more graphical way to unlock our encrypted root > partitions than the current fairly inelegant text prompt. Yes, that's planned as part of it. Bill From mrmazda at ij.net Wed May 14 00:37:24 2008 From: mrmazda at ij.net (Felix Miata) Date: Tue, 13 May 2008 20:37:24 -0400 Subject: The Prophecy of the 9 comes true (Fedora 9 walks the earth!) In-Reply-To: References: <1210687284.3170.30.camel@localhost.localdomain> <4829E2FA.8050700@ij.net> Message-ID: <482A3444.9010906@ij.net> On 2008/05/13 22:15 (GMT) Kevin Kofler apparently typed: > Felix Miata ij.net> writes: >> Would be nice if >>http://docs.fedoraproject.org/release-notes/f9/en_US/sn-Installer.html#sn-scsi-partition-limit >> was considerably less subtle about the risk of uninstallability in the >> absence of a new disk or disk wipe to put it on: >> https://bugzilla.redhat.com/show_bug.cgi?id=430836 > You're overdramatizing here: Not it all. It wouldn't be so bad if it would simply refuse to do anything, but Anaconda leads you to believe it can succeed by allowing installation to proceed through selection of (pre-existing) perfectly valid mount points (sdX15 or below), then crashing, instead of refusing to proceed, or, as Ubuntu, OpenSUSE & Mandriva do, allowing installation to sdx15 or below without the waste of time crashing. > as you say in the bug report, this only hits > people with more than 15 partitions on a PATA disk. This hasn't been supported > ever since libata was introduced in Fedora 7. Fedora 7 took the lead in obsoleting all systems so configured, and only a little over a year ago. It takes much longer than a year for systems to get replaced under Fedora's new and arbitrary libata installation demands. Even now SUSE (11.0 not yet released) and Mandriva (2008.1 just released) still include legacy drivers as an installation option, which means upgraders from those earlier versions of those systems needn't get stopped cold as now happens with Fedora. And now with support for the last of pre-exclusive-libata Fedora versions falling out of support, it will happen more often by those who previously were not motivated to upgrade to each most recent release. > There's a big margin between an > empty disk and a disk with 16+ partitions, so claiming it will only install on > an empty disk is misleading. There's no good reason for installation crashing doing something other major distros' installers have no problem with. That's why relnote elaboration needed. Moreover, what Anaconda really should do, in addition to not crashing, is provide access to all pre-existing partitions, whether on SATA or PATA or even real SCSI, via device mapper. Just because LVM exists doesn't mean it's best for everyone. -- ". . . . in everything, do to others what you would have them do to you . . . ." Matthew 7:12 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ From abartlet at samba.org Wed May 14 01:09:04 2008 From: abartlet at samba.org (Andrew Bartlett) Date: Wed, 14 May 2008 11:09:04 +1000 Subject: rhgb no more In-Reply-To: <20080514003233.GA15598@nostromo.devel.redhat.com> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> <1dedbbfc0805131545j758171c0p8b2fa1dff71c3e3a@mail.gmail.com> <20080514003233.GA15598@nostromo.devel.redhat.com> Message-ID: <1210727344.3675.17.camel@naomi> On Tue, 2008-05-13 at 20:32 -0400, Bill Nottingham wrote: > David Nielsen (gnomeuser at gmail.com) said: > > Would we get a slightly more graphical way to unlock our encrypted root > > partitions than the current fairly inelegant text prompt. > > Yes, that's planned as part of it. X in the initrd? :-) -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kevin.kofler at chello.at Wed May 14 01:11:01 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 14 May 2008 01:11:01 +0000 (UTC) Subject: The Prophecy of the 9 comes true (Fedora 9 walks the earth!) References: <1210687284.3170.30.camel@localhost.localdomain> <4829E2FA.8050700@ij.net> <482A3444.9010906@ij.net> Message-ID: Felix Miata ij.net> writes: > happens with Fedora. And now with support for the last of > pre-exclusive-libata Fedora versions falling out of support, it will happen > more often by those who previously were not motivated to upgrade to each most > recent release. Fedora Core 6, the last pre-libata release of Fedora, was EOLed in December 2007, so all possibly affected existing Fedora users are supposed to have upgraded already. Kevin Kofler From kevin.kofler at chello.at Wed May 14 01:14:30 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 14 May 2008 01:14:30 +0000 (UTC) Subject: rhgb no more References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> <1dedbbfc0805131545j758171c0p8b2fa1dff71c3e3a@mail.gmail.com> <20080514003233.GA15598@nostromo.devel.redhat.com> <1210727344.3675.17.camel@naomi> Message-ID: Andrew Bartlett samba.org> writes: > X in the initrd? Couldn't Qt/Embedded be used for this purpose? We'd have to find a way to prevent a conflict with the regular Qt/X11, but other than that it would seem to be the perfect match for a lightweight RHGB-type solution (i.e. one which doesn't require starting up X early) to me. Kevin Kofler From mclasen at redhat.com Wed May 14 01:20:19 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 13 May 2008 21:20:19 -0400 Subject: rhgb no more In-Reply-To: References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> <1dedbbfc0805131545j758171c0p8b2fa1dff71c3e3a@mail.gmail.com> <20080514003233.GA15598@nostromo.devel.redhat.com> <1210727344.3675.17.camel@naomi> Message-ID: <1210728019.4519.13.camel@localhost.localdomain> On Wed, 2008-05-14 at 01:14 +0000, Kevin Kofler wrote: > Andrew Bartlett samba.org> writes: > > X in the initrd? > > Couldn't Qt/Embedded be used for this purpose? We'd have to find a way to > prevent a conflict with the regular Qt/X11, but other than that it would seem > to be the perfect match for a lightweight RHGB-type solution (i.e. one which > doesn't require starting up X early) to me. Or GTK/directfb... but you don't really need or want a full-blown toolkit there, either way. The main thing is to handle keyboard input in an acceptable way, and display some feedback that resembles a password entry. krh was muttering about a xkb-to-console-keymap converter this morning, as a possible solution to the keyboard layout problem. From mrmazda at ij.net Wed May 14 01:30:30 2008 From: mrmazda at ij.net (Felix Miata) Date: Tue, 13 May 2008 21:30:30 -0400 Subject: The Prophecy of the 9 comes true (Fedora 9 walks the earth!) In-Reply-To: References: <1210687284.3170.30.camel@localhost.localdomain> <4829E2FA.8050700@ij.net> <482A3444.9010906@ij.net> Message-ID: <482A40B6.1040607@ij.net> On 2008/05/14 01:11 (GMT) Kevin Kofler apparently typed: > Felix Miata wrote: >> happens with Fedora. And now with support for the last of >> pre-exclusive-libata Fedora versions falling out of support, it will happen >> more often by those who previously were not motivated to upgrade to each most >> recent release. > Fedora Core 6, the last pre-libata release of Fedora, was EOLed in December > 2007, so all possibly affected existing Fedora users are supposed to have > upgraded already. I hope you'll forgive me for getting the tense of "fall" wrong. Not being able to install without a crash limits the number of machines I can attempt an install on to two older boxes that don't see much use beyond testing Linux installation tools. That in turn limits the time I can justify spending even to try, much less actually keep up with things that only matter if you can get past the installation process. I have to guess a nonzero quantity of those who were supposed to have upgraded have indeed done so, but not to F7, F8 or F9. -- ". . . . in everything, do to others what you would have them do to you . . . ." Matthew 7:12 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ From katzj at redhat.com Wed May 14 01:35:51 2008 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 13 May 2008 21:35:51 -0400 Subject: rhgb no more In-Reply-To: <1210728019.4519.13.camel@localhost.localdomain> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> <1dedbbfc0805131545j758171c0p8b2fa1dff71c3e3a@mail.gmail.com> <20080514003233.GA15598@nostromo.devel.redhat.com> <1210727344.3675.17.camel@naomi> <1210728019.4519.13.camel@localhost.localdomain> Message-ID: <1210728951.12036.52.camel@aglarond.local> On Tue, 2008-05-13 at 21:20 -0400, Matthias Clasen wrote: > On Wed, 2008-05-14 at 01:14 +0000, Kevin Kofler wrote: > > Andrew Bartlett samba.org> writes: > > > X in the initrd? > > > > Couldn't Qt/Embedded be used for this purpose? We'd have to find a way to > > prevent a conflict with the regular Qt/X11, but other than that it would seem > > to be the perfect match for a lightweight RHGB-type solution (i.e. one which > > doesn't require starting up X early) to me. > > Or GTK/directfb... but you don't really need or want a full-blown > toolkit there, either way. The main thing is to handle keyboard input in > an acceptable way, and display some feedback that resembles a password > entry. Yeah, all we really need to do is stick an appropriate graphic up on the screen and _maybe_ render some text to describe which partition is being unlocked. But there shouldn't be any need for a widget toolkit > krh was muttering about a xkb-to-console-keymap converter this > morning, as a possible solution to the keyboard layout problem. I had looked briefly at this early in the Fedora 9 cycle and it's the right thing to do even ignoring encrypted device passphrase input. Continuing the disaster of manual mapping between console keyboard layouts and X ones is just utter fail. Sure, you can't have *all* of the niceties of X's keyboard input, but you can map pretty well. And some other distros have been doing so for a while. I should just make the time to actually push this over the next week or two. It'll also help the mapping to X keyboard layouts as we're not writing an xorg.conf at all anymore[1] Jeremy [1] Well, with the uncommitted changes that are sitting on my laptop. But landing in a rawhide near you probably on Thursday. :) From lesmikesell at gmail.com Wed May 14 02:00:37 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 13 May 2008 21:00:37 -0500 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <482A24EA.7040002@fedoraproject.org> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <1210612643.6285.5.camel@rousalka.okg> <1210613511.12520.46.camel@localhost.localdomain> <1210619487.6844.48.camel@rousalka.okg> <1210621696.12520.62.camel@localhost.localdomain> <1210632587.12173.15.camel@rousalka.okg> <48293492.4020905@gmail.com> <41074.192.54.193.59.1210664862.squirrel@rousalka.dyndns.org> <4829B8D7.7010501@gmail.com> <4829E12A.7060901@gmail.com> <4829E3B0.9090108@redhat.com> <4829F09B.5040500@gmail.com> <4829F3FE.6070203@fedoraproject.org> <4829FCCA.50505@gmail.com> <4829FF0F.7050808@fedoraproject.org> <482A0B44.6050905@gmail.com> <482A0F27.401@fedoraproject.org> <482A123E.6010100@gmail.com> <482A14D4.4080304@fedoraproject.org> <482A22FE.2010509@gmail.com> <482A24EA.7040002@fedoraproject.org> Message-ID: <482A47C5.4020402@gmail.com> Rahul Sundaram wrote: >> >> I'm not demanding anything, I am just presenting a user's perspective >> and from here it looks like you are currently doing extra work to make >> things different and incompatible. > > It doesn't look anything like that if you are paying any attention at > all. Again, cut the drama. Constantly throwing insults at a project just > because you have different opinions on how it should be done isn't the > way to present anything much less act as a user representative. I'm trying to be realistic, not insulting. I just think that needing to use 3rd party apps is common and thus representative for users. How else is there to present that other than to bring up difficulties? > Besides > you can't really be a user representative without being a real regular > user yourself. I use FC6 daily. -- Les Mikesell lesmikesell at gmail.com From maximilianbianco at gmail.com Wed May 14 02:21:41 2008 From: maximilianbianco at gmail.com (max) Date: Tue, 13 May 2008 22:21:41 -0400 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <482A47C5.4020402@gmail.com> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <1210612643.6285.5.camel@rousalka.okg> <1210613511.12520.46.camel@localhost.localdomain> <1210619487.6844.48.camel@rousalka.okg> <1210621696.12520.62.camel@localhost.localdomain> <1210632587.12173.15.camel@rousalka.okg> <48293492.4020905@gmail.com> <41074.192.54.193.59.1210664862.squirrel@rousalka.dyndns.org> <4829B8D7.7010501@gmail.com> <4829E12A.7060901@gmail.com> <4829E3B0.9090108@redhat.com> <4829F09B.5040500@gmail.com> <4829F3FE.6070203@fedoraproject.org> <4829FCCA.50505@gmail.com> <4829FF0F.7050808@fedoraproject.org> <482A0B44.6050905@gmail.com> <482A0F27.401@fedoraproject.org> <482A123E.6010100@gmail.com> <482A14D4.4080304@fedoraproject.org> <482A22FE.2010509@gmail.com> <482A24EA.7040002@fedoraproject.org> <482A47C5.4020402@gmail.com> Message-ID: <482A4CB5.9060002@gmail.com> Les Mikesell wrote: > Rahul Sundaram wrote: > >>> >>> I'm not demanding anything, I am just presenting a user's perspective >>> and from here it looks like you are currently doing extra work to >>> make things different and incompatible. >> >> It doesn't look anything like that if you are paying any attention at >> all. Again, cut the drama. Constantly throwing insults at a project >> just because you have different opinions on how it should be done >> isn't the way to present anything much less act as a user representative. > > I'm trying to be realistic, not insulting. I just think that needing to > use 3rd party apps is common and thus representative for users. How > else is there to present that other than to bring up difficulties? > >> Besides you can't really be a user representative without being a real >> regular user yourself. > > I use FC6 daily. > Why no upgrade?Just curious. Max From lesmikesell at gmail.com Wed May 14 05:06:53 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 14 May 2008 00:06:53 -0500 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <482A4CB5.9060002@gmail.com> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <1210612643.6285.5.camel@rousalka.okg> <1210613511.12520.46.camel@localhost.localdomain> <1210619487.6844.48.camel@rousalka.okg> <1210621696.12520.62.camel@localhost.localdomain> <1210632587.12173.15.camel@rousalka.okg> <48293492.4020905@gmail.com> <41074.192.54.193.59.1210664862.squirrel@rousalka.dyndns.org> <4829B8D7.7010501@gmail.com> <4829E12A.7060901@gmail.com> <4829E3B0.9090108@redhat.com> <4829F09B.5040500@gmail.com> <4829F3FE.6070203@fedoraproject.org> <4829FCCA.50505@gmail.com> <4829FF0F.7050808@fedoraproject.org> <482A0B44.6050905@gmail.com> <482A0F27.401@fedoraproject.org> <482A123E.6010100@gmail.com> <482A14D4.4080304@fedoraproject.org> <482A22FE.2010509@gmail.com> <482A24EA.7040002@fedoraproject.org> <482A47C5.4020402@gmail.com> <482A4CB5.9060002@gmail.com> Message-ID: <482A736D.8090808@gmail.com> max wrote: > >>>> I'm not demanding anything, I am just presenting a user's >>>> perspective and from here it looks like you are currently doing >>>> extra work to make things different and incompatible. >>> >>> It doesn't look anything like that if you are paying any attention at >>> all. Again, cut the drama. Constantly throwing insults at a project >>> just because you have different opinions on how it should be done >>> isn't the way to present anything much less act as a user >>> representative. >> >> I'm trying to be realistic, not insulting. I just think that needing >> to use 3rd party apps is common and thus representative for users. >> How else is there to present that other than to bring up difficulties? >> >>> Besides you can't really be a user representative without being a >>> real regular user yourself. >> >> I use FC6 daily. >> > Why no upgrade?Just curious. I've been through all the previous versions and had enough bad experiences to expect it to take a couple of days to get things working and haven't had the time to kill. Most of the machines I manage are running Centos and I don't like having big differences between machines. Plus, for a long time I couldn't find a jpackage repo config for fedora versions past fc6. -- Les Mikesell lesmikesell at gmail.com From nicu_fedora at nicubunu.ro Wed May 14 06:10:09 2008 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Wed, 14 May 2008 09:10:09 +0300 Subject: rhgb no more In-Reply-To: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> Message-ID: <482A8241.2050709@nicubunu.ro> Ray Strode wrote: > > One thing you will soon notice in F10 rawhide is that rhgb is no > longer around. We've blocked it and plan on replacing it for F10. Woohoo! > This is a continuation of our "BetterStartup" feature from a few > Fedoras ago (I would post a link but the wiki seems to be down). The > replacement for rhgb will be a mixture of two things: > > 1) Starting gdm as early as possible and fitting it to give boot > progress before asking for login. This is somewhat in line with the > early-login prototype feature some of you may remember from several > fedora releases ago. It may be too early to ask about that, but from a theming/artwork point of view, is correct my understanding that this will be one piece less to theme? I expect we will have the during the progress the same background image as GDM (which uses the same image as the default desktop) and a progress bar made with GTK+. Maybe a panel (also made with GTK+?) to hold the progress bar? A splash image? Some icons from the default icon theme? Additional animations? > 2) Hiding boot messages before gdm unless escape key is pressed. For > graphics hardware that has drm modesetting, we'll be able to show some > sort of pretty graphics, and for everyone else we'll show a very > simple text mode progress. -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From alan at redhat.com Wed May 14 06:59:09 2008 From: alan at redhat.com (Alan Cox) Date: Wed, 14 May 2008 02:59:09 -0400 Subject: rhgb no more In-Reply-To: <1210728951.12036.52.camel@aglarond.local> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> <1dedbbfc0805131545j758171c0p8b2fa1dff71c3e3a@mail.gmail.com> <20080514003233.GA15598@nostromo.devel.redhat.com> <1210727344.3675.17.camel@naomi> <1210728019.4519.13.camel@localhost.localdomain> <1210728951.12036.52.camel@aglarond.local> Message-ID: <20080514065909.GB16814@devserv.devel.redhat.com> On Tue, May 13, 2008 at 09:35:51PM -0400, Jeremy Katz wrote: > Yeah, all we really need to do is stick an appropriate graphic up on the > screen and _maybe_ render some text to describe which partition is being > unlocked. But there shouldn't be any need for a widget toolkit VGAfb and the bogl library is quite sufficient for this. Historically it has been used for things like non ascii text consoles on some systems but it and/or nano-gui will do the job, and unlike the X server won't crash and burn on some older cards. From pertusus at free.fr Wed May 14 07:24:28 2008 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 14 May 2008 09:24:28 +0200 Subject: old redhat rpms list/mirrors In-Reply-To: <482A2F10.5060303@nobugconsulting.ro> References: <20080512075712.GA2582@free.fr> <4827FB52.4040307@nobugconsulting.ro> <20080512081632.GB2582@free.fr> <4827FF0B.8050803@nobugconsulting.ro> <20080512194519.GB3153@free.fr> <482A2F10.5060303@nobugconsulting.ro> Message-ID: <20080514072428.GA2665@free.fr> On Wed, May 14, 2008 at 03:15:12AM +0300, Manuel Wolfshant wrote: > On 05/12/2008 10:45 PM, Patrice Dumas wrote: >> On Mon, May 12, 2008 at 11:25:47AM +0300, Manuel Wolfshant wrote: >> >>> lftp archive.download.redhat.com:/pub/redhat/linux/5.0/en> ls os/i386 >>> >>> in other words, works for me... >>> >> >> Indeed, for me too with lftp, but not with firefox. Strange. >> > I have the disks for some old distros (6.1, 6.2, 7.x, IIRC). If it is > useful for you, I can try a ls -Rl on them (assuming the disks can still be > read...) and send you the results. I used lftp, it was fine, thanks. -- Pat From stlwrt at gmail.com Wed May 14 09:36:04 2008 From: stlwrt at gmail.com (Pavel Shevchuk) Date: Wed, 14 May 2008 12:36:04 +0300 Subject: rhgb no more In-Reply-To: <20080514065909.GB16814@devserv.devel.redhat.com> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> <1dedbbfc0805131545j758171c0p8b2fa1dff71c3e3a@mail.gmail.com> <20080514003233.GA15598@nostromo.devel.redhat.com> <1210727344.3675.17.camel@naomi> <1210728019.4519.13.camel@localhost.localdomain> <1210728951.12036.52.camel@aglarond.local> <20080514065909.GB16814@devserv.devel.redhat.com> Message-ID: Edje with DirectFB support is in rawhide already, ETK and EWL are coming soon ;) On Wed, May 14, 2008 at 9:59 AM, Alan Cox wrote: > On Tue, May 13, 2008 at 09:35:51PM -0400, Jeremy Katz wrote: > > Yeah, all we really need to do is stick an appropriate graphic up on the > > screen and _maybe_ render some text to describe which partition is being > > unlocked. But there shouldn't be any need for a widget toolkit > > VGAfb and the bogl library is quite sufficient for this. Historically it > has been used for things like non ascii text consoles on some systems but > it and/or nano-gui will do the job, and unlike the X server won't crash and > burn on some older cards. > > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- http://scwlab.com From rodd at clarkson.id.au Wed May 14 09:56:10 2008 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Wed, 14 May 2008 19:56:10 +1000 Subject: rawhide report: 20080513 changes (resend) In-Reply-To: <20080513162213.4468E209D1D@releng1.fedora.phx.redhat.com> References: <20080513162213.4468E209D1D@releng1.fedora.phx.redhat.com> Message-ID: <1210758970.6238.10.camel@localhost.localdomain> On Tue, 2008-05-13 at 16:22 +0000, Rawhide wrote: > New package openhpi-subagent > NetSNMP subagent for OpenHPI > New package ocaml-pgocaml > OCaml library for type-safe access to PostgreSQL databases > New package anyremote > Remote control through bluetooth or IR connection > New package wordwarvi > Side-scrolling shoot 'em up '80s style arcade game > New package e16-themes > Themes for Enlightenment, DR16 > New package ski > IA-64 user and system mode simulator > New package ocaml-sexplib > OCaml library for converting OCaml values to S-expressions > New package fsvs > Fast System VerSioning versioning for file trees using > subversion > Removed package dragonplayer > Removed package mogilefs-server > Removed package gail > Removed package okteta > Updated Packages: > > netcdf-4.0.0-0.3.beta2.fc10 > --------------------------- > * Thu May 8 18:00:00 2008 Ed Hill - 4.0.0-0.3.beta2 > - make package compliant with bz # 373861 > > * Thu May 8 18:00:00 2008 Ed Hill - 4.0.0-0.2.beta2 > - ExcludeArch: ppc64 since it doesn't (for now) have hdf5 > > * Wed May 7 18:00:00 2008 Ed Hill - 4.0.0-0.1.beta2 > - try out upstream 4.0.0-beta2 > > > zoneminder-1.22.3-14.fc10 > ------------------------- > * Tue May 6 18:00:00 2008 Martin Ebourne - > 1.22.3-14 > - Remove default runlevel, bz #441315 > > * Mon Apr 28 18:00:00 2008 Jason L Tibbitts III - > 1.22.3-13 > - Backport patch for CVE-2008-1381 from 1.23.3 to 1.22.3. > > > libid3tag-0.15.1b-6.fc10 > ------------------------ > * Fri May 9 18:00:00 2008 Todd Zullinger - 0.15.1b-6 > - fix for CVE-2008-2109 (#445812) > > > libxslt-1.1.23-3.fc10 > --------------------- > > gridengine-6.1u4-1.fc10 > ----------------------- > * Fri Apr 11 18:00:00 2008 - Orion Poplawski - > 6.1u4-1 > - Update to 6.1u4 > > > podsleuth-0.6.0-5.fc10 > ---------------------- > * Mon May 5 18:00:00 2008 Nigel Jones - 0.6.0-5 > - Fix iPod detection w/ hal-info >= 20080313 (Closes: Bug #445611) > - Correct last changelog entry > > > ocaml-ocamlnet-2.2.9-6.fc10 > --------------------------- > * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 2.2.9-6 > - Rebuild for OCaml 3.10.2 > > * Mon Apr 21 18:00:00 2008 Richard W.M. Jones - 2.2.9-5 > - New upstream URL. > > > ocaml-ssl-0.4.2-9.fc10 > ---------------------- > * Wed Apr 23 18:00:00 2008 Richard W.M. Jones - 0.4.2-9 > - Rebuild for OCaml 3.10.2 > > > atlas-3.6.0-15.fc10 > ------------------- > * Thu Feb 28 17:00:00 2008 Quentin Spencer 3.6.0-15 > - Disable altivec package--it is causing illegal instructions during build. > > * Thu Feb 28 17:00:00 2008 Quentin Spencer 3.6.0-14 > - Enable compilation on alpha (bug 426086). > - Patch for compilation on ia64 (bug 432744). > > * Tue Feb 19 17:00:00 2008 Fedora Release Engineering - 3.6.0-13 > - Autorebuild for GCC 4.3 > > > openvrml-0.17.5-5.fc9 > --------------------- > * Fri Apr 25 18:00:00 2008 Braden McDaniel - 0.17.5-5 > - Append -O0 after optflags on ppc64 to work around gcc segfault. > > * Tue Apr 22 18:00:00 2008 Braden McDaniel - 0.17.5-4 > - Patch to fix missing std qualification that gcc 4.3 complains about. > > * Wed Mar 26 18:00:00 2008 Braden McDaniel - 0.17.5-3 > - Fixed patch to use -p0. > > * Wed Mar 26 18:00:00 2008 Braden McDaniel - 0.17.5-2 > - Patch for crash in openvrml-xembed (bug 437611). > > > lftp-3.7.1-1.fc10 > ----------------- > * Wed Apr 23 18:00:00 2008 Martin Nagy - 3.7.1-1 > - update to upstream version 3.7.1 > > > openarena-0.7.6-1.fc10 > ---------------------- > * Wed Apr 23 18:00:00 2008 Micha? Bentkowski - 0.7.6-1 > - New release > - Fix desktop file a bit > > > > git-1.5.5.1-1.fc10 > ------------------ > * Mon Apr 21 18:00:00 2008 James Bowes 1.5.5.1-1 > - git-1.5.5.1 > > * Wed Apr 9 18:00:00 2008 James Bowes 1.5.5-1 > - git-1.5.5 > > gtkwave-3.1.9-1.fc10 > -------------------- > * Tue Apr 22 18:00:00 2008 Paul Howarth 3.1.9-1 > - update to 3.1.9 > > > scim-1.4.7-23.fc10 > ------------------ > > libchewing-0.3.0-11.fc10 > ------------------------ > * Tue Apr 22 18:00:00 2008 Caius Chance - 0.3.0-11.fc10 > - Resolves: rhbz195416 (Initial input mode between Chinese and English.) > Any reason why these lists are no longer alphabetical? R. -- "It's a fine line between denial and faith. It's much better on my side" From mjg59 at srcf.ucam.org Wed May 14 10:24:13 2008 From: mjg59 at srcf.ucam.org (Matthew Garrett) Date: Wed, 14 May 2008 11:24:13 +0100 Subject: rhgb no more In-Reply-To: <20080514065909.GB16814@devserv.devel.redhat.com> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> <1dedbbfc0805131545j758171c0p8b2fa1dff71c3e3a@mail.gmail.com> <20080514003233.GA15598@nostromo.devel.redhat.com> <1210727344.3675.17.camel@naomi> <1210728019.4519.13.camel@localhost.localdomain> <1210728951.12036.52.camel@aglarond.local> <20080514065909.GB16814@devserv.devel.redhat.com> Message-ID: <20080514102413.GA29792@srcf.ucam.org> On Wed, May 14, 2008 at 02:59:09AM -0400, Alan Cox wrote: > VGAfb and the bogl library is quite sufficient for this. Historically it > has been used for things like non ascii text consoles on some systems but > it and/or nano-gui will do the job, and unlike the X server won't crash and > burn on some older cards. Some machines don't like vga16fb. I've got a via-based system where using it results in horrific skew (every line is about 8 pixels further right than the previous line). I've also seen sis-based systems where hitting the vga crtcs directly works fine for the external video out, but leaves the TFT scanning out garbage. I suspect that all of this hardware is broken, but... -- Matthew Garrett | mjg59 at srcf.ucam.org From mjg59 at srcf.ucam.org Wed May 14 10:25:44 2008 From: mjg59 at srcf.ucam.org (Matthew Garrett) Date: Wed, 14 May 2008 11:25:44 +0100 Subject: rhgb no more In-Reply-To: References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> <1dedbbfc0805131545j758171c0p8b2fa1dff71c3e3a@mail.gmail.com> <20080514003233.GA15598@nostromo.devel.redhat.com> <1210727344.3675.17.camel@naomi> <1210728019.4519.13.camel@localhost.localdomain> <1210728951.12036.52.camel@aglarond.local> <20080514065909.GB16814@devserv.devel.redhat.com> Message-ID: <20080514102544.GB29792@srcf.ucam.org> On Wed, May 14, 2008 at 12:36:04PM +0300, Pavel Shevchuk wrote: > Edje with DirectFB support is in rawhide already, ETK and EWL are coming soon ;) Directfb by default isn't helpful, due to the various miseries that vesafb then inflicts upon you. At least X is (usually...) able to get out of the way in a graceful manner. -- Matthew Garrett | mjg59 at srcf.ucam.org From twoerner at redhat.com Wed May 14 10:44:52 2008 From: twoerner at redhat.com (Thomas Woerner) Date: Wed, 14 May 2008 12:44:52 +0200 Subject: rhgb no more In-Reply-To: <4829D8EF.9050101@ncsu.edu> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> <4829D8EF.9050101@ncsu.edu> Message-ID: <482AC2A4.6000004@redhat.com> Casey Dahlin wrote: > Kevin Kofler wrote: >> Ray Strode gmail.com> writes: >> >>> 1) Starting gdm as early as possible and fitting it to give boot >>> progress before asking for login. This is somewhat in line with the >>> early-login prototype feature some of you may remember from several >>> fedora releases ago. >>> >> >> Unfortunately, starting up GDM early and adding progress report there >> isn't going to help even a little bit for us KDM users. :-( >> >> Kevin Kofler >> >> > Not sure we're still planning on architecting it that way. GDM has > enough on its mind with the fresh rewrite. > --CJD > Please also put the .xsession start back in, it is missing again in F-9. Thomas From alan at redhat.com Wed May 14 10:52:28 2008 From: alan at redhat.com (Alan Cox) Date: Wed, 14 May 2008 06:52:28 -0400 Subject: rhgb no more In-Reply-To: <20080514102413.GA29792@srcf.ucam.org> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> <1dedbbfc0805131545j758171c0p8b2fa1dff71c3e3a@mail.gmail.com> <20080514003233.GA15598@nostromo.devel.redhat.com> <1210727344.3675.17.camel@naomi> <1210728019.4519.13.camel@localhost.localdomain> <1210728951.12036.52.camel@aglarond.local> <20080514065909.GB16814@devserv.devel.redhat.com> <20080514102413.GA29792@srcf.ucam.org> Message-ID: <20080514105228.GB24061@devserv.devel.redhat.com> On Wed, May 14, 2008 at 11:24:13AM +0100, Matthew Garrett wrote: > right than the previous line). I've also seen sis-based systems where > hitting the vga crtcs directly works fine for the external video out, > but leaves the TFT scanning out garbage. I suspect that all of this > hardware is broken, but... I thought the SiS one got fixed or did the patch never get applied ? SiS posted a cure years back but maybe it only made the R/H kernel. In both of these cases you don't muck with the clock setup but trust the BIOS did it (which is what windoze does) Alan From alan at redhat.com Wed May 14 10:52:59 2008 From: alan at redhat.com (Alan Cox) Date: Wed, 14 May 2008 06:52:59 -0400 Subject: rhgb no more In-Reply-To: <20080514102544.GB29792@srcf.ucam.org> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> <1dedbbfc0805131545j758171c0p8b2fa1dff71c3e3a@mail.gmail.com> <20080514003233.GA15598@nostromo.devel.redhat.com> <1210727344.3675.17.camel@naomi> <1210728019.4519.13.camel@localhost.localdomain> <1210728951.12036.52.camel@aglarond.local> <20080514065909.GB16814@devserv.devel.redhat.com> <20080514102544.GB29792@srcf.ucam.org> Message-ID: <20080514105259.GC24061@devserv.devel.redhat.com> On Wed, May 14, 2008 at 11:25:44AM +0100, Matthew Garrett wrote: > Directfb by default isn't helpful, due to the various miseries that > vesafb then inflicts upon you. At least X is (usually...) able to get > out of the way in a graceful manner. Vesafb also crashes on boot on some video cards 8( From karsten at redhat.com Wed May 14 11:08:23 2008 From: karsten at redhat.com (Karsten Hopp) Date: Wed, 14 May 2008 13:08:23 +0200 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <4829B803.3080802@gmail.com> References: <1209999548.32107.11.camel@kennedy> <481F2986.8010509@redhat.com> <1210002669.26792.65.camel@beck.corsepiu.local> <481FD064.6050307@ncsu.edu> <1210045081.4658.7.camel@localhost.localdomain> <481FD3D5.5070206@ncsu.edu> <48207309.3040403@redhat.com> <1210321932.26792.817.camel@beck.corsepiu.local> <4824184A.1010508@redhat.com> <4824856E.3080109@gmail.com> <3r9of5xq9c.ln2@ppp1053.in.ipex.cz> <4829B803.3080802@gmail.com> Message-ID: <482AC827.7030205@redhat.com> Toshio Kuratomi schrieb: > I'm arguing that the problem Karsten thinks he's addressing is > "widespread use of the autotools when there's no need to do it". If > there are few packages that BuildRequire autotools in the first place, > then there can't be a widespread use of autotools in package building, > let alone a widespread use that is unnecessary. > > -Toshio > I think you misunderstood my proposal to drop the old autofoo stuff. The main reasoning for my proposal was that I think that software packages shouldn't rely on old, unmaintained (upstream) helper programs such as p.e. automake-1.4 and that we should help upstream to move to more recent autofoo. Raising a barrier by not shipping the old stuff anymore and thus maybe forcing upstream maintainers to other distributions was a bad idea which I've canceled during this discussion. But I still think a guideline that new packages should be checked if they can easily ported to current autofoo before they get accepted would help us und upstream in the longer term. Please note that I don't insist on having them ported, if it is too complicated to port it should still get accepted. But not every package has that many special cases and hacks as the firefox package, most should be portable without too much affort and I'm sure most upstream maintainers would be glad to get patches for the autofoo stuff. Karsten From karsten at redhat.com Wed May 14 11:19:29 2008 From: karsten at redhat.com (Karsten Hopp) Date: Wed, 14 May 2008 13:19:29 +0200 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <4824B8E1.30406@redhat.com> References: <1209999548.32107.11.camel@kennedy> <481F2986.8010509@redhat.com> <1210002669.26792.65.camel@beck.corsepiu.local> <481FD064.6050307@ncsu.edu> <1210045081.4658.7.camel@localhost.localdomain> <481FD3D5.5070206@ncsu.edu> <48207309.3040403@redhat.com> <1210321932.26792.817.camel@beck.corsepiu.local> <4824184A.1010508@redhat.com> <4824856E.3080109@gmail.com> <4824B8E1.30406@redhat.com> Message-ID: <482ACAC1.5010202@redhat.com> Christopher Aillon schrieb: > On 05/09/2008 01:10 PM, Toshio Kuratomi wrote: >> If we really and truly want to get upstreams off of older versions of >> autoconf/automake, we need to introduce it into our toolchain and have >> every package that uses autotools invoke the current autoconf/automake >> in the build. This will bring errors to the surface so we can fix >> them and submit the changes upstream. > > Toshio, this thread is dead. > > I already brought one application that doesn't build with current > autotools to the surface: Firefox. (Well, plus Thunderbird, SeaMonkey, > etc). Yet, as popular as Firefox is, I don't see anyone fixing it. I've > been asking multiple times on this thread for people that care about > this issue to fix it. There have been no takers as of yet. > > That should speak volumes about how important this really is. > I had a look at the Firefox build environment and the patch from Enrico Weigelt you've pointed at. The main problem here isn't porting the stuff to current autofoo but to make sure that Firefox still builds on every supported platform and every combination of autoconf / automake versions. Heavy stuff indeed and lots of testing required ,-( I can now understand why I seem to have found a sore point and got you so agitated, I'm sorry about that. Karsten From pertusus at free.fr Wed May 14 11:23:37 2008 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 14 May 2008 13:23:37 +0200 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <482AC827.7030205@redhat.com> References: <481FD064.6050307@ncsu.edu> <1210045081.4658.7.camel@localhost.localdomain> <481FD3D5.5070206@ncsu.edu> <48207309.3040403@redhat.com> <1210321932.26792.817.camel@beck.corsepiu.local> <4824184A.1010508@redhat.com> <4824856E.3080109@gmail.com> <3r9of5xq9c.ln2@ppp1053.in.ipex.cz> <4829B803.3080802@gmail.com> <482AC827.7030205@redhat.com> Message-ID: <20080514112336.GA11185@free.fr> On Wed, May 14, 2008 at 01:08:23PM +0200, Karsten Hopp wrote: > should help upstream to move to more recent autofoo. ... > But I still think a guideline that > new packages should be checked if they can easily ported to current autofoo before they > get accepted would help us und upstream in the longer term. Please note that I don't insist > on having them ported, if it is too complicated to port it should still get accepted. > But not every package has that many special cases and hacks as the firefox package, most > should be portable without too much affort and I'm sure most upstream maintainers would be > glad to get patches for the autofoo stuff. I don't think this should be in guidelines or enforced in any way. These are more like development best practices for upstream. Fedora contributors can help upstream in that direction, but they can also help in any other direction, porting to newer autotools may not be worth the time used. Lets let the packagers decide for themselves where they should invest their time devoted to helping upstream. We could do a page in the wiki for the best practices for upstream that helps packaging (like you said, there is here using recent autotool versions, but there is also using pkgconfig, having CFLAGS easily overriden by the user, changing sonames for backward incompatible ABI library releases, but only for ABI incompatible changes, allowing for staged install easily, if possible using DESTDIR...). -- Pat From jkeating at redhat.com Wed May 14 11:47:52 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 14 May 2008 07:47:52 -0400 Subject: rawhide report: 20080513 changes (resend) In-Reply-To: <1210758970.6238.10.camel@localhost.localdomain> References: <20080513162213.4468E209D1D@releng1.fedora.phx.redhat.com> <1210758970.6238.10.camel@localhost.localdomain> Message-ID: <1210765672.3170.98.camel@localhost.localdomain> On Wed, 2008-05-14 at 19:56 +1000, Rodd Clarkson wrote: > Any reason why these lists are no longer alphabetical? This particular list was created by repodiff from yum-utils, and it may have been an older one before seth added alphabetizing to the output. The traditional tool, treediff, didn't seem to cope with the sheer amount of changes. In the near future we will be migrating to using repodiff by default for generating these reports. The bonus here is that repodiff is a yum-util and far easier to modify and enhance. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mjg59 at srcf.ucam.org Wed May 14 11:49:17 2008 From: mjg59 at srcf.ucam.org (Matthew Garrett) Date: Wed, 14 May 2008 12:49:17 +0100 Subject: rhgb no more In-Reply-To: <20080514105228.GB24061@devserv.devel.redhat.com> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> <1dedbbfc0805131545j758171c0p8b2fa1dff71c3e3a@mail.gmail.com> <20080514003233.GA15598@nostromo.devel.redhat.com> <1210727344.3675.17.camel@naomi> <1210728019.4519.13.camel@localhost.localdomain> <1210728951.12036.52.camel@aglarond.local> <20080514065909.GB16814@devserv.devel.redhat.com> <20080514102413.GA29792@srcf.ucam.org> <20080514105228.GB24061@devserv.devel.redhat.com> Message-ID: <20080514114917.GA31241@srcf.ucam.org> On Wed, May 14, 2008 at 06:52:28AM -0400, Alan Cox wrote: > I thought the SiS one got fixed or did the patch never get applied ? SiS > posted a cure years back but maybe it only made the R/H kernel. In both of > these cases you don't muck with the clock setup but trust the BIOS did it > (which is what windoze does) Ah, interesting. No, I don't think that ever got upstream. The other issue I saw on some hardware was that 640x480 either lost the last 80 lines or drew them at the top of the screen. Nailing the resolution to 640x400 instead seemed to fix that. -- Matthew Garrett | mjg59 at srcf.ucam.org From rc040203 at freenet.de Wed May 14 12:02:50 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 14 May 2008 14:02:50 +0200 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <482AC827.7030205@redhat.com> References: <1209999548.32107.11.camel@kennedy> <481F2986.8010509@redhat.com> <1210002669.26792.65.camel@beck.corsepiu.local> <481FD064.6050307@ncsu.edu> <1210045081.4658.7.camel@localhost.localdomain> <481FD3D5.5070206@ncsu.edu> <48207309.3040403@redhat.com> <1210321932.26792.817.camel@beck.corsepiu.local> <4824184A.1010508@redhat.com> <4824856E.3080109@gmail.com> <3r9of5xq9c.ln2@ppp1053.in.ipex.cz> <4829B803.3080802@gmail.com> <482AC827.7030205@redhat.com> Message-ID: <1210766570.26792.1016.camel@beck.corsepiu.local> On Wed, 2008-05-14 at 13:08 +0200, Karsten Hopp wrote: > Toshio Kuratomi schrieb: > > > I'm arguing that the problem Karsten thinks he's addressing is > > "widespread use of the autotools when there's no need to do it". If > > there are few packages that BuildRequire autotools in the first place, > > then there can't be a widespread use of autotools in package building, > > let alone a widespread use that is unnecessary. > > > > -Toshio > > > > I think you misunderstood my proposal to drop the old autofoo stuff. > > The main reasoning for my proposal was that I think that software packages shouldn't rely > on old, unmaintained (upstream) helper programs such as p.e. automake-1.4 and that we > should help upstream to move to more recent autofoo. Agreed. > Raising a barrier by not shipping the > old stuff anymore and thus maybe forcing upstream maintainers to other distributions was a > bad idea which I've canceled during this discussion. I disagree - It had not been a bad idea. It would have forced upstreams to learn about their long-term lazyness/sloppyness is going to evolve into "badness" by being confronted with a "the train has left the station" effect. It's what Fedora with almost all other tools all over the place. It's what is keeping Fedora package-maintainers busy, it's what is keeping Fedora-based developers technically ahead of developers based on other distros, etc. -- It's one of the key features Fedora is about. > But I still think a guideline that > new packages should be checked if they can easily ported to current autofoo before they > get accepted would help us und upstream in the longer term. There is no need for US to do this. Upstream should do this - It's their job - It's our job to tell them that their stuff is outdated. > Please note that I don't insist > on having them ported, if it is too complicated to port it should still get accepted. > But not every package has that many special cases and hacks as the firefox package, most > should be portable without too much affort and I'm sure most upstream maintainers would be > glad to get patches for the autofoo stuff. True. Ralf From galibert at pobox.com Wed May 14 12:58:39 2008 From: galibert at pobox.com (Olivier Galibert) Date: Wed, 14 May 2008 14:58:39 +0200 Subject: rhgb no more In-Reply-To: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> Message-ID: <20080514125839.GA73283@dspnet.fr.eu.org> On Tue, May 13, 2008 at 01:07:51PM -0400, Ray Strode wrote: > 2) Hiding boot messages before gdm unless escape key is pressed. For > graphics hardware that has drm modesetting, we'll be able to show some > sort of pretty graphics, and for everyone else we'll show a very > simple text mode progress. Here we go again. Are you going to wait for the escape key to be pressed or not for a little while, or are we going to have to press just at the right time between grub and modeswitch if we want to have a chance to check for problems? Is there going to be an easy way (like there is with rhgb) to see the messages (including history) while booting, to check for problems too? And, the usual rhetorical question, why so much people like the idea of forcibly ensuring that the users won't learn anything, ever? OG. From mtasaka at ioa.s.u-tokyo.ac.jp Wed May 14 13:11:26 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 14 May 2008 22:11:26 +0900 Subject: Merge reviews marked as triage target Message-ID: <482AE4FE.7050706@ioa.s.u-tokyo.ac.jp> Hello. About one hour ago many merge reviews are marked as triage targets like: https://www.redhat.com/archives/fedora-package-review/2008-May/msg01109.html In my recognition this must not happen because all packages in Fedora must pass merge reviews (or review requests) and these merge requests should not be closed automatically. Generally speaking all bugs with component "package review" should not be closed by triagers, should be? Regards, Mamoru From mschwendt at gmail.com Wed May 14 13:47:13 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 14 May 2008 15:47:13 +0200 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <4829F7FE.2060101@gmail.com> References: <3118d8de0805131056h62c29c27j84a468b8200b0e10@mail.gmail.com> <1210702375.1920.54.camel@localhost.localdomain> <1210702815.3494.23.camel@rousalka.okg> <1210703122.1920.56.camel@localhost.localdomain> <1210706127.3494.29.camel@rousalka.okg> <4829EFDB.1080005@gmail.com> <1210709191.3494.36.camel@rousalka.okg> <4829F7FE.2060101@gmail.com> Message-ID: <20080514154713.1d258975.mschwendt@gmail.com> On Tue, 13 May 2008 13:20:14 -0700, Toshio Kuratomi wrote: > Nicolas Mailhot wrote: > > What Jason complains about is that after > > taking all the jpp changes for a long time, when some problems were > > identified fedora side jpp was not notified of the fixes (aka downstream > > patch hoarding). > > > Just one further note, since I didn't make it clear in the last email. > It's not downstream patch hoarding if JPackage is not upstream. Since > there's no syncing between the packages since devrim took over, I'd be > hard pressed to say there is an upstream-downstream relationship between > the currently maintained package and the JPackage one. There was a > historical relationship but the package went the derived route instead > of the upstream-downstream route when the new maintainer took over. Then using the .jpp versioning scheme in the Fedora pkg is useless and misleading. You need to sync patches back and forth or else you get unexpected regression when a JPackage pkg updates the Fedora derived pkg without applying the same patch set. From ssorce at redhat.com Wed May 14 13:49:59 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 14 May 2008 09:49:59 -0400 Subject: rhgb no more In-Reply-To: <20080514125839.GA73283@dspnet.fr.eu.org> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> <20080514125839.GA73283@dspnet.fr.eu.org> Message-ID: <1210772999.28428.21.camel@localhost.localdomain> On Wed, 2008-05-14 at 14:58 +0200, Olivier Galibert wrote: > On Tue, May 13, 2008 at 01:07:51PM -0400, Ray Strode wrote: > > 2) Hiding boot messages before gdm unless escape key is pressed. For > > graphics hardware that has drm modesetting, we'll be able to show some > > sort of pretty graphics, and for everyone else we'll show a very > > simple text mode progress. > > Here we go again. > > Are you going to wait for the escape key to be pressed or not for a > little while, or are we going to have to press just at the right time > between grub and modeswitch if we want to have a chance to check for > problems? I hope it will always allow you to switch on the fly to the full log at any time or it will be a problem in many cases. > Is there going to be an easy way (like there is with rhgb) to see the > messages (including history) while booting, to check for problems too? I hope so. > And, the usual rhetorical question, why so much people like the idea > of forcibly ensuring that the users won't learn anything, ever? Users don't want to "learn", why should you FORCE users to "learn" something ? I personally like the option of *not* seeing ugly text messages at boot, even if I perfectly understand what they mean and find them useful when there is an error. Simo. -- Simo Sorce * Red Hat, Inc * New York From mschwendt at gmail.com Wed May 14 13:54:27 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 14 May 2008 15:54:27 +0200 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <4829FC5B.5030000@gmail.com> References: <3118d8de0805131316h55374c5di2b6ad5ed5c4f1b68@mail.gmail.com> <4829FC5B.5030000@gmail.com> Message-ID: <20080514155427.e39ad86d.mschwendt@gmail.com> On Tue, 13 May 2008 13:38:51 -0700, Toshio Kuratomi wrote: > Jason Corley wrote: > >> Nicolas, I believe you're wrong. I can't find a single revision by devrim that syncs from the JPackage spec[1]_ to the Fedora spec. > > > > Yes if you focus only on the current maintainer's history of > > collaboration with JPackage you won't find any. However the following > > shows what used to happen: > > > I don't dispute that. But I am saying that a new maintainer took over > the package. So there was no history of sharing changes with JPackage > there. Continuity doesn't follow the package because there is no policy > or guideline that says that java packages have a special relationship > with JPackage. the maintainer was just following the best practices > that they had established by working on other packages in Fedora. > > Fedora is a community of packagers. Those packagers have different > styles of packaging and working. Where we need to, we unite those > styles with Packaging Guidelines and FESCo Policies. Until we have a > policy that specifies that certain classes of packages must use JPackage > as upstream this kind of thing will happen as packages go through > different maintainers. In addition to my earlier comment: http://fedoraproject.org/wiki/Packaging/JPackagePolicy [...] Fedora includes a set of open source Java RPM packages that originate from the JPackage repository (www.jpackage.org). Currently, these packages are marked with a "jpp" tag: javacc-4.0-3jpp.3.src.rpm These packages are rebuilt against Fedora's gcc and included in Fedora. They use the "jpp" tag for three main technical reasons: * to help manage upgrading packages from Fedora to JPackage and back * to track package hierarchy (this Fedora Java package came from that JPackage Java package) -snip- You break with these two "main technical reasons" if you put "jpp" in the evr only for the third technical reason (i.e. "group operations"). From jonstanley at gmail.com Wed May 14 14:08:52 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Wed, 14 May 2008 10:08:52 -0400 Subject: Merge reviews marked as triage target In-Reply-To: <482AE4FE.7050706@ioa.s.u-tokyo.ac.jp> References: <482AE4FE.7050706@ioa.s.u-tokyo.ac.jp> Message-ID: On Wed, May 14, 2008 at 9:11 AM, Mamoru Tasaka wrote: > In my recognition this must not happen because all packages in Fedora must pass > merge reviews (or review requests) and these merge requests should not be closed > automatically. Generally speaking all bugs with component "package review" should > not be closed by triagers, should be? That is correct. It was our impression that all Package Reviews were to be filed against rawhide, therefore only the queries for rawhide take them into account. I will change the version of all of these such as to avoid them in the future. Sorry for the noise. -- Jon Stanley Fedora Bug Wrangler jstanley at fedoraproject.org From jonstanley at gmail.com Wed May 14 14:12:07 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Wed, 14 May 2008 10:12:07 -0400 Subject: Merge reviews marked as triage target In-Reply-To: References: <482AE4FE.7050706@ioa.s.u-tokyo.ac.jp> Message-ID: On Wed, May 14, 2008 at 10:08 AM, Jon Stanley wrote: > That is correct. It was our impression that all Package Reviews were > to be filed against rawhide, therefore only the queries for rawhide > take them into account. I will change the version of all of these > such as to avoid them in the future. Sorry for the noise. Note that there were only 25 such bugs, and all have now been moved to rawhide. Thanks for the heads up! From dr.diesel at gmail.com Wed May 14 14:13:41 2008 From: dr.diesel at gmail.com (Dr. Diesel) Date: Wed, 14 May 2008 09:13:41 -0500 Subject: Anyone else with hard freezes? In-Reply-To: <2a28d2ab0805131341x6d4d6332nd89e1252839f3866@mail.gmail.com> References: <2a28d2ab0805061455l9afae56p8a86218d08bc4b92@mail.gmail.com> <2a28d2ab0805061530j3a8aa79ehb51d96afedaad644@mail.gmail.com> <1210116098.6222.11.camel@optimus> <2a28d2ab0805081558q3fdb4b94hf41f40db0253f015@mail.gmail.com> <80d7e4090805081625m111b7955v2c96d864275334b2@mail.gmail.com> <2a28d2ab0805081723q6a3537d7n93db59501cf23b16@mail.gmail.com> <2a28d2ab0805090336j78fe2772q1df6283e3c5d38cf@mail.gmail.com> <1210398432.17530.0.camel@optimus> <2a28d2ab0805130448s2b3e8c8aw5e526bd04949d60a@mail.gmail.com> <2a28d2ab0805131341x6d4d6332nd89e1252839f3866@mail.gmail.com> Message-ID: <2a28d2ab0805140713h542598d6y5c010885dac62687@mail.gmail.com> All, it is possible that all of these freezes are caused by a failing hard drive? Perhaps failed during the upgrade from F8 to F9 and its only 3 months old!! Mmmmm, just my luck! Last night I suddenly began to receive Kerneloops after Kerneloops, 4-5 total then it hard locked. When I went to reboot I got the error couldn't find /sys /root etc, couldn't find any of the logical volumes. I tried rebooting it several times and finally it made it to doing an automatic fsck that fails at about 4%. SMART says the HD is fine. I'll have to pull the drive to retrieve and log files, assuming I'm able to read anything! I don't think its a CPU/memory issues as it will run memtest86/folding at home for 12+ hours without errors. This is not an overclocked system. Anyhow, failing HD sound possible? Thanks Andy On Tue, May 13, 2008 at 3:41 PM, Dr. Diesel wrote: > Finally caught something useful!!! Happened again earlier today! > > May 13 11:50:44 localhost dhclient: bound to 192.168.2.37 -- renewal > in 1574 seconds. > May 13 12:11:50 localhost kernel: slideshow[16311]: segfault at 14 ip > 3c69238d5f sp 7fff73f4f31f error 6 in > libX11.so.6.2.0[3c69200000+106000] > May 13 12:15:07 localhost kernel: slideshow[16576]: segfault at 14 ip > 3c69238d5f sp 7fff680a647f error 6 in > libX11.so.6.2.0[3c69200000+106000] > May 13 12:16:58 localhost dhclient: DHCPREQUEST on eth1 to 192.168.2.10 port 67 > May 13 12:16:58 localhost dhclient: DHCPACK from 192.168.2.10 > May 13 12:16:58 localhost dhclient: bound to 192.168.2.37 -- renewal > in 1544 seconds. > May 13 12:25:07 localhost kernel: slideshow[16842]: segfault at 14 ip > 3c69238d5f sp 7fff52abbe8f error 6 in > libX11.so.6.2.0[3c69200000+106000] > May 13 12:35:07 localhost kernel: slideshow[17107]: segfault at 14 ip > 3c69238d5f sp 7fff907edbcf error 6 in > libX11.so.6.2.0[3c69200000+106000] > May 13 14:11:42 localhost kernel: imklog 3.14.1, log source = > /proc/kmsg started. > > Andy > > > > On Tue, May 13, 2008 at 7:48 AM, Dr. Diesel wrote: > > I'm on my longest run without a crash, the only thing different is I > > disabled ntpd and avahi-daemon. > > > > Andy > > > > > > > > On Sat, May 10, 2008 at 12:47 AM, Dave Airlie wrote: > > > > > > > > > On Fri, 2008-05-09 at 05:36 -0500, Dr. Diesel wrote: > > > > Ok, that wasn't it either! > > > > > > try booting with nohz maybe. > > > > > > crazy but worth a go. > > > > > > Dave. > > > > > > > > > > > > -- > > > fedora-devel-list mailing list > > > fedora-devel-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > > > > > > > -- > > > > > > projecthuh.com > > All of my bits are free, are yours? Fedoraproject.org > > > > > > -- > projecthuh.com > All of my bits are free, are yours? Fedoraproject.org > -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org From denis at poolshark.org Wed May 14 14:20:29 2008 From: denis at poolshark.org (Denis Leroy) Date: Wed, 14 May 2008 16:20:29 +0200 Subject: Anyone else with hard freezes? In-Reply-To: <2a28d2ab0805140713h542598d6y5c010885dac62687@mail.gmail.com> References: <2a28d2ab0805061455l9afae56p8a86218d08bc4b92@mail.gmail.com> <2a28d2ab0805061530j3a8aa79ehb51d96afedaad644@mail.gmail.com> <1210116098.6222.11.camel@optimus> <2a28d2ab0805081558q3fdb4b94hf41f40db0253f015@mail.gmail.com> <80d7e4090805081625m111b7955v2c96d864275334b2@mail.gmail.com> <2a28d2ab0805081723q6a3537d7n93db59501cf23b16@mail.gmail.com> <2a28d2ab0805090336j78fe2772q1df6283e3c5d38cf@mail.gmail.com> <1210398432.17530.0.camel@optimus> <2a28d2ab0805130448s2b3e8c8aw5e526bd04949d60a@mail.gmail.com> <2a28d2ab0805131341x6d4d6332nd89e1252839f3866@mail.gmail.com> <2a28d2ab0805140713h542598d6y5c010885dac62687@mail.gmail.com> Message-ID: <482AF52D.1080509@poolshark.org> Dr. Diesel wrote: > All, it is possible that all of these freezes are caused by a failing > hard drive? Perhaps failed during the upgrade from F8 to F9 and its > only 3 months old!! Mmmmm, just my luck! > > Last night I suddenly began to receive Kerneloops after Kerneloops, > 4-5 total then it hard locked. When I went to reboot I got the error > couldn't find /sys /root etc, couldn't find any of the logical > volumes. I tried rebooting it several times and finally it made it to > doing an automatic fsck that fails at about 4%. SMART says the HD is > fine. Note that the overall SMART health status is near useless. What you should do is look at the disk error log : # smartctl -l error /dev/sda and run a short and/or long self test (short is couple of mins, long is typically 1 to 2 hours): # smartctl -t long /dev/sda # smartctl -t short /dev/sda Results of the self test after completion: # smartctl -l selftest /dev/sda You may want to do this from a live CD if your system is really unstable. From mmcgrath at redhat.com Wed May 14 14:26:12 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 14 May 2008 09:26:12 -0500 (CDT) Subject: Outage Notification - 2008-05-14 13:15 UTC Message-ID: There will be an outage starting at 2008-05-14 13:15 UTC, which will last approximately 1 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2008-05-14 13:15 UTC' Affected Services: Buildsystem Database Unaffected Services: Websites CVS / Source Control DNS Mail Torrent Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/545 Reason for Outage: Large spike in db2 load of unknown cause. Looking further. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From txtoth at gmail.com Wed May 14 14:45:40 2008 From: txtoth at gmail.com (Xavier Toth) Date: Wed, 14 May 2008 09:45:40 -0500 Subject: remote desktop access problem in FC9 preview Message-ID: I'm having problems getting the remote desktop to work in FC9 preview. I've configured it to allow access and disabled the firewall but when I use vncviewer :0 it fails with "no route to host". If I try and telnet to :5900 I get "connection refused". Anyone got this working? I'm not finding and man pages or docs for vino-server where are they? -------------- next part -------------- An HTML attachment was scrubbed... URL: From galibert at pobox.com Wed May 14 14:58:09 2008 From: galibert at pobox.com (Olivier Galibert) Date: Wed, 14 May 2008 16:58:09 +0200 Subject: rhgb no more In-Reply-To: <1210772999.28428.21.camel@localhost.localdomain> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> <20080514125839.GA73283@dspnet.fr.eu.org> <1210772999.28428.21.camel@localhost.localdomain> Message-ID: <20080514145809.GA93579@dspnet.fr.eu.org> On Wed, May 14, 2008 at 09:49:59AM -0400, Simo Sorce wrote: > > On Wed, 2008-05-14 at 14:58 +0200, Olivier Galibert wrote: > > And, the usual rhetorical question, why so much people like the idea > > of forcibly ensuring that the users won't learn anything, ever? > > Users don't want to "learn", why should you FORCE users to "learn" > something ? I'm not forcing them to learn anything, I'm just giving them the opportunity. Some people seem to be bent on ensuring that such an opportunity will *not* be presented, ever, by reducing the amount of presented information to the absolute minimum necessary for survival if everything goes well, and sometimes even less than that. And it looks like my users are not your users. Pretty much everybody new to linux I've seen like to learn, especially when it's incidental to their use. They even like the text messages, because the green "OK" boxes give them confidence that all is going well, the waiting is perfectly normal, the computer just has a lot of things to do. Even the occasional red error message is good. It pushes them to ask questions about it (to friends, to google, to forums), makes them understand a little more about their computer, and they *like* that. Probably something about being in control and informed rather than handled and considered unable to understand. Which is a feeling I've heard numerous times about the windows environment and its applications. "It says there's an error and I have to call my administrator and nothing unseful. What am I supposed to do? I don't have an administrator, it's my computer I paid for." > I personally like the option of *not* seeing ugly text messages at boot, > even if I perfectly understand what they mean and find them useful when > there is an error. If you find information ugly, why do you use a computer? An icon blinking for a while with nothing else seemingly happening and with no other information, _now_ that's ugly. OG. From pertusus at free.fr Wed May 14 15:10:45 2008 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 14 May 2008 17:10:45 +0200 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <1210766570.26792.1016.camel@beck.corsepiu.local> References: <1210045081.4658.7.camel@localhost.localdomain> <481FD3D5.5070206@ncsu.edu> <48207309.3040403@redhat.com> <1210321932.26792.817.camel@beck.corsepiu.local> <4824184A.1010508@redhat.com> <4824856E.3080109@gmail.com> <3r9of5xq9c.ln2@ppp1053.in.ipex.cz> <4829B803.3080802@gmail.com> <482AC827.7030205@redhat.com> <1210766570.26792.1016.camel@beck.corsepiu.local> Message-ID: <20080514151045.GA2570@free.fr> On Wed, May 14, 2008 at 02:02:50PM +0200, Ralf Corsepius wrote: > > It would have forced upstreams to learn about their long-term > lazyness/sloppyness is going to evolve into "badness" by being > confronted with a "the train has left the station" effect. Packages that has not been released since long can still use old autotools version without that being an issue. And then it is practical to be able to rerun the autotools for such packages. -- Pat From rawhide at fedoraproject.org Wed May 14 15:12:23 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Wed, 14 May 2008 15:12:23 +0000 (UTC) Subject: rawhide report: 20080514 changes Message-ID: <20080514151224.172DB209D1F@releng1.fedora.phx.redhat.com> Excluding Packages in global exclude list Finished Excluding Packages in global exclude list Finished New package perl-HTTP-Cache-Transparent Cache the result of http get-requests persistently New package ocaml-json-static OCaml JSON validator and converter (syntax extension) Removed package rhgb Removed package kaider Updated Packages: firstboot-1.98-1.fc10 --------------------- * Tue May 13 18:00:00 2008 Chris Lumens 1.98-1 - Remove the rhgb interface. - Use subprocess for starting X instead of rhpxl. - Don't run system-config-display from the init if there's no X config file. - Fix tracebacks when trying to chown broken symlinks (#445092). - Set up the keyboard if firstboot is run as a program (#445281). - Lots of updated translations. libxslt-1.1.24-1.fc10 --------------------- * Tue May 13 18:00:00 2008 Daniel Veillard 1.1.24-1.fc10 - release of 1.1.24 - fixes a few bugs including the key initialization problem - tentative fix for multiarch devel problems OpenSceneGraph-2.4.0-2.fc10 --------------------------- * Tue May 13 18:00:00 2008 Ralf Cors??pius - 2.4.0-2 - Add Orion Poplawski's patch to fix building with cmake-2.6.0. * Mon May 12 18:00:00 2008 Ralf Cors??pius - 2.4.0-1 - Upstream update. - Adjust patches to 2.4.0. kdelibs-4.0.72-3.fc10 --------------------- * Tue May 13 18:00:00 2008 Kevin Kofler - 4.0.72-3 - drop no longer needed ALSA default device Phonon hack docbook-dtds-1.0-36.fc10 ------------------------ * Tue May 13 18:00:00 2008 Ondrej Vasik - 1.0-36 - changed License(#445008) control-center-2.23.1-3.fc10 ---------------------------- * Tue May 13 18:00:00 2008 Matthias Clasen - 2.23.1-3 - Rebuild against newer libs openldap-2.4.9-4.fc10 --------------------- * Tue May 13 18:00:00 2008 Jan Safranek 2.4.9-1 - new upstream release - removed unnecessary MigrationTools patches pidgin-2.4.1-3.fc10 ------------------- * Tue May 13 18:00:00 2008 Stu Tomlinson 2.4.1-3 - Rebuild for new evolution-data-server - Clean up default prefs.xml - Enable nautilus integration plugin by default in prefs.xml (#242289) SimGear-1.0.0-4.fc10 -------------------- * Tue May 13 18:00:00 2008 Hans de Goede 1.0.0-4 - Rebuild for new plib soundconverter-1.2.0-1.fc10 --------------------------- * Tue May 13 18:00:00 2008 Denis Leroy - 1.2.0-1 - Update to upstream 1.2.0 gnome-applets-2.23.2-1.fc10 --------------------------- * Tue May 13 18:00:00 2008 Matthias Clasen - 1:2.23.2-1 - Update to 2.23.2 - Drop upstreamed patches rdesktop-1.6.0-1.fc10 --------------------- * Tue May 13 18:00:00 2008 Soren Sandmann - 1.6.0-1 Update to 1.6.0 taskjuggler-2.4.1-0.2.beta2.fc10 -------------------------------- * Tue May 13 18:00:00 2008 Ondrej Vasik - 2.4.1-0.2.beta2 - fixed typo in libs subpackage obsolete (which caused installation troubles) transmission-1.20-1.fc10 ------------------------ * Tue May 13 18:00:00 2008 Denis Leroy - 1.20-1 - Update to upstream 1.20 - Browser opening patch upstreamed - New dependencies (dbus, curl) yasm-0.7.0-1.fc10 ----------------- * Tue May 13 18:00:00 2008 Matthias Saou 0.7.0-1 - Update to 0.7.0. mailman-2.1.10-1.fc10 --------------------- * Mon May 12 18:00:00 2008 Tomas Smetana - 3:2.1.10-1 - new upstream version gtk2-engines-2.15.1-1.fc10 -------------------------- * Tue May 13 18:00:00 2008 Matthias Clasen - 2.15.1-1 - Update to 2.15.1 eog-2.23.2-1.fc10 ----------------- * Tue May 13 18:00:00 2008 Matthias Clasen - 2.23.2-1 - Update to 2.23.2 NetworkManager-0.7.0-0.9.3.svn3667.fc10 --------------------------------------- * Tue May 13 18:00:00 2008 Dan Williams - 1:0.7.0-0.9.3.svn3667 - Restore behavior of marking wifi devices as "down" when disabling wireless - Fix a crash on resume when a VPN was active when going to sleep * Tue May 13 18:00:00 2008 Dan Williams - 1:0.7.0-0.9.3.svn3665 - Fix issues with the Fedora plugin not noticing changes made by system-config-network (rh #444502) - Allow autoconnection of GSM and CDMA connections - Multiple IP address support for user connections - Fixes for Mobile Broadband cards that return line speed on connect - Implement PIN entry for GSM mobile broadband connections - Fix crash when editing unencrypted WiFi connections in the connection editor guile-1.8.5-1.fc10 ------------------ * Tue May 13 18:00:00 2008 Miroslav Lichvar - 5:1.8.5-1 - update to 1.8.5 - fix continuations on ia64 - remove umask setting from scriptlet, rpm sets it now totem-pl-parser-2.23.1-2.fc10 ----------------------------- * Tue May 13 18:00:00 2008 - Bastien Nocera - 2.23.1-2 - Rebuild gnome-desktop-2.23.2-0.2008.05.14.1.fc10 ---------------------------------------- * Wed May 14 18:00:00 2008 Jon McCann - 2.23.2-0.2008.05.14.1 - Update to 2.23.2 snapshot evolution-webcal-2.21.92-2.fc10 ------------------------------- * Tue May 13 18:00:00 2008 Matthew Barnes - 2.21.92-1.fc10 - Rebuild against newer libedataserver. xenner-0.34-1.fc10 ------------------ * Tue May 13 18:00:00 2008 Gerd Hoffmann - 0.34-1.fc10 - update to version 0.34 - wire up -drive cmd line arg (rhbz #445968). - accept & ignore -serial and -parallel (rhbz #445969). - implement stop & cont monitor commands (rhbz #446079). hunspell-sv-1.26-1.fc10 ----------------------- * Tue May 13 18:00:00 2008 Caolan McNamara - 1.26-1 - latest version evolution-sharp-0.17.2-1.fc10 ----------------------------- * Tue May 13 18:00:00 2008 Matthew Barnes - 0.17.2-1.fc10 - Update to 0.17.2. * Mon Apr 21 18:00:00 2008 Matthew Barnes - 0.17.1-1.fc10 - Update to 0.17.1. * Tue Apr 8 18:00:00 2008 Matthew Barnes - 0.16.1-1.fc9 - Restore patches for RH bug #221555 and GNOME bug #516044. Upstream accepted and then rejected the patches because upstream does multilib differently and they don't have a seperate directory configure option for Mono assemblies (I suggested --monodir=DIR but no one seemed interested). speex-1.2-0.9.beta3 ------------------- * Tue May 13 18:00:00 2008 Marcela Maslanova - 1.2-0.9.beta3 - polishing review (many thanks to Matthias Saou) mod_perl-2.0.4-3 ---------------- * Tue May 13 18:00:00 2008 Joe Orton 2.0.4-3 - trim changelog; rebuild * Fri Apr 18 18:00:00 2008 Joe Orton 2.0.4-2 - update to 2.0.4 oxine-0.7.1-1.fc10 ------------------ * Tue May 13 18:00:00 2008 Matthias Saou 0.7.1-1 - Update to 0.7.1. - Convert AUTHORS file to utf-8. blobAndConquer-0.93-1.fc10 -------------------------- * Tue May 13 18:00:00 2008 Hans de Goede 0.93-1 - New upstream release 0.93 anaconda-11.4.1.1-1 ------------------- * Tue May 13 18:00:00 2008 Jeremy Katz - 11.4.1.1-1 - Just call the XStartupCB() function directly and randr to the desired resolution (katzj) - Stop writing out an xorg.conf (katzj) - Make the "dump to removable device" option work in anaconda. (jgranado) gedit-2.23.1-1.fc10 ------------------- * Tue May 13 18:00:00 2008 Matthias Clasen - 1:2.23.1-1 - Update to 2.23.1 * Tue Apr 8 18:00:00 2008 - Bastien Nocera - 1:2.22.1-1 - Update to 2.22.1 logjam-4.5.3-23.fc10 -------------------- * Tue May 13 18:00:00 2008 Tom "spot" Callaway - 4.5.3-23 - add explicit without-xmms conditional (bz 445996) - add configuration option to start in dock (bz 445998) R-hdf5-1.6.6-5.fc10 ------------------- * Tue May 13 18:00:00 2008 Tom "spot" Callaway - 1.6.6-5 - excludearch ppc64, due to bugzilla 445423 sudo-1.6.9p13-6.fc10 -------------------- * Tue May 13 18:00:00 2008 Peter Vrabec 1.6.9p13-6 - compiled with secure path (#80215) * Mon May 5 18:00:00 2008 Peter Vrabec 1.6.9p13-5 - fix path to updatedb in /etc/sudoers (#445103) gtkhtml3-3.23.2-4.fc10 ---------------------- * Tue May 13 18:00:00 2008 Matthew Barnes - 3.23.2-4.fc10 - Add patch for GNOME bug #524338 (mail flickers when rendering). gnome-games-2.23.1-2.fc10 ------------------------- * Sun May 11 18:00:00 2008 Matthias Clasen - 1:2.23.1-2 - Add missing Requires for gnome-sudoko (#445941) chess-1.0-14.fc10 ----------------- * Tue May 13 18:00:00 2008 Hans de Goede 1.0-14 - Rebuild for new ogre evolution-data-server-2.23.2-2.fc10 ----------------------------------- * Tue May 13 18:00:00 2008 Matthew Barnes - 2.23.2-2.fc10 - Fix some third-party package breakage caused by libebackend. cheese-2.23.2-1.fc10 -------------------- * Tue May 13 18:00:00 2008 Matthias Clasen 2.23.2-1 - Update to 2.23.2 gnome-settings-daemon-2.23.1.1-5.fc10 ------------------------------------- * Tue May 13 18:00:00 2008 Matthias Clasen - 2.23.1-1-5 - Rebuild orca-2.23.2-1.fc10 ------------------ * Tue May 13 18:00:00 2008 Matthias Clasen - 2.23.2-1 - Update to 2.23.2 * Sun May 4 18:00:00 2008 Matthias Clasen - 2.23.1-2 - Fix source url mythes-de-0.20080513-1.fc10 --------------------------- * Tue May 13 18:00:00 2008 Caolan McNamara - 0.20080513-1 - latest version FlightGear-1.0.0-3.fc10 ----------------------- * Tue May 13 18:00:00 2008 Fabrice Bellet 1.0.0-3 - rebuild with newer plib bind-9.5.0-32.b3.fc10 --------------------- * Tue May 13 18:00:00 2008 Adam Tkac 32:9.5.0-32.b3 - reverted "any" patch, upstream says not needed - log EDNS failure only when we really switch to plain EDNS (#275091) - detect configuration file better * Tue May 6 18:00:00 2008 Adam Tkac 32:9.5.0-31.1.b3 - addresses 0.0.0.0 and ::0 really match any (#275091, comment #28) pango-1.21.1-1.fc10 ------------------- * Tue May 13 18:00:00 2008 Matthias Clasen - 1.21.1-1 - Update to 1.21.1 python-sqlobject-0.10.1-1.fc10 ------------------------------ * Tue May 13 18:00:00 2008 Luke Macken 0.10.1-1 - Update to 0.10.1 preupgrade-0.9.3-3.fc10 ----------------------- * Tue May 13 18:00:00 2008 Will Woods - 0.9.3-3 - Fix hang on "Downloading installer metadata" (bug #446244) * Tue May 13 18:00:00 2008 Seth Vidal - 0.9.3-2 - enable F9 in releases.list vegastrike-0.5.0-2.fc10 ----------------------- * Tue May 13 18:00:00 2008 Hans de Goede 0.5.0-2 - Rebuild for new ogre gnome-screensaver-2.22.1-2.fc10 ------------------------------- * Tue May 13 18:00:00 2008 Matthias Clasen - 2.22.1-2 - Rebuild supertuxkart-0.4-2.fc10 ----------------------- * Tue May 13 18:00:00 2008 Hans de Goede 0.4-2 - Rebuild for new plib mysql++-3.0.3-1.fc10 -------------------- * Tue May 13 18:00:00 2008 Remi Collet 3.0.3-1 - update to 3.0.3 - add mysql++-3.0.3-mystring.patch for x86_64 build fgfs-Atlas-0.3.1-9.fc10 ----------------------- * Tue May 13 18:00:00 2008 Fabrice Bellet 0.3.1-9 - rebuild with newer plib hplip-2.8.2-3.fc10 ------------------ * Tue May 13 18:00:00 2008 Tim Waugh 2.8.2-3 - Move installer directory to main package (bug #446171). ppp-2.4.4-7.fc10 ---------------- * Tue May 13 18:00:00 2008 Martin Nagy 2.4.4-7 - add new speeds, patch by Jason Vas Dias (#446132) qt-4.4.0-2.fc10 --------------- * Tue May 13 18:00:00 2008 Kevin Kofler 4.4.0-2 - revert _qt4_bindir change for now, needs more work (#446167) xmlto-0.0.20-3.fc10 ------------------- * Tue May 13 18:00:00 2008 Ondrej Vasik - 0.0.20-3 - fixed errorneus handling of backend stylesheet(#446092) - removed unused patches stormbaancoureur-2.1.4-1.fc10 ----------------------------- * Tue May 13 18:00:00 2008 Hans de Goede 2.1.4-1 - new upstream release 2.1.4 - Rebuild for new plib hunspell-pl-0.20080513-1.fc10 ----------------------------- * Tue May 13 18:00:00 2008 Caolan McNamara - 0.20080513-1 - latest version mythes-pl-1.5-1.fc10 -------------------- * Tue May 13 18:00:00 2008 Caolan McNamara - 1.5-1 - latest version syncevolution-0.7-2.fc10 ------------------------ hdf5-1.8.0.snap5-2.fc10 ----------------------- * Tue May 13 18:00:00 2008 Orion Poplawski 1.8.0.snap5-2 - Use new %{_fmoddir} macro - Re-enable ppc64, disable failing tests. Failing tests are for experimental long double support. ogre-1.4.8-1.fc10 ----------------- * Tue May 13 18:00:00 2008 Hans de Goede 1.4.8-1 - New upstream release 1.4.8 - Warning as always with a new upstream ogre release this breaks the ABI and changes the soname! mousetweaks-2.23.2-1.fc10 ------------------------- * Tue May 13 18:00:00 2008 Matthias Clasen - 2.23.2-1 - Update to 2.23.2 upstart-0.3.9-19.fc10 --------------------- * Fri Apr 25 18:00:00 2008 Bill Nottingham - 0.3.9-19 - with the merge of event-compat-sysv, move the sysvinit obsoletes/provides here hunspell-gl-0.20080410-1.fc10 ----------------------------- * Wed Apr 16 18:00:00 2008 Caolan McNamara - 0.20080410-1 - latest dictionaries Summary: Added Packages: 2 Removed Packages: 2 Modified Packages: 66 Broken deps for i386 ---------------------------------------------------------- LabPlot-1.5.1.6-4.fc8.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libMagick.so.10 autotrace-0.31.1-16.fc9.i386 requires libWand.so.10 autotrace-0.31.1-16.fc9.i386 requires libMagick.so.10 brasero-0.7.1-3.fc9.i386 requires libtotem-plparser.so.10 1:bug-buddy-2.22.0-2.fc9.i386 requires libedataserver-1.2.so.9 contact-lookup-applet-0.16-5.fc9.i386 requires libedataserver-1.2.so.9 contacts-0.8-3.fc9.i386 requires libedataserver-1.2.so.9 dates-0.4.5-2.fc9.i386 requires libedataserver-1.2.so.9 drawtiming-0.6.2-3.fc9.i386 requires libMagick++.so.10 drawtiming-0.6.2-3.fc9.i386 requires libWand.so.10 drawtiming-0.6.2-3.fc9.i386 requires libMagick.so.10 dx-4.4.4-6.fc9.i386 requires libWand.so.10 dx-4.4.4-6.fc9.i386 requires libMagick.so.10 dx-libs-4.4.4-6.fc9.i386 requires libWand.so.10 dx-libs-4.4.4-6.fc9.i386 requires libMagick.so.10 empathy-0.23.1-2.fc10.i386 requires libedataserver-1.2.so.9 empathy-libs-0.23.1-2.fc10.i386 requires libedataserver-1.2.so.9 evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-python-0.0.4-3.fc9.i386 requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.i386 requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-1.2.so.11 gdl-0.9-0.rc1.1.fc9.i386 requires libMagick++.so.10 glabels-2.2.2-1.fc9.i386 requires libedataserver-1.2.so.9 gnome-launch-box-0.4-8.fc9.i386 requires libedataserver-1.2.so.9 gnome-panel-2.23.1-1.fc10.i386 requires libedataserver-1.2.so.9 gnome-phone-manager-0.51-1.fc9.i386 requires libedataserver-1.2.so.9 gnome-python2-evolution-2.22.0-2.fc9.i386 requires libedataserver-1.2.so.9 gnome-python2-totem-2.22.0-2.fc9.i386 requires libtotem-plparser.so.10 gossip-0.29-1.fc10.i386 requires libedataserver-1.2.so.9 imageinfo-0.05-3.fc9.i386 requires libWand.so.10 imageinfo-0.05-3.fc9.i386 requires libMagick.so.10 k3d-0.6.7.0-6.fc9.i386 requires libMagick++.so.10 k3d-0.6.7.0-6.fc9.i386 requires libMagick.so.10 k3d-0.6.7.0-6.fc9.i386 requires libWand.so.10 kismet-extras-0.0.2007.10.R1-3.fc9.i386 requires libMagick.so.10 koffice-karbon-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-karbon-1.6.3-15.fc9.i386 requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libMagick.so.10 libfprint-0.0.5-3.fc9.i386 requires libWand.so.10 libfprint-0.0.5-3.fc9.i386 requires libMagick.so.10 libopensync-plugin-evolution2-0.35-3.fc9.i386 requires libedataserver-1.2.so.9 nautilus-sendto-0.14.0-1.fc9.i386 requires libedataserver-1.2.so.9 nip2-7.14.1-1.fc9.i386 requires libWand.so.10 nip2-7.14.1-1.fc9.i386 requires libMagick.so.10 1:openoffice.org-core-2.4.0-12.8.fc9.i386 requires libhunspell.so.1 1:osgal-0.6.1-3.fc9.i386 requires libosg.so.25 1:osgal-0.6.1-3.fc9.i386 requires libosgTerrain.so.25 1:osgal-0.6.1-3.fc9.i386 requires libosgViewer.so.25 1:osgal-0.6.1-3.fc9.i386 requires libosgDB.so.25 1:osgal-0.6.1-3.fc9.i386 requires libOpenThreads.so.9 1:osgal-0.6.1-3.fc9.i386 requires libosgText.so.25 1:osgal-0.6.1-3.fc9.i386 requires libosgFX.so.25 1:osgal-0.6.1-3.fc9.i386 requires libosgSim.so.25 1:osgal-0.6.1-3.fc9.i386 requires libosgParticle.so.25 1:osgal-0.6.1-3.fc9.i386 requires libosgManipulator.so.25 1:osgal-0.6.1-3.fc9.i386 requires libosgGA.so.25 1:osgal-0.6.1-3.fc9.i386 requires libosgUtil.so.25 osgcal-0.1.46-5.fc9.i386 requires libosgTerrain.so.25 osgcal-0.1.46-5.fc9.i386 requires libosgViewer.so.25 osgcal-0.1.46-5.fc9.i386 requires libOpenThreads.so.9 osgcal-0.1.46-5.fc9.i386 requires libosg.so.25 osgcal-0.1.46-5.fc9.i386 requires libosgText.so.25 osgcal-0.1.46-5.fc9.i386 requires libosgDB.so.25 osgcal-0.1.46-5.fc9.i386 requires libosgFX.so.25 osgcal-0.1.46-5.fc9.i386 requires libosgSim.so.25 osgcal-0.1.46-5.fc9.i386 requires libosgParticle.so.25 osgcal-0.1.46-5.fc9.i386 requires libosgManipulator.so.25 osgcal-0.1.46-5.fc9.i386 requires libosgGA.so.25 osgcal-0.1.46-5.fc9.i386 requires libosgUtil.so.25 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) php-magickwand-1.0.7-1.fc10.i386 requires libWand.so.10 php-magickwand-1.0.7-1.fc10.i386 requires libMagick.so.10 planner-eds-0.14.3-1.fc10.i386 requires libcamel-provider-1.2.so.11 planner-eds-0.14.3-1.fc10.i386 requires libedataserver-1.2.so.9 planner-eds-0.14.3-1.fc10.i386 requires libcamel-1.2.so.11 poker3d-1.1.36-9.fc9.i386 requires libosgTerrain.so.25 poker3d-1.1.36-9.fc9.i386 requires libosgViewer.so.25 poker3d-1.1.36-9.fc9.i386 requires libosgDB.so.25 poker3d-1.1.36-9.fc9.i386 requires libOpenThreads.so.9 poker3d-1.1.36-9.fc9.i386 requires libosgGA.so.25 poker3d-1.1.36-9.fc9.i386 requires libosg.so.25 poker3d-1.1.36-9.fc9.i386 requires libosgText.so.25 poker3d-1.1.36-9.fc9.i386 requires libosgFX.so.25 poker3d-1.1.36-9.fc9.i386 requires libosgSim.so.25 poker3d-1.1.36-9.fc9.i386 requires libosgParticle.so.25 poker3d-1.1.36-9.fc9.i386 requires libosgManipulator.so.25 poker3d-1.1.36-9.fc9.i386 requires libosgUtil.so.25 psiconv-0.9.8-1.fc8.i386 requires libWand.so.10 psiconv-0.9.8-1.fc8.i386 requires libMagick.so.10 pstoedit-3.45-2.fc9.i386 requires libMagick++.so.10 pstoedit-3.45-2.fc9.i386 requires libWand.so.10 pstoedit-3.45-2.fc9.i386 requires libMagick.so.10 q-7.10-3.fc9.i386 requires libMagick.so.10 qgis-0.9.1-5.fc9.i386 requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.i386 requires libgeos.so.2 rhythmbox-0.11.5-9.fc9.i386 requires libtotem-plparser.so.10 sunbird-0.8-3.fc9.i386 requires libhunspell.so.1 tasks-0.12-2.fc9.i386 requires libedataserver-1.2.so.9 theora-tools-1.0beta3-1.fc10.i386 requires libtheoraenc.so.1(libtheoraenc_1.0) theora-tools-1.0beta3-1.fc10.i386 requires libtheoraenc.so.1 thunderbird-lightning-0.8-3.fc9.i386 requires libhunspell.so.1 torcs-1.3.0-6.fc9.i386 requires libplibssgaux.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibssg.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibsl.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibsm.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibsg.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibul.so.1.8.4 totem-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 totem-mozplugin-2.23.2-2.fc9.i386 requires libtotem-plparser-mini.so.10 totem-mozplugin-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 totem-nautilus-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 vips-7.14.1-1.fc9.i386 requires libWand.so.10 vips-7.14.1-1.fc9.i386 requires libMagick.so.10 vips-python-7.14.1-1.fc9.i386 requires libWand.so.10 vips-python-7.14.1-1.fc9.i386 requires libMagick.so.10 vips-tools-7.14.1-1.fc9.i386 requires libWand.so.10 vips-tools-7.14.1-1.fc9.i386 requires libMagick.so.10 xastir-1.9.2-4.fc9.i386 requires libWand.so.10 xastir-1.9.2-4.fc9.i386 requires libMagick.so.10 xulrunner-1.9-0.60.cvs20080414.fc10.i386 requires libhunspell.so.1 Broken deps for x86_64 ---------------------------------------------------------- LabPlot-1.5.1.6-4.fc8.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libMagick.so.10 LabPlot-1.5.1.6-4.fc8.x86_64 requires libMagick++.so.10()(64bit) LabPlot-1.5.1.6-4.fc8.x86_64 requires libMagick.so.10()(64bit) LabPlot-1.5.1.6-4.fc8.x86_64 requires libWand.so.10()(64bit) autotrace-0.31.1-16.fc9.i386 requires libWand.so.10 autotrace-0.31.1-16.fc9.i386 requires libMagick.so.10 autotrace-0.31.1-16.fc9.x86_64 requires libWand.so.10()(64bit) autotrace-0.31.1-16.fc9.x86_64 requires libMagick.so.10()(64bit) brasero-0.7.1-3.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) 1:bug-buddy-2.22.0-2.fc9.i386 requires libedataserver-1.2.so.9 1:bug-buddy-2.22.0-2.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) contact-lookup-applet-0.16-5.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) contacts-0.8-3.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) dates-0.4.5-2.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) drawtiming-0.6.2-3.fc9.x86_64 requires libWand.so.10()(64bit) drawtiming-0.6.2-3.fc9.x86_64 requires libMagick++.so.10()(64bit) drawtiming-0.6.2-3.fc9.x86_64 requires libMagick.so.10()(64bit) dx-4.4.4-6.fc9.x86_64 requires libMagick.so.10()(64bit) dx-4.4.4-6.fc9.x86_64 requires libWand.so.10()(64bit) dx-libs-4.4.4-6.fc9.i386 requires libWand.so.10 dx-libs-4.4.4-6.fc9.i386 requires libMagick.so.10 dx-libs-4.4.4-6.fc9.x86_64 requires libMagick.so.10()(64bit) dx-libs-4.4.4-6.fc9.x86_64 requires libWand.so.10()(64bit) empathy-0.23.1-2.fc10.x86_64 requires libedataserver-1.2.so.9()(64bit) empathy-libs-0.23.1-2.fc10.i386 requires libedataserver-1.2.so.9 empathy-libs-0.23.1-2.fc10.x86_64 requires libedataserver-1.2.so.9()(64bit) evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libWand.so.10()(64bit) evolution-python-0.0.4-3.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx gdl-0.9-0.rc1.1.fc9.x86_64 requires libMagick++.so.10()(64bit) glabels-2.2.2-1.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) gnome-launch-box-0.4-8.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) gnome-panel-2.23.1-1.fc10.x86_64 requires libedataserver-1.2.so.9()(64bit) gnome-phone-manager-0.51-1.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) gnome-python2-evolution-2.22.0-2.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) gnome-python2-totem-2.22.0-2.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) gossip-0.29-1.fc10.x86_64 requires libedataserver-1.2.so.9()(64bit) imageinfo-0.05-3.fc9.x86_64 requires libWand.so.10()(64bit) imageinfo-0.05-3.fc9.x86_64 requires libMagick.so.10()(64bit) k3d-0.6.7.0-6.fc9.i386 requires libMagick++.so.10 k3d-0.6.7.0-6.fc9.i386 requires libMagick.so.10 k3d-0.6.7.0-6.fc9.i386 requires libWand.so.10 k3d-0.6.7.0-6.fc9.x86_64 requires libMagick.so.10()(64bit) k3d-0.6.7.0-6.fc9.x86_64 requires libWand.so.10()(64bit) k3d-0.6.7.0-6.fc9.x86_64 requires libMagick++.so.10()(64bit) kismet-extras-0.0.2007.10.R1-3.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.x86_64 requires libWand.so.10()(64bit) koffice-libs-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.x86_64 requires libWand.so.10()(64bit) libfprint-0.0.5-3.fc9.i386 requires libWand.so.10 libfprint-0.0.5-3.fc9.i386 requires libMagick.so.10 libfprint-0.0.5-3.fc9.x86_64 requires libWand.so.10()(64bit) libfprint-0.0.5-3.fc9.x86_64 requires libMagick.so.10()(64bit) libopensync-plugin-evolution2-0.35-3.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) nautilus-sendto-0.14.0-1.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) nip2-7.14.1-1.fc9.x86_64 requires libMagick.so.10()(64bit) nip2-7.14.1-1.fc9.x86_64 requires libWand.so.10()(64bit) 1:openoffice.org-core-2.4.0-12.8.fc9.x86_64 requires libhunspell.so.1()(64bit) 1:osgal-0.6.1-3.fc9.i386 requires libosg.so.25 1:osgal-0.6.1-3.fc9.i386 requires libosgTerrain.so.25 1:osgal-0.6.1-3.fc9.i386 requires libosgViewer.so.25 1:osgal-0.6.1-3.fc9.i386 requires libosgDB.so.25 1:osgal-0.6.1-3.fc9.i386 requires libOpenThreads.so.9 1:osgal-0.6.1-3.fc9.i386 requires libosgText.so.25 1:osgal-0.6.1-3.fc9.i386 requires libosgFX.so.25 1:osgal-0.6.1-3.fc9.i386 requires libosgSim.so.25 1:osgal-0.6.1-3.fc9.i386 requires libosgParticle.so.25 1:osgal-0.6.1-3.fc9.i386 requires libosgManipulator.so.25 1:osgal-0.6.1-3.fc9.i386 requires libosgGA.so.25 1:osgal-0.6.1-3.fc9.i386 requires libosgUtil.so.25 1:osgal-0.6.1-3.fc9.x86_64 requires libosgFX.so.25()(64bit) 1:osgal-0.6.1-3.fc9.x86_64 requires libosgGA.so.25()(64bit) 1:osgal-0.6.1-3.fc9.x86_64 requires libosgSim.so.25()(64bit) 1:osgal-0.6.1-3.fc9.x86_64 requires libosgUtil.so.25()(64bit) 1:osgal-0.6.1-3.fc9.x86_64 requires libOpenThreads.so.9()(64bit) 1:osgal-0.6.1-3.fc9.x86_64 requires libosgParticle.so.25()(64bit) 1:osgal-0.6.1-3.fc9.x86_64 requires libosgText.so.25()(64bit) 1:osgal-0.6.1-3.fc9.x86_64 requires libosgDB.so.25()(64bit) 1:osgal-0.6.1-3.fc9.x86_64 requires libosgManipulator.so.25()(64bit) 1:osgal-0.6.1-3.fc9.x86_64 requires libosg.so.25()(64bit) 1:osgal-0.6.1-3.fc9.x86_64 requires libosgTerrain.so.25()(64bit) 1:osgal-0.6.1-3.fc9.x86_64 requires libosgViewer.so.25()(64bit) osgcal-0.1.46-5.fc9.i386 requires libosgTerrain.so.25 osgcal-0.1.46-5.fc9.i386 requires libosgViewer.so.25 osgcal-0.1.46-5.fc9.i386 requires libOpenThreads.so.9 osgcal-0.1.46-5.fc9.i386 requires libosg.so.25 osgcal-0.1.46-5.fc9.i386 requires libosgText.so.25 osgcal-0.1.46-5.fc9.i386 requires libosgDB.so.25 osgcal-0.1.46-5.fc9.i386 requires libosgFX.so.25 osgcal-0.1.46-5.fc9.i386 requires libosgSim.so.25 osgcal-0.1.46-5.fc9.i386 requires libosgParticle.so.25 osgcal-0.1.46-5.fc9.i386 requires libosgManipulator.so.25 osgcal-0.1.46-5.fc9.i386 requires libosgGA.so.25 osgcal-0.1.46-5.fc9.i386 requires libosgUtil.so.25 osgcal-0.1.46-5.fc9.x86_64 requires libosgGA.so.25()(64bit) osgcal-0.1.46-5.fc9.x86_64 requires libosgFX.so.25()(64bit) osgcal-0.1.46-5.fc9.x86_64 requires libosgSim.so.25()(64bit) osgcal-0.1.46-5.fc9.x86_64 requires libosgUtil.so.25()(64bit) osgcal-0.1.46-5.fc9.x86_64 requires libOpenThreads.so.9()(64bit) osgcal-0.1.46-5.fc9.x86_64 requires libosgParticle.so.25()(64bit) osgcal-0.1.46-5.fc9.x86_64 requires libosgText.so.25()(64bit) osgcal-0.1.46-5.fc9.x86_64 requires libosgDB.so.25()(64bit) osgcal-0.1.46-5.fc9.x86_64 requires libosgManipulator.so.25()(64bit) osgcal-0.1.46-5.fc9.x86_64 requires libosg.so.25()(64bit) osgcal-0.1.46-5.fc9.x86_64 requires libosgTerrain.so.25()(64bit) osgcal-0.1.46-5.fc9.x86_64 requires libosgViewer.so.25()(64bit) perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) php-magickwand-1.0.7-1.fc10.x86_64 requires libWand.so.10()(64bit) php-magickwand-1.0.7-1.fc10.x86_64 requires libMagick.so.10()(64bit) planner-eds-0.14.3-1.fc10.x86_64 requires libcamel-provider-1.2.so.11()(64bit) planner-eds-0.14.3-1.fc10.x86_64 requires libcamel-1.2.so.11()(64bit) planner-eds-0.14.3-1.fc10.x86_64 requires libedataserver-1.2.so.9()(64bit) poker3d-1.1.36-9.fc9.x86_64 requires libosgGA.so.25()(64bit) poker3d-1.1.36-9.fc9.x86_64 requires libosgFX.so.25()(64bit) poker3d-1.1.36-9.fc9.x86_64 requires libosgUtil.so.25()(64bit) poker3d-1.1.36-9.fc9.x86_64 requires libOpenThreads.so.9()(64bit) poker3d-1.1.36-9.fc9.x86_64 requires libosgParticle.so.25()(64bit) poker3d-1.1.36-9.fc9.x86_64 requires libosgText.so.25()(64bit) poker3d-1.1.36-9.fc9.x86_64 requires libosgSim.so.25()(64bit) poker3d-1.1.36-9.fc9.x86_64 requires libosgManipulator.so.25()(64bit) poker3d-1.1.36-9.fc9.x86_64 requires libosg.so.25()(64bit) poker3d-1.1.36-9.fc9.x86_64 requires libosgTerrain.so.25()(64bit) poker3d-1.1.36-9.fc9.x86_64 requires libosgDB.so.25()(64bit) poker3d-1.1.36-9.fc9.x86_64 requires libosgViewer.so.25()(64bit) psiconv-0.9.8-1.fc8.i386 requires libWand.so.10 psiconv-0.9.8-1.fc8.i386 requires libMagick.so.10 psiconv-0.9.8-1.fc8.x86_64 requires libWand.so.10()(64bit) psiconv-0.9.8-1.fc8.x86_64 requires libMagick.so.10()(64bit) pstoedit-3.45-2.fc9.i386 requires libMagick++.so.10 pstoedit-3.45-2.fc9.i386 requires libWand.so.10 pstoedit-3.45-2.fc9.i386 requires libMagick.so.10 pstoedit-3.45-2.fc9.x86_64 requires libMagick++.so.10()(64bit) pstoedit-3.45-2.fc9.x86_64 requires libMagick.so.10()(64bit) pstoedit-3.45-2.fc9.x86_64 requires libWand.so.10()(64bit) q-7.10-3.fc9.i386 requires libMagick.so.10 qgis-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) rhythmbox-0.11.5-9.fc9.i386 requires libtotem-plparser.so.10 rhythmbox-0.11.5-9.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) sunbird-0.8-3.fc9.x86_64 requires libhunspell.so.1()(64bit) tasks-0.12-2.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) theora-tools-1.0beta3-1.fc10.x86_64 requires libtheoraenc.so.1(libtheoraenc_1.0)(64bit) theora-tools-1.0beta3-1.fc10.x86_64 requires libtheoraenc.so.1()(64bit) thunderbird-lightning-0.8-3.fc9.x86_64 requires libhunspell.so.1()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibsg.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibul.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibssgaux.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibsm.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibssg.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibsl.so.1.8.4()(64bit) totem-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 totem-2.23.2-2.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.x86_64 requires libtotem-plparser-mini.so.10()(64bit) totem-nautilus-2.23.2-2.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) vips-7.14.1-1.fc9.i386 requires libWand.so.10 vips-7.14.1-1.fc9.i386 requires libMagick.so.10 vips-7.14.1-1.fc9.x86_64 requires libMagick.so.10()(64bit) vips-7.14.1-1.fc9.x86_64 requires libWand.so.10()(64bit) vips-python-7.14.1-1.fc9.x86_64 requires libMagick.so.10()(64bit) vips-python-7.14.1-1.fc9.x86_64 requires libWand.so.10()(64bit) vips-tools-7.14.1-1.fc9.x86_64 requires libMagick.so.10()(64bit) vips-tools-7.14.1-1.fc9.x86_64 requires libWand.so.10()(64bit) xastir-1.9.2-4.fc9.x86_64 requires libMagick.so.10()(64bit) xastir-1.9.2-4.fc9.x86_64 requires libWand.so.10()(64bit) xulrunner-1.9-0.60.cvs20080414.fc10.i386 requires libhunspell.so.1 xulrunner-1.9-0.60.cvs20080414.fc10.x86_64 requires libhunspell.so.1()(64bit) Broken deps for ppc ---------------------------------------------------------- LabPlot-1.5.1.6-4.fc8.ppc requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.ppc requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.ppc requires libMagick.so.10 autotrace-0.31.1-16.fc9.ppc requires libWand.so.10 autotrace-0.31.1-16.fc9.ppc requires libMagick.so.10 autotrace-0.31.1-16.fc9.ppc64 requires libWand.so.10()(64bit) autotrace-0.31.1-16.fc9.ppc64 requires libMagick.so.10()(64bit) brasero-0.7.1-3.fc9.ppc requires libtotem-plparser.so.10 1:bug-buddy-2.22.0-2.fc9.ppc requires libedataserver-1.2.so.9 1:bug-buddy-2.22.0-2.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) contact-lookup-applet-0.16-5.fc9.ppc requires libedataserver-1.2.so.9 contacts-0.8-3.fc9.ppc requires libedataserver-1.2.so.9 dap-netcdf_handler-3.7.8-3.fc9.ppc64 requires libnetcdf.so.4()(64bit) dates-0.4.5-2.fc9.ppc requires libedataserver-1.2.so.9 drawtiming-0.6.2-3.fc9.ppc requires libMagick++.so.10 drawtiming-0.6.2-3.fc9.ppc requires libWand.so.10 drawtiming-0.6.2-3.fc9.ppc requires libMagick.so.10 dx-4.4.4-6.fc9.ppc requires libWand.so.10 dx-4.4.4-6.fc9.ppc requires libMagick.so.10 dx-libs-4.4.4-6.fc9.ppc requires libWand.so.10 dx-libs-4.4.4-6.fc9.ppc requires libMagick.so.10 dx-libs-4.4.4-6.fc9.ppc64 requires libnetcdf.so.4()(64bit) dx-libs-4.4.4-6.fc9.ppc64 requires libMagick.so.10()(64bit) dx-libs-4.4.4-6.fc9.ppc64 requires libWand.so.10()(64bit) empathy-0.23.1-2.fc10.ppc requires libedataserver-1.2.so.9 empathy-libs-0.23.1-2.fc10.ppc requires libedataserver-1.2.so.9 empathy-libs-0.23.1-2.fc10.ppc64 requires libedataserver-1.2.so.9()(64bit) evolution-brutus-1.2.11-2.fc9.ppc requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.ppc requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.ppc requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-python-0.0.4-3.fc9.ppc requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.ppc requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-1.2.so.11 gdal-1.5.1-5.fc9.ppc64 requires libnetcdf.so.4()(64bit) gdl-0.9-0.rc1.1.fc9.ppc requires libMagick++.so.10 glabels-2.2.2-1.fc9.ppc requires libedataserver-1.2.so.9 gnome-launch-box-0.4-8.fc9.ppc requires libedataserver-1.2.so.9 gnome-panel-2.23.1-1.fc10.ppc requires libedataserver-1.2.so.9 gnome-phone-manager-0.51-1.fc9.ppc requires libedataserver-1.2.so.9 gnome-python2-evolution-2.22.0-2.fc9.ppc requires libedataserver-1.2.so.9 gnome-python2-totem-2.22.0-2.fc9.ppc requires libtotem-plparser.so.10 gossip-0.29-1.fc10.ppc requires libedataserver-1.2.so.9 imageinfo-0.05-3.fc9.ppc requires libWand.so.10 imageinfo-0.05-3.fc9.ppc requires libMagick.so.10 k3d-0.6.7.0-6.fc9.ppc requires libMagick++.so.10 k3d-0.6.7.0-6.fc9.ppc requires libMagick.so.10 k3d-0.6.7.0-6.fc9.ppc requires libWand.so.10 k3d-0.6.7.0-6.fc9.ppc64 requires libMagick.so.10()(64bit) k3d-0.6.7.0-6.fc9.ppc64 requires libWand.so.10()(64bit) k3d-0.6.7.0-6.fc9.ppc64 requires libMagick++.so.10()(64bit) kismet-extras-0.0.2007.10.R1-3.fc9.ppc requires libMagick.so.10 koffice-karbon-1.6.3-15.fc9.ppc requires libWand.so.10 koffice-karbon-1.6.3-15.fc9.ppc requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.ppc requires libWand.so.10 koffice-libs-1.6.3-15.fc9.ppc requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) libfprint-0.0.5-3.fc9.ppc requires libWand.so.10 libfprint-0.0.5-3.fc9.ppc requires libMagick.so.10 libfprint-0.0.5-3.fc9.ppc64 requires libWand.so.10()(64bit) libfprint-0.0.5-3.fc9.ppc64 requires libMagick.so.10()(64bit) libopensync-plugin-evolution2-0.35-3.fc9.ppc requires libedataserver-1.2.so.9 nautilus-sendto-0.14.0-1.fc9.ppc requires libedataserver-1.2.so.9 nip2-7.14.1-1.fc9.ppc requires libWand.so.10 nip2-7.14.1-1.fc9.ppc requires libMagick.so.10 1:openoffice.org-core-2.4.0-12.8.fc9.ppc requires libhunspell.so.1 1:osgal-0.6.1-3.fc9.ppc requires libosg.so.25 1:osgal-0.6.1-3.fc9.ppc requires libosgTerrain.so.25 1:osgal-0.6.1-3.fc9.ppc requires libosgViewer.so.25 1:osgal-0.6.1-3.fc9.ppc requires libosgDB.so.25 1:osgal-0.6.1-3.fc9.ppc requires libOpenThreads.so.9 1:osgal-0.6.1-3.fc9.ppc requires libosgText.so.25 1:osgal-0.6.1-3.fc9.ppc requires libosgFX.so.25 1:osgal-0.6.1-3.fc9.ppc requires libosgSim.so.25 1:osgal-0.6.1-3.fc9.ppc requires libosgParticle.so.25 1:osgal-0.6.1-3.fc9.ppc requires libosgManipulator.so.25 1:osgal-0.6.1-3.fc9.ppc requires libosgGA.so.25 1:osgal-0.6.1-3.fc9.ppc requires libosgUtil.so.25 1:osgal-0.6.1-3.fc9.ppc64 requires libosgGA.so.25()(64bit) 1:osgal-0.6.1-3.fc9.ppc64 requires libosgFX.so.25()(64bit) 1:osgal-0.6.1-3.fc9.ppc64 requires libosgSim.so.25()(64bit) 1:osgal-0.6.1-3.fc9.ppc64 requires libosgUtil.so.25()(64bit) 1:osgal-0.6.1-3.fc9.ppc64 requires libOpenThreads.so.9()(64bit) 1:osgal-0.6.1-3.fc9.ppc64 requires libosgParticle.so.25()(64bit) 1:osgal-0.6.1-3.fc9.ppc64 requires libosgText.so.25()(64bit) 1:osgal-0.6.1-3.fc9.ppc64 requires libosgDB.so.25()(64bit) 1:osgal-0.6.1-3.fc9.ppc64 requires libosgManipulator.so.25()(64bit) 1:osgal-0.6.1-3.fc9.ppc64 requires libosg.so.25()(64bit) 1:osgal-0.6.1-3.fc9.ppc64 requires libosgTerrain.so.25()(64bit) 1:osgal-0.6.1-3.fc9.ppc64 requires libosgViewer.so.25()(64bit) osgcal-0.1.46-5.fc9.ppc requires libosgTerrain.so.25 osgcal-0.1.46-5.fc9.ppc requires libosgViewer.so.25 osgcal-0.1.46-5.fc9.ppc requires libosgDB.so.25 osgcal-0.1.46-5.fc9.ppc requires libOpenThreads.so.9 osgcal-0.1.46-5.fc9.ppc requires libosg.so.25 osgcal-0.1.46-5.fc9.ppc requires libosgText.so.25 osgcal-0.1.46-5.fc9.ppc requires libosgFX.so.25 osgcal-0.1.46-5.fc9.ppc requires libosgSim.so.25 osgcal-0.1.46-5.fc9.ppc requires libosgParticle.so.25 osgcal-0.1.46-5.fc9.ppc requires libosgManipulator.so.25 osgcal-0.1.46-5.fc9.ppc requires libosgGA.so.25 osgcal-0.1.46-5.fc9.ppc requires libosgUtil.so.25 osgcal-0.1.46-5.fc9.ppc64 requires libosgGA.so.25()(64bit) osgcal-0.1.46-5.fc9.ppc64 requires libosgFX.so.25()(64bit) osgcal-0.1.46-5.fc9.ppc64 requires libosgSim.so.25()(64bit) osgcal-0.1.46-5.fc9.ppc64 requires libosgUtil.so.25()(64bit) osgcal-0.1.46-5.fc9.ppc64 requires libOpenThreads.so.9()(64bit) osgcal-0.1.46-5.fc9.ppc64 requires libosgParticle.so.25()(64bit) osgcal-0.1.46-5.fc9.ppc64 requires libosgText.so.25()(64bit) osgcal-0.1.46-5.fc9.ppc64 requires libosgDB.so.25()(64bit) osgcal-0.1.46-5.fc9.ppc64 requires libosgManipulator.so.25()(64bit) osgcal-0.1.46-5.fc9.ppc64 requires libosg.so.25()(64bit) osgcal-0.1.46-5.fc9.ppc64 requires libosgTerrain.so.25()(64bit) osgcal-0.1.46-5.fc9.ppc64 requires libosgViewer.so.25()(64bit) perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) php-magickwand-1.0.7-1.fc10.ppc requires libWand.so.10 php-magickwand-1.0.7-1.fc10.ppc requires libMagick.so.10 planner-eds-0.14.3-1.fc10.ppc requires libcamel-provider-1.2.so.11 planner-eds-0.14.3-1.fc10.ppc requires libedataserver-1.2.so.9 planner-eds-0.14.3-1.fc10.ppc requires libcamel-1.2.so.11 poker3d-1.1.36-9.fc9.ppc requires libosgTerrain.so.25 poker3d-1.1.36-9.fc9.ppc requires libosgViewer.so.25 poker3d-1.1.36-9.fc9.ppc requires libosgDB.so.25 poker3d-1.1.36-9.fc9.ppc requires libOpenThreads.so.9 poker3d-1.1.36-9.fc9.ppc requires libosgGA.so.25 poker3d-1.1.36-9.fc9.ppc requires libosg.so.25 poker3d-1.1.36-9.fc9.ppc requires libosgText.so.25 poker3d-1.1.36-9.fc9.ppc requires libosgFX.so.25 poker3d-1.1.36-9.fc9.ppc requires libosgSim.so.25 poker3d-1.1.36-9.fc9.ppc requires libosgParticle.so.25 poker3d-1.1.36-9.fc9.ppc requires libosgManipulator.so.25 poker3d-1.1.36-9.fc9.ppc requires libosgUtil.so.25 psiconv-0.9.8-1.fc8.ppc requires libWand.so.10 psiconv-0.9.8-1.fc8.ppc requires libMagick.so.10 psiconv-0.9.8-1.fc8.ppc64 requires libWand.so.10()(64bit) psiconv-0.9.8-1.fc8.ppc64 requires libMagick.so.10()(64bit) pstoedit-3.45-2.fc9.ppc requires libMagick++.so.10 pstoedit-3.45-2.fc9.ppc requires libWand.so.10 pstoedit-3.45-2.fc9.ppc requires libMagick.so.10 pstoedit-3.45-2.fc9.ppc64 requires libMagick++.so.10()(64bit) pstoedit-3.45-2.fc9.ppc64 requires libMagick.so.10()(64bit) pstoedit-3.45-2.fc9.ppc64 requires libWand.so.10()(64bit) q-7.10-3.fc9.ppc requires libMagick.so.10 q-7.10-3.fc9.ppc64 requires libMagick.so.10()(64bit) qgis-0.9.1-5.fc9.ppc requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.ppc requires libgeos.so.2 rhythmbox-0.11.5-9.fc9.ppc requires libtotem-plparser.so.10 rhythmbox-0.11.5-9.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) sunbird-0.8-3.fc9.ppc requires libhunspell.so.1 tasks-0.12-2.fc9.ppc requires libedataserver-1.2.so.9 theora-tools-1.0beta3-1.fc10.ppc requires libtheoraenc.so.1(libtheoraenc_1.0) theora-tools-1.0beta3-1.fc10.ppc requires libtheoraenc.so.1 thunderbird-lightning-0.8-3.fc9.ppc requires libhunspell.so.1 torcs-1.3.0-6.fc9.ppc requires libplibssgaux.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibssg.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibsl.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibsm.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibsg.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibul.so.1.8.4 totem-2.23.2-2.fc9.ppc requires libtotem-plparser.so.10 totem-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.ppc requires libtotem-plparser-mini.so.10 totem-mozplugin-2.23.2-2.fc9.ppc requires libtotem-plparser.so.10 totem-nautilus-2.23.2-2.fc9.ppc requires libtotem-plparser.so.10 vips-7.14.1-1.fc9.ppc requires libWand.so.10 vips-7.14.1-1.fc9.ppc requires libMagick.so.10 vips-7.14.1-1.fc9.ppc64 requires libMagick.so.10()(64bit) vips-7.14.1-1.fc9.ppc64 requires libWand.so.10()(64bit) vips-python-7.14.1-1.fc9.ppc requires libWand.so.10 vips-python-7.14.1-1.fc9.ppc requires libMagick.so.10 vips-tools-7.14.1-1.fc9.ppc requires libWand.so.10 vips-tools-7.14.1-1.fc9.ppc requires libMagick.so.10 xastir-1.9.2-4.fc9.ppc requires libWand.so.10 xastir-1.9.2-4.fc9.ppc requires libMagick.so.10 xulrunner-1.9-0.60.cvs20080414.fc10.ppc requires libhunspell.so.1 xulrunner-1.9-0.60.cvs20080414.fc10.ppc64 requires libhunspell.so.1()(64bit) Broken deps for ppc64 ---------------------------------------------------------- ScientificPython-2.6-12.fc9.ppc64 requires libnetcdf.so.4()(64bit) autotrace-0.31.1-16.fc9.ppc64 requires libWand.so.10()(64bit) autotrace-0.31.1-16.fc9.ppc64 requires libMagick.so.10()(64bit) brasero-0.7.1-3.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) 1:bug-buddy-2.22.0-2.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) cdo-1.0.8-2.fc9.ppc64 requires libnetcdf.so.4()(64bit) contact-lookup-applet-0.16-5.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) contacts-0.8-3.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) dap-netcdf_handler-3.7.8-3.fc9.ppc64 requires libnetcdf.so.4()(64bit) dates-0.4.5-2.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) drawtiming-0.6.2-3.fc9.ppc64 requires libWand.so.10()(64bit) drawtiming-0.6.2-3.fc9.ppc64 requires libMagick++.so.10()(64bit) drawtiming-0.6.2-3.fc9.ppc64 requires libMagick.so.10()(64bit) dx-4.4.4-6.fc9.ppc64 requires libnetcdf.so.4()(64bit) dx-4.4.4-6.fc9.ppc64 requires libMagick.so.10()(64bit) dx-4.4.4-6.fc9.ppc64 requires libWand.so.10()(64bit) dx-libs-4.4.4-6.fc9.ppc64 requires libnetcdf.so.4()(64bit) dx-libs-4.4.4-6.fc9.ppc64 requires libMagick.so.10()(64bit) dx-libs-4.4.4-6.fc9.ppc64 requires libWand.so.10()(64bit) empathy-0.23.1-2.fc10.ppc64 requires libedataserver-1.2.so.9()(64bit) empathy-libs-0.23.1-2.fc10.ppc64 requires libedataserver-1.2.so.9()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-python-0.0.4-3.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) gdal-1.5.1-5.fc9.ppc64 requires libnetcdf.so.4()(64bit) gdl-0.9-0.rc1.1.fc9.ppc64 requires libMagick++.so.10()(64bit) gdl-0.9-0.rc1.1.fc9.ppc64 requires libnetcdf.so.4()(64bit) glabels-2.2.2-1.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) gnome-launch-box-0.4-8.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) gnome-panel-2.23.1-1.fc10.ppc64 requires libedataserver-1.2.so.9()(64bit) gnome-phone-manager-0.51-1.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) gnome-python2-evolution-2.22.0-2.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) gnome-python2-totem-2.22.0-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) gossip-0.29-1.fc10.ppc64 requires libedataserver-1.2.so.9()(64bit) grace-5.1.21-9.fc9.ppc64 requires libnetcdf.so.4()(64bit) grads-1.9b4-23.fc9.ppc64 requires libnetcdf.so.4()(64bit) imageinfo-0.05-3.fc9.ppc64 requires libWand.so.10()(64bit) imageinfo-0.05-3.fc9.ppc64 requires libMagick.so.10()(64bit) k3d-0.6.7.0-6.fc9.ppc64 requires libMagick.so.10()(64bit) k3d-0.6.7.0-6.fc9.ppc64 requires libWand.so.10()(64bit) k3d-0.6.7.0-6.fc9.ppc64 requires libMagick++.so.10()(64bit) kismet-extras-0.0.2007.10.R1-3.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) kst-netcdf-1.6.0-2.fc10.ppc64 requires libnetcdf_c++.so.4()(64bit) kst-netcdf-1.6.0-2.fc10.ppc64 requires libnetcdf.so.4()(64bit) libfprint-0.0.5-3.fc9.ppc64 requires libWand.so.10()(64bit) libfprint-0.0.5-3.fc9.ppc64 requires libMagick.so.10()(64bit) libopensync-plugin-evolution2-0.35-3.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot nautilus-sendto-0.14.0-1.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) ncview-1.92e-13.fc9.ppc64 requires libnetcdf.so.4()(64bit) netcdf-decoders-5.0.0-1.fc9.ppc64 requires libnetcdf.so.4()(64bit) netcdf-perl-1.2.3-7.fc9.ppc64 requires libnetcdf.so.4()(64bit) nip2-7.14.1-1.fc9.ppc64 requires libMagick.so.10()(64bit) nip2-7.14.1-1.fc9.ppc64 requires libWand.so.10()(64bit) 1:openoffice.org-core-2.4.0-12.8.fc9.ppc64 requires libhunspell.so.1()(64bit) 1:osgal-0.6.1-3.fc9.ppc64 requires libosgGA.so.25()(64bit) 1:osgal-0.6.1-3.fc9.ppc64 requires libosgFX.so.25()(64bit) 1:osgal-0.6.1-3.fc9.ppc64 requires libosgSim.so.25()(64bit) 1:osgal-0.6.1-3.fc9.ppc64 requires libosgUtil.so.25()(64bit) 1:osgal-0.6.1-3.fc9.ppc64 requires libOpenThreads.so.9()(64bit) 1:osgal-0.6.1-3.fc9.ppc64 requires libosgParticle.so.25()(64bit) 1:osgal-0.6.1-3.fc9.ppc64 requires libosgText.so.25()(64bit) 1:osgal-0.6.1-3.fc9.ppc64 requires libosgDB.so.25()(64bit) 1:osgal-0.6.1-3.fc9.ppc64 requires libosgManipulator.so.25()(64bit) 1:osgal-0.6.1-3.fc9.ppc64 requires libosg.so.25()(64bit) 1:osgal-0.6.1-3.fc9.ppc64 requires libosgTerrain.so.25()(64bit) 1:osgal-0.6.1-3.fc9.ppc64 requires libosgViewer.so.25()(64bit) osgcal-0.1.46-5.fc9.ppc64 requires libosgGA.so.25()(64bit) osgcal-0.1.46-5.fc9.ppc64 requires libosgFX.so.25()(64bit) osgcal-0.1.46-5.fc9.ppc64 requires libosgSim.so.25()(64bit) osgcal-0.1.46-5.fc9.ppc64 requires libosgUtil.so.25()(64bit) osgcal-0.1.46-5.fc9.ppc64 requires libOpenThreads.so.9()(64bit) osgcal-0.1.46-5.fc9.ppc64 requires libosgParticle.so.25()(64bit) osgcal-0.1.46-5.fc9.ppc64 requires libosgText.so.25()(64bit) osgcal-0.1.46-5.fc9.ppc64 requires libosgDB.so.25()(64bit) osgcal-0.1.46-5.fc9.ppc64 requires libosgManipulator.so.25()(64bit) osgcal-0.1.46-5.fc9.ppc64 requires libosg.so.25()(64bit) osgcal-0.1.46-5.fc9.ppc64 requires libosgTerrain.so.25()(64bit) osgcal-0.1.46-5.fc9.ppc64 requires libosgViewer.so.25()(64bit) perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 php-magickwand-1.0.7-1.fc10.ppc64 requires libWand.so.10()(64bit) php-magickwand-1.0.7-1.fc10.ppc64 requires libMagick.so.10()(64bit) planner-eds-0.14.3-1.fc10.ppc64 requires libcamel-provider-1.2.so.11()(64bit) planner-eds-0.14.3-1.fc10.ppc64 requires libcamel-1.2.so.11()(64bit) planner-eds-0.14.3-1.fc10.ppc64 requires libedataserver-1.2.so.9()(64bit) poker3d-1.1.36-9.fc9.ppc64 requires libosgGA.so.25()(64bit) poker3d-1.1.36-9.fc9.ppc64 requires libosgFX.so.25()(64bit) poker3d-1.1.36-9.fc9.ppc64 requires libosgUtil.so.25()(64bit) poker3d-1.1.36-9.fc9.ppc64 requires libOpenThreads.so.9()(64bit) poker3d-1.1.36-9.fc9.ppc64 requires libosgParticle.so.25()(64bit) poker3d-1.1.36-9.fc9.ppc64 requires libosgText.so.25()(64bit) poker3d-1.1.36-9.fc9.ppc64 requires libosgSim.so.25()(64bit) poker3d-1.1.36-9.fc9.ppc64 requires libosgManipulator.so.25()(64bit) poker3d-1.1.36-9.fc9.ppc64 requires libosg.so.25()(64bit) poker3d-1.1.36-9.fc9.ppc64 requires libosgTerrain.so.25()(64bit) poker3d-1.1.36-9.fc9.ppc64 requires libosgDB.so.25()(64bit) poker3d-1.1.36-9.fc9.ppc64 requires libosgViewer.so.25()(64bit) ppc64-utils-0.14-2.fc9.ppc64 requires yaboot psiconv-0.9.8-1.fc8.ppc64 requires libWand.so.10()(64bit) psiconv-0.9.8-1.fc8.ppc64 requires libMagick.so.10()(64bit) pstoedit-3.45-2.fc9.ppc64 requires libMagick++.so.10()(64bit) pstoedit-3.45-2.fc9.ppc64 requires libMagick.so.10()(64bit) pstoedit-3.45-2.fc9.ppc64 requires libWand.so.10()(64bit) q-7.10-3.fc9.ppc64 requires libMagick.so.10()(64bit) qgis-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) rhythmbox-0.11.5-9.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) scrip-1.4-9.fc8.ppc64 requires libnetcdf.so.4()(64bit) scrip-1.4-9.fc8.ppc64 requires libnetcdff.so.4()(64bit) sunbird-0.8-3.fc9.ppc64 requires libhunspell.so.1()(64bit) tasks-0.12-2.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) theora-tools-1.0beta3-1.fc10.ppc64 requires libtheoraenc.so.1(libtheoraenc_1.0)(64bit) theora-tools-1.0beta3-1.fc10.ppc64 requires libtheoraenc.so.1()(64bit) thunderbird-lightning-0.8-3.fc9.ppc64 requires libhunspell.so.1()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibsg.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibul.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibsm.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibssgaux.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibssg.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibsl.so.1.8.4()(64bit) totem-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.ppc64 requires libtotem-plparser-mini.so.10()(64bit) totem-nautilus-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) vips-7.14.1-1.fc9.ppc64 requires libMagick.so.10()(64bit) vips-7.14.1-1.fc9.ppc64 requires libWand.so.10()(64bit) vips-python-7.14.1-1.fc9.ppc64 requires libMagick.so.10()(64bit) vips-python-7.14.1-1.fc9.ppc64 requires libWand.so.10()(64bit) vips-tools-7.14.1-1.fc9.ppc64 requires libMagick.so.10()(64bit) vips-tools-7.14.1-1.fc9.ppc64 requires libWand.so.10()(64bit) xastir-1.9.2-4.fc9.ppc64 requires libMagick.so.10()(64bit) xastir-1.9.2-4.fc9.ppc64 requires libWand.so.10()(64bit) xulrunner-1.9-0.60.cvs20080414.fc10.ppc64 requires libhunspell.so.1()(64bit) sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed sending mail failed From buc at odusz.so-cdu.ru Wed May 14 15:29:45 2008 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Wed, 14 May 2008 19:29:45 +0400 Subject: rhgb no more In-Reply-To: <20080514145809.GA93579@dspnet.fr.eu.org> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> <20080514125839.GA73283@dspnet.fr.eu.org> <1210772999.28428.21.camel@localhost.localdomain> <20080514145809.GA93579@dspnet.fr.eu.org> Message-ID: <482B0569.2030605@odu.neva.ru> Olivier Galibert wrote: >> I personally like the option of *not* seeing ugly text messages at boot, >> even if I perfectly understand what they mean and find them useful when >> there is an error. >> > > If you find information ugly, why do you use a computer? An icon > blinking for a while with nothing else seemingly happening and with no > other information, _now_ that's ugly. > > Unfortunately, besides the people like you and me, there are a lot of "Joe Users". Perhaps the term of user (as we understood it in early 90) is not for them. A term of "customer" is for them. For example, customers of RHEL (which is Fedora-based). Surely such kind of users buy RHEL for another tasks, rather than learning of anything. It is discovered that it is better for them to avoid any extra information, "for which they did not pay money directly"... Certainly it must be the option -- whether to see "ugly" messages onboot or not. Personally, I prefer to see it. Perhaps I've simple got used to see it, and I feel more easy when I see that all goes OK immediately. ~buc http://www.fedoraproject.org/wiki/DmitryButskoy From tcallawa at redhat.com Wed May 14 15:57:29 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 14 May 2008 11:57:29 -0400 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <20080514155427.e39ad86d.mschwendt@gmail.com> References: <3118d8de0805131316h55374c5di2b6ad5ed5c4f1b68@mail.gmail.com> <4829FC5B.5030000@gmail.com> <20080514155427.e39ad86d.mschwendt@gmail.com> Message-ID: <1210780649.1920.121.camel@localhost.localdomain> On Wed, 2008-05-14 at 15:54 +0200, Michael Schwendt wrote: > You break with these two "main technical reasons" if you put "jpp" in > the evr only for the third technical reason (i.e. "group operations"). The version ordering described in that policy should meet the two reasons pointed out, even without the jpp in the evr. ~spot From sundaram at fedoraproject.org Wed May 14 15:59:02 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 14 May 2008 21:29:02 +0530 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <482A47C5.4020402@gmail.com> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <1210612643.6285.5.camel@rousalka.okg> <1210613511.12520.46.camel@localhost.localdomain> <1210619487.6844.48.camel@rousalka.okg> <1210621696.12520.62.camel@localhost.localdomain> <1210632587.12173.15.camel@rousalka.okg> <48293492.4020905@gmail.com> <41074.192.54.193.59.1210664862.squirrel@rousalka.dyndns.org> <4829B8D7.7010501@gmail.com> <4829E12A.7060901@gmail.com> <4829E3B0.9090108@redhat.com> <4829F09B.5040500@gmail.com> <4829F3FE.6070203@fedoraproject.org> <4829FCCA.50505@gmail.com> <4829FF0F.7050808@fedoraproject.org> <482A0B44.6050905@gmail.com> <482A0F27.401@fedoraproject.org> <482A123E.6010100@gmail.com> <482A14D4.4080304@fedoraproject.org> <482A22FE.2010509@gmail.com> <482A24EA.7040002@fedoraproject.org> <482A47C5.4020402@gmail.com> Message-ID: <482B0C46.5030409@fedoraproject.org> Les Mikesell wrote: > Rahul Sundaram wrote: > >>> >>> I'm not demanding anything, I am just presenting a user's perspective >>> and from here it looks like you are currently doing extra work to >>> make things different and incompatible. >> >> It doesn't look anything like that if you are paying any attention at >> all. Again, cut the drama. Constantly throwing insults at a project >> just because you have different opinions on how it should be done >> isn't the way to present anything much less act as a user representative. > > I'm trying to be realistic, not insulting. I just think that needing to > use 3rd party apps is common and thus representative for users. How > else is there to present that other than to bring up difficulties? The difficulties are understood and the tools are there. If you want to learn about them, ask in a users list. Rahul From notting at redhat.com Wed May 14 16:07:51 2008 From: notting at redhat.com (Bill Nottingham) Date: Wed, 14 May 2008 12:07:51 -0400 Subject: rawhide report: 20080513 changes (resend) In-Reply-To: <1210765672.3170.98.camel@localhost.localdomain> References: <20080513162213.4468E209D1D@releng1.fedora.phx.redhat.com> <1210758970.6238.10.camel@localhost.localdomain> <1210765672.3170.98.camel@localhost.localdomain> Message-ID: <20080514160751.GA10258@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > The bonus here is > that repodiff is a yum-util and far easier to modify and enhance. Also, it's less than 8 years old. Bill From lesmikesell at gmail.com Wed May 14 16:55:10 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 14 May 2008 11:55:10 -0500 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <482B0C46.5030409@fedoraproject.org> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <1210612643.6285.5.camel@rousalka.okg> <1210613511.12520.46.camel@localhost.localdomain> <1210619487.6844.48.camel@rousalka.okg> <1210621696.12520.62.camel@localhost.localdomain> <1210632587.12173.15.camel@rousalka.okg> <48293492.4020905@gmail.com> <41074.192.54.193.59.1210664862.squirrel@rousalka.dyndns.org> <4829B8D7.7010501@gmail.com> <4829E12A.7060901@gmail.com> <4829E3B0.9090108@redhat.com> <4829F09B.5040500@gmail.com> <4829F3FE.6070203@fedoraproject.org> <4829FCCA.50505@gmail.com> <4829FF0F.7050808@fedoraproject.org> <482A0B44.6050905@gmail.com> <482A0F27.401@fedoraproject.org> <482A123E.6010100@gmail.com> <482A14D4.4080304@fedoraproject.org> <482A22FE.2010509@gmail.com> <482A24EA.7040002@fedoraproject.org> <482A47C5.4020402@gmail.com> <482B0C46.5030409@fedoraproject.org> Message-ID: <482B196E.3010008@gmail.com> Rahul Sundaram wrote: > >>>> I'm not demanding anything, I am just presenting a user's >>>> perspective and from here it looks like you are currently doing >>>> extra work to make things different and incompatible. >>> >>> It doesn't look anything like that if you are paying any attention at >>> all. Again, cut the drama. Constantly throwing insults at a project >>> just because you have different opinions on how it should be done >>> isn't the way to present anything much less act as a user >>> representative. >> >> I'm trying to be realistic, not insulting. I just think that needing >> to use 3rd party apps is common and thus representative for users. >> How else is there to present that other than to bring up difficulties? > > The difficulties are understood and the tools are there. If you want to > learn about them, ask in a users list. The users list might tell me how someone else managed to work around certain difficulties but no one there would be able to help eliminate them or know whether that work-around is expected to be reliable through updates or just happened to work for the person who tried it. And particularly in the case of jpackage I don't see the point. Is it impossible to make the parts you have in common identical or change the names so you have nothing in common? -- Les Mikesell lesmikesell at gmail.com From jonstanley at gmail.com Wed May 14 17:07:47 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Wed, 14 May 2008 13:07:47 -0400 Subject: Tracker bugs created for Fedora 10 milestones and Fedora 11 Message-ID: In line with the triage release SOP, I've just created blocker bugs for Fedora 10 Alpha, Beta, and Preview releases. Trackers are also created for F11 blocker and target bugs. They are aliased in the normal way: - F10Alpha - F10Beta - F10PR - F11Blocker - F11Target Feel free to start planning in advance! :) -- Jon Stanley Fedora Bug Wrangler jstanley at fedoraproject.org _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From sundaram at fedoraproject.org Wed May 14 17:29:32 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 14 May 2008 22:59:32 +0530 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <482B196E.3010008@gmail.com> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <1210612643.6285.5.camel@rousalka.okg> <1210613511.12520.46.camel@localhost.localdomain> <1210619487.6844.48.camel@rousalka.okg> <1210621696.12520.62.camel@localhost.localdomain> <1210632587.12173.15.camel@rousalka.okg> <48293492.4020905@gmail.com> <41074.192.54.193.59.1210664862.squirrel@rousalka.dyndns.org> <4829B8D7.7010501@gmail.com> <4829E12A.7060901@gmail.com> <4829E3B0.9090108@redhat.com> <4829F09B.5040500@gmail.com> <4829F3FE.6070203@fedoraproject.org> <4829FCCA.50505@gmail.com> <4829FF0F.7050808@fedoraproject.org> <482A0B44.6050905@gmail.com> <482A0F27.401@fedoraproject.org> <482A123E.6010100@gmail.com> <482A14D4.4080304@fedoraproject.org> <482A22FE.2010509@gmail.com> <482A24EA.7040002@fedoraproject.org> <482A47C5.4020402@gmail.com> <482B0C46.5030409@fedoraproject.org> <482B196E.3010008@gmail.com> Message-ID: <482B217C.3020300@fedoraproject.org> Les Mikesell wrote: > > The users list might tell me how someone else managed to work around > certain difficulties but no one there would be able to help eliminate > them or know whether that work-around is expected to be reliable through > updates or just happened to work for the person who tried it. And > particularly in the case of jpackage I don't see the point. Is it > impossible to make the parts you have in common identical or change the > names so you have nothing in common? It is not impossible but it is pretty difficult and simplistic solutions just don't work. Fedora just cannot drop all the Java related packages as you wanted for reasons explained in detail earlier. Rahul From rc040203 at freenet.de Wed May 14 15:19:42 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 14 May 2008 17:19:42 +0200 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <20080514151045.GA2570@free.fr> References: <1210045081.4658.7.camel@localhost.localdomain> <481FD3D5.5070206@ncsu.edu> <48207309.3040403@redhat.com> <1210321932.26792.817.camel@beck.corsepiu.local> <4824184A.1010508@redhat.com> <4824856E.3080109@gmail.com> <3r9of5xq9c.ln2@ppp1053.in.ipex.cz> <4829B803.3080802@gmail.com> <482AC827.7030205@redhat.com> <1210766570.26792.1016.camel@beck.corsepiu.local> <20080514151045.GA2570@free.fr> Message-ID: <1210778382.26792.1058.camel@beck.corsepiu.local> On Wed, 2008-05-14 at 17:10 +0200, Patrice Dumas wrote: > On Wed, May 14, 2008 at 02:02:50PM +0200, Ralf Corsepius wrote: > > > > It would have forced upstreams to learn about their long-term > > lazyness/sloppyness is going to evolve into "badness" by being > > confronted with a "the train has left the station" effect. > > Packages that has not been released since long can still use old > autotools version without that being an issue. And then it is practical > to be able to rerun the autotools for such packages. Off-line, yes .. no need to make them part of the distribution. Ralf From jkeating at redhat.com Wed May 14 17:52:48 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 14 May 2008 13:52:48 -0400 Subject: FESCo Proposal for blocking older version of autoconf & automake In-Reply-To: <1210778382.26792.1058.camel@beck.corsepiu.local> References: <1210045081.4658.7.camel@localhost.localdomain> <481FD3D5.5070206@ncsu.edu> <48207309.3040403@redhat.com> <1210321932.26792.817.camel@beck.corsepiu.local> <4824184A.1010508@redhat.com> <4824856E.3080109@gmail.com> <3r9of5xq9c.ln2@ppp1053.in.ipex.cz> <4829B803.3080802@gmail.com> <482AC827.7030205@redhat.com> <1210766570.26792.1016.camel@beck.corsepiu.local> <20080514151045.GA2570@free.fr> <1210778382.26792.1058.camel@beck.corsepiu.local> Message-ID: <1210787568.3170.142.camel@localhost.localdomain> On Wed, 2008-05-14 at 17:19 +0200, Ralf Corsepius wrote: > > Packages that has not been released since long can still use old > > autotools version without that being an issue. And then it is practical > > to be able to rerun the autotools for such packages. > Off-line, yes .. no need to make them part of the distribution. Can you clarify "part of the distribution" here? If they aren't part of the Fedora Distribution, then Fedora suddenly can no longer be a development platform for these projects. This is not what we want. If however you mean not distributed with said project as part of the tarball, then I leave that discussion to somebody else. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From lesmikesell at gmail.com Wed May 14 18:34:47 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 14 May 2008 13:34:47 -0500 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <482B217C.3020300@fedoraproject.org> References: <20080507182919.GB8099@redhat.com> <1210611798.12520.41.camel@localhost.localdomain> <1210612643.6285.5.camel@rousalka.okg> <1210613511.12520.46.camel@localhost.localdomain> <1210619487.6844.48.camel@rousalka.okg> <1210621696.12520.62.camel@localhost.localdomain> <1210632587.12173.15.camel@rousalka.okg> <48293492.4020905@gmail.com> <41074.192.54.193.59.1210664862.squirrel@rousalka.dyndns.org> <4829B8D7.7010501@gmail.com> <4829E12A.7060901@gmail.com> <4829E3B0.9090108@redhat.com> <4829F09B.5040500@gmail.com> <4829F3FE.6070203@fedoraproject.org> <4829FCCA.50505@gmail.com> <4829FF0F.7050808@fedoraproject.org> <482A0B44.6050905@gmail.com> <482A0F27.401@fedoraproject.org> <482A123E.6010100@gmail.com> <482A14D4.4080304@fedoraproject.org> <482A22FE.2010509@gmail.com> <482A24EA.7040002@fedoraproject.org> <482A47C5.4020402@gmail.com> <482B0C46.5030409@fedoraproject.org> <482B196E.3010008@gmail.com> <482B217C.3020300@fedoraproject.or! g> Message-ID: <482B30C7.4040103@gmail.com> Rahul Sundaram wrote: > >> >> The users list might tell me how someone else managed to work around >> certain difficulties but no one there would be able to help eliminate >> them or know whether that work-around is expected to be reliable >> through updates or just happened to work for the person who tried it. >> And particularly in the case of jpackage I don't see the point. Is it >> impossible to make the parts you have in common identical or change >> the names so you have nothing in common? > > It is not impossible but it is pretty difficult and simplistic solutions > just don't work. Fedora just cannot drop all the Java related packages > as you wanted for reasons explained in detail earlier. How about changing the names of the packages (and perhaps the location of the files) that you must include for dependencies? I'd much rather waste space with duplicates that don't conflict than have potentially conflicting same-named packages/files. -- Les Mikesell lesmikesell at gmail.com From sundaram at fedoraproject.org Wed May 14 18:39:21 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 15 May 2008 00:09:21 +0530 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <482B30C7.4040103@gmail.com> References: <1210611798.12520.41.camel@localhost.localdomain> <1210612643.6285.5.camel@rousalka.okg> <1210613511.12520.46.camel@localhost.localdomain> <1210619487.6844.48.camel@rousalka.okg> <1210621696.12520.62.camel@localhost.localdomain> <1210632587.12173.15.camel@rousalka.okg> <48293492.4020905@gmail.com> <41074.192.54.193.59.1210664862.squirrel@rousalka.dyndns.org> <4829B8D7.7010501@gmail.com> <4829E12A.7060901@gmail.com> <4829E3B0.9090108@redhat.com> <4829F09B.5040500@gmail.com> <4829F3FE.6070203@fedoraproject.org> <4829FCCA.50505@gmail.com> <4829FF0F.7050808@fedoraproject.org> <482A0B44.6050905@gmail.com> <482A0F27.401@fedoraproject.org> <482A123E.6010100@gmail.com> <482A14D4.4080304@fedoraproject.org> <482A22FE.2010509@gmail.com> <482A24EA.7040002@fedoraproject.org> <482A47C5.4020402@gmail.com> <482B0C46.5030409@fedoraproject.org> <482B196E.3010008@gmail.com> <482B217C.3020300@fedoraproject.or! g> <482B30C7.4040103@gmail.com> Message-ID: <482B31D9.3050107@fedoraproject.org> Les Mikesell wrote: > How about changing the names of the packages (and perhaps the location > of the files) that you must include for dependencies? I'd much rather > waste space with duplicates that don't conflict than have potentially > conflicting same-named packages/files. That's a ugly hack and won't on all cases. Some paths are just standardized and changing them would break a lot of things including non-packaged applications. You have to figure out specific issues and talk to the Fedora Java team. http://www.redhat.com/mailman/listinfo/fedora-devel-java-list Rahul From pekkas at netcore.fi Wed May 14 18:51:27 2008 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 14 May 2008 21:51:27 +0300 (EEST) Subject: F8->F9 yum upgrade notes: bluecurve lost etc. Message-ID: Hi, I did a yum upgrade (F8->F9) which had some hiccups but nothing major. The first was that because F8 had updated cups and cups-libs after F9 was frozen, the upgrade could not succeed without tweaking until the F9 updates tree had been populated on mirrors. While this is easily solvable in online yum upgrades, this seems a more difficult problem to tackle if you'd try to upgrade offline using just the DVD. After the upgrade, there were some warts but no major problems. A couple notes: - The Bluecurve theme appears to have disappeared in a strange way. When you log in using an old user that had used bluecurve, all windows lacked the header (w/ the buttons) on top. Changing to 'Default' with Settings - Window Manager Settings fixed this, and when I next looked at the settings, bluecurve had already disppeared from selection. Some other user might not have realized what has gone wrong. Shouldn't there be an automatic transition path out if bluecurve no longer works? - At one time, the keyboard responsiveness in X windows disappeared. Each keystroke produced a beep. When you switched to console with CTRL-ALT-F1, you would get constant beeping but the keyboard would work until you switched back. Mouse worked fine; both are USB. I'll see if this problem appears again. - I noticed these "We are not in group 'pulse-rt' and PolicyKit refuse to grant us priviliges. Dropping SUID again." -messages (and other similar ones), but these appear to have originated prior to the upgrade. I wonder why these aren't in the defaults? - I noticed lots of 'too many timeouts resolving 'D.ROOT-SERVERS.NET/AAAA' (in '.'?): disabling EDNS' messages from named, but these also had started prior to the upgrade. I have no DNS munging on the path; these errors appear to coincide with the times when the ADSL line has been down. It would appear that the EDNS disabling code is not very reliable -- non-EDNS queries also time out when this happens. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From greno at verizon.net Wed May 14 19:34:53 2008 From: greno at verizon.net (Gerry Reno) Date: Wed, 14 May 2008 15:34:53 -0400 Subject: F7 intel ich5, alsa, device busy Message-ID: <482B3EDD.4010809@verizon.net> We have a laptop that is running F7 with Intel P4 and ICH5 and alsa. Whenever you boot the laptop it will play audio for a few minutes and then the audio app will get an error about not being able to open the audio channel. I go into soundcard detection and it does not play either. So I select reload audio drivers. This of course requires a reboot and then we're good for another few minutes until the audio driver/device becomes busy again. There is no other audio app running other than the one we are trying to use. I checked for new alsa libs and nothing. This is a truly annoying problem for the user. What is the best option here for sound on this laptop? Regards, Gerry From kevin.kofler at chello.at Wed May 14 19:52:14 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 14 May 2008 19:52:14 +0000 (UTC) Subject: F8->F9 yum upgrade notes: bluecurve lost etc. References: Message-ID: Pekka Savola netcore.fi> writes: > - The Bluecurve theme appears to have disappeared in a strange way. > When you log in using an old user that had used bluecurve, all windows > lacked the header (w/ the buttons) on top. Changing to 'Default' with > Settings - Window Manager Settings fixed this, and when I next looked > at the settings, bluecurve had already disppeared from selection. > Some other user might not have realized what has gone wrong. > Shouldn't there be an automatic transition path out if bluecurve no > longer works? Is that in KDE? The KDE 4 version of the theme is called quarticurve-kwin-theme, it should have replaced the old bluecurve-kwin-theme automatically, you can set the theme in the options. I realize the name change is causing some trouble, but as I did that port on my own without Red Hat's approval, I didn't want to abuse the trademark. If I hadn't done the Quarticurve port, there would be no Bluecurve theme for KWin at all in KDE 4. You can't use KDE 3 themes in KDE 4. Kevin Kofler From mike at cchtml.com Wed May 14 19:57:24 2008 From: mike at cchtml.com (Mike Cronenworth) Date: Wed, 14 May 2008 14:57:24 -0500 Subject: F7 intel ich5, alsa, device busy In-Reply-To: <482B3EDD.4010809@verizon.net> References: <482B3EDD.4010809@verizon.net> Message-ID: <482B4424.8010001@cchtml.com> -------- Original Message -------- Subject: F7 intel ich5, alsa, device busy From: Gerry Reno To: Development discussions related to Fedora Core Date: 05/14/2008 02:34 PM > So I select reload audio drivers. This of course requires a > reboot and then we're good for another few minutes until the audio > driver/device becomes busy again. The sound card config app is useless. Tell the user to ignore it. > What is > the best option here for sound on this laptop? > 1) Use lsof on /dev/snd/pcmC0D0p to see if anything is grabbing onto it. 2) Upgrade to Fedora 9 # rpm -Uhv fedora-release-9.0-2.noarch.rpm # yum update You may say "this is not an option" but there is no other way to get an updated driver for your system unless you want to manually install an F8 or F9 kernel (not recommended). Plus, PulseAudio (in F8 and now F9) may help alleviate his problem. > Regards, > Gerry > From kevin.kofler at chello.at Wed May 14 20:15:05 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 14 May 2008 20:15:05 +0000 (UTC) Subject: F8->F9 yum upgrade notes: bluecurve lost etc. References: Message-ID: Oh, and there's a Qt 4 widget style and a KDE 4 color scheme in the qt4-theme-quarticurve package. Also a README file with a hint how to use the widgetStyle4 hack to set KDE 4 to quarticurve and KDE 3 to bluecurve (again a naming issue). Kevin Kofler From greno at verizon.net Wed May 14 20:19:42 2008 From: greno at verizon.net (Gerry Reno) Date: Wed, 14 May 2008 16:19:42 -0400 Subject: F7 intel ich5, alsa, device busy In-Reply-To: <482B4424.8010001@cchtml.com> References: <482B3EDD.4010809@verizon.net> <482B4424.8010001@cchtml.com> Message-ID: <482B495E.2070307@verizon.net> Mike Cronenworth wrote: > -------- Original Message -------- > Subject: F7 intel ich5, alsa, device busy > From: Gerry Reno > To: Development discussions related to Fedora Core > > Date: 05/14/2008 02:34 PM >> So I select reload audio drivers. This of course requires a reboot >> and then we're good for another few minutes until the audio >> driver/device becomes busy again. > > The sound card config app is useless. Tell the user to ignore it. > > > What is > > the best option here for sound on this laptop? > > > > 1) Use lsof on /dev/snd/pcmC0D0p to see if anything is grabbing onto it. > > 2) Upgrade to Fedora 9 > # rpm -Uhv fedora-release-9.0-2.noarch.rpm > # yum update > > You may say "this is not an option" but there is no other way to get > an updated driver for your system unless you want to manually install > an F8 or F9 kernel (not recommended). Plus, PulseAudio (in F8 and now > F9) may help alleviate his problem. > > > Regards, > > Gerry > > > lsof find firefox got a hold of it. I killed all his firefox windows and then the audio app starts working again. So now, he can use his ip phone but he just can't browse while doing it. ?? Regards, Gerry From lesmikesell at gmail.com Wed May 14 20:38:53 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 14 May 2008 15:38:53 -0500 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <482B31D9.3050107@fedoraproject.org> References: <1210612643.6285.5.camel@rousalka.okg> <1210613511.12520.46.camel@localhost.localdomain> <1210619487.6844.48.camel@rousalka.okg> <1210621696.12520.62.camel@localhost.localdomain> <1210632587.12173.15.camel@rousalka.okg> <48293492.4020905@gmail.com> <41074.192.54.193.59.1210664862.squirrel@rousalka.dyndns.org> <4829B8D7.7010501@gmail.com> <4829E12A.7060901@gmail.com> <4829E3B0.9090108@redhat.com> <4829F09B.5040500@gmail.com> <4829F3FE.6070203@fedoraproject.org> <4829FCCA.50505@gmail.com> <4829FF0F.7050808@fedoraproject.org> <482A0B44.6050905@gmail.com> <482A0F27.401@fedoraproject.org> <482A123E.6010100@gmail.com> <482A14D4.4080304@fedoraproject.org> <482A22FE.2010509@gmail.com> <482A24EA.7040002@fedoraproject.org> <482A47C5.4020402@gmail.com> <482B0C46.5030409@fedoraproject.org> <482B196E.3010008@gmail.com> <482B217C.3020300@fedoraproject.or! g> <482B30C7.4040103@gmail.com> <482B31D9.3050107@fedoraproject.org> Message-ID: <482B4DDD.6000804@gmail.com> Rahul Sundaram wrote: > >> How about changing the names of the packages (and perhaps the location >> of the files) that you must include for dependencies? I'd much rather >> waste space with duplicates that don't conflict than have potentially >> conflicting same-named packages/files. > > That's a ugly hack and won't on all cases. Once you start relying on yum/rpm, there's nothing much uglier than conflicting packages. > Some paths are just > standardized and changing them would break a lot of things including > non-packaged applications. If things are standardized to the point that they can't be changed, then I don't see how keeping those jpackage/fedora versions identical can be such a big problem. > You have to figure out specific issues and > talk to the Fedora Java team. I'd hope there could be a general solution. -- Les Mikesell lesmikesell at gmail.com From sundaram at fedoraproject.org Wed May 14 20:45:15 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 15 May 2008 02:15:15 +0530 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <482B4DDD.6000804@gmail.com> References: <1210613511.12520.46.camel@localhost.localdomain> <1210619487.6844.48.camel@rousalka.okg> <1210621696.12520.62.camel@localhost.localdomain> <1210632587.12173.15.camel@rousalka.okg> <48293492.4020905@gmail.com> <41074.192.54.193.59.1210664862.squirrel@rousalka.dyndns.org> <4829B8D7.7010501@gmail.com> <4829E12A.7060901@gmail.com> <4829E3B0.9090108@redhat.com> <4829F09B.5040500@gmail.com> <4829F3FE.6070203@fedoraproject.org> <4829FCCA.50505@gmail.com> <4829FF0F.7050808@fedoraproject.org> <482A0B44.6050905@gmail.com> <482A0F27.401@fedoraproject.org> <482A123E.6010100@gmail.com> <482A14D4.4080304@fedoraproject.org> <482A22FE.2010509@gmail.com> <482A24EA.7040002@fedoraproject.org> <482A47C5.4020402@gmail.com> <482B0C46.5030409@fedoraproject.org> <482B196E.3010008@gmail.com> <482B217C.3020300@fedoraproject.or! g> <482B30C7.4040103@gmail.com> <482B31D9.3050107@fedoraproject.org> <482B4DDD.6000804@gmail.com> Message-ID: <482B4F5B.6040005@fedoraproject.org> Les Mikesell wrote: > > Once you start relying on yum/rpm, there's nothing much uglier than > conflicting packages. Conflicting third party repo/packages are for distributions regardless of the package manager. > If things are standardized to the point that they can't be changed, then > I don't see how keeping those jpackage/fedora versions identical can be > such a big problem. I didn't claim everything was standardized. Just that paths cannot be changed for all packages to avoid conflicts. >> You have to figure out specific issues and talk to the Fedora Java team. > > I'd hope there could be a general solution. There is no silver bullet. Rahul From mike at cchtml.com Wed May 14 21:04:22 2008 From: mike at cchtml.com (Mike Cronenworth) Date: Wed, 14 May 2008 16:04:22 -0500 Subject: F7 intel ich5, alsa, device busy In-Reply-To: <482B495E.2070307@verizon.net> References: <482B3EDD.4010809@verizon.net> <482B4424.8010001@cchtml.com> <482B495E.2070307@verizon.net> Message-ID: <482B53D6.3090709@cchtml.com> -------- Original Message -------- Subject: Re: F7 intel ich5, alsa, device busy From: Gerry Reno To: Development discussions related to Fedora Date: 05/14/2008 03:19 PM > Mike Cronenworth wrote: >> > What is >> > the best option here for sound on this laptop? >> > >> >> 1) Use lsof on /dev/snd/pcmC0D0p to see if anything is grabbing onto it. >> >> 2) Upgrade to Fedora 9 >> # rpm -Uhv fedora-release-9.0-2.noarch.rpm >> # yum update >> >> You may say "this is not an option" but there is no other way to get >> an updated driver for your system unless you want to manually install >> an F8 or F9 kernel (not recommended). Plus, PulseAudio (in F8 and now >> F9) may help alleviate his problem. >> >> > Regards, >> > Gerry >> > >> > lsof find firefox got a hold of it. I killed all his firefox windows > and then the audio app starts working again. So now, he can use his ip > phone but he just can't browse while doing it. ?? AFAIK Firefox should not be holding the sound driver open. Do they have Flash installed? Visiting Youtube? Possibly a plugin like mplayerplugin? Upgrading to F8 or F9 with PulseAudio would alleviate this. > > Regards, > Gerry > From maillist at diffingo.com Wed May 14 21:06:38 2008 From: maillist at diffingo.com (Stewart Adam) Date: Wed, 14 May 2008 17:06:38 -0400 Subject: rhgb no more In-Reply-To: <20080514125839.GA73283@dspnet.fr.eu.org> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> <20080514125839.GA73283@dspnet.fr.eu.org> Message-ID: <1210799198.15577.3.camel@Diffingo.localdomain> On Wed, 2008-05-14 at 14:58 +0200, Olivier Galibert wrote: > On Tue, May 13, 2008 at 01:07:51PM -0400, Ray Strode wrote: > > 2) Hiding boot messages before gdm unless escape key is pressed. For > > graphics hardware that has drm modesetting, we'll be able to show some > > sort of pretty graphics, and for everyone else we'll show a very > > simple text mode progress. > > Here we go again. > > Are you going to wait for the escape key to be pressed or not for a > little while, or are we going to have to press just at the right time > between grub and modeswitch if we want to have a chance to check for > problems? > Is there going to be an easy way (like there is with rhgb) to see the > messages (including history) while booting, to check for problems too? > > And, the usual rhetorical question, why so much people like the idea > of forcibly ensuring that the users won't learn anything, ever? > > OG. > ? [user at host ~]$ ls -l /var/log/boot.log -rw------- 1 root root 0 2008-05-11 04:31 /var/log/boot.log Why don't we start making use of boot.log... If the regular output is hidden, then just redirect it to boot.log and if something does happen to go wrong, we can have a notification in the GUI like we do for gnome-power-manager now. Stewart From surenkarapetyan at gmail.com Wed May 14 21:28:52 2008 From: surenkarapetyan at gmail.com (Suren Karapetyan) Date: Thu, 15 May 2008 02:28:52 +0500 Subject: F7 intel ich5, alsa, device busy In-Reply-To: <482B53D6.3090709@cchtml.com> References: <482B3EDD.4010809@verizon.net> <482B4424.8010001@cchtml.com> <482B495E.2070307@verizon.net> <482B53D6.3090709@cchtml.com> Message-ID: <482B5994.7000009@gmail.com> Mike Cronenworth wrote: > -------- Original Message -------- > Subject: Re: F7 intel ich5, alsa, device busy > From: Gerry Reno > To: Development discussions related to Fedora > > Date: 05/14/2008 03:19 PM > >> Mike Cronenworth wrote: >>> > What is >>> > the best option here for sound on this laptop? >>> > >>> >>> 1) Use lsof on /dev/snd/pcmC0D0p to see if anything is grabbing onto it. >>> >>> 2) Upgrade to Fedora 9 >>> # rpm -Uhv fedora-release-9.0-2.noarch.rpm >>> # yum update >>> >>> You may say "this is not an option" but there is no other way to get >>> an updated driver for your system unless you want to manually install >>> an F8 or F9 kernel (not recommended). Plus, PulseAudio (in F8 and now >>> F9) may help alleviate his problem. >>> >>> > Regards, >>> > Gerry >>> > >>> >> lsof find firefox got a hold of it. I killed all his firefox windows >> and then the audio app starts working again. So now, he can use his >> ip phone but he just can't browse while doing it. ?? > > AFAIK Firefox should not be holding the sound driver open. Do they have > Flash installed? Visiting Youtube? Possibly a plugin like mplayerplugin? > > Upgrading to F8 or F9 with PulseAudio would alleviate this. > >> >> Regards, >> Gerry >> > Or if You can't/don't want to upgrade build a newer kernel with alsa which has dmix in it. From mschmidt at redhat.com Wed May 14 21:52:44 2008 From: mschmidt at redhat.com (Michal Schmidt) Date: Wed, 14 May 2008 23:52:44 +0200 Subject: F7 intel ich5, alsa, device busy In-Reply-To: <482B5994.7000009@gmail.com> References: <482B3EDD.4010809@verizon.net> <482B4424.8010001@cchtml.com> <482B495E.2070307@verizon.net> <482B53D6.3090709@cchtml.com> <482B5994.7000009@gmail.com> Message-ID: <20080514235244.4905306b@hammerfall> Dne Thu, 15 May 2008 02:28:52 +0500 Suren Karapetyan napsal(a): > Or if You can't/don't want to upgrade build a newer kernel with alsa > which has dmix in it. dmix has nothing to do with the kernel. It's completely in userspace parts of ALSA. Michal From dr.diesel at gmail.com Wed May 14 21:59:33 2008 From: dr.diesel at gmail.com (Dr. Diesel) Date: Wed, 14 May 2008 17:59:33 -0400 Subject: Anyone else with hard freezes? In-Reply-To: <482AF52D.1080509@poolshark.org> References: <2a28d2ab0805061455l9afae56p8a86218d08bc4b92@mail.gmail.com> <2a28d2ab0805081558q3fdb4b94hf41f40db0253f015@mail.gmail.com> <80d7e4090805081625m111b7955v2c96d864275334b2@mail.gmail.com> <2a28d2ab0805081723q6a3537d7n93db59501cf23b16@mail.gmail.com> <2a28d2ab0805090336j78fe2772q1df6283e3c5d38cf@mail.gmail.com> <1210398432.17530.0.camel@optimus> <2a28d2ab0805130448s2b3e8c8aw5e526bd04949d60a@mail.gmail.com> <2a28d2ab0805131341x6d4d6332nd89e1252839f3866@mail.gmail.com> <2a28d2ab0805140713h542598d6y5c010885dac62687@mail.gmail.com> <482AF52D.1080509@poolshark.org> Message-ID: <2a28d2ab0805141459j22db5edcmb858afd627ea5d01@mail.gmail.com> Thanks for the input! I ran smartctl -t long and found no errors, did it several times! fsck found a zillion errors, is it possible this is still a bug issue? Thanks Andy On Wed, May 14, 2008 at 10:20 AM, Denis Leroy wrote: > Dr. Diesel wrote: >> >> All, it is possible that all of these freezes are caused by a failing >> hard drive? Perhaps failed during the upgrade from F8 to F9 and its >> only 3 months old!! Mmmmm, just my luck! >> >> Last night I suddenly began to receive Kerneloops after Kerneloops, >> 4-5 total then it hard locked. When I went to reboot I got the error >> couldn't find /sys /root etc, couldn't find any of the logical >> volumes. I tried rebooting it several times and finally it made it to >> doing an automatic fsck that fails at about 4%. SMART says the HD is >> fine. > > Note that the overall SMART health status is near useless. What you should > do is look at the disk error log : > > # smartctl -l error /dev/sda > > and run a short and/or long self test (short is couple of mins, long is > typically 1 to 2 hours): > > # smartctl -t long /dev/sda > # smartctl -t short /dev/sda > > Results of the self test after completion: > > # smartctl -l selftest /dev/sda > > You may want to do this from a live CD if your system is really unstable. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org From pertusus at free.fr Wed May 14 22:01:14 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 15 May 2008 00:01:14 +0200 Subject: rawhide bugs becoming F-9 bugs Message-ID: <20080514220114.GA2498@free.fr> Hello, Some rawhide bugs are turned into F-9 bugs (automatically). It is wrong, rawhide bugs should be converted much sooner, maybe during final freeze, now rawhide bugs are for F-10 and shouldn't be turned into F-9 bugs. -- Pat From surenkarapetyan at gmail.com Wed May 14 22:23:21 2008 From: surenkarapetyan at gmail.com (Suren Karapetyan) Date: Thu, 15 May 2008 03:23:21 +0500 Subject: F7 intel ich5, alsa, device busy In-Reply-To: <20080514235244.4905306b@hammerfall> References: <482B3EDD.4010809@verizon.net> <482B4424.8010001@cchtml.com> <482B495E.2070307@verizon.net> <482B53D6.3090709@cchtml.com> <482B5994.7000009@gmail.com> <20080514235244.4905306b@hammerfall> Message-ID: <482B6659.9000605@gmail.com> Michal Schmidt wrote: > Dne Thu, 15 May 2008 02:28:52 +0500 > Suren Karapetyan napsal(a): > >> Or if You can't/don't want to upgrade build a newer kernel with alsa >> which has dmix in it. > > dmix has nothing to do with the kernel. It's completely in userspace > parts of ALSA. > > Michal > Oops Of course it is :) But something tells me he won't be able to make new userspace alsa work with ~1,5 year old kernel. Anyway... the best thing to do is to upgrade to Fedora 9. From francis.earl at gmail.com Wed May 14 22:37:16 2008 From: francis.earl at gmail.com (Francis Earl) Date: Wed, 14 May 2008 15:37:16 -0700 Subject: SWFdec vs Gnash (also gcjwebplugin) Message-ID: <1210804636.27281.5.camel@trinity.blade> Are there any technical reasons as to why Fedora seems to prefer SWFdec over Gnash? I understand that to be part of the Gnome Developer Platform, your project must be LGPL, which Gnash is not, but Gnash actually works today for the more popular use cases (YouTube and friends) and seems to be implemented in a far better way (OpenGL etc) ... Also, wrt to gcjwebplugin, is there any way to make games like games.yahoo.com/pl work? I am sort of addicted to that game, but I'd rather not install the proprietary plugin. Thank you for any assistance, or feedback :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From pertusus at free.fr Wed May 14 22:43:37 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 15 May 2008 00:43:37 +0200 Subject: SWFdec vs Gnash (also gcjwebplugin) In-Reply-To: <1210804636.27281.5.camel@trinity.blade> References: <1210804636.27281.5.camel@trinity.blade> Message-ID: <20080514224337.GC2498@free.fr> On Wed, May 14, 2008 at 03:37:16PM -0700, Francis Earl wrote: > Are there any technical reasons as to why Fedora seems to prefer SWFdec > over Gnash? > > I understand that to be part of the Gnome Developer Platform, your > project must be LGPL, which Gnash is not, but Gnash actually works today > for the more popular use cases (YouTube and friends) and seems to be > implemented in a far better way (OpenGL etc) ... In fact, gnash in fedora uses agg as a backend and not openGL (swfdec uses cairo). In most cases, gnash and swfdec work for the same flash files, since they support similar flash versions ranges. -- Pat From stlwrt at gmail.com Wed May 14 22:49:17 2008 From: stlwrt at gmail.com (Pavel Shevchuk) Date: Thu, 15 May 2008 01:49:17 +0300 Subject: SWFdec vs Gnash (also gcjwebplugin) In-Reply-To: <1210804636.27281.5.camel@trinity.blade> References: <1210804636.27281.5.camel@trinity.blade> Message-ID: swfdec depends on less gnome-libs, and at least for me it works much better than gnash. It also has very nice "click to enable" feature On 5/15/08, Francis Earl wrote: > Are there any technical reasons as to why Fedora seems to prefer SWFdec > over Gnash? > > I understand that to be part of the Gnome Developer Platform, your > project must be LGPL, which Gnash is not, but Gnash actually works today > for the more popular use cases (YouTube and friends) and seems to be > implemented in a far better way (OpenGL etc) ... > > Also, wrt to gcjwebplugin, is there any way to make games like > games.yahoo.com/pl work? I am sort of addicted to that game, but I'd > rather not install the proprietary plugin. > > Thank you for any assistance, or feedback :) > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > -- http://scwlab.com From pertusus at free.fr Wed May 14 22:53:12 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 15 May 2008 00:53:12 +0200 Subject: SWFdec vs Gnash (also gcjwebplugin) In-Reply-To: References: <1210804636.27281.5.camel@trinity.blade> Message-ID: <20080514225312.GD2498@free.fr> On Thu, May 15, 2008 at 01:49:17AM +0300, Pavel Shevchuk wrote: > swfdec depends on less gnome-libs, and at least for me it works much > better than gnash. It also has very nice "click to enable" feature The "click to enable" will be in next gnash release. I doubt swfdec depends on less gnome libs (since both gnash and swfdec should only depend on gtk libs, and not on gnome libs). gnash depends on boost and agg, though. -- Pat From orion at cora.nwra.com Wed May 14 23:19:12 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 14 May 2008 17:19:12 -0600 Subject: mock/yum issues Message-ID: <482B7370.4080301@cora.nwra.com> Updated my F8 builder to mock-0.9.9-1.fc8. Did an x86_64 rawhide --no-clean build for a package that added openssl-devel to the BR list, and the following was installed: DEBUG util.py:250: Installing: DEBUG util.py:250: openssl-devel i386 0.9.8g-6.fc9 fedora 1.9 M DEBUG util.py:250: openssl-devel x86_64 0.9.8g-6.fc9 fedora 1.9 M DEBUG util.py:250: Installing for dependencies: DEBUG util.py:250: device-mapper-devel i386 1.02.24-11.fc9 fedora 31 k DEBUG util.py:250: e2fsprogs-devel i386 1.40.9-2.fc10 fedora 638 k DEBUG util.py:250: keyutils-libs-devel i386 1.2-3.fc9 fedora 27 k DEBUG util.py:250: krb5-devel i386 1.6.3-10.fc9 fedora 1.1 M DEBUG util.py:250: libselinux-devel i386 2.0.64-2.fc10 fedora 108 k DEBUG util.py:250: libsepol-devel i386 2.0.26-1.fc9 fedora 59 k DEBUG util.py:250: Transaction Summary Why the i386 packages? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From lesmikesell at gmail.com Wed May 14 23:35:36 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 14 May 2008 18:35:36 -0500 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <482B4F5B.6040005@fedoraproject.org> References: <1210619487.6844.48.camel@rousalka.okg> <1210621696.12520.62.camel@localhost.localdomain> <1210632587.12173.15.camel@rousalka.okg> <48293492.4020905@gmail.com> <41074.192.54.193.59.1210664862.squirrel@rousalka.dyndns.org> <4829B8D7.7010501@gmail.com> <4829E12A.7060901@gmail.com> <4829E3B0.9090108@redhat.com> <4829F09B.5040500@gmail.com> <4829F3FE.6070203@fedoraproject.org> <4829FCCA.50505@gmail.com> <4829FF0F.7050808@fedoraproject.org> <482A0B44.6050905@gmail.com> <482A0F27.401@fedoraproject.org> <482A123E.6010100@gmail.com> <482A14D4.4080304@fedoraproject.org> <482A22FE.2010509@gmail.com> <482A24EA.7040002@fedoraproject.org> <482A47C5.4020402@gmail.com> <482B0C46.5030409@fedoraproject.org> <482B196E.3010008@gmail.com> <482B217C.3020300@fedoraproject.or! g> <482B30C7.4040103@gmail.com> <482B31D9.3050107@fedoraproject.org> <482B4DDD.6000804@gmail.com> <482B4F5B.6040005@fedoraproject.org> Message-ID: <482B7748.4010709@gmail.com> Rahul Sundaram wrote: > Les Mikesell wrote: >> >> Once you start relying on yum/rpm, there's nothing much uglier than >> conflicting packages. > > Conflicting third party repo/packages are for distributions regardless > of the package manager. Yes, but now we are back to the fact that the jpackage ones didn't conflict with anything until fedora started including conflicting ones, so it seems in bad taste to blame the third party. Sorry if that sounds insulting, but that's just the way it looks from outside. If there was some big effort made to avoid this problem and it proved to be impossible, I must have missed the reasons. >> >> I'd hope there could be a general solution. > > There is no silver bullet. Not as long as conflicting versions of pre-existing packages are added to the base repositories... -- Les Mikesell lesmikesell at gmail.com From walters at verbum.org Wed May 14 23:44:04 2008 From: walters at verbum.org (Colin Walters) Date: Wed, 14 May 2008 19:44:04 -0400 Subject: mock/yum issues In-Reply-To: <482B7370.4080301@cora.nwra.com> References: <482B7370.4080301@cora.nwra.com> Message-ID: On Wed, May 14, 2008 at 7:19 PM, Orion Poplawski wrote: > Updated my F8 builder [...] > Why the i386 packages? That's the default multilib policy in Fedora 8. It was switched for Fedora 9. From jonstanley at gmail.com Wed May 14 23:49:48 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Wed, 14 May 2008 19:49:48 -0400 Subject: rawhide bugs becoming F-9 bugs In-Reply-To: <20080514220114.GA2498@free.fr> References: <20080514220114.GA2498@free.fr> Message-ID: On Wed, May 14, 2008 at 6:01 PM, Patrice Dumas wrote: > Some rawhide bugs are turned into F-9 bugs (automatically). It is wrong, > rawhide bugs should be converted much sooner, maybe during final freeze, > now rawhide bugs are for F-10 and shouldn't be turned into F-9 bugs. We had intended for this event to coincide with the unfreezing of rawhide for F10 content. Unfortunately, due to some technical difficulties, it didn't occur until about a day later (we were checking our queries for sanity, since we didn't want to get this wrong, and found some inconsistencies, actually caused by a bug in Bugzilla). Therefore, most of the action was correct. There may be a few bugs that made the cut that shouldn't have, but not many. Sorry again, we'll do better next time. If you need help mass-changing bugs (doubtful) drop by #fedora-qa and we'll help you out. From pertusus at free.fr Wed May 14 23:55:36 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 15 May 2008 01:55:36 +0200 Subject: rawhide bugs becoming F-9 bugs In-Reply-To: References: <20080514220114.GA2498@free.fr> Message-ID: <20080514235536.GB10077@free.fr> On Wed, May 14, 2008 at 07:49:48PM -0400, Jon Stanley wrote: > On Wed, May 14, 2008 at 6:01 PM, Patrice Dumas wrote: > > > Some rawhide bugs are turned into F-9 bugs (automatically). It is wrong, > > rawhide bugs should be converted much sooner, maybe during final freeze, > > now rawhide bugs are for F-10 and shouldn't be turned into F-9 bugs. > > We had intended for this event to coincide with the unfreezing of > rawhide for F10 content. Unfortunately, due to some technical I think that you should do this before, when cvs branching has been done and devel branch is for the next release, indeed at that point, and even though rawhide is still frozen work has begun on rawhide (you just have to look at the amount of change in the first update...). -- Pat From francis.earl at gmail.com Thu May 15 00:21:49 2008 From: francis.earl at gmail.com (Francis Earl) Date: Wed, 14 May 2008 17:21:49 -0700 Subject: SWFdec vs Gnash (also gcjwebplugin) In-Reply-To: References: <1210804636.27281.5.camel@trinity.blade> Message-ID: <1210810909.30000.3.camel@trinity.blade> On Thu, 2008-05-15 at 01:49 +0300, Pavel Shevchuk wrote: > swfdec depends on less gnome-libs, and at least for me it works much > better than gnash. It also has very nice "click to enable" feature How did you get it to even work? For me, with gstreamer -good -bad -ugly and -ffmpeg, doesn't work at all. With the same setup, gnash at least works in some cases (youtube for instance). I'd rather just use Adblock/NoScripts to block such content on sites I don't want to display. This way, it also collapses the given flash object. Further, swfdec-mozilla depends swfdec-gtk, whereas I don't see any Gnome related deps for gnash... > On 5/15/08, Francis Earl wrote: > > Are there any technical reasons as to why Fedora seems to prefer SWFdec > > over Gnash? > > > > I understand that to be part of the Gnome Developer Platform, your > > project must be LGPL, which Gnash is not, but Gnash actually works today > > for the more popular use cases (YouTube and friends) and seems to be > > implemented in a far better way (OpenGL etc) ... > > > > Also, wrt to gcjwebplugin, is there any way to make games like > > games.yahoo.com/pl work? I am sort of addicted to that game, but I'd > > rather not install the proprietary plugin. > > > > Thank you for any assistance, or feedback :) > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > > > -- > http://scwlab.com > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Thu May 15 00:37:42 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 15 May 2008 06:07:42 +0530 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <482B7748.4010709@gmail.com> References: <1210619487.6844.48.camel@rousalka.okg> <1210621696.12520.62.camel@localhost.localdomain> <1210632587.12173.15.camel@rousalka.okg> <48293492.4020905@gmail.com> <41074.192.54.193.59.1210664862.squirrel@rousalka.dyndns.org> <4829B8D7.7010501@gmail.com> <4829E12A.7060901@gmail.com> <4829E3B0.9090108@redhat.com> <4829F09B.5040500@gmail.com> <4829F3FE.6070203@fedoraproject.org> <4829FCCA.50505@gmail.com> <4829FF0F.7050808@fedoraproject.org> <482A0B44.6050905@gmail.com> <482A0F27.401@fedoraproject.org> <482A123E.6010100@gmail.com> <482A14D4.4080304@fedoraproject.org> <482A22FE.2010509@gmail.com> <482A24EA.7040002@fedoraproject.org> <482A47C5.4020402@gmail.com> <482B0C46.5030409@fedoraproject.org> <482B196E.3010008@gmail.com> <482B217C.3020300@fedoraproject.or! g> <482B30C7.4040103@gmail.com> <482B31D9.3050107@fedoraproject.org> <482B4DDD.6000804@gmail.com> <482B4F5B.6040005@fedoraproject.org> <482B7748.4010709@gmail.com> Message-ID: <482B85D6.3020603@fedoraproject.org> Les Mikesell wrote: > > Yes, but now we are back to the fact that the jpackage ones didn't > conflict with anything until fedora started including conflicting ones, > so it seems in bad taste to blame the third party. I didn't blame anyone. Just stated facts. Sorry if that sounds > insulting, but that's just the way it looks from outside. If there was > some big effort made to avoid this problem and it proved to be > impossible, I must have missed the reasons. You did despite it being explained to you several times. There are major software components like Openoffice.org and Eclipse that depends on Java. Excluding all the software just because they are in a third party repository is impossible. I will the end the discussion here since you seem to be going in circles. Rahul From bpepple at fedoraproject.org Thu May 15 00:40:54 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 14 May 2008 20:40:54 -0400 Subject: SWFdec vs Gnash (also gcjwebplugin) In-Reply-To: <1210810909.30000.3.camel@trinity.blade> References: <1210804636.27281.5.camel@trinity.blade> <1210810909.30000.3.camel@trinity.blade> Message-ID: <1210812054.7754.3.camel@kennedy> On Wed, 2008-05-14 at 17:21 -0700, Francis Earl wrote: > > Further, swfdec-mozilla depends swfdec-gtk, whereas I don't see any > Gnome related deps for gnash... Ummm, swfdec-gtk doesn't depend on any gnome libs. /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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: 197 bytes Desc: This is a digitally signed message part URL: From francis.earl at gmail.com Thu May 15 00:55:59 2008 From: francis.earl at gmail.com (Francis Earl) Date: Wed, 14 May 2008 17:55:59 -0700 Subject: SWFdec vs Gnash (also gcjwebplugin) In-Reply-To: <1210812054.7754.3.camel@kennedy> References: <1210804636.27281.5.camel@trinity.blade> <1210810909.30000.3.camel@trinity.blade> <1210812054.7754.3.camel@kennedy> Message-ID: <1210812959.31076.1.camel@trinity.blade> On Wed, 2008-05-14 at 20:40 -0400, Brian Pepple wrote: > On Wed, 2008-05-14 at 17:21 -0700, Francis Earl wrote: > > > > Further, swfdec-mozilla depends swfdec-gtk, whereas I don't see any > > Gnome related deps for gnash... > > Ummm, swfdec-gtk doesn't depend on any gnome libs. I didn't say it did... I simply inferred that swfdec depended on things closer to gnome than gnash did... Sorry for the confusion. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Thu May 15 01:09:42 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 15 May 2008 06:39:42 +0530 Subject: SWFdec vs Gnash (also gcjwebplugin) In-Reply-To: <1210812959.31076.1.camel@trinity.blade> References: <1210804636.27281.5.camel@trinity.blade> <1210810909.30000.3.camel@trinity.blade> <1210812054.7754.3.camel@kennedy> <1210812959.31076.1.camel@trinity.blade> Message-ID: <482B8D56.9080904@fedoraproject.org> Francis Earl wrote: > On Wed, 2008-05-14 at 20:40 -0400, Brian Pepple wrote: >> On Wed, 2008-05-14 at 17:21 -0700, Francis Earl wrote: >>> Further, swfdec-mozilla depends swfdec-gtk, whereas I don't see any >>> Gnome related deps for gnash... >> Ummm, swfdec-gtk doesn't depend on any gnome libs. > > I didn't say it did... I simply inferred that swfdec depended on things > closer to gnome than gnash did... Likely since swfdec is developed by someone is also a GNOME developer but the GNOME dependencies have always been separated and there is no reason others couldn't develop alternative frontends too if necessary. Rahul From bpepple at fedoraproject.org Thu May 15 01:15:03 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 14 May 2008 21:15:03 -0400 Subject: Plan for tomorrows (20080515) FESCO meeting Message-ID: <1210814103.7754.8.camel@kennedy> Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC in #fedora-meeting on irc.freenode.org: /topic FESCo-Meeting -- F9 - Post-mortem? - all /topic FESCo meeting -- Free discussion around Fedora You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule. You can also propose topics in the meeting while it is in the "Free discussion around Fedora" phase. If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing... Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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: 197 bytes Desc: This is a digitally signed message part URL: From ivazqueznet at gmail.com Thu May 15 01:18:43 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Wed, 14 May 2008 21:18:43 -0400 Subject: Tracker bugs created for Fedora 10 milestones and Fedora 11 In-Reply-To: References: Message-ID: <1210814323.26278.166.camel@ignacio.lan> On Wed, 2008-05-14 at 13:07 -0400, Jon Stanley wrote: > In line with the triage release SOP, I've just created blocker bugs > for Fedora 10 Alpha, Beta, and Preview releases. Trackers are also > created for F11 blocker and target bugs. They are aliased in the > normal way: > > - F10Alpha > - F10Beta > - F10PR > - F11Blocker > - F11Target > > Feel free to start planning in advance! :) Only mildly OT, should we (and by we I mean a smart-enough script :P) add unclosed merge reviews to F10Blocker? -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From lesmikesell at gmail.com Thu May 15 01:53:38 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 14 May 2008 20:53:38 -0500 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <482B85D6.3020603@fedoraproject.org> References: <1210621696.12520.62.camel@localhost.localdomain> <1210632587.12173.15.camel@rousalka.okg> <48293492.4020905@gmail.com> <41074.192.54.193.59.1210664862.squirrel@rousalka.dyndns.org> <4829B8D7.7010501@gmail.com> <4829E12A.7060901@gmail.com> <4829E3B0.9090108@redhat.com> <4829F09B.5040500@gmail.com> <4829F3FE.6070203@fedoraproject.org> <4829FCCA.50505@gmail.com> <4829FF0F.7050808@fedoraproject.org> <482A0B44.6050905@gmail.com> <482A0F27.401@fedoraproject.org> <482A123E.6010100@gmail.com> <482A14D4.4080304@fedoraproject.org> <482A22FE.2010509@gmail.com> <482A24EA.7040002@fedoraproject.org> <482A47C5.4020402@gmail.com> <482B0C46.5030409@fedoraproject.org> <482B196E.3010008@gmail.com> <482B217C.3020300@fedoraproject.or! g> <482B30C7.4040103@gmail.com> <482B31D9.3050107@fedoraproject.org> <482B4DDD.6000804@gmail.com> <482B4F5B.6040005@fedoraproject.org> <482B7748.4010709@gmail.com> <482B85D6.3020603@fedoraproject.org> Message-ID: <482B97A2.9080803@gmail.com> Rahul Sundaram wrote: > Les Mikesell wrote: >> >> Yes, but now we are back to the fact that the jpackage ones didn't >> conflict with anything until fedora started including conflicting >> ones, so it seems in bad taste to blame the third party. > > I didn't blame anyone. Just stated facts. Same here. No conflicts existed until fedora packagers duplicated packages that already existed in well-known repositories and forked them instead of mirroring. > Sorry if that sounds >> insulting, but that's just the way it looks from outside. If there >> was some big effort made to avoid this problem and it proved to be >> impossible, I must have missed the reasons. > > You did despite it being explained to you several times. There are major > software components like Openoffice.org and Eclipse that depends on > Java. Which still doesn't explain why any needed package that existed elsewhere couldn't be maintained identically to eliminate the conflict issue. Maybe there's a case of that somewhere but I'm not convinced it would have been a problem in general. Would jpackage really have refused to have the same maintainer make sure common packages were always identical? > Excluding all the software just because they are in a third party > repository is impossible. It doesn't have to be excluded, it has to not be a conflicting fork. > I will the end the discussion here since you > seem to be going in circles. The reason this discussion always goes in circles is that there are 2 factors involved and you always jump between one or the other in your answers, ignoring the fact that users have to deal the the end result. Factor 1 is that the fedora repo doesn't include everything that the pre-existing repositories provided and users still need. Whenever this comes up you respond about legalities/policy etc., etc., but the reasons don't matter. The fact is they aren't there. This shouldn't be an issue, since the other repos are still around, but... Factor 2 is that _some_ of the packages from the 3rd party repos were forked into potentially conflicting versions that may cause problems with the original, while factor 1 ensures that you can't get all of the packages you are likely to need without them. And a side effect seems to be that the old repos are no longer particularly interested in supporting fedora. If you can't address the effects of both factors at once, I guess there really isn't anything else to say. -- Les Mikesell lesmikesell at gmail.com From sundaram at fedoraproject.org Thu May 15 02:08:01 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 15 May 2008 07:38:01 +0530 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <482B97A2.9080803@gmail.com> References: <1210632587.12173.15.camel@rousalka.okg> <48293492.4020905@gmail.com> <41074.192.54.193.59.1210664862.squirrel@rousalka.dyndns.org> <4829B8D7.7010501@gmail.com> <4829E12A.7060901@gmail.com> <4829E3B0.9090108@redhat.com> <4829F09B.5040500@gmail.com> <4829F3FE.6070203@fedoraproject.org> <4829FCCA.50505@gmail.com> <4829FF0F.7050808@fedoraproject.org> <482A0B44.6050905@gmail.com> <482A0F27.401@fedoraproject.org> <482A123E.6010100@gmail.com> <482A14D4.4080304@fedoraproject.org> <482A22FE.2010509@gmail.com> <482A24EA.7040002@fedoraproject.org> <482A47C5.4020402@gmail.com> <482B0C46.5030409@fedoraproject.org> <482B196E.3010008@gmail.com> <482B217C.3020300@fedoraproject.or! g> <482B30C7.4040103@gmail.com> <482B31D9.3050107@fedoraproject.org> <482B4DDD.6000804@gmail.com> <482B4F5B.6040005@fedoraproject.org> <482B7748.4010709@gmail.com> <482B85D6.3020603@fedoraproject.org> <482B97A2.9080803@gmail.com> Message-ID: <482B9B01.3080305@fedoraproject.org> Les Mikesell wrote: > Rahul Sundaram wrote: >> Les Mikesell wrote: >>> >>> Yes, but now we are back to the fact that the jpackage ones didn't >>> conflict with anything until fedora started including conflicting >>> ones, so it seems in bad taste to blame the third party. >> >> I didn't blame anyone. Just stated facts. > > Same here. No conflicts existed until fedora packagers duplicated > packages that already existed in well-known repositories and forked them > instead of mirroring. A cross distribution package repository is always going to be different from a distribution specific repository. > Which still doesn't explain why any needed package that existed > elsewhere couldn't be maintained identically to eliminate the conflict > issue. Maybe there's a case of that somewhere but I'm not convinced it > would have been a problem in general. Would jpackage really have > refused to have the same maintainer make sure common packages were > always identical? It is impossible to do that. Fedora has its own release cycle, licensing policies and packaging guidelines. The package dependencies will differ in many cases based on all of these. > Factor 1 is that the fedora repo doesn't include everything that the > pre-existing repositories provided and users still need. Whenever this > comes up you respond about legalities/policy etc., etc., but the reasons > don't matter. The fact is they aren't there. This shouldn't be an > issue, since the other repos are still around, but... Software packages are in the Fedora repository because people volunteered to do so. That has nothing to do with legalities or policies and yes those might be a reason too and goes to the core of why such third party repositories even exist regardless of whether you care about them or not. > Factor 2 is that _some_ of the packages from the 3rd party repos were > forked into potentially conflicting versions that may cause problems > with the original, while factor 1 ensures that you can't get all of the > packages you are likely to need without them. And a side effect seems > to be that the old repos are no longer particularly interested in > supporting fedora. That's not the real reason again as explained to you earlier. > If you can't address the effects of both factors at once, I guess there > really isn't anything else to say. If you keep ignoring what is being said to you, there is no point indeed. Move on. Rahul From rhally at mindspring.com Thu May 15 02:33:02 2008 From: rhally at mindspring.com (Richard Hally) Date: Wed, 14 May 2008 22:33:02 -0400 Subject: Plan for tomorrows (20080515) FESCO meeting In-Reply-To: <1210814103.7754.8.camel@kennedy> References: <1210814103.7754.8.camel@kennedy> Message-ID: <482BA0DE.4000709@mindspring.com> Brian Pepple wrote: > Please find below the list of topics that are likely to come up in the > next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC > in #fedora-meeting on irc.freenode.org: > > /topic FESCo-Meeting -- F9 - Post-mortem? - all Shouldn't that be "post-partum"? Nothing died did it? Keep up the good work! =:) > /topic FESCo meeting -- Free discussion around Fedora > > You want something to be discussed? Send a note to the list in reply to > this mail and I'll add it to the schedule. You can also propose topics > in the meeting while it is in the "Free discussion around Fedora" phase. > > If your name/nick is on above list please update the status on the > Extras schedule pages in the wiki ahead of the meeting. That way all the > other FESCo members and interested contributors know what up ahead of > the meeting. And we will avoid long delays in the meeting -- those often > arise if someone describes the recent happenings on a topic directly in > the meeting while all the others have to wait for his slow typing... > > Later, > /B > > > ------------------------------------------------------------------------ > > No virus found in this incoming message. > Checked by AVG. > Version: 7.5.524 / Virus Database: 269.23.16/1432 - Release Date: 5/14/2008 7:49 AM From orion at cora.nwra.com Thu May 15 03:14:32 2008 From: orion at cora.nwra.com (orion at cora.nwra.com) Date: Wed, 14 May 2008 21:14:32 -0600 (MDT) Subject: mock/yum issues In-Reply-To: References: <482B7370.4080301@cora.nwra.com> Message-ID: <1978.71.208.51.146.1210821272.squirrel@www.cora.nwra.com> > On Wed, May 14, 2008 at 7:19 PM, Orion Poplawski > wrote: >> Updated my F8 builder [...] >> Why the i386 packages? > > That's the default multilib policy in Fedora 8. It was switched for > Fedora 9. So the new mock package for F8 is wrong then: # grub/syslinux on x86_64 need glibc-devel.i386 which pulls in glibc.i386, need to exclude all # .i?86 packages except these. #exclude=[0-9A-Za-fh-z]*.i?86 g[0-9A-Za-km-z]*.i?86 gl[0-9A-Za-hj-z]*.i?86 gli[0-9A-Zac-z]*.i?86 glib[0-9A-Za-bd-z]*.i?86 # The above is not needed anymore with yum multilib policy of "best" which is the default in Fedora. But this is only on F9+. F8 should still have it. https://bugzilla.redhat.com/show_bug.cgi?id=446556 - Orion From lordmorgul at gmail.com Thu May 15 03:37:23 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Wed, 14 May 2008 20:37:23 -0700 Subject: rawhide bugs becoming F-9 bugs In-Reply-To: <20080514235536.GB10077@free.fr> References: <20080514220114.GA2498@free.fr> <20080514235536.GB10077@free.fr> Message-ID: <482BAFF3.8070807@gmail.com> Patrice Dumas wrote: > On Wed, May 14, 2008 at 07:49:48PM -0400, Jon Stanley wrote: >> On Wed, May 14, 2008 at 6:01 PM, Patrice Dumas wrote: >> >>> Some rawhide bugs are turned into F-9 bugs (automatically). It is wrong, >>> rawhide bugs should be converted much sooner, maybe during final freeze, >>> now rawhide bugs are for F-10 and shouldn't be turned into F-9 bugs. >> We had intended for this event to coincide with the unfreezing of >> rawhide for F10 content. Unfortunately, due to some technical > > I think that you should do this before, when cvs branching has been > done and devel branch is for the next release, indeed at that point, and > even though rawhide is still frozen work has begun on rawhide (you just > have to look at the amount of change in the first update...). There were MANY duplicate bugs and some new bugs filed against rawhide which are F9 bugs in the last week before release... doing that change early would completely defeat the purpose of doing it at all. IMO the week of release might work fine, but there will always be some overlap that occurs when the bug triage people try to do this task. If they go early, then some F9 bugs will stay rawhide and should not. If they go later, then the first early filed F10 bugs might get changed... It would be better for people to seriously take a breather and wait on reporting F10 bugs on that first repo build for F10... there will obviously be many bugs and it'd be simpler to start posting them a week after the release. -- Andrew Farris www.lordmorgul.net gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29 From lesmikesell at gmail.com Thu May 15 03:40:56 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 14 May 2008 22:40:56 -0500 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <482B9B01.3080305@fedoraproject.org> References: <1210632587.12173.15.camel@rousalka.okg> <48293492.4020905@gmail.com> <41074.192.54.193.59.1210664862.squirrel@rousalka.dyndns.org> <4829B8D7.7010501@gmail.com> <4829E12A.7060901@gmail.com> <4829E3B0.9090108@redhat.com> <4829F09B.5040500@gmail.com> <4829F3FE.6070203@fedoraproject.org> <4829FCCA.50505@gmail.com> <4829FF0F.7050808@fedoraproject.org> <482A0B44.6050905@gmail.com> <482A0F27.401@fedoraproject.org> <482A123E.6010100@gmail.com> <482A14D4.4080304@fedoraproject.org> <482A22FE.2010509@gmail.com> <482A24EA.7040002@fedoraproject.org> <482A47C5.4020402@gmail.com> <482B0C46.5030409@fedoraproject.org> <482B196E.3010008@gmail.com> <482B217C.3020300@fedoraproject.or! g> <482B30C7.4040103@gmail.com> <482B31D9.3050107@fedoraproject.org> <482B4DDD.6000804@gmail.com> <482B4F5B.6040005@fedoraproject.org> <482B7748.4010709@gmail.com> <482B85D6.3020603@fedoraproject.org> <482B97A2.9080803@gmail.com> <482B9B01.3080305@fedoraproject.! org> Message-ID: <482BB0C8.6050205@gmail.com> Rahul Sundaram wrote: > >>> I didn't blame anyone. Just stated facts. >> >> Same here. No conflicts existed until fedora packagers duplicated >> packages that already existed in well-known repositories and forked >> them instead of mirroring. > > A cross distribution package repository is always going to be different > from a distribution specific repository. I don't see how that is relevant, given that the pre-existing repositories mostly/all have added version-specific instances for each fedora release. >> Which still doesn't explain why any needed package that existed >> elsewhere couldn't be maintained identically to eliminate the conflict >> issue. Maybe there's a case of that somewhere but I'm not convinced >> it would have been a problem in general. Would jpackage really have >> refused to have the same maintainer make sure common packages were >> always identical? > > It is impossible to do that. Fedora has its own release cycle, licensing > policies and packaging guidelines. The package dependencies will differ > in many cases based on all of these. Could you share some amusing anecdotes about how the existing repositories refused to make these changed versions available when you tried to provide them to maintain complete compatibility? >> Factor 2 is that _some_ of the packages from the 3rd party repos were >> forked into potentially conflicting versions that may cause problems >> with the original, while factor 1 ensures that you can't get all of >> the packages you are likely to need without them. And a side effect >> seems to be that the old repos are no longer particularly interested >> in supporting fedora. > > That's not the real reason again as explained to you earlier. The reason really doesn't matter. The effect and problems do. >> If you can't address the effects of both factors at once, I guess >> there really isn't anything else to say. > > If you keep ignoring what is being said to you, there is no point > indeed. Move on. There's been nothing to ignore - I haven't heard any plan to improve the situation. -- Les Mikesell lesmikesell at gmail.com From sundaram at fedoraproject.org Thu May 15 03:51:05 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 15 May 2008 09:21:05 +0530 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <482BB0C8.6050205@gmail.com> References: <48293492.4020905@gmail.com> <41074.192.54.193.59.1210664862.squirrel@rousalka.dyndns.org> <4829B8D7.7010501@gmail.com> <4829E12A.7060901@gmail.com> <4829E3B0.9090108@redhat.com> <4829F09B.5040500@gmail.com> <4829F3FE.6070203@fedoraproject.org> <4829FCCA.50505@gmail.com> <4829FF0F.7050808@fedoraproject.org> <482A0B44.6050905@gmail.com> <482A0F27.401@fedoraproject.org> <482A123E.6010100@gmail.com> <482A14D4.4080304@fedoraproject.org> <482A22FE.2010509@gmail.com> <482A24EA.7040002@fedoraproject.org> <482A47C5.4020402@gmail.com> <482B0C46.5030409@fedoraproject.org> <482B196E.3010008@gmail.com> <482B217C.3020300@fedoraproject.or! g> <482B30C7.4040103@gmail.com> <482B31D9.3050107@fedoraproject.org> <482B4DDD.6000804@gmail.com> <482B4F5B.6040005@fedoraproject.org> <482B7748.4010709@gmail.com> <482B85D6.3020603@fedoraproject.org> <482B97A2.9080803@gmail.com> <482B9B01.3080305@fedoraproject.! org> <482BB0C8.6050205@gmail.com> Message-ID: <482BB329.7080708@fedoraproject.org> Les Mikesell wrote: > Rahul Sundaram wrote: >> >>>> I didn't blame anyone. Just stated facts. >>> >>> Same here. No conflicts existed until fedora packagers duplicated >>> packages that already existed in well-known repositories and forked >>> them instead of mirroring. >> >> A cross distribution package repository is always going to be >> different from a distribution specific repository. > > I don't see how that is relevant, given that the pre-existing > repositories mostly/all have added version-specific instances for each > fedora release. Third party repositories follow their own licensing and packaging policies which are different even they target a specific distribution. This is what you fail to understand. > Could you share some amusing anecdotes about how the existing > repositories refused to make these changed versions available when you > tried to provide them to maintain complete compatibility? Refer to list archives in the specific repositories or past discussions even in this list. Giving you "amusing anecdotes" isn't my job. > The reason really doesn't matter. The effect and problems do. The reasons do matter since you keep claiming incorrectly what it is despite being corrected. Rahul From notting at redhat.com Thu May 15 04:01:25 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 15 May 2008 00:01:25 -0400 Subject: SWFdec vs Gnash (also gcjwebplugin) In-Reply-To: <1210804636.27281.5.camel@trinity.blade> References: <1210804636.27281.5.camel@trinity.blade> Message-ID: <20080515040125.GA26819@nostromo.devel.redhat.com> Francis Earl (francis.earl at gmail.com) said: > Are there any technical reasons as to why Fedora seems to prefer SWFdec > over Gnash? It works better would be the short answer. Having run both of them through a test suite (available at http://fedoraproject.org/wiki/QA/TestResults/Fedora9Swfdec/Rawhide), swfdec performed *much* better, not the least because it supports a larger subset of Flash 9. Bill From mastahnke at gmail.com Thu May 15 04:18:36 2008 From: mastahnke at gmail.com (Michael Stahnke) Date: Wed, 14 May 2008 23:18:36 -0500 Subject: Orphan Packages Message-ID: <7874d9dd0805142118u1f4a5f32vb2ad3beede44e50c@mail.gmail.com> I no longer use, nor really have interest in the following packages. They are free for the taking. python-libgmail python-libgmail-docs fuse-gmailfs stahnma From lesmikesell at gmail.com Thu May 15 05:26:18 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 15 May 2008 00:26:18 -0500 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <482BB329.7080708@fedoraproject.org> References: <41074.192.54.193.59.1210664862.squirrel@rousalka.dyndns.org> <4829B8D7.7010501@gmail.com> <4829E12A.7060901@gmail.com> <4829E3B0.9090108@redhat.com> <4829F09B.5040500@gmail.com> <4829F3FE.6070203@fedoraproject.org> <4829FCCA.50505@gmail.com> <4829FF0F.7050808@fedoraproject.org> <482A0B44.6050905@gmail.com> <482A0F27.401@fedoraproject.org> <482A123E.6010100@gmail.com> <482A14D4.4080304@fedoraproject.org> <482A22FE.2010509@gmail.com> <482A24EA.7040002@fedoraproject.org> <482A47C5.4020402@gmail.com> <482B0C46.5030409@fedoraproject.org> <482B196E.3010008@gmail.com> <482B217C.3020300@fedoraproject.or! g> <482B30C7.4040103@gmail.com> <482B31D9.3050107@fedoraproject.org> <482B4DDD.6000804@gmail.com> <482B4F5B.6040005@fedoraproject.org> <482B7748.4010709@gmail.com> <482B85D6.3020603@fedoraproject.org> <482B97A2.9080803@gmail.com> <482B9B01.3080305@fedoraproject.! org> <482BB0C8.6050205@gmail.com> <482BB329.7080708@fedoraproject.or! g> Message-ID: <482BC97A.3010602@gmail.com> Rahul Sundaram wrote: > >>>> Same here. No conflicts existed until fedora packagers duplicated >>>> packages that already existed in well-known repositories and forked >>>> them instead of mirroring. >>> >>> A cross distribution package repository is always going to be >>> different from a distribution specific repository. >> >> I don't see how that is relevant, given that the pre-existing >> repositories mostly/all have added version-specific instances for each >> fedora release. > > Third party repositories follow their own licensing and packaging > policies which are different even they target a specific distribution. > This is what you fail to understand. The only parts where this matters are those where there is incompatible duplication within the fedora repository. What I specifically fail to understand is why those packages that have been duplicated could not have been done in a way that the same contents would be acceptable in both repositories. Why, for example, couldn't the changes you say fedora needs as a dependency for openoffice be included in the jpackage repository for that fedora release and maintained as exact copies? >> Could you share some amusing anecdotes about how the existing >> repositories refused to make these changed versions available when you >> tried to provide them to maintain complete compatibility? > > Refer to list archives in the specific repositories or past discussions > even in this list. Giving you "amusing anecdotes" isn't my job. Those discussions left me with the impression that no actual effort was made to stay compatible with any other repository in spite of knowing that you don't and probably won't ever provide equivalent contents. I was hoping to hear otherwise. -- Les Mikesell lesmikesell at gmail.com From sundaram at fedoraproject.org Thu May 15 06:52:47 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 15 May 2008 12:22:47 +0530 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <482BC97A.3010602@gmail.com> References: <4829B8D7.7010501@gmail.com> <4829E12A.7060901@gmail.com> <4829E3B0.9090108@redhat.com> <4829F09B.5040500@gmail.com> <4829F3FE.6070203@fedoraproject.org> <4829FCCA.50505@gmail.com> <4829FF0F.7050808@fedoraproject.org> <482A0B44.6050905@gmail.com> <482A0F27.401@fedoraproject.org> <482A123E.6010100@gmail.com> <482A14D4.4080304@fedoraproject.org> <482A22FE.2010509@gmail.com> <482A24EA.7040002@fedoraproject.org> <482A47C5.4020402@gmail.com> <482B0C46.5030409@fedoraproject.org> <482B196E.3010008@gmail.com> <482B217C.3020300@fedoraproject.or! g> <482B30C7.4040103@gmail.com> <482B31D9.3050107@fedoraproject.org> <482B4DDD.6000804@gmail.com> <482B4F5B.6040005@fedoraproject.org> <482B7748.4010709@gmail.com> <482B85D6.3020603@fedoraproject.org> <482B97A2.9080803@gmail.com> <482B9B01.3080305@fedoraproject.! org> <482BB0C8.6050205@gmail.com> <482BB329.7080708@fedoraproject.or! g> <482BC97A.3010602@gmail.com> Message-ID: <482BDDBF.4040207@fedoraproject.org> Les Mikesell wrote: Why, for example, couldn't the changes you say > fedora needs as a dependency for openoffice be included in the jpackage > repository for that fedora release and maintained as exact copies? You are again ignoring reasons already explained. Jpackage specializes in Java packages and doesn't include all the packages Fedora does and vice versa. So the dependencies cannot be the same. Even it does there are differences in release cycles, patches, packaging and licensing policy among other reasons. It is pretty difficult to have two variants of a software with different maintainers in two different repositories perfectly in sync all the time even with the best efforts. Rahul From nicolas.mailhot at laposte.net Thu May 15 07:29:25 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 15 May 2008 09:29:25 +0200 (CEST) Subject: rawhide bugs becoming F-9 bugs In-Reply-To: <482BAFF3.8070807@gmail.com> References: <20080514220114.GA2498@free.fr> <20080514235536.GB10077@free.fr> <482BAFF3.8070807@gmail.com> Message-ID: <58294.192.54.193.59.1210836565.squirrel@rousalka.dyndns.org> Le Jeu 15 mai 2008 05:37, Andrew Farris a ?crit : > It would be better for people to seriously take a breather and wait on > reporting > F10 bugs on that first repo build for F10... there will obviously be > many bugs > and it'd be simpler to start posting them a week after the release. It does not works that way. People report bugs when they hit them. Some issues are obviously a Fn+1 target even before Fn is released, if only because of the level of changes needed to fix them. That's the real world. Real world is not simple. -- Nicolas Mailhot From balajig81 at gmail.com Thu May 15 07:56:27 2008 From: balajig81 at gmail.com (G) Date: Thu, 15 May 2008 13:26:27 +0530 Subject: My introduction & Idea Storm for F10 Message-ID: <6dd1343e0805150056x56dacdaalb54b67f10edcc939@mail.gmail.com> Hi My name is Balaji i am from Chennai (India). This is my first mail to the fedora development list, thought i could introduce myself and get into the development process as early as possible.I joined the Fedora team as a contributor during the final phases of F9 . I am already part of the bug triaging, testing team and of course the ambassador for Chennai (India). Looking forward to get into the F10 development process and be part of this truly exciting & challenging team :) I ve got a small suggestion if we have not yet done this. You could just try considering this if you find it really useful. Do we have some kind of idea storm where in people give their ideas for F10 something like what all features could go in for f10 ? Do we have it if not could we have it ? Thanks, Cheers, Balaji From mmaslano at redhat.com Thu May 15 08:46:12 2008 From: mmaslano at redhat.com (Marcela Maslanova) Date: Thu, 15 May 2008 10:46:12 +0200 Subject: My introduction & Idea Storm for F10 In-Reply-To: <6dd1343e0805150056x56dacdaalb54b67f10edcc939@mail.gmail.com> References: <6dd1343e0805150056x56dacdaalb54b67f10edcc939@mail.gmail.com> Message-ID: <482BF854.607@redhat.com> "G" wrote: > Hi > > My name is Balaji i am from Chennai (India). This is my first mail to > the fedora development list, thought i could introduce myself and get > into the development process as early as possible.I joined the Fedora > team as a contributor during the final phases of F9 . I am already > part of the bug triaging, testing team and of course the ambassador > for Chennai (India). Looking forward to get into the F10 development > process and be part of this truly exciting & challenging team :) > > I ve got a small suggestion if we have not yet done this. You could > just try considering this if you find it really useful. > Do we have some kind of idea storm where in people give their ideas > for F10 something like what all features could go in for f10 ? Do we > have it if not could we have it ? > > Thanks, > > Cheers, > Balaji > > Are you looking for this? http://fedoraproject.org/wiki/Releases/10/FeatureList?highlight=(feature) -- Marcela Ma?l??ov? BaseOS team Brno From pertusus at free.fr Thu May 15 09:02:26 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 15 May 2008 11:02:26 +0200 Subject: rawhide bugs becoming F-9 bugs In-Reply-To: <482BAFF3.8070807@gmail.com> References: <20080514220114.GA2498@free.fr> <20080514235536.GB10077@free.fr> <482BAFF3.8070807@gmail.com> Message-ID: <20080515090226.GB2656@free.fr> On Wed, May 14, 2008 at 08:37:23PM -0700, Andrew Farris wrote: > > There were MANY duplicate bugs and some new bugs filed against rawhide > which are F9 bugs in the last week before release... doing that change But aren't they rawhide bugs too? It is much better to have those bugs opened against the latest version of fedora, having to go through bugzilla just to say "hey, don't close my bug" as unfrequently as possible seems better to me. > occurs when the bug triage people try to do this task. If they go early, > then some F9 bugs will stay rawhide and should not. That seems almost impossible to me since, at this stage rawhide and F-9 are almost the same, bug-wise. > It would be better for people to seriously take a breather and wait on > reporting F10 bugs on that first repo build for F10... there will obviously > be many bugs and it'd be simpler to start posting them a week after the > release. No, especially enhancements, packaging bugs. In any case these are the kind of bugs that are filled against rawhide after the cvs branch moves. They are likely to be targeted for rawhide, while usual bugs are likely to be targeted for both rawhide and F-9, so it seems much better to me to have them be kept in rawhide. -- Pat From balajig81 at gmail.com Thu May 15 09:06:10 2008 From: balajig81 at gmail.com (G) Date: Thu, 15 May 2008 14:36:10 +0530 Subject: My introduction & Idea Storm for F10 In-Reply-To: <482BF854.607@redhat.com> References: <6dd1343e0805150056x56dacdaalb54b67f10edcc939@mail.gmail.com> <482BF854.607@redhat.com> Message-ID: <6dd1343e0805150206t797e0ffag321f76665ea7d05a@mail.gmail.com> Hi Thanks for your reply.Yes exactly but just curious to know how the feature list gets filled up . Is it something like we say this feature X is a very good feature which is used by distribution Y / this feature X would be good coz lot of people ask for it . If we have something like a vote kind of thing where if 60 % of people say i would love to see Fedora having more support for hibernate/suspend feature (example) , it would be really good i feel we as developers could also start looking at whats actually in need as the highest priority. Just my thoughts !! Cheers Balaji On 5/15/08, Marcela Maslanova wrote: > > > "G" wrote: > > > Hi > > > > My name is Balaji i am from Chennai (India). This is my first mail to > > the fedora development list, thought i could introduce myself and get > > into the development process as early as possible.I joined the Fedora > > team as a contributor during the final phases of F9 . I am already > > part of the bug triaging, testing team and of course the ambassador > > for Chennai (India). Looking forward to get into the F10 development > > process and be part of this truly exciting & challenging team :) > > > > I ve got a small suggestion if we have not yet done this. You could > > just try considering this if you find it really useful. > > Do we have some kind of idea storm where in people give their ideas > > for F10 something like what all features could go in for f10 ? Do we > > have it if not could we have it ? > > > > Thanks, > > > > Cheers, > > Balaji > > > > > > > Are you looking for this? > http://fedoraproject.org/wiki/Releases/10/FeatureList?highlight=(feature) > > -- > Marcela Ma?l??ov? > BaseOS team Brno > > -- > 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 Thu May 15 09:07:11 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 15 May 2008 11:07:11 +0200 Subject: SWFdec vs Gnash (also gcjwebplugin) In-Reply-To: <1210810909.30000.3.camel@trinity.blade> References: <1210804636.27281.5.camel@trinity.blade> <1210810909.30000.3.camel@trinity.blade> Message-ID: <20080515090711.GC2656@free.fr> On Wed, May 14, 2008 at 05:21:49PM -0700, Francis Earl wrote: > > How did you get it to even work? For me, with gstreamer -good -bad -ugly > and -ffmpeg, doesn't work at all. With the same setup, gnash at least > works in some cases (youtube for instance). That's strange, swfedec and gnash should need the same gstreamer setup. > Further, swfdec-mozilla depends swfdec-gtk, whereas I don't see any > Gnome related deps for gnash... Once again there are the same dependencies on gtk. And in fact the gnash executable shipped in fedora in the gnash package is even called gtk-gnash. As a side note, gnash has potentially a better kde integration, though it is broken currently because of the switch to kde4. swfdec has a thumbnailer support for gnome. -- Pat From paul at all-the-johnsons.co.uk Thu May 15 09:12:28 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Thu, 15 May 2008 10:12:28 +0100 Subject: Rawhide update problem Message-ID: <1210842748.3591.52.camel@T7.Linux> Hi, I'm not sure which is pulling in which, but when I try to update via yumex on either x86 or x86_64, I'm getting what looks to be a circular dep problem. Missing Dependency: libhunspell.so.1()(64bit) is needed by package xulrunner-1.9-0.60.cvs20080414.fc10.x86_64 (rawhide) Missing Dependency: libhunspell.so.1()(64bit) is needed by package 1:openoffice.org-core-2.4.0-12.8.fc9.x86_64 (installed) If I exclude both hunspell and xulrunner from the update, I still get a problem in that OOo-core needs hunspell.so.1 Are these expected to be fixed in today's rawhide? TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Thu May 15 09:19:52 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 15 May 2008 14:49:52 +0530 Subject: My introduction & Idea Storm for F10 In-Reply-To: <6dd1343e0805150206t797e0ffag321f76665ea7d05a@mail.gmail.com> References: <6dd1343e0805150056x56dacdaalb54b67f10edcc939@mail.gmail.com> <482BF854.607@redhat.com> <6dd1343e0805150206t797e0ffag321f76665ea7d05a@mail.gmail.com> Message-ID: <482C0038.2070500@fedoraproject.org> "G" wrote: > Hi > > Thanks for your reply.Yes exactly but just curious to know how the > feature list gets filled up . Is it something like we say this feature > X is a very good feature which is used by distribution Y / this > feature X would be good coz lot of people ask for it . If we have > something like a vote kind of thing where if 60 % of people say i > would love to see Fedora having more support for hibernate/suspend > feature (example) , it would be really good i feel we as developers > could also start looking at whats actually in need as the highest > priority. The feature list gets filled by following the policy outlined in http://fedoraproject.org/wiki/Features/Policy This is based not just on popularity but someone or a team actually willing to work on any particular feature. Rahul From pertusus at free.fr Thu May 15 09:22:03 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 15 May 2008 11:22:03 +0200 Subject: SWFdec vs Gnash (also gcjwebplugin) In-Reply-To: <20080515040125.GA26819@nostromo.devel.redhat.com> References: <1210804636.27281.5.camel@trinity.blade> <20080515040125.GA26819@nostromo.devel.redhat.com> Message-ID: <20080515092203.GD2656@free.fr> On Thu, May 15, 2008 at 12:01:25AM -0400, Bill Nottingham wrote: > Francis Earl (francis.earl at gmail.com) said: > > Are there any technical reasons as to why Fedora seems to prefer SWFdec > > over Gnash? > > It works better would be the short answer. Having run both of > them through a test suite (available at > http://fedoraproject.org/wiki/QA/TestResults/Fedora9Swfdec/Rawhide), > swfdec performed *much* better, not the least because it supports > a larger subset of Flash 9. Are the results for gnash somewhere? And for which version? Anyway, I don't think this is very relevant, since both gnash and swfdec are fast moving targets and the release pace and features prioritisation makes benchmarking and projection of changes very uneasy. -- Pat From caolanm at redhat.com Thu May 15 09:36:54 2008 From: caolanm at redhat.com (Caolan McNamara) Date: Thu, 15 May 2008 10:36:54 +0100 Subject: Rawhide update problem In-Reply-To: <1210842748.3591.52.camel@T7.Linux> References: <1210842748.3591.52.camel@T7.Linux> Message-ID: <1210844214.7436.362.camel@vain.rhgalway> On Thu, 2008-05-15 at 10:12 +0100, Paul wrote: > If I exclude both hunspell and xulrunner from the update, I still get a > problem in that OOo-core needs hunspell.so.1 1) xulrunner depends on hunspell 2) OOo depends on hunspell and xulrunner 3) I bumped hunspell (about a month ago into dist-f10) and it changes abi, so rebuild needed. 4) xulrunner is configured --with-system-hunspell but actually #includes a *local* copy of hunspell.hxx which now no longer matches the system hunspell header, so it fails to link on a rebuild. That's the actual bug here. 5) proper fix is to fix xulrunner to not use the local hunspell.hxx header when building aginst an external hunspell 6) quick and dirty fix is to simply link the system hunspell.hxx over the local one in %prep and rebuild xulrunner, 7) Nevertheless, seeing as xulrunner apparently can only be changed if upstream commits the change (if I understand correctly) 5 or 6 cannot be done, or cannot be done quickly, so for the sake of a quiet life I added last night a constructor to hunspell to provide the expected symbol that the internal hunspell.hxx misleads xulrunner into thinking should exist and rebuilt hunspell to make it available, which should make a xulrunner rebuild possible without a xulrunner fix. > Are these expected to be fixed in today's rawhide? Probably tomorrow, or soon after that. C. From paul at all-the-johnsons.co.uk Thu May 15 10:10:43 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Thu, 15 May 2008 11:10:43 +0100 Subject: Rawhide update problem In-Reply-To: <1210844214.7436.362.camel@vain.rhgalway> References: <1210842748.3591.52.camel@T7.Linux> <1210844214.7436.362.camel@vain.rhgalway> Message-ID: <1210846243.25543.3.camel@T7.Linux> Hi, > > Are these expected to be fixed in today's rawhide? > > Probably tomorrow, or soon after that. And OOo. 3? ;-) TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From lordmorgul at gmail.com Thu May 15 10:11:30 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Thu, 15 May 2008 03:11:30 -0700 Subject: rawhide bugs becoming F-9 bugs In-Reply-To: <20080515090226.GB2656@free.fr> References: <20080514220114.GA2498@free.fr> <20080514235536.GB10077@free.fr> <482BAFF3.8070807@gmail.com> <20080515090226.GB2656@free.fr> Message-ID: <482C0C52.1060408@gmail.com> Patrice Dumas wrote: > On Wed, May 14, 2008 at 08:37:23PM -0700, Andrew Farris wrote: >> There were MANY duplicate bugs and some new bugs filed against rawhide >> which are F9 bugs in the last week before release... doing that change > > But aren't they rawhide bugs too? Maybe, maybe not. > It is much better to have those bugs > opened against the latest version of fedora, having to go through > bugzilla just to say "hey, don't close my bug" as unfrequently as > possible seems better to me. Sure that makes sense in the short term, but how/when do you change them? Thats precisely the problem (not ever changing rawhide bugs to a release version) which resulted in several year old bugs being open against 'rawhide' for code that will never be touched again. Searching 'rawhide' bugs is much less useful when its that cluttered... and thats very bad for testers trying not to report duplicate bugs. So the question is, if not NOW at release, then when should those open bugs be changed to a release version? How much harder would it be to do later than it is now? -- Andrew Farris www.lordmorgul.net gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29 From caolanm at redhat.com Thu May 15 10:27:15 2008 From: caolanm at redhat.com (Caolan McNamara) Date: Thu, 15 May 2008 11:27:15 +0100 Subject: Rawhide update problem In-Reply-To: <1210846243.25543.3.camel@T7.Linux> References: <1210842748.3591.52.camel@T7.Linux> <1210844214.7436.362.camel@vain.rhgalway> <1210846243.25543.3.camel@T7.Linux> Message-ID: <1210847235.7436.373.camel@vain.rhgalway> On Thu, 2008-05-15 at 11:10 +0100, Paul wrote: > Hi, > > > > Are these expected to be fixed in today's rawhide? > > > > Probably tomorrow, or soon after that. > > And OOo. 3? That's the plan anyway. Build will be forthcoming in the new few days. OOo 3 may be a bit of a rocky ride given the a) three layer stuff http://wiki.services.openoffice.org/wiki/ODF_Toolkit/Efforts/Three-Layer_OOo which moves a lot of stuff around and b) a good amount of new stuff is going to be in extensions, which is a little bit complicated for a simple upgrade path from 2.X.Y but it all works lovely locally here anyway :-) On the bright side, a giant whack of the fedora patches are merged, or being merged, into OOo3, and a lot of the code-reduction stuff I've been working on will come through in this version as well. Also OOo3 should build and work out of the box for ia64, arm-eabi etc. as well, so the archteams shouldn't have to do anything to get OOo3 to build for them. C. From pekkas at netcore.fi Thu May 15 12:14:43 2008 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 15 May 2008 15:14:43 +0300 (EEST) Subject: F8->F9 yum upgrade notes: bluecurve lost etc. In-Reply-To: References: Message-ID: On Wed, 14 May 2008, Kevin Kofler wrote: > Pekka Savola netcore.fi> writes: >> - The Bluecurve theme appears to have disappeared in a strange way. >> When you log in using an old user that had used bluecurve, all windows >> lacked the header (w/ the buttons) on top. Changing to 'Default' with >> Settings - Window Manager Settings fixed this, and when I next looked >> at the settings, bluecurve had already disppeared from selection. >> Some other user might not have realized what has gone wrong. >> Shouldn't there be an automatic transition path out if bluecurve no >> longer works? > > Is that in KDE? The KDE 4 version of the theme is called > quarticurve-kwin-theme, it should have replaced the old bluecurve-kwin-theme > automatically, you can set the theme in the options. This is xfce; kde is installed but not in use. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From sgrubb at redhat.com Thu May 15 12:24:08 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Thu, 15 May 2008 08:24:08 -0400 Subject: rhgb no more In-Reply-To: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> Message-ID: <200805150824.08419.sgrubb@redhat.com> On Tuesday 13 May 2008 13:07:51 Ray Strode wrote: > The replacement for rhgb will be a mixture of two things: > > 1) Starting gdm as early as possible and fitting it to give boot > progress before asking for login. Please note that the audit daemon needs to start before any daemon if you want it to work right. There's a couple reasons, one being that it enables the audit system and without that, any process running before the audit daemon is not auditable - ever. The work around is to add audit=1 to grub.conf, but then you get a performance hit for everyone. The second reason is that any audit event that occurs before the audit daemon runs could be lost. There may be AVCs on boot that you want or something else important that you wanted to capture. I guess the message is without coordination, some of our security features may not be working right unless consideration is given to their needs. -Steve From lesmikesell at gmail.com Thu May 15 12:55:04 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 15 May 2008 07:55:04 -0500 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <482BDDBF.4040207@fedoraproject.org> References: <4829B8D7.7010501@gmail.com> <4829E12A.7060901@gmail.com> <4829E3B0.9090108@redhat.com> <4829F09B.5040500@gmail.com> <4829F3FE.6070203@fedoraproject.org> <4829FCCA.50505@gmail.com> <4829FF0F.7050808@fedoraproject.org> <482A0B44.6050905@gmail.com> <482A0F27.401@fedoraproject.org> <482A123E.6010100@gmail.com> <482A14D4.4080304@fedoraproject.org> <482A22FE.2010509@gmail.com> <482A24EA.7040002@fedoraproject.org> <482A47C5.4020402@gmail.com> <482B0C46.5030409@fedoraproject.org> <482B196E.3010008@gmail.com> <482B217C.3020300@fedoraproject.or! g> <482B30C7.4040103@gmail.com> <482B31D9.3050107@fedoraproject.org> <482B4DDD.6000804@gmail.com> <482B4F5B.6040005@fedoraproject.org> <482B7748.4010709@gmail.com> <482B85D6.3020603@fedoraproject.org> <482B97A2.9080803@gmail.com> <482B9B01.3080305@fedoraproject.! org> <482BB0C8.6050205@gmail.com> <482BB329.7080708@fedoraproject.or! g> <482BC97A.3010602@gmail.com> <482BDDBF.4040207@fedoraproj! ect.org> Message-ID: <482C32A8.5070404@gmail.com> Rahul Sundaram wrote: > > Why, for example, couldn't the changes you say >> fedora needs as a dependency for openoffice be included in the >> jpackage repository for that fedora release and maintained as exact >> copies? > > You are again ignoring reasons already explained. Jpackage specializes > in Java packages and doesn't include all the packages Fedora does and > vice versa. So the dependencies cannot be the same. Even it does there > are differences in release cycles, patches, packaging and licensing > policy among other reasons. It is pretty difficult to have two variants > of a software with different maintainers in two different repositories > perfectly in sync all the time even with the best efforts. The 'different maintainers' is the point in question. Did anyone offer to maintain the duplicated packages upstream with needed changes instead of forking incompatible ones? Packages fedora doesn't include and vice versa are irrelevant as long as the dependencies within each set can be met internally. It's not a matter of whether this is difficult or not, it is a question of whether some well informed person involved with the distribution/repositories does it once or whether every user who needs something not included in the base repository has to muddle through the incompatibilities himself and hope it doesn't change by the next update. -- Les Mikesell lesmikesell at gmail.com From sundaram at fedoraproject.org Thu May 15 13:04:30 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 15 May 2008 18:34:30 +0530 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <482C32A8.5070404@gmail.com> References: <4829E3B0.9090108@redhat.com> <4829F09B.5040500@gmail.com> <4829F3FE.6070203@fedoraproject.org> <4829FCCA.50505@gmail.com> <4829FF0F.7050808@fedoraproject.org> <482A0B44.6050905@gmail.com> <482A0F27.401@fedoraproject.org> <482A123E.6010100@gmail.com> <482A14D4.4080304@fedoraproject.org> <482A22FE.2010509@gmail.com> <482A24EA.7040002@fedoraproject.org> <482A47C5.4020402@gmail.com> <482B0C46.5030409@fedoraproject.org> <482B196E.3010008@gmail.com> <482B217C.3020300@fedoraproject.or! g> <482B30C7.4040103@gmail.com> <482B31D9.3050107@fedoraproject.org> <482B4DDD.6000804@gmail.com> <482B4F5B.6040005@fedoraproject.org> <482B7748.4010709@gmail.com> <482B85D6.3020603@fedoraproject.org> <482B97A2.9080803@gmail.com> <482B9B01.3080305@fedoraproject.! org> <482BB0C8.6050205@gmail.com> <482BB329.7080708@fedoraproject.or! g> <482BC97A.3010602@gmail.com> <482BDDBF.4040207@fedoraproj! ect.org> <482C32A8.5070404@gmail.com> Message-ID: <482C34DE.5080702@fedoraproject.org> Les Mikesell wrote: > Rahul Sundaram wrote: >> >> Why, for example, couldn't the changes you say >>> fedora needs as a dependency for openoffice be included in the >>> jpackage repository for that fedora release and maintained as exact >>> copies? >> >> You are again ignoring reasons already explained. Jpackage specializes >> in Java packages and doesn't include all the packages Fedora does and >> vice versa. So the dependencies cannot be the same. Even it does there >> are differences in release cycles, patches, packaging and licensing >> policy among other reasons. It is pretty difficult to have two >> variants of a software with different maintainers in two different >> repositories perfectly in sync all the time even with the best efforts. > > The 'different maintainers' is the point in question. Did anyone offer > to maintain the duplicated packages upstream with needed changes instead > of forking incompatible ones? Maintainers even if they are some which they are in some cases cannot avoid changes introduced for other reasons. In some cases, they try to stay in sync. In other cases, they have to deviate. Picking one point and ignoring others just keeps continuing your discussions endlessly. So end this discussion here and just move on. Rahul From mclasen at redhat.com Thu May 15 13:02:10 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 15 May 2008 09:02:10 -0400 Subject: rhgb no more In-Reply-To: <200805150824.08419.sgrubb@redhat.com> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> <200805150824.08419.sgrubb@redhat.com> Message-ID: <1210856530.4615.2.camel@localhost.localdomain> On Thu, 2008-05-15 at 08:24 -0400, Steve Grubb wrote: > On Tuesday 13 May 2008 13:07:51 Ray Strode wrote: > > The replacement for rhgb will be a mixture of two things: > > > > 1) Starting gdm as early as possible and fitting it to give boot > > progress before asking for login. > > Please note that the audit daemon needs to start before any daemon if you want > it to work right. There's a couple reasons, one being that it enables the > audit system and without that, any process running before the audit daemon is > not auditable - ever. The work around is to add audit=1 to grub.conf, but > then you get a performance hit for everyone. > > The second reason is that any audit event that occurs before the audit daemon > runs could be lost. There may be AVCs on boot that you want or something else > important that you wanted to capture. > > I guess the message is without coordination, some of our security features may > not be working right unless consideration is given to their needs. It certainly doesn't help if these security features are 'special' in these little ways that then to easily break them. Isn't there something we can do to fix this ? Either make the audit system cope with userspace parts coming later, or if starting auditd first is really a hard requirement, implement that in a way that doesn't require mailing list reminders ? Matthias From cra at WPI.EDU Thu May 15 13:35:26 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 15 May 2008 09:35:26 -0400 Subject: rawhide bugs becoming F-9 bugs In-Reply-To: <482C0C52.1060408@gmail.com> References: <20080514220114.GA2498@free.fr> <20080514235536.GB10077@free.fr> <482BAFF3.8070807@gmail.com> <20080515090226.GB2656@free.fr> <482C0C52.1060408@gmail.com> Message-ID: <20080515133526.GA29284@angus.ind.WPI.EDU> On Thu, May 15, 2008 at 03:11:30AM -0700, Andrew Farris wrote: > So the question is, if not NOW at release, then when should those open bugs > be changed to a release version? How much harder would it be to do later > than it is now? If you are going to change rawhide bugs to Fx bugs at Fx release time, why even have rawhide as a bugzilla version at all? Why not report bugs in what will become F10 under version F10 now? You can tell from the reported date that it was during the development cycle of F10. If people can't be bothered to update a bug once every 6 months if it still applies to the latest version, then it should be closed WONTFIX. Leaving it as "rawhide" forever does no one any good. So I propose to get rid of "rawhide" as a Bugzilla version, and create the F10 version NOW, and likewise, create Fx Bugzilla versions at the time Fx is branched in CVS. From lesmikesell at gmail.com Thu May 15 13:48:11 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 15 May 2008 08:48:11 -0500 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <482C34DE.5080702@fedoraproject.org> References: <4829F09B.5040500@gmail.com> <4829F3FE.6070203@fedoraproject.org> <4829FCCA.50505@gmail.com> <4829FF0F.7050808@fedoraproject.org> <482A0B44.6050905@gmail.com> <482A0F27.401@fedoraproject.org> <482A123E.6010100@gmail.com> <482A14D4.4080304@fedoraproject.org> <482A22FE.2010509@gmail.com> <482A24EA.7040002@fedoraproject.org> <482A47C5.4020402@gmail.com> <482B0C46.5030409@fedoraproject.org> <482B196E.3010008@gmail.com> <482B217C.3020300@fedoraproject.or! g> <482B30C7.4040103@gmail.com> <482B31D9.3050107@fedoraproject.org> <482B4DDD.6000804@gmail.com> <482B4F5B.6040005@fedoraproject.org> <482B7748.4010709@gmail.com> <482B85D6.3020603@fedoraproject.org> <482B97A2.9080803@gmail.com> <482B9B01.3080305@fedoraproject.! org> <482BB0C8.6050205@gmail.com> <482BB329.7080708@fedoraproject.or! g> <482BC97A.3010602@gmail.com> <482BDDBF.4040207@fedoraproj! ect.org> <482C32A8.5070404@gmail.com> <482C34DE.5080702@fedoraproject.org> Message-ID: <482C3F1B.1090106@gmail.com> Rahul Sundaram wrote: > >>> Why, for example, couldn't the changes you say >>>> fedora needs as a dependency for openoffice be included in the >>>> jpackage repository for that fedora release and maintained as exact >>>> copies? >>> >>> You are again ignoring reasons already explained. Jpackage >>> specializes in Java packages and doesn't include all the packages >>> Fedora does and vice versa. So the dependencies cannot be the same. >>> Even it does there are differences in release cycles, patches, >>> packaging and licensing policy among other reasons. It is pretty >>> difficult to have two variants of a software with different >>> maintainers in two different repositories perfectly in sync all the >>> time even with the best efforts. >> >> The 'different maintainers' is the point in question. Did anyone >> offer to maintain the duplicated packages upstream with needed changes >> instead of forking incompatible ones? > > Maintainers even if they are some which they are in some cases cannot > avoid changes introduced for other reasons. In some cases, they try to > stay in sync. In other cases, they have to deviate. Picking one point > and ignoring others just keeps continuing your discussions endlessly. But this is the only point with any potential for improvement. It has been clear forever that the fedora repository isn't ever going to contain everything users are likely to need for reasons that don't matter because they aren't going to change. The only issue is how difficult the fedora distribution makes it to work with the larger community that pre-dates fedora and is willing to provide those things. > So end this discussion here and just move on. Are you saying there is no hope for improvement? -- Les Mikesell lesmikesell at gmail.com From sundaram at fedoraproject.org Thu May 15 13:56:37 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 15 May 2008 19:26:37 +0530 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <482C3F1B.1090106@gmail.com> References: <4829F3FE.6070203@fedoraproject.org> <4829FCCA.50505@gmail.com> <4829FF0F.7050808@fedoraproject.org> <482A0B44.6050905@gmail.com> <482A0F27.401@fedoraproject.org> <482A123E.6010100@gmail.com> <482A14D4.4080304@fedoraproject.org> <482A22FE.2010509@gmail.com> <482A24EA.7040002@fedoraproject.org> <482A47C5.4020402@gmail.com> <482B0C46.5030409@fedoraproject.org> <482B196E.3010008@gmail.com> <482B217C.3020300@fedoraproject.or! g> <482B30C7.4040103@gmail.com> <482B31D9.3050107@fedoraproject.org> <482B4DDD.6000804@gmail.com> <482B4F5B.6040005@fedoraproject.org> <482B7748.4010709@gmail.com> <482B85D6.3020603@fedoraproject.org> <482B97A2.9080803@gmail.com> <482B9B01.3080305@fedoraproject.! org> <482BB0C8.6050205@gmail.com> <482BB329.7080708@fedoraproject.or! g> <482BC97A.3010602@gmail.com> <482BDDBF.4040207@fedoraproj! ect.org> <482C32A8.5070404@gmail.com> <482C34DE.5080702@fedoraproject.org> <482C3F1B.1090106@gmail.com> Message-ID: <482C4115.80006@fedoraproject.org> Les Mikesell wrote: > Rahul Sundaram wrote: >> >> Maintainers even if they are some which they are in some cases cannot >> avoid changes introduced for other reasons. In some cases, they try to >> stay in sync. In other cases, they have to deviate. Picking one point >> and ignoring others just keeps continuing your discussions endlessly. > > But this is the only point with any potential for improvement. It is interrelated to others. You can't improve any one thing in isolation. >> So end this discussion here and just move on. > > Are you saying there is no hope for improvement? Not with your suggestion solutions, no. Rahul From sgrubb at redhat.com Thu May 15 13:59:28 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Thu, 15 May 2008 09:59:28 -0400 Subject: rhgb no more In-Reply-To: <1210856530.4615.2.camel@localhost.localdomain> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> <200805150824.08419.sgrubb@redhat.com> <1210856530.4615.2.camel@localhost.localdomain> Message-ID: <200805150959.28963.sgrubb@redhat.com> On Thursday 15 May 2008 09:02:10 Matthias Clasen wrote: > On Thu, 2008-05-15 at 08:24 -0400, Steve Grubb wrote: > > On Tuesday 13 May 2008 13:07:51 Ray Strode wrote: > > > The replacement for rhgb will be a mixture of two things: > > > > > > 1) Starting gdm as early as possible and fitting it to give boot > > > progress before asking for login. > > > > Please note that the audit daemon needs to start before any daemon if you > > want it to work right. There's a couple reasons, one being that it > > enables the audit system and without that, any process running before the > > audit daemon is not auditable - ever. The work around is to add audit=1 > > to grub.conf, but then you get a performance hit for everyone. > > > > The second reason is that any audit event that occurs before the audit > > daemon runs could be lost. There may be AVCs on boot that you want or > > something else important that you wanted to capture. > > > > I guess the message is without coordination, some of our security > > features may not be working right unless consideration is given to their > > needs. > > It certainly doesn't help if these security features are 'special' in > these little ways that then to easily break them. The audit system is special in many ways. But people keep forgetting it. For example, the LSB headers forget to include audit as a facility even though it considers syslog a facility. Anyways...I have been receiving bug reports from people wondering why the audit system is broken. I eventually tracked it down to users doing a graphical boot. > Isn't there something we can do to fix this ? The problem is that there are some people that do not want auditing because they want performance. So they don't install the package. But anyone that does want auditd enabled needs it to start earlier than login processes and daemons. If the audit daemon is enabled, then just issuing "auditctl -e 1" is sufficient. But you wouldn't want to do that for the general case due to performance. > Either make the audit system cope with userspace parts coming later, or if > starting auditd first is really a hard requirement, implement that in a way > that doesn't require mailing list reminders ? I have it as low in init priority as I can get it. It even starts before rsyslog. If a graphical boot does not honor the settings in the init scripts, what am I supposed to do? Is there another directory that I need to drop a file into that gets picked up by the boot sequence? -Steve From halfline at gmail.com Thu May 15 14:42:21 2008 From: halfline at gmail.com (Ray Strode) Date: Thu, 15 May 2008 10:42:21 -0400 Subject: rhgb no more In-Reply-To: <1dedbbfc0805131545j758171c0p8b2fa1dff71c3e3a@mail.gmail.com> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> <1dedbbfc0805131545j758171c0p8b2fa1dff71c3e3a@mail.gmail.com> Message-ID: <45abe7d80805150742q2cd87256m91354698f5567b6a@mail.gmail.com> Hi, > Would we get a slightly more graphical way to unlock our encrypted root > partitions than the current fairly inelegant text prompt. Yes, that's in the plans. Although, it may just be an image or something, since l10n in the initrd is sort of hard. --Ray From mclasen at redhat.com Thu May 15 14:41:30 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 15 May 2008 10:41:30 -0400 Subject: rhgb no more In-Reply-To: <200805150959.28963.sgrubb@redhat.com> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> <200805150824.08419.sgrubb@redhat.com> <1210856530.4615.2.camel@localhost.localdomain> <200805150959.28963.sgrubb@redhat.com> Message-ID: <1210862490.4615.5.camel@localhost.localdomain> On Thu, 2008-05-15 at 09:59 -0400, Steve Grubb wrote: > > Either make the audit system cope with userspace parts coming later, or if > > starting auditd first is really a hard requirement, implement that in a way > > that doesn't require mailing list reminders ? > > I have it as low in init priority as I can get it. It even starts before > rsyslog. If a graphical boot does not honor the settings in the init scripts, > what am I supposed to do? Is there another directory that I need to drop a > file into that gets picked up by the boot sequence? Out of interest, does that mean that unlocking an encrypted disk leaves no audit trail ? That potentially happens before init starts... From pertusus at free.fr Thu May 15 14:49:39 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 15 May 2008 16:49:39 +0200 Subject: rawhide bugs becoming F-9 bugs In-Reply-To: <482C0C52.1060408@gmail.com> References: <20080514220114.GA2498@free.fr> <20080514235536.GB10077@free.fr> <482BAFF3.8070807@gmail.com> <20080515090226.GB2656@free.fr> <482C0C52.1060408@gmail.com> Message-ID: <20080515144939.GI2656@free.fr> On Thu, May 15, 2008 at 03:11:30AM -0700, Andrew Farris wrote: > Patrice Dumas wrote: >> On Wed, May 14, 2008 at 08:37:23PM -0700, Andrew Farris wrote: >>> There were MANY duplicate bugs and some new bugs filed against rawhide >>> which are F9 bugs in the last week before release... doing that change >> >> But aren't they rawhide bugs too? > > Maybe, maybe not. > >> It is much better to have those bugs >> opened against the latest version of fedora, having to go through >> bugzilla just to say "hey, don't close my bug" as unfrequently as >> possible seems better to me. > > Sure that makes sense in the short term, but how/when do you change them? > Thats precisely the problem (not ever changing rawhide bugs to a release > version) which resulted in several year old bugs being open against > 'rawhide' for code that will never be touched again. Searching 'rawhide' > bugs is much less useful when its that cluttered... and thats very bad for > testers trying not to report duplicate bugs. You are misunderstanding what I say, I am not against changing from rawhide to a release, for the reason you state, that rawhide is a moving target. But I think that it is better to make a mistake by filling a bug against a more recent version than against an old version, because in case of an old version, the packager will have to move his bug one more time when the release becomes EOL. So to avoid having time lost in changing releases it is better to make mistake in the direction of the next release than in the direction of past releases, and I explained in the remaining of my mail why it was much more likely that a bug filed in the time of uncertainy between release and rawhide it is likely that rawhide is right. > So the question is, if not NOW at release, then when should those open bugs > be changed to a release version? How much harder would it be to do later > than it is now? As I said before, I think that the right time is when a rawhide branch is created in CVS, and not at release time. -- Pat From notting at redhat.com Thu May 15 14:52:02 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 15 May 2008 10:52:02 -0400 Subject: SWFdec vs Gnash (also gcjwebplugin) In-Reply-To: <20080515092203.GD2656@free.fr> References: <1210804636.27281.5.camel@trinity.blade> <20080515040125.GA26819@nostromo.devel.redhat.com> <20080515092203.GD2656@free.fr> Message-ID: <20080515145202.GB8944@nostromo.devel.redhat.com> Patrice Dumas (pertusus at free.fr) said: > > It works better would be the short answer. Having run both of > > them through a test suite (available at > > http://fedoraproject.org/wiki/QA/TestResults/Fedora9Swfdec/Rawhide), > > swfdec performed *much* better, not the least because it supports > > a larger subset of Flash 9. > > Are the results for gnash somewhere? Probably not, sorry. > And for which version? Whatever was in rawhide for F9 at the time. Note that another issue in swfdec's favor is gst-missing-plugins support. Bill From sgrubb at redhat.com Thu May 15 14:56:58 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Thu, 15 May 2008 10:56:58 -0400 Subject: rhgb no more In-Reply-To: <1210862490.4615.5.camel@localhost.localdomain> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> <200805150959.28963.sgrubb@redhat.com> <1210862490.4615.5.camel@localhost.localdomain> Message-ID: <200805151056.58863.sgrubb@redhat.com> On Thursday 15 May 2008 10:41:30 Matthias Clasen wrote: > On Thu, 2008-05-15 at 09:59 -0400, Steve Grubb wrote: > > > Either make the audit system cope with userspace parts coming later, or > > > if starting auditd first is really a hard requirement, implement that > > > in a way that doesn't require mailing list reminders ? > > > > I have it as low in init priority as I can get it. It even starts before > > rsyslog. If a graphical boot does not honor the settings in the init > > scripts, what am I supposed to do? Is there another directory that I need > > to drop a file into that gets picked up by the boot sequence? > > Out of interest, does that mean that unlocking an encrypted disk leaves > no audit trail ? This is completely unaudited. It probably should be audited, but I'd need to know more about it to see if its done before the kernel is running or after. If its before, there's not a lot you can do except slow down the number of attempts and render the machine unusable by refusing to accept anymore passphrases. If its after the kernel is running, then yes an audit event should be sent into the kernel. -Steve From halfline at gmail.com Thu May 15 15:00:09 2008 From: halfline at gmail.com (Ray Strode) Date: Thu, 15 May 2008 11:00:09 -0400 Subject: rhgb no more In-Reply-To: <482A8241.2050709@nicubunu.ro> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> <482A8241.2050709@nicubunu.ro> Message-ID: <45abe7d80805150800k5140c5aif1a2ba6036818e0e@mail.gmail.com> Hi, > It may be too early to ask about that, but from a theming/artwork point of > view, is correct my understanding that this will be one piece less to theme? > I expect we will have the during the progress the same background image as > GDM (which uses the same image as the default desktop) and a progress bar > made with GTK+. Maybe a panel (also made with GTK+?) to hold the progress > bar? A splash image? Some icons from the default icon theme? Additional > animations? I'm not sure exactly what it will look like but I think you're basicallly right. I don't think there are any elaborate plans to make it themable, but if we end up making the login screen themeable again this would probably be as well, since they're from the same program. --Ray From halfline at gmail.com Thu May 15 15:02:39 2008 From: halfline at gmail.com (Ray Strode) Date: Thu, 15 May 2008 11:02:39 -0400 Subject: rhgb no more In-Reply-To: <482AC2A4.6000004@redhat.com> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> <4829D8EF.9050101@ncsu.edu> <482AC2A4.6000004@redhat.com> Message-ID: <45abe7d80805150802v69418d08kd59e92532e8901f0@mail.gmail.com> Hi, > Please also put the .xsession start back in, it is missing again in F-9. Install the xorg-x11-xinit-session package (see the Release notes). --Ray From jkeating at redhat.com Thu May 15 15:06:50 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 15 May 2008 11:06:50 -0400 Subject: rawhide bugs becoming F-9 bugs In-Reply-To: <20080515144939.GI2656@free.fr> References: <20080514220114.GA2498@free.fr> <20080514235536.GB10077@free.fr> <482BAFF3.8070807@gmail.com> <20080515090226.GB2656@free.fr> <482C0C52.1060408@gmail.com> <20080515144939.GI2656@free.fr> Message-ID: <1210864010.3170.176.camel@localhost.localdomain> On Thu, 2008-05-15 at 16:49 +0200, Patrice Dumas wrote: > > You are misunderstanding what I say, I am not against changing from > rawhide to a release, for the reason you state, that rawhide is a moving > target. But I think that it is better to make a mistake by filling a bug > against a more recent version than against an old version, because in > case of an old version, the packager will have to move his bug one more > time when the release becomes EOL. So to avoid having time lost in > changing releases it is better to make mistake in the direction of the > next release than in the direction of past releases, and I explained in > the remaining of my mail why it was much more likely that a bug filed in > the time of uncertainy between release and rawhide it is likely that > rawhide is right. Perhaps what's missing then is a flag a maintainer can toss into a bug that will exclude it from automated culling. That way you won't have to "move" it again at any time, you just note to the triage team that you are aware and working the bug by dropping something in the bug. Maybe a flag, maybe a status whiteboard item, but something. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From j.w.r.degoede at hhs.nl Thu May 15 15:00:38 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 15 May 2008 17:00:38 +0200 Subject: Review swapsies Message-ID: <482C5016.6000901@hhs.nl> Hi All, I've got a few packages which I would like to have reviewed: lwp - LWP thread library - https://bugzilla.redhat.com/show_bug.cgi?id=446650 rvm - RVM library - https://bugzilla.redhat.com/show_bug.cgi?id=446651 rpc2 - RPC2 library - https://bugzilla.redhat.com/show_bug.cgi?id=446652 coda - Coda distributed file system - https://bugzilla.redhat.com/show_bug.cgi?id=446653 vegastrike-music - Music for Vega Strike - https://bugzilla.redhat.com/show_bug.cgi?id=445847 All pretty easies straightforward reviews and I would be happy to review any package of yours in return. Regards, Hans From lesmikesell at gmail.com Thu May 15 15:14:58 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 15 May 2008 10:14:58 -0500 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <482C4115.80006@fedoraproject.org> References: <4829FCCA.50505@gmail.com> <4829FF0F.7050808@fedoraproject.org> <482A0B44.6050905@gmail.com> <482A0F27.401@fedoraproject.org> <482A123E.6010100@gmail.com> <482A14D4.4080304@fedoraproject.org> <482A22FE.2010509@gmail.com> <482A24EA.7040002@fedoraproject.org> <482A47C5.4020402@gmail.com> <482B0C46.5030409@fedoraproject.org> <482B196E.3010008@gmail.com> <482B217C.3020300@fedoraproject.or! g> <482B30C7.4040103@gmail.com> <482B31D9.3050107@fedoraproject.org> <482B4DDD.6000804@gmail.com> <482B4F5B.6040005@fedoraproject.org> <482B7748.4010709@gmail.com> <482B85D6.3020603@fedoraproject.org> <482B97A2.9080803@gmail.com> <482B9B01.3080305@fedoraproject.! org> <482BB0C8.6050205@gmail.com> <482BB329.7080708@fedoraproject.or! g> <482BC97A.3010602@gmail.com> <482BDDBF.4040207@fedoraproj! ect.org> <482C32A8.5070404@gmail.com> <482C34DE.5080702@fedoraproject.org> <482C3F1B.1090106@gmail.com> <482C4115.80006@fedoraproject.org> Message-ID: <482C5372.6040309@gmail.com> Rahul Sundaram wrote: > >>> >>> Maintainers even if they are some which they are in some cases cannot >>> avoid changes introduced for other reasons. In some cases, they try >>> to stay in sync. In other cases, they have to deviate. Picking one >>> point and ignoring others just keeps continuing your discussions >>> endlessly. >> >> But this is the only point with any potential for improvement. > > It is interrelated to others. You can't improve any one thing in isolation. > >>> So end this discussion here and just move on. >> >> Are you saying there is no hope for improvement? > > Not with your suggestion solutions, no. Then what solution is there other than switch to a distribution that hasn't fragmented its upstream support community this way? -- Les Mikesell lesmikesell at gmail.com From pertusus at free.fr Thu May 15 15:17:27 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 15 May 2008 17:17:27 +0200 Subject: SWFdec vs Gnash (also gcjwebplugin) In-Reply-To: <20080515145202.GB8944@nostromo.devel.redhat.com> References: <1210804636.27281.5.camel@trinity.blade> <20080515040125.GA26819@nostromo.devel.redhat.com> <20080515092203.GD2656@free.fr> <20080515145202.GB8944@nostromo.devel.redhat.com> Message-ID: <20080515151727.GJ2656@free.fr> On Thu, May 15, 2008 at 10:52:02AM -0400, Bill Nottingham wrote: > Patrice Dumas (pertusus at free.fr) said: > > > It works better would be the short answer. Having run both of > > > them through a test suite (available at > > > http://fedoraproject.org/wiki/QA/TestResults/Fedora9Swfdec/Rawhide), > > > swfdec performed *much* better, not the least because it supports > > > a larger subset of Flash 9. > > > > Are the results for gnash somewhere? > > Probably not, sorry. > > > And for which version? > > Whatever was in rawhide for F9 at the time. If the time of the wikipage writing is that time, then it was 0.8.2, it is a bit strange. I tested them with 0.8.2 and the result are similar than with swfdec, except for "Photobucket Slideshow". > Note that another issue in swfdec's favor is gst-missing-plugins support. I searched google with gst-missing-plugins but didn't found anything relevant. Is there a web page for that? Also there was adiscussion about that on the gnash mailing list if I recall well, and there may be people not willing to help proprietary codecs, but I don't remember well. -- Pat From jdieter at gmail.com Thu May 15 15:25:34 2008 From: jdieter at gmail.com (Jonathan Dieter) Date: Thu, 15 May 2008 18:25:34 +0300 Subject: Review swapsies In-Reply-To: <482C5016.6000901@hhs.nl> References: <482C5016.6000901@hhs.nl> Message-ID: <1210865134.4295.21.camel@jdlaptop> On Thu, 2008-05-15 at 17:00 +0200, Hans de Goede wrote: > coda - Coda distributed file system - > https://bugzilla.redhat.com/show_bug.cgi?id=446653 What the current status on Coda? I remember looking into it years ago when I was trying to find a good distributed filesystem and it seemed to be pretty dead. Is it living again? Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From limb at jcomserv.net Thu May 15 15:30:01 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 15 May 2008 10:30:01 -0500 (CDT) Subject: Review swapsies In-Reply-To: <482C5016.6000901@hhs.nl> References: <482C5016.6000901@hhs.nl> Message-ID: <47595.198.175.55.5.1210865401.squirrel@mail.jcomserv.net> > Hi All, > > I've got a few packages which I would like to have reviewed: > lwp - LWP thread library - > https://bugzilla.redhat.com/show_bug.cgi?id=446650 > rvm - RVM library - https://bugzilla.redhat.com/show_bug.cgi?id=446651 > rpc2 - RPC2 library - https://bugzilla.redhat.com/show_bug.cgi?id=446652 > coda - Coda distributed file system - > https://bugzilla.redhat.com/show_bug.cgi?id=446653 > vegastrike-music - Music for Vega Strike - > https://bugzilla.redhat.com/show_bug.cgi?id=445847 I'll take vegastrike-music if you take inksmoto: https://bugzilla.redhat.com/show_bug.cgi?id=438156 > All pretty easies straightforward reviews and I would be happy to review > any > package of yours in return. > > Regards, > > Hans > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From notting at redhat.com Thu May 15 15:33:46 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 15 May 2008 11:33:46 -0400 Subject: SWFdec vs Gnash (also gcjwebplugin) In-Reply-To: <20080515151727.GJ2656@free.fr> References: <1210804636.27281.5.camel@trinity.blade> <20080515040125.GA26819@nostromo.devel.redhat.com> <20080515092203.GD2656@free.fr> <20080515145202.GB8944@nostromo.devel.redhat.com> <20080515151727.GJ2656@free.fr> Message-ID: <20080515153346.GA11874@nostromo.devel.redhat.com> Patrice Dumas (pertusus at free.fr) said: > > Note that another issue in swfdec's favor is gst-missing-plugins support. > > I searched google with gst-missing-plugins but didn't found anything > relevant. Is there a web page for that? > > Also there was adiscussion about that on the gnash mailing list if I > recall well, and there may be people not willing to help proprietary > codecs, but I don't remember well. It's not proprietary, it's any codecs that aren't installed. The gstreamer side has zero implementation details as to where codecs are installed from. Bill From sgrubb at redhat.com Thu May 15 15:31:39 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Thu, 15 May 2008 11:31:39 -0400 Subject: snort maintainer ? Message-ID: <200805151131.39629.sgrubb@redhat.com> Hi, The version of snort in fedora is almost a year old. There have been several releases since 2.7.0.1. I need the package updated and with prelude support enabled (bz 441844). Is anyone working on snort? May I work on it and update it if no one else is? Thanks, -Steve From twoerner at redhat.com Thu May 15 15:49:35 2008 From: twoerner at redhat.com (Thomas Woerner) Date: Thu, 15 May 2008 17:49:35 +0200 Subject: rhgb no more In-Reply-To: <45abe7d80805150802v69418d08kd59e92532e8901f0@mail.gmail.com> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> <4829D8EF.9050101@ncsu.edu> <482AC2A4.6000004@redhat.com> <45abe7d80805150802v69418d08kd59e92532e8901f0@mail.gmail.com> Message-ID: <482C5B8F.5040908@redhat.com> Ray Strode wrote: > Hi, > > >> Please also put the .xsession start back in, it is missing again in F-9. > Install the xorg-x11-xinit-session package (see the Release notes). > > --Ray > Argh... I was searching for the wrong name. Thanks, Thomas From pertusus at free.fr Thu May 15 15:51:30 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 15 May 2008 17:51:30 +0200 Subject: SWFdec vs Gnash (also gcjwebplugin) In-Reply-To: <20080515153346.GA11874@nostromo.devel.redhat.com> References: <1210804636.27281.5.camel@trinity.blade> <20080515040125.GA26819@nostromo.devel.redhat.com> <20080515092203.GD2656@free.fr> <20080515145202.GB8944@nostromo.devel.redhat.com> <20080515151727.GJ2656@free.fr> <20080515153346.GA11874@nostromo.devel.redhat.com> Message-ID: <20080515155130.GK2656@free.fr> On Thu, May 15, 2008 at 11:33:46AM -0400, Bill Nottingham wrote: > > It's not proprietary, it's any codecs that aren't installed. The > gstreamer side has zero implementation details as to where codecs > are installed from. Sure, but since there are real issues mainly for proprietary codecs, having such feature is likely to lead to helping install proprietary codecs. This is not necessarily the case, I understand it well, but (and without having looked at this issue), I would assume that it may lead to proprietary codecs being installed. This may well be a false assumption, but a quite logical one. And if there are no implementation details, it is even more probable. In any case my assumptions are irrelevant since I wasn't part of that discussion in gnash, and I don't care that much (I always have all the codecs installed). Anyway I could still have a look at it for fedora sake, but where is the documentation? -- Pat From dennis at ausil.us Thu May 15 15:53:29 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 15 May 2008 10:53:29 -0500 Subject: snort maintainer ? In-Reply-To: <200805151131.39629.sgrubb@redhat.com> References: <200805151131.39629.sgrubb@redhat.com> Message-ID: <200805151053.35393.dennis@ausil.us> On Thursday 15 May 2008, Steve Grubb wrote: > Hi, > > The version of snort in fedora is almost a year old. There have been > several releases since 2.7.0.1. I need the package updated and with prelude > support enabled (bz 441844). Is anyone working on snort? May I work on it > and update it if no one else is? > > Thanks, > -Steve I'm the maintainer of snort the packaging of it is better than when i started but is nasty and painful. the package gets compiled 9 times during the build. Im open to co-maintainers. i was using snort in an old job which is why i picked it up. so far no one has stepped up and submitted patches. So submit patches to me and we can look at making you a co-maintainer or even primary maintainer if you can give it the love it needs. the devel tree has 2.8.1 checked in but there were some issues with it. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From notting at redhat.com Thu May 15 15:58:51 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 15 May 2008 11:58:51 -0400 Subject: SWFdec vs Gnash (also gcjwebplugin) In-Reply-To: <20080515155130.GK2656@free.fr> References: <1210804636.27281.5.camel@trinity.blade> <20080515040125.GA26819@nostromo.devel.redhat.com> <20080515092203.GD2656@free.fr> <20080515145202.GB8944@nostromo.devel.redhat.com> <20080515151727.GJ2656@free.fr> <20080515153346.GA11874@nostromo.devel.redhat.com> <20080515155130.GK2656@free.fr> Message-ID: <20080515155851.GB11874@nostromo.devel.redhat.com> Patrice Dumas (pertusus at free.fr) said: > On Thu, May 15, 2008 at 11:33:46AM -0400, Bill Nottingham wrote: > > > > It's not proprietary, it's any codecs that aren't installed. The > > gstreamer side has zero implementation details as to where codecs > > are installed from. > > Sure, but since there are real issues mainly for proprietary codecs, > having such feature is likely to lead to helping install proprietary > codecs. This is not necessarily the case, I understand it well, but > (and without having looked at this issue), I would assume that it may > lead to proprietary codecs being installed. This may well be a false > assumption, but a quite logical one. And if there are no implementation > details, it is even more probable. In any case my assumptions are > irrelevant since I wasn't part of that discussion in gnash, and I don't > care that much (I always have all the codecs installed). > > Anyway I could still have a look at it for fedora sake, but where is > the documentation? http://cgit.freedesktop.org/~bilboed/gstreamer/tree/docs/design/draft-missing-plugins.txt and: http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-libs/html/gstreamer-base-utils.html would probably make a good start. Bill From halfline at gmail.com Thu May 15 16:07:36 2008 From: halfline at gmail.com (Ray Strode) Date: Thu, 15 May 2008 12:07:36 -0400 Subject: rhgb no more In-Reply-To: <1210799198.15577.3.camel@Diffingo.localdomain> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> <20080514125839.GA73283@dspnet.fr.eu.org> <1210799198.15577.3.camel@Diffingo.localdomain> Message-ID: <45abe7d80805150907i6316a263q56798a8616810fa2@mail.gmail.com> Hi, > ? > [user at host ~]$ ls -l /var/log/boot.log > -rw------- 1 root root 0 2008-05-11 04:31 /var/log/boot.log > > Why don't we start making use of boot.log... If the regular output is hidden, then > just redirect it to boot.log and if something does happen to go wrong, we can have > a notification in the GUI like we do for gnome-power-manager now. The current code (which isn't in rawhide yet) logs boot messages, and a notification icon on errors has been discussed before. --Ray From halfline at gmail.com Thu May 15 16:09:51 2008 From: halfline at gmail.com (Ray Strode) Date: Thu, 15 May 2008 12:09:51 -0400 Subject: rhgb no more In-Reply-To: <20080514125839.GA73283@dspnet.fr.eu.org> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> <20080514125839.GA73283@dspnet.fr.eu.org> Message-ID: <45abe7d80805150909s142e2858xcc946bbe4ffb49a7@mail.gmail.com> Hi, On Wed, May 14, 2008 at 8:58 AM, Olivier Galibert wrote: > On Tue, May 13, 2008 at 01:07:51PM -0400, Ray Strode wrote: >> 2) Hiding boot messages before gdm unless escape key is pressed. For >> graphics hardware that has drm modesetting, we'll be able to show some >> sort of pretty graphics, and for everyone else we'll show a very >> simple text mode progress. > > Here we go again. > > Are you going to wait for the escape key to be pressed or not for a > little while, or are we going to have to press just at the right time > between grub and modeswitch if we want to have a chance to check for > problems? The idea is Escape at any time would make the graphics disappear, and would replay all messages that have happened under the hood. We also talked about potentially trapping the vt switching keys since users may naturally try to vt switch to see messages. > Is there going to be an easy way (like there is with rhgb) to see the > messages (including history) while booting, to check for problems too? Right, that's the Escape key escape hatch mentioned above. Also messages are logged to a file that you can look at after boot up. --Ray From halfline at gmail.com Thu May 15 16:14:45 2008 From: halfline at gmail.com (Ray Strode) Date: Thu, 15 May 2008 12:14:45 -0400 Subject: rhgb no more In-Reply-To: <200805150824.08419.sgrubb@redhat.com> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> <200805150824.08419.sgrubb@redhat.com> Message-ID: <45abe7d80805150914y26bbae55r635134bd408e9d8@mail.gmail.com> Hi, > Please note that the audit daemon needs to start before any daemon if you want > it to work right. There's a couple reasons, one being that it enables the > audit system and without that, any process running before the audit daemon is > not auditable - ever. The work around is to add audit=1 to grub.conf, but > then you get a performance hit for everyone. > > The second reason is that any audit event that occurs before the audit daemon > runs could be lost. There may be AVCs on boot that you want or something else > important that you wanted to capture. There shouldn't be any semantic shift on this front, but if there's problems we can make sure they get fixed up before the release. From sgrubb at redhat.com Thu May 15 16:14:35 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Thu, 15 May 2008 12:14:35 -0400 Subject: snort maintainer ? In-Reply-To: <200805151053.35393.dennis@ausil.us> References: <200805151131.39629.sgrubb@redhat.com> <200805151053.35393.dennis@ausil.us> Message-ID: <200805151214.35733.sgrubb@redhat.com> On Thursday 15 May 2008 11:53:29 Dennis Gilmore wrote: > I'm the maintainer of snort the packaging of it is better than when i > started but is nasty and painful. ? Agreed > so far no one has stepped up and submitted patches. below. thanks, -Steve Only in devel: snort-2.4.3-configure64.patch Only in devel: snort-2.4.4-demarc-patch.diff diff -ur devel/snortd snort/snortd --- devel/snortd 2007-11-17 18:46:17.000000000 -0500 +++ snort/snortd 2008-04-26 14:27:28.000000000 -0400 @@ -22,12 +22,20 @@ # source the interface to listen on . /etc/sysconfig/snort +if [ "$USER"x != "x" ] ; then + USER="-u $USER" +fi + +if [ "$GROUP"x != "x" ] ; then + GROUP="-g $GROUP" +fi + # See how we were called. case "$1" in start) echo -n "Starting snort: " cd /var/log/snort - daemon /usr/sbin/snort -A fast -b -l /var/log/snort -d -D \ + daemon /usr/sbin/snort -D $SNORT_OPTIONS $USER $GROUP \ -i $INTERFACE -c /etc/snort/snort.conf touch /var/lock/subsys/snort echo diff -ur devel/snort.spec snort/snort.spec --- devel/snort.spec 2008-02-18 15:16:11.000000000 -0500 +++ snort/snort.spec 2008-04-26 14:32:31.000000000 -0400 @@ -1,7 +1,7 @@ Summary: Intrusion detection system Name: snort -Version: 2.7.0.1 -Release: 6%{?dist} +Version: 2.8.1 +Release: 1%{?dist} License: GPLv2 Group: Applications/Internet Source0: http://www.snort.org/dl/current/snort-%{version}.tar.gz @@ -16,6 +16,7 @@ BuildRequires: perl BuildRequires: pcre-devel BuildRequires: sed +BuildRequires: libprelude-devel %package plain+flexresp Summary: Snort with Flexible Response @@ -152,7 +153,7 @@ %build SNORT_BASE_CONFIG="--with-libpcap-includes=/usr/include/pcap \ - --enable-dynamicplugin" + --enable-dynamicplugin --enable-prelude" export LDFLAGS=-L/usr/lib64/mysql # there are some strange configure errors # when not doing a distclean between major builds. @@ -316,7 +317,7 @@ } install snort.8 %{buildroot}%{_mandir}/man8 -install etc/generators etc/gen-msg.map etc/sid etc/sid-msg.map etc/threshold.conf etc/unicode.map etc/reference.config etc/classification.config etc/snort.conf %{buildroot}%{_sysconfdir}/snort +install etc/gen-msg.map etc/sid-msg.map etc/threshold.conf etc/unicode.map etc/reference.config etc/classification.config etc/snort.conf %{buildroot}%{_sysconfdir}/snort install -p -m 755 %{SOURCE1} %{buildroot}/etc/rc.d/init.d mkdir -p %{buildroot}/etc/sysconfig/ install -p -m 644 %{SOURCE3} %{buildroot}/etc/sysconfig/snort @@ -452,6 +453,7 @@ # handle compressed man pages. %attr(755,root,root) %{_mandir}/man8/snort.8* %attr(755,root,root) %dir /var/log/snort +%attr(755,root,root) %dir %{_sysconfdir}/snort/rules %attr(644,root,root) %config %{_sysconfdir}/snort %attr(755,root,root) /etc/rc.d/init.d/snortd %{_libdir}/snort @@ -483,6 +485,9 @@ %changelog +* Fri Apr 25 2008 Steve Grubb - 2.8.1-1 +- update to 2.8.1 + * Mon Feb 18 2008 Fedora Release Engineering - 2.7.0.1-6 - Autorebuild for GCC 4.3 diff -ur devel/sysconfig.snort snort/sysconfig.snort --- devel/sysconfig.snort 2007-11-17 18:46:17.000000000 -0500 +++ snort/sysconfig.snort 2008-04-26 14:19:43.000000000 -0400 @@ -1,2 +1,11 @@ +# What user account should we run under. Empty means root +USER="" + +# What group account should we run under. Empty means root +GROUP="" + # define the interface we listen on -INTERFACE=eth0 +INTERFACE="eth0" + +# If you are using prelude, delete the '-A fast' option +SNORT_OPTIONS="-A fast -b -l /var/log/snort -d" From sundaram at fedoraproject.org Thu May 15 16:39:14 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 15 May 2008 22:09:14 +0530 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <482C5372.6040309@gmail.com> References: <4829FF0F.7050808@fedoraproject.org> <482A0B44.6050905@gmail.com> <482A0F27.401@fedoraproject.org> <482A123E.6010100@gmail.com> <482A14D4.4080304@fedoraproject.org> <482A22FE.2010509@gmail.com> <482A24EA.7040002@fedoraproject.org> <482A47C5.4020402@gmail.com> <482B0C46.5030409@fedoraproject.org> <482B196E.3010008@gmail.com> <482B217C.3020300@fedoraproject.or! g> <482B30C7.4040103@gmail.com> <482B31D9.3050107@fedoraproject.org> <482B4DDD.6000804@gmail.com> <482B4F5B.6040005@fedoraproject.org> <482B7748.4010709@gmail.com> <482B85D6.3020603@fedoraproject.org> <482B97A2.9080803@gmail.com> <482B9B01.3080305@fedoraproject.! org> <482BB0C8.6050205@gmail.com> <482BB329.7080708@fedoraproject.or! g> <482BC97A.3010602@gmail.com> <482BDDBF.4040207@fedoraproj! ect.org> <482C32A8.5070404@gmail.com> <482C34DE.5080702@fedoraproject.org> <482C3F1B.1090106@gmail.com> <482C4115.80006@fedoraproject.org> <482C5372.6040309@gmail.com> Message-ID: <482C6732.3090002@fedoraproject.org> Les Mikesell wrote: > Rahul Sundaram wrote: >> >>>> >>>> Maintainers even if they are some which they are in some cases >>>> cannot avoid changes introduced for other reasons. In some cases, >>>> they try to stay in sync. In other cases, they have to deviate. >>>> Picking one point and ignoring others just keeps continuing your >>>> discussions endlessly. >>> >>> But this is the only point with any potential for improvement. >> >> It is interrelated to others. You can't improve any one thing in >> isolation. >> >>>> So end this discussion here and just move on. >>> >>> Are you saying there is no hope for improvement? >> >> Not with your suggestion solutions, no. > > Then what solution is there other than switch to a distribution that > hasn't fragmented its upstream support community this way? Try finding one more suitable for your magic needs. Good luck. Rahul From jspaleta at gmail.com Thu May 15 16:52:50 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 15 May 2008 08:52:50 -0800 Subject: My introduction & Idea Storm for F10 In-Reply-To: <482C0038.2070500@fedoraproject.org> References: <6dd1343e0805150056x56dacdaalb54b67f10edcc939@mail.gmail.com> <482BF854.607@redhat.com> <6dd1343e0805150206t797e0ffag321f76665ea7d05a@mail.gmail.com> <482C0038.2070500@fedoraproject.org> Message-ID: <604aa7910805150952q139c7ac8s9a4aa226ad266f68@mail.gmail.com> On Thu, May 15, 2008 at 1:19 AM, Rahul Sundaram wrote: > The feature list gets filled by following the policy outlined in > > http://fedoraproject.org/wiki/Features/Policy > > This is based not just on popularity but someone or a team actually willing > to work on any particular feature. And let me stress that the importance of doing it this way. Unlike Dell, the bulk of the work done directly as part of this project is volunteer. Having a long list of wishlist or popularity list of potential features is a recipe for disaster unless there are people who are committed to doing any of the work. An Idea Storm sort of thing is only going to be valuable if people are prepared to actually use it as a way to decide what they are going to work on. And as a Board member, I can't just point at people and tell them to work on something that other people want. I have a hard enough time convincing people to do what I want, and I was voted in based on 'popular' support. Popular opinion doesn't translate directly into interest in working towards getting it done. We simply do not have the resources to direct people to work on things they aren't interested in working on. It just doesn't work that way at the larger Fedora project-wide level. The Feature process is there to make sure that we are doing what we can as a Project to adequately track and support people who have made a commitment to do the hard work of making something new happen. Now that isn't to say that some groups of contributors or even particular individuals wouldn't be interested in working on something based on popularity. I would not be one of those people, but they could very well exist. As a starting point for any serious discussion on how to do something like an Idea Storm, I would need to see a group of contributors commited to the ideal behind the concept. If you want to see an Idea Storm attempted, first find the group of developers/maintainers/contributors with a broad enough skillset to be an effective development team. Have those people affirm publicly that they will make the commitment to try to use an Idea Storm like list to direct the work that they do. We can then have a real discussion about how to position and run an Idea Storm. Once we settle on that, the team can run an Idea Storm, cull a concept, make a plan and then put an item on the Proposed Feature List for the next release like any other development group could. But you know what, I haven't seen skilled contributors asking to run this sort of thing anytime someone asks about it. I think there's more than enough work to go around as it stands. People aren't just standing around idle waiting for something to work on. I don't think this Project's problem is finding more work to do. I think the problem is finding more people to do more work. An Idea Storm will not help that. Failing the creation of such a development team to serve the whims of the populace, these sort of activities should be done inside the scope of an appropriate SIG who is receptive to making use of this sort of information. If a particular SIG wants to makes a commitment to organize its available resources around a popularity poll...it's up to them. The key idea here is there really needs to be a group of contributors willing to make use of a poll in a meaningful way, before we bother constructing this sort of poll. Having a long list of things languish and see no love..is a PR lose. If we are going to do it, then people must step forward and commit to using it before me generate the list. -jef From j.w.r.degoede at hhs.nl Thu May 15 17:17:43 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 15 May 2008 19:17:43 +0200 Subject: Review swapsies In-Reply-To: <1210865134.4295.21.camel@jdlaptop> References: <482C5016.6000901@hhs.nl> <1210865134.4295.21.camel@jdlaptop> Message-ID: <482C7037.3050200@hhs.nl> Jonathan Dieter wrote: > On Thu, 2008-05-15 at 17:00 +0200, Hans de Goede wrote: >> coda - Coda distributed file system - >> https://bugzilla.redhat.com/show_bug.cgi?id=446653 > > What the current status on Coda? I remember looking into it years ago > when I was trying to find a good distributed filesystem and it seemed to > be pretty dead. Is it living again? > I'm using coda for some distributed filesystems lab exercises at the university where I teach, so I'ven't really stressed it in anyway, but it seems to work well and yes coda seems very alive, the 6.9.3 release which I've packaged is from 11-Jan-2008 and there is a 6.9.4-rc2 release from 10-Apr-2008. Regards, Hans From jdieter at gmail.com Thu May 15 17:29:22 2008 From: jdieter at gmail.com (Jonathan Dieter) Date: Thu, 15 May 2008 20:29:22 +0300 Subject: Review swapsies In-Reply-To: <482C7037.3050200@hhs.nl> References: <482C5016.6000901@hhs.nl> <1210865134.4295.21.camel@jdlaptop> <482C7037.3050200@hhs.nl> Message-ID: <1210872562.4295.24.camel@jdlaptop> On Thu, 2008-05-15 at 19:17 +0200, Hans de Goede wrote: > Jonathan Dieter wrote: > > What the current status on Coda? I remember looking into it years ago > > when I was trying to find a good distributed filesystem and it seemed to > > be pretty dead. Is it living again? > > I'm using coda for some distributed filesystems lab exercises at the university > where I teach, so I'ven't really stressed it in anyway, but it seems to work > well and yes coda seems very alive, the 6.9.3 release which I've packaged is > from 11-Jan-2008 and there is a 6.9.4-rc2 release from 10-Apr-2008. And does coda module that comes with the kernel work with this release or do we need to package it separately? Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From angray at beeb.net Thu May 15 17:30:08 2008 From: angray at beeb.net (Aaron Gray) Date: Thu, 15 May 2008 18:30:08 +0100 Subject: Mylex DAC960 and LSI legacy SCSI controllers on Fedora 9 Beta References: <01f701c8b3a0$d0ffe670$0700a8c0@ze4427wm><20080511232811.GA28606@redhat.com> <02b501c8b43a$a72bfd80$0700a8c0@ze4427wm> Message-ID: <066a01c8b6b1$52cca8b0$0700a8c0@ze4427wm> >> On Sun, May 11, 2008 at 08:54:25PM +0100, Aaron Gray wrote: >> > The Mylex DAC960 and LSI sym53c8xx SCSI controllers do not seem to be >> > detected at install time on Fedora 9 Beta, where they are on FC6. >> > >> > On FC6 and below text mode boxes display the loading of the two >> > drivers. This does not happen on Fedora 9 Beta. >> > >> > Are legacy SCSI devices no longer supported or do I have a beta bug or >> > local problem ? >> >> Definitely wasn't intentional. > > Thanks Dave, I will try again once back on site, also I will try FC 7 & 8. Okay I have tried F9Beta again and it is not loading the DAC960 or sym53c8xx SCSI device drivers. Aaron From j.w.r.degoede at hhs.nl Thu May 15 17:39:39 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 15 May 2008 19:39:39 +0200 Subject: Review swapsies In-Reply-To: <1210872562.4295.24.camel@jdlaptop> References: <482C5016.6000901@hhs.nl> <1210865134.4295.21.camel@jdlaptop> <482C7037.3050200@hhs.nl> <1210872562.4295.24.camel@jdlaptop> Message-ID: <482C755B.9030504@hhs.nl> Jonathan Dieter wrote: > On Thu, 2008-05-15 at 19:17 +0200, Hans de Goede wrote: >> Jonathan Dieter wrote: >>> What the current status on Coda? I remember looking into it years ago >>> when I was trying to find a good distributed filesystem and it seemed to >>> be pretty dead. Is it living again? >> I'm using coda for some distributed filesystems lab exercises at the university >> where I teach, so I'ven't really stressed it in anyway, but it seems to work >> well and yes coda seems very alive, the 6.9.3 release which I've packaged is >> from 11-Jan-2008 and there is a 6.9.4-rc2 release from 10-Apr-2008. > > And does coda module that comes with the kernel work with this release > or do we need to package it separately? > It works Regards, Hans From lesmikesell at gmail.com Thu May 15 17:57:47 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 15 May 2008 12:57:47 -0500 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <482C6732.3090002@fedoraproject.org> References: <482A0B44.6050905@gmail.com> <482A0F27.401@fedoraproject.org> <482A123E.6010100@gmail.com> <482A14D4.4080304@fedoraproject.org> <482A22FE.2010509@gmail.com> <482A24EA.7040002@fedoraproject.org> <482A47C5.4020402@gmail.com> <482B0C46.5030409@fedoraproject.org> <482B196E.3010008@gmail.com> <482B217C.3020300@fedoraproject.or! g> <482B30C7.4040103@gmail.com> <482B31D9.3050107@fedoraproject.org> <482B4DDD.6000804@gmail.com> <482B4F5B.6040005@fedoraproject.org> <482B7748.4010709@gmail.com> <482B85D6.3020603@fedoraproject.org> <482B97A2.9080803@gmail.com> <482B9B01.3080305@fedoraproject.! org> <482BB0C8.6050205@gmail.com> <482BB329.7080708@fedoraproject.or! g> <482BC97A.3010602@gmail.com> <482BDDBF.4040207@fedoraproj! ect.org> <482C32A8.5070404@gmail.com> <482C34DE.5080702@fedoraproject.org> <482C3F1B.1090106@gmail.com> <482C4115.80006@fedoraproject.org> <482C5372.6040309@gmail.com> <482C6732.3090002@fedoraproject.org> Message-ID: <482C799B.8020206@gmail.com> Rahul Sundaram wrote: > >>>> Are you saying there is no hope for improvement? >>> >>> Not with your suggestion solutions, no. >> >> Then what solution is there other than switch to a distribution that >> hasn't fragmented its upstream support community this way? > > Try finding one more suitable for your magic needs. Good luck. Sun Java 1.5 and the distro-imposed need for java-sun-compat is about as mainstream and un-magic as you can get, which is why I use it as the poster child for this discussion, but it's a repeating theme and the details don't matter. Take just about anything that isn't included in the fedora repository for whatever reasons - and there seem to be plenty of reasons - and the distribution has made it harder than it should be to install and maintain. -- Les Mikesell lesmikesell at gmail.com From sundaram at fedoraproject.org Thu May 15 18:01:19 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 15 May 2008 23:31:19 +0530 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <482C799B.8020206@gmail.com> References: <482A0F27.401@fedoraproject.org> <482A123E.6010100@gmail.com> <482A14D4.4080304@fedoraproject.org> <482A22FE.2010509@gmail.com> <482A24EA.7040002@fedoraproject.org> <482A47C5.4020402@gmail.com> <482B0C46.5030409@fedoraproject.org> <482B196E.3010008@gmail.com> <482B217C.3020300@fedoraproject.or! g> <482B30C7.4040103@gmail.com> <482B31D9.3050107@fedoraproject.org> <482B4DDD.6000804@gmail.com> <482B4F5B.6040005@fedoraproject.org> <482B7748.4010709@gmail.com> <482B85D6.3020603@fedoraproject.org> <482B97A2.9080803@gmail.com> <482B9B01.3080305@fedoraproject.! org> <482BB0C8.6050205@gmail.com> <482BB329.7080708@fedoraproject.or! g> <482BC97A.3010602@gmail.com> <482BDDBF.4040207@fedoraproj! ect.org> <482C32A8.5070404@gmail.com> <482C34DE.5080702@fedoraproject.org> <482C3F1B.1090106@gmail.com> <482C4115.80006@fedoraproject.org> <482C5372.6040309@gmail.com> <482C6732.3090002@fedoraproject.org> <482C799B.8020206@gmail.com> Message-ID: <482C7A6F.40803@fedoraproject.org> Les Mikesell wrote: > Rahul Sundaram wrote: >> >>>>> Are you saying there is no hope for improvement? >>>> >>>> Not with your suggestion solutions, no. >>> >>> Then what solution is there other than switch to a distribution that >>> hasn't fragmented its upstream support community this way? >> >> Try finding one more suitable for your magic needs. Good luck. > > Sun Java 1.5 and the distro-imposed need for java-sun-compat is about as > mainstream and un-magic as you can get, which is why I use it as the > poster child for this discussion, but it's a repeating theme and the > details don't matter. Take just about anything that isn't included in > the fedora repository for whatever reasons - and there seem to be plenty > of reasons - and the distribution has made it harder than it should be > to install and maintain. Do feel free to find ones that suit your purpose better and use them. Rahul From j.w.r.degoede at hhs.nl Thu May 15 19:14:00 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 15 May 2008 21:14:00 +0200 Subject: Review swapsies In-Reply-To: <47595.198.175.55.5.1210865401.squirrel@mail.jcomserv.net> References: <482C5016.6000901@hhs.nl> <47595.198.175.55.5.1210865401.squirrel@mail.jcomserv.net> Message-ID: <482C8B78.3060200@hhs.nl> Jon Ciesla wrote: >> Hi All, >> >> I've got a few packages which I would like to have reviewed: >> lwp - LWP thread library - >> https://bugzilla.redhat.com/show_bug.cgi?id=446650 >> rvm - RVM library - https://bugzilla.redhat.com/show_bug.cgi?id=446651 >> rpc2 - RPC2 library - https://bugzilla.redhat.com/show_bug.cgi?id=446652 >> coda - Coda distributed file system - >> https://bugzilla.redhat.com/show_bug.cgi?id=446653 >> vegastrike-music - Music for Vega Strike - >> https://bugzilla.redhat.com/show_bug.cgi?id=445847 > > I'll take vegastrike-music if you take inksmoto: > https://bugzilla.redhat.com/show_bug.cgi?id=438156 > Done, I already noticed that this was way too long on the Games SIG packages need review list, so I was already planning on reviewing it :) Regards, Hans From stlwrt at gmail.com Thu May 15 19:37:17 2008 From: stlwrt at gmail.com (Pavel Shevchuk) Date: Thu, 15 May 2008 22:37:17 +0300 Subject: Review swapsies In-Reply-To: <482C8B78.3060200@hhs.nl> References: <482C5016.6000901@hhs.nl> <47595.198.175.55.5.1210865401.squirrel@mail.jcomserv.net> <482C8B78.3060200@hhs.nl> Message-ID: Took a look at rpc2, found two minor flaws. P.S. Would be nice if someone reviews efreet, it's also very simple spec: https://bugzilla.redhat.com/show_bug.cgi?id=442404 On 5/15/08, Hans de Goede wrote: > Jon Ciesla wrote: > > > > > > Hi All, > > > > > > I've got a few packages which I would like to have reviewed: > > > lwp - LWP thread library - > > > https://bugzilla.redhat.com/show_bug.cgi?id=446650 > > > rvm - RVM library - > https://bugzilla.redhat.com/show_bug.cgi?id=446651 > > > rpc2 - RPC2 library - > https://bugzilla.redhat.com/show_bug.cgi?id=446652 > > > coda - Coda distributed file system - > > > https://bugzilla.redhat.com/show_bug.cgi?id=446653 > > > vegastrike-music - Music for Vega Strike - > > > https://bugzilla.redhat.com/show_bug.cgi?id=445847 > > > > > > > I'll take vegastrike-music if you take inksmoto: > > https://bugzilla.redhat.com/show_bug.cgi?id=438156 > > > > > > Done, > > I already noticed that this was way too long on the Games SIG packages need > review list, so I was already planning on reviewing it :) > > > Regards, > > Hans > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- http://scwlab.com From seg at haxxed.com Thu May 15 19:40:41 2008 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 15 May 2008 14:40:41 -0500 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <482BC97A.3010602@gmail.com> References: <482B31D9.3050107@fedoraproject.org> <482B4DDD.6000804@gmail.com> <482B4F5B.6040005@fedoraproject.org> <482B7748.4010709@gmail.com> <482B85D6.3020603@fedoraproject.org> <482B97A2.9080803@gmail.com> <482BB0C8.6050205@gmail.com> <482BB329.7080708@fedoraproject.org> <482BC97A.3010602@gmail.com> Message-ID: <1218b5bc0805151240w581841d7md1598f41065ede90@mail.gmail.com> On Thu, May 15, 2008 at 12:26 AM, Les Mikesell wrote: > The only parts where this matters are those where there is incompatible > duplication within the fedora repository. What I specifically fail to > understand is why those packages that have been duplicated could not have > been done in a way that the same contents would be acceptable in both > repositories. Why, for example, couldn't the changes you say fedora needs > as a dependency for openoffice be included in the jpackage repository for > that fedora release and maintained as exact copies? Overlapping repos are fundamentally broken, period. We've had long flamewars in the past about how ATrpms freely replaces Fedora packages making an unsupportable mess. Why are we allowing JPackage to pull the same crap? Fedora must not make any consessions to allowing JPackage to maintain overlapping packages in their repos. Because it is brain damaged. Period. This goes for all external repos, not just JPackage. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wcohen at redhat.com Thu May 15 20:02:46 2008 From: wcohen at redhat.com (William Cohen) Date: Thu, 15 May 2008 16:02:46 -0400 Subject: Fedora 9 livecd-creator questions Message-ID: <482C96E6.3070000@redhat.com> Hi All, I have previously generated a livecd spin that includes a Systemtap tutorial (based on F-7 and F-8). I am updating this livecd to be based on Fedora 9. I have a couple questions when going through this process to build a SystemTap tutorial. The /usr/share/livecd-tools/livecd-fedora-9-base-desktop.ks has : selinux --enforcing However this appears to cause the machine creating the livecd to hang as mentioned in Red Hat bz #445630. I guess for the time being turn off selinux when generating a livecd. It is a less drastic workaround for this? I am doing the livecd creation on a x86_64 machine, but I want the livecd to be an 32-bit (i386) version. Is "setarch i386" command preceeding the livecd-creator, the way to build a 32-bit livecd on a 64-bit machine without modifying the kickstart file? For some of the experiments in the tutorial root access in a shell is required. What would be the preferred way to allow someone using the livecd to get root access on the livecd? We would be happy to make the SystemtapTap tutorial livecd images available as a custom spin. How does one get a custom spin onto the following list: http://spins.fedoraproject.org/ The previous systemtap tutorial livecds iso's are available at: http://sourceware.org/systemtap/ftp/livecds/ -Will From sundaram at fedoraproject.org Thu May 15 20:16:53 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 16 May 2008 01:46:53 +0530 Subject: Fedora 9 livecd-creator questions In-Reply-To: <482C96E6.3070000@redhat.com> References: <482C96E6.3070000@redhat.com> Message-ID: <482C9A35.2020305@fedoraproject.org> William Cohen wrote: > Hi All, > > I have previously generated a livecd spin that includes a Systemtap > tutorial (based on F-7 and F-8). I am updating this livecd to be based > on Fedora 9. I have a couple questions when going through this process > to build a SystemTap tutorial. > > The /usr/share/livecd-tools/livecd-fedora-9-base-desktop.ks has : > > selinux --enforcing > > However this appears to cause the machine creating the livecd to hang as > mentioned in Red Hat bz #445630. I guess for the time being turn off > selinux when generating a livecd. It is a less drastic workaround for this? Set it to permissive mode. Turning it off entirely would prevent you from creating a live cd with SELinux enforcing since the labels wouldn't be correct. Refer ongoing fedora-selinux list discussions for details. > I am doing the livecd creation on a x86_64 machine, but I want the > livecd to be an 32-bit (i386) version. Is "setarch i386" command > preceeding the livecd-creator, the way to build a 32-bit livecd on a > 64-bit machine without modifying the kickstart file? Yes. > For some of the experiments in the tutorial root access in a shell is > required. What would be the preferred way to allow someone using the > livecd to get root access on the livecd? Sure. The default root passwords are blank on the other live images too. > We would be happy to make the SystemtapTap tutorial livecd images > available as a custom spin. How does one get a custom spin onto the > following list: > > http://spins.fedoraproject.org/ We, the spins SIG are responsible for this now. Guidelines at http://fedoraproject.org/wiki/SIGs/Spins Rahul From lesmikesell at gmail.com Thu May 15 21:06:33 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 15 May 2008 16:06:33 -0500 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <1218b5bc0805151240w581841d7md1598f41065ede90@mail.gmail.com> References: <482B31D9.3050107@fedoraproject.org> <482B4DDD.6000804@gmail.com> <482B4F5B.6040005@fedoraproject.org> <482B7748.4010709@gmail.com> <482B85D6.3020603@fedoraproject.org> <482B97A2.9080803@gmail.com> <482BB0C8.6050205@gmail.com> <482BB329.7080708@fedoraproject.org> <482BC97A.3010602@gmail.com> <1218b5bc0805151240w581841d7md1598f41065ede90@mail.gmail.com> Message-ID: <482CA5D9.6060603@gmail.com> Callum Lerwick wrote: > > > The only parts where this matters are those where there is > incompatible duplication within the fedora repository. What I > specifically fail to understand is why those packages that have been > duplicated could not have been done in a way that the same contents > would be acceptable in both repositories. Why, for example, > couldn't the changes you say fedora needs as a dependency for > openoffice be included in the jpackage repository for that fedora > release and maintained as exact copies? > > > Overlapping repos are fundamentally broken, period. Then why create overlap? > We've had long > flamewars in the past about how ATrpms freely replaces Fedora packages > making an unsupportable mess. I think ATrpms pre-dates fedora. Freshrpms certainly did. Do you think you can retroactively trademark the package names or something? > Why are we allowing JPackage to pull the > same crap? > > Fedora must not make any consessions to allowing JPackage to maintain > overlapping packages in their repos. Because it is brain damaged. Period. > > This goes for all external repos, not just JPackage. Allow? What kind of control do you think you have over other repos that were providing packages before fedora existed or the earlier versions of RedHat even had public update repositories? Your choice is to cooperate or not. The impression I got from the earlier discussions was that you refused the compromises that would have made consolidating the repositories acceptable, forked some of the packages from their pre-existing versions and thus made it next to impossible for users to get the rest of the content which, for various reasons, you didn't include. Maybe you see this some other way? -- Les Mikesell lesmikesell at gmail.com From konrad at tylerc.org Thu May 15 21:15:48 2008 From: konrad at tylerc.org (Konrad Meyer) Date: Thu, 15 May 2008 14:15:48 -0700 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <482CA5D9.6060603@gmail.com> References: <1218b5bc0805151240w581841d7md1598f41065ede90@mail.gmail.com> <482CA5D9.6060603@gmail.com> Message-ID: <200805151415.48220.konrad@tylerc.org> Quoth Les Mikesell: > Callum Lerwick wrote: > I think ATrpms pre-dates fedora. Freshrpms certainly did. Do you think > you can retroactively trademark the package names or something? Red Hat Linux pre-dates Fedora also, but it doesn't claim to provide packages for Fedora 8. -- Conrad Meyer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From lesmikesell at gmail.com Thu May 15 21:25:54 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 15 May 2008 16:25:54 -0500 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <200805151415.48220.konrad@tylerc.org> References: <1218b5bc0805151240w581841d7md1598f41065ede90@mail.gmail.com> <482CA5D9.6060603@gmail.com> <200805151415.48220.konrad@tylerc.org> Message-ID: <482CAA62.8060808@gmail.com> Konrad Meyer wrote: > Quoth Les Mikesell: >> Callum Lerwick wrote: >> I think ATrpms pre-dates fedora. Freshrpms certainly did. Do you think >> you can retroactively trademark the package names or something? > > Red Hat Linux pre-dates Fedora also, but it doesn't claim to provide packages > for Fedora 8. If Red Hat Linux had a history of providing additional services to users and thus you expected it to provide a repository for fedora version X, would you subvert that ability by forking some of its existing packages into incompatible versions duplicated into your own repository? -- Les Mikesell lesmikesell at gmail.com From eparis at redhat.com Thu May 15 21:33:05 2008 From: eparis at redhat.com (Eric Paris) Date: Thu, 15 May 2008 17:33:05 -0400 Subject: Fedora 9 livecd-creator questions In-Reply-To: <482C96E6.3070000@redhat.com> References: <482C96E6.3070000@redhat.com> Message-ID: <1210887186.3061.74.camel@localhost.localdomain> On Thu, 2008-05-15 at 16:02 -0400, William Cohen wrote: > Hi All, > > I have previously generated a livecd spin that includes a Systemtap tutorial > (based on F-7 and F-8). I am updating this livecd to be based on Fedora 9. I > have a couple questions when going through this process to build a SystemTap > tutorial. > > The /usr/share/livecd-tools/livecd-fedora-9-base-desktop.ks has : > > selinux --enforcing > > However this appears to cause the machine creating the livecd to hang as > mentioned in Red Hat bz #445630. I guess for the time being turn off selinux > when generating a livecd. It is a less drastic workaround for this? Biggest problem is trying to build say an F9 livecd on F8. When it installs the selinux policy in the chroot it actually loads that policy into the running kernel and crap hits the fan. For today your best choices I think are the run F9 composes on F9 with it set permissive, or turn it all the way off. I've been working on making selinux and livecd-creator play nicely together all week. Actually today I got my first bootable livecd images out of a rawhide machine running enforcing. But I still doubt I could get an F9 cd out of a say an F6 system. I'll get there but its still a ways out since me/the selinux community is blundering around in the dark without a guide on how the whole buildroot/livecd/rpm stuff works. > For some of the experiments in the tutorial root access in a shell is required. > What would be the preferred way to allow someone using the livecd to get root > access on the livecd? I added a rootpw blahblah statement to my kickstart and it didn't take. Could be because it just doesn't care or it could be because it was rawhide. Anyway, if you do get a rootpw loaded let me know how you fixed that. -Eric From dr.diesel at gmail.com Thu May 15 21:33:02 2008 From: dr.diesel at gmail.com (Dr. Diesel) Date: Thu, 15 May 2008 17:33:02 -0400 Subject: Anyone else with hard freezes? In-Reply-To: <2a28d2ab0805141459j22db5edcmb858afd627ea5d01@mail.gmail.com> References: <2a28d2ab0805061455l9afae56p8a86218d08bc4b92@mail.gmail.com> <80d7e4090805081625m111b7955v2c96d864275334b2@mail.gmail.com> <2a28d2ab0805081723q6a3537d7n93db59501cf23b16@mail.gmail.com> <2a28d2ab0805090336j78fe2772q1df6283e3c5d38cf@mail.gmail.com> <1210398432.17530.0.camel@optimus> <2a28d2ab0805130448s2b3e8c8aw5e526bd04949d60a@mail.gmail.com> <2a28d2ab0805131341x6d4d6332nd89e1252839f3866@mail.gmail.com> <2a28d2ab0805140713h542598d6y5c010885dac62687@mail.gmail.com> <482AF52D.1080509@poolshark.org> <2a28d2ab0805141459j22db5edcmb858afd627ea5d01@mail.gmail.com> Message-ID: <2a28d2ab0805151433m1b323ecak47a256b148cb982f@mail.gmail.com> And more! ISO 9660 Extensions: Microsoft Joliet Level 3 ISO 9660 Extensions: RRIP_1991A mtrr: no MTRR for d0000000,ff00000 found console-kit-dae[2420]: segfault at 8 ip 3c67e2a699 sp 4100fff0 error 4 in libglib-2.0.so.0.1600.3[3c67e00000+de000] mtrr: base(0xd0000000) is not aligned on a size(0xff00000) boundary Andy On Wed, May 14, 2008 at 5:59 PM, Dr. Diesel wrote: > Thanks for the input! > > I ran smartctl -t long and found no errors, did it several times! > > fsck found a zillion errors, is it possible this is still a bug issue? > > Thanks > Andy > > On Wed, May 14, 2008 at 10:20 AM, Denis Leroy wrote: >> Dr. Diesel wrote: >>> >>> All, it is possible that all of these freezes are caused by a failing >>> hard drive? Perhaps failed during the upgrade from F8 to F9 and its >>> only 3 months old!! Mmmmm, just my luck! >>> >>> Last night I suddenly began to receive Kerneloops after Kerneloops, >>> 4-5 total then it hard locked. When I went to reboot I got the error >>> couldn't find /sys /root etc, couldn't find any of the logical >>> volumes. I tried rebooting it several times and finally it made it to >>> doing an automatic fsck that fails at about 4%. SMART says the HD is >>> fine. >> >> Note that the overall SMART health status is near useless. What you should >> do is look at the disk error log : >> >> # smartctl -l error /dev/sda >> >> and run a short and/or long self test (short is couple of mins, long is >> typically 1 to 2 hours): >> >> # smartctl -t long /dev/sda >> # smartctl -t short /dev/sda >> >> Results of the self test after completion: >> >> # smartctl -l selftest /dev/sda >> >> You may want to do this from a live CD if your system is really unstable. >> >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list >> > > > > -- > projecthuh.com > All of my bits are free, are yours? Fedoraproject.org > -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org From jkeating at redhat.com Thu May 15 21:38:51 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 15 May 2008 17:38:51 -0400 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <482CAA62.8060808@gmail.com> References: <1218b5bc0805151240w581841d7md1598f41065ede90@mail.gmail.com> <482CA5D9.6060603@gmail.com> <200805151415.48220.konrad@tylerc.org> <482CAA62.8060808@gmail.com> Message-ID: <1210887531.4259.1.camel@localhost.localdomain> On Thu, 2008-05-15 at 16:25 -0500, Les Mikesell wrote: > If Red Hat Linux had a history of providing additional services to users > and thus you expected it to provide a repository for fedora version X, > would you subvert that ability by forking some of its existing packages > into incompatible versions duplicated into your own repository? Fedora cannot point to, make reference of, or otherwise "endorse" software repos external to Fedora's control. This introduces a legal risk. We also can't make use of external packages to build our dependent packages as this also introduces a security risk to our buildsystem. Therefor if it's software that is suitable to be in Fedora, the only way we can officially provide it for Fedora users is by having it in Fedora. This is why we have an open package submission system and an open build system and an open distribution. All other attempts at this game have failed in various ways. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alan at redhat.com Thu May 15 22:01:01 2008 From: alan at redhat.com (Alan Cox) Date: Thu, 15 May 2008 18:01:01 -0400 Subject: Anyone else with hard freezes? In-Reply-To: <2a28d2ab0805151433m1b323ecak47a256b148cb982f@mail.gmail.com> References: <80d7e4090805081625m111b7955v2c96d864275334b2@mail.gmail.com> <2a28d2ab0805081723q6a3537d7n93db59501cf23b16@mail.gmail.com> <2a28d2ab0805090336j78fe2772q1df6283e3c5d38cf@mail.gmail.com> <1210398432.17530.0.camel@optimus> <2a28d2ab0805130448s2b3e8c8aw5e526bd04949d60a@mail.gmail.com> <2a28d2ab0805131341x6d4d6332nd89e1252839f3866@mail.gmail.com> <2a28d2ab0805140713h542598d6y5c010885dac62687@mail.gmail.com> <482AF52D.1080509@poolshark.org> <2a28d2ab0805141459j22db5edcmb858afd627ea5d01@mail.gmail.com> <2a28d2ab0805151433m1b323ecak47a256b148cb982f@mail.gmail.com> Message-ID: <20080515220101.GA8240@devserv.devel.redhat.com> On Thu, May 15, 2008 at 05:33:02PM -0400, Dr. Diesel wrote: > And more! > > ISO 9660 Extensions: Microsoft Joliet Level 3 > ISO 9660 Extensions: RRIP_1991A > mtrr: no MTRR for d0000000,ff00000 found > console-kit-dae[2420]: segfault at 8 ip 3c67e2a699 sp 4100fff0 error 4 > in libglib-2.0.so.0.1600.3[3c67e00000+de000] > mtrr: base(0xd0000000) is not aligned on a size(0xff00000) boundary Out of curiosity what does memtest86 think of the box. A mix of random memory and disk corruptions is a good candidate for suspecting RAM (although it's certainly not conclusive and it could be an FC9 triggered bug) From lesmikesell at gmail.com Thu May 15 22:06:57 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 15 May 2008 17:06:57 -0500 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <1210887531.4259.1.camel@localhost.localdomain> References: <1218b5bc0805151240w581841d7md1598f41065ede90@mail.gmail.com> <482CA5D9.6060603@gmail.com> <200805151415.48220.konrad@tylerc.org> <482CAA62.8060808@gmail.com> <1210887531.4259.1.camel@localhost.localdomain> Message-ID: <482CB401.5040708@gmail.com> Jesse Keating wrote: > On Thu, 2008-05-15 at 16:25 -0500, Les Mikesell wrote: >> If Red Hat Linux had a history of providing additional services to users >> and thus you expected it to provide a repository for fedora version X, >> would you subvert that ability by forking some of its existing packages >> into incompatible versions duplicated into your own repository? > > Fedora cannot point to, make reference of, or otherwise "endorse" > software repos external to Fedora's control. This introduces a legal > risk. We also can't make use of external packages to build our > dependent packages as this also introduces a security risk to our > buildsystem. Therefor if it's software that is suitable to be in > Fedora, the only way we can officially provide it for Fedora users is by > having it in Fedora. This is why we have an open package submission > system and an open build system and an open distribution. All other > attempts at this game have failed in various ways. But even given the constraint that the fedora repo is self-consistent and contains all its own dependencies I don't see why that necessarily forces any incompatibilities with external repos. It looks like it just happened because no one cared about coordinating with them. The bigger issue for me is that you also can't or won't include everything that those external repos provide. That shouldn't be a surprise to anyone and it makes the incompatibilities a big problem. It's one thing to 'not endorse' anything outside and something very different to actively break their attempts to provide additional content for your users which is what forking their upstream packages amounts to, given the limitations of yum in sorting this stuff out. -- Les Mikesell lesmikesell at gmail.com From smooge at gmail.com Thu May 15 22:18:41 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 15 May 2008 16:18:41 -0600 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <482CB401.5040708@gmail.com> References: <1218b5bc0805151240w581841d7md1598f41065ede90@mail.gmail.com> <482CA5D9.6060603@gmail.com> <200805151415.48220.konrad@tylerc.org> <482CAA62.8060808@gmail.com> <1210887531.4259.1.camel@localhost.localdomain> <482CB401.5040708@gmail.com> Message-ID: <80d7e4090805151518p3a5b2c83y501f36cba50b5618@mail.gmail.com> On Thu, May 15, 2008 at 4:06 PM, Les Mikesell wrote: > Jesse Keating wrote: >> >> On Thu, 2008-05-15 at 16:25 -0500, Les Mikesell wrote: >>> >>> If Red Hat Linux had a history of providing additional services to users >>> and thus you expected it to provide a repository for fedora version X, would >>> you subvert that ability by forking some of its existing packages into >>> incompatible versions duplicated into your own repository? >> >> Fedora cannot point to, make reference of, or otherwise "endorse" >> software repos external to Fedora's control. This introduces a legal >> risk. We also can't make use of external packages to build our >> dependent packages as this also introduces a security risk to our >> buildsystem. Therefor if it's software that is suitable to be in >> Fedora, the only way we can officially provide it for Fedora users is by >> having it in Fedora. This is why we have an open package submission >> system and an open build system and an open distribution. All other >> attempts at this game have failed in various ways. > > But even given the constraint that the fedora repo is self-consistent and > contains all its own dependencies I don't see why that necessarily forces > any incompatibilities with external repos. It looks like it just happened > because no one cared about coordinating with them. > Les how about instead of point out all the faillings of the Fedora project every other email.. try and do some work. If you spent half of your energy you spent on making everyone look like idiots, misfits, and failures.. you could have sponsored and worked on some of those packages you are griping about. > The bigger issue for me is that you also can't or won't include everything > that those external repos provide. That shouldn't be a surprise to anyone > and it makes the incompatibilities a big problem. It's one thing to 'not > endorse' anything outside and something very different to actively break > their attempts to provide additional content for your users which is what > forking their upstream packages amounts to, given the limitations of yum in > sorting this stuff out. > > -- > Les Mikesell > lesmikesell at gmail.com > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From lesmikesell at gmail.com Thu May 15 22:49:08 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 15 May 2008 17:49:08 -0500 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <80d7e4090805151518p3a5b2c83y501f36cba50b5618@mail.gmail.com> References: <1218b5bc0805151240w581841d7md1598f41065ede90@mail.gmail.com> <482CA5D9.6060603@gmail.com> <200805151415.48220.konrad@tylerc.org> <482CAA62.8060808@gmail.com> <1210887531.4259.1.camel@localhost.localdomain> <482CB401.5040708@gmail.com> <80d7e4090805151518p3a5b2c83y501f36cba50b5618@mail.gmail.com> Message-ID: <482CBDE4.9050907@gmail.com> Stephen John Smoogen wrote: > > Les how about instead of point out all the faillings of the Fedora > project every other email.. try and do some work. > If you spent half of > your energy you spent on making everyone look like idiots, misfits, > and failures.. you could have sponsored and worked on some of those > packages you are griping about. The packages I want to install aren't missing from fedora because of a lack of packagers and I don't particularly want them in a fedora-maintained and policy-restricted repository. For the java-1.5.0-sun-compat package that makes a good example, there was a time when I'd find the instructions to set up yum for a current fedora here http://www.jpackage.org/yum.php. A working file probably still exists somewhere. -- Les Mikesell lesmikesell at gmail.com From seg at haxxed.com Thu May 15 23:03:44 2008 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 15 May 2008 18:03:44 -0500 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <482CA5D9.6060603@gmail.com> References: <482B4F5B.6040005@fedoraproject.org> <482B7748.4010709@gmail.com> <482B85D6.3020603@fedoraproject.org> <482B97A2.9080803@gmail.com> <482BB0C8.6050205@gmail.com> <482BB329.7080708@fedoraproject.org> <482BC97A.3010602@gmail.com> <1218b5bc0805151240w581841d7md1598f41065ede90@mail.gmail.com> <482CA5D9.6060603@gmail.com> Message-ID: <1218b5bc0805151603m274cc5e9s873e078cabc03762@mail.gmail.com> On Thu, May 15, 2008 at 4:06 PM, Les Mikesell wrote: > Overlapping repos are fundamentally broken, period. >> > > Then why create overlap? Because moving things into Fedora is a good thing for Fedora. We've had long flamewars in the past about how ATrpms freely replaces >> Fedora packages making an unsupportable mess. >> > > I think ATrpms pre-dates fedora. Freshrpms certainly did. Do you think you > can retroactively trademark the package names or something? > > > Why are we allowing JPackage to pull the > >> same crap? >> >> Fedora must not make any consessions to allowing JPackage to maintain >> overlapping packages in their repos. Because it is brain damaged. Period. >> >> This goes for all external repos, not just JPackage. >> > > Allow? What kind of control do you think you have over other repos that > were providing packages before fedora existed or the earlier versions of > RedHat even had public update repositories? Your choice is to cooperate or > not. The impression I got from the earlier discussions was that you refused > the compromises that would have made consolidating the repositories > acceptable, forked some of the packages from their pre-existing versions and > thus made it next to impossible for users to get the rest of the content > which, for various reasons, you didn't include. Maybe you see this some > other way? Look, I'm not going to waste my time trying to convince you of anything as you've established yourself as quite the Ferrous Cranius: http://redwing.hutman.net/~mreed/warriorshtm/ferouscranus.htm The only reason I reply at all is for the edification of everyone else on the list and anyone googling the archives, to put forth an argument that I feel has not been given the forceful representation it deserves. With that in mind: I am referring specifically to this section of the guidelines exception that is the subject of this very thread: http://fedoraproject.org/wiki/Packaging/JPackagePolicy#head-cc6af1b19379d1c8881c8636dc085e3bb8c6253f This section, and really the entire exception as a whole is a weaselly way of granting JPackage a blessing to duplicate packages available in Fedora without stating it in explicit terms, which appears to have successfully slipped it past us all. This is brain damaged beyond belief. Kill the exception, kill it dead. We never should have allowed it. No, we can't force external repos to do anything. But we can refuse to participate in a process we know is broken and unmaintainable, and explain to external repos as to why this is so. When a package moves to Fedora, external repos should drop the package from their Fedora repos. Anyone concerned with the package's maintanence in Fedora should become a Fedora maintainer, or maintain an amicable relationship with the Fedora mainainer. Yes, external repos often support other distros than Fedora. They can handle that however they like. Its not our problem. We have EPEL. The repo can port the Fedora package to whatever other distros they want. Whatever. Its Not Our Problem. Fedora does not compromise its engineering integrity. (And before I get accused of not participating in the drafting process: I was a lot dumber a year ago.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at redhat.com Thu May 15 23:37:57 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 15 May 2008 19:37:57 -0400 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <482CB401.5040708@gmail.com> References: <1218b5bc0805151240w581841d7md1598f41065ede90@mail.gmail.com> <482CA5D9.6060603@gmail.com> <200805151415.48220.konrad@tylerc.org> <482CAA62.8060808@gmail.com> <1210887531.4259.1.camel@localhost.localdomain> <482CB401.5040708@gmail.com> Message-ID: <1210894677.4060.0.camel@localhost.localdomain> On Thu, 2008-05-15 at 17:06 -0500, Les Mikesell wrote: > The bigger issue for me is that you also can't or won't include > everything that those external repos provide. That shouldn't be a > surprise to anyone and it makes the incompatibilities a big problem. > It's one thing to 'not endorse' anything outside and something very > different to actively break their attempts to provide additional content > for your users which is what forking their upstream packages amounts to, > given the limitations of yum in sorting this stuff out. Once again, Fedora is a self service distribution. It /could/ if it /wanted/ to and the "want" has to come from the community of contributors. You yourself could be one. You choose not to. The blame lies just as much with you as anybody else. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From casimiro.barreto at gmail.com Fri May 16 01:47:27 2008 From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto) Date: Thu, 15 May 2008 22:47:27 -0300 Subject: Anyone else with hard freezes? In-Reply-To: <20080515220101.GA8240@devserv.devel.redhat.com> References: <80d7e4090805081625m111b7955v2c96d864275334b2@mail.gmail.com> <2a28d2ab0805081723q6a3537d7n93db59501cf23b16@mail.gmail.com> <2a28d2ab0805090336j78fe2772q1df6283e3c5d38cf@mail.gmail.com> <1210398432.17530.0.camel@optimus> <2a28d2ab0805130448s2b3e8c8aw5e526bd04949d60a@mail.gmail.com> <2a28d2ab0805131341x6d4d6332nd89e1252839f3866@mail.gmail.com> <2a28d2ab0805140713h542598d6y5c010885dac62687@mail.gmail.com> <482AF52D.1080509@poolshark.org> <2a28d2ab0805141459j22db5edcmb858afd627ea5d01@mail.gmail.com> <2a28d2ab0805151433m1b323ecak47a256b148cb982f@mail.gmail.com> <20080515220101.GA8240@devserv.devel.redhat.com> Message-ID: <482CE7AF.7050100@gmail.com> Alan Cox escreveu: > On Thu, May 15, 2008 at 05:33:02PM -0400, Dr. Diesel wrote: > >> And more! >> >> ISO 9660 Extensions: Microsoft Joliet Level 3 >> ISO 9660 Extensions: RRIP_1991A >> mtrr: no MTRR for d0000000,ff00000 found >> console-kit-dae[2420]: segfault at 8 ip 3c67e2a699 sp 4100fff0 error 4 >> in libglib-2.0.so.0.1600.3[3c67e00000+de000] >> mtrr: base(0xd0000000) is not aligned on a size(0xff00000) boundary >> > > Out of curiosity what does memtest86 think of the box. A mix of random memory > and disk corruptions is a good candidate for suspecting RAM (although it's > certainly not conclusive and it could be an FC9 triggered bug) > > I installed OK (upgraded over a Fedora Rel 8 using DVD). Kernel XEN boots to the point that the message "Releasing VGA" appears. Then it freezes (a poweroff is necessary because system don't catch keyboard IRQs). System is: ASUS PS800-MX SE with 2 160GBytes SATA, two 80GBytes ATA and a RTL8139 additional network board. RAM is 2GBytes. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fedora-devel at coresfoundation.com Fri May 16 02:47:01 2008 From: fedora-devel at coresfoundation.com (Balaji Ravindran) Date: Thu, 15 May 2008 20:47:01 -0600 Subject: Packagekit - Multiple package installation Message-ID: <9c6d89220805151947x152f6c15of9c589975b16bf92@mail.gmail.com> Hi All., I'm wondering how to select multiple packages for installation in packagekit? Is there a workaround., or any alternate solution? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From rawhide at fedoraproject.org Fri May 16 03:48:51 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Fri, 16 May 2008 03:48:51 +0000 (UTC) Subject: rawhide report: 20080515 changes Message-ID: <20080516034851.B7917209D23@releng1.fedora.phx.redhat.com> From sundaram at fedoraproject.org Fri May 16 04:23:34 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 16 May 2008 09:53:34 +0530 Subject: Packagekit - Multiple package installation In-Reply-To: <9c6d89220805151947x152f6c15of9c589975b16bf92@mail.gmail.com> References: <9c6d89220805151947x152f6c15of9c589975b16bf92@mail.gmail.com> Message-ID: <482D0C46.9050004@fedoraproject.org> Balaji Ravindran wrote: > Hi All., > > I'm wondering how to select multiple packages for installation in > packagekit? Is there a workaround., or any alternate solution? > http://fedoraproject.org/wiki/PackageKitFaq. Alternative solutions would include yum and yumex. Rahul From jeevanullas at gmail.com Fri May 16 04:50:06 2008 From: jeevanullas at gmail.com (Deependra Singh Shekhawat) Date: Fri, 16 May 2008 10:20:06 +0530 Subject: Anyone else with hard freezes? In-Reply-To: <482CE7AF.7050100@gmail.com> References: <80d7e4090805081625m111b7955v2c96d864275334b2@mail.gmail.com> <1210398432.17530.0.camel@optimus> <2a28d2ab0805130448s2b3e8c8aw5e526bd04949d60a@mail.gmail.com> <2a28d2ab0805131341x6d4d6332nd89e1252839f3866@mail.gmail.com> <2a28d2ab0805140713h542598d6y5c010885dac62687@mail.gmail.com> <482AF52D.1080509@poolshark.org> <2a28d2ab0805141459j22db5edcmb858afd627ea5d01@mail.gmail.com> <2a28d2ab0805151433m1b323ecak47a256b148cb982f@mail.gmail.com> <20080515220101.GA8240@devserv.devel.redhat.com> <482CE7AF.7050100@gmail.com> Message-ID: <57127b5f0805152150r3a73f66ayc01eadabccb944ab@mail.gmail.com> I am having the same issue here. Booting the xen kernel just freezes there with that VGA message. 2008/5/16 Casimiro de Almeida Barreto : > Alan Cox escreveu: > > On Thu, May 15, 2008 at 05:33:02PM -0400, Dr. Diesel wrote: > > > And more! > > ISO 9660 Extensions: Microsoft Joliet Level 3 > ISO 9660 Extensions: RRIP_1991A > mtrr: no MTRR for d0000000,ff00000 found > console-kit-dae[2420]: segfault at 8 ip 3c67e2a699 sp 4100fff0 error 4 > in libglib-2.0.so.0.1600.3[3c67e00000+de000] > mtrr: base(0xd0000000) is not aligned on a size(0xff00000) boundary > > > Out of curiosity what does memtest86 think of the box. A mix of random > memory > and disk corruptions is a good candidate for suspecting RAM (although it's > certainly not conclusive and it could be an FC9 triggered bug) > > > > I installed OK (upgraded over a Fedora Rel 8 using DVD). > Kernel XEN boots to the point that the message "Releasing VGA" appears. Then > it freezes (a poweroff is necessary because system don't catch keyboard > IRQs). > > System is: ASUS PS800-MX SE with 2 160GBytes SATA, two 80GBytes ATA and a > RTL8139 additional network board. RAM is 2GBytes. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Enjoy Life ! From kagesenshi.87 at gmail.com Fri May 16 04:52:27 2008 From: kagesenshi.87 at gmail.com (Izhar Firdaus) Date: Fri, 16 May 2008 12:52:27 +0800 Subject: Using LiveUSB-Creator to do Wubi-like installation Message-ID: Looking at the concept of Fedora LiveUSB (disk image on existing disk, overlay image , etc) ... shouldn't this be possible? how well Syslinux support dualboot with windows?? I tried playing around on VM just now, but the lmacken liveusb-creator.exe doesnt allow selecting drive C .. (maybe will hack around later, though i'm still doubting whether i'm capable or not) -- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? http://fedoraproject.org/wiki/MohdIzharFirdaus http://blog.kagesenshi.org 92C2 B295 B40B B3DC 6866 5011 5BD2 584A 8A5D 7331 From trond.danielsen at gmail.com Fri May 16 04:58:42 2008 From: trond.danielsen at gmail.com (Trond Danielsen) Date: Fri, 16 May 2008 06:58:42 +0200 Subject: Packagekit - Multiple package installation In-Reply-To: <482D0C46.9050004@fedoraproject.org> References: <9c6d89220805151947x152f6c15of9c589975b16bf92@mail.gmail.com> <482D0C46.9050004@fedoraproject.org> Message-ID: <409676c70805152158i2bb68902v3226231306e3bfb4@mail.gmail.com> 2008/5/16 Rahul Sundaram : > Balaji Ravindran wrote: >> >> Hi All., >> >> I'm wondering how to select multiple packages for installation in >> packagekit? Is there a workaround., or any alternate solution? >> > > http://fedoraproject.org/wiki/PackageKitFaq. Alternative solutions would > include yum and yumex. I was going to ask a similar question: Is support for "yum groupinstall " , or will it be, implemented in PackageKit? -- Trond Danielsen From sundaram at fedoraproject.org Fri May 16 05:18:50 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 16 May 2008 10:48:50 +0530 Subject: Packagekit - Multiple package installation In-Reply-To: <409676c70805152158i2bb68902v3226231306e3bfb4@mail.gmail.com> References: <9c6d89220805151947x152f6c15of9c589975b16bf92@mail.gmail.com> <482D0C46.9050004@fedoraproject.org> <409676c70805152158i2bb68902v3226231306e3bfb4@mail.gmail.com> Message-ID: <482D193A.304@fedoraproject.org> Trond Danielsen wrote: > 2008/5/16 Rahul Sundaram : >> Balaji Ravindran wrote: >>> Hi All., >>> >>> I'm wondering how to select multiple packages for installation in >>> packagekit? Is there a workaround., or any alternate solution? >>> >> http://fedoraproject.org/wiki/PackageKitFaq. Alternative solutions would >> include yum and yumex. > > I was going to ask a similar question: Is support for "yum > groupinstall " , or will it be, implemented in PackageKit? Answered in the same FAQ. Rahul From balajig81 at gmail.com Fri May 16 05:30:45 2008 From: balajig81 at gmail.com (G) Date: Fri, 16 May 2008 11:00:45 +0530 Subject: My introduction & Idea Storm for F10 In-Reply-To: <604aa7910805150952q139c7ac8s9a4aa226ad266f68@mail.gmail.com> References: <6dd1343e0805150056x56dacdaalb54b67f10edcc939@mail.gmail.com> <482BF854.607@redhat.com> <6dd1343e0805150206t797e0ffag321f76665ea7d05a@mail.gmail.com> <482C0038.2070500@fedoraproject.org> <604aa7910805150952q139c7ac8s9a4aa226ad266f68@mail.gmail.com> Message-ID: <6dd1343e0805152230l209fcdan7e4464a45b110991@mail.gmail.com> Hi Jef Thank you so much for your detailed explanation for my question and it did answer my question on why not Idea Storm for F10 ?. Thank you once again for your time :) Cheers, Balaji On 5/15/08, Jeff Spaleta wrote: > On Thu, May 15, 2008 at 1:19 AM, Rahul Sundaram > wrote: > > The feature list gets filled by following the policy outlined in > > > > http://fedoraproject.org/wiki/Features/Policy > > > > This is based not just on popularity but someone or a team actually willing > > to work on any particular feature. > > > > And let me stress that the importance of doing it this way. Unlike > Dell, the bulk of the work done directly as part of this project is > volunteer. Having a long list of wishlist or popularity list of > potential features is a recipe for disaster unless there are people > who are committed to doing any of the work. An Idea Storm sort of > thing is only going to be valuable if people are prepared to actually > use it as a way to decide what they are going to work on. > > And as a Board member, I can't just point at people and tell them to > work on something that other people want. I have a hard enough time > convincing people to do what I want, and I was voted in based on > 'popular' support. Popular opinion doesn't translate directly into > interest in working towards getting it done. We simply do not have > the resources to direct people to work on things they aren't > interested in working on. It just doesn't work that way at the larger > Fedora project-wide level. The Feature process is there to make sure > that we are doing what we can as a Project to adequately track and > support people who have made a commitment to do the hard work of > making something new happen. > > Now that isn't to say that some groups of contributors or even > particular individuals wouldn't be interested in working on something > based on popularity. I would not be one of those people, but they > could very well exist. As a starting point for any serious discussion > on how to do something like an Idea Storm, I would need to see a group > of contributors commited to the ideal behind the concept. If you > want to see an Idea Storm attempted, first find the group of > developers/maintainers/contributors with a broad enough skillset to be > an effective development team. Have those people affirm publicly that > they will make the commitment to try to use an Idea Storm like list to > direct the work that they do. We can then have a real discussion > about how to position and run an Idea Storm. Once we settle on that, > the team can run an Idea Storm, cull a concept, make a plan and then > put an item on the Proposed Feature List for the next release like any > other development group could. > > But you know what, I haven't seen skilled contributors asking to run > this sort of thing anytime someone asks about it. I think there's more > than enough work to go around as it stands. People aren't just > standing around idle waiting for something to work on. I don't think > this Project's problem is finding more work to do. I think the problem > is finding more people to do more work. An Idea Storm will not help > that. > > Failing the creation of such a development team to serve the whims of > the populace, these sort of activities should be done inside the scope > of an appropriate SIG who is receptive to making use of this sort of > information. If a particular SIG wants to makes a commitment to > organize its available resources around a popularity poll...it's up to > them. > > The key idea here is there really needs to be a group of contributors > willing to make use of a poll in a meaningful way, before we bother > constructing this sort of poll. Having a long list of things languish > and see no love..is a PR lose. If we are going to do it, then people > must step forward and commit to using it before me generate the list. > > -jef > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From denis at poolshark.org Fri May 16 05:49:49 2008 From: denis at poolshark.org (Denis Leroy) Date: Fri, 16 May 2008 07:49:49 +0200 Subject: rawhide bugs becoming F-9 bugs In-Reply-To: <20080515133526.GA29284@angus.ind.WPI.EDU> References: <20080514220114.GA2498@free.fr> <20080514235536.GB10077@free.fr> <482BAFF3.8070807@gmail.com> <20080515090226.GB2656@free.fr> <482C0C52.1060408@gmail.com> <20080515133526.GA29284@angus.ind.WPI.EDU> Message-ID: <482D207D.4000904@poolshark.org> Chuck Anderson wrote: > On Thu, May 15, 2008 at 03:11:30AM -0700, Andrew Farris wrote: >> So the question is, if not NOW at release, then when should those open bugs >> be changed to a release version? How much harder would it be to do later >> than it is now? > > If you are going to change rawhide bugs to Fx bugs at Fx release time, > why even have rawhide as a bugzilla version at all? Why not report > bugs in what will become F10 under version F10 now? You can tell from > the reported date that it was during the development cycle of F10. > > If people can't be bothered to update a bug once every 6 months if it > still applies to the latest version, then it should be closed WONTFIX. > Leaving it as "rawhide" forever does no one any good. > > So I propose to get rid of "rawhide" as a Bugzilla version, and create > the F10 version NOW, and likewise, create Fx Bugzilla versions at the > time Fx is branched in CVS. +1 From ml at deadbabylon.de Fri May 16 06:15:27 2008 From: ml at deadbabylon.de (Sebastian Vahl) Date: Fri, 16 May 2008 08:15:27 +0200 Subject: KDE-SIG weekly report (20/2008) Message-ID: <200805160815.34079.ml@deadbabylon.de> This is a report of the weekly KDE-SIG-Meeting with a summary of the topics that were discussed. If you want to add a comment please reply ?to this email or add it to the related meeting page. ---------------------------------------------------------------------------------- = Weekly KDE Summary = Week: 20/2008 Time: 2008-05-13 16:00 UTC Meeting page: http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-05-13 Meeting log: http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-05-13?action=AttachFile&do=get&target=fedora-kde-sig-2008-05-13.txt ---------------------------------------------------------------------------------- = Participants = GeraldCox KevinKofler LukasTinkl MarieEllenFoster RexDieter SebastianVahl ShawnStarr ThanNgo ---------------------------------------------------------------------------------- = Agenda = - Celebrating the release of Fedora 9 :) - Dropping Phonon "ALSA default device" hack? [1] - _qt4_bindir (reverted for now due to - Status of kpackagekit - iclock applet (International Clock applet for Qt4/KDE4) - comments, opinions, inclusion into F10 - Recapitulate the way to F9 and initial release planning for F10 = Summary = '''Celebrating the release:''' * Fedora's KDE4 got mentioned in a Distrowatch Feature. [2] * There were some reports that spell-checking in kate is broken. '''dropping Phonon "ALSA default device" hack?''': * In the past we used a hack [3] to force Phonon to use Alsa by default if native PulseAudio support was broken. * Since xine-lib-pulseaudio is more reliable the hack will be dropped. '''qt4 bindir''': * the use of %{_bindir} as %{_qt4_bindir} was reverted because it causes/fixes some bugs: #446167 and #422291. * Instead of this the following solution will be used: * keep %{_qt4_bindir} and %{_bindir} separate. * move the executables to %{_bindir}. * keep %{_qt4_bindir} as a directory and use symlinks from there to %{_bindir} (or wrapper scripts if that works better). * This allows us to keep only qmake-qt4 in %{_bindir} and both qmake and qmake-qt4 in %{_qt4_bindir} for F8 and possibly F9, and only have a %{_bindir}/qmake in qt 4 in F10+. '''status of kpackagekit''': * RichardHughes mentioned a KDE frontend for PackageKit in his blog. [4] * LukasTinkl will have a closer look at kpackagekit. '''iclock applet (International Clock applet for Qt4/KDE4)''': * LukasTinkl created a clock applet fot Qt4/KDE4 and asked for feedback. [5] * He will also submit a package for review to include this in F10. '''Planning for F10''': * KDE's core components in Rawhide are now at 4.0.72 (4.1 alpha1 + 1 week). * kdepim needs work. * libopensync-plugin-kdepim needs to be upgraded to a development snapshot. * basket also needs to be upgraded to a KDE4 based snapshot (or basket support in kdepim needs to be disabled). * kdevelop: needs kdevplatform packaged and reviewed. * kde-l10n: kdepim and kdevelop will be handled first before the translations from kde-i18n will be switched to kde-l10n. * kdewebdev will stay at kde-3.5 because Quanta won't be ready for KDE 4.1. * RexDieter started to work on koffice-2. ---------------------------------------------------------------------------------- = Next Meeting = http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-05-20 ---------------------------------------------------------------------------------- = Links = [1] https://www.redhat.com/archives/fedora-list/2008-May/msg00826.html [2] http://distrowatch.com/weekly.php?issue=20080512#feature [3] http://cvs.fedoraproject.org/viewcvs/rpms/kdelibs/F-9/kdelibs-3.97.0-alsa-default-device.patch?rev=1.1&view=markup [4] http://blogs.gnome.org/hughsie/2008/05/02/kde-love/ [5] http://ktown.kde.org/~lukas/iclock/ = Buglist = https://bugzilla.redhat.com/show_bug.cgi?id=446167 https://bugzilla.redhat.com/show_bug.cgi?id=422291 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From pekkas at netcore.fi Fri May 16 06:59:33 2008 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 16 May 2008 09:59:33 +0300 (EEST) Subject: F8->F9 yum upgrade notes: bluecurve lost etc. In-Reply-To: References: Message-ID: On Wed, 14 May 2008, Pekka Savola wrote: > - At one time, the keyboard responsiveness in X windows disappeared. Each > keystroke produced a beep. When you switched to console with CTRL-ALT-F1, > you would get constant beeping but the keyboard would work until you switched > back. Mouse worked fine; both are USB. I'll see if this problem appears > again. This happened again, I guess this happens every 1-2 days. This time CTRL-ALT-F1 didn't work either but CTRL-ALT-BACKSPACE did. Which packages should this be filed against or is this a known problem already? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From pertusus at free.fr Fri May 16 07:41:46 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 16 May 2008 09:41:46 +0200 Subject: SWFdec vs Gnash (also gcjwebplugin) In-Reply-To: <20080515155851.GB11874@nostromo.devel.redhat.com> References: <1210804636.27281.5.camel@trinity.blade> <20080515040125.GA26819@nostromo.devel.redhat.com> <20080515092203.GD2656@free.fr> <20080515145202.GB8944@nostromo.devel.redhat.com> <20080515151727.GJ2656@free.fr> <20080515153346.GA11874@nostromo.devel.redhat.com> <20080515155130.GK2656@free.fr> <20080515155851.GB11874@nostromo.devel.redhat.com> Message-ID: <20080516074146.GC2603@free.fr> On Thu, May 15, 2008 at 11:58:51AM -0400, Bill Nottingham wrote: > > would probably make a good start. In fact it is already implemented and should be in the next release, due soon. -- Pat From rjones at redhat.com Fri May 16 07:46:00 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 16 May 2008 08:46:00 +0100 Subject: Review swapsies In-Reply-To: <482C5016.6000901@hhs.nl> References: <482C5016.6000901@hhs.nl> Message-ID: <20080516074600.GA3092@amd.home.annexia.org> On Thu, May 15, 2008 at 05:00:38PM +0200, Hans de Goede wrote: > coda - Coda distributed file system - > https://bugzilla.redhat.com/show_bug.cgi?id=446653 I'll take a look at this one. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From rawhide at fedoraproject.org Fri May 16 10:19:42 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Fri, 16 May 2008 10:19:42 +0000 (UTC) Subject: rawhide report: 20080516 changes Message-ID: <20080516101942.B055A209D22@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080515/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080516/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package libcapseo A realtime encoder/decoder library Updated Packages: Broken deps for i386 ---------------------------------------------------------- LabPlot-1.5.1.6-4.fc8.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libMagick.so.10 autotrace-0.31.1-16.fc9.i386 requires libWand.so.10 autotrace-0.31.1-16.fc9.i386 requires libMagick.so.10 brasero-0.7.1-3.fc9.i386 requires libtotem-plparser.so.10 drawtiming-0.6.2-3.fc9.i386 requires libMagick++.so.10 drawtiming-0.6.2-3.fc9.i386 requires libWand.so.10 drawtiming-0.6.2-3.fc9.i386 requires libMagick.so.10 dx-4.4.4-6.fc9.i386 requires libWand.so.10 dx-4.4.4-6.fc9.i386 requires libMagick.so.10 dx-libs-4.4.4-6.fc9.i386 requires libWand.so.10 dx-libs-4.4.4-6.fc9.i386 requires libMagick.so.10 empathy-0.23.1-2.fc10.i386 requires libedataserver-1.2.so.9 empathy-libs-0.23.1-2.fc10.i386 requires libedataserver-1.2.so.9 evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-python-0.0.4-3.fc9.i386 requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.i386 requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-1.2.so.11 gdl-0.9-0.rc1.1.fc9.i386 requires libMagick++.so.10 gnome-python2-evolution-2.22.0-2.fc9.i386 requires libedataserver-1.2.so.9 gnome-python2-totem-2.22.0-2.fc9.i386 requires libtotem-plparser.so.10 k3d-0.6.7.0-6.fc9.i386 requires libMagick++.so.10 k3d-0.6.7.0-6.fc9.i386 requires libMagick.so.10 k3d-0.6.7.0-6.fc9.i386 requires libWand.so.10 kismet-extras-0.0.2007.10.R1-3.fc9.i386 requires libMagick.so.10 koffice-karbon-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-karbon-1.6.3-15.fc9.i386 requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libMagick.so.10 libfprint-0.0.5-3.fc9.i386 requires libWand.so.10 libfprint-0.0.5-3.fc9.i386 requires libMagick.so.10 nip2-7.14.1-1.fc9.i386 requires libWand.so.10 nip2-7.14.1-1.fc9.i386 requires libMagick.so.10 obconf-2.0.3-1.fc9.i386 requires libobparser.so.16 obconf-2.0.3-1.fc9.i386 requires libobrender.so.16 1:openoffice.org-presentation-minimizer-3.0.0-0.0.12.1.fc10.i386 requires openoffice.org-base-impress = 1:3.0.0-0.0.12.1.fc10 1:openoffice.org-presenter-screen-3.0.0-0.0.12.1.fc10.i386 requires openoffice.org-base-impress = 1:3.0.0-0.0.12.1.fc10 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) php-magickwand-1.0.7-1.fc10.i386 requires libWand.so.10 php-magickwand-1.0.7-1.fc10.i386 requires libMagick.so.10 poker3d-1.1.36-9.fc9.i386 requires libosgTerrain.so.25 poker3d-1.1.36-9.fc9.i386 requires libosgViewer.so.25 poker3d-1.1.36-9.fc9.i386 requires libosgDB.so.25 poker3d-1.1.36-9.fc9.i386 requires libOpenThreads.so.9 poker3d-1.1.36-9.fc9.i386 requires libosgGA.so.25 poker3d-1.1.36-9.fc9.i386 requires libosg.so.25 poker3d-1.1.36-9.fc9.i386 requires libosgText.so.25 poker3d-1.1.36-9.fc9.i386 requires libosgFX.so.25 poker3d-1.1.36-9.fc9.i386 requires libosgSim.so.25 poker3d-1.1.36-9.fc9.i386 requires libosgParticle.so.25 poker3d-1.1.36-9.fc9.i386 requires libosgManipulator.so.25 poker3d-1.1.36-9.fc9.i386 requires libosgUtil.so.25 psiconv-0.9.8-1.fc8.i386 requires libWand.so.10 psiconv-0.9.8-1.fc8.i386 requires libMagick.so.10 q-7.10-3.fc9.i386 requires libMagick.so.10 qgis-0.9.1-5.fc9.i386 requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.i386 requires libgeos.so.2 rhythmbox-0.11.5-9.fc9.i386 requires libtotem-plparser.so.10 sunbird-0.8-3.fc9.i386 requires libhunspell.so.1 thunderbird-lightning-0.8-3.fc9.i386 requires libhunspell.so.1 torcs-1.3.0-6.fc9.i386 requires libplibssgaux.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibssg.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibsl.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibsm.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibsg.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibul.so.1.8.4 totem-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 totem-mozplugin-2.23.2-2.fc9.i386 requires libtotem-plparser-mini.so.10 totem-mozplugin-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 totem-nautilus-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 vips-7.14.1-1.fc9.i386 requires libWand.so.10 vips-7.14.1-1.fc9.i386 requires libMagick.so.10 vips-python-7.14.1-1.fc9.i386 requires libWand.so.10 vips-python-7.14.1-1.fc9.i386 requires libMagick.so.10 vips-tools-7.14.1-1.fc9.i386 requires libWand.so.10 vips-tools-7.14.1-1.fc9.i386 requires libMagick.so.10 xulrunner-1.9-0.60.cvs20080414.fc10.i386 requires libhunspell.so.1 Broken deps for x86_64 ---------------------------------------------------------- LabPlot-1.5.1.6-4.fc8.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libMagick.so.10 LabPlot-1.5.1.6-4.fc8.x86_64 requires libMagick++.so.10()(64bit) LabPlot-1.5.1.6-4.fc8.x86_64 requires libMagick.so.10()(64bit) LabPlot-1.5.1.6-4.fc8.x86_64 requires libWand.so.10()(64bit) autotrace-0.31.1-16.fc9.i386 requires libWand.so.10 autotrace-0.31.1-16.fc9.i386 requires libMagick.so.10 autotrace-0.31.1-16.fc9.x86_64 requires libWand.so.10()(64bit) autotrace-0.31.1-16.fc9.x86_64 requires libMagick.so.10()(64bit) brasero-0.7.1-3.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) drawtiming-0.6.2-3.fc9.x86_64 requires libWand.so.10()(64bit) drawtiming-0.6.2-3.fc9.x86_64 requires libMagick++.so.10()(64bit) drawtiming-0.6.2-3.fc9.x86_64 requires libMagick.so.10()(64bit) dx-4.4.4-6.fc9.x86_64 requires libMagick.so.10()(64bit) dx-4.4.4-6.fc9.x86_64 requires libWand.so.10()(64bit) dx-libs-4.4.4-6.fc9.i386 requires libWand.so.10 dx-libs-4.4.4-6.fc9.i386 requires libMagick.so.10 dx-libs-4.4.4-6.fc9.x86_64 requires libMagick.so.10()(64bit) dx-libs-4.4.4-6.fc9.x86_64 requires libWand.so.10()(64bit) empathy-0.23.1-2.fc10.x86_64 requires libedataserver-1.2.so.9()(64bit) empathy-libs-0.23.1-2.fc10.i386 requires libedataserver-1.2.so.9 empathy-libs-0.23.1-2.fc10.x86_64 requires libedataserver-1.2.so.9()(64bit) evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libWand.so.10()(64bit) evolution-python-0.0.4-3.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx gdl-0.9-0.rc1.1.fc9.x86_64 requires libMagick++.so.10()(64bit) gnome-python2-evolution-2.22.0-2.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) gnome-python2-totem-2.22.0-2.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) k3d-0.6.7.0-6.fc9.i386 requires libMagick++.so.10 k3d-0.6.7.0-6.fc9.i386 requires libMagick.so.10 k3d-0.6.7.0-6.fc9.i386 requires libWand.so.10 k3d-0.6.7.0-6.fc9.x86_64 requires libMagick.so.10()(64bit) k3d-0.6.7.0-6.fc9.x86_64 requires libWand.so.10()(64bit) k3d-0.6.7.0-6.fc9.x86_64 requires libMagick++.so.10()(64bit) kismet-extras-0.0.2007.10.R1-3.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.x86_64 requires libWand.so.10()(64bit) koffice-libs-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.x86_64 requires libWand.so.10()(64bit) libfprint-0.0.5-3.fc9.i386 requires libWand.so.10 libfprint-0.0.5-3.fc9.i386 requires libMagick.so.10 libfprint-0.0.5-3.fc9.x86_64 requires libWand.so.10()(64bit) libfprint-0.0.5-3.fc9.x86_64 requires libMagick.so.10()(64bit) nip2-7.14.1-1.fc9.x86_64 requires libMagick.so.10()(64bit) nip2-7.14.1-1.fc9.x86_64 requires libWand.so.10()(64bit) obconf-2.0.3-1.fc9.x86_64 requires libobparser.so.16()(64bit) obconf-2.0.3-1.fc9.x86_64 requires libobrender.so.16()(64bit) 1:openoffice.org-presentation-minimizer-3.0.0-0.0.12.1.fc10.x86_64 requires openoffice.org-base-impress = 1:3.0.0-0.0.12.1.fc10 1:openoffice.org-presenter-screen-3.0.0-0.0.12.1.fc10.x86_64 requires openoffice.org-base-impress = 1:3.0.0-0.0.12.1.fc10 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) php-magickwand-1.0.7-1.fc10.x86_64 requires libWand.so.10()(64bit) php-magickwand-1.0.7-1.fc10.x86_64 requires libMagick.so.10()(64bit) poker3d-1.1.36-9.fc9.x86_64 requires libosgGA.so.25()(64bit) poker3d-1.1.36-9.fc9.x86_64 requires libosgFX.so.25()(64bit) poker3d-1.1.36-9.fc9.x86_64 requires libosgUtil.so.25()(64bit) poker3d-1.1.36-9.fc9.x86_64 requires libOpenThreads.so.9()(64bit) poker3d-1.1.36-9.fc9.x86_64 requires libosgParticle.so.25()(64bit) poker3d-1.1.36-9.fc9.x86_64 requires libosgText.so.25()(64bit) poker3d-1.1.36-9.fc9.x86_64 requires libosgSim.so.25()(64bit) poker3d-1.1.36-9.fc9.x86_64 requires libosgManipulator.so.25()(64bit) poker3d-1.1.36-9.fc9.x86_64 requires libosg.so.25()(64bit) poker3d-1.1.36-9.fc9.x86_64 requires libosgTerrain.so.25()(64bit) poker3d-1.1.36-9.fc9.x86_64 requires libosgDB.so.25()(64bit) poker3d-1.1.36-9.fc9.x86_64 requires libosgViewer.so.25()(64bit) psiconv-0.9.8-1.fc8.i386 requires libWand.so.10 psiconv-0.9.8-1.fc8.i386 requires libMagick.so.10 psiconv-0.9.8-1.fc8.x86_64 requires libWand.so.10()(64bit) psiconv-0.9.8-1.fc8.x86_64 requires libMagick.so.10()(64bit) q-7.10-3.fc9.i386 requires libMagick.so.10 qgis-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) rhythmbox-0.11.5-9.fc9.i386 requires libtotem-plparser.so.10 rhythmbox-0.11.5-9.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) sunbird-0.8-3.fc9.x86_64 requires libhunspell.so.1()(64bit) thunderbird-lightning-0.8-3.fc9.x86_64 requires libhunspell.so.1()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibsg.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibul.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibssgaux.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibsm.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibssg.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibsl.so.1.8.4()(64bit) totem-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 totem-2.23.2-2.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.x86_64 requires libtotem-plparser-mini.so.10()(64bit) totem-nautilus-2.23.2-2.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) vips-7.14.1-1.fc9.i386 requires libWand.so.10 vips-7.14.1-1.fc9.i386 requires libMagick.so.10 vips-7.14.1-1.fc9.x86_64 requires libMagick.so.10()(64bit) vips-7.14.1-1.fc9.x86_64 requires libWand.so.10()(64bit) vips-python-7.14.1-1.fc9.x86_64 requires libMagick.so.10()(64bit) vips-python-7.14.1-1.fc9.x86_64 requires libWand.so.10()(64bit) vips-tools-7.14.1-1.fc9.x86_64 requires libMagick.so.10()(64bit) vips-tools-7.14.1-1.fc9.x86_64 requires libWand.so.10()(64bit) xulrunner-1.9-0.60.cvs20080414.fc10.i386 requires libhunspell.so.1 xulrunner-1.9-0.60.cvs20080414.fc10.x86_64 requires libhunspell.so.1()(64bit) Broken deps for ppc ---------------------------------------------------------- LabPlot-1.5.1.6-4.fc8.ppc requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.ppc requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.ppc requires libMagick.so.10 autotrace-0.31.1-16.fc9.ppc requires libWand.so.10 autotrace-0.31.1-16.fc9.ppc requires libMagick.so.10 autotrace-0.31.1-16.fc9.ppc64 requires libWand.so.10()(64bit) autotrace-0.31.1-16.fc9.ppc64 requires libMagick.so.10()(64bit) brasero-0.7.1-3.fc9.ppc requires libtotem-plparser.so.10 drawtiming-0.6.2-3.fc9.ppc requires libMagick++.so.10 drawtiming-0.6.2-3.fc9.ppc requires libWand.so.10 drawtiming-0.6.2-3.fc9.ppc requires libMagick.so.10 dx-4.4.4-6.fc9.ppc requires libWand.so.10 dx-4.4.4-6.fc9.ppc requires libMagick.so.10 dx-libs-4.4.4-6.fc9.ppc requires libWand.so.10 dx-libs-4.4.4-6.fc9.ppc requires libMagick.so.10 dx-libs-4.4.4-6.fc9.ppc64 requires libMagick.so.10()(64bit) dx-libs-4.4.4-6.fc9.ppc64 requires libWand.so.10()(64bit) empathy-0.23.1-2.fc10.ppc requires libedataserver-1.2.so.9 empathy-libs-0.23.1-2.fc10.ppc requires libedataserver-1.2.so.9 empathy-libs-0.23.1-2.fc10.ppc64 requires libedataserver-1.2.so.9()(64bit) evolution-brutus-1.2.11-2.fc9.ppc requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.ppc requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.ppc requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-python-0.0.4-3.fc9.ppc requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.ppc requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-1.2.so.11 gdl-0.9-0.rc1.1.fc9.ppc requires libMagick++.so.10 gnome-python2-evolution-2.22.0-2.fc9.ppc requires libedataserver-1.2.so.9 gnome-python2-totem-2.22.0-2.fc9.ppc requires libtotem-plparser.so.10 k3d-0.6.7.0-6.fc9.ppc requires libMagick++.so.10 k3d-0.6.7.0-6.fc9.ppc requires libMagick.so.10 k3d-0.6.7.0-6.fc9.ppc requires libWand.so.10 k3d-0.6.7.0-6.fc9.ppc64 requires libMagick.so.10()(64bit) k3d-0.6.7.0-6.fc9.ppc64 requires libWand.so.10()(64bit) k3d-0.6.7.0-6.fc9.ppc64 requires libMagick++.so.10()(64bit) kismet-extras-0.0.2007.10.R1-3.fc9.ppc requires libMagick.so.10 koffice-karbon-1.6.3-15.fc9.ppc requires libWand.so.10 koffice-karbon-1.6.3-15.fc9.ppc requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.ppc requires libWand.so.10 koffice-libs-1.6.3-15.fc9.ppc requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) libfprint-0.0.5-3.fc9.ppc requires libWand.so.10 libfprint-0.0.5-3.fc9.ppc requires libMagick.so.10 libfprint-0.0.5-3.fc9.ppc64 requires libWand.so.10()(64bit) libfprint-0.0.5-3.fc9.ppc64 requires libMagick.so.10()(64bit) nip2-7.14.1-1.fc9.ppc requires libWand.so.10 nip2-7.14.1-1.fc9.ppc requires libMagick.so.10 obconf-2.0.3-1.fc9.ppc requires libobparser.so.16 obconf-2.0.3-1.fc9.ppc requires libobrender.so.16 1:openoffice.org-presentation-minimizer-3.0.0-0.0.12.1.fc10.ppc requires openoffice.org-base-impress = 1:3.0.0-0.0.12.1.fc10 1:openoffice.org-presenter-screen-3.0.0-0.0.12.1.fc10.ppc requires openoffice.org-base-impress = 1:3.0.0-0.0.12.1.fc10 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) php-magickwand-1.0.7-1.fc10.ppc requires libWand.so.10 php-magickwand-1.0.7-1.fc10.ppc requires libMagick.so.10 poker3d-1.1.36-9.fc9.ppc requires libosgTerrain.so.25 poker3d-1.1.36-9.fc9.ppc requires libosgViewer.so.25 poker3d-1.1.36-9.fc9.ppc requires libosgDB.so.25 poker3d-1.1.36-9.fc9.ppc requires libOpenThreads.so.9 poker3d-1.1.36-9.fc9.ppc requires libosgGA.so.25 poker3d-1.1.36-9.fc9.ppc requires libosg.so.25 poker3d-1.1.36-9.fc9.ppc requires libosgText.so.25 poker3d-1.1.36-9.fc9.ppc requires libosgFX.so.25 poker3d-1.1.36-9.fc9.ppc requires libosgSim.so.25 poker3d-1.1.36-9.fc9.ppc requires libosgParticle.so.25 poker3d-1.1.36-9.fc9.ppc requires libosgManipulator.so.25 poker3d-1.1.36-9.fc9.ppc requires libosgUtil.so.25 psiconv-0.9.8-1.fc8.ppc requires libWand.so.10 psiconv-0.9.8-1.fc8.ppc requires libMagick.so.10 psiconv-0.9.8-1.fc8.ppc64 requires libWand.so.10()(64bit) psiconv-0.9.8-1.fc8.ppc64 requires libMagick.so.10()(64bit) q-7.10-3.fc9.ppc requires libMagick.so.10 q-7.10-3.fc9.ppc64 requires libMagick.so.10()(64bit) qgis-0.9.1-5.fc9.ppc requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.ppc requires libgeos.so.2 rhythmbox-0.11.5-9.fc9.ppc requires libtotem-plparser.so.10 rhythmbox-0.11.5-9.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) sunbird-0.8-3.fc9.ppc requires libhunspell.so.1 thunderbird-lightning-0.8-3.fc9.ppc requires libhunspell.so.1 torcs-1.3.0-6.fc9.ppc requires libplibssgaux.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibssg.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibsl.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibsm.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibsg.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibul.so.1.8.4 totem-2.23.2-2.fc9.ppc requires libtotem-plparser.so.10 totem-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.ppc requires libtotem-plparser-mini.so.10 totem-mozplugin-2.23.2-2.fc9.ppc requires libtotem-plparser.so.10 totem-nautilus-2.23.2-2.fc9.ppc requires libtotem-plparser.so.10 vips-7.14.1-1.fc9.ppc requires libWand.so.10 vips-7.14.1-1.fc9.ppc requires libMagick.so.10 vips-7.14.1-1.fc9.ppc64 requires libMagick.so.10()(64bit) vips-7.14.1-1.fc9.ppc64 requires libWand.so.10()(64bit) vips-python-7.14.1-1.fc9.ppc requires libWand.so.10 vips-python-7.14.1-1.fc9.ppc requires libMagick.so.10 vips-tools-7.14.1-1.fc9.ppc requires libWand.so.10 vips-tools-7.14.1-1.fc9.ppc requires libMagick.so.10 xulrunner-1.9-0.60.cvs20080414.fc10.ppc requires libhunspell.so.1 xulrunner-1.9-0.60.cvs20080414.fc10.ppc64 requires libhunspell.so.1()(64bit) Broken deps for ppc64 ---------------------------------------------------------- autotrace-0.31.1-16.fc9.ppc64 requires libWand.so.10()(64bit) autotrace-0.31.1-16.fc9.ppc64 requires libMagick.so.10()(64bit) brasero-0.7.1-3.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) drawtiming-0.6.2-3.fc9.ppc64 requires libWand.so.10()(64bit) drawtiming-0.6.2-3.fc9.ppc64 requires libMagick++.so.10()(64bit) drawtiming-0.6.2-3.fc9.ppc64 requires libMagick.so.10()(64bit) dx-4.4.4-6.fc9.ppc64 requires libMagick.so.10()(64bit) dx-4.4.4-6.fc9.ppc64 requires libWand.so.10()(64bit) dx-libs-4.4.4-6.fc9.ppc64 requires libMagick.so.10()(64bit) dx-libs-4.4.4-6.fc9.ppc64 requires libWand.so.10()(64bit) empathy-0.23.1-2.fc10.ppc64 requires libedataserver-1.2.so.9()(64bit) empathy-libs-0.23.1-2.fc10.ppc64 requires libedataserver-1.2.so.9()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-python-0.0.4-3.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) gdl-0.9-0.rc1.1.fc9.ppc64 requires libMagick++.so.10()(64bit) gnome-python2-evolution-2.22.0-2.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) gnome-python2-totem-2.22.0-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) k3d-0.6.7.0-6.fc9.ppc64 requires libMagick.so.10()(64bit) k3d-0.6.7.0-6.fc9.ppc64 requires libWand.so.10()(64bit) k3d-0.6.7.0-6.fc9.ppc64 requires libMagick++.so.10()(64bit) kismet-extras-0.0.2007.10.R1-3.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) libfprint-0.0.5-3.fc9.ppc64 requires libWand.so.10()(64bit) libfprint-0.0.5-3.fc9.ppc64 requires libMagick.so.10()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot nip2-7.14.1-1.fc9.ppc64 requires libMagick.so.10()(64bit) nip2-7.14.1-1.fc9.ppc64 requires libWand.so.10()(64bit) obconf-2.0.3-1.fc9.ppc64 requires libobparser.so.16()(64bit) obconf-2.0.3-1.fc9.ppc64 requires libobrender.so.16()(64bit) 1:openoffice.org-presentation-minimizer-3.0.0-0.0.12.1.fc10.ppc64 requires openoffice.org-base-impress = 1:3.0.0-0.0.12.1.fc10 1:openoffice.org-presenter-screen-3.0.0-0.0.12.1.fc10.ppc64 requires openoffice.org-base-impress = 1:3.0.0-0.0.12.1.fc10 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 php-magickwand-1.0.7-1.fc10.ppc64 requires libWand.so.10()(64bit) php-magickwand-1.0.7-1.fc10.ppc64 requires libMagick.so.10()(64bit) poker3d-1.1.36-9.fc9.ppc64 requires libosgGA.so.25()(64bit) poker3d-1.1.36-9.fc9.ppc64 requires libosgFX.so.25()(64bit) poker3d-1.1.36-9.fc9.ppc64 requires libosgUtil.so.25()(64bit) poker3d-1.1.36-9.fc9.ppc64 requires libOpenThreads.so.9()(64bit) poker3d-1.1.36-9.fc9.ppc64 requires libosgParticle.so.25()(64bit) poker3d-1.1.36-9.fc9.ppc64 requires libosgText.so.25()(64bit) poker3d-1.1.36-9.fc9.ppc64 requires libosgSim.so.25()(64bit) poker3d-1.1.36-9.fc9.ppc64 requires libosgManipulator.so.25()(64bit) poker3d-1.1.36-9.fc9.ppc64 requires libosg.so.25()(64bit) poker3d-1.1.36-9.fc9.ppc64 requires libosgTerrain.so.25()(64bit) poker3d-1.1.36-9.fc9.ppc64 requires libosgDB.so.25()(64bit) poker3d-1.1.36-9.fc9.ppc64 requires libosgViewer.so.25()(64bit) ppc64-utils-0.14-2.fc9.ppc64 requires yaboot psiconv-0.9.8-1.fc8.ppc64 requires libWand.so.10()(64bit) psiconv-0.9.8-1.fc8.ppc64 requires libMagick.so.10()(64bit) q-7.10-3.fc9.ppc64 requires libMagick.so.10()(64bit) qgis-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) rhythmbox-0.11.5-9.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) sunbird-0.8-3.fc9.ppc64 requires libhunspell.so.1()(64bit) thunderbird-lightning-0.8-3.fc9.ppc64 requires libhunspell.so.1()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibsg.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibul.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibsm.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibssgaux.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibssg.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibsl.so.1.8.4()(64bit) totem-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.ppc64 requires libtotem-plparser-mini.so.10()(64bit) totem-nautilus-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) vips-7.14.1-1.fc9.ppc64 requires libMagick.so.10()(64bit) vips-7.14.1-1.fc9.ppc64 requires libWand.so.10()(64bit) vips-python-7.14.1-1.fc9.ppc64 requires libMagick.so.10()(64bit) vips-python-7.14.1-1.fc9.ppc64 requires libWand.so.10()(64bit) vips-tools-7.14.1-1.fc9.ppc64 requires libMagick.so.10()(64bit) vips-tools-7.14.1-1.fc9.ppc64 requires libWand.so.10()(64bit) xulrunner-1.9-0.60.cvs20080414.fc10.ppc64 requires libhunspell.so.1()(64bit) From paul at all-the-johnsons.co.uk Fri May 16 11:00:50 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Fri, 16 May 2008 12:00:50 +0100 Subject: Ooo3 - warning (X86_64 users) Message-ID: <1210935650.5843.1.camel@T7.Linux> Hi, I've reported this into BZ as it's a real show stopper. I've no idea on x86 platforms, but on the x86_64 platform, OOo3 will just continually die. Loading files kills it, recover and it will die. Can anyone else reproduce this? TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From rawhide at fedoraproject.org Fri May 16 11:27:43 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Fri, 16 May 2008 11:27:43 +0000 (UTC) Subject: rawhide report: 20080516 changes (resend) Message-ID: <20080516112743.E11F7209D23@releng1.fedora.phx.redhat.com> Excluding Packages in global exclude list Finished Excluding Packages in global exclude list Finished New package rubygem-hoe Hoe is a simple rake/rubygems helper for project Rakefiles New package tmispell-voikko An Ispell compatible front-end for spell-checking modules New package rubygem-activeldap Ruby/ActiveLdap is a object-oriented API to LDAP New package perl-Text-Smart Processor for 'smart text' markup New package perl-Text-Smart-Plugin Template Toolkit plugin for Text::Smart New package rubygem-gem2rpm Generate rpm specfiles from gems New package ocaml-pa-monad OCaml syntax extension for monads New package libcapseo A realtime encoder/decoder library New package rubygem-rubyforge A script which automates a limited set of rubyforge operations New package ocaml-deriving Extension to OCaml for deriving functions from types Updated Packages: netcdf-4.0.0-0.4.beta2.fc10 --------------------------- * Thu May 15 18:00:00 2008 Balint Cristian - 4.0.0-0.4.beta2 - re-enable ppc64 since hdf5 is now present for ppc64 osgcal-0.1.46-6.fc10 -------------------- * Fri May 16 18:00:00 2008 Ralf Cors??pius - 0.1.46-6 - Rebuild against OSG-2.4.0. imageinfo-0.05-4.fc10 --------------------- * Thu May 15 18:00:00 2008 Brendt Wohlberg - 0.05-4 - Added patch for recent rename of Magick-config to MagickCore-config kdelibs-4.0.72-4.fc10 --------------------- * Thu May 15 18:00:00 2008 Kevin Kofler - 4.0.72-4 - fix proxy support (#443931, kde#155707) - move %{_kde4_appsdir}/ksgmltools2/ from -devel to the main package (#446435) planner-0.14.3-2.fc10 --------------------- * Tue May 13 18:00:00 2008 Caolan McNamara - 0.14.3-2 - rebuild for e-d-s gxine-0.5.902-1.fc10 -------------------- * Tue Apr 22 18:00:00 2008 Martin Sourada - 0.5.902-1 - new upstream version - drop xine-lib version patch - fixed in upstream - drop keep track of window state patch - fixed in upstream - add BR: hal - customize configure options - do not use spearate toolbar by default libtheora-1.0beta3-2.fc10 ------------------------- * Wed May 14 18:00:00 2008 Hans de Goede 0:1.0beta3-2 - Fix libtheoraenc getting build but not installed im-chooser-0.99.6-4.fc10 ------------------------ * Wed May 14 18:00:00 2008 Akira TAGOH - 0.99.6-4 - im-chooser-fix-window-border.patch: Display the progress window with the certain window border. (#444818) - imsettings-ignore-error-on-check-running.patch: Fix a crash issue when the pidfile doesn't exist. (#445129) tasks-0.12-2.fc10 ----------------- nautilus-sendto-0.14.0-4.fc10 ----------------------------- * Wed May 14 18:00:00 2008 Matthias Clasen - 0.14.0-4 - Rebuild again * Tue May 13 18:00:00 2008 - Bastien Nocera - 0.14.0-3 - Rebuild * Sun May 4 18:00:00 2008 Matthias Clasen - 0.14.0-2 - Fix source url perl-IPC-ShareLite-0.13-1.fc10 ------------------------------ * Thu May 15 18:00:00 2008 Steven Pritchard 0.13-1 - Update to 0.13. - Update Source0 URL. openser-1.3.2-2.fc10 -------------------- * Fri May 16 18:00:00 2008 Peter Lemenkov 1.3.2-2 - New modules - dialplan and drouting (this one still has no README) * Thu May 15 18:00:00 2008 Peter Lemenkov 1.3.2-1 - Ver. 1.3.2 perl-Apache-Session-1.86-1.fc10 ------------------------------- * Tue Feb 5 17:00:00 2008 Steven Pritchard 1.86-1 - Update to 1.86. vim-7.1.298-1.fc10 ------------------ * Thu May 15 18:00:00 2008 Karsten Hopp 7.1.298-1 - patchlevel 298 * Fri Apr 11 18:00:00 2008 Karsten Hopp 7.1.293-1 - patchlevel 293 - update forth syntax file (Benjamin Krill) perl-Data-Structure-Util-0.15-1.fc10 ------------------------------------ * Thu May 15 18:00:00 2008 Steven Pritchard 0.15-1 - Update to 0.15. - Fix Source0 URL (maintainer has changed). - Drop Clone dependency. - Build using Makefile.PL/make instead of Module::Build. gcompris-8.4.5-1.fc10 --------------------- * Thu May 15 18:00:00 2008 Johan Cwiklinski 8.4.5-1 - New upstream bugfix release 8.4.5 gqview-2.0.4-9 -------------- * Thu May 15 18:00:00 2008 Michael Schwendt - 2.0.4-9 - desktop-file: validate for F9+ taskjuggler-2.4.1-1.fc10 ------------------------ * Wed May 14 18:00:00 2008 Ondrej Vasik - 2.4.1-1 - new upstream release gossip-0.29-2.fc10 ------------------ * Wed May 14 18:00:00 2008 Brian Pepple - 0.29-2 - Rebuild for new e-d-s. kmymoney2-0.9-1.fc10 -------------------- * Wed May 14 18:00:00 2008 Rex Dieter 0.9-1 - kmymoney2-0.9 libxml2-2.6.32-2.fc10 --------------------- * Thu May 15 18:00:00 2008 Daniel Veillard 2.6.31-2.fc10 - try to fix multiarch problems like #440206 perl-DateTime-0.42-1.fc10 ------------------------- * Thu May 15 18:00:00 2008 Steven Pritchard 1:0.42-1 - Update to DateTime 0.42. - Update to DateTime::TimeZone 0.75. - Update FAQ URL in description. inn-2.4.4-1.fc10 ---------------- * Thu May 15 18:00:00 2008 Ondrej Vasik - 2.4.4-1 - new upstream release 2.4.4 rsyslog-3.16.1-1.fc10 --------------------- * Wed May 14 18:00:00 2008 Tomas Heinrich 3.16.1-1 - upgrade * Tue Apr 8 18:00:00 2008 Peter Vrabec 3.14.1-5 - prevent undesired error description in legacy warning messages * Tue Apr 8 18:00:00 2008 Peter Vrabec 3.14.1-4 - adjust symbol lookup method to 2.6 kernel * Tue Apr 8 18:00:00 2008 Peter Vrabec 3.14.1-3 - fix segfault of expression based filters xastir-1.9.2-5.fc10 ------------------- * Mon May 5 18:00:00 2008 Lucian Langa - 1.9.2-5 - Update to newer ImageMagick pptp-1.7.2-1.fc10 ----------------- * Wed May 14 18:00:00 2008 Paul Howarth 1.7.2-1 - Update to 1.7.2 - New script and manpage: pptpsetup - Add patch to remove reference to stropts.h, not shipped in F9 onwards NetworkManager-0.7.0-0.9.3.svn3669.fc10 --------------------------------------- * Wed May 14 18:00:00 2008 Dan Williams - 1:0.7.0-0.9.3.svn3669 - Fix initial carrier state detection on devices that are already up (rh #134886) autofs-5.0.3-16 --------------- * Wed May 14 18:00:00 2008 Ian Kent - 5.0.3-16 - update patches, documentation and comments only change. - rename patch and add to CVS. libopensync-plugin-evolution2-0.35-3.fc10 ----------------------------------------- PyQt4-4.4-1.fc10 ---------------- * Wed May 14 18:00:00 2008 Rex Dieter 4.4-1 - PyQt-4.4 - License: GPLv3 or GPLv2 with exceptions libgweather-2.23.2-1.fc10 ------------------------- * Wed May 14 18:00:00 2008 Matthias Clasen 2.23.2-1 - Update to 2.23.2 bug-buddy-2.22.0-3.fc10 ----------------------- * Wed May 14 18:00:00 2008 Matthias Clasen - 1:2.22.0-3 - Rebuild perl-Cache-Mmap-0.11-1.fc10 --------------------------- * Thu May 15 18:00:00 2008 Steven Pritchard 0.11-1 - Update to 0.11. texinfo-4.12-1.fc10 ------------------- * Wed May 14 18:00:00 2008 Vitezslav Crhonek - 4.12-1 - Update to texinfo-4.12 - Remove description ("This is...") from /usr/share/info/dir in info post install section Resolves: #433535 fedora-release-notes-9.0.1-1 ---------------------------- * Mon May 12 18:00:00 2008 Paul W. Frields - 9.0.1-1 - Update with various bugfixes and translation updates pstoedit-3.45-3.fc10 -------------------- * Wed May 14 18:00:00 2008 Denis Leroy - 3.45-3 - Rebuild for new ImageMagick tog-pegasus-2.7.0-7.fc10 ------------------------ * Thu May 15 18:00:00 2008 Vitezslav Crhonek - 2:2.7.0-7 - Rebuild rootsh-1.5.3-1.fc10 ------------------- * Wed May 14 18:00:00 2008 Tom "spot" Callaway 1.5.3-1 - update to 1.5.3 - open needs 3 args bzr-1.4-2.fc10 -------------- * Thu May 15 18:00:00 2008 Toshio Kuratomi - 1.4-2 - Workaround upstream Bug# 230223 by Requiring python-pycurl. gtk-gnutella-0.96.5-1.fc9 ------------------------- * Tue Apr 8 18:00:00 2008 Dmitry Butskoy - 0.96.5-1 - update to 0.96.5 osgal-0.6.1-4.fc10 ------------------ * Fri May 16 18:00:00 2008 Ralf Cors??pius - 1:0.6.1-4 - Rebuild against OSG-2.4.0. R-hdf5-1.6.6-6.fc10 ------------------- * Wed May 14 18:00:00 2008 Tom "spot" Callaway - 1.6.6-6 - reenable ppc64 R-2.7.0-2.fc10 -------------- * Tue May 13 18:00:00 2008 Tom "spot" Callaway 2.7.0-2 - add patch from Martyn Plummer to avoid possible bad path hardcoding in /usr/bin/Rscript - properly handle ia64 case (bz 446181) openoffice.org-3.0.0-0.0.12.1.fc10 ---------------------------------- * Fri May 9 18:00:00 2008 Caolan McNamara - 1:3.0.0-0.12.1 - next version - re-add openoffice.org-2.2.0.gccXXXXX.solenv.javaregistration.patch * Fri May 9 18:00:00 2008 Caolan McNamara - 1:3.0.0-0.11.1 - next version - drop integrated workspace.cmcfixes43.patch - drop integrated openoffice.org-3.0.0.ooo88375.filter.disablepdf.patch - drop integrated openoffice.org-3.0.0.ooo88319.setup_native.missing.patch - drop redundant openoffice.org-2.0.4.ooo69051.vcl.singlekeypress.patch - drop openoffice.org-2.0.4.rh217065.syncbackspace.patch as reported fixed - add openoffice.org-3.0.0.ooo89002.vcl.symbolfonts.patch - add openoffice.org-3.0.0.ooo89172.filter.string.patch - enable presentation-minimizer - enable presenter-screen - tidy configure line through --with-system-libs --with-system-headers - drop sequence check patch and use .xcu configuration * Wed Apr 30 18:00:00 2008 Caolan McNamara - 1:3.0.0-0.10.1 - next version - drop integrated openoffice.org-2.3.0.ooo82966.svx.missing3d.patch - drop integrated openoffice.org-2.2.1.ooo79481.sw.rowordcount.patch - drop openoffice.org-2.4.0.gccXXXXX.wizards.patch - drop openoffice.org-2.1.0.oooXXXXX.vcl.dontsortglyphs.patch - drop openoffice.org-2.2.1.ooo78971.xmloff.outofrange.patch - drop openoffice.org-2.4.0.ooo85054.stlport.noorigs.patch - drop openoffice.org-2.2.0.rh232389.tango.patch - Resolves: rhbz#444571 add openoffice.org-3.0.0.ooo88090.chart2.negativecount.patch - add workspace.ucpgio1.patch and disable gnome-vfs perl-BerkeleyDB-0.34-1.fc10 --------------------------- * Thu May 15 18:00:00 2008 Steven Pritchard 0.34-1 - Update to 0.34. perl-GSSAPI-0.26-1.fc10 ----------------------- * Thu May 15 18:00:00 2008 Steven Pritchard 0.26-1 - Update to 0.26. - Cleanup a little to more closely match cpanspec output. - BR ExtUtils::MakeMaker. mew-6.0.51-1.fc10 ----------------- * Wed May 14 18:00:00 2008 Akira TAGOH - 6.0.51-1 - New upstream release. * Thu Apr 17 18:00:00 2008 Akira TAGOH - 6.0.50-1 - New upstream release. uw-imap-2007a1-3.fc9 -------------------- * Sun May 18 18:00:00 2008 Rex Dieter 2007a1-3 - libc-client: incomplete list of obsoletes (#446240) clamav-0.93-1.fc9 ----------------- * Mon Apr 14 18:00:00 2008 Enrico Scholz - 0.93-1 - updated to final 0.93 - removed daily.inc + main.inc directories; they are now replaced by *.cld containers - trimmed down MAILTO list of cronjob to 'root' again; every well configured system has an alias for this recipient sylpheed-2.5.0-0.2.beta3 ------------------------ * Thu May 15 18:00:00 2008 Michael Schwendt - 2.5.0-0.2.beta3 - desktop-file: validate for F9+ a2ps-4.14-3.fc10 ---------------- * Wed May 14 18:00:00 2008 Patrice Dumas 4.14-3 - %{_datadir}/a2ps/afm/fonts.map is dynamically generated, mark it as such in %files (bug #70919) contact-lookup-applet-0.16-6.fc10 --------------------------------- * Wed May 14 18:00:00 2008 Brian Pepple - 0.16-6 - Rebuild for new e-d-s. gnome-phone-manager-0.51-2.fc10 ------------------------------- * Wed May 14 18:00:00 2008 - Bastien Nocera - 0.51-2 - Rebuild man-1.6f-6.fc10 --------------- * Wed May 14 18:00:00 2008 Ivana Varekova - 1.6f-6 - Resolves: #439314 move locale files - spec file cleanup * Wed Apr 16 18:00:00 2008 Ivana Varekova - 1.6f -5 - Resolves: #442192 fix fr translation kdegames-4.0.72-2.fc10 ---------------------- * Thu May 15 18:00:00 2008 Rex Dieter 4.0.72-2 - ggz-config --force , to ensure updates to possibly-changed ggz modules jd-2.0.0-0.4.svn2051_trunk.fc10 ------------------------------- * Thu May 15 18:00:00 2008 Mamoru Tasaka - 2.0.0-0.4.svn2051_trunk - 2.0.0 trunk 2051 dates-0.4.5-2.fc10 ------------------ arts-1.5.9-3.fc10 ----------------- * Thu May 15 18:00:00 2008 Rex Dieter 8:1.5.9-3 - arts support for mixed multilib usage (#444484) - f10+: drop optional esd, jack, nas support gnome-settings-daemon-2.23.2-0.2008.05.14.2.fc10 ------------------------------------------------ * Wed May 14 18:00:00 2008 Matthias Clasen - 2.23.2-0.2008.05.14.2 - Fix BuildRequires * Wed May 14 18:00:00 2008 Jon McCann - 2.23.2-0.2008.05.14.1 - Build snapshot perl-Devel-Cycle-1.09-1.fc10 ---------------------------- * Thu May 15 18:00:00 2008 Steven Pritchard 1.09-1 - Update to 1.09. - Reformat to match cpanspec output. - Fix find option order. - Use fixperms macro instead of our own chmod incantation. tzclock-2.7.1-1.fc10 -------------------- * Thu May 15 18:00:00 2008 Mamoru Tasaka - 2.7.1-1 - 2.7.1 Miro-1.2.3-2.fc10 ----------------- audacity-1.3.5-0.4.beta.fc10 ---------------------------- * Thu May 15 18:00:00 2008 Michael Schwendt - 1.3.5-0.4.beta - desktop-file: drop deprecated Encoding, drop Icon file extension * Thu May 15 18:00:00 2008 Michael Schwendt - 1.3.5-0.3.beta - merge 1.3.5-beta from test branch * Fri May 9 18:00:00 2008 Michael Schwendt - 1.3.5-0.2.beta - update to 1.3.5-beta - expat2 patch merged upstream - scriptlets: run update-desktop-database without path - drop scriptlet dependencies * Mon May 5 18:00:00 2008 Michael Schwendt - 1.3.5-0.1.rc3.20080505cvs - update to 1.3.5-rc3 cvs snapshot - ExportMP3.cpp libdir patch obsolete contacts-0.8-3.fc10 ------------------- gnome-panel-2.23.2.1-1.fc10 --------------------------- * Wed May 14 18:00:00 2008 Matthias Clasen - 2.23.2.1-1 - Update to 2.23.2.1 * Wed May 14 18:00:00 2008 Adam Tkac - 2.23.1-2 - rebuild mt-daapd-0.2.4.2-2.fc10 ----------------------- * Thu May 15 18:00:00 2008 W. Michael Petullo - 0.2.4.2-2 - Bump epoch. * Wed May 14 18:00:00 2008 W. Michael Petullo - 0.2.4.2-1 - New upstream version. - Remove check-input patch; it's upstream. * Fri Apr 18 18:00:00 2008 W. Michael Petullo - 0.9-0.2.1696 - Apply patch by Nico Golde to fix integer overflow, Bugzilla #442688. * Tue Feb 26 17:00:00 2008 W. Michael Petullo - 0.9-0.1.1696 - New upstream version. bind-9.5.0-33.rc1.fc10 ---------------------- * Wed May 14 18:00:00 2008 Adam Tkac 32:9.5.0-33.rc1 - updated to 9.5.0rc1 - merged patches - bind-9.5-libcap.patch - make binaries readable by others (#427826) perl-DateTime-Format-ICal-0.09-1.fc10 ------------------------------------- * Thu May 15 18:00:00 2008 Steven Pritchard 0.09-1 - Update to 0.09. gnome-launch-box-0.4-9.fc10 --------------------------- * Wed May 14 18:00:00 2008 - Bastien Nocera - 0.4-9 - Rebuild python-fedora-0.2.99.11-1.fc10 ------------------------------ gnome-screensaver-2.23.3-0.2008.05.14.1.fc10 -------------------------------------------- * Fri May 16 18:00:00 2008 Jon McCann - 2.23.3-0.2008.05.14.1 - Add frame to face image * Wed May 14 18:00:00 2008 Jon McCann - 2.23.3-0.2008.05.14.0 - Update to snapshot kdelibs3-3.5.9-10.fc10 ---------------------- * Sun May 18 18:00:00 2008 Rex Dieter 3.5.9-10 - fix kresources.desktop: NoDisplay=true f-spot-0.4.3.1-1.fc10 --------------------- * Tue May 13 18:00:00 2008 Matthias Clasen - 0.4.3.1-1 - Update to 0.4.3.1 perl-Authen-SASL-2.11-1.fc10 ---------------------------- * Thu May 15 18:00:00 2008 Steven Pritchard 2.11-1 - Update to 2.11. - Fix find option order. - Use fixperms macro instead of our own chmod incantation. - Reformat to resemble cpanspec output. - Drop explicit perl build dependency. autoconf-2.62-1.fc10 -------------------- * Tue May 13 18:00:00 2008 Karsten Hopp 2.62-1 - autoconf-2.62 scim-python-0.1.12-1.fc10 ------------------------- * Wed May 14 18:00:00 2008 Huang Peng - 0.1.12-1 - Update to 0.1.12. bouncycastle-1.39-1.fc10 ------------------------ * Thu May 15 18:00:00 2008 Thomas Fitzsimmons - 1.39-1 - Import Bouncy Castle 1.39. - Set target to 1.5. ocaml-lablgl-1.03-4.fc10 ------------------------ * Wed May 14 18:00:00 2008 Richard W.M. Jones - 1.03-4 - Remove BRs for camlp4, labltk. - Remove old Provides. gnome-session-2.23.2.2-2.fc10 ----------------------------- * Thu May 15 18:00:00 2008 Matthias Clasen - 2.23.2.2-2 - Don't crash while handling legacy sessions * Wed May 14 18:00:00 2008 Matthias Clasen - 2.23.2.2-1 - Update to 2.23.2.2 rubygem-rake-0.8.1-2.fc10 ------------------------- * Thu May 15 18:00:00 2008 Alan Pevec 0.8.1-2 - fix shebang in scripts * Thu May 15 18:00:00 2008 Alan Pevec 0.8.1-1 - new upstream version bouml-4.3.3-1.fc10 ------------------ * Wed May 14 18:00:00 2008 Debarshi Ray - 4.3.3-1 - Version bump to 4.3.3. Closes Red Hat Bugzilla bug #445908. - Previous releases can not read a project saved with this version, but projects made by previous releases can be read. snort-2.8.1-3.fc10 ------------------ * Thu May 15 18:00:00 2008 Dennis Gilmore - 2.8.1-3 - make rules dir * Thu May 15 18:00:00 2008 Dennis Gilmore - 2.8.1-2 - fix character encodings * Fri Apr 25 18:00:00 2008 Steve Grubb - 2.8.1-1 - update to 2.8.1 openbox-3.4.7.2-1.fc10 ---------------------- * Wed May 14 18:00:00 2008 Miroslav Lichvar - 3.4.7.2-1 - Update to 3.4.7.2 - Use gnome menus by default (Luke Macken) (#443548) - Force setting number of desktops (#444135) * Thu Apr 17 18:00:00 2008 Miroslav Lichvar - 3.4.7.1-1 - Update to 3.4.7.1 - Don't require /usr/share/themes perl-ExtUtils-Depends-0.300-1.fc10 ---------------------------------- * Thu May 15 18:00:00 2008 Steven Pritchard 0.300-1 - Update to 0.300. - Clean up to match cpanspec output. - Fix find option order. - Use fixperms macro instead of our own chmod incantation. - Update Source0 URL. - BR Test::More. libgpod-0.6.0-5.fc10 -------------------- * Wed May 14 18:00:00 2008 Todd Zullinger - 0.6.0-5 - Make libgpod-devel require glib2-devel (#446442) perl-Devel-StackTrace-1.18-2.fc10 --------------------------------- * Fri May 16 18:00:00 2008 Ralf Cors??pius - 1.18-2 - Bump release. * Mon Apr 7 18:00:00 2008 Ralf Cors??pius - 1.18-1 - Upstream update. glibc-2.8.90-1 -------------- * Thu May 15 18:00:00 2008 Jakub Jelinek 2.8.90-1 - update to trunk - O(n) memmem/strstr/strcasestr - i386/x86_64 TLS descriptors support - concurrent IPv4 and IPv6 DNS lookups by getaddrinfo glabels-2.2.2-1.fc10 -------------------- fonts-japanese-0.20061016-13.fc9 -------------------------------- * Tue Apr 8 18:00:00 2008 Akira TAGOH - 0.20061016-13 - Add VLGothic-fonts deps and drop sazanami-fonts-gothic. sip-4.7.5-1.fc10 ---------------- * Wed May 14 18:00:00 2008 Rex Dieter - 4.7.5-1 - sip-4.7.5 ktorrent-3.0.2-3.fc10 --------------------- * Wed May 14 18:00:00 2008 Roland Wolters - 3.0.2-3 - bugfix update to version 3.0.2 - some spec file fixes due to an update error * Mon Apr 28 18:00:00 2008 Rex Dieter - 3.0.1-4 - %postun: remove extraneous scriplets - -devel: own %{_kde4_includedir}/libbtcore/ (and subdirs) - -devel: Requires: kdelibs4-devel - drop: Requires: oxygen-icon-theme (kde4 runtime already does) - Requires(post,postun): xdg-utils libvorbis-1.2.0-4.fc10 ---------------------- * Wed May 14 18:00:00 2008 Jindrich Novy - 1:1.2.0-4 - fix CVE-2008-1420, CVE-2008-1419, CVE-2008-1423 (#446344) mousetweaks-2.23.2-3.fc10 ------------------------- * Thu May 15 18:00:00 2008 Matthias Clasen - 2.23.2-3 - Fix a typo * Wed May 14 18:00:00 2008 Matthias Clasen - 2.23.2-2 - Make the %pre script handle missing schema files libvirt-0.4.2-5.fc10 -------------------- * Thu May 15 18:00:00 2008 Daniel P. Berrange - 0.4.2-5.fc10 - Rebuild with policy enabled (rhbz #446616) hunspell-1.2.2-2.fc10 --------------------- * Wed May 14 18:00:00 2008 Caolan McNamara - 1.2.2-2 - give xulrunner what it needs so we can get on with it gtkwave-3.1.10-1.fc10 --------------------- * Thu May 15 18:00:00 2008 Paul Howarth 3.1.10-1 - update to 3.1.10 Summary: Added Packages: 10 Removed Packages: 0 Modified Packages: 96 Broken deps for i386 ---------------------------------------------------------- LabPlot-1.5.1.6-4.fc8.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libMagick.so.10 autotrace-0.31.1-16.fc9.i386 requires libWand.so.10 autotrace-0.31.1-16.fc9.i386 requires libMagick.so.10 brasero-0.7.1-3.fc9.i386 requires libtotem-plparser.so.10 drawtiming-0.6.2-3.fc9.i386 requires libMagick++.so.10 drawtiming-0.6.2-3.fc9.i386 requires libWand.so.10 drawtiming-0.6.2-3.fc9.i386 requires libMagick.so.10 dx-4.4.4-6.fc9.i386 requires libWand.so.10 dx-4.4.4-6.fc9.i386 requires libMagick.so.10 dx-libs-4.4.4-6.fc9.i386 requires libWand.so.10 dx-libs-4.4.4-6.fc9.i386 requires libMagick.so.10 empathy-0.23.1-2.fc10.i386 requires libedataserver-1.2.so.9 empathy-libs-0.23.1-2.fc10.i386 requires libedataserver-1.2.so.9 evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-python-0.0.4-3.fc9.i386 requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.i386 requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-1.2.so.11 gdl-0.9-0.rc1.1.fc9.i386 requires libMagick++.so.10 gnome-python2-evolution-2.22.0-2.fc9.i386 requires libedataserver-1.2.so.9 gnome-python2-totem-2.22.0-2.fc9.i386 requires libtotem-plparser.so.10 k3d-0.6.7.0-6.fc9.i386 requires libMagick++.so.10 k3d-0.6.7.0-6.fc9.i386 requires libMagick.so.10 k3d-0.6.7.0-6.fc9.i386 requires libWand.so.10 kismet-extras-0.0.2007.10.R1-3.fc9.i386 requires libMagick.so.10 koffice-karbon-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-karbon-1.6.3-15.fc9.i386 requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libMagick.so.10 libfprint-0.0.5-3.fc9.i386 requires libWand.so.10 libfprint-0.0.5-3.fc9.i386 requires libMagick.so.10 nip2-7.14.1-1.fc9.i386 requires libWand.so.10 nip2-7.14.1-1.fc9.i386 requires libMagick.so.10 obconf-2.0.3-1.fc9.i386 requires libobparser.so.16 obconf-2.0.3-1.fc9.i386 requires libobrender.so.16 1:openoffice.org-presentation-minimizer-3.0.0-0.0.12.1.fc10.i386 requires openoffice.org-base-impress = 1:3.0.0-0.0.12.1.fc10 1:openoffice.org-presenter-screen-3.0.0-0.0.12.1.fc10.i386 requires openoffice.org-base-impress = 1:3.0.0-0.0.12.1.fc10 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) php-magickwand-1.0.7-1.fc10.i386 requires libWand.so.10 php-magickwand-1.0.7-1.fc10.i386 requires libMagick.so.10 poker3d-1.1.36-9.fc9.i386 requires libosgTerrain.so.25 poker3d-1.1.36-9.fc9.i386 requires libosgViewer.so.25 poker3d-1.1.36-9.fc9.i386 requires libosgDB.so.25 poker3d-1.1.36-9.fc9.i386 requires libOpenThreads.so.9 poker3d-1.1.36-9.fc9.i386 requires libosgGA.so.25 poker3d-1.1.36-9.fc9.i386 requires libosg.so.25 poker3d-1.1.36-9.fc9.i386 requires libosgText.so.25 poker3d-1.1.36-9.fc9.i386 requires libosgFX.so.25 poker3d-1.1.36-9.fc9.i386 requires libosgSim.so.25 poker3d-1.1.36-9.fc9.i386 requires libosgParticle.so.25 poker3d-1.1.36-9.fc9.i386 requires libosgManipulator.so.25 poker3d-1.1.36-9.fc9.i386 requires libosgUtil.so.25 psiconv-0.9.8-1.fc8.i386 requires libWand.so.10 psiconv-0.9.8-1.fc8.i386 requires libMagick.so.10 q-7.10-3.fc9.i386 requires libMagick.so.10 qgis-0.9.1-5.fc9.i386 requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.i386 requires libgeos.so.2 rhythmbox-0.11.5-9.fc9.i386 requires libtotem-plparser.so.10 sunbird-0.8-3.fc9.i386 requires libhunspell.so.1 thunderbird-lightning-0.8-3.fc9.i386 requires libhunspell.so.1 torcs-1.3.0-6.fc9.i386 requires libplibssgaux.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibssg.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibsl.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibsm.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibsg.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibul.so.1.8.4 totem-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 totem-mozplugin-2.23.2-2.fc9.i386 requires libtotem-plparser-mini.so.10 totem-mozplugin-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 totem-nautilus-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 vips-7.14.1-1.fc9.i386 requires libWand.so.10 vips-7.14.1-1.fc9.i386 requires libMagick.so.10 vips-python-7.14.1-1.fc9.i386 requires libWand.so.10 vips-python-7.14.1-1.fc9.i386 requires libMagick.so.10 vips-tools-7.14.1-1.fc9.i386 requires libWand.so.10 vips-tools-7.14.1-1.fc9.i386 requires libMagick.so.10 xulrunner-1.9-0.60.cvs20080414.fc10.i386 requires libhunspell.so.1 Broken deps for x86_64 ---------------------------------------------------------- LabPlot-1.5.1.6-4.fc8.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libMagick.so.10 LabPlot-1.5.1.6-4.fc8.x86_64 requires libMagick++.so.10()(64bit) LabPlot-1.5.1.6-4.fc8.x86_64 requires libMagick.so.10()(64bit) LabPlot-1.5.1.6-4.fc8.x86_64 requires libWand.so.10()(64bit) autotrace-0.31.1-16.fc9.i386 requires libWand.so.10 autotrace-0.31.1-16.fc9.i386 requires libMagick.so.10 autotrace-0.31.1-16.fc9.x86_64 requires libWand.so.10()(64bit) autotrace-0.31.1-16.fc9.x86_64 requires libMagick.so.10()(64bit) brasero-0.7.1-3.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) drawtiming-0.6.2-3.fc9.x86_64 requires libWand.so.10()(64bit) drawtiming-0.6.2-3.fc9.x86_64 requires libMagick++.so.10()(64bit) drawtiming-0.6.2-3.fc9.x86_64 requires libMagick.so.10()(64bit) dx-4.4.4-6.fc9.x86_64 requires libMagick.so.10()(64bit) dx-4.4.4-6.fc9.x86_64 requires libWand.so.10()(64bit) dx-libs-4.4.4-6.fc9.i386 requires libWand.so.10 dx-libs-4.4.4-6.fc9.i386 requires libMagick.so.10 dx-libs-4.4.4-6.fc9.x86_64 requires libMagick.so.10()(64bit) dx-libs-4.4.4-6.fc9.x86_64 requires libWand.so.10()(64bit) empathy-0.23.1-2.fc10.x86_64 requires libedataserver-1.2.so.9()(64bit) empathy-libs-0.23.1-2.fc10.i386 requires libedataserver-1.2.so.9 empathy-libs-0.23.1-2.fc10.x86_64 requires libedataserver-1.2.so.9()(64bit) evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libWand.so.10()(64bit) evolution-python-0.0.4-3.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx gdl-0.9-0.rc1.1.fc9.x86_64 requires libMagick++.so.10()(64bit) gnome-python2-evolution-2.22.0-2.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) gnome-python2-totem-2.22.0-2.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) k3d-0.6.7.0-6.fc9.i386 requires libMagick++.so.10 k3d-0.6.7.0-6.fc9.i386 requires libMagick.so.10 k3d-0.6.7.0-6.fc9.i386 requires libWand.so.10 k3d-0.6.7.0-6.fc9.x86_64 requires libMagick.so.10()(64bit) k3d-0.6.7.0-6.fc9.x86_64 requires libWand.so.10()(64bit) k3d-0.6.7.0-6.fc9.x86_64 requires libMagick++.so.10()(64bit) kismet-extras-0.0.2007.10.R1-3.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.x86_64 requires libWand.so.10()(64bit) koffice-libs-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.x86_64 requires libWand.so.10()(64bit) libfprint-0.0.5-3.fc9.i386 requires libWand.so.10 libfprint-0.0.5-3.fc9.i386 requires libMagick.so.10 libfprint-0.0.5-3.fc9.x86_64 requires libWand.so.10()(64bit) libfprint-0.0.5-3.fc9.x86_64 requires libMagick.so.10()(64bit) nip2-7.14.1-1.fc9.x86_64 requires libMagick.so.10()(64bit) nip2-7.14.1-1.fc9.x86_64 requires libWand.so.10()(64bit) obconf-2.0.3-1.fc9.x86_64 requires libobparser.so.16()(64bit) obconf-2.0.3-1.fc9.x86_64 requires libobrender.so.16()(64bit) 1:openoffice.org-presentation-minimizer-3.0.0-0.0.12.1.fc10.x86_64 requires openoffice.org-base-impress = 1:3.0.0-0.0.12.1.fc10 1:openoffice.org-presenter-screen-3.0.0-0.0.12.1.fc10.x86_64 requires openoffice.org-base-impress = 1:3.0.0-0.0.12.1.fc10 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) php-magickwand-1.0.7-1.fc10.x86_64 requires libWand.so.10()(64bit) php-magickwand-1.0.7-1.fc10.x86_64 requires libMagick.so.10()(64bit) poker3d-1.1.36-9.fc9.x86_64 requires libosgGA.so.25()(64bit) poker3d-1.1.36-9.fc9.x86_64 requires libosgFX.so.25()(64bit) poker3d-1.1.36-9.fc9.x86_64 requires libosgUtil.so.25()(64bit) poker3d-1.1.36-9.fc9.x86_64 requires libOpenThreads.so.9()(64bit) poker3d-1.1.36-9.fc9.x86_64 requires libosgParticle.so.25()(64bit) poker3d-1.1.36-9.fc9.x86_64 requires libosgText.so.25()(64bit) poker3d-1.1.36-9.fc9.x86_64 requires libosgSim.so.25()(64bit) poker3d-1.1.36-9.fc9.x86_64 requires libosgManipulator.so.25()(64bit) poker3d-1.1.36-9.fc9.x86_64 requires libosg.so.25()(64bit) poker3d-1.1.36-9.fc9.x86_64 requires libosgTerrain.so.25()(64bit) poker3d-1.1.36-9.fc9.x86_64 requires libosgDB.so.25()(64bit) poker3d-1.1.36-9.fc9.x86_64 requires libosgViewer.so.25()(64bit) psiconv-0.9.8-1.fc8.i386 requires libWand.so.10 psiconv-0.9.8-1.fc8.i386 requires libMagick.so.10 psiconv-0.9.8-1.fc8.x86_64 requires libWand.so.10()(64bit) psiconv-0.9.8-1.fc8.x86_64 requires libMagick.so.10()(64bit) q-7.10-3.fc9.i386 requires libMagick.so.10 qgis-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) rhythmbox-0.11.5-9.fc9.i386 requires libtotem-plparser.so.10 rhythmbox-0.11.5-9.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) sunbird-0.8-3.fc9.x86_64 requires libhunspell.so.1()(64bit) thunderbird-lightning-0.8-3.fc9.x86_64 requires libhunspell.so.1()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibsg.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibul.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibssgaux.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibsm.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibssg.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibsl.so.1.8.4()(64bit) totem-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 totem-2.23.2-2.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.x86_64 requires libtotem-plparser-mini.so.10()(64bit) totem-nautilus-2.23.2-2.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) vips-7.14.1-1.fc9.i386 requires libWand.so.10 vips-7.14.1-1.fc9.i386 requires libMagick.so.10 vips-7.14.1-1.fc9.x86_64 requires libMagick.so.10()(64bit) vips-7.14.1-1.fc9.x86_64 requires libWand.so.10()(64bit) vips-python-7.14.1-1.fc9.x86_64 requires libMagick.so.10()(64bit) vips-python-7.14.1-1.fc9.x86_64 requires libWand.so.10()(64bit) vips-tools-7.14.1-1.fc9.x86_64 requires libMagick.so.10()(64bit) vips-tools-7.14.1-1.fc9.x86_64 requires libWand.so.10()(64bit) xulrunner-1.9-0.60.cvs20080414.fc10.i386 requires libhunspell.so.1 xulrunner-1.9-0.60.cvs20080414.fc10.x86_64 requires libhunspell.so.1()(64bit) Broken deps for ppc ---------------------------------------------------------- LabPlot-1.5.1.6-4.fc8.ppc requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.ppc requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.ppc requires libMagick.so.10 autotrace-0.31.1-16.fc9.ppc requires libWand.so.10 autotrace-0.31.1-16.fc9.ppc requires libMagick.so.10 autotrace-0.31.1-16.fc9.ppc64 requires libWand.so.10()(64bit) autotrace-0.31.1-16.fc9.ppc64 requires libMagick.so.10()(64bit) brasero-0.7.1-3.fc9.ppc requires libtotem-plparser.so.10 drawtiming-0.6.2-3.fc9.ppc requires libMagick++.so.10 drawtiming-0.6.2-3.fc9.ppc requires libWand.so.10 drawtiming-0.6.2-3.fc9.ppc requires libMagick.so.10 dx-4.4.4-6.fc9.ppc requires libWand.so.10 dx-4.4.4-6.fc9.ppc requires libMagick.so.10 dx-libs-4.4.4-6.fc9.ppc requires libWand.so.10 dx-libs-4.4.4-6.fc9.ppc requires libMagick.so.10 dx-libs-4.4.4-6.fc9.ppc64 requires libMagick.so.10()(64bit) dx-libs-4.4.4-6.fc9.ppc64 requires libWand.so.10()(64bit) empathy-0.23.1-2.fc10.ppc requires libedataserver-1.2.so.9 empathy-libs-0.23.1-2.fc10.ppc requires libedataserver-1.2.so.9 empathy-libs-0.23.1-2.fc10.ppc64 requires libedataserver-1.2.so.9()(64bit) evolution-brutus-1.2.11-2.fc9.ppc requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.ppc requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.ppc requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-python-0.0.4-3.fc9.ppc requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.ppc requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-1.2.so.11 gdl-0.9-0.rc1.1.fc9.ppc requires libMagick++.so.10 gnome-python2-evolution-2.22.0-2.fc9.ppc requires libedataserver-1.2.so.9 gnome-python2-totem-2.22.0-2.fc9.ppc requires libtotem-plparser.so.10 k3d-0.6.7.0-6.fc9.ppc requires libMagick++.so.10 k3d-0.6.7.0-6.fc9.ppc requires libMagick.so.10 k3d-0.6.7.0-6.fc9.ppc requires libWand.so.10 k3d-0.6.7.0-6.fc9.ppc64 requires libMagick.so.10()(64bit) k3d-0.6.7.0-6.fc9.ppc64 requires libWand.so.10()(64bit) k3d-0.6.7.0-6.fc9.ppc64 requires libMagick++.so.10()(64bit) kismet-extras-0.0.2007.10.R1-3.fc9.ppc requires libMagick.so.10 koffice-karbon-1.6.3-15.fc9.ppc requires libWand.so.10 koffice-karbon-1.6.3-15.fc9.ppc requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.ppc requires libWand.so.10 koffice-libs-1.6.3-15.fc9.ppc requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) libfprint-0.0.5-3.fc9.ppc requires libWand.so.10 libfprint-0.0.5-3.fc9.ppc requires libMagick.so.10 libfprint-0.0.5-3.fc9.ppc64 requires libWand.so.10()(64bit) libfprint-0.0.5-3.fc9.ppc64 requires libMagick.so.10()(64bit) nip2-7.14.1-1.fc9.ppc requires libWand.so.10 nip2-7.14.1-1.fc9.ppc requires libMagick.so.10 obconf-2.0.3-1.fc9.ppc requires libobparser.so.16 obconf-2.0.3-1.fc9.ppc requires libobrender.so.16 1:openoffice.org-presentation-minimizer-3.0.0-0.0.12.1.fc10.ppc requires openoffice.org-base-impress = 1:3.0.0-0.0.12.1.fc10 1:openoffice.org-presenter-screen-3.0.0-0.0.12.1.fc10.ppc requires openoffice.org-base-impress = 1:3.0.0-0.0.12.1.fc10 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) php-magickwand-1.0.7-1.fc10.ppc requires libWand.so.10 php-magickwand-1.0.7-1.fc10.ppc requires libMagick.so.10 poker3d-1.1.36-9.fc9.ppc requires libosgTerrain.so.25 poker3d-1.1.36-9.fc9.ppc requires libosgViewer.so.25 poker3d-1.1.36-9.fc9.ppc requires libosgDB.so.25 poker3d-1.1.36-9.fc9.ppc requires libOpenThreads.so.9 poker3d-1.1.36-9.fc9.ppc requires libosgGA.so.25 poker3d-1.1.36-9.fc9.ppc requires libosg.so.25 poker3d-1.1.36-9.fc9.ppc requires libosgText.so.25 poker3d-1.1.36-9.fc9.ppc requires libosgFX.so.25 poker3d-1.1.36-9.fc9.ppc requires libosgSim.so.25 poker3d-1.1.36-9.fc9.ppc requires libosgParticle.so.25 poker3d-1.1.36-9.fc9.ppc requires libosgManipulator.so.25 poker3d-1.1.36-9.fc9.ppc requires libosgUtil.so.25 psiconv-0.9.8-1.fc8.ppc requires libWand.so.10 psiconv-0.9.8-1.fc8.ppc requires libMagick.so.10 psiconv-0.9.8-1.fc8.ppc64 requires libWand.so.10()(64bit) psiconv-0.9.8-1.fc8.ppc64 requires libMagick.so.10()(64bit) q-7.10-3.fc9.ppc requires libMagick.so.10 q-7.10-3.fc9.ppc64 requires libMagick.so.10()(64bit) qgis-0.9.1-5.fc9.ppc requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.ppc requires libgeos.so.2 rhythmbox-0.11.5-9.fc9.ppc requires libtotem-plparser.so.10 rhythmbox-0.11.5-9.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) sunbird-0.8-3.fc9.ppc requires libhunspell.so.1 thunderbird-lightning-0.8-3.fc9.ppc requires libhunspell.so.1 torcs-1.3.0-6.fc9.ppc requires libplibssgaux.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibssg.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibsl.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibsm.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibsg.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibul.so.1.8.4 totem-2.23.2-2.fc9.ppc requires libtotem-plparser.so.10 totem-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.ppc requires libtotem-plparser-mini.so.10 totem-mozplugin-2.23.2-2.fc9.ppc requires libtotem-plparser.so.10 totem-nautilus-2.23.2-2.fc9.ppc requires libtotem-plparser.so.10 vips-7.14.1-1.fc9.ppc requires libWand.so.10 vips-7.14.1-1.fc9.ppc requires libMagick.so.10 vips-7.14.1-1.fc9.ppc64 requires libMagick.so.10()(64bit) vips-7.14.1-1.fc9.ppc64 requires libWand.so.10()(64bit) vips-python-7.14.1-1.fc9.ppc requires libWand.so.10 vips-python-7.14.1-1.fc9.ppc requires libMagick.so.10 vips-tools-7.14.1-1.fc9.ppc requires libWand.so.10 vips-tools-7.14.1-1.fc9.ppc requires libMagick.so.10 xulrunner-1.9-0.60.cvs20080414.fc10.ppc requires libhunspell.so.1 xulrunner-1.9-0.60.cvs20080414.fc10.ppc64 requires libhunspell.so.1()(64bit) Broken deps for ppc64 ---------------------------------------------------------- autotrace-0.31.1-16.fc9.ppc64 requires libWand.so.10()(64bit) autotrace-0.31.1-16.fc9.ppc64 requires libMagick.so.10()(64bit) brasero-0.7.1-3.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) drawtiming-0.6.2-3.fc9.ppc64 requires libWand.so.10()(64bit) drawtiming-0.6.2-3.fc9.ppc64 requires libMagick++.so.10()(64bit) drawtiming-0.6.2-3.fc9.ppc64 requires libMagick.so.10()(64bit) dx-4.4.4-6.fc9.ppc64 requires libMagick.so.10()(64bit) dx-4.4.4-6.fc9.ppc64 requires libWand.so.10()(64bit) dx-libs-4.4.4-6.fc9.ppc64 requires libMagick.so.10()(64bit) dx-libs-4.4.4-6.fc9.ppc64 requires libWand.so.10()(64bit) empathy-0.23.1-2.fc10.ppc64 requires libedataserver-1.2.so.9()(64bit) empathy-libs-0.23.1-2.fc10.ppc64 requires libedataserver-1.2.so.9()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-python-0.0.4-3.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) gdl-0.9-0.rc1.1.fc9.ppc64 requires libMagick++.so.10()(64bit) gnome-python2-evolution-2.22.0-2.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) gnome-python2-totem-2.22.0-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) k3d-0.6.7.0-6.fc9.ppc64 requires libMagick.so.10()(64bit) k3d-0.6.7.0-6.fc9.ppc64 requires libWand.so.10()(64bit) k3d-0.6.7.0-6.fc9.ppc64 requires libMagick++.so.10()(64bit) kismet-extras-0.0.2007.10.R1-3.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) libfprint-0.0.5-3.fc9.ppc64 requires libWand.so.10()(64bit) libfprint-0.0.5-3.fc9.ppc64 requires libMagick.so.10()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot nip2-7.14.1-1.fc9.ppc64 requires libMagick.so.10()(64bit) nip2-7.14.1-1.fc9.ppc64 requires libWand.so.10()(64bit) obconf-2.0.3-1.fc9.ppc64 requires libobparser.so.16()(64bit) obconf-2.0.3-1.fc9.ppc64 requires libobrender.so.16()(64bit) 1:openoffice.org-presentation-minimizer-3.0.0-0.0.12.1.fc10.ppc64 requires openoffice.org-base-impress = 1:3.0.0-0.0.12.1.fc10 1:openoffice.org-presenter-screen-3.0.0-0.0.12.1.fc10.ppc64 requires openoffice.org-base-impress = 1:3.0.0-0.0.12.1.fc10 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 php-magickwand-1.0.7-1.fc10.ppc64 requires libWand.so.10()(64bit) php-magickwand-1.0.7-1.fc10.ppc64 requires libMagick.so.10()(64bit) poker3d-1.1.36-9.fc9.ppc64 requires libosgGA.so.25()(64bit) poker3d-1.1.36-9.fc9.ppc64 requires libosgFX.so.25()(64bit) poker3d-1.1.36-9.fc9.ppc64 requires libosgUtil.so.25()(64bit) poker3d-1.1.36-9.fc9.ppc64 requires libOpenThreads.so.9()(64bit) poker3d-1.1.36-9.fc9.ppc64 requires libosgParticle.so.25()(64bit) poker3d-1.1.36-9.fc9.ppc64 requires libosgText.so.25()(64bit) poker3d-1.1.36-9.fc9.ppc64 requires libosgSim.so.25()(64bit) poker3d-1.1.36-9.fc9.ppc64 requires libosgManipulator.so.25()(64bit) poker3d-1.1.36-9.fc9.ppc64 requires libosg.so.25()(64bit) poker3d-1.1.36-9.fc9.ppc64 requires libosgTerrain.so.25()(64bit) poker3d-1.1.36-9.fc9.ppc64 requires libosgDB.so.25()(64bit) poker3d-1.1.36-9.fc9.ppc64 requires libosgViewer.so.25()(64bit) ppc64-utils-0.14-2.fc9.ppc64 requires yaboot psiconv-0.9.8-1.fc8.ppc64 requires libWand.so.10()(64bit) psiconv-0.9.8-1.fc8.ppc64 requires libMagick.so.10()(64bit) q-7.10-3.fc9.ppc64 requires libMagick.so.10()(64bit) qgis-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) rhythmbox-0.11.5-9.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) sunbird-0.8-3.fc9.ppc64 requires libhunspell.so.1()(64bit) thunderbird-lightning-0.8-3.fc9.ppc64 requires libhunspell.so.1()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibsg.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibul.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibsm.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibssgaux.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibssg.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibsl.so.1.8.4()(64bit) totem-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.ppc64 requires libtotem-plparser-mini.so.10()(64bit) totem-nautilus-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) vips-7.14.1-1.fc9.ppc64 requires libMagick.so.10()(64bit) vips-7.14.1-1.fc9.ppc64 requires libWand.so.10()(64bit) vips-python-7.14.1-1.fc9.ppc64 requires libMagick.so.10()(64bit) vips-python-7.14.1-1.fc9.ppc64 requires libWand.so.10()(64bit) vips-tools-7.14.1-1.fc9.ppc64 requires libMagick.so.10()(64bit) vips-tools-7.14.1-1.fc9.ppc64 requires libWand.so.10()(64bit) xulrunner-1.9-0.60.cvs20080414.fc10.ppc64 requires libhunspell.so.1()(64bit) From martin.sourada at gmail.com Fri May 16 11:31:18 2008 From: martin.sourada at gmail.com (Martin Sourada) Date: Fri, 16 May 2008 13:31:18 +0200 Subject: [Nodoka Notify Theme] Looking for Reviewer, Feedback Message-ID: <1210937478.3091.14.camel@pc-notebook> Hi, I've submitted about a month long ago a review request [1] for the first version of the notification-daemon-engine-nodoka [2] and I am looking for someone to review it. It should be pretty straightforward, I am also upstream for it, but I am not aware of any other standalone notification daemon engines/themes, so some feedback and suggestions for improvements would be welcome as well :) I'd be happy to review some other package in return. Thanks in advance, Martin [1] https://bugzilla.redhat.com/show_bug.cgi?id=443303 [2] https://fedorahosted.org/nodoka/ PS: I'll be again online today at the evening (probably since 17.00 UTC) and most likely you should be able to catch me (msourada) on #fedora-art if you have any questions. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From dr.diesel at gmail.com Fri May 16 12:03:03 2008 From: dr.diesel at gmail.com (Dr. Diesel) Date: Fri, 16 May 2008 07:03:03 -0500 Subject: Anyone else with hard freezes? In-Reply-To: <20080515220101.GA8240@devserv.devel.redhat.com> References: <80d7e4090805081625m111b7955v2c96d864275334b2@mail.gmail.com> <2a28d2ab0805090336j78fe2772q1df6283e3c5d38cf@mail.gmail.com> <1210398432.17530.0.camel@optimus> <2a28d2ab0805130448s2b3e8c8aw5e526bd04949d60a@mail.gmail.com> <2a28d2ab0805131341x6d4d6332nd89e1252839f3866@mail.gmail.com> <2a28d2ab0805140713h542598d6y5c010885dac62687@mail.gmail.com> <482AF52D.1080509@poolshark.org> <2a28d2ab0805141459j22db5edcmb858afd627ea5d01@mail.gmail.com> <2a28d2ab0805151433m1b323ecak47a256b148cb982f@mail.gmail.com> <20080515220101.GA8240@devserv.devel.redhat.com> Message-ID: <2a28d2ab0805160503j4c841d5fh67a9e493a7c938ad@mail.gmail.com> On Thu, May 15, 2008 at 5:01 PM, Alan Cox wrote: > On Thu, May 15, 2008 at 05:33:02PM -0400, Dr. Diesel wrote: >> And more! >> >> ISO 9660 Extensions: Microsoft Joliet Level 3 >> ISO 9660 Extensions: RRIP_1991A >> mtrr: no MTRR for d0000000,ff00000 found >> console-kit-dae[2420]: segfault at 8 ip 3c67e2a699 sp 4100fff0 error 4 >> in libglib-2.0.so.0.1600.3[3c67e00000+de000] >> mtrr: base(0xd0000000) is not aligned on a size(0xff00000) boundary > > Out of curiosity what does memtest86 think of the box. A mix of random memory > and disk corruptions is a good candidate for suspecting RAM (although it's > certainly not conclusive and it could be an FC9 triggered bug) That figures! I ran memtest86 and folding for 12+ hours when the freezing first started, no errors. I re-run it last night at your request and get an error! Only one, at the top, 2049meg, ran it several times, all that the same place. Probably why I only see the freezes after a few days. I'll report back if it makes a week or so with no issues. Thanks to all. -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org From j.w.r.degoede at hhs.nl Fri May 16 12:14:03 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 16 May 2008 14:14:03 +0200 Subject: Review swapsies In-Reply-To: <20080516074600.GA3092@amd.home.annexia.org> References: <482C5016.6000901@hhs.nl> <20080516074600.GA3092@amd.home.annexia.org> Message-ID: <482D7A8B.9070708@hhs.nl> Richard W.M. Jones wrote: > On Thu, May 15, 2008 at 05:00:38PM +0200, Hans de Goede wrote: >> coda - Coda distributed file system - >> https://bugzilla.redhat.com/show_bug.cgi?id=446653 > > I'll take a look at this one. > Thanks! Regards, Hans From aaronh at garden.org Fri May 16 14:24:05 2008 From: aaronh at garden.org (Aaron S. Hawley) Date: Fri, 16 May 2008 10:24:05 -0400 Subject: Bodhi documentation for new packages In-Reply-To: <20080506224247.GA3372@x300> References: <481F5F85.7080203@garden.org> <20080506224247.GA3372@x300> Message-ID: <482D9905.70000@garden.org> [Please, Cc me replies, thanks.] Luke Macken wrote: > On Mon, May 05, 2008 at 03:27:01PM -0400, Aaron S. Hawley wrote: >> >> >> The directions for joining Fedora as a package maintainer[1] are really >> great. Unfortunately, they trail off at the end when it comes to important >> tasks of making the package live using the Bodhi system, section "Request >> updates to released Fedoras for your new package". I ran into this >> roadblock last month, and it hasn't improved since. >> >> As a new maintainer, I know very little about the updates infrastructure of >> Fedora, which I predict is assumed knowledge about using Bodhi. This is >> probably unfair to new maintainers. Here's my proposal for what this >> section should say. It is also what I did, so I'm sure it needs >> correction, and let me know so I can get my new package (gnue-common) live. >> Thanks for Fedora, /a > > Thanks for taking the time to give feedback and help improve our documentation. > I completely agree that the updates/bodhi docs need some work. Come F9, > I hope to have a lot of new bodhi features and changes to existing > workflow deployed, so I'll be tweaking the documentation a lot then. > >> -- BEGIN -- >> >> The first field asks for the name of the "Package". This will feature a >> name completion system, but is currently broken. It uses the tag used in >> Fedora CVS and the Koji build system, e.g. >> --.fc9. > > The build completion is no longer broken. It doesn't not query by tag > (yet, at least), it simply offers all builds for the given package. > >> For new packages, choose "enhancement" as the "type" of update. > > Correct, for now. Spot and I discussed this yesterday and we thought it > would probably be a good idea to add another type of update specifically > for new packages. This would allow tools like PackageKit to say "Hey, > check out the newest packages in Fedora that you could possibly install!" > >> Keep the "Request" as "testing". > > It's probably best to leave this up to the developer pushing the update. > I originally made bodhi force packages to go through testing first, but > many people complained and had their reasons for wanting pushing directly > to stable. > >> There are no bugs that are related to any new package, so leave the "Bugs" >> field blank. > > New packages could possibly add their Review Request bug to the update, > which will have bodhi automatically close it when it gets pushed. > >> For new packages, add a copy of the package's description in the "Notes" >> section so end users will know what it is.[2] > > This sounds fine. > > Cheers, > luke Luke, I had a chance to rewrite the instructions for adding new packages with Bodhi using your response. I can throw them on the Wiki if you like. --BEGIN-- The first field asks for the name of the "Package". This field will auto-complete the package name found in the Koji build system, e.g. --.fc9. If completion doesn't work, just enter the package build name yourself. For new packages, choose "enhancement" as the "type" of update. Put the "Request" as "testing" if you want to put the package through testing first, see [:QA: Fedora Quality Assurance]. Put "stable" if you want to push the package directly to stable. There are no bugs that are related to any new package, so leave the "Bugs" field blank. In the future, the bug number for the Review Request bug might be entered here for Bodhi to automatically close when it gets pushed to the request update status. For new packages, add a copy of the package's description in the "Notes" section so end users will know what the package is. --END-- From katzj at redhat.com Fri May 16 14:35:11 2008 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 16 May 2008 10:35:11 -0400 Subject: Using LiveUSB-Creator to do Wubi-like installation In-Reply-To: References: Message-ID: <1210948511.32711.12.camel@aglarond.local> On Fri, 2008-05-16 at 12:52 +0800, Izhar Firdaus wrote: > Looking at the concept of Fedora LiveUSB (disk image on existing disk, > overlay image , etc) ... shouldn't this be possible? In theory you can do it. It's not going to be as nice, though -- the overlay image is implemented using dm-snapshot which won't be incredibly efficient with space as you go through and do updates Jeremy From jason.corley at gmail.com Fri May 16 16:52:40 2008 From: jason.corley at gmail.com (Jason Corley) Date: Fri, 16 May 2008 12:52:40 -0400 Subject: Summary of the 2008-04-08 Packaging Committee meeting Message-ID: <3118d8de0805160952n673df32clfe697b2aa65f4de4@mail.gmail.com> Callum Lerwick wrote: > Overlapping repos are fundamentally broken, period. We've had long flamewars in the past about how ATrpms freely > replaces Fedora packages making an unsupportable mess. Why are we allowing JPackage to pull the same crap? 1) JPackage predates Fedora and it's predecessor in interest fedora.us. 2) The packages that are in question come from JPackage and were imported into Fedora (hence the jpp in version string). 3) Most of the JPackage repository is contained in generic, which has a goal of being the same set of packages for all distributions we support. Only JNI code (or similar) is in the distribution specific repositories, so removal of packages that conflict with Fedora from the generic repo harms our user base that is not on Fedora. 4) JPackage does not support Fedora exclusively (nor do we intend to), we support Mandriva, OpenSuSE, etc. 5) JPackage is not beholden to the Fedora project in any way, so you aren't allowing anything. We are an OSS project, just like Fedora is, except we focus on something different than an entire OS. Jason From jkeating at redhat.com Fri May 16 17:15:42 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 16 May 2008 13:15:42 -0400 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <3118d8de0805160952n673df32clfe697b2aa65f4de4@mail.gmail.com> References: <3118d8de0805160952n673df32clfe697b2aa65f4de4@mail.gmail.com> Message-ID: <1210958142.4060.28.camel@localhost.localdomain> On Fri, 2008-05-16 at 12:52 -0400, Jason Corley wrote: > 1) JPackage predates Fedora and it's predecessor in interest > fedora.us. > 2) The packages that are in question come from JPackage and were > imported into Fedora (hence the jpp in version string). > 3) Most of the JPackage repository is contained in generic, which has > a goal of being the same set of packages for all distributions we > support. Only JNI code (or similar) is in the distribution specific > repositories, so removal of packages that conflict with Fedora from > the generic repo harms our user base that is not on Fedora. > 4) JPackage does not support Fedora exclusively (nor do we intend to), > we support Mandriva, OpenSuSE, etc. > 5) JPackage is not beholden to the Fedora project in any way, so you > aren't allowing anything. We are an OSS project, just like Fedora is, > except we focus on something different than an entire OS. None of what Jason says is incorrect. We can't possibly dictate what jpackage does. All we can do is figure out the best way to work with jpackage and our own user base. My vision is an infrastructure set that allows Fedora contributors to easily push/pull content from jpackage infrastructure and vice versa so that having the full jpackage set in Fedora is a possibility and getting things that are submitted purely to Fedora over into jpackage easily as well. The fact that we're arguing over a few characters in a release string instead of something far more fundamental is probably a good thing. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jspaleta at gmail.com Fri May 16 17:29:20 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 16 May 2008 09:29:20 -0800 Subject: I have a big mouth... Message-ID: <604aa7910805161029i1573ca51v11c144007c0254f3@mail.gmail.com> http://www.informationweek.com/blog/main/archives/2008/05/hats_off_for_fe.html First comment in the comment section. Since i love flashing my board creds as much as possible. I want to make sure everyone else is aware of my attempts at sullying the Fedora Board's reputation. -jef From limb at jcomserv.net Fri May 16 17:36:50 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 16 May 2008 12:36:50 -0500 (CDT) Subject: I have a big mouth... In-Reply-To: <604aa7910805161029i1573ca51v11c144007c0254f3@mail.gmail.com> References: <604aa7910805161029i1573ca51v11c144007c0254f3@mail.gmail.com> Message-ID: <3230.198.175.55.5.1210959410.squirrel@mail.jcomserv.net> > http://www.informationweek.com/blog/main/archives/2008/05/hats_off_for_fe.html > > First comment in the comment section. Since i love flashing my board > creds as much as possible. I want to make sure everyone else is aware > of my attempts at sullying the Fedora Board's reputation. +5 Insightful. And Frist Psot to boot! :) > -jef > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From lesmikesell at gmail.com Fri May 16 17:59:29 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 16 May 2008 12:59:29 -0500 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <1218b5bc0805151603m274cc5e9s873e078cabc03762@mail.gmail.com> References: <482B4F5B.6040005@fedoraproject.org> <482B7748.4010709@gmail.com> <482B85D6.3020603@fedoraproject.org> <482B97A2.9080803@gmail.com> <482BB0C8.6050205@gmail.com> <482BB329.7080708@fedoraproject.org> <482BC97A.3010602@gmail.com> <1218b5bc0805151240w581841d7md1598f41065ede90@mail.gmail.com> <482CA5D9.6060603@gmail.com> <1218b5bc0805151603m274cc5e9s873e078cabc03762@mail.gmail.com> Message-ID: <482DCB81.2000604@gmail.com> Callum Lerwick wrote: > > Overlapping repos are fundamentally broken, period. > > > Then why create overlap? > > > Because moving things into Fedora is a good thing for Fedora. I've never considered being tied to a single provider to be good for anyone. And certainly not when that provider imposes policies that fragment and can only deliver parts of what would otherwise be easily available elsewhere. > Look, I'm not going to waste my time trying to convince you of anything > as you've established yourself as quite the Ferrous Cranius: > > http://redwing.hutman.net/~mreed/warriorshtm/ferouscranus.htm Being 'right' isn't quite the point here. It's more a question of whether fedora can ever be a reasonable platform for someone who wants to install items that don't come from the fedora repository and almost certainly never will. -- Les Mikesell lesmikesell at gmail.com From surenkarapetyan at gmail.com Fri May 16 18:00:50 2008 From: surenkarapetyan at gmail.com (Suren Karapetyan) Date: Fri, 16 May 2008 23:00:50 +0500 Subject: I have a big mouth... In-Reply-To: <604aa7910805161029i1573ca51v11c144007c0254f3@mail.gmail.com> References: <604aa7910805161029i1573ca51v11c144007c0254f3@mail.gmail.com> Message-ID: <482DCBD2.2070205@gmail.com> Jeff Spaleta wrote: > http://www.informationweek.com/blog/main/archives/2008/05/hats_off_for_fe.html > > First comment in the comment section. Since i love flashing my board > creds as much as possible. I want to make sure everyone else is aware > of my attempts at sullying the Fedora Board's reputation. > > -jef > GREAT!!! > But what really upsets me, is the apparent reality that derived > distributions based on Debian take Debian completely and utterly for > granted. That has to stop. Liked this part the most. Giving back is one of the main principles which drive FOSS. A distro which is based on another one SHOULD give the work it does back to the one it is based on. A distro which uses a FOSS program SHOULD give back the patches it creates to upstream. If a distro manages to translate KDE it SHOULD commit the translations upstream. Very close relationships with upstream is one of the main things which makes me use Fedora (well at thirst it was bleeding edge software, but it's just a result of following upstream closely). And that's the main problem I have with FreeBSD. I don't like the concept of a "base" packages, which have been forked years ago. And also I don't like the idea of writing "our own grep", "our own find", "our own date", ... That's the way I thought when I was 12. I did't like using "other's" software: I wanted to have "my own". That's the way Microsoft did with OOXML. They did't want to use "other's" standards, they wanted to have their own "standard". And even more... They didn't want to use "other's" standard for storing dates, they wanted to have their own "standard". PS: The last part seems to be off-topic :) From mattdm at mattdm.org Fri May 16 18:53:20 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 16 May 2008 14:53:20 -0400 Subject: Flash on rawhide In-Reply-To: <2iaof5xq9c.ln2@ppp1053.in.ipex.cz> References: <1210086745.2716.6.camel@scrappy.miketc.com> <20080506152222.GA21258@nostromo.devel.redhat.com> <1210087782.2716.8.camel@scrappy.miketc.com> <20080508150650.GA18366@jadzia.bu.edu> <2iaof5xq9c.ln2@ppp1053.in.ipex.cz> Message-ID: <20080516185320.GA15490@jadzia.bu.edu> On Tue, May 13, 2008 at 01:27:30PM +0200, Matej Cepl wrote: > So, you have installed something like this? > > [matej at hubmaier ~]$ rpm -qa firefox\* nsplugin\* \*flash\* | sort > firefox-debuginfo-3.0-0.60.beta5.fc9.x86_64 > firefox-3.0-0.60.beta5.fc9.x86_64 > flash-plugin-9.0.124.0-release.i386 > libflashsupport-000-0.5.svn20070904.i386 > libflashsupport-000-0.5.svn20070904.x86_64 > nspluginwrapper-debuginfo-0.9.91.5-28.fc9.i386 > nspluginwrapper-debuginfo-0.9.91.5-28.fc9.x86_64 > nspluginwrapper-0.9.91.5-28.fc9.i386 > nspluginwrapper-0.9.91.5-28.fc9.x86_64 > [matej at hubmaier ~]$ Right, sans the debuginfo package. > no swfdec-mozilla, you have restarted firefox and you cannot play > http://www.youtube.com/watch?v=NkOuLZ2zcY0&feature=related It would play, just at hyperspeed. Solution was to *remove* the i386 libflashsupport. That is, I now have: $ rpm -qa firefox\* nsplugin\* \*flash\* | sort firefox-3.0-0.60.beta5.fc9.x86_64 flash-plugin-9.0.124.0-release.i386 libflashsupport-000-0.5.svn20070904.x86_64 nspluginwrapper-0.9.91.5-27.fc9.i386 nspluginwrapper-0.9.91.5-27.fc9.x86_64 and everything plays as normal. On my other test machine (F9, not rawhide), though, I had that, got no sound, and added the i386 libflashsupport and now it works fine. *shrug* -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From eparis at redhat.com Fri May 16 19:19:09 2008 From: eparis at redhat.com (Eric Paris) Date: Fri, 16 May 2008 15:19:09 -0400 Subject: livecd-creator and selinux, status at the end of week 1 Message-ID: <1210965549.2717.23.camel@localhost.localdomain> I've spent pretty much all week flailing around try to get livecd-creator working with selinux enforcing with F10 as both the host and the image. Next week begins the journey of working on making old composes work on F10. Where do I stand? Well, it seems to work! I booted an image and logged in. Changes I've made so far (doesn't look like a whole lot for basically a week of work....) policycoreutils got some updates to allow users to be created in the chroot (already built and in koji) and to make relabeling a little better. libselinux has no changes with my current approach. I do not want rpm running inside the chroot to transition to rpm_t, nor do I want scriptlets to run as rpm_script_t as then those scriptlets can cause transitions to things like depmod_t which isn't going to have permissions necessary to run with the possibly screwy labels inside the chroot. I added one rule to policy to allow hal to respond back to chroot allow hald_t unconfined_notrans_t:dbus send_msg; Create a fake /selinux inside the chroot it contains: mls -> copy from host poliyver -> copy from host enforce -> 0 load -> /dev/null This means that from the point of view of the inside of the chroot selinux is "on" but not enforcing. The not enforcing part is important because some programs (passwd for example) try to determine if selinux is going to permit something before it actually tries it. If passwd realizes that selinux is enforcing but then it doesn't have a real /selinux to make those decisions it gets mad. So I'm lieing to the chroot. Changes to livecd-creator: diff -Naupr imgcreate/creator.py imgcreate.new/creator.py --- imgcreate/creator.py 2008-05-06 12:16:08.000000000 -0400 +++ imgcreate.new/creator.py 2008-05-16 13:01:05.000000000 -0400 @@ -22,6 +22,7 @@ import stat import sys import tempfile import shutil +import selinux import yum import rpm @@ -427,7 +428,7 @@ class ImageCreator(object): self._mount_instroot(base_on) - for d in ("/dev/pts", "/etc", "/boot", "/var/log", "/var/cache/yum"): + for d in ("/dev/pts", "/etc", "/boot", "/var/log", "/var/cache/yum", "/sys", "/proc"): makedirs(self._instroot + d) cachesrc = cachedir or (self.__builddir + "/yum-cache") @@ -439,10 +440,6 @@ class ImageCreator(object): (cachesrc, "/var/cache/yum")]: self.__bindmounts.append(BindChrootMount(f, self._instroot, dest)) - # /selinux should only be mounted if selinux is enabled (enforcing or permissive) - if kickstart.selinux_enabled(self.ks): - self.__bindmounts.append(BindChrootMount("/selinux", self._instroot, None)) - # Create minimum /dev origumask = os.umask(0000) devices = [('null', 1, 3, 0666), @@ -460,6 +457,20 @@ class ImageCreator(object): os.symlink('/proc/self/fd/2', self._instroot + "/dev/stderr") os.umask(origumask) + # selinux whoo hooo + if kickstart.selinux_enabled(self.ks): + makedirs(self._instroot + "/selinux") + # this should actually create our new fake /selinux, not bind from the host, though i haven't decided how + self.__bindmounts.append(BindChrootMount("/selinux1", self._instroot, "/selinux")) + + # label the fs like it is a root before the bind mounting + cmd = "/sbin/setfiles -F -r %s %s %s" % (self._instroot, selinux.selinux_file_context_path(), self._instroot) + os.system(cmd) + # these dumb things don't get magically fixed, so make the user generic + for f in ["/proc", "/sys", "/selinux"]: + cmd = "chcon -u system_u %s" % (self._instroot + f) + os.system(cmd) + self._do_bindmounts() os.symlink("../proc/mounts", self._instroot + "/etc/mtab") diff -Naupr imgcreate/kickstart.py imgcreate.new/kickstart.py --- imgcreate/kickstart.py 2008-05-06 12:16:08.000000000 -0400 +++ imgcreate.new/kickstart.py 2008-05-15 10:10:40.000000000 -0400 @@ -372,11 +372,11 @@ class SelinuxConfig(KickstartConfig): if ksselinux.selinux == ksconstants.SELINUX_DISABLED: return - if not os.path.exists(self.path("/sbin/restorecon")): + if os.path.exists(self.path("/sbin/restorecon")): + self.call(["/sbin/restorecon", "-l", "-v", "-r", "-F", "-e", "/proc", "-e", "/sys", "-e", "/dev", "-e", "/selinux", "/"]) + else: return - self.call(["/sbin/restorecon", "-l", "-v", "-r", "/"]) - def apply(self, ksselinux): if os.path.exists(self.path("/usr/sbin/lokkit")): args = ["/usr/sbin/lokkit", "-f", "--quiet", "--nostart"] From jkeating at redhat.com Fri May 16 19:31:46 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 16 May 2008 15:31:46 -0400 Subject: livecd-creator and selinux, status at the end of week 1 In-Reply-To: <1210965549.2717.23.camel@localhost.localdomain> References: <1210965549.2717.23.camel@localhost.localdomain> Message-ID: <1210966306.4060.30.camel@localhost.localdomain> On Fri, 2008-05-16 at 15:19 -0400, Eric Paris wrote: > I've spent pretty much all week flailing around try to get > livecd-creator working with selinux enforcing with F10 as both the host > and the image. Next week begins the journey of working on making old > composes work on F10. Where do I stand? Well, it seems to work! I > booted an image and logged in. This is pretty awesome Eric, I'm glad the work is going on for this. I'll have to admit though, or biggest target right now is to be able to use RHEL5 to create F10 live images, as well as using RHEL5 to create f10 traditional install trees. For the latter, we currently /have/ to use mock so that the userland package set matches that which we're trying to compose (IE F10's yum is used, F10's anaconda is used, etc...) Let me know how we can help! -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From tjb at unh.edu Fri May 16 20:01:43 2008 From: tjb at unh.edu (Thomas J. Baker) Date: Fri, 16 May 2008 16:01:43 -0400 Subject: F9->Rawhide Help Message-ID: <1210968103.31092.30.camel@raptor.sr.unh.edu> I've just reinstalled my rawhide machine with F9 just to clear out the cruft and I'm having trouble getting back to rawhide. Aside from the tons of broken dependencies and "yum --skip-broken" not seeming to work, as soon as glibc gets updated, yum/python seems to be broken: [root at katratzi ~]# yum update yum\* Loaded plugins: refresh-packagekit Setting up Update Process Resolving Dependencies --> Running transaction check ---> Package yum-packagekit.i386 0:0.2.1-2.20080508.fc10 set to be updated --> Processing Dependency: yum-packagekit = 0.1.12-10.20080505.fc9 for package: PackageKit --> Running transaction check --> Processing Dependency: PackageKit = 0.1.12-10.20080505.fc9 for package: PackageKit-libs ---> Package PackageKit.i386 0:0.2.1-2.20080508.fc10 set to be updated --> Running transaction check ---> Package PackageKit-libs.i386 0:0.2.1-2.20080508.fc10 set to be updated --> Finished Dependency Resolution Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Updating: PackageKit i386 0.2.1-2.20080508.fc10 rawhide 395 k PackageKit-libs i386 0.2.1-2.20080508.fc10 rawhide 96 k yum-packagekit i386 0.2.1-2.20080508.fc10 rawhide 7.6 k Transaction Summary ============================================================================= Install 0 Package(s) Update 3 Package(s) Remove 0 Package(s) Total download size: 499 k Is this ok [y/N]: y Downloading Packages: *** glibc detected *** /usr/bin/python: double free or corruption (out): 0xbfcd4100 *** and hang forever here. Anyone having luck with rawhide at the moment? Thanks, tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From james at fedoraproject.com Fri May 16 20:40:46 2008 From: james at fedoraproject.com (James Antill) Date: Fri, 16 May 2008 16:40:46 -0400 Subject: F9->Rawhide Help In-Reply-To: <1210968103.31092.30.camel@raptor.sr.unh.edu> References: <1210968103.31092.30.camel@raptor.sr.unh.edu> Message-ID: <1210970446.17108.150.camel@code.and.org> On Fri, 2008-05-16 at 16:01 -0400, Thomas J. Baker wrote: > I've just reinstalled my rawhide machine with F9 just to clear out the > cruft and I'm having trouble getting back to rawhide. Aside from the > tons of broken dependencies and "yum --skip-broken" not seeming to work, > as soon as glibc gets updated, yum/python seems to be broken: > > [root at katratzi ~]# yum update yum\* > Loaded plugins: refresh-packagekit [...] > Total download size: 499 k > Is this ok [y/N]: y > Downloading Packages: > *** glibc detected *** /usr/bin/python: double free or corruption (out): 0xbfcd4100 *** > > > and hang forever here. Anyone having luck with rawhide at the moment? Known Glibc bug: 446909 -- James Antill Fedora From kevin at scrye.com Fri May 16 21:12:27 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Fri, 16 May 2008 15:12:27 -0600 Subject: F8->F9 yum upgrade notes: bluecurve lost etc. In-Reply-To: References: Message-ID: <20080516151227.5d40261d@ohm.scrye.com> On Thu, 15 May 2008 15:14:43 +0300 (EEST) pekkas at netcore.fi (Pekka Savola) wrote: > On Wed, 14 May 2008, Kevin Kofler wrote: > > Pekka Savola netcore.fi> writes: > >> - The Bluecurve theme appears to have disappeared in a strange > >> way. When you log in using an old user that had used bluecurve, > >> all windows lacked the header (w/ the buttons) on top. Changing > >> to 'Default' with Settings - Window Manager Settings fixed this, > >> and when I next looked at the settings, bluecurve had already > >> disppeared from selection. Some other user might not have realized > >> what has gone wrong. Shouldn't there be an automatic transition > >> path out if bluecurve no longer works? > > > > Is that in KDE? The KDE 4 version of the theme is called > > quarticurve-kwin-theme, it should have replaced the old > > bluecurve-kwin-theme automatically, you can set the theme in the > > options. > > This is xfce; kde is installed but not in use. Sadly, the Xfce bluecurve theme used to be included in the xfwm4 package, which was not a good idea moving ahead. ;( It's not been the default for quite some time, and has since been removed from there. The only way we could keep pulling it in would be to add a hard dependency on it, but thats not a nice thing for new installs/new users moving forward. ;( You should be able to install the '*bluecurve*' packages to get it back... kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From email.ahmedkamal at googlemail.com Fri May 16 21:54:44 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Sat, 17 May 2008 00:54:44 +0300 Subject: Fwd: Fedora 9 Sulpher: First Impression In-Reply-To: <3da3b5b40805161453n2bc70d14keab752fce5ef120c@mail.gmail.com> References: <1210852294.6072.2.camel@149-159-132-185.dhcp-bl.indiana.edu> <1210858838.20001.38.camel@victoria> <6a65d5240805150802qf15511as841404209ebaf53b@mail.gmail.com> <3da3b5b40805161453n2bc70d14keab752fce5ef120c@mail.gmail.com> Message-ID: <3da3b5b40805161454p7fa17dc6oa7113c88c89df573@mail.gmail.com> Guys, sorry, I meant that email to be at fedora-devel ---------- Forwarded message ---------- From: Ahmed Kamal Date: Sat, May 17, 2008 at 12:53 AM Subject: Re: Fedora 9 Sulpher: First Impression To: fedora-infrastructure-list at redhat.com Great work guys, F9 basically rocks. The "Fast-X" feature .. is sooo yummy :) I can't believe I lived with that ugly flicker the past decade. Also kde-4 .. soo cool, although we all agree it needs more polish. However, I am facing a perhaps higher than usual number of potential bugs! I will detail below, and you decide: - GDM has no shortcut key for "Login" button, while the "Cancel" button right beside it has the C underlined! That hurts my eyes :) - GDM does not remember the last session! So, I always need to choose kde4 - /media/windows-ntfs-drive/ is not automounted when KDE is started. So, okular starts and tries to open the pdf book I was reading, but fails! Not sure if that's a kde bug or a system one. But when I start KDE file manager, and click that directory, it mounts and opens fine! - network service not brining bridge devices up or similar (I will detail in a separate thread) - kernel not powering off my toshiba A105 S361 laptop upon shutdown! (grr .. this keeps coming and going on all 2.6 kernels) - Synaptics driver not "tapping" enabled! This remains a bug to me even though people on https://bugzilla.redhat.com/show_bug.cgi?id=437609 seem to have found a work around. Since Fedora changed the default behaviour, could we at least get a release notes section on how to activate tapping - Firefox3b5 sometimes showing solid color stripes over text, rendering it unreadable .. well, it is still in beta Other than those, F9 still rox :) Regards 2008/5/15 Ramez Hanna : been using it for a full working day now > i am impressed with the new packagekit so far > yet i don't see major changes that are apparent to the desktop user, but > what more can they ask for ;) > great work > > 2008/5/15 Paul W. Frields : > >> On Thu, 2008-05-15 at 07:51 -0400, Yu Feng wrote: >> > Everything is fine except the low quality graphics for GDM. It looks >> > like an over-compressed jpeg file. ?I'd rather to use a black screen as >> > background instead, but there is even no way to change the background >> > (yet). >> >> Very happy that you guys are trying out the distribution. However, you >> should discuss these topics on fedora-list, and not the lists intended >> for discussion of infrastructure, marketing, and translation. >> Thanks! :-) >> >> -- >> Paul W. Frields http://paul.frields.org/ >> gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 >> http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ >> irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug >> >> _______________________________________________ >> Fedora-infrastructure-list mailing list >> Fedora-infrastructure-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list >> >> > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From email.ahmedkamal at googlemail.com Fri May 16 22:02:13 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Sat, 17 May 2008 01:02:13 +0300 Subject: F9 potential service network bug? Message-ID: <3da3b5b40805161502w62f372dseca0ab6310e44447@mail.gmail.com> Hi, I have setup VirtualBox, and set up its bridged networking. The weird part is that somehow the bridge and my eth0 (sky2) were not being brought up on system start! I thought maybe it was NetworkManager weirdness, so I disabled that service. Now here is what happens: - Upon system start, I only get the following NICs: lo, vbox0 - If I immediately issue a "service network restart", I get the following NICs: eth0, vboxbr0, vbox0, lo Obviously, since nothing changed that a possible bug! Here are my relevant ifcfg files [root at magic1 network-scripts]# cat ifcfg-eth0 # Marvell Technology Group Ltd. 88E8036 PCI-E Fast Ethernet Controller DEVICE=eth0 BOOTPROTO=none HWADDR=00:a0:d1:2c:c6:08 ONBOOT=yes SEARCH="example.com" NM_CONTROLLED=no TYPE=Ethernet BRIDGE=vboxbr0 [root at magic1 network-scripts]# cat ifcfg-vboxbr0 DEVICE=vboxbr0 TYPE=Bridge BROADCAST=192.168.10.255 IPADDR=192.168.0.254 NETMASK=255.255.255.0 NETWORK=192.168.0.0 ONBOOT=yes NM_CONTROLLED=no -------------- next part -------------- An HTML attachment was scrubbed... URL: From email.ahmedkamal at googlemail.com Fri May 16 22:03:49 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Sat, 17 May 2008 01:03:49 +0300 Subject: Fedora 9 Sulpher: First Impression In-Reply-To: <3da3b5b40805161454p7fa17dc6oa7113c88c89df573@mail.gmail.com> References: <1210852294.6072.2.camel@149-159-132-185.dhcp-bl.indiana.edu> <1210858838.20001.38.camel@victoria> <6a65d5240805150802qf15511as841404209ebaf53b@mail.gmail.com> <3da3b5b40805161453n2bc70d14keab752fce5ef120c@mail.gmail.com> <3da3b5b40805161454p7fa17dc6oa7113c88c89df573@mail.gmail.com> Message-ID: <3da3b5b40805161503p486c7f6av858806ea17b4c363@mail.gmail.com> Um, let's add this one: Copy from KWrite, paste into Firefox in a Gmail compose email window, never pastes ?! On Sat, May 17, 2008 at 12:54 AM, Ahmed Kamal < email.ahmedkamal at googlemail.com> wrote: > Guys, sorry, I meant that email to be at fedora-devel > > > ---------- Forwarded message ---------- > From: Ahmed Kamal > Date: Sat, May 17, 2008 at 12:53 AM > Subject: Re: Fedora 9 Sulpher: First Impression > To: fedora-infrastructure-list at redhat.com > > > Great work guys, F9 basically rocks. The "Fast-X" feature .. is sooo yummy > :) I can't believe I lived with that ugly flicker the past decade. Also > kde-4 .. soo cool, although we all agree it needs more polish. However, I am > facing a perhaps higher than usual number of potential bugs! I will detail > below, and you decide: > > - GDM has no shortcut key for "Login" button, while the "Cancel" button > right beside it has the C underlined! That hurts my eyes :) > - GDM does not remember the last session! So, I always need to choose kde4 > - /media/windows-ntfs-drive/ is not automounted when KDE is started. So, > okular starts and tries to open the pdf book I was reading, but fails! Not > sure if that's a kde bug or a system one. But when I start KDE file manager, > and click that directory, it mounts and opens fine! > - network service not brining bridge devices up or similar (I will detail > in a separate thread) > - kernel not powering off my toshiba A105 S361 laptop upon shutdown! (grr > .. this keeps coming and going on all 2.6 kernels) > - Synaptics driver not "tapping" enabled! This remains a bug to me even > though people on https://bugzilla.redhat.com/show_bug.cgi?id=437609 seem > to have found a work around. Since Fedora changed the default behaviour, > could we at least get a release notes section on how to activate tapping > - Firefox3b5 sometimes showing solid color stripes over text, rendering it > unreadable .. well, it is still in beta > > Other than those, F9 still rox :) > Regards > > 2008/5/15 Ramez Hanna : > > been using it for a full working day now >> i am impressed with the new packagekit so far >> yet i don't see major changes that are apparent to the desktop user, but >> what more can they ask for ;) >> great work >> >> 2008/5/15 Paul W. Frields : >> >>> On Thu, 2008-05-15 at 07:51 -0400, Yu Feng wrote: >>> > Everything is fine except the low quality graphics for GDM. It looks >>> > like an over-compressed jpeg file. ?I'd rather to use a black screen as >>> > background instead, but there is even no way to change the background >>> > (yet). >>> >>> Very happy that you guys are trying out the distribution. However, you >>> should discuss these topics on fedora-list, and not the lists intended >>> for discussion of infrastructure, marketing, and translation. >>> Thanks! :-) >>> >>> -- >>> Paul W. Frields http://paul.frields.org/ >>> gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 >>> http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ >>> irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug >>> >>> _______________________________________________ >>> Fedora-infrastructure-list mailing list >>> Fedora-infrastructure-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list >>> >>> >> >> _______________________________________________ >> Fedora-infrastructure-list mailing list >> Fedora-infrastructure-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcbw at redhat.com Fri May 16 22:10:52 2008 From: dcbw at redhat.com (Dan Williams) Date: Fri, 16 May 2008 18:10:52 -0400 Subject: F9 potential service network bug? In-Reply-To: <3da3b5b40805161502w62f372dseca0ab6310e44447@mail.gmail.com> References: <3da3b5b40805161502w62f372dseca0ab6310e44447@mail.gmail.com> Message-ID: <1210975852.6805.10.camel@localhost.localdomain> On Sat, 2008-05-17 at 01:02 +0300, Ahmed Kamal wrote: > Hi, > I have setup VirtualBox, and set up its bridged networking. The weird > part is that somehow the bridge and my eth0 (sky2) were not being > brought up on system start! I thought maybe it was NetworkManager > weirdness, so I disabled that service. Now here is what happens: After you've disabled NetworkManager, you need to also: chkconfig network on to get it to start at the right runlevels. Have you done that? Dan > - Upon system start, I only get the following NICs: lo, vbox0 > - If I immediately issue a "service network restart", I get the > following NICs: eth0, vboxbr0, vbox0, lo > > Obviously, since nothing changed that a possible bug! Here are my > relevant ifcfg files > > [root at magic1 network-scripts]# cat ifcfg-eth0 > # Marvell Technology Group Ltd. 88E8036 PCI-E Fast Ethernet Controller > DEVICE=eth0 > BOOTPROTO=none > HWADDR=00:a0:d1:2c:c6:08 > ONBOOT=yes > SEARCH="example.com" > NM_CONTROLLED=no > TYPE=Ethernet > BRIDGE=vboxbr0 > [root at magic1 network-scripts]# cat ifcfg-vboxbr0 > DEVICE=vboxbr0 > TYPE=Bridge > BROADCAST=192.168.10.255 > IPADDR=192.168.0.254 > NETMASK=255.255.255.0 > NETWORK=192.168.0.0 > ONBOOT=yes > NM_CONTROLLED=no > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From email.ahmedkamal at googlemail.com Fri May 16 22:22:21 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Sat, 17 May 2008 01:22:21 +0300 Subject: F9 potential service network bug? In-Reply-To: <1210975852.6805.10.camel@localhost.localdomain> References: <3da3b5b40805161502w62f372dseca0ab6310e44447@mail.gmail.com> <1210975852.6805.10.camel@localhost.localdomain> Message-ID: <3da3b5b40805161522i2300f1cdhb1fc7b074084873f@mail.gmail.com> ick, nope. Well, thanks for the hint :) But it should really work without even disabling NM. Instead I'm getting this in the logs: messages-20080514:May 13 09:15:32 magic1 nm-system-settings: ifcfg-fedora: error: Unknown connection type 'Bridge' What else could be wrong? On Sat, May 17, 2008 at 1:10 AM, Dan Williams wrote: > On Sat, 2008-05-17 at 01:02 +0300, Ahmed Kamal wrote: > > Hi, > > I have setup VirtualBox, and set up its bridged networking. The weird > > part is that somehow the bridge and my eth0 (sky2) were not being > > brought up on system start! I thought maybe it was NetworkManager > > weirdness, so I disabled that service. Now here is what happens: > > After you've disabled NetworkManager, you need to also: > > chkconfig network on > > to get it to start at the right runlevels. Have you done that? > > Dan > > > - Upon system start, I only get the following NICs: lo, vbox0 > > - If I immediately issue a "service network restart", I get the > > following NICs: eth0, vboxbr0, vbox0, lo > > > > Obviously, since nothing changed that a possible bug! Here are my > > relevant ifcfg files > > > > [root at magic1 network-scripts]# cat ifcfg-eth0 > > # Marvell Technology Group Ltd. 88E8036 PCI-E Fast Ethernet Controller > > DEVICE=eth0 > > BOOTPROTO=none > > HWADDR=00:a0:d1:2c:c6:08 > > ONBOOT=yes > > SEARCH="example.com" > > NM_CONTROLLED=no > > TYPE=Ethernet > > BRIDGE=vboxbr0 > > [root at magic1 network-scripts]# cat ifcfg-vboxbr0 > > DEVICE=vboxbr0 > > TYPE=Bridge > > BROADCAST=192.168.10.255 > > IPADDR=192.168.0.254 > > NETMASK=255.255.255.0 > > NETWORK=192.168.0.0 > > ONBOOT=yes > > NM_CONTROLLED=no > > > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > -- > 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 jspaleta at gmail.com Fri May 16 22:27:00 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 16 May 2008 14:27:00 -0800 Subject: F9 potential service network bug? In-Reply-To: <3da3b5b40805161522i2300f1cdhb1fc7b074084873f@mail.gmail.com> References: <3da3b5b40805161502w62f372dseca0ab6310e44447@mail.gmail.com> <1210975852.6805.10.camel@localhost.localdomain> <3da3b5b40805161522i2300f1cdhb1fc7b074084873f@mail.gmail.com> Message-ID: <604aa7910805161527j6b193c6dj2af4248155d5cdaf@mail.gmail.com> 2008/5/16 Ahmed Kamal : > ick, nope. Well, thanks for the hint :) But it should really work without > even disabling NM. Instead I'm getting this in the logs: > messages-20080514:May 13 09:15:32 magic1 nm-system-settings: > ifcfg-fedora: error: Unknown connection type 'Bridge' > > What else could be wrong? NM doesn't handle all usage cases yet, which is why the legacy network stack is still available for people who need it. -jef"Rome wasn't built in a day and all that jazz"spaleta From stlwrt at gmail.com Fri May 16 22:27:23 2008 From: stlwrt at gmail.com (Pavel Shevchuk) Date: Sat, 17 May 2008 01:27:23 +0300 Subject: Fedora 9 Sulpher: First Impression In-Reply-To: <3da3b5b40805161503p486c7f6av858806ea17b4c363@mail.gmail.com> References: <1210852294.6072.2.camel@149-159-132-185.dhcp-bl.indiana.edu> <1210858838.20001.38.camel@victoria> <6a65d5240805150802qf15511as841404209ebaf53b@mail.gmail.com> <3da3b5b40805161453n2bc70d14keab752fce5ef120c@mail.gmail.com> <3da3b5b40805161454p7fa17dc6oa7113c88c89df573@mail.gmail.com> <3da3b5b40805161503p486c7f6av858806ea17b4c363@mail.gmail.com> Message-ID: If you use KDE you should switch to KDM. It will preload kdelibs making kde start a tiny bit faster, and also remembers default session. P.S. Shortcut to "login" button is "Enter" =) On 5/17/08, Ahmed Kamal wrote: > Um, let's add this one: Copy from KWrite, paste into Firefox in a Gmail > compose email window, never pastes ?! > > > On Sat, May 17, 2008 at 12:54 AM, Ahmed Kamal > wrote: > > > Guys, sorry, I meant that email to be at fedora-devel > > > > > > > > > > > > ---------- Forwarded message ---------- > > From: Ahmed Kamal > > Date: Sat, May 17, 2008 at 12:53 AM > > Subject: Re: Fedora 9 Sulpher: First Impression > > To: fedora-infrastructure-list at redhat.com > > > > > > Great work guys, F9 basically rocks. The "Fast-X" feature .. is sooo yummy > :) I can't believe I lived with that ugly flicker the past decade. Also > kde-4 .. soo cool, although we all agree it needs more polish. However, I am > facing a perhaps higher than usual number of potential bugs! I will detail > below, and you decide: > > > > - GDM has no shortcut key for "Login" button, while the "Cancel" button > right beside it has the C underlined! That hurts my eyes :) > > - GDM does not remember the last session! So, I always need to choose kde4 > > - /media/windows-ntfs-drive/ is not automounted when KDE is started. So, > okular starts and tries to open the pdf book I was reading, but fails! Not > sure if that's a kde bug or a system one. But when I start KDE file manager, > and click that directory, it mounts and opens fine! > > - network service not brining bridge devices up or similar (I will detail > in a separate thread) > > - kernel not powering off my toshiba A105 S361 laptop upon shutdown! (grr > .. this keeps coming and going on all 2.6 kernels) > > - Synaptics driver not "tapping" enabled! This remains a bug to me even > though people on > https://bugzilla.redhat.com/show_bug.cgi?id=437609 seem to > have found a work around. Since Fedora changed the default behaviour, could > we at least get a release notes section on how to activate tapping > > - Firefox3b5 sometimes showing solid color stripes over text, rendering it > unreadable .. well, it is still in beta > > > > Other than those, F9 still rox :) > > Regards > > > > > > 2008/5/15 Ramez Hanna : > > > > > > > > > > > been using it for a full working day now > > > i am impressed with the new packagekit so far > > > yet i don't see major changes that are apparent to the desktop user, but > what more can they ask for ;) > > > great work > > > > > > > > > 2008/5/15 Paul W. Frields : > > > > > > > > > > > > > > > > > > > On Thu, 2008-05-15 at 07:51 -0400, Yu Feng wrote: > > > > > Everything is fine except the low quality graphics for GDM. It looks > > > > > like an over-compressed jpeg file. ?I'd rather to use a black screen > as > > > > > background instead, but there is even no way to change the > background > > > > > (yet). > > > > > > > > Very happy that you guys are trying out the distribution. However, > you > > > > should discuss these topics on fedora-list, and not the lists intended > > > > for discussion of infrastructure, marketing, and translation. > > > > Thanks! :-) > > > > > > > > -- > > > > Paul W. Frields > http://paul.frields.org/ > > > > gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 > > > > http://redhat.com/ - - - - > http://pfrields.fedorapeople.org/ > > > > irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug > > > > > > > > > > > > _______________________________________________ > > > > Fedora-infrastructure-list mailing list > > > > Fedora-infrastructure-list at redhat.com > > > > > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > > > > > > > > > > > > > > > > > _______________________________________________ > > > Fedora-infrastructure-list mailing list > > > Fedora-infrastructure-list at redhat.com > > > > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > > > > > > > > > > > > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- http://scwlab.com From email.ahmedkamal at googlemail.com Fri May 16 22:32:31 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Sat, 17 May 2008 01:32:31 +0300 Subject: F9 potential service network bug? In-Reply-To: <604aa7910805161527j6b193c6dj2af4248155d5cdaf@mail.gmail.com> References: <3da3b5b40805161502w62f372dseca0ab6310e44447@mail.gmail.com> <1210975852.6805.10.camel@localhost.localdomain> <3da3b5b40805161522i2300f1cdhb1fc7b074084873f@mail.gmail.com> <604aa7910805161527j6b193c6dj2af4248155d5cdaf@mail.gmail.com> Message-ID: <3da3b5b40805161532yec3842l608e2ac267f661af@mail.gmail.com> Would it hurt then to have left the legacy network on by default ? Or at least spew an orange warning when detecting legacy config files that would require legacy network to run On Sat, May 17, 2008 at 1:27 AM, Jeff Spaleta wrote: > 2008/5/16 Ahmed Kamal : > > ick, nope. Well, thanks for the hint :) But it should really work without > > even disabling NM. Instead I'm getting this in the logs: > > messages-20080514:May 13 09:15:32 magic1 nm-system-settings: > > ifcfg-fedora: error: Unknown connection type 'Bridge' > > > > What else could be wrong? > > NM doesn't handle all usage cases yet, which is why the legacy network > stack is still available for people who need it. > > -jef"Rome wasn't built in a day and all that jazz"spaleta > > -- > 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 orion at cora.nwra.com Fri May 16 22:34:24 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 16 May 2008 16:34:24 -0600 Subject: Fedora 9 Sulpher: First Impression In-Reply-To: <3da3b5b40805161503p486c7f6av858806ea17b4c363@mail.gmail.com> References: <1210852294.6072.2.camel@149-159-132-185.dhcp-bl.indiana.edu> <1210858838.20001.38.camel@victoria> <6a65d5240805150802qf15511as841404209ebaf53b@mail.gmail.com> <3da3b5b40805161453n2bc70d14keab752fce5ef120c@mail.gmail.com> <3da3b5b40805161454p7fa17dc6oa7113c88c89df573@mail.gmail.com> <3da3b5b40805161503p486c7f6av858806ea17b4c363@mail.gmail.com> Message-ID: <482E0BF0.4000303@cora.nwra.com> Ahmed Kamal wrote: > Um, let's add this one: Copy from KWrite, paste into Firefox in a Gmail compose > email window, never pastes ?! Perhaps related to https://bugzilla.redhat.com/show_bug.cgi?id=441879 ? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From jspaleta at gmail.com Fri May 16 22:36:04 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 16 May 2008 14:36:04 -0800 Subject: F9 potential service network bug? In-Reply-To: <3da3b5b40805161532yec3842l608e2ac267f661af@mail.gmail.com> References: <3da3b5b40805161502w62f372dseca0ab6310e44447@mail.gmail.com> <1210975852.6805.10.camel@localhost.localdomain> <3da3b5b40805161522i2300f1cdhb1fc7b074084873f@mail.gmail.com> <604aa7910805161527j6b193c6dj2af4248155d5cdaf@mail.gmail.com> <3da3b5b40805161532yec3842l608e2ac267f661af@mail.gmail.com> Message-ID: <604aa7910805161536p1055ac4g2a134d9eb4d170aa@mail.gmail.com> 2008/5/16 Ahmed Kamal : > Would it hurt then to have left the legacy network on by default ? Or at > least spew an orange warning when detecting legacy config files that would > require legacy network to run Yes it definitely would have hurt to leave it as default. But having NM tell in the UI that it hit on a legacy configuration it's confused by..instead of just logging it..would be pretty useful. -jef From email.ahmedkamal at googlemail.com Fri May 16 22:53:54 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Sat, 17 May 2008 01:53:54 +0300 Subject: kernel mode-setting not starting secondary X (bug?) Message-ID: <3da3b5b40805161553v123a84c2r596e95ac9c394aca@mail.gmail.com> Hi, I am also using kernel mode setting (love it), but when I have the standard X running, if I switch to a VT, and try to start another X using: startx -- :2 it fails with: xauth: creating new authority file /root/.serverauth.15640 X.Org X Server 1.4.99 .901 (1.5.0 RC 1) Release Date: 5 September 2007 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.18-53.1.14.el5xen i686 Current Operating System: Linux magic1.magic.com 2.6.25-14.fc9.i686 #1 SMP Thu May 1 06:28:41 EDT 2008 i686 Build Date: 06 May 2008 03:35:07PM Build ID: xorg-x11-server 1.4.99.901-29.20080415.fc9 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.2.log", Time: Sat May 17 01:47:22 2008 (==) Using config file: "/etc/X11/xorg.conf" (EE) [drm] DRM was busy with another master. (EE) intel(0): [dri] DRIGetVersion failed to open the DRM [dri] Disabling DRI. (EE) intel(0): Kernel modesetting setup failed (EE) Screen(s) found, but none have a usable configuration. Fatal server error: no screens found giving up. xinit: Connection refused (errno 111): unable to connect to X server xinit: No such process (errno 3): Server error. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at xelerance.com Fri May 16 23:32:53 2008 From: paul at xelerance.com (Paul Wouters) Date: Fri, 16 May 2008 19:32:53 -0400 (EDT) Subject: F9 potential service network bug? In-Reply-To: <604aa7910805161527j6b193c6dj2af4248155d5cdaf@mail.gmail.com> References: <3da3b5b40805161502w62f372dseca0ab6310e44447@mail.gmail.com> <1210975852.6805.10.camel@localhost.localdomain> <3da3b5b40805161522i2300f1cdhb1fc7b074084873f@mail.gmail.com> <604aa7910805161527j6b193c6dj2af4248155d5cdaf@mail.gmail.com> Message-ID: On Fri, 16 May 2008, Jeff Spaleta wrote: > NM doesn't handle all usage cases yet, which is why the legacy network > stack is still available for people who need it. I'd have figured BOOTPROTO=static would not be that hard to support :P > -jef"Rome wasn't built in a day and all that jazz"spaleta To be honest, NM/avahi combo was not tested well enough. Even a stock install with selecting "static" via anaconda ended up not working. Paul From jspaleta at gmail.com Fri May 16 23:31:13 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 16 May 2008 15:31:13 -0800 Subject: F9 potential service network bug? In-Reply-To: References: <3da3b5b40805161502w62f372dseca0ab6310e44447@mail.gmail.com> <1210975852.6805.10.camel@localhost.localdomain> <3da3b5b40805161522i2300f1cdhb1fc7b074084873f@mail.gmail.com> <604aa7910805161527j6b193c6dj2af4248155d5cdaf@mail.gmail.com> Message-ID: <604aa7910805161631k1721d0a1sb1dcc6ff0f0a34a8@mail.gmail.com> On Fri, May 16, 2008 at 3:32 PM, Paul Wouters wrote: > To be honest, NM/avahi combo was not tested well enough. Even a stock > install with selecting "static" via anaconda ended up not working. I'll make an extra special effort to invite static users to participate in testing in the upcoming release cycle. -jef From jkeating at redhat.com Fri May 16 23:40:06 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 16 May 2008 19:40:06 -0400 Subject: F9 potential service network bug? In-Reply-To: References: <3da3b5b40805161502w62f372dseca0ab6310e44447@mail.gmail.com> <1210975852.6805.10.camel@localhost.localdomain> <3da3b5b40805161522i2300f1cdhb1fc7b074084873f@mail.gmail.com> <604aa7910805161527j6b193c6dj2af4248155d5cdaf@mail.gmail.com> Message-ID: <1210981206.4060.44.camel@localhost.localdomain> On Fri, 2008-05-16 at 19:32 -0400, Paul Wouters wrote: > I'd have figured BOOTPROTO=static would not be that hard to support :P Static works. Bridging is what's not supported right now. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From dcbw at redhat.com Sat May 17 01:57:09 2008 From: dcbw at redhat.com (Dan Williams) Date: Fri, 16 May 2008 21:57:09 -0400 Subject: F9 potential service network bug? In-Reply-To: References: <3da3b5b40805161502w62f372dseca0ab6310e44447@mail.gmail.com> <1210975852.6805.10.camel@localhost.localdomain> <3da3b5b40805161522i2300f1cdhb1fc7b074084873f@mail.gmail.com> <604aa7910805161527j6b193c6dj2af4248155d5cdaf@mail.gmail.com> Message-ID: <1210989429.24740.14.camel@localhost.localdomain> On Fri, 2008-05-16 at 19:32 -0400, Paul Wouters wrote: > On Fri, 16 May 2008, Jeff Spaleta wrote: > > > NM doesn't handle all usage cases yet, which is why the legacy network > > stack is still available for people who need it. > > I'd have figured BOOTPROTO=static would not be that hard to support :P > > > -jef"Rome wasn't built in a day and all that jazz"spaleta > > To be honest, NM/avahi combo was not tested well enough. Even a stock > install with selecting "static" via anaconda ended up not working. I've personally tested static IP addressing with static DNS servers with anaconda on the F9 release LiveCD, and it worked fine for me through multiple tests. What's not working for you? Can you attach the ifcfg files anaconda generated right after you installed? Dan From seg at haxxed.com Sat May 17 02:36:28 2008 From: seg at haxxed.com (Callum Lerwick) Date: Fri, 16 May 2008 21:36:28 -0500 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <1210958142.4060.28.camel@localhost.localdomain> References: <3118d8de0805160952n673df32clfe697b2aa65f4de4@mail.gmail.com> <1210958142.4060.28.camel@localhost.localdomain> Message-ID: <1218b5bc0805161936y3497c945i6727afc7cd40dd45@mail.gmail.com> 2008/5/16 Jesse Keating : > The fact that we're arguing over a few characters in a release string > instead of something far more fundamental is probably a good thing. That's not what I'm arguing about at all. The release string is a red herring. The real problem here is overlapping repos. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lmacken at redhat.com Sat May 17 02:37:44 2008 From: lmacken at redhat.com (Luke Macken) Date: Fri, 16 May 2008 22:37:44 -0400 Subject: Using LiveUSB-Creator to do Wubi-like installation In-Reply-To: References: Message-ID: <20080517023744.GA4184@x300> On Fri, May 16, 2008 at 12:52:27PM +0800, Izhar Firdaus wrote: > I tried playing around on VM just now, but the lmacken > liveusb-creator.exe doesnt allow selecting drive C .. (maybe will hack > around later, though i'm still doubting whether i'm capable or not) I plan on adding a [non-obvious] option to force the use of a given drive. luke From kaboom at oobleck.net Sat May 17 03:26:14 2008 From: kaboom at oobleck.net (Chris Ricker) Date: Fri, 16 May 2008 23:26:14 -0400 (EDT) Subject: F9 potential service network bug? In-Reply-To: <1210989429.24740.14.camel@localhost.localdomain> References: <3da3b5b40805161502w62f372dseca0ab6310e44447@mail.gmail.com> <1210975852.6805.10.camel@localhost.localdomain> <3da3b5b40805161522i2300f1cdhb1fc7b074084873f@mail.gmail.com> <604aa7910805161527j6b193c6dj2af4248155d5cdaf@mail.gmail.com> <1210989429.24740.14.camel@localhost.localdomain> Message-ID: On Fri, 16 May 2008, Dan Williams wrote: > I've personally tested static IP addressing with static DNS servers with > anaconda on the F9 release LiveCD, and it worked fine for me through > multiple tests. What's not working for you? Can you attach the ifcfg > files anaconda generated right after you installed? Multiple people (including me) have put non-working examples in the mother of all NM bugzilla tickets ;-) Have you tried non-LiveCD? later, chris From paul at xelerance.com Sat May 17 03:47:48 2008 From: paul at xelerance.com (Paul Wouters) Date: Fri, 16 May 2008 23:47:48 -0400 (EDT) Subject: F9 potential service network bug? In-Reply-To: References: <3da3b5b40805161502w62f372dseca0ab6310e44447@mail.gmail.com> <1210975852.6805.10.camel@localhost.localdomain> <3da3b5b40805161522i2300f1cdhb1fc7b074084873f@mail.gmail.com> <604aa7910805161527j6b193c6dj2af4248155d5cdaf@mail.gmail.com> <1210989429.24740.14.camel@localhost.localdomain> Message-ID: On Fri, 16 May 2008, Chris Ricker wrote: > > I've personally tested static IP addressing with static DNS servers with > > anaconda on the F9 release LiveCD, and it worked fine for me through > > multiple tests. What's not working for you? Can you attach the ifcfg > > files anaconda generated right after you installed? > > Multiple people (including me) have put non-working examples in the mother > of all NM bugzilla tickets ;-) > > Have you tried non-LiveCD? Mine was from a non-LiveCD. The ifcfg files generated look fine: # Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 DEVICE=eth0 BOOTPROTO=static HWADDR=00:d0:b7:85:f6:03 ONBOOT=no DHCP_HOSTNAME=bofh.xelerance.com # Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet DEVICE=eth1 BOOTPROTO=static HWADDR=00:0c:76:bc:9b:d1 IPADDR=193.110.157.17 NETMASK=255.255.255.248 ONBOOT=yes eth0 has (or had) no link during install. To be it looked like despite being confgured with BOOTPROTO=static, the avahi daemon and NetworkManager got started, and one of them started doing dhcp. The static IP did appear as an additiona IP on the eth1 interface, but since the DHCP was the main address, my public ip address changed. Paul From seg at haxxed.com Sat May 17 04:16:31 2008 From: seg at haxxed.com (Callum Lerwick) Date: Fri, 16 May 2008 23:16:31 -0500 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <3118d8de0805160952n673df32clfe697b2aa65f4de4@mail.gmail.com> References: <3118d8de0805160952n673df32clfe697b2aa65f4de4@mail.gmail.com> Message-ID: <1218b5bc0805162116k705c658i79a342044870e970@mail.gmail.com> On Fri, May 16, 2008 at 11:52 AM, Jason Corley wrote: > Callum Lerwick wrote: > > Overlapping repos are fundamentally broken, period. We've had long > flamewars in the past about how ATrpms freely > > replaces Fedora packages making an unsupportable mess. Why are we > allowing JPackage to pull the same crap? > > 1) JPackage predates Fedora and it's predecessor in interest fedora.us. And what does that have to do with engineering integrity? Overlapping repos are broken, period. Is anyone not convinced of this? Do I really need to go over the reasons why? I'm sorry, seniority is no justification. And JPackage only has seniority if you conveniently ignore the fact that Fedora is an evolved form of Red Hat Linux and not an entirely new project. 2) The packages that are in question come from JPackage and were > imported into Fedora (hence the jpp in version string). And? So continue keeping the Fedora package in sync with JPackage. > 3) Most of the JPackage repository is contained in generic, which has > a goal of being the same set of packages for all distributions we > support. Only JNI code (or similar) is in the distribution specific > repositories, so removal of packages that conflict with Fedora from > the generic repo harms our user base that is not on Fedora. Set up your build system to maintain symlinks to everything in the "generic" repo in the Fedora-specific repo, *except* for what exists in Fedora. Then point Fedora systems at *only* the Fedora-specific repo. Ta da, fixed. Now go do it. I'm already doing something similar for multilib support in my personal testing repo with some truly hideous bash script. I really should rewrite it in python... 4) JPackage does not support Fedora exclusively (nor do we intend to), > we support Mandriva, OpenSuSE, etc. Red herring. 5) JPackage is not beholden to the Fedora project in any way, so you > aren't allowing anything. We are an OSS project, just like Fedora is, > except we focus on something different than an entire OS. Neither is Fedora beholden to JPackage. I'm not sure what your point is. If JPackage insists on Doing It Wrong, that's their problem, not ours. I just gave you a possible solution. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lesmikesell at gmail.com Sat May 17 06:05:34 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Sat, 17 May 2008 01:05:34 -0500 Subject: Summary of the 2008-04-08 Packaging Committee meeting In-Reply-To: <1218b5bc0805162116k705c658i79a342044870e970@mail.gmail.com> References: <3118d8de0805160952n673df32clfe697b2aa65f4de4@mail.gmail.com> <1218b5bc0805162116k705c658i79a342044870e970@mail.gmail.com> Message-ID: <482E75AE.7010902@gmail.com> Callum Lerwick wrote: > >> 1) JPackage predates Fedora and it's predecessor in interest fedora.us. > > > And what does that have to do with engineering integrity? Overlapping repos > are broken, period. Is anyone not convinced of this? Do I really need to go > over the reasons why? It takes two participants to maintain an incompatibility. > I'm sorry, seniority is no justification. How so? The forked duplicate is clearly the problem. > And JPackage > only has seniority if you conveniently ignore the fact that Fedora is an > evolved form of Red Hat Linux and not an entirely new project. I don't quite know what that means or how it relates to all the other distributions it supports. Or why it should be relevant to the act of forking incompatible, conflicting duplicates of its packages. >> 2) The packages that are in question come from JPackage and were >> imported into Fedora (hence the jpp in version string). > > > And? So continue keeping the Fedora package in sync with JPackage. If they are exactly identical there's no conflict. >> 3) Most of the JPackage repository is contained in generic, which has >> a goal of being the same set of packages for all distributions we >> support. Only JNI code (or similar) is in the distribution specific >> repositories, so removal of packages that conflict with Fedora from >> the generic repo harms our user base that is not on Fedora. > > > Set up your build system to maintain symlinks to everything in the "generic" > repo in the Fedora-specific repo, *except* for what exists in Fedora. Then > point Fedora systems at *only* the Fedora-specific repo. > Ta da, fixed. Wouldn't it have been better to not break it in the first place? > 4) JPackage does not support Fedora exclusively (nor do we intend to), >> we support Mandriva, OpenSuSE, etc. > > > Red herring. What??? Why should the rest of the world cater to fedora's non-standardness? > 5) JPackage is not beholden to the Fedora project in any way, so you >> aren't allowing anything. We are an OSS project, just like Fedora is, >> except we focus on something different than an entire OS. > > > Neither is Fedora beholden to JPackage. Unless, of course, you cared about your users whose ability to get the packages you didn't bother to copy, due to policy issues or whatever, has been broken. > I'm not sure what your point is. If > JPackage insists on Doing It Wrong, that's their problem, not ours. I just > gave you a possible solution. The point is clearly that the repository creating the new incompatible forked copy of a package is the one causing the problem and the one that should have done it some other way. This would be sort-of irrelevant if the copying repository took copies of everything and fixed up the incompatibilities internally in their own version, but that hasn't happened with any of the repositories the fedora project has abused this way, leaving the users who need access to the other content hanging. -- Les Mikesell lesmikesell at gmail.com From gilboad at gmail.com Sat May 17 06:31:29 2008 From: gilboad at gmail.com (Gilboa Davara) Date: Sat, 17 May 2008 09:31:29 +0300 Subject: I have a big mouth... In-Reply-To: <604aa7910805161029i1573ca51v11c144007c0254f3@mail.gmail.com> References: <604aa7910805161029i1573ca51v11c144007c0254f3@mail.gmail.com> Message-ID: <1211005889.312.21.camel@gilboa-home-dev.localdomain> On Fri, 2008-05-16 at 09:29 -0800, Jeff Spaleta wrote: > http://www.informationweek.com/blog/main/archives/2008/05/hats_off_for_fe.html > > First comment in the comment section. Since i love flashing my board > creds as much as possible. I want to make sure everyone else is aware > of my attempts at sullying the Fedora Board's reputation. > > -jef > /+5 Informative, especially the "Taking Debian for granted" part... - Gilboa From mzerqung at 0pointer.de Sat May 17 10:16:16 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Sat, 17 May 2008 12:16:16 +0200 Subject: Glitch-Free PulseAudio in Rawhide Message-ID: <20080517101616.GA16071@tango.0pointer.de> Heya! Since yesterday glitch-free PulseAudio is available in Rawhide, breaking your sound setups. Please make sure to read this mail I posted to the PA ML a few minutes back, especially those people who have HDA audio hw and want to play with this: https://tango.0pointer.de/pipermail/pulseaudio-discuss/2008-May/001837.html Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From jdieter at gmail.com Sat May 17 10:16:21 2008 From: jdieter at gmail.com (Jonathan Dieter) Date: Sat, 17 May 2008 13:16:21 +0300 Subject: Broken dependencies in Rawhide Message-ID: <1211019381.3337.1.camel@jdlaptop> I've just got a couple of e-mails stating that two of my packages have broken dependencies in the development tree: ?On ppc: deltarpm-3.4-10.fc9.ppc requires /usr/bin/perl On x86_64: deltarpm-3.4-10.fc9.x86_64 requires /usr/bin/perl On i386: deltarpm-3.4-10.fc9.i386 requires /usr/bin/perl On ppc64: deltarpm-3.4-10.fc9.ppc64 requires /usr/bin/perl ?On ppc: presto-utils-0.3.2-1.fc8.noarch requires /bin/sh presto-utils-0.3.2-1.fc8.noarch requires /usr/bin/python On x86_64: presto-utils-0.3.2-1.fc8.noarch requires /bin/sh presto-utils-0.3.2-1.fc8.noarch requires /usr/bin/python On i386: presto-utils-0.3.2-1.fc8.noarch requires /bin/sh presto-utils-0.3.2-1.fc8.noarch requires /usr/bin/python On ppc64: presto-utils-0.3.2-1.fc8.noarch requires /bin/sh presto-utils-0.3.2-1.fc8.noarch requires /usr/bin/python This is just fuzz and I can ignore it, right? Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Sat May 17 10:19:45 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 17 May 2008 15:49:45 +0530 Subject: Broken dependencies in Rawhide In-Reply-To: <1211019381.3337.1.camel@jdlaptop> References: <1211019381.3337.1.camel@jdlaptop> Message-ID: <482EB141.8080304@fedoraproject.org> Jonathan Dieter wrote: > I've just got a couple of e-mails stating that two of my packages have > broken dependencies in the development tree: > > This is just fuzz and I can ignore it, right? Seems to be just a side effect of breakage from the latest glibc update in rawhide. Should be safe to ignore IIUC. Rahul From pingou at pingoured.fr Sat May 17 10:20:11 2008 From: pingou at pingoured.fr (pingou) Date: Sat, 17 May 2008 12:20:11 +0200 Subject: Broken dependencies in Rawhide In-Reply-To: <1211019381.3337.1.camel@jdlaptop> References: <1211019381.3337.1.camel@jdlaptop> Message-ID: <482EB15B.4030503@pingoured.fr> Jonathan Dieter wrote: > I've just got a couple of e-mails stating that two of my packages have > broken dependencies in the development tree: > This is just fuzz and I can ignore it, right? I got them about /bin/sh /sbin/ldconfig, so I guess we can ignore them... Cheers Pierre From lemenkov at gmail.com Sat May 17 10:19:51 2008 From: lemenkov at gmail.com (Peter Lemenkov) Date: Sat, 17 May 2008 14:19:51 +0400 Subject: Broken dependencies in Rawhide In-Reply-To: <1211019381.3337.1.camel@jdlaptop> References: <1211019381.3337.1.camel@jdlaptop> Message-ID: Hello All! 2008/5/17 Jonathan Dieter : > I've just got a couple of e-mails stating that two of my packages have The same for me. -- With best regards! From drago01 at gmail.com Sat May 17 10:31:37 2008 From: drago01 at gmail.com (drago01) Date: Sat, 17 May 2008 12:31:37 +0200 Subject: Glitch-Free PulseAudio in Rawhide In-Reply-To: <20080517101616.GA16071@tango.0pointer.de> References: <20080517101616.GA16071@tango.0pointer.de> Message-ID: On Sat, May 17, 2008 at 12:16 PM, Lennart Poettering wrote: > Heya! > > Since yesterday glitch-free PulseAudio is available in Rawhide, > breaking your sound setups. > > Please make sure to read this mail I posted to the PA ML a few minutes back, > especially those people who have HDA audio hw and want to play with this: > > https://tango.0pointer.de/pipermail/pulseaudio-discuss/2008-May/001837.html > > Lennart Can we get this patch into the rawhide kernel to make testing easier? From mzerqung at 0pointer.de Sat May 17 10:39:26 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Sat, 17 May 2008 12:39:26 +0200 Subject: Glitch-Free PulseAudio in Rawhide In-Reply-To: References: <20080517101616.GA16071@tango.0pointer.de> Message-ID: <20080517103926.GA16826@tango.0pointer.de> On Sat, 17.05.08 12:31, drago01 (drago01 at gmail.com) wrote: > > On Sat, May 17, 2008 at 12:16 PM, Lennart Poettering > wrote: > > Heya! > > > > Since yesterday glitch-free PulseAudio is available in Rawhide, > > breaking your sound setups. > > > > Please make sure to read this mail I posted to the PA ML a few minutes back, > > especially those people who have HDA audio hw and want to play with this: > > > > https://tango.0pointer.de/pipermail/pulseaudio-discuss/2008-May/001837.html > Can we get this patch into the rawhide kernel to make testing easier? That's the plan. However, I haven't tested this patch myself yet. I do my day-to-day testing with USB hw only -- which works fine without it. Unless someone else is quicker than me I will ask the kernel guys to merge this patch as soon I am sure that all things now work as well on HDA as they used to on USB. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From rawhide at fedoraproject.org Sat May 17 10:38:35 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Sat, 17 May 2008 10:38:35 +0000 (UTC) Subject: rawhide report: 20080517 changes Message-ID: <20080517103836.1CA49209D25@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080516/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080517/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package unique Unique instance support for applications New package lwp LWP thread library New package inksmoto Inksmoto Level Editor is the new xmoto level editor New package efreet An implementation of several specifications from freedesktop.org New package coda Coda distributed file system New package rpc2 RPC2 library New package cairo-dock Light eye-candy fully themable animated dock New package gypsy Gypsy is a GPS multiplexing daemon New package geoclue Geoclue is a modular geoinformation service New package rvm RVM library New package mod_bw Bandwidth Limiter For Apache Updated Packages: perl-Text-Diff-HTML-0.05-1.fc10 ------------------------------- * Fri May 16 18:00:00 2008 Steven Pritchard 0.05-1 - Update to 0.05. poker2d-1.5.0-1.fc10 -------------------- * Fri May 16 18:00:00 2008 Christopher Stone 1.5.0-1 - Upstream sync - Remove no longer needed configure patch - Remove autoreconf because it is no longer needed - Remove build requirements on gettext and libtool rtpproxy-1.1-0.3.beta.200804031.fc10 ------------------------------------ * Fri May 16 18:00:00 2008 Peter Lemenkov - 1.1-0.3.beta.200804031 - Snapshot 20080403.1 system-config-printer-0.9.91-1.fc10 ----------------------------------- * Fri May 16 18:00:00 2008 Tim Waugh 0.9.91-1 - No longer requires system-install-packages (bug #444645). - Added pysmbc. Build requires libsmbclient-devel. - Don't install consolehelper bits any more as they are no longer needed. - 0.9.91: - User interface overhaul, part 2. siege-2.67-1.fc10 ----------------- * Fri May 16 18:00:00 2008 Allisson Azevedo 2.67-1 - Update to 2.67 - Update License policycoreutils-2.0.49-2.fc10 ----------------------------- * Fri May 16 18:00:00 2008 Dan Walsh 2.0.49-2 - Fix listing of types in gui * Mon May 12 18:00:00 2008 Dan Walsh 2.0.49-1 - Update to upstream * Remove security_check_context calls for prefix validation from semanage. * Change setfiles and restorecon to not relabel if the file already has the correct context value even if -F/force is specified. * Mon May 12 18:00:00 2008 Dan Walsh 2.0.47-3 - Remove /usr/share/locale/sr at Latn/LC_MESSAGES/policycoreutils.mo gdl-0.9-0.rc1.3.fc10 -------------------- * Fri May 16 18:00:00 2008 - Orion Poplawski - 0.9-0.rc1.3 - Update to latest cvs - Add patch to handle new ImageMagick - Update netcdf locations * Mon Apr 28 18:00:00 2008 - Orion Poplawski - 0.9-0.rc1.2 - Rebuild for new ImageMagick udev-121-1.20080516git.fc10 --------------------------- * Fri May 16 18:00:00 2008 Harald Hoyer 121-1.20080516git - version 121 + latest git fixes * Thu Apr 24 18:00:00 2008 Harald Hoyer 120-6.20080421git - added input/hp_ilo_mouse symlink paps-0.6.8-6.fc10 ----------------- * Fri May 16 18:00:00 2008 Akira TAGOH - 0.6.8-6 - paps-cups.patch: Fix printing with -o landscape in CUPS. (#222137) - paps-autoconf262.patch: Fix an error on autoreconf. perl-Module-ScanDeps-0.84-1.fc10 -------------------------------- * Fri May 16 18:00:00 2008 Steven Pritchard 0.84-1 - Update to 0.84. ocaml-omake-0.9.8.5-3.fc10 -------------------------- * Fri May 16 18:00:00 2008 Richard W.M. Jones - 0.9.8.5-3 - Rebuild with OCaml 3.10.2-2 (fixes bz 445545). poker-engine-1.2.0-1.fc10 ------------------------- * Fri May 16 18:00:00 2008 Christopher Stone 1.2.0-1 - Upstream sync glusterfs-1.3.9-1.fc10 ---------------------- * Fri May 16 18:00:00 2008 Matthias Saou 1.3.9-1 - Update to 1.3.9. libsexy-0.1.11-8.fc10 --------------------- * Fri May 16 18:00:00 2008 Brian Pepple - 0.1.11-8 - Add requires for libxml2-devel to devel. (#446842) tuxpuck-0.8.2-6.fc10 -------------------- * Fri May 16 18:00:00 2008 Jon Ciesla 0.8.2-6 - FTBFS rebuild, BZ440791. perl-MasonX-Interp-WithCallbacks-1.18-1.fc10 -------------------------------------------- * Fri May 16 18:00:00 2008 Steven Pritchard 1.18-1 - Update to 1.18. nntpgrab-0.2.90-1.fc10 ---------------------- * Sat May 17 18:00:00 2008 Erik van Pienbroek - 0.2.90-1 - Update to version 0.2.90 (0.3 beta 1) containing lots of new features - Added a -server subpackage - Added a -web subpackage - All the plugins are now moved to /usr/lib/nntpgrab dhcp-4.0.0-15.fc10 ------------------ * Fri May 16 18:00:00 2008 David Cantrell - 12:4.0.0-15 - Set close-on-exec on dhclient.leases for SELinux (#446632) ghdl-0.26-0.94svn.7.fc10 ------------------------ * Fri May 16 18:00:00 2008 Thomas Sailer - 0.26-0.94svn.7 - update to svn94 libdc1394-2.0.2-1.fc10 ---------------------- * Mon May 12 18:00:00 2008 Tim Niemueller - 2.0.2-1 - Update to latest stable release 2.0.2 scim-sinhala-0.3.0-1.fc10 ------------------------- * Fri May 16 18:00:00 2008 Pravin Satpute - 0.3.0-1 - update to scim-sayura 0.3.0 from upstream - upated spec file as per new tarball libfprint-0.0.5-6.fc10 ---------------------- * Tue May 13 18:00:00 2008 Pingou 0.0.5-6 - Correction on the Build Requires * Tue May 13 18:00:00 2008 Pingou 0.0.5-5 - Correction on the Build Requires * Tue May 13 18:00:00 2008 Pingou 0.0.5-4 - Update the Build Requires due to the change on ImageMagick swig-1.3.35-2.fc10 ------------------ * Fri May 16 18:00:00 2008 Adam Tkac 1.3.35-2 - readded swig-arch.patch, will be kept downstream pulseaudio-0.9.11-0.0.svn20080516.fc10 -------------------------------------- * Fri May 16 18:00:00 2008 Matthias Clasen 0.9.11-0.0.svn20080516 - Update to an svn snapshot of the 'glitch-free' rewrite of pulseaudio nautilus-2.23.2-2.fc10 ---------------------- * Fri May 16 18:00:00 2008 Tomas Bzatek - 2.23.2-2 - Add treeview XDS drag&drop support (#446760) * Tue May 13 18:00:00 2008 Tomas Bzatek - 2.23.2-1 - Update to 2.23.2 fuse-s3fs-0.5-1.fc10 -------------------- * Fri May 16 18:00:00 2008 Neil Horman 0.5-1 - Updated s3fs to upstream version 0.5 augeas-0.1.1-1.fc10 ------------------- * Fri May 16 18:00:00 2008 David Lutterkort - 0.1.1-1 - New version * Fri May 2 18:00:00 2008 David Lutterkort - 0.1.0-2 - Fixes according to Fedora review ipa-1.0.0-5.fc10 ---------------- * Fri May 16 18:00:00 2008 Rob Crittenden - 1.0.0-5 - Set fedora-ds-base minimum version to 1.1.0.1-4 and mod_nss minimum version to 1.0.7-4 so we pick up the NSS fixes. - Add selinux-policy-base(post) to Requires (446496) GConf2-2.22.0-7.fc10 -------------------- * Wed May 14 18:00:00 2008 Ray Strode - 2.22.0-7 - update add_seconds patch to not remove timeouts that aren't created anymore gnome-python2-desktop-2.22.0-4.fc10 ----------------------------------- * Tue May 13 18:00:00 2008 Matthew Barnes - 2.22.0-4.fc10 - Rebuild against newer libedataserver and libtotem-plparser. * Tue Apr 29 18:00:00 2008 Matthew Barnes - 2.22.0-3.fc10 - gnome-python2-evolution obsoletes evolution-python (RH bug #444263). telepathy-gabble-0.7.6-1.fc10 ----------------------------- * Fri May 16 18:00:00 2008 Brian Pepple - 0.7.6-1 - Update to 0.7.6. perl-Params-CallbackRequest-1.18-1.fc10 --------------------------------------- * Fri May 16 18:00:00 2008 Steven Pritchard 1.18-1 - Update to 1.18. Broken deps for i386 ---------------------------------------------------------- 8Kingdoms-1.1.0-6.fc9.i386 requires /bin/sh AcetoneISO-6.7-5.fc9.i386 requires /bin/bash AcetoneISO2-2.0.2-3.fc10.i386 requires /bin/bash AllegroOGG-1.0.3-4.fc9.i386 requires /sbin/ldconfig BackupPC-3.1.0-2.fc9.noarch requires /bin/sh BackupPC-3.1.0-2.fc9.noarch requires /usr/sbin/useradd BackupPC-3.1.0-2.fc9.noarch requires /usr/bin/perl BackupPC-3.1.0-2.fc9.noarch requires /bin/sh BackupPC-3.1.0-2.fc9.noarch requires /usr/sbin/usermod BlockOutII-2.3-5.fc9.i386 requires /bin/sh CCfits-2.0-1.fc9.i386 requires /sbin/ldconfig CGAL-3.3.1-11.fc9.i386 requires /sbin/ldconfig CGAL-devel-3.3.1-11.fc9.i386 requires /etc/profile.d CGAL-devel-3.3.1-11.fc9.i386 requires /bin/sh CTL-1.4.1-6.fc9.i386 requires /sbin/ldconfig Canna-3.7p3-23.fc9.i386 requires /bin/sh Canna-3.7p3-23.fc9.i386 requires /sbin/chkconfig Canna-3.7p3-23.fc9.i386 requires /bin/bash Canna-3.7p3-23.fc9.i386 requires /bin/chown Canna-3.7p3-23.fc9.i386 requires /bin/grep Canna-3.7p3-23.fc9.i386 requires /bin/sh Canna-3.7p3-23.fc9.i386 requires /sbin/service Canna-3.7p3-23.fc9.i386 requires /etc/services Canna-libs-3.7p3-23.fc9.i386 requires /sbin/ldconfig CastPodder-5.0-8.fc6.noarch requires /bin/bash CastPodder-5.0-8.fc6.noarch requires /usr/bin/env CastPodder-5.0-8.fc6.noarch requires /bin/sh CastPodder-5.0-8.fc6.noarch requires /usr/bin/python ClanLib-0.8.1-1.fc9.i386 requires /sbin/ldconfig ClanLib06-0.6.5-12.fc9.i386 requires /sbin/ldconfig ClanLib06-devel-0.6.5-12.fc9.i386 requires /bin/sh Coin2-2.5.0-4.fc9.i386 requires /sbin/ldconfig Coin2-devel-2.5.0-4.fc9.i386 requires /bin/sh ConsoleKit-0.2.10-3.fc9.i386 requires /bin/sh ConsoleKit-0.2.10-3.fc9.i386 requires /bin/sh CriticalMass-1.0.2-5.fc9.i386 requires /bin/sh Cython-0.9.6.13.1-3.fc10.noarch requires /usr/bin/python DevIL-1.6.8-0.15.rc2.fc9.i386 requires /sbin/ldconfig DevIL-ILUT-1.6.8-0.15.rc2.fc9.i386 requires /sbin/ldconfig Django-0.96.1-2.fc9.noarch requires /usr/bin/env Django-0.96.1-2.fc9.noarch requires /usr/bin/python Django-docs-0.96.1-2.fc9.noarch requires /usr/bin/env ElectricFence-2.2.2-25.fc9.i386 requires /sbin/ldconfig ElectricFence-2.2.2-25.fc9.i386 requires /bin/bash FlightGear-1.0.0-3.fc10.i386 requires /bin/sh GConf2-2.22.0-7.fc10.i386 requires /sbin/ldconfig GConf2-2.22.0-7.fc10.i386 requires /bin/sh GConf2-2.22.0-7.fc10.i386 requires /usr/bin/killall GREYCstoration-gui-2.8-1.fc9.i386 requires /bin/sh GREYCstoration-gui-2.8-1.fc9.i386 requires /bin/sh GeoIP-1.4.4-2.fc9.i386 requires /sbin/ldconfig Glide3-20050815-7.fc9.i386 requires /bin/sh Glide3-20050815-7.fc9.i386 requires /sbin/ldconfig Glide3-libGL-6.2.1-8.fc9.i386 requires /bin/bash GraphicsMagick-1.1.10-3.fc9.i386 requires /sbin/ldconfig GraphicsMagick-c++-1.1.10-3.fc9.i386 requires /sbin/ldconfig GraphicsMagick-c++-devel-1.1.10-3.fc9.i386 requires /bin/sh GraphicsMagick-devel-1.1.10-3.fc9.i386 requires /bin/sh GtkAda-2.10.0-4.fc9.i386 requires /sbin/ldconfig GtkAda-devel-2.10.0-4.fc9.i386 requires /bin/sh 1:HelixPlayer-1.0.9-2.fc9.i386 requires /bin/sh 1:HelixPlayer-1.0.9-2.fc9.i386 requires /bin/sh 1:HelixPlayer-plugin-1.0.9-2.fc9.i386 requires /usr/lib/mozilla/plugins Hermes-1.3.3-14.fc9.i386 requires /sbin/ldconfig HippoDraw-1.21.1-4.fc9.i386 requires /bin/sh ImageMagick-6.4.0.10-1.fc10.i386 requires /sbin/ldconfig ImageMagick-c++-6.4.0.10-1.fc10.i386 requires /sbin/ldconfig ImageMagick-c++-devel-6.4.0.10-1.fc10.i386 requires /bin/sh ImageMagick-devel-6.4.0.10-1.fc10.i386 requires /bin/sh Inventor-2.1.5-31.fc9.i386 requires /usr/share/fonts/liberation/LiberationSerif-BoldItalic.ttf Inventor-2.1.5-31.fc9.i386 requires /usr/share/fonts/liberation/LiberationSans-Regular.ttf Inventor-2.1.5-31.fc9.i386 requires /usr/share/fonts/liberation/LiberationMono-Italic.ttf Inventor-2.1.5-31.fc9.i386 requires /usr/share/fonts/liberation/LiberationMono-BoldItalic.ttf Inventor-2.1.5-31.fc9.i386 requires /usr/share/fonts/liberation/LiberationSerif-Regular.ttf Inventor-2.1.5-31.fc9.i386 requires /usr/share/fonts/liberation/LiberationSans-BoldItalic.ttf Inventor-2.1.5-31.fc9.i386 requires /usr/share/fonts/liberation/LiberationMono-Bold.ttf Inventor-2.1.5-31.fc9.i386 requires /usr/share/fonts/liberation/LiberationSans-Bold.ttf Inventor-2.1.5-31.fc9.i386 requires /sbin/ldconfig Inventor-2.1.5-31.fc9.i386 requires /usr/share/fonts/liberation/LiberationSerif-Bold.ttf Inventor-2.1.5-31.fc9.i386 requires /usr/share/fonts/liberation/LiberationSerif-Italic.ttf Inventor-2.1.5-31.fc9.i386 requires /usr/share/fonts/liberation/LiberationMono-Regular.ttf Inventor-2.1.5-31.fc9.i386 requires /bin/sh Inventor-2.1.5-31.fc9.i386 requires /usr/share/fonts/liberation/LiberationSans-Italic.ttf Inventor-demos-2.1.5-31.fc9.i386 requires /bin/sh InventorXt-2.1.5-31.fc9.i386 requires /sbin/ldconfig InventorXt-2.1.5-31.fc9.i386 requires /usr/bin/xmessage Io-language-20071010-5.fc9.i386 requires /sbin/ldconfig JSDoc-1.10.2-4.fc8.noarch requires /usr/bin/perl KoboDeluxe-0.5.1-2.fc9.i386 requires /bin/sh KoboDeluxe-0.5.1-2.fc9.i386 requires /usr/sbin/groupadd LabPlot-1.5.1.6-4.fc8.i386 requires /bin/sh LabPlot-1.5.1.6-4.fc8.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libMagick.so.10 MAKEDEV-3.23-4.i386 requires /bin/sh Macaulay2-1.1-1.fc9.i386 requires /bin/sh Macaulay2-1.1-1.fc9.i386 requires /bin/sh Maelstrom-3.0.6-15.i386 requires /bin/sh MagicPoint-1.11b-6.fc9.i386 requires /usr/bin/perl MegaMek-0.30.11-3.fc9.i386 requires /bin/sh MegaMek-0.30.11-3.fc9.i386 requires /usr/bin/perl MegaMek-0.30.11-3.fc9.i386 requires /bin/sh Miro-1.2.3-2.fc10.i386 requires /usr/bin/python Miro-1.2.3-2.fc10.i386 requires /bin/sh Miro-1.2.3-2.fc10.i386 requires /bin/sh 1:NetworkManager-0.7.0-0.9.3.svn3669.fc10.i386 requires /bin/sh 1:NetworkManager-0.7.0-0.9.3.svn3669.fc10.i386 requires /bin/sh 1:NetworkManager-glib-0.7.0-0.9.3.svn3669.fc10.i386 requires /sbin/ldconfig 1:NetworkManager-gnome-0.7.0-0.9.3.svn3669.fc10.i386 requires /bin/sh 1:NetworkManager-openvpn-0.7.0-10.svn3632.fc10.i386 requires /bin/sh 1:NetworkManager-openvpn-0.7.0-10.svn3632.fc10.i386 requires /usr/bin/update-desktop-database 1:NetworkManager-openvpn-0.7.0-10.svn3632.fc10.i386 requires /sbin/ldconfig 1:NetworkManager-vpnc-0.7.0-0.7.7.svn3627.fc10.i386 requires /bin/sh 1:NetworkManager-vpnc-0.7.0-0.7.7.svn3627.fc10.i386 requires /sbin/ldconfig 1:ORBit-0.5.17-23.fc9.i386 requires /sbin/ldconfig 1:ORBit-0.5.17-23.fc9.i386 requires /sbin/install-info 1:ORBit-devel-0.5.17-23.fc9.i386 requires /bin/sh 1:ORBit-devel-0.5.17-23.fc9.i386 requires /bin/sh ORBit2-2.14.12-3.fc9.i386 requires /sbin/ldconfig ORBit2-devel-2.14.12-3.fc9.i386 requires /bin/sh OpenEXR-libs-1.6.1-4.fc10.i386 requires /sbin/ldconfig OpenEXR_CTL-libs-1.0.1-4.fc9.i386 requires /sbin/ldconfig OpenEXR_Viewers-1.0.1-2.fc10.i386 requires /bin/sh OpenEXR_Viewers-1.0.1-2.fc10.i386 requires /usr/sbin/alternatives OpenIPMI-2.0.13-2.fc9.i386 requires /bin/sh OpenIPMI-2.0.13-2.fc9.i386 requires /bin/sh OpenIPMI-libs-2.0.13-2.fc9.i386 requires /sbin/ldconfig OpenSceneGraph-libs-2.4.0-2.fc10.i386 requires /sbin/ldconfig OpenThreads-2.4.0-2.fc10.i386 requires /sbin/ldconfig PackageKit-0.2.1-2.20080508.fc10.i386 requires /usr/bin/python PackageKit-0.2.1-2.20080508.fc10.i386 requires /bin/bash PackageKit-0.2.1-2.20080508.fc10.i386 requires /bin/sh PackageKit-libs-0.2.1-2.20080508.fc10.i386 requires /sbin/ldconfig Perlbal-1.70-1.fc9.noarch requires /bin/sh Perlbal-1.70-1.fc9.noarch requires /sbin/service Perlbal-1.70-1.fc9.noarch requires /bin/bash Perlbal-1.70-1.fc9.noarch requires /usr/bin/perl Perlbal-1.70-1.fc9.noarch requires /sbin/chkconfig Pixie-2.2.3-3.fc9.i386 requires /sbin/ldconfig PolicyKit-0.8-2.fc9.i386 requires /usr/sbin/useradd PolicyKit-0.8-2.fc9.i386 requires /sbin/ldconfig PolicyKit-0.8-2.fc9.i386 requires /bin/sh Pound-2.4-1.fc9.i386 requires /bin/sh Pound-2.4-1.fc9.i386 requires /usr/sbin/groupadd Pound-2.4-1.fc9.i386 requires /usr/sbin/useradd Pound-2.4-1.fc9.i386 requires /sbin/service Pound-2.4-1.fc9.i386 requires /bin/bash Pound-2.4-1.fc9.i386 requires /sbin/chkconfig PyKDE-3.16.1-1.fc9.i386 requires /usr/bin/env PyKDE-devel-3.16.1-1.fc9.i386 requires /usr/bin/env PyQt-examples-3.17.4-4.fc9.i386 requires /usr/bin/env PyQt4-4.4-1.fc10.i386 requires /usr/bin/env PyQt4-devel-4.4-1.fc10.i386 requires /bin/sh PySolFC-1.1-6.fc9.noarch requires /usr/bin/env PySolFC-1.1-6.fc9.noarch requires /bin/sh PySolFC-1.1-6.fc9.noarch requires /usr/bin/python PyX-0.10-4.fc9.i386 requires /usr/bin/env PyXML-0.8.4-9.i386 requires /usr/bin/python Pyrex-0.9.6.4-2.fc10.noarch requires /usr/bin/python PythonCAD-0.1.36-3.fc9.noarch requires /bin/sh PythonCAD-0.1.36-3.fc9.noarch requires /usr/bin/env PythonCAD-0.1.36-3.fc9.noarch requires /usr/bin/python QuantLib-0.9.0-5.fc9.i386 requires /sbin/ldconfig QuantLib-devel-0.9.0-5.fc9.i386 requires /bin/sh R-2.7.0-2.fc10.i386 requires /bin/sh R-2.7.0-2.fc10.i386 requires /bin/bash R-2.7.0-2.fc10.i386 requires /bin/sh R-2.7.0-2.fc10.i386 requires /usr/bin/perl R-BSgenome.Celegans.UCSC.ce2-1.2.0-5.noarch requires /bin/sh R-BSgenome.Dmelanogaster.FlyBase.r51-1.3.1-3.noarch requires /bin/sh R-Biobase-1.16.1-5.fc9.i386 requires /bin/sh R-Biobase-1.16.1-5.fc9.i386 requires /bin/bash R-BufferedMatrix-1.4.0-1.fc10.i386 requires /bin/sh R-BufferedMatrixMethods-1.3.0-3.fc9.i386 requires /bin/sh R-DynDoc-1.18.0-1.fc10.noarch requires /bin/sh R-Matrix-0.999375-4.fc9.i386 requires /bin/sh R-RScaLAPACK-0.5.1-11.fc9.2.i386 requires /bin/sh R-RScaLAPACK-0.5.1-11.fc9.2.i386 requires /bin/sh R-abind-1.1-2.fc9.noarch requires /bin/sh R-acepack-1.3-4.fc9.i386 requires /bin/sh R-affyio-1.8.0-1.fc10.i386 requires /bin/sh R-car-1.2-3.fc10.noarch requires /bin/sh R-hdf5-1.6.6-6.fc10.i386 requires /bin/sh R-hgu95av2probe-2.0.0-1.fc9.noarch requires /bin/sh R-mAr-1.1-13.fc9.i386 requires /bin/sh R-maanova-1.9.0-2.fc9.i386 requires /bin/sh R-multcomp-1.0-1.fc9.noarch requires /bin/sh R-multtest-1.18.0-4.fc9.i386 requires /bin/sh R-mvtnorm-0.8-4.fc9.i386 requires /bin/sh R-pls-2.1-2.fc9.noarch requires /bin/sh R-qvalue-1.12.0-2.fc9.noarch requires /bin/sh R-rlecuyer-0.1-6.fc9.i386 requires /bin/sh R-systemfit-0.8-7.fc9.noarch requires /bin/sh R-tkWidgets-1.16.0-2.fc9.noarch requires /bin/sh R-waveslim-1.6.1-2.fc9.i386 requires /bin/sh R-wavethresh-2.2-9.fc9.i386 requires /bin/sh R-widgetTools-1.15.0-2.fc9.noarch requires /bin/sh Ri-li-2.0.1-3.fc9.i386 requires /bin/sh SAASound-3.2-5.fc10.i386 requires /sbin/ldconfig SDL-1.2.13-3.fc9.i386 requires /sbin/ldconfig SDL-devel-1.2.13-3.fc9.i386 requires /bin/sh SDL_Pango-0.1.2-8.i386 requires /sbin/ldconfig SDL_gfx-2.0.16-5.fc9.i386 requires /sbin/ldconfig SDL_image-1.2.6-6.fc9.i386 requires /sbin/ldconfig SDL_mixer-1.2.8-8.fc9.i386 requires /sbin/ldconfig SDL_net-1.2.7-4.fc9.i386 requires /sbin/ldconfig SDL_sound-1.0.3-1.fc10.i386 requires /sbin/ldconfig SDL_ttf-2.0.9-4.fc9.i386 requires /sbin/ldconfig SILLY-0.1.0-5.fc9.i386 requires /sbin/ldconfig SIMVoleon-2.0.1-7.fc9.i386 requires /bin/sh SIMVoleon-2.0.1-7.fc9.i386 requires /sbin/ldconfig SIMVoleon-devel-2.0.1-7.fc9.i386 requires /bin/sh ScientificPython-2.6-12.fc9.i386 requires /usr/bin/python SimGear-1.0.0-4.fc10.i386 requires /sbin/ldconfig SoQt-1.4.1-9.fc9.i386 requires /bin/sh SoQt-1.4.1-9.fc9.i386 requires /sbin/ldconfig SoQt-devel-1.4.1-9.fc9.i386 requires /usr/share/aclocal SoQt-devel-1.4.1-9.fc9.i386 requires /bin/sh Sprog-0.14-13.fc9.noarch requires /usr/bin/perl TeXmacs-1.0.6.14-1.fc9.i386 requires /bin/sh TeXmacs-1.0.6.14-1.fc9.i386 requires /usr/bin/env TeXmacs-1.0.6.14-1.fc9.i386 requires /bin/bash TeXmacs-1.0.6.14-1.fc9.i386 requires /bin/sh Terminal-0.2.8-3.fc9.i386 requires /bin/sh Terminal-0.2.8-3.fc9.i386 requires /bin/sh Thunar-0.9.0-4.fc9.i386 requires /bin/sh Thunar-0.9.0-4.fc9.i386 requires /bin/sh TnL-data-071111-1.fc9.noarch requires /bin/sh TurboGears-1.0.4.4-2.fc9.noarch requires /usr/bin/python VLGothic-fonts-20080429-1.fc10.noarch requires /bin/sh VLGothic-fonts-proportional-20080429-1.fc10.noarch requires /bin/sh WINGs-devel-0.92.0-17.fc9.i386 requires /bin/sh WINGs-libs-0.92.0-17.fc9.i386 requires /sbin/ldconfig WebKit-gtk-1.0.0-0.10.svn32531.fc10.i386 requires /sbin/ldconfig WindowMaker-0.92.0-17.fc9.i386 requires /sbin/ldconfig WindowMaker-0.92.0-17.fc9.i386 requires /usr/bin/perl WindowMaker-0.92.0-17.fc9.i386 requires /bin/sh WindowMaker-devel-0.92.0-17.fc9.i386 requires /bin/sh WritRecogn-0.1.9-0.fc10.i386 requires /bin/sh Xaw3d-1.5E-11.1.i386 requires /sbin/ldconfig Zim-0.23-2.fc9.noarch requires /usr/bin/perl a2ps-4.14-3.fc10.i386 requires /sbin/install-info a2ps-4.14-3.fc10.i386 requires /sbin/ldconfig a2ps-4.14-3.fc10.i386 requires /usr/bin/perl a2ps-4.14-3.fc10.i386 requires /bin/sh a2ps-4.14-3.fc10.i386 requires /bin/sh aalib-devel-1.4.0-0.15.rc5.fc9.i386 requires /bin/sh aalib-devel-1.4.0-0.15.rc5.fc9.i386 requires /sbin/install-info aalib-devel-1.4.0-0.15.rc5.fc9.i386 requires /bin/sh aalib-libs-1.4.0-0.15.rc5.fc9.i386 requires /sbin/ldconfig abcde-2.3.99.6-6.noarch requires /bin/bash abcde-2.3.99.6-6.noarch requires /bin/sh abcde-2.3.99.6-6.noarch requires /usr/bin/python 1:abiword-2.6.3-1.fc9.i386 requires /usr/bin/perl 1:abiword-2.6.3-1.fc9.i386 requires /bin/sh 1:abiword-2.6.3-1.fc9.i386 requires /bin/sh abuse-0.7.1-1.fc9.i386 requires /bin/sh abyssinica-fonts-1.0-2.fc8.noarch requires /bin/sh ack-1.78-1.fc9.noarch requires /usr/bin/perl acpid-1.0.6-7.fc9.i386 requires /bin/sh acpid-1.0.6-7.fc9.i386 requires /bin/bash acpid-1.0.6-7.fc9.i386 requires /sbin/chkconfig acpid-1.0.6-7.fc9.i386 requires /bin/sh acpid-1.0.6-7.fc9.i386 requires /sbin/service adanaxisgpl-1.2.5-2.fc9.i386 requires /bin/sh adaptx-0.9.13-5jpp.3.fc9.i386 requires /bin/sh adaptx-javadoc-0.9.13-5jpp.3.fc9.i386 requires /bin/sh adaptx-javadoc-0.9.13-5jpp.3.fc9.i386 requires /bin/rm adaptx-javadoc-0.9.13-5jpp.3.fc9.i386 requires /bin/ln adime-2.2.1-7.fc9.i386 requires /sbin/ldconfig adime-devel-2.2.1-7.fc9.i386 requires /bin/sh adime-devel-2.2.1-7.fc9.i386 requires /sbin/install-info adminutil-1.1.6-1.fc9.i386 requires /sbin/ldconfig adns-1.4-3.fc9.i386 requires /sbin/ldconfig adplug-2.1-6.fc9.i386 requires /sbin/ldconfig adplug-devel-2.1-6.fc9.i386 requires /bin/sh adplug-devel-2.1-6.fc9.i386 requires /sbin/install-info afflib-3.1.6-1.fc9.i386 requires /sbin/ldconfig agave-0.4.2-7.fc9.i386 requires /bin/sh agg-2.5-6.fc9.i386 requires /sbin/ldconfig agistudio-1.2.3-7.fc9.i386 requires /bin/sh aiccu-2007.01.15-3.fc9.i386 requires /bin/sh aiccu-2007.01.15-3.fc9.i386 requires /bin/sh 1:aiksaurus-1.2.1-15.fc6.i386 requires /sbin/ldconfig 1:aiksaurus-gtk-1.2.1-15.fc6.i386 requires /bin/sh aircrack-ng-0.9.3-1.fc9.i386 requires /bin/sh akode-2.0.2-5.fc9.i386 requires /sbin/ldconfig akode-devel-2.0.2-5.fc9.i386 requires /bin/sh akonadi-0.80.0-2.fc10.i386 requires /bin/sh akonadi-0.80.0-2.fc10.i386 requires /sbin/ldconfig alacarte-0.11.5-1.fc9.noarch requires /bin/sh alacarte-0.11.5-1.fc9.noarch requires /usr/bin/python2.5 alchemist-1.0.37-4.fc9.i386 requires /usr/bin/python alchemist-1.0.37-4.fc9.i386 requires /sbin/ldconfig aldrin-0.11-6.fc8.noarch requires /bin/sh aldrin-0.11-6.fc8.noarch requires /usr/bin/python alex4-1.0-6.fc9.i386 requires /bin/sh alexandria-0.6.3-4.fc9.noarch requires /bin/sh alexandria-0.6.3-4.fc9.noarch requires /usr/bin/env alfont-2.0.6-4.fc9.i386 requires /sbin/ldconfig alienarena-6.10-6.fc9.i386 requires /bin/bash alienarena-data-20071011-2.fc9.noarch requires /bin/sh alienblaster-1.1.0-4.fc9.i386 requires /bin/sh alienblaster-1.1.0-4.fc9.i386 requires /bin/bash alleggl-0.4.3-3.fc9.i386 requires /sbin/ldconfig allegro-4.2.2-10.fc10.i386 requires /bin/sh allegro-4.2.2-10.fc10.i386 requires /sbin/ldconfig allegro-devel-4.2.2-10.fc10.i386 requires /bin/sh allegro-devel-4.2.2-10.fc10.i386 requires /sbin/install-info allegro-devel-4.2.2-10.fc10.i386 requires /bin/sh alleyoop-0.9.3-4.fc9.i386 requires /bin/sh alliance-5.0-13.20070718snap.fc9.i386 requires /bin/sh alliance-5.0-13.20070718snap.fc9.i386 requires /bin/sh alltray-0.70-2.fc9.i386 requires /sbin/ldconfig alphabet-soup-1.1-4.fc9.i386 requires /bin/sh alsa-lib-1.0.16-3.fc9.i386 requires /sbin/ldconfig alsa-lib-1.0.16-3.fc9.i386 requires /bin/sh alsa-oss-1.0.15-0.1.fc9.i386 requires /bin/sh alsa-oss-libs-1.0.15-0.1.fc9.i386 requires /sbin/ldconfig alsa-utils-1.0.16-3.fc10.i386 requires /bin/bash 5:am-utils-6.1.5-8.fc9.i386 requires /bin/sh 5:am-utils-6.1.5-8.fc9.i386 requires /sbin/install-info 5:am-utils-6.1.5-8.fc9.i386 requires /bin/sh 5:am-utils-6.1.5-8.fc9.i386 requires /bin/grep 5:am-utils-6.1.5-8.fc9.i386 requires /usr/bin/perl 5:am-utils-6.1.5-8.fc9.i386 requires /bin/bash 5:am-utils-6.1.5-8.fc9.i386 requires /sbin/chkconfig amanda-2.5.2p1-10.fc9.i386 requires /sbin/ldconfig amanda-2.5.2p1-10.fc9.i386 requires /bin/sh amanda-2.5.2p1-10.fc9.i386 requires /usr/bin/Mail amanda-client-2.5.2p1-10.fc9.i386 requires /bin/sh amanda-client-2.5.2p1-10.fc9.i386 requires /sbin/service amanda-client-2.5.2p1-10.fc9.i386 requires /bin/sh amanda-server-2.5.2p1-10.fc9.i386 requires /sbin/service amanda-server-2.5.2p1-10.fc9.i386 requires /usr/bin/perl amanda-server-2.5.2p1-10.fc9.i386 requires /bin/sh amanda-server-2.5.2p1-10.fc9.i386 requires /bin/sh amanith-0.3-9.fc9.i386 requires /sbin/ldconfig amarok-1.4.8-5.fc9.i386 requires /bin/sh amarok-1.4.8-5.fc9.i386 requires /usr/bin/env amarokFS-0.5-3.fc9.i386 requires /bin/sh amarokFS-0.5-3.fc9.i386 requires /usr/bin/env amavisd-new-2.5.2-2.fc8.noarch requires /bin/sh amavisd-new-2.5.2-2.fc8.noarch requires /usr/sbin/useradd amavisd-new-2.5.2-2.fc8.noarch requires /sbin/service amavisd-new-2.5.2-2.fc8.noarch requires /usr/sbin/clamd amavisd-new-2.5.2-2.fc8.noarch requires /usr/bin/ar amavisd-new-2.5.2-2.fc8.noarch requires /usr/sbin/tmpwatch amavisd-new-2.5.2-2.fc8.noarch requires /etc/cron.daily amavisd-new-2.5.2-2.fc8.noarch requires /bin/bash amavisd-new-2.5.2-2.fc8.noarch requires /bin/sh amavisd-new-2.5.2-2.fc8.noarch requires /usr/bin/perl amavisd-new-2.5.2-2.fc8.noarch requires /etc/clamd.d amavisd-new-2.5.2-2.fc8.noarch requires /sbin/chkconfig amoebax-0.2.0-3.fc9.i386 requires /bin/sh amsn-0.97-3.fc9.i386 requires /bin/sh amsn-0.97-3.fc9.i386 requires /usr/bin/tclsh amsn-0.97-3.fc9.i386 requires /usr/bin/env amsn-0.97-3.fc9.i386 requires /usr/bin/wish amsn-0.97-3.fc9.i386 requires /bin/sh amtterm-1.0-2.fc9.i386 requires /usr/bin/perl anaconda-11.4.1.1-1.i386 requires /bin/sh anaconda-11.4.1.1-1.i386 requires /usr/bin/python anaconda-11.4.1.1-1.i386 requires /bin/sh anaconda-runtime-11.4.1.1-1.i386 requires /usr/bin/env anaconda-runtime-11.4.1.1-1.i386 requires /usr/bin/python anaconda-runtime-11.4.1.1-1.i386 requires /bin/bash anaconda-runtime-11.4.1.1-1.i386 requires /bin/sh anacron-2.3-59.fc9.i386 requires /bin/sh anacron-2.3-59.fc9.i386 requires /sbin/chkconfig anacron-2.3-59.fc9.i386 requires /bin/sh anacron-2.3-59.fc9.i386 requires /sbin/service and-1.2.2-6.fc9.i386 requires /bin/sh and-1.2.2-6.fc9.i386 requires /sbin/chkconfig and-1.2.2-6.fc9.i386 requires /bin/sh and-1.2.2-6.fc9.i386 requires /sbin/service angrydd-1.0.1-3.fc8.noarch requires /bin/sh angrydd-1.0.1-3.fc8.noarch requires /usr/bin/env animorph-0.3-3.fc9.i386 requires /sbin/ldconfig 1:anjuta-2.2.3-7.fc9.i386 requires /bin/sh 1:anjuta-2.2.3-7.fc9.i386 requires /sbin/ldconfig 1:anjuta-2.2.3-7.fc9.i386 requires /usr/bin/perl 1:anjuta-2.2.3-7.fc9.i386 requires /bin/bash 1:anjuta-doc-2.2.3-7.fc9.i386 requires /bin/sh ant-1.7.0-1jpp.4.fc9.i386 requires /bin/sh ant-antlr-1.7.0-1jpp.4.fc9.i386 requires /bin/sh ant-apache-bcel-1.7.0-1jpp.4.fc9.i386 requires /bin/sh ant-apache-bsf-1.7.0-1jpp.4.fc9.i386 requires /bin/sh ant-apache-log4j-1.7.0-1jpp.4.fc9.i386 requires /bin/sh ant-apache-oro-1.7.0-1jpp.4.fc9.i386 requires /bin/sh ant-apache-regexp-1.7.0-1jpp.4.fc9.i386 requires /bin/sh ant-apache-resolver-1.7.0-1jpp.4.fc9.i386 requires /bin/sh ant-commons-logging-1.7.0-1jpp.4.fc9.i386 requires /bin/sh ant-commons-net-1.7.0-1jpp.4.fc9.i386 requires /bin/sh ant-contrib-1.0-0.5.b2.fc9.i386 requires /bin/sh ant-javamail-1.7.0-1jpp.4.fc9.i386 requires /bin/sh ant-jdepend-1.7.0-1jpp.4.fc9.i386 requires /bin/sh ant-jmf-1.7.0-1jpp.4.fc9.i386 requires /bin/sh ant-jsch-1.7.0-1jpp.4.fc9.i386 requires /bin/sh ant-junit-1.7.0-1jpp.4.fc9.i386 requires /bin/sh ant-nodeps-1.7.0-1jpp.4.fc9.i386 requires /bin/sh ant-scripts-1.7.0-1jpp.4.fc9.i386 requires /usr/bin/python ant-swing-1.7.0-1jpp.4.fc9.i386 requires /bin/sh ant-trax-1.7.0-1jpp.4.fc9.i386 requires /bin/sh anthy-9100e-2.fc9.i386 requires /sbin/ldconfig antiword-0.37-7.fc9.i386 requires /bin/sh antlr-2.7.7-1jpp.7.fc9.i386 requires /usr/sbin/update-alternatives antlr-2.7.7-1jpp.7.fc9.i386 requires /bin/sh antlr-2.7.7-1jpp.7.fc9.i386 requires /bin/sh antlr-javadoc-2.7.7-1jpp.7.fc9.i386 requires /bin/sh antlr-javadoc-2.7.7-1jpp.7.fc9.i386 requires /bin/rm antlr-javadoc-2.7.7-1jpp.7.fc9.i386 requires /bin/ln ants-1.4-4.fc9.i386 requires /bin/sh anyremote-data-4.4-1.fc8.i386 requires /usr/bin/env aoetools-23-1.fc9.i386 requires /bin/bash aoetools-23-1.fc9.i386 requires /bin/sh apcupsd-3.14.3-2.1.fc9.i386 requires /bin/sh apcupsd-3.14.3-2.1.fc9.i386 requires /sbin/service apcupsd-3.14.3-2.1.fc9.i386 requires /bin/sh apcupsd-3.14.3-2.1.fc9.i386 requires /sbin/chkconfig apcupsd-3.14.3-2.1.fc9.i386 requires /bin/mail apg-2.3.0b-6.fc9.i386 requires /bin/sh aplus-fsf-4.22.1-3.fc10.i386 requires /sbin/ldconfig 1:apmd-3.2.2-7.i386 requires /bin/sh 1:apmd-3.2.2-7.i386 requires /bin/bash 1:apmd-3.2.2-7.i386 requires /bin/sh apollon-1.0.1-13.fc9.i386 requires /bin/sh apollon-libs-1.0.1-13.fc9.i386 requires /sbin/ldconfig apr-1.2.12-2.fc9.i386 requires /sbin/ldconfig apr-devel-1.2.12-2.fc9.i386 requires /bin/sh apr-util-1.2.12-5.fc9.i386 requires /sbin/ldconfig apr-util-devel-1.2.12-5.fc9.i386 requires /bin/sh aprsd-2.2.5-15.3.fc9.i386 requires /bin/sh aprsd-2.2.5-15.3.fc9.i386 requires /sbin/service aprsd-2.2.5-15.3.fc9.i386 requires /bin/bash aprsd-2.2.5-15.3.fc9.i386 requires /sbin/chkconfig apt-0.5.15lorg3.94-3.fc9.i386 requires /bin/sh apt-0.5.15lorg3.94-3.fc9.i386 requires /sbin/ldconfig apt-0.5.15lorg3.94-3.fc9.i386 requires /bin/bash apt-0.5.15lorg3.94-3.fc9.i386 requires /bin/sh aqbanking-2.3.3-3.fc9.i386 requires /sbin/ldconfig aqbanking-devel-2.3.3-3.fc9.i386 requires /bin/sh aqsis-1.2.0-8.fc9.i386 requires /usr/bin/env aqsis-1.2.0-8.fc9.i386 requires /sbin/ldconfig aqsis-data-1.2.0-8.fc9.i386 requires /bin/bash archivemail-0.7.2-1.fc9.noarch requires /usr/bin/env archmage-0.1.9-2.fc9.noarch requires /usr/bin/python ardour-2.4.1-1.fc9.i386 requires /bin/sh ardour-2.4.1-1.fc9.i386 requires /bin/sh argus-2.0.6.fixes.1-15.fc9.i386 requires /sbin/chkconfig argus-2.0.6.fixes.1-15.fc9.i386 requires /bin/sh argus-2.0.6.fixes.1-15.fc9.i386 requires /bin/sh arj-3.10.22-4.fc9.i386 requires /bin/sh arm-gp2x-linux-gcc-4.1.2-8.fc9.i386 requires /bin/sh armacycles-ad-0.2.8.2.1-6.fc9.i386 requires /bin/sh armacycles-ad-0.2.8.2.1-6.fc9.i386 requires /bin/bash armacycles-ad-dedicated-0.2.8.2.1-6.fc9.i386 requires /bin/bash arp-scan-1.6-2.fc9.i386 requires /usr/bin/perl arpack-2.1-7.fc9.i386 requires /sbin/ldconfig arptables_jf-0.0.8-12.fc9.i386 requires /bin/sh arptables_jf-0.0.8-12.fc9.i386 requires /bin/sh 14:arpwatch-2.1a15-8.fc9.i386 requires /bin/sh 14:arpwatch-2.1a15-8.fc9.i386 requires /bin/bash 14:arpwatch-2.1a15-8.fc9.i386 requires /sbin/chkconfig 14:arpwatch-2.1a15-8.fc9.i386 requires /bin/sh 14:arpwatch-2.1a15-8.fc9.i386 requires /sbin/service arrows-0.6-6.fc9.i386 requires /bin/sh 8:arts-1.5.9-3.fc10.i386 requires /sbin/ldconfig 8:arts-1.5.9-3.fc10.i386 requires /bin/sh 8:arts-devel-1.5.9-3.fc10.i386 requires /bin/sh artwiz-aleczapka-fonts-1.3-5.fc8.1.noarch requires /bin/sh asc-2.1.0.0-1.fc10.i386 requires /bin/sh asciidoc-8.2.5-2.fc9.noarch requires /usr/bin/env asm2-2.2.3-2jpp.1.fc9.noarch requires /bin/sh 12:aspell-0.60.6-1.fc10.i386 requires /bin/sh 12:aspell-0.60.6-1.fc10.i386 requires /sbin/install-info 12:aspell-0.60.6-1.fc10.i386 requires /sbin/ldconfig 12:aspell-0.60.6-1.fc10.i386 requires /bin/sh 12:aspell-devel-0.60.6-1.fc10.i386 requires /bin/sh 12:aspell-devel-0.60.6-1.fc10.i386 requires /sbin/install-info 12:aspell-devel-0.60.6-1.fc10.i386 requires /bin/sh asterisk-1.6.0-0.13.beta8.fc10.i386 requires /bin/sh asterisk-1.6.0-0.13.beta8.fc10.i386 requires /usr/sbin/groupadd asterisk-1.6.0-0.13.beta8.fc10.i386 requires /usr/sbin/useradd asterisk-1.6.0-0.13.beta8.fc10.i386 requires /sbin/service asterisk-1.6.0-0.13.beta8.fc10.i386 requires /bin/bash asterisk-1.6.0-0.13.beta8.fc10.i386 requires /bin/sh asterisk-1.6.0-0.13.beta8.fc10.i386 requires /sbin/chkconfig asterisk-misdn-1.6.0-0.13.beta8.fc10.i386 requires /bin/sh asterisk-misdn-1.6.0-0.13.beta8.fc10.i386 requires /usr/sbin/usermod asterisk-voicemail-1.6.0-0.13.beta8.fc10.i386 requires /usr/bin/sox asterisk-zaptel-1.6.0-0.13.beta8.fc10.i386 requires /bin/sh asterisk-zaptel-1.6.0-0.13.beta8.fc10.i386 requires /usr/sbin/usermod astromenace-1.2-8.fc9.i386 requires /bin/sh asylum-0.2.3-3.fc9.i386 requires /bin/sh asymptote-1.42-3.fc10.i386 requires /bin/sh asymptote-1.42-3.fc10.i386 requires /usr/bin/env at-3.1.10-23.fc9.i386 requires /bin/sh at-3.1.10-23.fc9.i386 requires /bin/bash at-3.1.10-23.fc9.i386 requires /bin/sh at-spi-1.22.1-2.fc10.i386 requires /sbin/ldconfig aterm-1.0.1-2.fc9.i386 requires /bin/sh athcool-0.3.12-2.fc9.i386 requires /bin/sh athcool-0.3.12-2.fc9.i386 requires /sbin/chkconfig athcool-0.3.12-2.fc9.i386 requires /bin/sh athcool-0.3.12-2.fc9.i386 requires /sbin/service atitvout-0.4-8.i386 requires /usr/bin/consolehelper atk-1.22.0-1.fc9.i386 requires /sbin/ldconfig atlas-3.6.0-15.fc10.i386 requires /etc/ld.so.conf.d atlas-3.6.0-15.fc10.i386 requires /sbin/ldconfig atlas-3dnow-3.6.0-15.fc10.i386 requires /sbin/ldconfig atlas-sse-3.6.0-15.fc10.i386 requires /sbin/ldconfig atlas-sse2-3.6.0-15.fc10.i386 requires /sbin/ldconfig atlascpp-0.6.1-3.fc9.i386 requires /sbin/ldconfig atomorun-1.1-0.8.pre2.fc9.i386 requires /bin/sh atop-1.23-7.fc10.i386 requires /bin/sh atop-1.23-7.fc10.i386 requires /bin/bash atop-1.23-7.fc10.i386 requires /sbin/chkconfig atop-1.23-7.fc10.i386 requires /sbin/service audacious-1.4.6-1.fc9.i386 requires /bin/sh audacious-devel-1.4.6-1.fc9.i386 requires /sbin/ldconfig audacious-libs-1.4.6-1.fc9.i386 requires /sbin/ldconfig audacious-plugins-1.4.5-1.fc9.i386 requires /bin/sh audacious-plugins-1.4.5-1.fc9.i386 requires /sbin/ldconfig audacity-1.3.5-0.4.beta.fc10.i386 requires /bin/sh audio-convert-mod-3.45.4-1.fc10.noarch requires /bin/bash audio-entropyd-1.0.1-2.fc9.i386 requires /bin/sh audio-entropyd-1.0.1-2.fc9.i386 requires /bin/sh 1:audiofile-0.2.6-8.fc9.i386 requires /sbin/ldconfig 1:audiofile-devel-0.2.6-8.fc9.i386 requires /bin/sh audispd-plugins-1.7.3-1.fc10.i386 requires /bin/sh audispd-plugins-1.7.3-1.fc10.i386 requires /usr/sbin/semodule audispd-plugins-1.7.3-1.fc10.i386 requires /sbin/restorecon audit-1.7.3-1.fc10.i386 requires /bin/sh audit-1.7.3-1.fc10.i386 requires /bin/bash audit-libs-1.7.3-1.fc10.i386 requires /sbin/ldconfig audit-viewer-0.2-2.fc10.i386 requires /bin/sh audit-viewer-0.2-2.fc10.i386 requires /bin/sh augeas-libs-0.1.1-1.fc10.i386 requires /sbin/ldconfig aumix-2.8-17.fc9.i386 requires /bin/sh auriferous-1.0.1-5.fc9.i386 requires /bin/sh authconfig-5.4.2-1.fc9.i386 requires /bin/sh authconfig-5.4.2-1.fc9.i386 requires /usr/bin/python authconfig-gtk-5.4.2-1.fc9.i386 requires /usr/bin/python authd-1.4.3-19.fc9.i386 requires /bin/sh autobuild-applet-1.0.3-5.fc9.i386 requires /usr/bin/python autobuild-applet-1.0.3-5.fc9.i386 requires /bin/sh autoconf-2.62-1.fc10.noarch requires /bin/sh autoconf-2.62-1.fc10.noarch requires /sbin/install-info autoconf-2.62-1.fc10.noarch requires /usr/bin/perl autoconf-2.62-1.fc10.noarch requires /bin/sh autoconf213-2.13-18.fc8.noarch requires /bin/sh autoconf213-2.13-18.fc8.noarch requires /usr/bin/perl autoconf213-2.13-18.fc8.noarch requires /sbin/install-info autoconf213-2.13-18.fc8.noarch requires /bin/sh autodir-0.99.9-5.fc9.i386 requires /bin/sh autodir-0.99.9-5.fc9.i386 requires /sbin/service autodir-0.99.9-5.fc9.i386 requires /bin/sh autodir-0.99.9-5.fc9.i386 requires /sbin/chkconfig autodownloader-0.2.0-6.fc9.noarch requires /usr/bin/env 1:autofs-5.0.3-16.i386 requires /bin/sh 1:autofs-5.0.3-16.i386 requires /bin/ps 1:autofs-5.0.3-16.i386 requires /sbin/service 1:autofs-5.0.3-16.i386 requires /bin/bash 1:autofs-5.0.3-16.i386 requires /sbin/chkconfig autogen-5.9.4-4.fc9.i386 requires /bin/sh autogen-5.9.4-4.fc9.i386 requires /sbin/install-info autogen-libopts-5.9.4-4.fc9.i386 requires /sbin/ldconfig autogen-libopts-devel-5.9.4-4.fc9.i386 requires /bin/sh automake-1.10.1-2.noarch requires /bin/sh automake-1.10.1-2.noarch requires /sbin/install-info automake-1.10.1-2.noarch requires /bin/sh automake-1.10.1-2.noarch requires /usr/bin/perl automake14-1.4p6-15.fc7.noarch requires /bin/sh automake14-1.4p6-15.fc7.noarch requires /usr/bin/perl automake14-1.4p6-15.fc7.noarch requires /sbin/install-info automake14-1.4p6-15.fc7.noarch requires /bin/sh automake15-1.5-23.noarch requires /bin/sh automake15-1.5-23.noarch requires /usr/bin/perl automake15-1.5-23.noarch requires /sbin/install-info automake15-1.5-23.noarch requires /bin/sh automake16-1.6.3-14.noarch requires /bin/sh automake16-1.6.3-14.noarch requires /sbin/install-info automake16-1.6.3-14.noarch requires /bin/sh automake16-1.6.3-14.noarch requires /usr/bin/perl automake17-1.7.9-11.noarch requires /bin/sh automake17-1.7.9-11.noarch requires /sbin/install-info automake17-1.7.9-11.noarch requires /bin/sh automake17-1.7.9-11.noarch requires /usr/bin/perl autossh-1.4a-1.fc9.i386 requires /usr/bin/ssh autotrace-0.31.1-16.fc9.i386 requires /sbin/ldconfig autotrace-0.31.1-16.fc9.i386 requires libWand.so.10 autotrace-0.31.1-16.fc9.i386 requires libMagick.so.10 autotrace-devel-0.31.1-16.fc9.i386 requires /bin/sh avahi-0.6.22-10.fc9.i386 requires /bin/sh avahi-0.6.22-10.fc9.i386 requires /bin/sh avahi-autoipd-0.6.22-10.fc9.i386 requires /bin/sh avahi-autoipd-0.6.22-10.fc9.i386 requires /bin/sh avahi-compat-howl-0.6.22-10.fc9.i386 requires /sbin/ldconfig avahi-compat-libdns_sd-0.6.22-10.fc9.i386 requires /sbin/ldconfig avahi-dnsconfd-0.6.22-10.fc9.i386 requires /bin/sh avahi-dnsconfd-0.6.22-10.fc9.i386 requires /bin/sh avahi-glib-0.6.22-10.fc9.i386 requires /sbin/ldconfig avahi-gobject-0.6.22-10.fc9.i386 requires /sbin/ldconfig avahi-qt3-0.6.22-10.fc9.i386 requires /sbin/ldconfig avahi-tools-0.6.22-10.fc9.i386 requires /usr/bin/python avahi-ui-0.6.22-10.fc9.i386 requires /sbin/ldconfig avalon-framework-4.1.4-3jpp.14.fc9.i386 requires /bin/sh avalon-framework-javadoc-4.1.4-3jpp.14.fc9.i386 requires /bin/rm avalon-framework-javadoc-4.1.4-3jpp.14.fc9.i386 requires /bin/ln avalon-logkit-1.2-5jpp.5.fc9.i386 requires /bin/sh avalon-logkit-javadoc-1.2-5jpp.5.fc9.i386 requires /bin/sh avalon-logkit-javadoc-1.2-5jpp.5.fc9.i386 requires /bin/rm avalon-logkit-javadoc-1.2-5jpp.5.fc9.i386 requires /bin/ln avant-window-navigator-0.2.6-8.fc9.i386 requires /bin/sh avant-window-navigator-0.2.6-8.fc9.i386 requires /usr/bin/env avant-window-navigator-0.2.6-8.fc9.i386 requires /usr/bin/python avant-window-navigator-0.2.6-8.fc9.i386 requires /bin/bash avarice-2.6-2.fc9.i386 requires /usr/bin/perl avarice-2.6-2.fc9.i386 requires /bin/sh avr-gcc-4.1.2-6.fc9.i386 requires /bin/sh avr-libc-1.4.6-4.fc8.noarch requires /bin/sh avrdude-5.5-3.fc9.i386 requires /bin/sh avrdude-5.5-3.fc9.i386 requires /sbin/install-info awn-extras-applets-0.2.6-4.fc9.i386 requires /usr/bin/python awn-extras-applets-0.2.6-4.fc9.i386 requires /usr/bin/env awn-extras-applets-0.2.6-4.fc9.i386 requires /bin/sh awstats-6.7-3.fc9.noarch requires /bin/bash awstats-6.7-3.fc9.noarch requires /usr/bin/perl awstats-6.7-3.fc9.noarch requires /bin/sh awstats-6.7-3.fc9.noarch requires /sbin/service awstats-selinux-6.7-3.fc9.noarch requires /bin/sh ax25-tools-0.0.8-2.fc9.i386 requires /bin/sh axis-1.2.1-3jpp.8.fc9.i386 requires /bin/sh azureus-3.0.4.2-14.fc9.i386 requires /bin/sh azureus-3.0.4.2-14.fc9.i386 requires /bin/sh babel-0.9.2-1.fc9.noarch requires /usr/bin/python babl-0.0.20-1.fc9.i386 requires /sbin/ldconfig bacula-client-2.0.3-13.fc9.i386 requires /bin/sh bacula-client-2.0.3-13.fc9.i386 requires /sbin/service bacula-client-2.0.3-13.fc9.i386 requires /bin/bash bacula-client-2.0.3-13.fc9.i386 requires /sbin/chkconfig bacula-common-2.0.3-13.fc9.i386 requires /bin/sh bacula-common-2.0.3-13.fc9.i386 requires /bin/sh bacula-director-common-2.0.3-13.fc9.i386 requires /bin/sh bacula-director-common-2.0.3-13.fc9.i386 requires /bin/bash bacula-director-common-2.0.3-13.fc9.i386 requires /bin/sh bacula-director-common-2.0.3-13.fc9.i386 requires /usr/bin/perl bacula-director-mysql-2.0.3-13.fc9.i386 requires /bin/sh bacula-director-mysql-2.0.3-13.fc9.i386 requires /bin/sh bacula-director-postgresql-2.0.3-13.fc9.i386 requires /bin/sh bacula-director-postgresql-2.0.3-13.fc9.i386 requires /bin/sh bacula-director-sqlite-2.0.3-13.fc9.i386 requires /bin/sh bacula-director-sqlite-2.0.3-13.fc9.i386 requires /bin/sh bacula-storage-common-2.0.3-13.fc9.i386 requires /bin/sh bacula-storage-common-2.0.3-13.fc9.i386 requires /usr/bin/python bacula-storage-common-2.0.3-13.fc9.i386 requires /bin/bash bacula-storage-common-2.0.3-13.fc9.i386 requires /bin/sh bacula-storage-mysql-2.0.3-13.fc9.i386 requires /bin/sh bacula-storage-postgresql-2.0.3-13.fc9.i386 requires /bin/sh bacula-storage-sqlite-2.0.3-13.fc9.i386 requires /bin/sh baekmuk-bdf-fonts-2.2-5.fc9.noarch requires /bin/sh baekmuk-ttf-fonts-batang-2.2-7.fc9.noarch requires /bin/sh baekmuk-ttf-fonts-dotum-2.2-7.fc9.noarch requires /bin/sh baekmuk-ttf-fonts-gulim-2.2-7.fc9.noarch requires /bin/sh baekmuk-ttf-fonts-hline-2.2-7.fc9.noarch requires /bin/sh bakery-2.4.4-2.fc9.i386 requires /sbin/ldconfig ballbuster-1.0-5.fc9.i386 requires /bin/sh ballz-1.0-3.fc9.i386 requires /bin/sh balsa-2.3.23-1.fc9.i386 requires /bin/sh banshee-0.99.1-1.1.fc10.i386 requires /bin/sh banshee-0.99.1-1.1.fc10.i386 requires /bin/bash barcode-0.98-11.fc9.i386 requires /bin/sh barcode-0.98-11.fc9.i386 requires /sbin/install-info bash-3.2-22.fc9.i386 requires /bin/sh bash-3.2-22.fc9.i386 requires /bin/bash bash-3.2-22.fc9.i386 requires /bin/sh bash-completion-20060301-10.noarch requires /bin/sh basket-1.0.2-5.fc9.i386 requires /bin/sh bazaar-1.4.2-11.fc9.i386 requires /usr/bin/gawk bc-1.06-33.fc9.i386 requires /bin/sh bc-1.06-33.fc9.i386 requires /sbin/install-info bcel-5.2-4jpp.2.fc9.i386 requires /bin/sh bcfg2-0.9.5.7-1.fc9.noarch requires /bin/sh bcfg2-0.9.5.7-1.fc9.noarch requires /sbin/chkconfig bcfg2-0.9.5.7-1.fc9.noarch requires /bin/sh bcfg2-0.9.5.7-1.fc9.noarch requires /usr/bin/python bcfg2-0.9.5.7-1.fc9.noarch requires /sbin/service bcfg2-server-0.9.5.7-1.fc9.noarch requires /bin/sh bcfg2-server-0.9.5.7-1.fc9.noarch requires /usr/bin/openssl bcfg2-server-0.9.5.7-1.fc9.noarch requires /sbin/chkconfig bcfg2-server-0.9.5.7-1.fc9.noarch requires /bin/sh bcfg2-server-0.9.5.7-1.fc9.noarch requires /usr/bin/python bcfg2-server-0.9.5.7-1.fc9.noarch requires /sbin/service 1:bdftruncate-7.2-4.fc9.i386 requires /usr/bin/perl bea-stax-1.2.0-0.2.rc1.2jpp.1.fc9.i386 requires /bin/sh bea-stax-api-1.2.0-0.2.rc1.2jpp.1.fc9.i386 requires /bin/sh beagle-0.3.7-3.fc9.i386 requires /bin/sh beagle-0.3.7-3.fc9.i386 requires /bin/bash beagle-0.3.7-3.fc9.i386 requires /bin/sh beagle-devel-0.3.7-3.fc9.i386 requires /bin/sh beagle-gnome-0.3.7-3.fc9.i386 requires /bin/sh berusky-1.1-8.fc9.i386 requires /bin/sh bes-3.5.3-3.fc9.i386 requires /bin/sh bes-3.5.3-3.fc9.i386 requires /sbin/ldconfig bes-3.5.3-3.fc9.i386 requires /bin/sh bes-devel-3.5.3-3.fc9.i386 requires /bin/sh bibexport-2.10-2.fc9.noarch requires /usr/bin/texhash bibexport-2.10-2.fc9.noarch requires /bin/sh bibexport-2.10-2.fc9.noarch requires /bin/sh bibletime-1.6.5-4.fc9.i386 requires /bin/sh bibus-1.4.1-4.fc9.noarch requires /usr/bin/env bigboard-0.5.33-2.fc10.i386 requires /bin/sh bigboard-0.5.33-2.fc10.i386 requires /bin/sh bigloo-3.0b-2.fc9.i386 requires /bin/sh bigloo-3.0b-2.fc9.i386 requires /sbin/install-info bigloo-3.0b-2.fc9.i386 requires /bin/sh bigloo-libs-3.0b-2.fc9.i386 requires /sbin/ldconfig biloba-0.6-1.fc10.i386 requires /bin/sh 32:bind-9.5.0-33.rc1.fc10.i386 requires /bin/sh 32:bind-9.5.0-33.rc1.fc10.i386 requires /bin/bash 32:bind-9.5.0-33.rc1.fc10.i386 requires /bin/sh 32:bind-chroot-9.5.0-33.rc1.fc10.i386 requires /bin/sh 32:bind-chroot-9.5.0-33.rc1.fc10.i386 requires /bin/bash 32:bind-chroot-9.5.0-33.rc1.fc10.i386 requires /bin/sh 32:bind-devel-9.5.0-33.rc1.fc10.i386 requires /bin/sh 32:bind-libs-9.5.0-33.rc1.fc10.i386 requires /sbin/ldconfig 32:bind-sdb-9.5.0-33.rc1.fc10.i386 requires /bin/sh binutils-2.18.50.0.6-2.i386 requires /bin/sh binutils-2.18.50.0.6-2.i386 requires /sbin/ldconfig binutils-2.18.50.0.6-2.i386 requires /sbin/install-info binutils-devel-2.18.50.0.6-2.i386 requires /bin/sh binutils-devel-2.18.50.0.6-2.i386 requires /sbin/install-info bison-2.3-5.fc9.i386 requires /bin/sh bison-2.3-5.fc9.i386 requires /sbin/install-info bit-0.4.1-3.fc9.i386 requires /sbin/ldconfig bitbake-1.8.8-1.fc8.noarch requires /usr/bin/python bitgtkmm-0.4.0-2.fc7.i386 requires /sbin/ldconfig bitlbee-1.2-1.fc9.i386 requires /bin/sh bitlbee-1.2-1.fc9.i386 requires /sbin/service bitmap-1.0.3-4.fc9.i386 requires /bin/sh bitmap-fonts-0.3-5.2.fc9.noarch requires /bin/sh bitmap-fonts-cjk-0.3-5.2.fc9.noarch requires /bin/sh bitstream-vera-fonts-1.10-8.noarch requires /bin/sh bittorrent-4.4.0-6.fc9.noarch requires /bin/sh bittorrent-4.4.0-6.fc9.noarch requires /bin/bash bittorrent-4.4.0-6.fc9.noarch requires /sbin/chkconfig bittorrent-4.4.0-6.fc9.noarch requires /usr/sbin/useradd bittorrent-4.4.0-6.fc9.noarch requires /usr/bin/python bittorrent-4.4.0-6.fc9.noarch requires /sbin/service bittorrent-4.4.0-6.fc9.noarch requires /usr/sbin/usermod bittorrent-gui-4.4.0-6.fc9.noarch requires /bin/sh bittorrent-gui-4.4.0-6.fc9.noarch requires /usr/bin/python blackbox-0.70.1-11.i386 requires /sbin/ldconfig blackbox-0.70.1-11.i386 requires /bin/sh blacs-1.1-26.fc9.1.i386 requires /sbin/ldconfig blam-1.8.3-13.fc9.i386 requires /bin/sh blam-1.8.3-13.fc9.i386 requires /bin/bash blas-3.1.1-3.fc9.i386 requires /sbin/ldconfig blender-2.46-0.3.fc10.i386 requires /bin/sh blender-2.46-0.3.fc10.i386 requires /bin/sh bless-0.5.2-6.fc9.i386 requires /bin/sh bless-doc-0.5.2-6.fc9.i386 requires /bin/sh blitz-0.9-7.fc9.i386 requires /sbin/ldconfig blitz-0.9-7.fc9.i386 requires /sbin/install-info blitz-devel-0.9-7.fc9.i386 requires /bin/sh blktrace-0.0-0.9.20080103162505.fc9.i386 requires /bin/sh blobAndConquer-0.93-1.fc10.i386 requires /bin/sh blobby-0.6-0.7.a.fc8.i386 requires /bin/sh blobwars-1.07-2.fc9.i386 requires /bin/sh blogtk-1.1-9.fc9.noarch requires /usr/bin/env blogtk-1.1-9.fc9.noarch requires /bin/sh blt-2.4-27.fc9.i386 requires /sbin/ldconfig blt-2.4-27.fc9.i386 requires /usr/bin/wish blt-2.4-27.fc9.i386 requires /usr/bin/tclsh bluecurve-icon-theme-8.0.2-1.fc9.noarch requires /bin/sh bluefish-1.0.7-4.fc9.i386 requires /bin/sh bluez-gnome-0.25-1.fc9.i386 requires /bin/sh bluez-libs-3.31-1.fc10.i386 requires /sbin/ldconfig bluez-utils-3.31-1.fc10.i386 requires /bin/sh bluez-utils-3.31-1.fc10.i386 requires /sbin/service bluez-utils-3.31-1.fc10.i386 requires /bin/sh bluez-utils-3.31-1.fc10.i386 requires /sbin/chkconfig bmpx-0.40.13-11.fc9.i386 requires /bin/sh bmpx-0.40.13-11.fc9.i386 requires /bin/sh boa-0.94.14-0.10.rc21.fc9.i386 requires /bin/sh boa-0.94.14-0.10.rc21.fc9.i386 requires /bin/bash boa-0.94.14-0.10.rc21.fc9.i386 requires /etc/mime.types boa-0.94.14-0.10.rc21.fc9.i386 requires /sbin/chkconfig boa-0.94.14-0.10.rc21.fc9.i386 requires /usr/sbin/useradd boa-0.94.14-0.10.rc21.fc9.i386 requires /sbin/service bochs-dlxlinux-2.3.6-3.fc9.i386 requires /bin/sh bodhi-client-0.4.10-3.fc9.noarch requires /usr/bin/python bodhi-server-0.4.10-3.fc9.noarch requires /usr/bin/python bodhi-server-0.4.10-3.fc9.noarch requires /usr/bin/env bogl-0.1.18-14.i386 requires /sbin/ldconfig bogl-devel-0.1.18-14.i386 requires /usr/bin/perl bogofilter-1.1.6-2.fc9.i386 requires /usr/bin/perl bogofilter-1.1.6-2.fc9.i386 requires /bin/sh boinc-client-5.10.45-13.20080315svn.fc10.i386 requires /bin/sh boinc-client-5.10.45-13.20080315svn.fc10.i386 requires /bin/sh boinc-manager-5.10.45-13.20080315svn.fc10.i386 requires /bin/sh bolzplatz2006-1.0.3-6.fc9.i386 requires /bin/sh bolzplatz2006-1.0.3-6.fc9.i386 requires /bin/sh bombardier-0.8.2.2-8.fc9.i386 requires /bin/sh bonnie++-1.03a-9.fc9.i386 requires /usr/bin/perl bontmia-0.14-2.fc8.noarch requires /bin/bash boo-0.8.1.2865-4.fc9.i386 requires /bin/sh boo-0.8.1.2865-4.fc9.i386 requires /bin/sh boolstuff-0.1.11-5.fc9.i386 requires /sbin/ldconfig boost-1.34.1-13.fc9.i386 requires /sbin/ldconfig bootchart-0.9-9.fc9.i386 requires /bin/sh bootchart-0.9-9.fc9.i386 requires /bin/sh bootparamd-0.17-27.fc9.i386 requires /bin/sh bootparamd-0.17-27.fc9.i386 requires /sbin/chkconfig bootparamd-0.17-27.fc9.i386 requires /bin/sh bootparamd-0.17-27.fc9.i386 requires /sbin/service boswars-2.5-1.fc9.i386 requires /bin/sh bouml-4.3.3-1.fc10.i386 requires /bin/sh bouml-4.3.3-1.fc10.i386 requires /bin/sh bouncycastle-1.39-1.fc10.i386 requires /bin/sh bpython-0.3.1-2.fc10.noarch requires /usr/bin/python brasero-0.7.1-4.fc10.i386 requires /bin/sh brazil-2.3-3.fc10.i386 requires /usr/bin/rebuild-gcj-db brazil-demo-2.3-3.fc10.i386 requires /usr/bin/tclsh brazil-demo-2.3-3.fc10.i386 requires /bin/sh brettfont-fonts-20080506-2.fc10.noarch requires /bin/sh brltty-3.9-2.2.fc9.i386 requires /bin/sh brltty-3.9-2.2.fc9.i386 requires /bin/bash brltty-3.9-2.2.fc9.i386 requires /bin/sh 1:broffice.org-base-3.0.0-0.0.12.1.fc10.i386 requires /bin/sh 1:broffice.org-base-3.0.0-0.0.12.1.fc10.i386 requires /bin/sh 1:broffice.org-brand-3.0.0-0.0.12.1.fc10.i386 requires /bin/sh 1:broffice.org-brand-3.0.0-0.0.12.1.fc10.i386 requires /bin/sh 1:broffice.org-calc-3.0.0-0.0.12.1.fc10.i386 requires /bin/sh 1:broffice.org-calc-3.0.0-0.0.12.1.fc10.i386 requires /bin/sh 1:broffice.org-draw-3.0.0-0.0.12.1.fc10.i386 requires /bin/sh 1:broffice.org-draw-3.0.0-0.0.12.1.fc10.i386 requires /bin/sh 1:broffice.org-impress-3.0.0-0.0.12.1.fc10.i386 requires /bin/sh 1:broffice.org-impress-3.0.0-0.0.12.1.fc10.i386 requires /bin/sh 1:broffice.org-math-3.0.0-0.0.12.1.fc10.i386 requires /bin/sh 1:broffice.org-math-3.0.0-0.0.12.1.fc10.i386 requires /bin/sh 1:broffice.org-writer-3.0.0-0.0.12.1.fc10.i386 requires /bin/sh 1:broffice.org-writer-3.0.0-0.0.12.1.fc10.i386 requires /bin/sh brutus-keyring-devel-0.9.0-6.fc8.i386 requires /sbin/ldconfig bsd-games-2.17-23.fc9.i386 requires /bin/sh bsd-games-2.17-23.fc9.i386 requires /bin/sh bsd-games-2.17-23.fc9.i386 requires /usr/sbin/groupadd bsf-2.3.0-12jpp.2.fc9.i386 requires /bin/sh bsh-1.3.0-12jpp.3.fc9.i386 requires /bin/sh bsh-demo-1.3.0-12jpp.3.fc9.i386 requires /usr/bin/env bsh-desktop-1.3.0-12jpp.3.fc9.i386 requires /bin/sh 1:bug-buddy-2.22.0-3.fc10.i386 requires /bin/sh bugzilla-3.0.4-1.fc10.noarch requires /bin/sh bugzilla-3.0.4-1.fc10.noarch requires /bin/sh bugzilla-3.0.4-1.fc10.noarch requires /usr/bin/perl bugzilla-contrib-3.0.4-1.fc10.noarch requires /usr/bin/env bugzilla-contrib-3.0.4-1.fc10.noarch requires /usr/bin/python bugzilla-contrib-3.0.4-1.fc10.noarch requires /usr/bin/perl bugzilla-contrib-3.0.4-1.fc10.noarch requires /bin/sh bugzilla-contrib-3.0.4-1.fc10.noarch requires /usr/bin/ruby bugzilla-doc-3.0.4-1.fc10.noarch requires /usr/bin/perl buildbot-0.7.7-2.fc9.noarch requires /usr/bin/env buildbot-0.7.7-2.fc9.noarch requires /usr/bin/python buoh-0.8.2-4.fc9.i386 requires /bin/sh bwbar-1.2.3-2.i386 requires /bin/sh bwbar-1.2.3-2.i386 requires /bin/bash bwbar-1.2.3-2.i386 requires /sbin/service byzanz-0.1.1-6.fc9.i386 requires /bin/sh bzip2-1.0.5-1.fc9.i386 requires /bin/sh bzip2-libs-1.0.5-1.fc9.i386 requires /sbin/ldconfig bzr-1.4-2.fc10.i386 requires /usr/bin/python bzr-gtk-0.94.0-1.fc10.i386 requires /usr/bin/python c-ares-1.5.1-2.fc9.i386 requires /sbin/ldconfig cachefilesd-0.7-4.fc9.i386 requires /bin/sh cachefilesd-0.7-4.fc9.i386 requires /bin/bash cachefilesd-0.7-4.fc9.i386 requires /sbin/chkconfig cachefilesd-0.7-4.fc9.i386 requires /sbin/service cacti-0.8.7b-1.fc9.noarch requires /bin/sh cacti-0.8.7b-1.fc9.noarch requires /usr/bin/perl cacti-0.8.7b-1.fc9.noarch requires /usr/sbin/useradd cacti-0.8.7b-1.fc9.noarch requires /usr/bin/php cacti-0.8.7b-1.fc9.noarch requires /bin/sh cacti-0.8.7b-1.fc9.noarch requires /sbin/service cairo-1.6.4-1.fc9.i386 requires /sbin/ldconfig cairo-clock-0.3.4-1.fc9.i386 requires /sbin/ldconfig cairo-dock-1.5.5.4-4.date20080506.fc10.i386 requires /bin/sh cairo-dock-plug-ins-1.5.5.4-4.date20080506.fc10.i386 requires /bin/bash cairo-dock-plug-ins-1.5.5.4-4.date20080506.fc10.i386 requires /bin/sh cairo-java-1.0.5-9.fc9.i386 requires /sbin/ldconfig cairomm-1.5.0-1.fc9.i386 requires /sbin/ldconfig cal3d-0.11.0-6.fc9.i386 requires /sbin/ldconfig calc-libs-2.12.2.1-12.fc9.i386 requires /sbin/ldconfig calc-stdrc-2.12.2.1-12.fc9.i386 requires /usr/bin/calc callweaver-1.2-0.4.rc5.20071230.fc9.i386 requires /bin/sh callweaver-1.2-0.4.rc5.20071230.fc9.i386 requires /sbin/chkconfig callweaver-1.2-0.4.rc5.20071230.fc9.i386 requires /bin/bash callweaver-1.2-0.4.rc5.20071230.fc9.i386 requires /bin/sh callweaver-misdn-1.2-0.4.rc5.20071230.fc9.i386 requires /bin/sh callweaver-ogi-1.2-0.4.rc5.20071230.fc9.i386 requires /usr/bin/perl callweaver-zaptel-1.2-0.4.rc5.20071230.fc9.i386 requires /bin/sh castor-0.9.5-2jpp.8.fc9.i386 requires /bin/sh castor-0.9.5-2jpp.8.fc9.i386 requires /bin/sh castor-demo-0.9.5-2jpp.8.fc9.i386 requires /bin/sh castor-test-0.9.5-2jpp.8.fc9.i386 requires /bin/sh castor-xml-0.9.5-2jpp.8.fc9.i386 requires /bin/sh catdoc-0.94.2-4.fc9.i386 requires /usr/bin/wish catfish-0.3-1.fc8.noarch requires /usr/bin/locate catfish-0.3-1.fc8.noarch requires /usr/bin/env catfish-0.3-1.fc8.noarch requires /usr/bin/find ccache-2.4-13.fc9.i386 requires /bin/sh ccache-2.4-13.fc9.i386 requires /bin/sh ccid-1.2.1-4.fc9.i386 requires /bin/sh ccrtp-1.6.0-1.fc9.i386 requires /sbin/ldconfig ccrtp-devel-1.6.0-1.fc9.i386 requires /bin/sh ccrtp-devel-1.6.0-1.fc9.i386 requires /sbin/install-info ccsm-0.7.2-1.fc9.noarch requires /bin/sh ccsm-0.7.2-1.fc9.noarch requires /usr/bin/python cdcollect-0.6.0-5.fc9.i386 requires /bin/sh cdcollect-0.6.0-5.fc9.i386 requires /bin/sh cdlabelgen-4.0.0-1.fc8.noarch requires /usr/bin/perl cdogs-data-0.4-3.fc8.noarch requires /bin/sh cdparanoia-libs-alpha9.8-30.i386 requires /bin/sh cduce-0.5.2.1-9.fc10.i386 requires /bin/sh cegui-0.5.0b-7.fc9.i386 requires /sbin/ldconfig cel-1.2-2.fc9.i386 requires /sbin/ldconfig cel-devel-1.2-2.fc9.i386 requires /bin/sh celestia-1.5.0-1.fc9.i386 requires /bin/sh cellwriter-1.3.3-1.fc10.i386 requires /bin/sh 1:centerim-4.22.4-1.fc9.i386 requires /usr/bin/perl cernlib-2006-29.fc9.i386 requires /sbin/ldconfig cernlib-g77-2006-29.fc9.i386 requires /sbin/ldconfig cernlib-g77-utils-2006-29.fc9.i386 requires /bin/bash cernlib-g77-utils-2006-29.fc9.i386 requires /bin/sh cernlib-packlib-2006-29.fc9.i386 requires /bin/sh cernlib-packlib-g77-2006-29.fc9.i386 requires /bin/sh cernlib-packlib-gfortran-2006-29.fc9.i386 requires /bin/sh cernlib-utils-2006-29.fc9.i386 requires /bin/bash cernlib-utils-2006-29.fc9.i386 requires /bin/sh certmaster-0.19-1.fc9.noarch requires /bin/sh certmaster-0.19-1.fc9.noarch requires /bin/sh certmaster-0.19-1.fc9.noarch requires /usr/bin/python cfengine-2.2.6-1.fc10.i386 requires /bin/sh cfengine-2.2.6-1.fc10.i386 requires /sbin/install-info cfengine-2.2.6-1.fc10.i386 requires /sbin/service cfengine-2.2.6-1.fc10.i386 requires /bin/bash cfengine-2.2.6-1.fc10.i386 requires /bin/sh cfengine-2.2.6-1.fc10.i386 requires /sbin/chkconfig cfitsio-3.060-3.fc9.i386 requires /sbin/ldconfig cfv-1.18.1-4.fc8.1.noarch requires /usr/bin/env cgdb-0.6.4-3.fc9.i386 requires /bin/sh cgdb-0.6.4-3.fc9.i386 requires /sbin/install-info cgoban-1.9.14-9.fc9.i386 requires /bin/sh charis-fonts-4.100-5.fc9.noarch requires /bin/sh check-0.9.5-2.fc9.1.i386 requires /bin/sh check-0.9.5-2.fc9.1.i386 requires /sbin/ldconfig check-0.9.5-2.fc9.1.i386 requires /sbin/install-info checkgmail-1.13-3.fc9.noarch requires /usr/bin/perl checkstyle-4.1-4jpp.3.fc9.noarch requires /bin/sh checkstyle-4.1-4jpp.3.fc9.noarch requires /usr/bin/perl checkstyle-optional-4.1-4jpp.3.fc9.noarch requires /bin/sh cheese-2.23.2-1.fc10.i386 requires /bin/sh cheese-2.23.2-1.fc10.i386 requires /bin/sh chemical-mime-data-0.1.94-3.fc8.noarch requires /bin/sh chemtool-1.6.11-3.fc9.i386 requires /bin/sh chess-1.0-14.fc10.i386 requires /bin/sh chess-1.0-14.fc10.i386 requires /usr/share/fonts/bitstream-vera/Vera.ttf childsplay-0.90.2-1.fc9.noarch requires /bin/sh childsplay-0.90.2-1.fc9.noarch requires /usr/bin/env childsplay-0.90.2-1.fc9.noarch requires /usr/bin/python chkrootkit-0.48-7.fc9.i386 requires /usr/bin/consolehelper chkrootkit-0.48-7.fc9.i386 requires /bin/sh chmlib-0.39-7.fc9.i386 requires /sbin/ldconfig chmsee-1.0.0-2.36.fc9.i386 requires /bin/sh cinepaint-0.22.1-7.fc9.i386 requires /bin/sh cinepaint-0.22.1-7.fc9.i386 requires /bin/sh cinepaint-devel-0.22.1-7.fc9.i386 requires /bin/sh cinepaint-libs-0.22.1-7.fc9.i386 requires /usr/bin/env cinepaint-libs-0.22.1-7.fc9.i386 requires /sbin/ldconfig cjkunifonts-ukai-0.1.20060928-4.fc8.noarch requires /bin/sh cjkunifonts-uming-0.1.20060928-4.fc8.noarch requires /bin/sh clamav-devel-0.93-1.fc9.i386 requires /bin/bash clamav-devel-0.93-1.fc9.i386 requires /usr/lib/pkgconfig clamav-devel-0.93-1.fc9.i386 requires /bin/sh clamav-filesystem-0.93-1.fc9.i386 requires /bin/sh clamav-lib-0.93-1.fc9.i386 requires /sbin/ldconfig clamav-milter-core-0.93-1.fc9.i386 requires /bin/sh clamav-milter-sysv-0.93-1.fc9.i386 requires /bin/sh clamav-milter-sysv-0.93-1.fc9.i386 requires /etc/rc.d/init.d clamav-milter-sysv-0.93-1.fc9.i386 requires /bin/sh clamav-server-0.93-1.fc9.i386 requires /bin/bash clamav-server-sysv-0.93-1.fc9.i386 requires /etc/rc.d/init.d clamav-update-0.93-1.fc9.i386 requires /bin/sh clamav-update-0.93-1.fc9.i386 requires /etc/cron.d clamav-update-0.93-1.fc9.i386 requires /bin/bash clamav-update-0.93-1.fc9.i386 requires /bin/chown clamav-update-0.93-1.fc9.i386 requires /bin/chmod clanbomber-1.05-8.fc9.i386 requires /bin/sh classads-1.0-1.fc9.i386 requires /sbin/ldconfig classpathx-jaf-1.0-11jpp.1.fc9.i386 requires /bin/sh classpathx-jaf-1.0-11jpp.1.fc9.i386 requires /usr/sbin/update-alternatives classpathx-jaf-1.0-11jpp.1.fc9.i386 requires /bin/sh classpathx-jaf-javadoc-1.0-11jpp.1.fc9.i386 requires /bin/rm classpathx-jaf-javadoc-1.0-11jpp.1.fc9.i386 requires /bin/ln classpathx-mail-1.1.1-5jpp.3.i386 requires /bin/sh classpathx-mail-1.1.1-5jpp.3.i386 requires /usr/sbin/update-alternatives classpathx-mail-1.1.1-5jpp.3.i386 requires /bin/sh classpathx-mail-javadoc-1.1.1-5jpp.3.i386 requires /bin/sh classpathx-mail-javadoc-1.1.1-5jpp.3.i386 requires /bin/ln classpathx-mail-javadoc-1.1.1-5jpp.3.i386 requires /bin/rm cleanfeed-0.95.7b-21.1.1.noarch requires /usr/bin/perl climm-0.6.2-1.fc9.i386 requires /bin/sh clips-libs-6.24-25.fc9.i386 requires /sbin/ldconfig clipsmm-0.0.7-4.fc9.i386 requires /sbin/ldconfig cln-1.2.2-1.fc10.i386 requires /sbin/ldconfig cln-1.2.2-1.fc10.i386 requires /sbin/install-info cln-devel-1.2.2-1.fc10.i386 requires /bin/sh clonekeen-0.8.3-4.fc9.i386 requires /bin/sh clonekeen-0.8.3-4.fc9.i386 requires /bin/bash cloudy-libs-07.02.01-4.fc9.i386 requires /sbin/ldconfig clusterssh-3.22-1.fc9.noarch requires /bin/sh clusterssh-3.22-1.fc9.noarch requires /usr/bin/perl clutter-0.6.0-1.fc9.i386 requires /sbin/ldconfig clutter-gst-0.6.1-1.fc9.i386 requires /sbin/ldconfig clutter-gtk-0.6.0-1.fc9.i386 requires /sbin/ldconfig cmake-gui-2.6.0-1.fc10.i386 requires /bin/sh cman-2.0.60-6.fc10.i386 requires /bin/sh cman-2.0.60-6.fc10.i386 requires /usr/bin/python cman-2.0.60-6.fc10.i386 requires /bin/bash cman-2.0.60-6.fc10.i386 requires /usr/bin/perl cman-2.0.60-6.fc10.i386 requires /sbin/chkconfig cmigemo-1.3-0.6.c_MIT.fc9.2.i386 requires /sbin/ldconfig cmucl-19e-0.3.pre2.fc10.i386 requires /bin/csh cmucl-19e-0.3.pre2.fc10.i386 requires /bin/sh cobbler-0.8.2-1.fc9.noarch requires /bin/sh cobbler-0.8.2-1.fc9.noarch requires /sbin/chkconfig cobbler-0.8.2-1.fc9.noarch requires /sbin/service coco-coq-0.1-3.fc8.noarch requires /bin/sh coco-coq-0.1-3.fc8.noarch requires /bin/bash coda-backup-6.9.3-1.fc10.i386 requires /usr/bin/perl coda-backup-6.9.3-1.fc10.i386 requires /bin/sh coda-client-6.9.3-1.fc10.i386 requires /bin/sh coda-client-6.9.3-1.fc10.i386 requires /usr/bin/python coda-client-6.9.3-1.fc10.i386 requires /usr/bin/perl coda-client-6.9.3-1.fc10.i386 requires /bin/sh coda-server-6.9.3-1.fc10.i386 requires /bin/sh coda-server-6.9.3-1.fc10.i386 requires /bin/sh codeblocks-8.02-1.fc9.i386 requires /bin/sh codeblocks-contrib-libs-8.02-1.fc9.i386 requires /sbin/ldconfig codeblocks-libs-8.02-1.fc9.i386 requires /sbin/ldconfig codeina-0.10.1-8.fc9.noarch requires /usr/bin/env codeina-0.10.1-8.fc9.noarch requires /bin/sh cogito-0.18.2-2.fc7.noarch requires /bin/bash cogito-0.18.2-2.fc7.noarch requires /usr/bin/env cohoba-0.0.4-5.fc7.noarch requires /bin/sh cohoba-0.0.4-5.fc7.noarch requires /usr/bin/env coldet-1.2-4.fc9.i386 requires /sbin/ldconfig collectd-4.3.2-9.fc10.i386 requires /bin/sh collectd-4.3.2-9.fc10.i386 requires /bin/bash colordiff-1.0.7-2.fc9.noarch requires /usr/bin/perl colordiff-1.0.7-2.fc9.noarch requires /bin/sh comedilib-0.8.1-1.fc10.i386 requires /bin/sh comedilib-0.8.1-1.fc10.i386 requires /sbin/ldconfig comix-3.6.4-6.fc9.noarch requires /bin/sh comix-3.6.4-6.fc9.noarch requires /usr/bin/env comix-3.6.4-6.fc9.noarch requires /usr/bin/jpegtran commoncpp2-1.6.1-1.fc9.i386 requires /sbin/ldconfig commoncpp2-devel-1.6.1-1.fc9.i386 requires /bin/sh commoncpp2-devel-1.6.1-1.fc9.i386 requires /sbin/install-info commoncpp2-devel-1.6.1-1.fc9.i386 requires /bin/sh compat-db-4.5.20-5.fc9.i386 requires /sbin/ldconfig compat-erlang-R10B-11.9.fc9.i386 requires /bin/sh compat-erlang-R10B-11.9.fc9.i386 requires /bin/sh compat-expat1-1.95.8-4.i386 requires /sbin/ldconfig compat-flex-2.5.4a-4.fc9.i386 requires /bin/sh compat-flex-2.5.4a-4.fc9.i386 requires /sbin/install-info compat-gcc-34-g77-3.4.6-9.i386 requires /bin/sh compat-gcc-34-g77-3.4.6-9.i386 requires /sbin/install-info compat-guichan05-0.5.0-8.fc9.i386 requires /sbin/ldconfig compat-guile-16-1.6.7-8.fc9.i386 requires /sbin/ldconfig compat-guile-16-1.6.7-8.fc9.i386 requires /bin/sh compat-guile-16-devel-1.6.7-8.fc9.i386 requires /usr/bin/guile-1.6 compat-guile-16-devel-1.6.7-8.fc9.i386 requires /bin/sh compat-libf2c-34-3.4.6-9.i386 requires /sbin/ldconfig compat-libgfortran-41-4.1.2-36.i386 requires /sbin/ldconfig compat-libosip2-2.2.2-16.fc9.i386 requires /sbin/ldconfig compat-libstdc++-296-2.96-140.i386 requires /sbin/ldconfig compat-libstdc++-33-3.2.3-63.i386 requires /sbin/ldconfig compat-wxGTK26-2.6.4-2.i386 requires /sbin/ldconfig compat-wxGTK26-devel-2.6.4-2.i386 requires /bin/sh compface-1.5.2-7.i386 requires /sbin/ldconfig compiz-0.7.2-4.fc10.i386 requires /sbin/ldconfig compiz-bcop-0.7.2-1.fc9.noarch requires /bin/bash compiz-fusion-extras-gnome-0.7.2-2.fc9.i386 requires /bin/sh compiz-fusion-gnome-0.7.2-2.fc9.i386 requires /bin/sh compiz-gnome-0.7.2-4.fc10.i386 requires /bin/sh compiz-kde-0.7.2-4.fc10.i386 requires /bin/sh compiz-kde-0.7.2-4.fc10.i386 requires /bin/sh compiz-manager-0.6.0-7.fc9.noarch requires /bin/sh concurrent-1.3.4-8jpp.1.fc9.i386 requires /bin/sh condor-7.0.0-8.fc9.i386 requires /bin/sh condor-7.0.0-8.fc9.i386 requires /usr/bin/env condor-7.0.0-8.fc9.i386 requires /sbin/service condor-7.0.0-8.fc9.i386 requires /bin/bash condor-7.0.0-8.fc9.i386 requires /bin/sh condor-7.0.0-8.fc9.i386 requires /usr/bin/perl condor-7.0.0-8.fc9.i386 requires /sbin/chkconfig conduit-0.3.8-1.fc9.noarch requires /bin/sh conduit-0.3.8-1.fc9.noarch requires /bin/bash conduit-0.3.8-1.fc9.noarch requires /usr/bin/env conduit-0.3.8-1.fc9.noarch requires /usr/bin/python cone-0.74-3.fc9.i386 requires /bin/sh cone-0.74-3.fc9.i386 requires /usr/bin/perl cone-0.74-3.fc9.i386 requires /usr/bin/perl cone-0.74-3.fc9.i386 requires /bin/sh conexus-0.5.3-4.fc9.i386 requires /sbin/ldconfig conexusmm-0.5.0-3.fc7.i386 requires /sbin/ldconfig conglomerate-0.9.1-5.fc9.i386 requires /bin/sh conman-0.2.1-1.fc10.i386 requires /bin/sh conman-0.2.1-1.fc10.i386 requires /usr/bin/env conman-0.2.1-1.fc10.i386 requires /sbin/service conman-0.2.1-1.fc10.i386 requires /usr/bin/expect conman-0.2.1-1.fc10.i386 requires /bin/sh conman-0.2.1-1.fc10.i386 requires /sbin/chkconfig conmux-0.0-7.493svn.fc10.noarch requires /bin/sh conmux-0.0-7.493svn.fc10.noarch requires /sbin/service conmux-0.0-7.493svn.fc10.noarch requires /usr/bin/expect conmux-0.0-7.493svn.fc10.noarch requires /usr/bin/perl conmux-0.0-7.493svn.fc10.noarch requires /bin/sh conmux-0.0-7.493svn.fc10.noarch requires /sbin/chkconfig conmux-client-0.0-7.493svn.fc10.noarch requires /usr/bin/perl conserver-8.1.16-5.fc9.i386 requires /bin/sh conserver-8.1.16-5.fc9.i386 requires /sbin/service conserver-8.1.16-5.fc9.i386 requires /bin/sh conserver-8.1.16-5.fc9.i386 requires /sbin/chkconfig conserver-client-8.1.16-5.fc9.i386 requires /bin/sh contacts-0.8-3.fc10.i386 requires /bin/sh 1:control-center-2.23.1-3.fc10.i386 requires /bin/sh 1:control-center-2.23.1-3.fc10.i386 requires /bin/sh convmv-1.12-1.fc9.noarch requires /usr/bin/perl cook-2.30-2.fc9.i386 requires /usr/bin/perl coolkey-1.1.0-6.fc9.i386 requires /bin/sh coreutils-6.11-2.fc10.i386 requires /bin/sh coreutils-6.11-2.fc10.i386 requires /sbin/install-info cowbell-0.2.7.1-10.fc10.i386 requires /bin/sh cowbell-0.2.7.1-10.fc10.i386 requires /bin/sh cowsay-3.03-4.fc8.noarch requires /usr/bin/perl cowsay-3.03-4.fc8.noarch requires /bin/sh cpan2rpm-2.028-2.fc8.1.noarch requires /usr/bin/perl cpanspec-1.75-1.fc10.noarch requires /usr/bin/repoquery cpanspec-1.75-1.fc10.noarch requires /usr/bin/perl cpanspec-1.75-1.fc10.noarch requires /bin/sh cpanspec-1.75-1.fc10.noarch requires /usr/bin/curl cpio-2.9-7.fc9.i386 requires /bin/sh cpio-2.9-7.fc9.i386 requires /sbin/install-info cpl-4.1.0-1.fc9.i386 requires /sbin/ldconfig cpp-4.3.0-8.i386 requires /bin/sh cpp-4.3.0-8.i386 requires /sbin/install-info cppunit-1.12.0-5.fc9.i386 requires /sbin/ldconfig cppunit-devel-1.12.0-5.fc9.i386 requires /bin/sh 1:cpufreq-utils-002-1.1.42.fc9.i386 requires /sbin/ldconfig 1:cpuspeed-1.2.1-5.fc9.i386 requires /bin/sh 1:cpuspeed-1.2.1-5.fc9.i386 requires /sbin/chkconfig 1:cpuspeed-1.2.1-5.fc9.i386 requires /bin/sh 1:cpuspeed-1.2.1-5.fc9.i386 requires /sbin/service crack-5.0a-8.fc9.i386 requires /bin/sh crack-5.0a-8.fc9.i386 requires /bin/bash crack-5.0a-8.fc9.i386 requires /bin/sh crack-attack-1.1.14-13.fc9.i386 requires /bin/sh cracklib-2.8.12-2.i386 requires /sbin/ldconfig cracklib-2.8.12-2.i386 requires /sbin/ldconfig cracklib-2.8.12-2.i386 requires /bin/sh createrepo-0.9.5-2.fc9.noarch requires /usr/bin/python createrepo-0.9.5-2.fc9.noarch requires /bin/sh createrepo-0.9.5-2.fc9.noarch requires /usr/bin/env crm114-0-1.7.20070810.fc9.i386 requires /usr/bin/crm cronie-1.0-5.fc9.i386 requires /bin/sh cronie-1.0-5.fc9.i386 requires /sbin/service cronie-1.0-5.fc9.i386 requires /bin/bash cronie-1.0-5.fc9.i386 requires /bin/sh cronie-1.0-5.fc9.i386 requires /sbin/chkconfig cronolog-1.6.2-7.fc9.i386 requires /bin/sh cronolog-1.6.2-7.fc9.i386 requires /usr/bin/perl cronolog-1.6.2-7.fc9.i386 requires /sbin/install-info crontabs-1.10-21.fc10.noarch requires /bin/bash crossfire-1.10.0-4.fc9.i386 requires /bin/sh crossfire-1.10.0-4.fc9.i386 requires /sbin/service crossfire-1.10.0-4.fc9.i386 requires /bin/bash crossfire-1.10.0-4.fc9.i386 requires /bin/sh crossfire-1.10.0-4.fc9.i386 requires /usr/bin/perl crossfire-1.10.0-4.fc9.i386 requires /sbin/chkconfig crossfire-client-1.10.0-4.fc9.i386 requires /bin/sh crossfire-maps-1.10.0-3.fc8.noarch requires /bin/bash crossfire-maps-1.10.0-3.fc8.noarch requires /usr/bin/perl crossfire-selinux-1.10.0-4.fc9.i386 requires /usr/sbin/semodule crossfire-selinux-1.10.0-4.fc9.i386 requires /sbin/fixfiles crossfire-selinux-1.10.0-4.fc9.i386 requires /bin/sh crossfire-selinux-1.10.0-4.fc9.i386 requires /usr/sbin/semanage crossfire-selinux-1.10.0-4.fc9.i386 requires /sbin/service crossvc-1.5.2-4.fc9.i386 requires /bin/sh cryptix-3.2.0-10jpp.2.i386 requires /bin/sh cryptix-asn1-20011119-8jpp.3.i386 requires /bin/sh cryptix-javadoc-3.2.0-10jpp.2.i386 requires /bin/sh cryptix-javadoc-3.2.0-10jpp.2.i386 requires /bin/rm cryptix-javadoc-3.2.0-10jpp.2.i386 requires /bin/ln crypto-utils-2.3-10.i386 requires /bin/bash cryptsetup-luks-1.0.6-2.fc9.i386 requires /sbin/ldconfig crystal-1.0.5-3.fc9.i386 requires /sbin/ldconfig crystal-stacker-1.5-6.fc9.i386 requires /bin/sh crystal-stacker-theme-editor-1.5-6.fc9.i386 requires /bin/sh crystalspace-1.2-4.fc9.i386 requires /sbin/ldconfig crystalspace-devel-1.2-4.fc9.i386 requires /usr/bin/env crystalspace-devel-1.2-4.fc9.i386 requires /bin/sh crystalspace-utils-1.2-4.fc9.i386 requires /bin/sh crystalsvg-icon-theme-4.0.72-1.fc10.i386 requires /bin/sh cscope-15.6-1.fc9.i386 requires /bin/sh csmash-0.6.6-18.i386 requires /bin/sh csound-5.03.0-16.fc9.i386 requires /sbin/ldconfig csound-java-5.03.0-16.fc9.i386 requires /bin/sh csound-java-5.03.0-16.fc9.i386 requires /sbin/ldconfig csound-tk-5.03.0-16.fc9.i386 requires /usr/bin/wish csound-tk-5.03.0-16.fc9.i386 requires /usr/bin/perl ctapi-common-1.1-4.fc9.i386 requires /bin/sh ctapi-cyberjack-3.0.5-2.fc9.i386 requires /sbin/ldconfig ctapi-cyberjack-3.0.5-2.fc9.i386 requires /usr/lib/ctapi ctapi-cyberjack-pcsc-3.0.5-2.fc9.i386 requires /bin/sh ctapi-cyberjack-tools-3.0.5-2.fc9.i386 requires /bin/sh cuetools-1.4.0-0.2.svn305.fc10.i386 requires /sbin/ldconfig cuetools-1.4.0-0.2.svn305.fc10.i386 requires /bin/sh culmus-fonts-0.101-4.fc8.noarch requires /bin/sh 1:cups-1.3.7-2.fc10.i386 requires /bin/sh 1:cups-1.3.7-2.fc10.i386 requires /usr/sbin/alternatives 1:cups-1.3.7-2.fc10.i386 requires /sbin/service 1:cups-1.3.7-2.fc10.i386 requires /bin/bash 1:cups-1.3.7-2.fc10.i386 requires /bin/sh 1:cups-1.3.7-2.fc10.i386 requires /usr/bin/perl 1:cups-1.3.7-2.fc10.i386 requires /sbin/chkconfig 1:cups-devel-1.3.7-2.fc10.i386 requires /bin/sh 1:cups-libs-1.3.7-2.fc10.i386 requires /sbin/ldconfig cups-pdf-2.4.7-1.fc9.i386 requires /bin/sh curry-0.9.11-4.fc9.i386 requires /bin/sh cvs-1.11.22-13.fc9.i386 requires /bin/sh cvs-1.11.22-13.fc9.i386 requires /sbin/install-info cvs-1.11.22-13.fc9.i386 requires /usr/bin/perl cvs-1.11.22-13.fc9.i386 requires /bin/sh cvs2cl-2.67-1.fc8.noarch requires /usr/bin/perl cvs2svn-2.1.1-1.fc10.noarch requires /usr/bin/python cvsplot-1.7.4-6.fc8.noarch requires /usr/bin/perl cvsutils-0.2.3-6.fc8.noarch requires /usr/bin/perl cvsutils-0.2.3-6.fc8.noarch requires /bin/sh cvsweb-3.0.6-3.fc6.noarch requires /usr/bin/perl cwiid-0.6.00-7.fc10.i386 requires /sbin/ldconfig cwrite-0.1.24-2.fc9.i386 requires /bin/sh cwrite-0.1.24-2.fc9.i386 requires /sbin/install-info cycle-0.3.1-4.fc7.noarch requires /usr/bin/env cyphesis-0.5.15-6.fc9.i386 requires /sbin/service cyphesis-0.5.15-6.fc9.i386 requires /bin/sh cyphesis-0.5.15-6.fc9.i386 requires /sbin/chkconfig cyphesis-0.5.15-6.fc9.i386 requires /bin/sh cyphesis-selinux-0.5.15-6.fc9.i386 requires /usr/sbin/semodule cyphesis-selinux-0.5.15-6.fc9.i386 requires /sbin/fixfiles cyphesis-selinux-0.5.15-6.fc9.i386 requires /bin/sh cyphesis-selinux-0.5.15-6.fc9.i386 requires /usr/sbin/semanage cyphesis-selinux-0.5.15-6.fc9.i386 requires /usr/sbin/setsebool cyphesis-selinux-0.5.15-6.fc9.i386 requires /sbin/service cyrus-imapd-2.3.11-1.fc9.i386 requires /bin/sh cyrus-imapd-2.3.11-1.fc9.i386 requires /sbin/service cyrus-imapd-2.3.11-1.fc9.i386 requires /usr/bin/perl cyrus-imapd-2.3.11-1.fc9.i386 requires /bin/sh cyrus-imapd-2.3.11-1.fc9.i386 requires /sbin/chkconfig cyrus-imapd-perl-2.3.11-1.fc9.i386 requires /usr/bin/perl cyrus-imapd-utils-2.3.11-1.fc9.i386 requires /usr/sbin/userdel cyrus-imapd-utils-2.3.11-1.fc9.i386 requires /bin/sh cyrus-imapd-utils-2.3.11-1.fc9.i386 requires /usr/sbin/groupadd cyrus-imapd-utils-2.3.11-1.fc9.i386 requires /bin/sh cyrus-imapd-utils-2.3.11-1.fc9.i386 requires /usr/sbin/groupdel cyrus-imapd-utils-2.3.11-1.fc9.i386 requires /usr/sbin/useradd cyrus-sasl-2.1.22-13.fc9.i386 requires /bin/sh cyrus-sasl-2.1.22-13.fc9.i386 requires /sbin/service cyrus-sasl-2.1.22-13.fc9.i386 requires /bin/bash cyrus-sasl-lib-2.1.22-13.fc9.i386 requires /sbin/ldconfig d-feet-0.1.8-1.fc9.noarch requires /bin/sh d-feet-0.1.8-1.fc9.noarch requires /usr/bin/python d4x-2.5.7.1-8.fc9.i386 requires /bin/sh dap-freeform_handler-3.7.7-2.fc9.i386 requires /sbin/ldconfig dap-freeform_handler-3.7.7-2.fc9.i386 requires /bin/sh dap-hdf4_handler-3.7.7-3.fc9.i386 requires /bin/sh dap-netcdf_handler-3.7.8-3.fc9.i386 requires /sbin/ldconfig dap-netcdf_handler-3.7.8-3.fc9.i386 requires /bin/sh dap-server-3.8.4-3.fc9.i386 requires /bin/sh dap-server-cgi-3.8.4-3.fc9.i386 requires /usr/bin/perl darcs-1.0.9-11.fc9.i386 requires /bin/sh darcs-server-1.0.9-11.fc9.i386 requires /usr/bin/xsltproc darcs-server-1.0.9-11.fc9.i386 requires /usr/bin/perl dasher-4.9.0-1.fc10.i386 requires /bin/sh dates-0.4.6-1.fc10.i386 requires /sbin/ldconfig dates-0.4.6-1.fc10.i386 requires /bin/sh dayplanner-0.8.1-3.fc9.noarch requires /bin/sh dayplanner-0.8.1-3.fc9.noarch requires /usr/bin/perl db4-4.6.21-5.fc9.i386 requires /sbin/ldconfig db4-java-4.6.21-5.fc9.i386 requires /sbin/ldconfig db4-tcl-4.6.21-5.fc9.i386 requires /sbin/ldconfig db4o-6.1-4.fc9.i386 requires /bin/sh 1:dbh-1.0.24-6.fc9.i386 requires /sbin/ldconfig dblatex-0.2.8-2.fc9.1.noarch requires /usr/bin/texhash dblatex-0.2.8-2.fc9.1.noarch requires /usr/bin/env dbmail-2.2.9-1.fc10.i386 requires /bin/sh dbmail-2.2.9-1.fc10.i386 requires /bin/bash dbmail-2.2.9-1.fc10.i386 requires /bin/sh dbus-1.2.1-3.fc10.i386 requires /bin/sh dbus-1.2.1-3.fc10.i386 requires /usr/sbin/useradd dbus-1.2.1-3.fc10.i386 requires /bin/sh dbus-glib-0.74-6.fc9.i386 requires /sbin/ldconfig dbus-libs-1.2.1-3.fc10.i386 requires /sbin/ldconfig dbus-qt-0.70-4.fc9.i386 requires /sbin/ldconfig dbus-qt3-0.8-5.fc9.i386 requires /sbin/ldconfig dbus-x11-1.2.1-3.fc10.i386 requires /bin/sh dbxml-2.3.10-12.fc9.i386 requires /sbin/ldconfig dclib-0.3.11-4.fc9.i386 requires /sbin/ldconfig dd2-0.2.2-3.fc9.i386 requires /bin/sh dd_rescue-1.14-7.fc9.i386 requires /bin/bash ddclient-3.7.3-1.fc9.noarch requires /bin/sh ddclient-3.7.3-1.fc9.noarch requires /usr/bin/perl ddclient-3.7.3-1.fc9.noarch requires /sbin/chkconfig ddclient-3.7.3-1.fc9.noarch requires /usr/sbin/groupadd ddclient-3.7.3-1.fc9.noarch requires /usr/sbin/useradd ddclient-3.7.3-1.fc9.noarch requires /bin/sh ddd-3.3.11-18.fc9.i386 requires /bin/sh ddd-3.3.11-18.fc9.i386 requires /sbin/install-info ddrescue-1.8-2.fc9.i386 requires /bin/sh ddrescue-1.8-2.fc9.i386 requires /sbin/install-info ddskk-12.2.0-11.fc7.noarch requires /bin/sh ddskk-12.2.0-11.fc7.noarch requires /sbin/install-info debootstrap-1.0.8-1.fc9.noarch requires /bin/sh 1:dejagnu-1.4.4-11.fc9.noarch requires /bin/sh 1:dejagnu-1.4.4-11.fc9.noarch requires /bin/sh dejavu-fonts-2.24-3.fc9.noarch requires /bin/sh dejavu-fonts-experimental-2.24-3.fc9.noarch requires /bin/sh dejavu-lgc-fonts-2.24-3.fc9.noarch requires /bin/sh deltarpm-3.4-10.fc9.i386 requires /usr/bin/perl deluge-0.5.9.0-1.fc10.i386 requires /bin/sh deluge-0.5.9.0-1.fc10.i386 requires /usr/bin/env deluge-0.5.9.0-1.fc10.i386 requires /usr/bin/python deluge-0.5.9.0-1.fc10.i386 requires /bin/bash deluge-0.5.9.0-1.fc10.i386 requires /bin/sh denyhosts-2.6-8.fc9.noarch requires /bin/sh denyhosts-2.6-8.fc9.noarch requires /bin/bash denyhosts-2.6-8.fc9.noarch requires /usr/bin/env denyhosts-2.6-8.fc9.noarch requires /bin/env denyhosts-2.6-8.fc9.noarch requires /bin/sh denyhosts-2.6-8.fc9.noarch requires /usr/bin/python deskbar-applet-2.23.2-1.fc10.i386 requires /bin/sh deskbar-applet-2.23.2-1.fc10.i386 requires /usr/bin/env desktop-data-model-1.2.4-1.fc10.i386 requires /sbin/ldconfig desktop-data-model-1.2.4-1.fc10.i386 requires /bin/sh desktop-file-utils-0.15-3.fc10.i386 requires /bin/sh dev86-0.16.17-9.fc9.i386 requires /bin/sh devhelp-0.19-4.fc9.i386 requires /bin/sh device-mapper-libs-1.02.24-11.fc9.i386 requires /sbin/ldconfig device-mapper-multipath-0.4.7-15.fc10.i386 requires /bin/sh device-mapper-multipath-0.4.7-15.fc10.i386 requires /bin/bash dgae-1.1-3.fc8.noarch requires /bin/sh dgae-1.1-3.fc8.noarch requires /bin/bash 12:dhclient-4.0.0-15.fc10.i386 requires /bin/bash 12:dhcp-4.0.0-15.fc10.i386 requires /bin/sh 12:dhcp-4.0.0-15.fc10.i386 requires /bin/sh dhcp-forwarder-0.7-14.fc9.i386 requires /bin/sh dhcp-forwarder-sysv-0.7-14.fc9.i386 requires /bin/sh dhcp-forwarder-sysv-0.7-14.fc9.i386 requires /bin/bash dhcp-forwarder-sysv-0.7-14.fc9.i386 requires /sbin/chkconfig dhcpv6-1.0.15-1.fc10.i386 requires /bin/sh dhcpv6-1.0.15-1.fc10.i386 requires /bin/sh 1:dia-0.96.1-6.fc10.i386 requires /usr/bin/env 1:dia-0.96.1-6.fc10.i386 requires /bin/sh dialog-1.1-5.20080316.fc10.i386 requires /sbin/ldconfig dialog-devel-1.1-5.20080316.fc10.i386 requires /bin/sh dictd-1.10.11-2.i386 requires /bin/sh dictd-1.10.11-2.i386 requires /bin/sh diffutils-2.8.1-21.fc9.i386 requires /bin/sh diffutils-2.8.1-21.fc9.i386 requires /sbin/install-info digikam-0.9.4-0.1.beta4.fc10.i386 requires /bin/sh digikam-0.9.4-0.1.beta4.fc10.i386 requires /usr/bin/perl digikam-0.9.4-0.1.beta4.fc10.i386 requires /bin/sh dillo-0.8.6-7.fc9.i386 requires /usr/bin/perl dirac-0.9.1-2.fc9.i386 requires /usr/bin/perl dirac-libs-0.9.1-2.fc9.i386 requires /sbin/ldconfig dircproxy-1.2.0-0.7.beta2.fc9.i386 requires /bin/sh dircproxy-1.2.0-0.7.beta2.fc9.i386 requires /usr/bin/perl dircproxy-1.2.0-0.7.beta2.fc9.i386 requires /bin/sh directfb-1.0.0-4.fc9.i386 requires /sbin/ldconfig directfb-devel-1.0.0-4.fc9.i386 requires /bin/sh dirmngr-1.0.1-2.fc9.i386 requires /bin/sh dirmngr-1.0.1-2.fc9.i386 requires /sbin/install-info dirvish-1.2.1-2.fc6.noarch requires /usr/bin/perl distcache-1.4.5-17.i386 requires /bin/sh distcache-1.4.5-17.i386 requires /sbin/service distcache-1.4.5-17.i386 requires /sbin/ldconfig distcache-1.4.5-17.i386 requires /bin/bash distcache-1.4.5-17.i386 requires /sbin/chkconfig distcc-2.18.3-4.fc9.i386 requires /bin/sh distcc-server-2.18.3-4.fc9.i386 requires /sbin/chkconfig distcc-server-2.18.3-4.fc9.i386 requires /bin/sh distcc-server-2.18.3-4.fc9.i386 requires /bin/sh djvulibre-3.5.20-2.fc9.i386 requires /bin/sh djvulibre-3.5.20-2.fc9.i386 requires /sbin/ldconfig djvulibre-3.5.20-2.fc9.i386 requires /bin/bash djvulibre-3.5.20-2.fc9.i386 requires /bin/sh djvulibre-libs-3.5.20-2.fc9.i386 requires /sbin/ldconfig dkim-milter-2.5.1-5.fc9.i386 requires /bin/sh dkim-milter-2.5.1-5.fc9.i386 requires /sbin/service dkim-milter-2.5.1-5.fc9.i386 requires /bin/bash dkim-milter-2.5.1-5.fc9.i386 requires /bin/sh dkim-milter-2.5.1-5.fc9.i386 requires /sbin/chkconfig dkms-2.0.19-1.fc9.noarch requires /bin/sh dkms-2.0.19-1.fc9.noarch requires /bin/bash dkms-2.0.19-1.fc9.noarch requires /bin/sh dmraid-1.0.0.rc14-6.fc9.i386 requires /sbin/ldconfig dnsmasq-2.41-0.8.fc9.i386 requires /bin/sh dnsmasq-2.41-0.8.fc9.i386 requires /bin/sed dnsmasq-2.41-0.8.fc9.i386 requires /sbin/chkconfig dnsmasq-2.41-0.8.fc9.i386 requires /bin/grep dnsmasq-2.41-0.8.fc9.i386 requires /bin/sh dnsmasq-2.41-0.8.fc9.i386 requires /sbin/service dnssec-tools-1.3.2-2.fc9.i386 requires /usr/bin/perl dnssec-tools-libs-1.3.2-2.fc9.i386 requires /sbin/ldconfig dnssec-tools-libs-devel-1.3.2-2.fc9.i386 requires /bin/sh docbook-dtds-1.0-36.fc10.noarch requires /bin/sh docbook-simple-1.1-3.fc9.noarch requires /bin/sh docbook-slides-3.4.0-3.fc9.noarch requires /bin/sh docbook-style-dsssl-1.79-5.fc9.noarch requires /bin/sh docbook-style-dsssl-1.79-5.fc9.noarch requires /usr/bin/perl docbook-style-xsl-1.73.2-9.fc9.noarch requires /bin/sh docbook-utils-0.6.14-13.fc9.noarch requires /usr/bin/perl docbook-utils-0.6.14-13.fc9.noarch requires /bin/sh docbook-utils-pdf-0.6.14-13.fc9.noarch requires /bin/sh docbook2X-0.8.8-3.fc9.i386 requires /bin/sh docbook2X-0.8.8-3.fc9.i386 requires /sbin/install-info docbook2X-0.8.8-3.fc9.i386 requires /usr/bin/sgml2xml docbook2X-0.8.8-3.fc9.i386 requires /usr/bin/perl docbook2X-0.8.8-3.fc9.i386 requires /bin/sh dogtail-0.6.90-1.381.fc9.noarch requires /bin/sh dogtail-0.6.90-1.381.fc9.noarch requires /usr/bin/python dom4j-demo-1.6.1-2jpp.3.fc8.noarch requires /bin/sh doodle-0.6.7-2.fc9.i386 requires /sbin/ldconfig dot2tex-2.7.0-4.fc9.noarch requires /usr/bin/python dotconf-1.0.13-6.fc9.i386 requires /sbin/ldconfig dotconf-devel-1.0.13-6.fc9.i386 requires /bin/sh doulos-fonts-4.100-1.fc9.noarch requires /bin/sh 1:dovecot-1.0.13-6.fc9.i386 requires /usr/sbin/userdel 1:dovecot-1.0.13-6.fc9.i386 requires /bin/sh 1:dovecot-1.0.13-6.fc9.i386 requires /usr/sbin/useradd 1:dovecot-1.0.13-6.fc9.i386 requires /sbin/service 1:dovecot-1.0.13-6.fc9.i386 requires /bin/touch 1:dovecot-1.0.13-6.fc9.i386 requires /bin/mv 1:dovecot-1.0.13-6.fc9.i386 requires /bin/bash 1:dovecot-1.0.13-6.fc9.i386 requires /bin/sh 1:dovecot-1.0.13-6.fc9.i386 requires /usr/sbin/groupdel 1:dovecot-1.0.13-6.fc9.i386 requires /sbin/chkconfig 1:dovecot-1.0.13-6.fc9.i386 requires /bin/rm drawtiming-0.6.2-3.fc9.i386 requires libMagick++.so.10 drawtiming-0.6.2-3.fc9.i386 requires libWand.so.10 drawtiming-0.6.2-3.fc9.i386 requires libMagick.so.10 drgeo-1.1.0-12.fc9.i386 requires /bin/bash driconf-0.9.1-7.fc9.noarch requires /usr/bin/python driftnet-0.1.6-16.20040426cvs.fc9.i386 requires /usr/bin/consolehelper drivel-2.1.1-0.5.20071130svn.fc9.i386 requires /bin/sh dropbear-0.50-3.fc9.i386 requires /bin/sh dropbear-0.50-3.fc9.i386 requires /bin/bash dropbear-0.50-3.fc9.i386 requires /sbin/service 1:drpython-3.11.0-2.fc9.noarch requires /bin/bash 1:drpython-3.11.0-2.fc9.noarch requires /usr/bin/env 1:drpython-3.11.0-2.fc9.noarch requires /bin/sh 1:drpython-3.11.0-2.fc9.noarch requires /usr/bin/python ds9-5.1-4.fc9.i386 requires /bin/sh dstat-0.6.7-3.fc10.noarch requires /usr/bin/env dtdparser-1.21-4jpp.2.fc9.i386 requires /bin/sh duel3-0.1-0.5.20060225.fc9.i386 requires /bin/sh dumb-0.9.3-7.fc9.i386 requires /sbin/ldconfig duplicity-0.4.11-1.fc10.i386 requires /usr/bin/python dvdauthor-0.6.14-5.fc9.i386 requires /bin/sh dvipdfm-0.13.2d-38.fc10.i386 requires /bin/sh dvipdfm-0.13.2d-38.fc10.i386 requires /bin/sh dvipdfm-0.13.2d-38.fc10.i386 requires /usr/bin/mktexlsr dvipdfmx-0-0.20.20071115cvs.fc9.i386 requires /bin/sh dvipdfmx-0-0.20.20071115cvs.fc9.i386 requires /usr/bin/mktexlsr dvipng-1.9-50.fc9.i386 requires /bin/sh dvipng-1.9-50.fc9.i386 requires /sbin/install-info dwarves-1.6-1.i386 requires /usr/bin/python dx-4.4.4-6.fc9.i386 requires /bin/sh dx-4.4.4-6.fc9.i386 requires libWand.so.10 dx-4.4.4-6.fc9.i386 requires libMagick.so.10 dx-libs-4.4.4-6.fc9.i386 requires /sbin/ldconfig dx-libs-4.4.4-6.fc9.i386 requires libWand.so.10 dx-libs-4.4.4-6.fc9.i386 requires libMagick.so.10 dxcc-20080225-4.fc9.noarch requires /usr/bin/perl dxcc-gui-20080225-4.fc9.noarch requires /bin/bash dxpc-3.9.1-0.3.b1.fc9.i386 requires /bin/bash dynamite-0.1-9.fc9.i386 requires /sbin/ldconfig e16-0.16.8.13-2.fc10.i386 requires /usr/bin/perl e16-0.16.8.13-2.fc10.i386 requires /bin/sh e16-epplets-0.10-3.fc10.i386 requires /sbin/ldconfig e16-themes-0.16.8.0.2-1.fc10.noarch requires /bin/sh e2fsprogs-1.40.9-2.fc10.i386 requires /bin/sh e2fsprogs-devel-1.40.9-2.fc10.i386 requires /bin/sh e2fsprogs-devel-1.40.9-2.fc10.i386 requires /sbin/install-info e2fsprogs-devel-1.40.9-2.fc10.i386 requires /bin/sh e2fsprogs-libs-1.40.9-2.fc10.i386 requires /sbin/ldconfig eb-4.3.2-1.fc9.i386 requires /sbin/ldconfig eb-4.3.2-1.fc9.i386 requires /usr/bin/perl eblook-1.6.1-3.fc9.i386 requires /bin/sh ebtables-2.0.8-5.fc9.i386 requires /bin/sh ebtables-2.0.8-5.fc9.i386 requires /sbin/service ebtables-2.0.8-5.fc9.i386 requires /bin/bash ebtables-2.0.8-5.fc9.i386 requires /usr/bin/perl ebtables-2.0.8-5.fc9.i386 requires /sbin/chkconfig echo-icon-theme-0.3.89.0-0.1.git51c57605.fc10.noarch requires /bin/sh ecl-0.9j-2.fc9.i386 requires /bin/sh ecl-0.9j-2.fc9.i386 requires /bin/sh 1:eclipse-cdt-4.0.3-1.fc9.i386 requires /bin/sh 1:eclipse-changelog-2.6.1-3.fc9.i386 requires /usr/bin/rebuild-gcj-db eclipse-checkstyle-4.0.1-10.fc9.i386 requires /bin/sh 1:eclipse-ecj-3.3.2-11.fc9.i386 requires /usr/bin/rebuild-gcj-db 1:eclipse-ecj-3.3.2-11.fc9.i386 requires /bin/sh eclipse-egit-0.3.1-0.fc9.i386 requires /usr/bin/rebuild-gcj-db eclipse-epic-0.6.23-1.fc9.i386 requires /usr/bin/rebuild-gcj-db eclipse-gef-3.3.0-2.fc9.i386 requires /usr/bin/rebuild-gcj-db 1:eclipse-jdt-3.3.2-11.fc9.i386 requires /usr/bin/rebuild-gcj-db 1:eclipse-jdt-3.3.2-11.fc9.i386 requires /bin/sh eclipse-mylyn-2.3.2-4.fc9.i386 requires /bin/sh eclipse-mylyn-bugzilla-2.3.2-4.fc9.i386 requires /bin/sh eclipse-mylyn-ide-2.3.2-4.fc9.i386 requires /bin/sh eclipse-mylyn-java-2.3.2-4.fc9.i386 requires /bin/sh eclipse-mylyn-trac-2.3.2-4.fc9.i386 requires /bin/sh 1:eclipse-pde-3.3.2-11.fc9.i386 requires /usr/bin/rebuild-gcj-db 1:eclipse-pde-3.3.2-11.fc9.i386 requires /bin/bash 1:eclipse-pde-runtime-3.3.2-11.fc9.i386 requires /usr/bin/rebuild-gcj-db eclipse-photran-4.0-1.b3.fc9.1.i386 requires /usr/bin/rebuild-gcj-db eclipse-phpeclipse-1.1.8-18.fc9.i386 requires /usr/bin/rebuild-gcj-db 1:eclipse-platform-3.3.2-11.fc9.i386 requires /bin/sh 1:eclipse-platform-3.3.2-11.fc9.i386 requires /usr/lib/eclipse/plugins/org.eclipse.swt.gtk.linux.x86_3.3.2.v3349.jar 1:eclipse-pydev-1.3.14-1.fc9.i386 requires /usr/bin/rebuild-gcj-db eclipse-quickrex-3.5.0-7.fc9.i386 requires /bin/sh 1:eclipse-rcp-3.3.2-11.fc9.i386 requires /usr/lib/eclipse/plugins/org.eclipse.swt.gtk.linux.x86_3.3.2.v3349.jar 1:eclipse-rcp-3.3.2-11.fc9.i386 requires /usr/bin/rebuild-gcj-db eclipse-rpm-editor-0.2.1-3.fc9.i386 requires /bin/sh eclipse-setools-3.3.2.4-1.fc9.i386 requires /bin/sh eclipse-slide-1.3.8-1.fc9.noarch requires /bin/sh eclipse-subclipse-1.2.4-9.fc9.i386 requires /usr/bin/rebuild-gcj-db ecore-0.9.9.042-3.fc10.i386 requires /sbin/ldconfig ecryptfs-utils-40-0.fc9.i386 requires /sbin/ldconfig ed-0.8-2.fc9.i386 requires /bin/sh ed-0.8-2.fc9.i386 requires /sbin/install-info ed2k_hash-gui-0.4.0-7.fc9.i386 requires /bin/sh edac-utils-0.9-8.fc9.i386 requires /bin/sh edac-utils-0.9-8.fc9.i386 requires /sbin/ldconfig edac-utils-0.9-8.fc9.i386 requires /usr/bin/perl edac-utils-0.9-8.fc9.i386 requires /bin/sh edje-0.5.0.042-3.fc10.i386 requires /sbin/ldconfig edje-0.5.0.042-3.fc10.i386 requires /bin/sh edrip-fonts-20080330-1.fc9.noarch requires /bin/sh edsadmin-1.0-2.fc9.noarch requires /bin/sh eel2-2.23.1-1.fc10.i386 requires /sbin/ldconfig eet-1.0.0-1.fc10.i386 requires /sbin/ldconfig efax-0.9a-1.001114.fc9.i386 requires /bin/sh efont-unicode-bdf-0.4.2-7.fc8.noarch requires /bin/sh efreet-0.0.3.042-3.fc10.i386 requires /sbin/ldconfig egd-0.9-2.fc9.noarch requires /usr/bin/perl eggdrop-1.6.19-1.fc10.i386 requires /bin/sh egoboo-2.7.5-4.fc9.i386 requires /bin/sh egoboo-data-2.7.5-1.fc9.noarch requires /bin/sh ejabberd-2.0.0-1.fc9.i386 requires /bin/sh ejabberd-2.0.0-1.fc9.i386 requires /bin/bash ejabberd-2.0.0-1.fc9.i386 requires /sbin/chkconfig ejabberd-2.0.0-1.fc9.i386 requires /bin/sh ejabberd-2.0.0-1.fc9.i386 requires /sbin/service ekg-1.7-6.fc9.i386 requires /usr/bin/luit ekg-1.7-6.fc9.i386 requires /usr/bin/perl ekg-1.7-6.fc9.i386 requires /bin/sh ekg2-devel-0.1.1-4.fc9.i386 requires /bin/sh ekiga-2.0.12-2.fc10.i386 requires /bin/sh ekiga-2.0.12-2.fc10.i386 requires /bin/sh ekiga-2.0.12-2.fc10.i386 requires /usr/bin/scrollkeeper-update electronics-menu-1.0-1.fc9.noarch requires /bin/sh elektra-0.6.10-6.fc9.i386 requires /bin/sh elektra-0.6.10-6.fc9.i386 requires /sbin/service elektra-0.6.10-6.fc9.i386 requires /sbin/ldconfig elektra-0.6.10-6.fc9.i386 requires /bin/bash elektra-0.6.10-6.fc9.i386 requires /sbin/chkconfig elfutils-0.135-1.fc10.i386 requires /bin/sh elfutils-libelf-0.135-1.fc10.i386 requires /sbin/ldconfig elfutils-libs-0.135-1.fc10.i386 requires /sbin/ldconfig elisa-0.3.2-1.fc8.noarch requires /usr/bin/python elsa-1.4-3.fc9.i386 requires /usr/bin/env elsa-1.4-3.fc9.i386 requires /bin/sh em8300-0.16.4-1.fc9.i386 requires /bin/sh em8300-0.16.4-1.fc9.i386 requires /etc/security/console.perms.d em8300-0.16.4-1.fc9.i386 requires /etc/alsa/cards em8300-devel-0.16.4-1.fc9.i386 requires /usr/bin/perl em8300-utils-0.16.4-1.fc9.i386 requires /usr/bin/perl 1:emacs-22.2-4.fc9.i386 requires /bin/sh 1:emacs-22.2-4.fc9.i386 requires /bin/sh emacs-auctex-11.85-7.fc9.noarch requires /bin/sh emacs-auctex-11.85-7.fc9.noarch requires /sbin/install-info emacs-bbdb-2.35-8.fc8.noarch requires /bin/sh 1:emacs-common-22.2-4.fc9.i386 requires /bin/sh 1:emacs-common-22.2-4.fc9.i386 requires /usr/bin/perl 1:emacs-common-22.2-4.fc9.i386 requires /usr/sbin/alternatives 1:emacs-common-22.2-4.fc9.i386 requires /sbin/install-info 1:emacs-common-22.2-4.fc9.i386 requires /bin/sh emacs-common-ebib-1.5.2-3.fc9.noarch requires /bin/sh emacs-common-ebib-1.5.2-3.fc9.noarch requires /sbin/install-info emacs-common-ess-5.3.7-1.fc10.noarch requires /bin/sh emacs-common-ess-5.3.7-1.fc10.noarch requires /sbin/install-info emacs-common-muse-3.12-1.fc9.noarch requires /bin/sh emacs-common-muse-3.12-1.fc9.noarch requires /sbin/install-info emacs-ess-5.3.7-1.fc10.noarch requires /bin/sh 1:emacs-nox-22.2-4.fc9.i386 requires /bin/sh 1:emacs-nox-22.2-4.fc9.i386 requires /bin/sh emacs-nxml-mode-0.20041004-6.fc8.noarch requires /bin/sh emacs-vm-8.0.9.544-1.fc9.i386 requires /bin/sh emacs-vm-8.0.9.544-1.fc9.i386 requires /sbin/install-info emacspeak-26-3.fc8.noarch requires /bin/sh emacspeak-26-3.fc8.noarch requires /usr/bin/perl emacspeak-26-3.fc8.noarch requires /usr/bin/tclsh emacspeak-26-3.fc8.noarch requires /bin/sh embryo-0.9.1.042-5.fc10.i386 requires /sbin/ldconfig emerald-0.5.2-4.fc9.i386 requires /bin/sh emesene-1.0-1.fc9.noarch requires /usr/bin/env empathy-0.23.2-1.fc10.i386 requires /bin/sh empathy-libs-0.23.2-1.fc10.i386 requires /sbin/ldconfig enca-1.9-4.fc9.i386 requires /sbin/ldconfig 1:enchant-1.3.0-4.fc10.i386 requires /sbin/ldconfig enemies-of-carlotta-1.2.4-1.fc7.noarch requires /usr/bin/python enet-1.1-3.fc9.i386 requires /sbin/ldconfig enigma-1.01-6.2.i386 requires /bin/sh enscript-1.6.4-9.fc9.i386 requires /bin/sh enscript-1.6.4-9.fc9.i386 requires /usr/bin/perl enscript-1.6.4-9.fc9.i386 requires /sbin/install-info enscript-1.6.4-9.fc9.i386 requires /bin/sh environment-modules-3.2.6-5.fc9.i386 requires /bin/sh eog-2.23.2-1.fc10.i386 requires /bin/sh epdfview-0.1.6-3.fc9.i386 requires /bin/sh epeg-0.9.1.042-4.fc10.i386 requires /sbin/ldconfig epiphany-2.22.1.1-1.fc9.i386 requires /bin/sh epiphany-extensions-2.22.1-1.fc9.i386 requires /bin/sh epydoc-3.0.1-1.fc9.noarch requires /usr/bin/python epylog-1.0.3-7.fc9.noarch requires /bin/sh epylog-1.0.3-7.fc9.noarch requires /usr/bin/python eric-4.1.2-2.fc9.noarch requires /bin/sh eric-4.1.2-2.fc9.noarch requires /usr/bin/env eric-4.1.2-2.fc9.noarch requires /bin/sh eric-4.1.2-2.fc9.noarch requires /usr/bin/python eris-1.3.13-2.fc9.i386 requires /sbin/ldconfig erlang-R12B-1.1.fc9.i386 requires /bin/sh erlang-R12B-1.1.fc9.i386 requires /bin/sh eruby-libs-1.0.5-11.i386 requires /sbin/ldconfig esc-1.0.1-9.fc9.i386 requires /bin/sh escape-200704130-8.fc9.i386 requires /bin/sh esmtp-0.6.0-4.fc9.i386 requires /bin/sh esmtp-0.6.0-4.fc9.i386 requires /bin/bash esmtp-0.6.0-4.fc9.i386 requires /usr/sbin/alternatives 1:esound-devel-0.2.38-7.fc9.i386 requires /bin/sh 1:esound-libs-0.2.38-7.fc9.i386 requires /sbin/ldconfig 1:esound-tools-0.2.38-7.fc9.i386 requires /bin/sh espeak-1.31-5.fc9.i386 requires /sbin/ldconfig eterm-0.9.4-10.fc9.i386 requires /sbin/ldconfig eterm-0.9.4-10.fc9.i386 requires /usr/bin/perl eterm-0.9.4-10.fc9.i386 requires /bin/sh etherape-0.9.7-6.fc9.i386 requires /bin/sh etherbat-1.0.1-4.fc9.i386 requires /usr/bin/ruby ettercap-0.7.3-22.fc9.i386 requires /bin/sh ettercap-0.7.3-22.fc9.i386 requires /usr/sbin/alternatives ettercap-gtk-0.7.3-22.fc9.i386 requires /usr/sbin/alternatives ettercap-gtk-0.7.3-22.fc9.i386 requires /bin/sh evas-0.9.9.042-3.fc10.i386 requires /sbin/ldconfig eventlog-0.2.5-9.fc9.i386 requires /sbin/ldconfig evince-2.22.1.1-1.fc9.i386 requires /bin/sh evolution-2.23.2-1.fc10.i386 requires /usr/bin/perl evolution-2.23.2-1.fc10.i386 requires /bin/sh evolution-bogofilter-2.23.2-1.fc10.i386 requires /bin/sh evolution-brutus-1.2.11-2.fc9.i386 requires /sbin/ldconfig evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-data-server-2.23.2-2.fc10.i386 requires /sbin/ldconfig evolution-exchange-2.23.2-1.fc10.i386 requires /bin/sh evolution-python-0.0.4-3.fc9.i386 requires libedataserver-1.2.so.9 evolution-rss-0.0.8-7.fc9.i386 requires /sbin/ldconfig evolution-rss-0.0.8-7.fc9.i386 requires /bin/sh evolution-webcal-2.21.92-2.fc10.i386 requires /bin/sh evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.i386 requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-1.2.so.11 ewftools-20080501-1.fc10.i386 requires /usr/bin/python2.5 exaile-0.2.13-1.fc9.i386 requires /bin/sh exempi-2.0.0-1.fc9.i386 requires /sbin/ldconfig exim-4.69-5.fc10.i386 requires /bin/sh exim-4.69-5.fc10.i386 requires /usr/sbin/alternatives exim-4.69-5.fc10.i386 requires /etc/aliases exim-4.69-5.fc10.i386 requires /usr/sbin/groupadd exim-4.69-5.fc10.i386 requires /usr/sbin/useradd exim-4.69-5.fc10.i386 requires /sbin/service exim-4.69-5.fc10.i386 requires /bin/bash exim-4.69-5.fc10.i386 requires /bin/sh exim-4.69-5.fc10.i386 requires /usr/bin/perl exim-4.69-5.fc10.i386 requires /sbin/chkconfig exim-clamav-4.69-5.fc10.i386 requires /bin/sh exim-clamav-4.69-5.fc10.i386 requires /sbin/chkconfig exim-clamav-4.69-5.fc10.i386 requires /sbin/service exim-greylist-4.69-5.fc10.i386 requires /etc/cron.daily exim-greylist-4.69-5.fc10.i386 requires /bin/bash exim-greylist-4.69-5.fc10.i386 requires /bin/sh exim-mon-4.69-5.fc10.i386 requires /bin/sh exiv2-libs-0.16-2.fc9.i386 requires /sbin/ldconfig exo-0.3.4-2.fc9.i386 requires /usr/bin/env exo-0.3.4-2.fc9.i386 requires /bin/sh exo-0.3.4-2.fc9.i386 requires /bin/sh expat-2.0.1-5.i386 requires /sbin/ldconfig expect-5.43.0-13.fc9.i386 requires /bin/sh expectk-5.43.0-13.fc9.i386 requires /bin/sh ez-ipupdate-3.0.11-0.17.b8.fc9.i386 requires /bin/sh ez-ipupdate-3.0.11-0.17.b8.fc9.i386 requires /sbin/chkconfig ez-ipupdate-3.0.11-0.17.b8.fc9.i386 requires /usr/sbin/groupadd ez-ipupdate-3.0.11-0.17.b8.fc9.i386 requires /usr/sbin/useradd f-spot-0.4.3.1-1.fc10.i386 requires /bin/sh f-spot-0.4.3.1-1.fc10.i386 requires /bin/bash f-spot-0.4.3.1-1.fc10.i386 requires /bin/sh fRaBs-2.11-1.fc9.noarch requires /bin/sh facter-1.3.8-1.fc8.noarch requires /usr/bin/ruby fail2ban-0.8.2-13.fc9.noarch requires /bin/sh fail2ban-0.8.2-13.fc9.noarch requires /bin/bash fail2ban-0.8.2-13.fc9.noarch requires /sbin/chkconfig fail2ban-0.8.2-13.fc9.noarch requires /usr/bin/python fail2ban-0.8.2-13.fc9.noarch requires /sbin/service fakechroot-2.5-13.fc9.i386 requires /bin/sh fakeroot-1.6.4-16.fc9.i386 requires /bin/sh fakeroot-1.6.4-16.fc9.i386 requires /usr/bin/getopt fann-2.0.0-4.1.fc9.i386 requires /sbin/ldconfig fantasdic-1.0-0.1.beta5.fc9.noarch requires /bin/sh fantasdic-1.0-0.1.beta5.fc9.noarch requires /usr/bin/ruby farsight-0.1.28-1.fc10.i386 requires /sbin/ldconfig fbg-0.9.1-2.fc9.i386 requires /bin/sh fbida-fbgs-2.06-5.fc9.i386 requires /bin/bash fbreader-0.8.12-2.fc9.i386 requires /sbin/ldconfig fbset-2.1-25.fc9.i386 requires /usr/bin/perl fcgi-2.4.0-5.fc9.i386 requires /sbin/ldconfig fcron-3.0.3-4.fc9.i386 requires /bin/sh fcron-3.0.3-4.fc9.i386 requires /usr/sbin/useradd fcron-3.0.3-4.fc9.i386 requires /sbin/service fcron-3.0.3-4.fc9.i386 requires /bin/sh fcron-3.0.3-4.fc9.i386 requires /sbin/chkconfig fedora-ds-admin-1.1.4-1.fc9.i386 requires /bin/sh fedora-ds-admin-1.1.4-1.fc9.i386 requires /usr/bin/env fedora-ds-admin-1.1.4-1.fc9.i386 requires /sbin/service fedora-ds-admin-1.1.4-1.fc9.i386 requires /sbin/ldconfig fedora-ds-admin-1.1.4-1.fc9.i386 requires /usr/bin/repl-monitor.pl fedora-ds-admin-1.1.4-1.fc9.i386 requires /bin/sh fedora-ds-admin-1.1.4-1.fc9.i386 requires /sbin/chkconfig fedora-ds-base-1.1.0.1-4.fc9.i386 requires /usr/bin/perl fedora-ds-base-1.1.0.1-4.fc9.i386 requires /sbin/ldconfig fedora-ds-base-1.1.0.1-4.fc9.i386 requires /bin/sh fedora-ds-base-1.1.0.1-4.fc9.i386 requires /sbin/service fedora-ds-base-1.1.0.1-4.fc9.i386 requires /sbin/chkconfig fedora-ds-base-1.1.0.1-4.fc9.i386 requires /usr/bin/env fedora-ds-base-1.1.0.1-4.fc9.i386 requires /bin/sh fedora-ds-dsgw-1.1.0-1.fc9.i386 requires /usr/bin/env fedora-ds-dsgw-1.1.0-1.fc9.i386 requires /etc/dirsrv/admin-serv/httpd.conf fedora-ds-dsgw-1.1.0-1.fc9.i386 requires /bin/sh fedora-icon-theme-1.0.0-1.fc8.noarch requires /bin/sh fedora-idm-console-1.1.1-2.fc9.i386 requires /bin/sh fedora-logos-9.0.0-3.fc10.noarch requires /bin/sh fedora-logos-9.0.0-3.fc10.noarch requires /bin/sh fedora-packager-0.3.0-1.fc9.noarch requires /bin/bash fedora-packager-0.3.0-1.fc9.noarch requires /usr/bin/python fedora-release-notes-9.0.1-1.noarch requires /bin/sh fedora-usermgmt-core-0.10-1.fc8.noarch requires /bin/bash fedora-usermgmt-devel-0.10-1.fc8.noarch requires /etc/rpm fedora-usermgmt-shadow-utils-0.10-1.fc8.noarch requires /bin/sh fedora-usermgmt-shadow-utils-0.10-1.fc8.noarch requires /usr/sbin/update-alternatives fedora-usermgmt-shadow-utils-0.10-1.fc8.noarch requires /bin/sh fedora-usermgmt-shadow-utils-0.10-1.fc8.noarch requires /etc/fedora/usermgmt feh-1.3.4-8.fc9.i386 requires /usr/bin/perl feh-1.3.4-8.fc9.i386 requires /bin/bash festival-1.96-4.fc9.i386 requires /bin/sh festival-docs-1.4.2-4.fc9.i386 requires /bin/sh festival-docs-1.4.2-4.fc9.i386 requires /sbin/install-info festival-lib-1.96-4.fc9.i386 requires /sbin/ldconfig festival-speechtools-libs-1.2.96-4.fc9.i386 requires /sbin/ldconfig festival-speechtools-utils-1.2.96-4.fc9.i386 requires /usr/bin/perl festival-speechtools-utils-1.2.96-4.fc9.i386 requires /bin/sh fftw-3.1.2-6.fc9.i386 requires /sbin/install-info fftw-3.1.2-6.fc9.i386 requires /sbin/ldconfig fftw-3.1.2-6.fc9.i386 requires /bin/sh fftw-devel-3.1.2-6.fc9.i386 requires /bin/sh fftw2-2.1.5-16.fc9.i386 requires /sbin/ldconfig fftw2-devel-2.1.5-16.fc9.i386 requires /bin/sh fig2ps-1.3.6-2.fc7.noarch requires /usr/bin/perl file-libs-4.23-5.fc9.i386 requires /sbin/ldconfig file-roller-2.23.1-1.fc10.i386 requires /bin/sh filelight-1.0-12.fc9.i386 requires /bin/sh fillets-ng-0.8.0-1.fc9.i386 requires /bin/sh finch-2.4.1-3.fc10.i386 requires /sbin/ldconfig 1:findutils-4.4.0-1.fc10.i386 requires /bin/sh 1:findutils-4.4.0-1.fc10.i386 requires /sbin/install-info fio-1.20-1.fc10.i386 requires /bin/bash firefox-3.0-0.59.cvs20080408.fc10.i386 requires /bin/sh firefox-3.0-0.59.cvs20080408.fc10.i386 requires /bin/sh firestarter-1.0.3-18.fc9.i386 requires /bin/sh firestarter-1.0.3-18.fc9.i386 requires /bin/sh firmware-tools-1.5.6-1.fc8.noarch requires /usr/bin/python2 firmware-tools-1.5.6-1.fc8.noarch requires /bin/sh firmware-tools-1.5.6-1.fc8.noarch requires /usr/bin/python firstaidkit-0.1.1-4.fc9.noarch requires /usr/bin/python firstaidkit-devel-0.1.1-4.fc9.noarch requires /bin/bash firstboot-1.98-1.fc10.i386 requires /bin/sh firstboot-1.98-1.fc10.i386 requires /bin/bash firstboot-1.98-1.fc10.i386 requires /usr/bin/python2 fish-1.23.0-2.fc9.i386 requires /bin/sh fityk-0.8.1-13.fc9.i386 requires /bin/sh flac-1.2.1-4.fc9.i386 requires /sbin/ldconfig flagpoll-0.9.1-2.fc9.noarch requires /usr/bin/python flawfinder-1.27-3.fc8.noarch requires /usr/bin/env flex-2.5.35-2.fc10.i386 requires /bin/sh flex-2.5.35-2.fc10.i386 requires /sbin/install-info flim-1.14.8-3.fc8.noarch requires /sbin/install-info flite-1.3-9.fc9.i386 requires /sbin/ldconfig flobopuyo-0.20-4.fc9.i386 requires /bin/sh flow-tools-0.68.4-1.fc9.i386 requires /bin/sh flow-tools-0.68.4-1.fc9.i386 requires /bin/env flow-tools-0.68.4-1.fc9.i386 requires /bin/sh fltk-1.1.8-1.fc9.i386 requires /sbin/ldconfig fltk-devel-1.1.8-1.fc9.i386 requires /bin/sh fltk-fluid-1.1.8-1.fc9.i386 requires /bin/sh fluidsynth-libs-1.0.7-11.a.fc9.i386 requires /sbin/ldconfig flumotion-0.4.2-5.fc9.i386 requires /usr/bin/python flumotion-0.4.2-5.fc9.i386 requires /bin/bash flumotion-0.4.2-5.fc9.i386 requires /bin/sh fluxbox-1.0.0-5.fc9.i386 requires /usr/bin/env fluxbox-1.0.0-5.fc9.i386 requires /bin/sh fluxstyle-1.0.1-2.fc7.noarch requires /usr/bin/env fmio-2.0.8-11.fc9.i386 requires /sbin/ldconfig fmio-2.0.8-11.fc9.i386 requires /usr/bin/python fmt-ptrn-java-1.3.17-1.fc9.i386 requires /sbin/ldconfig fmtools-1.0.2-3.fc9.i386 requires /bin/sh fnfx-0.3-11.fc9.i386 requires /bin/sh fnfx-0.3-11.fc9.i386 requires /bin/bash fnfx-0.3-11.fc9.i386 requires /sbin/chkconfig fnfx-0.3-11.fc9.i386 requires /sbin/service fontconfig-2.5.0-2.fc9.i386 requires /bin/sh fontconfig-2.5.0-2.fc9.i386 requires /sbin/ldconfig fontforge-20080309-1.fc9.i386 requires /usr/bin/fontforge fontforge-20080309-1.fc9.i386 requires /sbin/ldconfig fontmatrix-0.4.2-1.fc9.i386 requires /bin/sh fonts-ISO8859-2-1.0-18.fc8.noarch requires /bin/sh fonts-ISO8859-2-100dpi-1.0-18.fc8.noarch requires /bin/sh fonts-ISO8859-2-75dpi-1.0-18.fc8.noarch requires /bin/sh fonts-KOI8-R-1.0-10.fc8.noarch requires /usr/bin/perl fonts-hebrew-fancy-0.20051122-2.fc7.noarch requires /bin/sh fonts-japanese-0.20061016-13.fc9.noarch requires /bin/sh fonts-truetype-apl-4.22.1-3.fc10.i386 requires /bin/sh fonts-x11-apl-4.22.1-3.fc10.i386 requires /bin/sh fonttools-2.0-0.11.20060223cvs.fc7.i386 requires /usr/bin/python fontypython-0.2.0-6.fc7.noarch requires /usr/bin/python foomatic-3.0.2-60.fc10.i386 requires /bin/sh foomatic-3.0.2-60.fc10.i386 requires /usr/bin/perl foomatic-3.0.2-60.fc10.i386 requires /bin/bash fpc-2.2.0-12.fc10.i386 requires /bin/sh fpc-src-2.2.0-12.fc10.i386 requires /bin/sh fpc-src-2.2.0-12.fc10.i386 requires /usr/bin/env freealut-1.1.0-6.fc9.i386 requires /sbin/ldconfig freealut-devel-1.1.0-6.fc9.i386 requires /bin/sh freeciv-2.1.4-1.fc10.i386 requires /bin/sh freecol-0.7.3-2.fc9.noarch requires /bin/bash freecol-0.7.3-2.fc9.noarch requires /bin/sh freedoom-0.5-3.fc8.noarch requires /bin/sh freedroid-1.0.2-9.fc9.i386 requires /bin/sh freedroidrpg-0.10.3-2.fc9.i386 requires /bin/sh freefont-20060126-4.fc7.noarch requires /bin/sh freeglut-2.4.0-14.fc9.i386 requires /sbin/ldconfig freehdl-0.0.6-1.fc9.i386 requires /bin/sh freehdl-0.0.6-1.fc9.i386 requires /sbin/install-info freehdl-0.0.6-1.fc9.i386 requires /sbin/ldconfig freehdl-0.0.6-1.fc9.i386 requires /usr/bin/perl freehdl-0.0.6-1.fc9.i386 requires /bin/sh freeimage-3.10.0-1.fc9.i386 requires /sbin/ldconfig freeipmi-0.5.1-3.fc9.i386 requires /bin/sh freeipmi-0.5.1-3.fc9.i386 requires /sbin/ldconfig freeipmi-bmc-watchdog-0.5.1-3.fc9.i386 requires /bin/sh freeipmi-bmc-watchdog-0.5.1-3.fc9.i386 requires /bin/sh freeipmi-ipmidetectd-0.5.1-3.fc9.i386 requires /bin/sh freeipmi-ipmidetectd-0.5.1-3.fc9.i386 requires /bin/sh freenx-0.7.1-5.fc9.i386 requires /bin/sh freenx-0.7.1-5.fc9.i386 requires /bin/bash freenx-0.7.1-5.fc9.i386 requires /usr/bin/expect freenx-server-0.7.2-8.fc10.i386 requires /bin/sh freenx-server-0.7.2-8.fc10.i386 requires /usr/bin/expect freenx-server-0.7.2-8.fc10.i386 requires /usr/lib/nx freenx-server-0.7.2-8.fc10.i386 requires /bin/bash freenx-server-0.7.2-8.fc10.i386 requires /usr/lib/cups/backend freenx-server-0.7.2-8.fc10.i386 requires /bin/sh freeradius-2.0.2-2.fc9.i386 requires /bin/sh freeradius-2.0.2-2.fc9.i386 requires /sbin/ldconfig freeradius-2.0.2-2.fc9.i386 requires /usr/bin/perl freeradius-2.0.2-2.fc9.i386 requires /bin/sh freeradius-2.0.2-2.fc9.i386 requires /sbin/chkconfig freeradius-dialupadmin-2.0.2-2.fc9.i386 requires /usr/bin/perl freeradius-utils-2.0.2-2.fc9.i386 requires /usr/bin/perl freeradius-utils-2.0.2-2.fc9.i386 requires /bin/sh freetalk-3.0-2.fc9.i386 requires /sbin/install-info freetalk-3.0-2.fc9.i386 requires /bin/sh freetalk-3.0-2.fc9.i386 requires /bin/sh freetds-0.64-11.fc9.i386 requires /sbin/ldconfig freetennis-0.4.8-11.fc10.i386 requires /bin/sh freetype-2.3.5-4.fc9.i386 requires /sbin/ldconfig freetype-2.3.5-4.fc9.i386 requires /bin/sh freetype-devel-2.3.5-4.fc9.i386 requires /bin/sh freetype1-1.4-0.5.pre.fc9.i386 requires /sbin/ldconfig fribidi-0.19.1-2.fc9.i386 requires /sbin/ldconfig frozen-bubble-2.1.0-8.fc9.i386 requires /usr/bin/perl frozen-bubble-2.1.0-8.fc9.i386 requires /bin/sh frozen-bubble-server-2.1.0-8.fc9.i386 requires /bin/sh frozen-bubble-server-2.1.0-8.fc9.i386 requires /bin/sh frysk-0.2.1-2.fc9.i386 requires /sbin/ldconfig frysk-0.2.1-2.fc9.i386 requires /bin/sh frysk-devel-0.2.1-2.fc9.i386 requires /usr/bin/env frysk-devel-0.2.1-2.fc9.i386 requires /bin/bash frysk-devel-0.2.1-2.fc9.i386 requires /bin/sh fslint-2.24-1.fc8.noarch requires /bin/bash fslint-2.24-1.fc8.noarch requires /usr/bin/env fslint-2.24-1.fc8.noarch requires /bin/sh fslint-2.24-1.fc8.noarch requires /usr/bin/python ftgl-2.1.2-8.fc9.i386 requires /sbin/ldconfig ftnchek-3.3.1-7.fc9.i386 requires /bin/sh ftnchek-emacs-3.3.1-7.fc9.i386 requires /usr/share/emacs/site-lisp ftplib-3.1-4.fc9.i386 requires /sbin/ldconfig func-0.18-1.fc9.noarch requires /bin/sh func-0.18-1.fc9.noarch requires /bin/sh func-0.18-1.fc9.noarch requires /usr/bin/python funtools-1.4.0-7.fc9.i386 requires /bin/sh funtools-libs-1.4.0-7.fc9.i386 requires /sbin/ldconfig fuse-2.7.3-2.fc9.i386 requires /sbin/MAKEDEV fuse-2.7.3-2.fc9.i386 requires /bin/sh fuse-2.7.3-2.fc9.i386 requires /sbin/service fuse-2.7.3-2.fc9.i386 requires /bin/sh fuse-2.7.3-2.fc9.i386 requires /sbin/chkconfig fuse-encfs-1.4.2-2.fc10.i386 requires /sbin/ldconfig fuse-encfs-1.4.2-2.fc10.i386 requires /bin/sh fuse-gmailfs-0.8.0-1.fc9.noarch requires /usr/bin/env fuse-libs-2.7.3-2.fc9.i386 requires /sbin/ldconfig fuse-s3fs-0.5-1.fc10.noarch requires /usr/bin/python fusion-icon-0.1.0-0.2.5e2dc9git.fc9.noarch requires /bin/sh fusion-icon-0.1.0-0.2.5e2dc9git.fc9.noarch requires /usr/bin/python fvwm-2.5.24-2.fc9.i386 requires /usr/bin/python fvwm-2.5.24-2.fc9.i386 requires /usr/bin/mimeopen fvwm-2.5.24-2.fc9.i386 requires /usr/bin/perl fvwm-2.5.24-2.fc9.i386 requires /bin/sh fwbackups-1.43.1-6.fc9.noarch requires /bin/bash fwbackups-1.43.1-6.fc9.noarch requires /usr/bin/python fwbuilder-2.1.16-2.fc9.i386 requires /bin/sh fwfstab-0.03-2.fc9.noarch requires /bin/sh fwrestart-1.05-1.fc8.noarch requires /usr/bin/env fyre-1.0.1-5.fc9.i386 requires /sbin/service fyre-1.0.1-5.fc9.i386 requires /bin/bash fyre-1.0.1-5.fc9.i386 requires /sbin/chkconfig fyre-1.0.1-5.fc9.i386 requires /bin/sh g-wrap-1.9.9-5.fc9.i386 requires /sbin/install-info g-wrap-1.9.9-5.fc9.i386 requires /sbin/ldconfig g-wrap-devel-1.9.9-5.fc9.i386 requires /bin/sh g-wrap-devel-1.9.9-5.fc9.i386 requires /bin/sh g2banking-2.3.3-3.fc9.i386 requires /sbin/ldconfig g2banking-devel-2.3.3-3.fc9.i386 requires /bin/sh gai-0.5.10-14.fc9.i386 requires /sbin/ldconfig gajim-0.11.4-2.fc9.i386 requires /usr/bin/env gajim-0.11.4-2.fc9.i386 requires /bin/bash gajim-0.11.4-2.fc9.i386 requires /bin/sh galeon-2.0.5-1.fc9.i386 requires /bin/sh gallery2-2.2.4-4.fc10.noarch requires /bin/sh gallery2-2.2.4-4.fc10.noarch requires /usr/bin/perl gallery2-2.2.4-4.fc10.noarch requires /usr/bin/php gallery2-2.2.4-4.fc10.noarch requires /bin/sh galternatives-0.13.4-5.fc9.noarch requires /usr/sbin/update-alternatives galternatives-0.13.4-5.fc9.noarch requires /usr/bin/python gambas-ide-1.0.19-6.fc9.i386 requires /usr/bin/gbx gambas-runtime-1.0.19-6.fc9.i386 requires /usr/bin/gbx gambas2-gb-chart-2.5.0-1.fc9.i386 requires /usr/bin/env gambas2-gb-db-2.5.0-1.fc9.i386 requires /usr/bin/env gambas2-gb-desktop-2.5.0-1.fc9.i386 requires /usr/bin/env gambas2-gb-form-2.5.0-1.fc9.i386 requires /usr/bin/env gambas2-gb-form-dialog-2.5.0-1.fc9.i386 requires /usr/bin/env gambas2-gb-form-mdi-2.5.0-1.fc9.i386 requires /usr/bin/env gambas2-gb-gtk-2.5.0-1.fc9.i386 requires /usr/bin/env gambas2-gb-info-2.5.0-1.fc9.i386 requires /usr/bin/env gambas2-gb-qt-2.5.0-1.fc9.i386 requires /usr/bin/env gambas2-gb-report-2.5.0-1.fc9.i386 requires /usr/bin/env gambas2-gb-settings-2.5.0-1.fc9.i386 requires /usr/bin/env gambas2-gb-web-2.5.0-1.fc9.i386 requires /usr/bin/env gambas2-gb-xml-rpc-2.5.0-1.fc9.i386 requires /usr/bin/env gambas2-ide-2.5.0-1.fc9.i386 requires /usr/bin/env gambas2-runtime-2.5.0-1.fc9.i386 requires /bin/sh gambas2-script-2.5.0-1.fc9.i386 requires /bin/sh gambas2-script-2.5.0-1.fc9.i386 requires /usr/bin/env games-menus-0.3.2-1.fc9.noarch requires /bin/sh gamin-0.1.9-5.fc9.i386 requires /bin/sh gamin-python-0.1.9-5.fc9.i386 requires /usr/bin/env gammu-1.18.91-1.fc9.i386 requires /bin/bash gammu-1.18.91-1.fc9.i386 requires /bin/sh gammu-libs-1.18.91-1.fc9.i386 requires /sbin/ldconfig ganglia-3.0.7-1.fc9.i386 requires /bin/sh ganglia-3.0.7-1.fc9.i386 requires /bin/sh ganglia-devel-3.0.7-1.fc9.i386 requires /sbin/ldconfig ganglia-gmetad-3.0.7-1.fc9.i386 requires /bin/sh ganglia-gmetad-3.0.7-1.fc9.i386 requires /sbin/service ganglia-gmetad-3.0.7-1.fc9.i386 requires /bin/sh ganglia-gmetad-3.0.7-1.fc9.i386 requires /sbin/chkconfig ganglia-gmond-3.0.7-1.fc9.i386 requires /bin/sh ganglia-gmond-3.0.7-1.fc9.i386 requires /sbin/service ganglia-gmond-3.0.7-1.fc9.i386 requires /bin/sh ganglia-gmond-3.0.7-1.fc9.i386 requires /sbin/chkconfig ganymed-ssh2-210-6.fc9.i386 requires /usr/bin/rebuild-gcj-db ganyremote-2.8-2.fc10.noarch requires /usr/bin/env gauche-0.8.13-1.fc9.i386 requires /bin/sh gauche-0.8.13-1.fc9.i386 requires /usr/bin/gosh gauche-0.8.13-1.fc9.i386 requires /sbin/install-info gauche-0.8.13-1.fc9.i386 requires /sbin/ldconfig gauche-gl-0.4.4-3.fc9.i386 requires /bin/sh gauche-gl-0.4.4-3.fc9.i386 requires /sbin/install-info gauche-gl-0.4.4-3.fc9.i386 requires /bin/sh gauche-gtk-0.4.1-17.fc9.i386 requires /bin/sh gawk-3.1.5-17.fc9.i386 requires /bin/sh gawk-3.1.5-17.fc9.i386 requires /bin/mktemp gawk-3.1.5-17.fc9.i386 requires /sbin/install-info gawk-3.1.5-17.fc9.i386 requires /bin/sh gazpacho-0.7.2-2.fc8.noarch requires /usr/bin/python gbrainy-0.61-5.fc9.i386 requires /bin/sh gbrainy-0.61-5.fc9.i386 requires /bin/bash gc-7.1-1.fc10.i386 requires /sbin/ldconfig gcalctool-5.23.1-1.fc10.i386 requires /bin/sh gcc-4.3.0-8.i386 requires /bin/sh gcc-4.3.0-8.i386 requires /sbin/install-info gcc-4.3.0-8.i386 requires /bin/sh gcc-gfortran-4.3.0-8.i386 requires /bin/sh gcc-gfortran-4.3.0-8.i386 requires /sbin/install-info gcc-gnat-4.3.0-8.i386 requires /bin/sh gcc-gnat-4.3.0-8.i386 requires /sbin/install-info gcc-java-4.3.0-8.i386 requires /bin/sh gcc-java-4.3.0-8.i386 requires /sbin/install-info gcc-java-4.3.0-8.i386 requires /usr/share/java/eclipse-ecj.jar gcdmaster-1.2.2-4.fc9.i386 requires /bin/sh gchempaint-0.8.7-2.fc9.i386 requires /bin/sh gcin-1.3.9-2.fc9.i386 requires /bin/sh gcin-1.3.9-2.fc9.i386 requires /usr/sbin/alternatives gcin-1.3.9-2.fc9.i386 requires /bin/bash gcl-2.6.7-18.fc9.i386 requires /bin/sh gcl-2.6.7-18.fc9.i386 requires /sbin/install-info gcl-2.6.7-18.fc9.i386 requires /bin/sh 1:gcombust-0.1.55-13.i386 requires /bin/sh gcompris-8.4.5-1.fc10.i386 requires /sbin/install-info gcompris-8.4.5-1.fc10.i386 requires /bin/sh gconf-editor-2.22.0-1.fc9.i386 requires /bin/sh gconfmm26-2.22.0-1.fc9.i386 requires /bin/sh gconfmm26-2.22.0-1.fc9.i386 requires /sbin/ldconfig gcstar-1.3.2-1.fc9.noarch requires /usr/bin/perl gcstar-1.3.2-1.fc9.noarch requires /bin/sh gd-2.0.35-5.fc9.i386 requires /sbin/ldconfig gd-devel-2.0.35-5.fc9.i386 requires /bin/sh gd-progs-2.0.35-5.fc9.i386 requires /usr/bin/perl gdal-1.5.1-5.fc9.i386 requires /sbin/ldconfig gdal-devel-1.5.1-5.fc9.i386 requires /bin/sh gdal-python-1.5.1-5.fc9.i386 requires /usr/bin/env gdb-6.8-5.fc10.i386 requires /bin/sh gdb-6.8-5.fc10.i386 requires /sbin/install-info gdb-6.8-5.fc10.i386 requires /bin/sh gdbm-1.8.0-28.fc9.i386 requires /sbin/ldconfig gdbm-devel-1.8.0-28.fc9.i386 requires /bin/sh gdbm-devel-1.8.0-28.fc9.i386 requires /sbin/install-info gdeskcal-1.01-1.fc7.noarch requires /bin/sh gdeskcal-1.01-1.fc7.noarch requires /usr/bin/env gdesklets-0.36-1.fc9.i386 requires /usr/bin/env gdesklets-0.36-1.fc9.i386 requires /bin/sh gdevilspie-0.31-2.fc10.noarch requires /usr/bin/python 1:gdk-pixbuf-0.22.0-36.fc9.i386 requires /sbin/ldconfig 1:gdk-pixbuf-devel-0.22.0-36.fc9.i386 requires /bin/sh 1:gdm-2.22.0-6.fc10.i386 requires /bin/sh 1:gdm-2.22.0-6.fc10.i386 requires /usr/sbin/useradd 1:gdm-2.22.0-6.fc10.i386 requires /sbin/nologin 1:gdm-2.22.0-6.fc10.i386 requires /bin/sh gdome2-0.8.1-6.2.fc9.i386 requires /sbin/ldconfig gdome2-devel-0.8.1-6.2.fc9.i386 requires /bin/sh gds2pov-0.20080229-1.fc9.i386 requires /sbin/ldconfig geant321-2006-29.fc9.i386 requires /bin/sh geant321-g77-2006-29.fc9.i386 requires /bin/sh geda-gattrib-20080127-2.fc9.i386 requires /bin/sh geda-gnetlist-20080127-1.fc9.i386 requires /usr/bin/gawk geda-gnetlist-20080127-1.fc9.i386 requires /bin/bash geda-gschem-20080127-2.fc9.i386 requires /bin/sh geda-gschem-20080127-2.fc9.i386 requires /bin/sh geda-utils-20080127-1.fc9.i386 requires /usr/bin/env geda-utils-20080127-1.fc9.i386 requires /usr/bin/python geda-utils-20080127-1.fc9.i386 requires /usr/bin/perl geda-utils-20080127-1.fc9.i386 requires /bin/bash 1:gedit-2.23.1-1.fc10.i386 requires /bin/sh 1:gedit-2.23.1-1.fc10.i386 requires /bin/sh gedit-plugins-2.22.0-1.fc9.i386 requires /bin/sh geeqie-1.0-0.4.alpha1.fc10.i386 requires /bin/sh gegl-0.0.16-1.fc9.i386 requires /sbin/ldconfig gemdropx-0.9-4.fc9.i386 requires /bin/sh gengetopt-2.22-1.fc9.i386 requires /bin/sh gengetopt-2.22-1.fc9.i386 requires /sbin/install-info genisoimage-1.1.6-11.fc9.i386 requires /bin/sh genisoimage-1.1.6-11.fc9.i386 requires /usr/sbin/alternatives genisoimage-1.1.6-11.fc9.i386 requires /bin/sh genisoimage-1.1.6-11.fc9.i386 requires /usr/bin/perl gentium-fonts-1.02-5.fc7.noarch requires /bin/sh geoclue-0.11.1-4.fc10.i386 requires /sbin/ldconfig geomview-1.9.4-8.fc9.i386 requires /bin/sh geomview-1.9.4-8.fc9.i386 requires /sbin/install-info geomview-1.9.4-8.fc9.i386 requires /bin/sh geomview-libs-1.9.4-8.fc9.i386 requires /sbin/ldconfig geoqo-0.96-5.fc9.noarch requires /usr/bin/perl geos-3.0.0-3.fc10.i386 requires /sbin/ldconfig geos-devel-3.0.0-3.fc10.i386 requires /bin/sh gerbv-2.0.0-1.fc9.i386 requires /usr/bin/perl gerbv-2.0.0-1.fc9.i386 requires /bin/sh geronimo-specs-1.0-1.M2.2jpp.12.i386 requires /bin/sh getmail-4.8.1-1.fc9.noarch requires /usr/bin/python gettext-0.17-5.fc10.i386 requires /bin/sh gettext-0.17-5.fc10.i386 requires /sbin/install-info gettext-0.17-5.fc10.i386 requires /usr/bin/python gettext-0.17-5.fc10.i386 requires /sbin/ldconfig gettext-0.17-5.fc10.i386 requires /bin/sh gettext-devel-0.17-5.fc10.i386 requires /bin/sh gettext-devel-0.17-5.fc10.i386 requires /sbin/install-info gettext-devel-0.17-5.fc10.i386 requires /sbin/ldconfig gettext-devel-0.17-5.fc10.i386 requires /bin/sh gfa-0.4.1-6.fc9.i386 requires /bin/sh gforth-0.6.2-12.fc9.i386 requires /bin/sh gforth-0.6.2-12.fc9.i386 requires /usr/bin/gforth gforth-0.6.2-12.fc9.i386 requires /sbin/install-info gforth-0.6.2-12.fc9.i386 requires /bin/sh gfs-artemisia-fonts-20070415-6.fc10.noarch requires /bin/sh gfs-baskerville-fonts-20070327-7.fc10.noarch requires /bin/sh gfs-bodoni-classic-fonts-20070415-6.fc10.noarch requires /bin/sh gfs-bodoni-fonts-20070415-5.fc10.noarch requires /bin/sh gfs-complutum-fonts-20070413-7.fc10.noarch requires /bin/sh gfs-didot-classic-fonts-20070415-5.fc10.noarch requires /bin/sh gfs-didot-fonts-20070616-6.fc10.noarch requires /bin/sh gfs-gazis-fonts-20080318-2.fc10.noarch requires /bin/sh gfs-neohellenic-fonts-20070415-5.fc10.noarch requires /bin/sh gfs-olga-fonts-20060908-5.fc10.noarch requires /bin/sh gfs-porson-fonts-20060908-7.fc10.noarch requires /bin/sh gfs-solomos-fonts-20071114-6.fc10.noarch requires /bin/sh gfs-theokritos-fonts-20070415-6.fc10.noarch requires /bin/sh gfs2-utils-2.03.00-4.fc10.i386 requires /bin/sh gfs2-utils-2.03.00-4.fc10.i386 requires /bin/bash gfs2-utils-2.03.00-4.fc10.i386 requires /sbin/chkconfig gfs2-utils-2.03.00-4.fc10.i386 requires /sbin/service 2:gftp-2.0.18-3.fc9.i386 requires /bin/sh gg2-libs-2.3.0-9.fc9.i386 requires /sbin/ldconfig ggobi-2.1.7-1.fc9.i386 requires /sbin/ldconfig ggz-client-libs-0.0.14.1-1.fc9.i386 requires /sbin/ldconfig ggz-gtk-client-0.0.14.1-1.fc9.i386 requires /sbin/ldconfig ghc-6.8.2-2.fc9.i386 requires /bin/sh ghc-6.8.2-2.fc9.i386 requires /usr/bin/perl ghc-6.8.2-2.fc9.i386 requires /bin/sh ghc682-6.8.2-2.fc9.i386 requires /bin/sh ghc682-6.8.2-2.fc9.i386 requires /usr/bin/perl ghc682-6.8.2-2.fc9.i386 requires /bin/sh ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.i386 requires /bin/sh ghdl-0.26-0.94svn.7.fc10.i386 requires /bin/sh ghdl-0.26-0.94svn.7.fc10.i386 requires /sbin/install-info ghex-2.22.0-1.i386 requires /sbin/ldconfig ghex-2.22.0-1.i386 requires /bin/sh ghostscript-8.62-3.fc9.i386 requires /sbin/ldconfig ghostscript-8.62-3.fc9.i386 requires /usr/bin/perl ghostscript-8.62-3.fc9.i386 requires /bin/sh ghostscript-devel-8.62-3.fc9.i386 requires /bin/sh ghostscript-fonts-5.50-18.fc8.noarch requires /bin/sh ghostscript-fonts-5.50-18.fc8.noarch requires /usr/bin/mkfontscale ghostscript-fonts-5.50-18.fc8.noarch requires /usr/bin/mkfontdir giblib-1.2.4-11.i386 requires /sbin/ldconfig giblib-devel-1.2.4-11.i386 requires /bin/sh giflib-4.1.3-9.i386 requires /sbin/ldconfig giflib-utils-4.1.3-9.i386 requires /usr/bin/perl giflib-utils-4.1.3-9.i386 requires /bin/sh gift-0.11.8.1-10.fc9.i386 requires /sbin/ldconfig gift-0.11.8.1-10.fc9.i386 requires /usr/bin/perl gift-0.11.8.1-10.fc9.i386 requires /bin/bash gift-gnutella-0.0.11-5.fc9.i386 requires /sbin/ldconfig giggle-0.4-2.fc9.i386 requires /bin/sh gimmage-0.2.3-2.fc9.i386 requires /bin/sh gimmie-0.2.8-2.fc9.i386 requires /usr/bin/python gimmie-0.2.8-2.fc9.i386 requires /bin/sh 2:gimp-2.4.5-1.fc9.i386 requires /usr/bin/update-desktop-database 2:gimp-2.4.5-1.fc9.i386 requires /usr/bin/env 2:gimp-2.4.5-1.fc9.i386 requires /bin/bash 2:gimp-2.4.5-1.fc9.i386 requires /bin/sh 2:gimp-2.4.5-1.fc9.i386 requires /bin/sh 2:gimp-libs-2.4.5-1.fc9.i386 requires /sbin/ldconfig ginac-1.4.3-1.fc10.i386 requires /sbin/ldconfig ginac-1.4.3-1.fc10.i386 requires /sbin/install-info ginac-devel-1.4.3-1.fc10.i386 requires /bin/sh ginac-utils-1.4.3-1.fc10.i386 requires /bin/sh git-1.5.5.1-1.fc10.i386 requires /usr/bin/perl git-1.5.5.1-1.fc10.i386 requires /bin/sh git-arch-1.5.5.1-1.fc10.i386 requires /usr/bin/perl git-cvs-1.5.5.1-1.fc10.i386 requires /usr/bin/perl git-email-1.5.5.1-1.fc10.i386 requires /usr/bin/perl git-gui-1.5.5.1-1.fc10.i386 requires /bin/sh git-svn-1.5.5.1-1.fc10.i386 requires /usr/bin/perl gitk-1.5.5.1-1.fc10.i386 requires /bin/sh gitweb-1.5.5.1-1.fc10.i386 requires /usr/bin/perl gjots2-2.3.4-8.fc10.noarch requires /bin/sh gjots2-2.3.4-8.fc10.noarch requires /usr/bin/env gkrellm-2.3.1-3.fc9.i386 requires /bin/sh gkrellm-daemon-2.3.1-3.fc9.i386 requires /sbin/service gkrellm-daemon-2.3.1-3.fc9.i386 requires /bin/bash gkrellm-daemon-2.3.1-3.fc9.i386 requires /sbin/chkconfig gkrellm-daemon-2.3.1-3.fc9.i386 requires /bin/sh gkrellm-weather-2.0.7-6.fc9.i386 requires /usr/bin/perl glabels-2.2.2-1.fc10.i386 requires /sbin/ldconfig glabels-2.2.2-1.fc10.i386 requires /bin/sh glabels-doc-2.2.2-1.fc10.i386 requires /bin/sh glabels-libs-2.2.2-1.fc10.i386 requires /sbin/ldconfig glade3-3.4.4-1.fc9.i386 requires /bin/sh glade3-libgladeui-3.4.4-1.fc9.i386 requires /sbin/ldconfig glaxium-0.5-4.fc9.i386 requires /bin/sh glest-3.1.2-1.fc9.i386 requires /bin/sh glew-1.5.0-2.fc9.i386 requires /sbin/ldconfig glglobe-0.2-6.fc9.i386 requires /bin/sh 1:glib-1.2.10-29.fc9.i386 requires /sbin/ldconfig 1:glib-devel-1.2.10-29.fc9.i386 requires /bin/sh glib-java-0.2.6-12.fc9.i386 requires /sbin/ldconfig glib-java-0.2.6-12.fc9.i386 requires /sbin/ldconfig glib2-2.16.3-5.fc10.i386 requires /sbin/ldconfig glib2-devel-2.16.3-5.fc10.i386 requires /usr/bin/perl glib2-devel-2.16.3-5.fc10.i386 requires /bin/sh glibc-2.8.90-2.i386 requires /sbin/ldconfig glibc-2.8.90-2.i386 requires /usr/sbin/glibc_post_upgrade.i386 glibc-2.8.90-2.i686 requires /usr/sbin/glibc_post_upgrade.i686 glibc-2.8.90-2.i686 requires /sbin/ldconfig glibc-common-2.8.90-2.i386 requires /usr/sbin/build-locale-archive glibc-common-2.8.90-2.i386 requires /bin/bash glibc-common-2.8.90-2.i386 requires /usr/sbin/tzdata-update glibc-common-2.8.90-2.i386 requires /bin/sh glibc-devel-2.8.90-2.i386 requires /bin/sh glibc-devel-2.8.90-2.i386 requires /sbin/install-info glibc-headers-2.8.90-2.i386 requires /bin/sh glibc-utils-2.8.90-2.i386 requires /sbin/ldconfig glibc-utils-2.8.90-2.i386 requires /bin/bash glibc-utils-2.8.90-2.i386 requires /usr/bin/perl glibmm24-2.16.0-1.fc9.i386 requires /sbin/ldconfig glibmm24-devel-2.16.0-1.fc9.i386 requires /usr/bin/perl glimmer-3.02-3.fc9.i386 requires /bin/csh glimmer-3.02-3.fc9.i386 requires /bin/awk glipper-1.0-3.fc9.i386 requires /usr/bin/env glipper-1.0-3.fc9.i386 requires /bin/sh glitz-0.5.6-6.fc9.i386 requires /sbin/ldconfig glitz-glx-0.5.6-6.fc9.i386 requires /sbin/ldconfig gliv-1.9.6-3.fc9.i386 requires /bin/sh glob2-0.9.3-1.fc10.i386 requires /bin/sh global-5.4-2.fc9.i386 requires /bin/sh glom-1.6.15-1.fc9.i386 requires /sbin/ldconfig glom-1.6.15-1.fc9.i386 requires /bin/sh glpi-0.70.2-3.fc10.noarch requires /bin/sh glpi-0.70.2-3.fc10.noarch requires /sbin/service glpi-0.70.2-3.fc10.noarch requires /etc/logrotate.d glpi-mass-ocs-import-1.1-1.fc9.noarch requires /bin/sh glpi-mass-ocs-import-1.1-1.fc9.noarch requires /bin/sh glpi-mass-ocs-import-1.1-1.fc9.noarch requires /etc/cron.d glpk-4.28-1.fc10.i386 requires /sbin/ldconfig glpk-utils-4.28-1.fc10.i386 requires /bin/sh glump-0.9.11-3.fc8.noarch requires /usr/bin/python glunarclock-0.32.4-11.fc9.i386 requires /bin/sh glusterfs-client-1.3.9-1.fc10.i386 requires /bin/sh glusterfs-libs-1.3.9-1.fc10.i386 requires /sbin/ldconfig glusterfs-server-1.3.9-1.fc10.i386 requires /bin/sh glusterfs-server-1.3.9-1.fc10.i386 requires /bin/sh glyph-keeper-0.32-4.fc9.i386 requires /sbin/ldconfig gmediaserver-0.13.0-3.fc9.i386 requires /bin/sh gmediaserver-0.13.0-3.fc9.i386 requires /sbin/install-info gmediaserver-0.13.0-3.fc9.i386 requires /bin/bash gmediaserver-0.13.0-3.fc9.i386 requires /sbin/chkconfig gmfsk-0.7-0.5.pre1.fc9.i386 requires /bin/sh gmime-2.2.19-1.fc10.i386 requires /sbin/ldconfig gmime-devel-2.2.19-1.fc10.i386 requires /bin/sh gmp-4.2.2-7.fc9.i386 requires /sbin/ldconfig gmp-devel-4.2.2-7.fc9.i386 requires /bin/sh gmp-devel-4.2.2-7.fc9.i386 requires /sbin/install-info gmpc-0.15.5.0-3.fc9.i386 requires /bin/sh gmyth-0.7.1-1.fc9.i386 requires /sbin/ldconfig gnash-0.8.2-2.fc9.i386 requires /bin/sh gnash-0.8.2-2.fc9.i386 requires /sbin/install-info gnash-0.8.2-2.fc9.i386 requires /sbin/ldconfig gnash-0.8.2-2.fc9.i386 requires /bin/sh gnash-plugin-0.8.2-2.fc9.i386 requires /usr/lib/mozilla/plugins gnet2-2.0.7-11.fc9.i386 requires /sbin/ldconfig gnochm-0.9.11-2.fc9.noarch requires /bin/sh gnochm-0.9.11-2.fc9.noarch requires /usr/bin/python gnofract4d-3.8-1.fc9.i386 requires /usr/bin/env gnofract4d-3.8-1.fc9.i386 requires /usr/bin/python gnofract4d-3.8-1.fc9.i386 requires /bin/sh gnokii-0.6.24-1.fc9.i386 requires /bin/sh gnokii-0.6.24-1.fc9.i386 requires /usr/sbin/groupadd gnokii-0.6.24-1.fc9.i386 requires /sbin/ldconfig gnokii-smsd-0.6.24-1.fc9.i386 requires /usr/sbin/useradd gnokii-smsd-0.6.24-1.fc9.i386 requires /bin/bash gnokii-smsd-0.6.24-1.fc9.i386 requires /bin/sh gnokii-smsd-0.6.24-1.fc9.i386 requires /sbin/chkconfig gnokii-smsd-0.6.24-1.fc9.i386 requires /bin/sh gnome-applet-music-2.3.1-1.fc10.i386 requires /bin/sh gnome-applet-music-2.3.1-1.fc10.i386 requires /usr/bin/env gnome-applet-netspeed-0.14-3.fc9.i386 requires /bin/sh gnome-applet-sensors-1.8.2-2.fc9.i386 requires /bin/sh gnome-applet-sshmenu-3.15-5.fc9.noarch requires /bin/sh gnome-applet-sshmenu-3.15-5.fc9.noarch requires /usr/bin/ruby gnome-applet-timer-2.0.1-1.fc9.i386 requires /bin/sh gnome-applet-timer-2.0.1-1.fc9.i386 requires /usr/bin/env gnome-applet-vm-0.2.0-2.fc9.i386 requires /sbin/ldconfig gnome-applet-vm-0.2.0-2.fc9.i386 requires /usr/bin/gconftool-2 gnome-applet-vm-0.2.0-2.fc9.i386 requires /usr/bin/scrollkeeper-update gnome-applet-vm-0.2.0-2.fc9.i386 requires /bin/sh 1:gnome-applets-2.23.2-1.fc10.i386 requires /bin/sh 1:gnome-applets-2.23.2-1.fc10.i386 requires /usr/bin/env gnome-bluetooth-0.11.0-3.fc9.i386 requires /bin/sh gnome-bluetooth-libs-0.11.0-3.fc9.i386 requires /sbin/ldconfig gnome-build-0.2.4-1.fc9.i386 requires /sbin/ldconfig gnome-build-0.2.4-1.fc9.i386 requires /usr/bin/perl gnome-chemistry-utils-0.8.7-1.fc9.i386 requires /bin/sh gnome-chemistry-utils-mozplugin-0.8.7-1.fc9.i386 requires /usr/lib/mozilla/plugins gnome-commander-1.2.5-1.fc9.i386 requires /bin/sh gnome-common-2.18.0-1.fc8.noarch requires /bin/sh gnome-compiz-manager-0.10.4-4.fc9.i386 requires /sbin/ldconfig gnome-compiz-manager-0.10.4-4.fc9.i386 requires /bin/sh gnome-desktop-2.23.2-0.2008.05.14.1.fc10.i386 requires /usr/bin/python gnome-desktop-2.23.2-0.2008.05.14.1.fc10.i386 requires /sbin/ldconfig gnome-device-manager-0.2-3.fc9.i386 requires /bin/sh gnome-device-manager-devel-0.2-3.fc9.i386 requires /sbin/ldconfig gnome-device-manager-libs-0.2-3.fc9.i386 requires /sbin/ldconfig gnome-do-0.4.2.0-1.fc10.i386 requires /bin/sh gnome-doc-utils-0.12.2-1.fc9.noarch requires /bin/sh gnome-doc-utils-0.12.2-1.fc9.noarch requires /usr/bin/python 1:gnome-games-2.23.1-2.fc10.i386 requires /bin/sh 1:gnome-games-2.23.1-2.fc10.i386 requires /usr/bin/env gnome-genius-1.0.2-3.fc9.i386 requires /bin/sh gnome-icon-theme-2.22.0-6.fc9.noarch requires /bin/sh gnome-keyring-2.22.1-1.fc9.i386 requires /sbin/ldconfig gnome-keyring-2.22.1-1.fc9.i386 requires /bin/sh gnome-keyring-manager-2.20.0-2.fc9.i386 requires /bin/sh gnome-launch-box-0.4-9.fc10.i386 requires /bin/sh 1:gnome-libs-1.4.2-8.fc9.i386 requires /sbin/ldconfig 1:gnome-libs-1.4.2-8.fc9.i386 requires /bin/sh 1:gnome-libs-devel-1.4.2-8.fc9.i386 requires /bin/sh 1:gnome-libs-devel-1.4.2-8.fc9.i386 requires /usr/bin/perl gnome-mag-0.15.0-2.fc9.i386 requires /sbin/ldconfig gnome-media-2.23.1.1-2.fc10.i386 requires /bin/sh gnome-menus-2.23.1-1.fc10.i386 requires /sbin/ldconfig gnome-mount-0.8-1.fc9.i386 requires /bin/sh gnome-nds-thumbnailer-1.0.2-1.fc9.i386 requires /bin/sh gnome-netstatus-2.12.1-4.fc9.i386 requires /bin/sh gnome-nettool-2.22.0-1.fc9.i386 requires /bin/sh gnome-packagekit-0.2.1-2.20080508.fc10.i386 requires /bin/sh gnome-packagekit-0.2.1-2.20080508.fc10.i386 requires /usr/bin/python gnome-panel-2.23.2.1-1.fc10.i386 requires /bin/sh gnome-password-generator-1.5-2.fc9.noarch requires /bin/sh gnome-password-generator-1.5-2.fc9.noarch requires /usr/bin/python gnome-phone-manager-0.51-2.fc10.i386 requires /bin/sh gnome-pilot-2.0.16-2.fc9.i386 requires /bin/sh gnome-pilot-conduits-2.0.16-1.fc9.i386 requires /sbin/ldconfig gnome-power-manager-2.22.1-1.fc9.i386 requires /bin/sh gnome-power-manager-2.22.1-1.fc9.i386 requires /bin/sh gnome-ppp-0.3.23-5.fc9.i386 requires /bin/sh gnome-python2-bonobo-2.22.0-2.fc9.i386 requires /usr/bin/env gnome-python2-bonobo-2.22.0-2.fc9.i386 requires /bin/sh gnome-python2-gconf-2.22.0-2.fc9.i386 requires /usr/bin/env gnome-python2-gnomeprint-2.22.0-4.fc10.i386 requires /usr/bin/env gnome-python2-gnomevfs-2.22.0-2.fc9.i386 requires /usr/bin/env gnome-python2-libegg-2.19.1-15.fc9.i386 requires /usr/bin/python gnome-scan-0.6-2.fc9.i386 requires /bin/sh gnome-scan-libs-0.6-2.fc9.i386 requires /sbin/ldconfig gnome-schedule-2.0.2-1.fc9.noarch requires /bin/sh gnome-schedule-2.0.2-1.fc9.noarch requires /bin/sh gnome-screensaver-2.23.3-0.2008.05.14.1.fc10.i386 requires /bin/sh gnome-session-2.23.2.2-3.fc10.i386 requires /bin/sh gnome-session-2.23.2.2-3.fc10.i386 requires /bin/sh gnome-settings-daemon-2.23.2-0.2008.05.14.2.fc10.i386 requires /bin/sh gnome-sharp-2.16.1-1.fc9.i386 requires /sbin/ldconfig gnome-sharp-2.16.1-1.fc9.i386 requires /bin/sh gnome-specimen-0.3-1.fc8.noarch requires /bin/sh gnome-specimen-0.3-1.fc8.noarch requires /usr/bin/python gnome-speech-0.4.19-1.fc10.i386 requires /sbin/ldconfig gnome-system-monitor-2.22.1-5.fc9.i386 requires /bin/sh gnome-terminal-2.22.1-1.fc9.i386 requires /bin/sh gnome-themes-2.23.1-1.fc10.noarch requires /bin/sh gnome-translate-0.99-12.fc9.i386 requires /bin/sh gnome-user-docs-2.22.0-1.fc9.noarch requires /bin/sh gnome-user-share-0.31-1.fc9.i386 requires /bin/sh 1:gnome-utils-2.20.0.1-5.fc10.i386 requires /bin/sh gnome-vfs2-2.22.0-1.fc9.i386 requires /bin/sh gnome-vfs2-2.22.0-1.fc9.i386 requires /sbin/ldconfig gnome-vfs2-monikers-2.15.3-5.fc9.i386 requires /sbin/ldconfig gnome-vfsmm26-2.22.0-1.fc9.i386 requires /bin/sh gnome-vfsmm26-2.22.0-1.fc9.i386 requires /sbin/ldconfig gnome-volume-manager-2.22.5-1.fc10.i386 requires /bin/sh gnome-volume-manager-2.22.5-1.fc10.i386 requires /bin/sh gnome-web-photo-0.3-11.fc9.i386 requires /bin/sh gnomebaker-0.6.2-2.1.fc9.i386 requires /bin/sh gnomecatalog-0.3.4-3.fc9.noarch requires /usr/bin/python gnomeradio-1.7-5.fc9.i386 requires /bin/sh gnomesword-2.3.3-2.fc9.i386 requires /bin/sh gnotime-2.3.0-1.fc9.i386 requires /bin/sh gnotime-2.3.0-1.fc9.i386 requires /bin/sh gnu-getopt-1.0.12-4jpp.1.i386 requires /bin/sh gnu-getopt-javadoc-1.0.12-4jpp.1.i386 requires /bin/sh gnu-getopt-javadoc-1.0.12-4jpp.1.i386 requires /bin/ln gnu-getopt-javadoc-1.0.12-4jpp.1.i386 requires /bin/rm gnu-smalltalk-3.0.1-3.fc9.i386 requires /bin/sh gnu-smalltalk-3.0.1-3.fc9.i386 requires /bin/sed gnu-smalltalk-3.0.1-3.fc9.i386 requires /sbin/install-info gnu-smalltalk-3.0.1-3.fc9.i386 requires /sbin/ldconfig gnu-smalltalk-3.0.1-3.fc9.i386 requires /usr/bin/perl gnu-smalltalk-3.0.1-3.fc9.i386 requires /bin/sh gnu-smalltalk-devel-3.0.1-3.fc9.i386 requires /bin/sh gnubg-20061119-14.fc9.i386 requires /sbin/install-info gnubg-20061119-14.fc9.i386 requires /bin/sh gnubiff-2.2.7-4.fc9.i386 requires /sbin/install-info gnubiff-2.2.7-4.fc9.i386 requires /bin/sh gnucap-0.35-4.fc9.i386 requires /bin/sh gnucash-2.2.4-1.fc9.i386 requires /sbin/ldconfig gnucash-2.2.4-1.fc9.i386 requires /usr/bin/perl gnucash-2.2.4-1.fc9.i386 requires /bin/sh gnucash-2.2.4-1.fc9.i386 requires /bin/sh gnucash-docs-2.2.0-2.fc8.noarch requires /bin/sh gnucash-docs-2.2.0-2.fc8.noarch requires /usr/bin/scrollkeeper-update gnue-common-0.6.9-4.fc10.noarch requires /usr/bin/python gnugo-3.6-6.fc9.i386 requires /bin/sh 1:gnumeric-1.8.2-2.fc9.i386 requires /sbin/ldconfig 1:gnumeric-1.8.2-2.fc9.i386 requires /bin/sh 1:gnumeric-plugins-extras-1.8.2-2.fc9.i386 requires /usr/bin/perl gnupg-1.4.9-1.fc9.i386 requires /bin/sh gnupg-1.4.9-1.fc9.i386 requires /sbin/install-info gnupg-1.4.9-1.fc9.i386 requires /bin/sh gnupg2-2.0.9-1.fc9.i386 requires /bin/sh gnupg2-2.0.9-1.fc9.i386 requires /sbin/install-info gnupg2-2.0.9-1.fc9.i386 requires /bin/sh gnuplot-4.2.3-1.fc10.i386 requires /sbin/install-info gnuplot-4.2.3-1.fc10.i386 requires /bin/sh gnuradio-3.1.1-4.fc9.i386 requires /sbin/ldconfig gnuradio-devel-3.1.1-4.fc9.i386 requires /sbin/ldconfig gnustep-make-2.0.4-9.fc9.i386 requires /bin/sh gnutls-2.0.4-2.fc9.i386 requires /sbin/ldconfig gnutls-devel-2.0.4-2.fc9.i386 requires /bin/sh gnutls-devel-2.0.4-2.fc9.i386 requires /sbin/install-info gnutls-devel-2.0.4-2.fc9.i386 requires /bin/sh gobby-0.4.5-3.fc9.i386 requires /bin/sh goffice-0.6.2-1.fc9.i386 requires /sbin/ldconfig goffice04-0.4.3-3.fc9.i386 requires /sbin/ldconfig gok-1.3.7-3.fc9.i386 requires /bin/sh gonvert-0.2.19-3.fc9.noarch requires /usr/bin/python goocanvas-0.9-4.fc9.i386 requires /sbin/ldconfig goocanvasmm-0.4.0-3.fc9.i386 requires /sbin/ldconfig google-perftools-0.95-4.fc9.i386 requires /usr/bin/env google-perftools-0.95-4.fc9.i386 requires /sbin/ldconfig gossip-0.29-2.fc10.i386 requires /bin/sh gourmet-0.13.4-3.fc9.noarch requires /usr/bin/python gpa-0.7.6-5.fc10.i386 requires /bin/sh gpar2-0.3-6.fc9.i386 requires /bin/sh gparted-0.3.7-1.fc10.i386 requires /bin/bash gparted-0.3.7-1.fc10.i386 requires /bin/sh gperf-3.0.3-4.fc9.i386 requires /bin/sh gperf-3.0.3-4.fc9.i386 requires /sbin/install-info gpgme-1.1.6-3.fc9.i386 requires /sbin/ldconfig gpgme-devel-1.1.6-3.fc9.i386 requires /bin/sh gpgme-devel-1.1.6-3.fc9.i386 requires /sbin/install-info gpgme-devel-1.1.6-3.fc9.i386 requires /bin/sh gphoto2-2.4.0-10.fc9.i386 requires /bin/sh gphoto2-2.4.0-10.fc9.i386 requires /bin/bash gphoto2-devel-2.4.0-10.fc9.i386 requires /bin/sh gpixpod-0.6.2-3.fc9.i386 requires /bin/bash gpm-1.20.1-90.fc9.i386 requires /bin/sh gpm-1.20.1-90.fc9.i386 requires /sbin/ldconfig gpm-1.20.1-90.fc9.i386 requires /bin/bash gpm-1.20.1-90.fc9.i386 requires /sbin/chkconfig gpm-1.20.1-90.fc9.i386 requires /sbin/install-info gpodder-0.11.1-2.fc9.noarch requires /bin/sh gpodder-0.11.1-2.fc9.noarch requires /usr/bin/python gpredict-0.9.0-3.fc9.i386 requires /bin/sh gpsd-2.37-2.fc9.i386 requires /usr/bin/env gpsd-2.37-2.fc9.i386 requires /sbin/ldconfig gpsd-clients-2.37-2.fc9.i386 requires /usr/bin/env gpsd-devel-2.37-2.fc9.i386 requires /usr/bin/env gpsdrive-2.09-5.fc9.i386 requires /sbin/ldconfig gpsdrive-2.09-5.fc9.i386 requires /bin/bash gpsdrive-2.09-5.fc9.i386 requires /bin/sh gpsdrive-2.09-5.fc9.i386 requires /usr/bin/perl gpsim-0.22.0-5.fc8.i386 requires /sbin/ldconfig gpsman-6.3.2-3.fc9.noarch requires /bin/sh gq-1.3.4-1.fc9.i386 requires /bin/sh gquilt-0.20-3.fc9.noarch requires /bin/sh gquilt-0.20-3.fc9.noarch requires /bin/bash gqview-2.0.4-9.i386 requires /bin/sh grace-5.1.21-9.fc9.i386 requires /bin/sh grace-5.1.21-9.fc9.i386 requires /bin/sh gramps-2.2.10-1.fc9.noarch requires /bin/sh gramps-2.2.10-1.fc9.noarch requires /bin/sh graphviz-2.16.1-0.5.fc9.i386 requires /bin/sh graphviz-2.16.1-0.5.fc9.i386 requires /sbin/ldconfig graphviz-2.16.1-0.5.fc9.i386 requires /bin/sh graphviz-devil-2.16.1-0.5.fc9.i386 requires /bin/sh graphviz-gd-2.16.1-0.5.fc9.i386 requires /bin/sh graphviz-gd-2.16.1-0.5.fc9.i386 requires /sbin/ldconfig graphviz-gd-2.16.1-0.5.fc9.i386 requires /usr/bin/dot graphviz-tcl-2.16.1-0.5.fc9.i386 requires /bin/sh grass-6.3.0-0.4.RC6.fc9.i386 requires /usr/bin/python grass-6.3.0-0.4.RC6.fc9.i386 requires /bin/bash grass-6.3.0-0.4.RC6.fc9.i386 requires /bin/sh grass-libs-6.3.0-0.4.RC6.fc9.i386 requires /sbin/ldconfig grep-2.5.1-59.fc9.i386 requires /bin/sh grep-2.5.1-59.fc9.i386 requires /sbin/install-info grepmail-5.3033-4.fc9.noarch requires /usr/bin/perl gresistor-0.0.1-11.fc8.noarch requires /bin/sh gresistor-0.0.1-11.fc8.noarch requires /usr/bin/python greyhounds-0.8-0.3.prealpha.fc9.i386 requires /bin/sh greylistd-0.8.3.2-8.fc7.noarch requires /bin/sh greylistd-0.8.3.2-8.fc7.noarch requires /bin/bash greylistd-0.8.3.2-8.fc7.noarch requires /sbin/chkconfig greylistd-0.8.3.2-8.fc7.noarch requires /usr/bin/python greylistd-0.8.3.2-8.fc7.noarch requires /sbin/service grhino-0.16.0-5.fc9.i386 requires /bin/sh gridengine-6.1u4-1.fc10.i386 requires /bin/sh gridengine-6.1u4-1.fc10.i386 requires /bin/ksh gridengine-6.1u4-1.fc10.i386 requires /usr/sbin/alternatives gridengine-6.1u4-1.fc10.i386 requires /bin/csh gridengine-6.1u4-1.fc10.i386 requires /sbin/ldconfig gridengine-6.1u4-1.fc10.i386 requires /usr/sbin/alternatives gridengine-6.1u4-1.fc10.i386 requires /bin/sh gridengine-devel-6.1u4-1.fc10.i386 requires /bin/csh gridengine-devel-6.1u4-1.fc10.i386 requires /bin/sh gridengine-execd-6.1u4-1.fc10.i386 requires /bin/sh gridengine-execd-6.1u4-1.fc10.i386 requires /sbin/service gridengine-execd-6.1u4-1.fc10.i386 requires /bin/sh gridengine-execd-6.1u4-1.fc10.i386 requires /sbin/chkconfig gridengine-qmaster-6.1u4-1.fc10.i386 requires /bin/sh gridengine-qmaster-6.1u4-1.fc10.i386 requires /sbin/service gridengine-qmaster-6.1u4-1.fc10.i386 requires /bin/sh gridengine-qmaster-6.1u4-1.fc10.i386 requires /sbin/chkconfig grig-0.7.2-5.fc9.i386 requires /bin/sh grisbi-0.5.9-5.fc9.i386 requires /bin/sh groff-1.18.1.4-14.fc9.i386 requires /bin/sh groff-1.18.1.4-14.fc9.i386 requires /bin/sed groff-1.18.1.4-14.fc9.i386 requires /sbin/install-info groff-1.18.1.4-14.fc9.i386 requires /bin/bash groff-1.18.1.4-14.fc9.i386 requires /bin/sh groff-perl-1.18.1.4-14.fc9.i386 requires /usr/bin/perl groff-perl-1.18.1.4-14.fc9.i386 requires /bin/sh grsync-0.6.1-2.fc9.i386 requires /bin/bash grub-0.97-33.fc9.i386 requires /bin/sh grub-0.97-33.fc9.i386 requires /sbin/install-info grub-0.97-33.fc9.i386 requires /bin/sh grub-0.97-33.fc9.i386 requires /usr/bin/cmp gruler-0.8-3.fc9.noarch requires /usr/bin/ruby gruler-0.8-3.fc9.noarch requires /bin/bash gscan2pdf-0.9.21-2.fc9.noarch requires /bin/sh gscan2pdf-0.9.21-2.fc9.noarch requires /usr/bin/perl gshutdown-0.2-3.fc9.i386 requires /bin/sh gsl-1.10-10.fc9.i386 requires /sbin/ldconfig gsl-devel-1.10-10.fc9.i386 requires /bin/sh gsl-devel-1.10-10.fc9.i386 requires /sbin/install-info gsl-devel-1.10-10.fc9.i386 requires /bin/sh gsm-1.0.12-6.fc9.i386 requires /sbin/ldconfig gsoap-2.7.10-4.fc9.i386 requires /sbin/ldconfig gst-inspector-0.3-5.fc9.noarch requires /bin/sh gst-inspector-0.3-5.fc9.noarch requires /usr/bin/python gstream-1.6-2.fc9.i386 requires /sbin/ldconfig gstream-devel-1.6-2.fc9.i386 requires /bin/sh gstream-devel-1.6-2.fc9.i386 requires /sbin/install-info gstreamer-0.10.19-1.fc9.i386 requires /sbin/ldconfig gstreamer-0.10.19-1.fc9.i386 requires /bin/sh gstreamer-devel-0.10.19-1.fc9.i386 requires /bin/sh gstreamer-plugins-base-0.10.19-1.fc9.i386 requires /usr/bin/perl gstreamer-plugins-farsight-0.12.8-1.fc10.i386 requires /sbin/ldconfig gstreamer-plugins-good-0.10.8-1.fc10.i386 requires /bin/sh gt5-1.4.0-4.fc9.noarch requires /bin/sh gthumb-2.10.8-3.fc10.i386 requires /bin/sh gthumb-2.10.8-3.fc10.i386 requires /bin/bash 1:gtk+-1.2.10-61.fc9.i386 requires /sbin/ldconfig 1:gtk+-devel-1.2.10-61.fc9.i386 requires /bin/sh gtk+extra-2.1.1-8.fc9.i386 requires /sbin/ldconfig gtk-doc-1.10-1.fc10.noarch requires /bin/sh gtk-doc-1.10-1.fc10.noarch requires /usr/bin/perl gtk-doc-1.10-1.fc10.noarch requires /bin/sh gtk-doc-1.10-1.fc10.noarch requires /usr/bin/cmp gtk-doc-1.10-1.fc10.noarch requires /usr/bin/python gtk-recordmydesktop-0.3.7-1.fc9.noarch requires /usr/bin/python gtk-sharp-1.0.10-12.fc7.i386 requires /bin/sh gtk-sharp-gapi-1.0.10-12.fc7.i386 requires /usr/bin/perl gtk-sharp-gapi-1.0.10-12.fc7.i386 requires /bin/sh gtk-sharp2-2.10.3-2.fc9.i386 requires /sbin/ldconfig gtk-sharp2-gapi-2.10.3-2.fc9.i386 requires /usr/bin/perl gtk-sharp2-gapi-2.10.3-2.fc9.i386 requires /bin/sh gtk-vnc-0.3.6-1.fc10.i386 requires /sbin/ldconfig gtk2-2.13.0-2.fc10.i386 requires /bin/sh gtk2-2.13.0-2.fc10.i386 requires /bin/sh gtk2-devel-2.13.0-2.fc10.i386 requires /usr/bin/env gtkdatabox-0.8.2.2-2.fc9.i386 requires /sbin/ldconfig gtkglarea2-1.99.0-8.fc9.i386 requires /sbin/ldconfig gtkglext-libs-1.2.0-6.fc9.i386 requires /bin/sh gtkglextmm-1.2.0-6.fc9.i386 requires /sbin/ldconfig gtkglextmm-1.2.0-6.fc9.i386 requires /bin/sh gtkhtml2-2.11.1-3.fc9.i386 requires /sbin/ldconfig gtkhtml3-3.23.2-4.fc10.i386 requires /sbin/ldconfig gtkimageview-1.5.0-2.fc9.i386 requires /sbin/ldconfig gtkmathview-0.7.6-7.fc9.i386 requires /sbin/ldconfig gtkmm24-2.12.5-1.fc9.i386 requires /sbin/ldconfig gtkmozembedmm-1.4.2.cvs20060817-17.fc9.i386 requires /sbin/ldconfig gtkpod-0.99.12-2.fc9.i386 requires /usr/bin/python gtkpod-0.99.12-2.fc9.i386 requires /bin/bash gtkpod-0.99.12-2.fc9.i386 requires /bin/sh gtkpod-0.99.12-2.fc9.i386 requires /usr/bin/awk gtkpod-0.99.12-2.fc9.i386 requires /usr/bin/perl gtkpod-0.99.12-2.fc9.i386 requires /bin/sh 1:gtksourceview-1.8.5-4.fc9.i386 requires /sbin/ldconfig gtksourceview2-2.2.1-1.fc9.i386 requires /sbin/ldconfig gtkspell-2.0.11-8.fc9.i386 requires /sbin/ldconfig gtkterm-0.99.5-9.fc9.i386 requires /bin/sh gtorrentviewer-0.2b-15.fc9.i386 requires /bin/sh gtranslator-1.1.7-8.fc9.i386 requires /bin/sh gtranslator-1.1.7-8.fc9.i386 requires /bin/sh gts-0.7.6-9.fc9.i386 requires /sbin/ldconfig gts-0.7.6-9.fc9.i386 requires /bin/sh gts-devel-0.7.6-9.fc9.i386 requires /bin/sh gtypist-2.7-6.fc9.i386 requires /bin/sh gtypist-2.7-6.fc9.i386 requires /usr/bin/perl gtypist-2.7-6.fc9.i386 requires /sbin/install-info gucharmap-2.22.1-1.fc9.i386 requires /bin/sh guichan-0.7.1-1.fc9.i386 requires /sbin/ldconfig 5:guile-1.8.5-1.fc10.i386 requires /bin/sh 5:guile-1.8.5-1.fc10.i386 requires /sbin/install-info 5:guile-1.8.5-1.fc10.i386 requires /sbin/ldconfig 5:guile-1.8.5-1.fc10.i386 requires /bin/sh guile-cairo-1.4.0-6.fc9.i386 requires /sbin/ldconfig guile-cairo-1.4.0-6.fc9.i386 requires /sbin/install-info guile-cairo-1.4.0-6.fc9.i386 requires /bin/sh 5:guile-devel-1.8.5-1.fc10.i386 requires /usr/bin/guile 5:guile-devel-1.8.5-1.fc10.i386 requires /bin/sh guile-gnome-platform-2.15.93-6.fc8.i386 requires /bin/sh guile-gnome-platform-2.15.93-6.fc8.i386 requires /sbin/install-info guile-gnome-platform-2.15.93-6.fc8.i386 requires /sbin/ldconfig guile-gnome-platform-2.15.93-6.fc8.i386 requires /bin/sh guile-lib-0.1.6-1.fc9.noarch requires /bin/sh guile-lib-0.1.6-1.fc9.noarch requires /sbin/install-info guilt-0.30-1.fc8.noarch requires /bin/sh gutenprint-5.0.2-2.fc9.i386 requires /sbin/ldconfig gutenprint-cups-5.0.2-2.fc9.i386 requires /bin/sh gutenprint-cups-5.0.2-2.fc9.i386 requires /usr/bin/perl gutenprint-foomatic-5.0.2-2.fc9.i386 requires /bin/sh gutenprint-foomatic-5.0.2-2.fc9.i386 requires /usr/bin/python gv-3.6.3-3.fc9.i386 requires /bin/sh gv-3.6.3-3.fc9.i386 requires /sbin/install-info gv-3.6.3-3.fc9.i386 requires /usr/bin/update-desktop-database gv-3.6.3-3.fc9.i386 requires /usr/bin/update-mime-database gvfs-0.2.3-10.fc10.i386 requires /bin/sh gvfs-0.2.3-10.fc10.i386 requires /bin/sh gwave-2-7.20070514snap.fc9.i386 requires /usr/bin/perl gwave-2-7.20070514snap.fc9.i386 requires /bin/sh gwenhywfar-2.6.2-2.fc9.i386 requires /sbin/ldconfig gwenhywfar-devel-2.6.2-2.fc9.i386 requires /bin/sh gwget-0.99-5.fc9.i386 requires /bin/sh gxine-0.5.902-1.fc10.i386 requires /bin/sh gypsy-0.6-3.fc10.i386 requires /sbin/ldconfig gzip-1.3.12-6.fc9.i386 requires /bin/sh gzip-1.3.12-6.fc9.i386 requires /bin/sh gzip-1.3.12-6.fc9.i386 requires /sbin/install-info hackedbox-0.8.5-5.fc9.i386 requires /bin/bash hackedbox-0.8.5-5.fc9.i386 requires /bin/sh haddock-2.0.0.0-2.fc9.i386 requires /bin/sh hal-0.5.11-1.fc10.i386 requires /bin/sh hal-0.5.11-1.fc10.i386 requires /usr/sbin/useradd hal-0.5.11-1.fc10.i386 requires /usr/bin/polkit-auth hal-0.5.11-1.fc10.i386 requires /sbin/ldconfig hal-0.5.11-1.fc10.i386 requires /bin/bash hal-0.5.11-1.fc10.i386 requires /bin/sh hal-cups-utils-0.6.16-3.fc9.i386 requires /bin/sh hal-cups-utils-0.6.16-3.fc9.i386 requires /bin/env hal-cups-utils-0.6.16-3.fc9.i386 requires /bin/sh halberd-0.2.2-2.fc8.noarch requires /usr/bin/python halevt-0.0.8-1.fc9.i386 requires /bin/sh halevt-0.0.8-1.fc9.i386 requires /sbin/chkconfig halevt-0.0.8-1.fc9.i386 requires /bin/sh halevt-0.0.8-1.fc9.i386 requires /sbin/service hamlib-1.2.7-1.fc9.i386 requires /sbin/ldconfig hamlib-c++-1.2.7-1.fc9.i386 requires /sbin/ldconfig hamlib-tcl-1.2.7-1.fc9.i386 requires /sbin/ldconfig hamster-applet-0.4-1.fc10.i386 requires /usr/bin/env hamster-applet-0.4-1.fc10.i386 requires /bin/sh haproxy-1.3.14.3-1.fc9.i386 requires /bin/sh haproxy-1.3.14.3-1.fc9.i386 requires /sbin/chkconfig haproxy-1.3.14.3-1.fc9.i386 requires /usr/sbin/useradd haproxy-1.3.14.3-1.fc9.i386 requires /bin/sh haproxy-1.3.14.3-1.fc9.i386 requires /sbin/service harminv-1.3.1-10.fc9.i386 requires /sbin/ldconfig hatari-1.0.1-1.fc9.i386 requires /bin/sh hawknl-1.68-3.fc9.i386 requires /sbin/ldconfig hddtemp-0.3-0.15.beta15.fc9.i386 requires /bin/sh hddtemp-0.3-0.15.beta15.fc9.i386 requires /usr/bin/consolehelper hddtemp-0.3-0.15.beta15.fc9.i386 requires /bin/bash hddtemp-0.3-0.15.beta15.fc9.i386 requires /sbin/chkconfig hdf-4.2r3-2.fc9.i386 requires /bin/sh hdf5-1.8.0.snap5-2.fc10.i386 requires /sbin/ldconfig hdf5-devel-1.8.0.snap5-2.fc10.i386 requires /bin/bash hdf5-devel-1.8.0.snap5-2.fc10.i386 requires /bin/sh heartbeat-2.1.3-1.fc9.i386 requires /bin/sh heartbeat-2.1.3-1.fc9.i386 requires /usr/bin/python heartbeat-2.1.3-1.fc9.i386 requires /sbin/ldconfig heartbeat-2.1.3-1.fc9.i386 requires /bin/sh heartbeat-2.1.3-1.fc9.i386 requires /sbin/chkconfig heartbeat-gui-2.1.3-1.fc9.i386 requires /usr/bin/python hedgewars-0.9.3-1.fc10.i386 requires /bin/sh help2man-1.36.4-2.fc9.noarch requires /usr/bin/perl help2man-1.36.4-2.fc9.noarch requires /sbin/install-info help2man-1.36.4-2.fc9.noarch requires /bin/sh hercules-3.05-4.fc9.i386 requires /usr/bin/perl hercules-3.05-4.fc9.i386 requires /bin/sh hesinfo-3.1.0-3.i386 requires /sbin/ldconfig hesiod-3.1.0-10.i386 requires /sbin/ldconfig hevea-1.10-1.fc9.i386 requires /usr/bin/texhash hevea-1.10-1.fc9.i386 requires /bin/sh hfsutils-3.2.6-14.fc9.i386 requires /bin/sh hgsvn-0.1.5-3.fc9.noarch requires /usr/bin/python hicolor-icon-theme-0.10-4.noarch requires /bin/sh higlayout-1.0-2.fc9.i386 requires /bin/sh higlayout-javadoc-1.0-2.fc9.i386 requires /bin/sh hippo-canvas-0.2.31-1.fc10.i386 requires /sbin/ldconfig homebank-3.8-1.fc9.i386 requires /bin/sh horde-3.1.7-2.fc9.noarch requires /bin/sh horde-3.1.7-2.fc9.noarch requires /usr/bin/php horde-3.1.7-2.fc9.noarch requires /bin/sh horde-3.1.7-2.fc9.noarch requires /sbin/service hotwire-0.721-1.fc9.noarch requires /bin/sh hotwire-0.721-1.fc9.noarch requires /usr/bin/python hpic-0.52.2-6.fc9.i386 requires /sbin/ldconfig hplip-2.8.2-3.fc10.i386 requires /bin/sh hplip-2.8.2-3.fc10.i386 requires /usr/bin/env hplip-2.8.2-3.fc10.i386 requires /usr/bin/python hplip-2.8.2-3.fc10.i386 requires /sbin/service hplip-2.8.2-3.fc10.i386 requires /sbin/chkconfig hplip-gui-2.8.2-3.fc10.i386 requires /bin/sh hplip-gui-2.8.2-3.fc10.i386 requires /usr/bin/env hspell-1.0-8.fc9.i386 requires /usr/bin/perl 1:hsqldb-1.8.0.9-2jpp.1.fc9.i386 requires /bin/sh 1:hsqldb-1.8.0.9-2jpp.1.fc9.i386 requires /bin/ln 1:hsqldb-1.8.0.9-2jpp.1.fc9.i386 requires /bin/sh 1:hsqldb-1.8.0.9-2jpp.1.fc9.i386 requires /bin/rm 1:hsqldb-demo-1.8.0.9-2jpp.1.fc9.i386 requires /bin/sh 1:hsqldb-javadoc-1.8.0.9-2jpp.1.fc9.i386 requires /bin/sh 1:hsqldb-javadoc-1.8.0.9-2jpp.1.fc9.i386 requires /bin/rm 1:hsqldb-javadoc-1.8.0.9-2jpp.1.fc9.i386 requires /bin/ln ht2html-2.0-5.fc6.noarch requires /bin/sh ht2html-2.0-5.fc6.noarch requires /usr/bin/env 4:htdig-3.2.0-0.1.b6.fc10.i386 requires /bin/sh html-xml-utils-3.7-5.fc9.i386 requires /bin/bash html-xml-utils-3.7-5.fc9.i386 requires /usr/bin/perl html2ps-1.0-0.1.b5.fc10.noarch requires /usr/bin/perl html401-dtds-4.01-19991224.5.noarch requires /bin/sh html401-dtds-4.01-19991224.5.noarch requires /usr/bin/install-catalog htmldoc-1.8.27-6.fc9.i386 requires /bin/sh htmlview-4.0.0-3.fc7.noarch requires /bin/bash httpd-2.2.8-3.i386 requires /bin/sh httpd-2.2.8-3.i386 requires /usr/sbin/useradd httpd-2.2.8-3.i386 requires /etc/mime.types httpd-2.2.8-3.i386 requires /bin/bash httpd-2.2.8-3.i386 requires /bin/sh httpd-devel-2.2.8-3.i386 requires /usr/bin/perl httpd-devel-2.2.8-3.i386 requires /bin/sh httrack-3.42-9.fc9.i386 requires /sbin/ldconfig httrack-3.42-9.fc9.i386 requires /bin/bash hugin-0.7.0-0.3.20080218svn.fc9.i386 requires /bin/sh hugin-base-0.7.0-0.3.20080218svn.fc9.i386 requires /sbin/ldconfig hugin-base-0.7.0-0.3.20080218svn.fc9.i386 requires /bin/sh hugs98-2006.09-4.fc9.i386 requires /bin/sh hunspell-1.2.2-3.fc10.i386 requires /sbin/ldconfig hunspell-devel-1.2.2-3.fc10.i386 requires /usr/bin/perl hunt-1.5-7.fc9.i386 requires /bin/sh hwbrowser-0.42-1.fc9.noarch requires /bin/sh hydrogen-0.9.3-13.fc9.i386 requires /bin/sh hydrogen-0.9.3-13.fc9.i386 requires /bin/sh hyperestraier-1.4.13-2.fc9.i386 requires /sbin/ldconfig hyperestraier-1.4.13-2.fc9.i386 requires /bin/sh hyperestraier-devel-1.4.13-2.fc9.i386 requires /bin/sh hyperestraier-java-1.4.13-2.fc9.i386 requires /sbin/ldconfig hyperestraier-perl-1.4.13-2.fc9.i386 requires /usr/bin/perl hyphen-2.4-1.fc10.i386 requires /sbin/ldconfig hyphen-devel-2.4-1.fc10.i386 requires /usr/bin/perl i2c-tools-3.0.0-3.fc9.i386 requires /usr/bin/perl i8kutils-1.25-15.i386 requires /sbin/service i8kutils-1.25-15.i386 requires /bin/bash i8kutils-1.25-15.i386 requires /bin/sh i8kutils-1.25-15.i386 requires /sbin/chkconfig i8kutils-1.25-15.i386 requires /bin/sh ibmasm-3.0-14.i386 requires /sbin/lspci ibmasm-3.0-14.i386 requires /bin/sh ibmasm-3.0-14.i386 requires /sbin/ldconfig ibmasm-3.0-14.i386 requires /bin/bash ibmasm-3.0-14.i386 requires /sbin/chkconfig ibmasm-3.0-14.i386 requires /sbin/service ibmonitor-1.4-1.noarch requires /usr/bin/perl ice-3.2.1-17.fc9.i386 requires /usr/bin/env ice-3.2.1-17.fc9.i386 requires /sbin/ldconfig ice-servers-3.2.1-17.fc9.i386 requires /bin/sh ice-servers-3.2.1-17.fc9.i386 requires /bin/bash ice-servers-3.2.1-17.fc9.i386 requires /sbin/chkconfig ice-servers-3.2.1-17.fc9.i386 requires /sbin/service icecast-2.3.1-5.fc9.i386 requires /bin/sh icecast-2.3.1-5.fc9.i386 requires /usr/sbin/useradd icecast-2.3.1-5.fc9.i386 requires /sbin/service icecast-2.3.1-5.fc9.i386 requires /bin/sh icecast-2.3.1-5.fc9.i386 requires /sbin/chkconfig icecream-0.8.0-11.20080117svn.fc9.i386 requires /bin/sh icecream-0.8.0-11.20080117svn.fc9.i386 requires /usr/bin/env icecream-0.8.0-11.20080117svn.fc9.i386 requires /bin/sh icedax-1.1.6-11.fc9.i386 requires /bin/sh icedax-1.1.6-11.fc9.i386 requires /usr/sbin/alternatives icedax-1.1.6-11.fc9.i386 requires /bin/sh icegrid-gui-3.2.1-17.fc9.i386 requires /bin/sh ices-2.0.1-6.fc9.i386 requires /bin/sh ices-2.0.1-6.fc9.i386 requires /sbin/service ices-2.0.1-6.fc9.i386 requires /bin/sh ices-2.0.1-6.fc9.i386 requires /sbin/chkconfig icewm-xdgmenu-1.2.35-4.fc9.i386 requires /bin/sh icewm-xdgmenu-1.2.35-4.fc9.i386 requires /usr/bin/python icon-naming-utils-0.8.6-2.fc9.noarch requires /usr/bin/perl icu4j-3.6.1-2jpp.6.fc9.i386 requires /bin/sh id3lib-3.8.3-20.fc9.i386 requires /sbin/ldconfig idw-gpl-1.5.0-5.fc10.i386 requires /bin/sh ifd-egate-0.05-20.i386 requires /bin/sh ifm-5.1-6.fc9.i386 requires /usr/bin/wish ifm-5.1-6.fc9.i386 requires /usr/bin/perl ifplugd-0.28-11.fc9.i386 requires /bin/sh ifplugd-0.28-11.fc9.i386 requires /bin/bash ifplugd-0.28-11.fc9.i386 requires /bin/sh igraph-0.5-13.fc9.i386 requires /sbin/ldconfig igraph-0.5-13.fc9.i386 requires /sbin/install-info igraph-devel-0.5-13.fc9.i386 requires /bin/sh ikarus-0.0.2-2.fc9.i386 requires /bin/sh ikarus-0.0.2-2.fc9.i386 requires /bin/sh iksemel-1.3-4.fc9.i386 requires /sbin/ldconfig iksemel-devel-1.3-4.fc9.i386 requires /sbin/install-info iksemel-devel-1.3-4.fc9.i386 requires /bin/sh ilmbase-1.0.1-2.fc9.i386 requires /sbin/ldconfig im-chooser-0.99.6-4.fc10.i386 requires /usr/sbin/alternatives imake-1.0.2-6.fc9.i386 requires /usr/bin/perl imake-1.0.2-6.fc9.i386 requires /bin/sh imapsync-1.249-1.fc8.noarch requires /usr/bin/perl 1:imlib-1.9.15-7.fc9.i386 requires /sbin/ldconfig 1:imlib-devel-1.9.15-7.fc9.i386 requires /usr/share/aclocal 1:imlib-devel-1.9.15-7.fc9.i386 requires /bin/sh imlib2-1.4.0-5.fc9.i386 requires /sbin/ldconfig imlib2-devel-1.4.0-5.fc9.i386 requires /bin/sh imsettings-0.99.6-4.fc10.i386 requires /bin/dbus-send imsettings-0.99.6-4.fc10.i386 requires /bin/sh imsettings-libs-0.99.6-4.fc10.i386 requires /sbin/ldconfig inadyn-1.96.2-3.fc9.i386 requires /bin/sh inadyn-1.96.2-3.fc9.i386 requires /sbin/chkconfig inadyn-1.96.2-3.fc9.i386 requires /sbin/service inchi-1.0.2-0.3.fc9.i386 requires /sbin/ldconfig incollector-1.0-6.fc9.i386 requires /bin/sh inconsolata-fonts-1.009-1.fc9.noarch requires /bin/sh incron-0.5.7-1.fc9.i386 requires /bin/sh incron-0.5.7-1.fc9.i386 requires /sbin/service incron-0.5.7-1.fc9.i386 requires /bin/bash incron-0.5.7-1.fc9.i386 requires /sbin/chkconfig indent-2.2.10-1.fc9.i386 requires /bin/sh indent-2.2.10-1.fc9.i386 requires /sbin/install-info info-4.12-1.fc10.i386 requires /bin/sh initng-0.6.10.2-2.fc9.i386 requires /bin/sh initng-0.6.10.2-2.fc9.i386 requires /bin/sh initng-conf-gtk-0.5.1-4.fc9.i386 requires /bin/sh initng-ifiles-0.1.4-5.fc9.i386 requires /bin/sh initng-ifiles-0.1.4-5.fc9.i386 requires /bin/sh initng-ifiles-0.1.4-5.fc9.i386 requires /sbin/ldconfig initng-ifiles-0.1.4-5.fc9.i386 requires /bin/bash initng-lib-0.6.10.2-2.fc9.i386 requires /sbin/ldconfig initscripts-8.76.1-1.i386 requires /bin/sh initscripts-8.76.1-1.i386 requires /bin/sed initscripts-8.76.1-1.i386 requires /etc/redhat-release initscripts-8.76.1-1.i386 requires /sbin/runuser initscripts-8.76.1-1.i386 requires /sbin/sysctl initscripts-8.76.1-1.i386 requires /bin/awk initscripts-8.76.1-1.i386 requires /bin/sed initscripts-8.76.1-1.i386 requires /sbin/pidof initscripts-8.76.1-1.i386 requires /sbin/fuser initscripts-8.76.1-1.i386 requires /bin/bash initscripts-8.76.1-1.i386 requires /sbin/arping initscripts-8.76.1-1.i386 requires /bin/sh initscripts-8.76.1-1.i386 requires /bin/grep initscripts-8.76.1-1.i386 requires /bin/find initscripts-8.76.1-1.i386 requires /usr/sbin/groupadd initscripts-8.76.1-1.i386 requires /sbin/chkconfig initscripts-8.76.1-1.i386 requires /sbin/ip inkscape-0.46-2.fc9.i386 requires /usr/bin/perl inkscape-0.46-2.fc9.i386 requires /bin/sh inkscape-0.46-2.fc9.i386 requires /usr/bin/env inkscape-0.46-2.fc9.i386 requires /bin/sh inn-2.4.4-1.fc10.i386 requires /bin/sh inn-2.4.4-1.fc10.i386 requires /usr/lib/news/lib/innshellvars.pl inn-2.4.4-1.fc10.i386 requires /bin/bash inn-2.4.4-1.fc10.i386 requires /bin/sh inn-2.4.4-1.fc10.i386 requires /usr/bin/perl innotop-1.6.0-2.fc9.noarch requires /usr/bin/perl inotify-tools-3.13-1.fc9.i386 requires /sbin/ldconfig international-time-0.0.2-4.fc8.noarch requires /bin/sh international-time-0.0.2-4.fc8.noarch requires /usr/bin/python intltool-0.37.1-1.fc9.i386 requires /usr/bin/perl intltool-0.37.1-1.fc9.i386 requires /bin/sh iotop-0.1-3.fc9.noarch requires /usr/bin/python iozone-3-5.fc9.i386 requires /bin/sh ip-sentinel-0.12-11.fc9.i386 requires /bin/sh ip-sentinel-sysv-0.12-11.fc9.i386 requires /bin/sh ip-sentinel-sysv-0.12-11.fc9.i386 requires /bin/bash ip-sentinel-sysv-0.12-11.fc9.i386 requires /sbin/chkconfig ipa-admintools-1.0.0-5.fc10.i386 requires /usr/bin/python ipa-client-1.0.0-5.fc10.i386 requires /usr/bin/python ipa-radius-admintools-1.0.0-5.fc10.i386 requires /usr/bin/python ipa-radius-server-1.0.0-5.fc10.i386 requires /usr/bin/python ipa-server-1.0.0-5.fc10.i386 requires /bin/sh ipa-server-1.0.0-5.fc10.i386 requires /usr/bin/python ipa-server-1.0.0-5.fc10.i386 requires /bin/sh ipa-server-selinux-1.0.0-5.fc10.i386 requires /bin/sh ipcalculator-0.41-6.fc9.noarch requires /usr/bin/perl ipcalculator-cgi-0.41-6.fc9.noarch requires /usr/bin/perl ipe-6.0-0.24.pre30.fc9.i386 requires /sbin/ldconfig iproute-2.6.25-1.fc10.i386 requires /bin/bash ipsec-tools-0.7-13.fc9.i386 requires /bin/sh ipsec-tools-0.7-13.fc9.i386 requires /bin/bash ipsec-tools-0.7-13.fc9.i386 requires /bin/sh iptables-1.4.0-4.fc9.i386 requires /bin/sh iptables-1.4.0-4.fc9.i386 requires /bin/sh iptables-ipv6-1.4.0-4.fc9.i386 requires /bin/sh iptables-ipv6-1.4.0-4.fc9.i386 requires /bin/sh iputils-20071127-2.fc9.i386 requires /bin/sh iputils-20071127-2.fc9.i386 requires /bin/bash iputils-20071127-2.fc9.i386 requires /sbin/chkconfig iputils-20071127-2.fc9.i386 requires /sbin/service ipv6calc-0.71.0-2.fc9.i386 requires /usr/bin/perl ipv6calc-0.71.0-2.fc9.i386 requires /bin/sh ipvsadm-1.24-11.i386 requires /bin/sh ipvsadm-1.24-11.i386 requires /bin/bash ipvsadm-1.24-11.i386 requires /sbin/chkconfig ipvsadm-1.24-11.i386 requires /bin/sh ipxripd-0.8-5.fc9.i386 requires /bin/sh ipxripd-0.8-5.fc9.i386 requires /sbin/chkconfig ipxripd-0.8-5.fc9.i386 requires /bin/sh ipxripd-0.8-5.fc9.i386 requires /sbin/service ipython-0.8.2-1.fc9.noarch requires /usr/bin/env ipython-0.8.2-1.fc9.noarch requires /usr/bin/python ircd-hybrid-7.2.3-5.fc9.i386 requires /bin/sh ircd-hybrid-7.2.3-5.fc9.i386 requires /sbin/service ircd-hybrid-7.2.3-5.fc9.i386 requires /bin/sh ircd-hybrid-7.2.3-5.fc9.i386 requires /sbin/chkconfig irda-utils-0.9.18-4.fc9.i386 requires /bin/sh irda-utils-0.9.18-4.fc9.i386 requires /sbin/chkconfig irda-utils-0.9.18-4.fc9.i386 requires /bin/sh 2:irqbalance-0.55-9.fc10.i386 requires /bin/sh 2:irqbalance-0.55-9.fc10.i386 requires /sbin/chkconfig 2:irqbalance-0.55-9.fc10.i386 requires /bin/sh 2:irqbalance-0.55-9.fc10.i386 requires /sbin/service irsim-9.7.50-2.fc9.i386 requires /bin/sh iscsi-initiator-utils-6.2.0.868-0.7.fc9.i386 requires /bin/sh iscsi-initiator-utils-6.2.0.868-0.7.fc9.i386 requires /bin/sh iscsi-initiator-utils-6.2.0.868-0.7.fc9.i386 requires /sbin/service isdn4k-utils-3.2-58.fc9.i386 requires /bin/sh isdn4k-utils-3.2-58.fc9.i386 requires /bin/ln isdn4k-utils-3.2-58.fc9.i386 requires /sbin/ldconfig isdn4k-utils-3.2-58.fc9.i386 requires /bin/bash isdn4k-utils-3.2-58.fc9.i386 requires /bin/sh isdn4k-utils-3.2-58.fc9.i386 requires /usr/bin/perl isdn4k-utils-3.2-58.fc9.i386 requires /sbin/chkconfig isicom-3.05-20.fc9.i386 requires /bin/sh isicom-3.05-20.fc9.i386 requires /sbin/chkconfig isicom-3.05-20.fc9.i386 requires /bin/sh isicom-3.05-20.fc9.i386 requires /sbin/service isight-firmware-tools-1.0.2-2.fc9.i386 requires /bin/sh isight-firmware-tools-1.0.2-2.fc9.i386 requires /sbin/install-info isns-utils-0.91-0.0.fc9.i386 requires /bin/sh isns-utils-0.91-0.0.fc9.i386 requires /sbin/service isns-utils-0.91-0.0.fc9.i386 requires /sbin/chkconfig isns-utils-0.91-0.0.fc9.i386 requires /bin/sh isomaster-1.3.1-1.fc9.i386 requires /bin/sh isomaster-1.3.1-1.fc9.i386 requires /bin/sh istanbul-0.2.2-7.fc10.i386 requires /usr/bin/python isync-1.0.4-1.fc9.i386 requires /bin/sh itpp-4.0.0-2.fc9.i386 requires /sbin/ldconfig itpp-devel-4.0.0-2.fc9.i386 requires /bin/sh iverilog-0.9.20080314-1.fc9.i386 requires /bin/sh iwidgets-4.0.2-1.fc9.noarch requires /bin/sh jabberd-2.1.23-1.fc9.i386 requires /bin/sh jabberd-2.1.23-1.fc9.i386 requires /sbin/service jabberd-2.1.23-1.fc9.i386 requires /bin/bash jabbim-0.4-0.4.20080407svn.fc9.noarch requires /bin/sh jabbim-0.4-0.4.20080407svn.fc9.noarch requires /usr/bin/env jabbim-0.4-0.4.20080407svn.fc9.noarch requires /bin/sh jabbin-2.0-0.6.beta2a.fc9.i386 requires /bin/sh jack-audio-connection-kit-0.109.2-1.fc9.1.i386 requires /bin/sh jack-audio-connection-kit-0.109.2-1.fc9.1.i386 requires /sbin/ldconfig jack-rack-1.4.7-1.fc9.i386 requires /usr/bin/python jadetex-3.13-2.fc9.noarch requires /bin/sh jadetex-3.13-2.fc9.noarch requires /bin/sh jakarta-commons-beanutils-1.7.0-6jpp.1.i386 requires /bin/sh jakarta-commons-beanutils-javadoc-1.7.0-6jpp.1.i386 requires /bin/sh jakarta-commons-beanutils-javadoc-1.7.0-6jpp.1.i386 requires /bin/rm jakarta-commons-beanutils-javadoc-1.7.0-6jpp.1.i386 requires /bin/ln jakarta-commons-cli-1.0-7jpp_10.fc9.i386 requires /usr/bin/rebuild-gcj-db jakarta-commons-codec-1.3-9jpp.2.fc9.i386 requires /bin/sh jakarta-commons-collections-3.2-2jpp.2.fc9.i386 requires /bin/sh jakarta-commons-collections-testframework-3.2-2jpp.2.fc9.i386 requires /bin/sh jakarta-commons-collections-tomcat5-3.2-2jpp.2.fc9.i386 requires /bin/sh 1:jakarta-commons-daemon-1.0.1-6jpp.5.fc9.i386 requires /bin/sh 1:jakarta-commons-daemon-javadoc-1.0.1-6jpp.5.fc9.i386 requires /bin/rm 1:jakarta-commons-daemon-javadoc-1.0.1-6jpp.5.fc9.i386 requires /bin/ln jakarta-commons-dbcp-1.2.1-11jpp.3.fc9.i386 requires /bin/sh jakarta-commons-dbcp-1.2.1-11jpp.3.fc9.i386 requires /usr/sbin/update-alternatives jakarta-commons-dbcp-javadoc-1.2.1-11jpp.3.fc9.i386 requires /bin/rm jakarta-commons-dbcp-javadoc-1.2.1-11jpp.3.fc9.i386 requires /bin/ln jakarta-commons-dbcp-tomcat5-1.2.1-11jpp.3.fc9.i386 requires /bin/sh jakarta-commons-digester-1.7-7jpp.2.i386 requires /bin/sh jakarta-commons-digester-javadoc-1.7-7jpp.2.i386 requires /bin/sh jakarta-commons-digester-javadoc-1.7-7jpp.2.i386 requires /bin/rm jakarta-commons-digester-javadoc-1.7-7jpp.2.i386 requires /bin/ln 1:jakarta-commons-discovery-0.4-3jpp.1.fc9.i386 requires /bin/sh 1:jakarta-commons-discovery-javadoc-0.4-3jpp.1.fc9.i386 requires /bin/rm 1:jakarta-commons-discovery-javadoc-0.4-3jpp.1.fc9.i386 requires /bin/ln jakarta-commons-el-1.0-9jpp.2.fc9.i386 requires /bin/sh jakarta-commons-el-javadoc-1.0-9jpp.2.fc9.i386 requires /bin/sh jakarta-commons-el-javadoc-1.0-9jpp.2.fc9.i386 requires /bin/ln jakarta-commons-el-javadoc-1.0-9jpp.2.fc9.i386 requires /bin/rm 1:jakarta-commons-fileupload-1.0-7jpp.2.fc9.i386 requires /bin/sh 1:jakarta-commons-httpclient-3.1-0jpp.1.fc9.i386 requires /bin/sh 1:jakarta-commons-httpclient-javadoc-3.1-0jpp.1.fc9.i386 requires /bin/rm 1:jakarta-commons-httpclient-javadoc-3.1-0jpp.1.fc9.i386 requires /bin/ln jakarta-commons-io-1.3.2-1jpp.1.fc9.noarch requires /bin/sh jakarta-commons-lang-2.3-2jpp.1.fc9.i386 requires /bin/sh jakarta-commons-launcher-1.1-2jpp.3.fc9.i386 requires /bin/sh jakarta-commons-launcher-javadoc-1.1-2jpp.3.fc9.i386 requires /bin/sh jakarta-commons-launcher-javadoc-1.1-2jpp.3.fc9.i386 requires /bin/rm jakarta-commons-launcher-javadoc-1.1-2jpp.3.fc9.i386 requires /bin/ln jakarta-commons-logging-1.0.4-7jpp.5.fc9.i386 requires /bin/sh jakarta-commons-logging-javadoc-1.0.4-7jpp.5.fc9.i386 requires /bin/sh jakarta-commons-logging-javadoc-1.0.4-7jpp.5.fc9.i386 requires /bin/rm jakarta-commons-logging-javadoc-1.0.4-7jpp.5.fc9.i386 requires /bin/ln jakarta-commons-modeler-2.0-4jpp.2.fc9.i386 requires /bin/sh jakarta-commons-net-1.4.1-4jpp.1.fc9.noarch requires /bin/sh jakarta-commons-pool-1.3-10jpp.3.fc9.i386 requires /bin/sh jakarta-commons-pool-tomcat5-1.3-10jpp.3.fc9.i386 requires /bin/sh jakarta-commons-validator-1.1.4-6jpp.2.fc9.i386 requires /bin/sh jakarta-commons-validator-javadoc-1.1.4-6jpp.2.fc9.i386 requires /bin/sh jakarta-commons-validator-javadoc-1.1.4-6jpp.2.fc9.i386 requires /bin/rm jakarta-commons-validator-javadoc-1.1.4-6jpp.2.fc9.i386 requires /bin/ln jakarta-oro-2.0.8-4jpp.1.i386 requires /bin/sh jakarta-oro-javadoc-2.0.8-4jpp.1.i386 requires /bin/sh jakarta-oro-javadoc-2.0.8-4jpp.1.i386 requires /bin/ln jakarta-oro-javadoc-2.0.8-4jpp.1.i386 requires /bin/rm jakarta-taglibs-standard-1.1.1-9jpp.1.fc9.i386 requires /bin/sh jasper-libs-1.900.1-8.fc9.i386 requires /sbin/ldconfig java-1.5.0-gcj-1.5.0.0-21.fc9.i386 requires /bin/sh java-1.5.0-gcj-1.5.0.0-21.fc9.i386 requires /usr/bin/gcj-dbtool java-1.5.0-gcj-1.5.0.0-21.fc9.i386 requires /usr/bin/gij java-1.5.0-gcj-1.5.0.0-21.fc9.i386 requires /usr/sbin/alternatives java-1.5.0-gcj-1.5.0.0-21.fc9.i386 requires /usr/sbin/alternatives java-1.5.0-gcj-1.5.0.0-21.fc9.i386 requires /usr/lib/security/classpath.security java-1.5.0-gcj-1.5.0.0-21.fc9.i386 requires /bin/bash java-1.5.0-gcj-1.5.0.0-21.fc9.i386 requires /usr/bin/rebuild-gcj-db java-1.5.0-gcj-1.5.0.0-21.fc9.i386 requires /bin/sh java-1.5.0-gcj-1.5.0.0-21.fc9.i386 requires /usr/bin/gij java-1.5.0-gcj-devel-1.5.0.0-21.fc9.i386 requires /bin/sh java-1.5.0-gcj-devel-1.5.0.0-21.fc9.i386 requires /usr/bin/gij java-1.5.0-gcj-devel-1.5.0.0-21.fc9.i386 requires /usr/bin/gcj java-1.5.0-gcj-devel-1.5.0.0-21.fc9.i386 requires /usr/sbin/alternatives java-1.5.0-gcj-devel-1.5.0.0-21.fc9.i386 requires /usr/bin/env java-1.5.0-gcj-devel-1.5.0.0-21.fc9.i386 requires /bin/sh java-1.5.0-gcj-devel-1.5.0.0-21.fc9.i386 requires /usr/bin/gcj java-1.5.0-gcj-src-1.5.0.0-21.fc9.i386 requires /usr/bin/gij java-1.5.0-gcj-src-1.5.0.0-21.fc9.i386 requires /bin/sh java-1.5.0-gcj-src-1.5.0.0-21.fc9.i386 requires /usr/bin/gij 1:java-1.6.0-openjdk-1.6.0.0-0.12.b09.fc9.i386 requires /bin/sh 1:java-1.6.0-openjdk-1.6.0.0-0.12.b09.fc9.i386 requires /usr/bin/update-desktop-database 1:java-1.6.0-openjdk-1.6.0.0-0.12.b09.fc9.i386 requires /usr/sbin/alternatives 1:java-1.6.0-openjdk-demo-1.6.0.0-0.12.b09.fc9.i386 requires /bin/sh 1:java-1.6.0-openjdk-devel-1.6.0.0-0.12.b09.fc9.i386 requires /bin/sh 1:java-1.6.0-openjdk-devel-1.6.0.0-0.12.b09.fc9.i386 requires /usr/sbin/alternatives 1:java-1.6.0-openjdk-devel-1.6.0.0-0.12.b09.fc9.i386 requires /bin/sh 1:java-1.6.0-openjdk-javadoc-1.6.0.0-0.12.b09.fc9.i386 requires /usr/sbin/alternatives 1:java-1.6.0-openjdk-javadoc-1.6.0.0-0.12.b09.fc9.i386 requires /bin/sh 1:java-1.6.0-openjdk-plugin-1.6.0.0-0.12.b09.fc9.i386 requires /usr/lib/mozilla/plugins 1:java-1.6.0-openjdk-plugin-1.6.0.0-0.12.b09.fc9.i386 requires /usr/sbin/alternatives 1:java-1.6.0-openjdk-plugin-1.6.0.0-0.12.b09.fc9.i386 requires /bin/sh 1:java_cup-0.10-0.k.6jpp.2.i386 requires /bin/sh 1:java_cup-javadoc-0.10-0.k.6jpp.2.i386 requires /bin/sh 1:java_cup-javadoc-0.10-0.k.6jpp.2.i386 requires /bin/rm 1:java_cup-javadoc-0.10-0.k.6jpp.2.i386 requires /bin/ln javacc-4.0-4jpp.4.i386 requires /bin/sh javacc-4.0-4jpp.4.i386 requires /bin/sh jcommon-1.0.12-4.fc10.i386 requires /bin/sh jcommon-serializer-0.2.0-3.fc10.i386 requires /bin/sh jcommon-xml-1.0.12-4.fc10.i386 requires /bin/sh jd-2.0.0-0.4.svn2053_trunk.fc10.i386 requires /bin/sh jday-2.4-3.fc9.i386 requires /sbin/ldconfig jdepend-2.6-7jpp.3.i386 requires /bin/sh jdepend-javadoc-2.6-7jpp.3.i386 requires /bin/sh jdepend-javadoc-2.6-7jpp.3.i386 requires /bin/rm jdepend-javadoc-2.6-7jpp.3.i386 requires /bin/ln jdom-1.0-5jpp.2.fc9.i386 requires /bin/sh jdom-javadoc-1.0-5jpp.2.fc9.i386 requires /bin/sh jdom-javadoc-1.0-5jpp.2.fc9.i386 requires /bin/rm jdom-javadoc-1.0-5jpp.2.fc9.i386 requires /bin/ln jetty-5.1.12-1jpp.9.fc8.i386 requires /bin/sh jetty-5.1.12-1jpp.9.fc8.i386 requires /sbin/chkconfig jetty-5.1.12-1jpp.9.fc8.i386 requires /bin/sh jgroups-2.2.9.2-3jpp.2.i386 requires /bin/sh jgroups-javadoc-2.2.9.2-3jpp.2.i386 requires /bin/sh jgroups-javadoc-2.2.9.2-3jpp.2.i386 requires /bin/rm jgroups-javadoc-2.2.9.2-3jpp.2.i386 requires /bin/ln jigdo-0.7.3-6.fc9.i386 requires /bin/sh jlex-1.2.6-6jpp.1.i386 requires /bin/sh jlex-javadoc-1.2.6-6jpp.1.i386 requires /bin/sh jlex-javadoc-1.2.6-6jpp.1.i386 requires /bin/rm jlex-javadoc-1.2.6-6jpp.1.i386 requires /bin/ln jline-0.9.94-0jpp.1.fc9.noarch requires /bin/sh jline-0.9.94-0jpp.1.fc9.noarch requires /bin/stty john-1.7.0.2-6.fc9.i386 requires /bin/sh jokosher-1.0-0.2.20080216svn.fc9.noarch requires /bin/sh jokosher-1.0-0.2.20080216svn.fc9.noarch requires /usr/bin/python jomolhari-fonts-0.003-5.fc10.noarch requires /bin/sh joni-1.0.2-4.fc9.i386 requires /bin/sh jpackage-utils-1.7.5-1jpp.1.fc9.noarch requires /bin/sh jpgalleg-2.5-3.fc9.i386 requires /sbin/ldconfig jpilot-0.99.9-6.fc9.i386 requires /sbin/ldconfig jrefactory-2.8.9-7jpp.4.fc9.i386 requires /bin/sh jrtplib-3.7.1-4.fc9.i386 requires /sbin/ldconfig jruby-1.1.1-5.fc10.noarch requires /bin/bash jruby-1.1.1-5.fc10.noarch requires /usr/bin/env js-1.70-2.fc9.i386 requires /sbin/ldconfig jsch-0.1.31-2jpp.3.fc9.i386 requires /bin/sh jsch-demo-0.1.31-2jpp.3.fc9.i386 requires /bin/sh jsch-demo-0.1.31-2jpp.3.fc9.i386 requires /bin/rm jsch-demo-0.1.31-2jpp.3.fc9.i386 requires /bin/ln jsch-javadoc-0.1.31-2jpp.3.fc9.i386 requires /bin/sh jsch-javadoc-0.1.31-2jpp.3.fc9.i386 requires /bin/rm jsch-javadoc-0.1.31-2jpp.3.fc9.i386 requires /bin/ln jthread-1.2.1-4.fc9.i386 requires /sbin/ldconfig 2:jtidy-1.0-0.2.r7dev.1jpp.2.fc9.i386 requires /bin/sh 2:jtidy-javadoc-1.0-0.2.r7dev.1jpp.2.fc9.i386 requires /bin/rm 2:jtidy-javadoc-1.0-0.2.r7dev.1jpp.2.fc9.i386 requires /bin/ln junit-3.8.2-4jpp.3.fc9.i386 requires /bin/sh jwhois-4.0-7.fc9.i386 requires /bin/sh jwhois-4.0-7.fc9.i386 requires /sbin/install-info jython-2.2.1-0.1.Release_2_2_1.1jpp.1.fc9.i386 requires /bin/sh jython-demo-2.2.1-0.1.Release_2_2_1.1jpp.1.fc9.i386 requires /bin/sh jzlib-1.0.7-5jpp.1.i386 requires /bin/sh jzlib-demo-1.0.7-5jpp.1.i386 requires /bin/sh jzlib-demo-1.0.7-5jpp.1.i386 requires /bin/rm jzlib-demo-1.0.7-5jpp.1.i386 requires /bin/ln jzlib-javadoc-1.0.7-5jpp.1.i386 requires /bin/sh jzlib-javadoc-1.0.7-5jpp.1.i386 requires /bin/rm jzlib-javadoc-1.0.7-5jpp.1.i386 requires /bin/ln k3b-1.0.4-9.fc10.i386 requires /bin/sh k3d-0.6.7.0-7.fc10.i386 requires /sbin/ldconfig k3d-0.6.7.0-7.fc10.i386 requires /bin/bash k3d-0.6.7.0-7.fc10.i386 requires /bin/sh k3d-0.6.7.0-7.fc10.i386 requires /bin/sh k3d-devel-0.6.7.0-7.fc10.i386 requires /bin/sh kacst-fonts-1.6.2-2.fc8.noarch requires /bin/sh kadu-0.6.0-3.fc9.i386 requires /bin/sh kadu-dcopexport-0.6.0-3.fc9.i386 requires /bin/sh kadu-devel-0.6.0-3.fc9.i386 requires /bin/sh kaffeine-0.8.6-4.fc9.i386 requires /bin/sh kaffeine-libs-0.8.6-4.fc9.i386 requires /sbin/ldconfig kakasi-2.3.4-26.fc9.i386 requires /sbin/ldconfig kakasi-2.3.4-26.fc9.i386 requires /bin/sh kannel-1.4.1-7.i386 requires /bin/sh kannel-1.4.1-7.i386 requires /bin/sh kannel-devel-1.4.1-7.i386 requires /bin/sh kanyremote-4.8-1.fc10.noarch requires /usr/bin/env kasablanca-0.4.0.2-12.fc9.i386 requires /bin/sh katapult-0.3.2.1-3.fc9.i386 requires /bin/sh 1:kawa-1.9.1-5.fc9.i386 requires /bin/sh 1:kawa-1.9.1-5.fc9.i386 requires /bin/sh kbackup-0.5.3-4.fc9.i386 requires /bin/sh kbanking-2.3.3-3.fc9.i386 requires /sbin/ldconfig kbanking-devel-2.3.3-3.fc9.i386 requires /bin/sh kbd-1.12-31.fc9.i386 requires /bin/bash kbd-1.12-31.fc9.i386 requires /bin/sh kbibtex-0.2.1-19.fc9.i386 requires /bin/sh kbilliards-0.8.7b-7.fc9.i386 requires /bin/sh kcbench-0.3-1.1.noarch requires /bin/bash kcbench-0.3-1.1.noarch requires /usr/bin/bc kcbench-0.3-1.1.noarch requires /usr/bin/time kcbench-data-2.6.25-0.1-3.noarch requires /usr/bin/perl kcbench-data-2.6.25-0.1-3.noarch requires /bin/bash kcbench-data-2.6.25-0.1-3.noarch requires /usr/bin/env kcbench-data-2.6.25-0.1-3.noarch requires /bin/sh kcbench-data-2.6.25-0.1-3.noarch requires /usr/bin/python kcemirror-0.1.5-4.fc9.i386 requires /bin/sh kchmviewer-4.0-0.2.beta2.fc9.i386 requires /bin/sh kcoloredit-4.0.3-2.fc9.i386 requires /bin/sh 1:kdbg-2.1.0-2.fc9.i386 requires /bin/sh kde-settings-4.0-22.fc9.1.noarch requires /bin/sh kde-settings-4.0-22.fc9.1.noarch requires /bin/sh kde-settings-kdm-4.0-22.fc9.1.noarch requires /bin/sh kde-settings-kdm-4.0-22.fc9.1.noarch requires /bin/sh 1:kdeaccessibility-4.0.72-1.fc10.i386 requires /bin/sh 1:kdeaccessibility-4.0.72-1.fc10.i386 requires /sbin/ldconfig kdeaddons-atlantikdesigner-3.5.9-1.fc9.i386 requires /bin/sh 7:kdeadmin-4.0.72-1.fc10.i386 requires /bin/sh 7:kdeadmin-4.0.72-1.fc10.i386 requires /usr/bin/env 7:kdeadmin-4.0.72-1.fc10.i386 requires /sbin/ldconfig 7:kdeadmin-kpackage-4.0.72-1.fc10.i386 requires /bin/sh kdeartwork-icons-4.0.72-1.fc10.i386 requires /bin/sh 6:kdebase-4.0.72-2.fc10.i386 requires /bin/sh 6:kdebase-4.0.72-2.fc10.i386 requires /bin/sh 6:kdebase-libs-4.0.72-2.fc10.i386 requires /sbin/ldconfig kdebase-runtime-4.0.72-2.fc10.i386 requires /sbin/ldconfig kdebase-runtime-4.0.72-2.fc10.i386 requires /usr/bin/perl kdebase-runtime-4.0.72-2.fc10.i386 requires /bin/sh kdebase-runtime-4.0.72-2.fc10.i386 requires /bin/sh kdebase-workspace-4.0.72-3.fc10.i386 requires /usr/bin/perl kdebase-workspace-4.0.72-3.fc10.i386 requires /bin/sh kdebase-workspace-4.0.72-3.fc10.i386 requires /bin/sh kdebase-workspace-libs-4.0.72-3.fc10.i386 requires /sbin/ldconfig kdebase3-3.5.9-10.fc9.i386 requires /usr/bin/perl kdebase3-3.5.9-10.fc9.i386 requires /bin/sh kdebase3-3.5.9-10.fc9.i386 requires /bin/sh kdebase3-libs-3.5.9-10.fc9.i386 requires /sbin/ldconfig kdebindings-4.0.72-1.fc10.i386 requires /sbin/ldconfig kdebindings-4.0.72-1.fc10.i386 requires /usr/bin/env kdebindings-4.0.72-1.fc10.i386 requires /bin/sh kdebluetooth-1.0-0.41.beta8.fc9.i386 requires /bin/sh kdebluetooth-1.0-0.41.beta8.fc9.i386 requires /bin/bash kdebluetooth-1.0-0.41.beta8.fc9.i386 requires /bin/sh kdebluetooth-1.0-0.41.beta8.fc9.i386 requires /usr/bin/kdesu kdeedu-4.0.72-2.fc10.i386 requires /bin/sh kdeedu-4.0.72-2.fc10.i386 requires /usr/bin/env kdeedu-kstars-4.0.72-2.fc10.i386 requires /bin/sh kdeedu-libs-4.0.72-2.fc10.i386 requires /sbin/ldconfig 6:kdegames-4.0.72-2.fc10.i386 requires /bin/sh 6:kdegames-libs-4.0.72-2.fc10.i386 requires /sbin/ldconfig kdegames3-3.5.9-1.fc9.i386 requires /bin/sh kdegames3-libs-3.5.9-1.fc9.i386 requires /sbin/ldconfig 7:kdegraphics-4.0.72-2.fc10.i386 requires /bin/sh 7:kdegraphics-libs-4.0.72-2.fc10.i386 requires /sbin/ldconfig 6:kdelibs-4.0.72-4.fc10.i386 requires /sbin/ldconfig 6:kdelibs-4.0.72-4.fc10.i386 requires /usr/bin/perl 6:kdelibs-4.0.72-4.fc10.i386 requires /bin/sh 6:kdelibs-4.0.72-4.fc10.i386 requires /bin/sh 6:kdelibs-devel-4.0.72-4.fc10.i386 requires /bin/sh kdelibs3-3.5.9-10.fc10.i386 requires /sbin/ldconfig kdelibs3-3.5.9-10.fc10.i386 requires /usr/bin/perl kdelibs3-3.5.9-10.fc10.i386 requires /bin/sh kdelibs3-3.5.9-10.fc10.i386 requires /bin/sh kdelibs3-devel-3.5.9-10.fc10.i386 requires /bin/sh 6:kdemultimedia-4.0.72-1.fc10.i386 requires /bin/sh 6:kdemultimedia-4.0.72-1.fc10.i386 requires /usr/bin/env 6:kdemultimedia-4.0.72-1.fc10.i386 requires /usr/bin/perl 6:kdemultimedia-libs-4.0.72-1.fc10.i386 requires /sbin/ldconfig 7:kdenetwork-4.0.72-2.fc10.i386 requires /usr/bin/perl 7:kdenetwork-4.0.72-2.fc10.i386 requires /bin/sh 7:kdenetwork-4.0.72-2.fc10.i386 requires /bin/sh 7:kdenetwork-libs-4.0.72-2.fc10.i386 requires /sbin/ldconfig 6:kdepim-3.5.9-9.fc9.i386 requires /sbin/ldconfig 6:kdepim-3.5.9-9.fc9.i386 requires /usr/bin/perl 6:kdepim-3.5.9-9.fc9.i386 requires /bin/sh 6:kdepim-3.5.9-9.fc9.i386 requires /usr/bin/env 6:kdepim-3.5.9-9.fc9.i386 requires /bin/sh 6:kdepim-libs-3.5.9-9.fc9.i386 requires /sbin/ldconfig kdepimlibs-4.0.72-2.fc10.i386 requires /sbin/ldconfig kdepimlibs-4.0.72-2.fc10.i386 requires /usr/bin/perl kdesdk-4.0.72-1.fc10.i386 requires /usr/bin/perl kdesdk-4.0.72-1.fc10.i386 requires /bin/sh kdesdk-4.0.72-1.fc10.i386 requires /usr/bin/env kdesdk-4.0.72-1.fc10.i386 requires /bin/bash kdesdk-4.0.72-1.fc10.i386 requires /bin/sh kdesdk-libs-4.0.72-1.fc10.i386 requires /sbin/ldconfig kdesvn-0.14.3-1.fc10.i386 requires /bin/sh kdesvn-0.14.3-1.fc10.i386 requires /bin/sh 7:kdetoys-4.0.72-1.fc10.i386 requires /bin/sh 7:kdetoys-4.0.72-1.fc10.i386 requires /sbin/ldconfig kdetv-0.8.9-10.fc9.i386 requires /bin/sh 6:kdeutils-4.0.72-1.fc10.i386 requires /sbin/ldconfig 6:kdeutils-4.0.72-1.fc10.i386 requires /bin/sh 9:kdevelop-3.5.1-4.fc9.i386 requires /bin/sh 9:kdevelop-3.5.1-4.fc9.i386 requires /usr/bin/perl 9:kdevelop-libs-3.5.1-4.fc9.i386 requires /sbin/ldconfig 6:kdewebdev-3.5.9-3.fc9.i386 requires /bin/sh 6:kdewebdev-3.5.9-3.fc9.i386 requires /usr/bin/perl 6:kdewebdev-3.5.9-3.fc9.i386 requires /bin/sh 6:kdewebdev-libs-3.5.9-3.fc9.i386 requires /sbin/ldconfig kdiff3-0.9.92-13.fc9.i386 requires /bin/sh kdirstat-2.5.3-8.fc9.i386 requires /bin/sh kdirstat-2.5.3-8.fc9.i386 requires /usr/bin/perl kdissert-1.0.7-4.fc9.i386 requires /bin/sh kdnssd-avahi-0.1.3-0.6.20080116svn.fc9.i386 requires /sbin/ldconfig keepalived-1.1.15-5.fc10.i386 requires /bin/sh keepalived-1.1.15-5.fc10.i386 requires /sbin/chkconfig keepalived-1.1.15-5.fc10.i386 requires /bin/sh keepalived-1.1.15-5.fc10.i386 requires /sbin/service keepassx-0.3.1-1.fc9.i386 requires /bin/sh kernel-2.6.25.2-5.fc10.i586 requires /bin/sh kernel-2.6.25.2-5.fc10.i586 requires /bin/sh kernel-2.6.25.2-5.fc10.i686 requires /bin/sh kernel-2.6.25.2-5.fc10.i686 requires /bin/sh kernel-PAE-2.6.25.2-5.fc10.i686 requires /bin/sh kernel-PAE-2.6.25.2-5.fc10.i686 requires /bin/sh kernel-PAE-devel-2.6.25.2-5.fc10.i686 requires /usr/bin/find kernel-PAE-devel-2.6.25.2-5.fc10.i686 requires /bin/sh kernel-PAEdebug-2.6.25.2-5.fc10.i686 requires /bin/sh kernel-PAEdebug-2.6.25.2-5.fc10.i686 requires /bin/sh kernel-PAEdebug-devel-2.6.25.2-5.fc10.i686 requires /usr/bin/find kernel-PAEdebug-devel-2.6.25.2-5.fc10.i686 requires /bin/sh kernel-debug-2.6.25.2-5.fc10.i686 requires /bin/sh kernel-debug-2.6.25.2-5.fc10.i686 requires /bin/sh kernel-debug-devel-2.6.25.2-5.fc10.i686 requires /usr/bin/find kernel-debug-devel-2.6.25.2-5.fc10.i686 requires /bin/sh kernel-devel-2.6.25.2-5.fc10.i586 requires /usr/bin/find kernel-devel-2.6.25.2-5.fc10.i586 requires /bin/sh kernel-devel-2.6.25.2-5.fc10.i686 requires /usr/bin/find kernel-devel-2.6.25.2-5.fc10.i686 requires /bin/sh kernel-xen-2.6.25.2-2.fc10.i686 requires /bin/sh kernel-xen-2.6.25.2-2.fc10.i686 requires /bin/sh kernel-xen-devel-2.6.25.2-2.fc10.i686 requires /bin/sh kernel-xen-devel-2.6.25.2-2.fc10.i686 requires /usr/bin/find kerneloops-0.10-11.fc9.i386 requires /bin/sh kerneloops-0.10-11.fc9.i386 requires /bin/bash kerry-0.2.1-7.fc9.i386 requires /bin/sh kerry-0.2.1-7.fc9.i386 requires /bin/sh ketchup-0.9.8-1.fc8.noarch requires /usr/bin/python keurocalc-1.0.0-2.rc2.fc9.i386 requires /bin/sh kexec-tools-1.102pre-10.fc10.i386 requires /bin/sh kexec-tools-1.102pre-10.fc10.i386 requires /usr/bin/perl kexec-tools-1.102pre-10.fc10.i386 requires /bin/bash kexec-tools-1.102pre-10.fc10.i386 requires /bin/sh keychain-2.6.8-3.fc9.noarch requires /bin/sh keyjnote-0.10.2-1.fc9.noarch requires /usr/bin/env keyutils-1.2-3.fc9.i386 requires /bin/sh keyutils-libs-1.2-3.fc9.i386 requires /sbin/ldconfig kflickr-0.9.1-2.fc9.i386 requires /bin/sh kftpgrabber-0.8.1-6.fc9.i386 requires /bin/sh kftpgrabber-0.8.1-6.fc9.i386 requires /sbin/ldconfig kgrab-0.1.1-6.fc9.i386 requires /bin/sh kgtk-0.9.4-3.fc9.i386 requires /bin/bash kicad-2007.07.09-3.fc9.i386 requires /bin/sh kiconedit-4.0.3-2.fc9.i386 requires /bin/sh kid3-1.0-1.fc9.i386 requires /bin/sh kile-2.0.1-1.fc10.i386 requires /bin/sh kile-2.0.1-1.fc10.i386 requires /usr/bin/perl kinput2-v3.1-38.fc9.i386 requires /bin/sh kinput2-v3.1-38.fc9.i386 requires /usr/sbin/alternatives kinput2-v3.1-38.fc9.i386 requires /usr/sbin/alternatives kinput2-v3.1-38.fc9.i386 requires /bin/sh kio_sword-0.3-6.fc9.i386 requires /bin/sh kiosktool-1.0-10.fc9.i386 requires /bin/sh kipi-plugins-0.1.5-2.fc10.i386 requires /sbin/ldconfig kipi-plugins-0.1.5-2.fc10.i386 requires /bin/bash kismet-0.0.2007.10.R1-3.fc9.i386 requires /bin/sh kismet-0.0.2007.10.R1-3.fc9.i386 requires /etc/cron.daily kismet-0.0.2007.10.R1-3.fc9.i386 requires /bin/sh kismet-extras-0.0.2007.10.R1-3.fc9.i386 requires /usr/bin/perl kismet-extras-0.0.2007.10.R1-3.fc9.i386 requires libMagick.so.10 kita-0.177.3-12.fc9.2.i386 requires /bin/sh kita-0.177.3-12.fc9.2.i386 requires /sbin/ldconfig kitsune-2.0-4.fc9.i386 requires /bin/sh klamav-0.42-3.fc9.i386 requires /bin/sh kleansweep-0.2.9-7.fc9.i386 requires /bin/sh kleansweep-0.2.9-7.fc9.i386 requires /usr/bin/env klear-0.7.0-1.svn113.fc9.i386 requires /bin/sh kmenu-gnome-0.7.1-1.fc9.noarch requires /bin/sh kmid-2.0-0.6.20080213svn.fc9.i386 requires /bin/sh kmid-2.0-0.6.20080213svn.fc9.i386 requires /sbin/ldconfig kmobiletools-0.4.3.3-4.fc9.i386 requires /bin/sh kmplayer-0.10.0c-4.fc9.i386 requires /bin/sh kmymoney2-0.9-1.fc10.i386 requires /bin/sh kmymoney2-libs-0.9-1.fc10.i386 requires /sbin/ldconfig knetstats-1.6.1-8.fc9.i386 requires /bin/sh koan-0.8.0-1.fc9.noarch requires /usr/bin/python kodos-2.4.9-4.fc8.noarch requires /usr/bin/env kodos-2.4.9-4.fc8.noarch requires /usr/bin/python koffice-core-1.6.3-15.fc9.i386 requires /bin/sh koffice-filters-1.6.3-15.fc9.i386 requires /sbin/ldconfig koffice-karbon-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-karbon-1.6.3-15.fc9.i386 requires libMagick.so.10 koffice-kchart-1.6.3-15.fc9.i386 requires /sbin/ldconfig koffice-kexi-1.6.3-15.fc9.i386 requires /sbin/ldconfig koffice-kexi-1.6.3-15.fc9.i386 requires /bin/sh koffice-kpresenter-1.6.3-15.fc9.i386 requires /sbin/ldconfig koffice-kpresenter-1.6.3-15.fc9.i386 requires /usr/bin/perl koffice-kugar-1.6.3-15.fc9.i386 requires /sbin/ldconfig koffice-kword-1.6.3-15.fc9.i386 requires /sbin/ldconfig koffice-libs-1.6.3-15.fc9.i386 requires /sbin/ldconfig koffice-libs-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libMagick.so.10 koji-1.2.3-1.fc9.noarch requires /usr/bin/python koji-builder-1.2.3-1.fc9.noarch requires /bin/sh koji-builder-1.2.3-1.fc9.noarch requires /usr/bin/git koji-builder-1.2.3-1.fc9.noarch requires /sbin/chkconfig koji-builder-1.2.3-1.fc9.noarch requires /usr/bin/svn koji-builder-1.2.3-1.fc9.noarch requires /usr/sbin/useradd koji-builder-1.2.3-1.fc9.noarch requires /usr/bin/cvs koji-builder-1.2.3-1.fc9.noarch requires /bin/sh koji-builder-1.2.3-1.fc9.noarch requires /usr/bin/python koji-builder-1.2.3-1.fc9.noarch requires /sbin/service koji-utils-1.2.3-1.fc9.noarch requires /bin/sh koji-utils-1.2.3-1.fc9.noarch requires /bin/sh koji-utils-1.2.3-1.fc9.noarch requires /usr/bin/python komparator-0.9-1.fc9.i386 requires /bin/sh konq-plugins-4.0.3-0.3.20080409svn.fc9.i386 requires /bin/sh konq-plugins-4.0.3-0.3.20080409svn.fc9.i386 requires /usr/bin/env konversation-1.0.1-6.fc9.i386 requires /bin/sh konversation-1.0.1-6.fc9.i386 requires /usr/bin/env konversation-1.0.1-6.fc9.i386 requires /bin/bash konversation-1.0.1-6.fc9.i386 requires /bin/sh konversation-1.0.1-6.fc9.i386 requires /usr/bin/perl kooldock-0.4.6-4.fc9.i386 requires /bin/sh kover-3-3.i386 requires /bin/sh koverartist-0.5-11.fc9.i386 requires /bin/sh kpathsea-2007-31.fc10.i386 requires /bin/sh kpathsea-2007-31.fc10.i386 requires /sbin/restorecon kphotoalbum-3.1.1-2.fc10.i386 requires /bin/sh kphotobymail-0.4.1-1.fc7.noarch requires /usr/bin/env kpolynome-0.1.2-12.fc9.i386 requires /bin/sh kpowersave-0.7.3-3.fc9.i386 requires /bin/sh krb5-devel-1.6.3-10.fc9.i386 requires /bin/sh krb5-libs-1.6.3-10.fc9.i386 requires /sbin/ldconfig krb5-server-1.6.3-10.fc9.i386 requires /bin/sh krb5-server-1.6.3-10.fc9.i386 requires /sbin/install-info krb5-server-1.6.3-10.fc9.i386 requires /bin/bash krb5-server-1.6.3-10.fc9.i386 requires /bin/sh krb5-server-1.6.3-10.fc9.i386 requires /sbin/chkconfig krb5-workstation-1.6.3-10.fc9.i386 requires /bin/sh krb5-workstation-1.6.3-10.fc9.i386 requires /sbin/install-info krb5-workstation-1.6.3-10.fc9.i386 requires /bin/sh krb5-workstation-clients-1.6.3-10.fc9.i386 requires /bin/sh krb5-workstation-clients-1.6.3-10.fc9.i386 requires /sbin/install-info krb5-workstation-clients-1.6.3-10.fc9.i386 requires /bin/sh krb5-workstation-servers-1.6.3-10.fc9.i386 requires /bin/sh krb5-workstation-servers-1.6.3-10.fc9.i386 requires /etc/pam.d/remote krb5-workstation-servers-1.6.3-10.fc9.i386 requires /sbin/install-info krb5-workstation-servers-1.6.3-10.fc9.i386 requires /bin/bash krb5-workstation-servers-1.6.3-10.fc9.i386 requires /bin/sh krecipes-0.9.1-9.fc9.i386 requires /bin/sh kreetingkard-0.7.1-2.fc9.2.i386 requires /bin/sh krename-3.0.14-4.fc9.i386 requires /bin/sh krusader-1.80.0-5.fc9.i386 requires /bin/sh kscope-1.6.1-4.fc9.i386 requires /bin/sh ksensors-0.7.3-16.fc9.i386 requires /bin/sh ksh-20080202-1.fc9.i386 requires /bin/sh ksh-20080202-1.fc9.i386 requires /bin/sh kshutdown-1.0.1-2.fc9.i386 requires /bin/sh ksig-1.1-0.5.20080213.fc9.i386 requires /bin/sh ksirk-1.7-6.fc9.i386 requires /bin/sh ksirk-1.7-6.fc9.i386 requires /bin/bash ksmarttray-0.52-54.fc9.i386 requires /usr/bin/kdesu kst-1.6.0-2.fc10.i386 requires /sbin/ldconfig ksynaptics-0.3.3-5.fc9.i386 requires /bin/sh ktechlab-0.3.69-5.fc8.i386 requires /bin/sh ktorrent-3.0.2-3.fc10.i386 requires /bin/sh kudzu-1.2.85-1.i386 requires /sbin/chkconfig kudzu-1.2.85-1.i386 requires /bin/sh kvm-68-1.fc10.i386 requires /bin/sh labyrinth-0.4.0-1.fc10.noarch requires /bin/sh labyrinth-0.4.0-1.fc10.noarch requires /usr/bin/env lacewing-1.10-10.fc9.i386 requires /bin/sh lagan-2.0-2.fc9.i386 requires /usr/bin/env lagan-2.0-2.fc9.i386 requires /usr/bin/perl 2:lam-7.1.2-11.fc9.i386 requires /bin/sh 2:lam-7.1.2-11.fc9.i386 requires /usr/bin/env 2:lam-7.1.2-11.fc9.i386 requires /sbin/ldconfig 2:lam-7.1.2-11.fc9.i386 requires /usr/sbin/alternatives 2:lam-7.1.2-11.fc9.i386 requires /bin/sh 2:lam-devel-7.1.2-11.fc9.i386 requires /bin/sh 2:lam-devel-7.1.2-11.fc9.i386 requires /sbin/ldconfig 2:lam-devel-7.1.2-11.fc9.i386 requires /usr/sbin/alternatives 2:lam-libs-7.1.2-11.fc9.i386 requires /bin/sh 2:lam-libs-7.1.2-11.fc9.i386 requires /sbin/ldconfig 2:lam-libs-7.1.2-11.fc9.i386 requires /usr/sbin/alternatives lapack-3.1.1-3.fc9.i386 requires /sbin/ldconfig lash-0.5.4-2.fc9.i386 requires /sbin/install-info lash-0.5.4-2.fc9.i386 requires /bin/sh lasi-1.1.0-1.fc9.i386 requires /sbin/ldconfig lat-1.2.3-3.fc9.i386 requires /bin/sh lat-1.2.3-3.fc9.i386 requires /bin/sh latex-mk-1.8-2.fc7.noarch requires /bin/sh latex-mk-1.8-2.fc7.noarch requires /sbin/install-info latex-mk-1.8-2.fc7.noarch requires /bin/sh latex2html-2002.2.1-8.fc9.noarch requires /bin/sh latex2html-2002.2.1-8.fc9.noarch requires /usr/bin/perl latexmk-3.20-1.fc8.noarch requires /usr/bin/perl lbrickbuster2-2.6-0.9.beta7.fc8.i386 requires /bin/sh lcdproc-0.5.2-4.fc9.i386 requires /bin/sh lcdproc-0.5.2-4.fc9.i386 requires /usr/bin/perl lcdproc-0.5.2-4.fc9.i386 requires /bin/sh lcdproc-0.5.2-4.fc9.i386 requires /sbin/chkconfig lcms-libs-1.17-4.fc9.i386 requires /sbin/ldconfig lcov-1.4-2.fc6.noarch requires /usr/bin/perl lcov-1.4-2.fc6.noarch requires /usr/bin/gcov ldapjdk-4.18-1.fc9.i386 requires /bin/sh ldirectord-2.1.3-1.fc9.i386 requires /bin/sh ldirectord-2.1.3-1.fc9.i386 requires /sbin/ldconfig ldirectord-2.1.3-1.fc9.i386 requires /usr/bin/perl ldirectord-2.1.3-1.fc9.i386 requires /bin/sh ldirectord-2.1.3-1.fc9.i386 requires /sbin/chkconfig ldm-2.0.4-1.fc9.i386 requires /bin/sh ldns-1.2.2-3.fc9.i386 requires /sbin/ldconfig leafnode-1.11.6-3.fc9.i386 requires /bin/sh leafpad-0.8.13-1.fc9.i386 requires /bin/sh less-418-3.fc9.i386 requires /bin/sh lesstif-0.95.0-23.fc9.i386 requires /sbin/ldconfig lesstif-clients-0.95.0-23.fc9.i386 requires /bin/sh lesstif-devel-0.95.0-23.fc9.i386 requires /bin/sh lftp-3.7.1-1.fc10.i386 requires /bin/sh lftp-3.7.1-1.fc10.i386 requires /sbin/ldconfig lftp-3.7.1-1.fc10.i386 requires /usr/bin/perl lib3ds-1.3.0-2.fc9.i386 requires /sbin/ldconfig lib3ds-devel-1.3.0-2.fc9.i386 requires /bin/sh lib765-0.4.1-3.fc9.i386 requires /sbin/ldconfig libAfterImage-1.15-4.fc9.i386 requires /sbin/ldconfig libAfterImage-devel-1.15-4.fc9.i386 requires /bin/sh libEMF-1.0.3-7.fc9.i386 requires /sbin/ldconfig libFS-1.0.0-7.fc9.i386 requires /sbin/ldconfig libFoundation-1.1.3-11.fc9.i386 requires /sbin/ldconfig libHX-1.15-1.fc10.i386 requires /sbin/ldconfig libICE-1.0.4-3.fc9.i386 requires /sbin/ldconfig libIDL-0.8.10-2.fc9.i386 requires /sbin/ldconfig libIDL-devel-0.8.10-2.fc9.i386 requires /bin/sh libIDL-devel-0.8.10-2.fc9.i386 requires /sbin/install-info libIDL-devel-0.8.10-2.fc9.i386 requires /bin/sh libRmath-2.7.0-2.fc10.i386 requires /bin/sh libSM-1.0.2-5.fc9.i386 requires /sbin/ldconfig libX11-1.1.4-1.fc9.i386 requires /sbin/ldconfig libXNVCtrl-169.12-1.fc9.i386 requires /sbin/ldconfig libXScrnSaver-1.1.2-4.fc9.i386 requires /sbin/ldconfig libXTrap-1.0.0-5.fc9.i386 requires /sbin/ldconfig libXau-1.0.3-5.fc9.i386 requires /sbin/ldconfig libXaw-1.0.4-2.fc9.i386 requires /sbin/ldconfig libXcomposite-0.4.0-4.fc9.i386 requires /sbin/ldconfig libXcursor-1.1.9-2.fc9.i386 requires /sbin/ldconfig libXdamage-1.1.1-4.fc9.i386 requires /sbin/ldconfig libXdmcp-1.0.2-5.fc9.i386 requires /sbin/ldconfig libXevie-1.0.2-3.fc9.i386 requires /sbin/ldconfig libXext-1.0.4-1.fc9.i386 requires /sbin/ldconfig libXfixes-4.0.3-3.fc9.i386 requires /sbin/ldconfig libXfont-1.3.1-4.fc9.i386 requires /sbin/ldconfig libXfontcache-1.0.4-5.fc9.i386 requires /sbin/ldconfig libXft-2.1.12-5.fc9.i386 requires /sbin/ldconfig libXi-1.1.3-4.fc9.i386 requires /sbin/ldconfig libXinerama-1.0.3-1.fc9.i386 requires /sbin/ldconfig libXmu-1.0.4-1.fc9.i386 requires /sbin/ldconfig libXp-1.0.0-11.fc9.i386 requires /sbin/ldconfig libXpm-3.5.7-4.fc9.i386 requires /sbin/ldconfig libXrandr-1.2.2-3.fc9.i386 requires /sbin/ldconfig libXrender-0.9.4-3.fc9.i386 requires /sbin/ldconfig libXres-1.0.3-4.fc9.i386 requires /sbin/ldconfig libXt-1.0.4-5.fc9.i386 requires /sbin/ldconfig libXtst-1.0.3-3.fc9.i386 requires /sbin/ldconfig libXv-1.0.3-5.fc9.i386 requires /sbin/ldconfig libXvMC-1.0.4-4.fc9.i386 requires /sbin/ldconfig libXxf86dga-1.0.2-2.fc9.i386 requires /sbin/ldconfig libXxf86misc-1.0.1-5.fc9.i386 requires /sbin/ldconfig libXxf86vm-1.0.1-5.fc9.i386 requires /sbin/ldconfig libacl-2.2.47-1.fc9.i386 requires /sbin/ldconfig libaio-0.3.106-4.2.i386 requires /sbin/ldconfig libannodex-0.7.3-10.fc9.i386 requires /bin/sh libannodex-0.7.3-10.fc9.i386 requires /sbin/ldconfig libao-0.8.8-4.fc9.i386 requires /sbin/ldconfig libao-devel-0.8.8-4.fc9.i386 requires /usr/lib/libao.so.2 libapreq2-2.09-0.15.rc2.fc9.i386 requires /bin/sh libapreq2-2.09-0.15.rc2.fc9.i386 requires /sbin/ldconfig libapreq2-devel-2.09-0.15.rc2.fc9.i386 requires /bin/sh libarchive-2.4.17-1.fc9.i386 requires /sbin/ldconfig libart_lgpl-2.3.20-1.fc9.i386 requires /sbin/ldconfig libart_lgpl-devel-2.3.20-1.fc9.i386 requires /bin/sh libassa-3.5.0-2.i386 requires /sbin/ldconfig libassuan-devel-1.0.4-3.fc9.i386 requires /bin/sh libassuan-devel-1.0.4-3.fc9.i386 requires /sbin/install-info libassuan-devel-1.0.4-3.fc9.i386 requires /bin/sh libast-0.7.1-0.6.20080502cvs.fc10.i386 requires /sbin/ldconfig libast-devel-0.7.1-0.6.20080502cvs.fc10.i386 requires /bin/sh libattr-2.4.41-1.fc9.i386 requires /sbin/ldconfig libavc1394-0.5.3-2.fc9.i386 requires /sbin/ldconfig libax25-0.0.11-3.fc9.i386 requires /sbin/ldconfig libbeagle-0.3.5-1.fc9.i386 requires /sbin/ldconfig libbinio-1.4-9.fc9.i386 requires /sbin/ldconfig libbinio-devel-1.4-9.fc9.i386 requires /bin/sh libbinio-devel-1.4-9.fc9.i386 requires /sbin/install-info libbonobo-2.22.0-3.fc10.i386 requires /sbin/ldconfig libbonobo-2.22.0-3.fc10.i386 requires /usr/bin/perl libbonoboui-2.22.0-2.fc9.i386 requires /sbin/ldconfig libbtctl-0.10.0-2.fc9.i386 requires /sbin/ldconfig libburn-0.4.0-2.fc9.i386 requires /sbin/ldconfig libc-client-2007a1-3.fc9.i386 requires /sbin/ldconfig libcaca-0.99-0.4.beta11.fc9.i386 requires /sbin/ldconfig libcaca-devel-0.99-0.4.beta11.fc9.i386 requires /bin/sh libcap-2.06-4.fc9.i386 requires /sbin/ldconfig libcapseo-0.2.0-0.1.20080323git1c5f3e5.fc10.i386 requires /sbin/ldconfig libcdaudio-0.99.12p2-9.fc9.i386 requires /sbin/ldconfig libcdaudio-devel-0.99.12p2-9.fc9.i386 requires /bin/sh libcddb-1.3.0-4.fc9.i386 requires /sbin/ldconfig libcdio-0.79-3.fc9.i386 requires /bin/sh libcdio-0.79-3.fc9.i386 requires /sbin/install-info libcdio-0.79-3.fc9.i386 requires /sbin/ldconfig libcgi-1.0-8.fc9.i386 requires /sbin/ldconfig libchewing-0.3.0-11.fc10.i386 requires /sbin/ldconfig libchmxx-0.2-2.fc9.i386 requires /sbin/ldconfig libcmml-0.9.1-5.fc9.i386 requires /sbin/ldconfig libcmpiutil-0.3-1.fc9.i386 requires /sbin/ldconfig libcompizconfig-0.7.2-1.fc9.i386 requires /sbin/ldconfig libconcord-0.20-5.fc10.i386 requires /sbin/ldconfig libconfig-1.2.1-2.fc9.i386 requires /sbin/ldconfig libconfig-devel-1.2.1-2.fc9.i386 requires /bin/sh libconfig-devel-1.2.1-2.fc9.i386 requires /sbin/install-info libconfuse-2.6-1.fc9.i386 requires /sbin/ldconfig libcroco-0.6.1-5.fc9.i386 requires /bin/sh libcroco-devel-0.6.1-5.fc9.i386 requires /bin/sh libctl-3.0.2-6.fc9.i386 requires /sbin/ldconfig libctl-devel-3.0.2-6.fc9.i386 requires /bin/sh libcurl-7.18.1-2.fc10.i386 requires /sbin/ldconfig libcurl-devel-7.18.1-2.fc10.i386 requires /bin/sh libdaemon-0.12-3.fc9.i386 requires /sbin/ldconfig libdap-3.7.10-2.fc9.i386 requires /sbin/ldconfig libdap-devel-3.7.10-2.fc9.i386 requires /bin/sh libdar-2.3.6-3.fc9.i386 requires /sbin/ldconfig libdbi-0.8.3-1.fc9.i386 requires /sbin/ldconfig libdbi-drivers-0.8.3-1.fc9.i386 requires /sbin/ldconfig libdc1394-2.0.2-1.fc10.i386 requires /sbin/ldconfig libdhcp-1.99.8-1.fc10.i386 requires /sbin/ldconfig 12:libdhcp4client-4.0.0-15.fc10.i386 requires /sbin/ldconfig libdhcp6client-1.0.15-1.fc10.i386 requires /sbin/ldconfig libdiscid-0.1.1-6.fc9.i386 requires /sbin/ldconfig libdmx-1.0.2-5.fc9.i386 requires /sbin/ldconfig libdnet-1.12-3.fc9.i386 requires /sbin/ldconfig libdnet-devel-1.12-3.fc9.i386 requires /bin/sh libdockapp-0.6.2-1.fc10.i386 requires /sbin/ldconfig libdockapp-fonts-0.6.2-1.fc10.i386 requires /bin/sh libdrm-2.4.0-0.11.fc9.i386 requires /sbin/ldconfig libdsk-1.2.1-1.fc9.i386 requires /sbin/ldconfig libdstr-20080124-1.fc9.i386 requires /sbin/ldconfig libdv-1.0.0-4.fc9.i386 requires /sbin/ldconfig libdvdnav-4.1.1-6.fc9.i386 requires /sbin/ldconfig libdvdnav-devel-4.1.1-6.fc9.i386 requires /bin/sh libdvdread-4.1.1-6.fc9.i386 requires /sbin/ldconfig libdwarves1-1.6-1.i386 requires /sbin/ldconfig libeXosip2-3.1.0-1.fc9.i386 requires /sbin/ldconfig libebml-0.7.8-1.fc9.i386 requires /sbin/ldconfig libedit-2.10-4.20070831cvs.fc9.i386 requires /sbin/ldconfig libepc-0.3.5-1.fc10.i386 requires /sbin/ldconfig libepc-ui-0.3.5-1.fc10.i386 requires /sbin/ldconfig liberation-fonts-1.0-4.fc9.noarch requires /bin/sh libesmtp-1.0.4-7.fc9.i386 requires /sbin/ldconfig libesmtp-devel-1.0.4-7.fc9.i386 requires /bin/sh libetpan-0.52-5.fc9.i386 requires /sbin/ldconfig libetpan-devel-0.52-5.fc9.i386 requires /bin/sh libevent-1.3e-2.fc9.i386 requires /sbin/ldconfig libevent-devel-1.3e-2.fc9.i386 requires /usr/bin/env libewf-20080501-1.fc10.i386 requires /sbin/ldconfig libexif-0.6.16-1.fc9.i386 requires /sbin/ldconfig libextractor-0.5.19a-1.fc9.i386 requires /sbin/install-info libextractor-0.5.19a-1.fc9.i386 requires /sbin/ldconfig libextractor-0.5.19a-1.fc9.i386 requires /bin/sh libextractor-devel-0.5.19a-1.fc9.i386 requires /usr/lib/pkgconfig libextractor-plugins-thumbnailgtk-0.5.19a-1.fc9.i386 requires /usr/sbin/update-alternatives libextractor-plugins-thumbnailgtk-0.5.19a-1.fc9.i386 requires /bin/sh libextractor-plugins-thumbnailqt-0.5.19a-1.fc9.i386 requires /bin/sh libextractor-plugins-thumbnailqt-0.5.19a-1.fc9.i386 requires /usr/sbin/update-alternatives libffi-3.0.1-1.fc9.i386 requires /sbin/ldconfig libffi-devel-3.0.1-1.fc9.i386 requires /bin/sh libffi-devel-3.0.1-1.fc9.i386 requires /sbin/install-info libfishsound-0.9.1-1.fc9.i386 requires /sbin/ldconfig libflaim-4.9.1052-1.fc9.i386 requires /sbin/ldconfig libfontenc-1.0.4-5.fc9.i386 requires /sbin/ldconfig libfprint-0.0.5-6.fc10.i386 requires /sbin/ldconfig libfreebob-1.0.7-4.fc9.i386 requires /sbin/ldconfig libfwbuilder-2.1.16-2.fc9.i386 requires /sbin/ldconfig libfwbuilder-devel-2.1.16-2.fc9.i386 requires /bin/sh libgadu-1.8.0-1.fc9.i386 requires /sbin/ldconfig libgail-gnome-1.20.0-2.fc9.i386 requires /sbin/ldconfig libgalago-0.5.2-7.fc9.i386 requires /sbin/ldconfig libgalago-gtk-0.5.0-7.fc9.i386 requires /sbin/ldconfig libgcc-4.3.0-8.i386 requires /usr/sbin/libgcc_post_upgrade libgcj-4.3.0-8.i386 requires /bin/sh libgcj-4.3.0-8.i386 requires /sbin/install-info libgcj-4.3.0-8.i386 requires /sbin/ldconfig libgcj-devel-4.3.0-8.i386 requires /usr/lib/libgcj.so.9 libgcj-devel-4.3.0-8.i386 requires /usr/lib/libz.so libgcj-devel-4.3.0-8.i386 requires /bin/awk libgconf-java-2.12.4-10.fc9.i386 requires /sbin/ldconfig libgconf-java-devel-2.12.4-10.fc9.i386 requires /bin/sh libgcroots-0.2.1-3.fc9.i386 requires /sbin/ldconfig libgcrypt-1.4.0-3.i386 requires /sbin/ldconfig libgcrypt-devel-1.4.0-3.i386 requires /bin/sh libgcrypt-devel-1.4.0-3.i386 requires /sbin/install-info libgcrypt-devel-1.4.0-3.i386 requires /bin/sh 1:libgda-3.1.2-3.fc9.i386 requires /sbin/ldconfig 1:libgda-devel-3.1.2-3.fc9.i386 requires /bin/sh libgdamm-3.0.0-1.fc9.i386 requires /sbin/ldconfig libgdiplus-1.9-4.fc9.i386 requires /sbin/ldconfig libgdl-0.7.11-1.fc9.i386 requires /sbin/ldconfig libgeda-20080127-1.fc9.i386 requires /sbin/ldconfig libgeda-20080127-1.fc9.i386 requires /bin/sh libgee-0.1.1-3.fc9.i386 requires /sbin/ldconfig libgeotiff-1.2.4-3.fc9.i386 requires /sbin/ldconfig libgfortran-4.3.0-8.i386 requires /sbin/ldconfig libggz-0.0.14.1-1.fc9.i386 requires /sbin/ldconfig libgii-1.0.2-6.fc9.i386 requires /sbin/ldconfig 1:libglade-0.17-21.fc9.i386 requires /sbin/ldconfig 1:libglade-devel-0.17-21.fc9.i386 requires /usr/bin/env 1:libglade-devel-0.17-21.fc9.i386 requires /bin/sh libglade-java-2.12.5-8.fc9.i386 requires /sbin/ldconfig libglade2-2.6.2-5.fc9.i386 requires /sbin/ldconfig libglade2-devel-2.6.2-5.fc9.i386 requires /usr/bin/python libglademm24-2.6.6-1.fc9.i386 requires /sbin/ldconfig libglademm24-2.6.6-1.fc9.i386 requires /bin/sh libgnat-4.3.0-8.i386 requires /sbin/ldconfig libgnome-2.22.0-3.fc9.i386 requires /bin/sh libgnome-2.22.0-3.fc9.i386 requires /sbin/ldconfig libgnome-java-2.12.4-8.fc9.i386 requires /sbin/ldconfig libgnomecanvas-2.20.1.1-2.fc9.i386 requires /sbin/ldconfig libgnomecanvasmm26-2.22.0-1.fc9.i386 requires /sbin/ldconfig libgnomecanvasmm26-2.22.0-1.fc9.i386 requires /bin/sh libgnomecups-0.2.3-3.fc9.i386 requires /sbin/ldconfig 1:libgnomedb-3.0.0-6.fc9.i386 requires /sbin/ldconfig 1:libgnomedb-3.0.0-6.fc9.i386 requires /bin/sh 1:libgnomedb-devel-3.0.0-6.fc9.i386 requires /bin/sh libgnomedbmm-2.9.5-4.fc9.i386 requires /sbin/ldconfig libgnomekbd-2.23.2-1.fc10.i386 requires /bin/sh libgnomemm26-2.22.0-1.i386 requires /sbin/ldconfig libgnomemm26-2.22.0-1.i386 requires /bin/sh libgnomeprint22-2.18.4-1.fc9.i386 requires /sbin/ldconfig libgnomeprintui22-2.18.2-1.fc9.i386 requires /sbin/ldconfig libgnomeui-2.22.1-2.fc9.i386 requires /sbin/ldconfig libgnomeuimm26-2.22.0-1.fc9.i386 requires /bin/sh libgnomeuimm26-2.22.0-1.fc9.i386 requires /sbin/ldconfig libgomp-4.3.0-8.i386 requires /bin/sh libgomp-4.3.0-8.i386 requires /sbin/ldconfig libgomp-4.3.0-8.i386 requires /sbin/install-info libgpg-error-1.6-2.i386 requires /sbin/ldconfig libgpg-error-devel-1.6-2.i386 requires /bin/sh libgpod-0.6.0-5.fc10.i386 requires /sbin/ldconfig libgringotts-1.2.1-4.fc9.i386 requires /sbin/ldconfig libgsasl-0.2.18-6.fc9.i386 requires /sbin/ldconfig libgsf-1.14.8-1.fc9.i386 requires /bin/sh libgsf-1.14.8-1.fc9.i386 requires /sbin/ldconfig libgsf-gnome-1.14.8-1.fc9.i386 requires /sbin/ldconfig libgssapi-0.11-3.fc9.i386 requires /sbin/ldconfig libgssglue-0.1-5.fc9.i386 requires /sbin/ldconfig libgstroke-0.5.1-17.fc9.i386 requires /sbin/ldconfig libgtk-java-2.8.7-7.fc9.i386 requires /sbin/ldconfig libgtk-java-devel-2.8.7-7.fc9.i386 requires /bin/sh libgtksourceviewmm-0.3.1-1.fc8.i386 requires /sbin/ldconfig libgtop2-2.22.1-1.fc9.i386 requires /sbin/ldconfig libgweather-2.23.2-1.fc10.i386 requires /sbin/ldconfig libgweather-2.23.2-1.fc10.i386 requires /bin/sh libhangul-0.0.6-4.fc9.i386 requires /sbin/ldconfig libibverbs-1.1.1-3.fc9.i386 requires /sbin/ldconfig libical-0.30-1.fc9.i386 requires /sbin/ldconfig libical-devel-0.30-1.fc9.i386 requires /bin/sh libicu-3.8.1-7.fc9.i386 requires /sbin/ldconfig libicu-devel-3.8.1-7.fc9.i386 requires /bin/sh libid3tag-0.15.1b-6.fc10.i386 requires /sbin/ldconfig libident-0.32-2.fc9.i386 requires /sbin/ldconfig libident-tools-0.32-2.fc9.i386 requires /bin/sh libidn-0.6.14-7.i386 requires /bin/sh libidn-0.6.14-7.i386 requires /sbin/ldconfig libidn-0.6.14-7.i386 requires /sbin/install-info libiec61883-1.1.0-4.fc9.i386 requires /sbin/ldconfig libieee1284-0.2.11-3.fc9.i386 requires /sbin/ldconfig libifp-1.0.0.2-7.fc9.i386 requires /sbin/ldconfig libifp-1.0.0.2-7.fc9.i386 requires /bin/bash libipoddevice-0.5.3-4.fc9.i386 requires /sbin/ldconfig libiptcdata-1.0.2-2.fc9.i386 requires /sbin/ldconfig libisofs-0.2.8-3.fc9.i386 requires /sbin/ldconfig libitl-0.6.4-4.fc9.i386 requires /sbin/ldconfig libjingle-0.3.11-8.fc9.i386 requires /sbin/ldconfig libjpeg-6b-41.fc9.i386 requires /sbin/ldconfig libkdcraw-0.1.4-1.fc10.i386 requires /bin/sh libkexif-0.2.5-4.fc9.i386 requires /sbin/ldconfig libkexiv2-0.1.7-1.fc10.i386 requires /sbin/ldconfig libkipi-0.1.6-1.fc10.i386 requires /bin/sh libksba-1.0.3-2.fc9.i386 requires /sbin/ldconfig libksba-devel-1.0.3-2.fc9.i386 requires /sbin/install-info libksba-devel-1.0.3-2.fc9.i386 requires /bin/sh libksba-devel-1.0.3-2.fc9.i386 requires /bin/sh liblo-0.24-2.fc9.i386 requires /sbin/ldconfig liblqr-1-0.1.0-5.fc9.i386 requires /sbin/ldconfig liblrdf-0.4.0-13.fc9.i386 requires /sbin/ldconfig libmal-0.31-8.fc9.i386 requires /sbin/ldconfig libmalaga-7.12-1.fc9.i386 requires /sbin/ldconfig libmatchbox-1.9-3.fc9.i386 requires /sbin/ldconfig libmatheval-1.1.5-2.fc9.i386 requires /sbin/ldconfig libmatheval-devel-1.1.5-2.fc9.i386 requires /bin/sh libmatheval-devel-1.1.5-2.fc9.i386 requires /sbin/install-info libmatroska-0.8.1-3.fc9.i386 requires /sbin/ldconfig libmcrypt-2.5.8-5.fc9.i386 requires /sbin/ldconfig libmcrypt-devel-2.5.8-5.fc9.i386 requires /bin/sh libmikmod-3.2.0-3.beta2.fc9.i386 requires /sbin/ldconfig libmikmod-devel-3.2.0-3.beta2.fc9.i386 requires /bin/sh libmikmod-devel-3.2.0-3.beta2.fc9.i386 requires /bin/sh libmng-1.0.9-6.1.i386 requires /sbin/ldconfig libmodelfile-0.1.92-5.fc9.i386 requires /sbin/ldconfig 1:libmodplug-0.8.4-3.fc9.i386 requires /sbin/ldconfig libmowgli-0.5.0-2.fc9.i386 requires /sbin/ldconfig libmp4v2-1.5.0.1-6.fc9.i386 requires /sbin/ldconfig libmpcdec-1.2.6-4.fc9.i386 requires /sbin/ldconfig libmpd-0.15.0-3.fc9.i386 requires /sbin/ldconfig libmspack-0.0-0.5.20060920alpha.fc9.i386 requires /sbin/ldconfig libmtp-0.2.6.1-1.fc9.i386 requires /sbin/ldconfig libmudflap-4.3.0-8.i386 requires /sbin/ldconfig libmusicbrainz-2.1.5-6.fc9.i386 requires /sbin/ldconfig libnasl-2.2.10-5.fc9.i386 requires /sbin/ldconfig libnasl-devel-2.2.10-5.fc9.i386 requires /bin/sh libnc-dap-3.7.0-9.fc9.i386 requires /sbin/ldconfig libnc-dap-devel-3.7.0-9.fc9.i386 requires /bin/sh libnemesi-0.6.4-0.3.rc2.fc9.i386 requires /sbin/ldconfig libnet-devel-1.1.2.1-12.fc9.i386 requires /bin/sh libnet10-1.0.2a-14.fc9.i386 requires /bin/sh libnetfilter_conntrack-0.0.89-0.1.svn7356.fc9.i386 requires /sbin/ldconfig libnetfilter_log-0.0.13-6.fc9.i386 requires /sbin/ldconfig libnetfilter_queue-0.0.15-4.fc9.i386 requires /sbin/ldconfig libnfnetlink-0.0.33-0.1.svn7211.fc9.i386 requires /sbin/ldconfig libnids-1.22-4.fc9.i386 requires /sbin/ldconfig libnjb-2.2.6-3.fc9.i386 requires /sbin/ldconfig libnl-1.1-3.fc9.i386 requires /sbin/ldconfig libnotify-0.4.4-10.fc9.i386 requires /bin/sh libnova-0.12.1-3.fc10.i386 requires /sbin/ldconfig libnss-mysql-1.5-7.fc9.i386 requires /sbin/ldconfig libntlm-0.4.2-1.fc9.i386 requires /sbin/ldconfig libobjc-4.3.0-8.i386 requires /sbin/ldconfig libofa-0.9.3-13.fc9.i386 requires /sbin/ldconfig libofx-0.8.3-5.i386 requires /sbin/ldconfig 2:libogg-1.1.3-9.fc9.i386 requires /sbin/ldconfig liboggz-0.9.5-2.fc9.i386 requires /sbin/ldconfig liboggz-0.9.5-2.fc9.i386 requires /bin/sh liboil-0.3.14-1.fc9.i386 requires /sbin/ldconfig libopendaap-0.4.0-5.fc9.i386 requires /sbin/ldconfig libopenraw-0.0.5-1.fc9.i386 requires /sbin/ldconfig libopenraw-gnome-0.0.5-1.fc9.i386 requires /sbin/ldconfig libopensync-0.36-2.fc9.i386 requires /sbin/ldconfig libopensync-plugin-google-calendar-0.35-2.fc9.i386 requires /usr/bin/env libopensync-plugin-kdepim-0.35-2.fc9.i386 requires /sbin/ldconfig libopm-0.1-7.20050731cvs.fc9.i386 requires /sbin/ldconfig liborigin-20071119-3.fc10.i386 requires /sbin/ldconfig libosip2-3.1.0-1.fc9.i386 requires /sbin/ldconfig libotf-0.9.7-4.fc10.i386 requires /sbin/ldconfig libotf-devel-0.9.7-4.fc10.i386 requires /bin/sh libotr-3.1.0-2.fc9.i386 requires /sbin/ldconfig libp11-0.2.3-2.fc9.i386 requires /sbin/ldconfig libpanelappletmm-2.22.0-1.fc9.i386 requires /sbin/ldconfig libpano12-2.8.6-2.fc9.i386 requires /sbin/ldconfig libpano13-2.9.12-5.fc9.i386 requires /sbin/ldconfig libpaper-1.1.23-2.fc9.i386 requires /sbin/ldconfig libpaper-1.1.23-2.fc9.i386 requires /bin/bash libpar2-0.2-5.fc9.i386 requires /sbin/ldconfig 14:libpcap-0.9.8-2.fc9.i386 requires /sbin/ldconfig libpciaccess-0.10-2.fc9.i386 requires /sbin/ldconfig libpfm-3.4-1.fc10.i386 requires /sbin/ldconfig 2:libpng-1.2.24-1.fc9.i386 requires /sbin/ldconfig 2:libpng-devel-1.2.24-1.fc9.i386 requires /bin/sh libpng10-1.0.37-1.fc10.i386 requires /sbin/ldconfig libpolyxmass-0.9.1-2.fc9.i386 requires /sbin/ldconfig libpqxx-2.6.8-10.fc9.i386 requires /sbin/ldconfig libpqxx-devel-2.6.8-10.fc9.i386 requires /bin/sh libprelude-0.9.17.1-1.fc10.i386 requires /sbin/ldconfig libprelude-0.9.17.1-1.fc10.i386 requires /bin/sh libprelude-devel-0.9.17.1-1.fc10.i386 requires /bin/sh libpreludedb-0.9.14.1-2.fc9.i386 requires /sbin/ldconfig libpreludedb-devel-0.9.14.1-2.fc9.i386 requires /bin/sh libpri-1.4.3-2.fc9.i386 requires /sbin/ldconfig libpurple-2.4.1-3.fc10.i386 requires /usr/bin/env libpurple-2.4.1-3.fc10.i386 requires /sbin/ldconfig libpurple-2.4.1-3.fc10.i386 requires /bin/sh libqalculate-0.9.6-4.fc9.i386 requires /sbin/ldconfig librapi-0.11-2.fc9.i386 requires /sbin/ldconfig librapi-0.11-2.fc9.i386 requires /bin/bash libraw1394-1.3.0-6.fc9.i386 requires /sbin/ldconfig librdmacm-1.0.7-1.fc9.i386 requires /sbin/ldconfig librdmacm-devel-1.0.7-1.fc9.i386 requires /usr/include/infiniband/verbs.h libreadline-java-0.8.0-20.fc9.i386 requires /bin/sh librelp-0.1.1-2.fc10.i386 requires /bin/sh librelp-0.1.1-2.fc10.i386 requires /sbin/ldconfig librfid-0.2.0-1.fc9.i386 requires /sbin/ldconfig librra-0.11-2.fc9.i386 requires /sbin/ldconfig librsvg2-2.22.2-1.fc9.i386 requires /usr/bin/env librsvg2-2.22.2-1.fc9.i386 requires /bin/sh librsync-0.9.7-12.fc9.i386 requires /sbin/ldconfig librtfcomp-1.1-3.fc9.i386 requires /sbin/ldconfig librx-1.5-10.fc9.i386 requires /sbin/ldconfig librx-devel-1.5-10.fc9.i386 requires /bin/sh libsamplerate-0.1.3-1.fc10.i386 requires /sbin/ldconfig libsane-hpaio-2.8.2-3.fc10.i386 requires /bin/sh libscigraphica-2.1.1-8.fc9.i386 requires /sbin/ldconfig libselinux-2.0.64-2.fc10.i386 requires /bin/sh libselinux-2.0.64-2.fc10.i386 requires /sbin/ldconfig libsemanage-2.0.25-1.fc10.i386 requires /sbin/ldconfig libsepol-2.0.26-1.fc9.i386 requires /bin/sh libsepol-2.0.26-1.fc9.i386 requires /sbin/ldconfig libsexy-0.1.11-8.fc10.i386 requires /sbin/ldconfig libsexymm-0.1.9-5.fc9.i386 requires /sbin/ldconfig libshout-2.2.2-3.fc9.i386 requires /sbin/ldconfig libsidplay-1.36.57-17.i386 requires /sbin/ldconfig libsieve-2.2.6-3.fc9.i386 requires /sbin/ldconfig libsigc++-1.2.7-6.fc9.i386 requires /sbin/ldconfig libsigc++20-2.2.2-1.fc9.i386 requires /bin/sh libsigc++20-2.2.2-1.fc9.i386 requires /sbin/ldconfig libsigsegv-2.4-6.fc9.i386 requires /sbin/ldconfig libsilc-1.1.7-1.fc9.i386 requires /sbin/ldconfig libsmbclient-3.2.0-1.pre3.10.fc10.i386 requires /bin/sh libsmbios-2.0.1-2.fc10.1.i386 requires /sbin/ldconfig libsmi-0.4.8-1.fc10.i386 requires /sbin/ldconfig libsmi-0.4.8-1.fc10.i386 requires /bin/sh libsndfile-1.0.17-3.fc9.i386 requires /sbin/ldconfig libsoup-2.23.1-1.fc10.i386 requires /sbin/ldconfig libsoup22-2.2.105-2.fc9.i386 requires /sbin/ldconfig libspectre-0.2.0-2.fc9.i386 requires /sbin/ldconfig libspectrum-0.4.0-2.fc9.i386 requires /sbin/ldconfig libssh2-0.18-7.fc9.i386 requires /sbin/ldconfig libstatgrab-0.16-1.fc9.i386 requires /sbin/ldconfig libstdc++-4.3.0-8.i386 requires /sbin/ldconfig libstdc++-devel-4.3.0-8.i386 requires /usr/lib/libstdc++.so.6 libstroke-0.5.1-17.fc9.i386 requires /sbin/ldconfig libsvm-2.86-13.fc10.i386 requires /sbin/ldconfig libsvm-python-2.86-13.fc10.i386 requires /usr/bin/env libsvm-svm-toy-gtk-2.86-13.fc10.i386 requires /bin/sh 1:libswt3-gtk2-3.3.2-11.fc9.i386 requires /usr/bin/rebuild-gcj-db libsx-2.05-15.fc9.i386 requires /sbin/ldconfig libsynce-0.11-3.fc9.i386 requires /sbin/ldconfig libsyncml-0.4.5-2.fc9.i386 requires /sbin/ldconfig libsysfs-2.1.0-3.fc9.i386 requires /sbin/ldconfig libtalloc-1.2.0-10.fc10.i386 requires /bin/sh libtar-1.2.11-11.fc10.i386 requires /sbin/ldconfig libtasn1-1.3-1.fc9.i386 requires /sbin/ldconfig libtasn1-devel-1.3-1.fc9.i386 requires /bin/sh libtasn1-devel-1.3-1.fc9.i386 requires /bin/bash libtasn1-devel-1.3-1.fc9.i386 requires /sbin/install-info libtcd-2.2.3-1.fc9.2.i386 requires /sbin/ldconfig libtdb-1.1.1-10.fc10.i386 requires /bin/sh libtelepathy-0.3.3-1.fc9.i386 requires /sbin/ldconfig libtextcat-2.2-5.fc9.i386 requires /sbin/ldconfig libthai-0.1.9-4.fc9.i386 requires /sbin/ldconfig libtheora-1.0beta3-2.fc10.i386 requires /sbin/ldconfig libtidy-0.99.0-17.20070615.fc9.i386 requires /sbin/ldconfig libtiff-3.8.2-10.fc9.i386 requires /sbin/ldconfig libtimidity-0.1.0-6.fc9.i386 requires /sbin/ldconfig libtirpc-0.1.7-18.fc9.i386 requires /sbin/ldconfig libtirpc-devel-0.1.7-18.fc9.i386 requires /bin/sh libtlen-0-0.7.20060309.fc9.i386 requires /sbin/ldconfig libtomcrypt-1.17-9.fc9.i386 requires /sbin/ldconfig libtommath-0.41-8.fc9.i386 requires /sbin/ldconfig libtomoe-gtk-0.6.0-3.fc9.i386 requires /sbin/ldconfig libtomoe-gtk-devel-0.6.0-3.fc9.i386 requires /sbin/ldconfig libtool-1.5.24-6.fc9.i386 requires /bin/sh libtool-1.5.24-6.fc9.i386 requires /sbin/install-info libtool-1.5.24-6.fc9.i386 requires /bin/sh libtool-ltdl-1.5.24-6.fc9.i386 requires /sbin/ldconfig libtorque-2.1.10-5.fc9.i386 requires /sbin/ldconfig libtorque-devel-2.1.10-5.fc9.i386 requires /bin/sh libtorrent-0.11.8-4.fc9.i386 requires /sbin/ldconfig libtranslate-0.99-14.fc9.i386 requires /sbin/ldconfig libtunepimp-0.5.3-11.fc9.i386 requires /sbin/ldconfig libtwin-0.0.2-8.fc10.i386 requires /sbin/ldconfig libuninameslist-0.0-8.20060907.i386 requires /sbin/ldconfig libunwind-0.99-0.5.frysk20070405cvs.fc9.i386 requires /sbin/ldconfig libupnp-1.6.6-1.fc10.i386 requires /sbin/ldconfig libusb-0.1.12-15.fc9.i386 requires /sbin/ldconfig libusb-devel-0.1.12-15.fc9.i386 requires /bin/sh libuser-0.56.9-1.i386 requires /sbin/ldconfig libutempter-1.1.5-2.fc9.i386 requires /bin/sh libutempter-1.1.5-2.fc9.i386 requires /sbin/ldconfig libvirt-0.4.2-5.fc10.i386 requires /bin/sh libvirt-0.4.2-5.fc10.i386 requires /usr/sbin/lokkit libvirt-0.4.2-5.fc10.i386 requires /bin/sh libvirt-0.4.2-5.fc10.i386 requires /usr/bin/qemu-img libvirt-cim-0.3-4.fc9.i386 requires /bin/sh libvirt-cim-0.3-4.fc9.i386 requires /sbin/ldconfig libvirt-cim-0.3-4.fc9.i386 requires /bin/bash libvirt-cim-0.3-4.fc9.i386 requires /bin/sh libvirt-devel-0.4.2-5.fc10.i386 requires /usr/bin/python libvirt-python-0.4.2-5.fc10.i386 requires /usr/bin/python libvisual-0.4.0-6.fc9.i386 requires /sbin/ldconfig libvncserver-0.9.1-3.fc10.i386 requires /sbin/ldconfig libvncserver-devel-0.9.1-3.fc10.i386 requires /bin/sh libvoikko-1.7-0.1.rc2.fc10.i386 requires /sbin/ldconfig libvolume_id-121-1.20080516git.fc10.i386 requires /sbin/ldconfig 1:libvorbis-1.2.0-4.fc10.i386 requires /sbin/ldconfig libvpd-2.0.1-1.fc9.i386 requires /sbin/ldconfig libvte-java-0.12.1-11.fc9.i386 requires /sbin/ldconfig libwcs-3.7.0-2.fc9.i386 requires /sbin/ldconfig libwiimote-0.4-6.fc9.i386 requires /sbin/ldconfig libwmf-0.2.8.4-18.fc9.i386 requires /usr/bin/update-gdk-pixbuf-loaders libwmf-0.2.8.4-18.fc9.i386 requires /bin/sh libwmf-0.2.8.4-18.fc9.i386 requires /bin/sh libwmf-devel-0.2.8.4-18.fc9.i386 requires /bin/sh libwmf-lite-0.2.8.4-18.fc9.i386 requires /sbin/ldconfig libwnck-2.22.1-1.fc9.i386 requires /sbin/ldconfig libwpd-0.8.14-1.fc9.i386 requires /sbin/ldconfig libwvstreams-4.4.1-4.fc9.i386 requires /sbin/ldconfig libxcb-1.1-4.fc9.i386 requires /sbin/ldconfig libxfce4mcs-4.4.2-2.fc9.i386 requires /sbin/ldconfig libxfce4util-4.4.2-2.fc9.i386 requires /sbin/ldconfig libxfcegui4-4.4.2-2.fc9.i386 requires /bin/sh libxkbfile-1.0.4-5.fc9.i386 requires /sbin/ldconfig libxklavier-3.6-1.fc10.i386 requires /sbin/ldconfig 1:libxml-1.8.17-19.fc9.i386 requires /sbin/ldconfig libxml++-2.22.0-1.fc9.i386 requires /sbin/ldconfig libxml++-devel-2.22.0-1.fc9.i386 requires /bin/sh 1:libxml-devel-1.8.17-19.fc9.i386 requires /bin/sh libxml2-2.6.32-2.fc10.i386 requires /bin/sh libxml2-devel-2.6.32-2.fc10.i386 requires /bin/sh libxml2-devel-2.6.32-2.fc10.i386 requires /usr/bin/python libxml2-python-2.6.32-2.fc10.i386 requires /usr/bin/python libxslt-1.1.24-1.fc10.i386 requires /bin/sh libxslt-devel-1.1.24-1.fc10.i386 requires /bin/sh libxslt-python-1.1.24-1.fc10.i386 requires /usr/bin/python libyaz-3.0.26-1.fc10.i386 requires /sbin/ldconfig libyaz-devel-3.0.26-1.fc10.i386 requires /usr/bin/tclsh libyaz-devel-3.0.26-1.fc10.i386 requires /bin/sh libytnef-1.5-3.fc9.i386 requires /sbin/ldconfig libzip-0.8-5.fc9.i386 requires /sbin/ldconfig libzzub-0.2.3-12.fc9.i386 requires /sbin/ldconfig licq-1.3.5-2.fc10.i386 requires /usr/bin/perl licq-1.3.5-2.fc10.i386 requires /bin/sh licq-auto-reply-1.3.5-2.fc10.i386 requires /bin/bash liferea-1.4.13-3.fc9.i386 requires /bin/sh liferea-1.4.13-3.fc9.i386 requires /bin/sh lightning-1.2-13.fc9.i386 requires /bin/sh lightning-1.2-13.fc9.i386 requires /bin/sh lightning-1.2-13.fc9.i386 requires /sbin/install-info lighttpd-1.4.19-4.fc10.i386 requires /bin/sh lighttpd-1.4.19-4.fc10.i386 requires /usr/sbin/useradd lighttpd-1.4.19-4.fc10.i386 requires /sbin/service lighttpd-1.4.19-4.fc10.i386 requires /bin/sh lighttpd-1.4.19-4.fc10.i386 requires /sbin/chkconfig lilypond-2.10.33-1.fc8.i386 requires /sbin/install-info lilypond-2.10.33-1.fc8.i386 requires /usr/bin/python lilypond-2.10.33-1.fc8.i386 requires /usr/bin/guile lilypond-2.10.33-1.fc8.i386 requires /bin/sh lineakd-0.9-5.fc6.i386 requires /bin/sh lineakd-0.9-5.fc6.i386 requires /sbin/ldconfig link-grammar-4.2.5-2.fc9.i386 requires /sbin/ldconfig linkage-0.1.4-6.fc9.i386 requires /bin/sh linkchecker-4.7-11.fc9.i386 requires /usr/bin/python linphone-2.1.1-1.fc9.i386 requires /sbin/ldconfig linux-atm-2.5.0-5.i386 requires /usr/bin/perl linux-atm-2.5.0-5.i386 requires /bin/sh linux-atm-libs-2.5.0-5.i386 requires /sbin/ldconfig linux-igd-1.0-5.fc9.i386 requires /bin/sh linux-igd-1.0-5.fc9.i386 requires /bin/bash linux-igd-1.0-5.fc9.i386 requires /sbin/chkconfig linux-igd-1.0-5.fc9.i386 requires /sbin/service linux-libertine-fonts-2.7.9-1.fc9.noarch requires /bin/sh linuxdoc-tools-0.9.21-16.fc9.i386 requires /bin/sh linuxdoc-tools-0.9.21-16.fc9.i386 requires /usr/bin/perl linuxwacom-0.7.9.8-7.fc10.i386 requires /sbin/ldconfig liquidwar-5.6.4-4.fc9.i386 requires /bin/sh liquidwar-5.6.4-4.fc9.i386 requires /sbin/install-info liquidwar-server-5.6.4-4.fc9.i386 requires /bin/sh liquidwar-server-5.6.4-4.fc9.i386 requires /sbin/chkconfig liquidwar-server-5.6.4-4.fc9.i386 requires /usr/sbin/useradd liquidwar-server-5.6.4-4.fc9.i386 requires /bin/sh liquidwar-server-5.6.4-4.fc9.i386 requires /sbin/service lirc-0.8.3-1.fc10.i386 requires /bin/sh lirc-0.8.3-1.fc10.i386 requires /sbin/ldconfig lirc-0.8.3-1.fc10.i386 requires /bin/sh lirc-0.8.3-1.fc10.i386 requires /sbin/chkconfig lirc-libs-0.8.3-1.fc10.i386 requires /sbin/ldconfig listen-0.5-18.fc9.i386 requires /usr/bin/puid listen-0.5-18.fc9.i386 requires /usr/bin/env listen-0.5-18.fc9.i386 requires /sbin/ldconfig listen-0.5-18.fc9.i386 requires /bin/sh livecd-tools-017-1.fc9.i386 requires /bin/bash livecd-tools-017-1.fc9.i386 requires /usr/bin/python lklug-fonts-0.2.2-5.fc8.noarch requires /bin/sh lksctp-tools-1.0.7-3.fc9.i386 requires /sbin/ldconfig lksctp-tools-1.0.7-3.fc9.i386 requires /bin/sh llvm-2.2-3.fc9.i386 requires /sbin/ldconfig llvm-devel-2.2-3.fc9.i386 requires /usr/bin/perl lm_sensors-3.0.1-5.fc9.i386 requires /bin/sh lm_sensors-3.0.1-5.fc9.i386 requires /sbin/ldconfig lm_sensors-3.0.1-5.fc9.i386 requires /bin/bash lm_sensors-3.0.1-5.fc9.i386 requires /usr/sbin/dmidecode lm_sensors-3.0.1-5.fc9.i386 requires /bin/sh lm_sensors-3.0.1-5.fc9.i386 requires /usr/bin/perl lm_sensors-sensord-3.0.1-5.fc9.i386 requires /bin/sh lm_sensors-sensord-3.0.1-5.fc9.i386 requires /bin/sh lmarbles-1.0.7-9.i386 requires /bin/sh lock-keys-applet-1.0-14.fc9.i386 requires /bin/sh lockdev-1.0.1-12.fc9.1.i386 requires /bin/sh lockdev-1.0.1-12.fc9.1.i386 requires /sbin/ldconfig log4j-1.2.14-4jpp.1.fc9.i386 requires /bin/sh log4j-1.2.14-4jpp.1.fc9.i386 requires /bin/sh log4j-javadoc-1.2.14-4jpp.1.fc9.i386 requires /bin/sh log4j-javadoc-1.2.14-4jpp.1.fc9.i386 requires /bin/rm log4j-javadoc-1.2.14-4jpp.1.fc9.i386 requires /bin/ln logrotate-3.7.6-4.fc10.i386 requires /bin/sh logwatch-7.3.6-22.fc10.noarch requires /usr/bin/perl lohit-fonts-bengali-2.2.1-2.fc9.noarch requires /bin/sh lohit-fonts-gujarati-2.2.1-2.fc9.noarch requires /bin/sh lohit-fonts-hindi-2.2.1-2.fc9.noarch requires /bin/sh lohit-fonts-kannada-2.2.1-2.fc9.noarch requires /bin/sh lohit-fonts-malayalam-2.2.1-2.fc9.noarch requires /bin/sh lohit-fonts-oriya-2.2.1-2.fc9.noarch requires /bin/sh lohit-fonts-punjabi-2.2.1-2.fc9.noarch requires /bin/sh lohit-fonts-tamil-2.2.1-2.fc9.noarch requires /bin/sh lohit-fonts-telugu-2.2.1-2.fc9.noarch requires /bin/sh loki-lib-0.1.6-6.fc9.i386 requires /sbin/ldconfig londonlaw-0.2.1-3.fc9.noarch requires /bin/sh londonlaw-0.2.1-3.fc9.noarch requires /usr/bin/python loudmouth-1.3.4-1.fc9.i386 requires /sbin/ldconfig lpsolve-5.5.0.12-1.fc9.i386 requires /sbin/ldconfig lrmi-0.10-4.fc9.i386 requires /sbin/ldconfig lsvpd-1.6.3-1.fc9.i386 requires /usr/sbin/vpdupdate ltsp-client-5.1.7-2.fc9.i386 requires /bin/bash ltsp-client-5.1.7-2.fc9.i386 requires /bin/sh ltsp-server-5.1.7-2.fc9.i386 requires /bin/sh ltsp-server-5.1.7-2.fc9.i386 requires /usr/bin/perl ltsp-server-5.1.7-2.fc9.i386 requires /bin/bash ltsp-server-5.1.7-2.fc9.i386 requires /bin/sh ltsp-server-5.1.7-2.fc9.i386 requires /usr/bin/python ltsp-utils-0.25-4.fc6.noarch requires /usr/bin/perl ltsp-vmclient-5.1.7-2.fc9.i386 requires /bin/sh ltspfs-0.5.2-1.fc9.i386 requires /usr/bin/python ltspfsd-0.5.2-1.fc9.i386 requires /bin/sh luadoc-3.0.1-1.fc8.noarch requires /usr/bin/env lucene-2.3.1-2jpp.0.fc10.i386 requires /bin/sh lucene-javadoc-2.3.1-2jpp.0.fc10.i386 requires /bin/sh luma-2.4-3.fc9.noarch requires /usr/bin/env lvm2-2.02.33-11.fc9.i386 requires /bin/bash lvm2-2.02.33-11.fc9.i386 requires /bin/sh lvm2-cluster-2.02.33-11.fc9.i386 requires /bin/sh lvm2-cluster-2.02.33-11.fc9.i386 requires /bin/bash lvm2-cluster-2.02.33-11.fc9.i386 requires /bin/sh lwp-2.4-1.fc10.i386 requires /sbin/ldconfig lxappearance-0.2-1.fc10.i386 requires /bin/sh lybniz-1.3.2-1.fc9.noarch requires /bin/sh lybniz-1.3.2-1.fc9.noarch requires /usr/bin/python lynx-2.8.6-13.fc9.i386 requires /bin/sh lyx-1.5.5-1.fc10.i386 requires /bin/sh lyx-1.5.5-1.fc10.i386 requires /usr/bin/env lyx-1.5.5-1.fc10.i386 requires /usr/bin/python lyx-1.5.5-1.fc10.i386 requires /usr/bin/texhash lyx-1.5.5-1.fc10.i386 requires /bin/sh lzma-4.32.5-1.fc9.i386 requires /bin/sh lzma-libs-4.32.5-1.fc9.i386 requires /sbin/ldconfig lzo-2.03-1.fc10.i386 requires /sbin/ldconfig lzo-minilzo-2.03-1.fc10.i386 requires /sbin/ldconfig m17n-contrib-1.1.6-3.fc9.noarch requires /usr/bin/gawk m17n-db-1.5.1-3.fc9.noarch requires /bin/sh m17n-lib-1.5.1-1.fc9.i386 requires /sbin/ldconfig m2crypto-0.18.2-4.i386 requires /usr/bin/env m4-1.4.11-1.fc10.i386 requires /bin/sh m4-1.4.11-1.fc10.i386 requires /sbin/install-info mISDN-1.1.5-2.fc9.i386 requires /bin/sh mISDN-1.1.5-2.fc9.i386 requires /sbin/ldconfig macchanger-1.5.0-4.fc9.i386 requires /bin/sh macchanger-1.5.0-4.fc9.i386 requires /sbin/install-info mach-0.9.2-4.fc9.i386 requires /bin/sh mach-0.9.2-4.fc9.i386 requires /usr/bin/python machineball-1.0-5.fc9.i386 requires /bin/sh madan-fonts-1.0-6.fc8.noarch requires /bin/sh magic-7.5.116-1.fc9.i386 requires /bin/sh magic-7.5.116-1.fc9.i386 requires /usr/bin/tclsh magic-7.5.116-1.fc9.i386 requires /bin/awk magic-7.5.116-1.fc9.i386 requires /usr/bin/wish magic-7.5.116-1.fc9.i386 requires /bin/sh magicmaze-1.0.2-1.fc9.i386 requires /bin/sh magicor-1.1-0.1.rc1.fc9.noarch requires /bin/sh magicor-1.1-0.1.rc1.fc9.noarch requires /usr/bin/python mail-notification-5.3-1.fc9.i386 requires /bin/sh maildrop-2.0.4-6.fc9.i386 requires /bin/sh mailgraph-1.14-2.fc9.noarch requires /bin/sh mailgraph-1.14-2.fc9.noarch requires /bin/bash mailgraph-1.14-2.fc9.noarch requires /usr/bin/perl mailgraph-selinux-1.14-2.fc9.noarch requires /usr/sbin/semodule mailgraph-selinux-1.14-2.fc9.noarch requires /sbin/fixfiles mailgraph-selinux-1.14-2.fc9.noarch requires /bin/sh mailgraph-selinux-1.14-2.fc9.noarch requires /sbin/restorecon 3:mailman-2.1.10-1.fc10.i386 requires /bin/sh 3:mailman-2.1.10-1.fc10.i386 requires /usr/bin/env 3:mailman-2.1.10-1.fc10.i386 requires /usr/bin/python 3:mailman-2.1.10-1.fc10.i386 requires /sbin/service 3:mailman-2.1.10-1.fc10.i386 requires /bin/sh 3:mailman-2.1.10-1.fc10.i386 requires /sbin/chkconfig 1:make-3.81-12.fc9.i386 requires /bin/sh 1:make-3.81-12.fc9.i386 requires /sbin/install-info malaga-7.12-1.fc9.i386 requires /sbin/install-info malaga-7.12-1.fc9.i386 requires /bin/sh man-1.6f-6.fc10.i386 requires /bin/sh man-1.6f-6.fc10.i386 requires /bin/bash man-1.6f-6.fc10.i386 requires /bin/sh manaworld-0.0.24-1.fc9.i386 requires /bin/sh manedit-0.8.1-3.fc9.i386 requires /bin/sh manedit-0.8.1-3.fc9.i386 requires /bin/sh maniadrive-1.2-8.fc9.i386 requires /bin/sh mantis-1.1.1-1.fc9.noarch requires /usr/bin/php mantis-config-httpd-1.1.1-1.fc9.noarch requires /bin/sh mantis-config-httpd-1.1.1-1.fc9.noarch requires /etc/httpd/conf.d mapserver-python-5.0.2-2.fc9.i386 requires /bin/sh maradns-1.3.07.08-1.fc9.i386 requires /bin/sh maradns-1.3.07.08-1.fc9.i386 requires /bin/bash maradns-1.3.07.08-1.fc9.i386 requires /sbin/chkconfig maradns-1.3.07.08-1.fc9.i386 requires /sbin/service mash-0.3.6-1.fc9.noarch requires /usr/bin/python2 mash-0.3.6-1.fc9.noarch requires /usr/bin/python mathml-fonts-1.0-21.fc6.noarch requires /bin/sh mathml-fonts-1.0-21.fc6.noarch requires /bin/bash mathml-fonts-1.0-21.fc6.noarch requires /bin/sh maven-doxia-1.0-0.2.a7.2jpp.6.fc9.i386 requires /bin/sh maven-jxr-1.0-2jpp.5.fc9.i386 requires /bin/sh maven-scm-1.0-0.2.b3.1jpp.3.fc9.i386 requires /bin/sh maven-scm-javadoc-1.0-0.2.b3.1jpp.3.fc9.i386 requires /bin/rm maven-scm-javadoc-1.0-0.2.b3.1jpp.3.fc9.i386 requires /bin/ls maven-scm-test-1.0-0.2.b3.1jpp.3.fc9.i386 requires /bin/sh maven-shared-1.0-4jpp.4.fc9.i386 requires /bin/sh maven-shared-file-management-1.0-4jpp.4.fc9.i386 requires /bin/sh maven-shared-plugin-testing-harness-1.0-4jpp.4.fc9.i386 requires /bin/sh maven-surefire-1.5.3-2jpp.5.fc9.i386 requires /bin/sh maven-surefire-booter-1.5.3-2jpp.5.fc9.i386 requires /bin/sh maven-surefire-booter-javadoc-1.5.3-2jpp.5.fc9.i386 requires /bin/rm maven-surefire-booter-javadoc-1.5.3-2jpp.5.fc9.i386 requires /bin/ln maven-surefire-javadoc-1.5.3-2jpp.5.fc9.i386 requires /bin/rm maven-surefire-javadoc-1.5.3-2jpp.5.fc9.i386 requires /bin/ln maven2-2.0.4-10jpp.10.fc9.i386 requires /bin/sh maven2-2.0.4-10jpp.10.fc9.i386 requires /bin/rmdir maven2-2.0.4-10jpp.10.fc9.i386 requires /bin/sh maven2-plugin-ant-2.0.4-10jpp.10.fc9.i386 requires /bin/sh maven2-plugin-antlr-2.0.4-10jpp.10.fc9.i386 requires /bin/sh maven2-plugin-antrun-2.0.4-10jpp.10.fc9.i386 requires /bin/sh maven2-plugin-assembly-2.0.4-10jpp.10.fc9.i386 requires /bin/sh maven2-plugin-checkstyle-2.0.4-10jpp.10.fc9.i386 requires /bin/sh maven2-plugin-clean-2.0.4-10jpp.10.fc9.i386 requires /bin/sh maven2-plugin-compiler-2.0.4-10jpp.10.fc9.i386 requires /bin/sh maven2-plugin-dependency-2.0.4-10jpp.10.fc9.i386 requires /bin/sh maven2-plugin-deploy-2.0.4-10jpp.10.fc9.i386 requires /bin/sh maven2-plugin-ear-2.0.4-10jpp.10.fc9.i386 requires /bin/sh maven2-plugin-eclipse-2.0.4-10jpp.10.fc9.i386 requires /bin/sh maven2-plugin-ejb-2.0.4-10jpp.10.fc9.i386 requires /bin/sh maven2-plugin-help-2.0.4-10jpp.10.fc9.i386 requires /bin/sh maven2-plugin-idea-2.0.4-10jpp.10.fc9.i386 requires /bin/sh maven2-plugin-install-2.0.4-10jpp.10.fc9.i386 requires /bin/sh maven2-plugin-jar-2.0.4-10jpp.10.fc9.i386 requires /bin/sh maven2-plugin-javadoc-2.0.4-10jpp.10.fc9.i386 requires /bin/sh maven2-plugin-jxr-2.0.4-10jpp.10.fc9.i386 requires /bin/sh maven2-plugin-one-2.0.4-10jpp.10.fc9.i386 requires /bin/sh maven2-plugin-plugin-2.0.4-10jpp.10.fc9.i386 requires /bin/sh maven2-plugin-pmd-2.0.4-10jpp.10.fc9.i386 requires /bin/sh maven2-plugin-project-info-reports-2.0.4-10jpp.10.fc9.i386 requires /bin/sh maven2-plugin-rar-2.0.4-10jpp.10.fc9.i386 requires /bin/sh maven2-plugin-release-2.0.4-10jpp.10.fc9.i386 requires /bin/sh maven2-plugin-repository-2.0.4-10jpp.10.fc9.i386 requires /bin/sh maven2-plugin-resources-2.0.4-10jpp.10.fc9.i386 requires /bin/sh maven2-plugin-site-2.0.4-10jpp.10.fc9.i386 requires /bin/sh maven2-plugin-source-2.0.4-10jpp.10.fc9.i386 requires /bin/sh maven2-plugin-surefire-2.0.4-10jpp.10.fc9.i386 requires /bin/sh maven2-plugin-surefire-report-2.0.4-10jpp.10.fc9.i386 requires /bin/sh maven2-plugin-verifier-2.0.4-10jpp.10.fc9.i386 requires /bin/sh maxima-5.14.0-4.fc9.i386 requires /bin/sh maxima-5.14.0-4.fc9.i386 requires /bin/bash maxima-5.14.0-4.fc9.i386 requires /sbin/install-info maxima-5.14.0-4.fc9.i386 requires /bin/sh maxima-gui-5.14.0-4.fc9.i386 requires /bin/sh maxima-gui-5.14.0-4.fc9.i386 requires /bin/sh mboxgrep-0.7.9-5.fc9.i386 requires /bin/sh mboxgrep-0.7.9-5.fc9.i386 requires /sbin/install-info 1:mc-4.6.2-3.pre1.fc9.i386 requires /usr/bin/perl 1:mc-4.6.2-3.pre1.fc9.i386 requires /bin/sh mcs-libs-0.6.0-4.fc9.i386 requires /sbin/ldconfig mcstrans-0.2.11-1.fc10.i386 requires /bin/sh mcstrans-0.2.11-1.fc10.i386 requires /bin/bash mcstrans-0.2.11-1.fc10.i386 requires /sbin/chkconfig mcstrans-0.2.11-1.fc10.i386 requires /sbin/service mdadm-2.6.4-4.fc9.i386 requires /bin/sh mdadm-2.6.4-4.fc9.i386 requires /bin/bash mdadm-2.6.4-4.fc9.i386 requires /sbin/chkconfig mdadm-2.6.4-4.fc9.i386 requires /sbin/service mdbtools-libs-0.6-0.4.cvs20051109.fc9.i386 requires /sbin/ldconfig mdsplib-0.11-6.fc9.i386 requires /sbin/ldconfig meanwhile-1.0.2-6.fc9.i386 requires /sbin/ldconfig mecab-0.97-1.fc9.i386 requires /sbin/ldconfig mecab-devel-0.97-1.fc9.i386 requires /bin/sh mecab-ipadic-2.7.0.20070801-1.fc8.i386 requires /bin/sh mecab-ipadic-EUCJP-2.7.0.20070801-1.fc8.i386 requires /bin/sh mecab-jumandic-5.1.20070304-1.fc7.1.i386 requires /bin/sh mecab-jumandic-EUCJP-5.1.20070304-1.fc7.1.i386 requires /bin/sh mediatomb-0.11.0-1.fc9.i386 requires /bin/sh mediatomb-0.11.0-1.fc9.i386 requires /sbin/service mediatomb-0.11.0-1.fc9.i386 requires /bin/sh mediatomb-0.11.0-1.fc9.i386 requires /sbin/chkconfig mediawiki-1.10.4-39.fc9.i386 requires /usr/bin/env mediawiki-1.10.4-39.fc9.i386 requires /bin/bash mediawiki-1.10.4-39.fc9.i386 requires /bin/sh mediawiki-1.10.4-39.fc9.i386 requires /usr/bin/perl meld-1.1.5-4.fc9.noarch requires /bin/sh meld-1.1.5-4.fc9.noarch requires /usr/bin/env memcached-1.2.4-4.fc9.i386 requires /bin/sh memcached-1.2.4-4.fc9.i386 requires /sbin/service memcached-1.2.4-4.fc9.i386 requires /usr/bin/perl memcached-1.2.4-4.fc9.i386 requires /bin/sh memcached-1.2.4-4.fc9.i386 requires /sbin/chkconfig memcached-selinux-1.2.4-4.fc9.i386 requires /bin/sh memtest86+-2.01-3.fc9.i386 requires /bin/bash memtest86+-2.01-3.fc9.i386 requires /bin/sh mencal-2.3-1.fc8.noarch requires /usr/bin/perl mercator-0.2.5-4.fc9.i386 requires /sbin/ldconfig mercurial-1.0-4.fc9.i386 requires /usr/bin/env mercurial-1.0-4.fc9.i386 requires /bin/sh mercurial-1.0-4.fc9.i386 requires /usr/bin/python mercurial-hgk-1.0-4.fc9.i386 requires /usr/bin/env mesa-libGL-7.1-0.29.fc9.i386 requires /sbin/ldconfig mesa-libGLU-7.1-0.29.fc9.i386 requires /sbin/ldconfig mesa-libGLw-6.5.1-5.fc9.i386 requires /sbin/ldconfig mesa-libOSMesa-7.1-0.29.fc9.i386 requires /sbin/ldconfig metacafe-dl-2007.10.09-1.fc9.noarch requires /usr/bin/env metacity-2.23.13-1.fc10.i386 requires /bin/sh metacity-2.23.13-1.fc10.i386 requires /sbin/ldconfig metakit-2.4.9.7-5.fc9.i386 requires /sbin/ldconfig metamonitor-0.4.5-5.fc9.i386 requires /bin/sh metapixel-1.0.2-3.fc9.i386 requires /usr/bin/perl methane-1.4.7-4.fc9.i386 requires /bin/sh mew-common-6.0.51-1.fc10.i386 requires /bin/sh mew-common-6.0.51-1.fc10.i386 requires /usr/bin/env mew-common-6.0.51-1.fc10.i386 requires /sbin/install-info mew-common-6.0.51-1.fc10.i386 requires /bin/sh mfiler2-mdnd-4.0.9b-1.fc9.i386 requires /usr/bin/env mftrace-1.2.14-4.fc9.i386 requires /usr/bin/python mgetty-1.1.36-1.fc10.i386 requires /bin/sh mgetty-1.1.36-1.fc10.i386 requires /sbin/install-info mgetty-sendfax-1.1.36-1.fc10.i386 requires /bin/sh mgetty-sendfax-1.1.36-1.fc10.i386 requires /usr/sbin/useradd mgetty-sendfax-1.1.36-1.fc10.i386 requires /usr/bin/perl mgetty-sendfax-1.1.36-1.fc10.i386 requires /bin/sh mgopen-fonts-0.20050515-6.fc9.noarch requires /bin/sh mhash-0.9.9-5.i386 requires /sbin/ldconfig mhgui-0.2-6.fc9.i386 requires /sbin/ldconfig mhonarc-2.6.16-4.fc8.noarch requires /usr/bin/perl miau-0.6.5-2.fc9.i386 requires /bin/sh miau-0.6.5-2.fc9.i386 requires /sbin/install-info 1:microcode_ctl-1.17-1.45.fc9.i386 requires /bin/sh 1:microcode_ctl-1.17-1.45.fc9.i386 requires /bin/bash 1:microcode_ctl-1.17-1.45.fc9.i386 requires /sbin/chkconfig 1:microcode_ctl-1.17-1.45.fc9.i386 requires /bin/sh 1:microcode_ctl-1.17-1.45.fc9.i386 requires /sbin/service migemo-0.40-9.fc7.noarch requires /usr/bin/env migrationtools-47-1.fc9.noarch requires /usr/share/migrationtools/migrate_common.ph migrationtools-47-1.fc9.noarch requires /usr/bin/perl migrationtools-47-1.fc9.noarch requires /bin/sh milter-greylist-4.0-2.fc9.i386 requires /bin/sh milter-greylist-sysv-4.0-2.fc9.i386 requires /sbin/chkconfig milter-greylist-sysv-4.0-2.fc9.i386 requires /bin/sh milter-greylist-sysv-4.0-2.fc9.i386 requires /bin/sh milter-regex-1.7-3.fc9.i386 requires /bin/sh milter-regex-1.7-3.fc9.i386 requires /sbin/chkconfig milter-regex-1.7-3.fc9.i386 requires /bin/sh mimedefang-2.64-1.fc9.i386 requires /bin/sh mimedefang-2.64-1.fc9.i386 requires /sbin/service mimedefang-2.64-1.fc9.i386 requires /bin/bash mimedefang-2.64-1.fc9.i386 requires /bin/sh mimedefang-2.64-1.fc9.i386 requires /usr/bin/perl mimedefang-2.64-1.fc9.i386 requires /sbin/chkconfig mimetex-1.60-4.fc9.i386 requires /var/www/cgi-bin mimetex-1.60-4.fc9.i386 requires /var/www/html mimetic-0.9.3-2.fc8.i386 requires /sbin/ldconfig minbar-0.2.1-6.fc9.i386 requires /bin/sh minicom-2.3-2.fc9.i386 requires /bin/sh minizip-1.2.3-18.fc9.i386 requires /sbin/ldconfig mirage-0.9.3-1.fc9.i386 requires /bin/sh mirage-0.9.3-1.fc9.i386 requires /usr/bin/python mirrormagic-2.0.2-5.fc9.i386 requires /bin/sh mkbootdisk-1.5.3-3.1.i386 requires /bin/bash mkdst-0.8-1.fc9.noarch requires /bin/sh mkinitrd-6.0.52-2.fc9.i386 requires /bin/bash mkinitrd-6.0.52-2.fc9.i386 requires /sbin/insmod.static mkinitrd-6.0.52-2.fc9.i386 requires /bin/sh mkinitrd-6.0.52-2.fc9.i386 requires /sbin/losetup mknbi-1.4.4-14.fc9.i386 requires /usr/bin/perl mksh-33d-1.fc9.i386 requires /bin/sh mkvtoolnix-gui-2.1.0-2.fc9.i386 requires /bin/sh mlmmj-1.2.15-2.fc9.i386 requires /bin/sh mlocate-0.20-1.i386 requires /bin/sh mlocate-0.20-1.i386 requires /bin/sh mlton-20070826-12.fc9.i386 requires /usr/bin/perl mlton-20070826-12.fc9.i386 requires /usr/bin/env mlton-20070826-12.fc9.i386 requires /bin/sh mm-1.4.2-4.fc9.i386 requires /sbin/ldconfig mm-devel-1.4.2-4.fc9.i386 requires /bin/sh mock-0.9.9-1.fc10.noarch requires /bin/sh mock-0.9.9-1.fc10.noarch requires /usr/bin/python mod_auth_ntlm_winbind-0.0.0-0.8.20070129svn713.fc9.i386 requires /bin/sh mod_fcgid-selinux-2.2-4.fc9.i386 requires /usr/sbin/semodule mod_fcgid-selinux-2.2-4.fc9.i386 requires /bin/sh mod_fcgid-selinux-2.2-4.fc9.i386 requires /sbin/restorecon mod_mono-1.2.6-2.1.fc9.i386 requires /sbin/ldconfig mod_nss-1.0.7-4.fc10.i386 requires /bin/sh mod_nss-1.0.7-4.fc10.i386 requires /bin/bash mod_perl-2.0.4-3.i386 requires /usr/bin/perl mod_revocator-1.0.2-4.fc9.i386 requires /sbin/ldconfig 1:mod_ssl-2.2.8-3.i386 requires /bin/sh 1:mod_ssl-2.2.8-3.i386 requires /bin/cat modello-1.0-0.1.a8.4jpp.3.fc7.noarch requires /bin/sh modello-1.0-0.1.a8.4jpp.3.fc7.noarch requires /bin/sh modello-javadoc-1.0-0.1.a8.4jpp.3.fc7.noarch requires /bin/rm modello-javadoc-1.0-0.1.a8.4jpp.3.fc7.noarch requires /bin/ln module-init-tools-3.4-13.fc9.i386 requires /bin/sh module-init-tools-3.4-13.fc9.i386 requires /bin/bash module-init-tools-3.4-13.fc9.i386 requires /sbin/chkconfig module-init-tools-3.4-13.fc9.i386 requires /bin/sh mogilefsd-2.17-5.fc9.noarch requires /bin/sh mogilefsd-2.17-5.fc9.noarch requires /sbin/service mogilefsd-2.17-5.fc9.noarch requires /sbin/chkconfig mogilefsd-2.17-5.fc9.noarch requires /bin/bash mogilefsd-2.17-5.fc9.noarch requires /usr/bin/perl mogstored-2.17-5.fc9.noarch requires /bin/sh mogstored-2.17-5.fc9.noarch requires /sbin/service mogstored-2.17-5.fc9.noarch requires /usr/bin/perl mogstored-2.17-5.fc9.noarch requires /bin/bash mogstored-2.17-5.fc9.noarch requires /sbin/chkconfig moin-1.6.3-1.fc10.noarch requires /usr/bin/env moin-1.6.3-1.fc10.noarch requires /usr/bin/python moin-latex-0-0.20051126.3.fc6.noarch requires /usr/bin/python mona-examples-1.4r10-1.fc10.i386 requires /bin/sh mona-libs-1.4r10-1.fc10.i386 requires /sbin/ldconfig monit-4.10.1-7.fc9.i386 requires /bin/sh monit-4.10.1-7.fc9.i386 requires /sbin/service monit-4.10.1-7.fc9.i386 requires /bin/bash monit-4.10.1-7.fc9.i386 requires /sbin/chkconfig monitor-edid-1.16-4.fc9.i386 requires /usr/bin/perl monitor-edid-1.16-4.fc9.i386 requires /bin/sh monkey-bubble-0.4.0-9.fc9.i386 requires /bin/sh mono-addins-0.3.1-1.fc10.i386 requires /bin/sh mono-basic-1.9-4.fc10.i386 requires /bin/sh mono-core-1.9.1-2.fc10.i386 requires /bin/sh mono-core-1.9.1-2.fc10.i386 requires /bin/bash mono-data-1.9.1-2.fc10.i386 requires /bin/sh mono-debugger-0.60-3.fc9.i386 requires /sbin/ldconfig mono-debugger-0.60-3.fc9.i386 requires /bin/sh mono-devel-1.9.1-2.fc10.i386 requires /sbin/ldconfig mono-devel-1.9.1-2.fc10.i386 requires /bin/sh mono-extras-1.9.1-2.fc10.i386 requires /bin/sh mono-jscript-1.9.1-2.fc10.i386 requires /bin/sh mono-nunit-1.9.1-2.fc10.i386 requires /bin/sh mono-web-1.9.1-2.fc10.i386 requires /bin/sh mono-zeroconf-0.7.5-4.fc9.i386 requires /bin/bash monodevelop-0.19-6.fc9.i386 requires /bin/sh monodevelop-0.19-6.fc9.i386 requires /bin/bash monodevelop-0.19-6.fc9.i386 requires /bin/sh monodoc-1.9-1.fc10.i386 requires /bin/sh monosim-1.3.0.2-1.fc9.i386 requires /bin/sh monotone-0.39-1.fc9.i386 requires /bin/sh monotone-0.39-1.fc9.i386 requires /sbin/install-info monotone-server-0.39-1.fc9.i386 requires /bin/sh monotone-server-0.39-1.fc9.i386 requires /sbin/chkconfig monotone-server-0.39-1.fc9.i386 requires /bin/sh monotone-server-0.39-1.fc9.i386 requires /sbin/service monsterz-0.7.1-3.fc9.i386 requires /bin/sh monsterz-0.7.1-3.fc9.i386 requires /usr/bin/env moodle-1.9-1.fc9.noarch requires /bin/sh moodle-1.9-1.fc9.noarch requires /usr/bin/perl moodle-1.9-1.fc9.noarch requires /bin/bash moodle-1.9-1.fc9.noarch requires /sbin/chkconfig moodle-1.9-1.fc9.noarch requires /usr/bin/php moodle-1.9-1.fc9.noarch requires /bin/sh moodle-1.9-1.fc9.noarch requires /sbin/service moodss-21.5-3.fc9.i386 requires /usr/bin/env moomps-5.8-3.fc9.i386 requires /bin/bash moomps-5.8-3.fc9.i386 requires /bin/sh moomps-5.8-3.fc9.i386 requires /sbin/chkconfig moomps-5.8-3.fc9.i386 requires /usr/bin/tclsh moomps-5.8-3.fc9.i386 requires /sbin/service moreutils-0.28-3.fc9.i386 requires /usr/bin/perl mosml-2.01-11.fc9.i386 requires /bin/sh mousepad-0.2.13-2.fc9.i386 requires /bin/sh mousetweaks-2.23.2-3.fc10.i386 requires /bin/sh mozilla-opensc-signer-0.11.4-4.fc9.i386 requires /usr/lib/mozilla/plugins mozldap-6.0.5-2.fc9.i386 requires /sbin/ldconfig mpc-0.12.1-2.fc9.i386 requires /bin/sh mpfr-2.3.0-3.fc9.i386 requires /sbin/ldconfig mpfr-devel-2.3.0-3.fc9.i386 requires /bin/sh mpfr-devel-2.3.0-3.fc9.i386 requires /sbin/install-info mrtg-2.16.1-2.fc10.i386 requires /bin/sh mrtg-2.16.1-2.fc10.i386 requires /sbin/service mrtg-2.16.1-2.fc10.i386 requires /usr/bin/perl mrtg-2.16.1-2.fc10.i386 requires /bin/sh msmtp-1.4.13-4.fc9.i386 requires /bin/sh msmtp-1.4.13-4.fc9.i386 requires /sbin/install-info 1:mt-daapd-0.2.4.2-2.fc10.i386 requires /bin/sh 1:mt-daapd-0.2.4.2-2.fc10.i386 requires /sbin/service 1:mt-daapd-0.2.4.2-2.fc10.i386 requires /bin/bash 1:mt-daapd-0.2.4.2-2.fc10.i386 requires /sbin/chkconfig 1:mt-daapd-0.2.4.2-2.fc10.i386 requires /usr/sbin/useradd mtd-utils-1.1.0-2.fc8.i386 requires /usr/bin/perl mtools-3.9.11-4.fc9.i386 requires /bin/sh mtools-3.9.11-4.fc9.i386 requires /bin/sh mtpaint-3.20-3.fc9.i386 requires /bin/sh mtx-1.3.11-3.fc9.i386 requires /bin/sh muParser-1.28-4.fc9.i386 requires /sbin/ldconfig mugshot-1.1.95-1.fc9.i386 requires /usr/bin/python mugshot-1.1.95-1.fc9.i386 requires /bin/sh mugshot-1.1.95-1.fc9.i386 requires /bin/sh muine-0.8.8-9.fc9.i386 requires /bin/bash muine-0.8.8-9.fc9.i386 requires /bin/sh multican-0.0.5-4.fc9.i386 requires /sbin/ldconfig munin-1.2.5-4.fc9.noarch requires /bin/sh munin-1.2.5-4.fc9.noarch requires /usr/bin/perl munin-1.2.5-4.fc9.noarch requires /bin/sh munin-node-1.2.5-4.fc9.noarch requires /bin/sh munin-node-1.2.5-4.fc9.noarch requires /usr/bin/env munin-node-1.2.5-4.fc9.noarch requires /sbin/service munin-node-1.2.5-4.fc9.noarch requires /bin/bash munin-node-1.2.5-4.fc9.noarch requires /bin/sh munin-node-1.2.5-4.fc9.noarch requires /usr/bin/perl munin-node-1.2.5-4.fc9.noarch requires /sbin/chkconfig munipack-0.3.1-3.fc9.i386 requires /bin/sh museek+-0.1.13-3.fc9.i386 requires /usr/bin/env museek+-0.1.13-3.fc9.i386 requires /usr/bin/python musicbox-0.2.3-6.fc9.i386 requires /usr/bin/perl mussh-0.7-2.fc8.noarch requires /bin/bash 5:mutt-1.5.17-4.fc9.i386 requires /usr/bin/perl 1:mx4j-3.0.1-6jpp.4.i386 requires /bin/sh 1:mx4j-3.0.1-6jpp.4.i386 requires /usr/sbin/update-alternatives 1:mx4j-3.0.1-6jpp.4.i386 requires /bin/rm 1:mx4j-javadoc-3.0.1-6jpp.4.i386 requires /bin/sh 1:mx4j-javadoc-3.0.1-6jpp.4.i386 requires /bin/rm 1:mx4j-javadoc-3.0.1-6jpp.4.i386 requires /bin/ln mxml-2.2.2-8.fc9.i386 requires /sbin/ldconfig mybashburn-1.0.2-3.fc8.noarch requires /usr/bin/env mybashburn-1.0.2-3.fc8.noarch requires /bin/sh mypaint-0.5.0-7.fc9.i386 requires /usr/bin/env mysql-5.0.51a-1.fc9.i386 requires /bin/sh mysql-5.0.51a-1.fc9.i386 requires /sbin/install-info mysql-5.0.51a-1.fc9.i386 requires /usr/bin/perl mysql-5.0.51a-1.fc9.i386 requires /bin/sh mysql++-3.0.3-1.fc10.i386 requires /sbin/ldconfig mysql-administrator-5.0r12-5.fc9.i386 requires /bin/sh mysql-bench-5.0.51a-1.fc9.i386 requires /usr/bin/perl 1:mysql-connector-java-3.1.12-5.fc9.i386 requires /bin/sh mysql-connector-odbc-3.51.24r1071-1.fc9.i386 requires /sbin/ldconfig mysql-libs-5.0.51a-1.fc9.i386 requires /bin/sh mysql-libs-5.0.51a-1.fc9.i386 requires /sbin/ldconfig mysql-query-browser-5.0r12-5.fc9.i386 requires /bin/sh mysql-server-5.0.51a-1.fc9.i386 requires /bin/sh mysql-server-5.0.51a-1.fc9.i386 requires /usr/sbin/useradd mysql-server-5.0.51a-1.fc9.i386 requires /bin/bash mysql-server-5.0.51a-1.fc9.i386 requires /bin/sh mysql-server-5.0.51a-1.fc9.i386 requires /usr/bin/perl mysql-server-5.0.51a-1.fc9.i386 requires /sbin/chkconfig mysql-test-5.0.51a-1.fc9.i386 requires /usr/bin/perl mysql-test-5.0.51a-1.fc9.i386 requires /bin/sh mytop-1.6-2.fc9.noarch requires /usr/bin/perl nabi-0.18-9.fc9.i386 requires /usr/sbin/alternatives nabi-0.18-9.fc9.i386 requires /bin/sh nafees-web-naskh-fonts-1.0-1.fc8.noarch requires /bin/sh nagios-2.11-3.fc9.i386 requires /bin/sh nagios-2.11-3.fc9.i386 requires /usr/bin/perl nagios-2.11-3.fc9.i386 requires /bin/sh nagios-plugins-1.4.11-4.fc10.i386 requires /bin/sh nagios-plugins-breeze-1.4.11-4.fc10.i386 requires /usr/bin/perl nagios-plugins-by_ssh-1.4.11-4.fc10.i386 requires /usr/bin/ssh nagios-plugins-dig-1.4.11-4.fc10.i386 requires /usr/bin/dig nagios-plugins-disk_smb-1.4.11-4.fc10.i386 requires /usr/bin/smbclient nagios-plugins-disk_smb-1.4.11-4.fc10.i386 requires /usr/bin/perl nagios-plugins-dns-1.4.11-4.fc10.i386 requires /usr/bin/nslookup nagios-plugins-file_age-1.4.11-4.fc10.i386 requires /usr/bin/perl nagios-plugins-flexlm-1.4.11-4.fc10.i386 requires /usr/bin/perl nagios-plugins-fping-1.4.11-4.fc10.i386 requires /usr/sbin/fping nagios-plugins-ifoperstatus-1.4.11-4.fc10.i386 requires /usr/bin/perl nagios-plugins-ifstatus-1.4.11-4.fc10.i386 requires /usr/bin/perl nagios-plugins-ircd-1.4.11-4.fc10.i386 requires /usr/bin/perl nagios-plugins-linux_raid-1.4.11-4.fc10.i386 requires /usr/bin/perl nagios-plugins-log-1.4.11-4.fc10.i386 requires /bin/egrep nagios-plugins-log-1.4.11-4.fc10.i386 requires /bin/mktemp nagios-plugins-log-1.4.11-4.fc10.i386 requires /bin/sh nagios-plugins-mailq-1.4.11-4.fc10.i386 requires /usr/bin/perl nagios-plugins-ntp-1.4.11-4.fc10.i386 requires /usr/sbin/ntpq nagios-plugins-ntp-1.4.11-4.fc10.i386 requires /usr/sbin/ntpdc nagios-plugins-ntp-1.4.11-4.fc10.i386 requires /usr/sbin/ntpdate nagios-plugins-oracle-1.4.11-4.fc10.i386 requires /bin/sh nagios-plugins-ping-1.4.11-4.fc10.i386 requires /bin/ping nagios-plugins-ping-1.4.11-4.fc10.i386 requires /bin/ping6 nagios-plugins-rpc-1.4.11-4.fc10.i386 requires /usr/bin/perl nagios-plugins-rpc-1.4.11-4.fc10.i386 requires /usr/sbin/rpcinfo nagios-plugins-sensors-1.4.11-4.fc10.i386 requires /usr/bin/sensors nagios-plugins-sensors-1.4.11-4.fc10.i386 requires /bin/egrep nagios-plugins-sensors-1.4.11-4.fc10.i386 requires /bin/sh nagios-plugins-snmp-1.4.11-4.fc10.i386 requires /usr/bin/snmpget nagios-plugins-snmp-1.4.11-4.fc10.i386 requires /usr/bin/snmpgetnext nagios-plugins-wave-1.4.11-4.fc10.i386 requires /usr/bin/perl naim-0.11.8.3.1-6.fc9.i386 requires /bin/sh namazu-2.0.18-1.fc9.i386 requires /usr/bin/perl namazu-devel-2.0.18-1.fc9.i386 requires /bin/sh namazu-libs-2.0.18-1.fc9.i386 requires /sbin/ldconfig nano-2.0.6-4.fc9.i386 requires /bin/sh nano-2.0.6-4.fc9.i386 requires /sbin/install-info 1:nant-0.85-21.fc9.i386 requires /bin/sh 1:nant-docs-0.85-21.fc9.i386 requires /bin/sh nas-1.9.1-4.fc9.i386 requires /bin/sh nas-1.9.1-4.fc9.i386 requires /sbin/service nas-1.9.1-4.fc9.i386 requires /bin/bash nas-1.9.1-4.fc9.i386 requires /bin/sh nas-1.9.1-4.fc9.i386 requires /usr/bin/perl nas-libs-1.9.1-4.fc9.i386 requires /sbin/ldconfig nash-6.0.52-2.fc9.i386 requires /bin/bash nasm-2.01-2.fc9.i386 requires /bin/sh nasm-2.01-2.fc9.i386 requires /sbin/install-info naturette-1.3-1.fc8.noarch requires /bin/sh naturette-1.3-1.fc8.noarch requires /bin/bash nautilus-2.23.2-2.fc10.i386 requires /bin/sh nautilus-actions-1.4.1-3.fc9.i386 requires /bin/sh nautilus-cd-burner-2.22.1-1.fc9.i386 requires /bin/sh nautilus-open-terminal-0.9-2.fc9.i386 requires /bin/sh nautilus-python-0.4.3-5.fc9.i386 requires /sbin/ldconfig nautilus-sendto-0.14.0-4.fc10.i386 requires /bin/sh nazghul-haxima-0.6.0-4.20080407cvs.fc9.i386 requires /bin/sh nbd-2.9.10-1.fc9.i386 requires /bin/sh nc-1.84-16.fc9.i386 requires /bin/sh ncl-5.0.0-11.fc9.i386 requires /bin/csh ncl-devel-5.0.0-11.fc9.i386 requires /bin/csh ncl-examples-5.0.0-11.fc9.i386 requires /bin/csh nco-3.9.3-1.fc9.i386 requires /bin/sh ncpfs-2.2.6-10.fc9.i386 requires /sbin/ldconfig ncurses-devel-5.6-16.20080301.fc9.i386 requires /bin/sh ncurses-libs-5.6-16.20080301.fc9.i386 requires /sbin/ldconfig neXtaw-0.15.1-12.fc9.i386 requires /sbin/ldconfig nedit-5.5-18.fc9.i386 requires /bin/sh nekohtml-0.9.5-4jpp.1.fc7.noarch requires /bin/sh nemiver-0.5.2-1.fc9.i386 requires /bin/sh neon-0.28.2-2.i386 requires /sbin/ldconfig neon-devel-0.28.2-2.i386 requires /bin/sh nessus-core-2.2.10-4.fc9.i386 requires /bin/sh nessus-libraries-2.2.10-3.fc9.i386 requires /sbin/ldconfig nessus-libraries-devel-2.2.10-3.fc9.i386 requires /bin/sh nessus-server-2.2.10-4.fc9.i386 requires /bin/sh nessus-server-2.2.10-4.fc9.i386 requires /sbin/service nessus-server-2.2.10-4.fc9.i386 requires /bin/sh nessus-server-2.2.10-4.fc9.i386 requires /sbin/chkconfig 1:net-snmp-5.4.1-15.fc10.i386 requires /bin/sh 1:net-snmp-5.4.1-15.fc10.i386 requires /bin/bash 1:net-snmp-5.4.1-15.fc10.i386 requires /bin/sh 1:net-snmp-5.4.1-15.fc10.i386 requires /usr/bin/perl 1:net-snmp-devel-5.4.1-15.fc10.i386 requires /bin/sh 1:net-snmp-gui-5.4.1-15.fc10.i386 requires /usr/bin/perl 1:net-snmp-libs-5.4.1-15.fc10.i386 requires /sbin/ldconfig 1:net-snmp-perl-5.4.1-15.fc10.i386 requires /usr/bin/perl 1:net-snmp-perl-5.4.1-15.fc10.i386 requires /bin/bash 1:net-snmp-utils-5.4.1-15.fc10.i386 requires /usr/bin/perl net-tools-1.60-87.fc9.i386 requires /bin/sh net-tools-1.60-87.fc9.i386 requires /sbin/chkconfig net-tools-1.60-87.fc9.i386 requires /bin/sh net-tools-1.60-87.fc9.i386 requires /sbin/service net6-1.3.5-3.fc9.i386 requires /sbin/ldconfig 4:netatalk-2.0.3-19.fc9.i386 requires /bin/sh 4:netatalk-2.0.3-19.fc9.i386 requires /sbin/service 4:netatalk-2.0.3-19.fc9.i386 requires /sbin/ldconfig 4:netatalk-2.0.3-19.fc9.i386 requires /usr/bin/perl 4:netatalk-2.0.3-19.fc9.i386 requires /bin/sh 4:netatalk-2.0.3-19.fc9.i386 requires /sbin/chkconfig 4:netatalk-devel-2.0.3-19.fc9.i386 requires /bin/sh netcdf-4.0.0-0.4.beta2.fc10.i386 requires /bin/sh netcdf-perl-1.2.3-7.fc9.i386 requires /usr/bin/perl netdump-server-0.7.16-22.fc9.i386 requires /sbin/service netdump-server-0.7.16-22.fc9.i386 requires /bin/sh netdump-server-0.7.16-22.fc9.i386 requires /usr/bin/ssh-keygen netdump-server-0.7.16-22.fc9.i386 requires /usr/bin/ssh netdump-server-0.7.16-22.fc9.i386 requires /bin/sh netdump-server-0.7.16-22.fc9.i386 requires /sbin/ifconfig netembryo-0.0.5-2.fc9.i386 requires /sbin/ldconfig netgen-1.3.7-15.fc9.i386 requires /bin/sh netgen-1.3.7-15.fc9.i386 requires /bin/csh netgen-1.3.7-15.fc9.i386 requires /bin/sh netgo-0.5-10.fc9.i386 requires /bin/sh nethack-3.4.3-17.fc9.i386 requires /bin/sh nethack-3.4.3-17.fc9.i386 requires /bin/sh nethack-vultures-2.1.0-10.fc8.i386 requires /bin/sh nethack-vultures-2.1.0-10.fc8.i386 requires /usr/sbin/groupadd nethack-vultures-2.1.0-10.fc8.i386 requires /bin/sh nethack-vultures-2.1.0-10.fc8.i386 requires /usr/bin/bzip2 netlabel_tools-0.17-7.fc9.i386 requires /bin/sh netmask-2.3.9-3.fc9.i386 requires /bin/sh netmask-2.3.9-3.fc9.i386 requires /sbin/install-info netpanzer-0.8.2-3.fc9.i386 requires /bin/sh netpbm-10.35.43-1.fc10.i386 requires /sbin/ldconfig netpbm-progs-10.35.43-1.fc10.i386 requires /usr/bin/perl netpbm-progs-10.35.43-1.fc10.i386 requires /bin/sh nettle-1.15-4.fc9.i386 requires /bin/sh nettle-1.15-4.fc9.i386 requires /sbin/ldconfig nettle-1.15-4.fc9.i386 requires /sbin/install-info newscache-1.2-0.6.rc6.fc9.i386 requires /bin/sh newscache-1.2-0.6.rc6.fc9.i386 requires /sbin/service newscache-1.2-0.6.rc6.fc9.i386 requires /bin/bash newscache-1.2-0.6.rc6.fc9.i386 requires /sbin/chkconfig newsx-1.6-8.fc9.i386 requires /bin/sh newt-0.52.9-1.fc9.i386 requires /sbin/ldconfig nexcontrol-0.2-1.fc9.noarch requires /usr/bin/perl nexuiz-2.4-1.fc10.i386 requires /bin/sh 1:nfs-utils-1.1.2-5.fc10.i386 requires /sbin/nologin 1:nfs-utils-1.1.2-5.fc10.i386 requires /bin/bash 1:nfs-utils-1.1.2-5.fc10.i386 requires /bin/sh 1:nfs-utils-1.1.2-5.fc10.i386 requires /sbin/chkconfig 1:nfs-utils-1.1.2-5.fc10.i386 requires /bin/sh nfs-utils-lib-1.1.1-3.fc9.i386 requires /sbin/ldconfig nginx-0.6.31-1.fc10.i386 requires /bin/sh nginx-0.6.31-1.fc10.i386 requires /bin/sh ngspice-doc-17-14.fc9.i386 requires /bin/sh ngspice-doc-17-14.fc9.i386 requires /sbin/install-info nikto-1.36-3.fc8.noarch requires /usr/bin/perl nip2-7.14.1-1.fc9.i386 requires /bin/sh nip2-7.14.1-1.fc9.i386 requires /bin/bash nip2-7.14.1-1.fc9.i386 requires libWand.so.10 nip2-7.14.1-1.fc9.i386 requires libMagick.so.10 njam-1.25-9.fc9.i386 requires /bin/sh 2:nmap-frontend-4.62-1.fc10.i386 requires /usr/bin/python nmh-1.3-RC1.1.fc10.i386 requires /bin/sh nntpgrab-core-0.2.90-1.fc10.i386 requires /sbin/ldconfig nogravity-2.00-6.fc9.i386 requires /bin/sh nogravity-2.00-6.fc9.i386 requires /bin/bash notecase-1.6.1-4.fc9.i386 requires /bin/sh notification-daemon-0.3.7-9.fc9.i386 requires /bin/sh nqc-3.1.6-2.fc9.i386 requires /bin/sh nqc-3.1.6-2.fc9.i386 requires /usr/sbin/groupadd nrpe-2.7-6.fc9.i386 requires /bin/sh nrpe-2.7-6.fc9.i386 requires /sbin/chkconfig nrpe-2.7-6.fc9.i386 requires /usr/sbin/useradd nrpe-2.7-6.fc9.i386 requires /bin/sh nrpe-2.7-6.fc9.i386 requires /sbin/service nsca-2.7.2-6.fc9.i386 requires /bin/sh nsca-2.7.2-6.fc9.i386 requires /sbin/chkconfig nsca-2.7.2-6.fc9.i386 requires /bin/sh nsca-2.7.2-6.fc9.i386 requires /sbin/service nscd-2.8.90-2.i386 requires /usr/sbin/userdel nscd-2.8.90-2.i386 requires /bin/sh nscd-2.8.90-2.i386 requires /usr/sbin/useradd nscd-2.8.90-2.i386 requires /bin/bash nscd-2.8.90-2.i386 requires /sbin/chkconfig nsd-3.0.7-3.fc9.i386 requires /bin/sh nsd-3.0.7-3.fc9.i386 requires /bin/bash nsd-3.0.7-3.fc9.i386 requires /bin/sh nspluginwrapper-0.9.91.5-27.fc9.i386 requires /bin/sh nspluginwrapper-0.9.91.5-27.fc9.i386 requires /usr/bin/linux32 nspluginwrapper-0.9.91.5-27.fc9.i386 requires /bin/sh nspr-4.7.0.99.2-2.fc9.i386 requires /bin/sh nspr-devel-4.7.0.99.2-2.fc9.i386 requires /bin/sh nss-3.11.99.5-2.fc9.i386 requires /bin/sh nss-devel-3.11.99.5-2.fc9.i386 requires /bin/sh nss-mdns-0.10-4.fc9.i386 requires /bin/sh nss-mdns-0.10-4.fc9.i386 requires /sbin/ldconfig nss_compat_ossl-0.9.2-4.fc9.i386 requires /sbin/ldconfig nss_db-2.2-40.fc9.i386 requires /sbin/ldconfig nss_ldap-259-3.fc9.i386 requires /bin/sh nss_ldap-259-3.fc9.i386 requires /sbin/ldconfig 2:ntfs-3g-1.2506-1.fc10.i386 requires /sbin/ldconfig ntfs-config-1.0-0.6.rc5.fc9.noarch requires /usr/bin/python2.5 ntfsprogs-2.0.0-7.fc10.i386 requires /sbin/ldconfig ntp-4.2.4p4-6.fc9.i386 requires /bin/sh ntp-4.2.4p4-6.fc9.i386 requires /sbin/service ntp-4.2.4p4-6.fc9.i386 requires /bin/bash ntp-4.2.4p4-6.fc9.i386 requires /usr/bin/perl ntp-4.2.4p4-6.fc9.i386 requires /sbin/chkconfig numactl-2.0.0-1.fc10.i386 requires /sbin/ldconfig numactl-2.0.0-1.fc10.i386 requires /usr/bin/perl numlockx-1.0-14.fc9.i386 requires /bin/sh numpy-1.0.3.1-2.fc9.i386 requires /usr/bin/env nut-2.2.2-1.fc10.i386 requires /sbin/service nut-2.2.2-1.fc10.i386 requires /sbin/chkconfig nut-2.2.2-1.fc10.i386 requires /bin/sh nut-cgi-2.2.2-1.fc10.i386 requires /bin/sh nut-client-2.2.2-1.fc10.i386 requires /bin/sh nut-client-2.2.2-1.fc10.i386 requires /bin/bash nut-client-2.2.2-1.fc10.i386 requires /usr/sbin/useradd nut-client-2.2.2-1.fc10.i386 requires /bin/sh nvclock-gtk-0.8-0.6.b3a.fc10.i386 requires /bin/sh nx-3.2.0-27.fc9.i386 requires /bin/bash nx-3.2.0-27.fc9.i386 requires /bin/sh nyquist-2.37-2.fc9.i386 requires /bin/sh obby-0.4.4-3.fc9.i386 requires /sbin/ldconfig obconf-2.0.3-2.fc10.i386 requires /bin/sh obexftp-0.22-0.9.rc9.fc9.i386 requires /sbin/ldconfig obmenu-1.0-6.fc9.noarch requires /usr/bin/python ocaml-3.10.2-2.fc10.i386 requires /bin/sh ocaml-3.10.2-2.fc10.i386 requires /usr/bin/ocamlrun ocaml-camlidl-1.05-5.fc10.i386 requires /usr/bin/ocamlrun ocaml-camlp4-devel-3.10.2-2.fc10.i386 requires /usr/bin/ocamlrun ocaml-camlp5-devel-5.08-3.fc10.i386 requires /bin/sh ocaml-camlp5-devel-5.08-3.fc10.i386 requires /usr/bin/ocamlrun ocaml-cil-cilly-1.3.6-5.fc10.i386 requires /usr/bin/perl ocaml-deriving-0.1.1a-3.fc10.i386 requires /usr/bin/ocamlrun ocaml-docs-3.10.2-2.fc10.i386 requires /bin/sh ocaml-docs-3.10.2-2.fc10.i386 requires /sbin/install-info ocaml-findlib-1.2.1-3.fc10.i386 requires /bin/sh ocaml-findlib-devel-1.2.1-3.fc10.i386 requires /usr/bin/ocamlrun ocaml-gettext-devel-0.3.0-1.fc10.i386 requires /usr/bin/ocamlrun ocaml-gsl-devel-0.6.0-3.fc10.i386 requires /bin/sh ocaml-gsl-devel-0.6.0-3.fc10.i386 requires /sbin/install-info ocaml-lablgl-1.03-4.fc10.i386 requires /bin/sh ocaml-lablgtk-2.10.1-2.fc10.i386 requires /bin/sh ocaml-lablgtk-2.10.1-2.fc10.i386 requires /usr/bin/ocamlrun ocaml-lablgtk-devel-2.10.1-2.fc10.i386 requires /usr/bin/ocamlrun ocaml-labltk-3.10.2-2.fc10.i386 requires /bin/sh ocaml-labltk-devel-3.10.2-2.fc10.i386 requires /usr/bin/wish ocaml-labltk-devel-3.10.2-2.fc10.i386 requires /usr/bin/ocamlrun ocaml-ocamldoc-3.10.2-2.fc10.i386 requires /usr/bin/ocamlrun ocaml-perl4caml-0.9.5-5.fc10.i386 requires /usr/lib/perl5/5.10.0/i386-linux-thread-multi/CORE/libperl.so ocaml-runtime-3.10.2-2.fc10.i386 requires /bin/sh ocfs2-tools-1.3.9-7.20080221git.fc8.i386 requires /sbin/service ocfs2-tools-1.3.9-7.20080221git.fc8.i386 requires /bin/bash ocfs2-tools-1.3.9-7.20080221git.fc8.i386 requires /bin/sh ocfs2console-1.3.9-7.20080221git.fc8.i386 requires /usr/bin/python ochusha-0.5.99.66-0.4.cvs070110.fc9.2.i386 requires /etc/pki/tls/cert.pem ochusha-0.5.99.66-0.4.cvs070110.fc9.2.i386 requires /bin/sh ocrad-0.17-3.fc9.i386 requires /bin/sh ocrad-0.17-3.fc9.i386 requires /sbin/install-info ocsinventory-agent-0.0.9.2-1.fc10.noarch requires /etc/logrotate.d ocsinventory-agent-0.0.9.2-1.fc10.noarch requires /usr/bin/perl ocsinventory-agent-0.0.9.2-1.fc10.noarch requires /etc/cron.hourly ocsinventory-agent-0.0.9.2-1.fc10.noarch requires /bin/bash 6:octave-3.0.1-1.fc10.i386 requires /bin/sh 6:octave-3.0.1-1.fc10.i386 requires /sbin/install-info 6:octave-3.0.1-1.fc10.i386 requires /sbin/ldconfig 6:octave-3.0.1-1.fc10.i386 requires /bin/sh 6:octave-devel-3.0.1-1.fc10.i386 requires /bin/sh octave-forge-20080429-6.fc10.i386 requires /bin/sh octave-forge-20080429-6.fc10.i386 requires /bin/sh odccm-0.11-2.fc9.i386 requires /sbin/service odccm-0.11-2.fc9.i386 requires /bin/bash odccm-0.11-2.fc9.i386 requires /sbin/chkconfig odccm-0.11-2.fc9.i386 requires /bin/sh oddjob-0.29-2.fc9.i386 requires /bin/sh oddjob-0.29-2.fc9.i386 requires /bin/bash oddjob-0.29-2.fc9.i386 requires /sbin/chkconfig oddjob-0.29-2.fc9.i386 requires /bin/sh oddjob-0.29-2.fc9.i386 requires /sbin/service oddjob-libs-0.29-2.fc9.i386 requires /sbin/ldconfig oddjob-mkhomedir-0.29-2.fc9.i386 requires /bin/sh ode-0.9-4.fc9.i386 requires /sbin/ldconfig ode-devel-0.9-4.fc9.i386 requires /bin/sh offlineimap-5.99.7-1.fc9.noarch requires /usr/bin/python ogdi-3.2.0-0.8.beta1.fc9.i386 requires /sbin/ldconfig ogdi-devel-3.2.0-0.8.beta1.fc9.i386 requires /bin/sh oggconvert-0.3.0-14.fc9.noarch requires /usr/bin/python ogre-1.4.8-1.fc10.i386 requires /sbin/ldconfig ogre-samples-1.4.8-1.fc10.i386 requires /bin/bash oidentd-2.0.8-5.fc9.i386 requires /bin/sh oidentd-2.0.8-5.fc9.i386 requires /sbin/chkconfig oidentd-2.0.8-5.fc9.i386 requires /bin/sh oidentd-2.0.8-5.fc9.i386 requires /sbin/service ois-1.0-4.fc9.i386 requires /sbin/ldconfig oki4linux-2.1gst-3.fc9.i386 requires /bin/sh oki4linux-2.1gst-3.fc9.i386 requires /usr/bin/perl oki4linux-2.1gst-3.fc9.i386 requires /sbin/chkconfig oki4linux-2.1gst-3.fc9.i386 requires /bin/sh oniguruma-5.9.1-1.fc9.2.i386 requires /sbin/ldconfig oniguruma-devel-5.9.1-1.fc9.2.i386 requires /bin/sh online-desktop-0.2.28-1.fc10.i386 requires /usr/bin/env online-desktop-0.2.28-1.fc10.i386 requires /usr/bin/python online-desktop-0.2.28-1.fc10.i386 requires /bin/sh online-desktop-0.2.28-1.fc10.i386 requires /bin/sh online-desktop-flickr-0.2.28-1.fc10.i386 requires /bin/sh online-desktop-gmail-0.2.28-1.fc10.i386 requires /bin/sh online-desktop-google-calendar-0.2.28-1.fc10.i386 requires /bin/sh online-desktop-google-docs-0.2.28-1.fc10.i386 requires /bin/sh online-desktop-google-reader-0.2.28-1.fc10.i386 requires /bin/sh ooo2txt-0.0.6-3.fc9.noarch requires /usr/bin/perl oooqs2-1.0-3.fc6.i386 requires /bin/sh oorexx-devel-3.2.0-4.fc9.i386 requires /bin/sh oorexx-docs-3.2.0-4.fc9.i386 requires /usr/bin/rexx oorexx-libs-3.2.0-4.fc9.i386 requires /sbin/ldconfig opal-2.2.11-4.fc10.i386 requires /sbin/ldconfig openais-0.83-2.fc10.i386 requires /bin/sh openais-0.83-2.fc10.i386 requires /usr/sbin/useradd openais-0.83-2.fc10.i386 requires /bin/sh openais-0.83-2.fc10.i386 requires /sbin/chkconfig openal-0.0.9-0.15.20060204cvs.fc9.i386 requires /sbin/ldconfig openal-devel-0.0.9-0.15.20060204cvs.fc9.i386 requires /bin/sh openarena-0.7.6-1.fc10.noarch requires /bin/bash openbabel-2.2.0-0.3.b4.fc10.i386 requires /sbin/ldconfig openbox-3.4.7.2-1.fc10.i386 requires /usr/bin/env openbox-3.4.7.2-1.fc10.i386 requires /bin/sh openbox-libs-3.4.7.2-1.fc10.i386 requires /sbin/ldconfig opencdk-0.6.6-1.fc9.i386 requires /sbin/ldconfig opencdk-devel-0.6.6-1.fc9.i386 requires /bin/sh openct-0.6.14-4.fc9.i386 requires /bin/sh openct-0.6.14-4.fc9.i386 requires /sbin/ldconfig openct-0.6.14-4.fc9.i386 requires /usr/lib/ctapi openct-0.6.14-4.fc9.i386 requires /bin/sh openct-0.6.14-4.fc9.i386 requires /sbin/chkconfig opencv-1.0.0-8.fc10.i386 requires /sbin/ldconfig opencv-python-1.0.0-8.fc10.i386 requires /usr/bin/env opencv-python-1.0.0-8.fc10.i386 requires /usr/bin/python opencv-python-1.0.0-8.fc10.i386 requires /sbin/ldconfig opengl-games-utils-0.1-5.fc9.noarch requires /bin/bash opengrok-0.6-9.hg275.fc9.noarch requires /bin/sh openhpi-2.10.2-1.fc9.i386 requires /sbin/service openhpi-2.10.2-1.fc9.i386 requires /bin/bash openhpi-2.10.2-1.fc9.i386 requires /bin/sh openhpi-2.10.2-1.fc9.i386 requires /sbin/chkconfig openhpi-2.10.2-1.fc9.i386 requires /bin/sh openhpi-libs-2.10.2-1.fc9.i386 requires /sbin/ldconfig openhpi-subagent-2.3.4-2.fc10.i386 requires /sbin/service openhpi-subagent-2.3.4-2.fc10.i386 requires /bin/sh openhpi-subagent-2.3.4-2.fc10.i386 requires /sbin/chkconfig openhpi-subagent-2.3.4-2.fc10.i386 requires /bin/sh openjade-1.3.2-31.fc9.i386 requires /bin/sh openjade-1.3.2-31.fc9.i386 requires /sbin/ldconfig openjpeg-libs-1.3-2.fc9.i386 requires /sbin/ldconfig openldap-2.4.9-4.fc10.i386 requires /sbin/ldconfig openldap-devel-2.4.9-4.fc10.i386 requires /sbin/ldconfig openldap-servers-2.4.9-4.fc10.i386 requires /sbin/runuser openldap-servers-2.4.9-4.fc10.i386 requires /bin/sh openldap-servers-2.4.9-4.fc10.i386 requires /usr/sbin/useradd openldap-servers-2.4.9-4.fc10.i386 requires /sbin/chkconfig openldap-servers-2.4.9-4.fc10.i386 requires /bin/bash openlierox-0.57-0.9.beta5.fc9.i386 requires /bin/sh openlierox-0.57-0.9.beta5.fc9.i386 requires /bin/bash openmpi-1.2.4-2.fc9.i386 requires /bin/sh openmpi-1.2.4-2.fc9.i386 requires /sbin/ldconfig openmpi-1.2.4-2.fc9.i386 requires /usr/sbin/alternatives openmpi-devel-1.2.4-2.fc9.i386 requires /bin/sh openmpi-devel-1.2.4-2.fc9.i386 requires /sbin/ldconfig openmpi-devel-1.2.4-2.fc9.i386 requires /usr/sbin/alternatives openmpi-libs-1.2.4-2.fc9.i386 requires /bin/sh openmpi-libs-1.2.4-2.fc9.i386 requires /sbin/ldconfig openmpi-libs-1.2.4-2.fc9.i386 requires /usr/sbin/alternatives openmsx-0.6.3-3.fc9.i386 requires /bin/sh openmsx-0.6.3-3.fc9.i386 requires /usr/bin/env openobex-1.3-11.fc9.i386 requires /sbin/ldconfig 1:openoffice.org-base-3.0.0-0.0.12.1.fc10.i386 requires /bin/sh 1:openoffice.org-base-3.0.0-0.0.12.1.fc10.i386 requires /bin/sh 1:openoffice.org-brand-3.0.0-0.0.12.1.fc10.i386 requires /bin/sh 1:openoffice.org-brand-3.0.0-0.0.12.1.fc10.i386 requires /bin/sh 1:openoffice.org-calc-3.0.0-0.0.12.1.fc10.i386 requires /bin/sh 1:openoffice.org-calc-3.0.0-0.0.12.1.fc10.i386 requires /bin/sh 1:openoffice.org-core-3.0.0-0.0.12.1.fc10.i386 requires /bin/sh 1:openoffice.org-core-3.0.0-0.0.12.1.fc10.i386 requires /bin/sh 1:openoffice.org-devel-3.0.0-0.0.12.1.fc10.i386 requires /usr/bin/perl 1:openoffice.org-devel-3.0.0-0.0.12.1.fc10.i386 requires /usr/bin/python 1:openoffice.org-devel-3.0.0-0.0.12.1.fc10.i386 requires /bin/bash 1:openoffice.org-devel-3.0.0-0.0.12.1.fc10.i386 requires /bin/sh 1:openoffice.org-draw-3.0.0-0.0.12.1.fc10.i386 requires /bin/sh 1:openoffice.org-draw-3.0.0-0.0.12.1.fc10.i386 requires /bin/sh openoffice.org-extendedPDF-1.4-4.fc9.noarch requires /bin/sh 1:openoffice.org-impress-3.0.0-0.0.12.1.fc10.i386 requires /bin/sh 1:openoffice.org-impress-3.0.0-0.0.12.1.fc10.i386 requires /bin/sh 1:openoffice.org-math-3.0.0-0.0.12.1.fc10.i386 requires /bin/sh 1:openoffice.org-math-3.0.0-0.0.12.1.fc10.i386 requires /bin/sh openoffice.org-ooolatex-4.0.0-0.5.beta2.fc9.noarch requires /bin/sh openoffice.org-ooolatex-4.0.0-0.5.beta2.fc9.noarch requires /usr/bin/dvips openoffice.org-ooolatex-4.0.0-0.5.beta2.fc9.noarch requires /usr/bin/latex 1:openoffice.org-presentation-minimizer-3.0.0-0.0.12.1.fc10.i386 requires /bin/sh 1:openoffice.org-presentation-minimizer-3.0.0-0.0.12.1.fc10.i386 requires openoffice.org-base-impress = 1:3.0.0-0.0.12.1.fc10 1:openoffice.org-presenter-screen-3.0.0-0.0.12.1.fc10.i386 requires /bin/sh 1:openoffice.org-presenter-screen-3.0.0-0.0.12.1.fc10.i386 requires openoffice.org-base-impress = 1:3.0.0-0.0.12.1.fc10 1:openoffice.org-report-builder-3.0.0-0.0.12.1.fc10.i386 requires /bin/sh 1:openoffice.org-sdk-3.0.0-0.0.12.1.fc10.i386 requires /bin/csh 1:openoffice.org-sdk-3.0.0-0.0.12.1.fc10.i386 requires /bin/sh 1:openoffice.org-ure-3.0.0-0.0.12.1.fc10.i386 requires /bin/sh openoffice.org-voikko-2.2-4.fc9.i386 requires /bin/sh 1:openoffice.org-writer-3.0.0-0.0.12.1.fc10.i386 requires /bin/sh 1:openoffice.org-writer-3.0.0-0.0.12.1.fc10.i386 requires /bin/sh openoffice.org-writer2latex-0.5-2.fc9.i386 requires /bin/sh opensc-0.11.4-4.fc9.i386 requires /sbin/ldconfig opensc-devel-0.11.4-4.fc9.i386 requires /bin/sh openser-1.3.2-2.fc10.i386 requires /bin/sh openser-1.3.2-2.fc10.i386 requires /bin/bash openslp-1.2.1-9.fc9.i386 requires /sbin/ldconfig openslp-server-1.2.1-9.fc9.i386 requires /bin/sh openslp-server-1.2.1-9.fc9.i386 requires /bin/bash openslp-server-1.2.1-9.fc9.i386 requires /sbin/service opensp-1.5.2-7.fc9.i386 requires /sbin/ldconfig openssh-5.0p1-1.fc9.i386 requires /sbin/nologin openssh-clients-5.0p1-1.fc9.i386 requires /bin/sh openssh-server-5.0p1-1.fc9.i386 requires /bin/sh openssh-server-5.0p1-1.fc9.i386 requires /etc/pam.d/system-auth openssh-server-5.0p1-1.fc9.i386 requires /usr/sbin/useradd openssh-server-5.0p1-1.fc9.i386 requires /sbin/service openssh-server-5.0p1-1.fc9.i386 requires /bin/bash openssh-server-5.0p1-1.fc9.i386 requires /lib/security/pam_loginuid.so openssh-server-5.0p1-1.fc9.i386 requires /bin/sh openssl-0.9.8g-6.fc9.i386 requires /sbin/ldconfig openssl-0.9.8g-6.fc9.i386 requires /bin/sh openssl-0.9.8g-6.fc9.i686 requires /sbin/ldconfig openssl-0.9.8g-6.fc9.i686 requires /bin/sh openssl-perl-0.9.8g-6.fc9.i386 requires /usr/bin/perl openswan-2.6.09-2.fc9.i386 requires /bin/sh openswan-2.6.09-2.fc9.i386 requires /sbin/service openswan-2.6.09-2.fc9.i386 requires /usr/bin/perl openswan-2.6.09-2.fc9.i386 requires /bin/sh openswan-2.6.09-2.fc9.i386 requires /sbin/chkconfig openvpn-2.1-0.25.rc7.fc9.i386 requires /bin/sh openvpn-2.1-0.25.rc7.fc9.i386 requires /usr/sbin/useradd openvpn-2.1-0.25.rc7.fc9.i386 requires /sbin/service openvpn-2.1-0.25.rc7.fc9.i386 requires /bin/bash openvpn-2.1-0.25.rc7.fc9.i386 requires /bin/sh openvpn-2.1-0.25.rc7.fc9.i386 requires /sbin/chkconfig openvrml-0.17.5-5.fc9.i386 requires /sbin/ldconfig openvrml-gl-0.17.5-5.fc9.i386 requires /sbin/ldconfig openvrml-xembed-0.17.5-5.fc9.i386 requires /sbin/install-info openvrml-xembed-0.17.5-5.fc9.i386 requires /bin/sh oprofile-0.9.3-17.fc9.i386 requires /bin/sh opyum-0.0.3-1.fc9.noarch requires /bin/sh opyum-0.0.3-1.fc9.noarch requires /usr/bin/python orage-4.4.2-3.fc9.i386 requires /bin/sh orange-0.3-7.cvs20051118.fc9.i386 requires /sbin/ldconfig orca-2.23.2-1.fc10.i386 requires /bin/sh orca-2.23.2-1.fc10.i386 requires /bin/bash ortp-0.14.2-0.20080211.2.fc9.i386 requires /sbin/ldconfig 1:osgal-0.6.1-4.fc10.i386 requires /sbin/ldconfig osgcal-0.1.46-6.fc10.i386 requires /sbin/ldconfig ots-libs-0.5.0-1.fc9.i386 requires /sbin/ldconfig overgod-1.0-7.fc9.i386 requires /bin/sh oxine-0.7.1-1.fc10.i386 requires /bin/sh oxygen-icon-theme-4.0.72-2.fc10.noarch requires /bin/sh oxygen-icon-theme-scalable-4.0.72-2.fc10.noarch requires /bin/sh oyranos-devel-0.1.7-11.fc9.i386 requires /bin/sh oyranos-libs-0.1.7-11.fc9.i386 requires /sbin/ldconfig p0f-2.0.8-4.fc9.i386 requires /bin/sh p0rn-comfort-0.0.4-5.fc9.noarch requires /bin/sh p0rn-comfort-0.0.4-5.fc9.noarch requires /usr/bin/perl p0rn-comfort-0.0.4-5.fc9.noarch requires /bin/bash p7zip-4.51-4.fc9.i386 requires /bin/sh p7zip-plugins-4.51-4.fc9.i386 requires /bin/sh pAgenda-3.2-2.fc10.noarch requires /bin/sh pAgenda-3.2-2.fc10.noarch requires /usr/bin/env pachi-1.0-5.fc9.i386 requires /bin/sh pakchois-0.4-1.i386 requires /sbin/ldconfig paktype-fonts-2.0-2.fc8.noarch requires /bin/sh pam-1.0.1-2.fc10.i386 requires /bin/sh pam-1.0.1-2.fc10.i386 requires /sbin/ldconfig pam-1.0.1-2.fc10.i386 requires /bin/sh pam_mount-0.32-3.fc9.i386 requires /bin/sh pam_mount-0.32-3.fc9.i386 requires /bin/bash pam_mount-0.32-3.fc9.i386 requires /bin/sh pam_mount-0.32-3.fc9.i386 requires /usr/bin/perl pango-1.21.1-1.fc10.i386 requires /bin/sh papyrus-0.7.1-3.fc9.i386 requires /sbin/ldconfig paraview-3.2.1-6.fc9.i386 requires /usr/bin/update-desktop-database paraview-3.2.1-6.fc9.i386 requires /bin/sh paraview-data-3.2.1-6.fc9.i386 requires /bin/sh paraview-data-3.2.1-6.fc9.i386 requires /usr/bin/update-mime-database paraview-mpi-3.2.1-6.fc9.i386 requires /usr/bin/update-desktop-database paraview-mpi-3.2.1-6.fc9.i386 requires /bin/sh pards-0.4-6.fc9.i386 requires /sbin/ldconfig pari-2.3.3-1.fc9.i386 requires /sbin/ldconfig pari-gp-2.3.3-1.fc9.i386 requires /usr/bin/perl pari-gp-2.3.3-1.fc9.i386 requires /bin/sh parted-1.8.8-5.fc9.i386 requires /bin/sh parted-1.8.8-5.fc9.i386 requires /sbin/install-info parted-1.8.8-5.fc9.i386 requires /sbin/ldconfig passivetex-1.25-8.fc9.noarch requires /bin/sh passivetex-1.25-8.fc9.noarch requires /bin/sh passwd-0.75-2.fc9.i386 requires /etc/pam.d/system-auth patchutils-0.2.31-5.fc9.i386 requires /usr/bin/perl patchutils-0.2.31-5.fc9.i386 requires /bin/bash patchutils-0.2.31-5.fc9.i386 requires /bin/sh patchy-2006-29.fc9.i386 requires /bin/sh patchy-g77-2006-29.fc9.i386 requires /bin/sh patchy-gfortran-2006-29.fc9.i386 requires /bin/sh paw-2006-29.fc9.i386 requires /bin/sh paw-2006-29.fc9.i386 requires /bin/sh paw-g77-2006-29.fc9.i386 requires /bin/sh paw-g77-2006-29.fc9.i386 requires /bin/sh paw-gfortran-2006-29.fc9.i386 requires /bin/sh paw-gfortran-2006-29.fc9.i386 requires /bin/sh pbstop-4.16-3.fc9.i386 requires /usr/bin/perl pcapdiff-0.1-3.fc9.noarch requires /usr/bin/env pcb-0.20080202-2.fc9.i386 requires /usr/bin/tclsh pcb-0.20080202-2.fc9.i386 requires /sbin/install-info pcb-0.20080202-2.fc9.i386 requires /usr/bin/wish pcb-0.20080202-2.fc9.i386 requires /usr/bin/perl pcb-0.20080202-2.fc9.i386 requires /bin/sh pcb-0.20080202-2.fc9.i386 requires /bin/sh pciutils-2.2.10-1.fc9.i386 requires /bin/sh pcmanfm-0.4.1.1-1.fc10.i386 requires /bin/sh pcmanx-gtk2-0.3.5-9.336svn.fc7.i386 requires /sbin/ldconfig pcre-7.3-3.fc9.i386 requires /sbin/ldconfig pcre-devel-7.3-3.fc9.i386 requires /bin/sh pcsc-lite-1.4.4-3.fc9.i386 requires /bin/sh pcsc-lite-1.4.4-3.fc9.i386 requires /bin/sh pcsc-lite-1.4.4-3.fc9.i386 requires /sbin/chkconfig pcsc-lite-libs-1.4.4-3.fc9.i386 requires /sbin/ldconfig pcsc-lite-openct-0.6.14-4.fc9.i386 requires /bin/sh pcsc-tools-1.4.12-1.fc9.i386 requires /usr/bin/env pdfedit-0.3.2-4.fc9.i386 requires /bin/sh pdfjam-1.20-5.fc6.noarch requires /bin/sh pdns-2.9.21-4.fc9.i386 requires /bin/sh pdns-2.9.21-4.fc9.i386 requires /usr/sbin/useradd pdns-2.9.21-4.fc9.i386 requires /sbin/service pdns-2.9.21-4.fc9.i386 requires /bin/sh pdns-2.9.21-4.fc9.i386 requires /sbin/chkconfig pdns-recursor-3.1.6-1.fc10.i386 requires /bin/sh pdns-recursor-3.1.6-1.fc10.i386 requires /sbin/service pdns-recursor-3.1.6-1.fc10.i386 requires /bin/bash pdns-recursor-3.1.6-1.fc10.i386 requires /sbin/chkconfig pdsh-2.11-6.fc9.i386 requires /usr/bin/perl pekwm-0.1.5-5.fc7.i386 requires /usr/bin/env pengupop-2.2.2-3.fc9.i386 requires /bin/sh 4:perl-5.10.0-20.fc9.i386 requires /usr/bin/perl perl-Ace-1.91-4.fc9.noarch requires /usr/bin/perl perl-Archive-Tar-1.37-20.fc9.i386 requires /usr/bin/perl perl-Archive-Zip-1.23-1.fc10.noarch requires /usr/bin/perl perl-BerkeleyDB-0.34-1.fc10.i386 requires /usr/bin/perl perl-CPAN-1.9205-20.fc9.i386 requires /usr/bin/perl perl-CPANPLUS-0.84-20.fc9.i386 requires /usr/bin/perl perl-Calendar-Simple-1.19-1.fc9.noarch requires /usr/bin/perl perl-Catalyst-Devel-1.03-2.fc9.noarch requires /usr/bin/perl perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Cflow-1.053-9.fc9.i386 requires /usr/bin/perl perl-Convert-Binary-C-0.70-5.fc9.i386 requires /usr/bin/perl perl-Crypt-Primes-0.50-5.fc9.noarch requires /usr/bin/perl perl-Crypt-Random-1.25-5.fc9.noarch requires /usr/bin/perl perl-Curses-1.20-3.fc9.i386 requires /usr/bin/perl perl-DBD-XBase-0.241-7.fc9.noarch requires /usr/bin/perl perl-DBI-1.601-4.fc9.i386 requires /usr/bin/perl perl-DBI-Dumper-2.01-6.fc9.i386 requires /usr/bin/perl perl-Data-HexDump-0.02-4.fc9.noarch requires /usr/bin/perl perl-Data-Stag-0.10-4.fc9.noarch requires /usr/bin/perl perl-Devel-Cover-0.63-3.fc9.i386 requires /usr/bin/perl perl-Device-SerialPort-1.04-3.fc9.i386 requires /usr/bin/perl 1:perl-Digest-SHA-5.45-20.fc9.i386 requires /usr/bin/perl perl-ExtUtils-MakeMaker-6.36-20.fc9.i386 requires /usr/bin/perl perl-ExtUtils-MakeMaker-Coverage-0.05-4.fc9.noarch requires /usr/bin/perl 1:perl-ExtUtils-ParseXS-2.18-20.fc9.i386 requires /usr/bin/perl perl-File-Find-Rule-0.30-6.fc9.noarch requires /usr/bin/perl perl-File-MimeInfo-0.15-2.fc9.noarch requires /usr/bin/perl perl-File-Which-0.05-4.fc9.noarch requires /usr/bin/perl perl-Finance-YahooQuote-0.21-3.fc9.noarch requires /usr/bin/perl perl-GD-2.35-7.fc9.i386 requires /usr/bin/perl perl-GDTextUtil-0.86-11.fc9.noarch requires /bin/sh perl-Gearman-Server-1.09-2.fc9.noarch requires /usr/bin/perl perl-Gtk2-Ex-PodViewer-0.17-4.fc9.noarch requires /usr/bin/perl 1:perl-HTML-Mason-1.39-2.fc9.noarch requires /usr/bin/perl 1:perl-HTML-Mason-1.39-2.fc9.noarch requires /etc/httpd/conf.d perl-HTML-Tidy-1.08-3.fc9.i386 requires /usr/bin/perl 1:perl-HTML-Tree-3.23-4.fc9.noarch requires /usr/bin/perl perl-HTTP-DAV-0.31-2.fc9.noarch requires /usr/bin/perl perl-IO-stringy-2.110-8.fc9.noarch requires /usr/bin/perl perl-Image-ExifTool-7.25-1.fc10.noarch requires /usr/bin/perl perl-Image-Info-1.27-3.fc9.noarch requires /usr/share/X11/rgb.txt perl-Image-Size-3.1-3.fc9.noarch requires /usr/bin/perl perl-Kwiki-0.39-3.fc9.noarch requires /usr/bin/perl perl-Lingua-EN-Inflect-1.89-7.fc9.noarch requires /usr/bin/perl perl-Locale-Maketext-Lexicon-0.66-2.fc9.noarch requires /usr/bin/perl perl-MARC-Record-2.0.0-2.fc9.noarch requires /usr/bin/perl perl-MIME-Lite-3.01-6.fc9.noarch requires /usr/bin/perl perl-MIME-tools-5.426-1.fc9.noarch requires /usr/bin/perl perl-Mail-Mbox-MessageParser-1.5000-5.fc9.noarch requires /usr/bin/diff 1:perl-Module-Build-0.2808-20.fc9.i386 requires /usr/bin/perl perl-Module-CPANTS-Analyse-0.75-3.fc9.noarch requires /usr/bin/perl perl-Module-CoreList-2.14-20.fc9.i386 requires /usr/bin/perl perl-Module-Info-0.31-3.fc9.noarch requires /usr/bin/perl perl-Module-ScanDeps-0.84-1.fc10.noarch requires /usr/bin/perl perl-Module-Signature-0.55-3.fc9.noarch requires /usr/bin/perl perl-Module-Starter-1.42-5.fc9.noarch requires /usr/bin/perl perl-MogileFS-Utils-2.12-2.fc9.noarch requires /usr/bin/perl perl-Net-DNS-SEC-0.14-3.fc9.noarch requires /usr/bin/perl perl-Net-IP-1.25-8.fc9.noarch requires /usr/bin/perl perl-Net-IPv4Addr-0.10-3.fc9.noarch requires /usr/bin/perl perl-Net-NBName-0.26-3.fc9.noarch requires /usr/bin/perl perl-Net-Pcap-0.14-4.fc9.i386 requires /usr/bin/perl perl-Net-SNMP-5.2.0-2.fc9.noarch requires /usr/bin/perl perl-Net-Server-0.97-2.fc9.noarch requires /usr/bin/perl perl-Net-eBay-0.46-2.fc9.noarch requires /usr/bin/perl perl-PDL-2.4.3-12.fc9.i386 requires /usr/bin/perl perl-PPI-HTML-1.07-3.fc9.noarch requires /usr/bin/perl perl-PPI-Tester-0.06-5.fc9.noarch requires /usr/bin/perl perl-Parse-Yapp-1.05-38.fc9.noarch requires /usr/bin/perl perl-Perl-Critic-1.080-3.fc9.noarch requires /usr/bin/perl perl-Perl-MinimumVersion-0.15-5.fc9.noarch requires /usr/bin/perl perl-Perl6-Bible-0.30-5.fc9.noarch requires /usr/bin/perl perl-Pod-Coverage-0.19-3.fc9.noarch requires /usr/bin/perl perl-Pod-POM-0.17-9.fc9.noarch requires /usr/bin/perl perl-Pod-Readme-0.090-3.fc9.noarch requires /usr/bin/perl perl-Pod-Spell-1.01-4.fc9.noarch requires /usr/bin/perl perl-Pod-Tests-0.18-6.fc9.noarch requires /usr/bin/perl perl-Proc-ProcessTable-0.42-1.fc9.i386 requires /usr/bin/perl perl-Pugs-Compiler-Rule-0.28-2.fc9.noarch requires /usr/bin/env perl-RPM-Specfile-1.51-5.fc9.noarch requires /usr/bin/perl perl-Razor-Agent-2.84-4.fc9.i386 requires /usr/bin/perl perl-SGMLSpm-1.03ii-18.fc9.noarch requires /usr/bin/perl perl-SOAP-Lite-0.68-6.fc9.noarch requires /bin/env perl-SOAP-Lite-0.68-6.fc9.noarch requires /usr/bin/env perl-SQL-Translator-0.09000-1.fc9.noarch requires /usr/bin/perl perl-SVK-2.0.2-3.fc9.noarch requires /usr/bin/perl perl-SVN-Mirror-0.73-3.fc9.noarch requires /usr/bin/perl perl-Spreadsheet-WriteExcel-2.20-2.fc9.noarch requires /usr/bin/perl perl-String-ShellQuote-1.03-5.fc9.noarch requires /usr/bin/perl perl-Taint-Runtime-0.03-5.fc9.i386 requires /usr/bin/perl perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Template-Toolkit-2.19-4.fc9.i386 requires /usr/bin/perl perl-Test-AutoBuild-1.2.2-3.fc9.noarch requires /usr/bin/mkisofs perl-Test-AutoBuild-1.2.2-3.fc9.noarch requires /usr/bin/createrepo perl-Test-AutoBuild-1.2.2-3.fc9.noarch requires /usr/bin/xsltproc perl-Test-AutoBuild-1.2.2-3.fc9.noarch requires /usr/bin/perl perl-Test-AutoBuild-1.2.2-3.fc9.noarch requires /bin/sh perl-Test-AutoBuild-1.2.2-3.fc9.noarch requires /usr/bin/yum-arch perl-Test-AutoBuild-1.2.2-3.fc9.noarch requires /usr/bin/genbasedir perl-Test-AutoBuild-account-1.2.2-3.fc9.noarch requires /bin/sh perl-Test-Harness-2.64-20.fc9.i386 requires /usr/bin/perl perl-Test-Inline-2.208-2.fc9.noarch requires /usr/bin/perl perl-Test-Unit-0.25-4.fc9.noarch requires /usr/bin/perl perl-Text-RecordParser-1.2.1-4.fc9.noarch requires /usr/bin/perl perl-Text-Smart-1.0.2-1.fc10.noarch requires /usr/bin/perl perl-Tk-804.028-5.fc9.i386 requires /usr/bin/perl perl-Unicode-Map-0.112-14.fc9.i386 requires /usr/bin/perl perl-Unicode-Map8-0.12-17.fc9.i386 requires /usr/bin/perl perl-VCS-LibCVS-1.0002-3.fc9.noarch requires /usr/bin/perl perl-WWW-Mechanize-1.32-2.fc9.noarch requires /usr/bin/perl perl-WWW-Myspace-0.60-2.fc9.noarch requires /usr/bin/perl perl-WWW-Search-2.497-2.fc9.noarch requires /usr/bin/perl perl-Wx-0.81-1.fc9.i386 requires /usr/bin/perl perl-XML-Entities-0.03-1.fc9.noarch requires /usr/bin/perl perl-XML-Handler-YAWriter-0.23-5.fc9.noarch requires /usr/bin/perl 1:perl-XML-LibXML-1.65-5.fc9.i386 requires /bin/sh 1:perl-XML-LibXML-1.65-5.fc9.i386 requires /bin/sh perl-XML-SAX-0.16-5.fc9.noarch requires /bin/sh perl-XML-Tidy-1.2.54HJnFa-4.fc9.noarch requires /usr/bin/perl perl-XML-Twig-3.32-1.fc9.noarch requires /usr/bin/perl perl-XML-XPath-1.13-6.fc9.noarch requires /usr/bin/perl perl-XML-XQL-0.68-6.fc9.noarch requires /usr/bin/perl perl-YAML-0.66-3.fc9.noarch requires /usr/bin/perl perl-bioperl-1.5.2_102-12.fc9.noarch requires /usr/bin/perl perl-bioperl-run-1.5.2_100-3.fc9.noarch requires /usr/bin/perl 4:perl-devel-5.10.0-20.fc9.i386 requires /usr/bin/perl 4:perl-libs-5.10.0-20.fc9.i386 requires /sbin/ldconfig perl-libwww-perl-5.808-7.fc9.noarch requires /usr/bin/perl perl-pmtools-1.10-1.fc9.noarch requires /usr/bin/perl perltidy-20071205-3.fc9.noarch requires /usr/bin/perl pessulus-2.16.2-2.fc7.noarch requires /usr/bin/env pessulus-2.16.2-2.fc7.noarch requires /usr/bin/python petitboot-0.0.1-7.fc8.i386 requires /bin/sh pexpect-2.3-1.fc9.noarch requires /usr/bin/env pfqueue-0.5.6-7.fc9.i386 requires /sbin/ldconfig pgfouine-1.0-2.fc8.noarch requires /usr/bin/php pgp-tools-0.4.12-2.fc9.noarch requires /usr/bin/perl pgp-tools-0.4.12-2.fc9.noarch requires /bin/sh pharosc-8.3-1.fc8.noarch requires /bin/bash pharosc-alliance-8.3-1.fc8.noarch requires /bin/bash pharosc-alliance-devel-8.3-1.fc8.noarch requires /bin/bash pharosc-doc-8.3-1.fc8.noarch requires /bin/bash pharosc-magic-8.3-1.fc8.noarch requires /bin/bash pharosc-magic-devel-8.3-1.fc8.noarch requires /bin/bash pharosc-synopsys-8.3-1.fc8.noarch requires /bin/bash pharosc-xcircuit-8.3-1.fc8.noarch requires /bin/bash phasex-0.11.1-5.fc9.i386 requires /bin/sh photoml-0.25-1.fc9.noarch requires /usr/bin/perl photoml-0.25-1.fc9.noarch requires /bin/sh php-channel-phing-1.0.0-5.fc9.noarch requires /bin/sh php-channel-phing-1.0.0-5.fc9.noarch requires /usr/bin/pear php-channel-phpdb-1.0.0-4.fc8.noarch requires /bin/sh php-channel-phpdb-1.0.0-4.fc8.noarch requires /usr/bin/pear php-channel-phpunit-1.0-2.fc7.noarch requires /bin/sh php-channel-symfony-1.0.0-2.fc9.noarch requires /bin/sh php-channel-symfony-1.0.0-2.fc9.noarch requires /usr/bin/pear php-devel-5.2.5-7.fc9.i386 requires /bin/sh 1:php-eaccelerator-0.9.5.2-2.fc9.i386 requires /bin/sh php-embedded-5.2.5-7.fc9.i386 requires /sbin/ldconfig php-magickwand-1.0.7-1.fc10.i386 requires libWand.so.10 php-magickwand-1.0.7-1.fc10.i386 requires libMagick.so.10 1:php-pear-1.7.1-2.fc9.noarch requires /bin/sh php-pear-Auth-SASL-1.0.2-4.fc6.noarch requires /bin/sh php-pear-Auth-SASL-1.0.2-4.fc6.noarch requires /usr/bin/pear php-pear-Benchmark-1.2.7-1.fc8.noarch requires /usr/bin/pear php-pear-Benchmark-1.2.7-1.fc8.noarch requires /bin/sh php-pear-Cache-1.5.5-0.2.RC4.fc8.noarch requires /usr/bin/pear php-pear-Cache-1.5.5-0.2.RC4.fc8.noarch requires /bin/sh php-pear-Cache-Lite-1.7.3-1.fc10.noarch requires /bin/sh php-pear-Cache-Lite-1.7.3-1.fc10.noarch requires /usr/bin/pear php-pear-Console-Color-1.0.2-1.fc7.noarch requires /usr/bin/pear php-pear-Console-Color-1.0.2-1.fc7.noarch requires /bin/sh php-pear-Console-Getargs-1.3.4-1.fc8.1.noarch requires /usr/bin/pear php-pear-Console-Getargs-1.3.4-1.fc8.1.noarch requires /bin/sh php-pear-Console-Table-1.1.1-1.fc9.noarch requires /usr/bin/pear php-pear-Console-Table-1.1.1-1.fc9.noarch requires /bin/sh php-pear-Crypt-CHAP-1.0.1-1.fc7.noarch requires /usr/bin/pear php-pear-Crypt-CHAP-1.0.1-1.fc7.noarch requires /bin/sh php-pear-DB-1.7.13-1.fc8.noarch requires /bin/sh php-pear-DB-1.7.13-1.fc8.noarch requires /usr/bin/pear php-pear-DB-1.7.13-1.fc8.noarch requires /bin/sh php-pear-DB-DataObject-1.8.8-1.fc9.noarch requires /usr/bin/pear php-pear-DB-DataObject-1.8.8-1.fc9.noarch requires /bin/sh php-pear-DB-DataObject-1.8.8-1.fc9.noarch requires /usr/bin/php php-pear-DB-DataObject-FormBuilder-1.0.0-0.5.RC7.fc7.noarch requires /usr/bin/pear php-pear-DB-DataObject-FormBuilder-1.0.0-0.5.RC7.fc7.noarch requires /bin/sh php-pear-DB-DataObject-FormBuilder-1.0.0-0.5.RC7.fc7.noarch requires /usr/bin/php php-pear-DB-QueryTool-1.1.2-1.fc9.noarch requires /usr/bin/pear php-pear-DB-QueryTool-1.1.2-1.fc9.noarch requires /bin/sh php-pear-Date-1.4.7-2.fc7.noarch requires /usr/bin/pear php-pear-Date-1.4.7-2.fc7.noarch requires /bin/sh php-pear-Date-Holidays-0.17.4-1.fc9.noarch requires /usr/bin/pear php-pear-Date-Holidays-0.17.4-1.fc9.noarch requires /bin/sh php-pear-Date-Holidays-0.17.4-1.fc9.noarch requires /usr/bin/php php-pear-File-1.3.0-1.fc8.noarch requires /usr/bin/pear php-pear-File-1.3.0-1.fc8.noarch requires /bin/sh php-pear-File-Find-1.3.0-1.fc9.noarch requires /usr/bin/pear php-pear-File-Find-1.3.0-1.fc9.noarch requires /bin/sh php-pear-File-Passwd-1.1.6-2.fc7.noarch requires /usr/bin/pear php-pear-File-Passwd-1.1.6-2.fc7.noarch requires /bin/sh php-pear-File-SMBPasswd-1.0.2-1.fc7.noarch requires /usr/bin/pear php-pear-File-SMBPasswd-1.0.2-1.fc7.noarch requires /bin/sh php-pear-HTML-Common-1.2.4-1.fc8.noarch requires /usr/bin/pear php-pear-HTML-Common-1.2.4-1.fc8.noarch requires /bin/sh php-pear-HTML-QuickForm-3.2.10-1.fc9.noarch requires /usr/bin/pear php-pear-HTML-QuickForm-3.2.10-1.fc9.noarch requires /bin/sh php-pear-HTML-QuickForm-ElementGrid-0.1.1-1.fc7.noarch requires /usr/bin/pear php-pear-HTML-QuickForm-ElementGrid-0.1.1-1.fc7.noarch requires /bin/sh php-pear-HTML-QuickForm-advmultiselect-1.4.1-1.fc10.noarch requires /usr/bin/pear php-pear-HTML-QuickForm-advmultiselect-1.4.1-1.fc10.noarch requires /bin/sh php-pear-HTML-Table-1.8.2-1.fc9.noarch requires /usr/bin/pear php-pear-HTML-Table-1.8.2-1.fc9.noarch requires /bin/sh php-pear-HTTP-1.4.0-8.fc8.noarch requires /bin/sh php-pear-HTTP-1.4.0-8.fc8.noarch requires /usr/bin/pear php-pear-HTTP-Request-1.4.2-1.fc9.noarch requires /usr/bin/pear php-pear-HTTP-Request-1.4.2-1.fc9.noarch requires /bin/sh php-pear-HTTP-Upload-0.9.1-2.fc9.noarch requires /usr/bin/pear php-pear-HTTP-Upload-0.9.1-2.fc9.noarch requires /bin/sh php-pear-Image-Canvas-0.3.1-1.fc8.noarch requires /usr/bin/pear php-pear-Image-Canvas-0.3.1-1.fc8.noarch requires /bin/sh php-pear-Image-Color-1.0.2-3.fc7.noarch requires /usr/bin/pear php-pear-Image-Color-1.0.2-3.fc7.noarch requires /bin/sh php-pear-Image-Graph-0.7.2-2.fc7.noarch requires /usr/bin/pear php-pear-Image-Graph-0.7.2-2.fc7.noarch requires /bin/sh php-pear-Image-GraphViz-1.2.1-2.fc7.noarch requires /usr/bin/pear php-pear-Image-GraphViz-1.2.1-2.fc7.noarch requires /bin/sh php-pear-Log-1.10.1-1.fc10.noarch requires /bin/sh php-pear-Log-1.10.1-1.fc10.noarch requires /usr/bin/pear php-pear-MDB2-2.4.1-2.fc9.noarch requires /usr/bin/pear php-pear-MDB2-2.4.1-2.fc9.noarch requires /bin/sh php-pear-MDB2-Driver-mysql-1.4.1-3.fc9.noarch requires /usr/bin/pear php-pear-MDB2-Driver-mysql-1.4.1-3.fc9.noarch requires /bin/sh php-pear-MDB2-Driver-mysqli-1.4.1-3.fc9.noarch requires /usr/bin/pear php-pear-MDB2-Driver-mysqli-1.4.1-3.fc9.noarch requires /bin/sh php-pear-Mail-1.1.14-2.fc8.noarch requires /bin/sh php-pear-Mail-1.1.14-2.fc8.noarch requires /usr/bin/pear php-pear-Mail-Mime-1.5.2-3.fc9.noarch requires /usr/bin/pear php-pear-Mail-Mime-1.5.2-3.fc9.noarch requires /bin/sh php-pear-Mail-mimeDecode-1.5.0-3.fc9.noarch requires /usr/bin/pear php-pear-Mail-mimeDecode-1.5.0-3.fc9.noarch requires /bin/sh php-pear-Math-Stats-0.9.0-0.1.beta3.fc7.noarch requires /usr/bin/pear php-pear-Math-Stats-0.9.0-0.1.beta3.fc7.noarch requires /bin/sh php-pear-Net-Curl-1.2.3-2.fc6.noarch requires /usr/bin/pear php-pear-Net-Curl-1.2.3-2.fc6.noarch requires /bin/sh php-pear-Net-DIME-0.3-1.fc7.noarch requires /usr/bin/pear php-pear-Net-DIME-0.3-1.fc7.noarch requires /bin/sh php-pear-Net-FTP-1.3.4-1.fc9.noarch requires /usr/bin/pear php-pear-Net-FTP-1.3.4-1.fc9.noarch requires /bin/sh php-pear-Net-POP3-1.3.6-2.fc7.noarch requires /usr/bin/pear php-pear-Net-POP3-1.3.6-2.fc7.noarch requires /bin/sh php-pear-Net-Ping-2.4.3-1.fc9.noarch requires /usr/bin/pear php-pear-Net-Ping-2.4.3-1.fc9.noarch requires /bin/sh php-pear-Net-Ping-2.4.3-1.fc9.noarch requires /bin/ping php-pear-Net-SMTP-1.3.0-1.fc10.noarch requires /bin/sh php-pear-Net-SMTP-1.3.0-1.fc10.noarch requires /usr/bin/pear php-pear-Net-Sieve-1.1.5-2.fc7.noarch requires /usr/bin/pear php-pear-Net-Sieve-1.1.5-2.fc7.noarch requires /bin/sh php-pear-Net-Socket-1.0.8-1.fc7.noarch requires /usr/bin/pear php-pear-Net-Socket-1.0.8-1.fc7.noarch requires /bin/sh php-pear-Net-Traceroute-0.21.1-2.fc8.noarch requires /usr/bin/pear php-pear-Net-Traceroute-0.21.1-2.fc8.noarch requires /bin/sh php-pear-Net-URL-1.0.15-1.fc8.noarch requires /usr/bin/pear php-pear-Net-URL-1.0.15-1.fc8.noarch requires /bin/sh php-pear-Net-URL-Mapper-0.9.0-2.fc9.noarch requires /usr/bin/pear php-pear-Net-URL-Mapper-0.9.0-2.fc9.noarch requires /bin/sh php-pear-Net-UserAgent-Detect-2.4.0-1.fc8.noarch requires /usr/bin/pear php-pear-Net-UserAgent-Detect-2.4.0-1.fc8.noarch requires /bin/sh php-pear-Numbers-Roman-1.0.2-2.fc9.noarch requires /usr/bin/pear php-pear-Numbers-Roman-1.0.2-2.fc9.noarch requires /bin/sh php-pear-Numbers-Words-0.15.0-2.fc7.noarch requires /usr/bin/pear php-pear-Numbers-Words-0.15.0-2.fc7.noarch requires /bin/sh php-pear-PEAR-Command-Packaging-0.1.2-5.fc6.noarch requires /usr/bin/pear php-pear-PEAR-Command-Packaging-0.1.2-5.fc6.noarch requires /bin/sh php-pear-PHP-CodeSniffer-1.0.1-1.fc9.noarch requires /usr/bin/pear php-pear-PHP-CodeSniffer-1.0.1-1.fc9.noarch requires /bin/sh php-pear-PHP-Compat-1.5.0-1.fc6.noarch requires /usr/bin/pear php-pear-PHP-Compat-1.5.0-1.fc6.noarch requires /bin/sh php-pear-PHP-CompatInfo-1.7.0-1.fc10.noarch requires /usr/bin/pear php-pear-PHP-CompatInfo-1.7.0-1.fc10.noarch requires /bin/sh php-pear-PHP-CompatInfo-1.7.0-1.fc10.noarch requires /usr/bin/php php-pear-PHPUnit-3.2.15-1.fc9.noarch requires /usr/bin/pear php-pear-PHPUnit-3.2.15-1.fc9.noarch requires /bin/sh php-pear-PHPUnit-3.2.15-1.fc9.noarch requires /usr/bin/php php-pear-Pager-2.4.4-1.fc8.noarch requires /usr/bin/pear php-pear-Pager-2.4.4-1.fc8.noarch requires /bin/sh php-pear-Payment-Process-0.6.5-1.fc6.noarch requires /usr/bin/pear php-pear-Payment-Process-0.6.5-1.fc6.noarch requires /bin/sh php-pear-Phlickr-0.2.7-2.fc8.noarch requires /usr/bin/pear php-pear-Phlickr-0.2.7-2.fc8.noarch requires /bin/sh php-pear-PhpDocumentor-1.4.1-2.fc9.noarch requires /usr/bin/pear php-pear-PhpDocumentor-1.4.1-2.fc9.noarch requires /bin/sh php-pear-SOAP-0.11.0-1.fc8.noarch requires /usr/bin/pear php-pear-SOAP-0.11.0-1.fc8.noarch requires /bin/sh php-pear-Services-Weather-1.4.2-1.fc7.noarch requires /usr/bin/pear php-pear-Services-Weather-1.4.2-1.fc7.noarch requires /bin/sh php-pear-Services-Weather-1.4.2-1.fc7.noarch requires /usr/bin/php php-pear-Structures-DataGrid-0.9.0-2.fc9.noarch requires /usr/bin/pear php-pear-Structures-DataGrid-0.9.0-2.fc9.noarch requires /bin/sh php-pear-Structures-DataGrid-DataSource-Array-0.1.4-1.fc9.noarch requires /usr/bin/pear php-pear-Structures-DataGrid-DataSource-Array-0.1.4-1.fc9.noarch requires /bin/sh php-pear-Structures-DataGrid-DataSource-DataObject-0.2.1-1.fc9.noarch requires /usr/bin/pear php-pear-Structures-DataGrid-DataSource-DataObject-0.2.1-1.fc9.noarch requires /bin/sh php-pear-Structures-DataGrid-DataSource-MDB2-0.1.11-1.fc9.noarch requires /usr/bin/pear php-pear-Structures-DataGrid-DataSource-MDB2-0.1.11-1.fc9.noarch requires /bin/sh php-pear-Structures-DataGrid-DataSource-RSS-0.1.1-1.fc7.noarch requires /usr/bin/pear php-pear-Structures-DataGrid-DataSource-RSS-0.1.1-1.fc7.noarch requires /bin/sh php-pear-Structures-DataGrid-Renderer-Pager-0.1.3-1.fc9.noarch requires /usr/bin/pear php-pear-Structures-DataGrid-Renderer-Pager-0.1.3-1.fc9.noarch requires /bin/sh php-pear-Structures-DataGrid-Renderer-Smarty-0.1.4-1.fc9.noarch requires /usr/bin/pear php-pear-Structures-DataGrid-Renderer-Smarty-0.1.4-1.fc9.noarch requires /bin/sh php-pear-Validate-0.8.1-1.fc9.noarch requires /usr/bin/pear php-pear-Validate-0.8.1-1.fc9.noarch requires /bin/sh php-pear-Validate-Finance-CreditCard-0.5.2-1.fc6.noarch requires /usr/bin/pear php-pear-Validate-Finance-CreditCard-0.5.2-1.fc6.noarch requires /bin/sh php-pear-XML-Beautifier-1.1-2.fc7.noarch requires /usr/bin/pear php-pear-XML-Beautifier-1.1-2.fc7.noarch requires /bin/sh php-pear-XML-Parser-1.2.8-2.fc8.noarch requires /bin/sh php-pear-XML-Parser-1.2.8-2.fc8.noarch requires /usr/bin/pear php-pear-XML-RSS-0.9.10-3.fc7.noarch requires /usr/bin/pear php-pear-XML-RSS-0.9.10-3.fc7.noarch requires /bin/sh php-pear-XML-Serializer-0.18.0-3.fc7.noarch requires /usr/bin/pear php-pear-XML-Serializer-0.18.0-3.fc7.noarch requires /bin/sh php-pear-XML-Util-1.1.4-2.fc7.noarch requires /usr/bin/pear php-pear-XML-Util-1.1.4-2.fc7.noarch requires /bin/sh php-pear-creole-1.1.0-5.fc8.noarch requires /usr/bin/pear php-pear-creole-1.1.0-5.fc8.noarch requires /bin/sh php-pear-pake-1.1.4-3.fc9.noarch requires /bin/sh php-pear-pake-1.1.4-3.fc9.noarch requires /usr/bin/pear php-pear-pake-1.1.4-3.fc9.noarch requires /bin/sh php-pear-phing-2.3.0-1.fc9.noarch requires /bin/sh php-pear-phing-2.3.0-1.fc9.noarch requires /usr/bin/pear php-pear-phing-2.3.0-1.fc9.noarch requires /bin/sh php-pecl-mailparse-2.1.4-1.fc9.i386 requires /bin/sh php-pecl-mailparse-2.1.4-1.fc9.i386 requires /usr/bin/pecl php-pecl-memcache-2.2.3-1.fc9.i386 requires /bin/sh php-pecl-memcache-2.2.3-1.fc9.i386 requires /usr/bin/pecl php-pecl-phar-1.2.3-3.fc9.i386 requires /bin/sh php-pecl-phar-1.2.3-3.fc9.i386 requires /usr/bin/pecl php-pecl-phar-1.2.3-3.fc9.i386 requires /usr/bin/php php-pecl-radius-1.2.5-5.fc10.i386 requires /bin/sh php-pecl-radius-1.2.5-5.fc10.i386 requires /usr/bin/pecl php-pecl-xdebug-2.0.2-4.fc9.i386 requires /bin/sh php-pecl-xdebug-2.0.2-4.fc9.i386 requires /usr/bin/pecl phpMyAdmin-2.11.6-1.fc10.noarch requires /usr/bin/perl phpMyAdmin-2.11.6-1.fc10.noarch requires /bin/bash phpMyAdmin-2.11.6-1.fc10.noarch requires /bin/sh phpPgAdmin-4.2-1.fc9.noarch requires /bin/sh phpPgAdmin-4.2-1.fc9.noarch requires /usr/bin/awk phpPgAdmin-4.2-1.fc9.noarch requires /sbin/service phpPgAdmin-4.2-1.fc9.noarch requires /bin/bash phpPgAdmin-4.2-1.fc9.noarch requires /usr/bin/php phpTodo-0.8.1-0.8.beta.fc8.noarch requires /bin/sh phpcs-1.0.1-1.fc9.noarch requires /usr/bin/php phpdoc-1.4.1-2.fc9.noarch requires /usr/bin/php phpldapadmin-1.1.0.5-1.fc9.noarch requires /bin/sh phpwapmail-0.9.2-1.fc9.noarch requires /bin/sh physfs-1.0.1-8.fc9.i386 requires /sbin/ldconfig pic2aa-0.2.1-3.fc9.i386 requires /bin/sh picard-0.9.0-6.fc9.i386 requires /usr/bin/python piccolo-1.04-3jpp.2.fc9.i386 requires /bin/sh pida-0.5.1-6.fc9.i386 requires /usr/bin/env pida-0.5.1-6.fc9.i386 requires /usr/bin/python pida-0.5.1-6.fc9.i386 requires /bin/sh pidgin-2.4.1-3.fc10.i386 requires /bin/sh pigment-0.3.5-1.fc9.i386 requires /sbin/ldconfig piklab-0.15.0-1.fc9.i386 requires /bin/sh pikloops-0.2.5-3.fc9.i386 requires /bin/sh 2:pilot-link-0.12.3-13.fc9.i386 requires /usr/bin/env 2:pilot-link-0.12.3-13.fc9.i386 requires /sbin/ldconfig 2:pilot-link-0.12.3-13.fc9.i386 requires /usr/bin/perl pils-2.1.3-1.fc9.i386 requires /sbin/ldconfig pinball-0.3.1-11.fc9.i386 requires /bin/sh pinentry-0.7.4-5.fc9.i386 requires /bin/sh pinentry-0.7.4-5.fc9.i386 requires /usr/sbin/update-alternatives pinentry-0.7.4-5.fc9.i386 requires /sbin/install-info pinentry-gtk-0.7.4-5.fc9.i386 requires /usr/sbin/update-alternatives pinentry-gtk-0.7.4-5.fc9.i386 requires /bin/sh pinentry-qt-0.7.4-5.fc9.i386 requires /bin/sh pinentry-qt-0.7.4-5.fc9.i386 requires /usr/sbin/update-alternatives pinfo-0.6.9-7.fc9.i386 requires /bin/sh pingus-0.7.2-3.fc9.i386 requires /bin/sh pingus-0.7.2-3.fc9.i386 requires /usr/bin/guile pinot-0.85-1.fc10.i386 requires /bin/sh pioneers-0.12.2-1.fc10.i386 requires /bin/sh pipenightdreams-0.10.0-8.fc9.i386 requires /bin/sh pipepanic-0.1.3-5.fc9.i386 requires /bin/sh pitivi-0.11.1-2.fc9.noarch requires /usr/bin/env pixman-0.10.0-1.fc9.i386 requires /sbin/ldconfig pl-5.6.47-7.fc9.i386 requires /bin/bash plague-0.4.4.1-4.fc7.noarch requires /bin/sh plague-0.4.4.1-4.fc7.noarch requires /bin/bash plague-0.4.4.1-4.fc7.noarch requires /sbin/chkconfig plague-0.4.4.1-4.fc7.noarch requires /usr/bin/python plague-0.4.4.1-4.fc7.noarch requires /sbin/service plague-builder-0.4.4.1-4.fc7.noarch requires /bin/sh plague-builder-0.4.4.1-4.fc7.noarch requires /bin/bash plague-builder-0.4.4.1-4.fc7.noarch requires /sbin/chkconfig plague-builder-0.4.4.1-4.fc7.noarch requires /usr/sbin/useradd plague-builder-0.4.4.1-4.fc7.noarch requires /usr/bin/python plague-builder-0.4.4.1-4.fc7.noarch requires /sbin/service plague-client-0.4.4.1-4.fc7.noarch requires /usr/bin/python plague-utils-0.4.4.1-4.fc7.noarch requires /usr/bin/python planet-2.0-5.fc9.noarch requires /usr/bin/python planets-0.1.13-2.fc9.i386 requires /bin/sh planner-0.14.3-2.fc10.i386 requires /usr/bin/scrollkeeper-update planner-0.14.3-2.fc10.i386 requires /bin/sh plexus-ant-factory-1.0-0.2.a1.1jpp.6.fc9.i386 requires /bin/sh plexus-ant-factory-javadoc-1.0-0.2.a1.1jpp.6.fc9.i386 requires /bin/rm plexus-ant-factory-javadoc-1.0-0.2.a1.1jpp.6.fc9.i386 requires /bin/ls plexus-appserver-1.0-0.2.a5.2jpp.4.fc9.i386 requires /bin/sh plexus-archiver-1.0-0.2.a7.1jpp.1.fc9.i386 requires /bin/sh plexus-bsh-factory-1.0-0.2.a7s.1jpp.6.fc9.i386 requires /bin/sh plexus-cdc-1.0-0.2.a4.1jpp.4.fc9.i386 requires /bin/sh plexus-i18n-1.0-0.b6.5jpp.2.fc9.noarch requires /bin/sh plexus-maven-plugin-1.2-2jpp.3.fc9.i386 requires /bin/sh plexus-runtime-builder-1.0-0.2.a9.1jpp.3.fc9.i386 requires /bin/sh plexus-velocity-1.1.2-3jpp.1.fc9.i386 requires /bin/sh plexus-xmlrpc-1.0-0.2.b4.2jpp.7.fc9.i386 requires /bin/sh plib-1.8.5-1.fc10.i386 requires /sbin/ldconfig plotmm-0.1.2-6.fc9.i386 requires /sbin/ldconfig plotutils-2.5-5.fc9.i386 requires /bin/sh plotutils-2.5-5.fc9.i386 requires /sbin/install-info plotutils-2.5-5.fc9.i386 requires /sbin/ldconfig plplot-5.9.0-1.fc9.i386 requires /usr/bin/env plplot-5.9.0-1.fc9.i386 requires /sbin/install-info plplot-5.9.0-1.fc9.i386 requires /sbin/ldconfig plplot-5.9.0-1.fc9.i386 requires /bin/bash plplot-5.9.0-1.fc9.i386 requires /bin/sh plplot-5.9.0-1.fc9.i386 requires /bin/sh plplot-ada-5.9.0-1.fc9.i386 requires /sbin/ldconfig plplot-ada-devel-5.9.0-1.fc9.i386 requires /bin/bash plplot-devel-5.9.0-1.fc9.i386 requires /bin/bash plplot-gnome-5.9.0-1.fc9.i386 requires /sbin/ldconfig plplot-java-devel-5.9.0-1.fc9.i386 requires /bin/bash plplot-octave-5.9.0-1.fc9.i386 requires /sbin/ldconfig plplot-octave-5.9.0-1.fc9.i386 requires /bin/bash plplot-perl-5.9.0-1.fc9.i386 requires /bin/bash plplot-perl-5.9.0-1.fc9.i386 requires /usr/bin/env plplot-tk-5.9.0-1.fc9.i386 requires /sbin/ldconfig plplot-tk-devel-5.9.0-1.fc9.i386 requires /bin/sh plt-scheme-372-1.fc9.i386 requires /bin/bash plt-scheme-372-1.fc9.i386 requires /bin/sh pm-utils-1.1.1-2.fc10.i386 requires /bin/sh pm-utils-1.1.1-2.fc10.i386 requires /bin/bash pm-utils-1.1.1-2.fc10.i386 requires /bin/sh pmd-3.6-1jpp.3.fc7.noarch requires /bin/bash pmount-0.9.17-2.fc9.i386 requires /bin/mount 1:pnm2ppa-1.04-15.fc9.i386 requires /bin/sh po4a-0.32-4.fc8.noarch requires /usr/bin/perl po4a-0.32-4.fc8.noarch requires /bin/sh podsleuth-0.6.0-5.fc10.i386 requires /bin/bash poedit-1.3.9-2.fc9.i386 requires /bin/sh poker-bot-1.5.0-1.fc10.noarch requires /bin/sh poker-bot-1.5.0-1.fc10.noarch requires /sbin/chkconfig poker-bot-1.5.0-1.fc10.noarch requires /bin/sh poker-bot-1.5.0-1.fc10.noarch requires /usr/bin/python poker-bot-1.5.0-1.fc10.noarch requires /sbin/service poker-engine-1.2.0-1.fc10.noarch requires /usr/bin/python poker-eval-134.0-2.fc9.i386 requires /sbin/ldconfig poker-network-selinux-1.5.0-1.fc10.noarch requires /usr/sbin/semodule poker-network-selinux-1.5.0-1.fc10.noarch requires /sbin/fixfiles poker-network-selinux-1.5.0-1.fc10.noarch requires /bin/sh poker-network-selinux-1.5.0-1.fc10.noarch requires /usr/sbin/semanage poker-network-selinux-1.5.0-1.fc10.noarch requires /usr/sbin/setsebool poker-network-selinux-1.5.0-1.fc10.noarch requires /sbin/service poker-server-1.5.0-1.fc10.noarch requires /bin/sh poker-server-1.5.0-1.fc10.noarch requires /sbin/chkconfig poker-server-1.5.0-1.fc10.noarch requires /bin/sh poker-server-1.5.0-1.fc10.noarch requires /usr/bin/python poker-server-1.5.0-1.fc10.noarch requires /sbin/service poker-web-1.5.0-1.fc10.noarch requires /bin/sh poker2d-1.5.0-1.fc10.i386 requires /usr/bin/python2.5 poker2d-1.5.0-1.fc10.i386 requires /bin/sh poker3d-1.1.36-10.fc10.i386 requires /bin/sh poker3d-1.1.36-10.fc10.i386 requires /usr/libexec/poker3d/underware poker3d-1.1.36-10.fc10.i386 requires /bin/sh policycoreutils-2.0.49-2.fc10.i386 requires /bin/sh policycoreutils-2.0.49-2.fc10.i386 requires /bin/sed policycoreutils-2.0.49-2.fc10.i386 requires /bin/awk policycoreutils-2.0.49-2.fc10.i386 requires /usr/bin/python policycoreutils-2.0.49-2.fc10.i386 requires /sbin/service policycoreutils-2.0.49-2.fc10.i386 requires /usr/bin/diff policycoreutils-2.0.49-2.fc10.i386 requires /bin/mount policycoreutils-2.0.49-2.fc10.i386 requires /bin/egrep policycoreutils-2.0.49-2.fc10.i386 requires /bin/bash policycoreutils-2.0.49-2.fc10.i386 requires /bin/sh policycoreutils-2.0.49-2.fc10.i386 requires /sbin/chkconfig policycoreutils-gui-2.0.49-2.fc10.i386 requires /usr/bin/python polyml-libs-5.1-4.fc9.i386 requires /sbin/ldconfig pop-before-smtp-1.41-2.fc6.noarch requires /bin/sh pop-before-smtp-1.41-2.fc6.noarch requires /usr/bin/perl pop-before-smtp-1.41-2.fc6.noarch requires /bin/sh popt-1.13-3.fc9.i386 requires /sbin/ldconfig portaudio-19-5.fc9.i386 requires /sbin/ldconfig portecle-1.3-3.fc9.noarch requires /bin/sh portecle-1.3-3.fc9.noarch requires /bin/sh 2:postfix-2.5.1-2.fc9.i386 requires /bin/sh 2:postfix-2.5.1-2.fc9.i386 requires /usr/sbin/alternatives 2:postfix-2.5.1-2.fc9.i386 requires /usr/sbin/groupadd 2:postfix-2.5.1-2.fc9.i386 requires /usr/sbin/useradd 2:postfix-2.5.1-2.fc9.i386 requires /sbin/service 2:postfix-2.5.1-2.fc9.i386 requires /bin/bash 2:postfix-2.5.1-2.fc9.i386 requires /bin/sh 2:postfix-2.5.1-2.fc9.i386 requires /usr/bin/perl 2:postfix-2.5.1-2.fc9.i386 requires /sbin/chkconfig 2:postfix-pflogsumm-2.5.1-2.fc9.i386 requires /usr/bin/perl postgis-1.3.3-1.fc9.i386 requires /usr/bin/rebuild-gcj-db postgis-jdbc-1.3.3-1.fc9.i386 requires /usr/bin/rebuild-gcj-db postgresql-devel-8.3.1-3.fc10.i386 requires /bin/sh postgresql-jdbc-8.3.603-1jpp.fc9.i386 requires /bin/sh postgresql-jdbc-8.3.603-1jpp.fc9.i386 requires /usr/bin/rebuild-gcj-db postgresql-libs-8.3.1-3.fc10.i386 requires /sbin/ldconfig postgresql-odbc-08.03.0100-1.fc9.i386 requires /sbin/ldconfig postgresql-pgpool-3.4.1-2.fc9.1.i386 requires /bin/sh postgresql-pgpool-II-2.1-0.2.beta2.fc9.i386 requires /bin/sh postgresql-pgpool-II-2.1-0.2.beta2.fc9.i386 requires /sbin/ldconfig postgresql-pgpool-II-2.1-0.2.beta2.fc9.i386 requires /bin/sh postgresql-pgpoolAdmin-1.0.0-7.fc8.noarch requires /bin/sh postgresql-plperl-8.3.1-3.fc10.i386 requires /sbin/ldconfig postgresql-plpython-8.3.1-3.fc10.i386 requires /sbin/ldconfig postgresql-pltcl-8.3.1-3.fc10.i386 requires /sbin/ldconfig postgresql-pltcl-8.3.1-3.fc10.i386 requires /bin/sh postgresql-python-8.3.1-3.fc10.i386 requires /usr/bin/env postgresql-server-8.3.1-3.fc10.i386 requires /bin/sh postgresql-server-8.3.1-3.fc10.i386 requires /usr/sbin/useradd postgresql-server-8.3.1-3.fc10.i386 requires /bin/sh postgresql-server-8.3.1-3.fc10.i386 requires /sbin/chkconfig postgresql-table_log-0.4.4-4.fc9.1.i386 requires /sbin/ldconfig postgresql-test-8.3.1-3.fc10.i386 requires /bin/sh postgresql-test-8.3.1-3.fc10.i386 requires /bin/sh postgresql_autodoc-1.31-1.fc9.noarch requires /usr/bin/perl postgrey-1.30-1.fc8.noarch requires /bin/sh postgrey-1.30-1.fc8.noarch requires /usr/sbin/useradd postgrey-1.30-1.fc8.noarch requires /sbin/service postgrey-1.30-1.fc8.noarch requires /usr/bin/perl postgrey-1.30-1.fc8.noarch requires /bin/sh postgrey-1.30-1.fc8.noarch requires /sbin/chkconfig postr-0.10-2.fc9.noarch requires /bin/sh postr-0.10-2.fc9.noarch requires /usr/bin/python powerman-1.0.32-5.fc9.i386 requires /bin/sh powerman-1.0.32-5.fc9.i386 requires /bin/sh powermanga-0.90-3.i386 requires /bin/sh ppl-0.9-19.fc9.i386 requires /sbin/ldconfig ppl-pwl-0.9-19.fc9.i386 requires /sbin/ldconfig ppp-2.4.4-7.fc10.i386 requires /etc/pam.d/system-auth pptp-1.7.2-1.fc10.i386 requires /usr/bin/perl prelink-0.4.0-3.i386 requires /bin/sh prelink-0.4.0-3.i386 requires /bin/sh preload-0.4-6.fc9.i386 requires /bin/sh preload-0.4-6.fc9.i386 requires /bin/bash preload-0.4-6.fc9.i386 requires /sbin/chkconfig preload-0.4-6.fc9.i386 requires /sbin/service prelude-lml-0.9.12.2-1.fc10.i386 requires /bin/sh prelude-lml-0.9.12.2-1.fc10.i386 requires /sbin/service prelude-lml-0.9.12.2-1.fc10.i386 requires /bin/sh prelude-lml-0.9.12.2-1.fc10.i386 requires /sbin/chkconfig prelude-manager-0.9.12.1-1.fc10.i386 requires /bin/sh prelude-manager-0.9.12.1-1.fc10.i386 requires /sbin/service prelude-manager-0.9.12.1-1.fc10.i386 requires /bin/sh prelude-manager-0.9.12.1-1.fc10.i386 requires /sbin/chkconfig presto-utils-0.3.2-1.fc8.noarch requires /bin/sh presto-utils-0.3.2-1.fc8.noarch requires /usr/bin/python preupgrade-0.9.3-3.fc10.noarch requires /bin/sh preupgrade-0.9.3-3.fc10.noarch requires /bin/sh preupgrade-0.9.3-3.fc10.noarch requires /usr/bin/python prewikka-0.9.14-1.fc10.noarch requires /bin/sh prewikka-0.9.14-1.fc10.noarch requires /usr/bin/python privoxy-3.0.8-2.fc9.i386 requires /bin/sh privoxy-3.0.8-2.fc9.i386 requires /sbin/service privoxy-3.0.8-2.fc9.i386 requires /bin/sh privoxy-3.0.8-2.fc9.i386 requires /sbin/chkconfig procinfo-18-23.fc9.i386 requires /usr/bin/perl procmail-3.22-21.fc9.i386 requires /bin/sh procps-3.2.7-20.fc9.i386 requires /sbin/ldconfig professor-is-missing-0.1-3.fc8.noarch requires /bin/sh professor-is-missing-0.1-3.fc8.noarch requires /bin/bash proftpd-1.3.1-3.fc9.i386 requires /bin/sh proftpd-1.3.1-3.fc9.i386 requires /sbin/service proftpd-1.3.1-3.fc9.i386 requires /bin/sh proftpd-1.3.1-3.fc9.i386 requires /sbin/chkconfig proj-4.6.0-1.fc10.i386 requires /sbin/ldconfig proj-nad-4.6.0-1.fc10.i386 requires /bin/bash proxychains-3.1-5.fc9.i386 requires /sbin/ldconfig proxychains-3.1-5.fc9.i386 requires /bin/sh proxyknife-1.7-3.fc9.i386 requires /bin/sh proxyknife-1.7-3.fc9.i386 requires /sbin/install-info ps2eps-1.64-4.fc9.i386 requires /usr/bin/perl psacct-6.3.2-50.fc9.i386 requires /bin/sh psacct-6.3.2-50.fc9.i386 requires /sbin/chkconfig psacct-6.3.2-50.fc9.i386 requires /bin/bash psacct-6.3.2-50.fc9.i386 requires /sbin/install-info pscan-1.3-1.fc9.i386 requires /bin/sh psgml-1.2.5-6.fc7.noarch requires /bin/sh psi-0.11-4.fc9.i386 requires /bin/sh psi-0.11-4.fc9.i386 requires /bin/sh psiconv-0.9.8-1.fc8.i386 requires /sbin/ldconfig psiconv-0.9.8-1.fc8.i386 requires libWand.so.10 psiconv-0.9.8-1.fc8.i386 requires libMagick.so.10 psiconv-devel-0.9.8-1.fc8.i386 requires /bin/sh pstoedit-3.45-3.fc10.i386 requires /sbin/ldconfig psutils-1.17-28.fc9.i386 requires /usr/bin/perl psutils-1.17-28.fc9.i386 requires /bin/sh pth-2.0.7-6.i386 requires /sbin/ldconfig pth-devel-2.0.7-6.i386 requires /bin/sh publican-0.33-0.fc9.noarch requires /usr/bin/perl publican-0.33-0.fc9.noarch requires /bin/env publican-0.33-0.fc9.noarch requires /usr/bin/env pulseaudio-0.9.11-0.0.svn20080516.fc10.i386 requires /bin/sh pulseaudio-0.9.11-0.0.svn20080516.fc10.i386 requires /sbin/ldconfig pulseaudio-esound-compat-0.9.11-0.0.svn20080516.fc10.i386 requires /bin/sh pulseaudio-libs-0.9.11-0.0.svn20080516.fc10.i386 requires /sbin/ldconfig pulseaudio-libs-glib2-0.9.11-0.0.svn20080516.fc10.i386 requires /sbin/ldconfig pulseaudio-libs-zeroconf-0.9.11-0.0.svn20080516.fc10.i386 requires /sbin/ldconfig pulseaudio-utils-0.9.11-0.0.svn20080516.fc10.i386 requires /bin/sh pungi-1.2.18-1.fc9.noarch requires /usr/bin/python puppet-0.24.4-1.fc9.noarch requires /bin/sh puppet-0.24.4-1.fc9.noarch requires /usr/bin/ruby puppet-0.24.4-1.fc9.noarch requires /bin/bash puppet-server-0.24.4-1.fc9.noarch requires /bin/sh puppet-server-0.24.4-1.fc9.noarch requires /bin/bash puppet-server-0.24.4-1.fc9.noarch requires /usr/bin/ruby pure-ftpd-1.0.21-15.fc9.i386 requires /bin/sh pure-ftpd-1.0.21-15.fc9.i386 requires /usr/bin/python pure-ftpd-1.0.21-15.fc9.i386 requires /usr/bin/perl pure-ftpd-1.0.21-15.fc9.i386 requires /bin/bash pure-ftpd-selinux-1.0.21-15.fc9.i386 requires /bin/sh puretls-0.9-0.2.b5.5jpp.1.fc9.i386 requires /bin/sh puretls-demo-0.9-0.2.b5.5jpp.1.fc9.i386 requires /bin/sh puretls-demo-0.9-0.2.b5.5jpp.1.fc9.i386 requires /usr/bin/perl pvm-3.4.5-9.fc9.i386 requires /bin/csh pvm-3.4.5-9.fc9.i386 requires /bin/sh pvm-3.4.5-9.fc9.i386 requires /bin/sh pvm-gui-3.4.5-9.fc9.i386 requires /bin/csh pvm-gui-3.4.5-9.fc9.i386 requires /bin/sh pwlib-1.10.10-6.fc9.i386 requires /sbin/ldconfig pwlib-devel-1.10.10-6.fc9.i386 requires /bin/sh pybackpack-0.5.4-2.fc9.noarch requires /usr/bin/python pybliographer-1.2.11-2.fc9.noarch requires /bin/sh pybliographer-1.2.11-2.fc9.noarch requires /bin/sh pybliographer-1.2.11-2.fc9.noarch requires /usr/bin/python pycairo-1.4.12-3.fc10.i386 requires /usr/bin/env pychecker-0.8.17-4.noarch requires /bin/sh pychess-0.8-2.fc9.noarch requires /usr/bin/python pychess-0.8-2.fc9.noarch requires /usr/bin/env pydict-0.3.0-11.fc8.noarch requires /bin/sh pyflakes-0.2.1-3.fc7.noarch requires /usr/bin/python pyflowtools-0.3.3-1.fc9.i386 requires /usr/bin/env pygsl-0.9.1-8.fc9.i386 requires /usr/bin/env pygtk2-2.12.1-6.fc9.i386 requires /usr/bin/env pygtk2-2.12.1-6.fc9.i386 requires /usr/bin/python pygtk2-codegen-2.12.1-6.fc9.i386 requires /bin/sh pygtkglext-1.1.0-4.fc9.i386 requires /usr/bin/env pyicq-t-0.8-4.b.fc9.noarch requires /bin/sh pyicq-t-0.8-4.b.fc9.noarch requires /bin/bash pyicq-t-0.8-4.b.fc9.noarch requires /sbin/chkconfig pyicq-t-0.8-4.b.fc9.noarch requires /usr/bin/env pyicq-t-0.8-4.b.fc9.noarch requires /sbin/service pyjigdo-0.3.0-1.fc10.noarch requires /usr/bin/python pykickstart-1.34-1.fc10.noarch requires /usr/bin/python pylint-0.14.0-1.fc9.noarch requires /usr/bin/python pylint-gui-0.14.0-1.fc9.noarch requires /usr/bin/python pypar2-1.4-1.fc8.noarch requires /bin/sh pypar2-1.4-1.fc8.noarch requires /usr/bin/python pypoker-eval-135.0-1.fc9.i386 requires /sbin/ldconfig pyscript-0.6.1-2.fc9.noarch requires /usr/bin/python python-2.5.1-25.fc9.i386 requires /bin/sh python-2.5.1-25.fc9.i386 requires /usr/bin/python2.5 python-2.5.1-25.fc9.i386 requires /usr/bin/env python-4Suite-XML-1.0.2-3.i386 requires /usr/bin/env python-Coherence-0.5.0-1.fc9.noarch requires /usr/bin/python python-ZSI-2.0-3.fc9.noarch requires /usr/bin/env python-ZSI-2.0-3.fc9.noarch requires /usr/bin/python python-amara-1.2.0.2-2.fc8.noarch requires /usr/bin/python python-bugzilla-0.3-1.fc9.noarch requires /usr/bin/python python-cheetah-2.0.1-2.fc9.i386 requires /usr/bin/python python-clientform-0.2.7-2.fc9.noarch requires /usr/bin/env python-demjson-1.3-2.fc9.noarch requires /usr/bin/python python-devel-2.5.1-25.fc9.i386 requires /bin/sh python-dialog-2.7-7.fc8.noarch requires /usr/bin/env python-docutils-0.4-8.fc9.noarch requires /usr/bin/python python-durus-3.5-3.fc7.i386 requires /usr/bin/python python-exif-1.0.7-4.fc9.noarch requires /bin/bash python-exif-1.0.7-4.fc9.noarch requires /usr/bin/env python-eyed3-0.6.15-1.fc9.noarch requires /usr/bin/env python-formencode-1.0-1.fc9.noarch requires /bin/sh python-formencode-1.0-1.fc9.noarch requires /usr/bin/python python-igraph-0.5-5.fc9.i386 requires /usr/bin/python python-imaging-devel-1.1.6-9.fc9.i386 requires /usr/bin/env python-imaging-devel-1.1.6-9.fc9.i386 requires /usr/bin/python python-inotify-examples-0.7.1-2.fc9.i386 requires /bin/sh python-inotify-examples-0.7.1-2.fc9.i386 requires /usr/bin/env python-kaa-metadata-0.7.3-1.fc9.i386 requires /usr/bin/python python-kid-0.9.6-2.fc8.noarch requires /usr/bin/env python-kiwi-1.9.21-1.fc10.noarch requires /usr/bin/python python-kiwi-docs-1.9.21-1.fc10.noarch requires /usr/bin/env python-libgmail-0.1.8-2.fc9.noarch requires /usr/bin/env python-libgmail-docs-0.3-6.fc9.noarch requires /usr/bin/env python-libs-2.5.1-25.fc9.i386 requires /sbin/ldconfig python-logilab-common-0.28.0-1.fc9.noarch requires /usr/bin/python python-matplotlib-0.91.2-2.fc9.i386 requires /usr/bin/env python-mechanize-0.1.6-0.2.b.fc9.noarch requires /usr/bin/python python-musicbrainz2-0.5.0-2.fc9.noarch requires /usr/bin/python python-mutagen-1.13-2.fc9.noarch requires /usr/bin/python python-nevow-0.9.29-2.fc9.noarch requires /usr/bin/python 1:python-nltk-0.9.2-1.fc9.noarch requires /usr/bin/env 1:python-nltk-0.9.2-1.fc9.noarch requires /usr/bin/python python-nose-0.10.1-1.fc9.noarch requires /usr/bin/python python-numarray-1.5.2-6.fc9.i386 requires /usr/bin/env python-numarray-1.5.2-6.fc9.i386 requires /bin/sh python-paste-script-1.6.2-2.fc9.noarch requires /usr/bin/env python-paste-script-1.6.2-2.fc9.noarch requires /usr/bin/python python-pp-1.5.3-1.fc9.noarch requires /usr/bin/python python-pyblock-0.31-2.i386 requires /usr/bin/python python-pygments-0.9-2.fc9.noarch requires /usr/bin/python python-pyspf-2.0.3-1.fc8.noarch requires /usr/bin/python python-qpid-0.2-10.fc9.noarch requires /usr/bin/env python-setuptools-0.6c7-2.fc8.noarch requires /usr/bin/python python-setuptools-devel-0.6c7-2.fc8.noarch requires /usr/bin/python python-simpletal-4.1-5.fc7.noarch requires /usr/bin/python python-sqlobject-0.10.1-1.fc10.noarch requires /usr/bin/python python-tag-0.94.1-1.fc10.i386 requires /usr/bin/env python-test-2.5.1-25.fc9.i386 requires /usr/bin/env python-tools-2.5.1-25.fc9.i386 requires /bin/bash python-tools-2.5.1-25.fc9.i386 requires /usr/bin/env python-tools-2.5.1-25.fc9.i386 requires /bin/sh python-tools-2.5.1-25.fc9.i386 requires /usr/bin/python python-tpg-3.1.0-4.fc7.noarch requires /usr/bin/python python-tunepimp-0.5.3-11.fc9.i386 requires /usr/bin/env python-twisted-conch-0.8.0-4.fc9.i386 requires /usr/libexec/twisted-dropin-cache python-twisted-conch-0.8.0-4.fc9.i386 requires /usr/bin/python python-twisted-core-2.5.0-4.fc9.i386 requires /usr/libexec/twisted-dropin-cache python-twisted-core-2.5.0-4.fc9.i386 requires /usr/bin/env python-twisted-core-2.5.0-4.fc9.i386 requires /usr/bin/python python-twisted-lore-0.2.0-6.fc9.i386 requires /usr/libexec/twisted-dropin-cache python-twisted-lore-0.2.0-6.fc9.i386 requires /usr/bin/python python-twisted-mail-0.4.0-4.fc9.i386 requires /usr/libexec/twisted-dropin-cache python-twisted-mail-0.4.0-4.fc9.i386 requires /bin/sh python-twisted-mail-0.4.0-4.fc9.i386 requires /usr/bin/python python-twisted-names-0.4.0-3.fc9.i386 requires /usr/libexec/twisted-dropin-cache python-twisted-news-0.3.0-3.fc9.i386 requires /usr/libexec/twisted-dropin-cache python-twisted-web-0.7.0-3.fc9.i386 requires /usr/libexec/twisted-dropin-cache python-twisted-words-0.5.0-3.fc9.i386 requires /usr/libexec/twisted-dropin-cache python-twisted-words-0.5.0-3.fc9.i386 requires /usr/bin/python python-twyt-0.8-1.fc9.noarch requires /usr/bin/python python-urlgrabber-3.0.0-7.fc10.noarch requires /usr/bin/python python-virtinst-0.300.3-6.fc10.noarch requires /usr/bin/python python-vobject-0.6.0-2.fc9.noarch requires /usr/bin/python python-which-1.1.0-3.fc9.noarch requires /bin/sh pyzor-0.4.0-11.fc7.noarch requires /usr/bin/python q-7.10-3.fc9.i386 requires /bin/sh q-7.10-3.fc9.i386 requires /sbin/install-info q-7.10-3.fc9.i386 requires /sbin/ldconfig q-7.10-3.fc9.i386 requires /bin/sh q-7.10-3.fc9.i386 requires libMagick.so.10 q-devel-7.10-3.fc9.i386 requires /bin/sh qa-assistant-0.4.90.5-2.fc6.noarch requires /bin/sh qa-assistant-0.4.90.5-2.fc6.noarch requires /usr/bin/xmlcatalog qa-assistant-0.4.90.5-2.fc6.noarch requires /usr/bin/python qalculate-gtk-0.9.6-4.fc9.i386 requires /bin/sh qalculate-kde-0.9.6-5.fc9.i386 requires /bin/sh qascade-0.1-10.fc9.i386 requires /bin/sh qbanking-2.3.3-3.fc9.i386 requires /sbin/ldconfig qbanking-devel-2.3.3-3.fc9.i386 requires /bin/sh qca-1.0-10.fc9.i386 requires /sbin/ldconfig qca2-2.0.0-2.fc9.i386 requires /sbin/ldconfig qcad-2.0.5.0-8.fc9.i386 requires /bin/sh qct-1.5-6.fc9.i386 requires /usr/bin/env qct-1.5-6.fc9.i386 requires /usr/bin/python qdbm-1.8.77-3.fc9.i386 requires /sbin/ldconfig qdbm++-1.8.77-3.fc9.i386 requires /sbin/ldconfig qdbm-java-1.8.77-3.fc9.i386 requires /sbin/ldconfig qdbm-perl-1.8.77-3.fc9.i386 requires /usr/bin/perl qemu-0.9.1-7.fc10.i386 requires /bin/sh qemu-0.9.1-7.fc10.i386 requires /sbin/service qemu-0.9.1-7.fc10.i386 requires /bin/sh qemu-0.9.1-7.fc10.i386 requires /sbin/chkconfig qemu-launcher-1.7.4-4.fc9.noarch requires /bin/sh qemu-launcher-1.7.4-4.fc9.noarch requires /usr/bin/perl qfaxreader-0.3.1-9.fc9.3.i386 requires /bin/sh qgis-0.9.1-5.fc9.i386 requires libgeos.so.2 qgis-0.9.1-5.fc9.i386 requires /usr/bin/python qgis-0.9.1-5.fc9.i386 requires /sbin/ldconfig qgis-grass-0.9.1-5.fc9.i386 requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.i386 requires /sbin/ldconfig qhull-2003.1-10.fc9.i386 requires /sbin/ldconfig qimageblitz-0.0.4-0.4.svn706674.fc9.i386 requires /sbin/ldconfig qiv-2.0-9.fc9.i386 requires /bin/sh qjackctl-0.3.1a-6.fc9.i386 requires /bin/sh qmmp-0.1.5-2.fc9.i386 requires /bin/sh qmmp-0.1.5-2.fc9.i386 requires /sbin/ldconfig qof-0.7.5-2.fc9.i386 requires /sbin/ldconfig qpidc-0.2-26.fc9.i386 requires /bin/sh qpidc-0.2-26.fc9.i386 requires /sbin/service qpidc-0.2-26.fc9.i386 requires /sbin/ldconfig qpidc-0.2-26.fc9.i386 requires /sbin/chkconfig qpidd-0.2-26.fc9.i386 requires /bin/sh qpidd-0.2-26.fc9.i386 requires /bin/bash qpxtool-0.6.1-9.fc9.i386 requires /sbin/ldconfig qscintilla-2.2-1.fc10.i386 requires /sbin/ldconfig qstars-0.4-6.fc9.i386 requires /bin/sh qstars-xscreensaver-0.4-6.fc9.i386 requires /bin/sh qsynth-0.2.5-7.fc9.i386 requires /bin/sh 1:qt-4.4.0-3.fc10.i386 requires /sbin/ldconfig 1:qt-4.4.0-3.fc10.i386 requires /bin/bash 1:qt-devel-4.4.0-3.fc10.i386 requires /bin/sh 1:qt-devel-4.4.0-3.fc10.i386 requires /bin/bash 1:qt-doc-4.4.0-3.fc10.i386 requires /bin/bash qt-qsa-1.1.5-5.fc9.i386 requires /sbin/ldconfig qt-recordmydesktop-0.3.7-1.fc9.noarch requires /usr/bin/python 1:qt-x11-4.4.0-3.fc10.i386 requires /bin/sh 1:qt-x11-4.4.0-3.fc10.i386 requires /bin/bash qt3-3.3.8b-12.fc9.i386 requires /etc/ld.so.conf.d qt3-3.3.8b-12.fc9.i386 requires /sbin/ldconfig qt3-devel-3.3.8b-12.fc9.i386 requires /usr/bin/perl qtpfsgui-1.9.2-1.fc10.i386 requires /bin/sh quagga-0.99.9-6.fc9.i386 requires /bin/sh quagga-0.99.9-6.fc9.i386 requires /sbin/install-info quagga-0.99.9-6.fc9.i386 requires /bin/bash quagga-contrib-0.99.9-6.fc9.i386 requires /usr/bin/perl quake3-1.34-0.9.rc4.fc9.i386 requires /bin/bash quake3-demo-1.34-0.9.rc4.fc9.i386 requires /bin/sh quake3-demo-1.34-0.9.rc4.fc9.i386 requires /bin/bash quarry-0.2.0-3.fc9.i386 requires /bin/sh qucs-0.0.14-1.fc9.i386 requires /usr/bin/perl qucs-0.0.14-1.fc9.i386 requires /bin/sh quesa-1.8-1.fc9.i386 requires /sbin/ldconfig quesoglc-0.7.1-1.fc10.i386 requires /sbin/ldconfig queuegraph-1.1-3.fc9.noarch requires /usr/bin/perl queuegraph-1.1-3.fc9.noarch requires /bin/sh queuegraph-selinux-1.1-3.fc9.noarch requires /usr/sbin/semodule queuegraph-selinux-1.1-3.fc9.noarch requires /sbin/fixfiles queuegraph-selinux-1.1-3.fc9.noarch requires /bin/sh queuegraph-selinux-1.1-3.fc9.noarch requires /sbin/restorecon quilt-0.46-5.fc9.i386 requires /usr/bin/perl quilt-0.46-5.fc9.i386 requires /bin/bash quodlibet-1.0-3.fc9.i386 requires /usr/bin/env qwt-5.0.2-6.fc9.i386 requires /sbin/ldconfig qwtplot3d-0.2.7-6.fc9.i386 requires /sbin/ldconfig qwtplot3d-qt4-0.2.7-6.fc9.i386 requires /sbin/ldconfig radiusclient-ng-0.5.6-3.fc9.i386 requires /sbin/ldconfig radiusclient-ng-utils-0.5.6-3.fc9.i386 requires /bin/sh radvd-1.1-3.fc10.i386 requires /usr/sbin/userdel radvd-1.1-3.fc10.i386 requires /bin/sh radvd-1.1-3.fc10.i386 requires /usr/sbin/useradd radvd-1.1-3.fc10.i386 requires /bin/sh rafkill-1.2.2-7.fc9.i386 requires /bin/sh raidem-0.3.1-8.fc9.i386 requires /bin/sh raptor-1.4.16-2.fc9.i386 requires /sbin/ldconfig raptor-devel-1.4.16-2.fc9.i386 requires /bin/sh rarian-0.8.0-1.fc9.i386 requires /sbin/ldconfig rarian-compat-0.8.0-1.fc9.i386 requires /bin/sh rarian-compat-0.8.0-1.fc9.i386 requires /bin/bash rarian-compat-0.8.0-1.fc9.i386 requires /bin/sh rarpd-ss981107-26.1.fc9.i386 requires /bin/sh rarpd-ss981107-26.1.fc9.i386 requires /bin/bash rarpd-ss981107-26.1.fc9.i386 requires /sbin/chkconfig rasqal-0.9.15-1.fc9.i386 requires /sbin/ldconfig rasqal-devel-0.9.15-1.fc9.i386 requires /bin/sh ratpoison-1.4.1-2.fc9.i386 requires /bin/sh ratpoison-1.4.1-2.fc9.i386 requires /usr/bin/perl ratpoison-1.4.1-2.fc9.i386 requires /bin/bash ratpoison-1.4.1-2.fc9.i386 requires /sbin/install-info ratpoison-1.4.1-2.fc9.i386 requires /bin/sh rawstudio-1.0-1.fc10.i386 requires /bin/sh raydium-1.2-8.fc9.i386 requires /sbin/ldconfig rb_libtorrent-0.12.1-1.fc9.i386 requires /sbin/ldconfig rblcheck-1.5-15.fc9.i386 requires /bin/sh rbldnsd-0.996b-1.fc9.i386 requires /bin/sh rbldnsd-0.996b-1.fc9.i386 requires /bin/bash rbldnsd-0.996b-1.fc9.i386 requires /sbin/chkconfig rdiff-backup-1.0.5-7.fc9.i386 requires /usr/bin/python 1:readahead-1.4.2-5.fc9.i386 requires /bin/sh 1:readahead-1.4.2-5.fc9.i386 requires /bin/gawk 1:readahead-1.4.2-5.fc9.i386 requires /sbin/service 1:readahead-1.4.2-5.fc9.i386 requires /bin/bash 1:readahead-1.4.2-5.fc9.i386 requires /bin/sh 1:readahead-1.4.2-5.fc9.i386 requires /sbin/chkconfig readline-5.2-13.fc9.i386 requires /bin/sh readline-5.2-13.fc9.i386 requires /sbin/ldconfig readline-5.2-13.fc9.i386 requires /sbin/install-info readline-devel-5.2-13.fc9.i386 requires /bin/sh readline-devel-5.2-13.fc9.i386 requires /sbin/install-info recode-3.6-26.fc9.i386 requires /bin/sh recode-3.6-26.fc9.i386 requires /sbin/ldconfig recode-3.6-26.fc9.i386 requires /sbin/install-info redet-8.23-3.fc9.noarch requires /bin/sh redet-8.23-3.fc9.noarch requires /bin/sh redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/tty redhat-lsb-3.1-19.fc8.i386 requires /bin/cp redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/uniq redhat-lsb-3.1-19.fc8.i386 requires /bin/dd redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/pax redhat-lsb-3.1-19.fc8.i386 requires /bin/stty redhat-lsb-3.1-19.fc8.i386 requires /bin/ls redhat-lsb-3.1-19.fc8.i386 requires /bin/echo redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/tee redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/id redhat-lsb-3.1-19.fc8.i386 requires /bin/gzip redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/ipcrm redhat-lsb-3.1-19.fc8.i386 requires /bin/mknod redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/chfn redhat-lsb-3.1-19.fc8.i386 requires /bin/gettext redhat-lsb-3.1-19.fc8.i386 requires /bin/more redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/nohup redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/patch redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/make redhat-lsb-3.1-19.fc8.i386 requires /bin/touch redhat-lsb-3.1-19.fc8.i386 requires /bin/pwd redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/mkfifo redhat-lsb-3.1-19.fc8.i386 requires /bin/mv redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/join redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/fold redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/col redhat-lsb-3.1-19.fc8.i386 requires /bin/tar redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/msgfmt redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/tsort redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/crontab redhat-lsb-3.1-19.fc8.i386 requires /usr/lib/lsb/remove_initd redhat-lsb-3.1-19.fc8.i386 requires /bin/gunzip redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/file redhat-lsb-3.1-19.fc8.i386 requires /bin/sh redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/tail redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/chsh redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/csplit redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/find redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/at redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/od redhat-lsb-3.1-19.fc8.i386 requires /bin/mailx redhat-lsb-3.1-19.fc8.i386 requires /bin/hostname redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/ar redhat-lsb-3.1-19.fc8.i386 requires /bin/chgrp redhat-lsb-3.1-19.fc8.i386 requires /bin/true redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/wc redhat-lsb-3.1-19.fc8.i386 requires /bin/mount redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/md5sum redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/du redhat-lsb-3.1-19.fc8.i386 requires /bin/egrep redhat-lsb-3.1-19.fc8.i386 requires /bin/rm redhat-lsb-3.1-19.fc8.i386 requires /bin/basename redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/locale redhat-lsb-3.1-19.fc8.i386 requires /bin/df redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/paste redhat-lsb-3.1-19.fc8.i386 requires /usr/sbin/groupadd redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/killall redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/dirname redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/localedef redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/head redhat-lsb-3.1-19.fc8.i386 requires /bin/dmesg redhat-lsb-3.1-19.fc8.i386 requires /bin/sed redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/pr redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/logname redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/batch redhat-lsb-3.1-19.fc8.i386 requires /bin/awk redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/tr redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/bc redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/cmp redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/passwd redhat-lsb-3.1-19.fc8.i386 requires /bin/date redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/expand redhat-lsb-3.1-19.fc8.i386 requires /bin/chmod redhat-lsb-3.1-19.fc8.i386 requires /bin/rmdir redhat-lsb-3.1-19.fc8.i386 requires /bin/sleep redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/newgrp redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/expr redhat-lsb-3.1-19.fc8.i386 requires /bin/uname redhat-lsb-3.1-19.fc8.i386 requires /bin/ln redhat-lsb-3.1-19.fc8.i386 requires /bin/nice redhat-lsb-3.1-19.fc8.i386 requires /bin/cpio redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/install redhat-lsb-3.1-19.fc8.i386 requires /bin/su redhat-lsb-3.1-19.fc8.i386 requires /sbin/pidof redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/pathchk redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/groups redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/ipcs redhat-lsb-3.1-19.fc8.i386 requires /bin/bash redhat-lsb-3.1-19.fc8.i386 requires /bin/env redhat-lsb-3.1-19.fc8.i386 requires /bin/fgrep redhat-lsb-3.1-19.fc8.i386 requires /bin/grep redhat-lsb-3.1-19.fc8.i386 requires /bin/sort redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/iconv redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/split redhat-lsb-3.1-19.fc8.i386 requires /usr/sbin/groupdel redhat-lsb-3.1-19.fc8.i386 requires /bin/false redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/cksum redhat-lsb-3.1-19.fc8.i386 requires /bin/ed redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/man redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/logger redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/m4 redhat-lsb-3.1-19.fc8.i386 requires /bin/ps redhat-lsb-3.1-19.fc8.i386 requires /bin/cat redhat-lsb-3.1-19.fc8.i386 requires /usr/sbin/groupmod redhat-lsb-3.1-19.fc8.i386 requires /bin/cut redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/gencat redhat-lsb-3.1-19.fc8.i386 requires /usr/lib/lsb/install_initd redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/strip redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/nl redhat-lsb-3.1-19.fc8.i386 requires /sbin/shutdown redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/xargs redhat-lsb-3.1-19.fc8.i386 requires /bin/mkdir redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/time redhat-lsb-3.1-19.fc8.i386 requires /usr/sbin/userdel redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/unexpand redhat-lsb-3.1-19.fc8.i386 requires /bin/umount redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/getconf redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/diff redhat-lsb-3.1-19.fc8.i386 requires /usr/sbin/useradd redhat-lsb-3.1-19.fc8.i386 requires /sbin/fuser redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/printf redhat-lsb-3.1-19.fc8.i386 requires /usr/sbin/usermod redhat-lsb-3.1-19.fc8.i386 requires /bin/sh redhat-lsb-3.1-19.fc8.i386 requires /bin/kill redhat-lsb-3.1-19.fc8.i386 requires /bin/sync redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/renice redhat-lsb-3.1-19.fc8.i386 requires /bin/mktemp redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/test redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/comm redhat-lsb-3.1-19.fc8.i386 requires /bin/chown redhat-menus-8.9.11-3.fc9.noarch requires /bin/sh redhat-rpm-config-9.0.3-1.fc10.noarch requires /usr/bin/perl redhat-rpm-config-9.0.3-1.fc10.noarch requires /bin/bash redhat-rpm-config-9.0.3-1.fc10.noarch requires /bin/sh redland-1.0.7-1.fc9.i386 requires /sbin/ldconfig redland-devel-1.0.7-1.fc9.i386 requires /bin/sh redmode-1.0-2.fc9.noarch requires /bin/bash referencer-1.1.2-1.fc10.i386 requires /bin/sh regexp-1.5-2jpp.1.fc9.i386 requires /bin/sh regexp-javadoc-1.5-2jpp.1.fc9.i386 requires /bin/sh regexp-javadoc-1.5-2jpp.1.fc9.i386 requires /bin/rm regexp-javadoc-1.5-2jpp.1.fc9.i386 requires /bin/ln regexxer-0.9-3.fc9.i386 requires /bin/sh rekall-2.4.6-4.fc9.i386 requires /bin/sh rekall-2.4.6-4.fc9.i386 requires /bin/sh rekall-extra-2.4.6-4.fc9.i386 requires /sbin/ldconfig rekall-mysql-2.4.6-4.fc9.i386 requires /sbin/ldconfig rekall-odbc-2.4.6-4.fc9.i386 requires /sbin/ldconfig rekall-postgresql-2.4.6-4.fc9.i386 requires /sbin/ldconfig rekall-python-2.4.6-4.fc9.i386 requires /sbin/ldconfig rekall-sqlite-2.4.6-4.fc9.i386 requires /sbin/ldconfig remctl-2.11-6.fc9.i386 requires /sbin/ldconfig remind-03.01.04-1.fc9.i386 requires /usr/bin/perl remind-03.01.04-1.fc9.i386 requires /bin/sh remind-gui-03.01.04-1.fc9.i386 requires /bin/sh renrot-0.25-4.fc9.noarch requires /usr/bin/perl renrot-0.25-4.fc9.noarch requires /bin/sh repoman-0.9-3.fc8.noarch requires /bin/sh repoman-0.9-3.fc8.noarch requires /usr/bin/env repoview-0.6.2-1.fc9.noarch requires /usr/bin/python resapplet-0.1.1-7.fc9.i386 requires /bin/sh revelation-0.4.11-4.1.i386 requires /bin/sh revelation-0.4.11-4.1.i386 requires /usr/bin/env revisor-cli-2.1.0-2.fc10.noarch requires /usr/bin/python2 rgmanager-2.0.23-3.fc9.i386 requires /bin/sh rgmanager-2.0.23-3.fc9.i386 requires /sbin/findfs rgmanager-2.0.23-3.fc9.i386 requires /bin/bash rgmanager-2.0.23-3.fc9.i386 requires /bin/sh rgmanager-2.0.23-3.fc9.i386 requires /sbin/chkconfig rhm-0.2-11.fc9.i386 requires /bin/sh rhm-0.2-11.fc9.i386 requires /sbin/service rhm-0.2-11.fc9.i386 requires /bin/bash rhpl-0.215-3.i386 requires /usr/bin/python rhythmbox-0.11.5-9.fc9.i386 requires /bin/sh rhythmbox-0.11.5-9.fc9.i386 requires libtotem-plparser.so.10 rinetd-0.62-7.fc9.i386 requires /bin/sh rinetd-0.62-7.fc9.i386 requires /sbin/chkconfig rinetd-0.62-7.fc9.i386 requires /bin/sh rinetd-0.62-7.fc9.i386 requires /sbin/service rkhunter-1.3.2-2.fc9.noarch requires /usr/bin/perl rkhunter-1.3.2-2.fc9.noarch requires /bin/sh rkward-0.5.0b-2.fc10.i386 requires /bin/sh rkward-0.5.0b-2.fc10.i386 requires /bin/sh rlog-1.3.7-6.fc9.i386 requires /sbin/ldconfig 1:rng-utils-2.0-1.15.1.fc9.i386 requires /sbin/chkconfig 1:rng-utils-2.0-1.15.1.fc9.i386 requires /sbin/service roadstencil-fonts-1.0-2.fc10.noarch requires /bin/sh rogue-5.4.5-2.fc9.i386 requires /bin/sh rosegarden4-1.6.1-2.fc9.i386 requires /bin/sh rosegarden4-1.6.1-2.fc9.i386 requires /bin/bash rott-registered-1.0-5.fc9.i386 requires /bin/sh rott-registered-1.0-5.fc9.i386 requires /bin/bash rott-shareware-1.0-5.fc9.i386 requires /bin/sh rott-shareware-1.0-5.fc9.i386 requires /bin/bash roundcubemail-0.1-1.fc9.noarch requires /bin/sh roundup-1.4.4-1.fc9.noarch requires /bin/sh roundup-1.4.4-1.fc9.noarch requires /bin/bash roundup-1.4.4-1.fc9.noarch requires /sbin/chkconfig roundup-1.4.4-1.fc9.noarch requires /usr/bin/env roundup-1.4.4-1.fc9.noarch requires /usr/bin/python roundup-1.4.4-1.fc9.noarch requires /sbin/service roxterm-1.11.1-1.fc9.i386 requires /bin/sh rp-pppoe-3.8-3.fc9.i386 requires /bin/bash rp-pppoe-3.8-3.fc9.i386 requires /bin/sh rpc2-2.7-1.fc10.i386 requires /sbin/ldconfig rpcbind-0.1.4-14.fc9.i386 requires /usr/sbin/userdel rpcbind-0.1.4-14.fc9.i386 requires /bin/sh rpcbind-0.1.4-14.fc9.i386 requires /usr/sbin/groupadd rpcbind-0.1.4-14.fc9.i386 requires /usr/sbin/useradd rpcbind-0.1.4-14.fc9.i386 requires /bin/sh rpcbind-0.1.4-14.fc9.i386 requires /usr/sbin/groupdel rpcbind-0.1.4-14.fc9.i386 requires /sbin/chkconfig rpl-1.5.3-4.fc6.noarch requires /usr/bin/env rpm-4.4.2.3-2.fc9.i386 requires /bin/sh rpm-4.4.2.3-2.fc9.i386 requires /bin/bash rpm-4.4.2.3-2.fc9.i386 requires /bin/sh rpm-build-4.4.2.3-2.fc9.i386 requires /bin/bash rpm-build-4.4.2.3-2.fc9.i386 requires /bin/sh rpm-build-4.4.2.3-2.fc9.i386 requires /usr/bin/perl rpm-libs-4.4.2.3-2.fc9.i386 requires /sbin/ldconfig rpmdevtools-6.6-1.fc9.noarch requires /usr/bin/python rpmdevtools-6.6-1.fc9.noarch requires /bin/bash rpmdevtools-6.6-1.fc9.noarch requires /bin/sh rpmdevtools-6.6-1.fc9.noarch requires /usr/bin/perl rpmlint-0.82-3.fc9.noarch requires /bin/sh rpmlint-0.82-3.fc9.noarch requires /usr/bin/python rpmrebuild-2.2.2-1.fc10.noarch requires /bin/sh rpmrebuild-2.2.2-1.fc10.noarch requires /bin/bash rpmrebuild-2.2.2-1.fc10.noarch requires /bin/sh rpy-1.0.2-1.fc10.i386 requires /bin/sh rpy-1.0.2-1.fc10.i386 requires /sbin/install-info rrdtool-1.3-0.14.beta4.fc10.i386 requires /sbin/ldconfig rrdtool-tcl-1.3-0.14.beta4.fc10.i386 requires /bin/sh rsh-server-0.17-50.fc10.i386 requires /etc/pam.d/system-auth rsibreak-0.8.0-5.fc9.i386 requires /bin/sh rsnapshot-1.3.0-1.fc8.noarch requires /bin/sh rsnapshot-1.3.0-1.fc8.noarch requires /usr/bin/perl rss-glx-0.8.1.p-19.fc9.i386 requires /usr/bin/env rss-glx-xscreensaver-0.8.1.p-19.fc9.i386 requires /bin/sh rss2email-2.62-1.1.noarch requires /bin/sh rss2email-2.62-1.1.noarch requires /usr/bin/python rsyslog-3.16.1-1.fc10.i386 requires /bin/sh rsyslog-3.16.1-1.fc10.i386 requires /sbin/service rsyslog-3.16.1-1.fc10.i386 requires /bin/bash rsyslog-3.16.1-1.fc10.i386 requires /bin/sh rsyslog-3.16.1-1.fc10.i386 requires /sbin/chkconfig rt3-3.6.6-5.fc9.noarch requires /usr/bin/perl rt3-3.6.6-5.fc9.noarch requires /bin/rm rt3-3.6.6-5.fc9.noarch requires /bin/sh rt3-mailgate-3.6.6-5.fc9.noarch requires /usr/bin/perl rubberband-1.0.1-1.fc9.i386 requires /sbin/ldconfig ruby-1.8.6.114-1.fc9.i386 requires /usr/bin/ruby ruby-cairo-1.5.1-1.fc9.i386 requires /usr/bin/env ruby-gettext-package-1.90.0-1.fc9.noarch requires /usr/bin/ruby ruby-gettext-package-doc-1.90.0-1.fc9.noarch requires /usr/bin/ruby ruby-gettext-package-doc-1.90.0-1.fc9.noarch requires /bin/sh ruby-gettext-package-doc-1.90.0-1.fc9.noarch requires /usr/bin/env ruby-gtk2-0.16.0-28.fc9.i386 requires /usr/bin/env ruby-hyperestraier-1.4.13-2.fc9.i386 requires /usr/bin/ruby ruby-irb-1.8.6.114-1.fc9.i386 requires /usr/bin/ruby ruby-libglade2-0.16.0-28.fc9.i386 requires /usr/bin/env ruby-libs-1.8.6.114-1.fc9.i386 requires /sbin/ldconfig ruby-panelapplet2-0.16.0-28.fc9.i386 requires /usr/bin/env ruby-panelapplet2-0.16.0-28.fc9.i386 requires /usr/bin/ruby ruby-poppler-0.16.0-28.fc9.i386 requires /usr/bin/env ruby-qdbm-1.8.77-3.fc9.i386 requires /usr/bin/ruby ruby-racc-1.4.5-2.fc6.noarch requires /usr/bin/ruby ruby-rdoc-1.8.6.114-1.fc9.i386 requires /usr/bin/ruby ruby-ri-1.8.6.114-1.fc9.i386 requires /usr/bin/ruby ruby-rsvg-0.16.0-28.fc9.i386 requires /usr/bin/env ruby-tcltk-1.8.6.114-1.fc9.i386 requires /usr/bin/env ruby-vte-0.16.0-28.fc9.i386 requires /usr/bin/env rubygem-activeldap-0.10.0-10.fc10.noarch requires /usr/bin/ruby rubygem-activeldap-0.10.0-10.fc10.noarch requires /usr/bin/env rubygem-activeldap-0.10.0-10.fc10.noarch requires /bin/sh rubygem-daemons-1.0.7-2.fc8.noarch requires /usr/bin/env rubygem-gem2rpm-0.5.3-1.fc10.noarch requires /usr/bin/env rubygem-gem_plugin-0.2.2-2.fc8.noarch requires /usr/bin/ruby rubygem-hoe-1.5.1-6.fc10.noarch requires /usr/bin/env rubygem-mongrel-1.0.1-6.fc9.i386 requires /usr/bin/ruby rubygem-mongrel-1.0.1-6.fc9.i386 requires /usr/bin/env rubygem-rails-2.0.2-2.fc9.noarch requires /usr/bin/ruby rubygem-rails-2.0.2-2.fc9.noarch requires /usr/bin/env rubygem-rake-0.8.1-2.fc10.noarch requires /usr/bin/ruby rubygem-rubyforge-0.4.5-2.fc10.noarch requires /usr/bin/env rubygem-zoom-0.4.1-2.fc9.3.i386 requires /usr/bin/ruby rubygems-0.9.4-1.fc8.noarch requires /usr/bin/ruby rubyripper-0.5.0-2.fc9.noarch requires /usr/bin/env rubyripper-gui-0.5.0-2.fc9.noarch requires /usr/bin/env rudecgi-5.1.0-2.fc9.i386 requires /sbin/ldconfig rudeconfig-5.0.5-1.fc7.i386 requires /sbin/ldconfig rudesocket-1.3.0-2.fc9.i386 requires /sbin/ldconfig rusers-server-0.17-53.fc9.i386 requires /bin/sh rusers-server-0.17-53.fc9.i386 requires /bin/bash rusers-server-0.17-53.fc9.i386 requires /sbin/chkconfig rusers-server-0.17-53.fc9.i386 requires /bin/sh rvm-1.15-1.fc10.i386 requires /sbin/ldconfig rwall-server-0.17-28.fc9.i386 requires /bin/sh rwall-server-0.17-28.fc9.i386 requires /etc/init.d rwall-server-0.17-28.fc9.i386 requires /sbin/chkconfig rwall-server-0.17-28.fc9.i386 requires /bin/sh rwho-0.17-29.fc9.i386 requires /bin/sh rwho-0.17-29.fc9.i386 requires /sbin/chkconfig rwho-0.17-29.fc9.i386 requires /bin/sh rwho-0.17-29.fc9.i386 requires /etc/init.d rxvt-2.7.10-15.fc9.i386 requires /bin/sh s3switch-0.0-10.20020912.fc9.i386 requires /usr/bin/consolehelper sabayon-2.22.0-3.fc10.i386 requires /usr/bin/env sabayon-2.22.0-3.fc10.i386 requires /bin/sh sabayon-apply-2.22.0-3.fc10.i386 requires /bin/bash sabayon-apply-2.22.0-3.fc10.i386 requires /usr/bin/env safekeep-common-1.0.3-2.fc9.noarch requires /usr/bin/python safekeep-server-1.0.3-2.fc9.noarch requires /bin/sh safekeep-server-1.0.3-2.fc9.noarch requires /usr/sbin/groupadd safekeep-server-1.0.3-2.fc9.noarch requires /usr/sbin/useradd safekeep-server-1.0.3-2.fc9.noarch requires /bin/sh sagator-1.0.0-1.fc9.noarch requires /bin/sh sagator-1.0.0-1.fc9.noarch requires /sbin/chkconfig sagator-1.0.0-1.fc9.noarch requires /usr/bin/python2 sagator-1.0.0-1.fc9.noarch requires /bin/sh sagator-1.0.0-1.fc9.noarch requires /usr/bin/python sagator-1.0.0-1.fc9.noarch requires /sbin/service sage-0.2.0-3.fc9.i386 requires /sbin/ldconfig samba-3.2.0-1.pre3.10.fc10.i386 requires /bin/sh samba-3.2.0-1.pre3.10.fc10.i386 requires /sbin/service samba-3.2.0-1.pre3.10.fc10.i386 requires /bin/bash samba-3.2.0-1.pre3.10.fc10.i386 requires /bin/sh samba-3.2.0-1.pre3.10.fc10.i386 requires /usr/bin/perl samba-3.2.0-1.pre3.10.fc10.i386 requires /sbin/chkconfig samba-client-3.2.0-1.pre3.10.fc10.i386 requires /usr/bin/perl samba-client-3.2.0-1.pre3.10.fc10.i386 requires /bin/sh samba-common-3.2.0-1.pre3.10.fc10.i386 requires /bin/sh samba-common-3.2.0-1.pre3.10.fc10.i386 requires /usr/sbin/groupadd samba-common-3.2.0-1.pre3.10.fc10.i386 requires /sbin/service samba-common-3.2.0-1.pre3.10.fc10.i386 requires /sbin/chkconfig samba-winbind-3.2.0-1.pre3.10.fc10.i386 requires /bin/sh samba-winbind-3.2.0-1.pre3.10.fc10.i386 requires /usr/sbin/groupadd samba-winbind-3.2.0-1.pre3.10.fc10.i386 requires /sbin/service samba-winbind-3.2.0-1.pre3.10.fc10.i386 requires /bin/sh samba-winbind-3.2.0-1.pre3.10.fc10.i386 requires /sbin/chkconfig samyak-fonts-devanagari-1.2.0-2.fc9.noarch requires /bin/sh samyak-fonts-gujarati-1.2.0-2.fc9.noarch requires /bin/sh samyak-fonts-malayalam-1.2.0-2.fc9.noarch requires /bin/sh samyak-fonts-oriya-1.2.0-2.fc9.noarch requires /bin/sh samyak-fonts-tamil-1.2.0-2.fc9.noarch requires /bin/sh sane-backends-1.0.19-10.fc9.i386 requires /bin/bash sane-backends-devel-1.0.19-10.fc9.i386 requires /bin/sh sane-backends-libs-1.0.19-10.fc9.i386 requires /sbin/ldconfig sarai-fonts-1.0-4.fc9.noarch requires /bin/sh saxon-6.5.5-1jpp.2.fc7.noarch requires /bin/sh saxon-6.5.5-1jpp.2.fc7.noarch requires /usr/sbin/update-alternatives sazanami-fonts-gothic-0.20040629-4.20061016.fc8.noarch requires /bin/sh sazanami-fonts-mincho-0.20040629-4.20061016.fc8.noarch requires /bin/sh sbcl-1.0.13-1.fc9.i386 requires /bin/sh sbcl-1.0.13-1.fc9.i386 requires /sbin/install-info sblim-cmpi-base-1.5.4-7.fc7.i386 requires /bin/sh sblim-cmpi-base-1.5.4-7.fc7.i386 requires /sbin/ldconfig sblim-cmpi-base-1.5.4-7.fc7.i386 requires /bin/sh sblim-cmpi-base-test-1.5.4-7.fc7.i386 requires /usr/bin/perl sblim-cmpi-base-test-1.5.4-7.fc7.i386 requires /bin/bash sblim-cmpi-base-test-1.5.4-7.fc7.i386 requires /bin/sh sblim-testsuite-1.2.4-3.fc6.noarch requires /usr/bin/perl sblim-testsuite-1.2.4-3.fc6.noarch requires /bin/sh scalapack-1.7.5-2.fc9.i386 requires /sbin/ldconfig scanbuttond-0.2.3-12.fc9.i386 requires /bin/sh scanbuttond-0.2.3-12.fc9.i386 requires /sbin/service scanbuttond-0.2.3-12.fc9.i386 requires /sbin/ldconfig scanbuttond-0.2.3-12.fc9.i386 requires /bin/bash scanbuttond-0.2.3-12.fc9.i386 requires /bin/sh scanbuttond-0.2.3-12.fc9.i386 requires /sbin/chkconfig scapy-1.1.1-4.fc8.noarch requires /usr/bin/env schismtracker-0.5-0.7.rc1.fc9.i386 requires /bin/sh schroedinger-1.0.0-1.fc9.i386 requires /sbin/ldconfig scidavis-0.1.3-2.fc10.i386 requires /bin/sh scim-1.4.7-23.fc10.i386 requires /usr/sbin/alternatives scim-1.4.7-23.fc10.i386 requires /bin/sh scim-1.4.7-23.fc10.i386 requires /bin/sh scim-bridge-gtk-0.4.15-5.fc9.i386 requires /bin/sh scim-gtk-1.4.7-23.fc10.i386 requires /bin/sh scim-input-pad-0.1.1-8.fc9.i386 requires /sbin/ldconfig scim-input-pad-0.1.1-8.fc9.i386 requires /bin/sh scim-libs-1.4.7-23.fc10.i386 requires /sbin/ldconfig scim-python-pinyin-0.1.12-1.fc10.i386 requires /bin/sh scim-python-xingma-0.1.12-1.fc10.i386 requires /usr/bin/python scim-python-xingma-cangjie-0.1.12-1.fc10.i386 requires /bin/sh scim-python-xingma-erbi-0.1.12-1.fc10.i386 requires /bin/sh scim-python-xingma-wubi-0.1.12-1.fc10.i386 requires /bin/sh scim-python-xingma-zhengma-0.1.12-1.fc10.i386 requires /bin/sh scim-tables-0.5.7-5.fc9.i386 requires /sbin/ldconfig scim-tomoe-0.6.0-2.fc8.i386 requires /bin/sh scons-0.98.3-2.fc10.noarch requires /usr/bin/python scorched3d-41.3-2.fc9.i386 requires /bin/sh scorchwentbonkers-1.1-5.fc9.i386 requires /bin/sh scratchpad-0.3.0-4.fc9.i386 requires /bin/sh screen-4.0.3-11.fc9.i386 requires /bin/sh screen-4.0.3-11.fc9.i386 requires /sbin/install-info screen-4.0.3-11.fc9.i386 requires /usr/sbin/groupadd scribes-0.3.3.3-2.fc9.noarch requires /bin/sh scribes-0.3.3.3-2.fc9.noarch requires /usr/bin/env scribus-1.3.4-5.fc9.i386 requires /bin/sh scsi-target-utils-0.0-4.20071227snap.fc9.i386 requires /bin/sh scsi-target-utils-0.0-4.20071227snap.fc9.i386 requires /sbin/service scsi-target-utils-0.0-4.20071227snap.fc9.i386 requires /sbin/chkconfig scsi-target-utils-0.0-4.20071227snap.fc9.i386 requires /bin/sh scummvm-0.11.1-2.fc9.i386 requires /bin/sh scythia-0.9.3-2.2.fc9.i386 requires /bin/sh sdcc-2.6.0-12.fc9.i386 requires /bin/sh sdcc-libc-sources-2.6.0-12.fc9.i386 requires /bin/sh sdljava-0.9.1-9.fc9.i386 requires /bin/sh sdljava-demo-0.9.1-9.fc9.i386 requires /usr/share/fonts/dejavu/DejaVuSans-BoldOblique.ttf sdljava-demo-0.9.1-9.fc9.i386 requires /usr/share/fonts/dejavu/DejaVuSans-Bold.ttf sdljava-demo-0.9.1-9.fc9.i386 requires /usr/share/fonts/dejavu/DejaVuSans-Oblique.ttf sdljava-demo-0.9.1-9.fc9.i386 requires /usr/share/fonts/dejavu/DejaVuSans.ttf sdljava-demo-0.9.1-9.fc9.i386 requires /bin/sh sdljava-javadoc-0.9.1-9.fc9.i386 requires /bin/sh seahorse-2.22.1-1.fc9.i386 requires /bin/sh seahorse-2.22.1-1.fc9.i386 requires /bin/sh seahorse-adventures-1.0-2.fc8.noarch requires /bin/sh seahorse-adventures-1.0-2.fc8.noarch requires /usr/bin/env seahorse-adventures-1.0-2.fc8.noarch requires /usr/bin/python seamonkey-1.1.9-4.fc9.i386 requires /bin/sh seamonkey-1.1.9-4.fc9.i386 requires /bin/sh sear-0.6.3-10.fc9.i386 requires /bin/sh sec-2.4.1-1.fc8.noarch requires /bin/sh sec-2.4.1-1.fc8.noarch requires /bin/bash sec-2.4.1-1.fc8.noarch requires /usr/bin/perl sectool-0.7.3-1.fc10.noarch requires /usr/bin/env sectool-0.7.3-1.fc10.noarch requires /usr/bin/python sectool-gui-0.7.3-1.fc10.noarch requires /usr/bin/python sed-4.1.5-10.fc9.i386 requires /bin/sh sed-4.1.5-10.fc9.i386 requires /sbin/install-info seedit-2.2.0-2.fc9.i386 requires /bin/sh seedit-2.2.0-2.fc9.i386 requires /usr/bin/python seedit-gui-2.2.0-2.fc9.i386 requires /usr/bin/python seedit-policy-2.2.0-2.fc9.i386 requires /bin/sh seedit-policy-2.2.0-2.fc9.i386 requires /bin/sh seekwatcher-0.10-1.fc9.noarch requires /usr/bin/env selinux-policy-3.3.1-45.fc10.noarch requires /bin/sh selinux-policy-devel-3.3.1-45.fc10.noarch requires /bin/sh selinux-policy-devel-3.3.1-45.fc10.noarch requires /usr/bin/env selinux-policy-mls-3.3.1-45.fc10.noarch requires /bin/sh selinux-policy-targeted-3.3.1-45.fc10.noarch requires /bin/sh selinux-policy-targeted-3.3.1-45.fc10.noarch requires /bin/sh sendmail-8.14.2-4.fc9.i386 requires /bin/sh sendmail-8.14.2-4.fc9.i386 requires /usr/sbin/saslauthd sendmail-8.14.2-4.fc9.i386 requires /usr/sbin/alternatives sendmail-8.14.2-4.fc9.i386 requires /bin/bash sendmail-cf-8.14.2-4.fc9.i386 requires /bin/sh sepostgresql-8.3.1-2.197.fc10.i386 requires /bin/sh sepostgresql-8.3.1-2.197.fc10.i386 requires /sbin/service sepostgresql-8.3.1-2.197.fc10.i386 requires /bin/sh sepostgresql-8.3.1-2.197.fc10.i386 requires /sbin/chkconfig seq24-0.8.7-8.fc8.i386 requires /bin/sh ser-0.9.6-14.fc9.i386 requires /bin/sh ser-0.9.6-14.fc9.i386 requires /sbin/service ser-0.9.6-14.fc9.i386 requires /bin/bash ser-0.9.6-14.fc9.i386 requires /bin/sh ser-0.9.6-14.fc9.i386 requires /sbin/chkconfig ser-mysql-0.9.6-14.fc9.i386 requires /bin/sh ser-postgresql-0.9.6-14.fc9.i386 requires /bin/sh ser2net-2.4-2.fc9.1.i386 requires /bin/sh ser2net-2.4-2.fc9.1.i386 requires /bin/sh ser2net-2.4-2.fc9.1.i386 requires /sbin/service sergueis-destiny-1.1-4.fc8.noarch requires /bin/sh sergueis-destiny-1.1-4.fc8.noarch requires /bin/bash serpentine-0.9-2.fc9.noarch requires /bin/sh serpentine-0.9-2.fc9.noarch requires /usr/bin/env setools-console-3.3.4-1.fc9.i386 requires /bin/sh setools-gui-3.3.4-1.fc9.i386 requires /bin/sh setools-libs-3.3.4-1.fc9.i386 requires /sbin/ldconfig setools-libs-java-3.3.4-1.fc9.i386 requires /sbin/ldconfig setools-libs-tcl-3.3.4-1.fc9.i386 requires /sbin/ldconfig setroubleshoot-2.0.6-1.fc9.noarch requires /bin/sh setroubleshoot-2.0.6-1.fc9.noarch requires /usr/bin/update-desktop-database setroubleshoot-plugins-2.0.4-5.fc9.noarch requires /bin/sh setroubleshoot-server-2.0.6-1.fc9.noarch requires /bin/sh setroubleshoot-server-2.0.6-1.fc9.noarch requires /bin/bash setroubleshoot-server-2.0.6-1.fc9.noarch requires /sbin/chkconfig setroubleshoot-server-2.0.6-1.fc9.noarch requires /usr/bin/python setroubleshoot-server-2.0.6-1.fc9.noarch requires /sbin/service sg3_utils-libs-1.25-4.fc9.i386 requires /sbin/ldconfig sgml-common-0.6.3-23.fc9.noarch requires /bin/sh shapelib-1.2.10-16.20060304cvs.i386 requires /sbin/ldconfig shapelib-1.2.10-16.20060304cvs.i386 requires /bin/sh shared-mime-info-0.30-1.fc10.i386 requires /bin/sh sharutils-4.6.3-2.fc9.i386 requires /bin/sh sharutils-4.6.3-2.fc9.i386 requires /bin/bash sharutils-4.6.3-2.fc9.i386 requires /usr/bin/perl sharutils-4.6.3-2.fc9.i386 requires /sbin/install-info shippy-1.3.3.7-7.fc9.i386 requires /bin/sh shippy-common-1.3.3.7-7.fc9.i386 requires /bin/bash shorewall-common-4.0.10-2.fc10.noarch requires /bin/sh shorewall-common-4.0.10-2.fc10.noarch requires /sbin/chkconfig shorewall-common-4.0.10-2.fc10.noarch requires /bin/sh shorewall-common-4.0.10-2.fc10.noarch requires /sbin/service shorewall-lite-4.0.10-2.fc10.noarch requires /bin/sh shorewall-lite-4.0.10-2.fc10.noarch requires /sbin/chkconfig shorewall-lite-4.0.10-2.fc10.noarch requires /bin/sh shorewall-lite-4.0.10-2.fc10.noarch requires /sbin/service shorewall-perl-4.0.10-2.fc10.noarch requires /usr/bin/perl shorewall-shell-4.0.10-2.fc10.noarch requires /bin/sh showimg-0.9.5-16.fc9.i386 requires /sbin/ldconfig siege-2.67-1.fc10.i386 requires /usr/bin/perl siege-2.67-1.fc10.i386 requires /bin/sh sigscheme-0.8.3-1.fc10.i386 requires /sbin/ldconfig silkscreen-fonts-1.0-1.fc9.noarch requires /bin/sh simcoupe-1.0-4.fc10.i386 requires /bin/sh sinjdoc-0.5-6.fc9.i386 requires /bin/sh sinjdoc-0.5-6.fc9.i386 requires /bin/sh six-0.5.3-9.fc9.i386 requires /bin/sh skencil-0.6.17-18.20070606svn.fc9.i386 requires /bin/sh skencil-0.6.17-18.20070606svn.fc9.i386 requires /usr/bin/env skencil-0.6.17-18.20070606svn.fc9.i386 requires /usr/bin/python ski-devel-1.3.2-5.fc10.i386 requires /bin/sh ski-libs-1.3.2-5.fc10.i386 requires /sbin/ldconfig skstream-0.3.6-3.fc9.i386 requires /sbin/ldconfig slang-2.1.3-3.fc9.i386 requires /sbin/ldconfig slang-slsh-2.1.3-3.fc9.i386 requires /usr/bin/env slib-3b1-1.fc9.noarch requires /bin/sh slib-3b1-1.fc9.noarch requires /sbin/install-info slim-1.3.0-4.fc9.i386 requires /sbin/shutdown slim-1.3.0-4.fc9.i386 requires /etc/pam.d slim-1.3.0-4.fc9.i386 requires /usr/bin/perl slim-1.3.0-4.fc9.i386 requires /bin/sh slingshot-0.8.1p-1.fc8.noarch requires /bin/sh slingshot-0.8.1p-1.fc8.noarch requires /bin/bash sloccount-2.26-7.fc9.i386 requires /usr/bin/perl sloccount-2.26-7.fc9.i386 requires /bin/sh slrn-pull-0.9.8.1pl1-8.20070716cvs.fc9.i386 requires /bin/sh smart-0.52-54.fc9.i386 requires /usr/bin/python smarteiffel-2.3-2.fc9.i386 requires /bin/sh 1:smartmontools-5.38-4.1.fc10.i386 requires /sbin/service 1:smartmontools-5.38-4.1.fc10.i386 requires /bin/bash 1:smartmontools-5.38-4.1.fc10.i386 requires /bin/sh 1:smartmontools-5.38-4.1.fc10.i386 requires /sbin/chkconfig 1:smartmontools-5.38-4.1.fc10.i386 requires /bin/sh 1:smartmontools-config-5.38-4.1.fc10.i386 requires /usr/bin/python smashteroid-1.11-4.fc9.i386 requires /bin/sh smb4k-0.9.4-1.fc10.i386 requires /bin/sh smbldap-tools-0.9.4-2.fc9.noarch requires /usr/bin/perl smc-fonts-dyuthi-04-6.fc9.noarch requires /bin/sh smc-fonts-meera-04-6.fc9.noarch requires /bin/sh smc-fonts-rachana-04-6.fc9.noarch requires /bin/sh smc-fonts-raghumalayalam-04-6.fc9.noarch requires /bin/sh smc-fonts-suruma-04-6.fc9.noarch requires /bin/sh smolt-1.1.1.1-4.fc9.noarch requires /bin/sh smolt-1.1.1.1-4.fc9.noarch requires /bin/bash smolt-1.1.1.1-4.fc9.noarch requires /sbin/chkconfig smolt-1.1.1.1-4.fc9.noarch requires /usr/sbin/groupadd smolt-1.1.1.1-4.fc9.noarch requires /usr/sbin/useradd smolt-1.1.1.1-4.fc9.noarch requires /usr/bin/python smolt-1.1.1.1-4.fc9.noarch requires /sbin/service smolt-server-1.1.1.1-4.fc9.noarch requires /usr/bin/python smstools-3.0.10-2.fc9.i386 requires /bin/sh smstools-3.0.10-2.fc9.i386 requires /bin/bash smstools-3.0.10-2.fc9.i386 requires /sbin/chkconfig smstools-3.0.10-2.fc9.i386 requires /bin/sh smstools-3.0.10-2.fc9.i386 requires /sbin/service snake-0.11-0.2.fc9.noarch requires /usr/bin/python snake-server-0.11-0.2.fc9.noarch requires /bin/sh snake-server-0.11-0.2.fc9.noarch requires /bin/sh snake-server-0.11-0.2.fc9.noarch requires /usr/bin/python snort-2.8.1-3.fc10.i386 requires /bin/sh snort-2.8.1-3.fc10.i386 requires /bin/sh snort-bloat-2.8.1-3.fc10.i386 requires /bin/sh snort-mysql-2.8.1-3.fc10.i386 requires /bin/sh snort-mysql+flexresp-2.8.1-3.fc10.i386 requires /bin/sh snort-plain+flexresp-2.8.1-3.fc10.i386 requires /bin/sh snort-postgresql-2.8.1-3.fc10.i386 requires /bin/sh snort-postgresql+flexresp-2.8.1-3.fc10.i386 requires /bin/sh snort-snmp-2.8.1-3.fc10.i386 requires /bin/sh snort-snmp+flexresp-2.8.1-3.fc10.i386 requires /bin/sh snownews-1.5.8-2.fc9.i386 requires /usr/bin/perl sofia-sip-1.12.8-1.fc9.i386 requires /sbin/ldconfig sofia-sip-devel-1.12.8-1.fc9.i386 requires /usr/bin/env sofia-sip-glib-1.12.8-1.fc9.i386 requires /sbin/ldconfig solarwolf-1.5-2.fc8.noarch requires /bin/sh solarwolf-1.5-2.fc8.noarch requires /usr/bin/env solfege-3.10.4-1.fc10.i386 requires /bin/bash solfege-3.10.4-1.fc10.i386 requires /bin/sh solfege-3.10.4-1.fc10.i386 requires /usr/bin/python sonata-1.5.1-1.fc10.i386 requires /usr/bin/python sonic-visualiser-1.2-1.fc9.i386 requires /bin/sh sooperlooper-1.6.2-1.fc9.i386 requires /bin/sh soprano-2.0.98-1.fc10.i386 requires /sbin/ldconfig soprano-apidocs-2.0.98-1.fc10.i386 requires /usr/bin/perl sos-1.8-1.fc8.noarch requires /bin/bash sos-1.8-1.fc8.noarch requires /usr/bin/env sound-juicer-2.22.0-3.fc10.i386 requires /bin/sh soundconverter-1.2.0-1.fc10.noarch requires /bin/sh soundconverter-1.2.0-1.fc10.noarch requires /usr/bin/python soundtouch-1.3.1-10.fc9.i386 requires /sbin/ldconfig source-highlight-2.8-2.fc9.i386 requires /bin/sh source-highlight-2.8-2.fc9.i386 requires /sbin/install-info source-highlight-2.8-2.fc9.i386 requires /bin/sh sox-14.0.1-1.fc9.i386 requires /sbin/ldconfig spamass-milter-0.3.1-7.fc9.i386 requires /bin/sh spamass-milter-0.3.1-7.fc9.i386 requires /sbin/service spamass-milter-0.3.1-7.fc9.i386 requires /bin/bash spamass-milter-0.3.1-7.fc9.i386 requires /sbin/chkconfig spamassassin-3.2.4-4.fc9.i386 requires /sbin/chkconfig spamassassin-3.2.4-4.fc9.i386 requires /usr/bin/perl spamassassin-3.2.4-4.fc9.i386 requires /bin/sh spamassassin-3.2.4-4.fc9.i386 requires /sbin/service spamassassin-3.2.4-4.fc9.i386 requires /bin/bash spamassassin-3.2.4-4.fc9.i386 requires /bin/sh spambayes-1.0.4-5.fc8.noarch requires /usr/bin/python spampd-2.30-4.noarch requires /bin/sh spampd-2.30-4.noarch requires /usr/bin/perl spampd-2.30-4.noarch requires /sbin/chkconfig spampd-2.30-4.noarch requires /bin/sh spampd-2.30-4.noarch requires /sbin/service spandsp-0.0.4-0.10.pre18.fc9.i386 requires /sbin/ldconfig sparse-0.4.1-2.fc9.i386 requires /usr/bin/perl specto-0.2.2-1.fc9.noarch requires /bin/sh specto-0.2.2-1.fc9.noarch requires /usr/bin/python speedcrunch-0.9-3.fc9.i386 requires /bin/sh speex-1.2-0.9.beta3.i386 requires /sbin/ldconfig spicctrl-1.9-6.fc9.i386 requires /bin/sh spr-07.15.00-1.fc9.i386 requires /sbin/ldconfig sqlgrey-1.7.5-1.fc7.noarch requires /bin/sh sqlgrey-1.7.5-1.fc7.noarch requires /usr/bin/perl sqlgrey-1.7.5-1.fc7.noarch requires /bin/bash sqlgrey-1.7.5-1.fc7.noarch requires /sbin/chkconfig sqlgrey-1.7.5-1.fc7.noarch requires /bin/sh sqlgrey-1.7.5-1.fc7.noarch requires /sbin/service sqlite-3.5.8-1.fc10.i386 requires /sbin/ldconfig sqliteman-1.0.1-4.fc9.i386 requires /bin/sh 7:squid-3.0.STABLE5-2.fc10.i386 requires /bin/sh 7:squid-3.0.STABLE5-2.fc10.i386 requires /sbin/service 7:squid-3.0.STABLE5-2.fc10.i386 requires /bin/bash 7:squid-3.0.STABLE5-2.fc10.i386 requires /bin/sh 7:squid-3.0.STABLE5-2.fc10.i386 requires /usr/bin/perl 7:squid-3.0.STABLE5-2.fc10.i386 requires /sbin/chkconfig squidGuard-1.2.0-18.fc9.i386 requires /bin/sh squidGuard-1.2.0-18.fc9.i386 requires /usr/bin/chcon squidGuard-1.2.0-18.fc9.i386 requires /bin/bash squidGuard-1.2.0-18.fc9.i386 requires /usr/bin/perl squidGuard-1.2.0-18.fc9.i386 requires /sbin/chkconfig squirrelmail-1.4.13-1.fc9.noarch requires /usr/bin/env squirrelmail-1.4.13-1.fc9.noarch requires /bin/sh ss5-3.5.9-7.i386 requires /bin/sh ss5-3.5.9-7.i386 requires /bin/sh sshfp-1.1.2-1.fc7.noarch requires /usr/bin/python sshmenu-3.15-5.fc9.noarch requires /usr/bin/ruby ssmtp-2.61-11.5.fc9.3.i386 requires /bin/sh ssmtp-2.61-11.5.fc9.3.i386 requires /usr/sbin/alternatives stardict-3.0.1-8.fc9.i386 requires /bin/sh starplot-0.95.4-6.fc9.i386 requires /bin/sh starplot-gliese3-0.95-2.fc9.noarch requires /bin/sh starplot-yale5-0.95-2.fc9.noarch requires /bin/sh startup-notification-0.9-4.fc9.i386 requires /sbin/ldconfig statgrab-tools-0.16-1.fc9.i386 requires /usr/bin/perl statserial-1.1-41.fc9.i386 requires /bin/bash stgit-0.14.2-1.fc9.noarch requires /bin/sh stgit-0.14.2-1.fc9.noarch requires /usr/bin/python stix-fonts-0.9-6.fc9.noarch requires /bin/sh stix-fonts-integrals-0.9-6.fc9.noarch requires /bin/sh stix-fonts-pua-0.9-6.fc9.noarch requires /bin/sh stix-fonts-sizes-0.9-6.fc9.noarch requires /bin/sh stix-fonts-variants-0.9-6.fc9.noarch requires /bin/sh stonith-2.1.3-1.fc9.i386 requires /usr/bin/python stonith-2.1.3-1.fc9.i386 requires /sbin/ldconfig stonith-2.1.3-1.fc9.i386 requires /usr/bin/perl stonith-2.1.3-1.fc9.i386 requires /bin/sh stormbaancoureur-2.1.4-1.fc10.i386 requires /bin/sh stow-1.3.3-6.fc8.noarch requires /usr/bin/perl stow-1.3.3-6.fc8.noarch requires /sbin/install-info stow-1.3.3-6.fc8.noarch requires /bin/sh stratagus-2.2.4-4.fc9.i386 requires /usr/bin/env straw-0.27-12.fc9.noarch requires /bin/sh straw-0.27-12.fc9.noarch requires /usr/bin/python streamtuner-0.99.99-17.fc9.i386 requires /bin/sh strigi-libs-0.5.9-2.fc10.i386 requires /sbin/ldconfig struts-1.2.9-5jpp.9.fc9.i386 requires /bin/sh struts-javadoc-1.2.9-5jpp.9.fc9.i386 requires /bin/sh struts-javadoc-1.2.9-5jpp.9.fc9.i386 requires /bin/rm struts-javadoc-1.2.9-5jpp.9.fc9.i386 requires /bin/ln struts-webapps-tomcat5-1.2.9-5jpp.9.fc9.i386 requires /bin/sh struts-webapps-tomcat5-1.2.9-5jpp.9.fc9.i386 requires /bin/ln struts-webapps-tomcat5-1.2.9-5jpp.9.fc9.i386 requires /bin/rm stunnel-4.22-1.i386 requires /usr/bin/perl sub2srt-0.5.3-3.fc8.noarch requires /usr/bin/perl subversion-1.4.6-7.i386 requires /usr/bin/env subversion-1.4.6-7.i386 requires /usr/bin/python subversion-1.4.6-7.i386 requires /sbin/ldconfig subversion-1.4.6-7.i386 requires /bin/bash subversion-1.4.6-7.i386 requires /bin/sh subversion-1.4.6-7.i386 requires /usr/bin/perl subversion-javahl-1.4.6-7.i386 requires /sbin/ldconfig subversion-perl-1.4.6-7.i386 requires /sbin/ldconfig subversion-ruby-1.4.6-7.i386 requires /sbin/ldconfig suck-4.3.2-22.fc9.i386 requires /usr/bin/perl suck-4.3.2-22.fc9.i386 requires /bin/sh sudo-1.6.9p13-6.fc10.i386 requires /bin/sh sudo-1.6.9p13-6.fc10.i386 requires /etc/pam.d/system-auth sugar-0.79.4-2.fc10.i386 requires /bin/sh sugar-0.79.4-2.fc10.i386 requires /usr/bin/env sugar-0.79.4-2.fc10.i386 requires /bin/sh sugar-artwork-0.79.1-1.fc9.i386 requires /bin/sh sugar-datastore-0.6.0-1.fc9.noarch requires /usr/bin/env sugar-journal-79-3.fc9.noarch requires /usr/bin/env sugar-presence-service-0.79.0-1.fc9.noarch requires /usr/bin/env suitesparse-3.1.0-1.fc9.i386 requires /sbin/ldconfig sunbird-0.8-3.fc9.i386 requires /bin/sh sunbird-0.8-3.fc9.i386 requires libhunspell.so.1 sunbird-0.8-3.fc9.i386 requires /bin/sh sundials-2.3.0-6.fc9.i386 requires /sbin/ldconfig sundials-devel-2.3.0-6.fc9.i386 requires /bin/sh supertuxkart-0.4-2.fc10.i386 requires /bin/sh supervisor-2.1-4.fc9.noarch requires /bin/sh supervisor-2.1-4.fc9.noarch requires /bin/bash supervisor-2.1-4.fc9.noarch requires /sbin/chkconfig supervisor-2.1-4.fc9.noarch requires /usr/bin/python supervisor-2.1-4.fc9.noarch requires /sbin/service surfraw-1.0.7-3.fc8.noarch requires /bin/sh svgalib-1.9.25-4.fc9.i386 requires /sbin/ldconfig svgalib-1.9.25-4.fc9.i386 requires /usr/bin/perl svgalib-1.9.25-4.fc9.i386 requires /bin/sh svn2cl-0.10-1.noarch requires /bin/sh svncpp-0.9.6-1.fc9.i386 requires /sbin/ldconfig svnkit-1.1.4-3.fc9.i386 requires /usr/bin/rebuild-gcj-db svnmailer-1.0.8-3.fc7.noarch requires /usr/bin/python svrcore-4.0.4-2.fc9.i386 requires /sbin/ldconfig swaks-20061116.0-1.fc8.noarch requires /usr/bin/perl swatch-3.2.1-2.fc9.noarch requires /usr/bin/perl sweep-0.9.2-2.fc9.i386 requires /bin/sh swfdec-0.6.6-1.fc10.i386 requires /sbin/ldconfig swfdec-gnome-2.22.0-1.fc9.i386 requires /bin/sh swfdec-gtk-0.6.6-1.fc10.i386 requires /sbin/ldconfig swfdec-gtk-0.6.6-1.fc10.i386 requires /bin/sh swfdec-mozilla-0.6.0-1.fc9.i386 requires /usr/lib/mozilla/plugins swig-1.3.35-2.fc10.i386 requires /sbin/ldconfig swing-layout-1.0.3-2.fc9.i386 requires /bin/sh switchdesk-4.0.9-2.noarch requires /bin/bash switchdesk-gui-4.0.9-2.noarch requires /usr/bin/env sword-1.5.10-3.fc9.i386 requires /sbin/ldconfig syck-0.61-4.3.fc9.i386 requires /sbin/ldconfig synaptic-0.57.2-16.fc9.i386 requires /bin/sh synce-gnome-0.11-2.fc9.noarch requires /usr/bin/env synce-kde-0.9.1-3.fc9.i386 requires /bin/sh synce-kde-0.9.1-3.fc9.i386 requires /bin/sh synce-kpm-0.11-3.fc9.noarch requires /usr/bin/python synce-serial-0.11-2.fc9.i386 requires /bin/sh synce-sync-engine-0.11-6.fc9.noarch requires /usr/bin/python syncevolution-0.7-2.fc10.i386 requires /usr/bin/env sysconftool-0.15-3.fc6.noarch requires /usr/bin/perl syslog-ng-2.0.8-1.fc9.i386 requires /bin/sh syslog-ng-2.0.8-1.fc9.i386 requires /bin/sh sysreport-1.4.4-1.noarch requires /bin/bash sysreport-1.4.4-1.noarch requires /usr/bin/tr sysstat-8.0.4-4.fc10.i386 requires /bin/cp sysstat-8.0.4-4.fc10.i386 requires /usr/bin/id sysstat-8.0.4-4.fc10.i386 requires /etc/cron.d sysstat-8.0.4-4.fc10.i386 requires /bin/chmod sysstat-8.0.4-4.fc10.i386 requires /bin/mkdir sysstat-8.0.4-4.fc10.i386 requires /usr/bin/install sysstat-8.0.4-4.fc10.i386 requires /sbin/chkconfig sysstat-8.0.4-4.fc10.i386 requires /bin/sh sysstat-8.0.4-4.fc10.i386 requires /bin/mv sysstat-8.0.4-4.fc10.i386 requires /bin/grep sysstat-8.0.4-4.fc10.i386 requires /bin/sh system-config-audit-0.4.6-7.fc10.i386 requires /bin/sh system-config-bind-4.0.6-1.fc9.noarch requires /bin/sh system-config-bind-4.0.6-1.fc9.noarch requires /usr/bin/python system-config-boot-0.2.20-1.fc9.i386 requires /bin/sh system-config-cluster-1.0.53-1.0.noarch requires /usr/bin/python2 system-config-cluster-1.0.53-1.0.noarch requires /sbin/chkconfig system-config-date-1.9.31-1.fc10.noarch requires /bin/sh system-config-date-1.9.31-1.fc10.noarch requires /bin/sh system-config-date-1.9.31-1.fc10.noarch requires /usr/bin/python system-config-display-1.0.51-9.fc9.noarch requires /bin/sh system-config-display-1.0.51-9.fc9.noarch requires /usr/bin/Xorg system-config-display-1.0.51-9.fc9.noarch requires /bin/sh system-config-display-1.0.51-9.fc9.noarch requires /usr/bin/python2 system-config-firewall-1.2.7-1.fc9.noarch requires /bin/sh system-config-firewall-1.2.7-1.fc9.noarch requires /bin/sh system-config-firewall-1.2.7-1.fc9.noarch requires /usr/bin/python system-config-firewall-tui-1.2.7-1.fc9.noarch requires /usr/bin/python 5:system-config-httpd-1.4.4-1.fc8.noarch requires /bin/sh 5:system-config-httpd-1.4.4-1.fc8.noarch requires /bin/sh system-config-kdump-1.0.13-2.fc9.noarch requires /bin/sh system-config-kdump-1.0.13-2.fc9.noarch requires /bin/sh system-config-keyboard-1.2.15-2.fc9.noarch requires /bin/sh system-config-keyboard-1.2.15-2.fc9.noarch requires /bin/sh system-config-kickstart-2.7.16-1.fc9.noarch requires /bin/sh system-config-kickstart-2.7.16-1.fc9.noarch requires /usr/bin/python2 system-config-language-1.2.15-3.fc10.noarch requires /bin/sh system-config-language-1.2.15-3.fc10.noarch requires /bin/sh system-config-lvm-1.1.4-1.0.fc9.noarch requires /sbin/chkconfig system-config-lvm-1.1.4-1.0.fc9.noarch requires /usr/bin/python2 system-config-netboot-0.1.45.2-1.fc10.noarch requires /bin/sh system-config-netboot-0.1.45.2-1.fc10.noarch requires /usr/bin/python system-config-netboot-cmd-0.1.45.2-1.fc10.noarch requires /bin/sh system-config-netboot-cmd-0.1.45.2-1.fc10.noarch requires /bin/bash system-config-netboot-cmd-0.1.45.2-1.fc10.noarch requires /usr/bin/python system-config-network-1.5.7-1.fc9.noarch requires /usr/bin/python system-config-network-tui-1.5.7-1.fc9.noarch requires /bin/sh system-config-network-tui-1.5.7-1.fc9.noarch requires /usr/bin/python system-config-nfs-1.3.40-1.fc9.noarch requires /bin/sh system-config-nfs-1.3.40-1.fc9.noarch requires /usr/bin/python system-config-printer-0.9.91-1.fc10.i386 requires /bin/sh system-config-printer-0.9.91-1.fc10.i386 requires /usr/bin/env system-config-printer-0.9.91-1.fc10.i386 requires /bin/sh system-config-printer-0.9.91-1.fc10.i386 requires /usr/bin/python system-config-printer-libs-0.9.91-1.fc10.i386 requires /usr/bin/env system-config-printer-libs-0.9.91-1.fc10.i386 requires /usr/bin/python system-config-rootpassword-1.99.4-1.fc9.noarch requires /bin/sh system-config-rootpassword-1.99.4-1.fc9.noarch requires /bin/sh system-config-samba-1.2.63-1.fc9.noarch requires /bin/sh system-config-samba-1.2.63-1.fc9.noarch requires /usr/bin/python system-config-services-0.99.15-1.fc9.noarch requires /bin/sh system-config-services-0.99.15-1.fc9.noarch requires /usr/bin/python system-config-users-1.2.80-1.fc10.noarch requires /bin/sh system-config-users-1.2.80-1.fc10.noarch requires /usr/bin/pgrep system-config-users-1.2.80-1.fc10.noarch requires /bin/sh system-config-users-1.2.80-1.fc10.noarch requires /usr/bin/python system-config-vsftpd-0.5.1-1.fc10.noarch requires /usr/bin/env system-config-vsftpd-0.5.1-1.fc10.noarch requires /bin/sh system-summary-0.0.3-2.fc9.noarch requires /usr/bin/python system-switch-java-1.1.2-1.fc8.noarch requires /usr/bin/env system-switch-mail-0.5.26-2.noarch requires /usr/bin/python systemtap-0.6.2-1.fc9.i386 requires /bin/bash systemtap-0.6.2-1.fc9.i386 requires /usr/bin/stap systemtap-runtime-0.6.2-1.fc9.i386 requires /bin/sh systemtap-testsuite-0.6.2-1.fc9.i386 requires /usr/bin/perl systemtap-testsuite-0.6.2-1.fc9.i386 requires /bin/bash systemtap-testsuite-0.6.2-1.fc9.i386 requires /usr/bin/tclsh systemtap-testsuite-0.6.2-1.fc9.i386 requires /usr/bin/stap systemtap-testsuite-0.6.2-1.fc9.i386 requires /usr/bin/env systemtap-testsuite-0.6.2-1.fc9.i386 requires /bin/sh sysusage-2.6-3.fc9.noarch requires /usr/bin/perl sysvinit-tools-2.86-24.i386 requires /bin/sh t1lib-5.1.2-2.fc9.i386 requires /bin/sh t1lib-5.1.2-2.fc9.i386 requires /sbin/ldconfig t1lib-5.1.2-2.fc9.i386 requires /bin/sh taglib-1.5-1.fc9.i386 requires /sbin/ldconfig taglib-devel-1.5-1.fc9.i386 requires /bin/sh tagsoup-1.0.1-2jpp.1.fc9.i386 requires /bin/sh tagtool-0.12.3-4.fc9.i386 requires /bin/sh tailor-0.9.30-1.fc9.noarch requires /usr/bin/python taipeifonts-1.2-5.fc9.noarch requires /bin/sh tango-icon-theme-0.8.1-1.fc8.noarch requires /bin/sh tango-icon-theme-extras-0.1.0-1.fc7.noarch requires /bin/sh tanukiwrapper-3.2.3-2jpp.1.fc9.i386 requires /bin/sh tanukiwrapper-javadoc-3.2.3-2jpp.1.fc9.i386 requires /bin/sh tanukiwrapper-javadoc-3.2.3-2jpp.1.fc9.i386 requires /bin/rm tanukiwrapper-javadoc-3.2.3-2jpp.1.fc9.i386 requires /bin/ln 2:tar-1.19-3.fc9.i386 requires /bin/sh 2:tar-1.19-3.fc9.i386 requires /sbin/install-info taskcoach-0.69.1-2.fc9.noarch requires /bin/sh taskcoach-0.69.1-2.fc9.noarch requires /usr/bin/env taskcoach-0.69.1-2.fc9.noarch requires /usr/bin/python taskjuggler-2.4.1-1.fc10.i386 requires /bin/sh tasks-0.12-2.fc10.i386 requires /bin/sh taxipilot-0.9.2-6.fc9.i386 requires /bin/sh tbb-2.0-4.20070927.fc9.i386 requires /sbin/ldconfig tcd-utils-20061127-1.fc9.3.i386 requires /bin/sh 1:tcl-8.5.1-4.fc10.i386 requires /sbin/ldconfig tclabc-1.1.0-1.fc9.i386 requires /bin/sh tcldebugger-1.4-6.20061030cvs.fc9.noarch requires /bin/sh tclhttpd-3.5.1-19.fc9.i386 requires /bin/sh tclhttpd-3.5.1-19.fc9.i386 requires /sbin/chkconfig tclhttpd-3.5.1-19.fc9.i386 requires /bin/sh tclhttpd-3.5.1-19.fc9.i386 requires /sbin/service tcllib-1.10-2.fc9.noarch requires /bin/sh tclpro-1.5.0-11.20061030cvs.fc9.noarch requires /bin/sh tclx-8.4.0-10.fc9.i386 requires /sbin/ldconfig tcp_wrappers-libs-7.6-52.fc9.i386 requires /sbin/ldconfig 14:tcpdump-3.9.8-4.fc9.i386 requires /bin/sh tcpreplay-3.3.0-1.fc10.i386 requires /usr/sbin/tcpdump tcsh-6.15-4.fc9.i386 requires /bin/sh teckit-2.2.1-3.fc9.i386 requires /sbin/ldconfig teckit-devel-2.2.1-3.fc9.i386 requires /sbin/ldconfig tecnoballz-0.92-4.fc9.i386 requires /bin/sh teg-0.11.2-15.fc9.i386 requires /bin/sh telepathy-butterfly-0.3.1-1.fc9.noarch requires /usr/bin/python telepathy-glib-0.7.8-1.fc10.i386 requires /sbin/ldconfig telepathy-mission-control-4.64-1.fc9.i386 requires /sbin/ldconfig tellico-1.3.1-1.fc9.i386 requires /bin/sh tellico-1.3.1-1.fc9.i386 requires /usr/bin/env tempest-xscreensaver-0-0.6.20070929.fc9.i386 requires /bin/sh terminus-font-x11-4.20-8.fc8.noarch requires /bin/sh terminus-font-x11-4.20-8.fc8.noarch requires /usr/bin/fc-cache terminus-font-x11-4.20-8.fc8.noarch requires /usr/bin/mkfontdir testoob-1.13-4.fc9.noarch requires /usr/bin/env testoob-1.13-4.fc9.noarch requires /usr/bin/python tetex-IEEEtran-1.7.1-1.fc8.noarch requires /usr/bin/texhash tetex-IEEEtran-1.7.1-1.fc8.noarch requires /bin/sh tetex-IEEEtran-1.7.1-1.fc8.noarch requires /bin/sh tetex-bytefield-1.2a-3.fc6.noarch requires /bin/sh tetex-bytefield-1.2a-3.fc6.noarch requires /usr/bin/texhash tetex-dvipost-1.1-9.fc9.i386 requires /usr/bin/texhash tetex-elsevier-0.1.20071024-1.fc9.noarch requires /usr/bin/texhash tetex-eurofont-1.1.3-6.fc6.noarch requires /bin/sh tetex-font-cm-lgc-0.5-9.fc9.noarch requires /bin/sh tetex-font-kerkis-2.0-15.fc9.noarch requires /bin/sh tetex-fonts-hebrew-0.1-8.fc9.noarch requires /usr/bin/texhash tetex-fonts-hebrew-0.1-8.fc9.noarch requires /usr/bin/updmap-sys tetex-fonts-hebrew-0.1-8.fc9.noarch requires /bin/sh tetex-perltex-1.3-1.fc6.noarch requires /usr/bin/texhash tetex-perltex-1.3-1.fc6.noarch requires /usr/bin/perl tetex-perltex-1.3-1.fc6.noarch requires /bin/sh tetex-prosper-1.5-3.fc6.noarch requires /usr/bin/texhash tetex-prosper-1.5-3.fc6.noarch requires /bin/sh tetex-tex4ht-1.0.2008_02_28_2058-3.fc9.i386 requires /usr/bin/texhash tetex-tex4ht-1.0.2008_02_28_2058-3.fc9.i386 requires /usr/bin/perl tetex-tex4ht-1.0.2008_02_28_2058-3.fc9.i386 requires /usr/bin/dvipng tetex-tex4ht-1.0.2008_02_28_2058-3.fc9.i386 requires /bin/sh tetex-tex4ht-1.0.2008_02_28_2058-3.fc9.i386 requires /bin/sh tetex-unicode-0-7.20041017.fc6.noarch requires /bin/sh tetrinetx-1.13.16-4.fc9.i386 requires /bin/sh tetrinetx-1.13.16-4.fc9.i386 requires /sbin/chkconfig tetrinetx-1.13.16-4.fc9.i386 requires /usr/sbin/useradd tetrinetx-1.13.16-4.fc9.i386 requires /bin/sh tex-preview-11.85-7.fc9.noarch requires /bin/sh texi2html-1.78-3.fc8.noarch requires /bin/sh texi2html-1.78-3.fc8.noarch requires /usr/bin/perl texi2html-1.78-3.fc8.noarch requires /sbin/install-info texinfo-4.12-1.fc10.i386 requires /bin/sh texinfo-4.12-1.fc10.i386 requires /sbin/install-info texinfo-tex-4.12-1.fc10.i386 requires /bin/sh texinfo-tex-4.12-1.fc10.i386 requires /bin/sh texinfo-tex-4.12-1.fc10.i386 requires /usr/bin/texconfig-sys texlive-2007-31.fc10.i386 requires /bin/sh texlive-2007-31.fc10.i386 requires /usr/bin/fmtutil texlive-2007-31.fc10.i386 requires /bin/bash texlive-2007-31.fc10.i386 requires /bin/sh texlive-2007-31.fc10.i386 requires /sbin/restorecon texlive-afm-2007-31.fc10.i386 requires /bin/sh texlive-afm-2007-31.fc10.i386 requires /sbin/restorecon texlive-context-2007-31.fc10.i386 requires /bin/sh texlive-context-2007-31.fc10.i386 requires /sbin/restorecon texlive-context-2007-31.fc10.i386 requires /usr/bin/env texlive-context-2007-31.fc10.i386 requires /bin/sh texlive-doc-2007-31.fc10.i386 requires /usr/bin/env texlive-doc-2007-31.fc10.i386 requires /bin/sh texlive-dvips-2007-31.fc10.i386 requires /bin/sh texlive-dvips-2007-31.fc10.i386 requires /bin/sh texlive-dvips-2007-31.fc10.i386 requires /sbin/restorecon texlive-dviutils-2007-31.fc10.i386 requires /bin/sh texlive-dviutils-2007-31.fc10.i386 requires /sbin/restorecon texlive-dviutils-2007-31.fc10.i386 requires /bin/sh texlive-east-asian-2007-31.fc10.i386 requires /bin/sh texlive-east-asian-2007-31.fc10.i386 requires /bin/sh texlive-east-asian-2007-31.fc10.i386 requires /sbin/restorecon texlive-latex-2007-31.fc10.i386 requires /usr/bin/fmtutil-sys texlive-latex-2007-31.fc10.i386 requires /bin/sh texlive-latex-2007-31.fc10.i386 requires /usr/bin/fmtutil texlive-latex-2007-31.fc10.i386 requires /sbin/restorecon texlive-latex-2007-31.fc10.i386 requires /sbin/install-info texlive-latex-2007-31.fc10.i386 requires /bin/sh texlive-latex-2007-31.fc10.i386 requires /usr/bin/texconfig-sys texlive-texmf-2007-21.fc10.noarch requires /bin/sh texlive-texmf-2007-21.fc10.noarch requires /sbin/restorecon texlive-texmf-2007-21.fc10.noarch requires /bin/sh texlive-texmf-afm-2007-21.fc10.noarch requires /bin/sh texlive-texmf-afm-2007-21.fc10.noarch requires /sbin/restorecon texlive-texmf-context-2007-21.fc10.noarch requires /bin/sh texlive-texmf-context-2007-21.fc10.noarch requires /sbin/restorecon texlive-texmf-context-2007-21.fc10.noarch requires /usr/bin/env texlive-texmf-context-2007-21.fc10.noarch requires /bin/sh texlive-texmf-doc-2007-21.fc10.noarch requires /bin/sh texlive-texmf-doc-2007-21.fc10.noarch requires /sbin/restorecon texlive-texmf-doc-2007-21.fc10.noarch requires /usr/bin/perl texlive-texmf-doc-2007-21.fc10.noarch requires /usr/bin/env texlive-texmf-doc-2007-21.fc10.noarch requires /bin/sh texlive-texmf-dvips-2007-21.fc10.noarch requires /bin/sh texlive-texmf-dvips-2007-21.fc10.noarch requires /sbin/restorecon texlive-texmf-east-asian-2007-21.fc10.noarch requires /bin/sh texlive-texmf-east-asian-2007-21.fc10.noarch requires /sbin/restorecon texlive-texmf-fonts-2007-21.fc10.noarch requires /bin/sh texlive-texmf-fonts-2007-21.fc10.noarch requires /sbin/restorecon texlive-texmf-latex-2007-21.fc10.noarch requires /bin/sh texlive-texmf-latex-2007-21.fc10.noarch requires /sbin/restorecon texlive-texmf-xetex-2007-21.fc10.noarch requires /bin/sh texlive-texmf-xetex-2007-21.fc10.noarch requires /sbin/restorecon texlive-texmf-xetex-2007-21.fc10.noarch requires /usr/bin/perl texlive-utils-2007-31.fc10.i386 requires /usr/bin/env texlive-utils-2007-31.fc10.i386 requires /usr/bin/perl texlive-utils-2007-31.fc10.i386 requires /bin/sh texlive-xetex-2007-31.fc10.i386 requires /bin/sh texlive-xetex-2007-31.fc10.i386 requires /sbin/restorecon 1:texmaker-1.7-1.fc10.i386 requires /bin/sh textflow-0.2.3.1-1.fc10.noarch requires /usr/bin/python tftp-server-0.48-3.fc9.i386 requires /bin/sh tftp-server-0.48-3.fc9.i386 requires /sbin/service tgif-4.1.45-6.fc9.i386 requires /bin/sh tgif-4.1.45-6.fc9.i386 requires /bin/bash thaifonts-scalable-0.4.9-3.fc9.noarch requires /bin/sh themonospot-0.7.0.1-1.fc10.i386 requires /bin/sh thinkfinger-0.3-8.fc9.i386 requires /sbin/ldconfig thttpd-2.25b-16.fc9.i386 requires /bin/sh thttpd-2.25b-16.fc9.i386 requires /bin/bash thttpd-2.25b-16.fc9.i386 requires /sbin/chkconfig thttpd-2.25b-16.fc9.i386 requires /usr/sbin/groupadd thttpd-2.25b-16.fc9.i386 requires /usr/sbin/useradd thttpd-2.25b-16.fc9.i386 requires /bin/sh thttpd-2.25b-16.fc9.i386 requires /sbin/service thunar-archive-plugin-0.2.4-4.fc9.i386 requires /bin/sh thunar-archive-plugin-0.2.4-4.fc9.i386 requires /bin/sh thunar-shares-0.10-1.fc8.i386 requires /bin/sh thunar-volman-0.2.0-2.fc9.i386 requires /bin/sh thunar-volman-0.2.0-2.fc9.i386 requires /bin/sh thunderbird-2.0.0.14-1.fc10.i386 requires /bin/bash thunderbird-2.0.0.14-1.fc10.i386 requires /bin/sh thunderbird-2.0.0.14-1.fc10.i386 requires /bin/sh thunderbird-lightning-0.8-3.fc9.i386 requires libhunspell.so.1 thunderbird-lightning-0.8-3.fc9.i386 requires /bin/sh thunderbird-lightning-0.8-3.fc9.i386 requires /bin/sh tibetan-machine-uni-fonts-1.901-1.fc9.noarch requires /bin/sh tiger-3.2.1-8.fc9.i386 requires /usr/bin/perl tiger-3.2.1-8.fc9.i386 requires /bin/sh time-1.7-33.fc9.i386 requires /bin/sh time-1.7-33.fc9.i386 requires /sbin/install-info timidity++-2.13.2-16.fc10.i386 requires /bin/sh tin-1.8.3-4.fc9.i386 requires /usr/bin/perl tin-1.8.3-4.fc9.i386 requires /bin/sh tinyca2-0.7.5-3.fc7.noarch requires /usr/bin/perl tinyerp-4.2.2-1.fc9.noarch requires /bin/sh tinyerp-server-4.2.2-1.fc9.noarch requires /bin/sh tinyerp-server-4.2.2-1.fc9.noarch requires /usr/bin/python tinyerp-server-4.2.2-1.fc9.noarch requires /sbin/service tinyerp-server-4.2.2-1.fc9.noarch requires /bin/bash tinyerp-server-4.2.2-1.fc9.noarch requires /bin/sh tinyerp-server-4.2.2-1.fc9.noarch requires /sbin/chkconfig tinyproxy-1.6.3-2.fc10.i386 requires /bin/sh tinyproxy-1.6.3-2.fc10.i386 requires /bin/sh tinyxml-2.5.3-3.fc9.i386 requires /sbin/ldconfig tiobench-0.3.3-7.1.i386 requires /usr/bin/perl tiresias-fonts-1.0-2.fc9.noarch requires /bin/sh 1:tix-8.4.2-5.fc9.i386 requires /etc/ld.so.conf.d 1:tix-8.4.2-5.fc9.i386 requires /sbin/ldconfig 1:tk-8.5.1-4.fc10.i386 requires /bin/sh 1:tk-8.5.1-4.fc10.i386 requires /sbin/ldconfig 1:tk-8.5.1-4.fc10.i386 requires /bin/sh tkcon-2.4-6.fc8.noarch requires /bin/sh tkcvs-8.1-1.fc9.noarch requires /bin/sh tkimg-1.3-0.10.20080505svn.fc10.i386 requires /sbin/ldconfig tklib-0.4.1-7.fc9.noarch requires /bin/sh tla-1.3.5-5.fc9.i386 requires /bin/sh tmda-1.1.12-1.fc8.noarch requires /usr/bin/python tmda-ofmipd-1.1.12-1.fc8.noarch requires /bin/sh tmda-ofmipd-1.1.12-1.fc8.noarch requires /bin/bash tmda-ofmipd-1.1.12-1.fc8.noarch requires /sbin/chkconfig tmda-ofmipd-1.1.12-1.fc8.noarch requires /usr/bin/python tmpwatch-2.9.13-2.i386 requires /bin/sh tn5250-0.17.3-19.fc9.i386 requires /bin/sh tn5250-0.17.3-19.fc9.i386 requires /usr/bin/tic tn5250-0.17.3-19.fc9.i386 requires /sbin/ldconfig tn5250-0.17.3-19.fc9.i386 requires /bin/sh tn5250-devel-0.17.3-19.fc9.i386 requires /bin/sh 2:tog-pegasus-2.7.0-7.fc10.i386 requires /sbin/ldconfig 2:tog-pegasus-2.7.0-7.fc10.i386 requires /bin/sh 2:tog-pegasus-2.7.0-7.fc10.i386 requires /bin/bash 2:tog-pegasus-devel-2.7.0-7.fc10.i386 requires /bin/sh tokyocabinet-1.2.5-1.fc10.i386 requires /sbin/ldconfig tolua++-1.0.92-7.fc9.i386 requires /sbin/ldconfig tomboy-0.10.1-2.fc9.i386 requires /usr/bin/env tomboy-0.10.1-2.fc9.i386 requires /bin/sh tomcat-native-1.1.13-1.fc9.i386 requires /sbin/ldconfig tomcat5-5.5.26-1jpp.2.fc9.i386 requires /bin/sh tomcat5-5.5.26-1jpp.2.fc9.i386 requires /usr/sbin/groupadd tomcat5-5.5.26-1jpp.2.fc9.i386 requires /usr/sbin/useradd tomcat5-5.5.26-1jpp.2.fc9.i386 requires /sbin/chkconfig tomcat5-5.5.26-1jpp.2.fc9.i386 requires /bin/bash tomcat5-5.5.26-1jpp.2.fc9.i386 requires /bin/sh tomcat5-5.5.26-1jpp.2.fc9.i386 requires /bin/rm tomcat5-admin-webapps-5.5.26-1jpp.2.fc9.i386 requires /bin/sh tomcat5-admin-webapps-5.5.26-1jpp.2.fc9.i386 requires /bin/rm tomcat5-common-lib-5.5.26-1jpp.2.fc9.i386 requires /bin/sh tomcat5-common-lib-5.5.26-1jpp.2.fc9.i386 requires /bin/rm tomcat5-jasper-5.5.26-1jpp.2.fc9.i386 requires /bin/sh tomcat5-jasper-eclipse-5.5.26-1jpp.2.fc9.i386 requires /bin/sh tomcat5-jsp-2.0-api-5.5.26-1jpp.2.fc9.i386 requires /bin/sh tomcat5-jsp-2.0-api-5.5.26-1jpp.2.fc9.i386 requires /sbin/chkconfig tomcat5-jsp-2.0-api-5.5.26-1jpp.2.fc9.i386 requires /usr/sbin/update-alternatives tomcat5-jsp-2.0-api-javadoc-5.5.26-1jpp.2.fc9.i386 requires /bin/sh tomcat5-jsp-2.0-api-javadoc-5.5.26-1jpp.2.fc9.i386 requires /bin/rm tomcat5-jsp-2.0-api-javadoc-5.5.26-1jpp.2.fc9.i386 requires /bin/ln tomcat5-server-lib-5.5.26-1jpp.2.fc9.i386 requires /bin/sh tomcat5-server-lib-5.5.26-1jpp.2.fc9.i386 requires /bin/rm tomcat5-servlet-2.4-api-5.5.26-1jpp.2.fc9.i386 requires /bin/sh tomcat5-servlet-2.4-api-5.5.26-1jpp.2.fc9.i386 requires /sbin/chkconfig tomcat5-servlet-2.4-api-5.5.26-1jpp.2.fc9.i386 requires /usr/sbin/update-alternatives tomcat5-servlet-2.4-api-javadoc-5.5.26-1jpp.2.fc9.i386 requires /bin/sh tomcat5-servlet-2.4-api-javadoc-5.5.26-1jpp.2.fc9.i386 requires /bin/rm tomcat5-servlet-2.4-api-javadoc-5.5.26-1jpp.2.fc9.i386 requires /bin/ln tomcat5-webapps-5.5.26-1jpp.2.fc9.i386 requires /bin/sh tomcat5-webapps-5.5.26-1jpp.2.fc9.i386 requires /bin/rm tomcat6-6.0.16-1jpp.7.fc9.noarch requires /bin/sh tomcat6-6.0.16-1jpp.7.fc9.noarch requires /sbin/chkconfig tomcat6-6.0.16-1jpp.7.fc9.noarch requires /sbin/service tomcat6-jsp-2.1-api-6.0.16-1jpp.7.fc9.noarch requires /bin/sh tomcat6-lib-6.0.16-1jpp.7.fc9.noarch requires /bin/sh tomcat6-servlet-2.5-api-6.0.16-1jpp.7.fc9.noarch requires /bin/sh tomcat6-webapps-6.0.16-1jpp.7.fc9.noarch requires /bin/sh tomoe-0.6.0-5.fc9.i386 requires /sbin/ldconfig tong-1.0-10.fc9.i386 requires /bin/sh toped-0.8.6-2.fc9.i386 requires /bin/sh tor-core-0.1.2.19-1.fc9.i386 requires /bin/sh tor-core-0.1.2.19-1.fc9.i386 requires /etc/logrotate.d tor-lsb-0.1.2.19-1.fc9.i386 requires /bin/sh tor-lsb-0.1.2.19-1.fc9.i386 requires /bin/sh torcs-1.3.0-6.fc9.i386 requires libplibssgaux.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibssg.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires /bin/bash torcs-1.3.0-6.fc9.i386 requires libplibsl.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibsm.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibsg.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibul.so.1.8.4 torque-2.1.10-5.fc9.i386 requires /bin/sh torque-2.1.10-5.fc9.i386 requires /bin/sh torque-client-2.1.10-5.fc9.i386 requires /bin/sh torque-gui-2.1.10-5.fc9.i386 requires /usr/bin/pbs_wish torque-gui-2.1.10-5.fc9.i386 requires /usr/bin/wish8.5 torque-mom-2.1.10-5.fc9.i386 requires /bin/sh torque-mom-2.1.10-5.fc9.i386 requires /bin/sh torque-scheduler-2.1.10-5.fc9.i386 requires /bin/sh torque-scheduler-2.1.10-5.fc9.i386 requires /bin/sh torque-server-2.1.10-5.fc9.i386 requires /bin/sh torque-server-2.1.10-5.fc9.i386 requires /bin/sh totem-2.23.2-2.fc9.i386 requires /bin/sh totem-2.23.2-2.fc9.i386 requires /usr/bin/python totem-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 totem-2.23.2-2.fc9.i386 requires /bin/sh totem-gstreamer-2.23.2-2.fc9.i386 requires /bin/sh totem-mozplugin-2.23.2-2.fc9.i386 requires libtotem-plparser-mini.so.10 totem-mozplugin-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 totem-mythtv-2.23.2-2.fc9.i386 requires /bin/sh totem-nautilus-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 totem-pl-parser-2.23.1-2.fc10.i386 requires /sbin/ldconfig totem-xine-2.23.2-2.fc9.i386 requires /bin/sh tpb-0.6.4-10.fc9.i386 requires /bin/sh tpb-0.6.4-10.fc9.i386 requires /bin/sh tpm-tools-1.3.1-5.fc9.i386 requires /sbin/ldconfig trac-0.10.4-2.fc9.noarch requires /usr/bin/python trackballs-1.1.4-6.fc9.i386 requires /bin/sh tracker-0.6.6-2.fc9.i386 requires /sbin/ldconfig tracker-0.6.6-2.fc9.i386 requires /bin/sh tracker-search-tool-0.6.6-2.fc9.i386 requires /bin/sh 1:transfig-3.2.5-2.fc9.i386 requires /bin/csh 1:transfig-3.2.5-2.fc9.i386 requires /bin/sh translate-toolkit-1.0.1-1.fc9.noarch requires /bin/bash translate-toolkit-1.0.1-1.fc9.noarch requires /usr/bin/python transmission-1.20-1.fc10.i386 requires /bin/sh tre-0.7.5-5.fc9.i386 requires /sbin/ldconfig treecc-0.3.8-5.fc9.i386 requires /bin/sh tremulous-1.1.0-6.fc9.i386 requires /bin/sh tripwire-2.4.1.2-5.fc9.i386 requires /bin/sh tripwire-2.4.1.2-5.fc9.i386 requires /bin/sh trousers-0.3.1-5.fc9.i386 requires /sbin/service trousers-0.3.1-5.fc9.i386 requires /sbin/ldconfig trousers-0.3.1-5.fc9.i386 requires /bin/bash trousers-0.3.1-5.fc9.i386 requires /sbin/chkconfig trousers-0.3.1-5.fc9.i386 requires /bin/sh ttywatch-0.14-11.fc9.i386 requires /bin/sh ttywatch-0.14-11.fc9.i386 requires /sbin/chkconfig ttywatch-0.14-11.fc9.i386 requires /bin/sh ttywatch-0.14-11.fc9.i386 requires /sbin/service turba-2.1.7-1.fc9.noarch requires /usr/bin/perl turba-2.1.7-1.fc9.noarch requires /usr/bin/php turba-2.1.7-1.fc9.noarch requires /bin/sh 1:tuxpaint-0.9.17-3.fc9.i386 requires /usr/share/icons/hicolor/scalable 1:tuxpaint-0.9.17-3.fc9.i386 requires /bin/sh tuxpuck-0.8.2-6.fc10.i386 requires /bin/sh tvtime-1.0.2-2.fc9.i386 requires /bin/sh twitux-0.62-1.fc10.i386 requires /bin/sh ucarp-1.4-1.fc9.i386 requires /bin/sh ucarp-1.4-1.fc9.i386 requires /bin/bash ucarp-1.4-1.fc9.i386 requires /sbin/chkconfig ucarp-1.4-1.fc9.i386 requires /bin/sh ucarp-1.4-1.fc9.i386 requires /sbin/service ucblogo-5.5-10.fc9.i386 requires /bin/sh ucblogo-5.5-10.fc9.i386 requires /sbin/install-info ucl-1.03-8.fc9.i386 requires /sbin/ldconfig udev-121-1.20080516git.fc10.i386 requires /bin/sh udev-121-1.20080516git.fc10.i386 requires /sbin/service udev-121-1.20080516git.fc10.i386 requires /bin/bash udev-121-1.20080516git.fc10.i386 requires /bin/sh udev-121-1.20080516git.fc10.i386 requires /sbin/chkconfig udev-packagekit-0.2.1-2.20080508.fc10.i386 requires /bin/sh ufraw-0.13-4.fc9.i386 requires /bin/sh ufraw-common-0.13-4.fc9.i386 requires /bin/sh uim-1.4.2-3.fc10.i386 requires /bin/sh uim-1.4.2-3.fc10.i386 requires /sbin/ldconfig uim-1.4.2-3.fc10.i386 requires /usr/sbin/alternatives uim-anthy-1.4.2-3.fc10.i386 requires /bin/sh uim-anthy-1.4.2-3.fc10.i386 requires /usr/bin/uim-module-manager uim-canna-1.4.2-3.fc10.i386 requires /bin/sh uim-canna-1.4.2-3.fc10.i386 requires /usr/bin/uim-module-manager uim-gnome-1.4.2-3.fc10.i386 requires /usr/sbin/bonobo-activation-sysconf uim-gnome-1.4.2-3.fc10.i386 requires /bin/sh uim-gtk2-1.4.2-3.fc10.i386 requires /bin/sh uim-m17n-1.4.2-3.fc10.i386 requires /bin/sh uim-m17n-1.4.2-3.fc10.i386 requires /usr/bin/uim-module-manager uim-skk-1.4.2-3.fc10.i386 requires /bin/sh uim-skk-1.4.2-3.fc10.i386 requires /usr/bin/uim-module-manager ularn-1.5p4-11.fc9.i386 requires /bin/sh ulogd-1.24-9.fc9.i386 requires /bin/sh ulogd-1.24-9.fc9.i386 requires /bin/sh unicap-0.2.19-3.fc9.i386 requires /sbin/ldconfig uniconvertor-1.1.2-2.fc10.i386 requires /bin/sh uniconvertor-1.1.2-2.fc10.i386 requires /usr/bin/python unifdef-1.171-7.fc9.i386 requires /bin/sh unique-0.9.4-5.fc10.i386 requires /sbin/ldconfig unison213-2.13.16-10.fc9.i386 requires /usr/sbin/alternatives unison213-2.13.16-10.fc9.i386 requires /usr/sbin/alternatives unison213-2.13.16-10.fc9.i386 requires /bin/sh unison213-2.13.16-10.fc9.i386 requires /bin/sh unison227-2.27.57-8.fc9.i386 requires /usr/sbin/alternatives unison227-2.27.57-8.fc9.i386 requires /usr/sbin/alternatives unison227-2.27.57-8.fc9.i386 requires /bin/sh unison227-2.27.57-8.fc9.i386 requires /bin/sh units-1.87-2.fc9.i386 requires /bin/sh units-1.87-2.fc9.i386 requires /sbin/install-info unixODBC-2.2.12-7.fc9.i386 requires /sbin/ldconfig unixODBC-kde-2.2.12-7.fc9.i386 requires /sbin/ldconfig unixcw-2.3-2.fc9.i386 requires /sbin/ldconfig unshield-0.5-8.fc9.i386 requires /sbin/ldconfig unuran-1.2.4p1-1.fc10.i386 requires /bin/sh unuran-1.2.4p1-1.fc10.i386 requires /sbin/ldconfig unuran-1.2.4p1-1.fc10.i386 requires /sbin/install-info unzip-5.52-9.fc9.i386 requires /bin/sh up-imapproxy-1.2.4-9.fc9.i386 requires /bin/sh up-imapproxy-1.2.4-9.fc9.i386 requires /sbin/service up-imapproxy-1.2.4-9.fc9.i386 requires /bin/bash up-imapproxy-1.2.4-9.fc9.i386 requires /sbin/chkconfig uqm-0.6.2-3.fc9.i386 requires /bin/sh urbanterror-1.34-0.9.rc4.fc9.i386 requires /bin/sh urbanterror-1.34-0.9.rc4.fc9.i386 requires /bin/bash urlview-0.9-4.fc9.i386 requires /bin/bash urw-fonts-2.4-5.fc9.noarch requires /bin/sh usermode-1.97-1.i386 requires /etc/pam.d/system-auth ushare-1.1a-4.fc9.i386 requires /bin/sh ushare-1.1a-4.fc9.i386 requires /sbin/service ushare-1.1a-4.fc9.i386 requires /usr/sbin/alternatives ushare-1.1a-4.fc9.i386 requires /usr/sbin/alternatives ushare-1.1a-4.fc9.i386 requires /bin/sh ushare-1.1a-4.fc9.i386 requires /sbin/chkconfig usrp-3.1.1-4.fc9.i386 requires /usr/bin/env usrp-3.1.1-4.fc9.i386 requires /sbin/ldconfig ustr-1.0.4-6.fc9.i386 requires /sbin/ldconfig ustr-debug-1.0.4-6.fc9.i386 requires /sbin/ldconfig ustr-devel-1.0.4-6.fc9.i386 requires /bin/sh util-linux-ng-2.13.1-9.fc10.i386 requires /bin/sh util-linux-ng-2.13.1-9.fc10.i386 requires /sbin/install-info util-linux-ng-2.13.1-9.fc10.i386 requires /etc/pam.d/system-auth util-vserver-0.30.215-2.fc9.i386 requires /bin/sh util-vserver-0.30.215-2.fc9.i386 requires /usr/lib/util-vserver util-vserver-0.30.215-2.fc9.i386 requires /bin/bash util-vserver-0.30.215-2.fc9.i386 requires /usr/lib/util-vserver/sigexec util-vserver-0.30.215-2.fc9.i386 requires /bin/sh util-vserver-build-0.30.215-2.fc9.i386 requires /etc/vservers util-vserver-build-0.30.215-2.fc9.i386 requires /bin/sh util-vserver-build-0.30.215-2.fc9.i386 requires /bin/bash util-vserver-build-0.30.215-2.fc9.i386 requires /bin/sh util-vserver-core-0.30.215-2.fc9.i386 requires /bin/bash util-vserver-legacy-0.30.215-2.fc9.i386 requires /bin/bash util-vserver-legacy-0.30.215-2.fc9.i386 requires /bin/sh util-vserver-legacy-0.30.215-2.fc9.i386 requires /usr/bin/perl util-vserver-legacy-0.30.215-2.fc9.i386 requires /usr/lib/util-vserver util-vserver-legacy-0.30.215-2.fc9.i386 requires /sbin/chkconfig util-vserver-legacy-0.30.215-2.fc9.i386 requires /etc/rc.d/init.d util-vserver-legacy-0.30.215-2.fc9.i386 requires /bin/sh util-vserver-lib-0.30.215-2.fc9.i386 requires /sbin/ldconfig util-vserver-sysv-0.30.215-2.fc9.i386 requires /bin/sh util-vserver-sysv-0.30.215-2.fc9.i386 requires /bin/bash util-vserver-sysv-0.30.215-2.fc9.i386 requires /usr/lib/util-vserver util-vserver-sysv-0.30.215-2.fc9.i386 requires /sbin/chkconfig util-vserver-sysv-0.30.215-2.fc9.i386 requires /etc/rc.d/init.d util-vserver-sysv-0.30.215-2.fc9.i386 requires /bin/sh uucp-1.07-17.fc9.i386 requires /bin/sh uucp-1.07-17.fc9.i386 requires /bin/sh uucp-1.07-17.fc9.i386 requires /usr/bin/perl uucp-1.07-17.fc9.i386 requires /sbin/install-info uudeview-0.5.20-16.i386 requires /bin/sh uuid-1.6.1-3.fc9.i386 requires /sbin/ldconfig uuid-c++-1.6.1-3.fc9.i386 requires /sbin/ldconfig uuid-dce-1.6.1-3.fc9.i386 requires /sbin/ldconfig uuid-devel-1.6.1-3.fc9.i386 requires /bin/sh uuid-devel-1.6.1-3.fc9.i386 requires /usr/lib/pkgconfig uuid-pgsql-1.6.1-3.fc9.i386 requires /usr/lib/pgsql uuid-pgsql-1.6.1-3.fc9.i386 requires /usr/share/pgsql uuid-php-1.6.1-3.fc9.i386 requires /usr/lib/php/modules uuidd-1.40.9-2.fc10.i386 requires /bin/sh uuidd-1.40.9-2.fc10.i386 requires /bin/bash uw-imap-2007a1-3.fc9.i386 requires /bin/sh vala-0.1.7-1.fc9.i386 requires /sbin/ldconfig vala-tools-0.1.7-1.fc9.i386 requires /bin/sh 1:valgrind-3.3.0-3.i386 requires /usr/bin/perl vamp-plugin-sdk-1.1b-4.fc9.i386 requires /sbin/ldconfig varconf-0.6.5-3.fc9.i386 requires /sbin/ldconfig varnish-1.1.2-6.fc9.i386 requires /bin/sh varnish-1.1.2-6.fc9.i386 requires /sbin/service varnish-1.1.2-6.fc9.i386 requires /bin/sh varnish-1.1.2-6.fc9.i386 requires /sbin/chkconfig varnish-libs-1.1.2-6.fc9.i386 requires /sbin/ldconfig vavoom-1.27.1-1.fc9.i386 requires /bin/sh vavoom-1.27.1-1.fc9.i386 requires /bin/bash vblade-14-4.fc9.i386 requires /bin/sh vblade-14-4.fc9.i386 requires /sbin/chkconfig vblade-14-4.fc9.i386 requires /bin/sh vblade-14-4.fc9.i386 requires /sbin/service vdccm-0.10.1-3.fc9.i386 requires /sbin/ldconfig vdr-1.6.0-3.fc9.i386 requires /bin/sh vdr-1.6.0-3.fc9.i386 requires /bin/bash vdr-1.6.0-3.fc9.i386 requires /bin/sh vdr-1.6.0-3.fc9.i386 requires /usr/bin/perl vdr-1.6.0-3.fc9.i386 requires /sbin/chkconfig vdr-devel-1.6.0-3.fc9.i386 requires /bin/bash vdr-devel-1.6.0-3.fc9.i386 requires /usr/bin/perl vdr-osdteletext-0.5.1-31.fc9.i386 requires /bin/sh vdr-skins-20061119-6.fc9.noarch requires /bin/sh vdr-text2skin-1.1-23.cvsext0.10.fc9.i386 requires /bin/sh vdradmin-am-3.6.1-1.fc8.noarch requires /bin/sh vdradmin-am-3.6.1-1.fc8.noarch requires /usr/bin/perl vdradmin-am-3.6.1-1.fc8.noarch requires /bin/sh vdradmin-am-3.6.1-1.fc8.noarch requires /sbin/chkconfig vdrift-20071226-3.fc9.i386 requires /bin/sh vecmath1.2-1.14-2.fc9.i386 requires /bin/sh vecmath1.2-javadoc-1.14-2.fc9.i386 requires /bin/sh vegastrike-0.5.0-2.fc10.i386 requires /usr/bin/perl vegastrike-0.5.0-2.fc10.i386 requires /bin/sh vegastrike-data-0.5.0-2.noarch requires /bin/sh vegastrike-data-0.5.0-2.noarch requires /usr/bin/python velocity-1.4-7jpp.1.i386 requires /bin/sh velocity-demo-1.4-7jpp.1.i386 requires /bin/sh velocity-javadoc-1.4-7jpp.1.i386 requires /bin/sh velocity-javadoc-1.4-7jpp.1.i386 requires /bin/rm velocity-javadoc-1.4-7jpp.1.i386 requires /bin/ln verbiste-0.1.22-1.fc9.i386 requires /sbin/ldconfig verbiste-gnome-0.1.22-1.fc9.i386 requires /bin/sh veusz-1.0-3.fc9.i386 requires /bin/sh veusz-1.0-3.fc9.i386 requires /usr/bin/env veusz-1.0-3.fc9.i386 requires /usr/bin/python viewvc-1.0.5-1.fc9.noarch requires /usr/bin/python vigra-1.5.0-4.fc9.i386 requires /sbin/ldconfig vigra-devel-1.5.0-4.fc9.i386 requires /bin/sh 2:vim-X11-7.1.298-1.fc10.i386 requires /bin/sh 2:vim-X11-7.1.298-1.fc10.i386 requires /bin/sh 2:vim-common-7.1.298-1.fc10.i386 requires /bin/sh 2:vim-enhanced-7.1.298-1.fc10.i386 requires /bin/sh vim-vimoutliner-0.3.4-9.fc7.noarch requires /bin/sh vim-vimoutliner-0.3.4-9.fc7.noarch requires /usr/bin/perl vim-vimoutliner-0.3.4-9.fc7.noarch requires /usr/bin/python vinagre-2.23.1-1.fc10.i386 requires /bin/sh vino-2.22.1-1.fc9.i386 requires /bin/sh vips-7.14.1-1.fc9.i386 requires /sbin/ldconfig vips-7.14.1-1.fc9.i386 requires libWand.so.10 vips-7.14.1-1.fc9.i386 requires libMagick.so.10 vips-python-7.14.1-1.fc9.i386 requires libWand.so.10 vips-python-7.14.1-1.fc9.i386 requires libMagick.so.10 vips-tools-7.14.1-1.fc9.i386 requires /bin/bash vips-tools-7.14.1-1.fc9.i386 requires /bin/sh vips-tools-7.14.1-1.fc9.i386 requires libWand.so.10 vips-tools-7.14.1-1.fc9.i386 requires libMagick.so.10 virt-manager-0.5.4-3.fc9.i386 requires /bin/sh virt-manager-0.5.4-3.fc9.i386 requires /bin/sh vkeybd-0.1.17a-7.fc9.i386 requires /bin/sh vkeybd-0.1.17a-7.fc9.i386 requires /usr/bin/wish vlock-1.3-26.fc9.i386 requires /etc/pam.d/system-auth vnc-4.1.2-30.fc10.i386 requires /bin/sh vnc-libs-4.1.2-30.fc10.i386 requires /bin/sh vnc-ltsp-config-4.0-4.fc9.noarch requires /bin/sh vnc-ltsp-config-4.0-4.fc9.noarch requires /bin/sh vnc-server-4.1.2-30.fc10.i386 requires /bin/sh vnc-server-4.1.2-30.fc10.i386 requires /usr/bin/env vnc-server-4.1.2-30.fc10.i386 requires /bin/bash vnstat-1.6-2.fc9.i386 requires /bin/sh vnstat-1.6-2.fc9.i386 requires /usr/sbin/useradd vodovod-1.10-2.fc9.i386 requires /bin/sh vodovod-1.10-2.fc9.i386 requires /bin/sh vpnc-0.5.1-5.fc9.i386 requires /bin/sh vpnc-consoleuser-0.5.1-5.fc9.i386 requires /bin/sh vsftpd-2.0.6-3.fc9.i386 requires /bin/sh vsftpd-2.0.6-3.fc9.i386 requires /sbin/service vsftpd-2.0.6-3.fc9.i386 requires /bin/bash vsftpd-2.0.6-3.fc9.i386 requires /lib/security/pam_loginuid.so vsftpd-2.0.6-3.fc9.i386 requires /sbin/chkconfig vte-0.16.13-1.fc9.i386 requires /sbin/ldconfig vte-devel-0.16.13-1.fc9.i386 requires /bin/sh vtk-5.0.4-21.fc9.i386 requires /sbin/ldconfig vtk-devel-5.0.4-21.fc9.i386 requires /usr/bin/env vtk-python-5.0.4-21.fc9.i386 requires /sbin/ldconfig vtk-qt-5.0.4-21.fc9.i386 requires /sbin/ldconfig vtk-tcl-5.0.4-21.fc9.i386 requires /sbin/ldconfig vtk-testing-5.0.4-21.fc9.i386 requires /usr/bin/tclsh vtk-testing-5.0.4-21.fc9.i386 requires /usr/bin/env vym-1.10.0-3.fc9.i386 requires /bin/sh vym-1.10.0-3.fc9.i386 requires /usr/bin/perl vym-1.10.0-3.fc9.i386 requires /bin/bash w3c-libwww-5.4.1-0.10.20060206cvs.fc9.i386 requires /sbin/ldconfig w3c-libwww-devel-5.4.1-0.10.20060206cvs.fc9.i386 requires /bin/sh w3c-markup-validator-0.8.2-3.fc9.noarch requires /bin/sh w3c-markup-validator-0.8.2-3.fc9.noarch requires /usr/bin/perl w3c-markup-validator-libs-0.8.2-3.fc9.noarch requires /bin/sh w3m-0.5.2-10.fc10.i386 requires /usr/bin/perl w3m-el-common-1.4.4-7.fc9.noarch requires /bin/sh w3m-el-common-1.4.4-7.fc9.noarch requires /sbin/install-info waf-1.4.1-1.fc10.noarch requires /usr/bin/python wallpapoz-0.4.1-5.svn87_trunk.fc9.noarch requires /usr/bin/pgrep wallpapoz-0.4.1-5.svn87_trunk.fc9.noarch requires /usr/bin/kill wallpapoz-0.4.1-5.svn87_trunk.fc9.noarch requires /usr/bin/env wammu-0.26-2.fc9.noarch requires /usr/bin/python wavbreaker-0.9-3.fc9.i386 requires /bin/sh wavextract-1.0.0-3.fc9.noarch requires /usr/bin/env wavpack-4.41-2.fc9.i386 requires /sbin/ldconfig wbxml2-0.9.2-13.fc9.i386 requires /sbin/ldconfig wdaemon-0.13-1.fc9.i386 requires /bin/sh wdaemon-0.13-1.fc9.i386 requires /bin/bash wdm-1.28-10.fc9.i386 requires /etc/pam.d wdm-1.28-10.fc9.i386 requires /sbin/shutdown wdm-1.28-10.fc9.i386 requires /bin/bash wdm-1.28-10.fc9.i386 requires /bin/sh wdm-1.28-10.fc9.i386 requires /usr/bin/perl web2png-2.5.1-4.fc9.i386 requires /usr/bin/env webalizer-2.01_10-36.i386 requires /bin/sh webalizer-2.01_10-36.i386 requires /usr/sbin/useradd webalizer-2.01_10-36.i386 requires /bin/bash websec-1.9.0-4.1.noarch requires /usr/bin/perl werken-xpath-0.9.4-1.beta.12jpp.2.i386 requires /bin/sh werken-xpath-javadoc-0.9.4-1.beta.12jpp.2.i386 requires /bin/sh werken-xpath-javadoc-0.9.4-1.beta.12jpp.2.i386 requires /bin/ln werken-xpath-javadoc-0.9.4-1.beta.12jpp.2.i386 requires /bin/rm wesnoth-1.4.2-1.fc10.i386 requires /bin/sh wesnoth-server-1.4.2-1.fc10.i386 requires /bin/sh wesnoth-server-1.4.2-1.fc10.i386 requires /bin/sh wesnoth-server-1.4.2-1.fc10.i386 requires /sbin/chkconfig wesnoth-server-1.4.2-1.fc10.i386 requires /usr/sbin/useradd wesnoth-tools-1.4.2-1.fc10.i386 requires /usr/bin/env wfmath-0.3.7-2.fc9.i386 requires /sbin/ldconfig wfut-1.1.0-5.fc9.i386 requires /bin/sh wget-1.11.2-1.fc10.i386 requires /bin/sh wget-1.11.2-1.fc10.i386 requires /sbin/install-info which-2.19-3.fc9.i386 requires /bin/sh which-2.19-3.fc9.i386 requires /sbin/install-info whysynth-dssi-20070418-2.fc9.i386 requires /bin/sh widelands-0-0.9.build11.fc9.i386 requires /bin/sh wifi-radar-1.9.6-3.fc6.noarch requires /usr/bin/python wifiroamd-1.12-1.fc8.noarch requires /bin/sh wildmidi-libs-0.2.2-4.fc9.i386 requires /sbin/ldconfig wine-capi-0.9.58-1.fc9.i386 requires /sbin/ldconfig wine-cms-0.9.58-1.fc9.i386 requires /sbin/ldconfig wine-core-0.9.58-1.fc9.i386 requires /bin/sh wine-core-0.9.58-1.fc9.i386 requires /sbin/service wine-core-0.9.58-1.fc9.i386 requires /sbin/ldconfig wine-core-0.9.58-1.fc9.i386 requires /usr/bin/xmessage wine-core-0.9.58-1.fc9.i386 requires /bin/sh wine-core-0.9.58-1.fc9.i386 requires /sbin/chkconfig wine-devel-0.9.58-1.fc9.i386 requires /usr/bin/perl wine-esd-0.9.58-1.fc9.i386 requires /sbin/ldconfig wine-jack-0.9.58-1.fc9.i386 requires /sbin/ldconfig wine-ldap-0.9.58-1.fc9.i386 requires /sbin/ldconfig wine-nas-0.9.58-1.fc9.i386 requires /sbin/ldconfig wine-tools-0.9.58-1.fc9.i386 requires /usr/bin/perl wine-tools-0.9.58-1.fc9.i386 requires /bin/sh wine-twain-0.9.58-1.fc9.i386 requires /sbin/ldconfig wings-0.99.02-1.fc9.i386 requires /bin/sh winpdb-1.3.8-1.fc10.noarch requires /usr/bin/env winpdb-1.3.8-1.fc10.noarch requires /usr/bin/python 1:wireless-tools-29-2.fc9.i386 requires /sbin/ldconfig wireshark-1.0.0-2.fc9.i386 requires /sbin/ldconfig wkf-libs-1.3.11-2.fc9.i386 requires /sbin/ldconfig wklej-0.0.9-3.fc9.noarch requires /usr/bin/perl wlassistant-0.5.7-7.fc9.i386 requires /bin/sh wmx-6pl1-18.fc9.i386 requires /bin/bash wmx-6pl1-18.fc9.i386 requires /bin/sh wodim-1.1.6-11.fc9.i386 requires /bin/sh wodim-1.1.6-11.fc9.i386 requires /usr/sbin/alternatives wordwarvi-0.09-1.fc10.i386 requires /bin/sh worldofpadman-1.34-0.9.rc4.fc9.i386 requires /bin/bash worldofpadman-1.34-0.9.rc4.fc9.i386 requires /bin/sh worminator-3.0R2.1-8.fc9.i386 requires /bin/sh wormux-0.7.9-6.fc9.i386 requires /bin/sh wp_tray-0.5.3-7.fc9.i386 requires /bin/sh 1:wpa_supplicant-0.6.3-5.fc9.i386 requires /bin/sh 1:wpa_supplicant-0.6.3-5.fc9.i386 requires /bin/bash 1:wpa_supplicant-0.6.3-5.fc9.i386 requires /usr/bin/python wqy-bitmap-fonts-0.9.9-6.fc10.noarch requires /bin/sh wqy-unibit-fonts-1.1.0-4.fc8.noarch requires /bin/sh wqy-zenhei-fonts-0.5.23-0.fc9.noarch requires /bin/sh writer2latex-0.5-2.fc9.i386 requires /bin/sh ws-commons-util-1.0.1-6.fc8.i386 requires /usr/bin/rebuild-gcj-db wsdl4j-1.5.2-5jpp.2.fc9.i386 requires /bin/sh wsdl4j-javadoc-1.5.2-5jpp.2.fc9.i386 requires /bin/sh wsdl4j-javadoc-1.5.2-5jpp.2.fc9.i386 requires /bin/rm wsdl4j-javadoc-1.5.2-5jpp.2.fc9.i386 requires /bin/ln wuja-0.0.8-3.fc9.noarch requires /bin/sh wuja-0.0.8-3.fc9.noarch requires /usr/bin/python wv-1.2.4-4.fc9.i386 requires /sbin/ldconfig wv-1.2.4-4.fc9.i386 requires /bin/sh wv2-0.2.3-7.fc9.i386 requires /sbin/ldconfig wv2-devel-0.2.3-7.fc9.i386 requires /bin/sh wxBase-2.8.7-2.fc9.i386 requires /sbin/ldconfig wxGTK-2.8.7-2.fc9.i386 requires /sbin/ldconfig wxGTK-devel-2.8.7-2.fc9.i386 requires /bin/sh wxGTK-gl-2.8.7-2.fc9.i386 requires /sbin/ldconfig wxGlade-0.6.1-1.fc9.noarch requires /bin/sh wxGlade-0.6.1-1.fc9.noarch requires /bin/bash wxMaxima-0.7.4-3.fc9.i386 requires /bin/sh wxPython-2.8.7.1-2.fc9.i386 requires /usr/bin/env wxPython-2.8.7.1-2.fc9.i386 requires /usr/bin/python wxPython-2.8.7.1-2.fc9.i386 requires /bin/bash wxPython-2.8.7.1-2.fc9.i386 requires /bin/sh wxsvg-1.0-0.8.b10.fc10.i386 requires /sbin/ldconfig x11-ssh-askpass-1.2.4.1-4.fc9.i386 requires /usr/share/X11/app-defaults x3270-x11-3.3.6-5.fc9.i386 requires /bin/sh x3270-x11-3.3.6-5.fc9.i386 requires /usr/bin/mkfontdir xalan-c-1.10.0-4.fc9.i386 requires /sbin/ldconfig xalan-c-doc-1.10.0-4.fc9.i386 requires /bin/sh xalan-j2-2.7.0-7jpp.2.fc9.i386 requires /bin/sh xalan-j2-2.7.0-7jpp.2.fc9.i386 requires /usr/sbin/update-alternatives xalan-j2-demo-2.7.0-7jpp.2.fc9.i386 requires /bin/sh xalan-j2-javadoc-2.7.0-7jpp.2.fc9.i386 requires /bin/sh xalan-j2-javadoc-2.7.0-7jpp.2.fc9.i386 requires /bin/rm xalan-j2-javadoc-2.7.0-7jpp.2.fc9.i386 requires /bin/ln xalan-j2-xsltc-2.7.0-7jpp.2.fc9.i386 requires /bin/sh xaos-3.2.3-3.fc9.i386 requires /bin/sh xaos-3.2.3-3.fc9.i386 requires /sbin/install-info xapian-core-devel-1.0.6-1.fc9.i386 requires /bin/sh xapian-core-libs-1.0.6-1.fc9.i386 requires /sbin/ldconfig xar-1.5.1-6.fc9.i386 requires /sbin/ldconfig xarchiver-0.4.9-0.6.20070103svn24249.fc9.i386 requires /bin/sh xarchiver-0.4.9-0.6.20070103svn24249.fc9.i386 requires /bin/sh xarchon-0.50-7.fc9.i386 requires /bin/sh xastir-1.9.2-5.fc10.i386 requires /usr/bin/env xastir-1.9.2-5.fc10.i386 requires /bin/bash xastir-1.9.2-5.fc10.i386 requires /bin/sh xastir-1.9.2-5.fc10.i386 requires /usr/bin/perl xawtv-3.95-8.fc9.i386 requires /bin/bash xbae-4.60.4-9.fc9.i386 requires /sbin/ldconfig xbase-2.0.0-11.fc9.i386 requires /sbin/ldconfig xbase-devel-2.0.0-11.fc9.i386 requires /bin/sh xbindkeys-1.8.2-2.fc9.i386 requires /bin/sh xblast-2.10.4-5.fc9.i386 requires /usr/share/fonts/bitstream-vera/Vera.ttf xblast-common-2.10.4-5.fc9.i386 requires /bin/sh xblast-common-2.10.4-5.fc9.i386 requires /bin/bash xboard-4.2.7-17.fc9.i386 requires /bin/sh xboard-4.2.7-17.fc9.i386 requires /usr/bin/perl xboard-4.2.7-17.fc9.i386 requires /bin/sh xbsql-0.11-11.fc9.i386 requires /sbin/ldconfig xca-0.6.4-4.fc9.i386 requires /bin/sh xca-0.6.4-4.fc9.i386 requires /bin/sh 1:xchat-2.8.4-15.fc9.i386 requires /bin/sh xchat-gnome-0.18-12.fc9.i386 requires /bin/sh xchm-1.14-1.fc9.i386 requires /bin/sh xcircuit-3.4.27-3.fc9.i386 requires /bin/sh xcircuit-3.4.27-3.fc9.i386 requires /bin/sh xclip-0.10-3.fc9.i386 requires /bin/sh xdelta-1.1.4-3.fc9.i386 requires /sbin/ldconfig xdelta-devel-1.1.4-3.fc9.i386 requires /bin/bash xdg-user-dirs-0.10-1.fc9.i386 requires /bin/sh xdg-user-dirs-0.10-1.fc9.i386 requires /etc/X11/xinit/xinitrc.d xdg-utils-1.0.2-4.fc9.noarch requires /bin/bash xdg-utils-1.0.2-4.fc9.noarch requires /bin/sh xdoclet-1.2.3-9jpp.1.fc9.i386 requires /bin/sh xdvik-22.84.13-20.fc10.i386 requires /bin/sh xdvik-22.84.13-20.fc10.i386 requires /bin/sh xemacs-21.5.28-6.fc9.i386 requires /bin/sh xemacs-21.5.28-6.fc9.i386 requires /bin/sh xemacs-common-21.5.28-6.fc9.i386 requires /bin/sh xemacs-common-21.5.28-6.fc9.i386 requires /usr/sbin/alternatives xemacs-common-21.5.28-6.fc9.i386 requires /bin/sh xemacs-ess-5.3.7-1.fc10.noarch requires /bin/sh xemacs-info-21.5.28-6.fc9.i386 requires /bin/sh xemacs-info-21.5.28-6.fc9.i386 requires /sbin/install-info xemacs-nox-21.5.28-6.fc9.i386 requires /bin/sh xemacs-packages-extra-20070427-1.fc8.noarch requires /usr/bin/perl xemacs-packages-extra-20070427-1.fc8.noarch requires /usr/bin/env xemacs-packages-extra-20070427-1.fc8.noarch requires /bin/sh xen-3.2.0-10.fc9.i386 requires /bin/sh xen-3.2.0-10.fc9.i386 requires /usr/bin/env xen-3.2.0-10.fc9.i386 requires /bin/bash xen-libs-3.2.0-10.fc9.i386 requires /sbin/ldconfig xen-runtime-3.2.0-10.fc9.i386 requires /bin/sh xen-runtime-3.2.0-10.fc9.i386 requires /usr/bin/env xen-runtime-3.2.0-10.fc9.i386 requires /usr/bin/python xen-runtime-3.2.0-10.fc9.i386 requires /bin/bash xen-runtime-3.2.0-10.fc9.i386 requires /bin/sh xenner-0.34-1.fc10.i386 requires /bin/sh xenner-0.34-1.fc10.i386 requires /bin/sh xerces-c-2.8.0-1.fc9.i386 requires /sbin/ldconfig xerces-c27-2.7.0-4.fc9.i386 requires /sbin/ldconfig xerces-j2-2.7.1-10jpp.1.fc9.i386 requires /bin/sh xerces-j2-2.7.1-10jpp.1.fc9.i386 requires /usr/sbin/update-alternatives xerces-j2-demo-2.7.1-10jpp.1.fc9.i386 requires /bin/sh xeuphoric-0.18.2-10.fc9.i386 requires /bin/sh xfce-mcs-plugins-4.4.2-4.fc9.i386 requires /bin/sh xfce-utils-4.4.2-4.fc9.i386 requires /usr/bin/id xfce-utils-4.4.2-4.fc9.i386 requires /bin/sh xfce4-appfinder-4.4.2-2.fc9.i386 requires /bin/sh xfce4-battery-plugin-0.5.0-4.fc9.i386 requires /bin/sh xfce4-dev-tools-4.4.0-1.fc7.noarch requires /bin/sh xfce4-dict-plugin-0.3.0-1.fc9.i386 requires /bin/sh xfce4-eyes-plugin-4.4.0-4.fc9.i386 requires /bin/sh xfce4-fsguard-plugin-0.4.1-2.fc9.i386 requires /bin/sh xfce4-gsynaptics-mcs-plugin-1.0.0-1.fc9.i386 requires /bin/sh xfce4-mailwatch-plugin-1.0.1-8.fc9.i386 requires /bin/sh xfce4-mixer-4.4.2-2.fc9.i386 requires /bin/sh xfce4-mount-plugin-0.5.1-4.fc9.i386 requires /bin/sh xfce4-notes-plugin-1.6.1-2.fc9.i386 requires /bin/sh xfce4-panel-4.4.2-4.fc9.i386 requires /bin/sh xfce4-sensors-plugin-0.10.99.2-4.fc9.i386 requires /bin/sh xfce4-session-4.4.2-3.fc10.i386 requires /bin/sh xfce4-session-engines-4.4.2-3.fc10.i386 requires /bin/sh xfce4-time-out-plugin-0.1.1-1.fc9.i386 requires /bin/sh xfce4-weather-plugin-0.6.2-3.fc9.i386 requires /bin/sh xfdesktop-4.4.2-3.fc9.i386 requires /bin/sh xfig-common-3.2.5-10.fc9.i386 requires /bin/sh xfig-common-3.2.5-10.fc9.i386 requires /bin/bash xforms-1.0.90-11.fc9.i386 requires /sbin/ldconfig xfprint-4.4.2-2.fc9.i386 requires /bin/sh xfsprogs-2.9.8-1.fc10.i386 requires /sbin/ldconfig xfsprogs-2.9.8-1.fc10.i386 requires /bin/sh xfwm4-4.4.2-3.fc10.i386 requires /bin/sh xgalaxy-2.0.34-8.fc9.i386 requires /bin/sh xgrav-1.2.0-6.fc9.i386 requires /bin/sh xgridfit-1.5-2.fc9.noarch requires /usr/bin/xsltproc xguest-1.0.6-7.fc9.noarch requires /bin/sh xguest-1.0.6-7.fc9.noarch requires /bin/bash xhotkeys-0.9.8.3-5.fc9.noarch requires /bin/sh xhotkeys-0.9.8.3-5.fc9.noarch requires /bin/bash xhotkeys-0.9.8.3-5.fc9.noarch requires /usr/bin/python xhtml1-dtds-1.0-20020801.1.noarch requires /bin/sh xhtml1-dtds-1.0-20020801.1.noarch requires /usr/bin/xmlcatalog xhtml2ps-1.0-0.1.b5.fc10.noarch requires /usr/bin/wish xine-lib-1.1.12-3.fc10.i386 requires /sbin/ldconfig xine-lib-devel-1.1.12-3.fc10.i386 requires /bin/sh 2:xinetd-2.3.14-18.fc9.i386 requires /etc/init.d 2:xinetd-2.3.14-18.fc9.i386 requires /sbin/service 2:xinetd-2.3.14-18.fc9.i386 requires /bin/bash 2:xinetd-2.3.14-18.fc9.i386 requires /sbin/chkconfig 2:xinetd-2.3.14-18.fc9.i386 requires /bin/sh xjavadoc-1.1-5jpp.3.fc9.i386 requires /bin/sh xjavadoc-javadoc-1.1-5jpp.3.fc9.i386 requires /bin/sh xjavadoc-javadoc-1.1-5jpp.3.fc9.i386 requires /bin/rm xjavadoc-javadoc-1.1-5jpp.3.fc9.i386 requires /bin/ln xl2tpd-1.1.12-2.fc9.i386 requires /bin/sh xl2tpd-1.1.12-2.fc9.i386 requires /sbin/chkconfig xl2tpd-1.1.12-2.fc9.i386 requires /bin/sh xl2tpd-1.1.12-2.fc9.i386 requires /sbin/service xlhtml-0.5-8.fc9.i386 requires /usr/bin/perl xlhtml-0.5-8.fc9.i386 requires /bin/csh xlhtml-0.5-8.fc9.i386 requires /bin/bash xlhtml-0.5-8.fc9.i386 requires /bin/sh xml-commons-apis-1.3.04-1jpp.1.fc9.i386 requires /bin/sh xml-commons-apis-javadoc-1.3.04-1jpp.1.fc9.i386 requires /bin/ln xml-commons-apis-javadoc-1.3.04-1jpp.1.fc9.i386 requires /bin/rm xml-commons-apis12-1.2.04-1jpp.4.fc9.i386 requires /bin/sh xml-commons-resolver-1.1-1jpp.12.i386 requires /bin/sh xml-commons-resolver-javadoc-1.1-1jpp.12.i386 requires /bin/sh xml-commons-resolver-javadoc-1.1-1jpp.12.i386 requires /bin/rm xml-commons-resolver-javadoc-1.1-1jpp.12.i386 requires /bin/ln 1:xml-commons-which-1.0-1.b2.0jpp.2.i386 requires /bin/sh xmlcopyeditor-1.1.0.6-4.fc9.i386 requires /bin/sh 1:xmldb-api-0.1-0.2.20011111cvs.1jpp.2.fc9.i386 requires /bin/sh xmlrpc-2.0.1-4jpp.3.fc9.i386 requires /bin/sh xmlrpc-c-1.13.8-2.fc9.i386 requires /sbin/ldconfig xmlrpc-c-devel-1.13.8-2.fc9.i386 requires /bin/sh xmlsec1-1.2.9-10.1.i386 requires /bin/sh xmlsec1-devel-1.2.9-10.1.i386 requires /bin/sh xmlsec1-gnutls-1.2.9-10.1.i386 requires /bin/sh xmlsec1-openssl-1.2.9-10.1.i386 requires /bin/sh xmltex-20020625-11.fc9.noarch requires /bin/sh xmltex-20020625-11.fc9.noarch requires /bin/sh xmlto-0.0.20-3.fc10.i386 requires /bin/bash xmltoman-0.3-2.fc9.noarch requires /usr/bin/perl xmlunit-1.0-6jpp.1.fc9.i386 requires /bin/sh 1:xmms-1.2.10-38.fc9.i386 requires /bin/sh 1:xmms-1.2.10-38.fc9.i386 requires /usr/share/desktop-menu-patches/redhat-audio-player.desktop 1:xmms-1.2.10-38.fc9.i386 requires /bin/sh 1:xmms-devel-1.2.10-38.fc9.i386 requires /bin/sh 1:xmms-libs-1.2.10-38.fc9.i386 requires /sbin/ldconfig xmoto-0.4.2-1.fc9.i386 requires /bin/sh xmoto-edit-0.2.4-13.fc9.i386 requires /bin/sh xorg-x11-apps-7.3-3.fc9.i386 requires /bin/sh xorg-x11-drv-openchrome-0.2.902-3.fc9.i386 requires /bin/sh xorg-x11-filesystem-7.3-1.fc9.noarch requires /bin/bash xorg-x11-filesystem-7.3-1.fc9.noarch requires /bin/sh 1:xorg-x11-font-utils-7.2-4.fc9.i386 requires /bin/sh xorg-x11-fonts-100dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-75dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ISO8859-1-100dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ISO8859-1-75dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ISO8859-14-100dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ISO8859-14-75dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ISO8859-15-100dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ISO8859-15-75dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ISO8859-2-100dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ISO8859-2-75dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ISO8859-9-100dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ISO8859-9-75dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-Type1-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-cyrillic-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ethiopic-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-misc-7.2-6.fc9.noarch requires /bin/sh xorg-x11-server-Xorg-1.4.99.901-29.20080415.fc9.i386 requires /bin/sh xorg-x11-server-source-1.4.99.901-29.20080415.fc9.i386 requires /bin/sh 1:xorg-x11-xauth-1.0.2-4.fc9.i386 requires /bin/sh 1:xorg-x11-xdm-1.1.6-3.fc9.i386 requires /bin/sh 1:xorg-x11-xfs-1.0.5-2.fc9.i386 requires /bin/sh 1:xorg-x11-xfs-1.0.5-2.fc9.i386 requires /usr/bin/uniq 1:xorg-x11-xfs-1.0.5-2.fc9.i386 requires /usr/sbin/useradd 1:xorg-x11-xfs-1.0.5-2.fc9.i386 requires /usr/bin/find 1:xorg-x11-xfs-1.0.5-2.fc9.i386 requires /sbin/service 1:xorg-x11-xfs-1.0.5-2.fc9.i386 requires /sbin/nologin 1:xorg-x11-xfs-1.0.5-2.fc9.i386 requires /bin/bash 1:xorg-x11-xfs-1.0.5-2.fc9.i386 requires /bin/sh 1:xorg-x11-xfs-1.0.5-2.fc9.i386 requires /bin/sort 1:xorg-x11-xfs-1.0.5-2.fc9.i386 requires /sbin/chkconfig xorg-x11-xinit-1.0.7-6.fc9.i386 requires /bin/bash xorg-x11-xinit-1.0.7-6.fc9.i386 requires /bin/sh xorg-x11-xsm-1.0.2-7.fc9.i386 requires /bin/sh xosd-2.2.14-11.fc9.i386 requires /sbin/ldconfig xosd-devel-2.2.14-11.fc9.i386 requires /bin/sh xournal-0.4.2.1-1.fc9.i386 requires /bin/sh xpa-libs-2.1.8-6.fc9.i386 requires /sbin/ldconfig 1:xpdf-3.02-6.fc9.i386 requires /bin/sh xpilot-ng-4.7.2-14.fc9.i386 requires /bin/sh xpilot-ng-selinux-4.7.2-14.fc9.i386 requires /usr/sbin/semodule xpilot-ng-selinux-4.7.2-14.fc9.i386 requires /sbin/fixfiles xpilot-ng-selinux-4.7.2-14.fc9.i386 requires /bin/sh xpilot-ng-selinux-4.7.2-14.fc9.i386 requires /usr/sbin/semanage xpilot-ng-selinux-4.7.2-14.fc9.i386 requires /usr/sbin/setsebool xpilot-ng-selinux-4.7.2-14.fc9.i386 requires /sbin/service xpilot-ng-server-4.7.2-14.fc9.i386 requires /bin/sh xpilot-ng-server-4.7.2-14.fc9.i386 requires /usr/bin/env xpilot-ng-server-4.7.2-14.fc9.i386 requires /sbin/service xpilot-ng-server-4.7.2-14.fc9.i386 requires /bin/sh xpilot-ng-server-4.7.2-14.fc9.i386 requires /sbin/chkconfig xplanet-1.2.0-3.fc9.2.i386 requires /usr/bin/perl xqilla-2.0.0-5.fc9.i386 requires /sbin/ldconfig xqilla10-1.0.2-5.fc9.i386 requires /sbin/ldconfig xsane-gimp-0.995-3.fc9.i386 requires /bin/sh xsc-1.5-3.fc9.i386 requires /bin/sh xscorch-0.2.0-12.fc8.i386 requires /usr/bin/env 1:xscreensaver-base-5.05-3.fc9.i386 requires /bin/sh 1:xscreensaver-base-5.05-3.fc9.i386 requires /etc/pam.d/system-auth 1:xscreensaver-base-5.05-3.fc9.i386 requires /usr/bin/perl 1:xscreensaver-base-5.05-3.fc9.i386 requires /bin/bash 1:xscreensaver-extras-5.05-3.fc9.i386 requires /usr/bin/perl 1:xscreensaver-extras-5.05-3.fc9.i386 requires /bin/sh xsp-1.9.1-2.fc10.i386 requires /bin/sh xstar-xscreensaver-2.2.0-3.fc9.i386 requires /bin/sh xterm-235-1.fc10.i386 requires /bin/sh xtide-2.10-2.fc9.i386 requires /bin/sh xtide-2.10-2.fc9.i386 requires /sbin/service xtide-2.10-2.fc9.i386 requires /bin/sh xtide-2.10-2.fc9.i386 requires /sbin/chkconfig xtide-common-2.10-2.fc9.i386 requires /bin/sh xu4-1.1-0.4.cvs20070510.fc9.i386 requires /bin/sh xu4-1.1-0.4.cvs20070510.fc9.i386 requires /bin/bash xulrunner-1.9-0.63.cvs20080516.fc10.i386 requires /bin/sh xulrunner-1.9-0.63.cvs20080516.fc10.i386 requires /bin/sh xyz-gallery-0.1-1.fc9.noarch requires /usr/bin/perl xzgv-0.9-4.fc9.i386 requires /sbin/install-info xzgv-0.9-4.fc9.i386 requires /bin/sh yadex-1.7.0-10.fc9.i386 requires /bin/sh yafc-1.1.1-10.fc9.i386 requires /bin/sh yafc-1.1.1-10.fc9.i386 requires /sbin/install-info yafray-0.0.9-7.fc9.i386 requires /sbin/ldconfig yakuake-2.9.1-1.fc9.i386 requires /bin/sh yanone-kaffeesatz-fonts-20061120-3.fc9.noarch requires /bin/sh yap-5.1.1-9.fc9.i386 requires /bin/sh yap-5.1.1-9.fc9.i386 requires /sbin/install-info yap-5.1.1-9.fc9.i386 requires /sbin/ldconfig yasm-0.7.0-1.fc10.i386 requires /sbin/ldconfig yelp-2.22.1-1.fc9.i386 requires /bin/sh youtube-dl-2008.01.24-1.fc9.noarch requires /usr/bin/env 3:ypbind-1.20.4-4.fc9.i386 requires /bin/bash 3:ypbind-1.20.4-4.fc9.i386 requires /sbin/chkconfig 3:ypbind-1.20.4-4.fc9.i386 requires /bin/sh ypserv-2.19-9.fc9.i386 requires /bin/sh ypserv-2.19-9.fc9.i386 requires /sbin/service ypserv-2.19-9.fc9.i386 requires /usr/bin/awk ypserv-2.19-9.fc9.i386 requires /bin/bash ypserv-2.19-9.fc9.i386 requires /bin/sh ypserv-2.19-9.fc9.i386 requires /sbin/chkconfig yum-3.2.16-1.fc10.noarch requires /usr/bin/python yum-arch-2.2.2-2.fc7.noarch requires /usr/bin/python yum-cron-0.8.2-1.fc9.noarch requires /bin/sh yum-cron-0.8.2-1.fc9.noarch requires /bin/bash yum-cron-0.8.2-1.fc9.noarch requires /sbin/chkconfig yum-cron-0.8.2-1.fc9.noarch requires /bin/sh yum-cron-0.8.2-1.fc9.noarch requires /sbin/service yum-updateonboot-1.1.13-2.fc9.noarch requires /bin/sh yum-updateonboot-1.1.13-2.fc9.noarch requires /bin/bash 1:yum-updatesd-0.9-1.fc9.noarch requires /bin/sh 1:yum-updatesd-0.9-1.fc9.noarch requires /bin/bash 1:yum-updatesd-0.9-1.fc9.noarch requires /usr/bin/python 1:yum-updatesd-0.9-1.fc9.noarch requires /sbin/chkconfig 1:yum-updatesd-0.9-1.fc9.noarch requires /sbin/service yum-utils-1.1.13-2.fc9.noarch requires /usr/bin/python yumex-2.0.4-1.fc9.noarch requires /bin/bash yumex-2.0.4-1.fc9.noarch requires /usr/bin/env yumex-2.0.4-1.fc9.noarch requires /usr/bin/python zabbix-1.4.5-3.fc10.i386 requires /bin/sh zabbix-1.4.5-3.fc10.i386 requires /usr/sbin/useradd zabbix-1.4.5-3.fc10.i386 requires /sbin/service zabbix-1.4.5-3.fc10.i386 requires /bin/sh zabbix-1.4.5-3.fc10.i386 requires /sbin/chkconfig zabbix-agent-1.4.5-3.fc10.i386 requires /bin/sh zabbix-agent-1.4.5-3.fc10.i386 requires /usr/sbin/useradd zabbix-agent-1.4.5-3.fc10.i386 requires /sbin/service zabbix-agent-1.4.5-3.fc10.i386 requires /bin/sh zabbix-agent-1.4.5-3.fc10.i386 requires /sbin/chkconfig zaptel-1.4.10.1-1.fc10.i386 requires /sbin/chkconfig zaptel-1.4.10.1-1.fc10.i386 requires /bin/sh zaptel-1.4.10.1-1.fc10.i386 requires /bin/sh zaptel-1.4.10.1-1.fc10.i386 requires /sbin/service zaptel-lib-1.4.10.1-1.fc10.i386 requires /sbin/ldconfig zasx-1.30-6.fc9.i386 requires /bin/sh zenity-2.23.1-1.fc10.i386 requires /bin/sh zeroinstall-injector-0.32-1.fc9.noarch requires /bin/sh zeroinstall-injector-0.32-1.fc9.noarch requires /usr/bin/env zeroinstall-injector-0.32-1.fc9.noarch requires /usr/bin/python zile-2.2.19-3.fc9.i386 requires /bin/sh zlib-1.2.3-18.fc9.i386 requires /sbin/ldconfig zoneminder-1.22.3-14.fc10.i386 requires /bin/sh zoneminder-1.22.3-14.fc10.i386 requires /sbin/service zoneminder-1.22.3-14.fc10.i386 requires /usr/bin/perl zoneminder-1.22.3-14.fc10.i386 requires /bin/sh zoneminder-1.22.3-14.fc10.i386 requires /sbin/chkconfig zsh-4.3.4-7.fc9.i386 requires /bin/sh zsh-4.3.4-7.fc9.i386 requires /sbin/install-info zsh-4.3.4-7.fc9.i386 requires /bin/sh zsh-4.3.4-7.fc9.i386 requires /bin/zsh zvbi-0.2.30-1.fc9.i386 requires /bin/sh zvbi-0.2.30-1.fc9.i386 requires /sbin/service zvbi-0.2.30-1.fc9.i386 requires /sbin/chkconfig zvbi-0.2.30-1.fc9.i386 requires /bin/sh zvbi-fonts-0.2.30-1.fc9.i386 requires /bin/sh zynaddsubfx-2.2.1-18.fc9.i386 requires /bin/sh zziplib-0.13.49-5.fc9.i386 requires /sbin/ldconfig Broken deps for x86_64 ---------------------------------------------------------- 8Kingdoms-1.1.0-6.fc9.x86_64 requires /bin/sh AcetoneISO-6.7-5.fc9.x86_64 requires /bin/bash AcetoneISO2-2.0.2-3.fc10.x86_64 requires /bin/bash AllegroOGG-1.0.3-4.fc9.i386 requires /sbin/ldconfig AllegroOGG-1.0.3-4.fc9.x86_64 requires /sbin/ldconfig BackupPC-3.1.0-2.fc9.noarch requires /bin/sh BackupPC-3.1.0-2.fc9.noarch requires /usr/sbin/useradd BackupPC-3.1.0-2.fc9.noarch requires /usr/bin/perl BackupPC-3.1.0-2.fc9.noarch requires /bin/sh BackupPC-3.1.0-2.fc9.noarch requires /usr/sbin/usermod BlockOutII-2.3-5.fc9.x86_64 requires /bin/sh CCfits-2.0-1.fc9.i386 requires /sbin/ldconfig CCfits-2.0-1.fc9.x86_64 requires /sbin/ldconfig CGAL-3.3.1-11.fc9.i386 requires /sbin/ldconfig CGAL-3.3.1-11.fc9.x86_64 requires /sbin/ldconfig CGAL-devel-3.3.1-11.fc9.i386 requires /etc/profile.d CGAL-devel-3.3.1-11.fc9.i386 requires /bin/sh CGAL-devel-3.3.1-11.fc9.x86_64 requires /etc/profile.d CGAL-devel-3.3.1-11.fc9.x86_64 requires /bin/sh CTL-1.4.1-6.fc9.i386 requires /sbin/ldconfig CTL-1.4.1-6.fc9.x86_64 requires /sbin/ldconfig Canna-3.7p3-23.fc9.x86_64 requires /bin/sh Canna-3.7p3-23.fc9.x86_64 requires /sbin/chkconfig Canna-3.7p3-23.fc9.x86_64 requires /bin/bash Canna-3.7p3-23.fc9.x86_64 requires /bin/chown Canna-3.7p3-23.fc9.x86_64 requires /bin/grep Canna-3.7p3-23.fc9.x86_64 requires /bin/sh Canna-3.7p3-23.fc9.x86_64 requires /sbin/service Canna-3.7p3-23.fc9.x86_64 requires /etc/services Canna-libs-3.7p3-23.fc9.i386 requires /sbin/ldconfig Canna-libs-3.7p3-23.fc9.x86_64 requires /sbin/ldconfig CastPodder-5.0-8.fc6.noarch requires /bin/bash CastPodder-5.0-8.fc6.noarch requires /usr/bin/env CastPodder-5.0-8.fc6.noarch requires /bin/sh CastPodder-5.0-8.fc6.noarch requires /usr/bin/python ClanLib-0.8.1-1.fc9.i386 requires /sbin/ldconfig ClanLib-0.8.1-1.fc9.x86_64 requires /sbin/ldconfig ClanLib06-0.6.5-12.fc9.i386 requires /sbin/ldconfig ClanLib06-0.6.5-12.fc9.x86_64 requires /sbin/ldconfig ClanLib06-devel-0.6.5-12.fc9.i386 requires /bin/sh ClanLib06-devel-0.6.5-12.fc9.x86_64 requires /bin/sh Coin2-2.5.0-4.fc9.i386 requires /sbin/ldconfig Coin2-2.5.0-4.fc9.x86_64 requires /sbin/ldconfig Coin2-devel-2.5.0-4.fc9.i386 requires /bin/sh Coin2-devel-2.5.0-4.fc9.x86_64 requires /bin/sh ConsoleKit-0.2.10-3.fc9.x86_64 requires /bin/sh ConsoleKit-0.2.10-3.fc9.x86_64 requires /bin/sh CriticalMass-1.0.2-5.fc9.x86_64 requires /bin/sh Cython-0.9.6.13.1-3.fc10.noarch requires /usr/bin/python DevIL-1.6.8-0.15.rc2.fc9.i386 requires /sbin/ldconfig DevIL-1.6.8-0.15.rc2.fc9.x86_64 requires /sbin/ldconfig DevIL-ILUT-1.6.8-0.15.rc2.fc9.i386 requires /sbin/ldconfig DevIL-ILUT-1.6.8-0.15.rc2.fc9.x86_64 requires /sbin/ldconfig Django-0.96.1-2.fc9.noarch requires /usr/bin/env Django-0.96.1-2.fc9.noarch requires /usr/bin/python Django-docs-0.96.1-2.fc9.noarch requires /usr/bin/env ElectricFence-2.2.2-25.fc9.i386 requires /sbin/ldconfig ElectricFence-2.2.2-25.fc9.i386 requires /bin/bash ElectricFence-2.2.2-25.fc9.x86_64 requires /sbin/ldconfig ElectricFence-2.2.2-25.fc9.x86_64 requires /bin/bash FlightGear-1.0.0-3.fc10.x86_64 requires /bin/sh GConf2-2.22.0-7.fc10.i386 requires /sbin/ldconfig GConf2-2.22.0-7.fc10.i386 requires /bin/sh GConf2-2.22.0-7.fc10.i386 requires /usr/bin/killall GConf2-2.22.0-7.fc10.x86_64 requires /bin/sh GConf2-2.22.0-7.fc10.x86_64 requires /sbin/ldconfig GConf2-2.22.0-7.fc10.x86_64 requires /usr/bin/killall GREYCstoration-gui-2.8-1.fc9.x86_64 requires /bin/sh GREYCstoration-gui-2.8-1.fc9.x86_64 requires /bin/sh GeoIP-1.4.4-2.fc9.i386 requires /sbin/ldconfig GeoIP-1.4.4-2.fc9.x86_64 requires /sbin/ldconfig Glide3-20050815-7.fc9.i386 requires /bin/sh Glide3-20050815-7.fc9.i386 requires /sbin/ldconfig Glide3-20050815-7.fc9.x86_64 requires /sbin/ldconfig Glide3-libGL-6.2.1-8.fc9.x86_64 requires /bin/bash GraphicsMagick-1.1.10-3.fc9.i386 requires /sbin/ldconfig GraphicsMagick-1.1.10-3.fc9.x86_64 requires /sbin/ldconfig GraphicsMagick-c++-1.1.10-3.fc9.i386 requires /sbin/ldconfig GraphicsMagick-c++-1.1.10-3.fc9.x86_64 requires /sbin/ldconfig GraphicsMagick-c++-devel-1.1.10-3.fc9.i386 requires /bin/sh GraphicsMagick-c++-devel-1.1.10-3.fc9.x86_64 requires /bin/sh GraphicsMagick-devel-1.1.10-3.fc9.i386 requires /bin/sh GraphicsMagick-devel-1.1.10-3.fc9.x86_64 requires /bin/sh GtkAda-2.10.0-4.fc9.i386 requires /sbin/ldconfig GtkAda-2.10.0-4.fc9.x86_64 requires /sbin/ldconfig GtkAda-devel-2.10.0-4.fc9.i386 requires /bin/sh GtkAda-devel-2.10.0-4.fc9.x86_64 requires /bin/sh Hermes-1.3.3-14.fc9.i386 requires /sbin/ldconfig Hermes-1.3.3-14.fc9.x86_64 requires /sbin/ldconfig HippoDraw-1.21.1-4.fc9.i386 requires /bin/sh HippoDraw-1.21.1-4.fc9.x86_64 requires /bin/sh ImageMagick-6.4.0.10-1.fc10.i386 requires /sbin/ldconfig ImageMagick-6.4.0.10-1.fc10.x86_64 requires /sbin/ldconfig ImageMagick-c++-6.4.0.10-1.fc10.i386 requires /sbin/ldconfig ImageMagick-c++-6.4.0.10-1.fc10.x86_64 requires /sbin/ldconfig ImageMagick-c++-devel-6.4.0.10-1.fc10.i386 requires /bin/sh ImageMagick-c++-devel-6.4.0.10-1.fc10.x86_64 requires /bin/sh ImageMagick-devel-6.4.0.10-1.fc10.i386 requires /bin/sh ImageMagick-devel-6.4.0.10-1.fc10.x86_64 requires /bin/sh Inventor-2.1.5-31.fc9.i386 requires /usr/share/fonts/liberation/LiberationSerif-BoldItalic.ttf Inventor-2.1.5-31.fc9.i386 requires /usr/share/fonts/liberation/LiberationSans-Regular.ttf Inventor-2.1.5-31.fc9.i386 requires /usr/share/fonts/liberation/LiberationMono-Italic.ttf Inventor-2.1.5-31.fc9.i386 requires /usr/share/fonts/liberation/LiberationMono-BoldItalic.ttf Inventor-2.1.5-31.fc9.i386 requires /usr/share/fonts/liberation/LiberationSerif-Regular.ttf Inventor-2.1.5-31.fc9.i386 requires /usr/share/fonts/liberation/LiberationSans-BoldItalic.ttf Inventor-2.1.5-31.fc9.i386 requires /usr/share/fonts/liberation/LiberationMono-Bold.ttf Inventor-2.1.5-31.fc9.i386 requires /usr/share/fonts/liberation/LiberationSans-Bold.ttf Inventor-2.1.5-31.fc9.i386 requires /sbin/ldconfig Inventor-2.1.5-31.fc9.i386 requires /usr/share/fonts/liberation/LiberationSerif-Bold.ttf Inventor-2.1.5-31.fc9.i386 requires /usr/share/fonts/liberation/LiberationSerif-Italic.ttf Inventor-2.1.5-31.fc9.i386 requires /usr/share/fonts/liberation/LiberationMono-Regular.ttf Inventor-2.1.5-31.fc9.i386 requires /bin/sh Inventor-2.1.5-31.fc9.i386 requires /usr/share/fonts/liberation/LiberationSans-Italic.ttf Inventor-2.1.5-31.fc9.x86_64 requires /usr/share/fonts/liberation/LiberationSerif-BoldItalic.ttf Inventor-2.1.5-31.fc9.x86_64 requires /usr/share/fonts/liberation/LiberationSans-Regular.ttf Inventor-2.1.5-31.fc9.x86_64 requires /usr/share/fonts/liberation/LiberationMono-Italic.ttf Inventor-2.1.5-31.fc9.x86_64 requires /usr/share/fonts/liberation/LiberationMono-BoldItalic.ttf Inventor-2.1.5-31.fc9.x86_64 requires /usr/share/fonts/liberation/LiberationSerif-Regular.ttf Inventor-2.1.5-31.fc9.x86_64 requires /usr/share/fonts/liberation/LiberationSans-BoldItalic.ttf Inventor-2.1.5-31.fc9.x86_64 requires /usr/share/fonts/liberation/LiberationMono-Bold.ttf Inventor-2.1.5-31.fc9.x86_64 requires /usr/share/fonts/liberation/LiberationSans-Bold.ttf Inventor-2.1.5-31.fc9.x86_64 requires /sbin/ldconfig Inventor-2.1.5-31.fc9.x86_64 requires /usr/share/fonts/liberation/LiberationSerif-Bold.ttf Inventor-2.1.5-31.fc9.x86_64 requires /usr/share/fonts/liberation/LiberationSerif-Italic.ttf Inventor-2.1.5-31.fc9.x86_64 requires /usr/share/fonts/liberation/LiberationMono-Regular.ttf Inventor-2.1.5-31.fc9.x86_64 requires /bin/sh Inventor-2.1.5-31.fc9.x86_64 requires /usr/share/fonts/liberation/LiberationSans-Italic.ttf Inventor-demos-2.1.5-31.fc9.x86_64 requires /bin/sh InventorXt-2.1.5-31.fc9.i386 requires /sbin/ldconfig InventorXt-2.1.5-31.fc9.i386 requires /usr/bin/xmessage InventorXt-2.1.5-31.fc9.x86_64 requires /sbin/ldconfig InventorXt-2.1.5-31.fc9.x86_64 requires /usr/bin/xmessage Io-language-20071010-5.fc9.i386 requires /sbin/ldconfig Io-language-20071010-5.fc9.x86_64 requires /sbin/ldconfig JSDoc-1.10.2-4.fc8.noarch requires /usr/bin/perl KoboDeluxe-0.5.1-2.fc9.x86_64 requires /bin/sh KoboDeluxe-0.5.1-2.fc9.x86_64 requires /usr/sbin/groupadd LabPlot-1.5.1.6-4.fc8.i386 requires /bin/sh LabPlot-1.5.1.6-4.fc8.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libMagick.so.10 LabPlot-1.5.1.6-4.fc8.x86_64 requires /bin/sh LabPlot-1.5.1.6-4.fc8.x86_64 requires libMagick++.so.10()(64bit) LabPlot-1.5.1.6-4.fc8.x86_64 requires libMagick.so.10()(64bit) LabPlot-1.5.1.6-4.fc8.x86_64 requires libWand.so.10()(64bit) MAKEDEV-3.23-4.x86_64 requires /bin/sh Macaulay2-1.1-1.fc9.x86_64 requires /bin/sh Macaulay2-1.1-1.fc9.x86_64 requires /bin/sh Maelstrom-3.0.6-15.x86_64 requires /bin/sh MagicPoint-1.11b-6.fc9.x86_64 requires /usr/bin/perl MegaMek-0.30.11-3.fc9.x86_64 requires /bin/sh MegaMek-0.30.11-3.fc9.x86_64 requires /usr/bin/perl MegaMek-0.30.11-3.fc9.x86_64 requires /bin/sh Miro-1.2.3-2.fc10.x86_64 requires /bin/sh Miro-1.2.3-2.fc10.x86_64 requires /usr/bin/python Miro-1.2.3-2.fc10.x86_64 requires /bin/sh 1:NetworkManager-0.7.0-0.9.3.svn3669.fc10.i386 requires /bin/sh 1:NetworkManager-0.7.0-0.9.3.svn3669.fc10.i386 requires /bin/sh 1:NetworkManager-0.7.0-0.9.3.svn3669.fc10.x86_64 requires /bin/sh 1:NetworkManager-0.7.0-0.9.3.svn3669.fc10.x86_64 requires /bin/sh 1:NetworkManager-glib-0.7.0-0.9.3.svn3669.fc10.i386 requires /sbin/ldconfig 1:NetworkManager-glib-0.7.0-0.9.3.svn3669.fc10.x86_64 requires /sbin/ldconfig 1:NetworkManager-gnome-0.7.0-0.9.3.svn3669.fc10.x86_64 requires /bin/sh 1:NetworkManager-openvpn-0.7.0-10.svn3632.fc10.x86_64 requires /bin/sh 1:NetworkManager-openvpn-0.7.0-10.svn3632.fc10.x86_64 requires /usr/bin/update-desktop-database 1:NetworkManager-openvpn-0.7.0-10.svn3632.fc10.x86_64 requires /sbin/ldconfig 1:NetworkManager-vpnc-0.7.0-0.7.7.svn3627.fc10.x86_64 requires /bin/sh 1:NetworkManager-vpnc-0.7.0-0.7.7.svn3627.fc10.x86_64 requires /sbin/ldconfig 1:ORBit-0.5.17-23.fc9.i386 requires /sbin/ldconfig 1:ORBit-0.5.17-23.fc9.i386 requires /sbin/install-info 1:ORBit-0.5.17-23.fc9.x86_64 requires /sbin/ldconfig 1:ORBit-0.5.17-23.fc9.x86_64 requires /sbin/install-info 1:ORBit-devel-0.5.17-23.fc9.i386 requires /bin/sh 1:ORBit-devel-0.5.17-23.fc9.i386 requires /bin/sh 1:ORBit-devel-0.5.17-23.fc9.x86_64 requires /bin/sh 1:ORBit-devel-0.5.17-23.fc9.x86_64 requires /bin/sh ORBit2-2.14.12-3.fc9.i386 requires /sbin/ldconfig ORBit2-2.14.12-3.fc9.x86_64 requires /sbin/ldconfig ORBit2-devel-2.14.12-3.fc9.i386 requires /bin/sh ORBit2-devel-2.14.12-3.fc9.x86_64 requires /bin/sh OpenEXR-libs-1.6.1-4.fc10.i386 requires /sbin/ldconfig OpenEXR-libs-1.6.1-4.fc10.x86_64 requires /sbin/ldconfig OpenEXR_CTL-libs-1.0.1-4.fc9.i386 requires /sbin/ldconfig OpenEXR_CTL-libs-1.0.1-4.fc9.x86_64 requires /sbin/ldconfig OpenEXR_Viewers-1.0.1-2.fc10.x86_64 requires /bin/sh OpenEXR_Viewers-1.0.1-2.fc10.x86_64 requires /usr/sbin/alternatives OpenIPMI-2.0.13-2.fc9.x86_64 requires /bin/sh OpenIPMI-2.0.13-2.fc9.x86_64 requires /bin/sh OpenIPMI-libs-2.0.13-2.fc9.i386 requires /sbin/ldconfig OpenIPMI-libs-2.0.13-2.fc9.x86_64 requires /sbin/ldconfig OpenSceneGraph-libs-2.4.0-2.fc10.i386 requires /sbin/ldconfig OpenSceneGraph-libs-2.4.0-2.fc10.x86_64 requires /sbin/ldconfig OpenThreads-2.4.0-2.fc10.i386 requires /sbin/ldconfig OpenThreads-2.4.0-2.fc10.x86_64 requires /sbin/ldconfig PackageKit-0.2.1-2.20080508.fc10.x86_64 requires /usr/bin/python PackageKit-0.2.1-2.20080508.fc10.x86_64 requires /bin/bash PackageKit-0.2.1-2.20080508.fc10.x86_64 requires /bin/sh PackageKit-libs-0.2.1-2.20080508.fc10.i386 requires /sbin/ldconfig PackageKit-libs-0.2.1-2.20080508.fc10.x86_64 requires /sbin/ldconfig Perlbal-1.70-1.fc9.noarch requires /bin/sh Perlbal-1.70-1.fc9.noarch requires /sbin/service Perlbal-1.70-1.fc9.noarch requires /bin/bash Perlbal-1.70-1.fc9.noarch requires /usr/bin/perl Perlbal-1.70-1.fc9.noarch requires /sbin/chkconfig Pixie-2.2.3-3.fc9.i386 requires /sbin/ldconfig Pixie-2.2.3-3.fc9.x86_64 requires /sbin/ldconfig PolicyKit-0.8-2.fc9.i386 requires /usr/sbin/useradd PolicyKit-0.8-2.fc9.i386 requires /sbin/ldconfig PolicyKit-0.8-2.fc9.i386 requires /bin/sh PolicyKit-0.8-2.fc9.x86_64 requires /bin/sh PolicyKit-0.8-2.fc9.x86_64 requires /usr/sbin/useradd PolicyKit-0.8-2.fc9.x86_64 requires /sbin/ldconfig Pound-2.4-1.fc9.x86_64 requires /bin/sh Pound-2.4-1.fc9.x86_64 requires /usr/sbin/groupadd Pound-2.4-1.fc9.x86_64 requires /usr/sbin/useradd Pound-2.4-1.fc9.x86_64 requires /sbin/service Pound-2.4-1.fc9.x86_64 requires /bin/bash Pound-2.4-1.fc9.x86_64 requires /sbin/chkconfig PyKDE-3.16.1-1.fc9.x86_64 requires /usr/bin/env PyKDE-devel-3.16.1-1.fc9.i386 requires /usr/bin/env PyKDE-devel-3.16.1-1.fc9.x86_64 requires /usr/bin/env PyQt-examples-3.17.4-4.fc9.x86_64 requires /usr/bin/env PyQt4-4.4-1.fc10.x86_64 requires /usr/bin/env PyQt4-devel-4.4-1.fc10.i386 requires /bin/sh PyQt4-devel-4.4-1.fc10.x86_64 requires /bin/sh PySolFC-1.1-6.fc9.noarch requires /usr/bin/env PySolFC-1.1-6.fc9.noarch requires /bin/sh PySolFC-1.1-6.fc9.noarch requires /usr/bin/python PyX-0.10-4.fc9.x86_64 requires /usr/bin/env PyXML-0.8.4-9.x86_64 requires /usr/bin/python Pyrex-0.9.6.4-2.fc10.noarch requires /usr/bin/python PythonCAD-0.1.36-3.fc9.noarch requires /bin/sh PythonCAD-0.1.36-3.fc9.noarch requires /usr/bin/env PythonCAD-0.1.36-3.fc9.noarch requires /usr/bin/python QuantLib-0.9.0-5.fc9.i386 requires /sbin/ldconfig QuantLib-0.9.0-5.fc9.x86_64 requires /sbin/ldconfig QuantLib-devel-0.9.0-5.fc9.i386 requires /bin/sh QuantLib-devel-0.9.0-5.fc9.x86_64 requires /bin/sh R-2.7.0-2.fc10.i386 requires /bin/sh R-2.7.0-2.fc10.i386 requires /bin/bash R-2.7.0-2.fc10.i386 requires /bin/sh R-2.7.0-2.fc10.i386 requires /usr/bin/perl R-2.7.0-2.fc10.x86_64 requires /bin/sh R-2.7.0-2.fc10.x86_64 requires /bin/bash R-2.7.0-2.fc10.x86_64 requires /bin/sh R-2.7.0-2.fc10.x86_64 requires /usr/bin/perl R-BSgenome.Celegans.UCSC.ce2-1.2.0-5.noarch requires /bin/sh R-BSgenome.Dmelanogaster.FlyBase.r51-1.3.1-3.noarch requires /bin/sh R-Biobase-1.16.1-5.fc9.x86_64 requires /bin/sh R-Biobase-1.16.1-5.fc9.x86_64 requires /bin/bash R-BufferedMatrix-1.4.0-1.fc10.x86_64 requires /bin/sh R-BufferedMatrixMethods-1.3.0-3.fc9.x86_64 requires /bin/sh R-DynDoc-1.18.0-1.fc10.noarch requires /bin/sh R-Matrix-0.999375-4.fc9.x86_64 requires /bin/sh R-RScaLAPACK-0.5.1-11.fc9.2.x86_64 requires /bin/sh R-RScaLAPACK-0.5.1-11.fc9.2.x86_64 requires /bin/sh R-abind-1.1-2.fc9.noarch requires /bin/sh R-acepack-1.3-4.fc9.x86_64 requires /bin/sh R-affyio-1.8.0-1.fc10.x86_64 requires /bin/sh R-car-1.2-3.fc10.noarch requires /bin/sh R-hdf5-1.6.6-6.fc10.x86_64 requires /bin/sh R-hgu95av2probe-2.0.0-1.fc9.noarch requires /bin/sh R-mAr-1.1-13.fc9.x86_64 requires /bin/sh R-maanova-1.9.0-2.fc9.x86_64 requires /bin/sh R-multcomp-1.0-1.fc9.noarch requires /bin/sh R-multtest-1.18.0-4.fc9.x86_64 requires /bin/sh R-mvtnorm-0.8-4.fc9.x86_64 requires /bin/sh R-pls-2.1-2.fc9.noarch requires /bin/sh R-qvalue-1.12.0-2.fc9.noarch requires /bin/sh R-rlecuyer-0.1-6.fc9.x86_64 requires /bin/sh R-systemfit-0.8-7.fc9.noarch requires /bin/sh R-tkWidgets-1.16.0-2.fc9.noarch requires /bin/sh R-waveslim-1.6.1-2.fc9.x86_64 requires /bin/sh R-wavethresh-2.2-9.fc9.x86_64 requires /bin/sh R-widgetTools-1.15.0-2.fc9.noarch requires /bin/sh Ri-li-2.0.1-3.fc9.x86_64 requires /bin/sh SAASound-3.2-5.fc10.i386 requires /sbin/ldconfig SAASound-3.2-5.fc10.x86_64 requires /sbin/ldconfig SDL-1.2.13-3.fc9.i386 requires /sbin/ldconfig SDL-1.2.13-3.fc9.x86_64 requires /sbin/ldconfig SDL-devel-1.2.13-3.fc9.i386 requires /bin/sh SDL-devel-1.2.13-3.fc9.x86_64 requires /bin/sh SDL_Pango-0.1.2-8.i386 requires /sbin/ldconfig SDL_Pango-0.1.2-8.x86_64 requires /sbin/ldconfig SDL_gfx-2.0.16-5.fc9.i386 requires /sbin/ldconfig SDL_gfx-2.0.16-5.fc9.x86_64 requires /sbin/ldconfig SDL_image-1.2.6-6.fc9.i386 requires /sbin/ldconfig SDL_image-1.2.6-6.fc9.x86_64 requires /sbin/ldconfig SDL_mixer-1.2.8-8.fc9.i386 requires /sbin/ldconfig SDL_mixer-1.2.8-8.fc9.x86_64 requires /sbin/ldconfig SDL_net-1.2.7-4.fc9.i386 requires /sbin/ldconfig SDL_net-1.2.7-4.fc9.x86_64 requires /sbin/ldconfig SDL_sound-1.0.3-1.fc10.i386 requires /sbin/ldconfig SDL_sound-1.0.3-1.fc10.x86_64 requires /sbin/ldconfig SDL_ttf-2.0.9-4.fc9.i386 requires /sbin/ldconfig SDL_ttf-2.0.9-4.fc9.x86_64 requires /sbin/ldconfig SILLY-0.1.0-5.fc9.i386 requires /sbin/ldconfig SILLY-0.1.0-5.fc9.x86_64 requires /sbin/ldconfig SIMVoleon-2.0.1-7.fc9.i386 requires /bin/sh SIMVoleon-2.0.1-7.fc9.i386 requires /sbin/ldconfig SIMVoleon-2.0.1-7.fc9.x86_64 requires /bin/sh SIMVoleon-2.0.1-7.fc9.x86_64 requires /sbin/ldconfig SIMVoleon-devel-2.0.1-7.fc9.i386 requires /bin/sh SIMVoleon-devel-2.0.1-7.fc9.x86_64 requires /bin/sh ScientificPython-2.6-12.fc9.x86_64 requires /usr/bin/python SimGear-1.0.0-4.fc10.i386 requires /sbin/ldconfig SimGear-1.0.0-4.fc10.x86_64 requires /sbin/ldconfig SoQt-1.4.1-9.fc9.i386 requires /bin/sh SoQt-1.4.1-9.fc9.i386 requires /sbin/ldconfig SoQt-1.4.1-9.fc9.x86_64 requires /bin/sh SoQt-1.4.1-9.fc9.x86_64 requires /sbin/ldconfig SoQt-devel-1.4.1-9.fc9.i386 requires /usr/share/aclocal SoQt-devel-1.4.1-9.fc9.i386 requires /bin/sh SoQt-devel-1.4.1-9.fc9.x86_64 requires /usr/share/aclocal SoQt-devel-1.4.1-9.fc9.x86_64 requires /bin/sh Sprog-0.14-13.fc9.noarch requires /usr/bin/perl TeXmacs-1.0.6.14-1.fc9.x86_64 requires /bin/sh TeXmacs-1.0.6.14-1.fc9.x86_64 requires /usr/bin/env TeXmacs-1.0.6.14-1.fc9.x86_64 requires /bin/bash TeXmacs-1.0.6.14-1.fc9.x86_64 requires /bin/sh Terminal-0.2.8-3.fc9.x86_64 requires /bin/sh Terminal-0.2.8-3.fc9.x86_64 requires /bin/sh Thunar-0.9.0-4.fc9.i386 requires /bin/sh Thunar-0.9.0-4.fc9.i386 requires /bin/sh Thunar-0.9.0-4.fc9.x86_64 requires /bin/sh Thunar-0.9.0-4.fc9.x86_64 requires /bin/sh TnL-data-071111-1.fc9.noarch requires /bin/sh TurboGears-1.0.4.4-2.fc9.noarch requires /usr/bin/python VLGothic-fonts-20080429-1.fc10.noarch requires /bin/sh VLGothic-fonts-proportional-20080429-1.fc10.noarch requires /bin/sh WINGs-devel-0.92.0-17.fc9.i386 requires /bin/sh WINGs-devel-0.92.0-17.fc9.x86_64 requires /bin/sh WINGs-libs-0.92.0-17.fc9.i386 requires /sbin/ldconfig WINGs-libs-0.92.0-17.fc9.x86_64 requires /sbin/ldconfig WebKit-gtk-1.0.0-0.10.svn32531.fc10.i386 requires /sbin/ldconfig WebKit-gtk-1.0.0-0.10.svn32531.fc10.x86_64 requires /sbin/ldconfig WindowMaker-0.92.0-17.fc9.i386 requires /sbin/ldconfig WindowMaker-0.92.0-17.fc9.i386 requires /usr/bin/perl WindowMaker-0.92.0-17.fc9.i386 requires /bin/sh WindowMaker-0.92.0-17.fc9.x86_64 requires /sbin/ldconfig WindowMaker-0.92.0-17.fc9.x86_64 requires /usr/bin/perl WindowMaker-0.92.0-17.fc9.x86_64 requires /bin/sh WindowMaker-devel-0.92.0-17.fc9.i386 requires /bin/sh WindowMaker-devel-0.92.0-17.fc9.x86_64 requires /bin/sh WritRecogn-0.1.9-0.fc10.x86_64 requires /bin/sh Xaw3d-1.5E-11.1.i386 requires /sbin/ldconfig Xaw3d-1.5E-11.1.x86_64 requires /sbin/ldconfig Zim-0.23-2.fc9.noarch requires /usr/bin/perl a2ps-4.14-3.fc10.i386 requires /sbin/install-info a2ps-4.14-3.fc10.i386 requires /sbin/ldconfig a2ps-4.14-3.fc10.i386 requires /usr/bin/perl a2ps-4.14-3.fc10.i386 requires /bin/sh a2ps-4.14-3.fc10.i386 requires /bin/sh a2ps-4.14-3.fc10.x86_64 requires /sbin/install-info a2ps-4.14-3.fc10.x86_64 requires /sbin/ldconfig a2ps-4.14-3.fc10.x86_64 requires /usr/bin/perl a2ps-4.14-3.fc10.x86_64 requires /bin/sh a2ps-4.14-3.fc10.x86_64 requires /bin/sh aalib-devel-1.4.0-0.15.rc5.fc9.i386 requires /bin/sh aalib-devel-1.4.0-0.15.rc5.fc9.i386 requires /sbin/install-info aalib-devel-1.4.0-0.15.rc5.fc9.i386 requires /bin/sh aalib-devel-1.4.0-0.15.rc5.fc9.x86_64 requires /bin/sh aalib-devel-1.4.0-0.15.rc5.fc9.x86_64 requires /sbin/install-info aalib-devel-1.4.0-0.15.rc5.fc9.x86_64 requires /bin/sh aalib-libs-1.4.0-0.15.rc5.fc9.i386 requires /sbin/ldconfig aalib-libs-1.4.0-0.15.rc5.fc9.x86_64 requires /sbin/ldconfig abcde-2.3.99.6-6.noarch requires /bin/bash abcde-2.3.99.6-6.noarch requires /bin/sh abcde-2.3.99.6-6.noarch requires /usr/bin/python 1:abiword-2.6.3-1.fc9.x86_64 requires /bin/sh 1:abiword-2.6.3-1.fc9.x86_64 requires /bin/sh 1:abiword-2.6.3-1.fc9.x86_64 requires /usr/bin/perl abuse-0.7.1-1.fc9.x86_64 requires /bin/sh abyssinica-fonts-1.0-2.fc8.noarch requires /bin/sh ack-1.78-1.fc9.noarch requires /usr/bin/perl acpid-1.0.6-7.fc9.x86_64 requires /bin/sh acpid-1.0.6-7.fc9.x86_64 requires /bin/bash acpid-1.0.6-7.fc9.x86_64 requires /sbin/chkconfig acpid-1.0.6-7.fc9.x86_64 requires /bin/sh acpid-1.0.6-7.fc9.x86_64 requires /sbin/service adanaxisgpl-1.2.5-2.fc9.x86_64 requires /bin/sh adaptx-0.9.13-5jpp.3.fc9.x86_64 requires /bin/sh adaptx-javadoc-0.9.13-5jpp.3.fc9.x86_64 requires /bin/sh adaptx-javadoc-0.9.13-5jpp.3.fc9.x86_64 requires /bin/rm adaptx-javadoc-0.9.13-5jpp.3.fc9.x86_64 requires /bin/ln adime-2.2.1-7.fc9.i386 requires /sbin/ldconfig adime-2.2.1-7.fc9.x86_64 requires /sbin/ldconfig adime-devel-2.2.1-7.fc9.i386 requires /bin/sh adime-devel-2.2.1-7.fc9.i386 requires /sbin/install-info adime-devel-2.2.1-7.fc9.x86_64 requires /bin/sh adime-devel-2.2.1-7.fc9.x86_64 requires /sbin/install-info adminutil-1.1.6-1.fc9.i386 requires /sbin/ldconfig adminutil-1.1.6-1.fc9.x86_64 requires /sbin/ldconfig adns-1.4-3.fc9.i386 requires /sbin/ldconfig adns-1.4-3.fc9.x86_64 requires /sbin/ldconfig adplug-2.1-6.fc9.i386 requires /sbin/ldconfig adplug-2.1-6.fc9.x86_64 requires /sbin/ldconfig adplug-devel-2.1-6.fc9.i386 requires /bin/sh adplug-devel-2.1-6.fc9.i386 requires /sbin/install-info adplug-devel-2.1-6.fc9.x86_64 requires /bin/sh adplug-devel-2.1-6.fc9.x86_64 requires /sbin/install-info afflib-3.1.6-1.fc9.i386 requires /sbin/ldconfig afflib-3.1.6-1.fc9.x86_64 requires /sbin/ldconfig agave-0.4.2-7.fc9.x86_64 requires /bin/sh agg-2.5-6.fc9.i386 requires /sbin/ldconfig agg-2.5-6.fc9.x86_64 requires /sbin/ldconfig agistudio-1.2.3-7.fc9.x86_64 requires /bin/sh aiccu-2007.01.15-3.fc9.x86_64 requires /bin/sh aiccu-2007.01.15-3.fc9.x86_64 requires /bin/sh 1:aiksaurus-1.2.1-15.fc6.i386 requires /sbin/ldconfig 1:aiksaurus-1.2.1-15.fc6.x86_64 requires /sbin/ldconfig 1:aiksaurus-gtk-1.2.1-15.fc6.i386 requires /bin/sh 1:aiksaurus-gtk-1.2.1-15.fc6.x86_64 requires /bin/sh aircrack-ng-0.9.3-1.fc9.x86_64 requires /bin/sh akode-2.0.2-5.fc9.i386 requires /sbin/ldconfig akode-2.0.2-5.fc9.x86_64 requires /sbin/ldconfig akode-devel-2.0.2-5.fc9.i386 requires /bin/sh akode-devel-2.0.2-5.fc9.x86_64 requires /bin/sh akonadi-0.80.0-2.fc10.i386 requires /bin/sh akonadi-0.80.0-2.fc10.i386 requires /sbin/ldconfig akonadi-0.80.0-2.fc10.x86_64 requires /bin/sh akonadi-0.80.0-2.fc10.x86_64 requires /sbin/ldconfig alacarte-0.11.5-1.fc9.noarch requires /bin/sh alacarte-0.11.5-1.fc9.noarch requires /usr/bin/python2.5 alchemist-1.0.37-4.fc9.i386 requires /usr/bin/python alchemist-1.0.37-4.fc9.i386 requires /sbin/ldconfig alchemist-1.0.37-4.fc9.x86_64 requires /usr/bin/python alchemist-1.0.37-4.fc9.x86_64 requires /sbin/ldconfig aldrin-0.11-6.fc8.noarch requires /bin/sh aldrin-0.11-6.fc8.noarch requires /usr/bin/python alex4-1.0-6.fc9.x86_64 requires /bin/sh alexandria-0.6.3-4.fc9.noarch requires /bin/sh alexandria-0.6.3-4.fc9.noarch requires /usr/bin/env alfont-2.0.6-4.fc9.i386 requires /sbin/ldconfig alfont-2.0.6-4.fc9.x86_64 requires /sbin/ldconfig alienarena-6.10-6.fc9.x86_64 requires /bin/bash alienarena-data-20071011-2.fc9.noarch requires /bin/sh alienblaster-1.1.0-4.fc9.x86_64 requires /bin/sh alienblaster-1.1.0-4.fc9.x86_64 requires /bin/bash alleggl-0.4.3-3.fc9.i386 requires /sbin/ldconfig alleggl-0.4.3-3.fc9.x86_64 requires /sbin/ldconfig allegro-4.2.2-10.fc10.i386 requires /bin/sh allegro-4.2.2-10.fc10.i386 requires /sbin/ldconfig allegro-4.2.2-10.fc10.x86_64 requires /sbin/ldconfig allegro-devel-4.2.2-10.fc10.i386 requires /bin/sh allegro-devel-4.2.2-10.fc10.i386 requires /sbin/install-info allegro-devel-4.2.2-10.fc10.i386 requires /bin/sh allegro-devel-4.2.2-10.fc10.x86_64 requires /bin/sh allegro-devel-4.2.2-10.fc10.x86_64 requires /sbin/install-info allegro-devel-4.2.2-10.fc10.x86_64 requires /bin/sh alleyoop-0.9.3-4.fc9.x86_64 requires /bin/sh alliance-5.0-13.20070718snap.fc9.x86_64 requires /bin/sh alliance-5.0-13.20070718snap.fc9.x86_64 requires /bin/sh alltray-0.70-2.fc9.i386 requires /sbin/ldconfig alltray-0.70-2.fc9.x86_64 requires /sbin/ldconfig alphabet-soup-1.1-4.fc9.x86_64 requires /bin/sh alsa-lib-1.0.16-3.fc9.i386 requires /sbin/ldconfig alsa-lib-1.0.16-3.fc9.i386 requires /bin/sh alsa-lib-1.0.16-3.fc9.x86_64 requires /sbin/ldconfig alsa-lib-1.0.16-3.fc9.x86_64 requires /bin/sh alsa-oss-1.0.15-0.1.fc9.x86_64 requires /bin/sh alsa-oss-libs-1.0.15-0.1.fc9.i386 requires /sbin/ldconfig alsa-oss-libs-1.0.15-0.1.fc9.x86_64 requires /sbin/ldconfig alsa-utils-1.0.16-3.fc10.x86_64 requires /bin/bash 5:am-utils-6.1.5-8.fc9.i386 requires /bin/sh 5:am-utils-6.1.5-8.fc9.i386 requires /sbin/install-info 5:am-utils-6.1.5-8.fc9.i386 requires /bin/sh 5:am-utils-6.1.5-8.fc9.i386 requires /bin/grep 5:am-utils-6.1.5-8.fc9.i386 requires /usr/bin/perl 5:am-utils-6.1.5-8.fc9.i386 requires /bin/bash 5:am-utils-6.1.5-8.fc9.i386 requires /sbin/chkconfig 5:am-utils-6.1.5-8.fc9.x86_64 requires /bin/sh 5:am-utils-6.1.5-8.fc9.x86_64 requires /sbin/install-info 5:am-utils-6.1.5-8.fc9.x86_64 requires /bin/sh 5:am-utils-6.1.5-8.fc9.x86_64 requires /bin/grep 5:am-utils-6.1.5-8.fc9.x86_64 requires /usr/bin/perl 5:am-utils-6.1.5-8.fc9.x86_64 requires /bin/bash 5:am-utils-6.1.5-8.fc9.x86_64 requires /sbin/chkconfig amanda-2.5.2p1-10.fc9.i386 requires /sbin/ldconfig amanda-2.5.2p1-10.fc9.i386 requires /bin/sh amanda-2.5.2p1-10.fc9.i386 requires /usr/bin/Mail amanda-2.5.2p1-10.fc9.x86_64 requires /bin/sh amanda-2.5.2p1-10.fc9.x86_64 requires /sbin/ldconfig amanda-2.5.2p1-10.fc9.x86_64 requires /usr/bin/Mail amanda-client-2.5.2p1-10.fc9.x86_64 requires /bin/sh amanda-client-2.5.2p1-10.fc9.x86_64 requires /sbin/service amanda-client-2.5.2p1-10.fc9.x86_64 requires /bin/sh amanda-server-2.5.2p1-10.fc9.x86_64 requires /bin/sh amanda-server-2.5.2p1-10.fc9.x86_64 requires /sbin/service amanda-server-2.5.2p1-10.fc9.x86_64 requires /usr/bin/perl amanda-server-2.5.2p1-10.fc9.x86_64 requires /bin/sh amanith-0.3-9.fc9.i386 requires /sbin/ldconfig amanith-0.3-9.fc9.x86_64 requires /sbin/ldconfig amarok-1.4.8-5.fc9.i386 requires /bin/sh amarok-1.4.8-5.fc9.i386 requires /usr/bin/env amarok-1.4.8-5.fc9.x86_64 requires /bin/sh amarok-1.4.8-5.fc9.x86_64 requires /usr/bin/env amarokFS-0.5-3.fc9.x86_64 requires /bin/sh amarokFS-0.5-3.fc9.x86_64 requires /usr/bin/env amavisd-new-2.5.2-2.fc8.noarch requires /bin/sh amavisd-new-2.5.2-2.fc8.noarch requires /usr/sbin/useradd amavisd-new-2.5.2-2.fc8.noarch requires /sbin/service amavisd-new-2.5.2-2.fc8.noarch requires /usr/sbin/clamd amavisd-new-2.5.2-2.fc8.noarch requires /usr/bin/ar amavisd-new-2.5.2-2.fc8.noarch requires /usr/sbin/tmpwatch amavisd-new-2.5.2-2.fc8.noarch requires /etc/cron.daily amavisd-new-2.5.2-2.fc8.noarch requires /bin/bash amavisd-new-2.5.2-2.fc8.noarch requires /bin/sh amavisd-new-2.5.2-2.fc8.noarch requires /usr/bin/perl amavisd-new-2.5.2-2.fc8.noarch requires /etc/clamd.d amavisd-new-2.5.2-2.fc8.noarch requires /sbin/chkconfig amoebax-0.2.0-3.fc9.x86_64 requires /bin/sh amsn-0.97-3.fc9.x86_64 requires /bin/sh amsn-0.97-3.fc9.x86_64 requires /usr/bin/tclsh amsn-0.97-3.fc9.x86_64 requires /usr/bin/env amsn-0.97-3.fc9.x86_64 requires /usr/bin/wish amsn-0.97-3.fc9.x86_64 requires /bin/sh amtterm-1.0-2.fc9.x86_64 requires /usr/bin/perl anaconda-11.4.1.1-1.x86_64 requires /bin/sh anaconda-11.4.1.1-1.x86_64 requires /usr/bin/python anaconda-11.4.1.1-1.x86_64 requires /bin/sh anaconda-runtime-11.4.1.1-1.x86_64 requires /usr/bin/env anaconda-runtime-11.4.1.1-1.x86_64 requires /usr/bin/python anaconda-runtime-11.4.1.1-1.x86_64 requires /bin/bash anaconda-runtime-11.4.1.1-1.x86_64 requires /bin/sh anacron-2.3-59.fc9.x86_64 requires /bin/sh anacron-2.3-59.fc9.x86_64 requires /sbin/chkconfig anacron-2.3-59.fc9.x86_64 requires /bin/sh anacron-2.3-59.fc9.x86_64 requires /sbin/service and-1.2.2-6.fc9.x86_64 requires /bin/sh and-1.2.2-6.fc9.x86_64 requires /sbin/chkconfig and-1.2.2-6.fc9.x86_64 requires /bin/sh and-1.2.2-6.fc9.x86_64 requires /sbin/service angrydd-1.0.1-3.fc8.noarch requires /bin/sh angrydd-1.0.1-3.fc8.noarch requires /usr/bin/env animorph-0.3-3.fc9.i386 requires /sbin/ldconfig animorph-0.3-3.fc9.x86_64 requires /sbin/ldconfig 1:anjuta-2.2.3-7.fc9.i386 requires /bin/sh 1:anjuta-2.2.3-7.fc9.i386 requires /sbin/ldconfig 1:anjuta-2.2.3-7.fc9.i386 requires /usr/bin/perl 1:anjuta-2.2.3-7.fc9.i386 requires /bin/bash 1:anjuta-2.2.3-7.fc9.x86_64 requires /bin/sh 1:anjuta-2.2.3-7.fc9.x86_64 requires /sbin/ldconfig 1:anjuta-2.2.3-7.fc9.x86_64 requires /usr/bin/perl 1:anjuta-2.2.3-7.fc9.x86_64 requires /bin/bash 1:anjuta-doc-2.2.3-7.fc9.x86_64 requires /bin/sh ant-1.7.0-1jpp.4.fc9.x86_64 requires /bin/sh ant-antlr-1.7.0-1jpp.4.fc9.x86_64 requires /bin/sh ant-apache-bcel-1.7.0-1jpp.4.fc9.x86_64 requires /bin/sh ant-apache-bsf-1.7.0-1jpp.4.fc9.x86_64 requires /bin/sh ant-apache-log4j-1.7.0-1jpp.4.fc9.x86_64 requires /bin/sh ant-apache-oro-1.7.0-1jpp.4.fc9.x86_64 requires /bin/sh ant-apache-regexp-1.7.0-1jpp.4.fc9.x86_64 requires /bin/sh ant-apache-resolver-1.7.0-1jpp.4.fc9.x86_64 requires /bin/sh ant-commons-logging-1.7.0-1jpp.4.fc9.x86_64 requires /bin/sh ant-commons-net-1.7.0-1jpp.4.fc9.x86_64 requires /bin/sh ant-contrib-1.0-0.5.b2.fc9.x86_64 requires /bin/sh ant-javamail-1.7.0-1jpp.4.fc9.x86_64 requires /bin/sh ant-jdepend-1.7.0-1jpp.4.fc9.x86_64 requires /bin/sh ant-jmf-1.7.0-1jpp.4.fc9.x86_64 requires /bin/sh ant-jsch-1.7.0-1jpp.4.fc9.x86_64 requires /bin/sh ant-junit-1.7.0-1jpp.4.fc9.x86_64 requires /bin/sh ant-nodeps-1.7.0-1jpp.4.fc9.x86_64 requires /bin/sh ant-scripts-1.7.0-1jpp.4.fc9.x86_64 requires /usr/bin/python ant-swing-1.7.0-1jpp.4.fc9.x86_64 requires /bin/sh ant-trax-1.7.0-1jpp.4.fc9.x86_64 requires /bin/sh anthy-9100e-2.fc9.i386 requires /sbin/ldconfig anthy-9100e-2.fc9.x86_64 requires /sbin/ldconfig antiword-0.37-7.fc9.x86_64 requires /bin/sh antlr-2.7.7-1jpp.7.fc9.x86_64 requires /usr/sbin/update-alternatives antlr-2.7.7-1jpp.7.fc9.x86_64 requires /bin/sh antlr-2.7.7-1jpp.7.fc9.x86_64 requires /bin/sh antlr-javadoc-2.7.7-1jpp.7.fc9.x86_64 requires /bin/sh antlr-javadoc-2.7.7-1jpp.7.fc9.x86_64 requires /bin/rm antlr-javadoc-2.7.7-1jpp.7.fc9.x86_64 requires /bin/ln ants-1.4-4.fc9.x86_64 requires /bin/sh anyremote-data-4.4-1.fc8.x86_64 requires /usr/bin/env aoetools-23-1.fc9.x86_64 requires /bin/bash aoetools-23-1.fc9.x86_64 requires /bin/sh apcupsd-3.14.3-2.1.fc9.x86_64 requires /bin/sh apcupsd-3.14.3-2.1.fc9.x86_64 requires /sbin/service apcupsd-3.14.3-2.1.fc9.x86_64 requires /bin/sh apcupsd-3.14.3-2.1.fc9.x86_64 requires /sbin/chkconfig apcupsd-3.14.3-2.1.fc9.x86_64 requires /bin/mail apg-2.3.0b-6.fc9.x86_64 requires /bin/sh aplus-fsf-4.22.1-3.fc10.i386 requires /sbin/ldconfig aplus-fsf-4.22.1-3.fc10.x86_64 requires /sbin/ldconfig apollon-1.0.1-13.fc9.x86_64 requires /bin/sh apollon-libs-1.0.1-13.fc9.i386 requires /sbin/ldconfig apollon-libs-1.0.1-13.fc9.x86_64 requires /sbin/ldconfig apr-1.2.12-2.fc9.i386 requires /sbin/ldconfig apr-1.2.12-2.fc9.x86_64 requires /sbin/ldconfig apr-devel-1.2.12-2.fc9.i386 requires /bin/sh apr-devel-1.2.12-2.fc9.x86_64 requires /bin/sh apr-util-1.2.12-5.fc9.i386 requires /sbin/ldconfig apr-util-1.2.12-5.fc9.x86_64 requires /sbin/ldconfig apr-util-devel-1.2.12-5.fc9.i386 requires /bin/sh apr-util-devel-1.2.12-5.fc9.x86_64 requires /bin/sh aprsd-2.2.5-15.3.fc9.x86_64 requires /bin/sh aprsd-2.2.5-15.3.fc9.x86_64 requires /sbin/service aprsd-2.2.5-15.3.fc9.x86_64 requires /bin/bash aprsd-2.2.5-15.3.fc9.x86_64 requires /sbin/chkconfig apt-0.5.15lorg3.94-3.fc9.i386 requires /bin/sh apt-0.5.15lorg3.94-3.fc9.i386 requires /sbin/ldconfig apt-0.5.15lorg3.94-3.fc9.i386 requires /bin/bash apt-0.5.15lorg3.94-3.fc9.i386 requires /bin/sh apt-0.5.15lorg3.94-3.fc9.x86_64 requires /bin/sh apt-0.5.15lorg3.94-3.fc9.x86_64 requires /sbin/ldconfig apt-0.5.15lorg3.94-3.fc9.x86_64 requires /bin/bash apt-0.5.15lorg3.94-3.fc9.x86_64 requires /bin/sh aqbanking-2.3.3-3.fc9.i386 requires /sbin/ldconfig aqbanking-2.3.3-3.fc9.x86_64 requires /sbin/ldconfig aqbanking-devel-2.3.3-3.fc9.i386 requires /bin/sh aqbanking-devel-2.3.3-3.fc9.x86_64 requires /bin/sh aqsis-1.2.0-8.fc9.i386 requires /usr/bin/env aqsis-1.2.0-8.fc9.i386 requires /sbin/ldconfig aqsis-1.2.0-8.fc9.x86_64 requires /sbin/ldconfig aqsis-1.2.0-8.fc9.x86_64 requires /usr/bin/env aqsis-data-1.2.0-8.fc9.x86_64 requires /bin/bash archivemail-0.7.2-1.fc9.noarch requires /usr/bin/env archmage-0.1.9-2.fc9.noarch requires /usr/bin/python ardour-2.4.1-1.fc9.x86_64 requires /bin/sh ardour-2.4.1-1.fc9.x86_64 requires /bin/sh argus-2.0.6.fixes.1-15.fc9.x86_64 requires /sbin/chkconfig argus-2.0.6.fixes.1-15.fc9.x86_64 requires /bin/sh argus-2.0.6.fixes.1-15.fc9.x86_64 requires /bin/sh arj-3.10.22-4.fc9.x86_64 requires /bin/sh arm-gp2x-linux-gcc-4.1.2-8.fc9.x86_64 requires /bin/sh armacycles-ad-0.2.8.2.1-6.fc9.x86_64 requires /bin/sh armacycles-ad-0.2.8.2.1-6.fc9.x86_64 requires /bin/bash armacycles-ad-dedicated-0.2.8.2.1-6.fc9.x86_64 requires /bin/bash arp-scan-1.6-2.fc9.x86_64 requires /usr/bin/perl arpack-2.1-7.fc9.i386 requires /sbin/ldconfig arpack-2.1-7.fc9.x86_64 requires /sbin/ldconfig arptables_jf-0.0.8-12.fc9.x86_64 requires /bin/sh arptables_jf-0.0.8-12.fc9.x86_64 requires /bin/sh 14:arpwatch-2.1a15-8.fc9.x86_64 requires /bin/sh 14:arpwatch-2.1a15-8.fc9.x86_64 requires /bin/bash 14:arpwatch-2.1a15-8.fc9.x86_64 requires /sbin/chkconfig 14:arpwatch-2.1a15-8.fc9.x86_64 requires /bin/sh 14:arpwatch-2.1a15-8.fc9.x86_64 requires /sbin/service arrows-0.6-6.fc9.x86_64 requires /bin/sh 8:arts-1.5.9-3.fc10.i386 requires /sbin/ldconfig 8:arts-1.5.9-3.fc10.i386 requires /bin/sh 8:arts-1.5.9-3.fc10.x86_64 requires /sbin/ldconfig 8:arts-1.5.9-3.fc10.x86_64 requires /bin/sh 8:arts-devel-1.5.9-3.fc10.i386 requires /bin/sh 8:arts-devel-1.5.9-3.fc10.x86_64 requires /bin/sh artwiz-aleczapka-fonts-1.3-5.fc8.1.noarch requires /bin/sh asc-2.1.0.0-1.fc10.x86_64 requires /bin/sh asciidoc-8.2.5-2.fc9.noarch requires /usr/bin/env asm2-2.2.3-2jpp.1.fc9.noarch requires /bin/sh 12:aspell-0.60.6-1.fc10.i386 requires /bin/sh 12:aspell-0.60.6-1.fc10.i386 requires /sbin/install-info 12:aspell-0.60.6-1.fc10.i386 requires /sbin/ldconfig 12:aspell-0.60.6-1.fc10.i386 requires /bin/sh 12:aspell-0.60.6-1.fc10.x86_64 requires /bin/sh 12:aspell-0.60.6-1.fc10.x86_64 requires /sbin/install-info 12:aspell-0.60.6-1.fc10.x86_64 requires /sbin/ldconfig 12:aspell-0.60.6-1.fc10.x86_64 requires /bin/sh 12:aspell-devel-0.60.6-1.fc10.i386 requires /bin/sh 12:aspell-devel-0.60.6-1.fc10.i386 requires /sbin/install-info 12:aspell-devel-0.60.6-1.fc10.i386 requires /bin/sh 12:aspell-devel-0.60.6-1.fc10.x86_64 requires /bin/sh 12:aspell-devel-0.60.6-1.fc10.x86_64 requires /sbin/install-info 12:aspell-devel-0.60.6-1.fc10.x86_64 requires /bin/sh asterisk-1.6.0-0.13.beta8.fc10.x86_64 requires /bin/sh asterisk-1.6.0-0.13.beta8.fc10.x86_64 requires /usr/sbin/groupadd asterisk-1.6.0-0.13.beta8.fc10.x86_64 requires /usr/sbin/useradd asterisk-1.6.0-0.13.beta8.fc10.x86_64 requires /sbin/service asterisk-1.6.0-0.13.beta8.fc10.x86_64 requires /bin/bash asterisk-1.6.0-0.13.beta8.fc10.x86_64 requires /bin/sh asterisk-1.6.0-0.13.beta8.fc10.x86_64 requires /sbin/chkconfig asterisk-misdn-1.6.0-0.13.beta8.fc10.x86_64 requires /bin/sh asterisk-misdn-1.6.0-0.13.beta8.fc10.x86_64 requires /usr/sbin/usermod asterisk-voicemail-1.6.0-0.13.beta8.fc10.x86_64 requires /usr/bin/sox asterisk-zaptel-1.6.0-0.13.beta8.fc10.x86_64 requires /bin/sh asterisk-zaptel-1.6.0-0.13.beta8.fc10.x86_64 requires /usr/sbin/usermod astromenace-1.2-8.fc9.x86_64 requires /bin/sh asylum-0.2.3-3.fc9.x86_64 requires /bin/sh asymptote-1.42-3.fc10.x86_64 requires /bin/sh asymptote-1.42-3.fc10.x86_64 requires /usr/bin/env at-3.1.10-23.fc9.x86_64 requires /bin/sh at-3.1.10-23.fc9.x86_64 requires /bin/bash at-3.1.10-23.fc9.x86_64 requires /bin/sh at-spi-1.22.1-2.fc10.i386 requires /sbin/ldconfig at-spi-1.22.1-2.fc10.x86_64 requires /sbin/ldconfig aterm-1.0.1-2.fc9.x86_64 requires /bin/sh atk-1.22.0-1.fc9.i386 requires /sbin/ldconfig atk-1.22.0-1.fc9.x86_64 requires /sbin/ldconfig atlas-3.6.0-15.fc10.i386 requires /etc/ld.so.conf.d atlas-3.6.0-15.fc10.i386 requires /sbin/ldconfig atlas-3.6.0-15.fc10.x86_64 requires /sbin/ldconfig atlas-3.6.0-15.fc10.x86_64 requires /etc/ld.so.conf.d atlas-3dnow-3.6.0-15.fc10.i386 requires /sbin/ldconfig atlas-sse-3.6.0-15.fc10.i386 requires /sbin/ldconfig atlas-sse2-3.6.0-15.fc10.i386 requires /sbin/ldconfig atlascpp-0.6.1-3.fc9.i386 requires /sbin/ldconfig atlascpp-0.6.1-3.fc9.x86_64 requires /sbin/ldconfig atomorun-1.1-0.8.pre2.fc9.x86_64 requires /bin/sh atop-1.23-7.fc10.x86_64 requires /bin/sh atop-1.23-7.fc10.x86_64 requires /bin/bash atop-1.23-7.fc10.x86_64 requires /sbin/chkconfig atop-1.23-7.fc10.x86_64 requires /sbin/service audacious-1.4.6-1.fc9.x86_64 requires /bin/sh audacious-devel-1.4.6-1.fc9.i386 requires /sbin/ldconfig audacious-devel-1.4.6-1.fc9.x86_64 requires /sbin/ldconfig audacious-libs-1.4.6-1.fc9.i386 requires /sbin/ldconfig audacious-libs-1.4.6-1.fc9.x86_64 requires /sbin/ldconfig audacious-plugins-1.4.5-1.fc9.x86_64 requires /bin/sh audacious-plugins-1.4.5-1.fc9.x86_64 requires /sbin/ldconfig audacity-1.3.5-0.4.beta.fc10.x86_64 requires /bin/sh audio-convert-mod-3.45.4-1.fc10.noarch requires /bin/bash audio-entropyd-1.0.1-2.fc9.x86_64 requires /bin/sh audio-entropyd-1.0.1-2.fc9.x86_64 requires /bin/sh 1:audiofile-0.2.6-8.fc9.i386 requires /sbin/ldconfig 1:audiofile-0.2.6-8.fc9.x86_64 requires /sbin/ldconfig 1:audiofile-devel-0.2.6-8.fc9.i386 requires /bin/sh 1:audiofile-devel-0.2.6-8.fc9.x86_64 requires /bin/sh audispd-plugins-1.7.3-1.fc10.x86_64 requires /usr/sbin/semodule audispd-plugins-1.7.3-1.fc10.x86_64 requires /bin/sh audispd-plugins-1.7.3-1.fc10.x86_64 requires /sbin/restorecon audit-1.7.3-1.fc10.x86_64 requires /bin/sh audit-1.7.3-1.fc10.x86_64 requires /bin/bash audit-libs-1.7.3-1.fc10.i386 requires /sbin/ldconfig audit-libs-1.7.3-1.fc10.x86_64 requires /sbin/ldconfig audit-viewer-0.2-2.fc10.x86_64 requires /bin/sh audit-viewer-0.2-2.fc10.x86_64 requires /bin/sh augeas-libs-0.1.1-1.fc10.i386 requires /sbin/ldconfig augeas-libs-0.1.1-1.fc10.x86_64 requires /sbin/ldconfig aumix-2.8-17.fc9.x86_64 requires /bin/sh auriferous-1.0.1-5.fc9.x86_64 requires /bin/sh authconfig-5.4.2-1.fc9.x86_64 requires /bin/sh authconfig-5.4.2-1.fc9.x86_64 requires /usr/bin/python authconfig-gtk-5.4.2-1.fc9.x86_64 requires /usr/bin/python authd-1.4.3-19.fc9.x86_64 requires /bin/sh autobuild-applet-1.0.3-5.fc9.x86_64 requires /bin/sh autobuild-applet-1.0.3-5.fc9.x86_64 requires /usr/bin/python autoconf-2.62-1.fc10.noarch requires /bin/sh autoconf-2.62-1.fc10.noarch requires /sbin/install-info autoconf-2.62-1.fc10.noarch requires /usr/bin/perl autoconf-2.62-1.fc10.noarch requires /bin/sh autoconf213-2.13-18.fc8.noarch requires /bin/sh autoconf213-2.13-18.fc8.noarch requires /usr/bin/perl autoconf213-2.13-18.fc8.noarch requires /sbin/install-info autoconf213-2.13-18.fc8.noarch requires /bin/sh autodir-0.99.9-5.fc9.x86_64 requires /bin/sh autodir-0.99.9-5.fc9.x86_64 requires /sbin/service autodir-0.99.9-5.fc9.x86_64 requires /bin/sh autodir-0.99.9-5.fc9.x86_64 requires /sbin/chkconfig autodownloader-0.2.0-6.fc9.noarch requires /usr/bin/env 1:autofs-5.0.3-16.x86_64 requires /bin/sh 1:autofs-5.0.3-16.x86_64 requires /bin/ps 1:autofs-5.0.3-16.x86_64 requires /sbin/service 1:autofs-5.0.3-16.x86_64 requires /bin/bash 1:autofs-5.0.3-16.x86_64 requires /sbin/chkconfig autogen-5.9.4-4.fc9.x86_64 requires /bin/sh autogen-5.9.4-4.fc9.x86_64 requires /sbin/install-info autogen-libopts-5.9.4-4.fc9.i386 requires /sbin/ldconfig autogen-libopts-5.9.4-4.fc9.x86_64 requires /sbin/ldconfig autogen-libopts-devel-5.9.4-4.fc9.i386 requires /bin/sh autogen-libopts-devel-5.9.4-4.fc9.x86_64 requires /bin/sh automake-1.10.1-2.noarch requires /bin/sh automake-1.10.1-2.noarch requires /sbin/install-info automake-1.10.1-2.noarch requires /bin/sh automake-1.10.1-2.noarch requires /usr/bin/perl automake14-1.4p6-15.fc7.noarch requires /bin/sh automake14-1.4p6-15.fc7.noarch requires /usr/bin/perl automake14-1.4p6-15.fc7.noarch requires /sbin/install-info automake14-1.4p6-15.fc7.noarch requires /bin/sh automake15-1.5-23.noarch requires /bin/sh automake15-1.5-23.noarch requires /usr/bin/perl automake15-1.5-23.noarch requires /sbin/install-info automake15-1.5-23.noarch requires /bin/sh automake16-1.6.3-14.noarch requires /bin/sh automake16-1.6.3-14.noarch requires /sbin/install-info automake16-1.6.3-14.noarch requires /bin/sh automake16-1.6.3-14.noarch requires /usr/bin/perl automake17-1.7.9-11.noarch requires /bin/sh automake17-1.7.9-11.noarch requires /sbin/install-info automake17-1.7.9-11.noarch requires /bin/sh automake17-1.7.9-11.noarch requires /usr/bin/perl autossh-1.4a-1.fc9.x86_64 requires /usr/bin/ssh autotrace-0.31.1-16.fc9.i386 requires /sbin/ldconfig autotrace-0.31.1-16.fc9.i386 requires libWand.so.10 autotrace-0.31.1-16.fc9.i386 requires libMagick.so.10 autotrace-0.31.1-16.fc9.x86_64 requires libWand.so.10()(64bit) autotrace-0.31.1-16.fc9.x86_64 requires /sbin/ldconfig autotrace-0.31.1-16.fc9.x86_64 requires libMagick.so.10()(64bit) autotrace-devel-0.31.1-16.fc9.i386 requires /bin/sh autotrace-devel-0.31.1-16.fc9.x86_64 requires /bin/sh avahi-0.6.22-10.fc9.i386 requires /bin/sh avahi-0.6.22-10.fc9.i386 requires /bin/sh avahi-0.6.22-10.fc9.x86_64 requires /bin/sh avahi-0.6.22-10.fc9.x86_64 requires /bin/sh avahi-autoipd-0.6.22-10.fc9.x86_64 requires /bin/sh avahi-autoipd-0.6.22-10.fc9.x86_64 requires /bin/sh avahi-compat-howl-0.6.22-10.fc9.i386 requires /sbin/ldconfig avahi-compat-howl-0.6.22-10.fc9.x86_64 requires /sbin/ldconfig avahi-compat-libdns_sd-0.6.22-10.fc9.i386 requires /sbin/ldconfig avahi-compat-libdns_sd-0.6.22-10.fc9.x86_64 requires /sbin/ldconfig avahi-dnsconfd-0.6.22-10.fc9.x86_64 requires /bin/sh avahi-dnsconfd-0.6.22-10.fc9.x86_64 requires /bin/sh avahi-glib-0.6.22-10.fc9.i386 requires /sbin/ldconfig avahi-glib-0.6.22-10.fc9.x86_64 requires /sbin/ldconfig avahi-gobject-0.6.22-10.fc9.i386 requires /sbin/ldconfig avahi-gobject-0.6.22-10.fc9.x86_64 requires /sbin/ldconfig avahi-qt3-0.6.22-10.fc9.i386 requires /sbin/ldconfig avahi-qt3-0.6.22-10.fc9.x86_64 requires /sbin/ldconfig avahi-tools-0.6.22-10.fc9.x86_64 requires /usr/bin/python avahi-ui-0.6.22-10.fc9.i386 requires /sbin/ldconfig avahi-ui-0.6.22-10.fc9.x86_64 requires /sbin/ldconfig avalon-framework-4.1.4-3jpp.14.fc9.x86_64 requires /bin/sh avalon-framework-javadoc-4.1.4-3jpp.14.fc9.x86_64 requires /bin/rm avalon-framework-javadoc-4.1.4-3jpp.14.fc9.x86_64 requires /bin/ln avalon-logkit-1.2-5jpp.5.fc9.x86_64 requires /bin/sh avalon-logkit-javadoc-1.2-5jpp.5.fc9.x86_64 requires /bin/sh avalon-logkit-javadoc-1.2-5jpp.5.fc9.x86_64 requires /bin/rm avalon-logkit-javadoc-1.2-5jpp.5.fc9.x86_64 requires /bin/ln avant-window-navigator-0.2.6-8.fc9.i386 requires /bin/sh avant-window-navigator-0.2.6-8.fc9.i386 requires /usr/bin/env avant-window-navigator-0.2.6-8.fc9.i386 requires /usr/bin/python avant-window-navigator-0.2.6-8.fc9.i386 requires /bin/bash avant-window-navigator-0.2.6-8.fc9.x86_64 requires /bin/sh avant-window-navigator-0.2.6-8.fc9.x86_64 requires /usr/bin/env avant-window-navigator-0.2.6-8.fc9.x86_64 requires /usr/bin/python avant-window-navigator-0.2.6-8.fc9.x86_64 requires /bin/bash avarice-2.6-2.fc9.x86_64 requires /usr/bin/perl avarice-2.6-2.fc9.x86_64 requires /bin/sh avr-gcc-4.1.2-6.fc9.x86_64 requires /bin/sh avr-libc-1.4.6-4.fc8.noarch requires /bin/sh avrdude-5.5-3.fc9.x86_64 requires /bin/sh avrdude-5.5-3.fc9.x86_64 requires /sbin/install-info awn-extras-applets-0.2.6-4.fc9.i386 requires /usr/bin/python awn-extras-applets-0.2.6-4.fc9.i386 requires /usr/bin/env awn-extras-applets-0.2.6-4.fc9.i386 requires /bin/sh awn-extras-applets-0.2.6-4.fc9.x86_64 requires /bin/sh awn-extras-applets-0.2.6-4.fc9.x86_64 requires /usr/bin/python awn-extras-applets-0.2.6-4.fc9.x86_64 requires /usr/bin/env awstats-6.7-3.fc9.noarch requires /bin/bash awstats-6.7-3.fc9.noarch requires /usr/bin/perl awstats-6.7-3.fc9.noarch requires /bin/sh awstats-6.7-3.fc9.noarch requires /sbin/service awstats-selinux-6.7-3.fc9.noarch requires /bin/sh ax25-tools-0.0.8-2.fc9.x86_64 requires /bin/sh axis-1.2.1-3jpp.8.fc9.x86_64 requires /bin/sh azureus-3.0.4.2-14.fc9.x86_64 requires /bin/sh azureus-3.0.4.2-14.fc9.x86_64 requires /bin/sh babel-0.9.2-1.fc9.noarch requires /usr/bin/python babl-0.0.20-1.fc9.i386 requires /sbin/ldconfig babl-0.0.20-1.fc9.x86_64 requires /sbin/ldconfig bacula-client-2.0.3-13.fc9.x86_64 requires /bin/sh bacula-client-2.0.3-13.fc9.x86_64 requires /sbin/service bacula-client-2.0.3-13.fc9.x86_64 requires /bin/bash bacula-client-2.0.3-13.fc9.x86_64 requires /sbin/chkconfig bacula-common-2.0.3-13.fc9.x86_64 requires /bin/sh bacula-common-2.0.3-13.fc9.x86_64 requires /bin/sh bacula-director-common-2.0.3-13.fc9.x86_64 requires /bin/sh bacula-director-common-2.0.3-13.fc9.x86_64 requires /bin/bash bacula-director-common-2.0.3-13.fc9.x86_64 requires /bin/sh bacula-director-common-2.0.3-13.fc9.x86_64 requires /usr/bin/perl bacula-director-mysql-2.0.3-13.fc9.x86_64 requires /bin/sh bacula-director-mysql-2.0.3-13.fc9.x86_64 requires /bin/sh bacula-director-postgresql-2.0.3-13.fc9.x86_64 requires /bin/sh bacula-director-postgresql-2.0.3-13.fc9.x86_64 requires /bin/sh bacula-director-sqlite-2.0.3-13.fc9.x86_64 requires /bin/sh bacula-director-sqlite-2.0.3-13.fc9.x86_64 requires /bin/sh bacula-storage-common-2.0.3-13.fc9.x86_64 requires /bin/sh bacula-storage-common-2.0.3-13.fc9.x86_64 requires /usr/bin/python bacula-storage-common-2.0.3-13.fc9.x86_64 requires /bin/bash bacula-storage-common-2.0.3-13.fc9.x86_64 requires /bin/sh bacula-storage-mysql-2.0.3-13.fc9.x86_64 requires /bin/sh bacula-storage-postgresql-2.0.3-13.fc9.x86_64 requires /bin/sh bacula-storage-sqlite-2.0.3-13.fc9.x86_64 requires /bin/sh baekmuk-bdf-fonts-2.2-5.fc9.noarch requires /bin/sh baekmuk-ttf-fonts-batang-2.2-7.fc9.noarch requires /bin/sh baekmuk-ttf-fonts-dotum-2.2-7.fc9.noarch requires /bin/sh baekmuk-ttf-fonts-gulim-2.2-7.fc9.noarch requires /bin/sh baekmuk-ttf-fonts-hline-2.2-7.fc9.noarch requires /bin/sh bakery-2.4.4-2.fc9.i386 requires /sbin/ldconfig bakery-2.4.4-2.fc9.x86_64 requires /sbin/ldconfig ballbuster-1.0-5.fc9.x86_64 requires /bin/sh ballz-1.0-3.fc9.x86_64 requires /bin/sh balsa-2.3.23-1.fc9.x86_64 requires /bin/sh banshee-0.99.1-1.1.fc10.x86_64 requires /bin/sh banshee-0.99.1-1.1.fc10.x86_64 requires /bin/bash barcode-0.98-11.fc9.x86_64 requires /bin/sh barcode-0.98-11.fc9.x86_64 requires /sbin/install-info bash-3.2-22.fc9.x86_64 requires /bin/sh bash-3.2-22.fc9.x86_64 requires /bin/bash bash-3.2-22.fc9.x86_64 requires /bin/sh bash-completion-20060301-10.noarch requires /bin/sh basket-1.0.2-5.fc9.x86_64 requires /bin/sh bazaar-1.4.2-11.fc9.x86_64 requires /usr/bin/gawk bc-1.06-33.fc9.x86_64 requires /bin/sh bc-1.06-33.fc9.x86_64 requires /sbin/install-info bcel-5.2-4jpp.2.fc9.x86_64 requires /bin/sh bcfg2-0.9.5.7-1.fc9.noarch requires /bin/sh bcfg2-0.9.5.7-1.fc9.noarch requires /sbin/chkconfig bcfg2-0.9.5.7-1.fc9.noarch requires /bin/sh bcfg2-0.9.5.7-1.fc9.noarch requires /usr/bin/python bcfg2-0.9.5.7-1.fc9.noarch requires /sbin/service bcfg2-server-0.9.5.7-1.fc9.noarch requires /bin/sh bcfg2-server-0.9.5.7-1.fc9.noarch requires /usr/bin/openssl bcfg2-server-0.9.5.7-1.fc9.noarch requires /sbin/chkconfig bcfg2-server-0.9.5.7-1.fc9.noarch requires /bin/sh bcfg2-server-0.9.5.7-1.fc9.noarch requires /usr/bin/python bcfg2-server-0.9.5.7-1.fc9.noarch requires /sbin/service 1:bdftruncate-7.2-4.fc9.x86_64 requires /usr/bin/perl bea-stax-1.2.0-0.2.rc1.2jpp.1.fc9.x86_64 requires /bin/sh bea-stax-api-1.2.0-0.2.rc1.2jpp.1.fc9.x86_64 requires /bin/sh beagle-0.3.7-3.fc9.x86_64 requires /bin/sh beagle-0.3.7-3.fc9.x86_64 requires /bin/bash beagle-0.3.7-3.fc9.x86_64 requires /bin/sh beagle-devel-0.3.7-3.fc9.i386 requires /bin/sh beagle-devel-0.3.7-3.fc9.x86_64 requires /bin/sh beagle-gnome-0.3.7-3.fc9.x86_64 requires /bin/sh berusky-1.1-8.fc9.x86_64 requires /bin/sh bes-3.5.3-3.fc9.i386 requires /bin/sh bes-3.5.3-3.fc9.i386 requires /sbin/ldconfig bes-3.5.3-3.fc9.i386 requires /bin/sh bes-3.5.3-3.fc9.x86_64 requires /bin/sh bes-3.5.3-3.fc9.x86_64 requires /sbin/ldconfig bes-3.5.3-3.fc9.x86_64 requires /bin/sh bes-devel-3.5.3-3.fc9.i386 requires /bin/sh bes-devel-3.5.3-3.fc9.x86_64 requires /bin/sh bibexport-2.10-2.fc9.noarch requires /usr/bin/texhash bibexport-2.10-2.fc9.noarch requires /bin/sh bibexport-2.10-2.fc9.noarch requires /bin/sh bibletime-1.6.5-4.fc9.x86_64 requires /bin/sh bibus-1.4.1-4.fc9.noarch requires /usr/bin/env bigboard-0.5.33-2.fc10.x86_64 requires /bin/sh bigboard-0.5.33-2.fc10.x86_64 requires /bin/sh bigloo-3.0b-2.fc9.x86_64 requires /bin/sh bigloo-3.0b-2.fc9.x86_64 requires /sbin/install-info bigloo-3.0b-2.fc9.x86_64 requires /bin/sh bigloo-libs-3.0b-2.fc9.x86_64 requires /sbin/ldconfig biloba-0.6-1.fc10.x86_64 requires /bin/sh 32:bind-9.5.0-33.rc1.fc10.x86_64 requires /bin/sh 32:bind-9.5.0-33.rc1.fc10.x86_64 requires /bin/bash 32:bind-9.5.0-33.rc1.fc10.x86_64 requires /bin/sh 32:bind-chroot-9.5.0-33.rc1.fc10.x86_64 requires /bin/sh 32:bind-chroot-9.5.0-33.rc1.fc10.x86_64 requires /bin/bash 32:bind-chroot-9.5.0-33.rc1.fc10.x86_64 requires /bin/sh 32:bind-devel-9.5.0-33.rc1.fc10.i386 requires /bin/sh 32:bind-devel-9.5.0-33.rc1.fc10.x86_64 requires /bin/sh 32:bind-libs-9.5.0-33.rc1.fc10.i386 requires /sbin/ldconfig 32:bind-libs-9.5.0-33.rc1.fc10.x86_64 requires /sbin/ldconfig 32:bind-sdb-9.5.0-33.rc1.fc10.x86_64 requires /bin/sh binutils-2.18.50.0.6-2.x86_64 requires /bin/sh binutils-2.18.50.0.6-2.x86_64 requires /sbin/ldconfig binutils-2.18.50.0.6-2.x86_64 requires /sbin/install-info binutils-devel-2.18.50.0.6-2.i386 requires /bin/sh binutils-devel-2.18.50.0.6-2.i386 requires /sbin/install-info binutils-devel-2.18.50.0.6-2.x86_64 requires /bin/sh binutils-devel-2.18.50.0.6-2.x86_64 requires /sbin/install-info bison-2.3-5.fc9.x86_64 requires /bin/sh bison-2.3-5.fc9.x86_64 requires /sbin/install-info bit-0.4.1-3.fc9.i386 requires /sbin/ldconfig bit-0.4.1-3.fc9.x86_64 requires /sbin/ldconfig bitbake-1.8.8-1.fc8.noarch requires /usr/bin/python bitgtkmm-0.4.0-2.fc7.i386 requires /sbin/ldconfig bitgtkmm-0.4.0-2.fc7.x86_64 requires /sbin/ldconfig bitlbee-1.2-1.fc9.x86_64 requires /bin/sh bitlbee-1.2-1.fc9.x86_64 requires /sbin/service bitmap-1.0.3-4.fc9.x86_64 requires /bin/sh bitmap-fonts-0.3-5.2.fc9.noarch requires /bin/sh bitmap-fonts-cjk-0.3-5.2.fc9.noarch requires /bin/sh bitstream-vera-fonts-1.10-8.noarch requires /bin/sh bittorrent-4.4.0-6.fc9.noarch requires /bin/sh bittorrent-4.4.0-6.fc9.noarch requires /bin/bash bittorrent-4.4.0-6.fc9.noarch requires /sbin/chkconfig bittorrent-4.4.0-6.fc9.noarch requires /usr/sbin/useradd bittorrent-4.4.0-6.fc9.noarch requires /usr/bin/python bittorrent-4.4.0-6.fc9.noarch requires /sbin/service bittorrent-4.4.0-6.fc9.noarch requires /usr/sbin/usermod bittorrent-gui-4.4.0-6.fc9.noarch requires /bin/sh bittorrent-gui-4.4.0-6.fc9.noarch requires /usr/bin/python blackbox-0.70.1-11.i386 requires /sbin/ldconfig blackbox-0.70.1-11.i386 requires /bin/sh blackbox-0.70.1-11.x86_64 requires /sbin/ldconfig blackbox-0.70.1-11.x86_64 requires /bin/sh blacs-1.1-26.fc9.1.i386 requires /sbin/ldconfig blacs-1.1-26.fc9.1.x86_64 requires /sbin/ldconfig blam-1.8.3-13.fc9.x86_64 requires /bin/sh blam-1.8.3-13.fc9.x86_64 requires /bin/bash blas-3.1.1-3.fc9.i386 requires /sbin/ldconfig blas-3.1.1-3.fc9.x86_64 requires /sbin/ldconfig blender-2.46-0.3.fc10.x86_64 requires /bin/sh blender-2.46-0.3.fc10.x86_64 requires /bin/sh bless-0.5.2-6.fc9.x86_64 requires /bin/sh bless-doc-0.5.2-6.fc9.x86_64 requires /bin/sh blitz-0.9-7.fc9.i386 requires /sbin/ldconfig blitz-0.9-7.fc9.i386 requires /sbin/install-info blitz-0.9-7.fc9.x86_64 requires /sbin/ldconfig blitz-0.9-7.fc9.x86_64 requires /sbin/install-info blitz-devel-0.9-7.fc9.i386 requires /bin/sh blitz-devel-0.9-7.fc9.x86_64 requires /bin/sh blktrace-0.0-0.9.20080103162505.fc9.x86_64 requires /bin/sh blobAndConquer-0.93-1.fc10.x86_64 requires /bin/sh blobby-0.6-0.7.a.fc8.x86_64 requires /bin/sh blobwars-1.07-2.fc9.x86_64 requires /bin/sh blogtk-1.1-9.fc9.noarch requires /usr/bin/env blogtk-1.1-9.fc9.noarch requires /bin/sh blt-2.4-27.fc9.x86_64 requires /sbin/ldconfig blt-2.4-27.fc9.x86_64 requires /usr/bin/wish blt-2.4-27.fc9.x86_64 requires /usr/bin/tclsh bluecurve-icon-theme-8.0.2-1.fc9.noarch requires /bin/sh bluefish-1.0.7-4.fc9.x86_64 requires /bin/sh bluez-gnome-0.25-1.fc9.x86_64 requires /bin/sh bluez-libs-3.31-1.fc10.i386 requires /sbin/ldconfig bluez-libs-3.31-1.fc10.x86_64 requires /sbin/ldconfig bluez-utils-3.31-1.fc10.x86_64 requires /bin/sh bluez-utils-3.31-1.fc10.x86_64 requires /sbin/service bluez-utils-3.31-1.fc10.x86_64 requires /sbin/chkconfig bluez-utils-3.31-1.fc10.x86_64 requires /bin/sh bmpx-0.40.13-11.fc9.x86_64 requires /bin/sh bmpx-0.40.13-11.fc9.x86_64 requires /bin/sh boa-0.94.14-0.10.rc21.fc9.x86_64 requires /bin/sh boa-0.94.14-0.10.rc21.fc9.x86_64 requires /bin/bash boa-0.94.14-0.10.rc21.fc9.x86_64 requires /etc/mime.types boa-0.94.14-0.10.rc21.fc9.x86_64 requires /sbin/chkconfig boa-0.94.14-0.10.rc21.fc9.x86_64 requires /usr/sbin/useradd boa-0.94.14-0.10.rc21.fc9.x86_64 requires /sbin/service bochs-dlxlinux-2.3.6-3.fc9.x86_64 requires /bin/sh bodhi-client-0.4.10-3.fc9.noarch requires /usr/bin/python bodhi-server-0.4.10-3.fc9.noarch requires /usr/bin/python bodhi-server-0.4.10-3.fc9.noarch requires /usr/bin/env bogl-0.1.18-14.i386 requires /sbin/ldconfig bogl-0.1.18-14.x86_64 requires /sbin/ldconfig bogl-devel-0.1.18-14.i386 requires /usr/bin/perl bogl-devel-0.1.18-14.x86_64 requires /usr/bin/perl bogofilter-1.1.6-2.fc9.x86_64 requires /usr/bin/perl bogofilter-1.1.6-2.fc9.x86_64 requires /bin/sh boinc-client-5.10.45-13.20080315svn.fc10.x86_64 requires /bin/sh boinc-client-5.10.45-13.20080315svn.fc10.x86_64 requires /bin/sh boinc-manager-5.10.45-13.20080315svn.fc10.x86_64 requires /bin/sh bolzplatz2006-1.0.3-6.fc9.x86_64 requires /bin/sh bolzplatz2006-1.0.3-6.fc9.x86_64 requires /bin/sh bombardier-0.8.2.2-8.fc9.x86_64 requires /bin/sh bonnie++-1.03a-9.fc9.x86_64 requires /usr/bin/perl bontmia-0.14-2.fc8.noarch requires /bin/bash boo-0.8.1.2865-4.fc9.x86_64 requires /bin/sh boo-0.8.1.2865-4.fc9.x86_64 requires /bin/sh boolstuff-0.1.11-5.fc9.i386 requires /sbin/ldconfig boolstuff-0.1.11-5.fc9.x86_64 requires /sbin/ldconfig boost-1.34.1-13.fc9.i386 requires /sbin/ldconfig boost-1.34.1-13.fc9.x86_64 requires /sbin/ldconfig bootchart-0.9-9.fc9.x86_64 requires /bin/sh bootchart-0.9-9.fc9.x86_64 requires /bin/sh bootparamd-0.17-27.fc9.x86_64 requires /bin/sh bootparamd-0.17-27.fc9.x86_64 requires /sbin/chkconfig bootparamd-0.17-27.fc9.x86_64 requires /bin/sh bootparamd-0.17-27.fc9.x86_64 requires /sbin/service boswars-2.5-1.fc9.x86_64 requires /bin/sh bouml-4.3.3-1.fc10.x86_64 requires /bin/sh bouml-4.3.3-1.fc10.x86_64 requires /bin/sh bouncycastle-1.39-1.fc10.x86_64 requires /bin/sh bpython-0.3.1-2.fc10.noarch requires /usr/bin/python brasero-0.7.1-4.fc10.x86_64 requires /bin/sh brazil-2.3-3.fc10.x86_64 requires /usr/bin/rebuild-gcj-db brazil-demo-2.3-3.fc10.x86_64 requires /usr/bin/tclsh brazil-demo-2.3-3.fc10.x86_64 requires /bin/sh brettfont-fonts-20080506-2.fc10.noarch requires /bin/sh brltty-3.9-2.2.fc9.x86_64 requires /bin/sh brltty-3.9-2.2.fc9.x86_64 requires /bin/bash brltty-3.9-2.2.fc9.x86_64 requires /bin/sh 1:broffice.org-base-3.0.0-0.0.12.1.fc10.x86_64 requires /bin/sh 1:broffice.org-base-3.0.0-0.0.12.1.fc10.x86_64 requires /bin/sh 1:broffice.org-brand-3.0.0-0.0.12.1.fc10.x86_64 requires /bin/sh 1:broffice.org-brand-3.0.0-0.0.12.1.fc10.x86_64 requires /bin/sh 1:broffice.org-calc-3.0.0-0.0.12.1.fc10.x86_64 requires /bin/sh 1:broffice.org-calc-3.0.0-0.0.12.1.fc10.x86_64 requires /bin/sh 1:broffice.org-draw-3.0.0-0.0.12.1.fc10.x86_64 requires /bin/sh 1:broffice.org-draw-3.0.0-0.0.12.1.fc10.x86_64 requires /bin/sh 1:broffice.org-impress-3.0.0-0.0.12.1.fc10.x86_64 requires /bin/sh 1:broffice.org-impress-3.0.0-0.0.12.1.fc10.x86_64 requires /bin/sh 1:broffice.org-math-3.0.0-0.0.12.1.fc10.x86_64 requires /bin/sh 1:broffice.org-math-3.0.0-0.0.12.1.fc10.x86_64 requires /bin/sh 1:broffice.org-writer-3.0.0-0.0.12.1.fc10.x86_64 requires /bin/sh 1:broffice.org-writer-3.0.0-0.0.12.1.fc10.x86_64 requires /bin/sh brutus-keyring-devel-0.9.0-6.fc8.i386 requires /sbin/ldconfig brutus-keyring-devel-0.9.0-6.fc8.x86_64 requires /sbin/ldconfig bsd-games-2.17-23.fc9.x86_64 requires /bin/sh bsd-games-2.17-23.fc9.x86_64 requires /bin/sh bsd-games-2.17-23.fc9.x86_64 requires /usr/sbin/groupadd bsf-2.3.0-12jpp.2.fc9.x86_64 requires /bin/sh bsh-1.3.0-12jpp.3.fc9.x86_64 requires /bin/sh bsh-demo-1.3.0-12jpp.3.fc9.x86_64 requires /usr/bin/env bsh-desktop-1.3.0-12jpp.3.fc9.x86_64 requires /bin/sh 1:bug-buddy-2.22.0-3.fc10.i386 requires /bin/sh 1:bug-buddy-2.22.0-3.fc10.x86_64 requires /bin/sh bugzilla-3.0.4-1.fc10.noarch requires /bin/sh bugzilla-3.0.4-1.fc10.noarch requires /bin/sh bugzilla-3.0.4-1.fc10.noarch requires /usr/bin/perl bugzilla-contrib-3.0.4-1.fc10.noarch requires /usr/bin/env bugzilla-contrib-3.0.4-1.fc10.noarch requires /usr/bin/python bugzilla-contrib-3.0.4-1.fc10.noarch requires /usr/bin/perl bugzilla-contrib-3.0.4-1.fc10.noarch requires /bin/sh bugzilla-contrib-3.0.4-1.fc10.noarch requires /usr/bin/ruby bugzilla-doc-3.0.4-1.fc10.noarch requires /usr/bin/perl buildbot-0.7.7-2.fc9.noarch requires /usr/bin/env buildbot-0.7.7-2.fc9.noarch requires /usr/bin/python buoh-0.8.2-4.fc9.x86_64 requires /bin/sh bwbar-1.2.3-2.x86_64 requires /bin/sh bwbar-1.2.3-2.x86_64 requires /bin/bash bwbar-1.2.3-2.x86_64 requires /sbin/service byzanz-0.1.1-6.fc9.x86_64 requires /bin/sh bzip2-1.0.5-1.fc9.x86_64 requires /bin/sh bzip2-libs-1.0.5-1.fc9.i386 requires /sbin/ldconfig bzip2-libs-1.0.5-1.fc9.x86_64 requires /sbin/ldconfig bzr-1.4-2.fc10.x86_64 requires /usr/bin/python bzr-gtk-0.94.0-1.fc10.x86_64 requires /usr/bin/python c-ares-1.5.1-2.fc9.i386 requires /sbin/ldconfig c-ares-1.5.1-2.fc9.x86_64 requires /sbin/ldconfig cachefilesd-0.7-4.fc9.x86_64 requires /bin/sh cachefilesd-0.7-4.fc9.x86_64 requires /bin/bash cachefilesd-0.7-4.fc9.x86_64 requires /sbin/chkconfig cachefilesd-0.7-4.fc9.x86_64 requires /sbin/service cacti-0.8.7b-1.fc9.noarch requires /bin/sh cacti-0.8.7b-1.fc9.noarch requires /usr/bin/perl cacti-0.8.7b-1.fc9.noarch requires /usr/sbin/useradd cacti-0.8.7b-1.fc9.noarch requires /usr/bin/php cacti-0.8.7b-1.fc9.noarch requires /bin/sh cacti-0.8.7b-1.fc9.noarch requires /sbin/service cairo-1.6.4-1.fc9.i386 requires /sbin/ldconfig cairo-1.6.4-1.fc9.x86_64 requires /sbin/ldconfig cairo-clock-0.3.4-1.fc9.x86_64 requires /sbin/ldconfig cairo-dock-1.5.5.4-4.date20080506.fc10.x86_64 requires /bin/sh cairo-dock-plug-ins-1.5.5.4-4.date20080506.fc10.x86_64 requires /bin/bash cairo-dock-plug-ins-1.5.5.4-4.date20080506.fc10.x86_64 requires /bin/sh cairo-java-1.0.5-9.fc9.i386 requires /sbin/ldconfig cairo-java-1.0.5-9.fc9.x86_64 requires /sbin/ldconfig cairomm-1.5.0-1.fc9.i386 requires /sbin/ldconfig cairomm-1.5.0-1.fc9.x86_64 requires /sbin/ldconfig cal3d-0.11.0-6.fc9.i386 requires /sbin/ldconfig cal3d-0.11.0-6.fc9.x86_64 requires /sbin/ldconfig calc-libs-2.12.2.1-12.fc9.i386 requires /sbin/ldconfig calc-libs-2.12.2.1-12.fc9.x86_64 requires /sbin/ldconfig calc-stdrc-2.12.2.1-12.fc9.x86_64 requires /usr/bin/calc callweaver-1.2-0.4.rc5.20071230.fc9.i386 requires /bin/sh callweaver-1.2-0.4.rc5.20071230.fc9.i386 requires /sbin/chkconfig callweaver-1.2-0.4.rc5.20071230.fc9.i386 requires /bin/bash callweaver-1.2-0.4.rc5.20071230.fc9.i386 requires /bin/sh callweaver-1.2-0.4.rc5.20071230.fc9.x86_64 requires /bin/sh callweaver-1.2-0.4.rc5.20071230.fc9.x86_64 requires /sbin/chkconfig callweaver-1.2-0.4.rc5.20071230.fc9.x86_64 requires /bin/bash callweaver-1.2-0.4.rc5.20071230.fc9.x86_64 requires /bin/sh callweaver-misdn-1.2-0.4.rc5.20071230.fc9.x86_64 requires /bin/sh callweaver-ogi-1.2-0.4.rc5.20071230.fc9.x86_64 requires /usr/bin/perl callweaver-zaptel-1.2-0.4.rc5.20071230.fc9.x86_64 requires /bin/sh castor-0.9.5-2jpp.8.fc9.x86_64 requires /bin/sh castor-0.9.5-2jpp.8.fc9.x86_64 requires /bin/sh castor-demo-0.9.5-2jpp.8.fc9.x86_64 requires /bin/sh castor-test-0.9.5-2jpp.8.fc9.x86_64 requires /bin/sh castor-xml-0.9.5-2jpp.8.fc9.x86_64 requires /bin/sh catdoc-0.94.2-4.fc9.x86_64 requires /usr/bin/wish catfish-0.3-1.fc8.noarch requires /usr/bin/locate catfish-0.3-1.fc8.noarch requires /usr/bin/env catfish-0.3-1.fc8.noarch requires /usr/bin/find ccache-2.4-13.fc9.x86_64 requires /bin/sh ccache-2.4-13.fc9.x86_64 requires /bin/sh ccid-1.2.1-4.fc9.x86_64 requires /bin/sh ccrtp-1.6.0-1.fc9.i386 requires /sbin/ldconfig ccrtp-1.6.0-1.fc9.x86_64 requires /sbin/ldconfig ccrtp-devel-1.6.0-1.fc9.i386 requires /bin/sh ccrtp-devel-1.6.0-1.fc9.i386 requires /sbin/install-info ccrtp-devel-1.6.0-1.fc9.x86_64 requires /bin/sh ccrtp-devel-1.6.0-1.fc9.x86_64 requires /sbin/install-info ccsm-0.7.2-1.fc9.noarch requires /bin/sh ccsm-0.7.2-1.fc9.noarch requires /usr/bin/python cdcollect-0.6.0-5.fc9.x86_64 requires /bin/sh cdcollect-0.6.0-5.fc9.x86_64 requires /bin/sh cdlabelgen-4.0.0-1.fc8.noarch requires /usr/bin/perl cdogs-data-0.4-3.fc8.noarch requires /bin/sh cdparanoia-libs-alpha9.8-30.i386 requires /bin/sh cdparanoia-libs-alpha9.8-30.x86_64 requires /bin/sh cduce-0.5.2.1-9.fc10.x86_64 requires /bin/sh cegui-0.5.0b-7.fc9.i386 requires /sbin/ldconfig cegui-0.5.0b-7.fc9.x86_64 requires /sbin/ldconfig cel-1.2-2.fc9.x86_64 requires /sbin/ldconfig cel-devel-1.2-2.fc9.i386 requires /bin/sh cel-devel-1.2-2.fc9.x86_64 requires /bin/sh celestia-1.5.0-1.fc9.x86_64 requires /bin/sh cellwriter-1.3.3-1.fc10.x86_64 requires /bin/sh 1:centerim-4.22.4-1.fc9.x86_64 requires /usr/bin/perl cernlib-2006-29.fc9.i386 requires /sbin/ldconfig cernlib-2006-29.fc9.x86_64 requires /sbin/ldconfig cernlib-g77-2006-29.fc9.i386 requires /sbin/ldconfig cernlib-g77-2006-29.fc9.x86_64 requires /sbin/ldconfig cernlib-g77-utils-2006-29.fc9.x86_64 requires /bin/bash cernlib-g77-utils-2006-29.fc9.x86_64 requires /bin/sh cernlib-packlib-2006-29.fc9.x86_64 requires /bin/sh cernlib-packlib-g77-2006-29.fc9.x86_64 requires /bin/sh cernlib-packlib-gfortran-2006-29.fc9.x86_64 requires /bin/sh cernlib-utils-2006-29.fc9.x86_64 requires /bin/bash cernlib-utils-2006-29.fc9.x86_64 requires /bin/sh certmaster-0.19-1.fc9.noarch requires /bin/sh certmaster-0.19-1.fc9.noarch requires /bin/sh certmaster-0.19-1.fc9.noarch requires /usr/bin/python cfengine-2.2.6-1.fc10.x86_64 requires /bin/sh cfengine-2.2.6-1.fc10.x86_64 requires /sbin/install-info cfengine-2.2.6-1.fc10.x86_64 requires /sbin/service cfengine-2.2.6-1.fc10.x86_64 requires /bin/bash cfengine-2.2.6-1.fc10.x86_64 requires /bin/sh cfengine-2.2.6-1.fc10.x86_64 requires /sbin/chkconfig cfitsio-3.060-3.fc9.i386 requires /sbin/ldconfig cfitsio-3.060-3.fc9.x86_64 requires /sbin/ldconfig cfv-1.18.1-4.fc8.1.noarch requires /usr/bin/env cgdb-0.6.4-3.fc9.x86_64 requires /bin/sh cgdb-0.6.4-3.fc9.x86_64 requires /sbin/install-info cgoban-1.9.14-9.fc9.x86_64 requires /bin/sh charis-fonts-4.100-5.fc9.noarch requires /bin/sh check-0.9.5-2.fc9.1.i386 requires /bin/sh check-0.9.5-2.fc9.1.i386 requires /sbin/ldconfig check-0.9.5-2.fc9.1.i386 requires /sbin/install-info check-0.9.5-2.fc9.1.x86_64 requires /bin/sh check-0.9.5-2.fc9.1.x86_64 requires /sbin/ldconfig check-0.9.5-2.fc9.1.x86_64 requires /sbin/install-info checkgmail-1.13-3.fc9.noarch requires /usr/bin/perl checkstyle-4.1-4jpp.3.fc9.noarch requires /bin/sh checkstyle-4.1-4jpp.3.fc9.noarch requires /usr/bin/perl checkstyle-optional-4.1-4jpp.3.fc9.noarch requires /bin/sh cheese-2.23.2-1.fc10.x86_64 requires /bin/sh cheese-2.23.2-1.fc10.x86_64 requires /bin/sh chemical-mime-data-0.1.94-3.fc8.noarch requires /bin/sh chemtool-1.6.11-3.fc9.x86_64 requires /bin/sh chess-1.0-14.fc10.x86_64 requires /bin/sh chess-1.0-14.fc10.x86_64 requires /usr/share/fonts/bitstream-vera/Vera.ttf childsplay-0.90.2-1.fc9.noarch requires /bin/sh childsplay-0.90.2-1.fc9.noarch requires /usr/bin/env childsplay-0.90.2-1.fc9.noarch requires /usr/bin/python chkrootkit-0.48-7.fc9.x86_64 requires /usr/bin/consolehelper chkrootkit-0.48-7.fc9.x86_64 requires /bin/sh chmlib-0.39-7.fc9.i386 requires /sbin/ldconfig chmlib-0.39-7.fc9.x86_64 requires /sbin/ldconfig chmsee-1.0.0-2.36.fc9.x86_64 requires /bin/sh cinepaint-0.22.1-7.fc9.x86_64 requires /bin/sh cinepaint-0.22.1-7.fc9.x86_64 requires /bin/sh cinepaint-devel-0.22.1-7.fc9.i386 requires /bin/sh cinepaint-devel-0.22.1-7.fc9.x86_64 requires /bin/sh cinepaint-libs-0.22.1-7.fc9.i386 requires /usr/bin/env cinepaint-libs-0.22.1-7.fc9.i386 requires /sbin/ldconfig cinepaint-libs-0.22.1-7.fc9.x86_64 requires /sbin/ldconfig cinepaint-libs-0.22.1-7.fc9.x86_64 requires /usr/bin/env cjkunifonts-ukai-0.1.20060928-4.fc8.noarch requires /bin/sh cjkunifonts-uming-0.1.20060928-4.fc8.noarch requires /bin/sh clamav-devel-0.93-1.fc9.i386 requires /bin/bash clamav-devel-0.93-1.fc9.i386 requires /usr/lib/pkgconfig clamav-devel-0.93-1.fc9.i386 requires /bin/sh clamav-devel-0.93-1.fc9.x86_64 requires /usr/lib64/pkgconfig clamav-devel-0.93-1.fc9.x86_64 requires /bin/bash clamav-devel-0.93-1.fc9.x86_64 requires /bin/sh clamav-filesystem-0.93-1.fc9.x86_64 requires /bin/sh clamav-lib-0.93-1.fc9.i386 requires /sbin/ldconfig clamav-lib-0.93-1.fc9.x86_64 requires /sbin/ldconfig clamav-milter-core-0.93-1.fc9.x86_64 requires /bin/sh clamav-milter-sysv-0.93-1.fc9.x86_64 requires /bin/sh clamav-milter-sysv-0.93-1.fc9.x86_64 requires /etc/rc.d/init.d clamav-milter-sysv-0.93-1.fc9.x86_64 requires /bin/sh clamav-server-0.93-1.fc9.x86_64 requires /bin/bash clamav-server-sysv-0.93-1.fc9.x86_64 requires /etc/rc.d/init.d clamav-update-0.93-1.fc9.x86_64 requires /bin/sh clamav-update-0.93-1.fc9.x86_64 requires /etc/cron.d clamav-update-0.93-1.fc9.x86_64 requires /bin/chown clamav-update-0.93-1.fc9.x86_64 requires /bin/bash clamav-update-0.93-1.fc9.x86_64 requires /bin/chmod clanbomber-1.05-8.fc9.x86_64 requires /bin/sh classads-1.0-1.fc9.i386 requires /sbin/ldconfig classads-1.0-1.fc9.x86_64 requires /sbin/ldconfig classpathx-jaf-1.0-11jpp.1.fc9.x86_64 requires /bin/sh classpathx-jaf-1.0-11jpp.1.fc9.x86_64 requires /usr/sbin/update-alternatives classpathx-jaf-1.0-11jpp.1.fc9.x86_64 requires /bin/sh classpathx-jaf-javadoc-1.0-11jpp.1.fc9.x86_64 requires /bin/rm classpathx-jaf-javadoc-1.0-11jpp.1.fc9.x86_64 requires /bin/ln classpathx-mail-1.1.1-5jpp.3.x86_64 requires /bin/sh classpathx-mail-1.1.1-5jpp.3.x86_64 requires /usr/sbin/update-alternatives classpathx-mail-1.1.1-5jpp.3.x86_64 requires /bin/sh classpathx-mail-javadoc-1.1.1-5jpp.3.x86_64 requires /bin/sh classpathx-mail-javadoc-1.1.1-5jpp.3.x86_64 requires /bin/ln classpathx-mail-javadoc-1.1.1-5jpp.3.x86_64 requires /bin/rm cleanfeed-0.95.7b-21.1.1.noarch requires /usr/bin/perl climm-0.6.2-1.fc9.x86_64 requires /bin/sh clips-libs-6.24-25.fc9.i386 requires /sbin/ldconfig clips-libs-6.24-25.fc9.x86_64 requires /sbin/ldconfig clipsmm-0.0.7-4.fc9.i386 requires /sbin/ldconfig clipsmm-0.0.7-4.fc9.x86_64 requires /sbin/ldconfig cln-1.2.2-1.fc10.i386 requires /sbin/ldconfig cln-1.2.2-1.fc10.i386 requires /sbin/install-info cln-1.2.2-1.fc10.x86_64 requires /sbin/ldconfig cln-1.2.2-1.fc10.x86_64 requires /sbin/install-info cln-devel-1.2.2-1.fc10.i386 requires /bin/sh cln-devel-1.2.2-1.fc10.x86_64 requires /bin/sh clonekeen-0.8.3-4.fc9.x86_64 requires /bin/sh clonekeen-0.8.3-4.fc9.x86_64 requires /bin/bash cloudy-libs-07.02.01-4.fc9.i386 requires /sbin/ldconfig cloudy-libs-07.02.01-4.fc9.x86_64 requires /sbin/ldconfig clusterssh-3.22-1.fc9.noarch requires /bin/sh clusterssh-3.22-1.fc9.noarch requires /usr/bin/perl clutter-0.6.0-1.fc9.i386 requires /sbin/ldconfig clutter-0.6.0-1.fc9.x86_64 requires /sbin/ldconfig clutter-gst-0.6.1-1.fc9.i386 requires /sbin/ldconfig clutter-gst-0.6.1-1.fc9.x86_64 requires /sbin/ldconfig clutter-gtk-0.6.0-1.fc9.i386 requires /sbin/ldconfig clutter-gtk-0.6.0-1.fc9.x86_64 requires /sbin/ldconfig cmake-gui-2.6.0-1.fc10.x86_64 requires /bin/sh cman-2.0.60-6.fc10.i386 requires /bin/sh cman-2.0.60-6.fc10.i386 requires /usr/bin/python cman-2.0.60-6.fc10.i386 requires /bin/bash cman-2.0.60-6.fc10.i386 requires /usr/bin/perl cman-2.0.60-6.fc10.i386 requires /sbin/chkconfig cman-2.0.60-6.fc10.x86_64 requires /bin/sh cman-2.0.60-6.fc10.x86_64 requires /usr/bin/python cman-2.0.60-6.fc10.x86_64 requires /bin/bash cman-2.0.60-6.fc10.x86_64 requires /usr/bin/perl cman-2.0.60-6.fc10.x86_64 requires /sbin/chkconfig cmigemo-1.3-0.6.c_MIT.fc9.2.i386 requires /sbin/ldconfig cmigemo-1.3-0.6.c_MIT.fc9.2.x86_64 requires /sbin/ldconfig cobbler-0.8.2-1.fc9.noarch requires /bin/sh cobbler-0.8.2-1.fc9.noarch requires /sbin/chkconfig cobbler-0.8.2-1.fc9.noarch requires /sbin/service coco-coq-0.1-3.fc8.noarch requires /bin/sh coco-coq-0.1-3.fc8.noarch requires /bin/bash coda-backup-6.9.3-1.fc10.x86_64 requires /usr/bin/perl coda-backup-6.9.3-1.fc10.x86_64 requires /bin/sh coda-client-6.9.3-1.fc10.x86_64 requires /bin/sh coda-client-6.9.3-1.fc10.x86_64 requires /usr/bin/python coda-client-6.9.3-1.fc10.x86_64 requires /usr/bin/perl coda-client-6.9.3-1.fc10.x86_64 requires /bin/sh coda-server-6.9.3-1.fc10.x86_64 requires /bin/sh coda-server-6.9.3-1.fc10.x86_64 requires /bin/sh codeblocks-8.02-1.fc9.x86_64 requires /bin/sh codeblocks-contrib-libs-8.02-1.fc9.i386 requires /sbin/ldconfig codeblocks-contrib-libs-8.02-1.fc9.x86_64 requires /sbin/ldconfig codeblocks-libs-8.02-1.fc9.i386 requires /sbin/ldconfig codeblocks-libs-8.02-1.fc9.x86_64 requires /sbin/ldconfig codeina-0.10.1-8.fc9.noarch requires /usr/bin/env codeina-0.10.1-8.fc9.noarch requires /bin/sh cogito-0.18.2-2.fc7.noarch requires /bin/bash cogito-0.18.2-2.fc7.noarch requires /usr/bin/env cohoba-0.0.4-5.fc7.noarch requires /bin/sh cohoba-0.0.4-5.fc7.noarch requires /usr/bin/env coldet-1.2-4.fc9.i386 requires /sbin/ldconfig coldet-1.2-4.fc9.x86_64 requires /sbin/ldconfig collectd-4.3.2-9.fc10.x86_64 requires /bin/sh collectd-4.3.2-9.fc10.x86_64 requires /bin/bash colordiff-1.0.7-2.fc9.noarch requires /usr/bin/perl colordiff-1.0.7-2.fc9.noarch requires /bin/sh comedilib-0.8.1-1.fc10.i386 requires /bin/sh comedilib-0.8.1-1.fc10.i386 requires /sbin/ldconfig comedilib-0.8.1-1.fc10.x86_64 requires /sbin/ldconfig comedilib-0.8.1-1.fc10.x86_64 requires /bin/sh comix-3.6.4-6.fc9.noarch requires /bin/sh comix-3.6.4-6.fc9.noarch requires /usr/bin/env comix-3.6.4-6.fc9.noarch requires /usr/bin/jpegtran commoncpp2-1.6.1-1.fc9.i386 requires /sbin/ldconfig commoncpp2-1.6.1-1.fc9.x86_64 requires /sbin/ldconfig commoncpp2-devel-1.6.1-1.fc9.i386 requires /bin/sh commoncpp2-devel-1.6.1-1.fc9.i386 requires /sbin/install-info commoncpp2-devel-1.6.1-1.fc9.i386 requires /bin/sh commoncpp2-devel-1.6.1-1.fc9.x86_64 requires /bin/sh commoncpp2-devel-1.6.1-1.fc9.x86_64 requires /sbin/install-info commoncpp2-devel-1.6.1-1.fc9.x86_64 requires /bin/sh compat-db-4.5.20-5.fc9.x86_64 requires /sbin/ldconfig compat-erlang-R10B-11.9.fc9.x86_64 requires /bin/sh compat-erlang-R10B-11.9.fc9.x86_64 requires /bin/sh compat-expat1-1.95.8-4.i386 requires /sbin/ldconfig compat-expat1-1.95.8-4.x86_64 requires /sbin/ldconfig compat-flex-2.5.4a-4.fc9.x86_64 requires /bin/sh compat-flex-2.5.4a-4.fc9.x86_64 requires /sbin/install-info compat-gcc-34-g77-3.4.6-9.x86_64 requires /bin/sh compat-gcc-34-g77-3.4.6-9.x86_64 requires /sbin/install-info compat-guichan05-0.5.0-8.fc9.i386 requires /sbin/ldconfig compat-guichan05-0.5.0-8.fc9.x86_64 requires /sbin/ldconfig compat-guile-16-1.6.7-8.fc9.i386 requires /sbin/ldconfig compat-guile-16-1.6.7-8.fc9.i386 requires /bin/sh compat-guile-16-1.6.7-8.fc9.x86_64 requires /sbin/ldconfig compat-guile-16-1.6.7-8.fc9.x86_64 requires /bin/sh compat-guile-16-devel-1.6.7-8.fc9.i386 requires /usr/bin/guile-1.6 compat-guile-16-devel-1.6.7-8.fc9.i386 requires /bin/sh compat-guile-16-devel-1.6.7-8.fc9.x86_64 requires /usr/bin/guile-1.6 compat-guile-16-devel-1.6.7-8.fc9.x86_64 requires /bin/sh compat-libf2c-34-3.4.6-9.i386 requires /sbin/ldconfig compat-libf2c-34-3.4.6-9.x86_64 requires /sbin/ldconfig compat-libgfortran-41-4.1.2-36.i386 requires /sbin/ldconfig compat-libgfortran-41-4.1.2-36.x86_64 requires /sbin/ldconfig compat-libosip2-2.2.2-16.fc9.i386 requires /sbin/ldconfig compat-libosip2-2.2.2-16.fc9.x86_64 requires /sbin/ldconfig compat-libstdc++-296-2.96-140.i386 requires /sbin/ldconfig compat-libstdc++-33-3.2.3-63.i386 requires /sbin/ldconfig compat-libstdc++-33-3.2.3-63.x86_64 requires /sbin/ldconfig compat-wxGTK26-2.6.4-2.i386 requires /sbin/ldconfig compat-wxGTK26-2.6.4-2.x86_64 requires /sbin/ldconfig compat-wxGTK26-devel-2.6.4-2.i386 requires /bin/sh compat-wxGTK26-devel-2.6.4-2.x86_64 requires /bin/sh compface-1.5.2-7.i386 requires /sbin/ldconfig compface-1.5.2-7.x86_64 requires /sbin/ldconfig compiz-0.7.2-4.fc10.i386 requires /sbin/ldconfig compiz-0.7.2-4.fc10.x86_64 requires /sbin/ldconfig compiz-bcop-0.7.2-1.fc9.noarch requires /bin/bash compiz-fusion-extras-gnome-0.7.2-2.fc9.x86_64 requires /bin/sh compiz-fusion-gnome-0.7.2-2.fc9.x86_64 requires /bin/sh compiz-gnome-0.7.2-4.fc10.x86_64 requires /bin/sh compiz-kde-0.7.2-4.fc10.x86_64 requires /bin/sh compiz-kde-0.7.2-4.fc10.x86_64 requires /bin/sh compiz-manager-0.6.0-7.fc9.noarch requires /bin/sh concurrent-1.3.4-8jpp.1.fc9.x86_64 requires /bin/sh condor-7.0.0-8.fc9.x86_64 requires /bin/sh condor-7.0.0-8.fc9.x86_64 requires /usr/bin/env condor-7.0.0-8.fc9.x86_64 requires /sbin/service condor-7.0.0-8.fc9.x86_64 requires /bin/bash condor-7.0.0-8.fc9.x86_64 requires /bin/sh condor-7.0.0-8.fc9.x86_64 requires /usr/bin/perl condor-7.0.0-8.fc9.x86_64 requires /sbin/chkconfig conduit-0.3.8-1.fc9.noarch requires /bin/sh conduit-0.3.8-1.fc9.noarch requires /bin/bash conduit-0.3.8-1.fc9.noarch requires /usr/bin/env conduit-0.3.8-1.fc9.noarch requires /usr/bin/python cone-0.74-3.fc9.x86_64 requires /bin/sh cone-0.74-3.fc9.x86_64 requires /usr/bin/perl cone-0.74-3.fc9.x86_64 requires /bin/sh cone-0.74-3.fc9.x86_64 requires /usr/bin/perl conexus-0.5.3-4.fc9.i386 requires /sbin/ldconfig conexus-0.5.3-4.fc9.x86_64 requires /sbin/ldconfig conexusmm-0.5.0-3.fc7.i386 requires /sbin/ldconfig conexusmm-0.5.0-3.fc7.x86_64 requires /sbin/ldconfig conglomerate-0.9.1-5.fc9.x86_64 requires /bin/sh conman-0.2.1-1.fc10.x86_64 requires /bin/sh conman-0.2.1-1.fc10.x86_64 requires /sbin/chkconfig conman-0.2.1-1.fc10.x86_64 requires /usr/bin/env conman-0.2.1-1.fc10.x86_64 requires /bin/sh conman-0.2.1-1.fc10.x86_64 requires /sbin/service conman-0.2.1-1.fc10.x86_64 requires /usr/bin/expect conmux-0.0-7.493svn.fc10.noarch requires /bin/sh conmux-0.0-7.493svn.fc10.noarch requires /sbin/service conmux-0.0-7.493svn.fc10.noarch requires /usr/bin/expect conmux-0.0-7.493svn.fc10.noarch requires /usr/bin/perl conmux-0.0-7.493svn.fc10.noarch requires /bin/sh conmux-0.0-7.493svn.fc10.noarch requires /sbin/chkconfig conmux-client-0.0-7.493svn.fc10.noarch requires /usr/bin/perl conserver-8.1.16-5.fc9.x86_64 requires /sbin/chkconfig conserver-8.1.16-5.fc9.x86_64 requires /bin/sh conserver-8.1.16-5.fc9.x86_64 requires /bin/sh conserver-8.1.16-5.fc9.x86_64 requires /sbin/service conserver-client-8.1.16-5.fc9.x86_64 requires /bin/sh contacts-0.8-3.fc10.x86_64 requires /bin/sh 1:control-center-2.23.1-3.fc10.i386 requires /bin/sh 1:control-center-2.23.1-3.fc10.i386 requires /bin/sh 1:control-center-2.23.1-3.fc10.x86_64 requires /bin/sh 1:control-center-2.23.1-3.fc10.x86_64 requires /bin/sh convmv-1.12-1.fc9.noarch requires /usr/bin/perl cook-2.30-2.fc9.x86_64 requires /usr/bin/perl coolkey-1.1.0-6.fc9.i386 requires /bin/sh coolkey-1.1.0-6.fc9.x86_64 requires /bin/sh coreutils-6.11-2.fc10.x86_64 requires /bin/sh coreutils-6.11-2.fc10.x86_64 requires /sbin/install-info cowbell-0.2.7.1-10.fc10.x86_64 requires /bin/sh cowbell-0.2.7.1-10.fc10.x86_64 requires /bin/sh cowsay-3.03-4.fc8.noarch requires /usr/bin/perl cowsay-3.03-4.fc8.noarch requires /bin/sh cpan2rpm-2.028-2.fc8.1.noarch requires /usr/bin/perl cpanspec-1.75-1.fc10.noarch requires /usr/bin/repoquery cpanspec-1.75-1.fc10.noarch requires /usr/bin/perl cpanspec-1.75-1.fc10.noarch requires /bin/sh cpanspec-1.75-1.fc10.noarch requires /usr/bin/curl cpio-2.9-7.fc9.x86_64 requires /bin/sh cpio-2.9-7.fc9.x86_64 requires /sbin/install-info cpl-4.1.0-1.fc9.i386 requires /sbin/ldconfig cpl-4.1.0-1.fc9.x86_64 requires /sbin/ldconfig cpp-4.3.0-8.x86_64 requires /bin/sh cpp-4.3.0-8.x86_64 requires /sbin/install-info cppunit-1.12.0-5.fc9.i386 requires /sbin/ldconfig cppunit-1.12.0-5.fc9.x86_64 requires /sbin/ldconfig cppunit-devel-1.12.0-5.fc9.i386 requires /bin/sh cppunit-devel-1.12.0-5.fc9.x86_64 requires /bin/sh 1:cpufreq-utils-002-1.1.42.fc9.i386 requires /sbin/ldconfig 1:cpufreq-utils-002-1.1.42.fc9.x86_64 requires /sbin/ldconfig 1:cpuspeed-1.2.1-5.fc9.x86_64 requires /bin/sh 1:cpuspeed-1.2.1-5.fc9.x86_64 requires /sbin/chkconfig 1:cpuspeed-1.2.1-5.fc9.x86_64 requires /bin/sh 1:cpuspeed-1.2.1-5.fc9.x86_64 requires /sbin/service crack-5.0a-8.fc9.x86_64 requires /bin/sh crack-5.0a-8.fc9.x86_64 requires /bin/bash crack-5.0a-8.fc9.x86_64 requires /bin/sh crack-attack-1.1.14-13.fc9.x86_64 requires /bin/sh cracklib-2.8.12-2.i386 requires /sbin/ldconfig cracklib-2.8.12-2.i386 requires /sbin/ldconfig cracklib-2.8.12-2.i386 requires /bin/sh cracklib-2.8.12-2.x86_64 requires /sbin/ldconfig cracklib-2.8.12-2.x86_64 requires /sbin/ldconfig cracklib-2.8.12-2.x86_64 requires /bin/sh createrepo-0.9.5-2.fc9.noarch requires /usr/bin/python createrepo-0.9.5-2.fc9.noarch requires /bin/sh createrepo-0.9.5-2.fc9.noarch requires /usr/bin/env crm114-0-1.7.20070810.fc9.x86_64 requires /usr/bin/crm cronie-1.0-5.fc9.x86_64 requires /bin/sh cronie-1.0-5.fc9.x86_64 requires /sbin/service cronie-1.0-5.fc9.x86_64 requires /bin/bash cronie-1.0-5.fc9.x86_64 requires /bin/sh cronie-1.0-5.fc9.x86_64 requires /sbin/chkconfig cronolog-1.6.2-7.fc9.x86_64 requires /bin/sh cronolog-1.6.2-7.fc9.x86_64 requires /usr/bin/perl cronolog-1.6.2-7.fc9.x86_64 requires /sbin/install-info crontabs-1.10-21.fc10.noarch requires /bin/bash crossfire-1.10.0-4.fc9.x86_64 requires /bin/sh crossfire-1.10.0-4.fc9.x86_64 requires /sbin/service crossfire-1.10.0-4.fc9.x86_64 requires /bin/bash crossfire-1.10.0-4.fc9.x86_64 requires /bin/sh crossfire-1.10.0-4.fc9.x86_64 requires /usr/bin/perl crossfire-1.10.0-4.fc9.x86_64 requires /sbin/chkconfig crossfire-client-1.10.0-4.fc9.x86_64 requires /bin/sh crossfire-maps-1.10.0-3.fc8.noarch requires /bin/bash crossfire-maps-1.10.0-3.fc8.noarch requires /usr/bin/perl crossfire-selinux-1.10.0-4.fc9.x86_64 requires /usr/sbin/semodule crossfire-selinux-1.10.0-4.fc9.x86_64 requires /sbin/fixfiles crossfire-selinux-1.10.0-4.fc9.x86_64 requires /bin/sh crossfire-selinux-1.10.0-4.fc9.x86_64 requires /usr/sbin/semanage crossfire-selinux-1.10.0-4.fc9.x86_64 requires /sbin/service crossvc-1.5.2-4.fc9.x86_64 requires /bin/sh cryptix-3.2.0-10jpp.2.x86_64 requires /bin/sh cryptix-asn1-20011119-8jpp.3.x86_64 requires /bin/sh cryptix-javadoc-3.2.0-10jpp.2.x86_64 requires /bin/sh cryptix-javadoc-3.2.0-10jpp.2.x86_64 requires /bin/rm cryptix-javadoc-3.2.0-10jpp.2.x86_64 requires /bin/ln crypto-utils-2.3-10.x86_64 requires /bin/bash cryptsetup-luks-1.0.6-2.fc9.i386 requires /sbin/ldconfig cryptsetup-luks-1.0.6-2.fc9.x86_64 requires /sbin/ldconfig crystal-1.0.5-3.fc9.x86_64 requires /sbin/ldconfig crystal-stacker-1.5-6.fc9.x86_64 requires /bin/sh crystal-stacker-theme-editor-1.5-6.fc9.x86_64 requires /bin/sh crystalspace-1.2-4.fc9.i386 requires /sbin/ldconfig crystalspace-1.2-4.fc9.x86_64 requires /sbin/ldconfig crystalspace-devel-1.2-4.fc9.i386 requires /usr/bin/env crystalspace-devel-1.2-4.fc9.i386 requires /bin/sh crystalspace-devel-1.2-4.fc9.x86_64 requires /usr/bin/env crystalspace-devel-1.2-4.fc9.x86_64 requires /bin/sh crystalspace-utils-1.2-4.fc9.x86_64 requires /bin/sh crystalsvg-icon-theme-4.0.72-1.fc10.x86_64 requires /bin/sh cscope-15.6-1.fc9.x86_64 requires /bin/sh csmash-0.6.6-18.x86_64 requires /bin/sh csound-5.03.0-16.fc9.i386 requires /sbin/ldconfig csound-5.03.0-16.fc9.x86_64 requires /sbin/ldconfig csound-java-5.03.0-16.fc9.x86_64 requires /bin/sh csound-java-5.03.0-16.fc9.x86_64 requires /sbin/ldconfig csound-tk-5.03.0-16.fc9.x86_64 requires /usr/bin/wish csound-tk-5.03.0-16.fc9.x86_64 requires /usr/bin/perl ctapi-common-1.1-4.fc9.i386 requires /bin/sh ctapi-common-1.1-4.fc9.x86_64 requires /bin/sh ctapi-cyberjack-3.0.5-2.fc9.i386 requires /sbin/ldconfig ctapi-cyberjack-3.0.5-2.fc9.i386 requires /usr/lib/ctapi ctapi-cyberjack-3.0.5-2.fc9.x86_64 requires /sbin/ldconfig ctapi-cyberjack-3.0.5-2.fc9.x86_64 requires /usr/lib64/ctapi ctapi-cyberjack-pcsc-3.0.5-2.fc9.x86_64 requires /bin/sh ctapi-cyberjack-tools-3.0.5-2.fc9.x86_64 requires /bin/sh cuetools-1.4.0-0.2.svn305.fc10.i386 requires /sbin/ldconfig cuetools-1.4.0-0.2.svn305.fc10.i386 requires /bin/sh cuetools-1.4.0-0.2.svn305.fc10.x86_64 requires /sbin/ldconfig cuetools-1.4.0-0.2.svn305.fc10.x86_64 requires /bin/sh culmus-fonts-0.101-4.fc8.noarch requires /bin/sh 1:cups-1.3.7-2.fc10.x86_64 requires /bin/sh 1:cups-1.3.7-2.fc10.x86_64 requires /usr/sbin/alternatives 1:cups-1.3.7-2.fc10.x86_64 requires /sbin/service 1:cups-1.3.7-2.fc10.x86_64 requires /bin/bash 1:cups-1.3.7-2.fc10.x86_64 requires /bin/sh 1:cups-1.3.7-2.fc10.x86_64 requires /usr/bin/perl 1:cups-1.3.7-2.fc10.x86_64 requires /sbin/chkconfig 1:cups-devel-1.3.7-2.fc10.i386 requires /bin/sh 1:cups-devel-1.3.7-2.fc10.x86_64 requires /bin/sh 1:cups-libs-1.3.7-2.fc10.i386 requires /sbin/ldconfig 1:cups-libs-1.3.7-2.fc10.x86_64 requires /sbin/ldconfig cups-pdf-2.4.7-1.fc9.x86_64 requires /bin/sh curry-0.9.11-4.fc9.x86_64 requires /bin/sh cvs-1.11.22-13.fc9.x86_64 requires /bin/sh cvs-1.11.22-13.fc9.x86_64 requires /sbin/install-info cvs-1.11.22-13.fc9.x86_64 requires /usr/bin/perl cvs-1.11.22-13.fc9.x86_64 requires /bin/sh cvs2cl-2.67-1.fc8.noarch requires /usr/bin/perl cvs2svn-2.1.1-1.fc10.noarch requires /usr/bin/python cvsplot-1.7.4-6.fc8.noarch requires /usr/bin/perl cvsutils-0.2.3-6.fc8.noarch requires /usr/bin/perl cvsutils-0.2.3-6.fc8.noarch requires /bin/sh cvsweb-3.0.6-3.fc6.noarch requires /usr/bin/perl cwiid-0.6.00-7.fc10.i386 requires /sbin/ldconfig cwiid-0.6.00-7.fc10.x86_64 requires /sbin/ldconfig cwrite-0.1.24-2.fc9.x86_64 requires /bin/sh cwrite-0.1.24-2.fc9.x86_64 requires /sbin/install-info cycle-0.3.1-4.fc7.noarch requires /usr/bin/env cyphesis-0.5.15-6.fc9.x86_64 requires /bin/sh cyphesis-0.5.15-6.fc9.x86_64 requires /sbin/service cyphesis-0.5.15-6.fc9.x86_64 requires /bin/sh cyphesis-0.5.15-6.fc9.x86_64 requires /sbin/chkconfig cyphesis-selinux-0.5.15-6.fc9.x86_64 requires /usr/sbin/semodule cyphesis-selinux-0.5.15-6.fc9.x86_64 requires /sbin/fixfiles cyphesis-selinux-0.5.15-6.fc9.x86_64 requires /bin/sh cyphesis-selinux-0.5.15-6.fc9.x86_64 requires /usr/sbin/semanage cyphesis-selinux-0.5.15-6.fc9.x86_64 requires /usr/sbin/setsebool cyphesis-selinux-0.5.15-6.fc9.x86_64 requires /sbin/service cyrus-imapd-2.3.11-1.fc9.x86_64 requires /bin/sh cyrus-imapd-2.3.11-1.fc9.x86_64 requires /sbin/service cyrus-imapd-2.3.11-1.fc9.x86_64 requires /usr/bin/perl cyrus-imapd-2.3.11-1.fc9.x86_64 requires /bin/sh cyrus-imapd-2.3.11-1.fc9.x86_64 requires /sbin/chkconfig cyrus-imapd-perl-2.3.11-1.fc9.x86_64 requires /usr/bin/perl cyrus-imapd-utils-2.3.11-1.fc9.x86_64 requires /usr/sbin/userdel cyrus-imapd-utils-2.3.11-1.fc9.x86_64 requires /bin/sh cyrus-imapd-utils-2.3.11-1.fc9.x86_64 requires /usr/sbin/groupadd cyrus-imapd-utils-2.3.11-1.fc9.x86_64 requires /bin/sh cyrus-imapd-utils-2.3.11-1.fc9.x86_64 requires /usr/sbin/groupdel cyrus-imapd-utils-2.3.11-1.fc9.x86_64 requires /usr/sbin/useradd cyrus-sasl-2.1.22-13.fc9.x86_64 requires /bin/sh cyrus-sasl-2.1.22-13.fc9.x86_64 requires /sbin/service cyrus-sasl-2.1.22-13.fc9.x86_64 requires /bin/bash cyrus-sasl-lib-2.1.22-13.fc9.i386 requires /sbin/ldconfig cyrus-sasl-lib-2.1.22-13.fc9.x86_64 requires /sbin/ldconfig d-feet-0.1.8-1.fc9.noarch requires /bin/sh d-feet-0.1.8-1.fc9.noarch requires /usr/bin/python d4x-2.5.7.1-8.fc9.x86_64 requires /bin/sh dap-freeform_handler-3.7.7-2.fc9.i386 requires /sbin/ldconfig dap-freeform_handler-3.7.7-2.fc9.i386 requires /bin/sh dap-freeform_handler-3.7.7-2.fc9.x86_64 requires /sbin/ldconfig dap-freeform_handler-3.7.7-2.fc9.x86_64 requires /bin/sh dap-hdf4_handler-3.7.7-3.fc9.x86_64 requires /bin/sh dap-netcdf_handler-3.7.8-3.fc9.i386 requires /sbin/ldconfig dap-netcdf_handler-3.7.8-3.fc9.i386 requires /bin/sh dap-netcdf_handler-3.7.8-3.fc9.x86_64 requires /sbin/ldconfig dap-netcdf_handler-3.7.8-3.fc9.x86_64 requires /bin/sh dap-server-3.8.4-3.fc9.x86_64 requires /bin/sh dap-server-cgi-3.8.4-3.fc9.x86_64 requires /usr/bin/perl darcs-1.0.9-11.fc9.x86_64 requires /bin/sh darcs-server-1.0.9-11.fc9.x86_64 requires /usr/bin/xsltproc darcs-server-1.0.9-11.fc9.x86_64 requires /usr/bin/perl dasher-4.9.0-1.fc10.x86_64 requires /bin/sh dates-0.4.6-1.fc10.x86_64 requires /bin/sh dates-0.4.6-1.fc10.x86_64 requires /sbin/ldconfig dayplanner-0.8.1-3.fc9.noarch requires /bin/sh dayplanner-0.8.1-3.fc9.noarch requires /usr/bin/perl db4-4.6.21-5.fc9.i386 requires /sbin/ldconfig db4-4.6.21-5.fc9.x86_64 requires /sbin/ldconfig db4-java-4.6.21-5.fc9.x86_64 requires /sbin/ldconfig db4-tcl-4.6.21-5.fc9.x86_64 requires /sbin/ldconfig db4o-6.1-4.fc9.x86_64 requires /bin/sh 1:dbh-1.0.24-6.fc9.i386 requires /sbin/ldconfig 1:dbh-1.0.24-6.fc9.x86_64 requires /sbin/ldconfig dblatex-0.2.8-2.fc9.1.noarch requires /usr/bin/texhash dblatex-0.2.8-2.fc9.1.noarch requires /usr/bin/env dbmail-2.2.9-1.fc10.x86_64 requires /bin/sh dbmail-2.2.9-1.fc10.x86_64 requires /bin/bash dbmail-2.2.9-1.fc10.x86_64 requires /bin/sh dbus-1.2.1-3.fc10.x86_64 requires /bin/sh dbus-1.2.1-3.fc10.x86_64 requires /usr/sbin/useradd dbus-1.2.1-3.fc10.x86_64 requires /bin/sh dbus-glib-0.74-6.fc9.i386 requires /sbin/ldconfig dbus-glib-0.74-6.fc9.x86_64 requires /sbin/ldconfig dbus-libs-1.2.1-3.fc10.i386 requires /sbin/ldconfig dbus-libs-1.2.1-3.fc10.x86_64 requires /sbin/ldconfig dbus-qt-0.70-4.fc9.i386 requires /sbin/ldconfig dbus-qt-0.70-4.fc9.x86_64 requires /sbin/ldconfig dbus-qt3-0.8-5.fc9.i386 requires /sbin/ldconfig dbus-qt3-0.8-5.fc9.x86_64 requires /sbin/ldconfig dbus-x11-1.2.1-3.fc10.x86_64 requires /bin/sh dbxml-2.3.10-12.fc9.i386 requires /sbin/ldconfig dbxml-2.3.10-12.fc9.x86_64 requires /sbin/ldconfig dclib-0.3.11-4.fc9.i386 requires /sbin/ldconfig dclib-0.3.11-4.fc9.x86_64 requires /sbin/ldconfig dd2-0.2.2-3.fc9.x86_64 requires /bin/sh dd_rescue-1.14-7.fc9.x86_64 requires /bin/bash ddclient-3.7.3-1.fc9.noarch requires /bin/sh ddclient-3.7.3-1.fc9.noarch requires /usr/bin/perl ddclient-3.7.3-1.fc9.noarch requires /sbin/chkconfig ddclient-3.7.3-1.fc9.noarch requires /usr/sbin/groupadd ddclient-3.7.3-1.fc9.noarch requires /usr/sbin/useradd ddclient-3.7.3-1.fc9.noarch requires /bin/sh ddd-3.3.11-18.fc9.x86_64 requires /bin/sh ddd-3.3.11-18.fc9.x86_64 requires /sbin/install-info ddrescue-1.8-2.fc9.x86_64 requires /bin/sh ddrescue-1.8-2.fc9.x86_64 requires /sbin/install-info ddskk-12.2.0-11.fc7.noarch requires /bin/sh ddskk-12.2.0-11.fc7.noarch requires /sbin/install-info debootstrap-1.0.8-1.fc9.noarch requires /bin/sh 1:dejagnu-1.4.4-11.fc9.noarch requires /bin/sh 1:dejagnu-1.4.4-11.fc9.noarch requires /bin/sh dejavu-fonts-2.24-3.fc9.noarch requires /bin/sh dejavu-fonts-experimental-2.24-3.fc9.noarch requires /bin/sh dejavu-lgc-fonts-2.24-3.fc9.noarch requires /bin/sh deltarpm-3.4-10.fc9.x86_64 requires /usr/bin/perl deluge-0.5.9.0-1.fc10.x86_64 requires /bin/sh deluge-0.5.9.0-1.fc10.x86_64 requires /usr/bin/env deluge-0.5.9.0-1.fc10.x86_64 requires /usr/bin/python deluge-0.5.9.0-1.fc10.x86_64 requires /bin/bash deluge-0.5.9.0-1.fc10.x86_64 requires /bin/sh denyhosts-2.6-8.fc9.noarch requires /bin/sh denyhosts-2.6-8.fc9.noarch requires /bin/bash denyhosts-2.6-8.fc9.noarch requires /usr/bin/env denyhosts-2.6-8.fc9.noarch requires /bin/env denyhosts-2.6-8.fc9.noarch requires /bin/sh denyhosts-2.6-8.fc9.noarch requires /usr/bin/python deskbar-applet-2.23.2-1.fc10.x86_64 requires /bin/sh deskbar-applet-2.23.2-1.fc10.x86_64 requires /usr/bin/env desktop-data-model-1.2.4-1.fc10.i386 requires /sbin/ldconfig desktop-data-model-1.2.4-1.fc10.i386 requires /bin/sh desktop-data-model-1.2.4-1.fc10.x86_64 requires /bin/sh desktop-data-model-1.2.4-1.fc10.x86_64 requires /sbin/ldconfig desktop-file-utils-0.15-3.fc10.x86_64 requires /bin/sh dev86-0.16.17-9.fc9.x86_64 requires /bin/sh devhelp-0.19-4.fc9.i386 requires /bin/sh devhelp-0.19-4.fc9.x86_64 requires /bin/sh device-mapper-libs-1.02.24-11.fc9.i386 requires /sbin/ldconfig device-mapper-libs-1.02.24-11.fc9.x86_64 requires /sbin/ldconfig device-mapper-multipath-0.4.7-15.fc10.x86_64 requires /bin/sh device-mapper-multipath-0.4.7-15.fc10.x86_64 requires /bin/bash dgae-1.1-3.fc8.noarch requires /bin/sh dgae-1.1-3.fc8.noarch requires /bin/bash 12:dhclient-4.0.0-15.fc10.x86_64 requires /bin/bash 12:dhcp-4.0.0-15.fc10.x86_64 requires /bin/sh 12:dhcp-4.0.0-15.fc10.x86_64 requires /bin/sh dhcp-forwarder-0.7-14.fc9.x86_64 requires /bin/sh dhcp-forwarder-sysv-0.7-14.fc9.x86_64 requires /bin/sh dhcp-forwarder-sysv-0.7-14.fc9.x86_64 requires /bin/bash dhcp-forwarder-sysv-0.7-14.fc9.x86_64 requires /sbin/chkconfig dhcpv6-1.0.15-1.fc10.x86_64 requires /bin/sh dhcpv6-1.0.15-1.fc10.x86_64 requires /bin/sh 1:dia-0.96.1-6.fc10.x86_64 requires /bin/sh 1:dia-0.96.1-6.fc10.x86_64 requires /usr/bin/env dialog-1.1-5.20080316.fc10.i386 requires /sbin/ldconfig dialog-1.1-5.20080316.fc10.x86_64 requires /sbin/ldconfig dialog-devel-1.1-5.20080316.fc10.i386 requires /bin/sh dialog-devel-1.1-5.20080316.fc10.x86_64 requires /bin/sh dictd-1.10.11-2.x86_64 requires /bin/sh dictd-1.10.11-2.x86_64 requires /bin/sh diffutils-2.8.1-21.fc9.x86_64 requires /bin/sh diffutils-2.8.1-21.fc9.x86_64 requires /sbin/install-info digikam-0.9.4-0.1.beta4.fc10.i386 requires /bin/sh digikam-0.9.4-0.1.beta4.fc10.i386 requires /usr/bin/perl digikam-0.9.4-0.1.beta4.fc10.i386 requires /bin/sh digikam-0.9.4-0.1.beta4.fc10.x86_64 requires /bin/sh digikam-0.9.4-0.1.beta4.fc10.x86_64 requires /usr/bin/perl digikam-0.9.4-0.1.beta4.fc10.x86_64 requires /bin/sh dillo-0.8.6-7.fc9.x86_64 requires /usr/bin/perl dirac-0.9.1-2.fc9.x86_64 requires /usr/bin/perl dirac-libs-0.9.1-2.fc9.i386 requires /sbin/ldconfig dirac-libs-0.9.1-2.fc9.x86_64 requires /sbin/ldconfig dircproxy-1.2.0-0.7.beta2.fc9.x86_64 requires /bin/sh dircproxy-1.2.0-0.7.beta2.fc9.x86_64 requires /usr/bin/perl dircproxy-1.2.0-0.7.beta2.fc9.x86_64 requires /bin/sh directfb-1.0.0-4.fc9.i386 requires /sbin/ldconfig directfb-1.0.0-4.fc9.x86_64 requires /sbin/ldconfig directfb-devel-1.0.0-4.fc9.i386 requires /bin/sh directfb-devel-1.0.0-4.fc9.x86_64 requires /bin/sh dirmngr-1.0.1-2.fc9.x86_64 requires /bin/sh dirmngr-1.0.1-2.fc9.x86_64 requires /sbin/install-info dirvish-1.2.1-2.fc6.noarch requires /usr/bin/perl distcache-1.4.5-17.i386 requires /bin/sh distcache-1.4.5-17.i386 requires /sbin/service distcache-1.4.5-17.i386 requires /sbin/ldconfig distcache-1.4.5-17.i386 requires /bin/bash distcache-1.4.5-17.i386 requires /sbin/chkconfig distcache-1.4.5-17.x86_64 requires /bin/sh distcache-1.4.5-17.x86_64 requires /sbin/ldconfig distcache-1.4.5-17.x86_64 requires /bin/bash distcache-1.4.5-17.x86_64 requires /sbin/chkconfig distcache-1.4.5-17.x86_64 requires /sbin/service distcc-2.18.3-4.fc9.x86_64 requires /bin/sh distcc-server-2.18.3-4.fc9.x86_64 requires /sbin/chkconfig distcc-server-2.18.3-4.fc9.x86_64 requires /bin/sh distcc-server-2.18.3-4.fc9.x86_64 requires /bin/sh djvulibre-3.5.20-2.fc9.x86_64 requires /bin/sh djvulibre-3.5.20-2.fc9.x86_64 requires /sbin/ldconfig djvulibre-3.5.20-2.fc9.x86_64 requires /bin/bash djvulibre-3.5.20-2.fc9.x86_64 requires /bin/sh djvulibre-libs-3.5.20-2.fc9.i386 requires /sbin/ldconfig djvulibre-libs-3.5.20-2.fc9.x86_64 requires /sbin/ldconfig dkim-milter-2.5.1-5.fc9.x86_64 requires /bin/sh dkim-milter-2.5.1-5.fc9.x86_64 requires /sbin/service dkim-milter-2.5.1-5.fc9.x86_64 requires /bin/sh dkim-milter-2.5.1-5.fc9.x86_64 requires /bin/bash dkim-milter-2.5.1-5.fc9.x86_64 requires /sbin/chkconfig dkms-2.0.19-1.fc9.noarch requires /bin/sh dkms-2.0.19-1.fc9.noarch requires /bin/bash dkms-2.0.19-1.fc9.noarch requires /bin/sh dmraid-1.0.0.rc14-6.fc9.i386 requires /sbin/ldconfig dmraid-1.0.0.rc14-6.fc9.x86_64 requires /sbin/ldconfig dnsmasq-2.41-0.8.fc9.x86_64 requires /bin/sh dnsmasq-2.41-0.8.fc9.x86_64 requires /bin/sed dnsmasq-2.41-0.8.fc9.x86_64 requires /sbin/chkconfig dnsmasq-2.41-0.8.fc9.x86_64 requires /bin/grep dnsmasq-2.41-0.8.fc9.x86_64 requires /bin/sh dnsmasq-2.41-0.8.fc9.x86_64 requires /sbin/service dnssec-tools-1.3.2-2.fc9.x86_64 requires /usr/bin/perl dnssec-tools-libs-1.3.2-2.fc9.i386 requires /sbin/ldconfig dnssec-tools-libs-1.3.2-2.fc9.x86_64 requires /sbin/ldconfig dnssec-tools-libs-devel-1.3.2-2.fc9.i386 requires /bin/sh dnssec-tools-libs-devel-1.3.2-2.fc9.x86_64 requires /bin/sh docbook-dtds-1.0-36.fc10.noarch requires /bin/sh docbook-simple-1.1-3.fc9.noarch requires /bin/sh docbook-slides-3.4.0-3.fc9.noarch requires /bin/sh docbook-style-dsssl-1.79-5.fc9.noarch requires /bin/sh docbook-style-dsssl-1.79-5.fc9.noarch requires /usr/bin/perl docbook-style-xsl-1.73.2-9.fc9.noarch requires /bin/sh docbook-utils-0.6.14-13.fc9.noarch requires /usr/bin/perl docbook-utils-0.6.14-13.fc9.noarch requires /bin/sh docbook-utils-pdf-0.6.14-13.fc9.noarch requires /bin/sh docbook2X-0.8.8-3.fc9.x86_64 requires /bin/sh docbook2X-0.8.8-3.fc9.x86_64 requires /usr/bin/sgml2xml docbook2X-0.8.8-3.fc9.x86_64 requires /sbin/install-info docbook2X-0.8.8-3.fc9.x86_64 requires /usr/bin/perl docbook2X-0.8.8-3.fc9.x86_64 requires /bin/sh dogtail-0.6.90-1.381.fc9.noarch requires /bin/sh dogtail-0.6.90-1.381.fc9.noarch requires /usr/bin/python dom4j-demo-1.6.1-2jpp.3.fc8.noarch requires /bin/sh doodle-0.6.7-2.fc9.i386 requires /sbin/ldconfig doodle-0.6.7-2.fc9.x86_64 requires /sbin/ldconfig dot2tex-2.7.0-4.fc9.noarch requires /usr/bin/python dotconf-1.0.13-6.fc9.i386 requires /sbin/ldconfig dotconf-1.0.13-6.fc9.x86_64 requires /sbin/ldconfig dotconf-devel-1.0.13-6.fc9.i386 requires /bin/sh dotconf-devel-1.0.13-6.fc9.x86_64 requires /bin/sh doulos-fonts-4.100-1.fc9.noarch requires /bin/sh 1:dovecot-1.0.13-6.fc9.x86_64 requires /usr/sbin/userdel 1:dovecot-1.0.13-6.fc9.x86_64 requires /bin/mv 1:dovecot-1.0.13-6.fc9.x86_64 requires /usr/sbin/useradd 1:dovecot-1.0.13-6.fc9.x86_64 requires /bin/sh 1:dovecot-1.0.13-6.fc9.x86_64 requires /sbin/service 1:dovecot-1.0.13-6.fc9.x86_64 requires /bin/touch 1:dovecot-1.0.13-6.fc9.x86_64 requires /bin/bash 1:dovecot-1.0.13-6.fc9.x86_64 requires /bin/sh 1:dovecot-1.0.13-6.fc9.x86_64 requires /usr/sbin/groupdel 1:dovecot-1.0.13-6.fc9.x86_64 requires /sbin/chkconfig 1:dovecot-1.0.13-6.fc9.x86_64 requires /bin/rm drawtiming-0.6.2-3.fc9.x86_64 requires libWand.so.10()(64bit) drawtiming-0.6.2-3.fc9.x86_64 requires libMagick++.so.10()(64bit) drawtiming-0.6.2-3.fc9.x86_64 requires libMagick.so.10()(64bit) drgeo-1.1.0-12.fc9.x86_64 requires /bin/bash driconf-0.9.1-7.fc9.noarch requires /usr/bin/python driftnet-0.1.6-16.20040426cvs.fc9.x86_64 requires /usr/bin/consolehelper drivel-2.1.1-0.5.20071130svn.fc9.x86_64 requires /bin/sh dropbear-0.50-3.fc9.x86_64 requires /bin/sh dropbear-0.50-3.fc9.x86_64 requires /bin/bash dropbear-0.50-3.fc9.x86_64 requires /sbin/service 1:drpython-3.11.0-2.fc9.noarch requires /bin/bash 1:drpython-3.11.0-2.fc9.noarch requires /usr/bin/env 1:drpython-3.11.0-2.fc9.noarch requires /bin/sh 1:drpython-3.11.0-2.fc9.noarch requires /usr/bin/python ds9-5.1-4.fc9.x86_64 requires /bin/sh dstat-0.6.7-3.fc10.noarch requires /usr/bin/env dtdparser-1.21-4jpp.2.fc9.x86_64 requires /bin/sh duel3-0.1-0.5.20060225.fc9.x86_64 requires /bin/sh dumb-0.9.3-7.fc9.i386 requires /sbin/ldconfig dumb-0.9.3-7.fc9.x86_64 requires /sbin/ldconfig duplicity-0.4.11-1.fc10.x86_64 requires /usr/bin/python dvdauthor-0.6.14-5.fc9.x86_64 requires /bin/sh dvipdfm-0.13.2d-38.fc10.x86_64 requires /bin/sh dvipdfm-0.13.2d-38.fc10.x86_64 requires /bin/sh dvipdfm-0.13.2d-38.fc10.x86_64 requires /usr/bin/mktexlsr dvipdfmx-0-0.20.20071115cvs.fc9.x86_64 requires /bin/sh dvipdfmx-0-0.20.20071115cvs.fc9.x86_64 requires /usr/bin/mktexlsr dvipng-1.9-50.fc9.x86_64 requires /bin/sh dvipng-1.9-50.fc9.x86_64 requires /sbin/install-info dwarves-1.6-1.x86_64 requires /usr/bin/python dx-4.4.4-6.fc9.x86_64 requires libMagick.so.10()(64bit) dx-4.4.4-6.fc9.x86_64 requires /bin/sh dx-4.4.4-6.fc9.x86_64 requires libWand.so.10()(64bit) dx-libs-4.4.4-6.fc9.i386 requires /sbin/ldconfig dx-libs-4.4.4-6.fc9.i386 requires libWand.so.10 dx-libs-4.4.4-6.fc9.i386 requires libMagick.so.10 dx-libs-4.4.4-6.fc9.x86_64 requires libMagick.so.10()(64bit) dx-libs-4.4.4-6.fc9.x86_64 requires libWand.so.10()(64bit) dx-libs-4.4.4-6.fc9.x86_64 requires /sbin/ldconfig dxcc-20080225-4.fc9.noarch requires /usr/bin/perl dxcc-gui-20080225-4.fc9.noarch requires /bin/bash dxpc-3.9.1-0.3.b1.fc9.x86_64 requires /bin/bash dynamite-0.1-9.fc9.i386 requires /sbin/ldconfig dynamite-0.1-9.fc9.x86_64 requires /sbin/ldconfig e16-0.16.8.13-2.fc10.x86_64 requires /usr/bin/perl e16-0.16.8.13-2.fc10.x86_64 requires /bin/sh e16-epplets-0.10-3.fc10.i386 requires /sbin/ldconfig e16-epplets-0.10-3.fc10.x86_64 requires /sbin/ldconfig e16-themes-0.16.8.0.2-1.fc10.noarch requires /bin/sh e2fsprogs-1.40.9-2.fc10.x86_64 requires /bin/sh e2fsprogs-devel-1.40.9-2.fc10.i386 requires /bin/sh e2fsprogs-devel-1.40.9-2.fc10.i386 requires /sbin/install-info e2fsprogs-devel-1.40.9-2.fc10.i386 requires /bin/sh e2fsprogs-devel-1.40.9-2.fc10.x86_64 requires /bin/sh e2fsprogs-devel-1.40.9-2.fc10.x86_64 requires /sbin/install-info e2fsprogs-devel-1.40.9-2.fc10.x86_64 requires /bin/sh e2fsprogs-libs-1.40.9-2.fc10.i386 requires /sbin/ldconfig e2fsprogs-libs-1.40.9-2.fc10.x86_64 requires /sbin/ldconfig eb-4.3.2-1.fc9.i386 requires /sbin/ldconfig eb-4.3.2-1.fc9.i386 requires /usr/bin/perl eb-4.3.2-1.fc9.x86_64 requires /sbin/ldconfig eb-4.3.2-1.fc9.x86_64 requires /usr/bin/perl eblook-1.6.1-3.fc9.x86_64 requires /bin/sh ebtables-2.0.8-5.fc9.x86_64 requires /bin/sh ebtables-2.0.8-5.fc9.x86_64 requires /sbin/service ebtables-2.0.8-5.fc9.x86_64 requires /usr/bin/perl ebtables-2.0.8-5.fc9.x86_64 requires /bin/bash ebtables-2.0.8-5.fc9.x86_64 requires /sbin/chkconfig echo-icon-theme-0.3.89.0-0.1.git51c57605.fc10.noarch requires /bin/sh ecl-0.9j-2.fc9.x86_64 requires /bin/sh ecl-0.9j-2.fc9.x86_64 requires /bin/sh 1:eclipse-cdt-4.0.3-1.fc9.x86_64 requires /bin/sh 1:eclipse-changelog-2.6.1-3.fc9.x86_64 requires /usr/bin/rebuild-gcj-db eclipse-checkstyle-4.0.1-10.fc9.x86_64 requires /bin/sh 1:eclipse-ecj-3.3.2-11.fc9.x86_64 requires /usr/bin/rebuild-gcj-db 1:eclipse-ecj-3.3.2-11.fc9.x86_64 requires /bin/sh eclipse-egit-0.3.1-0.fc9.x86_64 requires /usr/bin/rebuild-gcj-db eclipse-epic-0.6.23-1.fc9.x86_64 requires /usr/bin/rebuild-gcj-db eclipse-gef-3.3.0-2.fc9.x86_64 requires /usr/bin/rebuild-gcj-db 1:eclipse-jdt-3.3.2-11.fc9.x86_64 requires /usr/bin/rebuild-gcj-db 1:eclipse-jdt-3.3.2-11.fc9.x86_64 requires /bin/sh eclipse-mylyn-2.3.2-4.fc9.x86_64 requires /bin/sh eclipse-mylyn-bugzilla-2.3.2-4.fc9.x86_64 requires /bin/sh eclipse-mylyn-ide-2.3.2-4.fc9.x86_64 requires /bin/sh eclipse-mylyn-java-2.3.2-4.fc9.x86_64 requires /bin/sh eclipse-mylyn-trac-2.3.2-4.fc9.x86_64 requires /bin/sh 1:eclipse-pde-3.3.2-11.fc9.x86_64 requires /usr/bin/rebuild-gcj-db 1:eclipse-pde-3.3.2-11.fc9.x86_64 requires /bin/bash 1:eclipse-pde-runtime-3.3.2-11.fc9.x86_64 requires /usr/bin/rebuild-gcj-db eclipse-photran-4.0-1.b3.fc9.1.x86_64 requires /usr/bin/rebuild-gcj-db eclipse-phpeclipse-1.1.8-18.fc9.x86_64 requires /usr/bin/rebuild-gcj-db 1:eclipse-platform-3.3.2-11.fc9.x86_64 requires /bin/sh 1:eclipse-platform-3.3.2-11.fc9.x86_64 requires /usr/lib64/eclipse/plugins/org.eclipse.swt.gtk.linux.x86_64_3.3.2.v3349.jar 1:eclipse-pydev-1.3.14-1.fc9.x86_64 requires /usr/bin/rebuild-gcj-db eclipse-quickrex-3.5.0-7.fc9.x86_64 requires /bin/sh 1:eclipse-rcp-3.3.2-11.fc9.x86_64 requires /usr/lib64/eclipse/plugins/org.eclipse.swt.gtk.linux.x86_64_3.3.2.v3349.jar 1:eclipse-rcp-3.3.2-11.fc9.x86_64 requires /usr/bin/rebuild-gcj-db eclipse-rpm-editor-0.2.1-3.fc9.x86_64 requires /bin/sh eclipse-setools-3.3.2.4-1.fc9.x86_64 requires /bin/sh eclipse-slide-1.3.8-1.fc9.noarch requires /bin/sh eclipse-subclipse-1.2.4-9.fc9.x86_64 requires /usr/bin/rebuild-gcj-db ecore-0.9.9.042-3.fc10.i386 requires /sbin/ldconfig ecore-0.9.9.042-3.fc10.x86_64 requires /sbin/ldconfig ecryptfs-utils-40-0.fc9.i386 requires /sbin/ldconfig ecryptfs-utils-40-0.fc9.x86_64 requires /sbin/ldconfig ed-0.8-2.fc9.x86_64 requires /bin/sh ed-0.8-2.fc9.x86_64 requires /sbin/install-info ed2k_hash-gui-0.4.0-7.fc9.x86_64 requires /bin/sh edac-utils-0.9-8.fc9.i386 requires /bin/sh edac-utils-0.9-8.fc9.i386 requires /sbin/ldconfig edac-utils-0.9-8.fc9.i386 requires /usr/bin/perl edac-utils-0.9-8.fc9.i386 requires /bin/sh edac-utils-0.9-8.fc9.x86_64 requires /bin/sh edac-utils-0.9-8.fc9.x86_64 requires /sbin/ldconfig edac-utils-0.9-8.fc9.x86_64 requires /usr/bin/perl edac-utils-0.9-8.fc9.x86_64 requires /bin/sh edje-0.5.0.042-3.fc10.i386 requires /sbin/ldconfig edje-0.5.0.042-3.fc10.i386 requires /bin/sh edje-0.5.0.042-3.fc10.x86_64 requires /sbin/ldconfig edje-0.5.0.042-3.fc10.x86_64 requires /bin/sh edrip-fonts-20080330-1.fc9.noarch requires /bin/sh edsadmin-1.0-2.fc9.noarch requires /bin/sh eel2-2.23.1-1.fc10.i386 requires /sbin/ldconfig eel2-2.23.1-1.fc10.x86_64 requires /sbin/ldconfig eet-1.0.0-1.fc10.i386 requires /sbin/ldconfig eet-1.0.0-1.fc10.x86_64 requires /sbin/ldconfig efax-0.9a-1.001114.fc9.x86_64 requires /bin/sh efont-unicode-bdf-0.4.2-7.fc8.noarch requires /bin/sh efreet-0.0.3.042-3.fc10.i386 requires /sbin/ldconfig efreet-0.0.3.042-3.fc10.x86_64 requires /sbin/ldconfig egd-0.9-2.fc9.noarch requires /usr/bin/perl eggdrop-1.6.19-1.fc10.x86_64 requires /bin/sh egoboo-2.7.5-4.fc9.x86_64 requires /bin/sh egoboo-data-2.7.5-1.fc9.noarch requires /bin/sh ejabberd-2.0.0-1.fc9.x86_64 requires /bin/sh ejabberd-2.0.0-1.fc9.x86_64 requires /bin/bash ejabberd-2.0.0-1.fc9.x86_64 requires /sbin/chkconfig ejabberd-2.0.0-1.fc9.x86_64 requires /bin/sh ejabberd-2.0.0-1.fc9.x86_64 requires /sbin/service ekg-1.7-6.fc9.x86_64 requires /usr/bin/luit ekg-1.7-6.fc9.x86_64 requires /usr/bin/perl ekg-1.7-6.fc9.x86_64 requires /bin/sh ekg2-devel-0.1.1-4.fc9.i386 requires /bin/sh ekg2-devel-0.1.1-4.fc9.x86_64 requires /bin/sh ekiga-2.0.12-2.fc10.x86_64 requires /bin/sh ekiga-2.0.12-2.fc10.x86_64 requires /bin/sh ekiga-2.0.12-2.fc10.x86_64 requires /usr/bin/scrollkeeper-update electronics-menu-1.0-1.fc9.noarch requires /bin/sh elektra-0.6.10-6.fc9.i386 requires /bin/sh elektra-0.6.10-6.fc9.i386 requires /sbin/service elektra-0.6.10-6.fc9.i386 requires /sbin/ldconfig elektra-0.6.10-6.fc9.i386 requires /bin/bash elektra-0.6.10-6.fc9.i386 requires /sbin/chkconfig elektra-0.6.10-6.fc9.x86_64 requires /bin/sh elektra-0.6.10-6.fc9.x86_64 requires /sbin/service elektra-0.6.10-6.fc9.x86_64 requires /sbin/ldconfig elektra-0.6.10-6.fc9.x86_64 requires /bin/bash elektra-0.6.10-6.fc9.x86_64 requires /sbin/chkconfig elfutils-0.135-1.fc10.x86_64 requires /bin/sh elfutils-libelf-0.135-1.fc10.i386 requires /sbin/ldconfig elfutils-libelf-0.135-1.fc10.x86_64 requires /sbin/ldconfig elfutils-libs-0.135-1.fc10.i386 requires /sbin/ldconfig elfutils-libs-0.135-1.fc10.x86_64 requires /sbin/ldconfig elisa-0.3.2-1.fc8.noarch requires /usr/bin/python elsa-1.4-3.fc9.x86_64 requires /usr/bin/env elsa-1.4-3.fc9.x86_64 requires /bin/sh em8300-0.16.4-1.fc9.x86_64 requires /bin/sh em8300-0.16.4-1.fc9.x86_64 requires /etc/security/console.perms.d em8300-0.16.4-1.fc9.x86_64 requires /etc/alsa/cards em8300-devel-0.16.4-1.fc9.i386 requires /usr/bin/perl em8300-devel-0.16.4-1.fc9.x86_64 requires /usr/bin/perl em8300-utils-0.16.4-1.fc9.x86_64 requires /usr/bin/perl 1:emacs-22.2-4.fc9.x86_64 requires /bin/sh 1:emacs-22.2-4.fc9.x86_64 requires /bin/sh emacs-auctex-11.85-7.fc9.noarch requires /bin/sh emacs-auctex-11.85-7.fc9.noarch requires /sbin/install-info emacs-bbdb-2.35-8.fc8.noarch requires /bin/sh 1:emacs-common-22.2-4.fc9.x86_64 requires /bin/sh 1:emacs-common-22.2-4.fc9.x86_64 requires /usr/bin/perl 1:emacs-common-22.2-4.fc9.x86_64 requires /usr/sbin/alternatives 1:emacs-common-22.2-4.fc9.x86_64 requires /sbin/install-info 1:emacs-common-22.2-4.fc9.x86_64 requires /bin/sh emacs-common-ebib-1.5.2-3.fc9.noarch requires /bin/sh emacs-common-ebib-1.5.2-3.fc9.noarch requires /sbin/install-info emacs-common-ess-5.3.7-1.fc10.noarch requires /bin/sh emacs-common-ess-5.3.7-1.fc10.noarch requires /sbin/install-info emacs-common-muse-3.12-1.fc9.noarch requires /bin/sh emacs-common-muse-3.12-1.fc9.noarch requires /sbin/install-info emacs-ess-5.3.7-1.fc10.noarch requires /bin/sh 1:emacs-nox-22.2-4.fc9.x86_64 requires /bin/sh 1:emacs-nox-22.2-4.fc9.x86_64 requires /bin/sh emacs-nxml-mode-0.20041004-6.fc8.noarch requires /bin/sh emacs-vm-8.0.9.544-1.fc9.x86_64 requires /bin/sh emacs-vm-8.0.9.544-1.fc9.x86_64 requires /sbin/install-info emacspeak-26-3.fc8.noarch requires /bin/sh emacspeak-26-3.fc8.noarch requires /usr/bin/perl emacspeak-26-3.fc8.noarch requires /usr/bin/tclsh emacspeak-26-3.fc8.noarch requires /bin/sh embryo-0.9.1.042-5.fc10.i386 requires /sbin/ldconfig embryo-0.9.1.042-5.fc10.x86_64 requires /sbin/ldconfig emerald-0.5.2-4.fc9.i386 requires /bin/sh emerald-0.5.2-4.fc9.x86_64 requires /bin/sh emesene-1.0-1.fc9.noarch requires /usr/bin/env empathy-0.23.2-1.fc10.x86_64 requires /bin/sh empathy-libs-0.23.2-1.fc10.i386 requires /sbin/ldconfig empathy-libs-0.23.2-1.fc10.x86_64 requires /sbin/ldconfig enca-1.9-4.fc9.i386 requires /sbin/ldconfig enca-1.9-4.fc9.x86_64 requires /sbin/ldconfig 1:enchant-1.3.0-4.fc10.i386 requires /sbin/ldconfig 1:enchant-1.3.0-4.fc10.x86_64 requires /sbin/ldconfig enemies-of-carlotta-1.2.4-1.fc7.noarch requires /usr/bin/python enet-1.1-3.fc9.i386 requires /sbin/ldconfig enet-1.1-3.fc9.x86_64 requires /sbin/ldconfig enigma-1.01-6.2.x86_64 requires /bin/sh enscript-1.6.4-9.fc9.x86_64 requires /bin/sh enscript-1.6.4-9.fc9.x86_64 requires /usr/bin/perl enscript-1.6.4-9.fc9.x86_64 requires /sbin/install-info enscript-1.6.4-9.fc9.x86_64 requires /bin/sh environment-modules-3.2.6-5.fc9.x86_64 requires /bin/sh eog-2.23.2-1.fc10.x86_64 requires /bin/sh epdfview-0.1.6-3.fc9.x86_64 requires /bin/sh epeg-0.9.1.042-4.fc10.i386 requires /sbin/ldconfig epeg-0.9.1.042-4.fc10.x86_64 requires /sbin/ldconfig epiphany-2.22.1.1-1.fc9.x86_64 requires /bin/sh epiphany-extensions-2.22.1-1.fc9.x86_64 requires /bin/sh epydoc-3.0.1-1.fc9.noarch requires /usr/bin/python epylog-1.0.3-7.fc9.noarch requires /bin/sh epylog-1.0.3-7.fc9.noarch requires /usr/bin/python eric-4.1.2-2.fc9.noarch requires /bin/sh eric-4.1.2-2.fc9.noarch requires /usr/bin/env eric-4.1.2-2.fc9.noarch requires /bin/sh eric-4.1.2-2.fc9.noarch requires /usr/bin/python eris-1.3.13-2.fc9.i386 requires /sbin/ldconfig eris-1.3.13-2.fc9.x86_64 requires /sbin/ldconfig erlang-R12B-1.1.fc9.x86_64 requires /bin/sh erlang-R12B-1.1.fc9.x86_64 requires /bin/sh eruby-libs-1.0.5-11.i386 requires /sbin/ldconfig eruby-libs-1.0.5-11.x86_64 requires /sbin/ldconfig esc-1.0.1-9.fc9.x86_64 requires /bin/sh escape-200704130-8.fc9.x86_64 requires /bin/sh esmtp-0.6.0-4.fc9.x86_64 requires /bin/sh esmtp-0.6.0-4.fc9.x86_64 requires /bin/bash esmtp-0.6.0-4.fc9.x86_64 requires /usr/sbin/alternatives 1:esound-devel-0.2.38-7.fc9.i386 requires /bin/sh 1:esound-devel-0.2.38-7.fc9.x86_64 requires /bin/sh 1:esound-libs-0.2.38-7.fc9.i386 requires /sbin/ldconfig 1:esound-libs-0.2.38-7.fc9.x86_64 requires /sbin/ldconfig 1:esound-tools-0.2.38-7.fc9.x86_64 requires /bin/sh espeak-1.31-5.fc9.i386 requires /sbin/ldconfig espeak-1.31-5.fc9.x86_64 requires /sbin/ldconfig eterm-0.9.4-10.fc9.x86_64 requires /sbin/ldconfig eterm-0.9.4-10.fc9.x86_64 requires /usr/bin/perl eterm-0.9.4-10.fc9.x86_64 requires /bin/sh etherape-0.9.7-6.fc9.x86_64 requires /bin/sh etherbat-1.0.1-4.fc9.x86_64 requires /usr/bin/ruby ettercap-0.7.3-22.fc9.x86_64 requires /bin/sh ettercap-0.7.3-22.fc9.x86_64 requires /usr/sbin/alternatives ettercap-gtk-0.7.3-22.fc9.x86_64 requires /bin/sh ettercap-gtk-0.7.3-22.fc9.x86_64 requires /usr/sbin/alternatives evas-0.9.9.042-3.fc10.i386 requires /sbin/ldconfig evas-0.9.9.042-3.fc10.x86_64 requires /sbin/ldconfig eventlog-0.2.5-9.fc9.i386 requires /sbin/ldconfig eventlog-0.2.5-9.fc9.x86_64 requires /sbin/ldconfig evince-2.22.1.1-1.fc9.i386 requires /bin/sh evince-2.22.1.1-1.fc9.x86_64 requires /bin/sh evolution-2.23.2-1.fc10.i386 requires /usr/bin/perl evolution-2.23.2-1.fc10.i386 requires /bin/sh evolution-2.23.2-1.fc10.x86_64 requires /bin/sh evolution-2.23.2-1.fc10.x86_64 requires /usr/bin/perl evolution-bogofilter-2.23.2-1.fc10.x86_64 requires /bin/sh evolution-brutus-1.2.11-2.fc9.i386 requires /sbin/ldconfig evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires /sbin/ldconfig evolution-brutus-1.2.11-2.fc9.x86_64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libWand.so.10()(64bit) evolution-data-server-2.23.2-2.fc10.i386 requires /sbin/ldconfig evolution-data-server-2.23.2-2.fc10.x86_64 requires /sbin/ldconfig evolution-exchange-2.23.2-1.fc10.x86_64 requires /bin/sh evolution-python-0.0.4-3.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) evolution-rss-0.0.8-7.fc9.x86_64 requires /bin/sh evolution-rss-0.0.8-7.fc9.x86_64 requires /sbin/ldconfig evolution-webcal-2.21.92-2.fc10.x86_64 requires /bin/sh evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) ewftools-20080501-1.fc10.x86_64 requires /usr/bin/python2.5 exaile-0.2.13-1.fc9.x86_64 requires /bin/sh exempi-2.0.0-1.fc9.i386 requires /sbin/ldconfig exempi-2.0.0-1.fc9.x86_64 requires /sbin/ldconfig exim-4.69-5.fc10.x86_64 requires /bin/sh exim-4.69-5.fc10.x86_64 requires /etc/aliases exim-4.69-5.fc10.x86_64 requires /usr/sbin/groupadd exim-4.69-5.fc10.x86_64 requires /usr/sbin/useradd exim-4.69-5.fc10.x86_64 requires /usr/sbin/alternatives exim-4.69-5.fc10.x86_64 requires /sbin/service exim-4.69-5.fc10.x86_64 requires /bin/bash exim-4.69-5.fc10.x86_64 requires /bin/sh exim-4.69-5.fc10.x86_64 requires /usr/bin/perl exim-4.69-5.fc10.x86_64 requires /sbin/chkconfig exim-clamav-4.69-5.fc10.x86_64 requires /bin/sh exim-clamav-4.69-5.fc10.x86_64 requires /sbin/chkconfig exim-clamav-4.69-5.fc10.x86_64 requires /sbin/service exim-greylist-4.69-5.fc10.x86_64 requires /etc/cron.daily exim-greylist-4.69-5.fc10.x86_64 requires /bin/bash exim-greylist-4.69-5.fc10.x86_64 requires /bin/sh exim-mon-4.69-5.fc10.x86_64 requires /bin/sh exiv2-libs-0.16-2.fc9.i386 requires /sbin/ldconfig exiv2-libs-0.16-2.fc9.x86_64 requires /sbin/ldconfig exo-0.3.4-2.fc9.i386 requires /usr/bin/env exo-0.3.4-2.fc9.i386 requires /bin/sh exo-0.3.4-2.fc9.i386 requires /bin/sh exo-0.3.4-2.fc9.x86_64 requires /bin/sh exo-0.3.4-2.fc9.x86_64 requires /usr/bin/env exo-0.3.4-2.fc9.x86_64 requires /bin/sh expat-2.0.1-5.i386 requires /sbin/ldconfig expat-2.0.1-5.x86_64 requires /sbin/ldconfig expect-5.43.0-13.fc9.i386 requires /bin/sh expect-5.43.0-13.fc9.x86_64 requires /bin/sh expectk-5.43.0-13.fc9.x86_64 requires /bin/sh ez-ipupdate-3.0.11-0.17.b8.fc9.x86_64 requires /bin/sh ez-ipupdate-3.0.11-0.17.b8.fc9.x86_64 requires /sbin/chkconfig ez-ipupdate-3.0.11-0.17.b8.fc9.x86_64 requires /usr/sbin/groupadd ez-ipupdate-3.0.11-0.17.b8.fc9.x86_64 requires /usr/sbin/useradd f-spot-0.4.3.1-1.fc10.x86_64 requires /bin/sh f-spot-0.4.3.1-1.fc10.x86_64 requires /bin/bash f-spot-0.4.3.1-1.fc10.x86_64 requires /bin/sh fRaBs-2.11-1.fc9.noarch requires /bin/sh facter-1.3.8-1.fc8.noarch requires /usr/bin/ruby fail2ban-0.8.2-13.fc9.noarch requires /bin/sh fail2ban-0.8.2-13.fc9.noarch requires /bin/bash fail2ban-0.8.2-13.fc9.noarch requires /sbin/chkconfig fail2ban-0.8.2-13.fc9.noarch requires /usr/bin/python fail2ban-0.8.2-13.fc9.noarch requires /sbin/service fakechroot-2.5-13.fc9.x86_64 requires /bin/sh fakeroot-1.6.4-16.fc9.x86_64 requires /bin/sh fakeroot-1.6.4-16.fc9.x86_64 requires /usr/bin/getopt fann-2.0.0-4.1.fc9.i386 requires /sbin/ldconfig fann-2.0.0-4.1.fc9.x86_64 requires /sbin/ldconfig fantasdic-1.0-0.1.beta5.fc9.noarch requires /bin/sh fantasdic-1.0-0.1.beta5.fc9.noarch requires /usr/bin/ruby farsight-0.1.28-1.fc10.i386 requires /sbin/ldconfig farsight-0.1.28-1.fc10.x86_64 requires /sbin/ldconfig fbg-0.9.1-2.fc9.x86_64 requires /bin/sh fbida-fbgs-2.06-5.fc9.x86_64 requires /bin/bash fbreader-0.8.12-2.fc9.i386 requires /sbin/ldconfig fbreader-0.8.12-2.fc9.x86_64 requires /sbin/ldconfig fbset-2.1-25.fc9.x86_64 requires /usr/bin/perl fcgi-2.4.0-5.fc9.i386 requires /sbin/ldconfig fcgi-2.4.0-5.fc9.x86_64 requires /sbin/ldconfig fcron-3.0.3-4.fc9.x86_64 requires /bin/sh fcron-3.0.3-4.fc9.x86_64 requires /sbin/service fcron-3.0.3-4.fc9.x86_64 requires /bin/sh fcron-3.0.3-4.fc9.x86_64 requires /sbin/chkconfig fcron-3.0.3-4.fc9.x86_64 requires /usr/sbin/useradd fedora-ds-admin-1.1.4-1.fc9.i386 requires /bin/sh fedora-ds-admin-1.1.4-1.fc9.i386 requires /usr/bin/env fedora-ds-admin-1.1.4-1.fc9.i386 requires /sbin/service fedora-ds-admin-1.1.4-1.fc9.i386 requires /sbin/ldconfig fedora-ds-admin-1.1.4-1.fc9.i386 requires /usr/bin/repl-monitor.pl fedora-ds-admin-1.1.4-1.fc9.i386 requires /bin/sh fedora-ds-admin-1.1.4-1.fc9.i386 requires /sbin/chkconfig fedora-ds-admin-1.1.4-1.fc9.x86_64 requires /bin/sh fedora-ds-admin-1.1.4-1.fc9.x86_64 requires /usr/bin/env fedora-ds-admin-1.1.4-1.fc9.x86_64 requires /sbin/service fedora-ds-admin-1.1.4-1.fc9.x86_64 requires /sbin/ldconfig fedora-ds-admin-1.1.4-1.fc9.x86_64 requires /usr/bin/repl-monitor.pl fedora-ds-admin-1.1.4-1.fc9.x86_64 requires /bin/sh fedora-ds-admin-1.1.4-1.fc9.x86_64 requires /sbin/chkconfig fedora-ds-base-1.1.0.1-4.fc9.i386 requires /usr/bin/perl fedora-ds-base-1.1.0.1-4.fc9.i386 requires /sbin/ldconfig fedora-ds-base-1.1.0.1-4.fc9.i386 requires /bin/sh fedora-ds-base-1.1.0.1-4.fc9.i386 requires /sbin/service fedora-ds-base-1.1.0.1-4.fc9.i386 requires /sbin/chkconfig fedora-ds-base-1.1.0.1-4.fc9.i386 requires /usr/bin/env fedora-ds-base-1.1.0.1-4.fc9.i386 requires /bin/sh fedora-ds-base-1.1.0.1-4.fc9.x86_64 requires /sbin/ldconfig fedora-ds-base-1.1.0.1-4.fc9.x86_64 requires /usr/bin/perl fedora-ds-base-1.1.0.1-4.fc9.x86_64 requires /usr/bin/env fedora-ds-base-1.1.0.1-4.fc9.x86_64 requires /bin/sh fedora-ds-base-1.1.0.1-4.fc9.x86_64 requires /sbin/service fedora-ds-base-1.1.0.1-4.fc9.x86_64 requires /sbin/chkconfig fedora-ds-base-1.1.0.1-4.fc9.x86_64 requires /bin/sh fedora-ds-dsgw-1.1.0-1.fc9.x86_64 requires /usr/bin/env fedora-ds-dsgw-1.1.0-1.fc9.x86_64 requires /etc/dirsrv/admin-serv/httpd.conf fedora-ds-dsgw-1.1.0-1.fc9.x86_64 requires /bin/sh fedora-icon-theme-1.0.0-1.fc8.noarch requires /bin/sh fedora-idm-console-1.1.1-2.fc9.x86_64 requires /bin/sh fedora-logos-9.0.0-3.fc10.noarch requires /bin/sh fedora-logos-9.0.0-3.fc10.noarch requires /bin/sh fedora-packager-0.3.0-1.fc9.noarch requires /bin/bash fedora-packager-0.3.0-1.fc9.noarch requires /usr/bin/python fedora-release-notes-9.0.1-1.noarch requires /bin/sh fedora-usermgmt-core-0.10-1.fc8.noarch requires /bin/bash fedora-usermgmt-devel-0.10-1.fc8.noarch requires /etc/rpm fedora-usermgmt-shadow-utils-0.10-1.fc8.noarch requires /bin/sh fedora-usermgmt-shadow-utils-0.10-1.fc8.noarch requires /usr/sbin/update-alternatives fedora-usermgmt-shadow-utils-0.10-1.fc8.noarch requires /bin/sh fedora-usermgmt-shadow-utils-0.10-1.fc8.noarch requires /etc/fedora/usermgmt feh-1.3.4-8.fc9.x86_64 requires /usr/bin/perl feh-1.3.4-8.fc9.x86_64 requires /bin/bash festival-1.96-4.fc9.x86_64 requires /bin/sh festival-docs-1.4.2-4.fc9.x86_64 requires /bin/sh festival-docs-1.4.2-4.fc9.x86_64 requires /sbin/install-info festival-lib-1.96-4.fc9.i386 requires /sbin/ldconfig festival-lib-1.96-4.fc9.x86_64 requires /sbin/ldconfig festival-speechtools-libs-1.2.96-4.fc9.i386 requires /sbin/ldconfig festival-speechtools-libs-1.2.96-4.fc9.x86_64 requires /sbin/ldconfig festival-speechtools-utils-1.2.96-4.fc9.x86_64 requires /usr/bin/perl festival-speechtools-utils-1.2.96-4.fc9.x86_64 requires /bin/sh fftw-3.1.2-6.fc9.i386 requires /sbin/install-info fftw-3.1.2-6.fc9.i386 requires /sbin/ldconfig fftw-3.1.2-6.fc9.i386 requires /bin/sh fftw-3.1.2-6.fc9.x86_64 requires /sbin/install-info fftw-3.1.2-6.fc9.x86_64 requires /sbin/ldconfig fftw-3.1.2-6.fc9.x86_64 requires /bin/sh fftw-devel-3.1.2-6.fc9.i386 requires /bin/sh fftw-devel-3.1.2-6.fc9.x86_64 requires /bin/sh fftw2-2.1.5-16.fc9.i386 requires /sbin/ldconfig fftw2-2.1.5-16.fc9.x86_64 requires /sbin/ldconfig fftw2-devel-2.1.5-16.fc9.i386 requires /bin/sh fftw2-devel-2.1.5-16.fc9.x86_64 requires /bin/sh fig2ps-1.3.6-2.fc7.noarch requires /usr/bin/perl file-libs-4.23-5.fc9.i386 requires /sbin/ldconfig file-libs-4.23-5.fc9.x86_64 requires /sbin/ldconfig file-roller-2.23.1-1.fc10.x86_64 requires /bin/sh filelight-1.0-12.fc9.x86_64 requires /bin/sh fillets-ng-0.8.0-1.fc9.x86_64 requires /bin/sh finch-2.4.1-3.fc10.i386 requires /sbin/ldconfig finch-2.4.1-3.fc10.x86_64 requires /sbin/ldconfig 1:findutils-4.4.0-1.fc10.x86_64 requires /bin/sh 1:findutils-4.4.0-1.fc10.x86_64 requires /sbin/install-info fio-1.20-1.fc10.x86_64 requires /bin/bash firefox-3.0-0.59.cvs20080408.fc10.x86_64 requires /bin/sh firefox-3.0-0.59.cvs20080408.fc10.x86_64 requires /bin/sh firestarter-1.0.3-18.fc9.x86_64 requires /bin/sh firestarter-1.0.3-18.fc9.x86_64 requires /bin/sh firmware-tools-1.5.6-1.fc8.noarch requires /usr/bin/python2 firmware-tools-1.5.6-1.fc8.noarch requires /bin/sh firmware-tools-1.5.6-1.fc8.noarch requires /usr/bin/python firstaidkit-0.1.1-4.fc9.noarch requires /usr/bin/python firstaidkit-devel-0.1.1-4.fc9.noarch requires /bin/bash firstboot-1.98-1.fc10.x86_64 requires /bin/sh firstboot-1.98-1.fc10.x86_64 requires /bin/bash firstboot-1.98-1.fc10.x86_64 requires /usr/bin/python2 fish-1.23.0-2.fc9.x86_64 requires /bin/sh fityk-0.8.1-13.fc9.i386 requires /bin/sh fityk-0.8.1-13.fc9.x86_64 requires /bin/sh flac-1.2.1-4.fc9.i386 requires /sbin/ldconfig flac-1.2.1-4.fc9.x86_64 requires /sbin/ldconfig flagpoll-0.9.1-2.fc9.noarch requires /usr/bin/python flawfinder-1.27-3.fc8.noarch requires /usr/bin/env flex-2.5.35-2.fc10.x86_64 requires /bin/sh flex-2.5.35-2.fc10.x86_64 requires /sbin/install-info flim-1.14.8-3.fc8.noarch requires /sbin/install-info flite-1.3-9.fc9.i386 requires /sbin/ldconfig flite-1.3-9.fc9.x86_64 requires /sbin/ldconfig flobopuyo-0.20-4.fc9.x86_64 requires /bin/sh flow-tools-0.68.4-1.fc9.i386 requires /bin/sh flow-tools-0.68.4-1.fc9.i386 requires /bin/env flow-tools-0.68.4-1.fc9.i386 requires /bin/sh flow-tools-0.68.4-1.fc9.x86_64 requires /bin/sh flow-tools-0.68.4-1.fc9.x86_64 requires /bin/env flow-tools-0.68.4-1.fc9.x86_64 requires /bin/sh fltk-1.1.8-1.fc9.i386 requires /sbin/ldconfig fltk-1.1.8-1.fc9.x86_64 requires /sbin/ldconfig fltk-devel-1.1.8-1.fc9.i386 requires /bin/sh fltk-devel-1.1.8-1.fc9.x86_64 requires /bin/sh fltk-fluid-1.1.8-1.fc9.x86_64 requires /bin/sh fluidsynth-libs-1.0.7-11.a.fc9.i386 requires /sbin/ldconfig fluidsynth-libs-1.0.7-11.a.fc9.x86_64 requires /sbin/ldconfig flumotion-0.4.2-5.fc9.x86_64 requires /bin/sh flumotion-0.4.2-5.fc9.x86_64 requires /usr/bin/python flumotion-0.4.2-5.fc9.x86_64 requires /bin/bash fluxbox-1.0.0-5.fc9.x86_64 requires /usr/bin/env fluxbox-1.0.0-5.fc9.x86_64 requires /bin/sh fluxstyle-1.0.1-2.fc7.noarch requires /usr/bin/env fmio-2.0.8-11.fc9.x86_64 requires /sbin/ldconfig fmio-2.0.8-11.fc9.x86_64 requires /usr/bin/python fmt-ptrn-java-1.3.17-1.fc9.i386 requires /sbin/ldconfig fmt-ptrn-java-1.3.17-1.fc9.x86_64 requires /sbin/ldconfig fmtools-1.0.2-3.fc9.x86_64 requires /bin/sh fnfx-0.3-11.fc9.x86_64 requires /bin/sh fnfx-0.3-11.fc9.x86_64 requires /bin/bash fnfx-0.3-11.fc9.x86_64 requires /sbin/chkconfig fnfx-0.3-11.fc9.x86_64 requires /sbin/service fontconfig-2.5.0-2.fc9.i386 requires /bin/sh fontconfig-2.5.0-2.fc9.i386 requires /sbin/ldconfig fontconfig-2.5.0-2.fc9.x86_64 requires /bin/sh fontconfig-2.5.0-2.fc9.x86_64 requires /sbin/ldconfig fontforge-20080309-1.fc9.i386 requires /usr/bin/fontforge fontforge-20080309-1.fc9.i386 requires /sbin/ldconfig fontforge-20080309-1.fc9.x86_64 requires /usr/bin/fontforge fontforge-20080309-1.fc9.x86_64 requires /sbin/ldconfig fontmatrix-0.4.2-1.fc9.x86_64 requires /bin/sh fonts-ISO8859-2-1.0-18.fc8.noarch requires /bin/sh fonts-ISO8859-2-100dpi-1.0-18.fc8.noarch requires /bin/sh fonts-ISO8859-2-75dpi-1.0-18.fc8.noarch requires /bin/sh fonts-KOI8-R-1.0-10.fc8.noarch requires /usr/bin/perl fonts-hebrew-fancy-0.20051122-2.fc7.noarch requires /bin/sh fonts-japanese-0.20061016-13.fc9.noarch requires /bin/sh fonts-truetype-apl-4.22.1-3.fc10.x86_64 requires /bin/sh fonts-x11-apl-4.22.1-3.fc10.x86_64 requires /bin/sh fonttools-2.0-0.11.20060223cvs.fc7.x86_64 requires /usr/bin/python fontypython-0.2.0-6.fc7.noarch requires /usr/bin/python foomatic-3.0.2-60.fc10.x86_64 requires /usr/bin/perl foomatic-3.0.2-60.fc10.x86_64 requires /bin/bash foomatic-3.0.2-60.fc10.x86_64 requires /bin/sh fpc-2.2.0-12.fc10.x86_64 requires /bin/sh fpc-src-2.2.0-12.fc10.x86_64 requires /bin/sh fpc-src-2.2.0-12.fc10.x86_64 requires /usr/bin/env freealut-1.1.0-6.fc9.i386 requires /sbin/ldconfig freealut-1.1.0-6.fc9.x86_64 requires /sbin/ldconfig freealut-devel-1.1.0-6.fc9.i386 requires /bin/sh freealut-devel-1.1.0-6.fc9.x86_64 requires /bin/sh freeciv-2.1.4-1.fc10.x86_64 requires /bin/sh freecol-0.7.3-2.fc9.noarch requires /bin/bash freecol-0.7.3-2.fc9.noarch requires /bin/sh freedoom-0.5-3.fc8.noarch requires /bin/sh freedroid-1.0.2-9.fc9.x86_64 requires /bin/sh freedroidrpg-0.10.3-2.fc9.x86_64 requires /bin/sh freefont-20060126-4.fc7.noarch requires /bin/sh freeglut-2.4.0-14.fc9.i386 requires /sbin/ldconfig freeglut-2.4.0-14.fc9.x86_64 requires /sbin/ldconfig freehdl-0.0.6-1.fc9.i386 requires /bin/sh freehdl-0.0.6-1.fc9.i386 requires /sbin/install-info freehdl-0.0.6-1.fc9.i386 requires /sbin/ldconfig freehdl-0.0.6-1.fc9.i386 requires /usr/bin/perl freehdl-0.0.6-1.fc9.i386 requires /bin/sh freehdl-0.0.6-1.fc9.x86_64 requires /bin/sh freehdl-0.0.6-1.fc9.x86_64 requires /sbin/install-info freehdl-0.0.6-1.fc9.x86_64 requires /sbin/ldconfig freehdl-0.0.6-1.fc9.x86_64 requires /usr/bin/perl freehdl-0.0.6-1.fc9.x86_64 requires /bin/sh freeimage-3.10.0-1.fc9.i386 requires /sbin/ldconfig freeimage-3.10.0-1.fc9.x86_64 requires /sbin/ldconfig freeipmi-0.5.1-3.fc9.i386 requires /bin/sh freeipmi-0.5.1-3.fc9.i386 requires /sbin/ldconfig freeipmi-0.5.1-3.fc9.x86_64 requires /bin/sh freeipmi-0.5.1-3.fc9.x86_64 requires /sbin/ldconfig freeipmi-bmc-watchdog-0.5.1-3.fc9.x86_64 requires /bin/sh freeipmi-bmc-watchdog-0.5.1-3.fc9.x86_64 requires /bin/sh freeipmi-ipmidetectd-0.5.1-3.fc9.x86_64 requires /bin/sh freeipmi-ipmidetectd-0.5.1-3.fc9.x86_64 requires /bin/sh freenx-0.7.1-5.fc9.x86_64 requires /bin/sh freenx-0.7.1-5.fc9.x86_64 requires /bin/bash freenx-0.7.1-5.fc9.x86_64 requires /usr/bin/expect freenx-server-0.7.2-8.fc10.x86_64 requires /bin/sh freenx-server-0.7.2-8.fc10.x86_64 requires /usr/bin/expect freenx-server-0.7.2-8.fc10.x86_64 requires /bin/bash freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib/cups/backend freenx-server-0.7.2-8.fc10.x86_64 requires /bin/sh freeradius-2.0.2-2.fc9.x86_64 requires /bin/sh freeradius-2.0.2-2.fc9.x86_64 requires /sbin/ldconfig freeradius-2.0.2-2.fc9.x86_64 requires /usr/bin/perl freeradius-2.0.2-2.fc9.x86_64 requires /bin/sh freeradius-2.0.2-2.fc9.x86_64 requires /sbin/chkconfig freeradius-dialupadmin-2.0.2-2.fc9.x86_64 requires /usr/bin/perl freeradius-utils-2.0.2-2.fc9.x86_64 requires /bin/sh freeradius-utils-2.0.2-2.fc9.x86_64 requires /usr/bin/perl freetalk-3.0-2.fc9.x86_64 requires /bin/sh freetalk-3.0-2.fc9.x86_64 requires /sbin/install-info freetalk-3.0-2.fc9.x86_64 requires /bin/sh freetds-0.64-11.fc9.i386 requires /sbin/ldconfig freetds-0.64-11.fc9.x86_64 requires /sbin/ldconfig freetennis-0.4.8-11.fc10.x86_64 requires /bin/sh freetype-2.3.5-4.fc9.i386 requires /sbin/ldconfig freetype-2.3.5-4.fc9.i386 requires /bin/sh freetype-2.3.5-4.fc9.x86_64 requires /sbin/ldconfig freetype-2.3.5-4.fc9.x86_64 requires /bin/sh freetype-devel-2.3.5-4.fc9.i386 requires /bin/sh freetype-devel-2.3.5-4.fc9.x86_64 requires /bin/sh freetype1-1.4-0.5.pre.fc9.i386 requires /sbin/ldconfig freetype1-1.4-0.5.pre.fc9.x86_64 requires /sbin/ldconfig fribidi-0.19.1-2.fc9.i386 requires /sbin/ldconfig fribidi-0.19.1-2.fc9.x86_64 requires /sbin/ldconfig frozen-bubble-2.1.0-8.fc9.x86_64 requires /bin/sh frozen-bubble-2.1.0-8.fc9.x86_64 requires /usr/bin/perl frozen-bubble-server-2.1.0-8.fc9.x86_64 requires /bin/sh frozen-bubble-server-2.1.0-8.fc9.x86_64 requires /bin/sh frysk-0.2.1-2.fc9.x86_64 requires /sbin/ldconfig frysk-0.2.1-2.fc9.x86_64 requires /bin/sh frysk-devel-0.2.1-2.fc9.i386 requires /usr/bin/env frysk-devel-0.2.1-2.fc9.i386 requires /bin/bash frysk-devel-0.2.1-2.fc9.i386 requires /bin/sh frysk-devel-0.2.1-2.fc9.x86_64 requires /usr/bin/env frysk-devel-0.2.1-2.fc9.x86_64 requires /bin/bash frysk-devel-0.2.1-2.fc9.x86_64 requires /bin/sh fslint-2.24-1.fc8.noarch requires /bin/bash fslint-2.24-1.fc8.noarch requires /usr/bin/env fslint-2.24-1.fc8.noarch requires /bin/sh fslint-2.24-1.fc8.noarch requires /usr/bin/python ftgl-2.1.2-8.fc9.i386 requires /sbin/ldconfig ftgl-2.1.2-8.fc9.x86_64 requires /sbin/ldconfig ftnchek-3.3.1-7.fc9.x86_64 requires /bin/sh ftnchek-emacs-3.3.1-7.fc9.x86_64 requires /usr/share/emacs/site-lisp ftplib-3.1-4.fc9.i386 requires /sbin/ldconfig ftplib-3.1-4.fc9.x86_64 requires /sbin/ldconfig func-0.18-1.fc9.noarch requires /bin/sh func-0.18-1.fc9.noarch requires /bin/sh func-0.18-1.fc9.noarch requires /usr/bin/python funtools-1.4.0-7.fc9.x86_64 requires /bin/sh funtools-libs-1.4.0-7.fc9.i386 requires /sbin/ldconfig funtools-libs-1.4.0-7.fc9.x86_64 requires /sbin/ldconfig fuse-2.7.3-2.fc9.x86_64 requires /bin/sh fuse-2.7.3-2.fc9.x86_64 requires /sbin/MAKEDEV fuse-2.7.3-2.fc9.x86_64 requires /sbin/chkconfig fuse-2.7.3-2.fc9.x86_64 requires /bin/sh fuse-2.7.3-2.fc9.x86_64 requires /sbin/service fuse-encfs-1.4.2-2.fc10.i386 requires /sbin/ldconfig fuse-encfs-1.4.2-2.fc10.i386 requires /bin/sh fuse-encfs-1.4.2-2.fc10.x86_64 requires /sbin/ldconfig fuse-encfs-1.4.2-2.fc10.x86_64 requires /bin/sh fuse-gmailfs-0.8.0-1.fc9.noarch requires /usr/bin/env fuse-libs-2.7.3-2.fc9.i386 requires /sbin/ldconfig fuse-libs-2.7.3-2.fc9.x86_64 requires /sbin/ldconfig fuse-s3fs-0.5-1.fc10.noarch requires /usr/bin/python fusion-icon-0.1.0-0.2.5e2dc9git.fc9.noarch requires /bin/sh fusion-icon-0.1.0-0.2.5e2dc9git.fc9.noarch requires /usr/bin/python fvwm-2.5.24-2.fc9.x86_64 requires /usr/bin/python fvwm-2.5.24-2.fc9.x86_64 requires /usr/bin/mimeopen fvwm-2.5.24-2.fc9.x86_64 requires /usr/bin/perl fvwm-2.5.24-2.fc9.x86_64 requires /bin/sh fwbackups-1.43.1-6.fc9.noarch requires /bin/bash fwbackups-1.43.1-6.fc9.noarch requires /usr/bin/python fwbuilder-2.1.16-2.fc9.x86_64 requires /bin/sh fwfstab-0.03-2.fc9.noarch requires /bin/sh fwrestart-1.05-1.fc8.noarch requires /usr/bin/env fyre-1.0.1-5.fc9.x86_64 requires /bin/sh fyre-1.0.1-5.fc9.x86_64 requires /sbin/service fyre-1.0.1-5.fc9.x86_64 requires /bin/bash fyre-1.0.1-5.fc9.x86_64 requires /sbin/chkconfig g-wrap-1.9.9-5.fc9.i386 requires /sbin/install-info g-wrap-1.9.9-5.fc9.i386 requires /sbin/ldconfig g-wrap-1.9.9-5.fc9.x86_64 requires /sbin/ldconfig g-wrap-1.9.9-5.fc9.x86_64 requires /sbin/install-info g-wrap-devel-1.9.9-5.fc9.i386 requires /bin/sh g-wrap-devel-1.9.9-5.fc9.i386 requires /bin/sh g-wrap-devel-1.9.9-5.fc9.x86_64 requires /bin/sh g-wrap-devel-1.9.9-5.fc9.x86_64 requires /bin/sh g2banking-2.3.3-3.fc9.i386 requires /sbin/ldconfig g2banking-2.3.3-3.fc9.x86_64 requires /sbin/ldconfig g2banking-devel-2.3.3-3.fc9.i386 requires /bin/sh g2banking-devel-2.3.3-3.fc9.x86_64 requires /bin/sh gai-0.5.10-14.fc9.i386 requires /sbin/ldconfig gai-0.5.10-14.fc9.x86_64 requires /sbin/ldconfig gajim-0.11.4-2.fc9.x86_64 requires /usr/bin/env gajim-0.11.4-2.fc9.x86_64 requires /bin/bash gajim-0.11.4-2.fc9.x86_64 requires /bin/sh galeon-2.0.5-1.fc9.x86_64 requires /bin/sh gallery2-2.2.4-4.fc10.noarch requires /bin/sh gallery2-2.2.4-4.fc10.noarch requires /usr/bin/perl gallery2-2.2.4-4.fc10.noarch requires /usr/bin/php gallery2-2.2.4-4.fc10.noarch requires /bin/sh galternatives-0.13.4-5.fc9.noarch requires /usr/sbin/update-alternatives galternatives-0.13.4-5.fc9.noarch requires /usr/bin/python gambas2-gb-chart-2.5.0-1.fc9.x86_64 requires /usr/bin/env gambas2-gb-db-2.5.0-1.fc9.x86_64 requires /usr/bin/env gambas2-gb-desktop-2.5.0-1.fc9.x86_64 requires /usr/bin/env gambas2-gb-form-2.5.0-1.fc9.x86_64 requires /usr/bin/env gambas2-gb-form-dialog-2.5.0-1.fc9.x86_64 requires /usr/bin/env gambas2-gb-form-mdi-2.5.0-1.fc9.x86_64 requires /usr/bin/env gambas2-gb-gtk-2.5.0-1.fc9.x86_64 requires /usr/bin/env gambas2-gb-info-2.5.0-1.fc9.x86_64 requires /usr/bin/env gambas2-gb-qt-2.5.0-1.fc9.x86_64 requires /usr/bin/env gambas2-gb-report-2.5.0-1.fc9.x86_64 requires /usr/bin/env gambas2-gb-settings-2.5.0-1.fc9.x86_64 requires /usr/bin/env gambas2-gb-web-2.5.0-1.fc9.x86_64 requires /usr/bin/env gambas2-gb-xml-rpc-2.5.0-1.fc9.x86_64 requires /usr/bin/env gambas2-ide-2.5.0-1.fc9.x86_64 requires /usr/bin/env gambas2-runtime-2.5.0-1.fc9.x86_64 requires /bin/sh gambas2-script-2.5.0-1.fc9.x86_64 requires /bin/sh gambas2-script-2.5.0-1.fc9.x86_64 requires /usr/bin/env games-menus-0.3.2-1.fc9.noarch requires /bin/sh gamin-0.1.9-5.fc9.i386 requires /bin/sh gamin-0.1.9-5.fc9.x86_64 requires /bin/sh gamin-python-0.1.9-5.fc9.x86_64 requires /usr/bin/env gammu-1.18.91-1.fc9.x86_64 requires /bin/bash gammu-1.18.91-1.fc9.x86_64 requires /bin/sh gammu-libs-1.18.91-1.fc9.i386 requires /sbin/ldconfig gammu-libs-1.18.91-1.fc9.x86_64 requires /sbin/ldconfig ganglia-3.0.7-1.fc9.i386 requires /bin/sh ganglia-3.0.7-1.fc9.i386 requires /bin/sh ganglia-3.0.7-1.fc9.x86_64 requires /bin/sh ganglia-3.0.7-1.fc9.x86_64 requires /bin/sh ganglia-devel-3.0.7-1.fc9.i386 requires /sbin/ldconfig ganglia-devel-3.0.7-1.fc9.x86_64 requires /sbin/ldconfig ganglia-gmetad-3.0.7-1.fc9.x86_64 requires /bin/sh ganglia-gmetad-3.0.7-1.fc9.x86_64 requires /sbin/service ganglia-gmetad-3.0.7-1.fc9.x86_64 requires /bin/sh ganglia-gmetad-3.0.7-1.fc9.x86_64 requires /sbin/chkconfig ganglia-gmond-3.0.7-1.fc9.x86_64 requires /bin/sh ganglia-gmond-3.0.7-1.fc9.x86_64 requires /sbin/service ganglia-gmond-3.0.7-1.fc9.x86_64 requires /bin/sh ganglia-gmond-3.0.7-1.fc9.x86_64 requires /sbin/chkconfig ganymed-ssh2-210-6.fc9.x86_64 requires /usr/bin/rebuild-gcj-db ganyremote-2.8-2.fc10.noarch requires /usr/bin/env gauche-0.8.13-1.fc9.i386 requires /bin/sh gauche-0.8.13-1.fc9.i386 requires /usr/bin/gosh gauche-0.8.13-1.fc9.i386 requires /sbin/install-info gauche-0.8.13-1.fc9.i386 requires /sbin/ldconfig gauche-0.8.13-1.fc9.x86_64 requires /bin/sh gauche-0.8.13-1.fc9.x86_64 requires /usr/bin/gosh gauche-0.8.13-1.fc9.x86_64 requires /sbin/install-info gauche-0.8.13-1.fc9.x86_64 requires /sbin/ldconfig gauche-gl-0.4.4-3.fc9.x86_64 requires /bin/sh gauche-gl-0.4.4-3.fc9.x86_64 requires /sbin/install-info gauche-gl-0.4.4-3.fc9.x86_64 requires /bin/sh gauche-gtk-0.4.1-17.fc9.x86_64 requires /bin/sh gawk-3.1.5-17.fc9.x86_64 requires /bin/sh gawk-3.1.5-17.fc9.x86_64 requires /bin/mktemp gawk-3.1.5-17.fc9.x86_64 requires /sbin/install-info gawk-3.1.5-17.fc9.x86_64 requires /bin/sh gazpacho-0.7.2-2.fc8.noarch requires /usr/bin/python gbrainy-0.61-5.fc9.x86_64 requires /bin/sh gbrainy-0.61-5.fc9.x86_64 requires /bin/bash gc-7.1-1.fc10.i386 requires /sbin/ldconfig gc-7.1-1.fc10.x86_64 requires /sbin/ldconfig gcalctool-5.23.1-1.fc10.x86_64 requires /bin/sh gcc-4.3.0-8.x86_64 requires /bin/sh gcc-4.3.0-8.x86_64 requires /sbin/install-info gcc-4.3.0-8.x86_64 requires /bin/sh gcc-gfortran-4.3.0-8.x86_64 requires /bin/sh gcc-gfortran-4.3.0-8.x86_64 requires /sbin/install-info gcc-gnat-4.3.0-8.x86_64 requires /bin/sh gcc-gnat-4.3.0-8.x86_64 requires /sbin/install-info gcc-java-4.3.0-8.x86_64 requires /bin/sh gcc-java-4.3.0-8.x86_64 requires /sbin/install-info gcc-java-4.3.0-8.x86_64 requires /usr/share/java/eclipse-ecj.jar gcdmaster-1.2.2-4.fc9.x86_64 requires /bin/sh gchempaint-0.8.7-2.fc9.x86_64 requires /bin/sh gcin-1.3.9-2.fc9.i386 requires /bin/sh gcin-1.3.9-2.fc9.i386 requires /usr/sbin/alternatives gcin-1.3.9-2.fc9.i386 requires /bin/bash gcin-1.3.9-2.fc9.x86_64 requires /bin/sh gcin-1.3.9-2.fc9.x86_64 requires /usr/sbin/alternatives gcin-1.3.9-2.fc9.x86_64 requires /bin/bash 1:gcombust-0.1.55-13.x86_64 requires /bin/sh gcompris-8.4.5-1.fc10.x86_64 requires /bin/sh gcompris-8.4.5-1.fc10.x86_64 requires /sbin/install-info gconf-editor-2.22.0-1.fc9.x86_64 requires /bin/sh gconfmm26-2.22.0-1.fc9.i386 requires /bin/sh gconfmm26-2.22.0-1.fc9.i386 requires /sbin/ldconfig gconfmm26-2.22.0-1.fc9.x86_64 requires /bin/sh gconfmm26-2.22.0-1.fc9.x86_64 requires /sbin/ldconfig gcstar-1.3.2-1.fc9.noarch requires /usr/bin/perl gcstar-1.3.2-1.fc9.noarch requires /bin/sh gd-2.0.35-5.fc9.i386 requires /sbin/ldconfig gd-2.0.35-5.fc9.x86_64 requires /sbin/ldconfig gd-devel-2.0.35-5.fc9.i386 requires /bin/sh gd-devel-2.0.35-5.fc9.x86_64 requires /bin/sh gd-progs-2.0.35-5.fc9.x86_64 requires /usr/bin/perl gdal-1.5.1-5.fc9.i386 requires /sbin/ldconfig gdal-1.5.1-5.fc9.x86_64 requires /sbin/ldconfig gdal-devel-1.5.1-5.fc9.i386 requires /bin/sh gdal-devel-1.5.1-5.fc9.x86_64 requires /bin/sh gdal-python-1.5.1-5.fc9.x86_64 requires /usr/bin/env gdb-6.8-5.fc10.x86_64 requires /bin/sh gdb-6.8-5.fc10.x86_64 requires /sbin/install-info gdb-6.8-5.fc10.x86_64 requires /bin/sh gdbm-1.8.0-28.fc9.i386 requires /sbin/ldconfig gdbm-1.8.0-28.fc9.x86_64 requires /sbin/ldconfig gdbm-devel-1.8.0-28.fc9.i386 requires /bin/sh gdbm-devel-1.8.0-28.fc9.i386 requires /sbin/install-info gdbm-devel-1.8.0-28.fc9.x86_64 requires /bin/sh gdbm-devel-1.8.0-28.fc9.x86_64 requires /sbin/install-info gdeskcal-1.01-1.fc7.noarch requires /bin/sh gdeskcal-1.01-1.fc7.noarch requires /usr/bin/env gdesklets-0.36-1.fc9.x86_64 requires /bin/sh gdesklets-0.36-1.fc9.x86_64 requires /usr/bin/env gdevilspie-0.31-2.fc10.noarch requires /usr/bin/python 1:gdk-pixbuf-0.22.0-36.fc9.i386 requires /sbin/ldconfig 1:gdk-pixbuf-0.22.0-36.fc9.x86_64 requires /sbin/ldconfig 1:gdk-pixbuf-devel-0.22.0-36.fc9.i386 requires /bin/sh 1:gdk-pixbuf-devel-0.22.0-36.fc9.x86_64 requires /bin/sh 1:gdm-2.22.0-6.fc10.x86_64 requires /bin/sh 1:gdm-2.22.0-6.fc10.x86_64 requires /usr/sbin/useradd 1:gdm-2.22.0-6.fc10.x86_64 requires /sbin/nologin 1:gdm-2.22.0-6.fc10.x86_64 requires /bin/sh gdome2-0.8.1-6.2.fc9.i386 requires /sbin/ldconfig gdome2-0.8.1-6.2.fc9.x86_64 requires /sbin/ldconfig gdome2-devel-0.8.1-6.2.fc9.i386 requires /bin/sh gdome2-devel-0.8.1-6.2.fc9.x86_64 requires /bin/sh gds2pov-0.20080229-1.fc9.i386 requires /sbin/ldconfig gds2pov-0.20080229-1.fc9.x86_64 requires /sbin/ldconfig geant321-2006-29.fc9.x86_64 requires /bin/sh geant321-g77-2006-29.fc9.x86_64 requires /bin/sh geda-gattrib-20080127-2.fc9.x86_64 requires /bin/sh geda-gnetlist-20080127-1.fc9.x86_64 requires /usr/bin/gawk geda-gnetlist-20080127-1.fc9.x86_64 requires /bin/bash geda-gschem-20080127-2.fc9.x86_64 requires /bin/sh geda-gschem-20080127-2.fc9.x86_64 requires /bin/sh geda-utils-20080127-1.fc9.x86_64 requires /usr/bin/env geda-utils-20080127-1.fc9.x86_64 requires /usr/bin/python geda-utils-20080127-1.fc9.x86_64 requires /usr/bin/perl geda-utils-20080127-1.fc9.x86_64 requires /bin/bash 1:gedit-2.23.1-1.fc10.x86_64 requires /bin/sh 1:gedit-2.23.1-1.fc10.x86_64 requires /bin/sh gedit-plugins-2.22.0-1.fc9.x86_64 requires /bin/sh geeqie-1.0-0.4.alpha1.fc10.x86_64 requires /bin/sh gegl-0.0.16-1.fc9.i386 requires /sbin/ldconfig gegl-0.0.16-1.fc9.x86_64 requires /sbin/ldconfig gemdropx-0.9-4.fc9.x86_64 requires /bin/sh gengetopt-2.22-1.fc9.x86_64 requires /bin/sh gengetopt-2.22-1.fc9.x86_64 requires /sbin/install-info genisoimage-1.1.6-11.fc9.x86_64 requires /bin/sh genisoimage-1.1.6-11.fc9.x86_64 requires /usr/sbin/alternatives genisoimage-1.1.6-11.fc9.x86_64 requires /bin/sh genisoimage-1.1.6-11.fc9.x86_64 requires /usr/bin/perl gentium-fonts-1.02-5.fc7.noarch requires /bin/sh geoclue-0.11.1-4.fc10.i386 requires /sbin/ldconfig geoclue-0.11.1-4.fc10.x86_64 requires /sbin/ldconfig geomview-1.9.4-8.fc9.x86_64 requires /bin/sh geomview-1.9.4-8.fc9.x86_64 requires /sbin/install-info geomview-1.9.4-8.fc9.x86_64 requires /bin/sh geomview-libs-1.9.4-8.fc9.i386 requires /sbin/ldconfig geomview-libs-1.9.4-8.fc9.x86_64 requires /sbin/ldconfig geoqo-0.96-5.fc9.noarch requires /usr/bin/perl geos-3.0.0-3.fc10.i386 requires /sbin/ldconfig geos-3.0.0-3.fc10.x86_64 requires /sbin/ldconfig geos-devel-3.0.0-3.fc10.i386 requires /bin/sh geos-devel-3.0.0-3.fc10.x86_64 requires /bin/sh gerbv-2.0.0-1.fc9.x86_64 requires /bin/sh gerbv-2.0.0-1.fc9.x86_64 requires /usr/bin/perl geronimo-specs-1.0-1.M2.2jpp.12.x86_64 requires /bin/sh getmail-4.8.1-1.fc9.noarch requires /usr/bin/python gettext-0.17-5.fc10.i386 requires /bin/sh gettext-0.17-5.fc10.i386 requires /sbin/install-info gettext-0.17-5.fc10.i386 requires /usr/bin/python gettext-0.17-5.fc10.i386 requires /sbin/ldconfig gettext-0.17-5.fc10.i386 requires /bin/sh gettext-0.17-5.fc10.x86_64 requires /bin/sh gettext-0.17-5.fc10.x86_64 requires /sbin/install-info gettext-0.17-5.fc10.x86_64 requires /usr/bin/python gettext-0.17-5.fc10.x86_64 requires /sbin/ldconfig gettext-0.17-5.fc10.x86_64 requires /bin/sh gettext-devel-0.17-5.fc10.i386 requires /bin/sh gettext-devel-0.17-5.fc10.i386 requires /sbin/install-info gettext-devel-0.17-5.fc10.i386 requires /sbin/ldconfig gettext-devel-0.17-5.fc10.i386 requires /bin/sh gettext-devel-0.17-5.fc10.x86_64 requires /bin/sh gettext-devel-0.17-5.fc10.x86_64 requires /sbin/install-info gettext-devel-0.17-5.fc10.x86_64 requires /sbin/ldconfig gettext-devel-0.17-5.fc10.x86_64 requires /bin/sh gfa-0.4.1-6.fc9.x86_64 requires /bin/sh gforth-0.6.2-12.fc9.x86_64 requires /bin/sh gforth-0.6.2-12.fc9.x86_64 requires /usr/bin/gforth gforth-0.6.2-12.fc9.x86_64 requires /sbin/install-info gforth-0.6.2-12.fc9.x86_64 requires /bin/sh gfs-artemisia-fonts-20070415-6.fc10.noarch requires /bin/sh gfs-baskerville-fonts-20070327-7.fc10.noarch requires /bin/sh gfs-bodoni-classic-fonts-20070415-6.fc10.noarch requires /bin/sh gfs-bodoni-fonts-20070415-5.fc10.noarch requires /bin/sh gfs-complutum-fonts-20070413-7.fc10.noarch requires /bin/sh gfs-didot-classic-fonts-20070415-5.fc10.noarch requires /bin/sh gfs-didot-fonts-20070616-6.fc10.noarch requires /bin/sh gfs-gazis-fonts-20080318-2.fc10.noarch requires /bin/sh gfs-neohellenic-fonts-20070415-5.fc10.noarch requires /bin/sh gfs-olga-fonts-20060908-5.fc10.noarch requires /bin/sh gfs-porson-fonts-20060908-7.fc10.noarch requires /bin/sh gfs-solomos-fonts-20071114-6.fc10.noarch requires /bin/sh gfs-theokritos-fonts-20070415-6.fc10.noarch requires /bin/sh gfs2-utils-2.03.00-4.fc10.x86_64 requires /bin/sh gfs2-utils-2.03.00-4.fc10.x86_64 requires /bin/bash gfs2-utils-2.03.00-4.fc10.x86_64 requires /sbin/chkconfig gfs2-utils-2.03.00-4.fc10.x86_64 requires /sbin/service 2:gftp-2.0.18-3.fc9.x86_64 requires /bin/sh gg2-libs-2.3.0-9.fc9.i386 requires /sbin/ldconfig gg2-libs-2.3.0-9.fc9.x86_64 requires /sbin/ldconfig ggobi-2.1.7-1.fc9.i386 requires /sbin/ldconfig ggobi-2.1.7-1.fc9.x86_64 requires /sbin/ldconfig ggz-client-libs-0.0.14.1-1.fc9.i386 requires /sbin/ldconfig ggz-client-libs-0.0.14.1-1.fc9.x86_64 requires /sbin/ldconfig ggz-gtk-client-0.0.14.1-1.fc9.i386 requires /sbin/ldconfig ggz-gtk-client-0.0.14.1-1.fc9.x86_64 requires /sbin/ldconfig ghc-6.8.2-2.fc9.x86_64 requires /bin/sh ghc-6.8.2-2.fc9.x86_64 requires /usr/bin/perl ghc-6.8.2-2.fc9.x86_64 requires /bin/sh ghc682-6.8.2-2.fc9.x86_64 requires /bin/sh ghc682-6.8.2-2.fc9.x86_64 requires /usr/bin/perl ghc682-6.8.2-2.fc9.x86_64 requires /bin/sh ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.x86_64 requires /bin/sh ghdl-0.26-0.94svn.7.fc10.x86_64 requires /bin/sh ghdl-0.26-0.94svn.7.fc10.x86_64 requires /sbin/install-info ghex-2.22.0-1.i386 requires /sbin/ldconfig ghex-2.22.0-1.i386 requires /bin/sh ghex-2.22.0-1.x86_64 requires /bin/sh ghex-2.22.0-1.x86_64 requires /sbin/ldconfig ghostscript-8.62-3.fc9.i386 requires /sbin/ldconfig ghostscript-8.62-3.fc9.i386 requires /usr/bin/perl ghostscript-8.62-3.fc9.i386 requires /bin/sh ghostscript-8.62-3.fc9.x86_64 requires /sbin/ldconfig ghostscript-8.62-3.fc9.x86_64 requires /usr/bin/perl ghostscript-8.62-3.fc9.x86_64 requires /bin/sh ghostscript-devel-8.62-3.fc9.i386 requires /bin/sh ghostscript-devel-8.62-3.fc9.x86_64 requires /bin/sh ghostscript-fonts-5.50-18.fc8.noarch requires /bin/sh ghostscript-fonts-5.50-18.fc8.noarch requires /usr/bin/mkfontscale ghostscript-fonts-5.50-18.fc8.noarch requires /usr/bin/mkfontdir giblib-1.2.4-11.i386 requires /sbin/ldconfig giblib-1.2.4-11.x86_64 requires /sbin/ldconfig giblib-devel-1.2.4-11.i386 requires /bin/sh giblib-devel-1.2.4-11.x86_64 requires /bin/sh giflib-4.1.3-9.i386 requires /sbin/ldconfig giflib-4.1.3-9.x86_64 requires /sbin/ldconfig giflib-utils-4.1.3-9.x86_64 requires /usr/bin/perl giflib-utils-4.1.3-9.x86_64 requires /bin/sh gift-0.11.8.1-10.fc9.i386 requires /sbin/ldconfig gift-0.11.8.1-10.fc9.i386 requires /usr/bin/perl gift-0.11.8.1-10.fc9.i386 requires /bin/bash gift-0.11.8.1-10.fc9.x86_64 requires /sbin/ldconfig gift-0.11.8.1-10.fc9.x86_64 requires /usr/bin/perl gift-0.11.8.1-10.fc9.x86_64 requires /bin/bash gift-gnutella-0.0.11-5.fc9.x86_64 requires /sbin/ldconfig giggle-0.4-2.fc9.x86_64 requires /bin/sh gimmage-0.2.3-2.fc9.x86_64 requires /bin/sh gimmie-0.2.8-2.fc9.x86_64 requires /bin/sh gimmie-0.2.8-2.fc9.x86_64 requires /usr/bin/python 2:gimp-2.4.5-1.fc9.x86_64 requires /bin/sh 2:gimp-2.4.5-1.fc9.x86_64 requires /usr/bin/update-desktop-database 2:gimp-2.4.5-1.fc9.x86_64 requires /usr/bin/env 2:gimp-2.4.5-1.fc9.x86_64 requires /bin/bash 2:gimp-2.4.5-1.fc9.x86_64 requires /bin/sh 2:gimp-libs-2.4.5-1.fc9.i386 requires /sbin/ldconfig 2:gimp-libs-2.4.5-1.fc9.x86_64 requires /sbin/ldconfig ginac-1.4.3-1.fc10.i386 requires /sbin/ldconfig ginac-1.4.3-1.fc10.i386 requires /sbin/install-info ginac-1.4.3-1.fc10.x86_64 requires /sbin/ldconfig ginac-1.4.3-1.fc10.x86_64 requires /sbin/install-info ginac-devel-1.4.3-1.fc10.i386 requires /bin/sh ginac-devel-1.4.3-1.fc10.x86_64 requires /bin/sh ginac-utils-1.4.3-1.fc10.x86_64 requires /bin/sh git-1.5.5.1-1.fc10.x86_64 requires /usr/bin/perl git-1.5.5.1-1.fc10.x86_64 requires /bin/sh git-arch-1.5.5.1-1.fc10.x86_64 requires /usr/bin/perl git-cvs-1.5.5.1-1.fc10.x86_64 requires /usr/bin/perl git-email-1.5.5.1-1.fc10.x86_64 requires /usr/bin/perl git-gui-1.5.5.1-1.fc10.x86_64 requires /bin/sh git-svn-1.5.5.1-1.fc10.x86_64 requires /usr/bin/perl gitk-1.5.5.1-1.fc10.x86_64 requires /bin/sh gitweb-1.5.5.1-1.fc10.x86_64 requires /usr/bin/perl gjots2-2.3.4-8.fc10.noarch requires /bin/sh gjots2-2.3.4-8.fc10.noarch requires /usr/bin/env gkrellm-2.3.1-3.fc9.x86_64 requires /bin/sh gkrellm-daemon-2.3.1-3.fc9.x86_64 requires /bin/sh gkrellm-daemon-2.3.1-3.fc9.x86_64 requires /bin/bash gkrellm-daemon-2.3.1-3.fc9.x86_64 requires /sbin/chkconfig gkrellm-daemon-2.3.1-3.fc9.x86_64 requires /sbin/service gkrellm-weather-2.0.7-6.fc9.x86_64 requires /usr/bin/perl glabels-2.2.2-1.fc10.x86_64 requires /bin/sh glabels-2.2.2-1.fc10.x86_64 requires /sbin/ldconfig glabels-doc-2.2.2-1.fc10.x86_64 requires /bin/sh glabels-libs-2.2.2-1.fc10.i386 requires /sbin/ldconfig glabels-libs-2.2.2-1.fc10.x86_64 requires /sbin/ldconfig glade3-3.4.4-1.fc9.x86_64 requires /bin/sh glade3-libgladeui-3.4.4-1.fc9.i386 requires /sbin/ldconfig glade3-libgladeui-3.4.4-1.fc9.x86_64 requires /sbin/ldconfig glaxium-0.5-4.fc9.x86_64 requires /bin/sh glest-3.1.2-1.fc9.x86_64 requires /bin/sh glew-1.5.0-2.fc9.i386 requires /sbin/ldconfig glew-1.5.0-2.fc9.x86_64 requires /sbin/ldconfig glglobe-0.2-6.fc9.x86_64 requires /bin/sh 1:glib-1.2.10-29.fc9.i386 requires /sbin/ldconfig 1:glib-1.2.10-29.fc9.x86_64 requires /sbin/ldconfig 1:glib-devel-1.2.10-29.fc9.i386 requires /bin/sh 1:glib-devel-1.2.10-29.fc9.x86_64 requires /bin/sh glib-java-0.2.6-12.fc9.i386 requires /sbin/ldconfig glib-java-0.2.6-12.fc9.i386 requires /sbin/ldconfig glib-java-0.2.6-12.fc9.x86_64 requires /sbin/ldconfig glib-java-0.2.6-12.fc9.x86_64 requires /sbin/ldconfig glib2-2.16.3-5.fc10.i386 requires /sbin/ldconfig glib2-2.16.3-5.fc10.x86_64 requires /sbin/ldconfig glib2-devel-2.16.3-5.fc10.i386 requires /usr/bin/perl glib2-devel-2.16.3-5.fc10.i386 requires /bin/sh glib2-devel-2.16.3-5.fc10.x86_64 requires /usr/bin/perl glib2-devel-2.16.3-5.fc10.x86_64 requires /bin/sh glibc-2.8.90-2.i386 requires /sbin/ldconfig glibc-2.8.90-2.i386 requires /usr/sbin/glibc_post_upgrade.i386 glibc-2.8.90-2.i686 requires /usr/sbin/glibc_post_upgrade.i686 glibc-2.8.90-2.i686 requires /sbin/ldconfig glibc-2.8.90-2.x86_64 requires /sbin/ldconfig glibc-2.8.90-2.x86_64 requires /usr/sbin/glibc_post_upgrade.x86_64 glibc-common-2.8.90-2.x86_64 requires /usr/sbin/build-locale-archive glibc-common-2.8.90-2.x86_64 requires /bin/bash glibc-common-2.8.90-2.x86_64 requires /usr/sbin/tzdata-update glibc-common-2.8.90-2.x86_64 requires /bin/sh glibc-devel-2.8.90-2.i386 requires /bin/sh glibc-devel-2.8.90-2.i386 requires /sbin/install-info glibc-devel-2.8.90-2.x86_64 requires /bin/sh glibc-devel-2.8.90-2.x86_64 requires /sbin/install-info glibc-headers-2.8.90-2.x86_64 requires /bin/sh glibc-utils-2.8.90-2.x86_64 requires /sbin/ldconfig glibc-utils-2.8.90-2.x86_64 requires /bin/bash glibc-utils-2.8.90-2.x86_64 requires /usr/bin/perl glibmm24-2.16.0-1.fc9.i386 requires /sbin/ldconfig glibmm24-2.16.0-1.fc9.x86_64 requires /sbin/ldconfig glibmm24-devel-2.16.0-1.fc9.i386 requires /usr/bin/perl glibmm24-devel-2.16.0-1.fc9.x86_64 requires /usr/bin/perl glimmer-3.02-3.fc9.x86_64 requires /bin/csh glimmer-3.02-3.fc9.x86_64 requires /bin/awk glipper-1.0-3.fc9.x86_64 requires /bin/sh glipper-1.0-3.fc9.x86_64 requires /usr/bin/env glitz-0.5.6-6.fc9.i386 requires /sbin/ldconfig glitz-0.5.6-6.fc9.x86_64 requires /sbin/ldconfig glitz-glx-0.5.6-6.fc9.i386 requires /sbin/ldconfig glitz-glx-0.5.6-6.fc9.x86_64 requires /sbin/ldconfig gliv-1.9.6-3.fc9.x86_64 requires /bin/sh glob2-0.9.3-1.fc10.x86_64 requires /bin/sh global-5.4-2.fc9.x86_64 requires /bin/sh glom-1.6.15-1.fc9.i386 requires /sbin/ldconfig glom-1.6.15-1.fc9.i386 requires /bin/sh glom-1.6.15-1.fc9.x86_64 requires /bin/sh glom-1.6.15-1.fc9.x86_64 requires /sbin/ldconfig glpi-0.70.2-3.fc10.noarch requires /bin/sh glpi-0.70.2-3.fc10.noarch requires /sbin/service glpi-0.70.2-3.fc10.noarch requires /etc/logrotate.d glpi-mass-ocs-import-1.1-1.fc9.noarch requires /bin/sh glpi-mass-ocs-import-1.1-1.fc9.noarch requires /bin/sh glpi-mass-ocs-import-1.1-1.fc9.noarch requires /etc/cron.d glpk-4.28-1.fc10.i386 requires /sbin/ldconfig glpk-4.28-1.fc10.x86_64 requires /sbin/ldconfig glpk-utils-4.28-1.fc10.x86_64 requires /bin/sh glump-0.9.11-3.fc8.noarch requires /usr/bin/python glunarclock-0.32.4-11.fc9.x86_64 requires /bin/sh glusterfs-client-1.3.9-1.fc10.x86_64 requires /bin/sh glusterfs-libs-1.3.9-1.fc10.i386 requires /sbin/ldconfig glusterfs-libs-1.3.9-1.fc10.x86_64 requires /sbin/ldconfig glusterfs-server-1.3.9-1.fc10.x86_64 requires /bin/sh glusterfs-server-1.3.9-1.fc10.x86_64 requires /bin/sh glyph-keeper-0.32-4.fc9.i386 requires /sbin/ldconfig glyph-keeper-0.32-4.fc9.x86_64 requires /sbin/ldconfig gmediaserver-0.13.0-3.fc9.x86_64 requires /bin/sh gmediaserver-0.13.0-3.fc9.x86_64 requires /sbin/install-info gmediaserver-0.13.0-3.fc9.x86_64 requires /bin/bash gmediaserver-0.13.0-3.fc9.x86_64 requires /sbin/chkconfig gmfsk-0.7-0.5.pre1.fc9.x86_64 requires /bin/sh gmime-2.2.19-1.fc10.i386 requires /sbin/ldconfig gmime-2.2.19-1.fc10.x86_64 requires /sbin/ldconfig gmime-devel-2.2.19-1.fc10.i386 requires /bin/sh gmime-devel-2.2.19-1.fc10.x86_64 requires /bin/sh gmp-4.2.2-7.fc9.i386 requires /sbin/ldconfig gmp-4.2.2-7.fc9.x86_64 requires /sbin/ldconfig gmp-devel-4.2.2-7.fc9.i386 requires /bin/sh gmp-devel-4.2.2-7.fc9.i386 requires /sbin/install-info gmp-devel-4.2.2-7.fc9.x86_64 requires /bin/sh gmp-devel-4.2.2-7.fc9.x86_64 requires /sbin/install-info gmpc-0.15.5.0-3.fc9.x86_64 requires /bin/sh gmyth-0.7.1-1.fc9.i386 requires /sbin/ldconfig gmyth-0.7.1-1.fc9.x86_64 requires /sbin/ldconfig gnash-0.8.2-2.fc9.x86_64 requires /bin/sh gnash-0.8.2-2.fc9.x86_64 requires /sbin/install-info gnash-0.8.2-2.fc9.x86_64 requires /sbin/ldconfig gnash-0.8.2-2.fc9.x86_64 requires /bin/sh gnash-plugin-0.8.2-2.fc9.x86_64 requires /usr/lib64/mozilla/plugins gnet2-2.0.7-11.fc9.i386 requires /sbin/ldconfig gnet2-2.0.7-11.fc9.x86_64 requires /sbin/ldconfig gnochm-0.9.11-2.fc9.noarch requires /bin/sh gnochm-0.9.11-2.fc9.noarch requires /usr/bin/python gnofract4d-3.8-1.fc9.x86_64 requires /bin/sh gnofract4d-3.8-1.fc9.x86_64 requires /usr/bin/env gnofract4d-3.8-1.fc9.x86_64 requires /usr/bin/python gnokii-0.6.24-1.fc9.i386 requires /bin/sh gnokii-0.6.24-1.fc9.i386 requires /usr/sbin/groupadd gnokii-0.6.24-1.fc9.i386 requires /sbin/ldconfig gnokii-0.6.24-1.fc9.x86_64 requires /bin/sh gnokii-0.6.24-1.fc9.x86_64 requires /sbin/ldconfig gnokii-0.6.24-1.fc9.x86_64 requires /usr/sbin/groupadd gnokii-smsd-0.6.24-1.fc9.x86_64 requires /bin/sh gnokii-smsd-0.6.24-1.fc9.x86_64 requires /bin/bash gnokii-smsd-0.6.24-1.fc9.x86_64 requires /sbin/chkconfig gnokii-smsd-0.6.24-1.fc9.x86_64 requires /usr/sbin/useradd gnokii-smsd-0.6.24-1.fc9.x86_64 requires /bin/sh gnome-applet-music-2.3.1-1.fc10.x86_64 requires /bin/sh gnome-applet-music-2.3.1-1.fc10.x86_64 requires /usr/bin/env gnome-applet-netspeed-0.14-3.fc9.x86_64 requires /bin/sh gnome-applet-sensors-1.8.2-2.fc9.x86_64 requires /bin/sh gnome-applet-sshmenu-3.15-5.fc9.noarch requires /bin/sh gnome-applet-sshmenu-3.15-5.fc9.noarch requires /usr/bin/ruby gnome-applet-timer-2.0.1-1.fc9.x86_64 requires /bin/sh gnome-applet-timer-2.0.1-1.fc9.x86_64 requires /usr/bin/env gnome-applet-vm-0.2.0-2.fc9.x86_64 requires /bin/sh gnome-applet-vm-0.2.0-2.fc9.x86_64 requires /sbin/ldconfig gnome-applet-vm-0.2.0-2.fc9.x86_64 requires /usr/bin/gconftool-2 gnome-applet-vm-0.2.0-2.fc9.x86_64 requires /usr/bin/scrollkeeper-update 1:gnome-applets-2.23.2-1.fc10.x86_64 requires /bin/sh 1:gnome-applets-2.23.2-1.fc10.x86_64 requires /usr/bin/env gnome-bluetooth-0.11.0-3.fc9.x86_64 requires /bin/sh gnome-bluetooth-libs-0.11.0-3.fc9.i386 requires /sbin/ldconfig gnome-bluetooth-libs-0.11.0-3.fc9.x86_64 requires /sbin/ldconfig gnome-build-0.2.4-1.fc9.i386 requires /sbin/ldconfig gnome-build-0.2.4-1.fc9.i386 requires /usr/bin/perl gnome-build-0.2.4-1.fc9.x86_64 requires /sbin/ldconfig gnome-build-0.2.4-1.fc9.x86_64 requires /usr/bin/perl gnome-chemistry-utils-0.8.7-1.fc9.i386 requires /bin/sh gnome-chemistry-utils-0.8.7-1.fc9.x86_64 requires /bin/sh gnome-chemistry-utils-mozplugin-0.8.7-1.fc9.x86_64 requires /usr/lib64/mozilla/plugins gnome-commander-1.2.5-1.fc9.x86_64 requires /bin/sh gnome-common-2.18.0-1.fc8.noarch requires /bin/sh gnome-compiz-manager-0.10.4-4.fc9.i386 requires /sbin/ldconfig gnome-compiz-manager-0.10.4-4.fc9.i386 requires /bin/sh gnome-compiz-manager-0.10.4-4.fc9.x86_64 requires /bin/sh gnome-compiz-manager-0.10.4-4.fc9.x86_64 requires /sbin/ldconfig gnome-desktop-2.23.2-0.2008.05.14.1.fc10.i386 requires /usr/bin/python gnome-desktop-2.23.2-0.2008.05.14.1.fc10.i386 requires /sbin/ldconfig gnome-desktop-2.23.2-0.2008.05.14.1.fc10.x86_64 requires /usr/bin/python gnome-desktop-2.23.2-0.2008.05.14.1.fc10.x86_64 requires /sbin/ldconfig gnome-device-manager-0.2-3.fc9.x86_64 requires /bin/sh gnome-device-manager-devel-0.2-3.fc9.i386 requires /sbin/ldconfig gnome-device-manager-devel-0.2-3.fc9.x86_64 requires /sbin/ldconfig gnome-device-manager-libs-0.2-3.fc9.i386 requires /sbin/ldconfig gnome-device-manager-libs-0.2-3.fc9.x86_64 requires /sbin/ldconfig gnome-do-0.4.2.0-1.fc10.x86_64 requires /bin/sh gnome-doc-utils-0.12.2-1.fc9.noarch requires /bin/sh gnome-doc-utils-0.12.2-1.fc9.noarch requires /usr/bin/python 1:gnome-games-2.23.1-2.fc10.x86_64 requires /bin/sh 1:gnome-games-2.23.1-2.fc10.x86_64 requires /usr/bin/env gnome-genius-1.0.2-3.fc9.x86_64 requires /bin/sh gnome-icon-theme-2.22.0-6.fc9.noarch requires /bin/sh gnome-keyring-2.22.1-1.fc9.i386 requires /sbin/ldconfig gnome-keyring-2.22.1-1.fc9.i386 requires /bin/sh gnome-keyring-2.22.1-1.fc9.x86_64 requires /bin/sh gnome-keyring-2.22.1-1.fc9.x86_64 requires /sbin/ldconfig gnome-keyring-manager-2.20.0-2.fc9.x86_64 requires /bin/sh gnome-launch-box-0.4-9.fc10.x86_64 requires /bin/sh 1:gnome-libs-1.4.2-8.fc9.i386 requires /sbin/ldconfig 1:gnome-libs-1.4.2-8.fc9.i386 requires /bin/sh 1:gnome-libs-1.4.2-8.fc9.x86_64 requires /sbin/ldconfig 1:gnome-libs-1.4.2-8.fc9.x86_64 requires /bin/sh 1:gnome-libs-devel-1.4.2-8.fc9.i386 requires /bin/sh 1:gnome-libs-devel-1.4.2-8.fc9.i386 requires /usr/bin/perl 1:gnome-libs-devel-1.4.2-8.fc9.x86_64 requires /bin/sh 1:gnome-libs-devel-1.4.2-8.fc9.x86_64 requires /usr/bin/perl gnome-mag-0.15.0-2.fc9.i386 requires /sbin/ldconfig gnome-mag-0.15.0-2.fc9.x86_64 requires /sbin/ldconfig gnome-media-2.23.1.1-2.fc10.i386 requires /bin/sh gnome-media-2.23.1.1-2.fc10.x86_64 requires /bin/sh gnome-menus-2.23.1-1.fc10.i386 requires /sbin/ldconfig gnome-menus-2.23.1-1.fc10.x86_64 requires /sbin/ldconfig gnome-mount-0.8-1.fc9.x86_64 requires /bin/sh gnome-nds-thumbnailer-1.0.2-1.fc9.x86_64 requires /bin/sh gnome-netstatus-2.12.1-4.fc9.x86_64 requires /bin/sh gnome-nettool-2.22.0-1.fc9.x86_64 requires /bin/sh gnome-packagekit-0.2.1-2.20080508.fc10.x86_64 requires /bin/sh gnome-packagekit-0.2.1-2.20080508.fc10.x86_64 requires /usr/bin/python gnome-panel-2.23.2.1-1.fc10.x86_64 requires /bin/sh gnome-password-generator-1.5-2.fc9.noarch requires /bin/sh gnome-password-generator-1.5-2.fc9.noarch requires /usr/bin/python gnome-phone-manager-0.51-2.fc10.x86_64 requires /bin/sh gnome-pilot-2.0.16-2.fc9.i386 requires /bin/sh gnome-pilot-2.0.16-2.fc9.x86_64 requires /bin/sh gnome-pilot-conduits-2.0.16-1.fc9.x86_64 requires /sbin/ldconfig gnome-power-manager-2.22.1-1.fc9.x86_64 requires /bin/sh gnome-power-manager-2.22.1-1.fc9.x86_64 requires /bin/sh gnome-ppp-0.3.23-5.fc9.x86_64 requires /bin/sh gnome-python2-bonobo-2.22.0-2.fc9.x86_64 requires /usr/bin/env gnome-python2-bonobo-2.22.0-2.fc9.x86_64 requires /bin/sh gnome-python2-gconf-2.22.0-2.fc9.x86_64 requires /usr/bin/env gnome-python2-gnomeprint-2.22.0-4.fc10.x86_64 requires /usr/bin/env gnome-python2-gnomevfs-2.22.0-2.fc9.x86_64 requires /usr/bin/env gnome-python2-libegg-2.19.1-15.fc9.x86_64 requires /usr/bin/python gnome-scan-0.6-2.fc9.x86_64 requires /bin/sh gnome-scan-libs-0.6-2.fc9.i386 requires /sbin/ldconfig gnome-scan-libs-0.6-2.fc9.x86_64 requires /sbin/ldconfig gnome-schedule-2.0.2-1.fc9.noarch requires /bin/sh gnome-schedule-2.0.2-1.fc9.noarch requires /bin/sh gnome-screensaver-2.23.3-0.2008.05.14.1.fc10.x86_64 requires /bin/sh gnome-session-2.23.2.2-3.fc10.x86_64 requires /bin/sh gnome-session-2.23.2.2-3.fc10.x86_64 requires /bin/sh gnome-settings-daemon-2.23.2-0.2008.05.14.2.fc10.x86_64 requires /bin/sh gnome-sharp-2.16.1-1.fc9.x86_64 requires /sbin/ldconfig gnome-sharp-2.16.1-1.fc9.x86_64 requires /bin/sh gnome-specimen-0.3-1.fc8.noarch requires /bin/sh gnome-specimen-0.3-1.fc8.noarch requires /usr/bin/python gnome-speech-0.4.19-1.fc10.i386 requires /sbin/ldconfig gnome-speech-0.4.19-1.fc10.x86_64 requires /sbin/ldconfig gnome-system-monitor-2.22.1-5.fc9.x86_64 requires /bin/sh gnome-terminal-2.22.1-1.fc9.x86_64 requires /bin/sh gnome-themes-2.23.1-1.fc10.noarch requires /bin/sh gnome-translate-0.99-12.fc9.x86_64 requires /bin/sh gnome-user-docs-2.22.0-1.fc9.noarch requires /bin/sh gnome-user-share-0.31-1.fc9.x86_64 requires /bin/sh 1:gnome-utils-2.20.0.1-5.fc10.i386 requires /bin/sh 1:gnome-utils-2.20.0.1-5.fc10.x86_64 requires /bin/sh gnome-vfs2-2.22.0-1.fc9.i386 requires /bin/sh gnome-vfs2-2.22.0-1.fc9.i386 requires /sbin/ldconfig gnome-vfs2-2.22.0-1.fc9.x86_64 requires /bin/sh gnome-vfs2-2.22.0-1.fc9.x86_64 requires /sbin/ldconfig gnome-vfs2-monikers-2.15.3-5.fc9.x86_64 requires /sbin/ldconfig gnome-vfsmm26-2.22.0-1.fc9.i386 requires /bin/sh gnome-vfsmm26-2.22.0-1.fc9.i386 requires /sbin/ldconfig gnome-vfsmm26-2.22.0-1.fc9.x86_64 requires /bin/sh gnome-vfsmm26-2.22.0-1.fc9.x86_64 requires /sbin/ldconfig gnome-volume-manager-2.22.5-1.fc10.x86_64 requires /bin/sh gnome-volume-manager-2.22.5-1.fc10.x86_64 requires /bin/sh gnome-web-photo-0.3-11.fc9.x86_64 requires /bin/sh gnomebaker-0.6.2-2.1.fc9.x86_64 requires /bin/sh gnomecatalog-0.3.4-3.fc9.noarch requires /usr/bin/python gnomeradio-1.7-5.fc9.x86_64 requires /bin/sh gnomesword-2.3.3-2.fc9.x86_64 requires /bin/sh gnotime-2.3.0-1.fc9.x86_64 requires /bin/sh gnotime-2.3.0-1.fc9.x86_64 requires /bin/sh gnu-getopt-1.0.12-4jpp.1.x86_64 requires /bin/sh gnu-getopt-javadoc-1.0.12-4jpp.1.x86_64 requires /bin/sh gnu-getopt-javadoc-1.0.12-4jpp.1.x86_64 requires /bin/ln gnu-getopt-javadoc-1.0.12-4jpp.1.x86_64 requires /bin/rm gnu-smalltalk-3.0.1-3.fc9.i386 requires /bin/sh gnu-smalltalk-3.0.1-3.fc9.i386 requires /bin/sed gnu-smalltalk-3.0.1-3.fc9.i386 requires /sbin/install-info gnu-smalltalk-3.0.1-3.fc9.i386 requires /sbin/ldconfig gnu-smalltalk-3.0.1-3.fc9.i386 requires /usr/bin/perl gnu-smalltalk-3.0.1-3.fc9.i386 requires /bin/sh gnu-smalltalk-3.0.1-3.fc9.x86_64 requires /bin/sh gnu-smalltalk-3.0.1-3.fc9.x86_64 requires /bin/sed gnu-smalltalk-3.0.1-3.fc9.x86_64 requires /sbin/install-info gnu-smalltalk-3.0.1-3.fc9.x86_64 requires /sbin/ldconfig gnu-smalltalk-3.0.1-3.fc9.x86_64 requires /usr/bin/perl gnu-smalltalk-3.0.1-3.fc9.x86_64 requires /bin/sh gnu-smalltalk-devel-3.0.1-3.fc9.i386 requires /bin/sh gnu-smalltalk-devel-3.0.1-3.fc9.x86_64 requires /bin/sh gnubg-20061119-14.fc9.x86_64 requires /bin/sh gnubg-20061119-14.fc9.x86_64 requires /sbin/install-info gnubiff-2.2.7-4.fc9.x86_64 requires /bin/sh gnubiff-2.2.7-4.fc9.x86_64 requires /sbin/install-info gnucap-0.35-4.fc9.x86_64 requires /bin/sh gnucash-2.2.4-1.fc9.x86_64 requires /bin/sh gnucash-2.2.4-1.fc9.x86_64 requires /sbin/ldconfig gnucash-2.2.4-1.fc9.x86_64 requires /usr/bin/perl gnucash-2.2.4-1.fc9.x86_64 requires /bin/sh gnucash-docs-2.2.0-2.fc8.noarch requires /bin/sh gnucash-docs-2.2.0-2.fc8.noarch requires /usr/bin/scrollkeeper-update gnue-common-0.6.9-4.fc10.noarch requires /usr/bin/python gnugo-3.6-6.fc9.x86_64 requires /bin/sh 1:gnumeric-1.8.2-2.fc9.i386 requires /sbin/ldconfig 1:gnumeric-1.8.2-2.fc9.i386 requires /bin/sh 1:gnumeric-1.8.2-2.fc9.x86_64 requires /bin/sh 1:gnumeric-1.8.2-2.fc9.x86_64 requires /sbin/ldconfig 1:gnumeric-plugins-extras-1.8.2-2.fc9.x86_64 requires /usr/bin/perl gnupg-1.4.9-1.fc9.x86_64 requires /bin/sh gnupg-1.4.9-1.fc9.x86_64 requires /sbin/install-info gnupg-1.4.9-1.fc9.x86_64 requires /bin/sh gnupg2-2.0.9-1.fc9.x86_64 requires /bin/sh gnupg2-2.0.9-1.fc9.x86_64 requires /sbin/install-info gnupg2-2.0.9-1.fc9.x86_64 requires /bin/sh gnuplot-4.2.3-1.fc10.x86_64 requires /bin/sh gnuplot-4.2.3-1.fc10.x86_64 requires /sbin/install-info gnuradio-3.1.1-4.fc9.i386 requires /sbin/ldconfig gnuradio-3.1.1-4.fc9.x86_64 requires /sbin/ldconfig gnuradio-devel-3.1.1-4.fc9.i386 requires /sbin/ldconfig gnuradio-devel-3.1.1-4.fc9.x86_64 requires /sbin/ldconfig gnustep-make-2.0.4-9.fc9.x86_64 requires /bin/sh gnutls-2.0.4-2.fc9.i386 requires /sbin/ldconfig gnutls-2.0.4-2.fc9.x86_64 requires /sbin/ldconfig gnutls-devel-2.0.4-2.fc9.i386 requires /bin/sh gnutls-devel-2.0.4-2.fc9.i386 requires /sbin/install-info gnutls-devel-2.0.4-2.fc9.i386 requires /bin/sh gnutls-devel-2.0.4-2.fc9.x86_64 requires /bin/sh gnutls-devel-2.0.4-2.fc9.x86_64 requires /sbin/install-info gnutls-devel-2.0.4-2.fc9.x86_64 requires /bin/sh gobby-0.4.5-3.fc9.x86_64 requires /bin/sh goffice-0.6.2-1.fc9.i386 requires /sbin/ldconfig goffice-0.6.2-1.fc9.x86_64 requires /sbin/ldconfig goffice04-0.4.3-3.fc9.i386 requires /sbin/ldconfig goffice04-0.4.3-3.fc9.x86_64 requires /sbin/ldconfig gok-1.3.7-3.fc9.x86_64 requires /bin/sh gonvert-0.2.19-3.fc9.noarch requires /usr/bin/python goocanvas-0.9-4.fc9.i386 requires /sbin/ldconfig goocanvas-0.9-4.fc9.x86_64 requires /sbin/ldconfig goocanvasmm-0.4.0-3.fc9.i386 requires /sbin/ldconfig goocanvasmm-0.4.0-3.fc9.x86_64 requires /sbin/ldconfig google-perftools-0.95-4.fc9.i386 requires /usr/bin/env google-perftools-0.95-4.fc9.i386 requires /sbin/ldconfig google-perftools-0.95-4.fc9.x86_64 requires /usr/bin/env google-perftools-0.95-4.fc9.x86_64 requires /sbin/ldconfig gossip-0.29-2.fc10.x86_64 requires /bin/sh gourmet-0.13.4-3.fc9.noarch requires /usr/bin/python gpa-0.7.6-5.fc10.x86_64 requires /bin/sh gpar2-0.3-6.fc9.x86_64 requires /bin/sh gparted-0.3.7-1.fc10.x86_64 requires /bin/sh gparted-0.3.7-1.fc10.x86_64 requires /bin/bash gperf-3.0.3-4.fc9.x86_64 requires /bin/sh gperf-3.0.3-4.fc9.x86_64 requires /sbin/install-info gpgme-1.1.6-3.fc9.i386 requires /sbin/ldconfig gpgme-1.1.6-3.fc9.x86_64 requires /sbin/ldconfig gpgme-devel-1.1.6-3.fc9.i386 requires /bin/sh gpgme-devel-1.1.6-3.fc9.i386 requires /sbin/install-info gpgme-devel-1.1.6-3.fc9.i386 requires /bin/sh gpgme-devel-1.1.6-3.fc9.x86_64 requires /bin/sh gpgme-devel-1.1.6-3.fc9.x86_64 requires /sbin/install-info gpgme-devel-1.1.6-3.fc9.x86_64 requires /bin/sh gphoto2-2.4.0-10.fc9.i386 requires /bin/sh gphoto2-2.4.0-10.fc9.i386 requires /bin/bash gphoto2-2.4.0-10.fc9.x86_64 requires /bin/sh gphoto2-2.4.0-10.fc9.x86_64 requires /bin/bash gphoto2-devel-2.4.0-10.fc9.i386 requires /bin/sh gphoto2-devel-2.4.0-10.fc9.x86_64 requires /bin/sh gpixpod-0.6.2-3.fc9.x86_64 requires /bin/bash gpm-1.20.1-90.fc9.i386 requires /bin/sh gpm-1.20.1-90.fc9.i386 requires /sbin/ldconfig gpm-1.20.1-90.fc9.i386 requires /bin/bash gpm-1.20.1-90.fc9.i386 requires /sbin/chkconfig gpm-1.20.1-90.fc9.i386 requires /sbin/install-info gpm-1.20.1-90.fc9.x86_64 requires /bin/sh gpm-1.20.1-90.fc9.x86_64 requires /sbin/ldconfig gpm-1.20.1-90.fc9.x86_64 requires /bin/bash gpm-1.20.1-90.fc9.x86_64 requires /sbin/chkconfig gpm-1.20.1-90.fc9.x86_64 requires /sbin/install-info gpodder-0.11.1-2.fc9.noarch requires /bin/sh gpodder-0.11.1-2.fc9.noarch requires /usr/bin/python gpredict-0.9.0-3.fc9.x86_64 requires /bin/sh gpsd-2.37-2.fc9.i386 requires /usr/bin/env gpsd-2.37-2.fc9.i386 requires /sbin/ldconfig gpsd-2.37-2.fc9.x86_64 requires /usr/bin/env gpsd-2.37-2.fc9.x86_64 requires /sbin/ldconfig gpsd-clients-2.37-2.fc9.x86_64 requires /usr/bin/env gpsd-devel-2.37-2.fc9.i386 requires /usr/bin/env gpsd-devel-2.37-2.fc9.x86_64 requires /usr/bin/env gpsdrive-2.09-5.fc9.i386 requires /sbin/ldconfig gpsdrive-2.09-5.fc9.i386 requires /bin/bash gpsdrive-2.09-5.fc9.i386 requires /bin/sh gpsdrive-2.09-5.fc9.i386 requires /usr/bin/perl gpsdrive-2.09-5.fc9.x86_64 requires /sbin/ldconfig gpsdrive-2.09-5.fc9.x86_64 requires /bin/bash gpsdrive-2.09-5.fc9.x86_64 requires /bin/sh gpsdrive-2.09-5.fc9.x86_64 requires /usr/bin/perl gpsim-0.22.0-5.fc8.i386 requires /sbin/ldconfig gpsim-0.22.0-5.fc8.x86_64 requires /sbin/ldconfig gpsman-6.3.2-3.fc9.noarch requires /bin/sh gq-1.3.4-1.fc9.x86_64 requires /bin/sh gquilt-0.20-3.fc9.noarch requires /bin/sh gquilt-0.20-3.fc9.noarch requires /bin/bash gqview-2.0.4-9.x86_64 requires /bin/sh grace-5.1.21-9.fc9.x86_64 requires /bin/sh grace-5.1.21-9.fc9.x86_64 requires /bin/sh gramps-2.2.10-1.fc9.noarch requires /bin/sh gramps-2.2.10-1.fc9.noarch requires /bin/sh graphviz-2.16.1-0.5.fc9.i386 requires /bin/sh graphviz-2.16.1-0.5.fc9.i386 requires /sbin/ldconfig graphviz-2.16.1-0.5.fc9.i386 requires /bin/sh graphviz-2.16.1-0.5.fc9.x86_64 requires /bin/sh graphviz-2.16.1-0.5.fc9.x86_64 requires /sbin/ldconfig graphviz-2.16.1-0.5.fc9.x86_64 requires /bin/sh graphviz-devil-2.16.1-0.5.fc9.x86_64 requires /bin/sh graphviz-gd-2.16.1-0.5.fc9.x86_64 requires /bin/sh graphviz-gd-2.16.1-0.5.fc9.x86_64 requires /sbin/ldconfig graphviz-gd-2.16.1-0.5.fc9.x86_64 requires /usr/bin/dot graphviz-tcl-2.16.1-0.5.fc9.x86_64 requires /bin/sh grass-6.3.0-0.4.RC6.fc9.x86_64 requires /usr/bin/python grass-6.3.0-0.4.RC6.fc9.x86_64 requires /bin/bash grass-6.3.0-0.4.RC6.fc9.x86_64 requires /bin/sh grass-libs-6.3.0-0.4.RC6.fc9.i386 requires /sbin/ldconfig grass-libs-6.3.0-0.4.RC6.fc9.x86_64 requires /sbin/ldconfig grep-2.5.1-59.fc9.x86_64 requires /bin/sh grep-2.5.1-59.fc9.x86_64 requires /sbin/install-info grepmail-5.3033-4.fc9.noarch requires /usr/bin/perl gresistor-0.0.1-11.fc8.noarch requires /bin/sh gresistor-0.0.1-11.fc8.noarch requires /usr/bin/python greyhounds-0.8-0.3.prealpha.fc9.x86_64 requires /bin/sh greylistd-0.8.3.2-8.fc7.noarch requires /bin/sh greylistd-0.8.3.2-8.fc7.noarch requires /bin/bash greylistd-0.8.3.2-8.fc7.noarch requires /sbin/chkconfig greylistd-0.8.3.2-8.fc7.noarch requires /usr/bin/python greylistd-0.8.3.2-8.fc7.noarch requires /sbin/service grhino-0.16.0-5.fc9.x86_64 requires /bin/sh gridengine-6.1u4-1.fc10.i386 requires /bin/sh gridengine-6.1u4-1.fc10.i386 requires /bin/ksh gridengine-6.1u4-1.fc10.i386 requires /usr/sbin/alternatives gridengine-6.1u4-1.fc10.i386 requires /bin/csh gridengine-6.1u4-1.fc10.i386 requires /sbin/ldconfig gridengine-6.1u4-1.fc10.i386 requires /usr/sbin/alternatives gridengine-6.1u4-1.fc10.i386 requires /bin/sh gridengine-6.1u4-1.fc10.x86_64 requires /bin/sh gridengine-6.1u4-1.fc10.x86_64 requires /bin/csh gridengine-6.1u4-1.fc10.x86_64 requires /bin/ksh gridengine-6.1u4-1.fc10.x86_64 requires /usr/sbin/alternatives gridengine-6.1u4-1.fc10.x86_64 requires /sbin/ldconfig gridengine-6.1u4-1.fc10.x86_64 requires /usr/sbin/alternatives gridengine-6.1u4-1.fc10.x86_64 requires /bin/sh gridengine-devel-6.1u4-1.fc10.i386 requires /bin/csh gridengine-devel-6.1u4-1.fc10.i386 requires /bin/sh gridengine-devel-6.1u4-1.fc10.x86_64 requires /bin/csh gridengine-devel-6.1u4-1.fc10.x86_64 requires /bin/sh gridengine-execd-6.1u4-1.fc10.x86_64 requires /bin/sh gridengine-execd-6.1u4-1.fc10.x86_64 requires /sbin/service gridengine-execd-6.1u4-1.fc10.x86_64 requires /bin/sh gridengine-execd-6.1u4-1.fc10.x86_64 requires /sbin/chkconfig gridengine-qmaster-6.1u4-1.fc10.x86_64 requires /bin/sh gridengine-qmaster-6.1u4-1.fc10.x86_64 requires /sbin/service gridengine-qmaster-6.1u4-1.fc10.x86_64 requires /bin/sh gridengine-qmaster-6.1u4-1.fc10.x86_64 requires /sbin/chkconfig grig-0.7.2-5.fc9.x86_64 requires /bin/sh grisbi-0.5.9-5.fc9.x86_64 requires /bin/sh groff-1.18.1.4-14.fc9.x86_64 requires /bin/sh groff-1.18.1.4-14.fc9.x86_64 requires /bin/sed groff-1.18.1.4-14.fc9.x86_64 requires /sbin/install-info groff-1.18.1.4-14.fc9.x86_64 requires /bin/bash groff-1.18.1.4-14.fc9.x86_64 requires /bin/sh groff-perl-1.18.1.4-14.fc9.x86_64 requires /usr/bin/perl groff-perl-1.18.1.4-14.fc9.x86_64 requires /bin/sh grsync-0.6.1-2.fc9.x86_64 requires /bin/bash grub-0.97-33.fc9.x86_64 requires /bin/sh grub-0.97-33.fc9.x86_64 requires /sbin/install-info grub-0.97-33.fc9.x86_64 requires /bin/sh grub-0.97-33.fc9.x86_64 requires /usr/bin/cmp gruler-0.8-3.fc9.noarch requires /usr/bin/ruby gruler-0.8-3.fc9.noarch requires /bin/bash gscan2pdf-0.9.21-2.fc9.noarch requires /bin/sh gscan2pdf-0.9.21-2.fc9.noarch requires /usr/bin/perl gshutdown-0.2-3.fc9.x86_64 requires /bin/sh gsl-1.10-10.fc9.i386 requires /sbin/ldconfig gsl-1.10-10.fc9.x86_64 requires /sbin/ldconfig gsl-devel-1.10-10.fc9.i386 requires /bin/sh gsl-devel-1.10-10.fc9.i386 requires /sbin/install-info gsl-devel-1.10-10.fc9.i386 requires /bin/sh gsl-devel-1.10-10.fc9.x86_64 requires /bin/sh gsl-devel-1.10-10.fc9.x86_64 requires /sbin/install-info gsl-devel-1.10-10.fc9.x86_64 requires /bin/sh gsm-1.0.12-6.fc9.i386 requires /sbin/ldconfig gsm-1.0.12-6.fc9.x86_64 requires /sbin/ldconfig gsoap-2.7.10-4.fc9.i386 requires /sbin/ldconfig gsoap-2.7.10-4.fc9.x86_64 requires /sbin/ldconfig gst-inspector-0.3-5.fc9.noarch requires /bin/sh gst-inspector-0.3-5.fc9.noarch requires /usr/bin/python gstream-1.6-2.fc9.i386 requires /sbin/ldconfig gstream-1.6-2.fc9.x86_64 requires /sbin/ldconfig gstream-devel-1.6-2.fc9.i386 requires /bin/sh gstream-devel-1.6-2.fc9.i386 requires /sbin/install-info gstream-devel-1.6-2.fc9.x86_64 requires /bin/sh gstream-devel-1.6-2.fc9.x86_64 requires /sbin/install-info gstreamer-0.10.19-1.fc9.i386 requires /sbin/ldconfig gstreamer-0.10.19-1.fc9.i386 requires /bin/sh gstreamer-0.10.19-1.fc9.x86_64 requires /sbin/ldconfig gstreamer-0.10.19-1.fc9.x86_64 requires /bin/sh gstreamer-devel-0.10.19-1.fc9.i386 requires /bin/sh gstreamer-devel-0.10.19-1.fc9.x86_64 requires /bin/sh gstreamer-plugins-base-0.10.19-1.fc9.i386 requires /usr/bin/perl gstreamer-plugins-base-0.10.19-1.fc9.x86_64 requires /usr/bin/perl gstreamer-plugins-farsight-0.12.8-1.fc10.x86_64 requires /sbin/ldconfig gstreamer-plugins-good-0.10.8-1.fc10.x86_64 requires /bin/sh gt5-1.4.0-4.fc9.noarch requires /bin/sh gthumb-2.10.8-3.fc10.x86_64 requires /bin/sh gthumb-2.10.8-3.fc10.x86_64 requires /bin/bash 1:gtk+-1.2.10-61.fc9.i386 requires /sbin/ldconfig 1:gtk+-1.2.10-61.fc9.x86_64 requires /sbin/ldconfig 1:gtk+-devel-1.2.10-61.fc9.i386 requires /bin/sh 1:gtk+-devel-1.2.10-61.fc9.x86_64 requires /bin/sh gtk+extra-2.1.1-8.fc9.i386 requires /sbin/ldconfig gtk+extra-2.1.1-8.fc9.x86_64 requires /sbin/ldconfig gtk-doc-1.10-1.fc10.noarch requires /bin/sh gtk-doc-1.10-1.fc10.noarch requires /usr/bin/perl gtk-doc-1.10-1.fc10.noarch requires /bin/sh gtk-doc-1.10-1.fc10.noarch requires /usr/bin/cmp gtk-doc-1.10-1.fc10.noarch requires /usr/bin/python gtk-recordmydesktop-0.3.7-1.fc9.noarch requires /usr/bin/python gtk-sharp-1.0.10-12.fc7.x86_64 requires /bin/sh gtk-sharp-gapi-1.0.10-12.fc7.x86_64 requires /usr/bin/perl gtk-sharp-gapi-1.0.10-12.fc7.x86_64 requires /bin/sh gtk-sharp2-2.10.3-2.fc9.x86_64 requires /sbin/ldconfig gtk-sharp2-gapi-2.10.3-2.fc9.x86_64 requires /usr/bin/perl gtk-sharp2-gapi-2.10.3-2.fc9.x86_64 requires /bin/sh gtk-vnc-0.3.6-1.fc10.i386 requires /sbin/ldconfig gtk-vnc-0.3.6-1.fc10.x86_64 requires /sbin/ldconfig gtk2-2.13.0-2.fc10.i386 requires /bin/sh gtk2-2.13.0-2.fc10.i386 requires /bin/sh gtk2-2.13.0-2.fc10.x86_64 requires /bin/sh gtk2-2.13.0-2.fc10.x86_64 requires /bin/sh gtk2-devel-2.13.0-2.fc10.i386 requires /usr/bin/env gtk2-devel-2.13.0-2.fc10.x86_64 requires /usr/bin/env gtkdatabox-0.8.2.2-2.fc9.i386 requires /sbin/ldconfig gtkdatabox-0.8.2.2-2.fc9.x86_64 requires /sbin/ldconfig gtkglarea2-1.99.0-8.fc9.i386 requires /sbin/ldconfig gtkglarea2-1.99.0-8.fc9.x86_64 requires /sbin/ldconfig gtkglext-libs-1.2.0-6.fc9.i386 requires /bin/sh gtkglext-libs-1.2.0-6.fc9.x86_64 requires /bin/sh gtkglextmm-1.2.0-6.fc9.i386 requires /sbin/ldconfig gtkglextmm-1.2.0-6.fc9.i386 requires /bin/sh gtkglextmm-1.2.0-6.fc9.x86_64 requires /bin/sh gtkglextmm-1.2.0-6.fc9.x86_64 requires /sbin/ldconfig gtkhtml2-2.11.1-3.fc9.i386 requires /sbin/ldconfig gtkhtml2-2.11.1-3.fc9.x86_64 requires /sbin/ldconfig gtkhtml3-3.23.2-4.fc10.i386 requires /sbin/ldconfig gtkhtml3-3.23.2-4.fc10.x86_64 requires /sbin/ldconfig gtkimageview-1.5.0-2.fc9.i386 requires /sbin/ldconfig gtkimageview-1.5.0-2.fc9.x86_64 requires /sbin/ldconfig gtkmathview-0.7.6-7.fc9.i386 requires /sbin/ldconfig gtkmathview-0.7.6-7.fc9.x86_64 requires /sbin/ldconfig gtkmm24-2.12.5-1.fc9.i386 requires /sbin/ldconfig gtkmm24-2.12.5-1.fc9.x86_64 requires /sbin/ldconfig gtkmozembedmm-1.4.2.cvs20060817-17.fc9.i386 requires /sbin/ldconfig gtkmozembedmm-1.4.2.cvs20060817-17.fc9.x86_64 requires /sbin/ldconfig gtkpod-0.99.12-2.fc9.x86_64 requires /bin/sh gtkpod-0.99.12-2.fc9.x86_64 requires /usr/bin/python gtkpod-0.99.12-2.fc9.x86_64 requires /usr/bin/awk gtkpod-0.99.12-2.fc9.x86_64 requires /bin/bash gtkpod-0.99.12-2.fc9.x86_64 requires /bin/sh gtkpod-0.99.12-2.fc9.x86_64 requires /usr/bin/perl 1:gtksourceview-1.8.5-4.fc9.i386 requires /sbin/ldconfig 1:gtksourceview-1.8.5-4.fc9.x86_64 requires /sbin/ldconfig gtksourceview2-2.2.1-1.fc9.i386 requires /sbin/ldconfig gtksourceview2-2.2.1-1.fc9.x86_64 requires /sbin/ldconfig gtkspell-2.0.11-8.fc9.i386 requires /sbin/ldconfig gtkspell-2.0.11-8.fc9.x86_64 requires /sbin/ldconfig gtkterm-0.99.5-9.fc9.x86_64 requires /bin/sh gtorrentviewer-0.2b-15.fc9.x86_64 requires /bin/sh gtranslator-1.1.7-8.fc9.x86_64 requires /bin/sh gtranslator-1.1.7-8.fc9.x86_64 requires /bin/sh gts-0.7.6-9.fc9.i386 requires /sbin/ldconfig gts-0.7.6-9.fc9.i386 requires /bin/sh gts-0.7.6-9.fc9.x86_64 requires /sbin/ldconfig gts-0.7.6-9.fc9.x86_64 requires /bin/sh gts-devel-0.7.6-9.fc9.i386 requires /bin/sh gts-devel-0.7.6-9.fc9.x86_64 requires /bin/sh gtypist-2.7-6.fc9.x86_64 requires /bin/sh gtypist-2.7-6.fc9.x86_64 requires /usr/bin/perl gtypist-2.7-6.fc9.x86_64 requires /sbin/install-info gucharmap-2.22.1-1.fc9.i386 requires /bin/sh gucharmap-2.22.1-1.fc9.x86_64 requires /bin/sh guichan-0.7.1-1.fc9.i386 requires /sbin/ldconfig guichan-0.7.1-1.fc9.x86_64 requires /sbin/ldconfig 5:guile-1.8.5-1.fc10.i386 requires /bin/sh 5:guile-1.8.5-1.fc10.i386 requires /sbin/install-info 5:guile-1.8.5-1.fc10.i386 requires /sbin/ldconfig 5:guile-1.8.5-1.fc10.i386 requires /bin/sh 5:guile-1.8.5-1.fc10.x86_64 requires /bin/sh 5:guile-1.8.5-1.fc10.x86_64 requires /sbin/install-info 5:guile-1.8.5-1.fc10.x86_64 requires /sbin/ldconfig 5:guile-1.8.5-1.fc10.x86_64 requires /bin/sh guile-cairo-1.4.0-6.fc9.i386 requires /sbin/ldconfig guile-cairo-1.4.0-6.fc9.i386 requires /sbin/install-info guile-cairo-1.4.0-6.fc9.i386 requires /bin/sh guile-cairo-1.4.0-6.fc9.x86_64 requires /bin/sh guile-cairo-1.4.0-6.fc9.x86_64 requires /sbin/ldconfig guile-cairo-1.4.0-6.fc9.x86_64 requires /sbin/install-info 5:guile-devel-1.8.5-1.fc10.i386 requires /usr/bin/guile 5:guile-devel-1.8.5-1.fc10.i386 requires /bin/sh 5:guile-devel-1.8.5-1.fc10.x86_64 requires /usr/bin/guile 5:guile-devel-1.8.5-1.fc10.x86_64 requires /bin/sh guile-gnome-platform-2.15.93-6.fc8.i386 requires /bin/sh guile-gnome-platform-2.15.93-6.fc8.i386 requires /sbin/install-info guile-gnome-platform-2.15.93-6.fc8.i386 requires /sbin/ldconfig guile-gnome-platform-2.15.93-6.fc8.i386 requires /bin/sh guile-gnome-platform-2.15.93-6.fc8.x86_64 requires /bin/sh guile-gnome-platform-2.15.93-6.fc8.x86_64 requires /sbin/install-info guile-gnome-platform-2.15.93-6.fc8.x86_64 requires /sbin/ldconfig guile-gnome-platform-2.15.93-6.fc8.x86_64 requires /bin/sh guile-lib-0.1.6-1.fc9.noarch requires /bin/sh guile-lib-0.1.6-1.fc9.noarch requires /sbin/install-info guilt-0.30-1.fc8.noarch requires /bin/sh gutenprint-5.0.2-2.fc9.i386 requires /sbin/ldconfig gutenprint-5.0.2-2.fc9.x86_64 requires /sbin/ldconfig gutenprint-cups-5.0.2-2.fc9.x86_64 requires /bin/sh gutenprint-cups-5.0.2-2.fc9.x86_64 requires /usr/bin/perl gutenprint-foomatic-5.0.2-2.fc9.x86_64 requires /bin/sh gutenprint-foomatic-5.0.2-2.fc9.x86_64 requires /usr/bin/python gv-3.6.3-3.fc9.x86_64 requires /bin/sh gv-3.6.3-3.fc9.x86_64 requires /sbin/install-info gv-3.6.3-3.fc9.x86_64 requires /usr/bin/update-desktop-database gv-3.6.3-3.fc9.x86_64 requires /usr/bin/update-mime-database gvfs-0.2.3-10.fc10.i386 requires /bin/sh gvfs-0.2.3-10.fc10.i386 requires /bin/sh gvfs-0.2.3-10.fc10.x86_64 requires /bin/sh gvfs-0.2.3-10.fc10.x86_64 requires /bin/sh gwave-2-7.20070514snap.fc9.x86_64 requires /bin/sh gwave-2-7.20070514snap.fc9.x86_64 requires /usr/bin/perl gwenhywfar-2.6.2-2.fc9.i386 requires /sbin/ldconfig gwenhywfar-2.6.2-2.fc9.x86_64 requires /sbin/ldconfig gwenhywfar-devel-2.6.2-2.fc9.i386 requires /bin/sh gwenhywfar-devel-2.6.2-2.fc9.x86_64 requires /bin/sh gwget-0.99-5.fc9.x86_64 requires /bin/sh gxine-0.5.902-1.fc10.x86_64 requires /bin/sh gypsy-0.6-3.fc10.i386 requires /sbin/ldconfig gypsy-0.6-3.fc10.x86_64 requires /sbin/ldconfig gzip-1.3.12-6.fc9.x86_64 requires /bin/sh gzip-1.3.12-6.fc9.x86_64 requires /bin/sh gzip-1.3.12-6.fc9.x86_64 requires /sbin/install-info hackedbox-0.8.5-5.fc9.x86_64 requires /bin/bash hackedbox-0.8.5-5.fc9.x86_64 requires /bin/sh haddock-2.0.0.0-2.fc9.x86_64 requires /bin/sh hal-0.5.11-1.fc10.x86_64 requires /bin/sh hal-0.5.11-1.fc10.x86_64 requires /usr/sbin/useradd hal-0.5.11-1.fc10.x86_64 requires /usr/bin/polkit-auth hal-0.5.11-1.fc10.x86_64 requires /sbin/ldconfig hal-0.5.11-1.fc10.x86_64 requires /bin/bash hal-0.5.11-1.fc10.x86_64 requires /bin/sh hal-cups-utils-0.6.16-3.fc9.x86_64 requires /bin/sh hal-cups-utils-0.6.16-3.fc9.x86_64 requires /bin/env hal-cups-utils-0.6.16-3.fc9.x86_64 requires /bin/sh halberd-0.2.2-2.fc8.noarch requires /usr/bin/python halevt-0.0.8-1.fc9.x86_64 requires /bin/sh halevt-0.0.8-1.fc9.x86_64 requires /sbin/chkconfig halevt-0.0.8-1.fc9.x86_64 requires /bin/sh halevt-0.0.8-1.fc9.x86_64 requires /sbin/service hamlib-1.2.7-1.fc9.i386 requires /sbin/ldconfig hamlib-1.2.7-1.fc9.x86_64 requires /sbin/ldconfig hamlib-c++-1.2.7-1.fc9.i386 requires /sbin/ldconfig hamlib-c++-1.2.7-1.fc9.x86_64 requires /sbin/ldconfig hamlib-tcl-1.2.7-1.fc9.x86_64 requires /sbin/ldconfig hamster-applet-0.4-1.fc10.x86_64 requires /bin/sh hamster-applet-0.4-1.fc10.x86_64 requires /usr/bin/env haproxy-1.3.14.3-1.fc9.x86_64 requires /bin/sh haproxy-1.3.14.3-1.fc9.x86_64 requires /sbin/chkconfig haproxy-1.3.14.3-1.fc9.x86_64 requires /usr/sbin/useradd haproxy-1.3.14.3-1.fc9.x86_64 requires /bin/sh haproxy-1.3.14.3-1.fc9.x86_64 requires /sbin/service harminv-1.3.1-10.fc9.i386 requires /sbin/ldconfig harminv-1.3.1-10.fc9.x86_64 requires /sbin/ldconfig hatari-1.0.1-1.fc9.x86_64 requires /bin/sh hawknl-1.68-3.fc9.i386 requires /sbin/ldconfig hawknl-1.68-3.fc9.x86_64 requires /sbin/ldconfig hddtemp-0.3-0.15.beta15.fc9.x86_64 requires /bin/sh hddtemp-0.3-0.15.beta15.fc9.x86_64 requires /usr/bin/consolehelper hddtemp-0.3-0.15.beta15.fc9.x86_64 requires /bin/bash hddtemp-0.3-0.15.beta15.fc9.x86_64 requires /sbin/chkconfig hdf-4.2r3-2.fc9.x86_64 requires /bin/sh hdf5-1.8.0.snap5-2.fc10.i386 requires /sbin/ldconfig hdf5-1.8.0.snap5-2.fc10.x86_64 requires /sbin/ldconfig hdf5-devel-1.8.0.snap5-2.fc10.i386 requires /bin/bash hdf5-devel-1.8.0.snap5-2.fc10.i386 requires /bin/sh hdf5-devel-1.8.0.snap5-2.fc10.x86_64 requires /bin/bash hdf5-devel-1.8.0.snap5-2.fc10.x86_64 requires /bin/sh heartbeat-2.1.3-1.fc9.i386 requires /bin/sh heartbeat-2.1.3-1.fc9.i386 requires /usr/bin/python heartbeat-2.1.3-1.fc9.i386 requires /sbin/ldconfig heartbeat-2.1.3-1.fc9.i386 requires /bin/sh heartbeat-2.1.3-1.fc9.i386 requires /sbin/chkconfig heartbeat-2.1.3-1.fc9.x86_64 requires /bin/sh heartbeat-2.1.3-1.fc9.x86_64 requires /usr/bin/python heartbeat-2.1.3-1.fc9.x86_64 requires /sbin/ldconfig heartbeat-2.1.3-1.fc9.x86_64 requires /bin/sh heartbeat-2.1.3-1.fc9.x86_64 requires /sbin/chkconfig heartbeat-gui-2.1.3-1.fc9.x86_64 requires /usr/bin/python hedgewars-0.9.3-1.fc10.x86_64 requires /bin/sh help2man-1.36.4-2.fc9.noarch requires /usr/bin/perl help2man-1.36.4-2.fc9.noarch requires /sbin/install-info help2man-1.36.4-2.fc9.noarch requires /bin/sh hercules-3.05-4.fc9.x86_64 requires /usr/bin/perl hercules-3.05-4.fc9.x86_64 requires /bin/sh hesinfo-3.1.0-3.x86_64 requires /sbin/ldconfig hesiod-3.1.0-10.i386 requires /sbin/ldconfig hesiod-3.1.0-10.x86_64 requires /sbin/ldconfig hevea-1.10-1.fc9.x86_64 requires /usr/bin/texhash hevea-1.10-1.fc9.x86_64 requires /bin/sh hfsutils-3.2.6-14.fc9.x86_64 requires /bin/sh hgsvn-0.1.5-3.fc9.noarch requires /usr/bin/python hicolor-icon-theme-0.10-4.noarch requires /bin/sh higlayout-1.0-2.fc9.x86_64 requires /bin/sh higlayout-javadoc-1.0-2.fc9.x86_64 requires /bin/sh hippo-canvas-0.2.31-1.fc10.i386 requires /sbin/ldconfig hippo-canvas-0.2.31-1.fc10.x86_64 requires /sbin/ldconfig homebank-3.8-1.fc9.x86_64 requires /bin/sh horde-3.1.7-2.fc9.noarch requires /bin/sh horde-3.1.7-2.fc9.noarch requires /usr/bin/php horde-3.1.7-2.fc9.noarch requires /bin/sh horde-3.1.7-2.fc9.noarch requires /sbin/service hotwire-0.721-1.fc9.noarch requires /bin/sh hotwire-0.721-1.fc9.noarch requires /usr/bin/python hpic-0.52.2-6.fc9.i386 requires /sbin/ldconfig hpic-0.52.2-6.fc9.x86_64 requires /sbin/ldconfig hplip-2.8.2-3.fc10.x86_64 requires /bin/sh hplip-2.8.2-3.fc10.x86_64 requires /usr/bin/env hplip-2.8.2-3.fc10.x86_64 requires /usr/bin/python hplip-2.8.2-3.fc10.x86_64 requires /sbin/service hplip-2.8.2-3.fc10.x86_64 requires /sbin/chkconfig hplip-gui-2.8.2-3.fc10.x86_64 requires /bin/sh hplip-gui-2.8.2-3.fc10.x86_64 requires /usr/bin/env hspell-1.0-8.fc9.x86_64 requires /usr/bin/perl 1:hsqldb-1.8.0.9-2jpp.1.fc9.x86_64 requires /bin/sh 1:hsqldb-1.8.0.9-2jpp.1.fc9.x86_64 requires /bin/ln 1:hsqldb-1.8.0.9-2jpp.1.fc9.x86_64 requires /bin/rm 1:hsqldb-1.8.0.9-2jpp.1.fc9.x86_64 requires /bin/sh 1:hsqldb-demo-1.8.0.9-2jpp.1.fc9.x86_64 requires /bin/sh 1:hsqldb-javadoc-1.8.0.9-2jpp.1.fc9.x86_64 requires /bin/sh 1:hsqldb-javadoc-1.8.0.9-2jpp.1.fc9.x86_64 requires /bin/rm 1:hsqldb-javadoc-1.8.0.9-2jpp.1.fc9.x86_64 requires /bin/ln ht2html-2.0-5.fc6.noarch requires /bin/sh ht2html-2.0-5.fc6.noarch requires /usr/bin/env 4:htdig-3.2.0-0.1.b6.fc10.x86_64 requires /bin/sh html-xml-utils-3.7-5.fc9.x86_64 requires /bin/bash html-xml-utils-3.7-5.fc9.x86_64 requires /usr/bin/perl html2ps-1.0-0.1.b5.fc10.noarch requires /usr/bin/perl html401-dtds-4.01-19991224.5.noarch requires /bin/sh html401-dtds-4.01-19991224.5.noarch requires /usr/bin/install-catalog htmldoc-1.8.27-6.fc9.x86_64 requires /bin/sh htmlview-4.0.0-3.fc7.noarch requires /bin/bash httpd-2.2.8-3.x86_64 requires /bin/sh httpd-2.2.8-3.x86_64 requires /usr/sbin/useradd httpd-2.2.8-3.x86_64 requires /etc/mime.types httpd-2.2.8-3.x86_64 requires /bin/bash httpd-2.2.8-3.x86_64 requires /bin/sh httpd-devel-2.2.8-3.i386 requires /usr/bin/perl httpd-devel-2.2.8-3.i386 requires /bin/sh httpd-devel-2.2.8-3.x86_64 requires /usr/bin/perl httpd-devel-2.2.8-3.x86_64 requires /bin/sh httrack-3.42-9.fc9.i386 requires /sbin/ldconfig httrack-3.42-9.fc9.i386 requires /bin/bash httrack-3.42-9.fc9.x86_64 requires /sbin/ldconfig httrack-3.42-9.fc9.x86_64 requires /bin/bash hugin-0.7.0-0.3.20080218svn.fc9.x86_64 requires /bin/sh hugin-base-0.7.0-0.3.20080218svn.fc9.i386 requires /sbin/ldconfig hugin-base-0.7.0-0.3.20080218svn.fc9.i386 requires /bin/sh hugin-base-0.7.0-0.3.20080218svn.fc9.x86_64 requires /sbin/ldconfig hugin-base-0.7.0-0.3.20080218svn.fc9.x86_64 requires /bin/sh hugs98-2006.09-4.fc9.x86_64 requires /bin/sh hunspell-1.2.2-3.fc10.i386 requires /sbin/ldconfig hunspell-1.2.2-3.fc10.x86_64 requires /sbin/ldconfig hunspell-devel-1.2.2-3.fc10.i386 requires /usr/bin/perl hunspell-devel-1.2.2-3.fc10.x86_64 requires /usr/bin/perl hunt-1.5-7.fc9.x86_64 requires /bin/sh hwbrowser-0.42-1.fc9.noarch requires /bin/sh hydrogen-0.9.3-13.fc9.x86_64 requires /bin/sh hydrogen-0.9.3-13.fc9.x86_64 requires /bin/sh hyperestraier-1.4.13-2.fc9.i386 requires /sbin/ldconfig hyperestraier-1.4.13-2.fc9.i386 requires /bin/sh hyperestraier-1.4.13-2.fc9.x86_64 requires /sbin/ldconfig hyperestraier-1.4.13-2.fc9.x86_64 requires /bin/sh hyperestraier-devel-1.4.13-2.fc9.i386 requires /bin/sh hyperestraier-devel-1.4.13-2.fc9.x86_64 requires /bin/sh hyperestraier-java-1.4.13-2.fc9.i386 requires /sbin/ldconfig hyperestraier-java-1.4.13-2.fc9.x86_64 requires /sbin/ldconfig hyperestraier-perl-1.4.13-2.fc9.x86_64 requires /usr/bin/perl hyphen-2.4-1.fc10.i386 requires /sbin/ldconfig hyphen-2.4-1.fc10.x86_64 requires /sbin/ldconfig hyphen-devel-2.4-1.fc10.i386 requires /usr/bin/perl hyphen-devel-2.4-1.fc10.x86_64 requires /usr/bin/perl i2c-tools-3.0.0-3.fc9.x86_64 requires /usr/bin/perl ibmasm-3.0-14.i386 requires /sbin/lspci ibmasm-3.0-14.i386 requires /bin/sh ibmasm-3.0-14.i386 requires /sbin/ldconfig ibmasm-3.0-14.i386 requires /bin/bash ibmasm-3.0-14.i386 requires /sbin/chkconfig ibmasm-3.0-14.i386 requires /sbin/service ibmonitor-1.4-1.noarch requires /usr/bin/perl ice-3.2.1-17.fc9.i386 requires /usr/bin/env ice-3.2.1-17.fc9.i386 requires /sbin/ldconfig ice-3.2.1-17.fc9.x86_64 requires /usr/bin/env ice-3.2.1-17.fc9.x86_64 requires /sbin/ldconfig ice-servers-3.2.1-17.fc9.x86_64 requires /bin/sh ice-servers-3.2.1-17.fc9.x86_64 requires /bin/bash ice-servers-3.2.1-17.fc9.x86_64 requires /sbin/chkconfig ice-servers-3.2.1-17.fc9.x86_64 requires /sbin/service icecast-2.3.1-5.fc9.x86_64 requires /usr/sbin/useradd icecast-2.3.1-5.fc9.x86_64 requires /bin/sh icecast-2.3.1-5.fc9.x86_64 requires /sbin/service icecast-2.3.1-5.fc9.x86_64 requires /bin/sh icecast-2.3.1-5.fc9.x86_64 requires /sbin/chkconfig icecream-0.8.0-11.20080117svn.fc9.i386 requires /bin/sh icecream-0.8.0-11.20080117svn.fc9.i386 requires /usr/bin/env icecream-0.8.0-11.20080117svn.fc9.i386 requires /bin/sh icecream-0.8.0-11.20080117svn.fc9.x86_64 requires /bin/sh icecream-0.8.0-11.20080117svn.fc9.x86_64 requires /usr/bin/env icecream-0.8.0-11.20080117svn.fc9.x86_64 requires /bin/sh icedax-1.1.6-11.fc9.x86_64 requires /bin/sh icedax-1.1.6-11.fc9.x86_64 requires /usr/sbin/alternatives icedax-1.1.6-11.fc9.x86_64 requires /bin/sh icegrid-gui-3.2.1-17.fc9.x86_64 requires /bin/sh ices-2.0.1-6.fc9.x86_64 requires /bin/sh ices-2.0.1-6.fc9.x86_64 requires /sbin/service ices-2.0.1-6.fc9.x86_64 requires /bin/sh ices-2.0.1-6.fc9.x86_64 requires /sbin/chkconfig icewm-xdgmenu-1.2.35-4.fc9.x86_64 requires /bin/sh icewm-xdgmenu-1.2.35-4.fc9.x86_64 requires /usr/bin/python icon-naming-utils-0.8.6-2.fc9.noarch requires /usr/bin/perl icu4j-3.6.1-2jpp.6.fc9.x86_64 requires /bin/sh id3lib-3.8.3-20.fc9.i386 requires /sbin/ldconfig id3lib-3.8.3-20.fc9.x86_64 requires /sbin/ldconfig idw-gpl-1.5.0-5.fc10.x86_64 requires /bin/sh ifd-egate-0.05-20.x86_64 requires /bin/sh ifm-5.1-6.fc9.x86_64 requires /usr/bin/wish ifm-5.1-6.fc9.x86_64 requires /usr/bin/perl ifplugd-0.28-11.fc9.x86_64 requires /bin/sh ifplugd-0.28-11.fc9.x86_64 requires /bin/bash ifplugd-0.28-11.fc9.x86_64 requires /bin/sh igraph-0.5-13.fc9.i386 requires /sbin/ldconfig igraph-0.5-13.fc9.i386 requires /sbin/install-info igraph-0.5-13.fc9.x86_64 requires /sbin/ldconfig igraph-0.5-13.fc9.x86_64 requires /sbin/install-info igraph-devel-0.5-13.fc9.i386 requires /bin/sh igraph-devel-0.5-13.fc9.x86_64 requires /bin/sh iksemel-1.3-4.fc9.i386 requires /sbin/ldconfig iksemel-1.3-4.fc9.x86_64 requires /sbin/ldconfig iksemel-devel-1.3-4.fc9.i386 requires /sbin/install-info iksemel-devel-1.3-4.fc9.i386 requires /bin/sh iksemel-devel-1.3-4.fc9.x86_64 requires /sbin/install-info iksemel-devel-1.3-4.fc9.x86_64 requires /bin/sh ilmbase-1.0.1-2.fc9.i386 requires /sbin/ldconfig ilmbase-1.0.1-2.fc9.x86_64 requires /sbin/ldconfig im-chooser-0.99.6-4.fc10.x86_64 requires /usr/sbin/alternatives imake-1.0.2-6.fc9.x86_64 requires /usr/bin/perl imake-1.0.2-6.fc9.x86_64 requires /bin/sh imapsync-1.249-1.fc8.noarch requires /usr/bin/perl 1:imlib-1.9.15-7.fc9.i386 requires /sbin/ldconfig 1:imlib-1.9.15-7.fc9.x86_64 requires /sbin/ldconfig 1:imlib-devel-1.9.15-7.fc9.i386 requires /usr/share/aclocal 1:imlib-devel-1.9.15-7.fc9.i386 requires /bin/sh 1:imlib-devel-1.9.15-7.fc9.x86_64 requires /usr/share/aclocal 1:imlib-devel-1.9.15-7.fc9.x86_64 requires /bin/sh imlib2-1.4.0-5.fc9.i386 requires /sbin/ldconfig imlib2-1.4.0-5.fc9.x86_64 requires /sbin/ldconfig imlib2-devel-1.4.0-5.fc9.i386 requires /bin/sh imlib2-devel-1.4.0-5.fc9.x86_64 requires /bin/sh imsettings-0.99.6-4.fc10.x86_64 requires /bin/sh imsettings-0.99.6-4.fc10.x86_64 requires /bin/dbus-send imsettings-libs-0.99.6-4.fc10.i386 requires /sbin/ldconfig imsettings-libs-0.99.6-4.fc10.x86_64 requires /sbin/ldconfig inadyn-1.96.2-3.fc9.x86_64 requires /bin/sh inadyn-1.96.2-3.fc9.x86_64 requires /sbin/chkconfig inadyn-1.96.2-3.fc9.x86_64 requires /sbin/service inchi-1.0.2-0.3.fc9.i386 requires /sbin/ldconfig inchi-1.0.2-0.3.fc9.x86_64 requires /sbin/ldconfig incollector-1.0-6.fc9.x86_64 requires /bin/sh inconsolata-fonts-1.009-1.fc9.noarch requires /bin/sh incron-0.5.7-1.fc9.x86_64 requires /bin/sh incron-0.5.7-1.fc9.x86_64 requires /bin/bash incron-0.5.7-1.fc9.x86_64 requires /sbin/chkconfig incron-0.5.7-1.fc9.x86_64 requires /sbin/service indent-2.2.10-1.fc9.x86_64 requires /bin/sh indent-2.2.10-1.fc9.x86_64 requires /sbin/install-info info-4.12-1.fc10.x86_64 requires /bin/sh initng-0.6.10.2-2.fc9.x86_64 requires /bin/sh initng-0.6.10.2-2.fc9.x86_64 requires /bin/sh initng-conf-gtk-0.5.1-4.fc9.x86_64 requires /bin/sh initng-ifiles-0.1.4-5.fc9.x86_64 requires /bin/sh initng-ifiles-0.1.4-5.fc9.x86_64 requires /bin/sh initng-ifiles-0.1.4-5.fc9.x86_64 requires /sbin/ldconfig initng-ifiles-0.1.4-5.fc9.x86_64 requires /bin/bash initng-lib-0.6.10.2-2.fc9.i386 requires /sbin/ldconfig initng-lib-0.6.10.2-2.fc9.x86_64 requires /sbin/ldconfig initscripts-8.76.1-1.x86_64 requires /bin/sh initscripts-8.76.1-1.x86_64 requires /bin/sed initscripts-8.76.1-1.x86_64 requires /etc/redhat-release initscripts-8.76.1-1.x86_64 requires /sbin/runuser initscripts-8.76.1-1.x86_64 requires /sbin/sysctl initscripts-8.76.1-1.x86_64 requires /bin/awk initscripts-8.76.1-1.x86_64 requires /bin/sed initscripts-8.76.1-1.x86_64 requires /sbin/pidof initscripts-8.76.1-1.x86_64 requires /sbin/fuser initscripts-8.76.1-1.x86_64 requires /bin/bash initscripts-8.76.1-1.x86_64 requires /sbin/arping initscripts-8.76.1-1.x86_64 requires /bin/sh initscripts-8.76.1-1.x86_64 requires /bin/grep initscripts-8.76.1-1.x86_64 requires /bin/find initscripts-8.76.1-1.x86_64 requires /usr/sbin/groupadd initscripts-8.76.1-1.x86_64 requires /sbin/chkconfig initscripts-8.76.1-1.x86_64 requires /sbin/ip inkscape-0.46-2.fc9.x86_64 requires /bin/sh inkscape-0.46-2.fc9.x86_64 requires /usr/bin/perl inkscape-0.46-2.fc9.x86_64 requires /bin/sh inkscape-0.46-2.fc9.x86_64 requires /usr/bin/env inn-2.4.4-1.fc10.x86_64 requires /bin/sh inn-2.4.4-1.fc10.x86_64 requires /usr/lib/news/lib/innshellvars.pl inn-2.4.4-1.fc10.x86_64 requires /bin/bash inn-2.4.4-1.fc10.x86_64 requires /bin/sh inn-2.4.4-1.fc10.x86_64 requires /usr/bin/perl innotop-1.6.0-2.fc9.noarch requires /usr/bin/perl inotify-tools-3.13-1.fc9.i386 requires /sbin/ldconfig inotify-tools-3.13-1.fc9.x86_64 requires /sbin/ldconfig international-time-0.0.2-4.fc8.noarch requires /bin/sh international-time-0.0.2-4.fc8.noarch requires /usr/bin/python intltool-0.37.1-1.fc9.x86_64 requires /usr/bin/perl intltool-0.37.1-1.fc9.x86_64 requires /bin/sh iotop-0.1-3.fc9.noarch requires /usr/bin/python iozone-3-5.fc9.x86_64 requires /bin/sh ip-sentinel-0.12-11.fc9.x86_64 requires /bin/sh ip-sentinel-sysv-0.12-11.fc9.x86_64 requires /bin/sh ip-sentinel-sysv-0.12-11.fc9.x86_64 requires /bin/bash ip-sentinel-sysv-0.12-11.fc9.x86_64 requires /sbin/chkconfig ipa-admintools-1.0.0-5.fc10.x86_64 requires /usr/bin/python ipa-client-1.0.0-5.fc10.x86_64 requires /usr/bin/python ipa-radius-admintools-1.0.0-5.fc10.x86_64 requires /usr/bin/python ipa-radius-server-1.0.0-5.fc10.x86_64 requires /usr/bin/python ipa-server-1.0.0-5.fc10.x86_64 requires /bin/sh ipa-server-1.0.0-5.fc10.x86_64 requires /usr/bin/python ipa-server-1.0.0-5.fc10.x86_64 requires /bin/sh ipa-server-selinux-1.0.0-5.fc10.x86_64 requires /bin/sh ipcalculator-0.41-6.fc9.noarch requires /usr/bin/perl ipcalculator-cgi-0.41-6.fc9.noarch requires /usr/bin/perl ipe-6.0-0.24.pre30.fc9.i386 requires /sbin/ldconfig ipe-6.0-0.24.pre30.fc9.x86_64 requires /sbin/ldconfig iproute-2.6.25-1.fc10.x86_64 requires /bin/bash ipsec-tools-0.7-13.fc9.x86_64 requires /bin/sh ipsec-tools-0.7-13.fc9.x86_64 requires /bin/sh ipsec-tools-0.7-13.fc9.x86_64 requires /bin/bash iptables-1.4.0-4.fc9.x86_64 requires /bin/sh iptables-1.4.0-4.fc9.x86_64 requires /bin/sh iptables-ipv6-1.4.0-4.fc9.x86_64 requires /bin/sh iptables-ipv6-1.4.0-4.fc9.x86_64 requires /bin/sh iputils-20071127-2.fc9.x86_64 requires /bin/sh iputils-20071127-2.fc9.x86_64 requires /bin/bash iputils-20071127-2.fc9.x86_64 requires /sbin/chkconfig iputils-20071127-2.fc9.x86_64 requires /sbin/service ipv6calc-0.71.0-2.fc9.x86_64 requires /usr/bin/perl ipv6calc-0.71.0-2.fc9.x86_64 requires /bin/sh ipvsadm-1.24-11.x86_64 requires /bin/sh ipvsadm-1.24-11.x86_64 requires /bin/bash ipvsadm-1.24-11.x86_64 requires /sbin/chkconfig ipvsadm-1.24-11.x86_64 requires /bin/sh ipxripd-0.8-5.fc9.x86_64 requires /bin/sh ipxripd-0.8-5.fc9.x86_64 requires /sbin/chkconfig ipxripd-0.8-5.fc9.x86_64 requires /bin/sh ipxripd-0.8-5.fc9.x86_64 requires /sbin/service ipython-0.8.2-1.fc9.noarch requires /usr/bin/env ipython-0.8.2-1.fc9.noarch requires /usr/bin/python ircd-hybrid-7.2.3-5.fc9.x86_64 requires /bin/sh ircd-hybrid-7.2.3-5.fc9.x86_64 requires /sbin/service ircd-hybrid-7.2.3-5.fc9.x86_64 requires /bin/sh ircd-hybrid-7.2.3-5.fc9.x86_64 requires /sbin/chkconfig irda-utils-0.9.18-4.fc9.x86_64 requires /bin/sh irda-utils-0.9.18-4.fc9.x86_64 requires /sbin/chkconfig irda-utils-0.9.18-4.fc9.x86_64 requires /bin/sh 2:irqbalance-0.55-9.fc10.x86_64 requires /bin/sh 2:irqbalance-0.55-9.fc10.x86_64 requires /sbin/chkconfig 2:irqbalance-0.55-9.fc10.x86_64 requires /bin/sh 2:irqbalance-0.55-9.fc10.x86_64 requires /sbin/service iscsi-initiator-utils-6.2.0.868-0.7.fc9.x86_64 requires /bin/sh iscsi-initiator-utils-6.2.0.868-0.7.fc9.x86_64 requires /bin/sh iscsi-initiator-utils-6.2.0.868-0.7.fc9.x86_64 requires /sbin/service isdn4k-utils-3.2-58.fc9.i386 requires /bin/sh isdn4k-utils-3.2-58.fc9.i386 requires /bin/ln isdn4k-utils-3.2-58.fc9.i386 requires /sbin/ldconfig isdn4k-utils-3.2-58.fc9.i386 requires /bin/bash isdn4k-utils-3.2-58.fc9.i386 requires /bin/sh isdn4k-utils-3.2-58.fc9.i386 requires /usr/bin/perl isdn4k-utils-3.2-58.fc9.i386 requires /sbin/chkconfig isdn4k-utils-3.2-58.fc9.x86_64 requires /bin/sh isdn4k-utils-3.2-58.fc9.x86_64 requires /bin/ln isdn4k-utils-3.2-58.fc9.x86_64 requires /sbin/ldconfig isdn4k-utils-3.2-58.fc9.x86_64 requires /bin/bash isdn4k-utils-3.2-58.fc9.x86_64 requires /bin/sh isdn4k-utils-3.2-58.fc9.x86_64 requires /usr/bin/perl isdn4k-utils-3.2-58.fc9.x86_64 requires /sbin/chkconfig isicom-3.05-20.fc9.x86_64 requires /bin/sh isicom-3.05-20.fc9.x86_64 requires /sbin/chkconfig isicom-3.05-20.fc9.x86_64 requires /bin/sh isicom-3.05-20.fc9.x86_64 requires /sbin/service isight-firmware-tools-1.0.2-2.fc9.x86_64 requires /bin/sh isight-firmware-tools-1.0.2-2.fc9.x86_64 requires /sbin/install-info isns-utils-0.91-0.0.fc9.x86_64 requires /bin/sh isns-utils-0.91-0.0.fc9.x86_64 requires /sbin/service isns-utils-0.91-0.0.fc9.x86_64 requires /sbin/chkconfig isns-utils-0.91-0.0.fc9.x86_64 requires /bin/sh isomaster-1.3.1-1.fc9.x86_64 requires /bin/sh isomaster-1.3.1-1.fc9.x86_64 requires /bin/sh istanbul-0.2.2-7.fc10.x86_64 requires /usr/bin/python isync-1.0.4-1.fc9.x86_64 requires /bin/sh itpp-4.0.0-2.fc9.i386 requires /sbin/ldconfig itpp-4.0.0-2.fc9.x86_64 requires /sbin/ldconfig itpp-devel-4.0.0-2.fc9.i386 requires /bin/sh itpp-devel-4.0.0-2.fc9.x86_64 requires /bin/sh iverilog-0.9.20080314-1.fc9.x86_64 requires /bin/sh iwidgets-4.0.2-1.fc9.noarch requires /bin/sh jabberd-2.1.23-1.fc9.x86_64 requires /bin/sh jabberd-2.1.23-1.fc9.x86_64 requires /sbin/service jabberd-2.1.23-1.fc9.x86_64 requires /bin/bash jabbim-0.4-0.4.20080407svn.fc9.noarch requires /bin/sh jabbim-0.4-0.4.20080407svn.fc9.noarch requires /usr/bin/env jabbim-0.4-0.4.20080407svn.fc9.noarch requires /bin/sh jabbin-2.0-0.6.beta2a.fc9.x86_64 requires /bin/sh jack-audio-connection-kit-0.109.2-1.fc9.1.i386 requires /bin/sh jack-audio-connection-kit-0.109.2-1.fc9.1.i386 requires /sbin/ldconfig jack-audio-connection-kit-0.109.2-1.fc9.1.x86_64 requires /bin/sh jack-audio-connection-kit-0.109.2-1.fc9.1.x86_64 requires /sbin/ldconfig jack-rack-1.4.7-1.fc9.x86_64 requires /usr/bin/python jadetex-3.13-2.fc9.noarch requires /bin/sh jadetex-3.13-2.fc9.noarch requires /bin/sh jakarta-commons-beanutils-1.7.0-6jpp.1.x86_64 requires /bin/sh jakarta-commons-beanutils-javadoc-1.7.0-6jpp.1.x86_64 requires /bin/sh jakarta-commons-beanutils-javadoc-1.7.0-6jpp.1.x86_64 requires /bin/rm jakarta-commons-beanutils-javadoc-1.7.0-6jpp.1.x86_64 requires /bin/ln jakarta-commons-cli-1.0-7jpp_10.fc9.x86_64 requires /usr/bin/rebuild-gcj-db jakarta-commons-codec-1.3-9jpp.2.fc9.x86_64 requires /bin/sh jakarta-commons-collections-3.2-2jpp.2.fc9.x86_64 requires /bin/sh jakarta-commons-collections-testframework-3.2-2jpp.2.fc9.x86_64 requires /bin/sh jakarta-commons-collections-tomcat5-3.2-2jpp.2.fc9.x86_64 requires /bin/sh 1:jakarta-commons-daemon-1.0.1-6jpp.5.fc9.x86_64 requires /bin/sh 1:jakarta-commons-daemon-javadoc-1.0.1-6jpp.5.fc9.x86_64 requires /bin/rm 1:jakarta-commons-daemon-javadoc-1.0.1-6jpp.5.fc9.x86_64 requires /bin/ln jakarta-commons-dbcp-1.2.1-11jpp.3.fc9.x86_64 requires /bin/sh jakarta-commons-dbcp-1.2.1-11jpp.3.fc9.x86_64 requires /usr/sbin/update-alternatives jakarta-commons-dbcp-javadoc-1.2.1-11jpp.3.fc9.x86_64 requires /bin/rm jakarta-commons-dbcp-javadoc-1.2.1-11jpp.3.fc9.x86_64 requires /bin/ln jakarta-commons-dbcp-tomcat5-1.2.1-11jpp.3.fc9.x86_64 requires /bin/sh jakarta-commons-digester-1.7-7jpp.2.x86_64 requires /bin/sh jakarta-commons-digester-javadoc-1.7-7jpp.2.x86_64 requires /bin/sh jakarta-commons-digester-javadoc-1.7-7jpp.2.x86_64 requires /bin/rm jakarta-commons-digester-javadoc-1.7-7jpp.2.x86_64 requires /bin/ln 1:jakarta-commons-discovery-0.4-3jpp.1.fc9.x86_64 requires /bin/sh 1:jakarta-commons-discovery-javadoc-0.4-3jpp.1.fc9.x86_64 requires /bin/rm 1:jakarta-commons-discovery-javadoc-0.4-3jpp.1.fc9.x86_64 requires /bin/ln jakarta-commons-el-1.0-9jpp.2.fc9.x86_64 requires /bin/sh jakarta-commons-el-javadoc-1.0-9jpp.2.fc9.x86_64 requires /bin/sh jakarta-commons-el-javadoc-1.0-9jpp.2.fc9.x86_64 requires /bin/ln jakarta-commons-el-javadoc-1.0-9jpp.2.fc9.x86_64 requires /bin/rm 1:jakarta-commons-fileupload-1.0-7jpp.2.fc9.x86_64 requires /bin/sh 1:jakarta-commons-httpclient-3.1-0jpp.1.fc9.x86_64 requires /bin/sh 1:jakarta-commons-httpclient-javadoc-3.1-0jpp.1.fc9.x86_64 requires /bin/rm 1:jakarta-commons-httpclient-javadoc-3.1-0jpp.1.fc9.x86_64 requires /bin/ln jakarta-commons-io-1.3.2-1jpp.1.fc9.noarch requires /bin/sh jakarta-commons-lang-2.3-2jpp.1.fc9.x86_64 requires /bin/sh jakarta-commons-launcher-1.1-2jpp.3.fc9.x86_64 requires /bin/sh jakarta-commons-launcher-javadoc-1.1-2jpp.3.fc9.x86_64 requires /bin/sh jakarta-commons-launcher-javadoc-1.1-2jpp.3.fc9.x86_64 requires /bin/rm jakarta-commons-launcher-javadoc-1.1-2jpp.3.fc9.x86_64 requires /bin/ln jakarta-commons-logging-1.0.4-7jpp.5.fc9.x86_64 requires /bin/sh jakarta-commons-logging-javadoc-1.0.4-7jpp.5.fc9.x86_64 requires /bin/sh jakarta-commons-logging-javadoc-1.0.4-7jpp.5.fc9.x86_64 requires /bin/rm jakarta-commons-logging-javadoc-1.0.4-7jpp.5.fc9.x86_64 requires /bin/ln jakarta-commons-modeler-2.0-4jpp.2.fc9.x86_64 requires /bin/sh jakarta-commons-net-1.4.1-4jpp.1.fc9.noarch requires /bin/sh jakarta-commons-pool-1.3-10jpp.3.fc9.x86_64 requires /bin/sh jakarta-commons-pool-tomcat5-1.3-10jpp.3.fc9.x86_64 requires /bin/sh jakarta-commons-validator-1.1.4-6jpp.2.fc9.x86_64 requires /bin/sh jakarta-commons-validator-javadoc-1.1.4-6jpp.2.fc9.x86_64 requires /bin/sh jakarta-commons-validator-javadoc-1.1.4-6jpp.2.fc9.x86_64 requires /bin/rm jakarta-commons-validator-javadoc-1.1.4-6jpp.2.fc9.x86_64 requires /bin/ln jakarta-oro-2.0.8-4jpp.1.x86_64 requires /bin/sh jakarta-oro-javadoc-2.0.8-4jpp.1.x86_64 requires /bin/sh jakarta-oro-javadoc-2.0.8-4jpp.1.x86_64 requires /bin/ln jakarta-oro-javadoc-2.0.8-4jpp.1.x86_64 requires /bin/rm jakarta-taglibs-standard-1.1.1-9jpp.1.fc9.x86_64 requires /bin/sh jasper-libs-1.900.1-8.fc9.i386 requires /sbin/ldconfig jasper-libs-1.900.1-8.fc9.x86_64 requires /sbin/ldconfig java-1.5.0-gcj-1.5.0.0-21.fc9.x86_64 requires /bin/sh java-1.5.0-gcj-1.5.0.0-21.fc9.x86_64 requires /usr/bin/gcj-dbtool java-1.5.0-gcj-1.5.0.0-21.fc9.x86_64 requires /usr/bin/gij java-1.5.0-gcj-1.5.0.0-21.fc9.x86_64 requires /usr/sbin/alternatives java-1.5.0-gcj-1.5.0.0-21.fc9.x86_64 requires /usr/sbin/alternatives java-1.5.0-gcj-1.5.0.0-21.fc9.x86_64 requires /bin/bash java-1.5.0-gcj-1.5.0.0-21.fc9.x86_64 requires /usr/bin/rebuild-gcj-db java-1.5.0-gcj-1.5.0.0-21.fc9.x86_64 requires /bin/sh java-1.5.0-gcj-1.5.0.0-21.fc9.x86_64 requires /usr/lib64/security/classpath.security java-1.5.0-gcj-1.5.0.0-21.fc9.x86_64 requires /usr/bin/gij java-1.5.0-gcj-devel-1.5.0.0-21.fc9.x86_64 requires /bin/sh java-1.5.0-gcj-devel-1.5.0.0-21.fc9.x86_64 requires /usr/bin/gij java-1.5.0-gcj-devel-1.5.0.0-21.fc9.x86_64 requires /usr/bin/gcj java-1.5.0-gcj-devel-1.5.0.0-21.fc9.x86_64 requires /usr/sbin/alternatives java-1.5.0-gcj-devel-1.5.0.0-21.fc9.x86_64 requires /usr/bin/env java-1.5.0-gcj-devel-1.5.0.0-21.fc9.x86_64 requires /bin/sh java-1.5.0-gcj-devel-1.5.0.0-21.fc9.x86_64 requires /usr/bin/gcj java-1.5.0-gcj-src-1.5.0.0-21.fc9.x86_64 requires /usr/bin/gij java-1.5.0-gcj-src-1.5.0.0-21.fc9.x86_64 requires /bin/sh java-1.5.0-gcj-src-1.5.0.0-21.fc9.x86_64 requires /usr/bin/gij 1:java-1.6.0-openjdk-1.6.0.0-0.12.b09.fc9.i386 requires /bin/sh 1:java-1.6.0-openjdk-1.6.0.0-0.12.b09.fc9.i386 requires /usr/bin/update-desktop-database 1:java-1.6.0-openjdk-1.6.0.0-0.12.b09.fc9.i386 requires /usr/sbin/alternatives 1:java-1.6.0-openjdk-1.6.0.0-0.12.b09.fc9.x86_64 requires /bin/sh 1:java-1.6.0-openjdk-1.6.0.0-0.12.b09.fc9.x86_64 requires /usr/bin/update-desktop-database 1:java-1.6.0-openjdk-1.6.0.0-0.12.b09.fc9.x86_64 requires /usr/sbin/alternatives 1:java-1.6.0-openjdk-demo-1.6.0.0-0.12.b09.fc9.x86_64 requires /bin/sh 1:java-1.6.0-openjdk-devel-1.6.0.0-0.12.b09.fc9.i386 requires /bin/sh 1:java-1.6.0-openjdk-devel-1.6.0.0-0.12.b09.fc9.i386 requires /usr/sbin/alternatives 1:java-1.6.0-openjdk-devel-1.6.0.0-0.12.b09.fc9.i386 requires /bin/sh 1:java-1.6.0-openjdk-devel-1.6.0.0-0.12.b09.fc9.x86_64 requires /bin/sh 1:java-1.6.0-openjdk-devel-1.6.0.0-0.12.b09.fc9.x86_64 requires /usr/sbin/alternatives 1:java-1.6.0-openjdk-devel-1.6.0.0-0.12.b09.fc9.x86_64 requires /bin/sh 1:java-1.6.0-openjdk-javadoc-1.6.0.0-0.12.b09.fc9.x86_64 requires /usr/sbin/alternatives 1:java-1.6.0-openjdk-javadoc-1.6.0.0-0.12.b09.fc9.x86_64 requires /bin/sh 1:java-1.6.0-openjdk-plugin-1.6.0.0-0.12.b09.fc9.x86_64 requires /bin/sh 1:java-1.6.0-openjdk-plugin-1.6.0.0-0.12.b09.fc9.x86_64 requires /usr/lib64/mozilla/plugins 1:java-1.6.0-openjdk-plugin-1.6.0.0-0.12.b09.fc9.x86_64 requires /usr/sbin/alternatives 1:java_cup-0.10-0.k.6jpp.2.x86_64 requires /bin/sh 1:java_cup-javadoc-0.10-0.k.6jpp.2.x86_64 requires /bin/sh 1:java_cup-javadoc-0.10-0.k.6jpp.2.x86_64 requires /bin/rm 1:java_cup-javadoc-0.10-0.k.6jpp.2.x86_64 requires /bin/ln javacc-4.0-4jpp.4.x86_64 requires /bin/sh javacc-4.0-4jpp.4.x86_64 requires /bin/sh jcommon-1.0.12-4.fc10.x86_64 requires /bin/sh jcommon-serializer-0.2.0-3.fc10.x86_64 requires /bin/sh jcommon-xml-1.0.12-4.fc10.x86_64 requires /bin/sh jd-2.0.0-0.4.svn2053_trunk.fc10.x86_64 requires /bin/sh jday-2.4-3.fc9.i386 requires /sbin/ldconfig jday-2.4-3.fc9.x86_64 requires /sbin/ldconfig jdepend-2.6-7jpp.3.x86_64 requires /bin/sh jdepend-javadoc-2.6-7jpp.3.x86_64 requires /bin/sh jdepend-javadoc-2.6-7jpp.3.x86_64 requires /bin/rm jdepend-javadoc-2.6-7jpp.3.x86_64 requires /bin/ln jdom-1.0-5jpp.2.fc9.x86_64 requires /bin/sh jdom-javadoc-1.0-5jpp.2.fc9.x86_64 requires /bin/sh jdom-javadoc-1.0-5jpp.2.fc9.x86_64 requires /bin/rm jdom-javadoc-1.0-5jpp.2.fc9.x86_64 requires /bin/ln jetty-5.1.12-1jpp.9.fc8.x86_64 requires /bin/sh jetty-5.1.12-1jpp.9.fc8.x86_64 requires /sbin/chkconfig jetty-5.1.12-1jpp.9.fc8.x86_64 requires /bin/sh jgroups-2.2.9.2-3jpp.2.x86_64 requires /bin/sh jgroups-javadoc-2.2.9.2-3jpp.2.x86_64 requires /bin/sh jgroups-javadoc-2.2.9.2-3jpp.2.x86_64 requires /bin/rm jgroups-javadoc-2.2.9.2-3jpp.2.x86_64 requires /bin/ln jigdo-0.7.3-6.fc9.x86_64 requires /bin/sh jlex-1.2.6-6jpp.1.x86_64 requires /bin/sh jlex-javadoc-1.2.6-6jpp.1.x86_64 requires /bin/sh jlex-javadoc-1.2.6-6jpp.1.x86_64 requires /bin/rm jlex-javadoc-1.2.6-6jpp.1.x86_64 requires /bin/ln jline-0.9.94-0jpp.1.fc9.noarch requires /bin/sh jline-0.9.94-0jpp.1.fc9.noarch requires /bin/stty john-1.7.0.2-6.fc9.x86_64 requires /bin/sh jokosher-1.0-0.2.20080216svn.fc9.noarch requires /bin/sh jokosher-1.0-0.2.20080216svn.fc9.noarch requires /usr/bin/python jomolhari-fonts-0.003-5.fc10.noarch requires /bin/sh joni-1.0.2-4.fc9.x86_64 requires /bin/sh jpackage-utils-1.7.5-1jpp.1.fc9.noarch requires /bin/sh jpgalleg-2.5-3.fc9.i386 requires /sbin/ldconfig jpgalleg-2.5-3.fc9.x86_64 requires /sbin/ldconfig jpilot-0.99.9-6.fc9.x86_64 requires /sbin/ldconfig jrefactory-2.8.9-7jpp.4.fc9.x86_64 requires /bin/sh jrtplib-3.7.1-4.fc9.i386 requires /sbin/ldconfig jrtplib-3.7.1-4.fc9.x86_64 requires /sbin/ldconfig jruby-1.1.1-5.fc10.noarch requires /bin/bash jruby-1.1.1-5.fc10.noarch requires /usr/bin/env js-1.70-2.fc9.i386 requires /sbin/ldconfig js-1.70-2.fc9.x86_64 requires /sbin/ldconfig jsch-0.1.31-2jpp.3.fc9.x86_64 requires /bin/sh jsch-demo-0.1.31-2jpp.3.fc9.x86_64 requires /bin/sh jsch-demo-0.1.31-2jpp.3.fc9.x86_64 requires /bin/rm jsch-demo-0.1.31-2jpp.3.fc9.x86_64 requires /bin/ln jsch-javadoc-0.1.31-2jpp.3.fc9.x86_64 requires /bin/sh jsch-javadoc-0.1.31-2jpp.3.fc9.x86_64 requires /bin/rm jsch-javadoc-0.1.31-2jpp.3.fc9.x86_64 requires /bin/ln jthread-1.2.1-4.fc9.i386 requires /sbin/ldconfig jthread-1.2.1-4.fc9.x86_64 requires /sbin/ldconfig 2:jtidy-1.0-0.2.r7dev.1jpp.2.fc9.x86_64 requires /bin/sh 2:jtidy-javadoc-1.0-0.2.r7dev.1jpp.2.fc9.x86_64 requires /bin/rm 2:jtidy-javadoc-1.0-0.2.r7dev.1jpp.2.fc9.x86_64 requires /bin/ln junit-3.8.2-4jpp.3.fc9.x86_64 requires /bin/sh jwhois-4.0-7.fc9.x86_64 requires /bin/sh jwhois-4.0-7.fc9.x86_64 requires /sbin/install-info jython-2.2.1-0.1.Release_2_2_1.1jpp.1.fc9.x86_64 requires /bin/sh jython-demo-2.2.1-0.1.Release_2_2_1.1jpp.1.fc9.x86_64 requires /bin/sh jzlib-1.0.7-5jpp.1.x86_64 requires /bin/sh jzlib-demo-1.0.7-5jpp.1.x86_64 requires /bin/sh jzlib-demo-1.0.7-5jpp.1.x86_64 requires /bin/rm jzlib-demo-1.0.7-5jpp.1.x86_64 requires /bin/ln jzlib-javadoc-1.0.7-5jpp.1.x86_64 requires /bin/sh jzlib-javadoc-1.0.7-5jpp.1.x86_64 requires /bin/rm jzlib-javadoc-1.0.7-5jpp.1.x86_64 requires /bin/ln k3b-1.0.4-9.fc10.i386 requires /bin/sh k3b-1.0.4-9.fc10.x86_64 requires /bin/sh k3d-0.6.7.0-7.fc10.i386 requires /sbin/ldconfig k3d-0.6.7.0-7.fc10.i386 requires /bin/bash k3d-0.6.7.0-7.fc10.i386 requires /bin/sh k3d-0.6.7.0-7.fc10.i386 requires /bin/sh k3d-0.6.7.0-7.fc10.x86_64 requires /sbin/ldconfig k3d-0.6.7.0-7.fc10.x86_64 requires /bin/sh k3d-0.6.7.0-7.fc10.x86_64 requires /bin/bash k3d-0.6.7.0-7.fc10.x86_64 requires /bin/sh k3d-devel-0.6.7.0-7.fc10.i386 requires /bin/sh k3d-devel-0.6.7.0-7.fc10.x86_64 requires /bin/sh kacst-fonts-1.6.2-2.fc8.noarch requires /bin/sh kadu-0.6.0-3.fc9.x86_64 requires /bin/sh kadu-dcopexport-0.6.0-3.fc9.x86_64 requires /bin/sh kadu-devel-0.6.0-3.fc9.i386 requires /bin/sh kadu-devel-0.6.0-3.fc9.x86_64 requires /bin/sh kaffeine-0.8.6-4.fc9.x86_64 requires /bin/sh kaffeine-libs-0.8.6-4.fc9.i386 requires /sbin/ldconfig kaffeine-libs-0.8.6-4.fc9.x86_64 requires /sbin/ldconfig kakasi-2.3.4-26.fc9.x86_64 requires /sbin/ldconfig kakasi-2.3.4-26.fc9.x86_64 requires /bin/sh kannel-1.4.1-7.x86_64 requires /bin/sh kannel-1.4.1-7.x86_64 requires /bin/sh kannel-devel-1.4.1-7.i386 requires /bin/sh kannel-devel-1.4.1-7.x86_64 requires /bin/sh kanyremote-4.8-1.fc10.noarch requires /usr/bin/env kasablanca-0.4.0.2-12.fc9.x86_64 requires /bin/sh katapult-0.3.2.1-3.fc9.i386 requires /bin/sh katapult-0.3.2.1-3.fc9.x86_64 requires /bin/sh 1:kawa-1.9.1-5.fc9.x86_64 requires /bin/sh 1:kawa-1.9.1-5.fc9.x86_64 requires /bin/sh kbackup-0.5.3-4.fc9.x86_64 requires /bin/sh kbanking-2.3.3-3.fc9.i386 requires /sbin/ldconfig kbanking-2.3.3-3.fc9.x86_64 requires /sbin/ldconfig kbanking-devel-2.3.3-3.fc9.i386 requires /bin/sh kbanking-devel-2.3.3-3.fc9.x86_64 requires /bin/sh kbd-1.12-31.fc9.x86_64 requires /bin/bash kbd-1.12-31.fc9.x86_64 requires /bin/sh kbibtex-0.2.1-19.fc9.x86_64 requires /bin/sh kbilliards-0.8.7b-7.fc9.x86_64 requires /bin/sh kcbench-0.3-1.1.noarch requires /bin/bash kcbench-0.3-1.1.noarch requires /usr/bin/bc kcbench-0.3-1.1.noarch requires /usr/bin/time kcbench-data-2.6.25-0.1-3.noarch requires /usr/bin/perl kcbench-data-2.6.25-0.1-3.noarch requires /bin/bash kcbench-data-2.6.25-0.1-3.noarch requires /usr/bin/env kcbench-data-2.6.25-0.1-3.noarch requires /bin/sh kcbench-data-2.6.25-0.1-3.noarch requires /usr/bin/python kcemirror-0.1.5-4.fc9.x86_64 requires /bin/sh kchmviewer-4.0-0.2.beta2.fc9.x86_64 requires /bin/sh kcoloredit-4.0.3-2.fc9.x86_64 requires /bin/sh 1:kdbg-2.1.0-2.fc9.x86_64 requires /bin/sh kde-settings-4.0-22.fc9.1.noarch requires /bin/sh kde-settings-4.0-22.fc9.1.noarch requires /bin/sh kde-settings-kdm-4.0-22.fc9.1.noarch requires /bin/sh kde-settings-kdm-4.0-22.fc9.1.noarch requires /bin/sh 1:kdeaccessibility-4.0.72-1.fc10.i386 requires /bin/sh 1:kdeaccessibility-4.0.72-1.fc10.i386 requires /sbin/ldconfig 1:kdeaccessibility-4.0.72-1.fc10.x86_64 requires /bin/sh 1:kdeaccessibility-4.0.72-1.fc10.x86_64 requires /sbin/ldconfig kdeaddons-atlantikdesigner-3.5.9-1.fc9.x86_64 requires /bin/sh 7:kdeadmin-4.0.72-1.fc10.x86_64 requires /bin/sh 7:kdeadmin-4.0.72-1.fc10.x86_64 requires /usr/bin/env 7:kdeadmin-4.0.72-1.fc10.x86_64 requires /sbin/ldconfig 7:kdeadmin-kpackage-4.0.72-1.fc10.x86_64 requires /bin/sh kdeartwork-icons-4.0.72-1.fc10.x86_64 requires /bin/sh 6:kdebase-4.0.72-2.fc10.x86_64 requires /bin/sh 6:kdebase-4.0.72-2.fc10.x86_64 requires /bin/sh 6:kdebase-libs-4.0.72-2.fc10.i386 requires /sbin/ldconfig 6:kdebase-libs-4.0.72-2.fc10.x86_64 requires /sbin/ldconfig kdebase-runtime-4.0.72-2.fc10.x86_64 requires /sbin/ldconfig kdebase-runtime-4.0.72-2.fc10.x86_64 requires /usr/bin/perl kdebase-runtime-4.0.72-2.fc10.x86_64 requires /bin/sh kdebase-runtime-4.0.72-2.fc10.x86_64 requires /bin/sh kdebase-workspace-4.0.72-3.fc10.x86_64 requires /usr/bin/perl kdebase-workspace-4.0.72-3.fc10.x86_64 requires /bin/sh kdebase-workspace-4.0.72-3.fc10.x86_64 requires /bin/sh kdebase-workspace-libs-4.0.72-3.fc10.i386 requires /sbin/ldconfig kdebase-workspace-libs-4.0.72-3.fc10.x86_64 requires /sbin/ldconfig kdebase3-3.5.9-10.fc9.x86_64 requires /usr/bin/perl kdebase3-3.5.9-10.fc9.x86_64 requires /bin/sh kdebase3-3.5.9-10.fc9.x86_64 requires /bin/sh kdebase3-libs-3.5.9-10.fc9.i386 requires /sbin/ldconfig kdebase3-libs-3.5.9-10.fc9.x86_64 requires /sbin/ldconfig kdebindings-4.0.72-1.fc10.i386 requires /sbin/ldconfig kdebindings-4.0.72-1.fc10.i386 requires /usr/bin/env kdebindings-4.0.72-1.fc10.i386 requires /bin/sh kdebindings-4.0.72-1.fc10.x86_64 requires /sbin/ldconfig kdebindings-4.0.72-1.fc10.x86_64 requires /bin/sh kdebindings-4.0.72-1.fc10.x86_64 requires /usr/bin/env kdebluetooth-1.0-0.41.beta8.fc9.x86_64 requires /bin/sh kdebluetooth-1.0-0.41.beta8.fc9.x86_64 requires /bin/bash kdebluetooth-1.0-0.41.beta8.fc9.x86_64 requires /bin/sh kdebluetooth-1.0-0.41.beta8.fc9.x86_64 requires /usr/bin/kdesu kdeedu-4.0.72-2.fc10.x86_64 requires /bin/sh kdeedu-4.0.72-2.fc10.x86_64 requires /usr/bin/env kdeedu-kstars-4.0.72-2.fc10.x86_64 requires /bin/sh kdeedu-libs-4.0.72-2.fc10.i386 requires /sbin/ldconfig kdeedu-libs-4.0.72-2.fc10.x86_64 requires /sbin/ldconfig 6:kdegames-4.0.72-2.fc10.x86_64 requires /bin/sh 6:kdegames-libs-4.0.72-2.fc10.i386 requires /sbin/ldconfig 6:kdegames-libs-4.0.72-2.fc10.x86_64 requires /sbin/ldconfig kdegames3-3.5.9-1.fc9.x86_64 requires /bin/sh kdegames3-libs-3.5.9-1.fc9.i386 requires /sbin/ldconfig kdegames3-libs-3.5.9-1.fc9.x86_64 requires /sbin/ldconfig 7:kdegraphics-4.0.72-2.fc10.x86_64 requires /bin/sh 7:kdegraphics-libs-4.0.72-2.fc10.i386 requires /sbin/ldconfig 7:kdegraphics-libs-4.0.72-2.fc10.x86_64 requires /sbin/ldconfig 6:kdelibs-4.0.72-4.fc10.i386 requires /sbin/ldconfig 6:kdelibs-4.0.72-4.fc10.i386 requires /usr/bin/perl 6:kdelibs-4.0.72-4.fc10.i386 requires /bin/sh 6:kdelibs-4.0.72-4.fc10.i386 requires /bin/sh 6:kdelibs-4.0.72-4.fc10.x86_64 requires /sbin/ldconfig 6:kdelibs-4.0.72-4.fc10.x86_64 requires /usr/bin/perl 6:kdelibs-4.0.72-4.fc10.x86_64 requires /bin/sh 6:kdelibs-4.0.72-4.fc10.x86_64 requires /bin/sh 6:kdelibs-devel-4.0.72-4.fc10.i386 requires /bin/sh 6:kdelibs-devel-4.0.72-4.fc10.x86_64 requires /bin/sh kdelibs3-3.5.9-10.fc10.i386 requires /sbin/ldconfig kdelibs3-3.5.9-10.fc10.i386 requires /usr/bin/perl kdelibs3-3.5.9-10.fc10.i386 requires /bin/sh kdelibs3-3.5.9-10.fc10.i386 requires /bin/sh kdelibs3-3.5.9-10.fc10.x86_64 requires /sbin/ldconfig kdelibs3-3.5.9-10.fc10.x86_64 requires /usr/bin/perl kdelibs3-3.5.9-10.fc10.x86_64 requires /bin/sh kdelibs3-3.5.9-10.fc10.x86_64 requires /bin/sh kdelibs3-devel-3.5.9-10.fc10.i386 requires /bin/sh kdelibs3-devel-3.5.9-10.fc10.x86_64 requires /bin/sh 6:kdemultimedia-4.0.72-1.fc10.x86_64 requires /bin/sh 6:kdemultimedia-4.0.72-1.fc10.x86_64 requires /usr/bin/env 6:kdemultimedia-4.0.72-1.fc10.x86_64 requires /usr/bin/perl 6:kdemultimedia-libs-4.0.72-1.fc10.i386 requires /sbin/ldconfig 6:kdemultimedia-libs-4.0.72-1.fc10.x86_64 requires /sbin/ldconfig 7:kdenetwork-4.0.72-2.fc10.x86_64 requires /usr/bin/perl 7:kdenetwork-4.0.72-2.fc10.x86_64 requires /bin/sh 7:kdenetwork-4.0.72-2.fc10.x86_64 requires /bin/sh 7:kdenetwork-libs-4.0.72-2.fc10.i386 requires /sbin/ldconfig 7:kdenetwork-libs-4.0.72-2.fc10.x86_64 requires /sbin/ldconfig 6:kdepim-3.5.9-9.fc9.x86_64 requires /sbin/ldconfig 6:kdepim-3.5.9-9.fc9.x86_64 requires /usr/bin/perl 6:kdepim-3.5.9-9.fc9.x86_64 requires /bin/sh 6:kdepim-3.5.9-9.fc9.x86_64 requires /usr/bin/env 6:kdepim-3.5.9-9.fc9.x86_64 requires /bin/sh 6:kdepim-libs-3.5.9-9.fc9.i386 requires /sbin/ldconfig 6:kdepim-libs-3.5.9-9.fc9.x86_64 requires /sbin/ldconfig kdepimlibs-4.0.72-2.fc10.i386 requires /sbin/ldconfig kdepimlibs-4.0.72-2.fc10.i386 requires /usr/bin/perl kdepimlibs-4.0.72-2.fc10.x86_64 requires /sbin/ldconfig kdepimlibs-4.0.72-2.fc10.x86_64 requires /usr/bin/perl kdesdk-4.0.72-1.fc10.x86_64 requires /usr/bin/perl kdesdk-4.0.72-1.fc10.x86_64 requires /bin/sh kdesdk-4.0.72-1.fc10.x86_64 requires /usr/bin/env kdesdk-4.0.72-1.fc10.x86_64 requires /bin/bash kdesdk-4.0.72-1.fc10.x86_64 requires /bin/sh kdesdk-libs-4.0.72-1.fc10.i386 requires /sbin/ldconfig kdesdk-libs-4.0.72-1.fc10.x86_64 requires /sbin/ldconfig kdesvn-0.14.3-1.fc10.i386 requires /bin/sh kdesvn-0.14.3-1.fc10.i386 requires /bin/sh kdesvn-0.14.3-1.fc10.x86_64 requires /bin/sh kdesvn-0.14.3-1.fc10.x86_64 requires /bin/sh 7:kdetoys-4.0.72-1.fc10.i386 requires /bin/sh 7:kdetoys-4.0.72-1.fc10.i386 requires /sbin/ldconfig 7:kdetoys-4.0.72-1.fc10.x86_64 requires /bin/sh 7:kdetoys-4.0.72-1.fc10.x86_64 requires /sbin/ldconfig kdetv-0.8.9-10.fc9.i386 requires /bin/sh kdetv-0.8.9-10.fc9.x86_64 requires /bin/sh 6:kdeutils-4.0.72-1.fc10.i386 requires /sbin/ldconfig 6:kdeutils-4.0.72-1.fc10.i386 requires /bin/sh 6:kdeutils-4.0.72-1.fc10.x86_64 requires /bin/sh 6:kdeutils-4.0.72-1.fc10.x86_64 requires /sbin/ldconfig 9:kdevelop-3.5.1-4.fc9.x86_64 requires /bin/sh 9:kdevelop-3.5.1-4.fc9.x86_64 requires /usr/bin/perl 9:kdevelop-libs-3.5.1-4.fc9.i386 requires /sbin/ldconfig 9:kdevelop-libs-3.5.1-4.fc9.x86_64 requires /sbin/ldconfig 6:kdewebdev-3.5.9-3.fc9.x86_64 requires /bin/sh 6:kdewebdev-3.5.9-3.fc9.x86_64 requires /bin/sh 6:kdewebdev-3.5.9-3.fc9.x86_64 requires /usr/bin/perl 6:kdewebdev-libs-3.5.9-3.fc9.i386 requires /sbin/ldconfig 6:kdewebdev-libs-3.5.9-3.fc9.x86_64 requires /sbin/ldconfig kdiff3-0.9.92-13.fc9.x86_64 requires /bin/sh kdirstat-2.5.3-8.fc9.x86_64 requires /bin/sh kdirstat-2.5.3-8.fc9.x86_64 requires /usr/bin/perl kdissert-1.0.7-4.fc9.x86_64 requires /bin/sh kdnssd-avahi-0.1.3-0.6.20080116svn.fc9.i386 requires /sbin/ldconfig kdnssd-avahi-0.1.3-0.6.20080116svn.fc9.x86_64 requires /sbin/ldconfig keepalived-1.1.15-5.fc10.x86_64 requires /bin/sh keepalived-1.1.15-5.fc10.x86_64 requires /sbin/chkconfig keepalived-1.1.15-5.fc10.x86_64 requires /bin/sh keepalived-1.1.15-5.fc10.x86_64 requires /sbin/service keepassx-0.3.1-1.fc9.x86_64 requires /bin/sh kernel-2.6.25.2-5.fc10.x86_64 requires /bin/sh kernel-2.6.25.2-5.fc10.x86_64 requires /bin/sh kernel-debug-2.6.25.2-5.fc10.x86_64 requires /bin/sh kernel-debug-2.6.25.2-5.fc10.x86_64 requires /bin/sh kernel-debug-devel-2.6.25.2-5.fc10.x86_64 requires /usr/bin/find kernel-debug-devel-2.6.25.2-5.fc10.x86_64 requires /bin/sh kernel-devel-2.6.25.2-5.fc10.x86_64 requires /usr/bin/find kernel-devel-2.6.25.2-5.fc10.x86_64 requires /bin/sh kernel-xen-2.6.25.2-2.fc10.x86_64 requires /bin/sh kernel-xen-2.6.25.2-2.fc10.x86_64 requires /bin/sh kernel-xen-devel-2.6.25.2-2.fc10.x86_64 requires /bin/sh kernel-xen-devel-2.6.25.2-2.fc10.x86_64 requires /usr/bin/find kerneloops-0.10-11.fc9.x86_64 requires /bin/sh kerneloops-0.10-11.fc9.x86_64 requires /bin/bash kerry-0.2.1-7.fc9.x86_64 requires /bin/sh kerry-0.2.1-7.fc9.x86_64 requires /bin/sh ketchup-0.9.8-1.fc8.noarch requires /usr/bin/python keurocalc-1.0.0-2.rc2.fc9.x86_64 requires /bin/sh kexec-tools-1.102pre-10.fc10.x86_64 requires /bin/sh kexec-tools-1.102pre-10.fc10.x86_64 requires /usr/bin/perl kexec-tools-1.102pre-10.fc10.x86_64 requires /bin/bash kexec-tools-1.102pre-10.fc10.x86_64 requires /bin/sh keychain-2.6.8-3.fc9.noarch requires /bin/sh keyjnote-0.10.2-1.fc9.noarch requires /usr/bin/env keyutils-1.2-3.fc9.x86_64 requires /bin/sh keyutils-libs-1.2-3.fc9.i386 requires /sbin/ldconfig keyutils-libs-1.2-3.fc9.x86_64 requires /sbin/ldconfig kflickr-0.9.1-2.fc9.x86_64 requires /bin/sh kftpgrabber-0.8.1-6.fc9.i386 requires /bin/sh kftpgrabber-0.8.1-6.fc9.i386 requires /sbin/ldconfig kftpgrabber-0.8.1-6.fc9.x86_64 requires /bin/sh kftpgrabber-0.8.1-6.fc9.x86_64 requires /sbin/ldconfig kgrab-0.1.1-6.fc9.x86_64 requires /bin/sh kgtk-0.9.4-3.fc9.x86_64 requires /bin/bash kicad-2007.07.09-3.fc9.x86_64 requires /bin/sh kiconedit-4.0.3-2.fc9.x86_64 requires /bin/sh kid3-1.0-1.fc9.x86_64 requires /bin/sh kile-2.0.1-1.fc10.x86_64 requires /bin/sh kile-2.0.1-1.fc10.x86_64 requires /usr/bin/perl kinput2-v3.1-38.fc9.x86_64 requires /bin/sh kinput2-v3.1-38.fc9.x86_64 requires /usr/sbin/alternatives kinput2-v3.1-38.fc9.x86_64 requires /usr/sbin/alternatives kinput2-v3.1-38.fc9.x86_64 requires /bin/sh kio_sword-0.3-6.fc9.x86_64 requires /bin/sh kiosktool-1.0-10.fc9.x86_64 requires /bin/sh kipi-plugins-0.1.5-2.fc10.i386 requires /sbin/ldconfig kipi-plugins-0.1.5-2.fc10.i386 requires /bin/bash kipi-plugins-0.1.5-2.fc10.x86_64 requires /sbin/ldconfig kipi-plugins-0.1.5-2.fc10.x86_64 requires /bin/bash kismet-0.0.2007.10.R1-3.fc9.x86_64 requires /bin/sh kismet-0.0.2007.10.R1-3.fc9.x86_64 requires /etc/cron.daily kismet-0.0.2007.10.R1-3.fc9.x86_64 requires /bin/sh kismet-extras-0.0.2007.10.R1-3.fc9.x86_64 requires libMagick.so.10()(64bit) kismet-extras-0.0.2007.10.R1-3.fc9.x86_64 requires /usr/bin/perl kita-0.177.3-12.fc9.2.i386 requires /bin/sh kita-0.177.3-12.fc9.2.i386 requires /sbin/ldconfig kita-0.177.3-12.fc9.2.x86_64 requires /bin/sh kita-0.177.3-12.fc9.2.x86_64 requires /sbin/ldconfig kitsune-2.0-4.fc9.x86_64 requires /bin/sh klamav-0.42-3.fc9.x86_64 requires /bin/sh kleansweep-0.2.9-7.fc9.x86_64 requires /bin/sh kleansweep-0.2.9-7.fc9.x86_64 requires /usr/bin/env klear-0.7.0-1.svn113.fc9.x86_64 requires /bin/sh kmenu-gnome-0.7.1-1.fc9.noarch requires /bin/sh kmid-2.0-0.6.20080213svn.fc9.i386 requires /bin/sh kmid-2.0-0.6.20080213svn.fc9.i386 requires /sbin/ldconfig kmid-2.0-0.6.20080213svn.fc9.x86_64 requires /sbin/ldconfig kmid-2.0-0.6.20080213svn.fc9.x86_64 requires /bin/sh kmobiletools-0.4.3.3-4.fc9.x86_64 requires /bin/sh kmplayer-0.10.0c-4.fc9.x86_64 requires /bin/sh kmymoney2-0.9-1.fc10.x86_64 requires /bin/sh kmymoney2-libs-0.9-1.fc10.i386 requires /sbin/ldconfig kmymoney2-libs-0.9-1.fc10.x86_64 requires /sbin/ldconfig knetstats-1.6.1-8.fc9.x86_64 requires /bin/sh koan-0.8.0-1.fc9.noarch requires /usr/bin/python kodos-2.4.9-4.fc8.noarch requires /usr/bin/env kodos-2.4.9-4.fc8.noarch requires /usr/bin/python koffice-core-1.6.3-15.fc9.x86_64 requires /bin/sh koffice-filters-1.6.3-15.fc9.i386 requires /sbin/ldconfig koffice-filters-1.6.3-15.fc9.x86_64 requires /sbin/ldconfig koffice-karbon-1.6.3-15.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.x86_64 requires libWand.so.10()(64bit) koffice-kchart-1.6.3-15.fc9.i386 requires /sbin/ldconfig koffice-kchart-1.6.3-15.fc9.x86_64 requires /sbin/ldconfig koffice-kexi-1.6.3-15.fc9.i386 requires /sbin/ldconfig koffice-kexi-1.6.3-15.fc9.i386 requires /bin/sh koffice-kexi-1.6.3-15.fc9.x86_64 requires /sbin/ldconfig koffice-kexi-1.6.3-15.fc9.x86_64 requires /bin/sh koffice-kpresenter-1.6.3-15.fc9.i386 requires /sbin/ldconfig koffice-kpresenter-1.6.3-15.fc9.i386 requires /usr/bin/perl koffice-kpresenter-1.6.3-15.fc9.x86_64 requires /sbin/ldconfig koffice-kpresenter-1.6.3-15.fc9.x86_64 requires /usr/bin/perl koffice-kugar-1.6.3-15.fc9.i386 requires /sbin/ldconfig koffice-kugar-1.6.3-15.fc9.x86_64 requires /sbin/ldconfig koffice-kword-1.6.3-15.fc9.i386 requires /sbin/ldconfig koffice-kword-1.6.3-15.fc9.x86_64 requires /sbin/ldconfig koffice-libs-1.6.3-15.fc9.i386 requires /sbin/ldconfig koffice-libs-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.x86_64 requires /sbin/ldconfig koffice-libs-1.6.3-15.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.x86_64 requires libWand.so.10()(64bit) koji-1.2.3-1.fc9.noarch requires /usr/bin/python koji-builder-1.2.3-1.fc9.noarch requires /bin/sh koji-builder-1.2.3-1.fc9.noarch requires /usr/bin/git koji-builder-1.2.3-1.fc9.noarch requires /sbin/chkconfig koji-builder-1.2.3-1.fc9.noarch requires /usr/bin/svn koji-builder-1.2.3-1.fc9.noarch requires /usr/sbin/useradd koji-builder-1.2.3-1.fc9.noarch requires /usr/bin/cvs koji-builder-1.2.3-1.fc9.noarch requires /bin/sh koji-builder-1.2.3-1.fc9.noarch requires /usr/bin/python koji-builder-1.2.3-1.fc9.noarch requires /sbin/service koji-utils-1.2.3-1.fc9.noarch requires /bin/sh koji-utils-1.2.3-1.fc9.noarch requires /bin/sh koji-utils-1.2.3-1.fc9.noarch requires /usr/bin/python komparator-0.9-1.fc9.x86_64 requires /bin/sh konq-plugins-4.0.3-0.3.20080409svn.fc9.x86_64 requires /bin/sh konq-plugins-4.0.3-0.3.20080409svn.fc9.x86_64 requires /usr/bin/env konversation-1.0.1-6.fc9.x86_64 requires /bin/sh konversation-1.0.1-6.fc9.x86_64 requires /usr/bin/env konversation-1.0.1-6.fc9.x86_64 requires /bin/bash konversation-1.0.1-6.fc9.x86_64 requires /bin/sh konversation-1.0.1-6.fc9.x86_64 requires /usr/bin/perl kooldock-0.4.6-4.fc9.x86_64 requires /bin/sh kover-3-3.x86_64 requires /bin/sh koverartist-0.5-11.fc9.x86_64 requires /bin/sh kpathsea-2007-31.fc10.i386 requires /bin/sh kpathsea-2007-31.fc10.i386 requires /sbin/restorecon kpathsea-2007-31.fc10.x86_64 requires /bin/sh kpathsea-2007-31.fc10.x86_64 requires /sbin/restorecon kphotoalbum-3.1.1-2.fc10.x86_64 requires /bin/sh kphotobymail-0.4.1-1.fc7.noarch requires /usr/bin/env kpolynome-0.1.2-12.fc9.x86_64 requires /bin/sh kpowersave-0.7.3-3.fc9.x86_64 requires /bin/sh krb5-devel-1.6.3-10.fc9.i386 requires /bin/sh krb5-devel-1.6.3-10.fc9.x86_64 requires /bin/sh krb5-libs-1.6.3-10.fc9.i386 requires /sbin/ldconfig krb5-libs-1.6.3-10.fc9.x86_64 requires /sbin/ldconfig krb5-server-1.6.3-10.fc9.x86_64 requires /bin/sh krb5-server-1.6.3-10.fc9.x86_64 requires /sbin/install-info krb5-server-1.6.3-10.fc9.x86_64 requires /bin/bash krb5-server-1.6.3-10.fc9.x86_64 requires /bin/sh krb5-server-1.6.3-10.fc9.x86_64 requires /sbin/chkconfig krb5-workstation-1.6.3-10.fc9.x86_64 requires /bin/sh krb5-workstation-1.6.3-10.fc9.x86_64 requires /sbin/install-info krb5-workstation-1.6.3-10.fc9.x86_64 requires /bin/sh krb5-workstation-clients-1.6.3-10.fc9.x86_64 requires /bin/sh krb5-workstation-clients-1.6.3-10.fc9.x86_64 requires /sbin/install-info krb5-workstation-clients-1.6.3-10.fc9.x86_64 requires /bin/sh krb5-workstation-servers-1.6.3-10.fc9.x86_64 requires /bin/sh krb5-workstation-servers-1.6.3-10.fc9.x86_64 requires /etc/pam.d/remote krb5-workstation-servers-1.6.3-10.fc9.x86_64 requires /sbin/install-info krb5-workstation-servers-1.6.3-10.fc9.x86_64 requires /bin/bash krb5-workstation-servers-1.6.3-10.fc9.x86_64 requires /bin/sh krecipes-0.9.1-9.fc9.x86_64 requires /bin/sh kreetingkard-0.7.1-2.fc9.2.x86_64 requires /bin/sh krename-3.0.14-4.fc9.x86_64 requires /bin/sh krusader-1.80.0-5.fc9.x86_64 requires /bin/sh kscope-1.6.1-4.fc9.x86_64 requires /bin/sh ksensors-0.7.3-16.fc9.x86_64 requires /bin/sh ksh-20080202-1.fc9.x86_64 requires /bin/sh ksh-20080202-1.fc9.x86_64 requires /bin/sh kshutdown-1.0.1-2.fc9.x86_64 requires /bin/sh ksig-1.1-0.5.20080213.fc9.x86_64 requires /bin/sh ksirk-1.7-6.fc9.x86_64 requires /bin/sh ksirk-1.7-6.fc9.x86_64 requires /bin/bash ksmarttray-0.52-54.fc9.x86_64 requires /usr/bin/kdesu kst-1.6.0-2.fc10.i386 requires /sbin/ldconfig kst-1.6.0-2.fc10.x86_64 requires /sbin/ldconfig ksynaptics-0.3.3-5.fc9.x86_64 requires /bin/sh ktechlab-0.3.69-5.fc8.x86_64 requires /bin/sh ktorrent-3.0.2-3.fc10.i386 requires /bin/sh ktorrent-3.0.2-3.fc10.x86_64 requires /bin/sh kudzu-1.2.85-1.x86_64 requires /sbin/chkconfig kudzu-1.2.85-1.x86_64 requires /bin/sh kvm-68-1.fc10.x86_64 requires /bin/sh labyrinth-0.4.0-1.fc10.noarch requires /bin/sh labyrinth-0.4.0-1.fc10.noarch requires /usr/bin/env lacewing-1.10-10.fc9.x86_64 requires /bin/sh lagan-2.0-2.fc9.x86_64 requires /usr/bin/env lagan-2.0-2.fc9.x86_64 requires /usr/bin/perl 2:lam-7.1.2-11.fc9.x86_64 requires /bin/sh 2:lam-7.1.2-11.fc9.x86_64 requires /usr/bin/env 2:lam-7.1.2-11.fc9.x86_64 requires /sbin/ldconfig 2:lam-7.1.2-11.fc9.x86_64 requires /usr/sbin/alternatives 2:lam-7.1.2-11.fc9.x86_64 requires /bin/sh 2:lam-devel-7.1.2-11.fc9.i386 requires /bin/sh 2:lam-devel-7.1.2-11.fc9.i386 requires /sbin/ldconfig 2:lam-devel-7.1.2-11.fc9.i386 requires /usr/sbin/alternatives 2:lam-devel-7.1.2-11.fc9.x86_64 requires /bin/sh 2:lam-devel-7.1.2-11.fc9.x86_64 requires /sbin/ldconfig 2:lam-devel-7.1.2-11.fc9.x86_64 requires /usr/sbin/alternatives 2:lam-libs-7.1.2-11.fc9.i386 requires /bin/sh 2:lam-libs-7.1.2-11.fc9.i386 requires /sbin/ldconfig 2:lam-libs-7.1.2-11.fc9.i386 requires /usr/sbin/alternatives 2:lam-libs-7.1.2-11.fc9.x86_64 requires /bin/sh 2:lam-libs-7.1.2-11.fc9.x86_64 requires /sbin/ldconfig 2:lam-libs-7.1.2-11.fc9.x86_64 requires /usr/sbin/alternatives lapack-3.1.1-3.fc9.i386 requires /sbin/ldconfig lapack-3.1.1-3.fc9.x86_64 requires /sbin/ldconfig lash-0.5.4-2.fc9.i386 requires /sbin/install-info lash-0.5.4-2.fc9.i386 requires /bin/sh lash-0.5.4-2.fc9.x86_64 requires /bin/sh lash-0.5.4-2.fc9.x86_64 requires /sbin/install-info lasi-1.1.0-1.fc9.i386 requires /sbin/ldconfig lasi-1.1.0-1.fc9.x86_64 requires /sbin/ldconfig lat-1.2.3-3.fc9.x86_64 requires /bin/sh lat-1.2.3-3.fc9.x86_64 requires /bin/sh latex-mk-1.8-2.fc7.noarch requires /bin/sh latex-mk-1.8-2.fc7.noarch requires /sbin/install-info latex-mk-1.8-2.fc7.noarch requires /bin/sh latex2html-2002.2.1-8.fc9.noarch requires /bin/sh latex2html-2002.2.1-8.fc9.noarch requires /usr/bin/perl latexmk-3.20-1.fc8.noarch requires /usr/bin/perl lbrickbuster2-2.6-0.9.beta7.fc8.x86_64 requires /bin/sh lcdproc-0.5.2-4.fc9.x86_64 requires /bin/sh lcdproc-0.5.2-4.fc9.x86_64 requires /usr/bin/perl lcdproc-0.5.2-4.fc9.x86_64 requires /bin/sh lcdproc-0.5.2-4.fc9.x86_64 requires /sbin/chkconfig lcms-libs-1.17-4.fc9.i386 requires /sbin/ldconfig lcms-libs-1.17-4.fc9.x86_64 requires /sbin/ldconfig lcov-1.4-2.fc6.noarch requires /usr/bin/perl lcov-1.4-2.fc6.noarch requires /usr/bin/gcov ldapjdk-4.18-1.fc9.x86_64 requires /bin/sh ldirectord-2.1.3-1.fc9.x86_64 requires /bin/sh ldirectord-2.1.3-1.fc9.x86_64 requires /sbin/ldconfig ldirectord-2.1.3-1.fc9.x86_64 requires /usr/bin/perl ldirectord-2.1.3-1.fc9.x86_64 requires /bin/sh ldirectord-2.1.3-1.fc9.x86_64 requires /sbin/chkconfig ldm-2.0.4-1.fc9.x86_64 requires /bin/sh ldns-1.2.2-3.fc9.x86_64 requires /sbin/ldconfig leafnode-1.11.6-3.fc9.x86_64 requires /bin/sh leafpad-0.8.13-1.fc9.x86_64 requires /bin/sh less-418-3.fc9.x86_64 requires /bin/sh lesstif-0.95.0-23.fc9.i386 requires /sbin/ldconfig lesstif-0.95.0-23.fc9.x86_64 requires /sbin/ldconfig lesstif-clients-0.95.0-23.fc9.x86_64 requires /bin/sh lesstif-devel-0.95.0-23.fc9.i386 requires /bin/sh lesstif-devel-0.95.0-23.fc9.x86_64 requires /bin/sh lftp-3.7.1-1.fc10.i386 requires /bin/sh lftp-3.7.1-1.fc10.i386 requires /sbin/ldconfig lftp-3.7.1-1.fc10.i386 requires /usr/bin/perl lftp-3.7.1-1.fc10.x86_64 requires /sbin/ldconfig lftp-3.7.1-1.fc10.x86_64 requires /usr/bin/perl lftp-3.7.1-1.fc10.x86_64 requires /bin/sh lib3ds-1.3.0-2.fc9.i386 requires /sbin/ldconfig lib3ds-1.3.0-2.fc9.x86_64 requires /sbin/ldconfig lib3ds-devel-1.3.0-2.fc9.i386 requires /bin/sh lib3ds-devel-1.3.0-2.fc9.x86_64 requires /bin/sh lib765-0.4.1-3.fc9.i386 requires /sbin/ldconfig lib765-0.4.1-3.fc9.x86_64 requires /sbin/ldconfig libAfterImage-1.15-4.fc9.i386 requires /sbin/ldconfig libAfterImage-1.15-4.fc9.x86_64 requires /sbin/ldconfig libAfterImage-devel-1.15-4.fc9.i386 requires /bin/sh libAfterImage-devel-1.15-4.fc9.x86_64 requires /bin/sh libEMF-1.0.3-7.fc9.i386 requires /sbin/ldconfig libEMF-1.0.3-7.fc9.x86_64 requires /sbin/ldconfig libFS-1.0.0-7.fc9.i386 requires /sbin/ldconfig libFS-1.0.0-7.fc9.x86_64 requires /sbin/ldconfig libFoundation-1.1.3-11.fc9.i386 requires /sbin/ldconfig libFoundation-1.1.3-11.fc9.x86_64 requires /sbin/ldconfig libHX-1.15-1.fc10.i386 requires /sbin/ldconfig libHX-1.15-1.fc10.x86_64 requires /sbin/ldconfig libICE-1.0.4-3.fc9.i386 requires /sbin/ldconfig libICE-1.0.4-3.fc9.x86_64 requires /sbin/ldconfig libIDL-0.8.10-2.fc9.i386 requires /sbin/ldconfig libIDL-0.8.10-2.fc9.x86_64 requires /sbin/ldconfig libIDL-devel-0.8.10-2.fc9.i386 requires /bin/sh libIDL-devel-0.8.10-2.fc9.i386 requires /sbin/install-info libIDL-devel-0.8.10-2.fc9.i386 requires /bin/sh libIDL-devel-0.8.10-2.fc9.x86_64 requires /bin/sh libIDL-devel-0.8.10-2.fc9.x86_64 requires /sbin/install-info libIDL-devel-0.8.10-2.fc9.x86_64 requires /bin/sh libRmath-2.7.0-2.fc10.x86_64 requires /bin/sh libSM-1.0.2-5.fc9.i386 requires /sbin/ldconfig libSM-1.0.2-5.fc9.x86_64 requires /sbin/ldconfig libX11-1.1.4-1.fc9.i386 requires /sbin/ldconfig libX11-1.1.4-1.fc9.x86_64 requires /sbin/ldconfig libXNVCtrl-169.12-1.fc9.i386 requires /sbin/ldconfig libXNVCtrl-169.12-1.fc9.x86_64 requires /sbin/ldconfig libXScrnSaver-1.1.2-4.fc9.i386 requires /sbin/ldconfig libXScrnSaver-1.1.2-4.fc9.x86_64 requires /sbin/ldconfig libXTrap-1.0.0-5.fc9.i386 requires /sbin/ldconfig libXTrap-1.0.0-5.fc9.x86_64 requires /sbin/ldconfig libXau-1.0.3-5.fc9.i386 requires /sbin/ldconfig libXau-1.0.3-5.fc9.x86_64 requires /sbin/ldconfig libXaw-1.0.4-2.fc9.i386 requires /sbin/ldconfig libXaw-1.0.4-2.fc9.x86_64 requires /sbin/ldconfig libXcomposite-0.4.0-4.fc9.i386 requires /sbin/ldconfig libXcomposite-0.4.0-4.fc9.x86_64 requires /sbin/ldconfig libXcursor-1.1.9-2.fc9.i386 requires /sbin/ldconfig libXcursor-1.1.9-2.fc9.x86_64 requires /sbin/ldconfig libXdamage-1.1.1-4.fc9.i386 requires /sbin/ldconfig libXdamage-1.1.1-4.fc9.x86_64 requires /sbin/ldconfig libXdmcp-1.0.2-5.fc9.i386 requires /sbin/ldconfig libXdmcp-1.0.2-5.fc9.x86_64 requires /sbin/ldconfig libXevie-1.0.2-3.fc9.i386 requires /sbin/ldconfig libXevie-1.0.2-3.fc9.x86_64 requires /sbin/ldconfig libXext-1.0.4-1.fc9.i386 requires /sbin/ldconfig libXext-1.0.4-1.fc9.x86_64 requires /sbin/ldconfig libXfixes-4.0.3-3.fc9.i386 requires /sbin/ldconfig libXfixes-4.0.3-3.fc9.x86_64 requires /sbin/ldconfig libXfont-1.3.1-4.fc9.i386 requires /sbin/ldconfig libXfont-1.3.1-4.fc9.x86_64 requires /sbin/ldconfig libXfontcache-1.0.4-5.fc9.i386 requires /sbin/ldconfig libXfontcache-1.0.4-5.fc9.x86_64 requires /sbin/ldconfig libXft-2.1.12-5.fc9.i386 requires /sbin/ldconfig libXft-2.1.12-5.fc9.x86_64 requires /sbin/ldconfig libXi-1.1.3-4.fc9.i386 requires /sbin/ldconfig libXi-1.1.3-4.fc9.x86_64 requires /sbin/ldconfig libXinerama-1.0.3-1.fc9.i386 requires /sbin/ldconfig libXinerama-1.0.3-1.fc9.x86_64 requires /sbin/ldconfig libXmu-1.0.4-1.fc9.i386 requires /sbin/ldconfig libXmu-1.0.4-1.fc9.x86_64 requires /sbin/ldconfig libXp-1.0.0-11.fc9.i386 requires /sbin/ldconfig libXp-1.0.0-11.fc9.x86_64 requires /sbin/ldconfig libXpm-3.5.7-4.fc9.i386 requires /sbin/ldconfig libXpm-3.5.7-4.fc9.x86_64 requires /sbin/ldconfig libXrandr-1.2.2-3.fc9.i386 requires /sbin/ldconfig libXrandr-1.2.2-3.fc9.x86_64 requires /sbin/ldconfig libXrender-0.9.4-3.fc9.i386 requires /sbin/ldconfig libXrender-0.9.4-3.fc9.x86_64 requires /sbin/ldconfig libXres-1.0.3-4.fc9.i386 requires /sbin/ldconfig libXres-1.0.3-4.fc9.x86_64 requires /sbin/ldconfig libXt-1.0.4-5.fc9.i386 requires /sbin/ldconfig libXt-1.0.4-5.fc9.x86_64 requires /sbin/ldconfig libXtst-1.0.3-3.fc9.i386 requires /sbin/ldconfig libXtst-1.0.3-3.fc9.x86_64 requires /sbin/ldconfig libXv-1.0.3-5.fc9.i386 requires /sbin/ldconfig libXv-1.0.3-5.fc9.x86_64 requires /sbin/ldconfig libXvMC-1.0.4-4.fc9.i386 requires /sbin/ldconfig libXvMC-1.0.4-4.fc9.x86_64 requires /sbin/ldconfig libXxf86dga-1.0.2-2.fc9.i386 requires /sbin/ldconfig libXxf86dga-1.0.2-2.fc9.x86_64 requires /sbin/ldconfig libXxf86misc-1.0.1-5.fc9.i386 requires /sbin/ldconfig libXxf86misc-1.0.1-5.fc9.x86_64 requires /sbin/ldconfig libXxf86vm-1.0.1-5.fc9.i386 requires /sbin/ldconfig libXxf86vm-1.0.1-5.fc9.x86_64 requires /sbin/ldconfig libacl-2.2.47-1.fc9.i386 requires /sbin/ldconfig libacl-2.2.47-1.fc9.x86_64 requires /sbin/ldconfig libaio-0.3.106-4.2.i386 requires /sbin/ldconfig libaio-0.3.106-4.2.x86_64 requires /sbin/ldconfig libannodex-0.7.3-10.fc9.i386 requires /bin/sh libannodex-0.7.3-10.fc9.i386 requires /sbin/ldconfig libannodex-0.7.3-10.fc9.x86_64 requires /bin/sh libannodex-0.7.3-10.fc9.x86_64 requires /sbin/ldconfig libao-0.8.8-4.fc9.i386 requires /sbin/ldconfig libao-0.8.8-4.fc9.x86_64 requires /sbin/ldconfig libao-devel-0.8.8-4.fc9.i386 requires /usr/lib/libao.so.2 libao-devel-0.8.8-4.fc9.x86_64 requires /usr/lib64/libao.so.2 libapreq2-2.09-0.15.rc2.fc9.i386 requires /bin/sh libapreq2-2.09-0.15.rc2.fc9.i386 requires /sbin/ldconfig libapreq2-2.09-0.15.rc2.fc9.x86_64 requires /bin/sh libapreq2-2.09-0.15.rc2.fc9.x86_64 requires /sbin/ldconfig libapreq2-devel-2.09-0.15.rc2.fc9.i386 requires /bin/sh libapreq2-devel-2.09-0.15.rc2.fc9.x86_64 requires /bin/sh libarchive-2.4.17-1.fc9.i386 requires /sbin/ldconfig libarchive-2.4.17-1.fc9.x86_64 requires /sbin/ldconfig libart_lgpl-2.3.20-1.fc9.i386 requires /sbin/ldconfig libart_lgpl-2.3.20-1.fc9.x86_64 requires /sbin/ldconfig libart_lgpl-devel-2.3.20-1.fc9.i386 requires /bin/sh libart_lgpl-devel-2.3.20-1.fc9.x86_64 requires /bin/sh libassa-3.5.0-2.i386 requires /sbin/ldconfig libassa-3.5.0-2.x86_64 requires /sbin/ldconfig libassuan-devel-1.0.4-3.fc9.i386 requires /bin/sh libassuan-devel-1.0.4-3.fc9.i386 requires /sbin/install-info libassuan-devel-1.0.4-3.fc9.i386 requires /bin/sh libassuan-devel-1.0.4-3.fc9.x86_64 requires /bin/sh libassuan-devel-1.0.4-3.fc9.x86_64 requires /sbin/install-info libassuan-devel-1.0.4-3.fc9.x86_64 requires /bin/sh libast-0.7.1-0.6.20080502cvs.fc10.i386 requires /sbin/ldconfig libast-0.7.1-0.6.20080502cvs.fc10.x86_64 requires /sbin/ldconfig libast-devel-0.7.1-0.6.20080502cvs.fc10.i386 requires /bin/sh libast-devel-0.7.1-0.6.20080502cvs.fc10.x86_64 requires /bin/sh libattr-2.4.41-1.fc9.i386 requires /sbin/ldconfig libattr-2.4.41-1.fc9.x86_64 requires /sbin/ldconfig libavc1394-0.5.3-2.fc9.i386 requires /sbin/ldconfig libavc1394-0.5.3-2.fc9.x86_64 requires /sbin/ldconfig libax25-0.0.11-3.fc9.i386 requires /sbin/ldconfig libax25-0.0.11-3.fc9.x86_64 requires /sbin/ldconfig libbeagle-0.3.5-1.fc9.i386 requires /sbin/ldconfig libbeagle-0.3.5-1.fc9.x86_64 requires /sbin/ldconfig libbinio-1.4-9.fc9.i386 requires /sbin/ldconfig libbinio-1.4-9.fc9.x86_64 requires /sbin/ldconfig libbinio-devel-1.4-9.fc9.i386 requires /bin/sh libbinio-devel-1.4-9.fc9.i386 requires /sbin/install-info libbinio-devel-1.4-9.fc9.x86_64 requires /bin/sh libbinio-devel-1.4-9.fc9.x86_64 requires /sbin/install-info libbonobo-2.22.0-3.fc10.i386 requires /sbin/ldconfig libbonobo-2.22.0-3.fc10.i386 requires /usr/bin/perl libbonobo-2.22.0-3.fc10.x86_64 requires /sbin/ldconfig libbonobo-2.22.0-3.fc10.x86_64 requires /usr/bin/perl libbonoboui-2.22.0-2.fc9.i386 requires /sbin/ldconfig libbonoboui-2.22.0-2.fc9.x86_64 requires /sbin/ldconfig libbtctl-0.10.0-2.fc9.i386 requires /sbin/ldconfig libbtctl-0.10.0-2.fc9.x86_64 requires /sbin/ldconfig libburn-0.4.0-2.fc9.i386 requires /sbin/ldconfig libburn-0.4.0-2.fc9.x86_64 requires /sbin/ldconfig libc-client-2007a1-3.fc9.i386 requires /sbin/ldconfig libc-client-2007a1-3.fc9.x86_64 requires /sbin/ldconfig libcaca-0.99-0.4.beta11.fc9.i386 requires /sbin/ldconfig libcaca-0.99-0.4.beta11.fc9.x86_64 requires /sbin/ldconfig libcaca-devel-0.99-0.4.beta11.fc9.i386 requires /bin/sh libcaca-devel-0.99-0.4.beta11.fc9.x86_64 requires /bin/sh libcap-2.06-4.fc9.i386 requires /sbin/ldconfig libcap-2.06-4.fc9.x86_64 requires /sbin/ldconfig libcapseo-0.2.0-0.1.20080323git1c5f3e5.fc10.i386 requires /sbin/ldconfig libcapseo-0.2.0-0.1.20080323git1c5f3e5.fc10.x86_64 requires /sbin/ldconfig libcdaudio-0.99.12p2-9.fc9.i386 requires /sbin/ldconfig libcdaudio-0.99.12p2-9.fc9.x86_64 requires /sbin/ldconfig libcdaudio-devel-0.99.12p2-9.fc9.i386 requires /bin/sh libcdaudio-devel-0.99.12p2-9.fc9.x86_64 requires /bin/sh libcddb-1.3.0-4.fc9.i386 requires /sbin/ldconfig libcddb-1.3.0-4.fc9.x86_64 requires /sbin/ldconfig libcdio-0.79-3.fc9.i386 requires /bin/sh libcdio-0.79-3.fc9.i386 requires /sbin/install-info libcdio-0.79-3.fc9.i386 requires /sbin/ldconfig libcdio-0.79-3.fc9.x86_64 requires /sbin/install-info libcdio-0.79-3.fc9.x86_64 requires /sbin/ldconfig libcdio-0.79-3.fc9.x86_64 requires /bin/sh libcgi-1.0-8.fc9.i386 requires /sbin/ldconfig libcgi-1.0-8.fc9.x86_64 requires /sbin/ldconfig libchewing-0.3.0-11.fc10.i386 requires /sbin/ldconfig libchewing-0.3.0-11.fc10.x86_64 requires /sbin/ldconfig libchmxx-0.2-2.fc9.i386 requires /sbin/ldconfig libchmxx-0.2-2.fc9.x86_64 requires /sbin/ldconfig libcmml-0.9.1-5.fc9.i386 requires /sbin/ldconfig libcmml-0.9.1-5.fc9.x86_64 requires /sbin/ldconfig libcmpiutil-0.3-1.fc9.i386 requires /sbin/ldconfig libcmpiutil-0.3-1.fc9.x86_64 requires /sbin/ldconfig libcompizconfig-0.7.2-1.fc9.i386 requires /sbin/ldconfig libcompizconfig-0.7.2-1.fc9.x86_64 requires /sbin/ldconfig libconcord-0.20-5.fc10.i386 requires /sbin/ldconfig libconcord-0.20-5.fc10.x86_64 requires /sbin/ldconfig libconfig-1.2.1-2.fc9.i386 requires /sbin/ldconfig libconfig-1.2.1-2.fc9.x86_64 requires /sbin/ldconfig libconfig-devel-1.2.1-2.fc9.i386 requires /bin/sh libconfig-devel-1.2.1-2.fc9.i386 requires /sbin/install-info libconfig-devel-1.2.1-2.fc9.x86_64 requires /bin/sh libconfig-devel-1.2.1-2.fc9.x86_64 requires /sbin/install-info libconfuse-2.6-1.fc9.i386 requires /sbin/ldconfig libconfuse-2.6-1.fc9.x86_64 requires /sbin/ldconfig libcroco-0.6.1-5.fc9.i386 requires /bin/sh libcroco-0.6.1-5.fc9.x86_64 requires /bin/sh libcroco-devel-0.6.1-5.fc9.i386 requires /bin/sh libcroco-devel-0.6.1-5.fc9.x86_64 requires /bin/sh libctl-3.0.2-6.fc9.i386 requires /sbin/ldconfig libctl-3.0.2-6.fc9.x86_64 requires /sbin/ldconfig libctl-devel-3.0.2-6.fc9.i386 requires /bin/sh libctl-devel-3.0.2-6.fc9.x86_64 requires /bin/sh libcurl-7.18.1-2.fc10.i386 requires /sbin/ldconfig libcurl-7.18.1-2.fc10.x86_64 requires /sbin/ldconfig libcurl-devel-7.18.1-2.fc10.i386 requires /bin/sh libcurl-devel-7.18.1-2.fc10.x86_64 requires /bin/sh libdaemon-0.12-3.fc9.i386 requires /sbin/ldconfig libdaemon-0.12-3.fc9.x86_64 requires /sbin/ldconfig libdap-3.7.10-2.fc9.i386 requires /sbin/ldconfig libdap-3.7.10-2.fc9.x86_64 requires /sbin/ldconfig libdap-devel-3.7.10-2.fc9.i386 requires /bin/sh libdap-devel-3.7.10-2.fc9.x86_64 requires /bin/sh libdar-2.3.6-3.fc9.i386 requires /sbin/ldconfig libdar-2.3.6-3.fc9.x86_64 requires /sbin/ldconfig libdbi-0.8.3-1.fc9.i386 requires /sbin/ldconfig libdbi-0.8.3-1.fc9.x86_64 requires /sbin/ldconfig libdbi-drivers-0.8.3-1.fc9.x86_64 requires /sbin/ldconfig libdc1394-2.0.2-1.fc10.i386 requires /sbin/ldconfig libdc1394-2.0.2-1.fc10.x86_64 requires /sbin/ldconfig libdhcp-1.99.8-1.fc10.i386 requires /sbin/ldconfig libdhcp-1.99.8-1.fc10.x86_64 requires /sbin/ldconfig 12:libdhcp4client-4.0.0-15.fc10.i386 requires /sbin/ldconfig 12:libdhcp4client-4.0.0-15.fc10.x86_64 requires /sbin/ldconfig libdhcp6client-1.0.15-1.fc10.i386 requires /sbin/ldconfig libdhcp6client-1.0.15-1.fc10.x86_64 requires /sbin/ldconfig libdiscid-0.1.1-6.fc9.i386 requires /sbin/ldconfig libdiscid-0.1.1-6.fc9.x86_64 requires /sbin/ldconfig libdmx-1.0.2-5.fc9.i386 requires /sbin/ldconfig libdmx-1.0.2-5.fc9.x86_64 requires /sbin/ldconfig libdnet-1.12-3.fc9.i386 requires /sbin/ldconfig libdnet-1.12-3.fc9.x86_64 requires /sbin/ldconfig libdnet-devel-1.12-3.fc9.i386 requires /bin/sh libdnet-devel-1.12-3.fc9.x86_64 requires /bin/sh libdockapp-0.6.2-1.fc10.i386 requires /sbin/ldconfig libdockapp-0.6.2-1.fc10.x86_64 requires /sbin/ldconfig libdockapp-fonts-0.6.2-1.fc10.x86_64 requires /bin/sh libdrm-2.4.0-0.11.fc9.i386 requires /sbin/ldconfig libdrm-2.4.0-0.11.fc9.x86_64 requires /sbin/ldconfig libdsk-1.2.1-1.fc9.i386 requires /sbin/ldconfig libdsk-1.2.1-1.fc9.x86_64 requires /sbin/ldconfig libdstr-20080124-1.fc9.i386 requires /sbin/ldconfig libdstr-20080124-1.fc9.x86_64 requires /sbin/ldconfig libdv-1.0.0-4.fc9.i386 requires /sbin/ldconfig libdv-1.0.0-4.fc9.x86_64 requires /sbin/ldconfig libdvdnav-4.1.1-6.fc9.i386 requires /sbin/ldconfig libdvdnav-4.1.1-6.fc9.x86_64 requires /sbin/ldconfig libdvdnav-devel-4.1.1-6.fc9.i386 requires /bin/sh libdvdnav-devel-4.1.1-6.fc9.x86_64 requires /bin/sh libdvdread-4.1.1-6.fc9.i386 requires /sbin/ldconfig libdvdread-4.1.1-6.fc9.x86_64 requires /sbin/ldconfig libdwarves1-1.6-1.i386 requires /sbin/ldconfig libdwarves1-1.6-1.x86_64 requires /sbin/ldconfig libeXosip2-3.1.0-1.fc9.i386 requires /sbin/ldconfig libeXosip2-3.1.0-1.fc9.x86_64 requires /sbin/ldconfig libebml-0.7.8-1.fc9.i386 requires /sbin/ldconfig libebml-0.7.8-1.fc9.x86_64 requires /sbin/ldconfig libedit-2.10-4.20070831cvs.fc9.i386 requires /sbin/ldconfig libedit-2.10-4.20070831cvs.fc9.x86_64 requires /sbin/ldconfig libepc-0.3.5-1.fc10.i386 requires /sbin/ldconfig libepc-0.3.5-1.fc10.x86_64 requires /sbin/ldconfig libepc-ui-0.3.5-1.fc10.i386 requires /sbin/ldconfig libepc-ui-0.3.5-1.fc10.x86_64 requires /sbin/ldconfig liberation-fonts-1.0-4.fc9.noarch requires /bin/sh libesmtp-1.0.4-7.fc9.i386 requires /sbin/ldconfig libesmtp-1.0.4-7.fc9.x86_64 requires /sbin/ldconfig libesmtp-devel-1.0.4-7.fc9.i386 requires /bin/sh libesmtp-devel-1.0.4-7.fc9.x86_64 requires /bin/sh libetpan-0.52-5.fc9.i386 requires /sbin/ldconfig libetpan-0.52-5.fc9.x86_64 requires /sbin/ldconfig libetpan-devel-0.52-5.fc9.i386 requires /bin/sh libetpan-devel-0.52-5.fc9.x86_64 requires /bin/sh libevent-1.3e-2.fc9.i386 requires /sbin/ldconfig libevent-1.3e-2.fc9.x86_64 requires /sbin/ldconfig libevent-devel-1.3e-2.fc9.i386 requires /usr/bin/env libevent-devel-1.3e-2.fc9.x86_64 requires /usr/bin/env libewf-20080501-1.fc10.i386 requires /sbin/ldconfig libewf-20080501-1.fc10.x86_64 requires /sbin/ldconfig libexif-0.6.16-1.fc9.i386 requires /sbin/ldconfig libexif-0.6.16-1.fc9.x86_64 requires /sbin/ldconfig libextractor-0.5.19a-1.fc9.i386 requires /sbin/install-info libextractor-0.5.19a-1.fc9.i386 requires /sbin/ldconfig libextractor-0.5.19a-1.fc9.i386 requires /bin/sh libextractor-0.5.19a-1.fc9.x86_64 requires /bin/sh libextractor-0.5.19a-1.fc9.x86_64 requires /sbin/ldconfig libextractor-0.5.19a-1.fc9.x86_64 requires /sbin/install-info libextractor-devel-0.5.19a-1.fc9.i386 requires /usr/lib/pkgconfig libextractor-devel-0.5.19a-1.fc9.x86_64 requires /usr/lib64/pkgconfig libextractor-plugins-thumbnailgtk-0.5.19a-1.fc9.x86_64 requires /bin/sh libextractor-plugins-thumbnailgtk-0.5.19a-1.fc9.x86_64 requires /usr/sbin/update-alternatives libextractor-plugins-thumbnailqt-0.5.19a-1.fc9.x86_64 requires /bin/sh libextractor-plugins-thumbnailqt-0.5.19a-1.fc9.x86_64 requires /usr/sbin/update-alternatives libffi-3.0.1-1.fc9.i386 requires /sbin/ldconfig libffi-3.0.1-1.fc9.x86_64 requires /sbin/ldconfig libffi-devel-3.0.1-1.fc9.i386 requires /bin/sh libffi-devel-3.0.1-1.fc9.i386 requires /sbin/install-info libffi-devel-3.0.1-1.fc9.x86_64 requires /bin/sh libffi-devel-3.0.1-1.fc9.x86_64 requires /sbin/install-info libfishsound-0.9.1-1.fc9.i386 requires /sbin/ldconfig libfishsound-0.9.1-1.fc9.x86_64 requires /sbin/ldconfig libflaim-4.9.1052-1.fc9.i386 requires /sbin/ldconfig libflaim-4.9.1052-1.fc9.x86_64 requires /sbin/ldconfig libfontenc-1.0.4-5.fc9.i386 requires /sbin/ldconfig libfontenc-1.0.4-5.fc9.x86_64 requires /sbin/ldconfig libfprint-0.0.5-6.fc10.i386 requires /sbin/ldconfig libfprint-0.0.5-6.fc10.x86_64 requires /sbin/ldconfig libfreebob-1.0.7-4.fc9.i386 requires /sbin/ldconfig libfreebob-1.0.7-4.fc9.x86_64 requires /sbin/ldconfig libfwbuilder-2.1.16-2.fc9.i386 requires /sbin/ldconfig libfwbuilder-2.1.16-2.fc9.x86_64 requires /sbin/ldconfig libfwbuilder-devel-2.1.16-2.fc9.i386 requires /bin/sh libfwbuilder-devel-2.1.16-2.fc9.x86_64 requires /bin/sh libgadu-1.8.0-1.fc9.i386 requires /sbin/ldconfig libgadu-1.8.0-1.fc9.x86_64 requires /sbin/ldconfig libgail-gnome-1.20.0-2.fc9.i386 requires /sbin/ldconfig libgail-gnome-1.20.0-2.fc9.x86_64 requires /sbin/ldconfig libgalago-0.5.2-7.fc9.i386 requires /sbin/ldconfig libgalago-0.5.2-7.fc9.x86_64 requires /sbin/ldconfig libgalago-gtk-0.5.0-7.fc9.i386 requires /sbin/ldconfig libgalago-gtk-0.5.0-7.fc9.x86_64 requires /sbin/ldconfig libgcc-4.3.0-8.i386 requires /usr/sbin/libgcc_post_upgrade libgcc-4.3.0-8.x86_64 requires /usr/sbin/libgcc_post_upgrade libgcj-4.3.0-8.i386 requires /bin/sh libgcj-4.3.0-8.i386 requires /sbin/install-info libgcj-4.3.0-8.i386 requires /sbin/ldconfig libgcj-4.3.0-8.x86_64 requires /sbin/install-info libgcj-4.3.0-8.x86_64 requires /sbin/ldconfig libgcj-4.3.0-8.x86_64 requires /bin/sh libgcj-devel-4.3.0-8.i386 requires /usr/lib/libgcj.so.9 libgcj-devel-4.3.0-8.i386 requires /usr/lib/libz.so libgcj-devel-4.3.0-8.i386 requires /bin/awk libgcj-devel-4.3.0-8.x86_64 requires /usr/lib64/libgcj.so.9 libgcj-devel-4.3.0-8.x86_64 requires /bin/awk libgcj-devel-4.3.0-8.x86_64 requires /usr/lib64/libz.so libgconf-java-2.12.4-10.fc9.i386 requires /sbin/ldconfig libgconf-java-2.12.4-10.fc9.x86_64 requires /sbin/ldconfig libgconf-java-devel-2.12.4-10.fc9.i386 requires /bin/sh libgconf-java-devel-2.12.4-10.fc9.x86_64 requires /bin/sh libgcroots-0.2.1-3.fc9.i386 requires /sbin/ldconfig libgcroots-0.2.1-3.fc9.x86_64 requires /sbin/ldconfig libgcrypt-1.4.0-3.i386 requires /sbin/ldconfig libgcrypt-1.4.0-3.x86_64 requires /sbin/ldconfig libgcrypt-devel-1.4.0-3.i386 requires /bin/sh libgcrypt-devel-1.4.0-3.i386 requires /sbin/install-info libgcrypt-devel-1.4.0-3.i386 requires /bin/sh libgcrypt-devel-1.4.0-3.x86_64 requires /bin/sh libgcrypt-devel-1.4.0-3.x86_64 requires /sbin/install-info libgcrypt-devel-1.4.0-3.x86_64 requires /bin/sh 1:libgda-3.1.2-3.fc9.i386 requires /sbin/ldconfig 1:libgda-3.1.2-3.fc9.x86_64 requires /sbin/ldconfig 1:libgda-devel-3.1.2-3.fc9.i386 requires /bin/sh 1:libgda-devel-3.1.2-3.fc9.x86_64 requires /bin/sh libgdamm-3.0.0-1.fc9.i386 requires /sbin/ldconfig libgdamm-3.0.0-1.fc9.x86_64 requires /sbin/ldconfig libgdiplus-1.9-4.fc9.i386 requires /sbin/ldconfig libgdiplus-1.9-4.fc9.x86_64 requires /sbin/ldconfig libgdl-0.7.11-1.fc9.i386 requires /sbin/ldconfig libgdl-0.7.11-1.fc9.x86_64 requires /sbin/ldconfig libgeda-20080127-1.fc9.i386 requires /sbin/ldconfig libgeda-20080127-1.fc9.i386 requires /bin/sh libgeda-20080127-1.fc9.x86_64 requires /bin/sh libgeda-20080127-1.fc9.x86_64 requires /sbin/ldconfig libgee-0.1.1-3.fc9.i386 requires /sbin/ldconfig libgee-0.1.1-3.fc9.x86_64 requires /sbin/ldconfig libgeotiff-1.2.4-3.fc9.i386 requires /sbin/ldconfig libgeotiff-1.2.4-3.fc9.x86_64 requires /sbin/ldconfig libgfortran-4.3.0-8.i386 requires /sbin/ldconfig libgfortran-4.3.0-8.x86_64 requires /sbin/ldconfig libggz-0.0.14.1-1.fc9.i386 requires /sbin/ldconfig libggz-0.0.14.1-1.fc9.x86_64 requires /sbin/ldconfig libgii-1.0.2-6.fc9.i386 requires /sbin/ldconfig libgii-1.0.2-6.fc9.x86_64 requires /sbin/ldconfig 1:libglade-0.17-21.fc9.i386 requires /sbin/ldconfig 1:libglade-0.17-21.fc9.x86_64 requires /sbin/ldconfig 1:libglade-devel-0.17-21.fc9.i386 requires /usr/bin/env 1:libglade-devel-0.17-21.fc9.i386 requires /bin/sh 1:libglade-devel-0.17-21.fc9.x86_64 requires /usr/bin/env 1:libglade-devel-0.17-21.fc9.x86_64 requires /bin/sh libglade-java-2.12.5-8.fc9.i386 requires /sbin/ldconfig libglade-java-2.12.5-8.fc9.x86_64 requires /sbin/ldconfig libglade2-2.6.2-5.fc9.i386 requires /sbin/ldconfig libglade2-2.6.2-5.fc9.x86_64 requires /sbin/ldconfig libglade2-devel-2.6.2-5.fc9.i386 requires /usr/bin/python libglade2-devel-2.6.2-5.fc9.x86_64 requires /usr/bin/python libglademm24-2.6.6-1.fc9.i386 requires /sbin/ldconfig libglademm24-2.6.6-1.fc9.i386 requires /bin/sh libglademm24-2.6.6-1.fc9.x86_64 requires /bin/sh libglademm24-2.6.6-1.fc9.x86_64 requires /sbin/ldconfig libgnat-4.3.0-8.i386 requires /sbin/ldconfig libgnat-4.3.0-8.x86_64 requires /sbin/ldconfig libgnome-2.22.0-3.fc9.i386 requires /bin/sh libgnome-2.22.0-3.fc9.i386 requires /sbin/ldconfig libgnome-2.22.0-3.fc9.x86_64 requires /bin/sh libgnome-2.22.0-3.fc9.x86_64 requires /sbin/ldconfig libgnome-java-2.12.4-8.fc9.i386 requires /sbin/ldconfig libgnome-java-2.12.4-8.fc9.x86_64 requires /sbin/ldconfig libgnomecanvas-2.20.1.1-2.fc9.i386 requires /sbin/ldconfig libgnomecanvas-2.20.1.1-2.fc9.x86_64 requires /sbin/ldconfig libgnomecanvasmm26-2.22.0-1.fc9.i386 requires /sbin/ldconfig libgnomecanvasmm26-2.22.0-1.fc9.i386 requires /bin/sh libgnomecanvasmm26-2.22.0-1.fc9.x86_64 requires /bin/sh libgnomecanvasmm26-2.22.0-1.fc9.x86_64 requires /sbin/ldconfig libgnomecups-0.2.3-3.fc9.i386 requires /sbin/ldconfig libgnomecups-0.2.3-3.fc9.x86_64 requires /sbin/ldconfig 1:libgnomedb-3.0.0-6.fc9.i386 requires /sbin/ldconfig 1:libgnomedb-3.0.0-6.fc9.i386 requires /bin/sh 1:libgnomedb-3.0.0-6.fc9.x86_64 requires /bin/sh 1:libgnomedb-3.0.0-6.fc9.x86_64 requires /sbin/ldconfig 1:libgnomedb-devel-3.0.0-6.fc9.i386 requires /bin/sh 1:libgnomedb-devel-3.0.0-6.fc9.x86_64 requires /bin/sh libgnomedbmm-2.9.5-4.fc9.i386 requires /sbin/ldconfig libgnomedbmm-2.9.5-4.fc9.x86_64 requires /sbin/ldconfig libgnomekbd-2.23.2-1.fc10.i386 requires /bin/sh libgnomekbd-2.23.2-1.fc10.x86_64 requires /bin/sh libgnomemm26-2.22.0-1.i386 requires /sbin/ldconfig libgnomemm26-2.22.0-1.i386 requires /bin/sh libgnomemm26-2.22.0-1.x86_64 requires /bin/sh libgnomemm26-2.22.0-1.x86_64 requires /sbin/ldconfig libgnomeprint22-2.18.4-1.fc9.i386 requires /sbin/ldconfig libgnomeprint22-2.18.4-1.fc9.x86_64 requires /sbin/ldconfig libgnomeprintui22-2.18.2-1.fc9.i386 requires /sbin/ldconfig libgnomeprintui22-2.18.2-1.fc9.x86_64 requires /sbin/ldconfig libgnomeui-2.22.1-2.fc9.i386 requires /sbin/ldconfig libgnomeui-2.22.1-2.fc9.x86_64 requires /sbin/ldconfig libgnomeuimm26-2.22.0-1.fc9.i386 requires /bin/sh libgnomeuimm26-2.22.0-1.fc9.i386 requires /sbin/ldconfig libgnomeuimm26-2.22.0-1.fc9.x86_64 requires /bin/sh libgnomeuimm26-2.22.0-1.fc9.x86_64 requires /sbin/ldconfig libgomp-4.3.0-8.i386 requires /bin/sh libgomp-4.3.0-8.i386 requires /sbin/ldconfig libgomp-4.3.0-8.i386 requires /sbin/install-info libgomp-4.3.0-8.x86_64 requires /bin/sh libgomp-4.3.0-8.x86_64 requires /sbin/ldconfig libgomp-4.3.0-8.x86_64 requires /sbin/install-info libgpg-error-1.6-2.i386 requires /sbin/ldconfig libgpg-error-1.6-2.x86_64 requires /sbin/ldconfig libgpg-error-devel-1.6-2.i386 requires /bin/sh libgpg-error-devel-1.6-2.x86_64 requires /bin/sh libgpod-0.6.0-5.fc10.i386 requires /sbin/ldconfig libgpod-0.6.0-5.fc10.x86_64 requires /sbin/ldconfig libgringotts-1.2.1-4.fc9.i386 requires /sbin/ldconfig libgringotts-1.2.1-4.fc9.x86_64 requires /sbin/ldconfig libgsasl-0.2.18-6.fc9.i386 requires /sbin/ldconfig libgsasl-0.2.18-6.fc9.x86_64 requires /sbin/ldconfig libgsf-1.14.8-1.fc9.i386 requires /bin/sh libgsf-1.14.8-1.fc9.i386 requires /sbin/ldconfig libgsf-1.14.8-1.fc9.x86_64 requires /bin/sh libgsf-1.14.8-1.fc9.x86_64 requires /sbin/ldconfig libgsf-gnome-1.14.8-1.fc9.i386 requires /sbin/ldconfig libgsf-gnome-1.14.8-1.fc9.x86_64 requires /sbin/ldconfig libgssapi-0.11-3.fc9.i386 requires /sbin/ldconfig libgssapi-0.11-3.fc9.x86_64 requires /sbin/ldconfig libgssglue-0.1-5.fc9.i386 requires /sbin/ldconfig libgssglue-0.1-5.fc9.x86_64 requires /sbin/ldconfig libgstroke-0.5.1-17.fc9.i386 requires /sbin/ldconfig libgstroke-0.5.1-17.fc9.x86_64 requires /sbin/ldconfig libgtk-java-2.8.7-7.fc9.i386 requires /sbin/ldconfig libgtk-java-2.8.7-7.fc9.x86_64 requires /sbin/ldconfig libgtk-java-devel-2.8.7-7.fc9.i386 requires /bin/sh libgtk-java-devel-2.8.7-7.fc9.x86_64 requires /bin/sh libgtksourceviewmm-0.3.1-1.fc8.i386 requires /sbin/ldconfig libgtksourceviewmm-0.3.1-1.fc8.x86_64 requires /sbin/ldconfig libgtop2-2.22.1-1.fc9.i386 requires /sbin/ldconfig libgtop2-2.22.1-1.fc9.x86_64 requires /sbin/ldconfig libgweather-2.23.2-1.fc10.i386 requires /sbin/ldconfig libgweather-2.23.2-1.fc10.i386 requires /bin/sh libgweather-2.23.2-1.fc10.x86_64 requires /bin/sh libgweather-2.23.2-1.fc10.x86_64 requires /sbin/ldconfig libhangul-0.0.6-4.fc9.i386 requires /sbin/ldconfig libhangul-0.0.6-4.fc9.x86_64 requires /sbin/ldconfig libhugetlbfs-1.1-6.fc9.x86_64 requires /bin/bash libhugetlbfs-test-1.1-6.fc9.x86_64 requires /bin/bash libibverbs-1.1.1-3.fc9.i386 requires /sbin/ldconfig libibverbs-1.1.1-3.fc9.x86_64 requires /sbin/ldconfig libical-0.30-1.fc9.i386 requires /sbin/ldconfig libical-0.30-1.fc9.x86_64 requires /sbin/ldconfig libical-devel-0.30-1.fc9.i386 requires /bin/sh libical-devel-0.30-1.fc9.x86_64 requires /bin/sh libicu-3.8.1-7.fc9.i386 requires /sbin/ldconfig libicu-3.8.1-7.fc9.x86_64 requires /sbin/ldconfig libicu-devel-3.8.1-7.fc9.i386 requires /bin/sh libicu-devel-3.8.1-7.fc9.x86_64 requires /bin/sh libid3tag-0.15.1b-6.fc10.i386 requires /sbin/ldconfig libid3tag-0.15.1b-6.fc10.x86_64 requires /sbin/ldconfig libident-0.32-2.fc9.i386 requires /sbin/ldconfig libident-0.32-2.fc9.x86_64 requires /sbin/ldconfig libident-tools-0.32-2.fc9.x86_64 requires /bin/sh libidn-0.6.14-7.i386 requires /bin/sh libidn-0.6.14-7.i386 requires /sbin/ldconfig libidn-0.6.14-7.i386 requires /sbin/install-info libidn-0.6.14-7.x86_64 requires /bin/sh libidn-0.6.14-7.x86_64 requires /sbin/ldconfig libidn-0.6.14-7.x86_64 requires /sbin/install-info libiec61883-1.1.0-4.fc9.i386 requires /sbin/ldconfig libiec61883-1.1.0-4.fc9.x86_64 requires /sbin/ldconfig libieee1284-0.2.11-3.fc9.i386 requires /sbin/ldconfig libieee1284-0.2.11-3.fc9.x86_64 requires /sbin/ldconfig libifp-1.0.0.2-7.fc9.i386 requires /sbin/ldconfig libifp-1.0.0.2-7.fc9.i386 requires /bin/bash libifp-1.0.0.2-7.fc9.x86_64 requires /sbin/ldconfig libifp-1.0.0.2-7.fc9.x86_64 requires /bin/bash libipoddevice-0.5.3-4.fc9.i386 requires /sbin/ldconfig libipoddevice-0.5.3-4.fc9.x86_64 requires /sbin/ldconfig libiptcdata-1.0.2-2.fc9.i386 requires /sbin/ldconfig libiptcdata-1.0.2-2.fc9.x86_64 requires /sbin/ldconfig libisofs-0.2.8-3.fc9.i386 requires /sbin/ldconfig libisofs-0.2.8-3.fc9.x86_64 requires /sbin/ldconfig libitl-0.6.4-4.fc9.i386 requires /sbin/ldconfig libitl-0.6.4-4.fc9.x86_64 requires /sbin/ldconfig libjingle-0.3.11-8.fc9.i386 requires /sbin/ldconfig libjingle-0.3.11-8.fc9.x86_64 requires /sbin/ldconfig libjpeg-6b-41.fc9.i386 requires /sbin/ldconfig libjpeg-6b-41.fc9.x86_64 requires /sbin/ldconfig libkdcraw-0.1.4-1.fc10.i386 requires /bin/sh libkdcraw-0.1.4-1.fc10.x86_64 requires /bin/sh libkexif-0.2.5-4.fc9.i386 requires /sbin/ldconfig libkexif-0.2.5-4.fc9.x86_64 requires /sbin/ldconfig libkexiv2-0.1.7-1.fc10.i386 requires /sbin/ldconfig libkexiv2-0.1.7-1.fc10.x86_64 requires /sbin/ldconfig libkipi-0.1.6-1.fc10.i386 requires /bin/sh libkipi-0.1.6-1.fc10.x86_64 requires /bin/sh libksba-1.0.3-2.fc9.i386 requires /sbin/ldconfig libksba-1.0.3-2.fc9.x86_64 requires /sbin/ldconfig libksba-devel-1.0.3-2.fc9.i386 requires /sbin/install-info libksba-devel-1.0.3-2.fc9.i386 requires /bin/sh libksba-devel-1.0.3-2.fc9.i386 requires /bin/sh libksba-devel-1.0.3-2.fc9.x86_64 requires /sbin/install-info libksba-devel-1.0.3-2.fc9.x86_64 requires /bin/sh libksba-devel-1.0.3-2.fc9.x86_64 requires /bin/sh liblo-0.24-2.fc9.i386 requires /sbin/ldconfig liblo-0.24-2.fc9.x86_64 requires /sbin/ldconfig liblqr-1-0.1.0-5.fc9.i386 requires /sbin/ldconfig liblqr-1-0.1.0-5.fc9.x86_64 requires /sbin/ldconfig liblrdf-0.4.0-13.fc9.i386 requires /sbin/ldconfig liblrdf-0.4.0-13.fc9.x86_64 requires /sbin/ldconfig libmal-0.31-8.fc9.i386 requires /sbin/ldconfig libmal-0.31-8.fc9.x86_64 requires /sbin/ldconfig libmalaga-7.12-1.fc9.i386 requires /sbin/ldconfig libmalaga-7.12-1.fc9.x86_64 requires /sbin/ldconfig libmatchbox-1.9-3.fc9.i386 requires /sbin/ldconfig libmatchbox-1.9-3.fc9.x86_64 requires /sbin/ldconfig libmatheval-1.1.5-2.fc9.i386 requires /sbin/ldconfig libmatheval-1.1.5-2.fc9.x86_64 requires /sbin/ldconfig libmatheval-devel-1.1.5-2.fc9.i386 requires /bin/sh libmatheval-devel-1.1.5-2.fc9.i386 requires /sbin/install-info libmatheval-devel-1.1.5-2.fc9.x86_64 requires /bin/sh libmatheval-devel-1.1.5-2.fc9.x86_64 requires /sbin/install-info libmatroska-0.8.1-3.fc9.i386 requires /sbin/ldconfig libmatroska-0.8.1-3.fc9.x86_64 requires /sbin/ldconfig libmcrypt-2.5.8-5.fc9.i386 requires /sbin/ldconfig libmcrypt-2.5.8-5.fc9.x86_64 requires /sbin/ldconfig libmcrypt-devel-2.5.8-5.fc9.i386 requires /bin/sh libmcrypt-devel-2.5.8-5.fc9.x86_64 requires /bin/sh libmikmod-3.2.0-3.beta2.fc9.i386 requires /sbin/ldconfig libmikmod-3.2.0-3.beta2.fc9.x86_64 requires /sbin/ldconfig libmikmod-devel-3.2.0-3.beta2.fc9.i386 requires /bin/sh libmikmod-devel-3.2.0-3.beta2.fc9.i386 requires /bin/sh libmikmod-devel-3.2.0-3.beta2.fc9.x86_64 requires /bin/sh libmikmod-devel-3.2.0-3.beta2.fc9.x86_64 requires /bin/sh libmng-1.0.9-6.1.i386 requires /sbin/ldconfig libmng-1.0.9-6.1.x86_64 requires /sbin/ldconfig libmodelfile-0.1.92-5.fc9.i386 requires /sbin/ldconfig libmodelfile-0.1.92-5.fc9.x86_64 requires /sbin/ldconfig 1:libmodplug-0.8.4-3.fc9.i386 requires /sbin/ldconfig 1:libmodplug-0.8.4-3.fc9.x86_64 requires /sbin/ldconfig libmowgli-0.5.0-2.fc9.i386 requires /sbin/ldconfig libmowgli-0.5.0-2.fc9.x86_64 requires /sbin/ldconfig libmp4v2-1.5.0.1-6.fc9.i386 requires /sbin/ldconfig libmp4v2-1.5.0.1-6.fc9.x86_64 requires /sbin/ldconfig libmpcdec-1.2.6-4.fc9.i386 requires /sbin/ldconfig libmpcdec-1.2.6-4.fc9.x86_64 requires /sbin/ldconfig libmpd-0.15.0-3.fc9.i386 requires /sbin/ldconfig libmpd-0.15.0-3.fc9.x86_64 requires /sbin/ldconfig libmspack-0.0-0.5.20060920alpha.fc9.i386 requires /sbin/ldconfig libmspack-0.0-0.5.20060920alpha.fc9.x86_64 requires /sbin/ldconfig libmtp-0.2.6.1-1.fc9.i386 requires /sbin/ldconfig libmtp-0.2.6.1-1.fc9.x86_64 requires /sbin/ldconfig libmudflap-4.3.0-8.i386 requires /sbin/ldconfig libmudflap-4.3.0-8.x86_64 requires /sbin/ldconfig libmusicbrainz-2.1.5-6.fc9.i386 requires /sbin/ldconfig libmusicbrainz-2.1.5-6.fc9.x86_64 requires /sbin/ldconfig libnasl-2.2.10-5.fc9.i386 requires /sbin/ldconfig libnasl-2.2.10-5.fc9.x86_64 requires /sbin/ldconfig libnasl-devel-2.2.10-5.fc9.i386 requires /bin/sh libnasl-devel-2.2.10-5.fc9.x86_64 requires /bin/sh libnc-dap-3.7.0-9.fc9.i386 requires /sbin/ldconfig libnc-dap-3.7.0-9.fc9.x86_64 requires /sbin/ldconfig libnc-dap-devel-3.7.0-9.fc9.i386 requires /bin/sh libnc-dap-devel-3.7.0-9.fc9.x86_64 requires /bin/sh libnemesi-0.6.4-0.3.rc2.fc9.i386 requires /sbin/ldconfig libnemesi-0.6.4-0.3.rc2.fc9.x86_64 requires /sbin/ldconfig libnet-devel-1.1.2.1-12.fc9.i386 requires /bin/sh libnet-devel-1.1.2.1-12.fc9.x86_64 requires /bin/sh libnet10-1.0.2a-14.fc9.x86_64 requires /bin/sh libnetfilter_conntrack-0.0.89-0.1.svn7356.fc9.i386 requires /sbin/ldconfig libnetfilter_conntrack-0.0.89-0.1.svn7356.fc9.x86_64 requires /sbin/ldconfig libnetfilter_log-0.0.13-6.fc9.i386 requires /sbin/ldconfig libnetfilter_log-0.0.13-6.fc9.x86_64 requires /sbin/ldconfig libnetfilter_queue-0.0.15-4.fc9.i386 requires /sbin/ldconfig libnetfilter_queue-0.0.15-4.fc9.x86_64 requires /sbin/ldconfig libnfnetlink-0.0.33-0.1.svn7211.fc9.i386 requires /sbin/ldconfig libnfnetlink-0.0.33-0.1.svn7211.fc9.x86_64 requires /sbin/ldconfig libnids-1.22-4.fc9.i386 requires /sbin/ldconfig libnids-1.22-4.fc9.x86_64 requires /sbin/ldconfig libnjb-2.2.6-3.fc9.i386 requires /sbin/ldconfig libnjb-2.2.6-3.fc9.x86_64 requires /sbin/ldconfig libnl-1.1-3.fc9.i386 requires /sbin/ldconfig libnl-1.1-3.fc9.x86_64 requires /sbin/ldconfig libnotify-0.4.4-10.fc9.i386 requires /bin/sh libnotify-0.4.4-10.fc9.x86_64 requires /bin/sh libnova-0.12.1-3.fc10.i386 requires /sbin/ldconfig libnova-0.12.1-3.fc10.x86_64 requires /sbin/ldconfig libnss-mysql-1.5-7.fc9.i386 requires /sbin/ldconfig libnss-mysql-1.5-7.fc9.x86_64 requires /sbin/ldconfig libntlm-0.4.2-1.fc9.i386 requires /sbin/ldconfig libntlm-0.4.2-1.fc9.x86_64 requires /sbin/ldconfig libobjc-4.3.0-8.i386 requires /sbin/ldconfig libobjc-4.3.0-8.x86_64 requires /sbin/ldconfig libofa-0.9.3-13.fc9.i386 requires /sbin/ldconfig libofa-0.9.3-13.fc9.x86_64 requires /sbin/ldconfig libofx-0.8.3-5.i386 requires /sbin/ldconfig libofx-0.8.3-5.x86_64 requires /sbin/ldconfig 2:libogg-1.1.3-9.fc9.i386 requires /sbin/ldconfig 2:libogg-1.1.3-9.fc9.x86_64 requires /sbin/ldconfig liboggz-0.9.5-2.fc9.i386 requires /sbin/ldconfig liboggz-0.9.5-2.fc9.i386 requires /bin/sh liboggz-0.9.5-2.fc9.x86_64 requires /sbin/ldconfig liboggz-0.9.5-2.fc9.x86_64 requires /bin/sh liboil-0.3.14-1.fc9.i386 requires /sbin/ldconfig liboil-0.3.14-1.fc9.x86_64 requires /sbin/ldconfig libopendaap-0.4.0-5.fc9.i386 requires /sbin/ldconfig libopendaap-0.4.0-5.fc9.x86_64 requires /sbin/ldconfig libopenraw-0.0.5-1.fc9.i386 requires /sbin/ldconfig libopenraw-0.0.5-1.fc9.x86_64 requires /sbin/ldconfig libopenraw-gnome-0.0.5-1.fc9.i386 requires /sbin/ldconfig libopenraw-gnome-0.0.5-1.fc9.x86_64 requires /sbin/ldconfig libopensync-0.36-2.fc9.i386 requires /sbin/ldconfig libopensync-0.36-2.fc9.x86_64 requires /sbin/ldconfig libopensync-plugin-google-calendar-0.35-2.fc9.x86_64 requires /usr/bin/env libopensync-plugin-kdepim-0.35-2.fc9.x86_64 requires /sbin/ldconfig libopm-0.1-7.20050731cvs.fc9.i386 requires /sbin/ldconfig libopm-0.1-7.20050731cvs.fc9.x86_64 requires /sbin/ldconfig liborigin-20071119-3.fc10.i386 requires /sbin/ldconfig liborigin-20071119-3.fc10.x86_64 requires /sbin/ldconfig libosip2-3.1.0-1.fc9.i386 requires /sbin/ldconfig libosip2-3.1.0-1.fc9.x86_64 requires /sbin/ldconfig libotf-0.9.7-4.fc10.i386 requires /sbin/ldconfig libotf-0.9.7-4.fc10.x86_64 requires /sbin/ldconfig libotf-devel-0.9.7-4.fc10.i386 requires /bin/sh libotf-devel-0.9.7-4.fc10.x86_64 requires /bin/sh libotr-3.1.0-2.fc9.i386 requires /sbin/ldconfig libotr-3.1.0-2.fc9.x86_64 requires /sbin/ldconfig libp11-0.2.3-2.fc9.i386 requires /sbin/ldconfig libp11-0.2.3-2.fc9.x86_64 requires /sbin/ldconfig libpanelappletmm-2.22.0-1.fc9.i386 requires /sbin/ldconfig libpanelappletmm-2.22.0-1.fc9.x86_64 requires /sbin/ldconfig libpano12-2.8.6-2.fc9.i386 requires /sbin/ldconfig libpano12-2.8.6-2.fc9.x86_64 requires /sbin/ldconfig libpano13-2.9.12-5.fc9.i386 requires /sbin/ldconfig libpano13-2.9.12-5.fc9.x86_64 requires /sbin/ldconfig libpaper-1.1.23-2.fc9.i386 requires /sbin/ldconfig libpaper-1.1.23-2.fc9.i386 requires /bin/bash libpaper-1.1.23-2.fc9.x86_64 requires /sbin/ldconfig libpaper-1.1.23-2.fc9.x86_64 requires /bin/bash libpar2-0.2-5.fc9.i386 requires /sbin/ldconfig libpar2-0.2-5.fc9.x86_64 requires /sbin/ldconfig 14:libpcap-0.9.8-2.fc9.i386 requires /sbin/ldconfig 14:libpcap-0.9.8-2.fc9.x86_64 requires /sbin/ldconfig libpciaccess-0.10-2.fc9.i386 requires /sbin/ldconfig libpciaccess-0.10-2.fc9.x86_64 requires /sbin/ldconfig libpfm-3.4-1.fc10.i386 requires /sbin/ldconfig libpfm-3.4-1.fc10.x86_64 requires /sbin/ldconfig 2:libpng-1.2.24-1.fc9.i386 requires /sbin/ldconfig 2:libpng-1.2.24-1.fc9.x86_64 requires /sbin/ldconfig 2:libpng-devel-1.2.24-1.fc9.i386 requires /bin/sh 2:libpng-devel-1.2.24-1.fc9.x86_64 requires /bin/sh libpng10-1.0.37-1.fc10.i386 requires /sbin/ldconfig libpng10-1.0.37-1.fc10.x86_64 requires /sbin/ldconfig libpolyxmass-0.9.1-2.fc9.i386 requires /sbin/ldconfig libpolyxmass-0.9.1-2.fc9.x86_64 requires /sbin/ldconfig libpqxx-2.6.8-10.fc9.i386 requires /sbin/ldconfig libpqxx-2.6.8-10.fc9.x86_64 requires /sbin/ldconfig libpqxx-devel-2.6.8-10.fc9.i386 requires /bin/sh libpqxx-devel-2.6.8-10.fc9.x86_64 requires /bin/sh libprelude-0.9.17.1-1.fc10.i386 requires /sbin/ldconfig libprelude-0.9.17.1-1.fc10.i386 requires /bin/sh libprelude-0.9.17.1-1.fc10.x86_64 requires /sbin/ldconfig libprelude-0.9.17.1-1.fc10.x86_64 requires /bin/sh libprelude-devel-0.9.17.1-1.fc10.i386 requires /bin/sh libprelude-devel-0.9.17.1-1.fc10.x86_64 requires /bin/sh libpreludedb-0.9.14.1-2.fc9.i386 requires /sbin/ldconfig libpreludedb-0.9.14.1-2.fc9.x86_64 requires /sbin/ldconfig libpreludedb-devel-0.9.14.1-2.fc9.i386 requires /bin/sh libpreludedb-devel-0.9.14.1-2.fc9.x86_64 requires /bin/sh libpri-1.4.3-2.fc9.i386 requires /sbin/ldconfig libpri-1.4.3-2.fc9.x86_64 requires /sbin/ldconfig libpurple-2.4.1-3.fc10.i386 requires /usr/bin/env libpurple-2.4.1-3.fc10.i386 requires /sbin/ldconfig libpurple-2.4.1-3.fc10.i386 requires /bin/sh libpurple-2.4.1-3.fc10.x86_64 requires /usr/bin/env libpurple-2.4.1-3.fc10.x86_64 requires /sbin/ldconfig libpurple-2.4.1-3.fc10.x86_64 requires /bin/sh libqalculate-0.9.6-4.fc9.i386 requires /sbin/ldconfig libqalculate-0.9.6-4.fc9.x86_64 requires /sbin/ldconfig librapi-0.11-2.fc9.i386 requires /sbin/ldconfig librapi-0.11-2.fc9.i386 requires /bin/bash librapi-0.11-2.fc9.x86_64 requires /sbin/ldconfig librapi-0.11-2.fc9.x86_64 requires /bin/bash libraw1394-1.3.0-6.fc9.i386 requires /sbin/ldconfig libraw1394-1.3.0-6.fc9.x86_64 requires /sbin/ldconfig librdmacm-1.0.7-1.fc9.i386 requires /sbin/ldconfig librdmacm-1.0.7-1.fc9.x86_64 requires /sbin/ldconfig librdmacm-devel-1.0.7-1.fc9.i386 requires /usr/include/infiniband/verbs.h librdmacm-devel-1.0.7-1.fc9.x86_64 requires /usr/include/infiniband/verbs.h libreadline-java-0.8.0-20.fc9.x86_64 requires /bin/sh librelp-0.1.1-2.fc10.i386 requires /bin/sh librelp-0.1.1-2.fc10.i386 requires /sbin/ldconfig librelp-0.1.1-2.fc10.x86_64 requires /bin/sh librelp-0.1.1-2.fc10.x86_64 requires /sbin/ldconfig librfid-0.2.0-1.fc9.i386 requires /sbin/ldconfig librfid-0.2.0-1.fc9.x86_64 requires /sbin/ldconfig librra-0.11-2.fc9.i386 requires /sbin/ldconfig librra-0.11-2.fc9.x86_64 requires /sbin/ldconfig librsvg2-2.22.2-1.fc9.i386 requires /usr/bin/env librsvg2-2.22.2-1.fc9.i386 requires /bin/sh librsvg2-2.22.2-1.fc9.x86_64 requires /bin/sh librsvg2-2.22.2-1.fc9.x86_64 requires /usr/bin/env librsync-0.9.7-12.fc9.i386 requires /sbin/ldconfig librsync-0.9.7-12.fc9.x86_64 requires /sbin/ldconfig librtfcomp-1.1-3.fc9.i386 requires /sbin/ldconfig librtfcomp-1.1-3.fc9.x86_64 requires /sbin/ldconfig librx-1.5-10.fc9.i386 requires /sbin/ldconfig librx-1.5-10.fc9.x86_64 requires /sbin/ldconfig librx-devel-1.5-10.fc9.i386 requires /bin/sh librx-devel-1.5-10.fc9.x86_64 requires /bin/sh libsamplerate-0.1.3-1.fc10.i386 requires /sbin/ldconfig libsamplerate-0.1.3-1.fc10.x86_64 requires /sbin/ldconfig libsane-hpaio-2.8.2-3.fc10.x86_64 requires /bin/sh libscigraphica-2.1.1-8.fc9.i386 requires /sbin/ldconfig libscigraphica-2.1.1-8.fc9.x86_64 requires /sbin/ldconfig libselinux-2.0.64-2.fc10.i386 requires /bin/sh libselinux-2.0.64-2.fc10.i386 requires /sbin/ldconfig libselinux-2.0.64-2.fc10.x86_64 requires /bin/sh libselinux-2.0.64-2.fc10.x86_64 requires /sbin/ldconfig libsemanage-2.0.25-1.fc10.i386 requires /sbin/ldconfig libsemanage-2.0.25-1.fc10.x86_64 requires /sbin/ldconfig libsepol-2.0.26-1.fc9.i386 requires /bin/sh libsepol-2.0.26-1.fc9.i386 requires /sbin/ldconfig libsepol-2.0.26-1.fc9.x86_64 requires /bin/sh libsepol-2.0.26-1.fc9.x86_64 requires /sbin/ldconfig libsexy-0.1.11-8.fc10.i386 requires /sbin/ldconfig libsexy-0.1.11-8.fc10.x86_64 requires /sbin/ldconfig libsexymm-0.1.9-5.fc9.i386 requires /sbin/ldconfig libsexymm-0.1.9-5.fc9.x86_64 requires /sbin/ldconfig libshout-2.2.2-3.fc9.i386 requires /sbin/ldconfig libshout-2.2.2-3.fc9.x86_64 requires /sbin/ldconfig libsidplay-1.36.57-17.i386 requires /sbin/ldconfig libsidplay-1.36.57-17.x86_64 requires /sbin/ldconfig libsieve-2.2.6-3.fc9.i386 requires /sbin/ldconfig libsieve-2.2.6-3.fc9.x86_64 requires /sbin/ldconfig libsigc++-1.2.7-6.fc9.i386 requires /sbin/ldconfig libsigc++-1.2.7-6.fc9.x86_64 requires /sbin/ldconfig libsigc++20-2.2.2-1.fc9.i386 requires /bin/sh libsigc++20-2.2.2-1.fc9.i386 requires /sbin/ldconfig libsigc++20-2.2.2-1.fc9.x86_64 requires /bin/sh libsigc++20-2.2.2-1.fc9.x86_64 requires /sbin/ldconfig libsigsegv-2.4-6.fc9.i386 requires /sbin/ldconfig libsigsegv-2.4-6.fc9.x86_64 requires /sbin/ldconfig libsilc-1.1.7-1.fc9.i386 requires /sbin/ldconfig libsilc-1.1.7-1.fc9.x86_64 requires /sbin/ldconfig libsmbclient-3.2.0-1.pre3.10.fc10.i386 requires /bin/sh libsmbclient-3.2.0-1.pre3.10.fc10.x86_64 requires /bin/sh libsmbios-2.0.1-2.fc10.1.i386 requires /sbin/ldconfig libsmbios-2.0.1-2.fc10.1.x86_64 requires /sbin/ldconfig libsmi-0.4.8-1.fc10.i386 requires /sbin/ldconfig libsmi-0.4.8-1.fc10.i386 requires /bin/sh libsmi-0.4.8-1.fc10.x86_64 requires /sbin/ldconfig libsmi-0.4.8-1.fc10.x86_64 requires /bin/sh libsndfile-1.0.17-3.fc9.i386 requires /sbin/ldconfig libsndfile-1.0.17-3.fc9.x86_64 requires /sbin/ldconfig libsoup-2.23.1-1.fc10.i386 requires /sbin/ldconfig libsoup-2.23.1-1.fc10.x86_64 requires /sbin/ldconfig libsoup22-2.2.105-2.fc9.i386 requires /sbin/ldconfig libsoup22-2.2.105-2.fc9.x86_64 requires /sbin/ldconfig libspectre-0.2.0-2.fc9.i386 requires /sbin/ldconfig libspectre-0.2.0-2.fc9.x86_64 requires /sbin/ldconfig libspectrum-0.4.0-2.fc9.i386 requires /sbin/ldconfig libspectrum-0.4.0-2.fc9.x86_64 requires /sbin/ldconfig libssh2-0.18-7.fc9.i386 requires /sbin/ldconfig libssh2-0.18-7.fc9.x86_64 requires /sbin/ldconfig libstatgrab-0.16-1.fc9.i386 requires /sbin/ldconfig libstatgrab-0.16-1.fc9.x86_64 requires /sbin/ldconfig libstdc++-4.3.0-8.i386 requires /sbin/ldconfig libstdc++-4.3.0-8.x86_64 requires /sbin/ldconfig libstdc++-devel-4.3.0-8.i386 requires /usr/lib/libstdc++.so.6 libstdc++-devel-4.3.0-8.x86_64 requires /usr/lib64/libstdc++.so.6 libstroke-0.5.1-17.fc9.i386 requires /sbin/ldconfig libstroke-0.5.1-17.fc9.x86_64 requires /sbin/ldconfig libsvm-2.86-13.fc10.i386 requires /sbin/ldconfig libsvm-2.86-13.fc10.x86_64 requires /sbin/ldconfig libsvm-python-2.86-13.fc10.x86_64 requires /usr/bin/env libsvm-svm-toy-gtk-2.86-13.fc10.x86_64 requires /bin/sh 1:libswt3-gtk2-3.3.2-11.fc9.x86_64 requires /usr/bin/rebuild-gcj-db libsx-2.05-15.fc9.i386 requires /sbin/ldconfig libsx-2.05-15.fc9.x86_64 requires /sbin/ldconfig libsynce-0.11-3.fc9.i386 requires /sbin/ldconfig libsynce-0.11-3.fc9.x86_64 requires /sbin/ldconfig libsyncml-0.4.5-2.fc9.i386 requires /sbin/ldconfig libsyncml-0.4.5-2.fc9.x86_64 requires /sbin/ldconfig libsysfs-2.1.0-3.fc9.i386 requires /sbin/ldconfig libsysfs-2.1.0-3.fc9.x86_64 requires /sbin/ldconfig libtalloc-1.2.0-10.fc10.i386 requires /bin/sh libtalloc-1.2.0-10.fc10.x86_64 requires /bin/sh libtar-1.2.11-11.fc10.i386 requires /sbin/ldconfig libtar-1.2.11-11.fc10.x86_64 requires /sbin/ldconfig libtasn1-1.3-1.fc9.i386 requires /sbin/ldconfig libtasn1-1.3-1.fc9.x86_64 requires /sbin/ldconfig libtasn1-devel-1.3-1.fc9.i386 requires /bin/sh libtasn1-devel-1.3-1.fc9.i386 requires /bin/bash libtasn1-devel-1.3-1.fc9.i386 requires /sbin/install-info libtasn1-devel-1.3-1.fc9.x86_64 requires /bin/sh libtasn1-devel-1.3-1.fc9.x86_64 requires /bin/bash libtasn1-devel-1.3-1.fc9.x86_64 requires /sbin/install-info libtcd-2.2.3-1.fc9.2.i386 requires /sbin/ldconfig libtcd-2.2.3-1.fc9.2.x86_64 requires /sbin/ldconfig libtdb-1.1.1-10.fc10.i386 requires /bin/sh libtdb-1.1.1-10.fc10.x86_64 requires /bin/sh libtelepathy-0.3.3-1.fc9.i386 requires /sbin/ldconfig libtelepathy-0.3.3-1.fc9.x86_64 requires /sbin/ldconfig libtextcat-2.2-5.fc9.i386 requires /sbin/ldconfig libtextcat-2.2-5.fc9.x86_64 requires /sbin/ldconfig libthai-0.1.9-4.fc9.i386 requires /sbin/ldconfig libthai-0.1.9-4.fc9.x86_64 requires /sbin/ldconfig libtheora-1.0beta3-2.fc10.i386 requires /sbin/ldconfig libtheora-1.0beta3-2.fc10.x86_64 requires /sbin/ldconfig libtidy-0.99.0-17.20070615.fc9.i386 requires /sbin/ldconfig libtidy-0.99.0-17.20070615.fc9.x86_64 requires /sbin/ldconfig libtiff-3.8.2-10.fc9.i386 requires /sbin/ldconfig libtiff-3.8.2-10.fc9.x86_64 requires /sbin/ldconfig libtimidity-0.1.0-6.fc9.i386 requires /sbin/ldconfig libtimidity-0.1.0-6.fc9.x86_64 requires /sbin/ldconfig libtirpc-0.1.7-18.fc9.i386 requires /sbin/ldconfig libtirpc-0.1.7-18.fc9.x86_64 requires /sbin/ldconfig libtirpc-devel-0.1.7-18.fc9.i386 requires /bin/sh libtirpc-devel-0.1.7-18.fc9.x86_64 requires /bin/sh libtlen-0-0.7.20060309.fc9.i386 requires /sbin/ldconfig libtlen-0-0.7.20060309.fc9.x86_64 requires /sbin/ldconfig libtomcrypt-1.17-9.fc9.i386 requires /sbin/ldconfig libtomcrypt-1.17-9.fc9.x86_64 requires /sbin/ldconfig libtommath-0.41-8.fc9.i386 requires /sbin/ldconfig libtommath-0.41-8.fc9.x86_64 requires /sbin/ldconfig libtomoe-gtk-0.6.0-3.fc9.i386 requires /sbin/ldconfig libtomoe-gtk-0.6.0-3.fc9.x86_64 requires /sbin/ldconfig libtomoe-gtk-devel-0.6.0-3.fc9.i386 requires /sbin/ldconfig libtomoe-gtk-devel-0.6.0-3.fc9.x86_64 requires /sbin/ldconfig libtool-1.5.24-6.fc9.x86_64 requires /bin/sh libtool-1.5.24-6.fc9.x86_64 requires /sbin/install-info libtool-1.5.24-6.fc9.x86_64 requires /bin/sh libtool-ltdl-1.5.24-6.fc9.i386 requires /sbin/ldconfig libtool-ltdl-1.5.24-6.fc9.x86_64 requires /sbin/ldconfig libtorque-2.1.10-5.fc9.i386 requires /sbin/ldconfig libtorque-2.1.10-5.fc9.x86_64 requires /sbin/ldconfig libtorque-devel-2.1.10-5.fc9.i386 requires /bin/sh libtorque-devel-2.1.10-5.fc9.x86_64 requires /bin/sh libtorrent-0.11.8-4.fc9.i386 requires /sbin/ldconfig libtorrent-0.11.8-4.fc9.x86_64 requires /sbin/ldconfig libtranslate-0.99-14.fc9.i386 requires /sbin/ldconfig libtranslate-0.99-14.fc9.x86_64 requires /sbin/ldconfig libtunepimp-0.5.3-11.fc9.i386 requires /sbin/ldconfig libtunepimp-0.5.3-11.fc9.x86_64 requires /sbin/ldconfig libtwin-0.0.2-8.fc10.i386 requires /sbin/ldconfig libtwin-0.0.2-8.fc10.x86_64 requires /sbin/ldconfig libuninameslist-0.0-8.20060907.i386 requires /sbin/ldconfig libuninameslist-0.0-8.20060907.x86_64 requires /sbin/ldconfig libunwind-0.99-0.5.frysk20070405cvs.fc9.i386 requires /sbin/ldconfig libunwind-0.99-0.5.frysk20070405cvs.fc9.x86_64 requires /sbin/ldconfig libupnp-1.6.6-1.fc10.i386 requires /sbin/ldconfig libupnp-1.6.6-1.fc10.x86_64 requires /sbin/ldconfig libusb-0.1.12-15.fc9.i386 requires /sbin/ldconfig libusb-0.1.12-15.fc9.x86_64 requires /sbin/ldconfig libusb-devel-0.1.12-15.fc9.i386 requires /bin/sh libusb-devel-0.1.12-15.fc9.x86_64 requires /bin/sh libuser-0.56.9-1.i386 requires /sbin/ldconfig libuser-0.56.9-1.x86_64 requires /sbin/ldconfig libutempter-1.1.5-2.fc9.i386 requires /bin/sh libutempter-1.1.5-2.fc9.i386 requires /sbin/ldconfig libutempter-1.1.5-2.fc9.x86_64 requires /bin/sh libutempter-1.1.5-2.fc9.x86_64 requires /sbin/ldconfig libvirt-0.4.2-5.fc10.i386 requires /bin/sh libvirt-0.4.2-5.fc10.i386 requires /usr/sbin/lokkit libvirt-0.4.2-5.fc10.i386 requires /bin/sh libvirt-0.4.2-5.fc10.i386 requires /usr/bin/qemu-img libvirt-0.4.2-5.fc10.x86_64 requires /bin/sh libvirt-0.4.2-5.fc10.x86_64 requires /usr/sbin/lokkit libvirt-0.4.2-5.fc10.x86_64 requires /bin/sh libvirt-0.4.2-5.fc10.x86_64 requires /usr/bin/qemu-img libvirt-cim-0.3-4.fc9.i386 requires /bin/sh libvirt-cim-0.3-4.fc9.i386 requires /sbin/ldconfig libvirt-cim-0.3-4.fc9.i386 requires /bin/bash libvirt-cim-0.3-4.fc9.i386 requires /bin/sh libvirt-cim-0.3-4.fc9.x86_64 requires /bin/sh libvirt-cim-0.3-4.fc9.x86_64 requires /sbin/ldconfig libvirt-cim-0.3-4.fc9.x86_64 requires /bin/bash libvirt-cim-0.3-4.fc9.x86_64 requires /bin/sh libvirt-devel-0.4.2-5.fc10.i386 requires /usr/bin/python libvirt-devel-0.4.2-5.fc10.x86_64 requires /usr/bin/python libvirt-python-0.4.2-5.fc10.x86_64 requires /usr/bin/python libvisual-0.4.0-6.fc9.i386 requires /sbin/ldconfig libvisual-0.4.0-6.fc9.x86_64 requires /sbin/ldconfig libvncserver-0.9.1-3.fc10.i386 requires /sbin/ldconfig libvncserver-0.9.1-3.fc10.x86_64 requires /sbin/ldconfig libvncserver-devel-0.9.1-3.fc10.i386 requires /bin/sh libvncserver-devel-0.9.1-3.fc10.x86_64 requires /bin/sh libvoikko-1.7-0.1.rc2.fc10.i386 requires /sbin/ldconfig libvoikko-1.7-0.1.rc2.fc10.x86_64 requires /sbin/ldconfig libvolume_id-121-1.20080516git.fc10.i386 requires /sbin/ldconfig libvolume_id-121-1.20080516git.fc10.x86_64 requires /sbin/ldconfig 1:libvorbis-1.2.0-4.fc10.i386 requires /sbin/ldconfig 1:libvorbis-1.2.0-4.fc10.x86_64 requires /sbin/ldconfig libvpd-2.0.1-1.fc9.i386 requires /sbin/ldconfig libvpd-2.0.1-1.fc9.x86_64 requires /sbin/ldconfig libvte-java-0.12.1-11.fc9.i386 requires /sbin/ldconfig libvte-java-0.12.1-11.fc9.x86_64 requires /sbin/ldconfig libwcs-3.7.0-2.fc9.i386 requires /sbin/ldconfig libwcs-3.7.0-2.fc9.x86_64 requires /sbin/ldconfig libwiimote-0.4-6.fc9.i386 requires /sbin/ldconfig libwiimote-0.4-6.fc9.x86_64 requires /sbin/ldconfig libwmf-0.2.8.4-18.fc9.i386 requires /usr/bin/update-gdk-pixbuf-loaders libwmf-0.2.8.4-18.fc9.i386 requires /bin/sh libwmf-0.2.8.4-18.fc9.i386 requires /bin/sh libwmf-0.2.8.4-18.fc9.x86_64 requires /bin/sh libwmf-0.2.8.4-18.fc9.x86_64 requires /usr/bin/update-gdk-pixbuf-loaders libwmf-0.2.8.4-18.fc9.x86_64 requires /bin/sh libwmf-devel-0.2.8.4-18.fc9.i386 requires /bin/sh libwmf-devel-0.2.8.4-18.fc9.x86_64 requires /bin/sh libwmf-lite-0.2.8.4-18.fc9.i386 requires /sbin/ldconfig libwmf-lite-0.2.8.4-18.fc9.x86_64 requires /sbin/ldconfig libwnck-2.22.1-1.fc9.i386 requires /sbin/ldconfig libwnck-2.22.1-1.fc9.x86_64 requires /sbin/ldconfig libwpd-0.8.14-1.fc9.i386 requires /sbin/ldconfig libwpd-0.8.14-1.fc9.x86_64 requires /sbin/ldconfig libwvstreams-4.4.1-4.fc9.i386 requires /sbin/ldconfig libwvstreams-4.4.1-4.fc9.x86_64 requires /sbin/ldconfig libxcb-1.1-4.fc9.i386 requires /sbin/ldconfig libxcb-1.1-4.fc9.x86_64 requires /sbin/ldconfig libxfce4mcs-4.4.2-2.fc9.i386 requires /sbin/ldconfig libxfce4mcs-4.4.2-2.fc9.x86_64 requires /sbin/ldconfig libxfce4util-4.4.2-2.fc9.i386 requires /sbin/ldconfig libxfce4util-4.4.2-2.fc9.x86_64 requires /sbin/ldconfig libxfcegui4-4.4.2-2.fc9.i386 requires /bin/sh libxfcegui4-4.4.2-2.fc9.x86_64 requires /bin/sh libxkbfile-1.0.4-5.fc9.i386 requires /sbin/ldconfig libxkbfile-1.0.4-5.fc9.x86_64 requires /sbin/ldconfig libxklavier-3.6-1.fc10.i386 requires /sbin/ldconfig libxklavier-3.6-1.fc10.x86_64 requires /sbin/ldconfig 1:libxml-1.8.17-19.fc9.i386 requires /sbin/ldconfig 1:libxml-1.8.17-19.fc9.x86_64 requires /sbin/ldconfig libxml++-2.22.0-1.fc9.i386 requires /sbin/ldconfig libxml++-2.22.0-1.fc9.x86_64 requires /sbin/ldconfig libxml++-devel-2.22.0-1.fc9.i386 requires /bin/sh libxml++-devel-2.22.0-1.fc9.x86_64 requires /bin/sh 1:libxml-devel-1.8.17-19.fc9.i386 requires /bin/sh 1:libxml-devel-1.8.17-19.fc9.x86_64 requires /bin/sh libxml2-2.6.32-2.fc10.i386 requires /bin/sh libxml2-2.6.32-2.fc10.x86_64 requires /bin/sh libxml2-devel-2.6.32-2.fc10.i386 requires /bin/sh libxml2-devel-2.6.32-2.fc10.i386 requires /usr/bin/python libxml2-devel-2.6.32-2.fc10.x86_64 requires /bin/sh libxml2-devel-2.6.32-2.fc10.x86_64 requires /usr/bin/python libxml2-python-2.6.32-2.fc10.x86_64 requires /usr/bin/python libxslt-1.1.24-1.fc10.i386 requires /bin/sh libxslt-1.1.24-1.fc10.x86_64 requires /bin/sh libxslt-devel-1.1.24-1.fc10.i386 requires /bin/sh libxslt-devel-1.1.24-1.fc10.x86_64 requires /bin/sh libxslt-python-1.1.24-1.fc10.x86_64 requires /usr/bin/python libyaz-3.0.26-1.fc10.i386 requires /sbin/ldconfig libyaz-3.0.26-1.fc10.x86_64 requires /sbin/ldconfig libyaz-devel-3.0.26-1.fc10.i386 requires /usr/bin/tclsh libyaz-devel-3.0.26-1.fc10.i386 requires /bin/sh libyaz-devel-3.0.26-1.fc10.x86_64 requires /usr/bin/tclsh libyaz-devel-3.0.26-1.fc10.x86_64 requires /bin/sh libytnef-1.5-3.fc9.i386 requires /sbin/ldconfig libytnef-1.5-3.fc9.x86_64 requires /sbin/ldconfig libzip-0.8-5.fc9.i386 requires /sbin/ldconfig libzip-0.8-5.fc9.x86_64 requires /sbin/ldconfig libzzub-0.2.3-12.fc9.i386 requires /sbin/ldconfig libzzub-0.2.3-12.fc9.x86_64 requires /sbin/ldconfig licq-1.3.5-2.fc10.x86_64 requires /usr/bin/perl licq-1.3.5-2.fc10.x86_64 requires /bin/sh licq-auto-reply-1.3.5-2.fc10.x86_64 requires /bin/bash liferea-1.4.13-3.fc9.x86_64 requires /bin/sh liferea-1.4.13-3.fc9.x86_64 requires /bin/sh lighttpd-1.4.19-4.fc10.x86_64 requires /bin/sh lighttpd-1.4.19-4.fc10.x86_64 requires /usr/sbin/useradd lighttpd-1.4.19-4.fc10.x86_64 requires /sbin/service lighttpd-1.4.19-4.fc10.x86_64 requires /bin/sh lighttpd-1.4.19-4.fc10.x86_64 requires /sbin/chkconfig lilypond-2.10.33-1.fc8.x86_64 requires /bin/sh lilypond-2.10.33-1.fc8.x86_64 requires /sbin/install-info lilypond-2.10.33-1.fc8.x86_64 requires /usr/bin/python lilypond-2.10.33-1.fc8.x86_64 requires /usr/bin/guile lineakd-0.9-5.fc6.i386 requires /bin/sh lineakd-0.9-5.fc6.i386 requires /sbin/ldconfig lineakd-0.9-5.fc6.x86_64 requires /bin/sh lineakd-0.9-5.fc6.x86_64 requires /sbin/ldconfig link-grammar-4.2.5-2.fc9.i386 requires /sbin/ldconfig link-grammar-4.2.5-2.fc9.x86_64 requires /sbin/ldconfig linkage-0.1.4-6.fc9.i386 requires /bin/sh linkage-0.1.4-6.fc9.x86_64 requires /bin/sh linkchecker-4.7-11.fc9.x86_64 requires /usr/bin/python linphone-2.1.1-1.fc9.i386 requires /sbin/ldconfig linphone-2.1.1-1.fc9.x86_64 requires /sbin/ldconfig linux-atm-2.5.0-5.x86_64 requires /usr/bin/perl linux-atm-2.5.0-5.x86_64 requires /bin/sh linux-atm-libs-2.5.0-5.i386 requires /sbin/ldconfig linux-atm-libs-2.5.0-5.x86_64 requires /sbin/ldconfig linux-igd-1.0-5.fc9.x86_64 requires /bin/sh linux-igd-1.0-5.fc9.x86_64 requires /bin/bash linux-igd-1.0-5.fc9.x86_64 requires /sbin/chkconfig linux-igd-1.0-5.fc9.x86_64 requires /sbin/service linux-libertine-fonts-2.7.9-1.fc9.noarch requires /bin/sh linuxdoc-tools-0.9.21-16.fc9.x86_64 requires /bin/sh linuxdoc-tools-0.9.21-16.fc9.x86_64 requires /usr/bin/perl linuxwacom-0.7.9.8-7.fc10.i386 requires /sbin/ldconfig linuxwacom-0.7.9.8-7.fc10.x86_64 requires /sbin/ldconfig liquidwar-5.6.4-4.fc9.x86_64 requires /bin/sh liquidwar-5.6.4-4.fc9.x86_64 requires /sbin/install-info liquidwar-server-5.6.4-4.fc9.x86_64 requires /bin/sh liquidwar-server-5.6.4-4.fc9.x86_64 requires /sbin/chkconfig liquidwar-server-5.6.4-4.fc9.x86_64 requires /usr/sbin/useradd liquidwar-server-5.6.4-4.fc9.x86_64 requires /bin/sh liquidwar-server-5.6.4-4.fc9.x86_64 requires /sbin/service lirc-0.8.3-1.fc10.x86_64 requires /bin/sh lirc-0.8.3-1.fc10.x86_64 requires /sbin/chkconfig lirc-0.8.3-1.fc10.x86_64 requires /sbin/ldconfig lirc-0.8.3-1.fc10.x86_64 requires /bin/sh lirc-libs-0.8.3-1.fc10.i386 requires /sbin/ldconfig lirc-libs-0.8.3-1.fc10.x86_64 requires /sbin/ldconfig listen-0.5-18.fc9.x86_64 requires /usr/bin/puid listen-0.5-18.fc9.x86_64 requires /usr/bin/env listen-0.5-18.fc9.x86_64 requires /sbin/ldconfig listen-0.5-18.fc9.x86_64 requires /bin/sh livecd-tools-017-1.fc9.x86_64 requires /bin/bash livecd-tools-017-1.fc9.x86_64 requires /usr/bin/python lklug-fonts-0.2.2-5.fc8.noarch requires /bin/sh lksctp-tools-1.0.7-3.fc9.i386 requires /sbin/ldconfig lksctp-tools-1.0.7-3.fc9.i386 requires /bin/sh lksctp-tools-1.0.7-3.fc9.x86_64 requires /sbin/ldconfig lksctp-tools-1.0.7-3.fc9.x86_64 requires /bin/sh llvm-2.2-3.fc9.x86_64 requires /sbin/ldconfig llvm-devel-2.2-3.fc9.i386 requires /usr/bin/perl llvm-devel-2.2-3.fc9.x86_64 requires /usr/bin/perl lm_sensors-3.0.1-5.fc9.i386 requires /bin/sh lm_sensors-3.0.1-5.fc9.i386 requires /sbin/ldconfig lm_sensors-3.0.1-5.fc9.i386 requires /bin/bash lm_sensors-3.0.1-5.fc9.i386 requires /usr/sbin/dmidecode lm_sensors-3.0.1-5.fc9.i386 requires /bin/sh lm_sensors-3.0.1-5.fc9.i386 requires /usr/bin/perl lm_sensors-3.0.1-5.fc9.x86_64 requires /bin/sh lm_sensors-3.0.1-5.fc9.x86_64 requires /sbin/ldconfig lm_sensors-3.0.1-5.fc9.x86_64 requires /bin/bash lm_sensors-3.0.1-5.fc9.x86_64 requires /usr/sbin/dmidecode lm_sensors-3.0.1-5.fc9.x86_64 requires /bin/sh lm_sensors-3.0.1-5.fc9.x86_64 requires /usr/bin/perl lm_sensors-sensord-3.0.1-5.fc9.x86_64 requires /bin/sh lm_sensors-sensord-3.0.1-5.fc9.x86_64 requires /bin/sh lmarbles-1.0.7-9.x86_64 requires /bin/sh lock-keys-applet-1.0-14.fc9.x86_64 requires /bin/sh lockdev-1.0.1-12.fc9.1.i386 requires /bin/sh lockdev-1.0.1-12.fc9.1.i386 requires /sbin/ldconfig lockdev-1.0.1-12.fc9.1.x86_64 requires /bin/sh lockdev-1.0.1-12.fc9.1.x86_64 requires /sbin/ldconfig log4j-1.2.14-4jpp.1.fc9.x86_64 requires /bin/sh log4j-1.2.14-4jpp.1.fc9.x86_64 requires /bin/sh log4j-javadoc-1.2.14-4jpp.1.fc9.x86_64 requires /bin/sh log4j-javadoc-1.2.14-4jpp.1.fc9.x86_64 requires /bin/rm log4j-javadoc-1.2.14-4jpp.1.fc9.x86_64 requires /bin/ln logrotate-3.7.6-4.fc10.x86_64 requires /bin/sh logwatch-7.3.6-22.fc10.noarch requires /usr/bin/perl lohit-fonts-bengali-2.2.1-2.fc9.noarch requires /bin/sh lohit-fonts-gujarati-2.2.1-2.fc9.noarch requires /bin/sh lohit-fonts-hindi-2.2.1-2.fc9.noarch requires /bin/sh lohit-fonts-kannada-2.2.1-2.fc9.noarch requires /bin/sh lohit-fonts-malayalam-2.2.1-2.fc9.noarch requires /bin/sh lohit-fonts-oriya-2.2.1-2.fc9.noarch requires /bin/sh lohit-fonts-punjabi-2.2.1-2.fc9.noarch requires /bin/sh lohit-fonts-tamil-2.2.1-2.fc9.noarch requires /bin/sh lohit-fonts-telugu-2.2.1-2.fc9.noarch requires /bin/sh loki-lib-0.1.6-6.fc9.i386 requires /sbin/ldconfig loki-lib-0.1.6-6.fc9.x86_64 requires /sbin/ldconfig londonlaw-0.2.1-3.fc9.noarch requires /bin/sh londonlaw-0.2.1-3.fc9.noarch requires /usr/bin/python loudmouth-1.3.4-1.fc9.i386 requires /sbin/ldconfig loudmouth-1.3.4-1.fc9.x86_64 requires /sbin/ldconfig lpsolve-5.5.0.12-1.fc9.x86_64 requires /sbin/ldconfig lrmi-0.10-4.fc9.i386 requires /sbin/ldconfig lsvpd-1.6.3-1.fc9.x86_64 requires /usr/sbin/vpdupdate ltsp-client-5.1.7-2.fc9.x86_64 requires /bin/bash ltsp-client-5.1.7-2.fc9.x86_64 requires /bin/sh ltsp-server-5.1.7-2.fc9.x86_64 requires /bin/sh ltsp-server-5.1.7-2.fc9.x86_64 requires /usr/bin/perl ltsp-server-5.1.7-2.fc9.x86_64 requires /bin/bash ltsp-server-5.1.7-2.fc9.x86_64 requires /bin/sh ltsp-server-5.1.7-2.fc9.x86_64 requires /usr/bin/python ltsp-utils-0.25-4.fc6.noarch requires /usr/bin/perl ltsp-vmclient-5.1.7-2.fc9.x86_64 requires /bin/sh ltspfs-0.5.2-1.fc9.x86_64 requires /usr/bin/python ltspfsd-0.5.2-1.fc9.x86_64 requires /bin/sh luadoc-3.0.1-1.fc8.noarch requires /usr/bin/env lucene-2.3.1-2jpp.0.fc10.x86_64 requires /bin/sh lucene-javadoc-2.3.1-2jpp.0.fc10.x86_64 requires /bin/sh luma-2.4-3.fc9.noarch requires /usr/bin/env lvm2-2.02.33-11.fc9.x86_64 requires /bin/bash lvm2-2.02.33-11.fc9.x86_64 requires /bin/sh lvm2-cluster-2.02.33-11.fc9.x86_64 requires /bin/sh lvm2-cluster-2.02.33-11.fc9.x86_64 requires /bin/bash lvm2-cluster-2.02.33-11.fc9.x86_64 requires /bin/sh lwp-2.4-1.fc10.i386 requires /sbin/ldconfig lwp-2.4-1.fc10.x86_64 requires /sbin/ldconfig lxappearance-0.2-1.fc10.x86_64 requires /bin/sh lybniz-1.3.2-1.fc9.noarch requires /bin/sh lybniz-1.3.2-1.fc9.noarch requires /usr/bin/python lynx-2.8.6-13.fc9.x86_64 requires /bin/sh lyx-1.5.5-1.fc10.x86_64 requires /bin/sh lyx-1.5.5-1.fc10.x86_64 requires /usr/bin/env lyx-1.5.5-1.fc10.x86_64 requires /usr/bin/python lyx-1.5.5-1.fc10.x86_64 requires /usr/bin/texhash lyx-1.5.5-1.fc10.x86_64 requires /bin/sh lzma-4.32.5-1.fc9.x86_64 requires /bin/sh lzma-libs-4.32.5-1.fc9.i386 requires /sbin/ldconfig lzma-libs-4.32.5-1.fc9.x86_64 requires /sbin/ldconfig lzo-2.03-1.fc10.i386 requires /sbin/ldconfig lzo-2.03-1.fc10.x86_64 requires /sbin/ldconfig lzo-minilzo-2.03-1.fc10.i386 requires /sbin/ldconfig lzo-minilzo-2.03-1.fc10.x86_64 requires /sbin/ldconfig m17n-contrib-1.1.6-3.fc9.noarch requires /usr/bin/gawk m17n-db-1.5.1-3.fc9.noarch requires /bin/sh m17n-lib-1.5.1-1.fc9.i386 requires /sbin/ldconfig m17n-lib-1.5.1-1.fc9.x86_64 requires /sbin/ldconfig m2crypto-0.18.2-4.x86_64 requires /usr/bin/env m4-1.4.11-1.fc10.x86_64 requires /bin/sh m4-1.4.11-1.fc10.x86_64 requires /sbin/install-info mISDN-1.1.5-2.fc9.i386 requires /bin/sh mISDN-1.1.5-2.fc9.i386 requires /sbin/ldconfig mISDN-1.1.5-2.fc9.x86_64 requires /bin/sh mISDN-1.1.5-2.fc9.x86_64 requires /sbin/ldconfig macchanger-1.5.0-4.fc9.x86_64 requires /bin/sh macchanger-1.5.0-4.fc9.x86_64 requires /sbin/install-info mach-0.9.2-4.fc9.i386 requires /bin/sh mach-0.9.2-4.fc9.i386 requires /usr/bin/python mach-0.9.2-4.fc9.x86_64 requires /bin/sh mach-0.9.2-4.fc9.x86_64 requires /usr/bin/python machineball-1.0-5.fc9.x86_64 requires /bin/sh madan-fonts-1.0-6.fc8.noarch requires /bin/sh magic-7.5.116-1.fc9.x86_64 requires /bin/sh magic-7.5.116-1.fc9.x86_64 requires /usr/bin/tclsh magic-7.5.116-1.fc9.x86_64 requires /bin/awk magic-7.5.116-1.fc9.x86_64 requires /usr/bin/wish magic-7.5.116-1.fc9.x86_64 requires /bin/sh magicmaze-1.0.2-1.fc9.x86_64 requires /bin/sh magicor-1.1-0.1.rc1.fc9.noarch requires /bin/sh magicor-1.1-0.1.rc1.fc9.noarch requires /usr/bin/python mail-notification-5.3-1.fc9.x86_64 requires /bin/sh maildrop-2.0.4-6.fc9.x86_64 requires /bin/sh mailgraph-1.14-2.fc9.noarch requires /bin/sh mailgraph-1.14-2.fc9.noarch requires /bin/bash mailgraph-1.14-2.fc9.noarch requires /usr/bin/perl mailgraph-selinux-1.14-2.fc9.noarch requires /usr/sbin/semodule mailgraph-selinux-1.14-2.fc9.noarch requires /sbin/fixfiles mailgraph-selinux-1.14-2.fc9.noarch requires /bin/sh mailgraph-selinux-1.14-2.fc9.noarch requires /sbin/restorecon 3:mailman-2.1.10-1.fc10.x86_64 requires /bin/sh 3:mailman-2.1.10-1.fc10.x86_64 requires /usr/bin/env 3:mailman-2.1.10-1.fc10.x86_64 requires /usr/bin/python 3:mailman-2.1.10-1.fc10.x86_64 requires /sbin/service 3:mailman-2.1.10-1.fc10.x86_64 requires /bin/sh 3:mailman-2.1.10-1.fc10.x86_64 requires /sbin/chkconfig 1:make-3.81-12.fc9.x86_64 requires /bin/sh 1:make-3.81-12.fc9.x86_64 requires /sbin/install-info malaga-7.12-1.fc9.x86_64 requires /bin/sh malaga-7.12-1.fc9.x86_64 requires /sbin/install-info man-1.6f-6.fc10.x86_64 requires /bin/sh man-1.6f-6.fc10.x86_64 requires /bin/bash man-1.6f-6.fc10.x86_64 requires /bin/sh manaworld-0.0.24-1.fc9.x86_64 requires /bin/sh manedit-0.8.1-3.fc9.x86_64 requires /bin/sh manedit-0.8.1-3.fc9.x86_64 requires /bin/sh maniadrive-1.2-8.fc9.x86_64 requires /bin/sh mantis-1.1.1-1.fc9.noarch requires /usr/bin/php mantis-config-httpd-1.1.1-1.fc9.noarch requires /bin/sh mantis-config-httpd-1.1.1-1.fc9.noarch requires /etc/httpd/conf.d mapserver-python-5.0.2-2.fc9.x86_64 requires /bin/sh maradns-1.3.07.08-1.fc9.x86_64 requires /bin/sh maradns-1.3.07.08-1.fc9.x86_64 requires /bin/bash maradns-1.3.07.08-1.fc9.x86_64 requires /sbin/chkconfig maradns-1.3.07.08-1.fc9.x86_64 requires /sbin/service mash-0.3.6-1.fc9.noarch requires /usr/bin/python2 mash-0.3.6-1.fc9.noarch requires /usr/bin/python mathml-fonts-1.0-21.fc6.noarch requires /bin/sh mathml-fonts-1.0-21.fc6.noarch requires /bin/bash mathml-fonts-1.0-21.fc6.noarch requires /bin/sh maven-doxia-1.0-0.2.a7.2jpp.6.fc9.x86_64 requires /bin/sh maven-jxr-1.0-2jpp.5.fc9.x86_64 requires /bin/sh maven-scm-1.0-0.2.b3.1jpp.3.fc9.x86_64 requires /bin/sh maven-scm-javadoc-1.0-0.2.b3.1jpp.3.fc9.x86_64 requires /bin/rm maven-scm-javadoc-1.0-0.2.b3.1jpp.3.fc9.x86_64 requires /bin/ls maven-scm-test-1.0-0.2.b3.1jpp.3.fc9.x86_64 requires /bin/sh maven-shared-1.0-4jpp.4.fc9.x86_64 requires /bin/sh maven-shared-file-management-1.0-4jpp.4.fc9.x86_64 requires /bin/sh maven-shared-plugin-testing-harness-1.0-4jpp.4.fc9.x86_64 requires /bin/sh maven-surefire-1.5.3-2jpp.5.fc9.x86_64 requires /bin/sh maven-surefire-booter-1.5.3-2jpp.5.fc9.x86_64 requires /bin/sh maven-surefire-booter-javadoc-1.5.3-2jpp.5.fc9.x86_64 requires /bin/rm maven-surefire-booter-javadoc-1.5.3-2jpp.5.fc9.x86_64 requires /bin/ln maven-surefire-javadoc-1.5.3-2jpp.5.fc9.x86_64 requires /bin/rm maven-surefire-javadoc-1.5.3-2jpp.5.fc9.x86_64 requires /bin/ln maven2-2.0.4-10jpp.10.fc9.x86_64 requires /bin/sh maven2-2.0.4-10jpp.10.fc9.x86_64 requires /bin/rmdir maven2-2.0.4-10jpp.10.fc9.x86_64 requires /bin/sh maven2-plugin-ant-2.0.4-10jpp.10.fc9.x86_64 requires /bin/sh maven2-plugin-antlr-2.0.4-10jpp.10.fc9.x86_64 requires /bin/sh maven2-plugin-antrun-2.0.4-10jpp.10.fc9.x86_64 requires /bin/sh maven2-plugin-assembly-2.0.4-10jpp.10.fc9.x86_64 requires /bin/sh maven2-plugin-checkstyle-2.0.4-10jpp.10.fc9.x86_64 requires /bin/sh maven2-plugin-clean-2.0.4-10jpp.10.fc9.x86_64 requires /bin/sh maven2-plugin-compiler-2.0.4-10jpp.10.fc9.x86_64 requires /bin/sh maven2-plugin-dependency-2.0.4-10jpp.10.fc9.x86_64 requires /bin/sh maven2-plugin-deploy-2.0.4-10jpp.10.fc9.x86_64 requires /bin/sh maven2-plugin-ear-2.0.4-10jpp.10.fc9.x86_64 requires /bin/sh maven2-plugin-eclipse-2.0.4-10jpp.10.fc9.x86_64 requires /bin/sh maven2-plugin-ejb-2.0.4-10jpp.10.fc9.x86_64 requires /bin/sh maven2-plugin-help-2.0.4-10jpp.10.fc9.x86_64 requires /bin/sh maven2-plugin-idea-2.0.4-10jpp.10.fc9.x86_64 requires /bin/sh maven2-plugin-install-2.0.4-10jpp.10.fc9.x86_64 requires /bin/sh maven2-plugin-jar-2.0.4-10jpp.10.fc9.x86_64 requires /bin/sh maven2-plugin-javadoc-2.0.4-10jpp.10.fc9.x86_64 requires /bin/sh maven2-plugin-jxr-2.0.4-10jpp.10.fc9.x86_64 requires /bin/sh maven2-plugin-one-2.0.4-10jpp.10.fc9.x86_64 requires /bin/sh maven2-plugin-plugin-2.0.4-10jpp.10.fc9.x86_64 requires /bin/sh maven2-plugin-pmd-2.0.4-10jpp.10.fc9.x86_64 requires /bin/sh maven2-plugin-project-info-reports-2.0.4-10jpp.10.fc9.x86_64 requires /bin/sh maven2-plugin-rar-2.0.4-10jpp.10.fc9.x86_64 requires /bin/sh maven2-plugin-release-2.0.4-10jpp.10.fc9.x86_64 requires /bin/sh maven2-plugin-repository-2.0.4-10jpp.10.fc9.x86_64 requires /bin/sh maven2-plugin-resources-2.0.4-10jpp.10.fc9.x86_64 requires /bin/sh maven2-plugin-site-2.0.4-10jpp.10.fc9.x86_64 requires /bin/sh maven2-plugin-source-2.0.4-10jpp.10.fc9.x86_64 requires /bin/sh maven2-plugin-surefire-2.0.4-10jpp.10.fc9.x86_64 requires /bin/sh maven2-plugin-surefire-report-2.0.4-10jpp.10.fc9.x86_64 requires /bin/sh maven2-plugin-verifier-2.0.4-10jpp.10.fc9.x86_64 requires /bin/sh maxima-5.14.0-4.fc9.x86_64 requires /bin/sh maxima-5.14.0-4.fc9.x86_64 requires /bin/bash maxima-5.14.0-4.fc9.x86_64 requires /sbin/install-info maxima-5.14.0-4.fc9.x86_64 requires /bin/sh maxima-gui-5.14.0-4.fc9.x86_64 requires /bin/sh maxima-gui-5.14.0-4.fc9.x86_64 requires /bin/sh mboxgrep-0.7.9-5.fc9.x86_64 requires /bin/sh mboxgrep-0.7.9-5.fc9.x86_64 requires /sbin/install-info 1:mc-4.6.2-3.pre1.fc9.x86_64 requires /usr/bin/perl 1:mc-4.6.2-3.pre1.fc9.x86_64 requires /bin/sh 1:mcelog-0.7-1.23.fc9.x86_64 requires /bin/bash mcs-libs-0.6.0-4.fc9.i386 requires /sbin/ldconfig mcs-libs-0.6.0-4.fc9.x86_64 requires /sbin/ldconfig mcstrans-0.2.11-1.fc10.x86_64 requires /bin/sh mcstrans-0.2.11-1.fc10.x86_64 requires /bin/bash mcstrans-0.2.11-1.fc10.x86_64 requires /sbin/chkconfig mcstrans-0.2.11-1.fc10.x86_64 requires /sbin/service mdadm-2.6.4-4.fc9.x86_64 requires /bin/sh mdadm-2.6.4-4.fc9.x86_64 requires /bin/bash mdadm-2.6.4-4.fc9.x86_64 requires /sbin/chkconfig mdadm-2.6.4-4.fc9.x86_64 requires /sbin/service mdbtools-libs-0.6-0.4.cvs20051109.fc9.i386 requires /sbin/ldconfig mdbtools-libs-0.6-0.4.cvs20051109.fc9.x86_64 requires /sbin/ldconfig mdsplib-0.11-6.fc9.i386 requires /sbin/ldconfig mdsplib-0.11-6.fc9.x86_64 requires /sbin/ldconfig meanwhile-1.0.2-6.fc9.i386 requires /sbin/ldconfig meanwhile-1.0.2-6.fc9.x86_64 requires /sbin/ldconfig mecab-0.97-1.fc9.i386 requires /sbin/ldconfig mecab-0.97-1.fc9.x86_64 requires /sbin/ldconfig mecab-devel-0.97-1.fc9.i386 requires /bin/sh mecab-devel-0.97-1.fc9.x86_64 requires /bin/sh mecab-ipadic-2.7.0.20070801-1.fc8.x86_64 requires /bin/sh mecab-ipadic-EUCJP-2.7.0.20070801-1.fc8.x86_64 requires /bin/sh mecab-jumandic-5.1.20070304-1.fc7.1.x86_64 requires /bin/sh mecab-jumandic-EUCJP-5.1.20070304-1.fc7.1.x86_64 requires /bin/sh mediatomb-0.11.0-1.fc9.x86_64 requires /bin/sh mediatomb-0.11.0-1.fc9.x86_64 requires /sbin/service mediatomb-0.11.0-1.fc9.x86_64 requires /bin/sh mediatomb-0.11.0-1.fc9.x86_64 requires /sbin/chkconfig mediawiki-1.10.4-39.fc9.x86_64 requires /usr/bin/env mediawiki-1.10.4-39.fc9.x86_64 requires /bin/bash mediawiki-1.10.4-39.fc9.x86_64 requires /bin/sh mediawiki-1.10.4-39.fc9.x86_64 requires /usr/bin/perl meld-1.1.5-4.fc9.noarch requires /bin/sh meld-1.1.5-4.fc9.noarch requires /usr/bin/env memcached-1.2.4-4.fc9.x86_64 requires /bin/sh memcached-1.2.4-4.fc9.x86_64 requires /sbin/service memcached-1.2.4-4.fc9.x86_64 requires /usr/bin/perl memcached-1.2.4-4.fc9.x86_64 requires /bin/sh memcached-1.2.4-4.fc9.x86_64 requires /sbin/chkconfig memcached-selinux-1.2.4-4.fc9.x86_64 requires /bin/sh memtest86+-2.01-3.fc9.x86_64 requires /bin/bash memtest86+-2.01-3.fc9.x86_64 requires /bin/sh mencal-2.3-1.fc8.noarch requires /usr/bin/perl mercator-0.2.5-4.fc9.i386 requires /sbin/ldconfig mercator-0.2.5-4.fc9.x86_64 requires /sbin/ldconfig mercurial-1.0-4.fc9.x86_64 requires /usr/bin/env mercurial-1.0-4.fc9.x86_64 requires /bin/sh mercurial-1.0-4.fc9.x86_64 requires /usr/bin/python mercurial-hgk-1.0-4.fc9.x86_64 requires /usr/bin/env mesa-libGL-7.1-0.29.fc9.i386 requires /sbin/ldconfig mesa-libGL-7.1-0.29.fc9.x86_64 requires /sbin/ldconfig mesa-libGLU-7.1-0.29.fc9.i386 requires /sbin/ldconfig mesa-libGLU-7.1-0.29.fc9.x86_64 requires /sbin/ldconfig mesa-libGLw-6.5.1-5.fc9.i386 requires /sbin/ldconfig mesa-libGLw-6.5.1-5.fc9.x86_64 requires /sbin/ldconfig mesa-libOSMesa-7.1-0.29.fc9.i386 requires /sbin/ldconfig mesa-libOSMesa-7.1-0.29.fc9.x86_64 requires /sbin/ldconfig metacafe-dl-2007.10.09-1.fc9.noarch requires /usr/bin/env metacity-2.23.13-1.fc10.i386 requires /bin/sh metacity-2.23.13-1.fc10.i386 requires /sbin/ldconfig metacity-2.23.13-1.fc10.x86_64 requires /bin/sh metacity-2.23.13-1.fc10.x86_64 requires /sbin/ldconfig metakit-2.4.9.7-5.fc9.x86_64 requires /sbin/ldconfig metamonitor-0.4.5-5.fc9.x86_64 requires /bin/sh metapixel-1.0.2-3.fc9.x86_64 requires /usr/bin/perl methane-1.4.7-4.fc9.x86_64 requires /bin/sh mew-common-6.0.51-1.fc10.x86_64 requires /bin/sh mew-common-6.0.51-1.fc10.x86_64 requires /usr/bin/env mew-common-6.0.51-1.fc10.x86_64 requires /sbin/install-info mew-common-6.0.51-1.fc10.x86_64 requires /bin/sh mfiler2-mdnd-4.0.9b-1.fc9.x86_64 requires /usr/bin/env mftrace-1.2.14-4.fc9.x86_64 requires /usr/bin/python mgetty-1.1.36-1.fc10.x86_64 requires /bin/sh mgetty-1.1.36-1.fc10.x86_64 requires /sbin/install-info mgetty-sendfax-1.1.36-1.fc10.x86_64 requires /bin/sh mgetty-sendfax-1.1.36-1.fc10.x86_64 requires /usr/sbin/useradd mgetty-sendfax-1.1.36-1.fc10.x86_64 requires /usr/bin/perl mgetty-sendfax-1.1.36-1.fc10.x86_64 requires /bin/sh mgopen-fonts-0.20050515-6.fc9.noarch requires /bin/sh mhash-0.9.9-5.i386 requires /sbin/ldconfig mhash-0.9.9-5.x86_64 requires /sbin/ldconfig mhgui-0.2-6.fc9.i386 requires /sbin/ldconfig mhgui-0.2-6.fc9.x86_64 requires /sbin/ldconfig mhonarc-2.6.16-4.fc8.noarch requires /usr/bin/perl miau-0.6.5-2.fc9.x86_64 requires /bin/sh miau-0.6.5-2.fc9.x86_64 requires /sbin/install-info 1:microcode_ctl-1.17-1.45.fc9.x86_64 requires /bin/sh 1:microcode_ctl-1.17-1.45.fc9.x86_64 requires /bin/bash 1:microcode_ctl-1.17-1.45.fc9.x86_64 requires /sbin/chkconfig 1:microcode_ctl-1.17-1.45.fc9.x86_64 requires /bin/sh 1:microcode_ctl-1.17-1.45.fc9.x86_64 requires /sbin/service migemo-0.40-9.fc7.noarch requires /usr/bin/env migrationtools-47-1.fc9.noarch requires /usr/share/migrationtools/migrate_common.ph migrationtools-47-1.fc9.noarch requires /usr/bin/perl migrationtools-47-1.fc9.noarch requires /bin/sh milter-greylist-4.0-2.fc9.x86_64 requires /bin/sh milter-greylist-sysv-4.0-2.fc9.x86_64 requires /sbin/chkconfig milter-greylist-sysv-4.0-2.fc9.x86_64 requires /bin/sh milter-greylist-sysv-4.0-2.fc9.x86_64 requires /bin/sh milter-regex-1.7-3.fc9.x86_64 requires /bin/sh milter-regex-1.7-3.fc9.x86_64 requires /sbin/chkconfig milter-regex-1.7-3.fc9.x86_64 requires /bin/sh mimedefang-2.64-1.fc9.x86_64 requires /bin/sh mimedefang-2.64-1.fc9.x86_64 requires /sbin/service mimedefang-2.64-1.fc9.x86_64 requires /bin/bash mimedefang-2.64-1.fc9.x86_64 requires /bin/sh mimedefang-2.64-1.fc9.x86_64 requires /usr/bin/perl mimedefang-2.64-1.fc9.x86_64 requires /sbin/chkconfig mimetex-1.60-4.fc9.x86_64 requires /var/www/cgi-bin mimetex-1.60-4.fc9.x86_64 requires /var/www/html mimetic-0.9.3-2.fc8.i386 requires /sbin/ldconfig mimetic-0.9.3-2.fc8.x86_64 requires /sbin/ldconfig minbar-0.2.1-6.fc9.x86_64 requires /bin/sh minicom-2.3-2.fc9.x86_64 requires /bin/sh minizip-1.2.3-18.fc9.i386 requires /sbin/ldconfig minizip-1.2.3-18.fc9.x86_64 requires /sbin/ldconfig mirage-0.9.3-1.fc9.x86_64 requires /bin/sh mirage-0.9.3-1.fc9.x86_64 requires /usr/bin/python mirrormagic-2.0.2-5.fc9.x86_64 requires /bin/sh mkbootdisk-1.5.3-3.1.x86_64 requires /bin/bash mkdst-0.8-1.fc9.noarch requires /bin/sh mkinitrd-6.0.52-2.fc9.x86_64 requires /bin/bash mkinitrd-6.0.52-2.fc9.x86_64 requires /sbin/insmod.static mkinitrd-6.0.52-2.fc9.x86_64 requires /bin/sh mkinitrd-6.0.52-2.fc9.x86_64 requires /sbin/losetup mknbi-1.4.4-14.fc9.x86_64 requires /usr/bin/perl mksh-33d-1.fc9.x86_64 requires /bin/sh mkvtoolnix-gui-2.1.0-2.fc9.x86_64 requires /bin/sh mlmmj-1.2.15-2.fc9.x86_64 requires /bin/sh mlocate-0.20-1.x86_64 requires /bin/sh mlocate-0.20-1.x86_64 requires /bin/sh mlton-20070826-12.fc9.x86_64 requires /usr/bin/perl mlton-20070826-12.fc9.x86_64 requires /usr/bin/env mlton-20070826-12.fc9.x86_64 requires /bin/sh mm-1.4.2-4.fc9.i386 requires /sbin/ldconfig mm-1.4.2-4.fc9.x86_64 requires /sbin/ldconfig mm-devel-1.4.2-4.fc9.i386 requires /bin/sh mm-devel-1.4.2-4.fc9.x86_64 requires /bin/sh mock-0.9.9-1.fc10.noarch requires /bin/sh mock-0.9.9-1.fc10.noarch requires /usr/bin/python mod_auth_ntlm_winbind-0.0.0-0.8.20070129svn713.fc9.x86_64 requires /bin/sh mod_fcgid-selinux-2.2-4.fc9.x86_64 requires /usr/sbin/semodule mod_fcgid-selinux-2.2-4.fc9.x86_64 requires /bin/sh mod_fcgid-selinux-2.2-4.fc9.x86_64 requires /sbin/restorecon mod_mono-1.2.6-2.1.fc9.x86_64 requires /sbin/ldconfig mod_nss-1.0.7-4.fc10.x86_64 requires /bin/sh mod_nss-1.0.7-4.fc10.x86_64 requires /bin/bash mod_perl-2.0.4-3.x86_64 requires /usr/bin/perl mod_revocator-1.0.2-4.fc9.i386 requires /sbin/ldconfig mod_revocator-1.0.2-4.fc9.x86_64 requires /sbin/ldconfig 1:mod_ssl-2.2.8-3.x86_64 requires /bin/sh 1:mod_ssl-2.2.8-3.x86_64 requires /bin/cat modello-1.0-0.1.a8.4jpp.3.fc7.noarch requires /bin/sh modello-1.0-0.1.a8.4jpp.3.fc7.noarch requires /bin/sh modello-javadoc-1.0-0.1.a8.4jpp.3.fc7.noarch requires /bin/rm modello-javadoc-1.0-0.1.a8.4jpp.3.fc7.noarch requires /bin/ln module-init-tools-3.4-13.fc9.x86_64 requires /bin/sh module-init-tools-3.4-13.fc9.x86_64 requires /bin/bash module-init-tools-3.4-13.fc9.x86_64 requires /sbin/chkconfig module-init-tools-3.4-13.fc9.x86_64 requires /bin/sh mogilefsd-2.17-5.fc9.noarch requires /bin/sh mogilefsd-2.17-5.fc9.noarch requires /sbin/service mogilefsd-2.17-5.fc9.noarch requires /sbin/chkconfig mogilefsd-2.17-5.fc9.noarch requires /bin/bash mogilefsd-2.17-5.fc9.noarch requires /usr/bin/perl mogstored-2.17-5.fc9.noarch requires /bin/sh mogstored-2.17-5.fc9.noarch requires /sbin/service mogstored-2.17-5.fc9.noarch requires /usr/bin/perl mogstored-2.17-5.fc9.noarch requires /bin/bash mogstored-2.17-5.fc9.noarch requires /sbin/chkconfig moin-1.6.3-1.fc10.noarch requires /usr/bin/env moin-1.6.3-1.fc10.noarch requires /usr/bin/python moin-latex-0-0.20051126.3.fc6.noarch requires /usr/bin/python mona-examples-1.4r10-1.fc10.x86_64 requires /bin/sh mona-libs-1.4r10-1.fc10.i386 requires /sbin/ldconfig mona-libs-1.4r10-1.fc10.x86_64 requires /sbin/ldconfig monit-4.10.1-7.fc9.x86_64 requires /bin/sh monit-4.10.1-7.fc9.x86_64 requires /bin/bash monit-4.10.1-7.fc9.x86_64 requires /sbin/chkconfig monit-4.10.1-7.fc9.x86_64 requires /sbin/service monitor-edid-1.16-4.fc9.x86_64 requires /usr/bin/perl monitor-edid-1.16-4.fc9.x86_64 requires /bin/sh monkey-bubble-0.4.0-9.fc9.x86_64 requires /bin/sh mono-addins-0.3.1-1.fc10.x86_64 requires /bin/sh mono-basic-1.9-4.fc10.x86_64 requires /bin/sh mono-core-1.9.1-2.fc10.i386 requires /bin/sh mono-core-1.9.1-2.fc10.i386 requires /bin/bash mono-core-1.9.1-2.fc10.x86_64 requires /bin/bash mono-core-1.9.1-2.fc10.x86_64 requires /bin/sh mono-data-1.9.1-2.fc10.x86_64 requires /bin/sh mono-debugger-0.60-3.fc9.i386 requires /sbin/ldconfig mono-debugger-0.60-3.fc9.i386 requires /bin/sh mono-debugger-0.60-3.fc9.x86_64 requires /sbin/ldconfig mono-debugger-0.60-3.fc9.x86_64 requires /bin/sh mono-devel-1.9.1-2.fc10.i386 requires /sbin/ldconfig mono-devel-1.9.1-2.fc10.i386 requires /bin/sh mono-devel-1.9.1-2.fc10.x86_64 requires /sbin/ldconfig mono-devel-1.9.1-2.fc10.x86_64 requires /bin/sh mono-extras-1.9.1-2.fc10.x86_64 requires /bin/sh mono-jscript-1.9.1-2.fc10.x86_64 requires /bin/sh mono-nunit-1.9.1-2.fc10.x86_64 requires /bin/sh mono-web-1.9.1-2.fc10.x86_64 requires /bin/sh mono-zeroconf-0.7.5-4.fc9.x86_64 requires /bin/bash monodevelop-0.19-6.fc9.x86_64 requires /bin/sh monodevelop-0.19-6.fc9.x86_64 requires /bin/bash monodevelop-0.19-6.fc9.x86_64 requires /bin/sh monodoc-1.9-1.fc10.x86_64 requires /bin/sh monosim-1.3.0.2-1.fc9.x86_64 requires /bin/sh monotone-0.39-1.fc9.x86_64 requires /bin/sh monotone-0.39-1.fc9.x86_64 requires /sbin/install-info monotone-server-0.39-1.fc9.x86_64 requires /bin/sh monotone-server-0.39-1.fc9.x86_64 requires /sbin/chkconfig monotone-server-0.39-1.fc9.x86_64 requires /bin/sh monotone-server-0.39-1.fc9.x86_64 requires /sbin/service monsterz-0.7.1-3.fc9.x86_64 requires /bin/sh monsterz-0.7.1-3.fc9.x86_64 requires /usr/bin/env moodle-1.9-1.fc9.noarch requires /bin/sh moodle-1.9-1.fc9.noarch requires /usr/bin/perl moodle-1.9-1.fc9.noarch requires /bin/bash moodle-1.9-1.fc9.noarch requires /sbin/chkconfig moodle-1.9-1.fc9.noarch requires /usr/bin/php moodle-1.9-1.fc9.noarch requires /bin/sh moodle-1.9-1.fc9.noarch requires /sbin/service moodss-21.5-3.fc9.x86_64 requires /usr/bin/env moomps-5.8-3.fc9.x86_64 requires /bin/bash moomps-5.8-3.fc9.x86_64 requires /bin/sh moomps-5.8-3.fc9.x86_64 requires /sbin/chkconfig moomps-5.8-3.fc9.x86_64 requires /usr/bin/tclsh moomps-5.8-3.fc9.x86_64 requires /sbin/service moreutils-0.28-3.fc9.x86_64 requires /usr/bin/perl mosml-2.01-11.fc9.i386 requires /bin/sh mousepad-0.2.13-2.fc9.x86_64 requires /bin/sh mousetweaks-2.23.2-3.fc10.x86_64 requires /bin/sh mozilla-opensc-signer-0.11.4-4.fc9.x86_64 requires /usr/lib64/mozilla/plugins mozldap-6.0.5-2.fc9.i386 requires /sbin/ldconfig mozldap-6.0.5-2.fc9.x86_64 requires /sbin/ldconfig mpc-0.12.1-2.fc9.x86_64 requires /bin/sh mpfr-2.3.0-3.fc9.i386 requires /sbin/ldconfig mpfr-2.3.0-3.fc9.x86_64 requires /sbin/ldconfig mpfr-devel-2.3.0-3.fc9.i386 requires /bin/sh mpfr-devel-2.3.0-3.fc9.i386 requires /sbin/install-info mpfr-devel-2.3.0-3.fc9.x86_64 requires /bin/sh mpfr-devel-2.3.0-3.fc9.x86_64 requires /sbin/install-info mrtg-2.16.1-2.fc10.x86_64 requires /bin/sh mrtg-2.16.1-2.fc10.x86_64 requires /sbin/service mrtg-2.16.1-2.fc10.x86_64 requires /usr/bin/perl mrtg-2.16.1-2.fc10.x86_64 requires /bin/sh msmtp-1.4.13-4.fc9.x86_64 requires /bin/sh msmtp-1.4.13-4.fc9.x86_64 requires /sbin/install-info 1:mt-daapd-0.2.4.2-2.fc10.x86_64 requires /bin/sh 1:mt-daapd-0.2.4.2-2.fc10.x86_64 requires /usr/sbin/useradd 1:mt-daapd-0.2.4.2-2.fc10.x86_64 requires /sbin/service 1:mt-daapd-0.2.4.2-2.fc10.x86_64 requires /bin/bash 1:mt-daapd-0.2.4.2-2.fc10.x86_64 requires /sbin/chkconfig mtd-utils-1.1.0-2.fc8.x86_64 requires /usr/bin/perl mtools-3.9.11-4.fc9.x86_64 requires /bin/sh mtools-3.9.11-4.fc9.x86_64 requires /bin/sh mtpaint-3.20-3.fc9.x86_64 requires /bin/sh mtx-1.3.11-3.fc9.x86_64 requires /bin/sh muParser-1.28-4.fc9.i386 requires /sbin/ldconfig muParser-1.28-4.fc9.x86_64 requires /sbin/ldconfig mugshot-1.1.95-1.fc9.x86_64 requires /bin/sh mugshot-1.1.95-1.fc9.x86_64 requires /usr/bin/python mugshot-1.1.95-1.fc9.x86_64 requires /bin/sh muine-0.8.8-9.fc9.x86_64 requires /bin/sh muine-0.8.8-9.fc9.x86_64 requires /bin/bash multican-0.0.5-4.fc9.i386 requires /sbin/ldconfig multican-0.0.5-4.fc9.x86_64 requires /sbin/ldconfig munin-1.2.5-4.fc9.noarch requires /bin/sh munin-1.2.5-4.fc9.noarch requires /usr/bin/perl munin-1.2.5-4.fc9.noarch requires /bin/sh munin-node-1.2.5-4.fc9.noarch requires /bin/sh munin-node-1.2.5-4.fc9.noarch requires /usr/bin/env munin-node-1.2.5-4.fc9.noarch requires /sbin/service munin-node-1.2.5-4.fc9.noarch requires /bin/bash munin-node-1.2.5-4.fc9.noarch requires /bin/sh munin-node-1.2.5-4.fc9.noarch requires /usr/bin/perl munin-node-1.2.5-4.fc9.noarch requires /sbin/chkconfig munipack-0.3.1-3.fc9.x86_64 requires /bin/sh museek+-0.1.13-3.fc9.x86_64 requires /usr/bin/env museek+-0.1.13-3.fc9.x86_64 requires /usr/bin/python musicbox-0.2.3-6.fc9.x86_64 requires /usr/bin/perl mussh-0.7-2.fc8.noarch requires /bin/bash 5:mutt-1.5.17-4.fc9.x86_64 requires /usr/bin/perl 1:mx4j-3.0.1-6jpp.4.x86_64 requires /bin/sh 1:mx4j-3.0.1-6jpp.4.x86_64 requires /usr/sbin/update-alternatives 1:mx4j-3.0.1-6jpp.4.x86_64 requires /bin/rm 1:mx4j-javadoc-3.0.1-6jpp.4.x86_64 requires /bin/sh 1:mx4j-javadoc-3.0.1-6jpp.4.x86_64 requires /bin/rm 1:mx4j-javadoc-3.0.1-6jpp.4.x86_64 requires /bin/ln mxml-2.2.2-8.fc9.i386 requires /sbin/ldconfig mxml-2.2.2-8.fc9.x86_64 requires /sbin/ldconfig mybashburn-1.0.2-3.fc8.noarch requires /usr/bin/env mybashburn-1.0.2-3.fc8.noarch requires /bin/sh mypaint-0.5.0-7.fc9.x86_64 requires /usr/bin/env mysql-5.0.51a-1.fc9.x86_64 requires /bin/sh mysql-5.0.51a-1.fc9.x86_64 requires /sbin/install-info mysql-5.0.51a-1.fc9.x86_64 requires /usr/bin/perl mysql-5.0.51a-1.fc9.x86_64 requires /bin/sh mysql++-3.0.3-1.fc10.i386 requires /sbin/ldconfig mysql++-3.0.3-1.fc10.x86_64 requires /sbin/ldconfig mysql-administrator-5.0r12-5.fc9.x86_64 requires /bin/sh mysql-bench-5.0.51a-1.fc9.x86_64 requires /usr/bin/perl 1:mysql-connector-java-3.1.12-5.fc9.x86_64 requires /bin/sh mysql-connector-odbc-3.51.24r1071-1.fc9.x86_64 requires /sbin/ldconfig mysql-libs-5.0.51a-1.fc9.i386 requires /bin/sh mysql-libs-5.0.51a-1.fc9.i386 requires /sbin/ldconfig mysql-libs-5.0.51a-1.fc9.x86_64 requires /bin/sh mysql-libs-5.0.51a-1.fc9.x86_64 requires /sbin/ldconfig mysql-query-browser-5.0r12-5.fc9.x86_64 requires /bin/sh mysql-server-5.0.51a-1.fc9.x86_64 requires /bin/sh mysql-server-5.0.51a-1.fc9.x86_64 requires /usr/sbin/useradd mysql-server-5.0.51a-1.fc9.x86_64 requires /bin/bash mysql-server-5.0.51a-1.fc9.x86_64 requires /bin/sh mysql-server-5.0.51a-1.fc9.x86_64 requires /usr/bin/perl mysql-server-5.0.51a-1.fc9.x86_64 requires /sbin/chkconfig mysql-test-5.0.51a-1.fc9.x86_64 requires /usr/bin/perl mysql-test-5.0.51a-1.fc9.x86_64 requires /bin/sh mytop-1.6-2.fc9.noarch requires /usr/bin/perl nabi-0.18-9.fc9.x86_64 requires /bin/sh nabi-0.18-9.fc9.x86_64 requires /usr/sbin/alternatives nafees-web-naskh-fonts-1.0-1.fc8.noarch requires /bin/sh nagios-2.11-3.fc9.x86_64 requires /bin/sh nagios-2.11-3.fc9.x86_64 requires /usr/bin/perl nagios-2.11-3.fc9.x86_64 requires /bin/sh nagios-plugins-1.4.11-4.fc10.x86_64 requires /bin/sh nagios-plugins-breeze-1.4.11-4.fc10.x86_64 requires /usr/bin/perl nagios-plugins-by_ssh-1.4.11-4.fc10.x86_64 requires /usr/bin/ssh nagios-plugins-dig-1.4.11-4.fc10.x86_64 requires /usr/bin/dig nagios-plugins-disk_smb-1.4.11-4.fc10.x86_64 requires /usr/bin/smbclient nagios-plugins-disk_smb-1.4.11-4.fc10.x86_64 requires /usr/bin/perl nagios-plugins-dns-1.4.11-4.fc10.x86_64 requires /usr/bin/nslookup nagios-plugins-file_age-1.4.11-4.fc10.x86_64 requires /usr/bin/perl nagios-plugins-flexlm-1.4.11-4.fc10.x86_64 requires /usr/bin/perl nagios-plugins-fping-1.4.11-4.fc10.x86_64 requires /usr/sbin/fping nagios-plugins-ifoperstatus-1.4.11-4.fc10.x86_64 requires /usr/bin/perl nagios-plugins-ifstatus-1.4.11-4.fc10.x86_64 requires /usr/bin/perl nagios-plugins-ircd-1.4.11-4.fc10.x86_64 requires /usr/bin/perl nagios-plugins-linux_raid-1.4.11-4.fc10.x86_64 requires /usr/bin/perl nagios-plugins-log-1.4.11-4.fc10.x86_64 requires /bin/egrep nagios-plugins-log-1.4.11-4.fc10.x86_64 requires /bin/mktemp nagios-plugins-log-1.4.11-4.fc10.x86_64 requires /bin/sh nagios-plugins-mailq-1.4.11-4.fc10.x86_64 requires /usr/bin/perl nagios-plugins-ntp-1.4.11-4.fc10.x86_64 requires /usr/sbin/ntpq nagios-plugins-ntp-1.4.11-4.fc10.x86_64 requires /usr/sbin/ntpdc nagios-plugins-ntp-1.4.11-4.fc10.x86_64 requires /usr/sbin/ntpdate nagios-plugins-oracle-1.4.11-4.fc10.x86_64 requires /bin/sh nagios-plugins-ping-1.4.11-4.fc10.x86_64 requires /bin/ping nagios-plugins-ping-1.4.11-4.fc10.x86_64 requires /bin/ping6 nagios-plugins-rpc-1.4.11-4.fc10.x86_64 requires /usr/bin/perl nagios-plugins-rpc-1.4.11-4.fc10.x86_64 requires /usr/sbin/rpcinfo nagios-plugins-sensors-1.4.11-4.fc10.x86_64 requires /usr/bin/sensors nagios-plugins-sensors-1.4.11-4.fc10.x86_64 requires /bin/egrep nagios-plugins-sensors-1.4.11-4.fc10.x86_64 requires /bin/sh nagios-plugins-snmp-1.4.11-4.fc10.x86_64 requires /usr/bin/snmpget nagios-plugins-snmp-1.4.11-4.fc10.x86_64 requires /usr/bin/snmpgetnext nagios-plugins-wave-1.4.11-4.fc10.x86_64 requires /usr/bin/perl naim-0.11.8.3.1-6.fc9.x86_64 requires /bin/sh namazu-2.0.18-1.fc9.x86_64 requires /usr/bin/perl namazu-devel-2.0.18-1.fc9.i386 requires /bin/sh namazu-devel-2.0.18-1.fc9.x86_64 requires /bin/sh namazu-libs-2.0.18-1.fc9.i386 requires /sbin/ldconfig namazu-libs-2.0.18-1.fc9.x86_64 requires /sbin/ldconfig nano-2.0.6-4.fc9.x86_64 requires /bin/sh nano-2.0.6-4.fc9.x86_64 requires /sbin/install-info 1:nant-0.85-21.fc9.x86_64 requires /bin/sh 1:nant-docs-0.85-21.fc9.x86_64 requires /bin/sh nas-1.9.1-4.fc9.x86_64 requires /bin/sh nas-1.9.1-4.fc9.x86_64 requires /sbin/service nas-1.9.1-4.fc9.x86_64 requires /bin/bash nas-1.9.1-4.fc9.x86_64 requires /bin/sh nas-1.9.1-4.fc9.x86_64 requires /usr/bin/perl nas-libs-1.9.1-4.fc9.i386 requires /sbin/ldconfig nas-libs-1.9.1-4.fc9.x86_64 requires /sbin/ldconfig nash-6.0.52-2.fc9.i386 requires /bin/bash nash-6.0.52-2.fc9.x86_64 requires /bin/bash nasm-2.01-2.fc9.x86_64 requires /bin/sh nasm-2.01-2.fc9.x86_64 requires /sbin/install-info naturette-1.3-1.fc8.noarch requires /bin/sh naturette-1.3-1.fc8.noarch requires /bin/bash nautilus-2.23.2-2.fc10.x86_64 requires /bin/sh nautilus-actions-1.4.1-3.fc9.x86_64 requires /bin/sh nautilus-cd-burner-2.22.1-1.fc9.i386 requires /bin/sh nautilus-cd-burner-2.22.1-1.fc9.x86_64 requires /bin/sh nautilus-open-terminal-0.9-2.fc9.x86_64 requires /bin/sh nautilus-python-0.4.3-5.fc9.x86_64 requires /sbin/ldconfig nautilus-sendto-0.14.0-4.fc10.x86_64 requires /bin/sh nazghul-haxima-0.6.0-4.20080407cvs.fc9.x86_64 requires /bin/sh nbd-2.9.10-1.fc9.x86_64 requires /bin/sh nc-1.84-16.fc9.x86_64 requires /bin/sh ncl-5.0.0-11.fc9.x86_64 requires /bin/csh ncl-devel-5.0.0-11.fc9.i386 requires /bin/csh ncl-devel-5.0.0-11.fc9.x86_64 requires /bin/csh ncl-examples-5.0.0-11.fc9.x86_64 requires /bin/csh nco-3.9.3-1.fc9.i386 requires /bin/sh nco-3.9.3-1.fc9.x86_64 requires /bin/sh ncpfs-2.2.6-10.fc9.i386 requires /sbin/ldconfig ncpfs-2.2.6-10.fc9.x86_64 requires /sbin/ldconfig ncurses-devel-5.6-16.20080301.fc9.i386 requires /bin/sh ncurses-devel-5.6-16.20080301.fc9.x86_64 requires /bin/sh ncurses-libs-5.6-16.20080301.fc9.i386 requires /sbin/ldconfig ncurses-libs-5.6-16.20080301.fc9.x86_64 requires /sbin/ldconfig neXtaw-0.15.1-12.fc9.i386 requires /sbin/ldconfig neXtaw-0.15.1-12.fc9.x86_64 requires /sbin/ldconfig nedit-5.5-18.fc9.x86_64 requires /bin/sh nekohtml-0.9.5-4jpp.1.fc7.noarch requires /bin/sh nemiver-0.5.2-1.fc9.i386 requires /bin/sh nemiver-0.5.2-1.fc9.x86_64 requires /bin/sh neon-0.28.2-2.i386 requires /sbin/ldconfig neon-0.28.2-2.x86_64 requires /sbin/ldconfig neon-devel-0.28.2-2.i386 requires /bin/sh neon-devel-0.28.2-2.x86_64 requires /bin/sh nessus-core-2.2.10-4.fc9.x86_64 requires /bin/sh nessus-libraries-2.2.10-3.fc9.i386 requires /sbin/ldconfig nessus-libraries-2.2.10-3.fc9.x86_64 requires /sbin/ldconfig nessus-libraries-devel-2.2.10-3.fc9.i386 requires /bin/sh nessus-libraries-devel-2.2.10-3.fc9.x86_64 requires /bin/sh nessus-server-2.2.10-4.fc9.x86_64 requires /bin/sh nessus-server-2.2.10-4.fc9.x86_64 requires /sbin/service nessus-server-2.2.10-4.fc9.x86_64 requires /sbin/chkconfig nessus-server-2.2.10-4.fc9.x86_64 requires /bin/sh 1:net-snmp-5.4.1-15.fc10.x86_64 requires /bin/sh 1:net-snmp-5.4.1-15.fc10.x86_64 requires /bin/bash 1:net-snmp-5.4.1-15.fc10.x86_64 requires /bin/sh 1:net-snmp-5.4.1-15.fc10.x86_64 requires /usr/bin/perl 1:net-snmp-devel-5.4.1-15.fc10.i386 requires /bin/sh 1:net-snmp-devel-5.4.1-15.fc10.x86_64 requires /bin/sh 1:net-snmp-gui-5.4.1-15.fc10.x86_64 requires /usr/bin/perl 1:net-snmp-libs-5.4.1-15.fc10.i386 requires /sbin/ldconfig 1:net-snmp-libs-5.4.1-15.fc10.x86_64 requires /sbin/ldconfig 1:net-snmp-perl-5.4.1-15.fc10.x86_64 requires /usr/bin/perl 1:net-snmp-perl-5.4.1-15.fc10.x86_64 requires /bin/bash 1:net-snmp-utils-5.4.1-15.fc10.x86_64 requires /usr/bin/perl net-tools-1.60-87.fc9.x86_64 requires /bin/sh net-tools-1.60-87.fc9.x86_64 requires /sbin/chkconfig net-tools-1.60-87.fc9.x86_64 requires /bin/sh net-tools-1.60-87.fc9.x86_64 requires /sbin/service net6-1.3.5-3.fc9.i386 requires /sbin/ldconfig net6-1.3.5-3.fc9.x86_64 requires /sbin/ldconfig 4:netatalk-2.0.3-19.fc9.x86_64 requires /bin/sh 4:netatalk-2.0.3-19.fc9.x86_64 requires /sbin/service 4:netatalk-2.0.3-19.fc9.x86_64 requires /sbin/ldconfig 4:netatalk-2.0.3-19.fc9.x86_64 requires /usr/bin/perl 4:netatalk-2.0.3-19.fc9.x86_64 requires /bin/sh 4:netatalk-2.0.3-19.fc9.x86_64 requires /sbin/chkconfig 4:netatalk-devel-2.0.3-19.fc9.i386 requires /bin/sh 4:netatalk-devel-2.0.3-19.fc9.x86_64 requires /bin/sh netcdf-4.0.0-0.4.beta2.fc10.i386 requires /bin/sh netcdf-4.0.0-0.4.beta2.fc10.x86_64 requires /bin/sh netcdf-perl-1.2.3-7.fc9.x86_64 requires /usr/bin/perl netdump-server-0.7.16-22.fc9.x86_64 requires /bin/sh netdump-server-0.7.16-22.fc9.x86_64 requires /sbin/service netdump-server-0.7.16-22.fc9.x86_64 requires /bin/sh netdump-server-0.7.16-22.fc9.x86_64 requires /usr/bin/ssh-keygen netdump-server-0.7.16-22.fc9.x86_64 requires /usr/bin/ssh netdump-server-0.7.16-22.fc9.x86_64 requires /sbin/ifconfig netembryo-0.0.5-2.fc9.i386 requires /sbin/ldconfig netembryo-0.0.5-2.fc9.x86_64 requires /sbin/ldconfig netgen-1.3.7-15.fc9.x86_64 requires /bin/sh netgen-1.3.7-15.fc9.x86_64 requires /bin/csh netgen-1.3.7-15.fc9.x86_64 requires /bin/sh netgo-0.5-10.fc9.x86_64 requires /bin/sh nethack-3.4.3-17.fc9.x86_64 requires /bin/sh nethack-3.4.3-17.fc9.x86_64 requires /bin/sh nethack-vultures-2.1.0-10.fc8.x86_64 requires /bin/sh nethack-vultures-2.1.0-10.fc8.x86_64 requires /usr/sbin/groupadd nethack-vultures-2.1.0-10.fc8.x86_64 requires /bin/sh nethack-vultures-2.1.0-10.fc8.x86_64 requires /usr/bin/bzip2 netlabel_tools-0.17-7.fc9.x86_64 requires /bin/sh netmask-2.3.9-3.fc9.x86_64 requires /bin/sh netmask-2.3.9-3.fc9.x86_64 requires /sbin/install-info netpanzer-0.8.2-3.fc9.x86_64 requires /bin/sh netpbm-10.35.43-1.fc10.i386 requires /sbin/ldconfig netpbm-10.35.43-1.fc10.x86_64 requires /sbin/ldconfig netpbm-progs-10.35.43-1.fc10.x86_64 requires /usr/bin/perl netpbm-progs-10.35.43-1.fc10.x86_64 requires /bin/sh nettle-1.15-4.fc9.i386 requires /bin/sh nettle-1.15-4.fc9.i386 requires /sbin/ldconfig nettle-1.15-4.fc9.i386 requires /sbin/install-info nettle-1.15-4.fc9.x86_64 requires /bin/sh nettle-1.15-4.fc9.x86_64 requires /sbin/ldconfig nettle-1.15-4.fc9.x86_64 requires /sbin/install-info newscache-1.2-0.6.rc6.fc9.x86_64 requires /bin/sh newscache-1.2-0.6.rc6.fc9.x86_64 requires /sbin/service newscache-1.2-0.6.rc6.fc9.x86_64 requires /bin/bash newscache-1.2-0.6.rc6.fc9.x86_64 requires /sbin/chkconfig newsx-1.6-8.fc9.x86_64 requires /bin/sh newt-0.52.9-1.fc9.i386 requires /sbin/ldconfig newt-0.52.9-1.fc9.x86_64 requires /sbin/ldconfig nexcontrol-0.2-1.fc9.noarch requires /usr/bin/perl nexuiz-2.4-1.fc10.x86_64 requires /bin/sh 1:nfs-utils-1.1.2-5.fc10.x86_64 requires /bin/sh 1:nfs-utils-1.1.2-5.fc10.x86_64 requires /bin/sh 1:nfs-utils-1.1.2-5.fc10.x86_64 requires /sbin/nologin 1:nfs-utils-1.1.2-5.fc10.x86_64 requires /bin/bash 1:nfs-utils-1.1.2-5.fc10.x86_64 requires /sbin/chkconfig nfs-utils-lib-1.1.1-3.fc9.i386 requires /sbin/ldconfig nfs-utils-lib-1.1.1-3.fc9.x86_64 requires /sbin/ldconfig nginx-0.6.31-1.fc10.x86_64 requires /bin/sh nginx-0.6.31-1.fc10.x86_64 requires /bin/sh ngspice-doc-17-14.fc9.x86_64 requires /bin/sh ngspice-doc-17-14.fc9.x86_64 requires /sbin/install-info nikto-1.36-3.fc8.noarch requires /usr/bin/perl nip2-7.14.1-1.fc9.x86_64 requires /bin/sh nip2-7.14.1-1.fc9.x86_64 requires libMagick.so.10()(64bit) nip2-7.14.1-1.fc9.x86_64 requires /bin/bash nip2-7.14.1-1.fc9.x86_64 requires libWand.so.10()(64bit) njam-1.25-9.fc9.x86_64 requires /bin/sh 2:nmap-frontend-4.62-1.fc10.x86_64 requires /usr/bin/python nmh-1.3-RC1.1.fc10.x86_64 requires /bin/sh nntpgrab-core-0.2.90-1.fc10.i386 requires /sbin/ldconfig nntpgrab-core-0.2.90-1.fc10.x86_64 requires /sbin/ldconfig nogravity-2.00-6.fc9.x86_64 requires /bin/sh nogravity-2.00-6.fc9.x86_64 requires /bin/bash notecase-1.6.1-4.fc9.x86_64 requires /bin/sh notification-daemon-0.3.7-9.fc9.x86_64 requires /bin/sh nqc-3.1.6-2.fc9.x86_64 requires /bin/sh nqc-3.1.6-2.fc9.x86_64 requires /usr/sbin/groupadd nrpe-2.7-6.fc9.x86_64 requires /bin/sh nrpe-2.7-6.fc9.x86_64 requires /sbin/chkconfig nrpe-2.7-6.fc9.x86_64 requires /usr/sbin/useradd nrpe-2.7-6.fc9.x86_64 requires /bin/sh nrpe-2.7-6.fc9.x86_64 requires /sbin/service nsca-2.7.2-6.fc9.x86_64 requires /bin/sh nsca-2.7.2-6.fc9.x86_64 requires /sbin/chkconfig nsca-2.7.2-6.fc9.x86_64 requires /bin/sh nsca-2.7.2-6.fc9.x86_64 requires /sbin/service nscd-2.8.90-2.x86_64 requires /usr/sbin/userdel nscd-2.8.90-2.x86_64 requires /bin/sh nscd-2.8.90-2.x86_64 requires /usr/sbin/useradd nscd-2.8.90-2.x86_64 requires /bin/bash nscd-2.8.90-2.x86_64 requires /sbin/chkconfig nsd-3.0.7-3.fc9.x86_64 requires /bin/sh nsd-3.0.7-3.fc9.x86_64 requires /bin/bash nsd-3.0.7-3.fc9.x86_64 requires /bin/sh nspluginwrapper-0.9.91.5-27.fc9.i386 requires /bin/sh nspluginwrapper-0.9.91.5-27.fc9.i386 requires /usr/bin/linux32 nspluginwrapper-0.9.91.5-27.fc9.i386 requires /bin/sh nspluginwrapper-0.9.91.5-27.fc9.x86_64 requires /bin/sh nspluginwrapper-0.9.91.5-27.fc9.x86_64 requires /bin/sh nspluginwrapper-0.9.91.5-27.fc9.x86_64 requires /usr/bin/linux32 nspr-4.7.0.99.2-2.fc9.i386 requires /bin/sh nspr-4.7.0.99.2-2.fc9.x86_64 requires /bin/sh nspr-devel-4.7.0.99.2-2.fc9.i386 requires /bin/sh nspr-devel-4.7.0.99.2-2.fc9.x86_64 requires /bin/sh nss-3.11.99.5-2.fc9.i386 requires /bin/sh nss-3.11.99.5-2.fc9.x86_64 requires /bin/sh nss-devel-3.11.99.5-2.fc9.i386 requires /bin/sh nss-devel-3.11.99.5-2.fc9.x86_64 requires /bin/sh nss-mdns-0.10-4.fc9.i386 requires /bin/sh nss-mdns-0.10-4.fc9.i386 requires /sbin/ldconfig nss-mdns-0.10-4.fc9.x86_64 requires /bin/sh nss-mdns-0.10-4.fc9.x86_64 requires /sbin/ldconfig nss_compat_ossl-0.9.2-4.fc9.i386 requires /sbin/ldconfig nss_compat_ossl-0.9.2-4.fc9.x86_64 requires /sbin/ldconfig nss_db-2.2-40.fc9.i386 requires /sbin/ldconfig nss_db-2.2-40.fc9.x86_64 requires /sbin/ldconfig nss_ldap-259-3.fc9.i386 requires /bin/sh nss_ldap-259-3.fc9.i386 requires /sbin/ldconfig nss_ldap-259-3.fc9.x86_64 requires /bin/sh nss_ldap-259-3.fc9.x86_64 requires /sbin/ldconfig 2:ntfs-3g-1.2506-1.fc10.i386 requires /sbin/ldconfig 2:ntfs-3g-1.2506-1.fc10.x86_64 requires /sbin/ldconfig ntfs-config-1.0-0.6.rc5.fc9.noarch requires /usr/bin/python2.5 ntfsprogs-2.0.0-7.fc10.i386 requires /sbin/ldconfig ntfsprogs-2.0.0-7.fc10.x86_64 requires /sbin/ldconfig ntp-4.2.4p4-6.fc9.x86_64 requires /bin/sh ntp-4.2.4p4-6.fc9.x86_64 requires /sbin/service ntp-4.2.4p4-6.fc9.x86_64 requires /bin/bash ntp-4.2.4p4-6.fc9.x86_64 requires /usr/bin/perl ntp-4.2.4p4-6.fc9.x86_64 requires /sbin/chkconfig numactl-2.0.0-1.fc10.i386 requires /sbin/ldconfig numactl-2.0.0-1.fc10.i386 requires /usr/bin/perl numactl-2.0.0-1.fc10.x86_64 requires /sbin/ldconfig numactl-2.0.0-1.fc10.x86_64 requires /usr/bin/perl numlockx-1.0-14.fc9.x86_64 requires /bin/sh numpy-1.0.3.1-2.fc9.x86_64 requires /usr/bin/env nut-2.2.2-1.fc10.x86_64 requires /bin/sh nut-2.2.2-1.fc10.x86_64 requires /sbin/service nut-2.2.2-1.fc10.x86_64 requires /sbin/chkconfig nut-cgi-2.2.2-1.fc10.x86_64 requires /bin/sh nut-client-2.2.2-1.fc10.i386 requires /bin/sh nut-client-2.2.2-1.fc10.i386 requires /bin/bash nut-client-2.2.2-1.fc10.i386 requires /usr/sbin/useradd nut-client-2.2.2-1.fc10.i386 requires /bin/sh nut-client-2.2.2-1.fc10.x86_64 requires /bin/sh nut-client-2.2.2-1.fc10.x86_64 requires /bin/bash nut-client-2.2.2-1.fc10.x86_64 requires /usr/sbin/useradd nut-client-2.2.2-1.fc10.x86_64 requires /bin/sh nvclock-gtk-0.8-0.6.b3a.fc10.x86_64 requires /bin/sh nx-3.2.0-27.fc9.i386 requires /bin/bash nx-3.2.0-27.fc9.i386 requires /bin/sh nyquist-2.37-2.fc9.x86_64 requires /bin/sh obby-0.4.4-3.fc9.i386 requires /sbin/ldconfig obby-0.4.4-3.fc9.x86_64 requires /sbin/ldconfig obconf-2.0.3-2.fc10.x86_64 requires /bin/sh obexftp-0.22-0.9.rc9.fc9.i386 requires /sbin/ldconfig obexftp-0.22-0.9.rc9.fc9.x86_64 requires /sbin/ldconfig obmenu-1.0-6.fc9.noarch requires /usr/bin/python ocaml-3.10.2-2.fc10.x86_64 requires /bin/sh ocaml-3.10.2-2.fc10.x86_64 requires /usr/bin/ocamlrun ocaml-camlidl-1.05-5.fc10.x86_64 requires /usr/bin/ocamlrun ocaml-camlp4-devel-3.10.2-2.fc10.i386 requires /usr/bin/ocamlrun ocaml-camlp4-devel-3.10.2-2.fc10.x86_64 requires /usr/bin/ocamlrun ocaml-camlp5-devel-5.08-3.fc10.i386 requires /bin/sh ocaml-camlp5-devel-5.08-3.fc10.i386 requires /usr/bin/ocamlrun ocaml-camlp5-devel-5.08-3.fc10.x86_64 requires /bin/sh ocaml-camlp5-devel-5.08-3.fc10.x86_64 requires /usr/bin/ocamlrun ocaml-cil-cilly-1.3.6-5.fc10.x86_64 requires /usr/bin/perl ocaml-deriving-0.1.1a-3.fc10.x86_64 requires /usr/bin/ocamlrun ocaml-docs-3.10.2-2.fc10.x86_64 requires /bin/sh ocaml-docs-3.10.2-2.fc10.x86_64 requires /sbin/install-info ocaml-findlib-1.2.1-3.fc10.x86_64 requires /bin/sh ocaml-findlib-devel-1.2.1-3.fc10.i386 requires /usr/bin/ocamlrun ocaml-findlib-devel-1.2.1-3.fc10.x86_64 requires /usr/bin/ocamlrun ocaml-gettext-devel-0.3.0-1.fc10.i386 requires /usr/bin/ocamlrun ocaml-gettext-devel-0.3.0-1.fc10.x86_64 requires /usr/bin/ocamlrun ocaml-gsl-devel-0.6.0-3.fc10.i386 requires /bin/sh ocaml-gsl-devel-0.6.0-3.fc10.i386 requires /sbin/install-info ocaml-gsl-devel-0.6.0-3.fc10.x86_64 requires /bin/sh ocaml-gsl-devel-0.6.0-3.fc10.x86_64 requires /sbin/install-info ocaml-lablgl-1.03-4.fc10.x86_64 requires /bin/sh ocaml-lablgtk-2.10.1-2.fc10.x86_64 requires /bin/sh ocaml-lablgtk-2.10.1-2.fc10.x86_64 requires /usr/bin/ocamlrun ocaml-lablgtk-devel-2.10.1-2.fc10.i386 requires /usr/bin/ocamlrun ocaml-lablgtk-devel-2.10.1-2.fc10.x86_64 requires /usr/bin/ocamlrun ocaml-labltk-3.10.2-2.fc10.x86_64 requires /bin/sh ocaml-labltk-devel-3.10.2-2.fc10.i386 requires /usr/bin/wish ocaml-labltk-devel-3.10.2-2.fc10.i386 requires /usr/bin/ocamlrun ocaml-labltk-devel-3.10.2-2.fc10.x86_64 requires /usr/bin/wish ocaml-labltk-devel-3.10.2-2.fc10.x86_64 requires /usr/bin/ocamlrun ocaml-ocamldoc-3.10.2-2.fc10.x86_64 requires /usr/bin/ocamlrun ocaml-perl4caml-0.9.5-5.fc10.x86_64 requires /usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi/CORE/libperl.so ocaml-runtime-3.10.2-2.fc10.x86_64 requires /bin/sh ocfs2-tools-1.3.9-7.20080221git.fc8.x86_64 requires /bin/sh ocfs2-tools-1.3.9-7.20080221git.fc8.x86_64 requires /sbin/service ocfs2-tools-1.3.9-7.20080221git.fc8.x86_64 requires /bin/bash ocfs2console-1.3.9-7.20080221git.fc8.x86_64 requires /usr/bin/python ochusha-0.5.99.66-0.4.cvs070110.fc9.2.i386 requires /etc/pki/tls/cert.pem ochusha-0.5.99.66-0.4.cvs070110.fc9.2.i386 requires /bin/sh ochusha-0.5.99.66-0.4.cvs070110.fc9.2.x86_64 requires /bin/sh ochusha-0.5.99.66-0.4.cvs070110.fc9.2.x86_64 requires /etc/pki/tls/cert.pem ocrad-0.17-3.fc9.x86_64 requires /bin/sh ocrad-0.17-3.fc9.x86_64 requires /sbin/install-info ocsinventory-agent-0.0.9.2-1.fc10.noarch requires /etc/logrotate.d ocsinventory-agent-0.0.9.2-1.fc10.noarch requires /usr/bin/perl ocsinventory-agent-0.0.9.2-1.fc10.noarch requires /etc/cron.hourly ocsinventory-agent-0.0.9.2-1.fc10.noarch requires /bin/bash 6:octave-3.0.1-1.fc10.i386 requires /bin/sh 6:octave-3.0.1-1.fc10.i386 requires /sbin/install-info 6:octave-3.0.1-1.fc10.i386 requires /sbin/ldconfig 6:octave-3.0.1-1.fc10.i386 requires /bin/sh 6:octave-3.0.1-1.fc10.x86_64 requires /bin/sh 6:octave-3.0.1-1.fc10.x86_64 requires /sbin/install-info 6:octave-3.0.1-1.fc10.x86_64 requires /sbin/ldconfig 6:octave-3.0.1-1.fc10.x86_64 requires /bin/sh 6:octave-devel-3.0.1-1.fc10.i386 requires /bin/sh 6:octave-devel-3.0.1-1.fc10.x86_64 requires /bin/sh octave-forge-20080429-6.fc10.x86_64 requires /bin/sh octave-forge-20080429-6.fc10.x86_64 requires /bin/sh odccm-0.11-2.fc9.x86_64 requires /bin/sh odccm-0.11-2.fc9.x86_64 requires /sbin/service odccm-0.11-2.fc9.x86_64 requires /sbin/chkconfig odccm-0.11-2.fc9.x86_64 requires /bin/bash oddjob-0.29-2.fc9.x86_64 requires /bin/sh oddjob-0.29-2.fc9.x86_64 requires /bin/bash oddjob-0.29-2.fc9.x86_64 requires /sbin/chkconfig oddjob-0.29-2.fc9.x86_64 requires /bin/sh oddjob-0.29-2.fc9.x86_64 requires /sbin/service oddjob-libs-0.29-2.fc9.i386 requires /sbin/ldconfig oddjob-libs-0.29-2.fc9.x86_64 requires /sbin/ldconfig oddjob-mkhomedir-0.29-2.fc9.i386 requires /bin/sh oddjob-mkhomedir-0.29-2.fc9.x86_64 requires /bin/sh ode-0.9-4.fc9.i386 requires /sbin/ldconfig ode-0.9-4.fc9.x86_64 requires /sbin/ldconfig ode-devel-0.9-4.fc9.i386 requires /bin/sh ode-devel-0.9-4.fc9.x86_64 requires /bin/sh offlineimap-5.99.7-1.fc9.noarch requires /usr/bin/python ogdi-3.2.0-0.8.beta1.fc9.i386 requires /sbin/ldconfig ogdi-3.2.0-0.8.beta1.fc9.x86_64 requires /sbin/ldconfig ogdi-devel-3.2.0-0.8.beta1.fc9.i386 requires /bin/sh ogdi-devel-3.2.0-0.8.beta1.fc9.x86_64 requires /bin/sh oggconvert-0.3.0-14.fc9.noarch requires /usr/bin/python ogre-1.4.8-1.fc10.i386 requires /sbin/ldconfig ogre-1.4.8-1.fc10.x86_64 requires /sbin/ldconfig ogre-samples-1.4.8-1.fc10.x86_64 requires /bin/bash oidentd-2.0.8-5.fc9.x86_64 requires /bin/sh oidentd-2.0.8-5.fc9.x86_64 requires /sbin/chkconfig oidentd-2.0.8-5.fc9.x86_64 requires /bin/sh oidentd-2.0.8-5.fc9.x86_64 requires /sbin/service ois-1.0-4.fc9.i386 requires /sbin/ldconfig ois-1.0-4.fc9.x86_64 requires /sbin/ldconfig oki4linux-2.1gst-3.fc9.x86_64 requires /bin/sh oki4linux-2.1gst-3.fc9.x86_64 requires /usr/bin/perl oki4linux-2.1gst-3.fc9.x86_64 requires /sbin/chkconfig oki4linux-2.1gst-3.fc9.x86_64 requires /bin/sh oniguruma-5.9.1-1.fc9.2.i386 requires /sbin/ldconfig oniguruma-5.9.1-1.fc9.2.x86_64 requires /sbin/ldconfig oniguruma-devel-5.9.1-1.fc9.2.i386 requires /bin/sh oniguruma-devel-5.9.1-1.fc9.2.x86_64 requires /bin/sh online-desktop-0.2.28-1.fc10.x86_64 requires /bin/sh online-desktop-0.2.28-1.fc10.x86_64 requires /usr/bin/env online-desktop-0.2.28-1.fc10.x86_64 requires /usr/bin/python online-desktop-0.2.28-1.fc10.x86_64 requires /bin/sh online-desktop-flickr-0.2.28-1.fc10.x86_64 requires /bin/sh online-desktop-gmail-0.2.28-1.fc10.x86_64 requires /bin/sh online-desktop-google-calendar-0.2.28-1.fc10.x86_64 requires /bin/sh online-desktop-google-docs-0.2.28-1.fc10.x86_64 requires /bin/sh online-desktop-google-reader-0.2.28-1.fc10.x86_64 requires /bin/sh ooo2txt-0.0.6-3.fc9.noarch requires /usr/bin/perl oooqs2-1.0-3.fc6.x86_64 requires /bin/sh oorexx-devel-3.2.0-4.fc9.i386 requires /bin/sh oorexx-libs-3.2.0-4.fc9.i386 requires /sbin/ldconfig opal-2.2.11-4.fc10.i386 requires /sbin/ldconfig opal-2.2.11-4.fc10.x86_64 requires /sbin/ldconfig openais-0.83-2.fc10.i386 requires /bin/sh openais-0.83-2.fc10.i386 requires /usr/sbin/useradd openais-0.83-2.fc10.i386 requires /bin/sh openais-0.83-2.fc10.i386 requires /sbin/chkconfig openais-0.83-2.fc10.x86_64 requires /bin/sh openais-0.83-2.fc10.x86_64 requires /usr/sbin/useradd openais-0.83-2.fc10.x86_64 requires /bin/sh openais-0.83-2.fc10.x86_64 requires /sbin/chkconfig openal-0.0.9-0.15.20060204cvs.fc9.i386 requires /sbin/ldconfig openal-0.0.9-0.15.20060204cvs.fc9.x86_64 requires /sbin/ldconfig openal-devel-0.0.9-0.15.20060204cvs.fc9.i386 requires /bin/sh openal-devel-0.0.9-0.15.20060204cvs.fc9.x86_64 requires /bin/sh openarena-0.7.6-1.fc10.noarch requires /bin/bash openbabel-2.2.0-0.3.b4.fc10.i386 requires /sbin/ldconfig openbabel-2.2.0-0.3.b4.fc10.x86_64 requires /sbin/ldconfig openbox-3.4.7.2-1.fc10.x86_64 requires /usr/bin/env openbox-3.4.7.2-1.fc10.x86_64 requires /bin/sh openbox-libs-3.4.7.2-1.fc10.i386 requires /sbin/ldconfig openbox-libs-3.4.7.2-1.fc10.x86_64 requires /sbin/ldconfig opencdk-0.6.6-1.fc9.i386 requires /sbin/ldconfig opencdk-0.6.6-1.fc9.x86_64 requires /sbin/ldconfig opencdk-devel-0.6.6-1.fc9.i386 requires /bin/sh opencdk-devel-0.6.6-1.fc9.x86_64 requires /bin/sh openct-0.6.14-4.fc9.i386 requires /bin/sh openct-0.6.14-4.fc9.i386 requires /sbin/ldconfig openct-0.6.14-4.fc9.i386 requires /usr/lib/ctapi openct-0.6.14-4.fc9.i386 requires /bin/sh openct-0.6.14-4.fc9.i386 requires /sbin/chkconfig openct-0.6.14-4.fc9.x86_64 requires /bin/sh openct-0.6.14-4.fc9.x86_64 requires /sbin/ldconfig openct-0.6.14-4.fc9.x86_64 requires /bin/sh openct-0.6.14-4.fc9.x86_64 requires /usr/lib64/ctapi openct-0.6.14-4.fc9.x86_64 requires /sbin/chkconfig opencv-1.0.0-8.fc10.i386 requires /sbin/ldconfig opencv-1.0.0-8.fc10.x86_64 requires /sbin/ldconfig opencv-python-1.0.0-8.fc10.x86_64 requires /usr/bin/env opencv-python-1.0.0-8.fc10.x86_64 requires /usr/bin/python opencv-python-1.0.0-8.fc10.x86_64 requires /sbin/ldconfig opengl-games-utils-0.1-5.fc9.noarch requires /bin/bash opengrok-0.6-9.hg275.fc9.noarch requires /bin/sh openhpi-2.10.2-1.fc9.x86_64 requires /bin/sh openhpi-2.10.2-1.fc9.x86_64 requires /sbin/service openhpi-2.10.2-1.fc9.x86_64 requires /sbin/chkconfig openhpi-2.10.2-1.fc9.x86_64 requires /bin/bash openhpi-2.10.2-1.fc9.x86_64 requires /bin/sh openhpi-libs-2.10.2-1.fc9.i386 requires /sbin/ldconfig openhpi-libs-2.10.2-1.fc9.x86_64 requires /sbin/ldconfig openhpi-subagent-2.3.4-2.fc10.x86_64 requires /bin/sh openhpi-subagent-2.3.4-2.fc10.x86_64 requires /sbin/service openhpi-subagent-2.3.4-2.fc10.x86_64 requires /sbin/chkconfig openhpi-subagent-2.3.4-2.fc10.x86_64 requires /bin/sh openjade-1.3.2-31.fc9.i386 requires /bin/sh openjade-1.3.2-31.fc9.i386 requires /sbin/ldconfig openjade-1.3.2-31.fc9.x86_64 requires /bin/sh openjade-1.3.2-31.fc9.x86_64 requires /sbin/ldconfig openjpeg-libs-1.3-2.fc9.i386 requires /sbin/ldconfig openjpeg-libs-1.3-2.fc9.x86_64 requires /sbin/ldconfig openldap-2.4.9-4.fc10.i386 requires /sbin/ldconfig openldap-2.4.9-4.fc10.x86_64 requires /sbin/ldconfig openldap-devel-2.4.9-4.fc10.i386 requires /sbin/ldconfig openldap-devel-2.4.9-4.fc10.x86_64 requires /sbin/ldconfig openldap-servers-2.4.9-4.fc10.x86_64 requires /sbin/runuser openldap-servers-2.4.9-4.fc10.x86_64 requires /bin/sh openldap-servers-2.4.9-4.fc10.x86_64 requires /sbin/chkconfig openldap-servers-2.4.9-4.fc10.x86_64 requires /usr/sbin/useradd openldap-servers-2.4.9-4.fc10.x86_64 requires /bin/bash openlierox-0.57-0.9.beta5.fc9.x86_64 requires /bin/sh openlierox-0.57-0.9.beta5.fc9.x86_64 requires /bin/bash openmpi-1.2.4-2.fc9.x86_64 requires /bin/sh openmpi-1.2.4-2.fc9.x86_64 requires /sbin/ldconfig openmpi-1.2.4-2.fc9.x86_64 requires /usr/sbin/alternatives openmpi-devel-1.2.4-2.fc9.i386 requires /bin/sh openmpi-devel-1.2.4-2.fc9.i386 requires /sbin/ldconfig openmpi-devel-1.2.4-2.fc9.i386 requires /usr/sbin/alternatives openmpi-devel-1.2.4-2.fc9.x86_64 requires /bin/sh openmpi-devel-1.2.4-2.fc9.x86_64 requires /sbin/ldconfig openmpi-devel-1.2.4-2.fc9.x86_64 requires /usr/sbin/alternatives openmpi-libs-1.2.4-2.fc9.i386 requires /bin/sh openmpi-libs-1.2.4-2.fc9.i386 requires /sbin/ldconfig openmpi-libs-1.2.4-2.fc9.i386 requires /usr/sbin/alternatives openmpi-libs-1.2.4-2.fc9.x86_64 requires /bin/sh openmpi-libs-1.2.4-2.fc9.x86_64 requires /sbin/ldconfig openmpi-libs-1.2.4-2.fc9.x86_64 requires /usr/sbin/alternatives openmsx-0.6.3-3.fc9.x86_64 requires /bin/sh openmsx-0.6.3-3.fc9.x86_64 requires /usr/bin/env openobex-1.3-11.fc9.i386 requires /sbin/ldconfig openobex-1.3-11.fc9.x86_64 requires /sbin/ldconfig 1:openoffice.org-base-3.0.0-0.0.12.1.fc10.x86_64 requires /bin/sh 1:openoffice.org-base-3.0.0-0.0.12.1.fc10.x86_64 requires /bin/sh 1:openoffice.org-brand-3.0.0-0.0.12.1.fc10.x86_64 requires /bin/sh 1:openoffice.org-brand-3.0.0-0.0.12.1.fc10.x86_64 requires /bin/sh 1:openoffice.org-calc-3.0.0-0.0.12.1.fc10.x86_64 requires /bin/sh 1:openoffice.org-calc-3.0.0-0.0.12.1.fc10.x86_64 requires /bin/sh 1:openoffice.org-core-3.0.0-0.0.12.1.fc10.x86_64 requires /bin/sh 1:openoffice.org-core-3.0.0-0.0.12.1.fc10.x86_64 requires /bin/sh 1:openoffice.org-devel-3.0.0-0.0.12.1.fc10.i386 requires /usr/bin/perl 1:openoffice.org-devel-3.0.0-0.0.12.1.fc10.i386 requires /usr/bin/python 1:openoffice.org-devel-3.0.0-0.0.12.1.fc10.i386 requires /bin/bash 1:openoffice.org-devel-3.0.0-0.0.12.1.fc10.i386 requires /bin/sh 1:openoffice.org-devel-3.0.0-0.0.12.1.fc10.x86_64 requires /usr/bin/perl 1:openoffice.org-devel-3.0.0-0.0.12.1.fc10.x86_64 requires /usr/bin/python 1:openoffice.org-devel-3.0.0-0.0.12.1.fc10.x86_64 requires /bin/bash 1:openoffice.org-devel-3.0.0-0.0.12.1.fc10.x86_64 requires /bin/sh 1:openoffice.org-draw-3.0.0-0.0.12.1.fc10.x86_64 requires /bin/sh 1:openoffice.org-draw-3.0.0-0.0.12.1.fc10.x86_64 requires /bin/sh openoffice.org-extendedPDF-1.4-4.fc9.noarch requires /bin/sh 1:openoffice.org-impress-3.0.0-0.0.12.1.fc10.x86_64 requires /bin/sh 1:openoffice.org-impress-3.0.0-0.0.12.1.fc10.x86_64 requires /bin/sh 1:openoffice.org-math-3.0.0-0.0.12.1.fc10.x86_64 requires /bin/sh 1:openoffice.org-math-3.0.0-0.0.12.1.fc10.x86_64 requires /bin/sh openoffice.org-ooolatex-4.0.0-0.5.beta2.fc9.noarch requires /bin/sh openoffice.org-ooolatex-4.0.0-0.5.beta2.fc9.noarch requires /usr/bin/dvips openoffice.org-ooolatex-4.0.0-0.5.beta2.fc9.noarch requires /usr/bin/latex 1:openoffice.org-presentation-minimizer-3.0.0-0.0.12.1.fc10.x86_64 requires /bin/sh 1:openoffice.org-presentation-minimizer-3.0.0-0.0.12.1.fc10.x86_64 requires openoffice.org-base-impress = 1:3.0.0-0.0.12.1.fc10 1:openoffice.org-presenter-screen-3.0.0-0.0.12.1.fc10.x86_64 requires /bin/sh 1:openoffice.org-presenter-screen-3.0.0-0.0.12.1.fc10.x86_64 requires openoffice.org-base-impress = 1:3.0.0-0.0.12.1.fc10 1:openoffice.org-report-builder-3.0.0-0.0.12.1.fc10.x86_64 requires /bin/sh 1:openoffice.org-sdk-3.0.0-0.0.12.1.fc10.x86_64 requires /bin/csh 1:openoffice.org-sdk-3.0.0-0.0.12.1.fc10.x86_64 requires /bin/sh 1:openoffice.org-ure-3.0.0-0.0.12.1.fc10.x86_64 requires /bin/sh openoffice.org-voikko-2.2-4.fc9.x86_64 requires /bin/sh 1:openoffice.org-writer-3.0.0-0.0.12.1.fc10.x86_64 requires /bin/sh 1:openoffice.org-writer-3.0.0-0.0.12.1.fc10.x86_64 requires /bin/sh openoffice.org-writer2latex-0.5-2.fc9.x86_64 requires /bin/sh opensc-0.11.4-4.fc9.i386 requires /sbin/ldconfig opensc-0.11.4-4.fc9.x86_64 requires /sbin/ldconfig opensc-devel-0.11.4-4.fc9.i386 requires /bin/sh opensc-devel-0.11.4-4.fc9.x86_64 requires /bin/sh openser-1.3.2-2.fc10.x86_64 requires /bin/sh openser-1.3.2-2.fc10.x86_64 requires /bin/bash openslp-1.2.1-9.fc9.i386 requires /sbin/ldconfig openslp-1.2.1-9.fc9.x86_64 requires /sbin/ldconfig openslp-server-1.2.1-9.fc9.x86_64 requires /bin/sh openslp-server-1.2.1-9.fc9.x86_64 requires /bin/bash openslp-server-1.2.1-9.fc9.x86_64 requires /sbin/service opensp-1.5.2-7.fc9.i386 requires /sbin/ldconfig opensp-1.5.2-7.fc9.x86_64 requires /sbin/ldconfig openssh-5.0p1-1.fc9.x86_64 requires /sbin/nologin openssh-clients-5.0p1-1.fc9.x86_64 requires /bin/sh openssh-server-5.0p1-1.fc9.x86_64 requires /bin/sh openssh-server-5.0p1-1.fc9.x86_64 requires /lib64/security/pam_loginuid.so openssh-server-5.0p1-1.fc9.x86_64 requires /etc/pam.d/system-auth openssh-server-5.0p1-1.fc9.x86_64 requires /usr/sbin/useradd openssh-server-5.0p1-1.fc9.x86_64 requires /sbin/service openssh-server-5.0p1-1.fc9.x86_64 requires /bin/bash openssh-server-5.0p1-1.fc9.x86_64 requires /bin/sh openssl-0.9.8g-6.fc9.i386 requires /sbin/ldconfig openssl-0.9.8g-6.fc9.i386 requires /bin/sh openssl-0.9.8g-6.fc9.i686 requires /sbin/ldconfig openssl-0.9.8g-6.fc9.i686 requires /bin/sh openssl-0.9.8g-6.fc9.x86_64 requires /sbin/ldconfig openssl-0.9.8g-6.fc9.x86_64 requires /bin/sh openssl-perl-0.9.8g-6.fc9.x86_64 requires /usr/bin/perl openswan-2.6.09-2.fc9.x86_64 requires /bin/sh openswan-2.6.09-2.fc9.x86_64 requires /sbin/service openswan-2.6.09-2.fc9.x86_64 requires /bin/sh openswan-2.6.09-2.fc9.x86_64 requires /usr/bin/perl openswan-2.6.09-2.fc9.x86_64 requires /sbin/chkconfig openvpn-2.1-0.25.rc7.fc9.x86_64 requires /bin/sh openvpn-2.1-0.25.rc7.fc9.x86_64 requires /usr/sbin/useradd openvpn-2.1-0.25.rc7.fc9.x86_64 requires /sbin/service openvpn-2.1-0.25.rc7.fc9.x86_64 requires /bin/bash openvpn-2.1-0.25.rc7.fc9.x86_64 requires /bin/sh openvpn-2.1-0.25.rc7.fc9.x86_64 requires /sbin/chkconfig openvrml-0.17.5-5.fc9.i386 requires /sbin/ldconfig openvrml-0.17.5-5.fc9.x86_64 requires /sbin/ldconfig openvrml-gl-0.17.5-5.fc9.i386 requires /sbin/ldconfig openvrml-gl-0.17.5-5.fc9.x86_64 requires /sbin/ldconfig openvrml-xembed-0.17.5-5.fc9.x86_64 requires /bin/sh openvrml-xembed-0.17.5-5.fc9.x86_64 requires /sbin/install-info oprofile-0.9.3-17.fc9.x86_64 requires /bin/sh opyum-0.0.3-1.fc9.noarch requires /bin/sh opyum-0.0.3-1.fc9.noarch requires /usr/bin/python orage-4.4.2-3.fc9.x86_64 requires /bin/sh orange-0.3-7.cvs20051118.fc9.i386 requires /sbin/ldconfig orange-0.3-7.cvs20051118.fc9.x86_64 requires /sbin/ldconfig orca-2.23.2-1.fc10.x86_64 requires /bin/sh orca-2.23.2-1.fc10.x86_64 requires /bin/bash ortp-0.14.2-0.20080211.2.fc9.i386 requires /sbin/ldconfig ortp-0.14.2-0.20080211.2.fc9.x86_64 requires /sbin/ldconfig 1:osgal-0.6.1-4.fc10.i386 requires /sbin/ldconfig 1:osgal-0.6.1-4.fc10.x86_64 requires /sbin/ldconfig osgcal-0.1.46-6.fc10.i386 requires /sbin/ldconfig osgcal-0.1.46-6.fc10.x86_64 requires /sbin/ldconfig ots-libs-0.5.0-1.fc9.i386 requires /sbin/ldconfig ots-libs-0.5.0-1.fc9.x86_64 requires /sbin/ldconfig overgod-1.0-7.fc9.x86_64 requires /bin/sh oxine-0.7.1-1.fc10.x86_64 requires /bin/sh oxygen-icon-theme-4.0.72-2.fc10.noarch requires /bin/sh oxygen-icon-theme-scalable-4.0.72-2.fc10.noarch requires /bin/sh oyranos-devel-0.1.7-11.fc9.i386 requires /bin/sh oyranos-devel-0.1.7-11.fc9.x86_64 requires /bin/sh oyranos-libs-0.1.7-11.fc9.i386 requires /sbin/ldconfig oyranos-libs-0.1.7-11.fc9.x86_64 requires /sbin/ldconfig p0f-2.0.8-4.fc9.x86_64 requires /bin/sh p0rn-comfort-0.0.4-5.fc9.noarch requires /bin/sh p0rn-comfort-0.0.4-5.fc9.noarch requires /usr/bin/perl p0rn-comfort-0.0.4-5.fc9.noarch requires /bin/bash p7zip-4.51-4.fc9.x86_64 requires /bin/sh p7zip-plugins-4.51-4.fc9.x86_64 requires /bin/sh pAgenda-3.2-2.fc10.noarch requires /bin/sh pAgenda-3.2-2.fc10.noarch requires /usr/bin/env pachi-1.0-5.fc9.x86_64 requires /bin/sh pakchois-0.4-1.i386 requires /sbin/ldconfig pakchois-0.4-1.x86_64 requires /sbin/ldconfig paktype-fonts-2.0-2.fc8.noarch requires /bin/sh pam-1.0.1-2.fc10.i386 requires /bin/sh pam-1.0.1-2.fc10.i386 requires /sbin/ldconfig pam-1.0.1-2.fc10.i386 requires /bin/sh pam-1.0.1-2.fc10.x86_64 requires /bin/sh pam-1.0.1-2.fc10.x86_64 requires /sbin/ldconfig pam-1.0.1-2.fc10.x86_64 requires /bin/sh pam_mount-0.32-3.fc9.i386 requires /bin/sh pam_mount-0.32-3.fc9.i386 requires /bin/bash pam_mount-0.32-3.fc9.i386 requires /bin/sh pam_mount-0.32-3.fc9.i386 requires /usr/bin/perl pam_mount-0.32-3.fc9.x86_64 requires /bin/sh pam_mount-0.32-3.fc9.x86_64 requires /bin/bash pam_mount-0.32-3.fc9.x86_64 requires /bin/sh pam_mount-0.32-3.fc9.x86_64 requires /usr/bin/perl pango-1.21.1-1.fc10.i386 requires /bin/sh pango-1.21.1-1.fc10.x86_64 requires /bin/sh papyrus-0.7.1-3.fc9.i386 requires /sbin/ldconfig papyrus-0.7.1-3.fc9.x86_64 requires /sbin/ldconfig paraview-3.2.1-6.fc9.i386 requires /usr/bin/update-desktop-database paraview-3.2.1-6.fc9.i386 requires /bin/sh paraview-3.2.1-6.fc9.x86_64 requires /usr/bin/update-desktop-database paraview-3.2.1-6.fc9.x86_64 requires /bin/sh paraview-data-3.2.1-6.fc9.x86_64 requires /bin/sh paraview-data-3.2.1-6.fc9.x86_64 requires /usr/bin/update-mime-database paraview-mpi-3.2.1-6.fc9.i386 requires /usr/bin/update-desktop-database paraview-mpi-3.2.1-6.fc9.i386 requires /bin/sh paraview-mpi-3.2.1-6.fc9.x86_64 requires /usr/bin/update-desktop-database paraview-mpi-3.2.1-6.fc9.x86_64 requires /bin/sh pards-0.4-6.fc9.i386 requires /sbin/ldconfig pards-0.4-6.fc9.x86_64 requires /sbin/ldconfig pari-2.3.3-1.fc9.i386 requires /sbin/ldconfig pari-2.3.3-1.fc9.x86_64 requires /sbin/ldconfig pari-gp-2.3.3-1.fc9.x86_64 requires /usr/bin/perl pari-gp-2.3.3-1.fc9.x86_64 requires /bin/sh parted-1.8.8-5.fc9.i386 requires /bin/sh parted-1.8.8-5.fc9.i386 requires /sbin/install-info parted-1.8.8-5.fc9.i386 requires /sbin/ldconfig parted-1.8.8-5.fc9.x86_64 requires /bin/sh parted-1.8.8-5.fc9.x86_64 requires /sbin/install-info parted-1.8.8-5.fc9.x86_64 requires /sbin/ldconfig passivetex-1.25-8.fc9.noarch requires /bin/sh passivetex-1.25-8.fc9.noarch requires /bin/sh passwd-0.75-2.fc9.x86_64 requires /etc/pam.d/system-auth patchutils-0.2.31-5.fc9.x86_64 requires /usr/bin/perl patchutils-0.2.31-5.fc9.x86_64 requires /bin/bash patchutils-0.2.31-5.fc9.x86_64 requires /bin/sh patchy-2006-29.fc9.x86_64 requires /bin/sh patchy-g77-2006-29.fc9.x86_64 requires /bin/sh patchy-gfortran-2006-29.fc9.x86_64 requires /bin/sh paw-2006-29.fc9.x86_64 requires /bin/sh paw-2006-29.fc9.x86_64 requires /bin/sh paw-g77-2006-29.fc9.x86_64 requires /bin/sh paw-g77-2006-29.fc9.x86_64 requires /bin/sh paw-gfortran-2006-29.fc9.x86_64 requires /bin/sh paw-gfortran-2006-29.fc9.x86_64 requires /bin/sh pbstop-4.16-3.fc9.x86_64 requires /usr/bin/perl pcapdiff-0.1-3.fc9.noarch requires /usr/bin/env pcb-0.20080202-2.fc9.x86_64 requires /bin/sh pcb-0.20080202-2.fc9.x86_64 requires /usr/bin/tclsh pcb-0.20080202-2.fc9.x86_64 requires /sbin/install-info pcb-0.20080202-2.fc9.x86_64 requires /usr/bin/wish pcb-0.20080202-2.fc9.x86_64 requires /usr/bin/perl pcb-0.20080202-2.fc9.x86_64 requires /bin/sh pciutils-2.2.10-1.fc9.x86_64 requires /bin/sh pcmanfm-0.4.1.1-1.fc10.x86_64 requires /bin/sh pcmanx-gtk2-0.3.5-9.336svn.fc7.i386 requires /sbin/ldconfig pcmanx-gtk2-0.3.5-9.336svn.fc7.x86_64 requires /sbin/ldconfig pcre-7.3-3.fc9.i386 requires /sbin/ldconfig pcre-7.3-3.fc9.x86_64 requires /sbin/ldconfig pcre-devel-7.3-3.fc9.i386 requires /bin/sh pcre-devel-7.3-3.fc9.x86_64 requires /bin/sh pcsc-lite-1.4.4-3.fc9.x86_64 requires /bin/sh pcsc-lite-1.4.4-3.fc9.x86_64 requires /sbin/chkconfig pcsc-lite-1.4.4-3.fc9.x86_64 requires /bin/sh pcsc-lite-libs-1.4.4-3.fc9.i386 requires /sbin/ldconfig pcsc-lite-libs-1.4.4-3.fc9.x86_64 requires /sbin/ldconfig pcsc-lite-openct-0.6.14-4.fc9.x86_64 requires /bin/sh pcsc-tools-1.4.12-1.fc9.x86_64 requires /usr/bin/env pdfedit-0.3.2-4.fc9.x86_64 requires /bin/sh pdfjam-1.20-5.fc6.noarch requires /bin/sh pdns-2.9.21-4.fc9.x86_64 requires /bin/sh pdns-2.9.21-4.fc9.x86_64 requires /usr/sbin/useradd pdns-2.9.21-4.fc9.x86_64 requires /sbin/service pdns-2.9.21-4.fc9.x86_64 requires /bin/sh pdns-2.9.21-4.fc9.x86_64 requires /sbin/chkconfig pdns-recursor-3.1.6-1.fc10.x86_64 requires /bin/sh pdns-recursor-3.1.6-1.fc10.x86_64 requires /sbin/service pdns-recursor-3.1.6-1.fc10.x86_64 requires /bin/bash pdns-recursor-3.1.6-1.fc10.x86_64 requires /sbin/chkconfig pdsh-2.11-6.fc9.x86_64 requires /usr/bin/perl pekwm-0.1.5-5.fc7.x86_64 requires /usr/bin/env pengupop-2.2.2-3.fc9.x86_64 requires /bin/sh 4:perl-5.10.0-20.fc9.i386 requires /usr/bin/perl 4:perl-5.10.0-20.fc9.x86_64 requires /usr/bin/perl perl-Ace-1.91-4.fc9.noarch requires /usr/bin/perl perl-Archive-Tar-1.37-20.fc9.x86_64 requires /usr/bin/perl perl-Archive-Zip-1.23-1.fc10.noarch requires /usr/bin/perl perl-BerkeleyDB-0.34-1.fc10.x86_64 requires /usr/bin/perl perl-CPAN-1.9205-20.fc9.x86_64 requires /usr/bin/perl perl-CPANPLUS-0.84-20.fc9.x86_64 requires /usr/bin/perl perl-Calendar-Simple-1.19-1.fc9.noarch requires /usr/bin/perl perl-Catalyst-Devel-1.03-2.fc9.noarch requires /usr/bin/perl perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Cflow-1.053-9.fc9.x86_64 requires /usr/bin/perl perl-Convert-Binary-C-0.70-5.fc9.x86_64 requires /usr/bin/perl perl-Crypt-Primes-0.50-5.fc9.noarch requires /usr/bin/perl perl-Crypt-Random-1.25-5.fc9.noarch requires /usr/bin/perl perl-Curses-1.20-3.fc9.x86_64 requires /usr/bin/perl perl-DBD-XBase-0.241-7.fc9.noarch requires /usr/bin/perl perl-DBI-1.601-4.fc9.x86_64 requires /usr/bin/perl perl-DBI-Dumper-2.01-6.fc9.x86_64 requires /usr/bin/perl perl-Data-HexDump-0.02-4.fc9.noarch requires /usr/bin/perl perl-Data-Stag-0.10-4.fc9.noarch requires /usr/bin/perl perl-Devel-Cover-0.63-3.fc9.x86_64 requires /usr/bin/perl perl-Device-SerialPort-1.04-3.fc9.x86_64 requires /usr/bin/perl 1:perl-Digest-SHA-5.45-20.fc9.x86_64 requires /usr/bin/perl perl-ExtUtils-MakeMaker-6.36-20.fc9.x86_64 requires /usr/bin/perl perl-ExtUtils-MakeMaker-Coverage-0.05-4.fc9.noarch requires /usr/bin/perl 1:perl-ExtUtils-ParseXS-2.18-20.fc9.x86_64 requires /usr/bin/perl perl-File-Find-Rule-0.30-6.fc9.noarch requires /usr/bin/perl perl-File-MimeInfo-0.15-2.fc9.noarch requires /usr/bin/perl perl-File-Which-0.05-4.fc9.noarch requires /usr/bin/perl perl-Finance-YahooQuote-0.21-3.fc9.noarch requires /usr/bin/perl perl-GD-2.35-7.fc9.x86_64 requires /usr/bin/perl perl-GDTextUtil-0.86-11.fc9.noarch requires /bin/sh perl-Gearman-Server-1.09-2.fc9.noarch requires /usr/bin/perl perl-Gtk2-Ex-PodViewer-0.17-4.fc9.noarch requires /usr/bin/perl 1:perl-HTML-Mason-1.39-2.fc9.noarch requires /usr/bin/perl 1:perl-HTML-Mason-1.39-2.fc9.noarch requires /etc/httpd/conf.d perl-HTML-Tidy-1.08-3.fc9.x86_64 requires /usr/bin/perl 1:perl-HTML-Tree-3.23-4.fc9.noarch requires /usr/bin/perl perl-HTTP-DAV-0.31-2.fc9.noarch requires /usr/bin/perl perl-IO-stringy-2.110-8.fc9.noarch requires /usr/bin/perl perl-Image-ExifTool-7.25-1.fc10.noarch requires /usr/bin/perl perl-Image-Info-1.27-3.fc9.noarch requires /usr/share/X11/rgb.txt perl-Image-Size-3.1-3.fc9.noarch requires /usr/bin/perl perl-Kwiki-0.39-3.fc9.noarch requires /usr/bin/perl perl-Lingua-EN-Inflect-1.89-7.fc9.noarch requires /usr/bin/perl perl-Locale-Maketext-Lexicon-0.66-2.fc9.noarch requires /usr/bin/perl perl-MARC-Record-2.0.0-2.fc9.noarch requires /usr/bin/perl perl-MIME-Lite-3.01-6.fc9.noarch requires /usr/bin/perl perl-MIME-tools-5.426-1.fc9.noarch requires /usr/bin/perl perl-Mail-Mbox-MessageParser-1.5000-5.fc9.noarch requires /usr/bin/diff 1:perl-Module-Build-0.2808-20.fc9.x86_64 requires /usr/bin/perl perl-Module-CPANTS-Analyse-0.75-3.fc9.noarch requires /usr/bin/perl perl-Module-CoreList-2.14-20.fc9.x86_64 requires /usr/bin/perl perl-Module-Info-0.31-3.fc9.noarch requires /usr/bin/perl perl-Module-ScanDeps-0.84-1.fc10.noarch requires /usr/bin/perl perl-Module-Signature-0.55-3.fc9.noarch requires /usr/bin/perl perl-Module-Starter-1.42-5.fc9.noarch requires /usr/bin/perl perl-MogileFS-Utils-2.12-2.fc9.noarch requires /usr/bin/perl perl-Net-DNS-SEC-0.14-3.fc9.noarch requires /usr/bin/perl perl-Net-IP-1.25-8.fc9.noarch requires /usr/bin/perl perl-Net-IPv4Addr-0.10-3.fc9.noarch requires /usr/bin/perl perl-Net-NBName-0.26-3.fc9.noarch requires /usr/bin/perl perl-Net-Pcap-0.14-4.fc9.x86_64 requires /usr/bin/perl perl-Net-SNMP-5.2.0-2.fc9.noarch requires /usr/bin/perl perl-Net-Server-0.97-2.fc9.noarch requires /usr/bin/perl perl-Net-eBay-0.46-2.fc9.noarch requires /usr/bin/perl perl-PDL-2.4.3-12.fc9.x86_64 requires /usr/bin/perl perl-PPI-HTML-1.07-3.fc9.noarch requires /usr/bin/perl perl-PPI-Tester-0.06-5.fc9.noarch requires /usr/bin/perl perl-Parse-Yapp-1.05-38.fc9.noarch requires /usr/bin/perl perl-Perl-Critic-1.080-3.fc9.noarch requires /usr/bin/perl perl-Perl-MinimumVersion-0.15-5.fc9.noarch requires /usr/bin/perl perl-Perl6-Bible-0.30-5.fc9.noarch requires /usr/bin/perl perl-Pod-Coverage-0.19-3.fc9.noarch requires /usr/bin/perl perl-Pod-POM-0.17-9.fc9.noarch requires /usr/bin/perl perl-Pod-Readme-0.090-3.fc9.noarch requires /usr/bin/perl perl-Pod-Spell-1.01-4.fc9.noarch requires /usr/bin/perl perl-Pod-Tests-0.18-6.fc9.noarch requires /usr/bin/perl perl-Proc-ProcessTable-0.42-1.fc9.x86_64 requires /usr/bin/perl perl-Pugs-Compiler-Rule-0.28-2.fc9.noarch requires /usr/bin/env perl-RPM-Specfile-1.51-5.fc9.noarch requires /usr/bin/perl perl-Razor-Agent-2.84-4.fc9.x86_64 requires /usr/bin/perl perl-SGMLSpm-1.03ii-18.fc9.noarch requires /usr/bin/perl perl-SOAP-Lite-0.68-6.fc9.noarch requires /bin/env perl-SOAP-Lite-0.68-6.fc9.noarch requires /usr/bin/env perl-SQL-Translator-0.09000-1.fc9.noarch requires /usr/bin/perl perl-SVK-2.0.2-3.fc9.noarch requires /usr/bin/perl perl-SVN-Mirror-0.73-3.fc9.noarch requires /usr/bin/perl perl-Spreadsheet-WriteExcel-2.20-2.fc9.noarch requires /usr/bin/perl perl-String-ShellQuote-1.03-5.fc9.noarch requires /usr/bin/perl perl-Taint-Runtime-0.03-5.fc9.x86_64 requires /usr/bin/perl perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Template-Toolkit-2.19-4.fc9.x86_64 requires /usr/bin/perl perl-Test-AutoBuild-1.2.2-3.fc9.noarch requires /usr/bin/mkisofs perl-Test-AutoBuild-1.2.2-3.fc9.noarch requires /usr/bin/createrepo perl-Test-AutoBuild-1.2.2-3.fc9.noarch requires /usr/bin/xsltproc perl-Test-AutoBuild-1.2.2-3.fc9.noarch requires /usr/bin/perl perl-Test-AutoBuild-1.2.2-3.fc9.noarch requires /bin/sh perl-Test-AutoBuild-1.2.2-3.fc9.noarch requires /usr/bin/yum-arch perl-Test-AutoBuild-1.2.2-3.fc9.noarch requires /usr/bin/genbasedir perl-Test-AutoBuild-account-1.2.2-3.fc9.noarch requires /bin/sh perl-Test-Harness-2.64-20.fc9.x86_64 requires /usr/bin/perl perl-Test-Inline-2.208-2.fc9.noarch requires /usr/bin/perl perl-Test-Unit-0.25-4.fc9.noarch requires /usr/bin/perl perl-Text-RecordParser-1.2.1-4.fc9.noarch requires /usr/bin/perl perl-Text-Smart-1.0.2-1.fc10.noarch requires /usr/bin/perl perl-Tk-804.028-5.fc9.x86_64 requires /usr/bin/perl perl-Unicode-Map-0.112-14.fc9.x86_64 requires /usr/bin/perl perl-Unicode-Map8-0.12-17.fc9.x86_64 requires /usr/bin/perl perl-VCS-LibCVS-1.0002-3.fc9.noarch requires /usr/bin/perl perl-WWW-Mechanize-1.32-2.fc9.noarch requires /usr/bin/perl perl-WWW-Myspace-0.60-2.fc9.noarch requires /usr/bin/perl perl-WWW-Search-2.497-2.fc9.noarch requires /usr/bin/perl perl-Wx-0.81-1.fc9.x86_64 requires /usr/bin/perl perl-XML-Entities-0.03-1.fc9.noarch requires /usr/bin/perl perl-XML-Handler-YAWriter-0.23-5.fc9.noarch requires /usr/bin/perl 1:perl-XML-LibXML-1.65-5.fc9.x86_64 requires /bin/sh 1:perl-XML-LibXML-1.65-5.fc9.x86_64 requires /bin/sh perl-XML-SAX-0.16-5.fc9.noarch requires /bin/sh perl-XML-Tidy-1.2.54HJnFa-4.fc9.noarch requires /usr/bin/perl perl-XML-Twig-3.32-1.fc9.noarch requires /usr/bin/perl perl-XML-XPath-1.13-6.fc9.noarch requires /usr/bin/perl perl-XML-XQL-0.68-6.fc9.noarch requires /usr/bin/perl perl-YAML-0.66-3.fc9.noarch requires /usr/bin/perl perl-bioperl-1.5.2_102-12.fc9.noarch requires /usr/bin/perl perl-bioperl-run-1.5.2_100-3.fc9.noarch requires /usr/bin/perl 4:perl-devel-5.10.0-20.fc9.i386 requires /usr/bin/perl 4:perl-devel-5.10.0-20.fc9.x86_64 requires /usr/bin/perl 4:perl-libs-5.10.0-20.fc9.i386 requires /sbin/ldconfig 4:perl-libs-5.10.0-20.fc9.x86_64 requires /sbin/ldconfig perl-libwww-perl-5.808-7.fc9.noarch requires /usr/bin/perl perl-pmtools-1.10-1.fc9.noarch requires /usr/bin/perl perltidy-20071205-3.fc9.noarch requires /usr/bin/perl pessulus-2.16.2-2.fc7.noarch requires /usr/bin/env pessulus-2.16.2-2.fc7.noarch requires /usr/bin/python petitboot-0.0.1-7.fc8.x86_64 requires /bin/sh pexpect-2.3-1.fc9.noarch requires /usr/bin/env pfqueue-0.5.6-7.fc9.i386 requires /sbin/ldconfig pfqueue-0.5.6-7.fc9.x86_64 requires /sbin/ldconfig pgfouine-1.0-2.fc8.noarch requires /usr/bin/php pgp-tools-0.4.12-2.fc9.noarch requires /usr/bin/perl pgp-tools-0.4.12-2.fc9.noarch requires /bin/sh pharosc-8.3-1.fc8.noarch requires /bin/bash pharosc-alliance-8.3-1.fc8.noarch requires /bin/bash pharosc-alliance-devel-8.3-1.fc8.noarch requires /bin/bash pharosc-doc-8.3-1.fc8.noarch requires /bin/bash pharosc-magic-8.3-1.fc8.noarch requires /bin/bash pharosc-magic-devel-8.3-1.fc8.noarch requires /bin/bash pharosc-synopsys-8.3-1.fc8.noarch requires /bin/bash pharosc-xcircuit-8.3-1.fc8.noarch requires /bin/bash phasex-0.11.1-5.fc9.x86_64 requires /bin/sh photoml-0.25-1.fc9.noarch requires /usr/bin/perl photoml-0.25-1.fc9.noarch requires /bin/sh php-channel-phing-1.0.0-5.fc9.noarch requires /bin/sh php-channel-phing-1.0.0-5.fc9.noarch requires /usr/bin/pear php-channel-phpdb-1.0.0-4.fc8.noarch requires /bin/sh php-channel-phpdb-1.0.0-4.fc8.noarch requires /usr/bin/pear php-channel-phpunit-1.0-2.fc7.noarch requires /bin/sh php-channel-symfony-1.0.0-2.fc9.noarch requires /bin/sh php-channel-symfony-1.0.0-2.fc9.noarch requires /usr/bin/pear php-devel-5.2.5-7.fc9.i386 requires /bin/sh php-devel-5.2.5-7.fc9.x86_64 requires /bin/sh 1:php-eaccelerator-0.9.5.2-2.fc9.x86_64 requires /bin/sh php-embedded-5.2.5-7.fc9.i386 requires /sbin/ldconfig php-embedded-5.2.5-7.fc9.x86_64 requires /sbin/ldconfig php-magickwand-1.0.7-1.fc10.x86_64 requires libWand.so.10()(64bit) php-magickwand-1.0.7-1.fc10.x86_64 requires libMagick.so.10()(64bit) 1:php-pear-1.7.1-2.fc9.noarch requires /bin/sh php-pear-Auth-SASL-1.0.2-4.fc6.noarch requires /bin/sh php-pear-Auth-SASL-1.0.2-4.fc6.noarch requires /usr/bin/pear php-pear-Benchmark-1.2.7-1.fc8.noarch requires /usr/bin/pear php-pear-Benchmark-1.2.7-1.fc8.noarch requires /bin/sh php-pear-Cache-1.5.5-0.2.RC4.fc8.noarch requires /usr/bin/pear php-pear-Cache-1.5.5-0.2.RC4.fc8.noarch requires /bin/sh php-pear-Cache-Lite-1.7.3-1.fc10.noarch requires /bin/sh php-pear-Cache-Lite-1.7.3-1.fc10.noarch requires /usr/bin/pear php-pear-Console-Color-1.0.2-1.fc7.noarch requires /usr/bin/pear php-pear-Console-Color-1.0.2-1.fc7.noarch requires /bin/sh php-pear-Console-Getargs-1.3.4-1.fc8.1.noarch requires /usr/bin/pear php-pear-Console-Getargs-1.3.4-1.fc8.1.noarch requires /bin/sh php-pear-Console-Table-1.1.1-1.fc9.noarch requires /usr/bin/pear php-pear-Console-Table-1.1.1-1.fc9.noarch requires /bin/sh php-pear-Crypt-CHAP-1.0.1-1.fc7.noarch requires /usr/bin/pear php-pear-Crypt-CHAP-1.0.1-1.fc7.noarch requires /bin/sh php-pear-DB-1.7.13-1.fc8.noarch requires /bin/sh php-pear-DB-1.7.13-1.fc8.noarch requires /usr/bin/pear php-pear-DB-1.7.13-1.fc8.noarch requires /bin/sh php-pear-DB-DataObject-1.8.8-1.fc9.noarch requires /usr/bin/pear php-pear-DB-DataObject-1.8.8-1.fc9.noarch requires /bin/sh php-pear-DB-DataObject-1.8.8-1.fc9.noarch requires /usr/bin/php php-pear-DB-DataObject-FormBuilder-1.0.0-0.5.RC7.fc7.noarch requires /usr/bin/pear php-pear-DB-DataObject-FormBuilder-1.0.0-0.5.RC7.fc7.noarch requires /bin/sh php-pear-DB-DataObject-FormBuilder-1.0.0-0.5.RC7.fc7.noarch requires /usr/bin/php php-pear-DB-QueryTool-1.1.2-1.fc9.noarch requires /usr/bin/pear php-pear-DB-QueryTool-1.1.2-1.fc9.noarch requires /bin/sh php-pear-Date-1.4.7-2.fc7.noarch requires /usr/bin/pear php-pear-Date-1.4.7-2.fc7.noarch requires /bin/sh php-pear-Date-Holidays-0.17.4-1.fc9.noarch requires /usr/bin/pear php-pear-Date-Holidays-0.17.4-1.fc9.noarch requires /bin/sh php-pear-Date-Holidays-0.17.4-1.fc9.noarch requires /usr/bin/php php-pear-File-1.3.0-1.fc8.noarch requires /usr/bin/pear php-pear-File-1.3.0-1.fc8.noarch requires /bin/sh php-pear-File-Find-1.3.0-1.fc9.noarch requires /usr/bin/pear php-pear-File-Find-1.3.0-1.fc9.noarch requires /bin/sh php-pear-File-Passwd-1.1.6-2.fc7.noarch requires /usr/bin/pear php-pear-File-Passwd-1.1.6-2.fc7.noarch requires /bin/sh php-pear-File-SMBPasswd-1.0.2-1.fc7.noarch requires /usr/bin/pear php-pear-File-SMBPasswd-1.0.2-1.fc7.noarch requires /bin/sh php-pear-HTML-Common-1.2.4-1.fc8.noarch requires /usr/bin/pear php-pear-HTML-Common-1.2.4-1.fc8.noarch requires /bin/sh php-pear-HTML-QuickForm-3.2.10-1.fc9.noarch requires /usr/bin/pear php-pear-HTML-QuickForm-3.2.10-1.fc9.noarch requires /bin/sh php-pear-HTML-QuickForm-ElementGrid-0.1.1-1.fc7.noarch requires /usr/bin/pear php-pear-HTML-QuickForm-ElementGrid-0.1.1-1.fc7.noarch requires /bin/sh php-pear-HTML-QuickForm-advmultiselect-1.4.1-1.fc10.noarch requires /usr/bin/pear php-pear-HTML-QuickForm-advmultiselect-1.4.1-1.fc10.noarch requires /bin/sh php-pear-HTML-Table-1.8.2-1.fc9.noarch requires /usr/bin/pear php-pear-HTML-Table-1.8.2-1.fc9.noarch requires /bin/sh php-pear-HTTP-1.4.0-8.fc8.noarch requires /bin/sh php-pear-HTTP-1.4.0-8.fc8.noarch requires /usr/bin/pear php-pear-HTTP-Request-1.4.2-1.fc9.noarch requires /usr/bin/pear php-pear-HTTP-Request-1.4.2-1.fc9.noarch requires /bin/sh php-pear-HTTP-Upload-0.9.1-2.fc9.noarch requires /usr/bin/pear php-pear-HTTP-Upload-0.9.1-2.fc9.noarch requires /bin/sh php-pear-Image-Canvas-0.3.1-1.fc8.noarch requires /usr/bin/pear php-pear-Image-Canvas-0.3.1-1.fc8.noarch requires /bin/sh php-pear-Image-Color-1.0.2-3.fc7.noarch requires /usr/bin/pear php-pear-Image-Color-1.0.2-3.fc7.noarch requires /bin/sh php-pear-Image-Graph-0.7.2-2.fc7.noarch requires /usr/bin/pear php-pear-Image-Graph-0.7.2-2.fc7.noarch requires /bin/sh php-pear-Image-GraphViz-1.2.1-2.fc7.noarch requires /usr/bin/pear php-pear-Image-GraphViz-1.2.1-2.fc7.noarch requires /bin/sh php-pear-Log-1.10.1-1.fc10.noarch requires /bin/sh php-pear-Log-1.10.1-1.fc10.noarch requires /usr/bin/pear php-pear-MDB2-2.4.1-2.fc9.noarch requires /usr/bin/pear php-pear-MDB2-2.4.1-2.fc9.noarch requires /bin/sh php-pear-MDB2-Driver-mysql-1.4.1-3.fc9.noarch requires /usr/bin/pear php-pear-MDB2-Driver-mysql-1.4.1-3.fc9.noarch requires /bin/sh php-pear-MDB2-Driver-mysqli-1.4.1-3.fc9.noarch requires /usr/bin/pear php-pear-MDB2-Driver-mysqli-1.4.1-3.fc9.noarch requires /bin/sh php-pear-Mail-1.1.14-2.fc8.noarch requires /bin/sh php-pear-Mail-1.1.14-2.fc8.noarch requires /usr/bin/pear php-pear-Mail-Mime-1.5.2-3.fc9.noarch requires /usr/bin/pear php-pear-Mail-Mime-1.5.2-3.fc9.noarch requires /bin/sh php-pear-Mail-mimeDecode-1.5.0-3.fc9.noarch requires /usr/bin/pear php-pear-Mail-mimeDecode-1.5.0-3.fc9.noarch requires /bin/sh php-pear-Math-Stats-0.9.0-0.1.beta3.fc7.noarch requires /usr/bin/pear php-pear-Math-Stats-0.9.0-0.1.beta3.fc7.noarch requires /bin/sh php-pear-Net-Curl-1.2.3-2.fc6.noarch requires /usr/bin/pear php-pear-Net-Curl-1.2.3-2.fc6.noarch requires /bin/sh php-pear-Net-DIME-0.3-1.fc7.noarch requires /usr/bin/pear php-pear-Net-DIME-0.3-1.fc7.noarch requires /bin/sh php-pear-Net-FTP-1.3.4-1.fc9.noarch requires /usr/bin/pear php-pear-Net-FTP-1.3.4-1.fc9.noarch requires /bin/sh php-pear-Net-POP3-1.3.6-2.fc7.noarch requires /usr/bin/pear php-pear-Net-POP3-1.3.6-2.fc7.noarch requires /bin/sh php-pear-Net-Ping-2.4.3-1.fc9.noarch requires /usr/bin/pear php-pear-Net-Ping-2.4.3-1.fc9.noarch requires /bin/sh php-pear-Net-Ping-2.4.3-1.fc9.noarch requires /bin/ping php-pear-Net-SMTP-1.3.0-1.fc10.noarch requires /bin/sh php-pear-Net-SMTP-1.3.0-1.fc10.noarch requires /usr/bin/pear php-pear-Net-Sieve-1.1.5-2.fc7.noarch requires /usr/bin/pear php-pear-Net-Sieve-1.1.5-2.fc7.noarch requires /bin/sh php-pear-Net-Socket-1.0.8-1.fc7.noarch requires /usr/bin/pear php-pear-Net-Socket-1.0.8-1.fc7.noarch requires /bin/sh php-pear-Net-Traceroute-0.21.1-2.fc8.noarch requires /usr/bin/pear php-pear-Net-Traceroute-0.21.1-2.fc8.noarch requires /bin/sh php-pear-Net-URL-1.0.15-1.fc8.noarch requires /usr/bin/pear php-pear-Net-URL-1.0.15-1.fc8.noarch requires /bin/sh php-pear-Net-URL-Mapper-0.9.0-2.fc9.noarch requires /usr/bin/pear php-pear-Net-URL-Mapper-0.9.0-2.fc9.noarch requires /bin/sh php-pear-Net-UserAgent-Detect-2.4.0-1.fc8.noarch requires /usr/bin/pear php-pear-Net-UserAgent-Detect-2.4.0-1.fc8.noarch requires /bin/sh php-pear-Numbers-Roman-1.0.2-2.fc9.noarch requires /usr/bin/pear php-pear-Numbers-Roman-1.0.2-2.fc9.noarch requires /bin/sh php-pear-Numbers-Words-0.15.0-2.fc7.noarch requires /usr/bin/pear php-pear-Numbers-Words-0.15.0-2.fc7.noarch requires /bin/sh php-pear-PEAR-Command-Packaging-0.1.2-5.fc6.noarch requires /usr/bin/pear php-pear-PEAR-Command-Packaging-0.1.2-5.fc6.noarch requires /bin/sh php-pear-PHP-CodeSniffer-1.0.1-1.fc9.noarch requires /usr/bin/pear php-pear-PHP-CodeSniffer-1.0.1-1.fc9.noarch requires /bin/sh php-pear-PHP-Compat-1.5.0-1.fc6.noarch requires /usr/bin/pear php-pear-PHP-Compat-1.5.0-1.fc6.noarch requires /bin/sh php-pear-PHP-CompatInfo-1.7.0-1.fc10.noarch requires /usr/bin/pear php-pear-PHP-CompatInfo-1.7.0-1.fc10.noarch requires /bin/sh php-pear-PHP-CompatInfo-1.7.0-1.fc10.noarch requires /usr/bin/php php-pear-PHPUnit-3.2.15-1.fc9.noarch requires /usr/bin/pear php-pear-PHPUnit-3.2.15-1.fc9.noarch requires /bin/sh php-pear-PHPUnit-3.2.15-1.fc9.noarch requires /usr/bin/php php-pear-Pager-2.4.4-1.fc8.noarch requires /usr/bin/pear php-pear-Pager-2.4.4-1.fc8.noarch requires /bin/sh php-pear-Payment-Process-0.6.5-1.fc6.noarch requires /usr/bin/pear php-pear-Payment-Process-0.6.5-1.fc6.noarch requires /bin/sh php-pear-Phlickr-0.2.7-2.fc8.noarch requires /usr/bin/pear php-pear-Phlickr-0.2.7-2.fc8.noarch requires /bin/sh php-pear-PhpDocumentor-1.4.1-2.fc9.noarch requires /usr/bin/pear php-pear-PhpDocumentor-1.4.1-2.fc9.noarch requires /bin/sh php-pear-SOAP-0.11.0-1.fc8.noarch requires /usr/bin/pear php-pear-SOAP-0.11.0-1.fc8.noarch requires /bin/sh php-pear-Services-Weather-1.4.2-1.fc7.noarch requires /usr/bin/pear php-pear-Services-Weather-1.4.2-1.fc7.noarch requires /bin/sh php-pear-Services-Weather-1.4.2-1.fc7.noarch requires /usr/bin/php php-pear-Structures-DataGrid-0.9.0-2.fc9.noarch requires /usr/bin/pear php-pear-Structures-DataGrid-0.9.0-2.fc9.noarch requires /bin/sh php-pear-Structures-DataGrid-DataSource-Array-0.1.4-1.fc9.noarch requires /usr/bin/pear php-pear-Structures-DataGrid-DataSource-Array-0.1.4-1.fc9.noarch requires /bin/sh php-pear-Structures-DataGrid-DataSource-DataObject-0.2.1-1.fc9.noarch requires /usr/bin/pear php-pear-Structures-DataGrid-DataSource-DataObject-0.2.1-1.fc9.noarch requires /bin/sh php-pear-Structures-DataGrid-DataSource-MDB2-0.1.11-1.fc9.noarch requires /usr/bin/pear php-pear-Structures-DataGrid-DataSource-MDB2-0.1.11-1.fc9.noarch requires /bin/sh php-pear-Structures-DataGrid-DataSource-RSS-0.1.1-1.fc7.noarch requires /usr/bin/pear php-pear-Structures-DataGrid-DataSource-RSS-0.1.1-1.fc7.noarch requires /bin/sh php-pear-Structures-DataGrid-Renderer-Pager-0.1.3-1.fc9.noarch requires /usr/bin/pear php-pear-Structures-DataGrid-Renderer-Pager-0.1.3-1.fc9.noarch requires /bin/sh php-pear-Structures-DataGrid-Renderer-Smarty-0.1.4-1.fc9.noarch requires /usr/bin/pear php-pear-Structures-DataGrid-Renderer-Smarty-0.1.4-1.fc9.noarch requires /bin/sh php-pear-Validate-0.8.1-1.fc9.noarch requires /usr/bin/pear php-pear-Validate-0.8.1-1.fc9.noarch requires /bin/sh php-pear-Validate-Finance-CreditCard-0.5.2-1.fc6.noarch requires /usr/bin/pear php-pear-Validate-Finance-CreditCard-0.5.2-1.fc6.noarch requires /bin/sh php-pear-XML-Beautifier-1.1-2.fc7.noarch requires /usr/bin/pear php-pear-XML-Beautifier-1.1-2.fc7.noarch requires /bin/sh php-pear-XML-Parser-1.2.8-2.fc8.noarch requires /bin/sh php-pear-XML-Parser-1.2.8-2.fc8.noarch requires /usr/bin/pear php-pear-XML-RSS-0.9.10-3.fc7.noarch requires /usr/bin/pear php-pear-XML-RSS-0.9.10-3.fc7.noarch requires /bin/sh php-pear-XML-Serializer-0.18.0-3.fc7.noarch requires /usr/bin/pear php-pear-XML-Serializer-0.18.0-3.fc7.noarch requires /bin/sh php-pear-XML-Util-1.1.4-2.fc7.noarch requires /usr/bin/pear php-pear-XML-Util-1.1.4-2.fc7.noarch requires /bin/sh php-pear-creole-1.1.0-5.fc8.noarch requires /usr/bin/pear php-pear-creole-1.1.0-5.fc8.noarch requires /bin/sh php-pear-pake-1.1.4-3.fc9.noarch requires /bin/sh php-pear-pake-1.1.4-3.fc9.noarch requires /usr/bin/pear php-pear-pake-1.1.4-3.fc9.noarch requires /bin/sh php-pear-phing-2.3.0-1.fc9.noarch requires /bin/sh php-pear-phing-2.3.0-1.fc9.noarch requires /usr/bin/pear php-pear-phing-2.3.0-1.fc9.noarch requires /bin/sh php-pecl-mailparse-2.1.4-1.fc9.x86_64 requires /bin/sh php-pecl-mailparse-2.1.4-1.fc9.x86_64 requires /usr/bin/pecl php-pecl-memcache-2.2.3-1.fc9.x86_64 requires /bin/sh php-pecl-memcache-2.2.3-1.fc9.x86_64 requires /usr/bin/pecl php-pecl-phar-1.2.3-3.fc9.x86_64 requires /bin/sh php-pecl-phar-1.2.3-3.fc9.x86_64 requires /usr/bin/pecl php-pecl-phar-1.2.3-3.fc9.x86_64 requires /usr/bin/php php-pecl-radius-1.2.5-5.fc10.x86_64 requires /bin/sh php-pecl-radius-1.2.5-5.fc10.x86_64 requires /usr/bin/pecl php-pecl-xdebug-2.0.2-4.fc9.x86_64 requires /bin/sh php-pecl-xdebug-2.0.2-4.fc9.x86_64 requires /usr/bin/pecl phpMyAdmin-2.11.6-1.fc10.noarch requires /usr/bin/perl phpMyAdmin-2.11.6-1.fc10.noarch requires /bin/bash phpMyAdmin-2.11.6-1.fc10.noarch requires /bin/sh phpPgAdmin-4.2-1.fc9.noarch requires /bin/sh phpPgAdmin-4.2-1.fc9.noarch requires /usr/bin/awk phpPgAdmin-4.2-1.fc9.noarch requires /sbin/service phpPgAdmin-4.2-1.fc9.noarch requires /bin/bash phpPgAdmin-4.2-1.fc9.noarch requires /usr/bin/php phpTodo-0.8.1-0.8.beta.fc8.noarch requires /bin/sh phpcs-1.0.1-1.fc9.noarch requires /usr/bin/php phpdoc-1.4.1-2.fc9.noarch requires /usr/bin/php phpldapadmin-1.1.0.5-1.fc9.noarch requires /bin/sh phpwapmail-0.9.2-1.fc9.noarch requires /bin/sh physfs-1.0.1-8.fc9.i386 requires /sbin/ldconfig physfs-1.0.1-8.fc9.x86_64 requires /sbin/ldconfig pic2aa-0.2.1-3.fc9.x86_64 requires /bin/sh picard-0.9.0-6.fc9.x86_64 requires /usr/bin/python piccolo-1.04-3jpp.2.fc9.x86_64 requires /bin/sh pida-0.5.1-6.fc9.x86_64 requires /bin/sh pida-0.5.1-6.fc9.x86_64 requires /usr/bin/env pida-0.5.1-6.fc9.x86_64 requires /usr/bin/python pidgin-2.4.1-3.fc10.x86_64 requires /bin/sh pigment-0.3.5-1.fc9.i386 requires /sbin/ldconfig pigment-0.3.5-1.fc9.x86_64 requires /sbin/ldconfig piklab-0.15.0-1.fc9.x86_64 requires /bin/sh pikloops-0.2.5-3.fc9.x86_64 requires /bin/sh 2:pilot-link-0.12.3-13.fc9.i386 requires /usr/bin/env 2:pilot-link-0.12.3-13.fc9.i386 requires /sbin/ldconfig 2:pilot-link-0.12.3-13.fc9.i386 requires /usr/bin/perl 2:pilot-link-0.12.3-13.fc9.x86_64 requires /usr/bin/env 2:pilot-link-0.12.3-13.fc9.x86_64 requires /sbin/ldconfig 2:pilot-link-0.12.3-13.fc9.x86_64 requires /usr/bin/perl pils-2.1.3-1.fc9.i386 requires /sbin/ldconfig pils-2.1.3-1.fc9.x86_64 requires /sbin/ldconfig pinball-0.3.1-11.fc9.x86_64 requires /bin/sh pinentry-0.7.4-5.fc9.x86_64 requires /bin/sh pinentry-0.7.4-5.fc9.x86_64 requires /usr/sbin/update-alternatives pinentry-0.7.4-5.fc9.x86_64 requires /sbin/install-info pinentry-gtk-0.7.4-5.fc9.x86_64 requires /bin/sh pinentry-gtk-0.7.4-5.fc9.x86_64 requires /usr/sbin/update-alternatives pinentry-qt-0.7.4-5.fc9.x86_64 requires /bin/sh pinentry-qt-0.7.4-5.fc9.x86_64 requires /usr/sbin/update-alternatives pinfo-0.6.9-7.fc9.x86_64 requires /bin/sh pingus-0.7.2-3.fc9.x86_64 requires /bin/sh pingus-0.7.2-3.fc9.x86_64 requires /usr/bin/guile pinot-0.85-1.fc10.x86_64 requires /bin/sh pioneers-0.12.2-1.fc10.x86_64 requires /bin/sh pipenightdreams-0.10.0-8.fc9.x86_64 requires /bin/sh pipepanic-0.1.3-5.fc9.x86_64 requires /bin/sh pitivi-0.11.1-2.fc9.noarch requires /usr/bin/env pixman-0.10.0-1.fc9.i386 requires /sbin/ldconfig pixman-0.10.0-1.fc9.x86_64 requires /sbin/ldconfig pl-5.6.47-7.fc9.x86_64 requires /bin/bash plague-0.4.4.1-4.fc7.noarch requires /bin/sh plague-0.4.4.1-4.fc7.noarch requires /bin/bash plague-0.4.4.1-4.fc7.noarch requires /sbin/chkconfig plague-0.4.4.1-4.fc7.noarch requires /usr/bin/python plague-0.4.4.1-4.fc7.noarch requires /sbin/service plague-builder-0.4.4.1-4.fc7.noarch requires /bin/sh plague-builder-0.4.4.1-4.fc7.noarch requires /bin/bash plague-builder-0.4.4.1-4.fc7.noarch requires /sbin/chkconfig plague-builder-0.4.4.1-4.fc7.noarch requires /usr/sbin/useradd plague-builder-0.4.4.1-4.fc7.noarch requires /usr/bin/python plague-builder-0.4.4.1-4.fc7.noarch requires /sbin/service plague-client-0.4.4.1-4.fc7.noarch requires /usr/bin/python plague-utils-0.4.4.1-4.fc7.noarch requires /usr/bin/python planet-2.0-5.fc9.noarch requires /usr/bin/python planets-0.1.13-2.fc9.x86_64 requires /bin/sh planner-0.14.3-2.fc10.i386 requires /usr/bin/scrollkeeper-update planner-0.14.3-2.fc10.i386 requires /bin/sh planner-0.14.3-2.fc10.x86_64 requires /bin/sh planner-0.14.3-2.fc10.x86_64 requires /usr/bin/scrollkeeper-update plexus-ant-factory-1.0-0.2.a1.1jpp.6.fc9.x86_64 requires /bin/sh plexus-ant-factory-javadoc-1.0-0.2.a1.1jpp.6.fc9.x86_64 requires /bin/rm plexus-ant-factory-javadoc-1.0-0.2.a1.1jpp.6.fc9.x86_64 requires /bin/ls plexus-appserver-1.0-0.2.a5.2jpp.4.fc9.x86_64 requires /bin/sh plexus-archiver-1.0-0.2.a7.1jpp.1.fc9.x86_64 requires /bin/sh plexus-bsh-factory-1.0-0.2.a7s.1jpp.6.fc9.x86_64 requires /bin/sh plexus-cdc-1.0-0.2.a4.1jpp.4.fc9.x86_64 requires /bin/sh plexus-i18n-1.0-0.b6.5jpp.2.fc9.noarch requires /bin/sh plexus-maven-plugin-1.2-2jpp.3.fc9.x86_64 requires /bin/sh plexus-runtime-builder-1.0-0.2.a9.1jpp.3.fc9.x86_64 requires /bin/sh plexus-velocity-1.1.2-3jpp.1.fc9.x86_64 requires /bin/sh plexus-xmlrpc-1.0-0.2.b4.2jpp.7.fc9.x86_64 requires /bin/sh plib-1.8.5-1.fc10.i386 requires /sbin/ldconfig plib-1.8.5-1.fc10.x86_64 requires /sbin/ldconfig plotmm-0.1.2-6.fc9.i386 requires /sbin/ldconfig plotmm-0.1.2-6.fc9.x86_64 requires /sbin/ldconfig plotutils-2.5-5.fc9.i386 requires /bin/sh plotutils-2.5-5.fc9.i386 requires /sbin/install-info plotutils-2.5-5.fc9.i386 requires /sbin/ldconfig plotutils-2.5-5.fc9.x86_64 requires /bin/sh plotutils-2.5-5.fc9.x86_64 requires /sbin/install-info plotutils-2.5-5.fc9.x86_64 requires /sbin/ldconfig plplot-5.9.0-1.fc9.x86_64 requires /bin/sh plplot-5.9.0-1.fc9.x86_64 requires /usr/bin/env plplot-5.9.0-1.fc9.x86_64 requires /sbin/install-info plplot-5.9.0-1.fc9.x86_64 requires /sbin/ldconfig plplot-5.9.0-1.fc9.x86_64 requires /bin/bash plplot-5.9.0-1.fc9.x86_64 requires /bin/sh plplot-ada-5.9.0-1.fc9.i386 requires /sbin/ldconfig plplot-ada-5.9.0-1.fc9.x86_64 requires /sbin/ldconfig plplot-ada-devel-5.9.0-1.fc9.i386 requires /bin/bash plplot-ada-devel-5.9.0-1.fc9.x86_64 requires /bin/bash plplot-devel-5.9.0-1.fc9.i386 requires /bin/bash plplot-devel-5.9.0-1.fc9.x86_64 requires /bin/bash plplot-gnome-5.9.0-1.fc9.i386 requires /sbin/ldconfig plplot-gnome-5.9.0-1.fc9.x86_64 requires /sbin/ldconfig plplot-java-devel-5.9.0-1.fc9.i386 requires /bin/bash plplot-java-devel-5.9.0-1.fc9.x86_64 requires /bin/bash plplot-octave-5.9.0-1.fc9.x86_64 requires /sbin/ldconfig plplot-octave-5.9.0-1.fc9.x86_64 requires /bin/bash plplot-perl-5.9.0-1.fc9.x86_64 requires /bin/bash plplot-perl-5.9.0-1.fc9.x86_64 requires /usr/bin/env plplot-tk-5.9.0-1.fc9.i386 requires /sbin/ldconfig plplot-tk-5.9.0-1.fc9.x86_64 requires /sbin/ldconfig plplot-tk-devel-5.9.0-1.fc9.i386 requires /bin/sh plplot-tk-devel-5.9.0-1.fc9.x86_64 requires /bin/sh plt-scheme-372-1.fc9.x86_64 requires /bin/bash plt-scheme-372-1.fc9.x86_64 requires /bin/sh pm-utils-1.1.1-2.fc10.x86_64 requires /bin/sh pm-utils-1.1.1-2.fc10.x86_64 requires /bin/bash pm-utils-1.1.1-2.fc10.x86_64 requires /bin/sh pmd-3.6-1jpp.3.fc7.noarch requires /bin/bash pmount-0.9.17-2.fc9.x86_64 requires /bin/mount 1:pnm2ppa-1.04-15.fc9.x86_64 requires /bin/sh po4a-0.32-4.fc8.noarch requires /usr/bin/perl po4a-0.32-4.fc8.noarch requires /bin/sh podsleuth-0.6.0-5.fc10.x86_64 requires /bin/bash poedit-1.3.9-2.fc9.x86_64 requires /bin/sh poker-bot-1.5.0-1.fc10.noarch requires /bin/sh poker-bot-1.5.0-1.fc10.noarch requires /sbin/chkconfig poker-bot-1.5.0-1.fc10.noarch requires /bin/sh poker-bot-1.5.0-1.fc10.noarch requires /usr/bin/python poker-bot-1.5.0-1.fc10.noarch requires /sbin/service poker-engine-1.2.0-1.fc10.noarch requires /usr/bin/python poker-eval-134.0-2.fc9.i386 requires /sbin/ldconfig poker-eval-134.0-2.fc9.x86_64 requires /sbin/ldconfig poker-network-selinux-1.5.0-1.fc10.noarch requires /usr/sbin/semodule poker-network-selinux-1.5.0-1.fc10.noarch requires /sbin/fixfiles poker-network-selinux-1.5.0-1.fc10.noarch requires /bin/sh poker-network-selinux-1.5.0-1.fc10.noarch requires /usr/sbin/semanage poker-network-selinux-1.5.0-1.fc10.noarch requires /usr/sbin/setsebool poker-network-selinux-1.5.0-1.fc10.noarch requires /sbin/service poker-server-1.5.0-1.fc10.noarch requires /bin/sh poker-server-1.5.0-1.fc10.noarch requires /sbin/chkconfig poker-server-1.5.0-1.fc10.noarch requires /bin/sh poker-server-1.5.0-1.fc10.noarch requires /usr/bin/python poker-server-1.5.0-1.fc10.noarch requires /sbin/service poker-web-1.5.0-1.fc10.noarch requires /bin/sh poker2d-1.5.0-1.fc10.x86_64 requires /bin/sh poker2d-1.5.0-1.fc10.x86_64 requires /usr/bin/python2.5 poker3d-1.1.36-10.fc10.x86_64 requires /bin/sh poker3d-1.1.36-10.fc10.x86_64 requires /usr/libexec/poker3d/underware poker3d-1.1.36-10.fc10.x86_64 requires /bin/sh policycoreutils-2.0.49-2.fc10.x86_64 requires /bin/sh policycoreutils-2.0.49-2.fc10.x86_64 requires /bin/sed policycoreutils-2.0.49-2.fc10.x86_64 requires /bin/mount policycoreutils-2.0.49-2.fc10.x86_64 requires /bin/awk policycoreutils-2.0.49-2.fc10.x86_64 requires /usr/bin/python policycoreutils-2.0.49-2.fc10.x86_64 requires /sbin/service policycoreutils-2.0.49-2.fc10.x86_64 requires /usr/bin/diff policycoreutils-2.0.49-2.fc10.x86_64 requires /bin/egrep policycoreutils-2.0.49-2.fc10.x86_64 requires /bin/bash policycoreutils-2.0.49-2.fc10.x86_64 requires /bin/sh policycoreutils-2.0.49-2.fc10.x86_64 requires /sbin/chkconfig policycoreutils-gui-2.0.49-2.fc10.x86_64 requires /usr/bin/python polyml-libs-5.1-4.fc9.i386 requires /sbin/ldconfig polyml-libs-5.1-4.fc9.x86_64 requires /sbin/ldconfig pop-before-smtp-1.41-2.fc6.noarch requires /bin/sh pop-before-smtp-1.41-2.fc6.noarch requires /usr/bin/perl pop-before-smtp-1.41-2.fc6.noarch requires /bin/sh popt-1.13-3.fc9.i386 requires /sbin/ldconfig popt-1.13-3.fc9.x86_64 requires /sbin/ldconfig portaudio-19-5.fc9.i386 requires /sbin/ldconfig portaudio-19-5.fc9.x86_64 requires /sbin/ldconfig portecle-1.3-3.fc9.noarch requires /bin/sh portecle-1.3-3.fc9.noarch requires /bin/sh 2:postfix-2.5.1-2.fc9.i386 requires /bin/sh 2:postfix-2.5.1-2.fc9.i386 requires /usr/sbin/alternatives 2:postfix-2.5.1-2.fc9.i386 requires /usr/sbin/groupadd 2:postfix-2.5.1-2.fc9.i386 requires /usr/sbin/useradd 2:postfix-2.5.1-2.fc9.i386 requires /sbin/service 2:postfix-2.5.1-2.fc9.i386 requires /bin/bash 2:postfix-2.5.1-2.fc9.i386 requires /bin/sh 2:postfix-2.5.1-2.fc9.i386 requires /usr/bin/perl 2:postfix-2.5.1-2.fc9.i386 requires /sbin/chkconfig 2:postfix-2.5.1-2.fc9.x86_64 requires /bin/sh 2:postfix-2.5.1-2.fc9.x86_64 requires /usr/sbin/groupadd 2:postfix-2.5.1-2.fc9.x86_64 requires /usr/sbin/useradd 2:postfix-2.5.1-2.fc9.x86_64 requires /usr/sbin/alternatives 2:postfix-2.5.1-2.fc9.x86_64 requires /sbin/service 2:postfix-2.5.1-2.fc9.x86_64 requires /bin/bash 2:postfix-2.5.1-2.fc9.x86_64 requires /bin/sh 2:postfix-2.5.1-2.fc9.x86_64 requires /usr/bin/perl 2:postfix-2.5.1-2.fc9.x86_64 requires /sbin/chkconfig 2:postfix-pflogsumm-2.5.1-2.fc9.x86_64 requires /usr/bin/perl postgis-1.3.3-1.fc9.x86_64 requires /usr/bin/rebuild-gcj-db postgis-jdbc-1.3.3-1.fc9.x86_64 requires /usr/bin/rebuild-gcj-db postgresql-devel-8.3.1-3.fc10.i386 requires /bin/sh postgresql-devel-8.3.1-3.fc10.x86_64 requires /bin/sh postgresql-jdbc-8.3.603-1jpp.fc9.x86_64 requires /bin/sh postgresql-jdbc-8.3.603-1jpp.fc9.x86_64 requires /usr/bin/rebuild-gcj-db postgresql-libs-8.3.1-3.fc10.i386 requires /sbin/ldconfig postgresql-libs-8.3.1-3.fc10.x86_64 requires /sbin/ldconfig postgresql-odbc-08.03.0100-1.fc9.x86_64 requires /sbin/ldconfig postgresql-pgpool-3.4.1-2.fc9.1.x86_64 requires /bin/sh postgresql-pgpool-II-2.1-0.2.beta2.fc9.i386 requires /bin/sh postgresql-pgpool-II-2.1-0.2.beta2.fc9.i386 requires /sbin/ldconfig postgresql-pgpool-II-2.1-0.2.beta2.fc9.i386 requires /bin/sh postgresql-pgpool-II-2.1-0.2.beta2.fc9.x86_64 requires /bin/sh postgresql-pgpool-II-2.1-0.2.beta2.fc9.x86_64 requires /sbin/ldconfig postgresql-pgpool-II-2.1-0.2.beta2.fc9.x86_64 requires /bin/sh postgresql-pgpoolAdmin-1.0.0-7.fc8.noarch requires /bin/sh postgresql-plperl-8.3.1-3.fc10.x86_64 requires /sbin/ldconfig postgresql-plpython-8.3.1-3.fc10.x86_64 requires /sbin/ldconfig postgresql-pltcl-8.3.1-3.fc10.x86_64 requires /sbin/ldconfig postgresql-pltcl-8.3.1-3.fc10.x86_64 requires /bin/sh postgresql-python-8.3.1-3.fc10.x86_64 requires /usr/bin/env postgresql-server-8.3.1-3.fc10.x86_64 requires /bin/sh postgresql-server-8.3.1-3.fc10.x86_64 requires /usr/sbin/useradd postgresql-server-8.3.1-3.fc10.x86_64 requires /bin/sh postgresql-server-8.3.1-3.fc10.x86_64 requires /sbin/chkconfig postgresql-table_log-0.4.4-4.fc9.1.x86_64 requires /sbin/ldconfig postgresql-test-8.3.1-3.fc10.x86_64 requires /bin/sh postgresql-test-8.3.1-3.fc10.x86_64 requires /bin/sh postgresql_autodoc-1.31-1.fc9.noarch requires /usr/bin/perl postgrey-1.30-1.fc8.noarch requires /bin/sh postgrey-1.30-1.fc8.noarch requires /usr/sbin/useradd postgrey-1.30-1.fc8.noarch requires /sbin/service postgrey-1.30-1.fc8.noarch requires /usr/bin/perl postgrey-1.30-1.fc8.noarch requires /bin/sh postgrey-1.30-1.fc8.noarch requires /sbin/chkconfig postr-0.10-2.fc9.noarch requires /bin/sh postr-0.10-2.fc9.noarch requires /usr/bin/python powerman-1.0.32-5.fc9.x86_64 requires /bin/sh powerman-1.0.32-5.fc9.x86_64 requires /bin/sh powermanga-0.90-3.x86_64 requires /bin/sh ppl-0.9-19.fc9.i386 requires /sbin/ldconfig ppl-0.9-19.fc9.x86_64 requires /sbin/ldconfig ppl-pwl-0.9-19.fc9.i386 requires /sbin/ldconfig ppl-pwl-0.9-19.fc9.x86_64 requires /sbin/ldconfig ppp-2.4.4-7.fc10.x86_64 requires /etc/pam.d/system-auth pptp-1.7.2-1.fc10.x86_64 requires /usr/bin/perl prelink-0.4.0-3.x86_64 requires /bin/sh prelink-0.4.0-3.x86_64 requires /bin/sh preload-0.4-6.fc9.x86_64 requires /bin/sh preload-0.4-6.fc9.x86_64 requires /bin/bash preload-0.4-6.fc9.x86_64 requires /sbin/chkconfig preload-0.4-6.fc9.x86_64 requires /sbin/service prelude-lml-0.9.12.2-1.fc10.x86_64 requires /bin/sh prelude-lml-0.9.12.2-1.fc10.x86_64 requires /sbin/service prelude-lml-0.9.12.2-1.fc10.x86_64 requires /bin/sh prelude-lml-0.9.12.2-1.fc10.x86_64 requires /sbin/chkconfig prelude-manager-0.9.12.1-1.fc10.x86_64 requires /bin/sh prelude-manager-0.9.12.1-1.fc10.x86_64 requires /sbin/service prelude-manager-0.9.12.1-1.fc10.x86_64 requires /bin/sh prelude-manager-0.9.12.1-1.fc10.x86_64 requires /sbin/chkconfig presto-utils-0.3.2-1.fc8.noarch requires /bin/sh presto-utils-0.3.2-1.fc8.noarch requires /usr/bin/python preupgrade-0.9.3-3.fc10.noarch requires /bin/sh preupgrade-0.9.3-3.fc10.noarch requires /bin/sh preupgrade-0.9.3-3.fc10.noarch requires /usr/bin/python prewikka-0.9.14-1.fc10.noarch requires /bin/sh prewikka-0.9.14-1.fc10.noarch requires /usr/bin/python privoxy-3.0.8-2.fc9.x86_64 requires /bin/sh privoxy-3.0.8-2.fc9.x86_64 requires /sbin/chkconfig privoxy-3.0.8-2.fc9.x86_64 requires /bin/sh privoxy-3.0.8-2.fc9.x86_64 requires /sbin/service procinfo-18-23.fc9.x86_64 requires /usr/bin/perl procmail-3.22-21.fc9.x86_64 requires /bin/sh procps-3.2.7-20.fc9.x86_64 requires /sbin/ldconfig professor-is-missing-0.1-3.fc8.noarch requires /bin/sh professor-is-missing-0.1-3.fc8.noarch requires /bin/bash proftpd-1.3.1-3.fc9.x86_64 requires /bin/sh proftpd-1.3.1-3.fc9.x86_64 requires /sbin/service proftpd-1.3.1-3.fc9.x86_64 requires /bin/sh proftpd-1.3.1-3.fc9.x86_64 requires /sbin/chkconfig proj-4.6.0-1.fc10.i386 requires /sbin/ldconfig proj-4.6.0-1.fc10.x86_64 requires /sbin/ldconfig proj-nad-4.6.0-1.fc10.x86_64 requires /bin/bash proxychains-3.1-5.fc9.i386 requires /sbin/ldconfig proxychains-3.1-5.fc9.i386 requires /bin/sh proxychains-3.1-5.fc9.x86_64 requires /sbin/ldconfig proxychains-3.1-5.fc9.x86_64 requires /bin/sh proxyknife-1.7-3.fc9.x86_64 requires /bin/sh proxyknife-1.7-3.fc9.x86_64 requires /sbin/install-info ps2eps-1.64-4.fc9.x86_64 requires /usr/bin/perl psacct-6.3.2-50.fc9.x86_64 requires /bin/sh psacct-6.3.2-50.fc9.x86_64 requires /sbin/chkconfig psacct-6.3.2-50.fc9.x86_64 requires /bin/bash psacct-6.3.2-50.fc9.x86_64 requires /sbin/install-info pscan-1.3-1.fc9.x86_64 requires /bin/sh psgml-1.2.5-6.fc7.noarch requires /bin/sh psi-0.11-4.fc9.x86_64 requires /bin/sh psi-0.11-4.fc9.x86_64 requires /bin/sh psiconv-0.9.8-1.fc8.i386 requires /sbin/ldconfig psiconv-0.9.8-1.fc8.i386 requires libWand.so.10 psiconv-0.9.8-1.fc8.i386 requires libMagick.so.10 psiconv-0.9.8-1.fc8.x86_64 requires libWand.so.10()(64bit) psiconv-0.9.8-1.fc8.x86_64 requires /sbin/ldconfig psiconv-0.9.8-1.fc8.x86_64 requires libMagick.so.10()(64bit) psiconv-devel-0.9.8-1.fc8.i386 requires /bin/sh psiconv-devel-0.9.8-1.fc8.x86_64 requires /bin/sh pstoedit-3.45-3.fc10.i386 requires /sbin/ldconfig pstoedit-3.45-3.fc10.x86_64 requires /sbin/ldconfig psutils-1.17-28.fc9.x86_64 requires /usr/bin/perl psutils-1.17-28.fc9.x86_64 requires /bin/sh pth-2.0.7-6.i386 requires /sbin/ldconfig pth-2.0.7-6.x86_64 requires /sbin/ldconfig pth-devel-2.0.7-6.i386 requires /bin/sh pth-devel-2.0.7-6.x86_64 requires /bin/sh publican-0.33-0.fc9.noarch requires /usr/bin/perl publican-0.33-0.fc9.noarch requires /bin/env publican-0.33-0.fc9.noarch requires /usr/bin/env pulseaudio-0.9.11-0.0.svn20080516.fc10.x86_64 requires /bin/sh pulseaudio-0.9.11-0.0.svn20080516.fc10.x86_64 requires /sbin/ldconfig pulseaudio-esound-compat-0.9.11-0.0.svn20080516.fc10.x86_64 requires /bin/sh pulseaudio-libs-0.9.11-0.0.svn20080516.fc10.i386 requires /sbin/ldconfig pulseaudio-libs-0.9.11-0.0.svn20080516.fc10.x86_64 requires /sbin/ldconfig pulseaudio-libs-glib2-0.9.11-0.0.svn20080516.fc10.i386 requires /sbin/ldconfig pulseaudio-libs-glib2-0.9.11-0.0.svn20080516.fc10.x86_64 requires /sbin/ldconfig pulseaudio-libs-zeroconf-0.9.11-0.0.svn20080516.fc10.i386 requires /sbin/ldconfig pulseaudio-libs-zeroconf-0.9.11-0.0.svn20080516.fc10.x86_64 requires /sbin/ldconfig pulseaudio-utils-0.9.11-0.0.svn20080516.fc10.i386 requires /bin/sh pulseaudio-utils-0.9.11-0.0.svn20080516.fc10.x86_64 requires /bin/sh pungi-1.2.18-1.fc9.noarch requires /usr/bin/python puppet-0.24.4-1.fc9.noarch requires /bin/sh puppet-0.24.4-1.fc9.noarch requires /usr/bin/ruby puppet-0.24.4-1.fc9.noarch requires /bin/bash puppet-server-0.24.4-1.fc9.noarch requires /bin/sh puppet-server-0.24.4-1.fc9.noarch requires /bin/bash puppet-server-0.24.4-1.fc9.noarch requires /usr/bin/ruby pure-ftpd-1.0.21-15.fc9.x86_64 requires /bin/sh pure-ftpd-1.0.21-15.fc9.x86_64 requires /usr/bin/python pure-ftpd-1.0.21-15.fc9.x86_64 requires /usr/bin/perl pure-ftpd-1.0.21-15.fc9.x86_64 requires /bin/bash pure-ftpd-selinux-1.0.21-15.fc9.x86_64 requires /bin/sh puretls-0.9-0.2.b5.5jpp.1.fc9.x86_64 requires /bin/sh puretls-demo-0.9-0.2.b5.5jpp.1.fc9.x86_64 requires /bin/sh puretls-demo-0.9-0.2.b5.5jpp.1.fc9.x86_64 requires /usr/bin/perl pvm-3.4.5-9.fc9.x86_64 requires /bin/csh pvm-3.4.5-9.fc9.x86_64 requires /bin/sh pvm-3.4.5-9.fc9.x86_64 requires /bin/sh pvm-gui-3.4.5-9.fc9.x86_64 requires /bin/csh pvm-gui-3.4.5-9.fc9.x86_64 requires /bin/sh pwlib-1.10.10-6.fc9.i386 requires /sbin/ldconfig pwlib-1.10.10-6.fc9.x86_64 requires /sbin/ldconfig pwlib-devel-1.10.10-6.fc9.i386 requires /bin/sh pwlib-devel-1.10.10-6.fc9.x86_64 requires /bin/sh pybackpack-0.5.4-2.fc9.noarch requires /usr/bin/python pybliographer-1.2.11-2.fc9.noarch requires /bin/sh pybliographer-1.2.11-2.fc9.noarch requires /bin/sh pybliographer-1.2.11-2.fc9.noarch requires /usr/bin/python pycairo-1.4.12-3.fc10.x86_64 requires /usr/bin/env pychecker-0.8.17-4.noarch requires /bin/sh pychess-0.8-2.fc9.noarch requires /usr/bin/python pychess-0.8-2.fc9.noarch requires /usr/bin/env pydict-0.3.0-11.fc8.noarch requires /bin/sh pyflakes-0.2.1-3.fc7.noarch requires /usr/bin/python pyflowtools-0.3.3-1.fc9.x86_64 requires /usr/bin/env pygsl-0.9.1-8.fc9.x86_64 requires /usr/bin/env pygtk2-2.12.1-6.fc9.x86_64 requires /usr/bin/env pygtk2-2.12.1-6.fc9.x86_64 requires /usr/bin/python pygtk2-codegen-2.12.1-6.fc9.x86_64 requires /bin/sh pygtkglext-1.1.0-4.fc9.x86_64 requires /usr/bin/env pyicq-t-0.8-4.b.fc9.noarch requires /bin/sh pyicq-t-0.8-4.b.fc9.noarch requires /bin/bash pyicq-t-0.8-4.b.fc9.noarch requires /sbin/chkconfig pyicq-t-0.8-4.b.fc9.noarch requires /usr/bin/env pyicq-t-0.8-4.b.fc9.noarch requires /sbin/service pyjigdo-0.3.0-1.fc10.noarch requires /usr/bin/python pykickstart-1.34-1.fc10.noarch requires /usr/bin/python pylint-0.14.0-1.fc9.noarch requires /usr/bin/python pylint-gui-0.14.0-1.fc9.noarch requires /usr/bin/python pypar2-1.4-1.fc8.noarch requires /bin/sh pypar2-1.4-1.fc8.noarch requires /usr/bin/python pypoker-eval-135.0-1.fc9.x86_64 requires /sbin/ldconfig pyscript-0.6.1-2.fc9.noarch requires /usr/bin/python python-2.5.1-25.fc9.x86_64 requires /usr/bin/env python-2.5.1-25.fc9.x86_64 requires /bin/sh python-2.5.1-25.fc9.x86_64 requires /usr/bin/python2.5 python-4Suite-XML-1.0.2-3.x86_64 requires /usr/bin/env python-Coherence-0.5.0-1.fc9.noarch requires /usr/bin/python python-ZSI-2.0-3.fc9.noarch requires /usr/bin/env python-ZSI-2.0-3.fc9.noarch requires /usr/bin/python python-amara-1.2.0.2-2.fc8.noarch requires /usr/bin/python python-bugzilla-0.3-1.fc9.noarch requires /usr/bin/python python-cheetah-2.0.1-2.fc9.x86_64 requires /usr/bin/python python-clientform-0.2.7-2.fc9.noarch requires /usr/bin/env python-demjson-1.3-2.fc9.noarch requires /usr/bin/python python-devel-2.5.1-25.fc9.i386 requires /bin/sh python-devel-2.5.1-25.fc9.x86_64 requires /bin/sh python-dialog-2.7-7.fc8.noarch requires /usr/bin/env python-docutils-0.4-8.fc9.noarch requires /usr/bin/python python-durus-3.5-3.fc7.x86_64 requires /usr/bin/python python-exif-1.0.7-4.fc9.noarch requires /bin/bash python-exif-1.0.7-4.fc9.noarch requires /usr/bin/env python-eyed3-0.6.15-1.fc9.noarch requires /usr/bin/env python-formencode-1.0-1.fc9.noarch requires /bin/sh python-formencode-1.0-1.fc9.noarch requires /usr/bin/python python-igraph-0.5-5.fc9.x86_64 requires /usr/bin/python python-imaging-devel-1.1.6-9.fc9.i386 requires /usr/bin/env python-imaging-devel-1.1.6-9.fc9.i386 requires /usr/bin/python python-imaging-devel-1.1.6-9.fc9.x86_64 requires /usr/bin/env python-imaging-devel-1.1.6-9.fc9.x86_64 requires /usr/bin/python python-inotify-examples-0.7.1-2.fc9.x86_64 requires /bin/sh python-inotify-examples-0.7.1-2.fc9.x86_64 requires /usr/bin/env python-kaa-metadata-0.7.3-1.fc9.x86_64 requires /usr/bin/python python-kid-0.9.6-2.fc8.noarch requires /usr/bin/env python-kiwi-1.9.21-1.fc10.noarch requires /usr/bin/python python-kiwi-docs-1.9.21-1.fc10.noarch requires /usr/bin/env python-libgmail-0.1.8-2.fc9.noarch requires /usr/bin/env python-libgmail-docs-0.3-6.fc9.noarch requires /usr/bin/env python-libs-2.5.1-25.fc9.i386 requires /sbin/ldconfig python-libs-2.5.1-25.fc9.x86_64 requires /sbin/ldconfig python-logilab-common-0.28.0-1.fc9.noarch requires /usr/bin/python python-matplotlib-0.91.2-2.fc9.x86_64 requires /usr/bin/env python-mechanize-0.1.6-0.2.b.fc9.noarch requires /usr/bin/python python-musicbrainz2-0.5.0-2.fc9.noarch requires /usr/bin/python python-mutagen-1.13-2.fc9.noarch requires /usr/bin/python python-nevow-0.9.29-2.fc9.noarch requires /usr/bin/python 1:python-nltk-0.9.2-1.fc9.noarch requires /usr/bin/env 1:python-nltk-0.9.2-1.fc9.noarch requires /usr/bin/python python-nose-0.10.1-1.fc9.noarch requires /usr/bin/python python-numarray-1.5.2-6.fc9.x86_64 requires /usr/bin/env python-numarray-1.5.2-6.fc9.x86_64 requires /bin/sh python-paste-script-1.6.2-2.fc9.noarch requires /usr/bin/env python-paste-script-1.6.2-2.fc9.noarch requires /usr/bin/python python-pp-1.5.3-1.fc9.noarch requires /usr/bin/python python-pyblock-0.31-2.x86_64 requires /usr/bin/python python-pygments-0.9-2.fc9.noarch requires /usr/bin/python python-pyspf-2.0.3-1.fc8.noarch requires /usr/bin/python python-qpid-0.2-10.fc9.noarch requires /usr/bin/env python-setuptools-0.6c7-2.fc8.noarch requires /usr/bin/python python-setuptools-devel-0.6c7-2.fc8.noarch requires /usr/bin/python python-simpletal-4.1-5.fc7.noarch requires /usr/bin/python python-sqlobject-0.10.1-1.fc10.noarch requires /usr/bin/python python-tag-0.94.1-1.fc10.x86_64 requires /usr/bin/env python-test-2.5.1-25.fc9.x86_64 requires /usr/bin/env python-tools-2.5.1-25.fc9.x86_64 requires /bin/bash python-tools-2.5.1-25.fc9.x86_64 requires /usr/bin/env python-tools-2.5.1-25.fc9.x86_64 requires /bin/sh python-tools-2.5.1-25.fc9.x86_64 requires /usr/bin/python python-tpg-3.1.0-4.fc7.noarch requires /usr/bin/python python-tunepimp-0.5.3-11.fc9.x86_64 requires /usr/bin/env python-twisted-conch-0.8.0-4.fc9.x86_64 requires /usr/libexec/twisted-dropin-cache python-twisted-conch-0.8.0-4.fc9.x86_64 requires /usr/bin/python python-twisted-core-2.5.0-4.fc9.x86_64 requires /usr/libexec/twisted-dropin-cache python-twisted-core-2.5.0-4.fc9.x86_64 requires /usr/bin/env python-twisted-core-2.5.0-4.fc9.x86_64 requires /usr/bin/python python-twisted-lore-0.2.0-6.fc9.x86_64 requires /usr/libexec/twisted-dropin-cache python-twisted-lore-0.2.0-6.fc9.x86_64 requires /usr/bin/python python-twisted-mail-0.4.0-4.fc9.x86_64 requires /usr/libexec/twisted-dropin-cache python-twisted-mail-0.4.0-4.fc9.x86_64 requires /bin/sh python-twisted-mail-0.4.0-4.fc9.x86_64 requires /usr/bin/python python-twisted-names-0.4.0-3.fc9.x86_64 requires /usr/libexec/twisted-dropin-cache python-twisted-news-0.3.0-3.fc9.x86_64 requires /usr/libexec/twisted-dropin-cache python-twisted-web-0.7.0-3.fc9.x86_64 requires /usr/libexec/twisted-dropin-cache python-twisted-words-0.5.0-3.fc9.x86_64 requires /usr/libexec/twisted-dropin-cache python-twisted-words-0.5.0-3.fc9.x86_64 requires /usr/bin/python python-twyt-0.8-1.fc9.noarch requires /usr/bin/python python-urlgrabber-3.0.0-7.fc10.noarch requires /usr/bin/python python-virtinst-0.300.3-6.fc10.noarch requires /usr/bin/python python-vobject-0.6.0-2.fc9.noarch requires /usr/bin/python python-which-1.1.0-3.fc9.noarch requires /bin/sh pyzor-0.4.0-11.fc7.noarch requires /usr/bin/python q-7.10-3.fc9.i386 requires /bin/sh q-7.10-3.fc9.i386 requires /sbin/install-info q-7.10-3.fc9.i386 requires /sbin/ldconfig q-7.10-3.fc9.i386 requires /bin/sh q-7.10-3.fc9.i386 requires libMagick.so.10 q-devel-7.10-3.fc9.i386 requires /bin/sh qa-assistant-0.4.90.5-2.fc6.noarch requires /bin/sh qa-assistant-0.4.90.5-2.fc6.noarch requires /usr/bin/xmlcatalog qa-assistant-0.4.90.5-2.fc6.noarch requires /usr/bin/python qalculate-gtk-0.9.6-4.fc9.x86_64 requires /bin/sh qalculate-kde-0.9.6-5.fc9.x86_64 requires /bin/sh qascade-0.1-10.fc9.x86_64 requires /bin/sh qbanking-2.3.3-3.fc9.i386 requires /sbin/ldconfig qbanking-2.3.3-3.fc9.x86_64 requires /sbin/ldconfig qbanking-devel-2.3.3-3.fc9.i386 requires /bin/sh qbanking-devel-2.3.3-3.fc9.x86_64 requires /bin/sh qca-1.0-10.fc9.i386 requires /sbin/ldconfig qca-1.0-10.fc9.x86_64 requires /sbin/ldconfig qca2-2.0.0-2.fc9.i386 requires /sbin/ldconfig qca2-2.0.0-2.fc9.x86_64 requires /sbin/ldconfig qcad-2.0.5.0-8.fc9.x86_64 requires /bin/sh qct-1.5-6.fc9.x86_64 requires /usr/bin/env qct-1.5-6.fc9.x86_64 requires /usr/bin/python qdbm-1.8.77-3.fc9.i386 requires /sbin/ldconfig qdbm-1.8.77-3.fc9.x86_64 requires /sbin/ldconfig qdbm++-1.8.77-3.fc9.i386 requires /sbin/ldconfig qdbm++-1.8.77-3.fc9.x86_64 requires /sbin/ldconfig qdbm-java-1.8.77-3.fc9.i386 requires /sbin/ldconfig qdbm-java-1.8.77-3.fc9.x86_64 requires /sbin/ldconfig qdbm-perl-1.8.77-3.fc9.x86_64 requires /usr/bin/perl qemu-0.9.1-7.fc10.x86_64 requires /bin/sh qemu-0.9.1-7.fc10.x86_64 requires /sbin/service qemu-0.9.1-7.fc10.x86_64 requires /bin/sh qemu-0.9.1-7.fc10.x86_64 requires /sbin/chkconfig qemu-launcher-1.7.4-4.fc9.noarch requires /bin/sh qemu-launcher-1.7.4-4.fc9.noarch requires /usr/bin/perl qfaxreader-0.3.1-9.fc9.3.x86_64 requires /bin/sh qgis-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) qgis-0.9.1-5.fc9.x86_64 requires /usr/bin/python qgis-0.9.1-5.fc9.x86_64 requires /sbin/ldconfig qgis-grass-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.x86_64 requires /sbin/ldconfig qhull-2003.1-10.fc9.i386 requires /sbin/ldconfig qhull-2003.1-10.fc9.x86_64 requires /sbin/ldconfig qimageblitz-0.0.4-0.4.svn706674.fc9.i386 requires /sbin/ldconfig qimageblitz-0.0.4-0.4.svn706674.fc9.x86_64 requires /sbin/ldconfig qiv-2.0-9.fc9.x86_64 requires /bin/sh qjackctl-0.3.1a-6.fc9.x86_64 requires /bin/sh qmmp-0.1.5-2.fc9.x86_64 requires /bin/sh qmmp-0.1.5-2.fc9.x86_64 requires /sbin/ldconfig qof-0.7.5-2.fc9.i386 requires /sbin/ldconfig qof-0.7.5-2.fc9.x86_64 requires /sbin/ldconfig qpidc-0.2-26.fc9.i386 requires /bin/sh qpidc-0.2-26.fc9.i386 requires /sbin/service qpidc-0.2-26.fc9.i386 requires /sbin/ldconfig qpidc-0.2-26.fc9.i386 requires /sbin/chkconfig qpidc-0.2-26.fc9.x86_64 requires /bin/sh qpidc-0.2-26.fc9.x86_64 requires /sbin/service qpidc-0.2-26.fc9.x86_64 requires /sbin/ldconfig qpidc-0.2-26.fc9.x86_64 requires /sbin/chkconfig qpidd-0.2-26.fc9.i386 requires /bin/sh qpidd-0.2-26.fc9.i386 requires /bin/bash qpidd-0.2-26.fc9.x86_64 requires /bin/sh qpidd-0.2-26.fc9.x86_64 requires /bin/bash qpxtool-0.6.1-9.fc9.i386 requires /sbin/ldconfig qpxtool-0.6.1-9.fc9.x86_64 requires /sbin/ldconfig qscintilla-2.2-1.fc10.i386 requires /sbin/ldconfig qscintilla-2.2-1.fc10.x86_64 requires /sbin/ldconfig qstars-0.4-6.fc9.x86_64 requires /bin/sh qstars-xscreensaver-0.4-6.fc9.x86_64 requires /bin/sh qsynth-0.2.5-7.fc9.x86_64 requires /bin/sh 1:qt-4.4.0-3.fc10.i386 requires /sbin/ldconfig 1:qt-4.4.0-3.fc10.i386 requires /bin/bash 1:qt-4.4.0-3.fc10.x86_64 requires /sbin/ldconfig 1:qt-4.4.0-3.fc10.x86_64 requires /bin/bash 1:qt-devel-4.4.0-3.fc10.i386 requires /bin/sh 1:qt-devel-4.4.0-3.fc10.i386 requires /bin/bash 1:qt-devel-4.4.0-3.fc10.x86_64 requires /bin/sh 1:qt-devel-4.4.0-3.fc10.x86_64 requires /bin/bash 1:qt-doc-4.4.0-3.fc10.x86_64 requires /bin/bash qt-qsa-1.1.5-5.fc9.i386 requires /sbin/ldconfig qt-qsa-1.1.5-5.fc9.x86_64 requires /sbin/ldconfig qt-recordmydesktop-0.3.7-1.fc9.noarch requires /usr/bin/python 1:qt-x11-4.4.0-3.fc10.i386 requires /bin/sh 1:qt-x11-4.4.0-3.fc10.i386 requires /bin/bash 1:qt-x11-4.4.0-3.fc10.x86_64 requires /bin/sh 1:qt-x11-4.4.0-3.fc10.x86_64 requires /bin/bash qt3-3.3.8b-12.fc9.i386 requires /etc/ld.so.conf.d qt3-3.3.8b-12.fc9.i386 requires /sbin/ldconfig qt3-3.3.8b-12.fc9.x86_64 requires /sbin/ldconfig qt3-3.3.8b-12.fc9.x86_64 requires /etc/ld.so.conf.d qt3-devel-3.3.8b-12.fc9.i386 requires /usr/bin/perl qt3-devel-3.3.8b-12.fc9.x86_64 requires /usr/bin/perl qtpfsgui-1.9.2-1.fc10.x86_64 requires /bin/sh quagga-0.99.9-6.fc9.x86_64 requires /bin/sh quagga-0.99.9-6.fc9.x86_64 requires /sbin/install-info quagga-0.99.9-6.fc9.x86_64 requires /bin/bash quagga-contrib-0.99.9-6.fc9.x86_64 requires /usr/bin/perl quake3-1.34-0.9.rc4.fc9.x86_64 requires /bin/bash quake3-demo-1.34-0.9.rc4.fc9.x86_64 requires /bin/sh quake3-demo-1.34-0.9.rc4.fc9.x86_64 requires /bin/bash quarry-0.2.0-3.fc9.x86_64 requires /bin/sh qucs-0.0.14-1.fc9.x86_64 requires /usr/bin/perl qucs-0.0.14-1.fc9.x86_64 requires /bin/sh quesa-1.8-1.fc9.i386 requires /sbin/ldconfig quesa-1.8-1.fc9.x86_64 requires /sbin/ldconfig quesoglc-0.7.1-1.fc10.i386 requires /sbin/ldconfig quesoglc-0.7.1-1.fc10.x86_64 requires /sbin/ldconfig queuegraph-1.1-3.fc9.noarch requires /usr/bin/perl queuegraph-1.1-3.fc9.noarch requires /bin/sh queuegraph-selinux-1.1-3.fc9.noarch requires /usr/sbin/semodule queuegraph-selinux-1.1-3.fc9.noarch requires /sbin/fixfiles queuegraph-selinux-1.1-3.fc9.noarch requires /bin/sh queuegraph-selinux-1.1-3.fc9.noarch requires /sbin/restorecon quilt-0.46-5.fc9.x86_64 requires /usr/bin/perl quilt-0.46-5.fc9.x86_64 requires /bin/bash quodlibet-1.0-3.fc9.x86_64 requires /usr/bin/env qwt-5.0.2-6.fc9.i386 requires /sbin/ldconfig qwt-5.0.2-6.fc9.x86_64 requires /sbin/ldconfig qwtplot3d-0.2.7-6.fc9.i386 requires /sbin/ldconfig qwtplot3d-0.2.7-6.fc9.x86_64 requires /sbin/ldconfig qwtplot3d-qt4-0.2.7-6.fc9.i386 requires /sbin/ldconfig qwtplot3d-qt4-0.2.7-6.fc9.x86_64 requires /sbin/ldconfig radiusclient-ng-0.5.6-3.fc9.i386 requires /sbin/ldconfig radiusclient-ng-0.5.6-3.fc9.x86_64 requires /sbin/ldconfig radiusclient-ng-utils-0.5.6-3.fc9.x86_64 requires /bin/sh radvd-1.1-3.fc10.x86_64 requires /usr/sbin/userdel radvd-1.1-3.fc10.x86_64 requires /bin/sh radvd-1.1-3.fc10.x86_64 requires /usr/sbin/useradd radvd-1.1-3.fc10.x86_64 requires /bin/sh rafkill-1.2.2-7.fc9.x86_64 requires /bin/sh raidem-0.3.1-8.fc9.x86_64 requires /bin/sh raptor-1.4.16-2.fc9.i386 requires /sbin/ldconfig raptor-1.4.16-2.fc9.x86_64 requires /sbin/ldconfig raptor-devel-1.4.16-2.fc9.i386 requires /bin/sh raptor-devel-1.4.16-2.fc9.x86_64 requires /bin/sh rarian-0.8.0-1.fc9.i386 requires /sbin/ldconfig rarian-0.8.0-1.fc9.x86_64 requires /sbin/ldconfig rarian-compat-0.8.0-1.fc9.x86_64 requires /bin/sh rarian-compat-0.8.0-1.fc9.x86_64 requires /bin/bash rarian-compat-0.8.0-1.fc9.x86_64 requires /bin/sh rarpd-ss981107-26.1.fc9.x86_64 requires /bin/sh rarpd-ss981107-26.1.fc9.x86_64 requires /bin/bash rarpd-ss981107-26.1.fc9.x86_64 requires /sbin/chkconfig rasqal-0.9.15-1.fc9.i386 requires /sbin/ldconfig rasqal-0.9.15-1.fc9.x86_64 requires /sbin/ldconfig rasqal-devel-0.9.15-1.fc9.i386 requires /bin/sh rasqal-devel-0.9.15-1.fc9.x86_64 requires /bin/sh ratpoison-1.4.1-2.fc9.x86_64 requires /bin/sh ratpoison-1.4.1-2.fc9.x86_64 requires /usr/bin/perl ratpoison-1.4.1-2.fc9.x86_64 requires /bin/bash ratpoison-1.4.1-2.fc9.x86_64 requires /sbin/install-info ratpoison-1.4.1-2.fc9.x86_64 requires /bin/sh rawstudio-1.0-1.fc10.x86_64 requires /bin/sh raydium-1.2-8.fc9.i386 requires /sbin/ldconfig raydium-1.2-8.fc9.x86_64 requires /sbin/ldconfig rb_libtorrent-0.12.1-1.fc9.i386 requires /sbin/ldconfig rb_libtorrent-0.12.1-1.fc9.x86_64 requires /sbin/ldconfig rblcheck-1.5-15.fc9.x86_64 requires /bin/sh rbldnsd-0.996b-1.fc9.x86_64 requires /bin/sh rbldnsd-0.996b-1.fc9.x86_64 requires /bin/bash rbldnsd-0.996b-1.fc9.x86_64 requires /sbin/chkconfig rdiff-backup-1.0.5-7.fc9.x86_64 requires /usr/bin/python 1:readahead-1.4.2-5.fc9.x86_64 requires /bin/sh 1:readahead-1.4.2-5.fc9.x86_64 requires /bin/bash 1:readahead-1.4.2-5.fc9.x86_64 requires /bin/gawk 1:readahead-1.4.2-5.fc9.x86_64 requires /sbin/chkconfig 1:readahead-1.4.2-5.fc9.x86_64 requires /bin/sh 1:readahead-1.4.2-5.fc9.x86_64 requires /sbin/service readline-5.2-13.fc9.i386 requires /bin/sh readline-5.2-13.fc9.i386 requires /sbin/ldconfig readline-5.2-13.fc9.i386 requires /sbin/install-info readline-5.2-13.fc9.x86_64 requires /bin/sh readline-5.2-13.fc9.x86_64 requires /sbin/ldconfig readline-5.2-13.fc9.x86_64 requires /sbin/install-info readline-devel-5.2-13.fc9.i386 requires /bin/sh readline-devel-5.2-13.fc9.i386 requires /sbin/install-info readline-devel-5.2-13.fc9.x86_64 requires /sbin/install-info readline-devel-5.2-13.fc9.x86_64 requires /bin/sh recode-3.6-26.fc9.i386 requires /bin/sh recode-3.6-26.fc9.i386 requires /sbin/ldconfig recode-3.6-26.fc9.i386 requires /sbin/install-info recode-3.6-26.fc9.x86_64 requires /bin/sh recode-3.6-26.fc9.x86_64 requires /sbin/ldconfig recode-3.6-26.fc9.x86_64 requires /sbin/install-info redet-8.23-3.fc9.noarch requires /bin/sh redet-8.23-3.fc9.noarch requires /bin/sh redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/tty redhat-lsb-3.1-19.fc8.i386 requires /bin/cp redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/uniq redhat-lsb-3.1-19.fc8.i386 requires /bin/dd redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/pax redhat-lsb-3.1-19.fc8.i386 requires /bin/stty redhat-lsb-3.1-19.fc8.i386 requires /bin/ls redhat-lsb-3.1-19.fc8.i386 requires /bin/echo redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/tee redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/id redhat-lsb-3.1-19.fc8.i386 requires /bin/gzip redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/ipcrm redhat-lsb-3.1-19.fc8.i386 requires /bin/mknod redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/chfn redhat-lsb-3.1-19.fc8.i386 requires /bin/gettext redhat-lsb-3.1-19.fc8.i386 requires /bin/more redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/nohup redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/patch redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/make redhat-lsb-3.1-19.fc8.i386 requires /bin/touch redhat-lsb-3.1-19.fc8.i386 requires /bin/pwd redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/mkfifo redhat-lsb-3.1-19.fc8.i386 requires /bin/mv redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/join redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/fold redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/col redhat-lsb-3.1-19.fc8.i386 requires /bin/tar redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/msgfmt redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/tsort redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/crontab redhat-lsb-3.1-19.fc8.i386 requires /usr/lib/lsb/remove_initd redhat-lsb-3.1-19.fc8.i386 requires /bin/gunzip redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/file redhat-lsb-3.1-19.fc8.i386 requires /bin/sh redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/tail redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/chsh redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/csplit redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/find redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/at redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/od redhat-lsb-3.1-19.fc8.i386 requires /bin/mailx redhat-lsb-3.1-19.fc8.i386 requires /bin/hostname redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/ar redhat-lsb-3.1-19.fc8.i386 requires /bin/chgrp redhat-lsb-3.1-19.fc8.i386 requires /bin/true redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/wc redhat-lsb-3.1-19.fc8.i386 requires /bin/mount redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/md5sum redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/du redhat-lsb-3.1-19.fc8.i386 requires /bin/egrep redhat-lsb-3.1-19.fc8.i386 requires /bin/rm redhat-lsb-3.1-19.fc8.i386 requires /bin/basename redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/locale redhat-lsb-3.1-19.fc8.i386 requires /bin/df redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/paste redhat-lsb-3.1-19.fc8.i386 requires /usr/sbin/groupadd redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/killall redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/dirname redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/localedef redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/head redhat-lsb-3.1-19.fc8.i386 requires /bin/dmesg redhat-lsb-3.1-19.fc8.i386 requires /bin/sed redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/pr redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/logname redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/batch redhat-lsb-3.1-19.fc8.i386 requires /bin/awk redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/tr redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/bc redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/cmp redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/passwd redhat-lsb-3.1-19.fc8.i386 requires /bin/date redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/expand redhat-lsb-3.1-19.fc8.i386 requires /bin/chmod redhat-lsb-3.1-19.fc8.i386 requires /bin/rmdir redhat-lsb-3.1-19.fc8.i386 requires /bin/sleep redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/newgrp redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/expr redhat-lsb-3.1-19.fc8.i386 requires /bin/uname redhat-lsb-3.1-19.fc8.i386 requires /bin/ln redhat-lsb-3.1-19.fc8.i386 requires /bin/nice redhat-lsb-3.1-19.fc8.i386 requires /bin/cpio redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/install redhat-lsb-3.1-19.fc8.i386 requires /bin/su redhat-lsb-3.1-19.fc8.i386 requires /sbin/pidof redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/pathchk redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/groups redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/ipcs redhat-lsb-3.1-19.fc8.i386 requires /bin/bash redhat-lsb-3.1-19.fc8.i386 requires /bin/env redhat-lsb-3.1-19.fc8.i386 requires /bin/fgrep redhat-lsb-3.1-19.fc8.i386 requires /bin/grep redhat-lsb-3.1-19.fc8.i386 requires /bin/sort redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/iconv redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/split redhat-lsb-3.1-19.fc8.i386 requires /usr/sbin/groupdel redhat-lsb-3.1-19.fc8.i386 requires /bin/false redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/cksum redhat-lsb-3.1-19.fc8.i386 requires /bin/ed redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/man redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/logger redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/m4 redhat-lsb-3.1-19.fc8.i386 requires /bin/ps redhat-lsb-3.1-19.fc8.i386 requires /bin/cat redhat-lsb-3.1-19.fc8.i386 requires /usr/sbin/groupmod redhat-lsb-3.1-19.fc8.i386 requires /bin/cut redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/gencat redhat-lsb-3.1-19.fc8.i386 requires /usr/lib/lsb/install_initd redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/strip redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/nl redhat-lsb-3.1-19.fc8.i386 requires /sbin/shutdown redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/xargs redhat-lsb-3.1-19.fc8.i386 requires /bin/mkdir redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/time redhat-lsb-3.1-19.fc8.i386 requires /usr/sbin/userdel redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/unexpand redhat-lsb-3.1-19.fc8.i386 requires /bin/umount redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/getconf redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/diff redhat-lsb-3.1-19.fc8.i386 requires /usr/sbin/useradd redhat-lsb-3.1-19.fc8.i386 requires /sbin/fuser redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/printf redhat-lsb-3.1-19.fc8.i386 requires /usr/sbin/usermod redhat-lsb-3.1-19.fc8.i386 requires /bin/sh redhat-lsb-3.1-19.fc8.i386 requires /bin/kill redhat-lsb-3.1-19.fc8.i386 requires /bin/sync redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/renice redhat-lsb-3.1-19.fc8.i386 requires /bin/mktemp redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/test redhat-lsb-3.1-19.fc8.i386 requires /usr/bin/comm redhat-lsb-3.1-19.fc8.i386 requires /bin/chown redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/tty redhat-lsb-3.1-19.fc8.x86_64 requires /bin/cp redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/uniq redhat-lsb-3.1-19.fc8.x86_64 requires /bin/dd redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/pax redhat-lsb-3.1-19.fc8.x86_64 requires /bin/stty redhat-lsb-3.1-19.fc8.x86_64 requires /bin/ls redhat-lsb-3.1-19.fc8.x86_64 requires /bin/echo redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/tee redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/id redhat-lsb-3.1-19.fc8.x86_64 requires /bin/gzip redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/ipcrm redhat-lsb-3.1-19.fc8.x86_64 requires /bin/mknod redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/chfn redhat-lsb-3.1-19.fc8.x86_64 requires /bin/gettext redhat-lsb-3.1-19.fc8.x86_64 requires /bin/more redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/nohup redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/patch redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/make redhat-lsb-3.1-19.fc8.x86_64 requires /bin/touch redhat-lsb-3.1-19.fc8.x86_64 requires /bin/pwd redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/mkfifo redhat-lsb-3.1-19.fc8.x86_64 requires /usr/lib64/lsb/remove_initd redhat-lsb-3.1-19.fc8.x86_64 requires /bin/mv redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/join redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/fold redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/col redhat-lsb-3.1-19.fc8.x86_64 requires /bin/tar redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/msgfmt redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/tsort redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/crontab redhat-lsb-3.1-19.fc8.x86_64 requires /bin/gunzip redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/file redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/tail redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/chsh redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/csplit redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/find redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/at redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/od redhat-lsb-3.1-19.fc8.x86_64 requires /bin/mailx redhat-lsb-3.1-19.fc8.x86_64 requires /bin/hostname redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/ar redhat-lsb-3.1-19.fc8.x86_64 requires /bin/chgrp redhat-lsb-3.1-19.fc8.x86_64 requires /bin/true redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/wc redhat-lsb-3.1-19.fc8.x86_64 requires /bin/mount redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/md5sum redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/du redhat-lsb-3.1-19.fc8.x86_64 requires /bin/egrep redhat-lsb-3.1-19.fc8.x86_64 requires /bin/rm redhat-lsb-3.1-19.fc8.x86_64 requires /bin/basename redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/locale redhat-lsb-3.1-19.fc8.x86_64 requires /bin/df redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/paste redhat-lsb-3.1-19.fc8.x86_64 requires /usr/sbin/groupadd redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/killall redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/dirname redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/localedef redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/head redhat-lsb-3.1-19.fc8.x86_64 requires /bin/dmesg redhat-lsb-3.1-19.fc8.x86_64 requires /bin/sed redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/pr redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/logname redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/batch redhat-lsb-3.1-19.fc8.x86_64 requires /bin/awk redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/tr redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/bc redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/cmp redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/passwd redhat-lsb-3.1-19.fc8.x86_64 requires /bin/date redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/expand redhat-lsb-3.1-19.fc8.x86_64 requires /bin/chmod redhat-lsb-3.1-19.fc8.x86_64 requires /usr/lib64/lsb/install_initd redhat-lsb-3.1-19.fc8.x86_64 requires /bin/rmdir redhat-lsb-3.1-19.fc8.x86_64 requires /bin/sleep redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/newgrp redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/expr redhat-lsb-3.1-19.fc8.x86_64 requires /bin/uname redhat-lsb-3.1-19.fc8.x86_64 requires /bin/ln redhat-lsb-3.1-19.fc8.x86_64 requires /bin/nice redhat-lsb-3.1-19.fc8.x86_64 requires /bin/cpio redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/install redhat-lsb-3.1-19.fc8.x86_64 requires /bin/su redhat-lsb-3.1-19.fc8.x86_64 requires /sbin/pidof redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/pathchk redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/groups redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/ipcs redhat-lsb-3.1-19.fc8.x86_64 requires /bin/bash redhat-lsb-3.1-19.fc8.x86_64 requires /bin/env redhat-lsb-3.1-19.fc8.x86_64 requires /bin/fgrep redhat-lsb-3.1-19.fc8.x86_64 requires /bin/grep redhat-lsb-3.1-19.fc8.x86_64 requires /bin/sort redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/iconv redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/split redhat-lsb-3.1-19.fc8.x86_64 requires /usr/sbin/groupdel redhat-lsb-3.1-19.fc8.x86_64 requires /bin/false redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/cksum redhat-lsb-3.1-19.fc8.x86_64 requires /bin/ed redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/man redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/logger redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/m4 redhat-lsb-3.1-19.fc8.x86_64 requires /bin/ps redhat-lsb-3.1-19.fc8.x86_64 requires /bin/cat redhat-lsb-3.1-19.fc8.x86_64 requires /usr/sbin/groupmod redhat-lsb-3.1-19.fc8.x86_64 requires /bin/cut redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/gencat redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/strip redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/nl redhat-lsb-3.1-19.fc8.x86_64 requires /sbin/shutdown redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/xargs redhat-lsb-3.1-19.fc8.x86_64 requires /bin/mkdir redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/time redhat-lsb-3.1-19.fc8.x86_64 requires /usr/sbin/userdel redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/unexpand redhat-lsb-3.1-19.fc8.x86_64 requires /bin/umount redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/getconf redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/diff redhat-lsb-3.1-19.fc8.x86_64 requires /usr/sbin/useradd redhat-lsb-3.1-19.fc8.x86_64 requires /sbin/fuser redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/printf redhat-lsb-3.1-19.fc8.x86_64 requires /usr/sbin/usermod redhat-lsb-3.1-19.fc8.x86_64 requires /bin/sh redhat-lsb-3.1-19.fc8.x86_64 requires /bin/kill redhat-lsb-3.1-19.fc8.x86_64 requires /bin/sync redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/renice redhat-lsb-3.1-19.fc8.x86_64 requires /bin/mktemp redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/test redhat-lsb-3.1-19.fc8.x86_64 requires /usr/bin/comm redhat-lsb-3.1-19.fc8.x86_64 requires /bin/chown redhat-menus-8.9.11-3.fc9.noarch requires /bin/sh redhat-rpm-config-9.0.3-1.fc10.noarch requires /usr/bin/perl redhat-rpm-config-9.0.3-1.fc10.noarch requires /bin/bash redhat-rpm-config-9.0.3-1.fc10.noarch requires /bin/sh redland-1.0.7-1.fc9.i386 requires /sbin/ldconfig redland-1.0.7-1.fc9.x86_64 requires /sbin/ldconfig redland-devel-1.0.7-1.fc9.i386 requires /bin/sh redland-devel-1.0.7-1.fc9.x86_64 requires /bin/sh redmode-1.0-2.fc9.noarch requires /bin/bash referencer-1.1.2-1.fc10.x86_64 requires /bin/sh regexp-1.5-2jpp.1.fc9.x86_64 requires /bin/sh regexp-javadoc-1.5-2jpp.1.fc9.x86_64 requires /bin/sh regexp-javadoc-1.5-2jpp.1.fc9.x86_64 requires /bin/rm regexp-javadoc-1.5-2jpp.1.fc9.x86_64 requires /bin/ln regexxer-0.9-3.fc9.x86_64 requires /bin/sh rekall-2.4.6-4.fc9.i386 requires /bin/sh rekall-2.4.6-4.fc9.i386 requires /bin/sh rekall-2.4.6-4.fc9.x86_64 requires /bin/sh rekall-2.4.6-4.fc9.x86_64 requires /bin/sh rekall-extra-2.4.6-4.fc9.i386 requires /sbin/ldconfig rekall-extra-2.4.6-4.fc9.x86_64 requires /sbin/ldconfig rekall-mysql-2.4.6-4.fc9.i386 requires /sbin/ldconfig rekall-mysql-2.4.6-4.fc9.x86_64 requires /sbin/ldconfig rekall-odbc-2.4.6-4.fc9.i386 requires /sbin/ldconfig rekall-odbc-2.4.6-4.fc9.x86_64 requires /sbin/ldconfig rekall-postgresql-2.4.6-4.fc9.i386 requires /sbin/ldconfig rekall-postgresql-2.4.6-4.fc9.x86_64 requires /sbin/ldconfig rekall-python-2.4.6-4.fc9.i386 requires /sbin/ldconfig rekall-python-2.4.6-4.fc9.x86_64 requires /sbin/ldconfig rekall-sqlite-2.4.6-4.fc9.i386 requires /sbin/ldconfig rekall-sqlite-2.4.6-4.fc9.x86_64 requires /sbin/ldconfig remctl-2.11-6.fc9.i386 requires /sbin/ldconfig remctl-2.11-6.fc9.x86_64 requires /sbin/ldconfig remind-03.01.04-1.fc9.x86_64 requires /usr/bin/perl remind-03.01.04-1.fc9.x86_64 requires /bin/sh remind-gui-03.01.04-1.fc9.x86_64 requires /bin/sh renrot-0.25-4.fc9.noarch requires /usr/bin/perl renrot-0.25-4.fc9.noarch requires /bin/sh repoman-0.9-3.fc8.noarch requires /bin/sh repoman-0.9-3.fc8.noarch requires /usr/bin/env repoview-0.6.2-1.fc9.noarch requires /usr/bin/python resapplet-0.1.1-7.fc9.x86_64 requires /bin/sh revelation-0.4.11-4.1.x86_64 requires /bin/sh revelation-0.4.11-4.1.x86_64 requires /usr/bin/env revisor-cli-2.1.0-2.fc10.noarch requires /usr/bin/python2 rgmanager-2.0.23-3.fc9.x86_64 requires /bin/sh rgmanager-2.0.23-3.fc9.x86_64 requires /sbin/findfs rgmanager-2.0.23-3.fc9.x86_64 requires /bin/bash rgmanager-2.0.23-3.fc9.x86_64 requires /bin/sh rgmanager-2.0.23-3.fc9.x86_64 requires /sbin/chkconfig rhm-0.2-11.fc9.i386 requires /bin/sh rhm-0.2-11.fc9.i386 requires /sbin/service rhm-0.2-11.fc9.i386 requires /bin/bash rhm-0.2-11.fc9.x86_64 requires /bin/sh rhm-0.2-11.fc9.x86_64 requires /sbin/service rhm-0.2-11.fc9.x86_64 requires /bin/bash rhpl-0.215-3.x86_64 requires /usr/bin/python rhythmbox-0.11.5-9.fc9.i386 requires /bin/sh rhythmbox-0.11.5-9.fc9.i386 requires libtotem-plparser.so.10 rhythmbox-0.11.5-9.fc9.x86_64 requires /bin/sh rhythmbox-0.11.5-9.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) rinetd-0.62-7.fc9.x86_64 requires /bin/sh rinetd-0.62-7.fc9.x86_64 requires /sbin/chkconfig rinetd-0.62-7.fc9.x86_64 requires /bin/sh rinetd-0.62-7.fc9.x86_64 requires /sbin/service rkhunter-1.3.2-2.fc9.noarch requires /usr/bin/perl rkhunter-1.3.2-2.fc9.noarch requires /bin/sh rkward-0.5.0b-2.fc10.x86_64 requires /bin/sh rkward-0.5.0b-2.fc10.x86_64 requires /bin/sh rlog-1.3.7-6.fc9.i386 requires /sbin/ldconfig rlog-1.3.7-6.fc9.x86_64 requires /sbin/ldconfig 1:rng-utils-2.0-1.15.1.fc9.x86_64 requires /sbin/chkconfig 1:rng-utils-2.0-1.15.1.fc9.x86_64 requires /sbin/service roadstencil-fonts-1.0-2.fc10.noarch requires /bin/sh rogue-5.4.5-2.fc9.x86_64 requires /bin/sh rosegarden4-1.6.1-2.fc9.x86_64 requires /bin/sh rosegarden4-1.6.1-2.fc9.x86_64 requires /bin/bash rott-registered-1.0-5.fc9.x86_64 requires /bin/sh rott-registered-1.0-5.fc9.x86_64 requires /bin/bash rott-shareware-1.0-5.fc9.x86_64 requires /bin/sh rott-shareware-1.0-5.fc9.x86_64 requires /bin/bash roundcubemail-0.1-1.fc9.noarch requires /bin/sh roundup-1.4.4-1.fc9.noarch requires /bin/sh roundup-1.4.4-1.fc9.noarch requires /bin/bash roundup-1.4.4-1.fc9.noarch requires /sbin/chkconfig roundup-1.4.4-1.fc9.noarch requires /usr/bin/env roundup-1.4.4-1.fc9.noarch requires /usr/bin/python roundup-1.4.4-1.fc9.noarch requires /sbin/service roxterm-1.11.1-1.fc9.x86_64 requires /bin/sh rp-pppoe-3.8-3.fc9.x86_64 requires /bin/bash rp-pppoe-3.8-3.fc9.x86_64 requires /bin/sh rpc2-2.7-1.fc10.i386 requires /sbin/ldconfig rpc2-2.7-1.fc10.x86_64 requires /sbin/ldconfig rpcbind-0.1.4-14.fc9.x86_64 requires /usr/sbin/userdel rpcbind-0.1.4-14.fc9.x86_64 requires /bin/sh rpcbind-0.1.4-14.fc9.x86_64 requires /usr/sbin/groupadd rpcbind-0.1.4-14.fc9.x86_64 requires /usr/sbin/useradd rpcbind-0.1.4-14.fc9.x86_64 requires /bin/sh rpcbind-0.1.4-14.fc9.x86_64 requires /usr/sbin/groupdel rpcbind-0.1.4-14.fc9.x86_64 requires /sbin/chkconfig rpl-1.5.3-4.fc6.noarch requires /usr/bin/env rpm-4.4.2.3-2.fc9.x86_64 requires /bin/sh rpm-4.4.2.3-2.fc9.x86_64 requires /bin/bash rpm-4.4.2.3-2.fc9.x86_64 requires /bin/sh rpm-build-4.4.2.3-2.fc9.x86_64 requires /bin/bash rpm-build-4.4.2.3-2.fc9.x86_64 requires /bin/sh rpm-build-4.4.2.3-2.fc9.x86_64 requires /usr/bin/perl rpm-libs-4.4.2.3-2.fc9.i386 requires /sbin/ldconfig rpm-libs-4.4.2.3-2.fc9.x86_64 requires /sbin/ldconfig rpmdevtools-6.6-1.fc9.noarch requires /usr/bin/python rpmdevtools-6.6-1.fc9.noarch requires /bin/bash rpmdevtools-6.6-1.fc9.noarch requires /bin/sh rpmdevtools-6.6-1.fc9.noarch requires /usr/bin/perl rpmlint-0.82-3.fc9.noarch requires /bin/sh rpmlint-0.82-3.fc9.noarch requires /usr/bin/python rpmrebuild-2.2.2-1.fc10.noarch requires /bin/sh rpmrebuild-2.2.2-1.fc10.noarch requires /bin/bash rpmrebuild-2.2.2-1.fc10.noarch requires /bin/sh rpy-1.0.2-1.fc10.x86_64 requires /bin/sh rpy-1.0.2-1.fc10.x86_64 requires /sbin/install-info rrdtool-1.3-0.14.beta4.fc10.i386 requires /sbin/ldconfig rrdtool-1.3-0.14.beta4.fc10.x86_64 requires /sbin/ldconfig rrdtool-tcl-1.3-0.14.beta4.fc10.x86_64 requires /bin/sh rsh-server-0.17-50.fc10.x86_64 requires /etc/pam.d/system-auth rsibreak-0.8.0-5.fc9.x86_64 requires /bin/sh rsnapshot-1.3.0-1.fc8.noarch requires /bin/sh rsnapshot-1.3.0-1.fc8.noarch requires /usr/bin/perl rss-glx-0.8.1.p-19.fc9.x86_64 requires /usr/bin/env rss-glx-xscreensaver-0.8.1.p-19.fc9.x86_64 requires /bin/sh rss2email-2.62-1.1.noarch requires /bin/sh rss2email-2.62-1.1.noarch requires /usr/bin/python rsyslog-3.16.1-1.fc10.x86_64 requires /bin/sh rsyslog-3.16.1-1.fc10.x86_64 requires /sbin/service rsyslog-3.16.1-1.fc10.x86_64 requires /bin/bash rsyslog-3.16.1-1.fc10.x86_64 requires /bin/sh rsyslog-3.16.1-1.fc10.x86_64 requires /sbin/chkconfig rt3-3.6.6-5.fc9.noarch requires /usr/bin/perl rt3-3.6.6-5.fc9.noarch requires /bin/rm rt3-3.6.6-5.fc9.noarch requires /bin/sh rt3-mailgate-3.6.6-5.fc9.noarch requires /usr/bin/perl rubberband-1.0.1-1.fc9.i386 requires /sbin/ldconfig rubberband-1.0.1-1.fc9.x86_64 requires /sbin/ldconfig ruby-1.8.6.114-1.fc9.x86_64 requires /usr/bin/ruby ruby-cairo-1.5.1-1.fc9.x86_64 requires /usr/bin/env ruby-gettext-package-1.90.0-1.fc9.noarch requires /usr/bin/ruby ruby-gettext-package-doc-1.90.0-1.fc9.noarch requires /usr/bin/ruby ruby-gettext-package-doc-1.90.0-1.fc9.noarch requires /bin/sh ruby-gettext-package-doc-1.90.0-1.fc9.noarch requires /usr/bin/env ruby-gtk2-0.16.0-28.fc9.x86_64 requires /usr/bin/env ruby-hyperestraier-1.4.13-2.fc9.x86_64 requires /usr/bin/ruby ruby-irb-1.8.6.114-1.fc9.x86_64 requires /usr/bin/ruby ruby-libglade2-0.16.0-28.fc9.x86_64 requires /usr/bin/env ruby-libs-1.8.6.114-1.fc9.i386 requires /sbin/ldconfig ruby-libs-1.8.6.114-1.fc9.x86_64 requires /sbin/ldconfig ruby-panelapplet2-0.16.0-28.fc9.x86_64 requires /usr/bin/env ruby-panelapplet2-0.16.0-28.fc9.x86_64 requires /usr/bin/ruby ruby-poppler-0.16.0-28.fc9.x86_64 requires /usr/bin/env ruby-qdbm-1.8.77-3.fc9.x86_64 requires /usr/bin/ruby ruby-racc-1.4.5-2.fc6.noarch requires /usr/bin/ruby ruby-rdoc-1.8.6.114-1.fc9.x86_64 requires /usr/bin/ruby ruby-ri-1.8.6.114-1.fc9.x86_64 requires /usr/bin/ruby ruby-rsvg-0.16.0-28.fc9.x86_64 requires /usr/bin/env ruby-tcltk-1.8.6.114-1.fc9.x86_64 requires /usr/bin/env ruby-vte-0.16.0-28.fc9.x86_64 requires /usr/bin/env rubygem-activeldap-0.10.0-10.fc10.noarch requires /usr/bin/ruby rubygem-activeldap-0.10.0-10.fc10.noarch requires /usr/bin/env rubygem-activeldap-0.10.0-10.fc10.noarch requires /bin/sh rubygem-daemons-1.0.7-2.fc8.noarch requires /usr/bin/env rubygem-gem2rpm-0.5.3-1.fc10.noarch requires /usr/bin/env rubygem-gem_plugin-0.2.2-2.fc8.noarch requires /usr/bin/ruby rubygem-hoe-1.5.1-6.fc10.noarch requires /usr/bin/env rubygem-mongrel-1.0.1-6.fc9.x86_64 requires /usr/bin/ruby rubygem-mongrel-1.0.1-6.fc9.x86_64 requires /usr/bin/env rubygem-rails-2.0.2-2.fc9.noarch requires /usr/bin/ruby rubygem-rails-2.0.2-2.fc9.noarch requires /usr/bin/env rubygem-rake-0.8.1-2.fc10.noarch requires /usr/bin/ruby rubygem-rubyforge-0.4.5-2.fc10.noarch requires /usr/bin/env rubygem-zoom-0.4.1-2.fc9.3.x86_64 requires /usr/bin/ruby rubygems-0.9.4-1.fc8.noarch requires /usr/bin/ruby rubyripper-0.5.0-2.fc9.noarch requires /usr/bin/env rubyripper-gui-0.5.0-2.fc9.noarch requires /usr/bin/env rudecgi-5.1.0-2.fc9.i386 requires /sbin/ldconfig rudecgi-5.1.0-2.fc9.x86_64 requires /sbin/ldconfig rudeconfig-5.0.5-1.fc7.i386 requires /sbin/ldconfig rudeconfig-5.0.5-1.fc7.x86_64 requires /sbin/ldconfig rudesocket-1.3.0-2.fc9.i386 requires /sbin/ldconfig rudesocket-1.3.0-2.fc9.x86_64 requires /sbin/ldconfig rusers-server-0.17-53.fc9.x86_64 requires /bin/sh rusers-server-0.17-53.fc9.x86_64 requires /bin/bash rusers-server-0.17-53.fc9.x86_64 requires /sbin/chkconfig rusers-server-0.17-53.fc9.x86_64 requires /bin/sh rvm-1.15-1.fc10.i386 requires /sbin/ldconfig rvm-1.15-1.fc10.x86_64 requires /sbin/ldconfig rwall-server-0.17-28.fc9.x86_64 requires /bin/sh rwall-server-0.17-28.fc9.x86_64 requires /etc/init.d rwall-server-0.17-28.fc9.x86_64 requires /sbin/chkconfig rwall-server-0.17-28.fc9.x86_64 requires /bin/sh rwho-0.17-29.fc9.x86_64 requires /bin/sh rwho-0.17-29.fc9.x86_64 requires /sbin/chkconfig rwho-0.17-29.fc9.x86_64 requires /bin/sh rwho-0.17-29.fc9.x86_64 requires /etc/init.d rxvt-2.7.10-15.fc9.x86_64 requires /bin/sh sabayon-2.22.0-3.fc10.x86_64 requires /bin/sh sabayon-2.22.0-3.fc10.x86_64 requires /usr/bin/env sabayon-apply-2.22.0-3.fc10.x86_64 requires /bin/bash sabayon-apply-2.22.0-3.fc10.x86_64 requires /usr/bin/env safekeep-common-1.0.3-2.fc9.noarch requires /usr/bin/python safekeep-server-1.0.3-2.fc9.noarch requires /bin/sh safekeep-server-1.0.3-2.fc9.noarch requires /usr/sbin/groupadd safekeep-server-1.0.3-2.fc9.noarch requires /usr/sbin/useradd safekeep-server-1.0.3-2.fc9.noarch requires /bin/sh sagator-1.0.0-1.fc9.noarch requires /bin/sh sagator-1.0.0-1.fc9.noarch requires /sbin/chkconfig sagator-1.0.0-1.fc9.noarch requires /usr/bin/python2 sagator-1.0.0-1.fc9.noarch requires /bin/sh sagator-1.0.0-1.fc9.noarch requires /usr/bin/python sagator-1.0.0-1.fc9.noarch requires /sbin/service sage-0.2.0-3.fc9.i386 requires /sbin/ldconfig sage-0.2.0-3.fc9.x86_64 requires /sbin/ldconfig samba-3.2.0-1.pre3.10.fc10.x86_64 requires /bin/sh samba-3.2.0-1.pre3.10.fc10.x86_64 requires /sbin/service samba-3.2.0-1.pre3.10.fc10.x86_64 requires /bin/bash samba-3.2.0-1.pre3.10.fc10.x86_64 requires /bin/sh samba-3.2.0-1.pre3.10.fc10.x86_64 requires /usr/bin/perl samba-3.2.0-1.pre3.10.fc10.x86_64 requires /sbin/chkconfig samba-client-3.2.0-1.pre3.10.fc10.x86_64 requires /usr/bin/perl samba-client-3.2.0-1.pre3.10.fc10.x86_64 requires /bin/sh samba-common-3.2.0-1.pre3.10.fc10.i386 requires /bin/sh samba-common-3.2.0-1.pre3.10.fc10.i386 requires /usr/sbin/groupadd samba-common-3.2.0-1.pre3.10.fc10.i386 requires /sbin/service samba-common-3.2.0-1.pre3.10.fc10.i386 requires /sbin/chkconfig samba-common-3.2.0-1.pre3.10.fc10.x86_64 requires /bin/sh samba-common-3.2.0-1.pre3.10.fc10.x86_64 requires /usr/sbin/groupadd samba-common-3.2.0-1.pre3.10.fc10.x86_64 requires /sbin/service samba-common-3.2.0-1.pre3.10.fc10.x86_64 requires /sbin/chkconfig samba-winbind-3.2.0-1.pre3.10.fc10.i386 requires /bin/sh samba-winbind-3.2.0-1.pre3.10.fc10.i386 requires /usr/sbin/groupadd samba-winbind-3.2.0-1.pre3.10.fc10.i386 requires /sbin/service samba-winbind-3.2.0-1.pre3.10.fc10.i386 requires /bin/sh samba-winbind-3.2.0-1.pre3.10.fc10.i386 requires /sbin/chkconfig samba-winbind-3.2.0-1.pre3.10.fc10.x86_64 requires /bin/sh samba-winbind-3.2.0-1.pre3.10.fc10.x86_64 requires /usr/sbin/groupadd samba-winbind-3.2.0-1.pre3.10.fc10.x86_64 requires /sbin/service samba-winbind-3.2.0-1.pre3.10.fc10.x86_64 requires /bin/sh samba-winbind-3.2.0-1.pre3.10.fc10.x86_64 requires /sbin/chkconfig samyak-fonts-devanagari-1.2.0-2.fc9.noarch requires /bin/sh samyak-fonts-gujarati-1.2.0-2.fc9.noarch requires /bin/sh samyak-fonts-malayalam-1.2.0-2.fc9.noarch requires /bin/sh samyak-fonts-oriya-1.2.0-2.fc9.noarch requires /bin/sh samyak-fonts-tamil-1.2.0-2.fc9.noarch requires /bin/sh sane-backends-1.0.19-10.fc9.x86_64 requires /bin/bash sane-backends-devel-1.0.19-10.fc9.i386 requires /bin/sh sane-backends-devel-1.0.19-10.fc9.x86_64 requires /bin/sh sane-backends-libs-1.0.19-10.fc9.i386 requires /sbin/ldconfig sane-backends-libs-1.0.19-10.fc9.x86_64 requires /sbin/ldconfig sarai-fonts-1.0-4.fc9.noarch requires /bin/sh saxon-6.5.5-1jpp.2.fc7.noarch requires /bin/sh saxon-6.5.5-1jpp.2.fc7.noarch requires /usr/sbin/update-alternatives sazanami-fonts-gothic-0.20040629-4.20061016.fc8.noarch requires /bin/sh sazanami-fonts-mincho-0.20040629-4.20061016.fc8.noarch requires /bin/sh sbcl-1.0.13-1.fc9.x86_64 requires /bin/sh sbcl-1.0.13-1.fc9.x86_64 requires /sbin/install-info sblim-cmpi-base-1.5.4-7.fc7.i386 requires /bin/sh sblim-cmpi-base-1.5.4-7.fc7.i386 requires /sbin/ldconfig sblim-cmpi-base-1.5.4-7.fc7.i386 requires /bin/sh sblim-cmpi-base-1.5.4-7.fc7.x86_64 requires /bin/sh sblim-cmpi-base-1.5.4-7.fc7.x86_64 requires /sbin/ldconfig sblim-cmpi-base-1.5.4-7.fc7.x86_64 requires /bin/sh sblim-cmpi-base-test-1.5.4-7.fc7.x86_64 requires /usr/bin/perl sblim-cmpi-base-test-1.5.4-7.fc7.x86_64 requires /bin/bash sblim-cmpi-base-test-1.5.4-7.fc7.x86_64 requires /bin/sh sblim-testsuite-1.2.4-3.fc6.noarch requires /usr/bin/perl sblim-testsuite-1.2.4-3.fc6.noarch requires /bin/sh scalapack-1.7.5-2.fc9.i386 requires /sbin/ldconfig scalapack-1.7.5-2.fc9.x86_64 requires /sbin/ldconfig scanbuttond-0.2.3-12.fc9.x86_64 requires /bin/sh scanbuttond-0.2.3-12.fc9.x86_64 requires /sbin/service scanbuttond-0.2.3-12.fc9.x86_64 requires /sbin/chkconfig scanbuttond-0.2.3-12.fc9.x86_64 requires /sbin/ldconfig scanbuttond-0.2.3-12.fc9.x86_64 requires /bin/bash scanbuttond-0.2.3-12.fc9.x86_64 requires /bin/sh scapy-1.1.1-4.fc8.noarch requires /usr/bin/env schismtracker-0.5-0.7.rc1.fc9.x86_64 requires /bin/sh schroedinger-1.0.0-1.fc9.i386 requires /sbin/ldconfig schroedinger-1.0.0-1.fc9.x86_64 requires /sbin/ldconfig scidavis-0.1.3-2.fc10.x86_64 requires /bin/sh scim-1.4.7-23.fc10.x86_64 requires /bin/sh scim-1.4.7-23.fc10.x86_64 requires /usr/sbin/alternatives scim-1.4.7-23.fc10.x86_64 requires /bin/sh scim-bridge-gtk-0.4.15-5.fc9.i386 requires /bin/sh scim-bridge-gtk-0.4.15-5.fc9.x86_64 requires /bin/sh scim-gtk-1.4.7-23.fc10.i386 requires /bin/sh scim-gtk-1.4.7-23.fc10.x86_64 requires /bin/sh scim-input-pad-0.1.1-8.fc9.i386 requires /sbin/ldconfig scim-input-pad-0.1.1-8.fc9.i386 requires /bin/sh scim-input-pad-0.1.1-8.fc9.x86_64 requires /sbin/ldconfig scim-input-pad-0.1.1-8.fc9.x86_64 requires /bin/sh scim-libs-1.4.7-23.fc10.i386 requires /sbin/ldconfig scim-libs-1.4.7-23.fc10.x86_64 requires /sbin/ldconfig scim-python-pinyin-0.1.12-1.fc10.x86_64 requires /bin/sh scim-python-xingma-0.1.12-1.fc10.x86_64 requires /usr/bin/python scim-python-xingma-cangjie-0.1.12-1.fc10.x86_64 requires /bin/sh scim-python-xingma-erbi-0.1.12-1.fc10.x86_64 requires /bin/sh scim-python-xingma-wubi-0.1.12-1.fc10.x86_64 requires /bin/sh scim-python-xingma-zhengma-0.1.12-1.fc10.x86_64 requires /bin/sh scim-tables-0.5.7-5.fc9.x86_64 requires /sbin/ldconfig scim-tomoe-0.6.0-2.fc8.x86_64 requires /bin/sh scons-0.98.3-2.fc10.noarch requires /usr/bin/python scorched3d-41.3-2.fc9.x86_64 requires /bin/sh scorchwentbonkers-1.1-5.fc9.x86_64 requires /bin/sh scratchpad-0.3.0-4.fc9.x86_64 requires /bin/sh screen-4.0.3-11.fc9.x86_64 requires /bin/sh screen-4.0.3-11.fc9.x86_64 requires /usr/sbin/groupadd screen-4.0.3-11.fc9.x86_64 requires /sbin/install-info scribes-0.3.3.3-2.fc9.noarch requires /bin/sh scribes-0.3.3.3-2.fc9.noarch requires /usr/bin/env scribus-1.3.4-5.fc9.x86_64 requires /bin/sh scsi-target-utils-0.0-4.20071227snap.fc9.x86_64 requires /bin/sh scsi-target-utils-0.0-4.20071227snap.fc9.x86_64 requires /sbin/service scsi-target-utils-0.0-4.20071227snap.fc9.x86_64 requires /sbin/chkconfig scsi-target-utils-0.0-4.20071227snap.fc9.x86_64 requires /bin/sh scummvm-0.11.1-2.fc9.x86_64 requires /bin/sh scythia-0.9.3-2.2.fc9.x86_64 requires /bin/sh sdcc-2.6.0-12.fc9.x86_64 requires /bin/sh sdcc-libc-sources-2.6.0-12.fc9.x86_64 requires /bin/sh sdljava-0.9.1-9.fc9.x86_64 requires /bin/sh sdljava-demo-0.9.1-9.fc9.x86_64 requires /usr/share/fonts/dejavu/DejaVuSans-BoldOblique.ttf sdljava-demo-0.9.1-9.fc9.x86_64 requires /usr/share/fonts/dejavu/DejaVuSans-Bold.ttf sdljava-demo-0.9.1-9.fc9.x86_64 requires /usr/share/fonts/dejavu/DejaVuSans-Oblique.ttf sdljava-demo-0.9.1-9.fc9.x86_64 requires /usr/share/fonts/dejavu/DejaVuSans.ttf sdljava-demo-0.9.1-9.fc9.x86_64 requires /bin/sh sdljava-javadoc-0.9.1-9.fc9.x86_64 requires /bin/sh seahorse-2.22.1-1.fc9.i386 requires /bin/sh seahorse-2.22.1-1.fc9.i386 requires /bin/sh seahorse-2.22.1-1.fc9.x86_64 requires /bin/sh seahorse-2.22.1-1.fc9.x86_64 requires /bin/sh seahorse-adventures-1.0-2.fc8.noarch requires /bin/sh seahorse-adventures-1.0-2.fc8.noarch requires /usr/bin/env seahorse-adventures-1.0-2.fc8.noarch requires /usr/bin/python seamonkey-1.1.9-4.fc9.x86_64 requires /bin/sh seamonkey-1.1.9-4.fc9.x86_64 requires /bin/sh sear-0.6.3-10.fc9.x86_64 requires /bin/sh sec-2.4.1-1.fc8.noarch requires /bin/sh sec-2.4.1-1.fc8.noarch requires /bin/bash sec-2.4.1-1.fc8.noarch requires /usr/bin/perl sectool-0.7.3-1.fc10.noarch requires /usr/bin/env sectool-0.7.3-1.fc10.noarch requires /usr/bin/python sectool-gui-0.7.3-1.fc10.noarch requires /usr/bin/python sed-4.1.5-10.fc9.x86_64 requires /bin/sh sed-4.1.5-10.fc9.x86_64 requires /sbin/install-info seedit-2.2.0-2.fc9.x86_64 requires /bin/sh seedit-2.2.0-2.fc9.x86_64 requires /usr/bin/python seedit-gui-2.2.0-2.fc9.x86_64 requires /usr/bin/python seedit-policy-2.2.0-2.fc9.x86_64 requires /bin/sh seedit-policy-2.2.0-2.fc9.x86_64 requires /bin/sh seekwatcher-0.10-1.fc9.noarch requires /usr/bin/env selinux-policy-3.3.1-45.fc10.noarch requires /bin/sh selinux-policy-devel-3.3.1-45.fc10.noarch requires /bin/sh selinux-policy-devel-3.3.1-45.fc10.noarch requires /usr/bin/env selinux-policy-mls-3.3.1-45.fc10.noarch requires /bin/sh selinux-policy-targeted-3.3.1-45.fc10.noarch requires /bin/sh selinux-policy-targeted-3.3.1-45.fc10.noarch requires /bin/sh sendmail-8.14.2-4.fc9.i386 requires /bin/sh sendmail-8.14.2-4.fc9.i386 requires /usr/sbin/saslauthd sendmail-8.14.2-4.fc9.i386 requires /usr/sbin/alternatives sendmail-8.14.2-4.fc9.i386 requires /bin/bash sendmail-8.14.2-4.fc9.x86_64 requires /bin/sh sendmail-8.14.2-4.fc9.x86_64 requires /usr/sbin/saslauthd sendmail-8.14.2-4.fc9.x86_64 requires /bin/bash sendmail-8.14.2-4.fc9.x86_64 requires /usr/sbin/alternatives sendmail-cf-8.14.2-4.fc9.x86_64 requires /bin/sh sepostgresql-8.3.1-2.197.fc10.x86_64 requires /bin/sh sepostgresql-8.3.1-2.197.fc10.x86_64 requires /sbin/service sepostgresql-8.3.1-2.197.fc10.x86_64 requires /bin/sh sepostgresql-8.3.1-2.197.fc10.x86_64 requires /sbin/chkconfig seq24-0.8.7-8.fc8.x86_64 requires /bin/sh ser-0.9.6-14.fc9.x86_64 requires /bin/sh ser-0.9.6-14.fc9.x86_64 requires /bin/bash ser-0.9.6-14.fc9.x86_64 requires /sbin/chkconfig ser-0.9.6-14.fc9.x86_64 requires /bin/sh ser-0.9.6-14.fc9.x86_64 requires /sbin/service ser-mysql-0.9.6-14.fc9.x86_64 requires /bin/sh ser-postgresql-0.9.6-14.fc9.x86_64 requires /bin/sh ser2net-2.4-2.fc9.1.x86_64 requires /bin/sh ser2net-2.4-2.fc9.1.x86_64 requires /bin/sh ser2net-2.4-2.fc9.1.x86_64 requires /sbin/service sergueis-destiny-1.1-4.fc8.noarch requires /bin/sh sergueis-destiny-1.1-4.fc8.noarch requires /bin/bash serpentine-0.9-2.fc9.noarch requires /bin/sh serpentine-0.9-2.fc9.noarch requires /usr/bin/env setools-console-3.3.4-1.fc9.x86_64 requires /bin/sh setools-gui-3.3.4-1.fc9.x86_64 requires /bin/sh setools-libs-3.3.4-1.fc9.i386 requires /sbin/ldconfig setools-libs-3.3.4-1.fc9.x86_64 requires /sbin/ldconfig setools-libs-java-3.3.4-1.fc9.i386 requires /sbin/ldconfig setools-libs-java-3.3.4-1.fc9.x86_64 requires /sbin/ldconfig setools-libs-tcl-3.3.4-1.fc9.x86_64 requires /sbin/ldconfig setroubleshoot-2.0.6-1.fc9.noarch requires /bin/sh setroubleshoot-2.0.6-1.fc9.noarch requires /usr/bin/update-desktop-database setroubleshoot-plugins-2.0.4-5.fc9.noarch requires /bin/sh setroubleshoot-server-2.0.6-1.fc9.noarch requires /bin/sh setroubleshoot-server-2.0.6-1.fc9.noarch requires /bin/bash setroubleshoot-server-2.0.6-1.fc9.noarch requires /sbin/chkconfig setroubleshoot-server-2.0.6-1.fc9.noarch requires /usr/bin/python setroubleshoot-server-2.0.6-1.fc9.noarch requires /sbin/service sg3_utils-libs-1.25-4.fc9.i386 requires /sbin/ldconfig sg3_utils-libs-1.25-4.fc9.x86_64 requires /sbin/ldconfig sgml-common-0.6.3-23.fc9.noarch requires /bin/sh shapelib-1.2.10-16.20060304cvs.i386 requires /sbin/ldconfig shapelib-1.2.10-16.20060304cvs.i386 requires /bin/sh shapelib-1.2.10-16.20060304cvs.x86_64 requires /sbin/ldconfig shapelib-1.2.10-16.20060304cvs.x86_64 requires /bin/sh shared-mime-info-0.30-1.fc10.x86_64 requires /bin/sh sharutils-4.6.3-2.fc9.x86_64 requires /bin/sh sharutils-4.6.3-2.fc9.x86_64 requires /bin/bash sharutils-4.6.3-2.fc9.x86_64 requires /usr/bin/perl sharutils-4.6.3-2.fc9.x86_64 requires /sbin/install-info shippy-1.3.3.7-7.fc9.x86_64 requires /bin/sh shippy-common-1.3.3.7-7.fc9.x86_64 requires /bin/bash shorewall-common-4.0.10-2.fc10.noarch requires /bin/sh shorewall-common-4.0.10-2.fc10.noarch requires /sbin/chkconfig shorewall-common-4.0.10-2.fc10.noarch requires /bin/sh shorewall-common-4.0.10-2.fc10.noarch requires /sbin/service shorewall-lite-4.0.10-2.fc10.noarch requires /bin/sh shorewall-lite-4.0.10-2.fc10.noarch requires /sbin/chkconfig shorewall-lite-4.0.10-2.fc10.noarch requires /bin/sh shorewall-lite-4.0.10-2.fc10.noarch requires /sbin/service shorewall-perl-4.0.10-2.fc10.noarch requires /usr/bin/perl shorewall-shell-4.0.10-2.fc10.noarch requires /bin/sh showimg-0.9.5-16.fc9.i386 requires /sbin/ldconfig showimg-0.9.5-16.fc9.x86_64 requires /sbin/ldconfig siege-2.67-1.fc10.x86_64 requires /usr/bin/perl siege-2.67-1.fc10.x86_64 requires /bin/sh sigscheme-0.8.3-1.fc10.i386 requires /sbin/ldconfig sigscheme-0.8.3-1.fc10.x86_64 requires /sbin/ldconfig silkscreen-fonts-1.0-1.fc9.noarch requires /bin/sh simcoupe-1.0-4.fc10.x86_64 requires /bin/sh sinjdoc-0.5-6.fc9.x86_64 requires /bin/sh sinjdoc-0.5-6.fc9.x86_64 requires /bin/sh six-0.5.3-9.fc9.x86_64 requires /bin/sh skencil-0.6.17-18.20070606svn.fc9.x86_64 requires /bin/sh skencil-0.6.17-18.20070606svn.fc9.x86_64 requires /usr/bin/env skencil-0.6.17-18.20070606svn.fc9.x86_64 requires /usr/bin/python ski-devel-1.3.2-5.fc10.i386 requires /bin/sh ski-devel-1.3.2-5.fc10.x86_64 requires /bin/sh ski-libs-1.3.2-5.fc10.i386 requires /sbin/ldconfig ski-libs-1.3.2-5.fc10.x86_64 requires /sbin/ldconfig skstream-0.3.6-3.fc9.i386 requires /sbin/ldconfig skstream-0.3.6-3.fc9.x86_64 requires /sbin/ldconfig slang-2.1.3-3.fc9.i386 requires /sbin/ldconfig slang-2.1.3-3.fc9.x86_64 requires /sbin/ldconfig slang-slsh-2.1.3-3.fc9.x86_64 requires /usr/bin/env slib-3b1-1.fc9.noarch requires /bin/sh slib-3b1-1.fc9.noarch requires /sbin/install-info slim-1.3.0-4.fc9.x86_64 requires /sbin/shutdown slim-1.3.0-4.fc9.x86_64 requires /etc/pam.d slim-1.3.0-4.fc9.x86_64 requires /usr/bin/perl slim-1.3.0-4.fc9.x86_64 requires /bin/sh slingshot-0.8.1p-1.fc8.noarch requires /bin/sh slingshot-0.8.1p-1.fc8.noarch requires /bin/bash sloccount-2.26-7.fc9.x86_64 requires /usr/bin/perl sloccount-2.26-7.fc9.x86_64 requires /bin/sh slrn-pull-0.9.8.1pl1-8.20070716cvs.fc9.x86_64 requires /bin/sh smart-0.52-54.fc9.x86_64 requires /usr/bin/python smarteiffel-2.3-2.fc9.x86_64 requires /bin/sh 1:smartmontools-5.38-4.1.fc10.x86_64 requires /bin/sh 1:smartmontools-5.38-4.1.fc10.x86_64 requires /bin/bash 1:smartmontools-5.38-4.1.fc10.x86_64 requires /sbin/chkconfig 1:smartmontools-5.38-4.1.fc10.x86_64 requires /bin/sh 1:smartmontools-5.38-4.1.fc10.x86_64 requires /sbin/service 1:smartmontools-config-5.38-4.1.fc10.x86_64 requires /usr/bin/python smashteroid-1.11-4.fc9.x86_64 requires /bin/sh smb4k-0.9.4-1.fc10.i386 requires /bin/sh smb4k-0.9.4-1.fc10.x86_64 requires /bin/sh smbldap-tools-0.9.4-2.fc9.noarch requires /usr/bin/perl smc-fonts-dyuthi-04-6.fc9.noarch requires /bin/sh smc-fonts-meera-04-6.fc9.noarch requires /bin/sh smc-fonts-rachana-04-6.fc9.noarch requires /bin/sh smc-fonts-raghumalayalam-04-6.fc9.noarch requires /bin/sh smc-fonts-suruma-04-6.fc9.noarch requires /bin/sh smolt-1.1.1.1-4.fc9.noarch requires /bin/sh smolt-1.1.1.1-4.fc9.noarch requires /bin/bash smolt-1.1.1.1-4.fc9.noarch requires /sbin/chkconfig smolt-1.1.1.1-4.fc9.noarch requires /usr/sbin/groupadd smolt-1.1.1.1-4.fc9.noarch requires /usr/sbin/useradd smolt-1.1.1.1-4.fc9.noarch requires /usr/bin/python smolt-1.1.1.1-4.fc9.noarch requires /sbin/service smolt-server-1.1.1.1-4.fc9.noarch requires /usr/bin/python smstools-3.0.10-2.fc9.x86_64 requires /bin/sh smstools-3.0.10-2.fc9.x86_64 requires /bin/bash smstools-3.0.10-2.fc9.x86_64 requires /sbin/chkconfig smstools-3.0.10-2.fc9.x86_64 requires /bin/sh smstools-3.0.10-2.fc9.x86_64 requires /sbin/service snake-0.11-0.2.fc9.noarch requires /usr/bin/python snake-server-0.11-0.2.fc9.noarch requires /bin/sh snake-server-0.11-0.2.fc9.noarch requires /bin/sh snake-server-0.11-0.2.fc9.noarch requires /usr/bin/python snort-2.8.1-3.fc10.x86_64 requires /bin/sh snort-2.8.1-3.fc10.x86_64 requires /bin/sh snort-bloat-2.8.1-3.fc10.x86_64 requires /bin/sh snort-mysql-2.8.1-3.fc10.x86_64 requires /bin/sh snort-mysql+flexresp-2.8.1-3.fc10.x86_64 requires /bin/sh snort-plain+flexresp-2.8.1-3.fc10.x86_64 requires /bin/sh snort-postgresql-2.8.1-3.fc10.x86_64 requires /bin/sh snort-postgresql+flexresp-2.8.1-3.fc10.x86_64 requires /bin/sh snort-snmp-2.8.1-3.fc10.x86_64 requires /bin/sh snort-snmp+flexresp-2.8.1-3.fc10.x86_64 requires /bin/sh snownews-1.5.8-2.fc9.x86_64 requires /usr/bin/perl sofia-sip-1.12.8-1.fc9.i386 requires /sbin/ldconfig sofia-sip-1.12.8-1.fc9.x86_64 requires /sbin/ldconfig sofia-sip-devel-1.12.8-1.fc9.i386 requires /usr/bin/env sofia-sip-devel-1.12.8-1.fc9.x86_64 requires /usr/bin/env sofia-sip-glib-1.12.8-1.fc9.i386 requires /sbin/ldconfig sofia-sip-glib-1.12.8-1.fc9.x86_64 requires /sbin/ldconfig solarwolf-1.5-2.fc8.noarch requires /bin/sh solarwolf-1.5-2.fc8.noarch requires /usr/bin/env solfege-3.10.4-1.fc10.x86_64 requires /bin/bash solfege-3.10.4-1.fc10.x86_64 requires /bin/sh solfege-3.10.4-1.fc10.x86_64 requires /usr/bin/python sonata-1.5.1-1.fc10.x86_64 requires /usr/bin/python sonic-visualiser-1.2-1.fc9.x86_64 requires /bin/sh sooperlooper-1.6.2-1.fc9.x86_64 requires /bin/sh soprano-2.0.98-1.fc10.i386 requires /sbin/ldconfig soprano-2.0.98-1.fc10.x86_64 requires /sbin/ldconfig soprano-apidocs-2.0.98-1.fc10.x86_64 requires /usr/bin/perl sos-1.8-1.fc8.noarch requires /bin/bash sos-1.8-1.fc8.noarch requires /usr/bin/env sound-juicer-2.22.0-3.fc10.x86_64 requires /bin/sh soundconverter-1.2.0-1.fc10.noarch requires /bin/sh soundconverter-1.2.0-1.fc10.noarch requires /usr/bin/python soundtouch-1.3.1-10.fc9.i386 requires /sbin/ldconfig soundtouch-1.3.1-10.fc9.x86_64 requires /sbin/ldconfig source-highlight-2.8-2.fc9.x86_64 requires /bin/sh source-highlight-2.8-2.fc9.x86_64 requires /sbin/install-info source-highlight-2.8-2.fc9.x86_64 requires /bin/sh sox-14.0.1-1.fc9.i386 requires /sbin/ldconfig sox-14.0.1-1.fc9.x86_64 requires /sbin/ldconfig spamass-milter-0.3.1-7.fc9.x86_64 requires /bin/sh spamass-milter-0.3.1-7.fc9.x86_64 requires /sbin/service spamass-milter-0.3.1-7.fc9.x86_64 requires /bin/bash spamass-milter-0.3.1-7.fc9.x86_64 requires /sbin/chkconfig spamassassin-3.2.4-4.fc9.x86_64 requires /sbin/chkconfig spamassassin-3.2.4-4.fc9.x86_64 requires /usr/bin/perl spamassassin-3.2.4-4.fc9.x86_64 requires /bin/sh spamassassin-3.2.4-4.fc9.x86_64 requires /sbin/service spamassassin-3.2.4-4.fc9.x86_64 requires /bin/bash spamassassin-3.2.4-4.fc9.x86_64 requires /bin/sh spambayes-1.0.4-5.fc8.noarch requires /usr/bin/python spampd-2.30-4.noarch requires /bin/sh spampd-2.30-4.noarch requires /usr/bin/perl spampd-2.30-4.noarch requires /sbin/chkconfig spampd-2.30-4.noarch requires /bin/sh spampd-2.30-4.noarch requires /sbin/service spandsp-0.0.4-0.10.pre18.fc9.i386 requires /sbin/ldconfig spandsp-0.0.4-0.10.pre18.fc9.x86_64 requires /sbin/ldconfig sparse-0.4.1-2.fc9.x86_64 requires /usr/bin/perl specto-0.2.2-1.fc9.noarch requires /bin/sh specto-0.2.2-1.fc9.noarch requires /usr/bin/python speedcrunch-0.9-3.fc9.x86_64 requires /bin/sh speex-1.2-0.9.beta3.i386 requires /sbin/ldconfig speex-1.2-0.9.beta3.x86_64 requires /sbin/ldconfig spr-07.15.00-1.fc9.i386 requires /sbin/ldconfig spr-07.15.00-1.fc9.x86_64 requires /sbin/ldconfig sqlgrey-1.7.5-1.fc7.noarch requires /bin/sh sqlgrey-1.7.5-1.fc7.noarch requires /usr/bin/perl sqlgrey-1.7.5-1.fc7.noarch requires /bin/bash sqlgrey-1.7.5-1.fc7.noarch requires /sbin/chkconfig sqlgrey-1.7.5-1.fc7.noarch requires /bin/sh sqlgrey-1.7.5-1.fc7.noarch requires /sbin/service sqlite-3.5.8-1.fc10.i386 requires /sbin/ldconfig sqlite-3.5.8-1.fc10.x86_64 requires /sbin/ldconfig sqliteman-1.0.1-4.fc9.x86_64 requires /bin/sh 7:squid-3.0.STABLE5-2.fc10.x86_64 requires /bin/sh 7:squid-3.0.STABLE5-2.fc10.x86_64 requires /sbin/service 7:squid-3.0.STABLE5-2.fc10.x86_64 requires /bin/bash 7:squid-3.0.STABLE5-2.fc10.x86_64 requires /bin/sh 7:squid-3.0.STABLE5-2.fc10.x86_64 requires /usr/bin/perl 7:squid-3.0.STABLE5-2.fc10.x86_64 requires /sbin/chkconfig squidGuard-1.2.0-18.fc9.x86_64 requires /bin/sh squidGuard-1.2.0-18.fc9.x86_64 requires /usr/bin/chcon squidGuard-1.2.0-18.fc9.x86_64 requires /bin/bash squidGuard-1.2.0-18.fc9.x86_64 requires /usr/bin/perl squidGuard-1.2.0-18.fc9.x86_64 requires /sbin/chkconfig squirrelmail-1.4.13-1.fc9.noarch requires /usr/bin/env squirrelmail-1.4.13-1.fc9.noarch requires /bin/sh ss5-3.5.9-7.x86_64 requires /bin/sh ss5-3.5.9-7.x86_64 requires /bin/sh sshfp-1.1.2-1.fc7.noarch requires /usr/bin/python sshmenu-3.15-5.fc9.noarch requires /usr/bin/ruby ssmtp-2.61-11.5.fc9.3.x86_64 requires /bin/sh ssmtp-2.61-11.5.fc9.3.x86_64 requires /usr/sbin/alternatives stardict-3.0.1-8.fc9.x86_64 requires /bin/sh starplot-0.95.4-6.fc9.x86_64 requires /bin/sh starplot-gliese3-0.95-2.fc9.noarch requires /bin/sh starplot-yale5-0.95-2.fc9.noarch requires /bin/sh startup-notification-0.9-4.fc9.i386 requires /sbin/ldconfig startup-notification-0.9-4.fc9.x86_64 requires /sbin/ldconfig statgrab-tools-0.16-1.fc9.x86_64 requires /usr/bin/perl statserial-1.1-41.fc9.x86_64 requires /bin/bash stgit-0.14.2-1.fc9.noarch requires /bin/sh stgit-0.14.2-1.fc9.noarch requires /usr/bin/python stix-fonts-0.9-6.fc9.noarch requires /bin/sh stix-fonts-integrals-0.9-6.fc9.noarch requires /bin/sh stix-fonts-pua-0.9-6.fc9.noarch requires /bin/sh stix-fonts-sizes-0.9-6.fc9.noarch requires /bin/sh stix-fonts-variants-0.9-6.fc9.noarch requires /bin/sh stonith-2.1.3-1.fc9.i386 requires /usr/bin/python stonith-2.1.3-1.fc9.i386 requires /sbin/ldconfig stonith-2.1.3-1.fc9.i386 requires /usr/bin/perl stonith-2.1.3-1.fc9.i386 requires /bin/sh stonith-2.1.3-1.fc9.x86_64 requires /usr/bin/python stonith-2.1.3-1.fc9.x86_64 requires /sbin/ldconfig stonith-2.1.3-1.fc9.x86_64 requires /usr/bin/perl stonith-2.1.3-1.fc9.x86_64 requires /bin/sh stormbaancoureur-2.1.4-1.fc10.x86_64 requires /bin/sh stow-1.3.3-6.fc8.noarch requires /usr/bin/perl stow-1.3.3-6.fc8.noarch requires /sbin/install-info stow-1.3.3-6.fc8.noarch requires /bin/sh stratagus-2.2.4-4.fc9.x86_64 requires /usr/bin/env straw-0.27-12.fc9.noarch requires /bin/sh straw-0.27-12.fc9.noarch requires /usr/bin/python streamtuner-0.99.99-17.fc9.x86_64 requires /bin/sh strigi-libs-0.5.9-2.fc10.i386 requires /sbin/ldconfig strigi-libs-0.5.9-2.fc10.x86_64 requires /sbin/ldconfig struts-1.2.9-5jpp.9.fc9.x86_64 requires /bin/sh struts-javadoc-1.2.9-5jpp.9.fc9.x86_64 requires /bin/sh struts-javadoc-1.2.9-5jpp.9.fc9.x86_64 requires /bin/rm struts-javadoc-1.2.9-5jpp.9.fc9.x86_64 requires /bin/ln struts-webapps-tomcat5-1.2.9-5jpp.9.fc9.x86_64 requires /bin/sh struts-webapps-tomcat5-1.2.9-5jpp.9.fc9.x86_64 requires /bin/ln struts-webapps-tomcat5-1.2.9-5jpp.9.fc9.x86_64 requires /bin/rm stunnel-4.22-1.x86_64 requires /usr/bin/perl sub2srt-0.5.3-3.fc8.noarch requires /usr/bin/perl subversion-1.4.6-7.i386 requires /usr/bin/env subversion-1.4.6-7.i386 requires /usr/bin/python subversion-1.4.6-7.i386 requires /sbin/ldconfig subversion-1.4.6-7.i386 requires /bin/bash subversion-1.4.6-7.i386 requires /bin/sh subversion-1.4.6-7.i386 requires /usr/bin/perl subversion-1.4.6-7.x86_64 requires /usr/bin/env subversion-1.4.6-7.x86_64 requires /usr/bin/python subversion-1.4.6-7.x86_64 requires /sbin/ldconfig subversion-1.4.6-7.x86_64 requires /bin/bash subversion-1.4.6-7.x86_64 requires /bin/sh subversion-1.4.6-7.x86_64 requires /usr/bin/perl subversion-javahl-1.4.6-7.i386 requires /sbin/ldconfig subversion-javahl-1.4.6-7.x86_64 requires /sbin/ldconfig subversion-perl-1.4.6-7.i386 requires /sbin/ldconfig subversion-perl-1.4.6-7.x86_64 requires /sbin/ldconfig subversion-ruby-1.4.6-7.i386 requires /sbin/ldconfig subversion-ruby-1.4.6-7.x86_64 requires /sbin/ldconfig suck-4.3.2-22.fc9.x86_64 requires /bin/sh suck-4.3.2-22.fc9.x86_64 requires /usr/bin/perl sudo-1.6.9p13-6.fc10.x86_64 requires /bin/sh sudo-1.6.9p13-6.fc10.x86_64 requires /etc/pam.d/system-auth sugar-0.79.4-2.fc10.x86_64 requires /bin/sh sugar-0.79.4-2.fc10.x86_64 requires /usr/bin/env sugar-0.79.4-2.fc10.x86_64 requires /bin/sh sugar-artwork-0.79.1-1.fc9.i386 requires /bin/sh sugar-artwork-0.79.1-1.fc9.x86_64 requires /bin/sh sugar-datastore-0.6.0-1.fc9.noarch requires /usr/bin/env sugar-journal-79-3.fc9.noarch requires /usr/bin/env sugar-presence-service-0.79.0-1.fc9.noarch requires /usr/bin/env suitesparse-3.1.0-1.fc9.i386 requires /sbin/ldconfig suitesparse-3.1.0-1.fc9.x86_64 requires /sbin/ldconfig sunbird-0.8-3.fc9.x86_64 requires /bin/sh sunbird-0.8-3.fc9.x86_64 requires /bin/sh sunbird-0.8-3.fc9.x86_64 requires libhunspell.so.1()(64bit) sundials-2.3.0-6.fc9.i386 requires /sbin/ldconfig sundials-2.3.0-6.fc9.x86_64 requires /sbin/ldconfig sundials-devel-2.3.0-6.fc9.i386 requires /bin/sh sundials-devel-2.3.0-6.fc9.x86_64 requires /bin/sh supertuxkart-0.4-2.fc10.x86_64 requires /bin/sh supervisor-2.1-4.fc9.noarch requires /bin/sh supervisor-2.1-4.fc9.noarch requires /bin/bash supervisor-2.1-4.fc9.noarch requires /sbin/chkconfig supervisor-2.1-4.fc9.noarch requires /usr/bin/python supervisor-2.1-4.fc9.noarch requires /sbin/service surfraw-1.0.7-3.fc8.noarch requires /bin/sh svgalib-1.9.25-4.fc9.i386 requires /sbin/ldconfig svgalib-1.9.25-4.fc9.i386 requires /usr/bin/perl svgalib-1.9.25-4.fc9.i386 requires /bin/sh svgalib-1.9.25-4.fc9.x86_64 requires /sbin/ldconfig svgalib-1.9.25-4.fc9.x86_64 requires /usr/bin/perl svgalib-1.9.25-4.fc9.x86_64 requires /bin/sh svn2cl-0.10-1.noarch requires /bin/sh svncpp-0.9.6-1.fc9.i386 requires /sbin/ldconfig svncpp-0.9.6-1.fc9.x86_64 requires /sbin/ldconfig svnkit-1.1.4-3.fc9.x86_64 requires /usr/bin/rebuild-gcj-db svnmailer-1.0.8-3.fc7.noarch requires /usr/bin/python svrcore-4.0.4-2.fc9.i386 requires /sbin/ldconfig svrcore-4.0.4-2.fc9.x86_64 requires /sbin/ldconfig swaks-20061116.0-1.fc8.noarch requires /usr/bin/perl swatch-3.2.1-2.fc9.noarch requires /usr/bin/perl sweep-0.9.2-2.fc9.x86_64 requires /bin/sh swfdec-0.6.6-1.fc10.i386 requires /sbin/ldconfig swfdec-0.6.6-1.fc10.x86_64 requires /sbin/ldconfig swfdec-gnome-2.22.0-1.fc9.x86_64 requires /bin/sh swfdec-gtk-0.6.6-1.fc10.i386 requires /sbin/ldconfig swfdec-gtk-0.6.6-1.fc10.i386 requires /bin/sh swfdec-gtk-0.6.6-1.fc10.x86_64 requires /bin/sh swfdec-gtk-0.6.6-1.fc10.x86_64 requires /sbin/ldconfig swfdec-mozilla-0.6.0-1.fc9.x86_64 requires /usr/lib64/mozilla/plugins swig-1.3.35-2.fc10.x86_64 requires /sbin/ldconfig swing-layout-1.0.3-2.fc9.x86_64 requires /bin/sh switchdesk-4.0.9-2.noarch requires /bin/bash switchdesk-gui-4.0.9-2.noarch requires /usr/bin/env sword-1.5.10-3.fc9.i386 requires /sbin/ldconfig sword-1.5.10-3.fc9.x86_64 requires /sbin/ldconfig syck-0.61-4.3.fc9.i386 requires /sbin/ldconfig syck-0.61-4.3.fc9.x86_64 requires /sbin/ldconfig synaptic-0.57.2-16.fc9.x86_64 requires /bin/sh synce-gnome-0.11-2.fc9.noarch requires /usr/bin/env synce-kde-0.9.1-3.fc9.x86_64 requires /bin/sh synce-kde-0.9.1-3.fc9.x86_64 requires /bin/sh synce-kpm-0.11-3.fc9.noarch requires /usr/bin/python synce-serial-0.11-2.fc9.x86_64 requires /bin/sh synce-sync-engine-0.11-6.fc9.noarch requires /usr/bin/python syncevolution-0.7-2.fc10.x86_64 requires /usr/bin/env sysconftool-0.15-3.fc6.noarch requires /usr/bin/perl syslog-ng-2.0.8-1.fc9.x86_64 requires /bin/sh syslog-ng-2.0.8-1.fc9.x86_64 requires /bin/sh sysreport-1.4.4-1.noarch requires /bin/bash sysreport-1.4.4-1.noarch requires /usr/bin/tr sysstat-8.0.4-4.fc10.x86_64 requires /bin/cp sysstat-8.0.4-4.fc10.x86_64 requires /bin/sh sysstat-8.0.4-4.fc10.x86_64 requires /usr/bin/id sysstat-8.0.4-4.fc10.x86_64 requires /etc/cron.d sysstat-8.0.4-4.fc10.x86_64 requires /bin/chmod sysstat-8.0.4-4.fc10.x86_64 requires /bin/mkdir sysstat-8.0.4-4.fc10.x86_64 requires /usr/bin/install sysstat-8.0.4-4.fc10.x86_64 requires /sbin/chkconfig sysstat-8.0.4-4.fc10.x86_64 requires /bin/sh sysstat-8.0.4-4.fc10.x86_64 requires /bin/mv sysstat-8.0.4-4.fc10.x86_64 requires /bin/grep system-config-audit-0.4.6-7.fc10.x86_64 requires /bin/sh system-config-bind-4.0.6-1.fc9.noarch requires /bin/sh system-config-bind-4.0.6-1.fc9.noarch requires /usr/bin/python system-config-boot-0.2.20-1.fc9.x86_64 requires /bin/sh system-config-cluster-1.0.53-1.0.noarch requires /usr/bin/python2 system-config-cluster-1.0.53-1.0.noarch requires /sbin/chkconfig system-config-date-1.9.31-1.fc10.noarch requires /bin/sh system-config-date-1.9.31-1.fc10.noarch requires /bin/sh system-config-date-1.9.31-1.fc10.noarch requires /usr/bin/python system-config-display-1.0.51-9.fc9.noarch requires /bin/sh system-config-display-1.0.51-9.fc9.noarch requires /usr/bin/Xorg system-config-display-1.0.51-9.fc9.noarch requires /bin/sh system-config-display-1.0.51-9.fc9.noarch requires /usr/bin/python2 system-config-firewall-1.2.7-1.fc9.noarch requires /bin/sh system-config-firewall-1.2.7-1.fc9.noarch requires /bin/sh system-config-firewall-1.2.7-1.fc9.noarch requires /usr/bin/python system-config-firewall-tui-1.2.7-1.fc9.noarch requires /usr/bin/python 5:system-config-httpd-1.4.4-1.fc8.noarch requires /bin/sh 5:system-config-httpd-1.4.4-1.fc8.noarch requires /bin/sh system-config-kdump-1.0.13-2.fc9.noarch requires /bin/sh system-config-kdump-1.0.13-2.fc9.noarch requires /bin/sh system-config-keyboard-1.2.15-2.fc9.noarch requires /bin/sh system-config-keyboard-1.2.15-2.fc9.noarch requires /bin/sh system-config-kickstart-2.7.16-1.fc9.noarch requires /bin/sh system-config-kickstart-2.7.16-1.fc9.noarch requires /usr/bin/python2 system-config-language-1.2.15-3.fc10.noarch requires /bin/sh system-config-language-1.2.15-3.fc10.noarch requires /bin/sh system-config-lvm-1.1.4-1.0.fc9.noarch requires /sbin/chkconfig system-config-lvm-1.1.4-1.0.fc9.noarch requires /usr/bin/python2 system-config-netboot-0.1.45.2-1.fc10.noarch requires /bin/sh system-config-netboot-0.1.45.2-1.fc10.noarch requires /usr/bin/python system-config-netboot-cmd-0.1.45.2-1.fc10.noarch requires /bin/sh system-config-netboot-cmd-0.1.45.2-1.fc10.noarch requires /bin/bash system-config-netboot-cmd-0.1.45.2-1.fc10.noarch requires /usr/bin/python system-config-network-1.5.7-1.fc9.noarch requires /usr/bin/python system-config-network-tui-1.5.7-1.fc9.noarch requires /bin/sh system-config-network-tui-1.5.7-1.fc9.noarch requires /usr/bin/python system-config-nfs-1.3.40-1.fc9.noarch requires /bin/sh system-config-nfs-1.3.40-1.fc9.noarch requires /usr/bin/python system-config-printer-0.9.91-1.fc10.x86_64 requires /bin/sh system-config-printer-0.9.91-1.fc10.x86_64 requires /usr/bin/env system-config-printer-0.9.91-1.fc10.x86_64 requires /bin/sh system-config-printer-0.9.91-1.fc10.x86_64 requires /usr/bin/python system-config-printer-libs-0.9.91-1.fc10.x86_64 requires /usr/bin/env system-config-printer-libs-0.9.91-1.fc10.x86_64 requires /usr/bin/python system-config-rootpassword-1.99.4-1.fc9.noarch requires /bin/sh system-config-rootpassword-1.99.4-1.fc9.noarch requires /bin/sh system-config-samba-1.2.63-1.fc9.noarch requires /bin/sh system-config-samba-1.2.63-1.fc9.noarch requires /usr/bin/python system-config-services-0.99.15-1.fc9.noarch requires /bin/sh system-config-services-0.99.15-1.fc9.noarch requires /usr/bin/python system-config-users-1.2.80-1.fc10.noarch requires /bin/sh system-config-users-1.2.80-1.fc10.noarch requires /usr/bin/pgrep system-config-users-1.2.80-1.fc10.noarch requires /bin/sh system-config-users-1.2.80-1.fc10.noarch requires /usr/bin/python system-config-vsftpd-0.5.1-1.fc10.noarch requires /usr/bin/env system-config-vsftpd-0.5.1-1.fc10.noarch requires /bin/sh system-summary-0.0.3-2.fc9.noarch requires /usr/bin/python system-switch-java-1.1.2-1.fc8.noarch requires /usr/bin/env system-switch-mail-0.5.26-2.noarch requires /usr/bin/python systemtap-0.6.2-1.fc9.x86_64 requires /bin/bash systemtap-0.6.2-1.fc9.x86_64 requires /usr/bin/stap systemtap-runtime-0.6.2-1.fc9.x86_64 requires /bin/sh systemtap-testsuite-0.6.2-1.fc9.x86_64 requires /usr/bin/perl systemtap-testsuite-0.6.2-1.fc9.x86_64 requires /bin/bash systemtap-testsuite-0.6.2-1.fc9.x86_64 requires /usr/bin/tclsh systemtap-testsuite-0.6.2-1.fc9.x86_64 requires /usr/bin/stap systemtap-testsuite-0.6.2-1.fc9.x86_64 requires /usr/bin/env systemtap-testsuite-0.6.2-1.fc9.x86_64 requires /bin/sh sysusage-2.6-3.fc9.noarch requires /usr/bin/perl sysvinit-tools-2.86-24.x86_64 requires /bin/sh t1lib-5.1.2-2.fc9.i386 requires /bin/sh t1lib-5.1.2-2.fc9.i386 requires /sbin/ldconfig t1lib-5.1.2-2.fc9.i386 requires /bin/sh t1lib-5.1.2-2.fc9.x86_64 requires /bin/sh t1lib-5.1.2-2.fc9.x86_64 requires /sbin/ldconfig t1lib-5.1.2-2.fc9.x86_64 requires /bin/sh taglib-1.5-1.fc9.i386 requires /sbin/ldconfig taglib-1.5-1.fc9.x86_64 requires /sbin/ldconfig taglib-devel-1.5-1.fc9.i386 requires /bin/sh taglib-devel-1.5-1.fc9.x86_64 requires /bin/sh tagsoup-1.0.1-2jpp.1.fc9.x86_64 requires /bin/sh tagtool-0.12.3-4.fc9.x86_64 requires /bin/sh tailor-0.9.30-1.fc9.noarch requires /usr/bin/python taipeifonts-1.2-5.fc9.noarch requires /bin/sh tango-icon-theme-0.8.1-1.fc8.noarch requires /bin/sh tango-icon-theme-extras-0.1.0-1.fc7.noarch requires /bin/sh tanukiwrapper-3.2.3-2jpp.1.fc9.x86_64 requires /bin/sh tanukiwrapper-javadoc-3.2.3-2jpp.1.fc9.x86_64 requires /bin/sh tanukiwrapper-javadoc-3.2.3-2jpp.1.fc9.x86_64 requires /bin/rm tanukiwrapper-javadoc-3.2.3-2jpp.1.fc9.x86_64 requires /bin/ln 2:tar-1.19-3.fc9.x86_64 requires /bin/sh 2:tar-1.19-3.fc9.x86_64 requires /sbin/install-info taskcoach-0.69.1-2.fc9.noarch requires /bin/sh taskcoach-0.69.1-2.fc9.noarch requires /usr/bin/env taskcoach-0.69.1-2.fc9.noarch requires /usr/bin/python taskjuggler-2.4.1-1.fc10.x86_64 requires /bin/sh tasks-0.12-2.fc10.x86_64 requires /bin/sh taxipilot-0.9.2-6.fc9.i386 requires /bin/sh taxipilot-0.9.2-6.fc9.x86_64 requires /bin/sh tbb-2.0-4.20070927.fc9.i386 requires /sbin/ldconfig tbb-2.0-4.20070927.fc9.x86_64 requires /sbin/ldconfig tcd-utils-20061127-1.fc9.3.x86_64 requires /bin/sh 1:tcl-8.5.1-4.fc10.i386 requires /sbin/ldconfig 1:tcl-8.5.1-4.fc10.x86_64 requires /sbin/ldconfig tclabc-1.1.0-1.fc9.x86_64 requires /bin/sh tcldebugger-1.4-6.20061030cvs.fc9.noarch requires /bin/sh tclhttpd-3.5.1-19.fc9.x86_64 requires /bin/sh tclhttpd-3.5.1-19.fc9.x86_64 requires /sbin/chkconfig tclhttpd-3.5.1-19.fc9.x86_64 requires /bin/sh tclhttpd-3.5.1-19.fc9.x86_64 requires /sbin/service tcllib-1.10-2.fc9.noarch requires /bin/sh tclpro-1.5.0-11.20061030cvs.fc9.noarch requires /bin/sh tclx-8.4.0-10.fc9.x86_64 requires /sbin/ldconfig tcp_wrappers-libs-7.6-52.fc9.i386 requires /sbin/ldconfig tcp_wrappers-libs-7.6-52.fc9.x86_64 requires /sbin/ldconfig 14:tcpdump-3.9.8-4.fc9.x86_64 requires /bin/sh tcpreplay-3.3.0-1.fc10.x86_64 requires /usr/sbin/tcpdump tcsh-6.15-4.fc9.x86_64 requires /bin/sh teckit-2.2.1-3.fc9.i386 requires /sbin/ldconfig teckit-2.2.1-3.fc9.x86_64 requires /sbin/ldconfig teckit-devel-2.2.1-3.fc9.i386 requires /sbin/ldconfig teckit-devel-2.2.1-3.fc9.x86_64 requires /sbin/ldconfig tecnoballz-0.92-4.fc9.x86_64 requires /bin/sh teg-0.11.2-15.fc9.x86_64 requires /bin/sh telepathy-butterfly-0.3.1-1.fc9.noarch requires /usr/bin/python telepathy-glib-0.7.8-1.fc10.i386 requires /sbin/ldconfig telepathy-glib-0.7.8-1.fc10.x86_64 requires /sbin/ldconfig telepathy-mission-control-4.64-1.fc9.i386 requires /sbin/ldconfig telepathy-mission-control-4.64-1.fc9.x86_64 requires /sbin/ldconfig tellico-1.3.1-1.fc9.x86_64 requires /bin/sh tellico-1.3.1-1.fc9.x86_64 requires /usr/bin/env tempest-xscreensaver-0-0.6.20070929.fc9.x86_64 requires /bin/sh terminus-font-x11-4.20-8.fc8.noarch requires /bin/sh terminus-font-x11-4.20-8.fc8.noarch requires /usr/bin/fc-cache terminus-font-x11-4.20-8.fc8.noarch requires /usr/bin/mkfontdir testoob-1.13-4.fc9.noarch requires /usr/bin/env testoob-1.13-4.fc9.noarch requires /usr/bin/python tetex-IEEEtran-1.7.1-1.fc8.noarch requires /usr/bin/texhash tetex-IEEEtran-1.7.1-1.fc8.noarch requires /bin/sh tetex-IEEEtran-1.7.1-1.fc8.noarch requires /bin/sh tetex-bytefield-1.2a-3.fc6.noarch requires /bin/sh tetex-bytefield-1.2a-3.fc6.noarch requires /usr/bin/texhash tetex-dvipost-1.1-9.fc9.x86_64 requires /usr/bin/texhash tetex-elsevier-0.1.20071024-1.fc9.noarch requires /usr/bin/texhash tetex-eurofont-1.1.3-6.fc6.noarch requires /bin/sh tetex-font-cm-lgc-0.5-9.fc9.noarch requires /bin/sh tetex-font-kerkis-2.0-15.fc9.noarch requires /bin/sh tetex-fonts-hebrew-0.1-8.fc9.noarch requires /usr/bin/texhash tetex-fonts-hebrew-0.1-8.fc9.noarch requires /usr/bin/updmap-sys tetex-fonts-hebrew-0.1-8.fc9.noarch requires /bin/sh tetex-perltex-1.3-1.fc6.noarch requires /usr/bin/texhash tetex-perltex-1.3-1.fc6.noarch requires /usr/bin/perl tetex-perltex-1.3-1.fc6.noarch requires /bin/sh tetex-prosper-1.5-3.fc6.noarch requires /usr/bin/texhash tetex-prosper-1.5-3.fc6.noarch requires /bin/sh tetex-tex4ht-1.0.2008_02_28_2058-3.fc9.x86_64 requires /usr/bin/texhash tetex-tex4ht-1.0.2008_02_28_2058-3.fc9.x86_64 requires /usr/bin/perl tetex-tex4ht-1.0.2008_02_28_2058-3.fc9.x86_64 requires /usr/bin/dvipng tetex-tex4ht-1.0.2008_02_28_2058-3.fc9.x86_64 requires /bin/sh tetex-tex4ht-1.0.2008_02_28_2058-3.fc9.x86_64 requires /bin/sh tetex-unicode-0-7.20041017.fc6.noarch requires /bin/sh tetrinetx-1.13.16-4.fc9.x86_64 requires /bin/sh tetrinetx-1.13.16-4.fc9.x86_64 requires /sbin/chkconfig tetrinetx-1.13.16-4.fc9.x86_64 requires /usr/sbin/useradd tetrinetx-1.13.16-4.fc9.x86_64 requires /bin/sh tex-preview-11.85-7.fc9.noarch requires /bin/sh texi2html-1.78-3.fc8.noarch requires /bin/sh texi2html-1.78-3.fc8.noarch requires /usr/bin/perl texi2html-1.78-3.fc8.noarch requires /sbin/install-info texinfo-4.12-1.fc10.x86_64 requires /bin/sh texinfo-4.12-1.fc10.x86_64 requires /sbin/install-info texinfo-tex-4.12-1.fc10.x86_64 requires /bin/sh texinfo-tex-4.12-1.fc10.x86_64 requires /bin/sh texinfo-tex-4.12-1.fc10.x86_64 requires /usr/bin/texconfig-sys texlive-2007-31.fc10.x86_64 requires /bin/sh texlive-2007-31.fc10.x86_64 requires /usr/bin/fmtutil texlive-2007-31.fc10.x86_64 requires /bin/bash texlive-2007-31.fc10.x86_64 requires /bin/sh texlive-2007-31.fc10.x86_64 requires /sbin/restorecon texlive-afm-2007-31.fc10.x86_64 requires /bin/sh texlive-afm-2007-31.fc10.x86_64 requires /sbin/restorecon texlive-context-2007-31.fc10.x86_64 requires /bin/sh texlive-context-2007-31.fc10.x86_64 requires /sbin/restorecon texlive-context-2007-31.fc10.x86_64 requires /usr/bin/env texlive-context-2007-31.fc10.x86_64 requires /bin/sh texlive-doc-2007-31.fc10.x86_64 requires /usr/bin/env texlive-doc-2007-31.fc10.x86_64 requires /bin/sh texlive-dvips-2007-31.fc10.x86_64 requires /bin/sh texlive-dvips-2007-31.fc10.x86_64 requires /sbin/restorecon texlive-dvips-2007-31.fc10.x86_64 requires /bin/sh texlive-dviutils-2007-31.fc10.x86_64 requires /bin/sh texlive-dviutils-2007-31.fc10.x86_64 requires /sbin/restorecon texlive-dviutils-2007-31.fc10.x86_64 requires /bin/sh texlive-east-asian-2007-31.fc10.x86_64 requires /bin/sh texlive-east-asian-2007-31.fc10.x86_64 requires /sbin/restorecon texlive-east-asian-2007-31.fc10.x86_64 requires /bin/sh texlive-latex-2007-31.fc10.x86_64 requires /usr/bin/fmtutil-sys texlive-latex-2007-31.fc10.x86_64 requires /bin/sh texlive-latex-2007-31.fc10.x86_64 requires /usr/bin/fmtutil texlive-latex-2007-31.fc10.x86_64 requires /sbin/restorecon texlive-latex-2007-31.fc10.x86_64 requires /sbin/install-info texlive-latex-2007-31.fc10.x86_64 requires /bin/sh texlive-latex-2007-31.fc10.x86_64 requires /usr/bin/texconfig-sys texlive-texmf-2007-21.fc10.noarch requires /bin/sh texlive-texmf-2007-21.fc10.noarch requires /sbin/restorecon texlive-texmf-2007-21.fc10.noarch requires /bin/sh texlive-texmf-afm-2007-21.fc10.noarch requires /bin/sh texlive-texmf-afm-2007-21.fc10.noarch requires /sbin/restorecon texlive-texmf-context-2007-21.fc10.noarch requires /bin/sh texlive-texmf-context-2007-21.fc10.noarch requires /sbin/restorecon texlive-texmf-context-2007-21.fc10.noarch requires /usr/bin/env texlive-texmf-context-2007-21.fc10.noarch requires /bin/sh texlive-texmf-doc-2007-21.fc10.noarch requires /bin/sh texlive-texmf-doc-2007-21.fc10.noarch requires /sbin/restorecon texlive-texmf-doc-2007-21.fc10.noarch requires /usr/bin/perl texlive-texmf-doc-2007-21.fc10.noarch requires /usr/bin/env texlive-texmf-doc-2007-21.fc10.noarch requires /bin/sh texlive-texmf-dvips-2007-21.fc10.noarch requires /bin/sh texlive-texmf-dvips-2007-21.fc10.noarch requires /sbin/restorecon texlive-texmf-east-asian-2007-21.fc10.noarch requires /bin/sh texlive-texmf-east-asian-2007-21.fc10.noarch requires /sbin/restorecon texlive-texmf-fonts-2007-21.fc10.noarch requires /bin/sh texlive-texmf-fonts-2007-21.fc10.noarch requires /sbin/restorecon texlive-texmf-latex-2007-21.fc10.noarch requires /bin/sh texlive-texmf-latex-2007-21.fc10.noarch requires /sbin/restorecon texlive-texmf-xetex-2007-21.fc10.noarch requires /bin/sh texlive-texmf-xetex-2007-21.fc10.noarch requires /sbin/restorecon texlive-texmf-xetex-2007-21.fc10.noarch requires /usr/bin/perl texlive-utils-2007-31.fc10.x86_64 requires /usr/bin/env texlive-utils-2007-31.fc10.x86_64 requires /usr/bin/perl texlive-utils-2007-31.fc10.x86_64 requires /bin/sh texlive-xetex-2007-31.fc10.x86_64 requires /bin/sh texlive-xetex-2007-31.fc10.x86_64 requires /sbin/restorecon 1:texmaker-1.7-1.fc10.x86_64 requires /bin/sh textflow-0.2.3.1-1.fc10.noarch requires /usr/bin/python tftp-server-0.48-3.fc9.x86_64 requires /bin/sh tftp-server-0.48-3.fc9.x86_64 requires /sbin/service tgif-4.1.45-6.fc9.x86_64 requires /bin/sh tgif-4.1.45-6.fc9.x86_64 requires /bin/bash thaifonts-scalable-0.4.9-3.fc9.noarch requires /bin/sh themonospot-0.7.0.1-1.fc10.x86_64 requires /bin/sh thinkfinger-0.3-8.fc9.i386 requires /sbin/ldconfig thinkfinger-0.3-8.fc9.x86_64 requires /sbin/ldconfig thttpd-2.25b-16.fc9.x86_64 requires /bin/sh thttpd-2.25b-16.fc9.x86_64 requires /bin/bash thttpd-2.25b-16.fc9.x86_64 requires /sbin/chkconfig thttpd-2.25b-16.fc9.x86_64 requires /usr/sbin/groupadd thttpd-2.25b-16.fc9.x86_64 requires /usr/sbin/useradd thttpd-2.25b-16.fc9.x86_64 requires /bin/sh thttpd-2.25b-16.fc9.x86_64 requires /sbin/service thunar-archive-plugin-0.2.4-4.fc9.x86_64 requires /bin/sh thunar-archive-plugin-0.2.4-4.fc9.x86_64 requires /bin/sh thunar-shares-0.10-1.fc8.x86_64 requires /bin/sh thunar-volman-0.2.0-2.fc9.x86_64 requires /bin/sh thunar-volman-0.2.0-2.fc9.x86_64 requires /bin/sh thunderbird-2.0.0.14-1.fc10.x86_64 requires /bin/sh thunderbird-2.0.0.14-1.fc10.x86_64 requires /bin/bash thunderbird-2.0.0.14-1.fc10.x86_64 requires /bin/sh thunderbird-lightning-0.8-3.fc9.x86_64 requires /bin/sh thunderbird-lightning-0.8-3.fc9.x86_64 requires /bin/sh thunderbird-lightning-0.8-3.fc9.x86_64 requires libhunspell.so.1()(64bit) tibetan-machine-uni-fonts-1.901-1.fc9.noarch requires /bin/sh tiger-3.2.1-8.fc9.x86_64 requires /usr/bin/perl tiger-3.2.1-8.fc9.x86_64 requires /bin/sh time-1.7-33.fc9.x86_64 requires /bin/sh time-1.7-33.fc9.x86_64 requires /sbin/install-info timidity++-2.13.2-16.fc10.x86_64 requires /bin/sh tin-1.8.3-4.fc9.x86_64 requires /usr/bin/perl tin-1.8.3-4.fc9.x86_64 requires /bin/sh tinyca2-0.7.5-3.fc7.noarch requires /usr/bin/perl tinyerp-4.2.2-1.fc9.noarch requires /bin/sh tinyerp-server-4.2.2-1.fc9.noarch requires /bin/sh tinyerp-server-4.2.2-1.fc9.noarch requires /usr/bin/python tinyerp-server-4.2.2-1.fc9.noarch requires /sbin/service tinyerp-server-4.2.2-1.fc9.noarch requires /bin/bash tinyerp-server-4.2.2-1.fc9.noarch requires /bin/sh tinyerp-server-4.2.2-1.fc9.noarch requires /sbin/chkconfig tinyproxy-1.6.3-2.fc10.x86_64 requires /bin/sh tinyproxy-1.6.3-2.fc10.x86_64 requires /bin/sh tinyxml-2.5.3-3.fc9.i386 requires /sbin/ldconfig tinyxml-2.5.3-3.fc9.x86_64 requires /sbin/ldconfig tiobench-0.3.3-7.1.x86_64 requires /usr/bin/perl tiresias-fonts-1.0-2.fc9.noarch requires /bin/sh 1:tix-8.4.2-5.fc9.i386 requires /etc/ld.so.conf.d 1:tix-8.4.2-5.fc9.i386 requires /sbin/ldconfig 1:tix-8.4.2-5.fc9.x86_64 requires /etc/ld.so.conf.d 1:tix-8.4.2-5.fc9.x86_64 requires /sbin/ldconfig 1:tk-8.5.1-4.fc10.i386 requires /bin/sh 1:tk-8.5.1-4.fc10.i386 requires /sbin/ldconfig 1:tk-8.5.1-4.fc10.i386 requires /bin/sh 1:tk-8.5.1-4.fc10.x86_64 requires /bin/sh 1:tk-8.5.1-4.fc10.x86_64 requires /sbin/ldconfig 1:tk-8.5.1-4.fc10.x86_64 requires /bin/sh tkcon-2.4-6.fc8.noarch requires /bin/sh tkcvs-8.1-1.fc9.noarch requires /bin/sh tkimg-1.3-0.10.20080505svn.fc10.x86_64 requires /sbin/ldconfig tklib-0.4.1-7.fc9.noarch requires /bin/sh tla-1.3.5-5.fc9.x86_64 requires /bin/sh tmda-1.1.12-1.fc8.noarch requires /usr/bin/python tmda-ofmipd-1.1.12-1.fc8.noarch requires /bin/sh tmda-ofmipd-1.1.12-1.fc8.noarch requires /bin/bash tmda-ofmipd-1.1.12-1.fc8.noarch requires /sbin/chkconfig tmda-ofmipd-1.1.12-1.fc8.noarch requires /usr/bin/python tmpwatch-2.9.13-2.x86_64 requires /bin/sh tn5250-0.17.3-19.fc9.i386 requires /bin/sh tn5250-0.17.3-19.fc9.i386 requires /usr/bin/tic tn5250-0.17.3-19.fc9.i386 requires /sbin/ldconfig tn5250-0.17.3-19.fc9.i386 requires /bin/sh tn5250-0.17.3-19.fc9.x86_64 requires /bin/sh tn5250-0.17.3-19.fc9.x86_64 requires /sbin/ldconfig tn5250-0.17.3-19.fc9.x86_64 requires /usr/bin/tic tn5250-0.17.3-19.fc9.x86_64 requires /bin/sh tn5250-devel-0.17.3-19.fc9.i386 requires /bin/sh tn5250-devel-0.17.3-19.fc9.x86_64 requires /bin/sh 2:tog-pegasus-2.7.0-7.fc10.i386 requires /sbin/ldconfig 2:tog-pegasus-2.7.0-7.fc10.i386 requires /bin/sh 2:tog-pegasus-2.7.0-7.fc10.i386 requires /bin/bash 2:tog-pegasus-2.7.0-7.fc10.x86_64 requires /sbin/ldconfig 2:tog-pegasus-2.7.0-7.fc10.x86_64 requires /bin/sh 2:tog-pegasus-2.7.0-7.fc10.x86_64 requires /bin/bash 2:tog-pegasus-devel-2.7.0-7.fc10.i386 requires /bin/sh 2:tog-pegasus-devel-2.7.0-7.fc10.x86_64 requires /bin/sh tokyocabinet-1.2.5-1.fc10.i386 requires /sbin/ldconfig tokyocabinet-1.2.5-1.fc10.x86_64 requires /sbin/ldconfig tolua++-1.0.92-7.fc9.i386 requires /sbin/ldconfig tolua++-1.0.92-7.fc9.x86_64 requires /sbin/ldconfig tomboy-0.10.1-2.fc9.x86_64 requires /bin/sh tomboy-0.10.1-2.fc9.x86_64 requires /usr/bin/env tomcat-native-1.1.13-1.fc9.i386 requires /sbin/ldconfig tomcat-native-1.1.13-1.fc9.x86_64 requires /sbin/ldconfig tomcat5-5.5.26-1jpp.2.fc9.x86_64 requires /bin/sh tomcat5-5.5.26-1jpp.2.fc9.x86_64 requires /usr/sbin/groupadd tomcat5-5.5.26-1jpp.2.fc9.x86_64 requires /usr/sbin/useradd tomcat5-5.5.26-1jpp.2.fc9.x86_64 requires /sbin/chkconfig tomcat5-5.5.26-1jpp.2.fc9.x86_64 requires /bin/bash tomcat5-5.5.26-1jpp.2.fc9.x86_64 requires /bin/sh tomcat5-5.5.26-1jpp.2.fc9.x86_64 requires /bin/rm tomcat5-admin-webapps-5.5.26-1jpp.2.fc9.x86_64 requires /bin/sh tomcat5-admin-webapps-5.5.26-1jpp.2.fc9.x86_64 requires /bin/rm tomcat5-common-lib-5.5.26-1jpp.2.fc9.x86_64 requires /bin/sh tomcat5-common-lib-5.5.26-1jpp.2.fc9.x86_64 requires /bin/rm tomcat5-jasper-5.5.26-1jpp.2.fc9.x86_64 requires /bin/sh tomcat5-jasper-eclipse-5.5.26-1jpp.2.fc9.x86_64 requires /bin/sh tomcat5-jsp-2.0-api-5.5.26-1jpp.2.fc9.x86_64 requires /bin/sh tomcat5-jsp-2.0-api-5.5.26-1jpp.2.fc9.x86_64 requires /sbin/chkconfig tomcat5-jsp-2.0-api-5.5.26-1jpp.2.fc9.x86_64 requires /usr/sbin/update-alternatives tomcat5-jsp-2.0-api-javadoc-5.5.26-1jpp.2.fc9.x86_64 requires /bin/sh tomcat5-jsp-2.0-api-javadoc-5.5.26-1jpp.2.fc9.x86_64 requires /bin/rm tomcat5-jsp-2.0-api-javadoc-5.5.26-1jpp.2.fc9.x86_64 requires /bin/ln tomcat5-server-lib-5.5.26-1jpp.2.fc9.x86_64 requires /bin/sh tomcat5-server-lib-5.5.26-1jpp.2.fc9.x86_64 requires /bin/rm tomcat5-servlet-2.4-api-5.5.26-1jpp.2.fc9.x86_64 requires /bin/sh tomcat5-servlet-2.4-api-5.5.26-1jpp.2.fc9.x86_64 requires /sbin/chkconfig tomcat5-servlet-2.4-api-5.5.26-1jpp.2.fc9.x86_64 requires /usr/sbin/update-alternatives tomcat5-servlet-2.4-api-javadoc-5.5.26-1jpp.2.fc9.x86_64 requires /bin/sh tomcat5-servlet-2.4-api-javadoc-5.5.26-1jpp.2.fc9.x86_64 requires /bin/rm tomcat5-servlet-2.4-api-javadoc-5.5.26-1jpp.2.fc9.x86_64 requires /bin/ln tomcat5-webapps-5.5.26-1jpp.2.fc9.x86_64 requires /bin/sh tomcat5-webapps-5.5.26-1jpp.2.fc9.x86_64 requires /bin/rm tomcat6-6.0.16-1jpp.7.fc9.noarch requires /bin/sh tomcat6-6.0.16-1jpp.7.fc9.noarch requires /sbin/chkconfig tomcat6-6.0.16-1jpp.7.fc9.noarch requires /sbin/service tomcat6-jsp-2.1-api-6.0.16-1jpp.7.fc9.noarch requires /bin/sh tomcat6-lib-6.0.16-1jpp.7.fc9.noarch requires /bin/sh tomcat6-servlet-2.5-api-6.0.16-1jpp.7.fc9.noarch requires /bin/sh tomcat6-webapps-6.0.16-1jpp.7.fc9.noarch requires /bin/sh tomoe-0.6.0-5.fc9.i386 requires /sbin/ldconfig tomoe-0.6.0-5.fc9.x86_64 requires /sbin/ldconfig tong-1.0-10.fc9.x86_64 requires /bin/sh toped-0.8.6-2.fc9.i386 requires /bin/sh toped-0.8.6-2.fc9.x86_64 requires /bin/sh tor-core-0.1.2.19-1.fc9.x86_64 requires /bin/sh tor-core-0.1.2.19-1.fc9.x86_64 requires /etc/logrotate.d tor-lsb-0.1.2.19-1.fc9.x86_64 requires /bin/sh tor-lsb-0.1.2.19-1.fc9.x86_64 requires /bin/sh torcs-1.3.0-6.fc9.x86_64 requires libplibsg.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibul.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibssgaux.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibsm.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires /bin/bash torcs-1.3.0-6.fc9.x86_64 requires libplibssg.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibsl.so.1.8.4()(64bit) torque-2.1.10-5.fc9.x86_64 requires /bin/sh torque-2.1.10-5.fc9.x86_64 requires /bin/sh torque-client-2.1.10-5.fc9.x86_64 requires /bin/sh torque-gui-2.1.10-5.fc9.x86_64 requires /usr/bin/pbs_wish torque-gui-2.1.10-5.fc9.x86_64 requires /usr/bin/wish8.5 torque-mom-2.1.10-5.fc9.x86_64 requires /bin/sh torque-mom-2.1.10-5.fc9.x86_64 requires /bin/sh torque-scheduler-2.1.10-5.fc9.x86_64 requires /bin/sh torque-scheduler-2.1.10-5.fc9.x86_64 requires /bin/sh torque-server-2.1.10-5.fc9.x86_64 requires /bin/sh torque-server-2.1.10-5.fc9.x86_64 requires /bin/sh totem-2.23.2-2.fc9.i386 requires /bin/sh totem-2.23.2-2.fc9.i386 requires /usr/bin/python totem-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 totem-2.23.2-2.fc9.i386 requires /bin/sh totem-2.23.2-2.fc9.x86_64 requires /bin/sh totem-2.23.2-2.fc9.x86_64 requires /usr/bin/python totem-2.23.2-2.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) totem-2.23.2-2.fc9.x86_64 requires /bin/sh totem-gstreamer-2.23.2-2.fc9.i386 requires /bin/sh totem-gstreamer-2.23.2-2.fc9.x86_64 requires /bin/sh totem-mozplugin-2.23.2-2.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.x86_64 requires libtotem-plparser-mini.so.10()(64bit) totem-mythtv-2.23.2-2.fc9.x86_64 requires /bin/sh totem-nautilus-2.23.2-2.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) totem-pl-parser-2.23.1-2.fc10.i386 requires /sbin/ldconfig totem-pl-parser-2.23.1-2.fc10.x86_64 requires /sbin/ldconfig totem-xine-2.23.2-2.fc9.i386 requires /bin/sh totem-xine-2.23.2-2.fc9.x86_64 requires /bin/sh tpb-0.6.4-10.fc9.x86_64 requires /bin/sh tpb-0.6.4-10.fc9.x86_64 requires /bin/sh tpm-tools-1.3.1-5.fc9.i386 requires /sbin/ldconfig tpm-tools-1.3.1-5.fc9.x86_64 requires /sbin/ldconfig trac-0.10.4-2.fc9.noarch requires /usr/bin/python trackballs-1.1.4-6.fc9.x86_64 requires /bin/sh tracker-0.6.6-2.fc9.i386 requires /sbin/ldconfig tracker-0.6.6-2.fc9.i386 requires /bin/sh tracker-0.6.6-2.fc9.x86_64 requires /sbin/ldconfig tracker-0.6.6-2.fc9.x86_64 requires /bin/sh tracker-search-tool-0.6.6-2.fc9.x86_64 requires /bin/sh 1:transfig-3.2.5-2.fc9.x86_64 requires /bin/csh 1:transfig-3.2.5-2.fc9.x86_64 requires /bin/sh translate-toolkit-1.0.1-1.fc9.noarch requires /bin/bash translate-toolkit-1.0.1-1.fc9.noarch requires /usr/bin/python transmission-1.20-1.fc10.x86_64 requires /bin/sh tre-0.7.5-5.fc9.i386 requires /sbin/ldconfig tre-0.7.5-5.fc9.x86_64 requires /sbin/ldconfig treecc-0.3.8-5.fc9.x86_64 requires /bin/sh tremulous-1.1.0-6.fc9.x86_64 requires /bin/sh tripwire-2.4.1.2-5.fc9.x86_64 requires /bin/sh tripwire-2.4.1.2-5.fc9.x86_64 requires /bin/sh trousers-0.3.1-5.fc9.i386 requires /sbin/service trousers-0.3.1-5.fc9.i386 requires /sbin/ldconfig trousers-0.3.1-5.fc9.i386 requires /bin/bash trousers-0.3.1-5.fc9.i386 requires /sbin/chkconfig trousers-0.3.1-5.fc9.i386 requires /bin/sh trousers-0.3.1-5.fc9.x86_64 requires /bin/sh trousers-0.3.1-5.fc9.x86_64 requires /sbin/service trousers-0.3.1-5.fc9.x86_64 requires /sbin/chkconfig trousers-0.3.1-5.fc9.x86_64 requires /sbin/ldconfig trousers-0.3.1-5.fc9.x86_64 requires /bin/bash ttywatch-0.14-11.fc9.x86_64 requires /bin/sh ttywatch-0.14-11.fc9.x86_64 requires /sbin/chkconfig ttywatch-0.14-11.fc9.x86_64 requires /bin/sh ttywatch-0.14-11.fc9.x86_64 requires /sbin/service turba-2.1.7-1.fc9.noarch requires /usr/bin/perl turba-2.1.7-1.fc9.noarch requires /usr/bin/php turba-2.1.7-1.fc9.noarch requires /bin/sh 1:tuxpaint-0.9.17-3.fc9.x86_64 requires /usr/share/icons/hicolor/scalable 1:tuxpaint-0.9.17-3.fc9.x86_64 requires /bin/sh tuxpuck-0.8.2-6.fc10.x86_64 requires /bin/sh tvtime-1.0.2-2.fc9.x86_64 requires /bin/sh twitux-0.62-1.fc10.x86_64 requires /bin/sh ucarp-1.4-1.fc9.x86_64 requires /bin/sh ucarp-1.4-1.fc9.x86_64 requires /bin/bash ucarp-1.4-1.fc9.x86_64 requires /sbin/chkconfig ucarp-1.4-1.fc9.x86_64 requires /bin/sh ucarp-1.4-1.fc9.x86_64 requires /sbin/service ucblogo-5.5-10.fc9.x86_64 requires /bin/sh ucblogo-5.5-10.fc9.x86_64 requires /sbin/install-info ucl-1.03-8.fc9.i386 requires /sbin/ldconfig ucl-1.03-8.fc9.x86_64 requires /sbin/ldconfig udev-121-1.20080516git.fc10.x86_64 requires /bin/sh udev-121-1.20080516git.fc10.x86_64 requires /sbin/service udev-121-1.20080516git.fc10.x86_64 requires /bin/bash udev-121-1.20080516git.fc10.x86_64 requires /bin/sh udev-121-1.20080516git.fc10.x86_64 requires /sbin/chkconfig udev-packagekit-0.2.1-2.20080508.fc10.x86_64 requires /bin/sh ufraw-0.13-4.fc9.x86_64 requires /bin/sh ufraw-common-0.13-4.fc9.x86_64 requires /bin/sh uim-1.4.2-3.fc10.i386 requires /bin/sh uim-1.4.2-3.fc10.i386 requires /sbin/ldconfig uim-1.4.2-3.fc10.i386 requires /usr/sbin/alternatives uim-1.4.2-3.fc10.x86_64 requires /bin/sh uim-1.4.2-3.fc10.x86_64 requires /sbin/ldconfig uim-1.4.2-3.fc10.x86_64 requires /usr/sbin/alternatives uim-anthy-1.4.2-3.fc10.x86_64 requires /bin/sh uim-anthy-1.4.2-3.fc10.x86_64 requires /usr/bin/uim-module-manager uim-canna-1.4.2-3.fc10.x86_64 requires /bin/sh uim-canna-1.4.2-3.fc10.x86_64 requires /usr/bin/uim-module-manager uim-gnome-1.4.2-3.fc10.x86_64 requires /bin/sh uim-gnome-1.4.2-3.fc10.x86_64 requires /usr/sbin/bonobo-activation-sysconf uim-gtk2-1.4.2-3.fc10.x86_64 requires /bin/sh uim-m17n-1.4.2-3.fc10.x86_64 requires /bin/sh uim-m17n-1.4.2-3.fc10.x86_64 requires /usr/bin/uim-module-manager uim-skk-1.4.2-3.fc10.x86_64 requires /bin/sh uim-skk-1.4.2-3.fc10.x86_64 requires /usr/bin/uim-module-manager ularn-1.5p4-11.fc9.x86_64 requires /bin/sh ulogd-1.24-9.fc9.x86_64 requires /bin/sh ulogd-1.24-9.fc9.x86_64 requires /bin/sh unicap-0.2.19-3.fc9.i386 requires /sbin/ldconfig unicap-0.2.19-3.fc9.x86_64 requires /sbin/ldconfig uniconvertor-1.1.2-2.fc10.x86_64 requires /usr/bin/python uniconvertor-1.1.2-2.fc10.x86_64 requires /bin/sh unifdef-1.171-7.fc9.x86_64 requires /bin/sh unique-0.9.4-5.fc10.i386 requires /sbin/ldconfig unique-0.9.4-5.fc10.x86_64 requires /sbin/ldconfig unison213-2.13.16-10.fc9.x86_64 requires /bin/sh unison213-2.13.16-10.fc9.x86_64 requires /usr/sbin/alternatives unison213-2.13.16-10.fc9.x86_64 requires /usr/sbin/alternatives unison213-2.13.16-10.fc9.x86_64 requires /bin/sh unison227-2.27.57-8.fc9.x86_64 requires /bin/sh unison227-2.27.57-8.fc9.x86_64 requires /usr/sbin/alternatives unison227-2.27.57-8.fc9.x86_64 requires /usr/sbin/alternatives unison227-2.27.57-8.fc9.x86_64 requires /bin/sh units-1.87-2.fc9.x86_64 requires /bin/sh units-1.87-2.fc9.x86_64 requires /sbin/install-info unixODBC-2.2.12-7.fc9.i386 requires /sbin/ldconfig unixODBC-2.2.12-7.fc9.x86_64 requires /sbin/ldconfig unixODBC-kde-2.2.12-7.fc9.i386 requires /sbin/ldconfig unixODBC-kde-2.2.12-7.fc9.x86_64 requires /sbin/ldconfig unixcw-2.3-2.fc9.i386 requires /sbin/ldconfig unixcw-2.3-2.fc9.x86_64 requires /sbin/ldconfig unshield-0.5-8.fc9.i386 requires /sbin/ldconfig unshield-0.5-8.fc9.x86_64 requires /sbin/ldconfig unuran-1.2.4p1-1.fc10.i386 requires /bin/sh unuran-1.2.4p1-1.fc10.i386 requires /sbin/ldconfig unuran-1.2.4p1-1.fc10.i386 requires /sbin/install-info unuran-1.2.4p1-1.fc10.x86_64 requires /bin/sh unuran-1.2.4p1-1.fc10.x86_64 requires /sbin/ldconfig unuran-1.2.4p1-1.fc10.x86_64 requires /sbin/install-info unzip-5.52-9.fc9.x86_64 requires /bin/sh up-imapproxy-1.2.4-9.fc9.x86_64 requires /bin/sh up-imapproxy-1.2.4-9.fc9.x86_64 requires /bin/bash up-imapproxy-1.2.4-9.fc9.x86_64 requires /sbin/chkconfig up-imapproxy-1.2.4-9.fc9.x86_64 requires /sbin/service uqm-0.6.2-3.fc9.x86_64 requires /bin/sh urbanterror-1.34-0.9.rc4.fc9.x86_64 requires /bin/sh urbanterror-1.34-0.9.rc4.fc9.x86_64 requires /bin/bash urlview-0.9-4.fc9.x86_64 requires /bin/bash urw-fonts-2.4-5.fc9.noarch requires /bin/sh usermode-1.97-1.x86_64 requires /etc/pam.d/system-auth ushare-1.1a-4.fc9.x86_64 requires /bin/sh ushare-1.1a-4.fc9.x86_64 requires /sbin/service ushare-1.1a-4.fc9.x86_64 requires /usr/sbin/alternatives ushare-1.1a-4.fc9.x86_64 requires /usr/sbin/alternatives ushare-1.1a-4.fc9.x86_64 requires /bin/sh ushare-1.1a-4.fc9.x86_64 requires /sbin/chkconfig usrp-3.1.1-4.fc9.i386 requires /usr/bin/env usrp-3.1.1-4.fc9.i386 requires /sbin/ldconfig usrp-3.1.1-4.fc9.x86_64 requires /usr/bin/env usrp-3.1.1-4.fc9.x86_64 requires /sbin/ldconfig ustr-1.0.4-6.fc9.i386 requires /sbin/ldconfig ustr-1.0.4-6.fc9.x86_64 requires /sbin/ldconfig ustr-debug-1.0.4-6.fc9.i386 requires /sbin/ldconfig ustr-debug-1.0.4-6.fc9.x86_64 requires /sbin/ldconfig ustr-devel-1.0.4-6.fc9.i386 requires /bin/sh ustr-devel-1.0.4-6.fc9.x86_64 requires /bin/sh util-linux-ng-2.13.1-9.fc10.x86_64 requires /bin/sh util-linux-ng-2.13.1-9.fc10.x86_64 requires /etc/pam.d/system-auth util-linux-ng-2.13.1-9.fc10.x86_64 requires /sbin/install-info util-vserver-0.30.215-2.fc9.x86_64 requires /bin/sh util-vserver-0.30.215-2.fc9.x86_64 requires /usr/lib64/util-vserver util-vserver-0.30.215-2.fc9.x86_64 requires /bin/bash util-vserver-0.30.215-2.fc9.x86_64 requires /bin/sh util-vserver-0.30.215-2.fc9.x86_64 requires /usr/lib64/util-vserver/sigexec util-vserver-build-0.30.215-2.fc9.x86_64 requires /bin/sh util-vserver-build-0.30.215-2.fc9.x86_64 requires /bin/bash util-vserver-build-0.30.215-2.fc9.x86_64 requires /bin/sh util-vserver-build-0.30.215-2.fc9.x86_64 requires /etc/vservers util-vserver-core-0.30.215-2.fc9.x86_64 requires /bin/bash util-vserver-legacy-0.30.215-2.fc9.x86_64 requires /bin/bash util-vserver-legacy-0.30.215-2.fc9.x86_64 requires /bin/sh util-vserver-legacy-0.30.215-2.fc9.x86_64 requires /usr/bin/perl util-vserver-legacy-0.30.215-2.fc9.x86_64 requires /usr/lib64/util-vserver util-vserver-legacy-0.30.215-2.fc9.x86_64 requires /sbin/chkconfig util-vserver-legacy-0.30.215-2.fc9.x86_64 requires /etc/rc.d/init.d util-vserver-legacy-0.30.215-2.fc9.x86_64 requires /bin/sh util-vserver-lib-0.30.215-2.fc9.i386 requires /sbin/ldconfig util-vserver-lib-0.30.215-2.fc9.x86_64 requires /sbin/ldconfig util-vserver-sysv-0.30.215-2.fc9.x86_64 requires /bin/sh util-vserver-sysv-0.30.215-2.fc9.x86_64 requires /bin/bash util-vserver-sysv-0.30.215-2.fc9.x86_64 requires /usr/lib64/util-vserver util-vserver-sysv-0.30.215-2.fc9.x86_64 requires /sbin/chkconfig util-vserver-sysv-0.30.215-2.fc9.x86_64 requires /etc/rc.d/init.d util-vserver-sysv-0.30.215-2.fc9.x86_64 requires /bin/sh uucp-1.07-17.fc9.x86_64 requires /bin/sh uucp-1.07-17.fc9.x86_64 requires /bin/sh uucp-1.07-17.fc9.x86_64 requires /usr/bin/perl uucp-1.07-17.fc9.x86_64 requires /sbin/install-info uudeview-0.5.20-16.x86_64 requires /bin/sh uuid-1.6.1-3.fc9.i386 requires /sbin/ldconfig uuid-1.6.1-3.fc9.x86_64 requires /sbin/ldconfig uuid-c++-1.6.1-3.fc9.i386 requires /sbin/ldconfig uuid-c++-1.6.1-3.fc9.x86_64 requires /sbin/ldconfig uuid-dce-1.6.1-3.fc9.i386 requires /sbin/ldconfig uuid-dce-1.6.1-3.fc9.x86_64 requires /sbin/ldconfig uuid-devel-1.6.1-3.fc9.i386 requires /bin/sh uuid-devel-1.6.1-3.fc9.i386 requires /usr/lib/pkgconfig uuid-devel-1.6.1-3.fc9.x86_64 requires /usr/lib64/pkgconfig uuid-devel-1.6.1-3.fc9.x86_64 requires /bin/sh uuid-pgsql-1.6.1-3.fc9.x86_64 requires /usr/share/pgsql uuid-pgsql-1.6.1-3.fc9.x86_64 requires /usr/lib64/pgsql uuid-php-1.6.1-3.fc9.x86_64 requires /usr/lib64/php/modules uuidd-1.40.9-2.fc10.x86_64 requires /bin/sh uuidd-1.40.9-2.fc10.x86_64 requires /bin/bash uw-imap-2007a1-3.fc9.x86_64 requires /bin/sh vala-0.1.7-1.fc9.i386 requires /sbin/ldconfig vala-0.1.7-1.fc9.x86_64 requires /sbin/ldconfig vala-tools-0.1.7-1.fc9.x86_64 requires /bin/sh 1:valgrind-3.3.0-3.i386 requires /usr/bin/perl 1:valgrind-3.3.0-3.x86_64 requires /usr/bin/perl vamp-plugin-sdk-1.1b-4.fc9.i386 requires /sbin/ldconfig vamp-plugin-sdk-1.1b-4.fc9.x86_64 requires /sbin/ldconfig varconf-0.6.5-3.fc9.i386 requires /sbin/ldconfig varconf-0.6.5-3.fc9.x86_64 requires /sbin/ldconfig varnish-1.1.2-6.fc9.x86_64 requires /bin/sh varnish-1.1.2-6.fc9.x86_64 requires /sbin/service varnish-1.1.2-6.fc9.x86_64 requires /bin/sh varnish-1.1.2-6.fc9.x86_64 requires /sbin/chkconfig varnish-libs-1.1.2-6.fc9.i386 requires /sbin/ldconfig varnish-libs-1.1.2-6.fc9.x86_64 requires /sbin/ldconfig vavoom-1.27.1-1.fc9.x86_64 requires /bin/sh vavoom-1.27.1-1.fc9.x86_64 requires /bin/bash vblade-14-4.fc9.x86_64 requires /bin/sh vblade-14-4.fc9.x86_64 requires /sbin/chkconfig vblade-14-4.fc9.x86_64 requires /bin/sh vblade-14-4.fc9.x86_64 requires /sbin/service vdccm-0.10.1-3.fc9.x86_64 requires /sbin/ldconfig vdr-1.6.0-3.fc9.x86_64 requires /bin/sh vdr-1.6.0-3.fc9.x86_64 requires /bin/bash vdr-1.6.0-3.fc9.x86_64 requires /bin/sh vdr-1.6.0-3.fc9.x86_64 requires /usr/bin/perl vdr-1.6.0-3.fc9.x86_64 requires /sbin/chkconfig vdr-devel-1.6.0-3.fc9.i386 requires /bin/bash vdr-devel-1.6.0-3.fc9.i386 requires /usr/bin/perl vdr-devel-1.6.0-3.fc9.x86_64 requires /bin/bash vdr-devel-1.6.0-3.fc9.x86_64 requires /usr/bin/perl vdr-osdteletext-0.5.1-31.fc9.x86_64 requires /bin/sh vdr-skins-20061119-6.fc9.noarch requires /bin/sh vdr-text2skin-1.1-23.cvsext0.10.fc9.x86_64 requires /bin/sh vdradmin-am-3.6.1-1.fc8.noarch requires /bin/sh vdradmin-am-3.6.1-1.fc8.noarch requires /usr/bin/perl vdradmin-am-3.6.1-1.fc8.noarch requires /bin/sh vdradmin-am-3.6.1-1.fc8.noarch requires /sbin/chkconfig vdrift-20071226-3.fc9.x86_64 requires /bin/sh vecmath1.2-1.14-2.fc9.x86_64 requires /bin/sh vecmath1.2-javadoc-1.14-2.fc9.x86_64 requires /bin/sh vegastrike-0.5.0-2.fc10.x86_64 requires /usr/bin/perl vegastrike-0.5.0-2.fc10.x86_64 requires /bin/sh vegastrike-data-0.5.0-2.noarch requires /bin/sh vegastrike-data-0.5.0-2.noarch requires /usr/bin/python velocity-1.4-7jpp.1.x86_64 requires /bin/sh velocity-demo-1.4-7jpp.1.x86_64 requires /bin/sh velocity-javadoc-1.4-7jpp.1.x86_64 requires /bin/sh velocity-javadoc-1.4-7jpp.1.x86_64 requires /bin/rm velocity-javadoc-1.4-7jpp.1.x86_64 requires /bin/ln verbiste-0.1.22-1.fc9.i386 requires /sbin/ldconfig verbiste-0.1.22-1.fc9.x86_64 requires /sbin/ldconfig verbiste-gnome-0.1.22-1.fc9.x86_64 requires /bin/sh veusz-1.0-3.fc9.x86_64 requires /bin/sh veusz-1.0-3.fc9.x86_64 requires /usr/bin/env veusz-1.0-3.fc9.x86_64 requires /usr/bin/python viewvc-1.0.5-1.fc9.noarch requires /usr/bin/python vigra-1.5.0-4.fc9.i386 requires /sbin/ldconfig vigra-1.5.0-4.fc9.x86_64 requires /sbin/ldconfig vigra-devel-1.5.0-4.fc9.i386 requires /bin/sh vigra-devel-1.5.0-4.fc9.x86_64 requires /bin/sh 2:vim-X11-7.1.298-1.fc10.x86_64 requires /bin/sh 2:vim-X11-7.1.298-1.fc10.x86_64 requires /bin/sh 2:vim-common-7.1.298-1.fc10.x86_64 requires /bin/sh 2:vim-enhanced-7.1.298-1.fc10.x86_64 requires /bin/sh vim-vimoutliner-0.3.4-9.fc7.noarch requires /bin/sh vim-vimoutliner-0.3.4-9.fc7.noarch requires /usr/bin/perl vim-vimoutliner-0.3.4-9.fc7.noarch requires /usr/bin/python vinagre-2.23.1-1.fc10.x86_64 requires /bin/sh vino-2.22.1-1.fc9.x86_64 requires /bin/sh vips-7.14.1-1.fc9.i386 requires /sbin/ldconfig vips-7.14.1-1.fc9.i386 requires libWand.so.10 vips-7.14.1-1.fc9.i386 requires libMagick.so.10 vips-7.14.1-1.fc9.x86_64 requires /sbin/ldconfig vips-7.14.1-1.fc9.x86_64 requires libMagick.so.10()(64bit) vips-7.14.1-1.fc9.x86_64 requires libWand.so.10()(64bit) vips-python-7.14.1-1.fc9.x86_64 requires libMagick.so.10()(64bit) vips-python-7.14.1-1.fc9.x86_64 requires libWand.so.10()(64bit) vips-tools-7.14.1-1.fc9.x86_64 requires libMagick.so.10()(64bit) vips-tools-7.14.1-1.fc9.x86_64 requires /bin/bash vips-tools-7.14.1-1.fc9.x86_64 requires /bin/sh vips-tools-7.14.1-1.fc9.x86_64 requires libWand.so.10()(64bit) virt-manager-0.5.4-3.fc9.x86_64 requires /bin/sh virt-manager-0.5.4-3.fc9.x86_64 requires /bin/sh vkeybd-0.1.17a-7.fc9.x86_64 requires /bin/sh vkeybd-0.1.17a-7.fc9.x86_64 requires /usr/bin/wish vlock-1.3-26.fc9.x86_64 requires /etc/pam.d/system-auth vnc-4.1.2-30.fc10.x86_64 requires /bin/sh vnc-libs-4.1.2-30.fc10.i386 requires /bin/sh vnc-libs-4.1.2-30.fc10.x86_64 requires /bin/sh vnc-ltsp-config-4.0-4.fc9.noarch requires /bin/sh vnc-ltsp-config-4.0-4.fc9.noarch requires /bin/sh vnc-server-4.1.2-30.fc10.x86_64 requires /bin/sh vnc-server-4.1.2-30.fc10.x86_64 requires /usr/bin/env vnc-server-4.1.2-30.fc10.x86_64 requires /bin/bash vnstat-1.6-2.fc9.x86_64 requires /bin/sh vnstat-1.6-2.fc9.x86_64 requires /usr/sbin/useradd vodovod-1.10-2.fc9.x86_64 requires /bin/sh vodovod-1.10-2.fc9.x86_64 requires /bin/sh vpnc-0.5.1-5.fc9.x86_64 requires /bin/sh vpnc-consoleuser-0.5.1-5.fc9.x86_64 requires /bin/sh vsftpd-2.0.6-3.fc9.x86_64 requires /bin/sh vsftpd-2.0.6-3.fc9.x86_64 requires /lib64/security/pam_loginuid.so vsftpd-2.0.6-3.fc9.x86_64 requires /sbin/service vsftpd-2.0.6-3.fc9.x86_64 requires /bin/bash vsftpd-2.0.6-3.fc9.x86_64 requires /sbin/chkconfig vte-0.16.13-1.fc9.i386 requires /sbin/ldconfig vte-0.16.13-1.fc9.x86_64 requires /sbin/ldconfig vte-devel-0.16.13-1.fc9.i386 requires /bin/sh vte-devel-0.16.13-1.fc9.x86_64 requires /bin/sh vtk-5.0.4-21.fc9.i386 requires /sbin/ldconfig vtk-5.0.4-21.fc9.x86_64 requires /sbin/ldconfig vtk-devel-5.0.4-21.fc9.i386 requires /usr/bin/env vtk-devel-5.0.4-21.fc9.x86_64 requires /usr/bin/env vtk-python-5.0.4-21.fc9.i386 requires /sbin/ldconfig vtk-python-5.0.4-21.fc9.x86_64 requires /sbin/ldconfig vtk-qt-5.0.4-21.fc9.i386 requires /sbin/ldconfig vtk-qt-5.0.4-21.fc9.x86_64 requires /sbin/ldconfig vtk-tcl-5.0.4-21.fc9.i386 requires /sbin/ldconfig vtk-tcl-5.0.4-21.fc9.x86_64 requires /sbin/ldconfig vtk-testing-5.0.4-21.fc9.x86_64 requires /usr/bin/tclsh vtk-testing-5.0.4-21.fc9.x86_64 requires /usr/bin/env vym-1.10.0-3.fc9.x86_64 requires /bin/sh vym-1.10.0-3.fc9.x86_64 requires /bin/bash vym-1.10.0-3.fc9.x86_64 requires /usr/bin/perl w3c-libwww-5.4.1-0.10.20060206cvs.fc9.i386 requires /sbin/ldconfig w3c-libwww-5.4.1-0.10.20060206cvs.fc9.x86_64 requires /sbin/ldconfig w3c-libwww-devel-5.4.1-0.10.20060206cvs.fc9.i386 requires /bin/sh w3c-libwww-devel-5.4.1-0.10.20060206cvs.fc9.x86_64 requires /bin/sh w3c-markup-validator-0.8.2-3.fc9.noarch requires /bin/sh w3c-markup-validator-0.8.2-3.fc9.noarch requires /usr/bin/perl w3c-markup-validator-libs-0.8.2-3.fc9.noarch requires /bin/sh w3m-0.5.2-10.fc10.x86_64 requires /usr/bin/perl w3m-el-common-1.4.4-7.fc9.noarch requires /bin/sh w3m-el-common-1.4.4-7.fc9.noarch requires /sbin/install-info waf-1.4.1-1.fc10.noarch requires /usr/bin/python wallpapoz-0.4.1-5.svn87_trunk.fc9.noarch requires /usr/bin/pgrep wallpapoz-0.4.1-5.svn87_trunk.fc9.noarch requires /usr/bin/kill wallpapoz-0.4.1-5.svn87_trunk.fc9.noarch requires /usr/bin/env wammu-0.26-2.fc9.noarch requires /usr/bin/python wavbreaker-0.9-3.fc9.x86_64 requires /bin/sh wavextract-1.0.0-3.fc9.noarch requires /usr/bin/env wavpack-4.41-2.fc9.i386 requires /sbin/ldconfig wavpack-4.41-2.fc9.x86_64 requires /sbin/ldconfig wbxml2-0.9.2-13.fc9.i386 requires /sbin/ldconfig wbxml2-0.9.2-13.fc9.x86_64 requires /sbin/ldconfig wdaemon-0.13-1.fc9.x86_64 requires /bin/sh wdaemon-0.13-1.fc9.x86_64 requires /bin/bash wdm-1.28-10.fc9.x86_64 requires /sbin/shutdown wdm-1.28-10.fc9.x86_64 requires /etc/pam.d wdm-1.28-10.fc9.x86_64 requires /bin/bash wdm-1.28-10.fc9.x86_64 requires /bin/sh wdm-1.28-10.fc9.x86_64 requires /usr/bin/perl web2png-2.5.1-4.fc9.x86_64 requires /usr/bin/env webalizer-2.01_10-36.x86_64 requires /bin/sh webalizer-2.01_10-36.x86_64 requires /bin/bash webalizer-2.01_10-36.x86_64 requires /usr/sbin/useradd websec-1.9.0-4.1.noarch requires /usr/bin/perl werken-xpath-0.9.4-1.beta.12jpp.2.x86_64 requires /bin/sh werken-xpath-javadoc-0.9.4-1.beta.12jpp.2.x86_64 requires /bin/sh werken-xpath-javadoc-0.9.4-1.beta.12jpp.2.x86_64 requires /bin/ln werken-xpath-javadoc-0.9.4-1.beta.12jpp.2.x86_64 requires /bin/rm wesnoth-1.4.2-1.fc10.x86_64 requires /bin/sh wesnoth-server-1.4.2-1.fc10.x86_64 requires /bin/sh wesnoth-server-1.4.2-1.fc10.x86_64 requires /bin/sh wesnoth-server-1.4.2-1.fc10.x86_64 requires /sbin/chkconfig wesnoth-server-1.4.2-1.fc10.x86_64 requires /usr/sbin/useradd wesnoth-tools-1.4.2-1.fc10.x86_64 requires /usr/bin/env wfmath-0.3.7-2.fc9.i386 requires /sbin/ldconfig wfmath-0.3.7-2.fc9.x86_64 requires /sbin/ldconfig wfut-1.1.0-5.fc9.x86_64 requires /bin/sh wget-1.11.2-1.fc10.x86_64 requires /bin/sh wget-1.11.2-1.fc10.x86_64 requires /sbin/install-info which-2.19-3.fc9.x86_64 requires /bin/sh which-2.19-3.fc9.x86_64 requires /sbin/install-info whysynth-dssi-20070418-2.fc9.x86_64 requires /bin/sh widelands-0-0.9.build11.fc9.x86_64 requires /bin/sh wifi-radar-1.9.6-3.fc6.noarch requires /usr/bin/python wifiroamd-1.12-1.fc8.noarch requires /bin/sh wildmidi-libs-0.2.2-4.fc9.i386 requires /sbin/ldconfig wildmidi-libs-0.2.2-4.fc9.x86_64 requires /sbin/ldconfig wine-capi-0.9.58-1.fc9.i386 requires /sbin/ldconfig wine-cms-0.9.58-1.fc9.i386 requires /sbin/ldconfig wine-core-0.9.58-1.fc9.i386 requires /bin/sh wine-core-0.9.58-1.fc9.i386 requires /sbin/service wine-core-0.9.58-1.fc9.i386 requires /sbin/ldconfig wine-core-0.9.58-1.fc9.i386 requires /usr/bin/xmessage wine-core-0.9.58-1.fc9.i386 requires /bin/sh wine-core-0.9.58-1.fc9.i386 requires /sbin/chkconfig wine-devel-0.9.58-1.fc9.i386 requires /usr/bin/perl wine-esd-0.9.58-1.fc9.i386 requires /sbin/ldconfig wine-jack-0.9.58-1.fc9.i386 requires /sbin/ldconfig wine-ldap-0.9.58-1.fc9.i386 requires /sbin/ldconfig wine-nas-0.9.58-1.fc9.i386 requires /sbin/ldconfig wine-tools-0.9.58-1.fc9.i386 requires /usr/bin/perl wine-tools-0.9.58-1.fc9.i386 requires /bin/sh wine-twain-0.9.58-1.fc9.i386 requires /sbin/ldconfig wings-0.99.02-1.fc9.x86_64 requires /bin/sh winpdb-1.3.8-1.fc10.noarch requires /usr/bin/env winpdb-1.3.8-1.fc10.noarch requires /usr/bin/python 1:wireless-tools-29-2.fc9.i386 requires /sbin/ldconfig 1:wireless-tools-29-2.fc9.x86_64 requires /sbin/ldconfig wireshark-1.0.0-2.fc9.i386 requires /sbin/ldconfig wireshark-1.0.0-2.fc9.x86_64 requires /sbin/ldconfig wkf-libs-1.3.11-2.fc9.i386 requires /sbin/ldconfig wkf-libs-1.3.11-2.fc9.x86_64 requires /sbin/ldconfig wklej-0.0.9-3.fc9.noarch requires /usr/bin/perl wlassistant-0.5.7-7.fc9.x86_64 requires /bin/sh wmx-6pl1-18.fc9.x86_64 requires /bin/bash wmx-6pl1-18.fc9.x86_64 requires /bin/sh wodim-1.1.6-11.fc9.x86_64 requires /bin/sh wodim-1.1.6-11.fc9.x86_64 requires /usr/sbin/alternatives wordwarvi-0.09-1.fc10.x86_64 requires /bin/sh worldofpadman-1.34-0.9.rc4.fc9.x86_64 requires /bin/bash worldofpadman-1.34-0.9.rc4.fc9.x86_64 requires /bin/sh worminator-3.0R2.1-8.fc9.x86_64 requires /bin/sh wormux-0.7.9-6.fc9.x86_64 requires /bin/sh wp_tray-0.5.3-7.fc9.x86_64 requires /bin/sh 1:wpa_supplicant-0.6.3-5.fc9.x86_64 requires /bin/sh 1:wpa_supplicant-0.6.3-5.fc9.x86_64 requires /bin/bash 1:wpa_supplicant-0.6.3-5.fc9.x86_64 requires /usr/bin/python wqy-bitmap-fonts-0.9.9-6.fc10.noarch requires /bin/sh wqy-unibit-fonts-1.1.0-4.fc8.noarch requires /bin/sh wqy-zenhei-fonts-0.5.23-0.fc9.noarch requires /bin/sh writer2latex-0.5-2.fc9.x86_64 requires /bin/sh ws-commons-util-1.0.1-6.fc8.x86_64 requires /usr/bin/rebuild-gcj-db wsdl4j-1.5.2-5jpp.2.fc9.x86_64 requires /bin/sh wsdl4j-javadoc-1.5.2-5jpp.2.fc9.x86_64 requires /bin/sh wsdl4j-javadoc-1.5.2-5jpp.2.fc9.x86_64 requires /bin/rm wsdl4j-javadoc-1.5.2-5jpp.2.fc9.x86_64 requires /bin/ln wuja-0.0.8-3.fc9.noarch requires /bin/sh wuja-0.0.8-3.fc9.noarch requires /usr/bin/python wv-1.2.4-4.fc9.i386 requires /sbin/ldconfig wv-1.2.4-4.fc9.i386 requires /bin/sh wv-1.2.4-4.fc9.x86_64 requires /sbin/ldconfig wv-1.2.4-4.fc9.x86_64 requires /bin/sh wv2-0.2.3-7.fc9.i386 requires /sbin/ldconfig wv2-0.2.3-7.fc9.x86_64 requires /sbin/ldconfig wv2-devel-0.2.3-7.fc9.i386 requires /bin/sh wv2-devel-0.2.3-7.fc9.x86_64 requires /bin/sh wxBase-2.8.7-2.fc9.i386 requires /sbin/ldconfig wxBase-2.8.7-2.fc9.x86_64 requires /sbin/ldconfig wxGTK-2.8.7-2.fc9.i386 requires /sbin/ldconfig wxGTK-2.8.7-2.fc9.x86_64 requires /sbin/ldconfig wxGTK-devel-2.8.7-2.fc9.i386 requires /bin/sh wxGTK-devel-2.8.7-2.fc9.x86_64 requires /bin/sh wxGTK-gl-2.8.7-2.fc9.i386 requires /sbin/ldconfig wxGTK-gl-2.8.7-2.fc9.x86_64 requires /sbin/ldconfig wxGlade-0.6.1-1.fc9.noarch requires /bin/sh wxGlade-0.6.1-1.fc9.noarch requires /bin/bash wxMaxima-0.7.4-3.fc9.x86_64 requires /bin/sh wxPython-2.8.7.1-2.fc9.x86_64 requires /usr/bin/env wxPython-2.8.7.1-2.fc9.x86_64 requires /usr/bin/python wxPython-2.8.7.1-2.fc9.x86_64 requires /bin/bash wxPython-2.8.7.1-2.fc9.x86_64 requires /bin/sh wxsvg-1.0-0.8.b10.fc10.i386 requires /sbin/ldconfig wxsvg-1.0-0.8.b10.fc10.x86_64 requires /sbin/ldconfig x11-ssh-askpass-1.2.4.1-4.fc9.x86_64 requires /usr/share/X11/app-defaults x3270-x11-3.3.6-5.fc9.x86_64 requires /bin/sh x3270-x11-3.3.6-5.fc9.x86_64 requires /usr/bin/mkfontdir xalan-c-1.10.0-4.fc9.i386 requires /sbin/ldconfig xalan-c-1.10.0-4.fc9.x86_64 requires /sbin/ldconfig xalan-c-doc-1.10.0-4.fc9.x86_64 requires /bin/sh xalan-j2-2.7.0-7jpp.2.fc9.x86_64 requires /bin/sh xalan-j2-2.7.0-7jpp.2.fc9.x86_64 requires /usr/sbin/update-alternatives xalan-j2-demo-2.7.0-7jpp.2.fc9.x86_64 requires /bin/sh xalan-j2-javadoc-2.7.0-7jpp.2.fc9.x86_64 requires /bin/sh xalan-j2-javadoc-2.7.0-7jpp.2.fc9.x86_64 requires /bin/rm xalan-j2-javadoc-2.7.0-7jpp.2.fc9.x86_64 requires /bin/ln xalan-j2-xsltc-2.7.0-7jpp.2.fc9.x86_64 requires /bin/sh xaos-3.2.3-3.fc9.x86_64 requires /bin/sh xaos-3.2.3-3.fc9.x86_64 requires /sbin/install-info xapian-core-devel-1.0.6-1.fc9.i386 requires /bin/sh xapian-core-devel-1.0.6-1.fc9.x86_64 requires /bin/sh xapian-core-libs-1.0.6-1.fc9.i386 requires /sbin/ldconfig xapian-core-libs-1.0.6-1.fc9.x86_64 requires /sbin/ldconfig xar-1.5.1-6.fc9.i386 requires /sbin/ldconfig xar-1.5.1-6.fc9.x86_64 requires /sbin/ldconfig xarchiver-0.4.9-0.6.20070103svn24249.fc9.x86_64 requires /bin/sh xarchiver-0.4.9-0.6.20070103svn24249.fc9.x86_64 requires /bin/sh xarchon-0.50-7.fc9.x86_64 requires /bin/sh xastir-1.9.2-5.fc10.x86_64 requires /usr/bin/env xastir-1.9.2-5.fc10.x86_64 requires /bin/bash xastir-1.9.2-5.fc10.x86_64 requires /bin/sh xastir-1.9.2-5.fc10.x86_64 requires /usr/bin/perl xawtv-3.95-8.fc9.x86_64 requires /bin/bash xbae-4.60.4-9.fc9.i386 requires /sbin/ldconfig xbae-4.60.4-9.fc9.x86_64 requires /sbin/ldconfig xbase-2.0.0-11.fc9.i386 requires /sbin/ldconfig xbase-2.0.0-11.fc9.x86_64 requires /sbin/ldconfig xbase-devel-2.0.0-11.fc9.i386 requires /bin/sh xbase-devel-2.0.0-11.fc9.x86_64 requires /bin/sh xbindkeys-1.8.2-2.fc9.x86_64 requires /bin/sh xblast-2.10.4-5.fc9.x86_64 requires /usr/share/fonts/bitstream-vera/Vera.ttf xblast-common-2.10.4-5.fc9.x86_64 requires /bin/sh xblast-common-2.10.4-5.fc9.x86_64 requires /bin/bash xboard-4.2.7-17.fc9.x86_64 requires /bin/sh xboard-4.2.7-17.fc9.x86_64 requires /usr/bin/perl xboard-4.2.7-17.fc9.x86_64 requires /bin/sh xbsql-0.11-11.fc9.i386 requires /sbin/ldconfig xbsql-0.11-11.fc9.x86_64 requires /sbin/ldconfig xca-0.6.4-4.fc9.x86_64 requires /bin/sh xca-0.6.4-4.fc9.x86_64 requires /bin/sh 1:xchat-2.8.4-15.fc9.x86_64 requires /bin/sh xchat-gnome-0.18-12.fc9.x86_64 requires /bin/sh xchm-1.14-1.fc9.x86_64 requires /bin/sh xcircuit-3.4.27-3.fc9.x86_64 requires /bin/sh xcircuit-3.4.27-3.fc9.x86_64 requires /bin/sh xclip-0.10-3.fc9.x86_64 requires /bin/sh xdelta-1.1.4-3.fc9.i386 requires /sbin/ldconfig xdelta-1.1.4-3.fc9.x86_64 requires /sbin/ldconfig xdelta-devel-1.1.4-3.fc9.i386 requires /bin/bash xdelta-devel-1.1.4-3.fc9.x86_64 requires /bin/bash xdg-user-dirs-0.10-1.fc9.x86_64 requires /bin/sh xdg-user-dirs-0.10-1.fc9.x86_64 requires /etc/X11/xinit/xinitrc.d xdg-utils-1.0.2-4.fc9.noarch requires /bin/bash xdg-utils-1.0.2-4.fc9.noarch requires /bin/sh xdoclet-1.2.3-9jpp.1.fc9.x86_64 requires /bin/sh xdvik-22.84.13-20.fc10.x86_64 requires /bin/sh xdvik-22.84.13-20.fc10.x86_64 requires /bin/sh xemacs-21.5.28-6.fc9.x86_64 requires /bin/sh xemacs-21.5.28-6.fc9.x86_64 requires /bin/sh xemacs-common-21.5.28-6.fc9.x86_64 requires /bin/sh xemacs-common-21.5.28-6.fc9.x86_64 requires /usr/sbin/alternatives xemacs-common-21.5.28-6.fc9.x86_64 requires /bin/sh xemacs-ess-5.3.7-1.fc10.noarch requires /bin/sh xemacs-info-21.5.28-6.fc9.x86_64 requires /bin/sh xemacs-info-21.5.28-6.fc9.x86_64 requires /sbin/install-info xemacs-nox-21.5.28-6.fc9.x86_64 requires /bin/sh xemacs-packages-extra-20070427-1.fc8.noarch requires /usr/bin/perl xemacs-packages-extra-20070427-1.fc8.noarch requires /usr/bin/env xemacs-packages-extra-20070427-1.fc8.noarch requires /bin/sh xen-3.2.0-10.fc9.x86_64 requires /bin/sh xen-3.2.0-10.fc9.x86_64 requires /usr/bin/env xen-3.2.0-10.fc9.x86_64 requires /bin/bash xen-libs-3.2.0-10.fc9.i386 requires /sbin/ldconfig xen-libs-3.2.0-10.fc9.x86_64 requires /sbin/ldconfig xen-runtime-3.2.0-10.fc9.x86_64 requires /bin/sh xen-runtime-3.2.0-10.fc9.x86_64 requires /usr/bin/env xen-runtime-3.2.0-10.fc9.x86_64 requires /usr/bin/python xen-runtime-3.2.0-10.fc9.x86_64 requires /bin/bash xen-runtime-3.2.0-10.fc9.x86_64 requires /bin/sh xenner-0.34-1.fc10.x86_64 requires /bin/sh xenner-0.34-1.fc10.x86_64 requires /bin/sh xerces-c-2.8.0-1.fc9.i386 requires /sbin/ldconfig xerces-c-2.8.0-1.fc9.x86_64 requires /sbin/ldconfig xerces-c27-2.7.0-4.fc9.i386 requires /sbin/ldconfig xerces-c27-2.7.0-4.fc9.x86_64 requires /sbin/ldconfig xerces-j2-2.7.1-10jpp.1.fc9.x86_64 requires /bin/sh xerces-j2-2.7.1-10jpp.1.fc9.x86_64 requires /usr/sbin/update-alternatives xerces-j2-demo-2.7.1-10jpp.1.fc9.x86_64 requires /bin/sh xfce-mcs-plugins-4.4.2-4.fc9.x86_64 requires /bin/sh xfce-utils-4.4.2-4.fc9.x86_64 requires /usr/bin/id xfce-utils-4.4.2-4.fc9.x86_64 requires /bin/sh xfce4-appfinder-4.4.2-2.fc9.x86_64 requires /bin/sh xfce4-battery-plugin-0.5.0-4.fc9.x86_64 requires /bin/sh xfce4-dev-tools-4.4.0-1.fc7.noarch requires /bin/sh xfce4-dict-plugin-0.3.0-1.fc9.x86_64 requires /bin/sh xfce4-eyes-plugin-4.4.0-4.fc9.x86_64 requires /bin/sh xfce4-fsguard-plugin-0.4.1-2.fc9.x86_64 requires /bin/sh xfce4-gsynaptics-mcs-plugin-1.0.0-1.fc9.x86_64 requires /bin/sh xfce4-mailwatch-plugin-1.0.1-8.fc9.x86_64 requires /bin/sh xfce4-mixer-4.4.2-2.fc9.x86_64 requires /bin/sh xfce4-mount-plugin-0.5.1-4.fc9.x86_64 requires /bin/sh xfce4-notes-plugin-1.6.1-2.fc9.x86_64 requires /bin/sh xfce4-panel-4.4.2-4.fc9.i386 requires /bin/sh xfce4-panel-4.4.2-4.fc9.x86_64 requires /bin/sh xfce4-sensors-plugin-0.10.99.2-4.fc9.x86_64 requires /bin/sh xfce4-session-4.4.2-3.fc10.i386 requires /bin/sh xfce4-session-4.4.2-3.fc10.x86_64 requires /bin/sh xfce4-session-engines-4.4.2-3.fc10.x86_64 requires /bin/sh xfce4-time-out-plugin-0.1.1-1.fc9.x86_64 requires /bin/sh xfce4-weather-plugin-0.6.2-3.fc9.x86_64 requires /bin/sh xfdesktop-4.4.2-3.fc9.x86_64 requires /bin/sh xfig-common-3.2.5-10.fc9.x86_64 requires /bin/sh xfig-common-3.2.5-10.fc9.x86_64 requires /bin/bash xforms-1.0.90-11.fc9.i386 requires /sbin/ldconfig xforms-1.0.90-11.fc9.x86_64 requires /sbin/ldconfig xfprint-4.4.2-2.fc9.i386 requires /bin/sh xfprint-4.4.2-2.fc9.x86_64 requires /bin/sh xfsprogs-2.9.8-1.fc10.i386 requires /sbin/ldconfig xfsprogs-2.9.8-1.fc10.i386 requires /bin/sh xfsprogs-2.9.8-1.fc10.x86_64 requires /sbin/ldconfig xfsprogs-2.9.8-1.fc10.x86_64 requires /bin/sh xfwm4-4.4.2-3.fc10.x86_64 requires /bin/sh xgalaxy-2.0.34-8.fc9.x86_64 requires /bin/sh xgrav-1.2.0-6.fc9.x86_64 requires /bin/sh xgridfit-1.5-2.fc9.noarch requires /usr/bin/xsltproc xguest-1.0.6-7.fc9.noarch requires /bin/sh xguest-1.0.6-7.fc9.noarch requires /bin/bash xhotkeys-0.9.8.3-5.fc9.noarch requires /bin/sh xhotkeys-0.9.8.3-5.fc9.noarch requires /bin/bash xhotkeys-0.9.8.3-5.fc9.noarch requires /usr/bin/python xhtml1-dtds-1.0-20020801.1.noarch requires /bin/sh xhtml1-dtds-1.0-20020801.1.noarch requires /usr/bin/xmlcatalog xhtml2ps-1.0-0.1.b5.fc10.noarch requires /usr/bin/wish xine-lib-1.1.12-3.fc10.i386 requires /sbin/ldconfig xine-lib-1.1.12-3.fc10.x86_64 requires /sbin/ldconfig xine-lib-devel-1.1.12-3.fc10.i386 requires /bin/sh xine-lib-devel-1.1.12-3.fc10.x86_64 requires /bin/sh 2:xinetd-2.3.14-18.fc9.x86_64 requires /etc/init.d 2:xinetd-2.3.14-18.fc9.x86_64 requires /bin/sh 2:xinetd-2.3.14-18.fc9.x86_64 requires /sbin/service 2:xinetd-2.3.14-18.fc9.x86_64 requires /bin/bash 2:xinetd-2.3.14-18.fc9.x86_64 requires /sbin/chkconfig xjavadoc-1.1-5jpp.3.fc9.x86_64 requires /bin/sh xjavadoc-javadoc-1.1-5jpp.3.fc9.x86_64 requires /bin/sh xjavadoc-javadoc-1.1-5jpp.3.fc9.x86_64 requires /bin/rm xjavadoc-javadoc-1.1-5jpp.3.fc9.x86_64 requires /bin/ln xl2tpd-1.1.12-2.fc9.x86_64 requires /bin/sh xl2tpd-1.1.12-2.fc9.x86_64 requires /sbin/chkconfig xl2tpd-1.1.12-2.fc9.x86_64 requires /bin/sh xl2tpd-1.1.12-2.fc9.x86_64 requires /sbin/service xlhtml-0.5-8.fc9.x86_64 requires /usr/bin/perl xlhtml-0.5-8.fc9.x86_64 requires /bin/csh xlhtml-0.5-8.fc9.x86_64 requires /bin/bash xlhtml-0.5-8.fc9.x86_64 requires /bin/sh xml-commons-apis-1.3.04-1jpp.1.fc9.x86_64 requires /bin/sh xml-commons-apis-javadoc-1.3.04-1jpp.1.fc9.x86_64 requires /bin/ln xml-commons-apis-javadoc-1.3.04-1jpp.1.fc9.x86_64 requires /bin/rm xml-commons-apis12-1.2.04-1jpp.4.fc9.x86_64 requires /bin/sh xml-commons-resolver-1.1-1jpp.12.x86_64 requires /bin/sh xml-commons-resolver-javadoc-1.1-1jpp.12.x86_64 requires /bin/sh xml-commons-resolver-javadoc-1.1-1jpp.12.x86_64 requires /bin/rm xml-commons-resolver-javadoc-1.1-1jpp.12.x86_64 requires /bin/ln 1:xml-commons-which-1.0-1.b2.0jpp.2.x86_64 requires /bin/sh xmlcopyeditor-1.1.0.6-4.fc9.x86_64 requires /bin/sh 1:xmldb-api-0.1-0.2.20011111cvs.1jpp.2.fc9.x86_64 requires /bin/sh xmlrpc-2.0.1-4jpp.3.fc9.x86_64 requires /bin/sh xmlrpc-c-1.13.8-2.fc9.i386 requires /sbin/ldconfig xmlrpc-c-1.13.8-2.fc9.x86_64 requires /sbin/ldconfig xmlrpc-c-devel-1.13.8-2.fc9.i386 requires /bin/sh xmlrpc-c-devel-1.13.8-2.fc9.x86_64 requires /bin/sh xmlsec1-1.2.9-10.1.i386 requires /bin/sh xmlsec1-1.2.9-10.1.x86_64 requires /bin/sh xmlsec1-devel-1.2.9-10.1.i386 requires /bin/sh xmlsec1-devel-1.2.9-10.1.x86_64 requires /bin/sh xmlsec1-gnutls-1.2.9-10.1.i386 requires /bin/sh xmlsec1-gnutls-1.2.9-10.1.x86_64 requires /bin/sh xmlsec1-openssl-1.2.9-10.1.i386 requires /bin/sh xmlsec1-openssl-1.2.9-10.1.x86_64 requires /bin/sh xmltex-20020625-11.fc9.noarch requires /bin/sh xmltex-20020625-11.fc9.noarch requires /bin/sh xmlto-0.0.20-3.fc10.x86_64 requires /bin/bash xmltoman-0.3-2.fc9.noarch requires /usr/bin/perl xmlunit-1.0-6jpp.1.fc9.x86_64 requires /bin/sh 1:xmms-1.2.10-38.fc9.x86_64 requires /bin/sh 1:xmms-1.2.10-38.fc9.x86_64 requires /usr/share/desktop-menu-patches/redhat-audio-player.desktop 1:xmms-1.2.10-38.fc9.x86_64 requires /bin/sh 1:xmms-devel-1.2.10-38.fc9.i386 requires /bin/sh 1:xmms-devel-1.2.10-38.fc9.x86_64 requires /bin/sh 1:xmms-libs-1.2.10-38.fc9.i386 requires /sbin/ldconfig 1:xmms-libs-1.2.10-38.fc9.x86_64 requires /sbin/ldconfig xmoto-0.4.2-1.fc9.x86_64 requires /bin/sh xmoto-edit-0.2.4-13.fc9.x86_64 requires /bin/sh xorg-x11-apps-7.3-3.fc9.x86_64 requires /bin/sh xorg-x11-drv-openchrome-0.2.902-3.fc9.i386 requires /bin/sh xorg-x11-drv-openchrome-0.2.902-3.fc9.x86_64 requires /bin/sh xorg-x11-filesystem-7.3-1.fc9.noarch requires /bin/bash xorg-x11-filesystem-7.3-1.fc9.noarch requires /bin/sh 1:xorg-x11-font-utils-7.2-4.fc9.x86_64 requires /bin/sh xorg-x11-fonts-100dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-75dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ISO8859-1-100dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ISO8859-1-75dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ISO8859-14-100dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ISO8859-14-75dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ISO8859-15-100dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ISO8859-15-75dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ISO8859-2-100dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ISO8859-2-75dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ISO8859-9-100dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ISO8859-9-75dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-Type1-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-cyrillic-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ethiopic-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-misc-7.2-6.fc9.noarch requires /bin/sh xorg-x11-server-Xorg-1.4.99.901-29.20080415.fc9.x86_64 requires /bin/sh xorg-x11-server-source-1.4.99.901-29.20080415.fc9.x86_64 requires /bin/sh 1:xorg-x11-xauth-1.0.2-4.fc9.x86_64 requires /bin/sh 1:xorg-x11-xdm-1.1.6-3.fc9.x86_64 requires /bin/sh 1:xorg-x11-xfs-1.0.5-2.fc9.x86_64 requires /bin/sh 1:xorg-x11-xfs-1.0.5-2.fc9.x86_64 requires /usr/bin/uniq 1:xorg-x11-xfs-1.0.5-2.fc9.x86_64 requires /usr/sbin/useradd 1:xorg-x11-xfs-1.0.5-2.fc9.x86_64 requires /usr/bin/find 1:xorg-x11-xfs-1.0.5-2.fc9.x86_64 requires /sbin/service 1:xorg-x11-xfs-1.0.5-2.fc9.x86_64 requires /sbin/nologin 1:xorg-x11-xfs-1.0.5-2.fc9.x86_64 requires /bin/bash 1:xorg-x11-xfs-1.0.5-2.fc9.x86_64 requires /bin/sh 1:xorg-x11-xfs-1.0.5-2.fc9.x86_64 requires /bin/sort 1:xorg-x11-xfs-1.0.5-2.fc9.x86_64 requires /sbin/chkconfig xorg-x11-xinit-1.0.7-6.fc9.x86_64 requires /bin/bash xorg-x11-xinit-1.0.7-6.fc9.x86_64 requires /bin/sh xorg-x11-xsm-1.0.2-7.fc9.x86_64 requires /bin/sh xosd-2.2.14-11.fc9.i386 requires /sbin/ldconfig xosd-2.2.14-11.fc9.x86_64 requires /sbin/ldconfig xosd-devel-2.2.14-11.fc9.i386 requires /bin/sh xosd-devel-2.2.14-11.fc9.x86_64 requires /bin/sh xournal-0.4.2.1-1.fc9.x86_64 requires /bin/sh xpa-libs-2.1.8-6.fc9.i386 requires /sbin/ldconfig xpa-libs-2.1.8-6.fc9.x86_64 requires /sbin/ldconfig 1:xpdf-3.02-6.fc9.x86_64 requires /bin/sh xpilot-ng-4.7.2-14.fc9.x86_64 requires /bin/sh xpilot-ng-selinux-4.7.2-14.fc9.x86_64 requires /usr/sbin/semodule xpilot-ng-selinux-4.7.2-14.fc9.x86_64 requires /sbin/fixfiles xpilot-ng-selinux-4.7.2-14.fc9.x86_64 requires /bin/sh xpilot-ng-selinux-4.7.2-14.fc9.x86_64 requires /usr/sbin/semanage xpilot-ng-selinux-4.7.2-14.fc9.x86_64 requires /usr/sbin/setsebool xpilot-ng-selinux-4.7.2-14.fc9.x86_64 requires /sbin/service xpilot-ng-server-4.7.2-14.fc9.x86_64 requires /bin/sh xpilot-ng-server-4.7.2-14.fc9.x86_64 requires /usr/bin/env xpilot-ng-server-4.7.2-14.fc9.x86_64 requires /sbin/service xpilot-ng-server-4.7.2-14.fc9.x86_64 requires /bin/sh xpilot-ng-server-4.7.2-14.fc9.x86_64 requires /sbin/chkconfig xplanet-1.2.0-3.fc9.2.x86_64 requires /usr/bin/perl xqilla-2.0.0-5.fc9.i386 requires /sbin/ldconfig xqilla-2.0.0-5.fc9.x86_64 requires /sbin/ldconfig xqilla10-1.0.2-5.fc9.i386 requires /sbin/ldconfig xqilla10-1.0.2-5.fc9.x86_64 requires /sbin/ldconfig xsane-gimp-0.995-3.fc9.x86_64 requires /bin/sh xsc-1.5-3.fc9.x86_64 requires /bin/sh xscorch-0.2.0-12.fc8.x86_64 requires /usr/bin/env 1:xscreensaver-base-5.05-3.fc9.x86_64 requires /etc/pam.d/system-auth 1:xscreensaver-base-5.05-3.fc9.x86_64 requires /usr/bin/perl 1:xscreensaver-base-5.05-3.fc9.x86_64 requires /bin/bash 1:xscreensaver-base-5.05-3.fc9.x86_64 requires /bin/sh 1:xscreensaver-extras-5.05-3.fc9.x86_64 requires /usr/bin/perl 1:xscreensaver-extras-5.05-3.fc9.x86_64 requires /bin/sh xsp-1.9.1-2.fc10.x86_64 requires /bin/sh xstar-xscreensaver-2.2.0-3.fc9.x86_64 requires /bin/sh xterm-235-1.fc10.x86_64 requires /bin/sh xtide-2.10-2.fc9.x86_64 requires /bin/sh xtide-2.10-2.fc9.x86_64 requires /sbin/service xtide-2.10-2.fc9.x86_64 requires /bin/sh xtide-2.10-2.fc9.x86_64 requires /sbin/chkconfig xtide-common-2.10-2.fc9.x86_64 requires /bin/sh xu4-1.1-0.4.cvs20070510.fc9.x86_64 requires /bin/sh xu4-1.1-0.4.cvs20070510.fc9.x86_64 requires /bin/bash xulrunner-1.9-0.63.cvs20080516.fc10.i386 requires /bin/sh xulrunner-1.9-0.63.cvs20080516.fc10.i386 requires /bin/sh xulrunner-1.9-0.63.cvs20080516.fc10.x86_64 requires /bin/sh xulrunner-1.9-0.63.cvs20080516.fc10.x86_64 requires /bin/sh xyz-gallery-0.1-1.fc9.noarch requires /usr/bin/perl xzgv-0.9-4.fc9.x86_64 requires /bin/sh xzgv-0.9-4.fc9.x86_64 requires /sbin/install-info yadex-1.7.0-10.fc9.x86_64 requires /bin/sh yafc-1.1.1-10.fc9.x86_64 requires /bin/sh yafc-1.1.1-10.fc9.x86_64 requires /sbin/install-info yafray-0.0.9-7.fc9.x86_64 requires /sbin/ldconfig yakuake-2.9.1-1.fc9.x86_64 requires /bin/sh yanone-kaffeesatz-fonts-20061120-3.fc9.noarch requires /bin/sh yap-5.1.1-9.fc9.x86_64 requires /bin/sh yap-5.1.1-9.fc9.x86_64 requires /sbin/ldconfig yap-5.1.1-9.fc9.x86_64 requires /sbin/install-info yasm-0.7.0-1.fc10.x86_64 requires /sbin/ldconfig yelp-2.22.1-1.fc9.x86_64 requires /bin/sh youtube-dl-2008.01.24-1.fc9.noarch requires /usr/bin/env 3:ypbind-1.20.4-4.fc9.x86_64 requires /bin/sh 3:ypbind-1.20.4-4.fc9.x86_64 requires /sbin/chkconfig 3:ypbind-1.20.4-4.fc9.x86_64 requires /bin/bash ypserv-2.19-9.fc9.x86_64 requires /bin/sh ypserv-2.19-9.fc9.x86_64 requires /sbin/service ypserv-2.19-9.fc9.x86_64 requires /usr/bin/awk ypserv-2.19-9.fc9.x86_64 requires /bin/bash ypserv-2.19-9.fc9.x86_64 requires /bin/sh ypserv-2.19-9.fc9.x86_64 requires /sbin/chkconfig yum-3.2.16-1.fc10.noarch requires /usr/bin/python yum-arch-2.2.2-2.fc7.noarch requires /usr/bin/python yum-cron-0.8.2-1.fc9.noarch requires /bin/sh yum-cron-0.8.2-1.fc9.noarch requires /bin/bash yum-cron-0.8.2-1.fc9.noarch requires /sbin/chkconfig yum-cron-0.8.2-1.fc9.noarch requires /bin/sh yum-cron-0.8.2-1.fc9.noarch requires /sbin/service yum-updateonboot-1.1.13-2.fc9.noarch requires /bin/sh yum-updateonboot-1.1.13-2.fc9.noarch requires /bin/bash 1:yum-updatesd-0.9-1.fc9.noarch requires /bin/sh 1:yum-updatesd-0.9-1.fc9.noarch requires /bin/bash 1:yum-updatesd-0.9-1.fc9.noarch requires /usr/bin/python 1:yum-updatesd-0.9-1.fc9.noarch requires /sbin/chkconfig 1:yum-updatesd-0.9-1.fc9.noarch requires /sbin/service yum-utils-1.1.13-2.fc9.noarch requires /usr/bin/python yumex-2.0.4-1.fc9.noarch requires /bin/bash yumex-2.0.4-1.fc9.noarch requires /usr/bin/env yumex-2.0.4-1.fc9.noarch requires /usr/bin/python zabbix-1.4.5-3.fc10.x86_64 requires /bin/sh zabbix-1.4.5-3.fc10.x86_64 requires /usr/sbin/useradd zabbix-1.4.5-3.fc10.x86_64 requires /sbin/service zabbix-1.4.5-3.fc10.x86_64 requires /bin/sh zabbix-1.4.5-3.fc10.x86_64 requires /sbin/chkconfig zabbix-agent-1.4.5-3.fc10.x86_64 requires /bin/sh zabbix-agent-1.4.5-3.fc10.x86_64 requires /sbin/chkconfig zabbix-agent-1.4.5-3.fc10.x86_64 requires /usr/sbin/useradd zabbix-agent-1.4.5-3.fc10.x86_64 requires /bin/sh zabbix-agent-1.4.5-3.fc10.x86_64 requires /sbin/service zaptel-1.4.10.1-1.fc10.x86_64 requires /sbin/chkconfig zaptel-1.4.10.1-1.fc10.x86_64 requires /bin/sh zaptel-1.4.10.1-1.fc10.x86_64 requires /bin/sh zaptel-1.4.10.1-1.fc10.x86_64 requires /sbin/service zaptel-lib-1.4.10.1-1.fc10.i386 requires /sbin/ldconfig zaptel-lib-1.4.10.1-1.fc10.x86_64 requires /sbin/ldconfig zasx-1.30-6.fc9.x86_64 requires /bin/sh zenity-2.23.1-1.fc10.x86_64 requires /bin/sh zeroinstall-injector-0.32-1.fc9.noarch requires /bin/sh zeroinstall-injector-0.32-1.fc9.noarch requires /usr/bin/env zeroinstall-injector-0.32-1.fc9.noarch requires /usr/bin/python zile-2.2.19-3.fc9.x86_64 requires /bin/sh zlib-1.2.3-18.fc9.i386 requires /sbin/ldconfig zlib-1.2.3-18.fc9.x86_64 requires /sbin/ldconfig zoneminder-1.22.3-14.fc10.x86_64 requires /bin/sh zoneminder-1.22.3-14.fc10.x86_64 requires /sbin/service zoneminder-1.22.3-14.fc10.x86_64 requires /usr/bin/perl zoneminder-1.22.3-14.fc10.x86_64 requires /bin/sh zoneminder-1.22.3-14.fc10.x86_64 requires /sbin/chkconfig zsh-4.3.4-7.fc9.x86_64 requires /bin/sh zsh-4.3.4-7.fc9.x86_64 requires /sbin/install-info zsh-4.3.4-7.fc9.x86_64 requires /bin/sh zsh-4.3.4-7.fc9.x86_64 requires /bin/zsh zvbi-0.2.30-1.fc9.i386 requires /bin/sh zvbi-0.2.30-1.fc9.i386 requires /sbin/service zvbi-0.2.30-1.fc9.i386 requires /sbin/chkconfig zvbi-0.2.30-1.fc9.i386 requires /bin/sh zvbi-0.2.30-1.fc9.x86_64 requires /bin/sh zvbi-0.2.30-1.fc9.x86_64 requires /sbin/service zvbi-0.2.30-1.fc9.x86_64 requires /bin/sh zvbi-0.2.30-1.fc9.x86_64 requires /sbin/chkconfig zvbi-fonts-0.2.30-1.fc9.x86_64 requires /bin/sh zynaddsubfx-2.2.1-18.fc9.x86_64 requires /bin/sh zziplib-0.13.49-5.fc9.i386 requires /sbin/ldconfig zziplib-0.13.49-5.fc9.x86_64 requires /sbin/ldconfig Broken deps for ppc ---------------------------------------------------------- 8Kingdoms-1.1.0-6.fc9.ppc requires /bin/sh AcetoneISO-6.7-5.fc9.ppc requires /bin/bash AcetoneISO2-2.0.2-3.fc10.ppc requires /bin/bash AllegroOGG-1.0.3-4.fc9.ppc requires /sbin/ldconfig AllegroOGG-1.0.3-4.fc9.ppc64 requires /sbin/ldconfig BackupPC-3.1.0-2.fc9.noarch requires /bin/sh BackupPC-3.1.0-2.fc9.noarch requires /usr/sbin/useradd BackupPC-3.1.0-2.fc9.noarch requires /usr/bin/perl BackupPC-3.1.0-2.fc9.noarch requires /bin/sh BackupPC-3.1.0-2.fc9.noarch requires /usr/sbin/usermod BlockOutII-2.3-5.fc9.ppc requires /bin/sh CCfits-2.0-1.fc9.ppc requires /sbin/ldconfig CCfits-2.0-1.fc9.ppc64 requires /sbin/ldconfig CGAL-3.3.1-11.fc9.ppc requires /sbin/ldconfig CGAL-3.3.1-11.fc9.ppc64 requires /sbin/ldconfig CGAL-devel-3.3.1-11.fc9.ppc requires /etc/profile.d CGAL-devel-3.3.1-11.fc9.ppc requires /bin/sh CGAL-devel-3.3.1-11.fc9.ppc64 requires /etc/profile.d CGAL-devel-3.3.1-11.fc9.ppc64 requires /bin/sh CTL-1.4.1-6.fc9.ppc requires /sbin/ldconfig CTL-1.4.1-6.fc9.ppc64 requires /sbin/ldconfig Canna-3.7p3-23.fc9.ppc requires /bin/sh Canna-3.7p3-23.fc9.ppc requires /sbin/chkconfig Canna-3.7p3-23.fc9.ppc requires /bin/bash Canna-3.7p3-23.fc9.ppc requires /bin/chown Canna-3.7p3-23.fc9.ppc requires /bin/grep Canna-3.7p3-23.fc9.ppc requires /bin/sh Canna-3.7p3-23.fc9.ppc requires /sbin/service Canna-3.7p3-23.fc9.ppc requires /etc/services Canna-libs-3.7p3-23.fc9.ppc requires /sbin/ldconfig Canna-libs-3.7p3-23.fc9.ppc64 requires /sbin/ldconfig CastPodder-5.0-8.fc6.noarch requires /bin/bash CastPodder-5.0-8.fc6.noarch requires /usr/bin/env CastPodder-5.0-8.fc6.noarch requires /bin/sh CastPodder-5.0-8.fc6.noarch requires /usr/bin/python ClanLib-0.8.1-1.fc9.ppc requires /sbin/ldconfig ClanLib-0.8.1-1.fc9.ppc64 requires /sbin/ldconfig ClanLib06-0.6.5-12.fc9.ppc requires /sbin/ldconfig ClanLib06-0.6.5-12.fc9.ppc64 requires /sbin/ldconfig ClanLib06-devel-0.6.5-12.fc9.ppc requires /bin/sh ClanLib06-devel-0.6.5-12.fc9.ppc64 requires /bin/sh Coin2-2.5.0-4.fc9.ppc requires /sbin/ldconfig Coin2-2.5.0-4.fc9.ppc64 requires /sbin/ldconfig Coin2-devel-2.5.0-4.fc9.ppc requires /bin/sh Coin2-devel-2.5.0-4.fc9.ppc64 requires /bin/sh ConsoleKit-0.2.10-3.fc9.ppc requires /bin/sh ConsoleKit-0.2.10-3.fc9.ppc requires /bin/sh CriticalMass-1.0.2-5.fc9.ppc requires /bin/sh Cython-0.9.6.13.1-3.fc10.noarch requires /usr/bin/python DevIL-1.6.8-0.15.rc2.fc9.ppc requires /sbin/ldconfig DevIL-1.6.8-0.15.rc2.fc9.ppc64 requires /sbin/ldconfig DevIL-ILUT-1.6.8-0.15.rc2.fc9.ppc requires /sbin/ldconfig DevIL-ILUT-1.6.8-0.15.rc2.fc9.ppc64 requires /sbin/ldconfig Django-0.96.1-2.fc9.noarch requires /usr/bin/env Django-0.96.1-2.fc9.noarch requires /usr/bin/python Django-docs-0.96.1-2.fc9.noarch requires /usr/bin/env ElectricFence-2.2.2-25.fc9.ppc requires /sbin/ldconfig ElectricFence-2.2.2-25.fc9.ppc requires /bin/bash ElectricFence-2.2.2-25.fc9.ppc64 requires /sbin/ldconfig ElectricFence-2.2.2-25.fc9.ppc64 requires /bin/bash FlightGear-1.0.0-3.fc10.ppc requires /bin/sh GConf2-2.22.0-7.fc10.ppc requires /sbin/ldconfig GConf2-2.22.0-7.fc10.ppc requires /bin/sh GConf2-2.22.0-7.fc10.ppc requires /usr/bin/killall GConf2-2.22.0-7.fc10.ppc64 requires /bin/sh GConf2-2.22.0-7.fc10.ppc64 requires /sbin/ldconfig GConf2-2.22.0-7.fc10.ppc64 requires /usr/bin/killall GREYCstoration-gui-2.8-1.fc9.ppc requires /bin/sh GREYCstoration-gui-2.8-1.fc9.ppc requires /bin/sh GeoIP-1.4.4-2.fc9.ppc requires /sbin/ldconfig GeoIP-1.4.4-2.fc9.ppc64 requires /sbin/ldconfig GraphicsMagick-1.1.10-3.fc9.ppc requires /sbin/ldconfig GraphicsMagick-1.1.10-3.fc9.ppc64 requires /sbin/ldconfig GraphicsMagick-c++-1.1.10-3.fc9.ppc requires /sbin/ldconfig GraphicsMagick-c++-1.1.10-3.fc9.ppc64 requires /sbin/ldconfig GraphicsMagick-c++-devel-1.1.10-3.fc9.ppc requires /bin/sh GraphicsMagick-c++-devel-1.1.10-3.fc9.ppc64 requires /bin/sh GraphicsMagick-devel-1.1.10-3.fc9.ppc requires /bin/sh GraphicsMagick-devel-1.1.10-3.fc9.ppc64 requires /bin/sh GtkAda-2.10.0-4.fc9.ppc requires /sbin/ldconfig GtkAda-devel-2.10.0-4.fc9.ppc requires /bin/sh 1:HelixPlayer-1.0.9-2.fc9.ppc requires /bin/sh 1:HelixPlayer-1.0.9-2.fc9.ppc requires /bin/sh 1:HelixPlayer-plugin-1.0.9-2.fc9.ppc requires /usr/lib/mozilla/plugins Hermes-1.3.3-14.fc9.ppc requires /sbin/ldconfig Hermes-1.3.3-14.fc9.ppc64 requires /sbin/ldconfig HippoDraw-1.21.1-4.fc9.ppc requires /bin/sh HippoDraw-1.21.1-4.fc9.ppc64 requires /bin/sh ImageMagick-6.4.0.10-1.fc10.ppc requires /sbin/ldconfig ImageMagick-6.4.0.10-1.fc10.ppc64 requires /sbin/ldconfig ImageMagick-c++-6.4.0.10-1.fc10.ppc requires /sbin/ldconfig ImageMagick-c++-6.4.0.10-1.fc10.ppc64 requires /sbin/ldconfig ImageMagick-c++-devel-6.4.0.10-1.fc10.ppc requires /bin/sh ImageMagick-c++-devel-6.4.0.10-1.fc10.ppc64 requires /bin/sh ImageMagick-devel-6.4.0.10-1.fc10.ppc requires /bin/sh ImageMagick-devel-6.4.0.10-1.fc10.ppc64 requires /bin/sh Inventor-2.1.5-31.fc9.ppc requires /usr/share/fonts/liberation/LiberationSerif-BoldItalic.ttf Inventor-2.1.5-31.fc9.ppc requires /usr/share/fonts/liberation/LiberationSans-Regular.ttf Inventor-2.1.5-31.fc9.ppc requires /usr/share/fonts/liberation/LiberationMono-Italic.ttf Inventor-2.1.5-31.fc9.ppc requires /usr/share/fonts/liberation/LiberationMono-BoldItalic.ttf Inventor-2.1.5-31.fc9.ppc requires /usr/share/fonts/liberation/LiberationSerif-Regular.ttf Inventor-2.1.5-31.fc9.ppc requires /usr/share/fonts/liberation/LiberationSans-BoldItalic.ttf Inventor-2.1.5-31.fc9.ppc requires /usr/share/fonts/liberation/LiberationMono-Bold.ttf Inventor-2.1.5-31.fc9.ppc requires /usr/share/fonts/liberation/LiberationSans-Bold.ttf Inventor-2.1.5-31.fc9.ppc requires /sbin/ldconfig Inventor-2.1.5-31.fc9.ppc requires /usr/share/fonts/liberation/LiberationSerif-Bold.ttf Inventor-2.1.5-31.fc9.ppc requires /usr/share/fonts/liberation/LiberationSerif-Italic.ttf Inventor-2.1.5-31.fc9.ppc requires /usr/share/fonts/liberation/LiberationMono-Regular.ttf Inventor-2.1.5-31.fc9.ppc requires /bin/sh Inventor-2.1.5-31.fc9.ppc requires /usr/share/fonts/liberation/LiberationSans-Italic.ttf Inventor-2.1.5-31.fc9.ppc64 requires /usr/share/fonts/liberation/LiberationSerif-BoldItalic.ttf Inventor-2.1.5-31.fc9.ppc64 requires /usr/share/fonts/liberation/LiberationSans-Regular.ttf Inventor-2.1.5-31.fc9.ppc64 requires /usr/share/fonts/liberation/LiberationMono-Italic.ttf Inventor-2.1.5-31.fc9.ppc64 requires /usr/share/fonts/liberation/LiberationMono-BoldItalic.ttf Inventor-2.1.5-31.fc9.ppc64 requires /usr/share/fonts/liberation/LiberationSerif-Regular.ttf Inventor-2.1.5-31.fc9.ppc64 requires /usr/share/fonts/liberation/LiberationSans-BoldItalic.ttf Inventor-2.1.5-31.fc9.ppc64 requires /usr/share/fonts/liberation/LiberationMono-Bold.ttf Inventor-2.1.5-31.fc9.ppc64 requires /usr/share/fonts/liberation/LiberationSans-Bold.ttf Inventor-2.1.5-31.fc9.ppc64 requires /sbin/ldconfig Inventor-2.1.5-31.fc9.ppc64 requires /usr/share/fonts/liberation/LiberationSerif-Bold.ttf Inventor-2.1.5-31.fc9.ppc64 requires /usr/share/fonts/liberation/LiberationSerif-Italic.ttf Inventor-2.1.5-31.fc9.ppc64 requires /usr/share/fonts/liberation/LiberationMono-Regular.ttf Inventor-2.1.5-31.fc9.ppc64 requires /bin/sh Inventor-2.1.5-31.fc9.ppc64 requires /usr/share/fonts/liberation/LiberationSans-Italic.ttf Inventor-demos-2.1.5-31.fc9.ppc requires /bin/sh InventorXt-2.1.5-31.fc9.ppc requires /sbin/ldconfig InventorXt-2.1.5-31.fc9.ppc requires /usr/bin/xmessage InventorXt-2.1.5-31.fc9.ppc64 requires /sbin/ldconfig InventorXt-2.1.5-31.fc9.ppc64 requires /usr/bin/xmessage Io-language-20071010-5.fc9.ppc requires /sbin/ldconfig Io-language-20071010-5.fc9.ppc64 requires /sbin/ldconfig JSDoc-1.10.2-4.fc8.noarch requires /usr/bin/perl KoboDeluxe-0.5.1-2.fc9.ppc requires /bin/sh KoboDeluxe-0.5.1-2.fc9.ppc requires /usr/sbin/groupadd LabPlot-1.5.1.6-4.fc8.ppc requires /bin/sh LabPlot-1.5.1.6-4.fc8.ppc requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.ppc requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.ppc requires libMagick.so.10 MAKEDEV-3.23-4.ppc requires /bin/sh Macaulay2-1.1-1.fc9.ppc requires /bin/sh Macaulay2-1.1-1.fc9.ppc requires /bin/sh Maelstrom-3.0.6-15.ppc requires /bin/sh MagicPoint-1.11b-6.fc9.ppc requires /usr/bin/perl MegaMek-0.30.11-3.fc9.ppc requires /bin/sh MegaMek-0.30.11-3.fc9.ppc requires /usr/bin/perl MegaMek-0.30.11-3.fc9.ppc requires /bin/sh Miro-1.2.3-2.fc10.ppc requires /usr/bin/python Miro-1.2.3-2.fc10.ppc requires /bin/sh Miro-1.2.3-2.fc10.ppc requires /bin/sh 1:NetworkManager-0.7.0-0.9.3.svn3669.fc10.ppc requires /bin/sh 1:NetworkManager-0.7.0-0.9.3.svn3669.fc10.ppc requires /bin/sh 1:NetworkManager-0.7.0-0.9.3.svn3669.fc10.ppc64 requires /bin/sh 1:NetworkManager-0.7.0-0.9.3.svn3669.fc10.ppc64 requires /bin/sh 1:NetworkManager-glib-0.7.0-0.9.3.svn3669.fc10.ppc requires /sbin/ldconfig 1:NetworkManager-glib-0.7.0-0.9.3.svn3669.fc10.ppc64 requires /sbin/ldconfig 1:NetworkManager-gnome-0.7.0-0.9.3.svn3669.fc10.ppc requires /bin/sh 1:NetworkManager-openvpn-0.7.0-10.svn3632.fc10.ppc requires /bin/sh 1:NetworkManager-openvpn-0.7.0-10.svn3632.fc10.ppc requires /usr/bin/update-desktop-database 1:NetworkManager-openvpn-0.7.0-10.svn3632.fc10.ppc requires /sbin/ldconfig 1:NetworkManager-vpnc-0.7.0-0.7.7.svn3627.fc10.ppc requires /bin/sh 1:NetworkManager-vpnc-0.7.0-0.7.7.svn3627.fc10.ppc requires /sbin/ldconfig 1:ORBit-0.5.17-23.fc9.ppc requires /sbin/ldconfig 1:ORBit-0.5.17-23.fc9.ppc requires /sbin/install-info 1:ORBit-0.5.17-23.fc9.ppc64 requires /sbin/ldconfig 1:ORBit-0.5.17-23.fc9.ppc64 requires /sbin/install-info 1:ORBit-devel-0.5.17-23.fc9.ppc requires /bin/sh 1:ORBit-devel-0.5.17-23.fc9.ppc requires /bin/sh 1:ORBit-devel-0.5.17-23.fc9.ppc64 requires /bin/sh 1:ORBit-devel-0.5.17-23.fc9.ppc64 requires /bin/sh ORBit2-2.14.12-3.fc9.ppc requires /sbin/ldconfig ORBit2-2.14.12-3.fc9.ppc64 requires /sbin/ldconfig ORBit2-devel-2.14.12-3.fc9.ppc requires /bin/sh ORBit2-devel-2.14.12-3.fc9.ppc64 requires /bin/sh OpenEXR-libs-1.6.1-4.fc10.ppc requires /sbin/ldconfig OpenEXR-libs-1.6.1-4.fc10.ppc64 requires /sbin/ldconfig OpenEXR_CTL-libs-1.0.1-4.fc9.ppc requires /sbin/ldconfig OpenEXR_CTL-libs-1.0.1-4.fc9.ppc64 requires /sbin/ldconfig OpenEXR_Viewers-1.0.1-2.fc10.ppc requires /bin/sh OpenEXR_Viewers-1.0.1-2.fc10.ppc requires /usr/sbin/alternatives OpenIPMI-2.0.13-2.fc9.ppc requires /bin/sh OpenIPMI-2.0.13-2.fc9.ppc requires /bin/sh OpenIPMI-libs-2.0.13-2.fc9.ppc requires /sbin/ldconfig OpenIPMI-libs-2.0.13-2.fc9.ppc64 requires /sbin/ldconfig OpenSceneGraph-libs-2.4.0-2.fc10.ppc requires /sbin/ldconfig OpenSceneGraph-libs-2.4.0-2.fc10.ppc64 requires /sbin/ldconfig OpenThreads-2.4.0-2.fc10.ppc requires /sbin/ldconfig OpenThreads-2.4.0-2.fc10.ppc64 requires /sbin/ldconfig PackageKit-0.2.1-2.20080508.fc10.ppc requires /usr/bin/python PackageKit-0.2.1-2.20080508.fc10.ppc requires /bin/bash PackageKit-0.2.1-2.20080508.fc10.ppc requires /bin/sh PackageKit-libs-0.2.1-2.20080508.fc10.ppc requires /sbin/ldconfig PackageKit-libs-0.2.1-2.20080508.fc10.ppc64 requires /sbin/ldconfig Perlbal-1.70-1.fc9.noarch requires /bin/sh Perlbal-1.70-1.fc9.noarch requires /sbin/service Perlbal-1.70-1.fc9.noarch requires /bin/bash Perlbal-1.70-1.fc9.noarch requires /usr/bin/perl Perlbal-1.70-1.fc9.noarch requires /sbin/chkconfig Pixie-2.2.3-3.fc9.ppc requires /sbin/ldconfig Pixie-2.2.3-3.fc9.ppc64 requires /sbin/ldconfig PolicyKit-0.8-2.fc9.ppc requires /usr/sbin/useradd PolicyKit-0.8-2.fc9.ppc requires /sbin/ldconfig PolicyKit-0.8-2.fc9.ppc requires /bin/sh PolicyKit-0.8-2.fc9.ppc64 requires /bin/sh PolicyKit-0.8-2.fc9.ppc64 requires /usr/sbin/useradd PolicyKit-0.8-2.fc9.ppc64 requires /sbin/ldconfig Pound-2.4-1.fc9.ppc requires /bin/sh Pound-2.4-1.fc9.ppc requires /usr/sbin/groupadd Pound-2.4-1.fc9.ppc requires /usr/sbin/useradd Pound-2.4-1.fc9.ppc requires /sbin/service Pound-2.4-1.fc9.ppc requires /bin/bash Pound-2.4-1.fc9.ppc requires /sbin/chkconfig PyKDE-3.16.1-1.fc9.ppc requires /usr/bin/env PyKDE-devel-3.16.1-1.fc9.ppc requires /usr/bin/env PyKDE-devel-3.16.1-1.fc9.ppc64 requires /usr/bin/env PyQt-examples-3.17.4-4.fc9.ppc requires /usr/bin/env PyQt4-4.4-1.fc10.ppc requires /usr/bin/env PyQt4-devel-4.4-1.fc10.ppc requires /bin/sh PyQt4-devel-4.4-1.fc10.ppc64 requires /bin/sh PySolFC-1.1-6.fc9.noarch requires /usr/bin/env PySolFC-1.1-6.fc9.noarch requires /bin/sh PySolFC-1.1-6.fc9.noarch requires /usr/bin/python PyX-0.10-4.fc9.ppc requires /usr/bin/env PyXML-0.8.4-9.ppc requires /usr/bin/python Pyrex-0.9.6.4-2.fc10.noarch requires /usr/bin/python PythonCAD-0.1.36-3.fc9.noarch requires /bin/sh PythonCAD-0.1.36-3.fc9.noarch requires /usr/bin/env PythonCAD-0.1.36-3.fc9.noarch requires /usr/bin/python QuantLib-0.9.0-5.fc9.ppc requires /sbin/ldconfig QuantLib-0.9.0-5.fc9.ppc64 requires /sbin/ldconfig QuantLib-devel-0.9.0-5.fc9.ppc requires /bin/sh QuantLib-devel-0.9.0-5.fc9.ppc64 requires /bin/sh R-2.7.0-2.fc10.ppc requires /bin/sh R-2.7.0-2.fc10.ppc requires /bin/bash R-2.7.0-2.fc10.ppc requires /bin/sh R-2.7.0-2.fc10.ppc requires /usr/bin/perl R-2.7.0-2.fc10.ppc64 requires /bin/sh R-2.7.0-2.fc10.ppc64 requires /bin/bash R-2.7.0-2.fc10.ppc64 requires /bin/sh R-2.7.0-2.fc10.ppc64 requires /usr/bin/perl R-BSgenome.Celegans.UCSC.ce2-1.2.0-5.noarch requires /bin/sh R-BSgenome.Dmelanogaster.FlyBase.r51-1.3.1-3.noarch requires /bin/sh R-Biobase-1.16.1-5.fc9.ppc requires /bin/sh R-Biobase-1.16.1-5.fc9.ppc requires /bin/bash R-BufferedMatrix-1.4.0-1.fc10.ppc requires /bin/sh R-BufferedMatrixMethods-1.3.0-3.fc9.ppc requires /bin/sh R-DynDoc-1.18.0-1.fc10.noarch requires /bin/sh R-Matrix-0.999375-4.fc9.ppc requires /bin/sh R-RScaLAPACK-0.5.1-11.fc9.2.ppc requires /bin/sh R-RScaLAPACK-0.5.1-11.fc9.2.ppc requires /bin/sh R-abind-1.1-2.fc9.noarch requires /bin/sh R-acepack-1.3-4.fc9.ppc requires /bin/sh R-affyio-1.8.0-1.fc10.ppc requires /bin/sh R-car-1.2-3.fc10.noarch requires /bin/sh R-hdf5-1.6.6-6.fc10.ppc requires /bin/sh R-hgu95av2probe-2.0.0-1.fc9.noarch requires /bin/sh R-mAr-1.1-13.fc9.ppc requires /bin/sh R-maanova-1.9.0-2.fc9.ppc requires /bin/sh R-multcomp-1.0-1.fc9.noarch requires /bin/sh R-multtest-1.18.0-4.fc9.ppc requires /bin/sh R-mvtnorm-0.8-4.fc9.ppc requires /bin/sh R-pls-2.1-2.fc9.noarch requires /bin/sh R-qvalue-1.12.0-2.fc9.noarch requires /bin/sh R-rlecuyer-0.1-6.fc9.ppc requires /bin/sh R-systemfit-0.8-7.fc9.noarch requires /bin/sh R-tkWidgets-1.16.0-2.fc9.noarch requires /bin/sh R-waveslim-1.6.1-2.fc9.ppc requires /bin/sh R-wavethresh-2.2-9.fc9.ppc requires /bin/sh R-widgetTools-1.15.0-2.fc9.noarch requires /bin/sh Ri-li-2.0.1-3.fc9.ppc requires /bin/sh SAASound-3.2-5.fc10.ppc requires /sbin/ldconfig SAASound-3.2-5.fc10.ppc64 requires /sbin/ldconfig SDL-1.2.13-3.fc9.ppc requires /sbin/ldconfig SDL-1.2.13-3.fc9.ppc64 requires /sbin/ldconfig SDL-devel-1.2.13-3.fc9.ppc requires /bin/sh SDL-devel-1.2.13-3.fc9.ppc64 requires /bin/sh SDL_Pango-0.1.2-8.ppc requires /sbin/ldconfig SDL_Pango-0.1.2-8.ppc64 requires /sbin/ldconfig SDL_gfx-2.0.16-5.fc9.ppc requires /sbin/ldconfig SDL_gfx-2.0.16-5.fc9.ppc64 requires /sbin/ldconfig SDL_image-1.2.6-6.fc9.ppc requires /sbin/ldconfig SDL_image-1.2.6-6.fc9.ppc64 requires /sbin/ldconfig SDL_mixer-1.2.8-8.fc9.ppc requires /sbin/ldconfig SDL_mixer-1.2.8-8.fc9.ppc64 requires /sbin/ldconfig SDL_net-1.2.7-4.fc9.ppc requires /sbin/ldconfig SDL_net-1.2.7-4.fc9.ppc64 requires /sbin/ldconfig SDL_sound-1.0.3-1.fc10.ppc requires /sbin/ldconfig SDL_sound-1.0.3-1.fc10.ppc64 requires /sbin/ldconfig SDL_ttf-2.0.9-4.fc9.ppc requires /sbin/ldconfig SDL_ttf-2.0.9-4.fc9.ppc64 requires /sbin/ldconfig SILLY-0.1.0-5.fc9.ppc requires /sbin/ldconfig SILLY-0.1.0-5.fc9.ppc64 requires /sbin/ldconfig SIMVoleon-2.0.1-7.fc9.ppc requires /bin/sh SIMVoleon-2.0.1-7.fc9.ppc requires /sbin/ldconfig SIMVoleon-2.0.1-7.fc9.ppc64 requires /bin/sh SIMVoleon-2.0.1-7.fc9.ppc64 requires /sbin/ldconfig SIMVoleon-devel-2.0.1-7.fc9.ppc requires /bin/sh SIMVoleon-devel-2.0.1-7.fc9.ppc64 requires /bin/sh ScientificPython-2.6-12.fc9.ppc requires /usr/bin/python SimGear-1.0.0-4.fc10.ppc requires /sbin/ldconfig SimGear-1.0.0-4.fc10.ppc64 requires /sbin/ldconfig SoQt-1.4.1-9.fc9.ppc requires /bin/sh SoQt-1.4.1-9.fc9.ppc requires /sbin/ldconfig SoQt-1.4.1-9.fc9.ppc64 requires /bin/sh SoQt-1.4.1-9.fc9.ppc64 requires /sbin/ldconfig SoQt-devel-1.4.1-9.fc9.ppc requires /usr/share/aclocal SoQt-devel-1.4.1-9.fc9.ppc requires /bin/sh SoQt-devel-1.4.1-9.fc9.ppc64 requires /usr/share/aclocal SoQt-devel-1.4.1-9.fc9.ppc64 requires /bin/sh Sprog-0.14-13.fc9.noarch requires /usr/bin/perl TeXmacs-1.0.6.14-1.fc9.ppc requires /bin/sh TeXmacs-1.0.6.14-1.fc9.ppc requires /usr/bin/env TeXmacs-1.0.6.14-1.fc9.ppc requires /bin/bash TeXmacs-1.0.6.14-1.fc9.ppc requires /bin/sh Terminal-0.2.8-3.fc9.ppc requires /bin/sh Terminal-0.2.8-3.fc9.ppc requires /bin/sh Thunar-0.9.0-4.fc9.ppc requires /bin/sh Thunar-0.9.0-4.fc9.ppc requires /bin/sh Thunar-0.9.0-4.fc9.ppc64 requires /bin/sh Thunar-0.9.0-4.fc9.ppc64 requires /bin/sh TnL-data-071111-1.fc9.noarch requires /bin/sh TurboGears-1.0.4.4-2.fc9.noarch requires /usr/bin/python VLGothic-fonts-20080429-1.fc10.noarch requires /bin/sh VLGothic-fonts-proportional-20080429-1.fc10.noarch requires /bin/sh WINGs-devel-0.92.0-17.fc9.ppc requires /bin/sh WINGs-devel-0.92.0-17.fc9.ppc64 requires /bin/sh WINGs-libs-0.92.0-17.fc9.ppc requires /sbin/ldconfig WINGs-libs-0.92.0-17.fc9.ppc64 requires /sbin/ldconfig WebKit-gtk-1.0.0-0.10.svn32531.fc10.ppc requires /sbin/ldconfig WebKit-gtk-1.0.0-0.10.svn32531.fc10.ppc64 requires /sbin/ldconfig WindowMaker-0.92.0-17.fc9.ppc requires /sbin/ldconfig WindowMaker-0.92.0-17.fc9.ppc requires /usr/bin/perl WindowMaker-0.92.0-17.fc9.ppc requires /bin/sh WindowMaker-0.92.0-17.fc9.ppc64 requires /sbin/ldconfig WindowMaker-0.92.0-17.fc9.ppc64 requires /usr/bin/perl WindowMaker-0.92.0-17.fc9.ppc64 requires /bin/sh WindowMaker-devel-0.92.0-17.fc9.ppc requires /bin/sh WindowMaker-devel-0.92.0-17.fc9.ppc64 requires /bin/sh WritRecogn-0.1.9-0.fc10.ppc requires /bin/sh Xaw3d-1.5E-11.1.ppc requires /sbin/ldconfig Xaw3d-1.5E-11.1.ppc64 requires /sbin/ldconfig Zim-0.23-2.fc9.noarch requires /usr/bin/perl a2ps-4.14-3.fc10.ppc requires /sbin/install-info a2ps-4.14-3.fc10.ppc requires /sbin/ldconfig a2ps-4.14-3.fc10.ppc requires /usr/bin/perl a2ps-4.14-3.fc10.ppc requires /bin/sh a2ps-4.14-3.fc10.ppc requires /bin/sh a2ps-4.14-3.fc10.ppc64 requires /sbin/install-info a2ps-4.14-3.fc10.ppc64 requires /sbin/ldconfig a2ps-4.14-3.fc10.ppc64 requires /usr/bin/perl a2ps-4.14-3.fc10.ppc64 requires /bin/sh a2ps-4.14-3.fc10.ppc64 requires /bin/sh aalib-devel-1.4.0-0.15.rc5.fc9.ppc requires /bin/sh aalib-devel-1.4.0-0.15.rc5.fc9.ppc requires /sbin/install-info aalib-devel-1.4.0-0.15.rc5.fc9.ppc requires /bin/sh aalib-devel-1.4.0-0.15.rc5.fc9.ppc64 requires /bin/sh aalib-devel-1.4.0-0.15.rc5.fc9.ppc64 requires /sbin/install-info aalib-devel-1.4.0-0.15.rc5.fc9.ppc64 requires /bin/sh aalib-libs-1.4.0-0.15.rc5.fc9.ppc requires /sbin/ldconfig aalib-libs-1.4.0-0.15.rc5.fc9.ppc64 requires /sbin/ldconfig abcde-2.3.99.6-6.noarch requires /bin/bash abcde-2.3.99.6-6.noarch requires /bin/sh abcde-2.3.99.6-6.noarch requires /usr/bin/python 1:abiword-2.6.3-1.fc9.ppc requires /usr/bin/perl 1:abiword-2.6.3-1.fc9.ppc requires /bin/sh 1:abiword-2.6.3-1.fc9.ppc requires /bin/sh abuse-0.7.1-1.fc9.ppc requires /bin/sh abyssinica-fonts-1.0-2.fc8.noarch requires /bin/sh ack-1.78-1.fc9.noarch requires /usr/bin/perl adanaxisgpl-1.2.5-2.fc9.ppc requires /bin/sh adaptx-0.9.13-5jpp.3.fc9.ppc requires /bin/sh adaptx-javadoc-0.9.13-5jpp.3.fc9.ppc requires /bin/sh adaptx-javadoc-0.9.13-5jpp.3.fc9.ppc requires /bin/rm adaptx-javadoc-0.9.13-5jpp.3.fc9.ppc requires /bin/ln adime-2.2.1-7.fc9.ppc requires /sbin/ldconfig adime-2.2.1-7.fc9.ppc64 requires /sbin/ldconfig adime-devel-2.2.1-7.fc9.ppc requires /bin/sh adime-devel-2.2.1-7.fc9.ppc requires /sbin/install-info adime-devel-2.2.1-7.fc9.ppc64 requires /bin/sh adime-devel-2.2.1-7.fc9.ppc64 requires /sbin/install-info adminutil-1.1.6-1.fc9.ppc requires /sbin/ldconfig adminutil-1.1.6-1.fc9.ppc64 requires /sbin/ldconfig adns-1.4-3.fc9.ppc requires /sbin/ldconfig adns-1.4-3.fc9.ppc64 requires /sbin/ldconfig adplug-2.1-6.fc9.ppc requires /sbin/ldconfig adplug-2.1-6.fc9.ppc64 requires /sbin/ldconfig adplug-devel-2.1-6.fc9.ppc requires /bin/sh adplug-devel-2.1-6.fc9.ppc requires /sbin/install-info adplug-devel-2.1-6.fc9.ppc64 requires /bin/sh adplug-devel-2.1-6.fc9.ppc64 requires /sbin/install-info afflib-3.1.6-1.fc9.ppc requires /sbin/ldconfig afflib-3.1.6-1.fc9.ppc64 requires /sbin/ldconfig agave-0.4.2-7.fc9.ppc requires /bin/sh agg-2.5-6.fc9.ppc requires /sbin/ldconfig agg-2.5-6.fc9.ppc64 requires /sbin/ldconfig agistudio-1.2.3-7.fc9.ppc requires /bin/sh aiccu-2007.01.15-3.fc9.ppc requires /bin/sh aiccu-2007.01.15-3.fc9.ppc requires /bin/sh 1:aiksaurus-1.2.1-15.fc6.ppc requires /sbin/ldconfig 1:aiksaurus-1.2.1-15.fc6.ppc64 requires /sbin/ldconfig 1:aiksaurus-gtk-1.2.1-15.fc6.ppc requires /bin/sh 1:aiksaurus-gtk-1.2.1-15.fc6.ppc64 requires /bin/sh aircrack-ng-0.9.3-1.fc9.ppc requires /bin/sh akode-2.0.2-5.fc9.ppc requires /sbin/ldconfig akode-2.0.2-5.fc9.ppc64 requires /sbin/ldconfig akode-devel-2.0.2-5.fc9.ppc requires /bin/sh akode-devel-2.0.2-5.fc9.ppc64 requires /bin/sh akonadi-0.80.0-2.fc10.ppc requires /bin/sh akonadi-0.80.0-2.fc10.ppc requires /sbin/ldconfig akonadi-0.80.0-2.fc10.ppc64 requires /bin/sh akonadi-0.80.0-2.fc10.ppc64 requires /sbin/ldconfig alacarte-0.11.5-1.fc9.noarch requires /bin/sh alacarte-0.11.5-1.fc9.noarch requires /usr/bin/python2.5 alchemist-1.0.37-4.fc9.ppc requires /usr/bin/python alchemist-1.0.37-4.fc9.ppc requires /sbin/ldconfig alchemist-1.0.37-4.fc9.ppc64 requires /usr/bin/python alchemist-1.0.37-4.fc9.ppc64 requires /sbin/ldconfig aldrin-0.11-6.fc8.noarch requires /bin/sh aldrin-0.11-6.fc8.noarch requires /usr/bin/python alex4-1.0-6.fc9.ppc requires /bin/sh alexandria-0.6.3-4.fc9.noarch requires /bin/sh alexandria-0.6.3-4.fc9.noarch requires /usr/bin/env alfont-2.0.6-4.fc9.ppc requires /sbin/ldconfig alfont-2.0.6-4.fc9.ppc64 requires /sbin/ldconfig alienarena-6.10-6.fc9.ppc requires /bin/bash alienarena-data-20071011-2.fc9.noarch requires /bin/sh alienblaster-1.1.0-4.fc9.ppc requires /bin/sh alienblaster-1.1.0-4.fc9.ppc requires /bin/bash alleggl-0.4.3-3.fc9.ppc requires /sbin/ldconfig alleggl-0.4.3-3.fc9.ppc64 requires /sbin/ldconfig allegro-4.2.2-10.fc10.ppc requires /sbin/ldconfig allegro-4.2.2-10.fc10.ppc64 requires /sbin/ldconfig allegro-devel-4.2.2-10.fc10.ppc requires /bin/sh allegro-devel-4.2.2-10.fc10.ppc requires /sbin/install-info allegro-devel-4.2.2-10.fc10.ppc requires /bin/sh allegro-devel-4.2.2-10.fc10.ppc64 requires /bin/sh allegro-devel-4.2.2-10.fc10.ppc64 requires /sbin/install-info allegro-devel-4.2.2-10.fc10.ppc64 requires /bin/sh alleyoop-0.9.3-4.fc9.ppc requires /bin/sh alliance-5.0-13.20070718snap.fc9.ppc requires /bin/sh alliance-5.0-13.20070718snap.fc9.ppc requires /bin/sh alltray-0.70-2.fc9.ppc requires /sbin/ldconfig alltray-0.70-2.fc9.ppc64 requires /sbin/ldconfig alphabet-soup-1.1-4.fc9.ppc requires /bin/sh alsa-lib-1.0.16-3.fc9.ppc requires /sbin/ldconfig alsa-lib-1.0.16-3.fc9.ppc requires /bin/sh alsa-lib-1.0.16-3.fc9.ppc64 requires /sbin/ldconfig alsa-lib-1.0.16-3.fc9.ppc64 requires /bin/sh alsa-oss-1.0.15-0.1.fc9.ppc requires /bin/sh alsa-oss-libs-1.0.15-0.1.fc9.ppc requires /sbin/ldconfig alsa-oss-libs-1.0.15-0.1.fc9.ppc64 requires /sbin/ldconfig alsa-utils-1.0.16-3.fc10.ppc requires /bin/bash 5:am-utils-6.1.5-8.fc9.ppc requires /bin/sh 5:am-utils-6.1.5-8.fc9.ppc requires /sbin/install-info 5:am-utils-6.1.5-8.fc9.ppc requires /bin/sh 5:am-utils-6.1.5-8.fc9.ppc requires /bin/grep 5:am-utils-6.1.5-8.fc9.ppc requires /usr/bin/perl 5:am-utils-6.1.5-8.fc9.ppc requires /bin/bash 5:am-utils-6.1.5-8.fc9.ppc requires /sbin/chkconfig 5:am-utils-6.1.5-8.fc9.ppc64 requires /bin/sh 5:am-utils-6.1.5-8.fc9.ppc64 requires /bin/sh 5:am-utils-6.1.5-8.fc9.ppc64 requires /sbin/install-info 5:am-utils-6.1.5-8.fc9.ppc64 requires /bin/grep 5:am-utils-6.1.5-8.fc9.ppc64 requires /usr/bin/perl 5:am-utils-6.1.5-8.fc9.ppc64 requires /bin/bash 5:am-utils-6.1.5-8.fc9.ppc64 requires /sbin/chkconfig amanda-2.5.2p1-10.fc9.ppc requires /sbin/ldconfig amanda-2.5.2p1-10.fc9.ppc requires /bin/sh amanda-2.5.2p1-10.fc9.ppc requires /usr/bin/Mail amanda-2.5.2p1-10.fc9.ppc64 requires /bin/sh amanda-2.5.2p1-10.fc9.ppc64 requires /sbin/ldconfig amanda-2.5.2p1-10.fc9.ppc64 requires /usr/bin/Mail amanda-client-2.5.2p1-10.fc9.ppc requires /bin/sh amanda-client-2.5.2p1-10.fc9.ppc requires /sbin/service amanda-client-2.5.2p1-10.fc9.ppc requires /bin/sh amanda-server-2.5.2p1-10.fc9.ppc requires /sbin/service amanda-server-2.5.2p1-10.fc9.ppc requires /usr/bin/perl amanda-server-2.5.2p1-10.fc9.ppc requires /bin/sh amanda-server-2.5.2p1-10.fc9.ppc requires /bin/sh amanith-0.3-9.fc9.ppc requires /sbin/ldconfig amanith-0.3-9.fc9.ppc64 requires /sbin/ldconfig amarok-1.4.8-5.fc9.ppc requires /usr/bin/env amarok-1.4.8-5.fc9.ppc requires /bin/sh amarok-1.4.8-5.fc9.ppc64 requires /bin/sh amarok-1.4.8-5.fc9.ppc64 requires /usr/bin/env amarokFS-0.5-3.fc9.ppc requires /bin/sh amarokFS-0.5-3.fc9.ppc requires /usr/bin/env amavisd-new-2.5.2-2.fc8.noarch requires /bin/sh amavisd-new-2.5.2-2.fc8.noarch requires /usr/sbin/useradd amavisd-new-2.5.2-2.fc8.noarch requires /sbin/service amavisd-new-2.5.2-2.fc8.noarch requires /usr/sbin/clamd amavisd-new-2.5.2-2.fc8.noarch requires /usr/bin/ar amavisd-new-2.5.2-2.fc8.noarch requires /usr/sbin/tmpwatch amavisd-new-2.5.2-2.fc8.noarch requires /etc/cron.daily amavisd-new-2.5.2-2.fc8.noarch requires /bin/bash amavisd-new-2.5.2-2.fc8.noarch requires /bin/sh amavisd-new-2.5.2-2.fc8.noarch requires /usr/bin/perl amavisd-new-2.5.2-2.fc8.noarch requires /etc/clamd.d amavisd-new-2.5.2-2.fc8.noarch requires /sbin/chkconfig amoebax-0.2.0-3.fc9.ppc requires /bin/sh amsn-0.97-3.fc9.ppc requires /bin/sh amsn-0.97-3.fc9.ppc requires /usr/bin/tclsh amsn-0.97-3.fc9.ppc requires /usr/bin/env amsn-0.97-3.fc9.ppc requires /usr/bin/wish amsn-0.97-3.fc9.ppc requires /bin/sh amtterm-1.0-2.fc9.ppc requires /usr/bin/perl anaconda-11.4.1.1-1.ppc requires /bin/sh anaconda-11.4.1.1-1.ppc requires /usr/bin/python anaconda-11.4.1.1-1.ppc requires /bin/sh anaconda-runtime-11.4.1.1-1.ppc requires /usr/bin/env anaconda-runtime-11.4.1.1-1.ppc requires /usr/bin/python anaconda-runtime-11.4.1.1-1.ppc requires /bin/bash anaconda-runtime-11.4.1.1-1.ppc requires /bin/sh anacron-2.3-59.fc9.ppc requires /bin/sh anacron-2.3-59.fc9.ppc requires /sbin/chkconfig anacron-2.3-59.fc9.ppc requires /bin/sh anacron-2.3-59.fc9.ppc requires /sbin/service and-1.2.2-6.fc9.ppc requires /bin/sh and-1.2.2-6.fc9.ppc requires /sbin/chkconfig and-1.2.2-6.fc9.ppc requires /bin/sh and-1.2.2-6.fc9.ppc requires /sbin/service angrydd-1.0.1-3.fc8.noarch requires /bin/sh angrydd-1.0.1-3.fc8.noarch requires /usr/bin/env animorph-0.3-3.fc9.ppc requires /sbin/ldconfig animorph-0.3-3.fc9.ppc64 requires /sbin/ldconfig 1:anjuta-2.2.3-7.fc9.ppc requires /bin/sh 1:anjuta-2.2.3-7.fc9.ppc requires /sbin/ldconfig 1:anjuta-2.2.3-7.fc9.ppc requires /usr/bin/perl 1:anjuta-2.2.3-7.fc9.ppc requires /bin/bash 1:anjuta-2.2.3-7.fc9.ppc64 requires /bin/sh 1:anjuta-2.2.3-7.fc9.ppc64 requires /sbin/ldconfig 1:anjuta-2.2.3-7.fc9.ppc64 requires /usr/bin/perl 1:anjuta-2.2.3-7.fc9.ppc64 requires /bin/bash 1:anjuta-doc-2.2.3-7.fc9.ppc requires /bin/sh ant-1.7.0-1jpp.4.fc9.ppc requires /bin/sh ant-antlr-1.7.0-1jpp.4.fc9.ppc requires /bin/sh ant-apache-bcel-1.7.0-1jpp.4.fc9.ppc requires /bin/sh ant-apache-bsf-1.7.0-1jpp.4.fc9.ppc requires /bin/sh ant-apache-log4j-1.7.0-1jpp.4.fc9.ppc requires /bin/sh ant-apache-oro-1.7.0-1jpp.4.fc9.ppc requires /bin/sh ant-apache-regexp-1.7.0-1jpp.4.fc9.ppc requires /bin/sh ant-apache-resolver-1.7.0-1jpp.4.fc9.ppc requires /bin/sh ant-commons-logging-1.7.0-1jpp.4.fc9.ppc requires /bin/sh ant-commons-net-1.7.0-1jpp.4.fc9.ppc requires /bin/sh ant-contrib-1.0-0.5.b2.fc9.ppc requires /bin/sh ant-javamail-1.7.0-1jpp.4.fc9.ppc requires /bin/sh ant-jdepend-1.7.0-1jpp.4.fc9.ppc requires /bin/sh ant-jmf-1.7.0-1jpp.4.fc9.ppc requires /bin/sh ant-jsch-1.7.0-1jpp.4.fc9.ppc requires /bin/sh ant-junit-1.7.0-1jpp.4.fc9.ppc requires /bin/sh ant-nodeps-1.7.0-1jpp.4.fc9.ppc requires /bin/sh ant-scripts-1.7.0-1jpp.4.fc9.ppc requires /usr/bin/python ant-swing-1.7.0-1jpp.4.fc9.ppc requires /bin/sh ant-trax-1.7.0-1jpp.4.fc9.ppc requires /bin/sh anthy-9100e-2.fc9.ppc requires /sbin/ldconfig anthy-9100e-2.fc9.ppc64 requires /sbin/ldconfig antiword-0.37-7.fc9.ppc requires /bin/sh antlr-2.7.7-1jpp.7.fc9.ppc requires /usr/sbin/update-alternatives antlr-2.7.7-1jpp.7.fc9.ppc requires /bin/sh antlr-2.7.7-1jpp.7.fc9.ppc requires /bin/sh antlr-javadoc-2.7.7-1jpp.7.fc9.ppc requires /bin/sh antlr-javadoc-2.7.7-1jpp.7.fc9.ppc requires /bin/rm antlr-javadoc-2.7.7-1jpp.7.fc9.ppc requires /bin/ln ants-1.4-4.fc9.ppc requires /bin/sh anyremote-data-4.4-1.fc8.ppc requires /usr/bin/env aoetools-23-1.fc9.ppc requires /bin/bash aoetools-23-1.fc9.ppc requires /bin/sh apcupsd-3.14.3-2.1.fc9.ppc requires /bin/sh apcupsd-3.14.3-2.1.fc9.ppc requires /sbin/service apcupsd-3.14.3-2.1.fc9.ppc requires /bin/sh apcupsd-3.14.3-2.1.fc9.ppc requires /sbin/chkconfig apcupsd-3.14.3-2.1.fc9.ppc requires /bin/mail apg-2.3.0b-6.fc9.ppc requires /bin/sh aplus-fsf-4.22.1-3.fc10.ppc requires /sbin/ldconfig aplus-fsf-4.22.1-3.fc10.ppc64 requires /sbin/ldconfig apmud-1.0.0-9.fc9.ppc requires /bin/sh apmud-1.0.0-9.fc9.ppc requires /usr/bin/wish apmud-1.0.0-9.fc9.ppc requires /bin/sh apollon-1.0.1-13.fc9.ppc requires /bin/sh apollon-libs-1.0.1-13.fc9.ppc requires /sbin/ldconfig apollon-libs-1.0.1-13.fc9.ppc64 requires /sbin/ldconfig apr-1.2.12-2.fc9.ppc requires /sbin/ldconfig apr-1.2.12-2.fc9.ppc64 requires /sbin/ldconfig apr-devel-1.2.12-2.fc9.ppc requires /bin/sh apr-devel-1.2.12-2.fc9.ppc64 requires /bin/sh apr-util-1.2.12-5.fc9.ppc requires /sbin/ldconfig apr-util-1.2.12-5.fc9.ppc64 requires /sbin/ldconfig apr-util-devel-1.2.12-5.fc9.ppc requires /bin/sh apr-util-devel-1.2.12-5.fc9.ppc64 requires /bin/sh aprsd-2.2.5-15.3.fc9.ppc requires /bin/sh aprsd-2.2.5-15.3.fc9.ppc requires /sbin/service aprsd-2.2.5-15.3.fc9.ppc requires /bin/bash aprsd-2.2.5-15.3.fc9.ppc requires /sbin/chkconfig apt-0.5.15lorg3.94-3.fc9.ppc requires /bin/sh apt-0.5.15lorg3.94-3.fc9.ppc requires /sbin/ldconfig apt-0.5.15lorg3.94-3.fc9.ppc requires /bin/bash apt-0.5.15lorg3.94-3.fc9.ppc requires /bin/sh apt-0.5.15lorg3.94-3.fc9.ppc64 requires /bin/sh apt-0.5.15lorg3.94-3.fc9.ppc64 requires /sbin/ldconfig apt-0.5.15lorg3.94-3.fc9.ppc64 requires /bin/bash apt-0.5.15lorg3.94-3.fc9.ppc64 requires /bin/sh aqbanking-2.3.3-3.fc9.ppc requires /sbin/ldconfig aqbanking-2.3.3-3.fc9.ppc64 requires /sbin/ldconfig aqbanking-devel-2.3.3-3.fc9.ppc requires /bin/sh aqbanking-devel-2.3.3-3.fc9.ppc64 requires /bin/sh aqsis-1.2.0-8.fc9.ppc requires /usr/bin/env aqsis-1.2.0-8.fc9.ppc requires /sbin/ldconfig aqsis-1.2.0-8.fc9.ppc64 requires /sbin/ldconfig aqsis-1.2.0-8.fc9.ppc64 requires /usr/bin/env aqsis-data-1.2.0-8.fc9.ppc requires /bin/bash archivemail-0.7.2-1.fc9.noarch requires /usr/bin/env archmage-0.1.9-2.fc9.noarch requires /usr/bin/python ardour-2.4.1-1.fc9.ppc requires /bin/sh ardour-2.4.1-1.fc9.ppc requires /bin/sh argus-2.0.6.fixes.1-15.fc9.ppc requires /sbin/chkconfig argus-2.0.6.fixes.1-15.fc9.ppc requires /bin/sh argus-2.0.6.fixes.1-15.fc9.ppc requires /bin/sh arj-3.10.22-4.fc9.ppc requires /bin/sh arm-gp2x-linux-gcc-4.1.2-8.fc9.ppc requires /bin/sh armacycles-ad-0.2.8.2.1-6.fc9.ppc requires /bin/sh armacycles-ad-0.2.8.2.1-6.fc9.ppc requires /bin/bash armacycles-ad-dedicated-0.2.8.2.1-6.fc9.ppc requires /bin/bash arp-scan-1.6-2.fc9.ppc requires /usr/bin/perl arpack-2.1-7.fc9.ppc requires /sbin/ldconfig arpack-2.1-7.fc9.ppc64 requires /sbin/ldconfig arptables_jf-0.0.8-12.fc9.ppc requires /bin/sh arptables_jf-0.0.8-12.fc9.ppc requires /bin/sh 14:arpwatch-2.1a15-8.fc9.ppc requires /bin/sh 14:arpwatch-2.1a15-8.fc9.ppc requires /bin/bash 14:arpwatch-2.1a15-8.fc9.ppc requires /sbin/chkconfig 14:arpwatch-2.1a15-8.fc9.ppc requires /bin/sh 14:arpwatch-2.1a15-8.fc9.ppc requires /sbin/service arrows-0.6-6.fc9.ppc requires /bin/sh 8:arts-1.5.9-3.fc10.ppc requires /sbin/ldconfig 8:arts-1.5.9-3.fc10.ppc requires /bin/sh 8:arts-1.5.9-3.fc10.ppc64 requires /sbin/ldconfig 8:arts-1.5.9-3.fc10.ppc64 requires /bin/sh 8:arts-devel-1.5.9-3.fc10.ppc requires /bin/sh 8:arts-devel-1.5.9-3.fc10.ppc64 requires /bin/sh artwiz-aleczapka-fonts-1.3-5.fc8.1.noarch requires /bin/sh asc-2.1.0.0-1.fc10.ppc requires /bin/sh asciidoc-8.2.5-2.fc9.noarch requires /usr/bin/env asm2-2.2.3-2jpp.1.fc9.noarch requires /bin/sh 12:aspell-0.60.6-1.fc10.ppc requires /bin/sh 12:aspell-0.60.6-1.fc10.ppc requires /sbin/install-info 12:aspell-0.60.6-1.fc10.ppc requires /sbin/ldconfig 12:aspell-0.60.6-1.fc10.ppc requires /bin/sh 12:aspell-0.60.6-1.fc10.ppc64 requires /bin/sh 12:aspell-0.60.6-1.fc10.ppc64 requires /sbin/install-info 12:aspell-0.60.6-1.fc10.ppc64 requires /sbin/ldconfig 12:aspell-0.60.6-1.fc10.ppc64 requires /bin/sh 12:aspell-devel-0.60.6-1.fc10.ppc requires /bin/sh 12:aspell-devel-0.60.6-1.fc10.ppc requires /sbin/install-info 12:aspell-devel-0.60.6-1.fc10.ppc requires /bin/sh 12:aspell-devel-0.60.6-1.fc10.ppc64 requires /bin/sh 12:aspell-devel-0.60.6-1.fc10.ppc64 requires /sbin/install-info 12:aspell-devel-0.60.6-1.fc10.ppc64 requires /bin/sh asterisk-1.6.0-0.13.beta8.fc10.ppc requires /bin/sh asterisk-1.6.0-0.13.beta8.fc10.ppc requires /usr/sbin/groupadd asterisk-1.6.0-0.13.beta8.fc10.ppc requires /usr/sbin/useradd asterisk-1.6.0-0.13.beta8.fc10.ppc requires /sbin/service asterisk-1.6.0-0.13.beta8.fc10.ppc requires /bin/bash asterisk-1.6.0-0.13.beta8.fc10.ppc requires /bin/sh asterisk-1.6.0-0.13.beta8.fc10.ppc requires /sbin/chkconfig asterisk-misdn-1.6.0-0.13.beta8.fc10.ppc requires /bin/sh asterisk-misdn-1.6.0-0.13.beta8.fc10.ppc requires /usr/sbin/usermod asterisk-voicemail-1.6.0-0.13.beta8.fc10.ppc requires /usr/bin/sox asterisk-zaptel-1.6.0-0.13.beta8.fc10.ppc requires /bin/sh asterisk-zaptel-1.6.0-0.13.beta8.fc10.ppc requires /usr/sbin/usermod astromenace-1.2-8.fc9.ppc requires /bin/sh asylum-0.2.3-3.fc9.ppc requires /bin/sh asymptote-1.42-3.fc10.ppc requires /bin/sh asymptote-1.42-3.fc10.ppc requires /usr/bin/env at-3.1.10-23.fc9.ppc requires /bin/sh at-3.1.10-23.fc9.ppc requires /bin/bash at-3.1.10-23.fc9.ppc requires /bin/sh at-spi-1.22.1-2.fc10.ppc requires /sbin/ldconfig at-spi-1.22.1-2.fc10.ppc64 requires /sbin/ldconfig aterm-1.0.1-2.fc9.ppc requires /bin/sh atk-1.22.0-1.fc9.ppc requires /sbin/ldconfig atk-1.22.0-1.fc9.ppc64 requires /sbin/ldconfig atlas-3.6.0-15.fc10.ppc requires /etc/ld.so.conf.d atlas-3.6.0-15.fc10.ppc requires /sbin/ldconfig atlas-3.6.0-15.fc10.ppc64 requires /sbin/ldconfig atlas-3.6.0-15.fc10.ppc64 requires /etc/ld.so.conf.d atlascpp-0.6.1-3.fc9.ppc requires /sbin/ldconfig atlascpp-0.6.1-3.fc9.ppc64 requires /sbin/ldconfig atomorun-1.1-0.8.pre2.fc9.ppc requires /bin/sh atop-1.23-7.fc10.ppc requires /bin/sh atop-1.23-7.fc10.ppc requires /bin/bash atop-1.23-7.fc10.ppc requires /sbin/chkconfig atop-1.23-7.fc10.ppc requires /sbin/service audacious-1.4.6-1.fc9.ppc requires /bin/sh audacious-devel-1.4.6-1.fc9.ppc requires /sbin/ldconfig audacious-devel-1.4.6-1.fc9.ppc64 requires /sbin/ldconfig audacious-libs-1.4.6-1.fc9.ppc requires /sbin/ldconfig audacious-libs-1.4.6-1.fc9.ppc64 requires /sbin/ldconfig audacious-plugins-1.4.5-1.fc9.ppc requires /bin/sh audacious-plugins-1.4.5-1.fc9.ppc requires /sbin/ldconfig audacity-1.3.5-0.4.beta.fc10.ppc requires /bin/sh audio-convert-mod-3.45.4-1.fc10.noarch requires /bin/bash audio-entropyd-1.0.1-2.fc9.ppc requires /bin/sh audio-entropyd-1.0.1-2.fc9.ppc requires /bin/sh 1:audiofile-0.2.6-8.fc9.ppc requires /sbin/ldconfig 1:audiofile-0.2.6-8.fc9.ppc64 requires /sbin/ldconfig 1:audiofile-devel-0.2.6-8.fc9.ppc requires /bin/sh 1:audiofile-devel-0.2.6-8.fc9.ppc64 requires /bin/sh audispd-plugins-1.7.3-1.fc10.ppc requires /bin/sh audispd-plugins-1.7.3-1.fc10.ppc requires /usr/sbin/semodule audispd-plugins-1.7.3-1.fc10.ppc requires /sbin/restorecon audit-1.7.3-1.fc10.ppc requires /bin/sh audit-1.7.3-1.fc10.ppc requires /bin/bash audit-libs-1.7.3-1.fc10.ppc requires /sbin/ldconfig audit-libs-1.7.3-1.fc10.ppc64 requires /sbin/ldconfig audit-viewer-0.2-2.fc10.ppc requires /bin/sh audit-viewer-0.2-2.fc10.ppc requires /bin/sh augeas-libs-0.1.1-1.fc10.ppc requires /sbin/ldconfig augeas-libs-0.1.1-1.fc10.ppc64 requires /sbin/ldconfig aumix-2.8-17.fc9.ppc requires /bin/sh auriferous-1.0.1-5.fc9.ppc requires /bin/sh authconfig-5.4.2-1.fc9.ppc requires /bin/sh authconfig-5.4.2-1.fc9.ppc requires /usr/bin/python authconfig-gtk-5.4.2-1.fc9.ppc requires /usr/bin/python authd-1.4.3-19.fc9.ppc requires /bin/sh autobuild-applet-1.0.3-5.fc9.ppc requires /usr/bin/python autobuild-applet-1.0.3-5.fc9.ppc requires /bin/sh autoconf-2.62-1.fc10.noarch requires /bin/sh autoconf-2.62-1.fc10.noarch requires /sbin/install-info autoconf-2.62-1.fc10.noarch requires /usr/bin/perl autoconf-2.62-1.fc10.noarch requires /bin/sh autoconf213-2.13-18.fc8.noarch requires /bin/sh autoconf213-2.13-18.fc8.noarch requires /usr/bin/perl autoconf213-2.13-18.fc8.noarch requires /sbin/install-info autoconf213-2.13-18.fc8.noarch requires /bin/sh autodir-0.99.9-5.fc9.ppc requires /bin/sh autodir-0.99.9-5.fc9.ppc requires /sbin/service autodir-0.99.9-5.fc9.ppc requires /bin/sh autodir-0.99.9-5.fc9.ppc requires /sbin/chkconfig autodownloader-0.2.0-6.fc9.noarch requires /usr/bin/env 1:autofs-5.0.3-16.ppc requires /bin/sh 1:autofs-5.0.3-16.ppc requires /bin/ps 1:autofs-5.0.3-16.ppc requires /sbin/service 1:autofs-5.0.3-16.ppc requires /bin/bash 1:autofs-5.0.3-16.ppc requires /sbin/chkconfig autogen-5.9.4-4.fc9.ppc requires /bin/sh autogen-5.9.4-4.fc9.ppc requires /sbin/install-info autogen-libopts-5.9.4-4.fc9.ppc requires /sbin/ldconfig autogen-libopts-5.9.4-4.fc9.ppc64 requires /sbin/ldconfig autogen-libopts-devel-5.9.4-4.fc9.ppc requires /bin/sh autogen-libopts-devel-5.9.4-4.fc9.ppc64 requires /bin/sh automake-1.10.1-2.noarch requires /bin/sh automake-1.10.1-2.noarch requires /sbin/install-info automake-1.10.1-2.noarch requires /bin/sh automake-1.10.1-2.noarch requires /usr/bin/perl automake14-1.4p6-15.fc7.noarch requires /bin/sh automake14-1.4p6-15.fc7.noarch requires /usr/bin/perl automake14-1.4p6-15.fc7.noarch requires /sbin/install-info automake14-1.4p6-15.fc7.noarch requires /bin/sh automake15-1.5-23.noarch requires /bin/sh automake15-1.5-23.noarch requires /usr/bin/perl automake15-1.5-23.noarch requires /sbin/install-info automake15-1.5-23.noarch requires /bin/sh automake16-1.6.3-14.noarch requires /bin/sh automake16-1.6.3-14.noarch requires /sbin/install-info automake16-1.6.3-14.noarch requires /bin/sh automake16-1.6.3-14.noarch requires /usr/bin/perl automake17-1.7.9-11.noarch requires /bin/sh automake17-1.7.9-11.noarch requires /sbin/install-info automake17-1.7.9-11.noarch requires /bin/sh automake17-1.7.9-11.noarch requires /usr/bin/perl autossh-1.4a-1.fc9.ppc requires /usr/bin/ssh autotrace-0.31.1-16.fc9.ppc requires /sbin/ldconfig autotrace-0.31.1-16.fc9.ppc requires libWand.so.10 autotrace-0.31.1-16.fc9.ppc requires libMagick.so.10 autotrace-0.31.1-16.fc9.ppc64 requires libWand.so.10()(64bit) autotrace-0.31.1-16.fc9.ppc64 requires /sbin/ldconfig autotrace-0.31.1-16.fc9.ppc64 requires libMagick.so.10()(64bit) autotrace-devel-0.31.1-16.fc9.ppc requires /bin/sh autotrace-devel-0.31.1-16.fc9.ppc64 requires /bin/sh avahi-0.6.22-10.fc9.ppc requires /bin/sh avahi-0.6.22-10.fc9.ppc requires /bin/sh avahi-0.6.22-10.fc9.ppc64 requires /bin/sh avahi-0.6.22-10.fc9.ppc64 requires /bin/sh avahi-autoipd-0.6.22-10.fc9.ppc requires /bin/sh avahi-autoipd-0.6.22-10.fc9.ppc requires /bin/sh avahi-compat-howl-0.6.22-10.fc9.ppc requires /sbin/ldconfig avahi-compat-howl-0.6.22-10.fc9.ppc64 requires /sbin/ldconfig avahi-compat-libdns_sd-0.6.22-10.fc9.ppc requires /sbin/ldconfig avahi-compat-libdns_sd-0.6.22-10.fc9.ppc64 requires /sbin/ldconfig avahi-dnsconfd-0.6.22-10.fc9.ppc requires /bin/sh avahi-dnsconfd-0.6.22-10.fc9.ppc requires /bin/sh avahi-glib-0.6.22-10.fc9.ppc requires /sbin/ldconfig avahi-glib-0.6.22-10.fc9.ppc64 requires /sbin/ldconfig avahi-gobject-0.6.22-10.fc9.ppc requires /sbin/ldconfig avahi-gobject-0.6.22-10.fc9.ppc64 requires /sbin/ldconfig avahi-qt3-0.6.22-10.fc9.ppc requires /sbin/ldconfig avahi-qt3-0.6.22-10.fc9.ppc64 requires /sbin/ldconfig avahi-tools-0.6.22-10.fc9.ppc requires /usr/bin/python avahi-ui-0.6.22-10.fc9.ppc requires /sbin/ldconfig avahi-ui-0.6.22-10.fc9.ppc64 requires /sbin/ldconfig avalon-framework-4.1.4-3jpp.14.fc9.ppc requires /bin/sh avalon-framework-javadoc-4.1.4-3jpp.14.fc9.ppc requires /bin/rm avalon-framework-javadoc-4.1.4-3jpp.14.fc9.ppc requires /bin/ln avalon-logkit-1.2-5jpp.5.fc9.ppc requires /bin/sh avalon-logkit-javadoc-1.2-5jpp.5.fc9.ppc requires /bin/sh avalon-logkit-javadoc-1.2-5jpp.5.fc9.ppc requires /bin/rm avalon-logkit-javadoc-1.2-5jpp.5.fc9.ppc requires /bin/ln avant-window-navigator-0.2.6-8.fc9.ppc requires /bin/sh avant-window-navigator-0.2.6-8.fc9.ppc requires /usr/bin/env avant-window-navigator-0.2.6-8.fc9.ppc requires /usr/bin/python avant-window-navigator-0.2.6-8.fc9.ppc requires /bin/bash avant-window-navigator-0.2.6-8.fc9.ppc64 requires /bin/sh avant-window-navigator-0.2.6-8.fc9.ppc64 requires /usr/bin/env avant-window-navigator-0.2.6-8.fc9.ppc64 requires /usr/bin/python avant-window-navigator-0.2.6-8.fc9.ppc64 requires /bin/bash avarice-2.6-2.fc9.ppc requires /usr/bin/perl avarice-2.6-2.fc9.ppc requires /bin/sh avr-gcc-4.1.2-6.fc9.ppc requires /bin/sh avr-libc-1.4.6-4.fc8.noarch requires /bin/sh avrdude-5.5-3.fc9.ppc requires /bin/sh avrdude-5.5-3.fc9.ppc requires /sbin/install-info awn-extras-applets-0.2.6-4.fc9.ppc requires /usr/bin/python awn-extras-applets-0.2.6-4.fc9.ppc requires /usr/bin/env awn-extras-applets-0.2.6-4.fc9.ppc requires /bin/sh awn-extras-applets-0.2.6-4.fc9.ppc64 requires /bin/sh awn-extras-applets-0.2.6-4.fc9.ppc64 requires /usr/bin/python awn-extras-applets-0.2.6-4.fc9.ppc64 requires /usr/bin/env awstats-6.7-3.fc9.noarch requires /bin/bash awstats-6.7-3.fc9.noarch requires /usr/bin/perl awstats-6.7-3.fc9.noarch requires /bin/sh awstats-6.7-3.fc9.noarch requires /sbin/service awstats-selinux-6.7-3.fc9.noarch requires /bin/sh ax25-tools-0.0.8-2.fc9.ppc requires /bin/sh axis-1.2.1-3jpp.8.fc9.ppc requires /bin/sh azureus-3.0.4.2-14.fc9.ppc requires /bin/sh azureus-3.0.4.2-14.fc9.ppc requires /bin/sh babel-0.9.2-1.fc9.noarch requires /usr/bin/python babl-0.0.20-1.fc9.ppc requires /sbin/ldconfig babl-0.0.20-1.fc9.ppc64 requires /sbin/ldconfig bacula-client-2.0.3-13.fc9.ppc requires /bin/sh bacula-client-2.0.3-13.fc9.ppc requires /sbin/service bacula-client-2.0.3-13.fc9.ppc requires /bin/bash bacula-client-2.0.3-13.fc9.ppc requires /sbin/chkconfig bacula-common-2.0.3-13.fc9.ppc requires /bin/sh bacula-common-2.0.3-13.fc9.ppc requires /bin/sh bacula-director-common-2.0.3-13.fc9.ppc requires /bin/sh bacula-director-common-2.0.3-13.fc9.ppc requires /bin/bash bacula-director-common-2.0.3-13.fc9.ppc requires /bin/sh bacula-director-common-2.0.3-13.fc9.ppc requires /usr/bin/perl bacula-director-mysql-2.0.3-13.fc9.ppc requires /bin/sh bacula-director-mysql-2.0.3-13.fc9.ppc requires /bin/sh bacula-director-postgresql-2.0.3-13.fc9.ppc requires /bin/sh bacula-director-postgresql-2.0.3-13.fc9.ppc requires /bin/sh bacula-director-sqlite-2.0.3-13.fc9.ppc requires /bin/sh bacula-director-sqlite-2.0.3-13.fc9.ppc requires /bin/sh bacula-storage-common-2.0.3-13.fc9.ppc requires /bin/sh bacula-storage-common-2.0.3-13.fc9.ppc requires /usr/bin/python bacula-storage-common-2.0.3-13.fc9.ppc requires /bin/bash bacula-storage-common-2.0.3-13.fc9.ppc requires /bin/sh bacula-storage-mysql-2.0.3-13.fc9.ppc requires /bin/sh bacula-storage-postgresql-2.0.3-13.fc9.ppc requires /bin/sh bacula-storage-sqlite-2.0.3-13.fc9.ppc requires /bin/sh baekmuk-bdf-fonts-2.2-5.fc9.noarch requires /bin/sh baekmuk-ttf-fonts-batang-2.2-7.fc9.noarch requires /bin/sh baekmuk-ttf-fonts-dotum-2.2-7.fc9.noarch requires /bin/sh baekmuk-ttf-fonts-gulim-2.2-7.fc9.noarch requires /bin/sh baekmuk-ttf-fonts-hline-2.2-7.fc9.noarch requires /bin/sh bakery-2.4.4-2.fc9.ppc requires /sbin/ldconfig bakery-2.4.4-2.fc9.ppc64 requires /sbin/ldconfig ballbuster-1.0-5.fc9.ppc requires /bin/sh ballz-1.0-3.fc9.ppc requires /bin/sh balsa-2.3.23-1.fc9.ppc requires /bin/sh banshee-0.99.1-1.1.fc10.ppc requires /bin/bash banshee-0.99.1-1.1.fc10.ppc requires /bin/sh barcode-0.98-11.fc9.ppc requires /bin/sh barcode-0.98-11.fc9.ppc requires /sbin/install-info bash-3.2-22.fc9.ppc requires /bin/sh bash-3.2-22.fc9.ppc requires /bin/bash bash-3.2-22.fc9.ppc requires /bin/sh bash-completion-20060301-10.noarch requires /bin/sh basket-1.0.2-5.fc9.ppc requires /bin/sh bazaar-1.4.2-11.fc9.ppc requires /usr/bin/gawk bc-1.06-33.fc9.ppc requires /bin/sh bc-1.06-33.fc9.ppc requires /sbin/install-info bcel-5.2-4jpp.2.fc9.ppc requires /bin/sh bcfg2-0.9.5.7-1.fc9.noarch requires /bin/sh bcfg2-0.9.5.7-1.fc9.noarch requires /sbin/chkconfig bcfg2-0.9.5.7-1.fc9.noarch requires /bin/sh bcfg2-0.9.5.7-1.fc9.noarch requires /usr/bin/python bcfg2-0.9.5.7-1.fc9.noarch requires /sbin/service bcfg2-server-0.9.5.7-1.fc9.noarch requires /bin/sh bcfg2-server-0.9.5.7-1.fc9.noarch requires /usr/bin/openssl bcfg2-server-0.9.5.7-1.fc9.noarch requires /sbin/chkconfig bcfg2-server-0.9.5.7-1.fc9.noarch requires /bin/sh bcfg2-server-0.9.5.7-1.fc9.noarch requires /usr/bin/python bcfg2-server-0.9.5.7-1.fc9.noarch requires /sbin/service 1:bdftruncate-7.2-4.fc9.ppc requires /usr/bin/perl bea-stax-1.2.0-0.2.rc1.2jpp.1.fc9.ppc requires /bin/sh bea-stax-api-1.2.0-0.2.rc1.2jpp.1.fc9.ppc requires /bin/sh beagle-0.3.7-3.fc9.ppc requires /bin/bash beagle-0.3.7-3.fc9.ppc requires /bin/sh beagle-0.3.7-3.fc9.ppc requires /bin/sh beagle-devel-0.3.7-3.fc9.ppc requires /bin/sh beagle-gnome-0.3.7-3.fc9.ppc requires /bin/sh berusky-1.1-8.fc9.ppc requires /bin/sh bes-3.5.3-3.fc9.ppc requires /bin/sh bes-3.5.3-3.fc9.ppc requires /sbin/ldconfig bes-3.5.3-3.fc9.ppc requires /bin/sh bes-3.5.3-3.fc9.ppc64 requires /bin/sh bes-3.5.3-3.fc9.ppc64 requires /sbin/ldconfig bes-3.5.3-3.fc9.ppc64 requires /bin/sh bes-devel-3.5.3-3.fc9.ppc requires /bin/sh bes-devel-3.5.3-3.fc9.ppc64 requires /bin/sh bibexport-2.10-2.fc9.noarch requires /usr/bin/texhash bibexport-2.10-2.fc9.noarch requires /bin/sh bibexport-2.10-2.fc9.noarch requires /bin/sh bibletime-1.6.5-4.fc9.ppc requires /bin/sh bibus-1.4.1-4.fc9.noarch requires /usr/bin/env bigboard-0.5.33-2.fc10.ppc requires /bin/sh bigboard-0.5.33-2.fc10.ppc requires /bin/sh bigloo-3.0b-2.fc9.ppc requires /bin/sh bigloo-3.0b-2.fc9.ppc requires /sbin/install-info bigloo-3.0b-2.fc9.ppc requires /bin/sh bigloo-libs-3.0b-2.fc9.ppc requires /sbin/ldconfig biloba-0.6-1.fc10.ppc requires /bin/sh 32:bind-9.5.0-33.rc1.fc10.ppc requires /bin/sh 32:bind-9.5.0-33.rc1.fc10.ppc requires /bin/bash 32:bind-9.5.0-33.rc1.fc10.ppc requires /bin/sh 32:bind-chroot-9.5.0-33.rc1.fc10.ppc requires /bin/sh 32:bind-chroot-9.5.0-33.rc1.fc10.ppc requires /bin/bash 32:bind-chroot-9.5.0-33.rc1.fc10.ppc requires /bin/sh 32:bind-devel-9.5.0-33.rc1.fc10.ppc requires /bin/sh 32:bind-devel-9.5.0-33.rc1.fc10.ppc64 requires /bin/sh 32:bind-libs-9.5.0-33.rc1.fc10.ppc requires /sbin/ldconfig 32:bind-libs-9.5.0-33.rc1.fc10.ppc64 requires /sbin/ldconfig 32:bind-sdb-9.5.0-33.rc1.fc10.ppc requires /bin/sh binutils-2.18.50.0.6-2.ppc requires /bin/sh binutils-2.18.50.0.6-2.ppc requires /sbin/ldconfig binutils-2.18.50.0.6-2.ppc requires /sbin/install-info binutils-2.18.50.0.6-2.ppc requires /bin/sh binutils-devel-2.18.50.0.6-2.ppc requires /bin/sh binutils-devel-2.18.50.0.6-2.ppc requires /sbin/install-info binutils-devel-2.18.50.0.6-2.ppc64 requires /bin/sh binutils-devel-2.18.50.0.6-2.ppc64 requires /sbin/install-info bison-2.3-5.fc9.ppc requires /bin/sh bison-2.3-5.fc9.ppc requires /sbin/install-info bit-0.4.1-3.fc9.ppc requires /sbin/ldconfig bit-0.4.1-3.fc9.ppc64 requires /sbin/ldconfig bitbake-1.8.8-1.fc8.noarch requires /usr/bin/python bitgtkmm-0.4.0-2.fc7.ppc requires /sbin/ldconfig bitgtkmm-0.4.0-2.fc7.ppc64 requires /sbin/ldconfig bitlbee-1.2-1.fc9.ppc requires /bin/sh bitlbee-1.2-1.fc9.ppc requires /sbin/service bitmap-1.0.3-4.fc9.ppc requires /bin/sh bitmap-fonts-0.3-5.2.fc9.noarch requires /bin/sh bitmap-fonts-cjk-0.3-5.2.fc9.noarch requires /bin/sh bitstream-vera-fonts-1.10-8.noarch requires /bin/sh bittorrent-4.4.0-6.fc9.noarch requires /bin/sh bittorrent-4.4.0-6.fc9.noarch requires /bin/bash bittorrent-4.4.0-6.fc9.noarch requires /sbin/chkconfig bittorrent-4.4.0-6.fc9.noarch requires /usr/sbin/useradd bittorrent-4.4.0-6.fc9.noarch requires /usr/bin/python bittorrent-4.4.0-6.fc9.noarch requires /sbin/service bittorrent-4.4.0-6.fc9.noarch requires /usr/sbin/usermod bittorrent-gui-4.4.0-6.fc9.noarch requires /bin/sh bittorrent-gui-4.4.0-6.fc9.noarch requires /usr/bin/python blackbox-0.70.1-11.ppc requires /sbin/ldconfig blackbox-0.70.1-11.ppc requires /bin/sh blackbox-0.70.1-11.ppc64 requires /sbin/ldconfig blackbox-0.70.1-11.ppc64 requires /bin/sh blacs-1.1-26.fc9.1.ppc requires /sbin/ldconfig blacs-1.1-26.fc9.1.ppc64 requires /sbin/ldconfig blam-1.8.3-13.fc9.ppc requires /bin/sh blam-1.8.3-13.fc9.ppc requires /bin/bash blas-3.1.1-3.fc9.ppc requires /sbin/ldconfig blas-3.1.1-3.fc9.ppc64 requires /sbin/ldconfig blender-2.46-0.3.fc10.ppc requires /bin/sh blender-2.46-0.3.fc10.ppc requires /bin/sh bless-0.5.2-6.fc9.ppc requires /bin/sh bless-doc-0.5.2-6.fc9.ppc requires /bin/sh blitz-0.9-7.fc9.ppc requires /sbin/ldconfig blitz-0.9-7.fc9.ppc requires /sbin/install-info blitz-0.9-7.fc9.ppc64 requires /sbin/ldconfig blitz-0.9-7.fc9.ppc64 requires /sbin/install-info blitz-devel-0.9-7.fc9.ppc requires /bin/sh blitz-devel-0.9-7.fc9.ppc64 requires /bin/sh blktrace-0.0-0.9.20080103162505.fc9.ppc requires /bin/sh blobAndConquer-0.93-1.fc10.ppc requires /bin/sh blobby-0.6-0.7.a.fc8.ppc requires /bin/sh blobwars-1.07-2.fc9.ppc requires /bin/sh blogtk-1.1-9.fc9.noarch requires /usr/bin/env blogtk-1.1-9.fc9.noarch requires /bin/sh blt-2.4-27.fc9.ppc requires /sbin/ldconfig blt-2.4-27.fc9.ppc requires /usr/bin/wish blt-2.4-27.fc9.ppc requires /usr/bin/tclsh bluecurve-icon-theme-8.0.2-1.fc9.noarch requires /bin/sh bluefish-1.0.7-4.fc9.ppc requires /bin/sh bluez-gnome-0.25-1.fc9.ppc requires /bin/sh bluez-libs-3.31-1.fc10.ppc requires /sbin/ldconfig bluez-libs-3.31-1.fc10.ppc64 requires /sbin/ldconfig bluez-utils-3.31-1.fc10.ppc requires /bin/sh bluez-utils-3.31-1.fc10.ppc requires /sbin/service bluez-utils-3.31-1.fc10.ppc requires /bin/sh bluez-utils-3.31-1.fc10.ppc requires /sbin/chkconfig bmpx-0.40.13-11.fc9.ppc requires /bin/sh bmpx-0.40.13-11.fc9.ppc requires /bin/sh boa-0.94.14-0.10.rc21.fc9.ppc requires /bin/sh boa-0.94.14-0.10.rc21.fc9.ppc requires /bin/bash boa-0.94.14-0.10.rc21.fc9.ppc requires /etc/mime.types boa-0.94.14-0.10.rc21.fc9.ppc requires /sbin/chkconfig boa-0.94.14-0.10.rc21.fc9.ppc requires /usr/sbin/useradd boa-0.94.14-0.10.rc21.fc9.ppc requires /sbin/service bochs-dlxlinux-2.3.6-3.fc9.ppc requires /bin/sh bodhi-client-0.4.10-3.fc9.noarch requires /usr/bin/python bodhi-server-0.4.10-3.fc9.noarch requires /usr/bin/python bodhi-server-0.4.10-3.fc9.noarch requires /usr/bin/env bogl-0.1.18-14.ppc requires /sbin/ldconfig bogl-0.1.18-14.ppc64 requires /sbin/ldconfig bogl-devel-0.1.18-14.ppc requires /usr/bin/perl bogl-devel-0.1.18-14.ppc64 requires /usr/bin/perl bogofilter-1.1.6-2.fc9.ppc requires /usr/bin/perl bogofilter-1.1.6-2.fc9.ppc requires /bin/sh boinc-client-5.10.45-13.20080315svn.fc10.ppc requires /bin/sh boinc-client-5.10.45-13.20080315svn.fc10.ppc requires /bin/sh boinc-manager-5.10.45-13.20080315svn.fc10.ppc requires /bin/sh bolzplatz2006-1.0.3-6.fc9.ppc requires /bin/sh bolzplatz2006-1.0.3-6.fc9.ppc requires /bin/sh bombardier-0.8.2.2-8.fc9.ppc requires /bin/sh bonnie++-1.03a-9.fc9.ppc requires /usr/bin/perl bontmia-0.14-2.fc8.noarch requires /bin/bash boolstuff-0.1.11-5.fc9.ppc requires /sbin/ldconfig boolstuff-0.1.11-5.fc9.ppc64 requires /sbin/ldconfig boost-1.34.1-13.fc9.ppc requires /sbin/ldconfig boost-1.34.1-13.fc9.ppc64 requires /sbin/ldconfig bootchart-0.9-9.fc9.ppc requires /bin/sh bootchart-0.9-9.fc9.ppc requires /bin/sh bootparamd-0.17-27.fc9.ppc requires /bin/sh bootparamd-0.17-27.fc9.ppc requires /sbin/chkconfig bootparamd-0.17-27.fc9.ppc requires /bin/sh bootparamd-0.17-27.fc9.ppc requires /sbin/service boswars-2.5-1.fc9.ppc requires /bin/sh bouml-4.3.3-1.fc10.ppc requires /bin/sh bouml-4.3.3-1.fc10.ppc requires /bin/sh bouncycastle-1.39-1.fc10.ppc requires /bin/sh bpython-0.3.1-2.fc10.noarch requires /usr/bin/python brasero-0.7.1-4.fc10.ppc requires /bin/sh brazil-2.3-3.fc10.ppc requires /usr/bin/rebuild-gcj-db brazil-demo-2.3-3.fc10.ppc requires /usr/bin/tclsh brazil-demo-2.3-3.fc10.ppc requires /bin/sh brettfont-fonts-20080506-2.fc10.noarch requires /bin/sh brltty-3.9-2.2.fc9.ppc requires /bin/sh brltty-3.9-2.2.fc9.ppc requires /bin/bash brltty-3.9-2.2.fc9.ppc requires /bin/sh 1:broffice.org-base-3.0.0-0.0.12.1.fc10.ppc requires /bin/sh 1:broffice.org-base-3.0.0-0.0.12.1.fc10.ppc requires /bin/sh 1:broffice.org-brand-3.0.0-0.0.12.1.fc10.ppc requires /bin/sh 1:broffice.org-brand-3.0.0-0.0.12.1.fc10.ppc requires /bin/sh 1:broffice.org-calc-3.0.0-0.0.12.1.fc10.ppc requires /bin/sh 1:broffice.org-calc-3.0.0-0.0.12.1.fc10.ppc requires /bin/sh 1:broffice.org-draw-3.0.0-0.0.12.1.fc10.ppc requires /bin/sh 1:broffice.org-draw-3.0.0-0.0.12.1.fc10.ppc requires /bin/sh 1:broffice.org-impress-3.0.0-0.0.12.1.fc10.ppc requires /bin/sh 1:broffice.org-impress-3.0.0-0.0.12.1.fc10.ppc requires /bin/sh 1:broffice.org-math-3.0.0-0.0.12.1.fc10.ppc requires /bin/sh 1:broffice.org-math-3.0.0-0.0.12.1.fc10.ppc requires /bin/sh 1:broffice.org-writer-3.0.0-0.0.12.1.fc10.ppc requires /bin/sh 1:broffice.org-writer-3.0.0-0.0.12.1.fc10.ppc requires /bin/sh brutus-keyring-devel-0.9.0-6.fc8.ppc requires /sbin/ldconfig brutus-keyring-devel-0.9.0-6.fc8.ppc64 requires /sbin/ldconfig bsd-games-2.17-23.fc9.ppc requires /bin/sh bsd-games-2.17-23.fc9.ppc requires /bin/sh bsd-games-2.17-23.fc9.ppc requires /usr/sbin/groupadd bsf-2.3.0-12jpp.2.fc9.ppc requires /bin/sh bsh-1.3.0-12jpp.3.fc9.ppc requires /bin/sh bsh-demo-1.3.0-12jpp.3.fc9.ppc requires /usr/bin/env bsh-desktop-1.3.0-12jpp.3.fc9.ppc requires /bin/sh 1:bug-buddy-2.22.0-3.fc10.ppc requires /bin/sh 1:bug-buddy-2.22.0-3.fc10.ppc64 requires /bin/sh bugzilla-3.0.4-1.fc10.noarch requires /bin/sh bugzilla-3.0.4-1.fc10.noarch requires /bin/sh bugzilla-3.0.4-1.fc10.noarch requires /usr/bin/perl bugzilla-contrib-3.0.4-1.fc10.noarch requires /usr/bin/env bugzilla-contrib-3.0.4-1.fc10.noarch requires /usr/bin/python bugzilla-contrib-3.0.4-1.fc10.noarch requires /usr/bin/perl bugzilla-contrib-3.0.4-1.fc10.noarch requires /bin/sh bugzilla-contrib-3.0.4-1.fc10.noarch requires /usr/bin/ruby bugzilla-doc-3.0.4-1.fc10.noarch requires /usr/bin/perl buildbot-0.7.7-2.fc9.noarch requires /usr/bin/env buildbot-0.7.7-2.fc9.noarch requires /usr/bin/python buoh-0.8.2-4.fc9.ppc requires /bin/sh bwbar-1.2.3-2.ppc requires /bin/sh bwbar-1.2.3-2.ppc requires /bin/bash bwbar-1.2.3-2.ppc requires /sbin/service byzanz-0.1.1-6.fc9.ppc requires /bin/sh bzip2-1.0.5-1.fc9.ppc requires /bin/sh bzip2-libs-1.0.5-1.fc9.ppc requires /sbin/ldconfig bzip2-libs-1.0.5-1.fc9.ppc64 requires /sbin/ldconfig bzr-1.4-2.fc10.ppc requires /usr/bin/python bzr-gtk-0.94.0-1.fc10.ppc requires /usr/bin/python c-ares-1.5.1-2.fc9.ppc requires /sbin/ldconfig c-ares-1.5.1-2.fc9.ppc64 requires /sbin/ldconfig cachefilesd-0.7-4.fc9.ppc requires /bin/sh cachefilesd-0.7-4.fc9.ppc requires /bin/bash cachefilesd-0.7-4.fc9.ppc requires /sbin/chkconfig cachefilesd-0.7-4.fc9.ppc requires /sbin/service cacti-0.8.7b-1.fc9.noarch requires /bin/sh cacti-0.8.7b-1.fc9.noarch requires /usr/bin/perl cacti-0.8.7b-1.fc9.noarch requires /usr/sbin/useradd cacti-0.8.7b-1.fc9.noarch requires /usr/bin/php cacti-0.8.7b-1.fc9.noarch requires /bin/sh cacti-0.8.7b-1.fc9.noarch requires /sbin/service cairo-1.6.4-1.fc9.ppc requires /sbin/ldconfig cairo-1.6.4-1.fc9.ppc64 requires /sbin/ldconfig cairo-clock-0.3.4-1.fc9.ppc requires /sbin/ldconfig cairo-dock-1.5.5.4-4.date20080506.fc10.ppc requires /bin/sh cairo-dock-plug-ins-1.5.5.4-4.date20080506.fc10.ppc requires /bin/bash cairo-dock-plug-ins-1.5.5.4-4.date20080506.fc10.ppc requires /bin/sh cairo-java-1.0.5-9.fc9.ppc requires /sbin/ldconfig cairo-java-1.0.5-9.fc9.ppc64 requires /sbin/ldconfig cairomm-1.5.0-1.fc9.ppc requires /sbin/ldconfig cairomm-1.5.0-1.fc9.ppc64 requires /sbin/ldconfig cal3d-0.11.0-6.fc9.ppc requires /sbin/ldconfig cal3d-0.11.0-6.fc9.ppc64 requires /sbin/ldconfig calc-libs-2.12.2.1-12.fc9.ppc requires /sbin/ldconfig calc-libs-2.12.2.1-12.fc9.ppc64 requires /sbin/ldconfig calc-stdrc-2.12.2.1-12.fc9.ppc requires /usr/bin/calc callweaver-1.2-0.4.rc5.20071230.fc9.ppc requires /bin/sh callweaver-1.2-0.4.rc5.20071230.fc9.ppc requires /sbin/chkconfig callweaver-1.2-0.4.rc5.20071230.fc9.ppc requires /bin/bash callweaver-1.2-0.4.rc5.20071230.fc9.ppc requires /bin/sh callweaver-1.2-0.4.rc5.20071230.fc9.ppc64 requires /bin/sh callweaver-1.2-0.4.rc5.20071230.fc9.ppc64 requires /sbin/chkconfig callweaver-1.2-0.4.rc5.20071230.fc9.ppc64 requires /bin/bash callweaver-1.2-0.4.rc5.20071230.fc9.ppc64 requires /bin/sh callweaver-misdn-1.2-0.4.rc5.20071230.fc9.ppc requires /bin/sh callweaver-ogi-1.2-0.4.rc5.20071230.fc9.ppc requires /usr/bin/perl callweaver-zaptel-1.2-0.4.rc5.20071230.fc9.ppc requires /bin/sh castor-0.9.5-2jpp.8.fc9.ppc requires /bin/sh castor-0.9.5-2jpp.8.fc9.ppc requires /bin/sh castor-demo-0.9.5-2jpp.8.fc9.ppc requires /bin/sh castor-test-0.9.5-2jpp.8.fc9.ppc requires /bin/sh castor-xml-0.9.5-2jpp.8.fc9.ppc requires /bin/sh catdoc-0.94.2-4.fc9.ppc requires /usr/bin/wish catfish-0.3-1.fc8.noarch requires /usr/bin/locate catfish-0.3-1.fc8.noarch requires /usr/bin/env catfish-0.3-1.fc8.noarch requires /usr/bin/find ccache-2.4-13.fc9.ppc requires /bin/sh ccache-2.4-13.fc9.ppc requires /bin/sh ccid-1.2.1-4.fc9.ppc requires /bin/sh ccrtp-1.6.0-1.fc9.ppc requires /sbin/ldconfig ccrtp-1.6.0-1.fc9.ppc64 requires /sbin/ldconfig ccrtp-devel-1.6.0-1.fc9.ppc requires /bin/sh ccrtp-devel-1.6.0-1.fc9.ppc requires /sbin/install-info ccrtp-devel-1.6.0-1.fc9.ppc64 requires /bin/sh ccrtp-devel-1.6.0-1.fc9.ppc64 requires /sbin/install-info ccsm-0.7.2-1.fc9.noarch requires /bin/sh ccsm-0.7.2-1.fc9.noarch requires /usr/bin/python cdcollect-0.6.0-5.fc9.ppc requires /bin/sh cdcollect-0.6.0-5.fc9.ppc requires /bin/sh cdlabelgen-4.0.0-1.fc8.noarch requires /usr/bin/perl cdogs-data-0.4-3.fc8.noarch requires /bin/sh cdparanoia-libs-alpha9.8-30.ppc requires /bin/sh cdparanoia-libs-alpha9.8-30.ppc64 requires /bin/sh cduce-0.5.2.1-9.fc10.ppc requires /bin/sh cegui-0.5.0b-7.fc9.ppc requires /sbin/ldconfig cegui-0.5.0b-7.fc9.ppc64 requires /sbin/ldconfig celestia-1.5.0-1.fc9.ppc requires /bin/sh cellwriter-1.3.3-1.fc10.ppc requires /bin/sh 1:centerim-4.22.4-1.fc9.ppc requires /usr/bin/perl cernlib-2006-29.fc9.ppc requires /sbin/ldconfig cernlib-2006-29.fc9.ppc64 requires /sbin/ldconfig cernlib-g77-2006-29.fc9.ppc requires /sbin/ldconfig cernlib-g77-2006-29.fc9.ppc64 requires /sbin/ldconfig cernlib-g77-utils-2006-29.fc9.ppc requires /bin/bash cernlib-g77-utils-2006-29.fc9.ppc requires /bin/sh cernlib-packlib-2006-29.fc9.ppc requires /bin/sh cernlib-packlib-g77-2006-29.fc9.ppc requires /bin/sh cernlib-packlib-gfortran-2006-29.fc9.ppc requires /bin/sh cernlib-utils-2006-29.fc9.ppc requires /bin/bash cernlib-utils-2006-29.fc9.ppc requires /bin/sh certmaster-0.19-1.fc9.noarch requires /bin/sh certmaster-0.19-1.fc9.noarch requires /bin/sh certmaster-0.19-1.fc9.noarch requires /usr/bin/python cfengine-2.2.6-1.fc10.ppc requires /bin/sh cfengine-2.2.6-1.fc10.ppc requires /sbin/install-info cfengine-2.2.6-1.fc10.ppc requires /sbin/service cfengine-2.2.6-1.fc10.ppc requires /bin/bash cfengine-2.2.6-1.fc10.ppc requires /bin/sh cfengine-2.2.6-1.fc10.ppc requires /sbin/chkconfig cfitsio-3.060-3.fc9.ppc requires /sbin/ldconfig cfitsio-3.060-3.fc9.ppc64 requires /sbin/ldconfig cfv-1.18.1-4.fc8.1.noarch requires /usr/bin/env cgdb-0.6.4-3.fc9.ppc requires /bin/sh cgdb-0.6.4-3.fc9.ppc requires /sbin/install-info cgoban-1.9.14-9.fc9.ppc requires /bin/sh charis-fonts-4.100-5.fc9.noarch requires /bin/sh check-0.9.5-2.fc9.1.ppc requires /bin/sh check-0.9.5-2.fc9.1.ppc requires /sbin/ldconfig check-0.9.5-2.fc9.1.ppc requires /sbin/install-info check-0.9.5-2.fc9.1.ppc64 requires /bin/sh check-0.9.5-2.fc9.1.ppc64 requires /sbin/ldconfig check-0.9.5-2.fc9.1.ppc64 requires /sbin/install-info checkgmail-1.13-3.fc9.noarch requires /usr/bin/perl checkstyle-4.1-4jpp.3.fc9.noarch requires /bin/sh checkstyle-4.1-4jpp.3.fc9.noarch requires /usr/bin/perl checkstyle-optional-4.1-4jpp.3.fc9.noarch requires /bin/sh cheese-2.23.2-1.fc10.ppc requires /bin/sh cheese-2.23.2-1.fc10.ppc requires /bin/sh chemical-mime-data-0.1.94-3.fc8.noarch requires /bin/sh chemtool-1.6.11-3.fc9.ppc requires /bin/sh chess-1.0-14.fc10.ppc requires /bin/sh chess-1.0-14.fc10.ppc requires /usr/share/fonts/bitstream-vera/Vera.ttf childsplay-0.90.2-1.fc9.noarch requires /bin/sh childsplay-0.90.2-1.fc9.noarch requires /usr/bin/env childsplay-0.90.2-1.fc9.noarch requires /usr/bin/python chkrootkit-0.48-7.fc9.ppc requires /usr/bin/consolehelper chkrootkit-0.48-7.fc9.ppc requires /bin/sh chmlib-0.39-7.fc9.ppc requires /sbin/ldconfig chmlib-0.39-7.fc9.ppc64 requires /sbin/ldconfig chmsee-1.0.0-2.36.fc9.ppc requires /bin/sh cinepaint-0.22.1-7.fc9.ppc requires /bin/sh cinepaint-0.22.1-7.fc9.ppc requires /bin/sh cinepaint-devel-0.22.1-7.fc9.ppc requires /bin/sh cinepaint-devel-0.22.1-7.fc9.ppc64 requires /bin/sh cinepaint-libs-0.22.1-7.fc9.ppc requires /usr/bin/env cinepaint-libs-0.22.1-7.fc9.ppc requires /sbin/ldconfig cinepaint-libs-0.22.1-7.fc9.ppc64 requires /sbin/ldconfig cinepaint-libs-0.22.1-7.fc9.ppc64 requires /usr/bin/env cjkunifonts-ukai-0.1.20060928-4.fc8.noarch requires /bin/sh cjkunifonts-uming-0.1.20060928-4.fc8.noarch requires /bin/sh clamav-devel-0.93-1.fc9.ppc requires /bin/bash clamav-devel-0.93-1.fc9.ppc requires /usr/lib/pkgconfig clamav-devel-0.93-1.fc9.ppc requires /bin/sh clamav-devel-0.93-1.fc9.ppc64 requires /usr/lib64/pkgconfig clamav-devel-0.93-1.fc9.ppc64 requires /bin/bash clamav-devel-0.93-1.fc9.ppc64 requires /bin/sh clamav-filesystem-0.93-1.fc9.ppc requires /bin/sh clamav-lib-0.93-1.fc9.ppc requires /sbin/ldconfig clamav-lib-0.93-1.fc9.ppc64 requires /sbin/ldconfig clamav-milter-core-0.93-1.fc9.ppc requires /bin/sh clamav-milter-sysv-0.93-1.fc9.ppc requires /bin/sh clamav-milter-sysv-0.93-1.fc9.ppc requires /etc/rc.d/init.d clamav-milter-sysv-0.93-1.fc9.ppc requires /bin/sh clamav-server-0.93-1.fc9.ppc requires /bin/bash clamav-server-sysv-0.93-1.fc9.ppc requires /etc/rc.d/init.d clamav-update-0.93-1.fc9.ppc requires /bin/sh clamav-update-0.93-1.fc9.ppc requires /etc/cron.d clamav-update-0.93-1.fc9.ppc requires /bin/bash clamav-update-0.93-1.fc9.ppc requires /bin/chown clamav-update-0.93-1.fc9.ppc requires /bin/chmod clanbomber-1.05-8.fc9.ppc requires /bin/sh classads-1.0-1.fc9.ppc requires /sbin/ldconfig classads-1.0-1.fc9.ppc64 requires /sbin/ldconfig classpathx-jaf-1.0-11jpp.1.fc9.ppc requires /bin/sh classpathx-jaf-1.0-11jpp.1.fc9.ppc requires /usr/sbin/update-alternatives classpathx-jaf-1.0-11jpp.1.fc9.ppc requires /bin/sh classpathx-jaf-javadoc-1.0-11jpp.1.fc9.ppc requires /bin/rm classpathx-jaf-javadoc-1.0-11jpp.1.fc9.ppc requires /bin/ln classpathx-mail-1.1.1-5jpp.3.ppc requires /bin/sh classpathx-mail-1.1.1-5jpp.3.ppc requires /usr/sbin/update-alternatives classpathx-mail-1.1.1-5jpp.3.ppc requires /bin/sh classpathx-mail-javadoc-1.1.1-5jpp.3.ppc requires /bin/sh classpathx-mail-javadoc-1.1.1-5jpp.3.ppc requires /bin/ln classpathx-mail-javadoc-1.1.1-5jpp.3.ppc requires /bin/rm cleanfeed-0.95.7b-21.1.1.noarch requires /usr/bin/perl climm-0.6.2-1.fc9.ppc requires /bin/sh clips-libs-6.24-25.fc9.ppc requires /sbin/ldconfig clips-libs-6.24-25.fc9.ppc64 requires /sbin/ldconfig clipsmm-0.0.7-4.fc9.ppc requires /sbin/ldconfig clipsmm-0.0.7-4.fc9.ppc64 requires /sbin/ldconfig cln-1.2.2-1.fc10.ppc requires /sbin/ldconfig cln-1.2.2-1.fc10.ppc requires /sbin/install-info cln-1.2.2-1.fc10.ppc64 requires /sbin/ldconfig cln-1.2.2-1.fc10.ppc64 requires /sbin/install-info cln-devel-1.2.2-1.fc10.ppc requires /bin/sh cln-devel-1.2.2-1.fc10.ppc64 requires /bin/sh clonekeen-0.8.3-4.fc9.ppc requires /bin/sh clonekeen-0.8.3-4.fc9.ppc requires /bin/bash cloudy-libs-07.02.01-4.fc9.ppc requires /sbin/ldconfig cloudy-libs-07.02.01-4.fc9.ppc64 requires /sbin/ldconfig clusterssh-3.22-1.fc9.noarch requires /bin/sh clusterssh-3.22-1.fc9.noarch requires /usr/bin/perl clutter-0.6.0-1.fc9.ppc requires /sbin/ldconfig clutter-0.6.0-1.fc9.ppc64 requires /sbin/ldconfig clutter-gst-0.6.1-1.fc9.ppc requires /sbin/ldconfig clutter-gst-0.6.1-1.fc9.ppc64 requires /sbin/ldconfig clutter-gtk-0.6.0-1.fc9.ppc requires /sbin/ldconfig clutter-gtk-0.6.0-1.fc9.ppc64 requires /sbin/ldconfig cmake-gui-2.6.0-1.fc10.ppc requires /bin/sh cman-2.0.60-6.fc10.ppc requires /bin/sh cman-2.0.60-6.fc10.ppc requires /usr/bin/python cman-2.0.60-6.fc10.ppc requires /bin/bash cman-2.0.60-6.fc10.ppc requires /usr/bin/perl cman-2.0.60-6.fc10.ppc requires /sbin/chkconfig cman-2.0.60-6.fc10.ppc64 requires /bin/sh cman-2.0.60-6.fc10.ppc64 requires /usr/bin/python cman-2.0.60-6.fc10.ppc64 requires /bin/bash cman-2.0.60-6.fc10.ppc64 requires /usr/bin/perl cman-2.0.60-6.fc10.ppc64 requires /sbin/chkconfig cmigemo-1.3-0.6.c_MIT.fc9.2.ppc requires /sbin/ldconfig cmigemo-1.3-0.6.c_MIT.fc9.2.ppc64 requires /sbin/ldconfig coco-coq-0.1-3.fc8.noarch requires /bin/sh coco-coq-0.1-3.fc8.noarch requires /bin/bash coda-backup-6.9.3-1.fc10.ppc requires /usr/bin/perl coda-backup-6.9.3-1.fc10.ppc requires /bin/sh coda-client-6.9.3-1.fc10.ppc requires /bin/sh coda-client-6.9.3-1.fc10.ppc requires /usr/bin/python coda-client-6.9.3-1.fc10.ppc requires /usr/bin/perl coda-client-6.9.3-1.fc10.ppc requires /bin/sh coda-server-6.9.3-1.fc10.ppc requires /bin/sh coda-server-6.9.3-1.fc10.ppc requires /bin/sh codeblocks-8.02-1.fc9.ppc requires /bin/sh codeblocks-contrib-libs-8.02-1.fc9.ppc requires /sbin/ldconfig codeblocks-contrib-libs-8.02-1.fc9.ppc64 requires /sbin/ldconfig codeblocks-libs-8.02-1.fc9.ppc requires /sbin/ldconfig codeblocks-libs-8.02-1.fc9.ppc64 requires /sbin/ldconfig codeina-0.10.1-8.fc9.noarch requires /usr/bin/env codeina-0.10.1-8.fc9.noarch requires /bin/sh cogito-0.18.2-2.fc7.noarch requires /bin/bash cogito-0.18.2-2.fc7.noarch requires /usr/bin/env cohoba-0.0.4-5.fc7.noarch requires /bin/sh cohoba-0.0.4-5.fc7.noarch requires /usr/bin/env coldet-1.2-4.fc9.ppc requires /sbin/ldconfig coldet-1.2-4.fc9.ppc64 requires /sbin/ldconfig collectd-4.3.2-9.fc10.ppc requires /bin/sh collectd-4.3.2-9.fc10.ppc requires /bin/bash colordiff-1.0.7-2.fc9.noarch requires /usr/bin/perl colordiff-1.0.7-2.fc9.noarch requires /bin/sh comedilib-0.8.1-1.fc10.ppc requires /bin/sh comedilib-0.8.1-1.fc10.ppc requires /sbin/ldconfig comedilib-0.8.1-1.fc10.ppc64 requires /sbin/ldconfig comedilib-0.8.1-1.fc10.ppc64 requires /bin/sh comix-3.6.4-6.fc9.noarch requires /bin/sh comix-3.6.4-6.fc9.noarch requires /usr/bin/env comix-3.6.4-6.fc9.noarch requires /usr/bin/jpegtran commoncpp2-1.6.1-1.fc9.ppc requires /sbin/ldconfig commoncpp2-1.6.1-1.fc9.ppc64 requires /sbin/ldconfig commoncpp2-devel-1.6.1-1.fc9.ppc requires /bin/sh commoncpp2-devel-1.6.1-1.fc9.ppc requires /sbin/install-info commoncpp2-devel-1.6.1-1.fc9.ppc requires /bin/sh commoncpp2-devel-1.6.1-1.fc9.ppc64 requires /bin/sh commoncpp2-devel-1.6.1-1.fc9.ppc64 requires /sbin/install-info commoncpp2-devel-1.6.1-1.fc9.ppc64 requires /bin/sh compat-db-4.5.20-5.fc9.ppc requires /sbin/ldconfig compat-erlang-R10B-11.9.fc9.ppc requires /bin/sh compat-erlang-R10B-11.9.fc9.ppc requires /bin/sh compat-expat1-1.95.8-4.ppc requires /sbin/ldconfig compat-expat1-1.95.8-4.ppc64 requires /sbin/ldconfig compat-flex-2.5.4a-4.fc9.ppc requires /bin/sh compat-flex-2.5.4a-4.fc9.ppc requires /sbin/install-info compat-gcc-34-g77-3.4.6-9.ppc requires /bin/sh compat-gcc-34-g77-3.4.6-9.ppc requires /sbin/install-info compat-guichan05-0.5.0-8.fc9.ppc requires /sbin/ldconfig compat-guichan05-0.5.0-8.fc9.ppc64 requires /sbin/ldconfig compat-guile-16-1.6.7-8.fc9.ppc requires /sbin/ldconfig compat-guile-16-1.6.7-8.fc9.ppc requires /bin/sh compat-guile-16-1.6.7-8.fc9.ppc64 requires /sbin/ldconfig compat-guile-16-1.6.7-8.fc9.ppc64 requires /bin/sh compat-guile-16-devel-1.6.7-8.fc9.ppc requires /usr/bin/guile-1.6 compat-guile-16-devel-1.6.7-8.fc9.ppc requires /bin/sh compat-guile-16-devel-1.6.7-8.fc9.ppc64 requires /usr/bin/guile-1.6 compat-guile-16-devel-1.6.7-8.fc9.ppc64 requires /bin/sh compat-libf2c-34-3.4.6-9.ppc requires /sbin/ldconfig compat-libf2c-34-3.4.6-9.ppc64 requires /sbin/ldconfig compat-libgfortran-41-4.1.2-36.ppc requires /sbin/ldconfig compat-libgfortran-41-4.1.2-36.ppc64 requires /sbin/ldconfig compat-libosip2-2.2.2-16.fc9.ppc requires /sbin/ldconfig compat-libosip2-2.2.2-16.fc9.ppc64 requires /sbin/ldconfig compat-libstdc++-296-2.96-140.ppc requires /sbin/ldconfig compat-libstdc++-33-3.2.3-63.ppc requires /sbin/ldconfig compat-libstdc++-33-3.2.3-63.ppc64 requires /sbin/ldconfig compat-wxGTK26-2.6.4-2.ppc requires /sbin/ldconfig compat-wxGTK26-2.6.4-2.ppc64 requires /sbin/ldconfig compat-wxGTK26-devel-2.6.4-2.ppc requires /bin/sh compat-wxGTK26-devel-2.6.4-2.ppc64 requires /bin/sh compface-1.5.2-7.ppc requires /sbin/ldconfig compface-1.5.2-7.ppc64 requires /sbin/ldconfig compiz-0.7.2-4.fc10.ppc requires /sbin/ldconfig compiz-bcop-0.7.2-1.fc9.noarch requires /bin/bash compiz-fusion-extras-gnome-0.7.2-2.fc9.ppc requires /bin/sh compiz-fusion-gnome-0.7.2-2.fc9.ppc requires /bin/sh compiz-gnome-0.7.2-4.fc10.ppc requires /bin/sh compiz-kde-0.7.2-4.fc10.ppc requires /bin/sh compiz-kde-0.7.2-4.fc10.ppc requires /bin/sh compiz-manager-0.6.0-7.fc9.noarch requires /bin/sh concurrent-1.3.4-8jpp.1.fc9.ppc requires /bin/sh condor-7.0.0-8.fc9.ppc requires /bin/sh condor-7.0.0-8.fc9.ppc requires /usr/bin/env condor-7.0.0-8.fc9.ppc requires /sbin/service condor-7.0.0-8.fc9.ppc requires /bin/bash condor-7.0.0-8.fc9.ppc requires /bin/sh condor-7.0.0-8.fc9.ppc requires /usr/bin/perl condor-7.0.0-8.fc9.ppc requires /sbin/chkconfig conduit-0.3.8-1.fc9.noarch requires /bin/sh conduit-0.3.8-1.fc9.noarch requires /bin/bash conduit-0.3.8-1.fc9.noarch requires /usr/bin/env conduit-0.3.8-1.fc9.noarch requires /usr/bin/python cone-0.74-3.fc9.ppc requires /bin/sh cone-0.74-3.fc9.ppc requires /usr/bin/perl cone-0.74-3.fc9.ppc requires /usr/bin/perl cone-0.74-3.fc9.ppc requires /bin/sh conexus-0.5.3-4.fc9.ppc requires /sbin/ldconfig conexus-0.5.3-4.fc9.ppc64 requires /sbin/ldconfig conexusmm-0.5.0-3.fc7.ppc requires /sbin/ldconfig conexusmm-0.5.0-3.fc7.ppc64 requires /sbin/ldconfig conglomerate-0.9.1-5.fc9.ppc requires /bin/sh conman-0.2.1-1.fc10.ppc requires /bin/sh conman-0.2.1-1.fc10.ppc requires /usr/bin/env conman-0.2.1-1.fc10.ppc requires /sbin/service conman-0.2.1-1.fc10.ppc requires /usr/bin/expect conman-0.2.1-1.fc10.ppc requires /bin/sh conman-0.2.1-1.fc10.ppc requires /sbin/chkconfig conmux-0.0-7.493svn.fc10.noarch requires /bin/sh conmux-0.0-7.493svn.fc10.noarch requires /sbin/service conmux-0.0-7.493svn.fc10.noarch requires /usr/bin/expect conmux-0.0-7.493svn.fc10.noarch requires /usr/bin/perl conmux-0.0-7.493svn.fc10.noarch requires /bin/sh conmux-0.0-7.493svn.fc10.noarch requires /sbin/chkconfig conmux-client-0.0-7.493svn.fc10.noarch requires /usr/bin/perl conserver-8.1.16-5.fc9.ppc requires /bin/sh conserver-8.1.16-5.fc9.ppc requires /sbin/service conserver-8.1.16-5.fc9.ppc requires /bin/sh conserver-8.1.16-5.fc9.ppc requires /sbin/chkconfig conserver-client-8.1.16-5.fc9.ppc requires /bin/sh contacts-0.8-3.fc10.ppc requires /bin/sh 1:control-center-2.23.1-3.fc10.ppc requires /bin/sh 1:control-center-2.23.1-3.fc10.ppc requires /bin/sh 1:control-center-2.23.1-3.fc10.ppc64 requires /bin/sh 1:control-center-2.23.1-3.fc10.ppc64 requires /bin/sh convmv-1.12-1.fc9.noarch requires /usr/bin/perl cook-2.30-2.fc9.ppc requires /usr/bin/perl coolkey-1.1.0-6.fc9.ppc requires /bin/sh coolkey-1.1.0-6.fc9.ppc64 requires /bin/sh coreutils-6.11-2.fc10.ppc requires /bin/sh coreutils-6.11-2.fc10.ppc requires /sbin/install-info cowbell-0.2.7.1-10.fc10.ppc requires /bin/sh cowbell-0.2.7.1-10.fc10.ppc requires /bin/sh cowsay-3.03-4.fc8.noarch requires /usr/bin/perl cowsay-3.03-4.fc8.noarch requires /bin/sh cpan2rpm-2.028-2.fc8.1.noarch requires /usr/bin/perl cpanspec-1.75-1.fc10.noarch requires /usr/bin/repoquery cpanspec-1.75-1.fc10.noarch requires /usr/bin/perl cpanspec-1.75-1.fc10.noarch requires /bin/sh cpanspec-1.75-1.fc10.noarch requires /usr/bin/curl cpio-2.9-7.fc9.ppc requires /bin/sh cpio-2.9-7.fc9.ppc requires /sbin/install-info cpl-4.1.0-1.fc9.ppc requires /sbin/ldconfig cpl-4.1.0-1.fc9.ppc64 requires /sbin/ldconfig cpp-4.3.0-8.ppc requires /bin/sh cpp-4.3.0-8.ppc requires /sbin/install-info cppunit-1.12.0-5.fc9.ppc requires /sbin/ldconfig cppunit-1.12.0-5.fc9.ppc64 requires /sbin/ldconfig cppunit-devel-1.12.0-5.fc9.ppc requires /bin/sh cppunit-devel-1.12.0-5.fc9.ppc64 requires /bin/sh 1:cpufreq-utils-002-1.1.42.fc9.ppc requires /sbin/ldconfig 1:cpufreq-utils-002-1.1.42.fc9.ppc64 requires /sbin/ldconfig 1:cpuspeed-1.2.1-5.fc9.ppc requires /bin/sh 1:cpuspeed-1.2.1-5.fc9.ppc requires /sbin/chkconfig 1:cpuspeed-1.2.1-5.fc9.ppc requires /bin/sh 1:cpuspeed-1.2.1-5.fc9.ppc requires /sbin/service crack-5.0a-8.fc9.ppc requires /bin/sh crack-5.0a-8.fc9.ppc requires /bin/bash crack-5.0a-8.fc9.ppc requires /bin/sh crack-attack-1.1.14-13.fc9.ppc requires /bin/sh cracklib-2.8.12-2.ppc requires /sbin/ldconfig cracklib-2.8.12-2.ppc requires /sbin/ldconfig cracklib-2.8.12-2.ppc requires /bin/sh cracklib-2.8.12-2.ppc64 requires /sbin/ldconfig cracklib-2.8.12-2.ppc64 requires /sbin/ldconfig cracklib-2.8.12-2.ppc64 requires /bin/sh createrepo-0.9.5-2.fc9.noarch requires /usr/bin/python createrepo-0.9.5-2.fc9.noarch requires /bin/sh createrepo-0.9.5-2.fc9.noarch requires /usr/bin/env crm114-0-1.7.20070810.fc9.ppc requires /usr/bin/crm cronie-1.0-5.fc9.ppc requires /bin/sh cronie-1.0-5.fc9.ppc requires /sbin/service cronie-1.0-5.fc9.ppc requires /bin/bash cronie-1.0-5.fc9.ppc requires /bin/sh cronie-1.0-5.fc9.ppc requires /sbin/chkconfig cronolog-1.6.2-7.fc9.ppc requires /bin/sh cronolog-1.6.2-7.fc9.ppc requires /usr/bin/perl cronolog-1.6.2-7.fc9.ppc requires /sbin/install-info crontabs-1.10-21.fc10.noarch requires /bin/bash crossfire-1.10.0-4.fc9.ppc requires /bin/sh crossfire-1.10.0-4.fc9.ppc requires /sbin/service crossfire-1.10.0-4.fc9.ppc requires /bin/bash crossfire-1.10.0-4.fc9.ppc requires /bin/sh crossfire-1.10.0-4.fc9.ppc requires /usr/bin/perl crossfire-1.10.0-4.fc9.ppc requires /sbin/chkconfig crossfire-client-1.10.0-4.fc9.ppc requires /bin/sh crossfire-maps-1.10.0-3.fc8.noarch requires /bin/bash crossfire-maps-1.10.0-3.fc8.noarch requires /usr/bin/perl crossfire-selinux-1.10.0-4.fc9.ppc requires /usr/sbin/semodule crossfire-selinux-1.10.0-4.fc9.ppc requires /sbin/fixfiles crossfire-selinux-1.10.0-4.fc9.ppc requires /bin/sh crossfire-selinux-1.10.0-4.fc9.ppc requires /usr/sbin/semanage crossfire-selinux-1.10.0-4.fc9.ppc requires /sbin/service crossvc-1.5.2-4.fc9.ppc requires /bin/sh cryptix-3.2.0-10jpp.2.ppc requires /bin/sh cryptix-asn1-20011119-8jpp.3.ppc requires /bin/sh cryptix-javadoc-3.2.0-10jpp.2.ppc requires /bin/sh cryptix-javadoc-3.2.0-10jpp.2.ppc requires /bin/rm cryptix-javadoc-3.2.0-10jpp.2.ppc requires /bin/ln crypto-utils-2.3-10.ppc requires /bin/bash cryptsetup-luks-1.0.6-2.fc9.ppc requires /sbin/ldconfig cryptsetup-luks-1.0.6-2.fc9.ppc64 requires /sbin/ldconfig crystal-1.0.5-3.fc9.ppc requires /sbin/ldconfig crystal-stacker-1.5-6.fc9.ppc requires /bin/sh crystal-stacker-theme-editor-1.5-6.fc9.ppc requires /bin/sh crystalsvg-icon-theme-4.0.72-1.fc10.ppc requires /bin/sh cscope-15.6-1.fc9.ppc requires /bin/sh csmash-0.6.6-18.ppc requires /bin/sh csound-5.03.0-16.fc9.ppc requires /sbin/ldconfig csound-5.03.0-16.fc9.ppc64 requires /sbin/ldconfig csound-java-5.03.0-16.fc9.ppc requires /bin/sh csound-java-5.03.0-16.fc9.ppc requires /sbin/ldconfig csound-tk-5.03.0-16.fc9.ppc requires /usr/bin/wish csound-tk-5.03.0-16.fc9.ppc requires /usr/bin/perl ctapi-common-1.1-4.fc9.ppc requires /bin/sh ctapi-common-1.1-4.fc9.ppc64 requires /bin/sh ctapi-cyberjack-3.0.5-2.fc9.ppc requires /sbin/ldconfig ctapi-cyberjack-3.0.5-2.fc9.ppc requires /usr/lib/ctapi ctapi-cyberjack-3.0.5-2.fc9.ppc64 requires /sbin/ldconfig ctapi-cyberjack-3.0.5-2.fc9.ppc64 requires /usr/lib64/ctapi ctapi-cyberjack-pcsc-3.0.5-2.fc9.ppc requires /bin/sh ctapi-cyberjack-tools-3.0.5-2.fc9.ppc requires /bin/sh cuetools-1.4.0-0.2.svn305.fc10.ppc requires /sbin/ldconfig cuetools-1.4.0-0.2.svn305.fc10.ppc requires /bin/sh cuetools-1.4.0-0.2.svn305.fc10.ppc64 requires /sbin/ldconfig cuetools-1.4.0-0.2.svn305.fc10.ppc64 requires /bin/sh culmus-fonts-0.101-4.fc8.noarch requires /bin/sh 1:cups-1.3.7-2.fc10.ppc requires /bin/sh 1:cups-1.3.7-2.fc10.ppc requires /usr/sbin/alternatives 1:cups-1.3.7-2.fc10.ppc requires /sbin/service 1:cups-1.3.7-2.fc10.ppc requires /bin/bash 1:cups-1.3.7-2.fc10.ppc requires /bin/sh 1:cups-1.3.7-2.fc10.ppc requires /usr/bin/perl 1:cups-1.3.7-2.fc10.ppc requires /sbin/chkconfig 1:cups-devel-1.3.7-2.fc10.ppc requires /bin/sh 1:cups-devel-1.3.7-2.fc10.ppc64 requires /bin/sh 1:cups-libs-1.3.7-2.fc10.ppc requires /sbin/ldconfig 1:cups-libs-1.3.7-2.fc10.ppc64 requires /sbin/ldconfig cups-pdf-2.4.7-1.fc9.ppc requires /bin/sh curry-0.9.11-4.fc9.ppc requires /bin/sh cvs-1.11.22-13.fc9.ppc requires /bin/sh cvs-1.11.22-13.fc9.ppc requires /sbin/install-info cvs-1.11.22-13.fc9.ppc requires /usr/bin/perl cvs-1.11.22-13.fc9.ppc requires /bin/sh cvs2cl-2.67-1.fc8.noarch requires /usr/bin/perl cvs2svn-2.1.1-1.fc10.noarch requires /usr/bin/python cvsplot-1.7.4-6.fc8.noarch requires /usr/bin/perl cvsutils-0.2.3-6.fc8.noarch requires /usr/bin/perl cvsutils-0.2.3-6.fc8.noarch requires /bin/sh cvsweb-3.0.6-3.fc6.noarch requires /usr/bin/perl cwiid-0.6.00-7.fc10.ppc requires /sbin/ldconfig cwiid-0.6.00-7.fc10.ppc64 requires /sbin/ldconfig cwrite-0.1.24-2.fc9.ppc requires /bin/sh cwrite-0.1.24-2.fc9.ppc requires /sbin/install-info cycle-0.3.1-4.fc7.noarch requires /usr/bin/env cyphesis-0.5.15-6.fc9.ppc requires /sbin/service cyphesis-0.5.15-6.fc9.ppc requires /bin/sh cyphesis-0.5.15-6.fc9.ppc requires /sbin/chkconfig cyphesis-0.5.15-6.fc9.ppc requires /bin/sh cyphesis-selinux-0.5.15-6.fc9.ppc requires /usr/sbin/semodule cyphesis-selinux-0.5.15-6.fc9.ppc requires /sbin/fixfiles cyphesis-selinux-0.5.15-6.fc9.ppc requires /bin/sh cyphesis-selinux-0.5.15-6.fc9.ppc requires /usr/sbin/semanage cyphesis-selinux-0.5.15-6.fc9.ppc requires /usr/sbin/setsebool cyphesis-selinux-0.5.15-6.fc9.ppc requires /sbin/service cyrus-imapd-2.3.11-1.fc9.ppc requires /bin/sh cyrus-imapd-2.3.11-1.fc9.ppc requires /sbin/service cyrus-imapd-2.3.11-1.fc9.ppc requires /usr/bin/perl cyrus-imapd-2.3.11-1.fc9.ppc requires /bin/sh cyrus-imapd-2.3.11-1.fc9.ppc requires /sbin/chkconfig cyrus-imapd-perl-2.3.11-1.fc9.ppc requires /usr/bin/perl cyrus-imapd-utils-2.3.11-1.fc9.ppc requires /usr/sbin/userdel cyrus-imapd-utils-2.3.11-1.fc9.ppc requires /bin/sh cyrus-imapd-utils-2.3.11-1.fc9.ppc requires /usr/sbin/groupadd cyrus-imapd-utils-2.3.11-1.fc9.ppc requires /bin/sh cyrus-imapd-utils-2.3.11-1.fc9.ppc requires /usr/sbin/groupdel cyrus-imapd-utils-2.3.11-1.fc9.ppc requires /usr/sbin/useradd cyrus-sasl-2.1.22-13.fc9.ppc requires /bin/sh cyrus-sasl-2.1.22-13.fc9.ppc requires /sbin/service cyrus-sasl-2.1.22-13.fc9.ppc requires /bin/bash cyrus-sasl-lib-2.1.22-13.fc9.ppc requires /sbin/ldconfig cyrus-sasl-lib-2.1.22-13.fc9.ppc64 requires /sbin/ldconfig d-feet-0.1.8-1.fc9.noarch requires /bin/sh d-feet-0.1.8-1.fc9.noarch requires /usr/bin/python d4x-2.5.7.1-8.fc9.ppc requires /bin/sh dap-freeform_handler-3.7.7-2.fc9.ppc requires /sbin/ldconfig dap-freeform_handler-3.7.7-2.fc9.ppc requires /bin/sh dap-freeform_handler-3.7.7-2.fc9.ppc64 requires /sbin/ldconfig dap-freeform_handler-3.7.7-2.fc9.ppc64 requires /bin/sh dap-hdf4_handler-3.7.7-3.fc9.ppc requires /bin/sh dap-netcdf_handler-3.7.8-3.fc9.ppc requires /sbin/ldconfig dap-netcdf_handler-3.7.8-3.fc9.ppc requires /bin/sh dap-netcdf_handler-3.7.8-3.fc9.ppc64 requires /sbin/ldconfig dap-netcdf_handler-3.7.8-3.fc9.ppc64 requires /bin/sh dap-server-3.8.4-3.fc9.ppc requires /bin/sh dap-server-cgi-3.8.4-3.fc9.ppc requires /usr/bin/perl darcs-1.0.9-11.fc9.ppc requires /bin/sh darcs-server-1.0.9-11.fc9.ppc requires /usr/bin/xsltproc darcs-server-1.0.9-11.fc9.ppc requires /usr/bin/perl dasher-4.9.0-1.fc10.ppc requires /bin/sh dates-0.4.6-1.fc10.ppc requires /sbin/ldconfig dates-0.4.6-1.fc10.ppc requires /bin/sh dayplanner-0.8.1-3.fc9.noarch requires /bin/sh dayplanner-0.8.1-3.fc9.noarch requires /usr/bin/perl db4-4.6.21-5.fc9.ppc requires /sbin/ldconfig db4-4.6.21-5.fc9.ppc64 requires /sbin/ldconfig db4-java-4.6.21-5.fc9.ppc requires /sbin/ldconfig db4-tcl-4.6.21-5.fc9.ppc requires /sbin/ldconfig db4o-6.1-4.fc9.ppc requires /bin/sh 1:dbh-1.0.24-6.fc9.ppc requires /sbin/ldconfig 1:dbh-1.0.24-6.fc9.ppc64 requires /sbin/ldconfig dblatex-0.2.8-2.fc9.1.noarch requires /usr/bin/texhash dblatex-0.2.8-2.fc9.1.noarch requires /usr/bin/env dbmail-2.2.9-1.fc10.ppc requires /bin/sh dbmail-2.2.9-1.fc10.ppc requires /bin/bash dbmail-2.2.9-1.fc10.ppc requires /bin/sh dbus-1.2.1-3.fc10.ppc requires /bin/sh dbus-1.2.1-3.fc10.ppc requires /usr/sbin/useradd dbus-1.2.1-3.fc10.ppc requires /bin/sh dbus-glib-0.74-6.fc9.ppc requires /sbin/ldconfig dbus-glib-0.74-6.fc9.ppc64 requires /sbin/ldconfig dbus-libs-1.2.1-3.fc10.ppc requires /sbin/ldconfig dbus-libs-1.2.1-3.fc10.ppc64 requires /sbin/ldconfig dbus-qt-0.70-4.fc9.ppc requires /sbin/ldconfig dbus-qt-0.70-4.fc9.ppc64 requires /sbin/ldconfig dbus-qt3-0.8-5.fc9.ppc requires /sbin/ldconfig dbus-qt3-0.8-5.fc9.ppc64 requires /sbin/ldconfig dbus-x11-1.2.1-3.fc10.ppc requires /bin/sh dbxml-2.3.10-12.fc9.ppc requires /sbin/ldconfig dbxml-2.3.10-12.fc9.ppc64 requires /sbin/ldconfig dclib-0.3.11-4.fc9.ppc requires /sbin/ldconfig dclib-0.3.11-4.fc9.ppc64 requires /sbin/ldconfig dd2-0.2.2-3.fc9.ppc requires /bin/sh dd_rescue-1.14-7.fc9.ppc requires /bin/bash ddclient-3.7.3-1.fc9.noarch requires /bin/sh ddclient-3.7.3-1.fc9.noarch requires /usr/bin/perl ddclient-3.7.3-1.fc9.noarch requires /sbin/chkconfig ddclient-3.7.3-1.fc9.noarch requires /usr/sbin/groupadd ddclient-3.7.3-1.fc9.noarch requires /usr/sbin/useradd ddclient-3.7.3-1.fc9.noarch requires /bin/sh ddd-3.3.11-18.fc9.ppc requires /bin/sh ddd-3.3.11-18.fc9.ppc requires /sbin/install-info ddrescue-1.8-2.fc9.ppc requires /bin/sh ddrescue-1.8-2.fc9.ppc requires /sbin/install-info ddskk-12.2.0-11.fc7.noarch requires /bin/sh ddskk-12.2.0-11.fc7.noarch requires /sbin/install-info debootstrap-1.0.8-1.fc9.noarch requires /bin/sh 1:dejagnu-1.4.4-11.fc9.noarch requires /bin/sh 1:dejagnu-1.4.4-11.fc9.noarch requires /bin/sh dejavu-fonts-2.24-3.fc9.noarch requires /bin/sh dejavu-fonts-experimental-2.24-3.fc9.noarch requires /bin/sh dejavu-lgc-fonts-2.24-3.fc9.noarch requires /bin/sh deltarpm-3.4-10.fc9.ppc requires /usr/bin/perl deluge-0.5.9.0-1.fc10.ppc requires /bin/sh deluge-0.5.9.0-1.fc10.ppc requires /usr/bin/env deluge-0.5.9.0-1.fc10.ppc requires /usr/bin/python deluge-0.5.9.0-1.fc10.ppc requires /bin/bash deluge-0.5.9.0-1.fc10.ppc requires /bin/sh denyhosts-2.6-8.fc9.noarch requires /bin/sh denyhosts-2.6-8.fc9.noarch requires /bin/bash denyhosts-2.6-8.fc9.noarch requires /usr/bin/env denyhosts-2.6-8.fc9.noarch requires /bin/env denyhosts-2.6-8.fc9.noarch requires /bin/sh denyhosts-2.6-8.fc9.noarch requires /usr/bin/python deskbar-applet-2.23.2-1.fc10.ppc requires /bin/sh deskbar-applet-2.23.2-1.fc10.ppc requires /usr/bin/env desktop-data-model-1.2.4-1.fc10.ppc requires /sbin/ldconfig desktop-data-model-1.2.4-1.fc10.ppc requires /bin/sh desktop-data-model-1.2.4-1.fc10.ppc64 requires /bin/sh desktop-data-model-1.2.4-1.fc10.ppc64 requires /sbin/ldconfig desktop-file-utils-0.15-3.fc10.ppc requires /bin/sh devhelp-0.19-4.fc9.ppc requires /bin/sh devhelp-0.19-4.fc9.ppc64 requires /bin/sh device-mapper-libs-1.02.24-11.fc9.ppc requires /sbin/ldconfig device-mapper-libs-1.02.24-11.fc9.ppc64 requires /sbin/ldconfig device-mapper-multipath-0.4.7-15.fc10.ppc requires /bin/sh device-mapper-multipath-0.4.7-15.fc10.ppc requires /bin/bash dgae-1.1-3.fc8.noarch requires /bin/sh dgae-1.1-3.fc8.noarch requires /bin/bash 12:dhclient-4.0.0-15.fc10.ppc requires /bin/bash 12:dhcp-4.0.0-15.fc10.ppc requires /bin/sh 12:dhcp-4.0.0-15.fc10.ppc requires /bin/sh dhcp-forwarder-0.7-14.fc9.ppc requires /bin/sh dhcp-forwarder-sysv-0.7-14.fc9.ppc requires /bin/sh dhcp-forwarder-sysv-0.7-14.fc9.ppc requires /bin/bash dhcp-forwarder-sysv-0.7-14.fc9.ppc requires /sbin/chkconfig dhcpv6-1.0.15-1.fc10.ppc requires /bin/sh dhcpv6-1.0.15-1.fc10.ppc requires /bin/sh 1:dia-0.96.1-6.fc10.ppc requires /usr/bin/env 1:dia-0.96.1-6.fc10.ppc requires /bin/sh dialog-1.1-5.20080316.fc10.ppc requires /sbin/ldconfig dialog-1.1-5.20080316.fc10.ppc64 requires /sbin/ldconfig dialog-devel-1.1-5.20080316.fc10.ppc requires /bin/sh dialog-devel-1.1-5.20080316.fc10.ppc64 requires /bin/sh dictd-1.10.11-2.ppc requires /bin/sh dictd-1.10.11-2.ppc requires /bin/sh diffutils-2.8.1-21.fc9.ppc requires /bin/sh diffutils-2.8.1-21.fc9.ppc requires /sbin/install-info digikam-0.9.4-0.1.beta4.fc10.ppc requires /bin/sh digikam-0.9.4-0.1.beta4.fc10.ppc requires /usr/bin/perl digikam-0.9.4-0.1.beta4.fc10.ppc requires /bin/sh digikam-0.9.4-0.1.beta4.fc10.ppc64 requires /bin/sh digikam-0.9.4-0.1.beta4.fc10.ppc64 requires /usr/bin/perl digikam-0.9.4-0.1.beta4.fc10.ppc64 requires /bin/sh dillo-0.8.6-7.fc9.ppc requires /usr/bin/perl dirac-0.9.1-2.fc9.ppc requires /usr/bin/perl dirac-libs-0.9.1-2.fc9.ppc requires /sbin/ldconfig dirac-libs-0.9.1-2.fc9.ppc64 requires /sbin/ldconfig dircproxy-1.2.0-0.7.beta2.fc9.ppc requires /bin/sh dircproxy-1.2.0-0.7.beta2.fc9.ppc requires /usr/bin/perl dircproxy-1.2.0-0.7.beta2.fc9.ppc requires /bin/sh directfb-1.0.0-4.fc9.ppc requires /sbin/ldconfig directfb-1.0.0-4.fc9.ppc64 requires /sbin/ldconfig directfb-devel-1.0.0-4.fc9.ppc requires /bin/sh directfb-devel-1.0.0-4.fc9.ppc64 requires /bin/sh dirmngr-1.0.1-2.fc9.ppc requires /bin/sh dirmngr-1.0.1-2.fc9.ppc requires /sbin/install-info dirvish-1.2.1-2.fc6.noarch requires /usr/bin/perl distcache-1.4.5-17.ppc requires /bin/sh distcache-1.4.5-17.ppc requires /sbin/service distcache-1.4.5-17.ppc requires /sbin/ldconfig distcache-1.4.5-17.ppc requires /bin/bash distcache-1.4.5-17.ppc requires /sbin/chkconfig distcache-1.4.5-17.ppc64 requires /bin/sh distcache-1.4.5-17.ppc64 requires /sbin/ldconfig distcache-1.4.5-17.ppc64 requires /bin/bash distcache-1.4.5-17.ppc64 requires /sbin/chkconfig distcache-1.4.5-17.ppc64 requires /sbin/service distcc-2.18.3-4.fc9.ppc requires /bin/sh distcc-server-2.18.3-4.fc9.ppc requires /sbin/chkconfig distcc-server-2.18.3-4.fc9.ppc requires /bin/sh distcc-server-2.18.3-4.fc9.ppc requires /bin/sh djvulibre-3.5.20-2.fc9.ppc requires /bin/sh djvulibre-3.5.20-2.fc9.ppc requires /sbin/ldconfig djvulibre-3.5.20-2.fc9.ppc requires /bin/bash djvulibre-3.5.20-2.fc9.ppc requires /bin/sh djvulibre-libs-3.5.20-2.fc9.ppc requires /sbin/ldconfig djvulibre-libs-3.5.20-2.fc9.ppc64 requires /sbin/ldconfig dkim-milter-2.5.1-5.fc9.ppc requires /bin/sh dkim-milter-2.5.1-5.fc9.ppc requires /sbin/service dkim-milter-2.5.1-5.fc9.ppc requires /bin/bash dkim-milter-2.5.1-5.fc9.ppc requires /bin/sh dkim-milter-2.5.1-5.fc9.ppc requires /sbin/chkconfig dkms-2.0.19-1.fc9.noarch requires /bin/sh dkms-2.0.19-1.fc9.noarch requires /bin/bash dkms-2.0.19-1.fc9.noarch requires /bin/sh dmraid-1.0.0.rc14-6.fc9.ppc requires /sbin/ldconfig dmraid-1.0.0.rc14-6.fc9.ppc64 requires /sbin/ldconfig dnsmasq-2.41-0.8.fc9.ppc requires /bin/sh dnsmasq-2.41-0.8.fc9.ppc requires /bin/sed dnsmasq-2.41-0.8.fc9.ppc requires /sbin/chkconfig dnsmasq-2.41-0.8.fc9.ppc requires /bin/grep dnsmasq-2.41-0.8.fc9.ppc requires /bin/sh dnsmasq-2.41-0.8.fc9.ppc requires /sbin/service dnssec-tools-1.3.2-2.fc9.ppc requires /usr/bin/perl dnssec-tools-libs-1.3.2-2.fc9.ppc requires /sbin/ldconfig dnssec-tools-libs-1.3.2-2.fc9.ppc64 requires /sbin/ldconfig dnssec-tools-libs-devel-1.3.2-2.fc9.ppc requires /bin/sh dnssec-tools-libs-devel-1.3.2-2.fc9.ppc64 requires /bin/sh docbook-dtds-1.0-36.fc10.noarch requires /bin/sh docbook-simple-1.1-3.fc9.noarch requires /bin/sh docbook-slides-3.4.0-3.fc9.noarch requires /bin/sh docbook-style-dsssl-1.79-5.fc9.noarch requires /bin/sh docbook-style-dsssl-1.79-5.fc9.noarch requires /usr/bin/perl docbook-style-xsl-1.73.2-9.fc9.noarch requires /bin/sh docbook-utils-0.6.14-13.fc9.noarch requires /usr/bin/perl docbook-utils-0.6.14-13.fc9.noarch requires /bin/sh docbook-utils-pdf-0.6.14-13.fc9.noarch requires /bin/sh docbook2X-0.8.8-3.fc9.ppc requires /bin/sh docbook2X-0.8.8-3.fc9.ppc requires /sbin/install-info docbook2X-0.8.8-3.fc9.ppc requires /usr/bin/sgml2xml docbook2X-0.8.8-3.fc9.ppc requires /usr/bin/perl docbook2X-0.8.8-3.fc9.ppc requires /bin/sh dogtail-0.6.90-1.381.fc9.noarch requires /bin/sh dogtail-0.6.90-1.381.fc9.noarch requires /usr/bin/python dom4j-demo-1.6.1-2jpp.3.fc8.noarch requires /bin/sh doodle-0.6.7-2.fc9.ppc requires /sbin/ldconfig doodle-0.6.7-2.fc9.ppc64 requires /sbin/ldconfig dot2tex-2.7.0-4.fc9.noarch requires /usr/bin/python dotconf-1.0.13-6.fc9.ppc requires /sbin/ldconfig dotconf-1.0.13-6.fc9.ppc64 requires /sbin/ldconfig dotconf-devel-1.0.13-6.fc9.ppc requires /bin/sh dotconf-devel-1.0.13-6.fc9.ppc64 requires /bin/sh doulos-fonts-4.100-1.fc9.noarch requires /bin/sh 1:dovecot-1.0.13-6.fc9.ppc requires /usr/sbin/userdel 1:dovecot-1.0.13-6.fc9.ppc requires /bin/sh 1:dovecot-1.0.13-6.fc9.ppc requires /usr/sbin/useradd 1:dovecot-1.0.13-6.fc9.ppc requires /sbin/service 1:dovecot-1.0.13-6.fc9.ppc requires /bin/touch 1:dovecot-1.0.13-6.fc9.ppc requires /bin/mv 1:dovecot-1.0.13-6.fc9.ppc requires /bin/bash 1:dovecot-1.0.13-6.fc9.ppc requires /bin/sh 1:dovecot-1.0.13-6.fc9.ppc requires /usr/sbin/groupdel 1:dovecot-1.0.13-6.fc9.ppc requires /sbin/chkconfig 1:dovecot-1.0.13-6.fc9.ppc requires /bin/rm drawtiming-0.6.2-3.fc9.ppc requires libMagick++.so.10 drawtiming-0.6.2-3.fc9.ppc requires libWand.so.10 drawtiming-0.6.2-3.fc9.ppc requires libMagick.so.10 drgeo-1.1.0-12.fc9.ppc requires /bin/bash driconf-0.9.1-7.fc9.noarch requires /usr/bin/python driftnet-0.1.6-16.20040426cvs.fc9.ppc requires /usr/bin/consolehelper drivel-2.1.1-0.5.20071130svn.fc9.ppc requires /bin/sh dropbear-0.50-3.fc9.ppc requires /bin/sh dropbear-0.50-3.fc9.ppc requires /bin/bash dropbear-0.50-3.fc9.ppc requires /sbin/service 1:drpython-3.11.0-2.fc9.noarch requires /bin/bash 1:drpython-3.11.0-2.fc9.noarch requires /usr/bin/env 1:drpython-3.11.0-2.fc9.noarch requires /bin/sh 1:drpython-3.11.0-2.fc9.noarch requires /usr/bin/python ds9-5.1-4.fc9.ppc requires /bin/sh dstat-0.6.7-3.fc10.noarch requires /usr/bin/env dtdparser-1.21-4jpp.2.fc9.ppc requires /bin/sh duel3-0.1-0.5.20060225.fc9.ppc requires /bin/sh dumb-0.9.3-7.fc9.ppc requires /sbin/ldconfig dumb-0.9.3-7.fc9.ppc64 requires /sbin/ldconfig duplicity-0.4.11-1.fc10.ppc requires /usr/bin/python dvdauthor-0.6.14-5.fc9.ppc requires /bin/sh dvipdfm-0.13.2d-38.fc10.ppc requires /bin/sh dvipdfm-0.13.2d-38.fc10.ppc requires /bin/sh dvipdfm-0.13.2d-38.fc10.ppc requires /usr/bin/mktexlsr dvipdfmx-0-0.20.20071115cvs.fc9.ppc requires /bin/sh dvipdfmx-0-0.20.20071115cvs.fc9.ppc requires /usr/bin/mktexlsr dvipng-1.9-50.fc9.ppc requires /bin/sh dvipng-1.9-50.fc9.ppc requires /sbin/install-info dwarves-1.6-1.ppc requires /usr/bin/python dx-4.4.4-6.fc9.ppc requires /bin/sh dx-4.4.4-6.fc9.ppc requires libWand.so.10 dx-4.4.4-6.fc9.ppc requires libMagick.so.10 dx-libs-4.4.4-6.fc9.ppc requires /sbin/ldconfig dx-libs-4.4.4-6.fc9.ppc requires libWand.so.10 dx-libs-4.4.4-6.fc9.ppc requires libMagick.so.10 dx-libs-4.4.4-6.fc9.ppc64 requires libMagick.so.10()(64bit) dx-libs-4.4.4-6.fc9.ppc64 requires libWand.so.10()(64bit) dx-libs-4.4.4-6.fc9.ppc64 requires /sbin/ldconfig dxcc-20080225-4.fc9.noarch requires /usr/bin/perl dxcc-gui-20080225-4.fc9.noarch requires /bin/bash dxpc-3.9.1-0.3.b1.fc9.ppc requires /bin/bash dynamite-0.1-9.fc9.ppc requires /sbin/ldconfig dynamite-0.1-9.fc9.ppc64 requires /sbin/ldconfig e16-0.16.8.13-2.fc10.ppc requires /usr/bin/perl e16-0.16.8.13-2.fc10.ppc requires /bin/sh e16-epplets-0.10-3.fc10.ppc requires /sbin/ldconfig e16-epplets-0.10-3.fc10.ppc64 requires /sbin/ldconfig e16-themes-0.16.8.0.2-1.fc10.noarch requires /bin/sh e2fsprogs-1.40.9-2.fc10.ppc requires /bin/sh e2fsprogs-devel-1.40.9-2.fc10.ppc requires /bin/sh e2fsprogs-devel-1.40.9-2.fc10.ppc requires /sbin/install-info e2fsprogs-devel-1.40.9-2.fc10.ppc requires /bin/sh e2fsprogs-devel-1.40.9-2.fc10.ppc64 requires /bin/sh e2fsprogs-devel-1.40.9-2.fc10.ppc64 requires /sbin/install-info e2fsprogs-devel-1.40.9-2.fc10.ppc64 requires /bin/sh e2fsprogs-libs-1.40.9-2.fc10.ppc requires /sbin/ldconfig e2fsprogs-libs-1.40.9-2.fc10.ppc64 requires /sbin/ldconfig eb-4.3.2-1.fc9.ppc requires /sbin/ldconfig eb-4.3.2-1.fc9.ppc requires /usr/bin/perl eb-4.3.2-1.fc9.ppc64 requires /sbin/ldconfig eb-4.3.2-1.fc9.ppc64 requires /usr/bin/perl eblook-1.6.1-3.fc9.ppc requires /bin/sh ebtables-2.0.8-5.fc9.ppc requires /bin/sh ebtables-2.0.8-5.fc9.ppc requires /sbin/service ebtables-2.0.8-5.fc9.ppc requires /bin/bash ebtables-2.0.8-5.fc9.ppc requires /usr/bin/perl ebtables-2.0.8-5.fc9.ppc requires /sbin/chkconfig echo-icon-theme-0.3.89.0-0.1.git51c57605.fc10.noarch requires /bin/sh ecl-0.9j-2.fc9.ppc requires /bin/sh ecl-0.9j-2.fc9.ppc requires /bin/sh 1:eclipse-cdt-4.0.3-1.fc9.ppc requires /bin/sh 1:eclipse-changelog-2.6.1-3.fc9.ppc requires /usr/bin/rebuild-gcj-db eclipse-checkstyle-4.0.1-10.fc9.ppc requires /bin/sh 1:eclipse-ecj-3.3.2-11.fc9.ppc requires /usr/bin/rebuild-gcj-db 1:eclipse-ecj-3.3.2-11.fc9.ppc requires /bin/sh eclipse-egit-0.3.1-0.fc9.ppc requires /usr/bin/rebuild-gcj-db eclipse-epic-0.6.23-1.fc9.ppc requires /usr/bin/rebuild-gcj-db eclipse-gef-3.3.0-2.fc9.ppc requires /usr/bin/rebuild-gcj-db 1:eclipse-jdt-3.3.2-11.fc9.ppc requires /usr/bin/rebuild-gcj-db 1:eclipse-jdt-3.3.2-11.fc9.ppc requires /bin/sh eclipse-mylyn-2.3.2-4.fc9.ppc requires /bin/sh eclipse-mylyn-bugzilla-2.3.2-4.fc9.ppc requires /bin/sh eclipse-mylyn-ide-2.3.2-4.fc9.ppc requires /bin/sh eclipse-mylyn-java-2.3.2-4.fc9.ppc requires /bin/sh eclipse-mylyn-trac-2.3.2-4.fc9.ppc requires /bin/sh 1:eclipse-pde-3.3.2-11.fc9.ppc requires /usr/bin/rebuild-gcj-db 1:eclipse-pde-3.3.2-11.fc9.ppc requires /bin/bash 1:eclipse-pde-runtime-3.3.2-11.fc9.ppc requires /usr/bin/rebuild-gcj-db eclipse-photran-4.0-1.b3.fc9.1.ppc requires /usr/bin/rebuild-gcj-db eclipse-phpeclipse-1.1.8-18.fc9.ppc requires /usr/bin/rebuild-gcj-db 1:eclipse-platform-3.3.2-11.fc9.ppc requires /bin/sh 1:eclipse-platform-3.3.2-11.fc9.ppc requires /usr/lib/eclipse/plugins/org.eclipse.swt.gtk.linux.ppc_3.3.2.v3349.jar 1:eclipse-pydev-1.3.14-1.fc9.ppc requires /usr/bin/rebuild-gcj-db eclipse-quickrex-3.5.0-7.fc9.ppc requires /bin/sh 1:eclipse-rcp-3.3.2-11.fc9.ppc requires /usr/lib/eclipse/plugins/org.eclipse.swt.gtk.linux.ppc_3.3.2.v3349.jar 1:eclipse-rcp-3.3.2-11.fc9.ppc requires /usr/bin/rebuild-gcj-db eclipse-rpm-editor-0.2.1-3.fc9.ppc requires /bin/sh eclipse-setools-3.3.2.4-1.fc9.ppc requires /bin/sh eclipse-slide-1.3.8-1.fc9.noarch requires /bin/sh eclipse-subclipse-1.2.4-9.fc9.ppc requires /usr/bin/rebuild-gcj-db ecore-0.9.9.042-3.fc10.ppc requires /sbin/ldconfig ecore-0.9.9.042-3.fc10.ppc64 requires /sbin/ldconfig ecryptfs-utils-40-0.fc9.ppc requires /sbin/ldconfig ecryptfs-utils-40-0.fc9.ppc64 requires /sbin/ldconfig ed-0.8-2.fc9.ppc requires /bin/sh ed-0.8-2.fc9.ppc requires /sbin/install-info ed2k_hash-gui-0.4.0-7.fc9.ppc requires /bin/sh edje-0.5.0.042-3.fc10.ppc requires /sbin/ldconfig edje-0.5.0.042-3.fc10.ppc requires /bin/sh edje-0.5.0.042-3.fc10.ppc64 requires /sbin/ldconfig edje-0.5.0.042-3.fc10.ppc64 requires /bin/sh edrip-fonts-20080330-1.fc9.noarch requires /bin/sh edsadmin-1.0-2.fc9.noarch requires /bin/sh eel2-2.23.1-1.fc10.ppc requires /sbin/ldconfig eel2-2.23.1-1.fc10.ppc64 requires /sbin/ldconfig eet-1.0.0-1.fc10.ppc requires /sbin/ldconfig eet-1.0.0-1.fc10.ppc64 requires /sbin/ldconfig efax-0.9a-1.001114.fc9.ppc requires /bin/sh efont-unicode-bdf-0.4.2-7.fc8.noarch requires /bin/sh efreet-0.0.3.042-3.fc10.ppc requires /sbin/ldconfig efreet-0.0.3.042-3.fc10.ppc64 requires /sbin/ldconfig egd-0.9-2.fc9.noarch requires /usr/bin/perl eggdrop-1.6.19-1.fc10.ppc requires /bin/sh egoboo-2.7.5-4.fc9.ppc requires /bin/sh egoboo-data-2.7.5-1.fc9.noarch requires /bin/sh ejabberd-2.0.0-1.fc9.ppc requires /bin/sh ejabberd-2.0.0-1.fc9.ppc requires /bin/bash ejabberd-2.0.0-1.fc9.ppc requires /sbin/chkconfig ejabberd-2.0.0-1.fc9.ppc requires /bin/sh ejabberd-2.0.0-1.fc9.ppc requires /sbin/service ekg-1.7-6.fc9.ppc requires /usr/bin/luit ekg-1.7-6.fc9.ppc requires /usr/bin/perl ekg-1.7-6.fc9.ppc requires /bin/sh ekg2-devel-0.1.1-4.fc9.ppc requires /bin/sh ekg2-devel-0.1.1-4.fc9.ppc64 requires /bin/sh ekiga-2.0.12-2.fc10.ppc requires /bin/sh ekiga-2.0.12-2.fc10.ppc requires /bin/sh ekiga-2.0.12-2.fc10.ppc requires /usr/bin/scrollkeeper-update electronics-menu-1.0-1.fc9.noarch requires /bin/sh elektra-0.6.10-6.fc9.ppc requires /bin/sh elektra-0.6.10-6.fc9.ppc requires /sbin/service elektra-0.6.10-6.fc9.ppc requires /sbin/ldconfig elektra-0.6.10-6.fc9.ppc requires /bin/bash elektra-0.6.10-6.fc9.ppc requires /sbin/chkconfig elektra-0.6.10-6.fc9.ppc64 requires /bin/sh elektra-0.6.10-6.fc9.ppc64 requires /sbin/service elektra-0.6.10-6.fc9.ppc64 requires /sbin/ldconfig elektra-0.6.10-6.fc9.ppc64 requires /bin/bash elektra-0.6.10-6.fc9.ppc64 requires /sbin/chkconfig elfutils-0.135-1.fc10.ppc requires /bin/sh elfutils-libelf-0.135-1.fc10.ppc requires /sbin/ldconfig elfutils-libelf-0.135-1.fc10.ppc64 requires /sbin/ldconfig elfutils-libs-0.135-1.fc10.ppc requires /sbin/ldconfig elfutils-libs-0.135-1.fc10.ppc64 requires /sbin/ldconfig elisa-0.3.2-1.fc8.noarch requires /usr/bin/python elsa-1.4-3.fc9.ppc requires /usr/bin/env elsa-1.4-3.fc9.ppc requires /bin/sh em8300-0.16.4-1.fc9.ppc requires /bin/sh em8300-0.16.4-1.fc9.ppc requires /etc/security/console.perms.d em8300-0.16.4-1.fc9.ppc requires /etc/alsa/cards em8300-devel-0.16.4-1.fc9.ppc requires /usr/bin/perl em8300-devel-0.16.4-1.fc9.ppc64 requires /usr/bin/perl em8300-utils-0.16.4-1.fc9.ppc requires /usr/bin/perl 1:emacs-22.2-4.fc9.ppc requires /bin/sh 1:emacs-22.2-4.fc9.ppc requires /bin/sh emacs-auctex-11.85-7.fc9.noarch requires /bin/sh emacs-auctex-11.85-7.fc9.noarch requires /sbin/install-info emacs-bbdb-2.35-8.fc8.noarch requires /bin/sh 1:emacs-common-22.2-4.fc9.ppc requires /bin/sh 1:emacs-common-22.2-4.fc9.ppc requires /usr/bin/perl 1:emacs-common-22.2-4.fc9.ppc requires /usr/sbin/alternatives 1:emacs-common-22.2-4.fc9.ppc requires /sbin/install-info 1:emacs-common-22.2-4.fc9.ppc requires /bin/sh emacs-common-ebib-1.5.2-3.fc9.noarch requires /bin/sh emacs-common-ebib-1.5.2-3.fc9.noarch requires /sbin/install-info emacs-common-ess-5.3.7-1.fc10.noarch requires /bin/sh emacs-common-ess-5.3.7-1.fc10.noarch requires /sbin/install-info emacs-common-muse-3.12-1.fc9.noarch requires /bin/sh emacs-common-muse-3.12-1.fc9.noarch requires /sbin/install-info emacs-ess-5.3.7-1.fc10.noarch requires /bin/sh 1:emacs-nox-22.2-4.fc9.ppc requires /bin/sh 1:emacs-nox-22.2-4.fc9.ppc requires /bin/sh emacs-nxml-mode-0.20041004-6.fc8.noarch requires /bin/sh emacs-vm-8.0.9.544-1.fc9.ppc requires /bin/sh emacs-vm-8.0.9.544-1.fc9.ppc requires /sbin/install-info emacspeak-26-3.fc8.noarch requires /bin/sh emacspeak-26-3.fc8.noarch requires /usr/bin/perl emacspeak-26-3.fc8.noarch requires /usr/bin/tclsh emacspeak-26-3.fc8.noarch requires /bin/sh embryo-0.9.1.042-5.fc10.ppc requires /sbin/ldconfig embryo-0.9.1.042-5.fc10.ppc64 requires /sbin/ldconfig emerald-0.5.2-4.fc9.ppc requires /bin/sh emesene-1.0-1.fc9.noarch requires /usr/bin/env empathy-0.23.2-1.fc10.ppc requires /bin/sh empathy-libs-0.23.2-1.fc10.ppc requires /sbin/ldconfig empathy-libs-0.23.2-1.fc10.ppc64 requires /sbin/ldconfig enca-1.9-4.fc9.ppc requires /sbin/ldconfig enca-1.9-4.fc9.ppc64 requires /sbin/ldconfig 1:enchant-1.3.0-4.fc10.ppc requires /sbin/ldconfig 1:enchant-1.3.0-4.fc10.ppc64 requires /sbin/ldconfig enemies-of-carlotta-1.2.4-1.fc7.noarch requires /usr/bin/python enet-1.1-3.fc9.ppc requires /sbin/ldconfig enet-1.1-3.fc9.ppc64 requires /sbin/ldconfig enigma-1.01-6.2.ppc requires /bin/sh enscript-1.6.4-9.fc9.ppc requires /bin/sh enscript-1.6.4-9.fc9.ppc requires /usr/bin/perl enscript-1.6.4-9.fc9.ppc requires /sbin/install-info enscript-1.6.4-9.fc9.ppc requires /bin/sh environment-modules-3.2.6-5.fc9.ppc requires /bin/sh eog-2.23.2-1.fc10.ppc requires /bin/sh epdfview-0.1.6-3.fc9.ppc requires /bin/sh epeg-0.9.1.042-4.fc10.ppc requires /sbin/ldconfig epeg-0.9.1.042-4.fc10.ppc64 requires /sbin/ldconfig epiphany-2.22.1.1-1.fc9.ppc requires /bin/sh epiphany-extensions-2.22.1-1.fc9.ppc requires /bin/sh epydoc-3.0.1-1.fc9.noarch requires /usr/bin/python epylog-1.0.3-7.fc9.noarch requires /bin/sh epylog-1.0.3-7.fc9.noarch requires /usr/bin/python eric-4.1.2-2.fc9.noarch requires /bin/sh eric-4.1.2-2.fc9.noarch requires /usr/bin/env eric-4.1.2-2.fc9.noarch requires /bin/sh eric-4.1.2-2.fc9.noarch requires /usr/bin/python eris-1.3.13-2.fc9.ppc requires /sbin/ldconfig eris-1.3.13-2.fc9.ppc64 requires /sbin/ldconfig erlang-R12B-1.1.fc9.ppc requires /bin/sh erlang-R12B-1.1.fc9.ppc requires /bin/sh eruby-libs-1.0.5-11.ppc requires /sbin/ldconfig eruby-libs-1.0.5-11.ppc64 requires /sbin/ldconfig esc-1.0.1-9.fc9.ppc requires /bin/sh escape-200704130-8.fc9.ppc requires /bin/sh esmtp-0.6.0-4.fc9.ppc requires /bin/sh esmtp-0.6.0-4.fc9.ppc requires /bin/bash esmtp-0.6.0-4.fc9.ppc requires /usr/sbin/alternatives 1:esound-devel-0.2.38-7.fc9.ppc requires /bin/sh 1:esound-devel-0.2.38-7.fc9.ppc64 requires /bin/sh 1:esound-libs-0.2.38-7.fc9.ppc requires /sbin/ldconfig 1:esound-libs-0.2.38-7.fc9.ppc64 requires /sbin/ldconfig 1:esound-tools-0.2.38-7.fc9.ppc requires /bin/sh espeak-1.31-5.fc9.ppc requires /sbin/ldconfig espeak-1.31-5.fc9.ppc64 requires /sbin/ldconfig eterm-0.9.4-10.fc9.ppc requires /sbin/ldconfig eterm-0.9.4-10.fc9.ppc requires /usr/bin/perl eterm-0.9.4-10.fc9.ppc requires /bin/sh etherape-0.9.7-6.fc9.ppc requires /bin/sh etherbat-1.0.1-4.fc9.ppc requires /usr/bin/ruby ettercap-0.7.3-22.fc9.ppc requires /bin/sh ettercap-0.7.3-22.fc9.ppc requires /usr/sbin/alternatives ettercap-gtk-0.7.3-22.fc9.ppc requires /usr/sbin/alternatives ettercap-gtk-0.7.3-22.fc9.ppc requires /bin/sh evas-0.9.9.042-3.fc10.ppc requires /sbin/ldconfig evas-0.9.9.042-3.fc10.ppc64 requires /sbin/ldconfig eventlog-0.2.5-9.fc9.ppc requires /sbin/ldconfig eventlog-0.2.5-9.fc9.ppc64 requires /sbin/ldconfig evince-2.22.1.1-1.fc9.ppc requires /bin/sh evince-2.22.1.1-1.fc9.ppc64 requires /bin/sh evolution-2.23.2-1.fc10.ppc requires /usr/bin/perl evolution-2.23.2-1.fc10.ppc requires /bin/sh evolution-2.23.2-1.fc10.ppc64 requires /bin/sh evolution-2.23.2-1.fc10.ppc64 requires /usr/bin/perl evolution-bogofilter-2.23.2-1.fc10.ppc requires /bin/sh evolution-brutus-1.2.11-2.fc9.ppc requires /sbin/ldconfig evolution-brutus-1.2.11-2.fc9.ppc requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.ppc requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.ppc requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires /sbin/ldconfig evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-data-server-2.23.2-2.fc10.ppc requires /sbin/ldconfig evolution-data-server-2.23.2-2.fc10.ppc64 requires /sbin/ldconfig evolution-exchange-2.23.2-1.fc10.ppc requires /bin/sh evolution-python-0.0.4-3.fc9.ppc requires libedataserver-1.2.so.9 evolution-rss-0.0.8-7.fc9.ppc requires /sbin/ldconfig evolution-rss-0.0.8-7.fc9.ppc requires /bin/sh evolution-webcal-2.21.92-2.fc10.ppc requires /bin/sh evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.ppc requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-1.2.so.11 ewftools-20080501-1.fc10.ppc requires /usr/bin/python2.5 exaile-0.2.13-1.fc9.ppc requires /bin/sh exempi-2.0.0-1.fc9.ppc requires /sbin/ldconfig exempi-2.0.0-1.fc9.ppc64 requires /sbin/ldconfig exim-4.69-5.fc10.ppc requires /bin/sh exim-4.69-5.fc10.ppc requires /usr/sbin/alternatives exim-4.69-5.fc10.ppc requires /etc/aliases exim-4.69-5.fc10.ppc requires /usr/sbin/groupadd exim-4.69-5.fc10.ppc requires /usr/sbin/useradd exim-4.69-5.fc10.ppc requires /sbin/service exim-4.69-5.fc10.ppc requires /bin/bash exim-4.69-5.fc10.ppc requires /bin/sh exim-4.69-5.fc10.ppc requires /usr/bin/perl exim-4.69-5.fc10.ppc requires /sbin/chkconfig exim-clamav-4.69-5.fc10.ppc requires /bin/sh exim-clamav-4.69-5.fc10.ppc requires /sbin/chkconfig exim-clamav-4.69-5.fc10.ppc requires /sbin/service exim-greylist-4.69-5.fc10.ppc requires /etc/cron.daily exim-greylist-4.69-5.fc10.ppc requires /bin/bash exim-greylist-4.69-5.fc10.ppc requires /bin/sh exim-mon-4.69-5.fc10.ppc requires /bin/sh exiv2-libs-0.16-2.fc9.ppc requires /sbin/ldconfig exiv2-libs-0.16-2.fc9.ppc64 requires /sbin/ldconfig exo-0.3.4-2.fc9.ppc requires /usr/bin/env exo-0.3.4-2.fc9.ppc requires /bin/sh exo-0.3.4-2.fc9.ppc requires /bin/sh exo-0.3.4-2.fc9.ppc64 requires /bin/sh exo-0.3.4-2.fc9.ppc64 requires /usr/bin/env exo-0.3.4-2.fc9.ppc64 requires /bin/sh expat-2.0.1-5.ppc requires /sbin/ldconfig expat-2.0.1-5.ppc64 requires /sbin/ldconfig expect-5.43.0-13.fc9.ppc requires /bin/sh expect-5.43.0-13.fc9.ppc64 requires /bin/sh expectk-5.43.0-13.fc9.ppc requires /bin/sh ez-ipupdate-3.0.11-0.17.b8.fc9.ppc requires /bin/sh ez-ipupdate-3.0.11-0.17.b8.fc9.ppc requires /sbin/chkconfig ez-ipupdate-3.0.11-0.17.b8.fc9.ppc requires /usr/sbin/groupadd ez-ipupdate-3.0.11-0.17.b8.fc9.ppc requires /usr/sbin/useradd f-spot-0.4.3.1-1.fc10.ppc requires /bin/sh f-spot-0.4.3.1-1.fc10.ppc requires /bin/bash f-spot-0.4.3.1-1.fc10.ppc requires /bin/sh fRaBs-2.11-1.fc9.noarch requires /bin/sh facter-1.3.8-1.fc8.noarch requires /usr/bin/ruby fail2ban-0.8.2-13.fc9.noarch requires /bin/sh fail2ban-0.8.2-13.fc9.noarch requires /bin/bash fail2ban-0.8.2-13.fc9.noarch requires /sbin/chkconfig fail2ban-0.8.2-13.fc9.noarch requires /usr/bin/python fail2ban-0.8.2-13.fc9.noarch requires /sbin/service fakechroot-2.5-13.fc9.ppc requires /bin/sh fakeroot-1.6.4-16.fc9.ppc requires /bin/sh fakeroot-1.6.4-16.fc9.ppc requires /usr/bin/getopt fann-2.0.0-4.1.fc9.ppc requires /sbin/ldconfig fann-2.0.0-4.1.fc9.ppc64 requires /sbin/ldconfig fantasdic-1.0-0.1.beta5.fc9.noarch requires /bin/sh fantasdic-1.0-0.1.beta5.fc9.noarch requires /usr/bin/ruby farsight-0.1.28-1.fc10.ppc requires /sbin/ldconfig farsight-0.1.28-1.fc10.ppc64 requires /sbin/ldconfig fbg-0.9.1-2.fc9.ppc requires /bin/sh fbida-fbgs-2.06-5.fc9.ppc requires /bin/bash fbreader-0.8.12-2.fc9.ppc requires /sbin/ldconfig fbreader-0.8.12-2.fc9.ppc64 requires /sbin/ldconfig fbset-2.1-25.fc9.ppc requires /usr/bin/perl fcgi-2.4.0-5.fc9.ppc requires /sbin/ldconfig fcgi-2.4.0-5.fc9.ppc64 requires /sbin/ldconfig fcron-3.0.3-4.fc9.ppc requires /bin/sh fcron-3.0.3-4.fc9.ppc requires /usr/sbin/useradd fcron-3.0.3-4.fc9.ppc requires /sbin/service fcron-3.0.3-4.fc9.ppc requires /bin/sh fcron-3.0.3-4.fc9.ppc requires /sbin/chkconfig fedora-ds-admin-1.1.4-1.fc9.ppc requires /bin/sh fedora-ds-admin-1.1.4-1.fc9.ppc requires /usr/bin/env fedora-ds-admin-1.1.4-1.fc9.ppc requires /sbin/service fedora-ds-admin-1.1.4-1.fc9.ppc requires /sbin/ldconfig fedora-ds-admin-1.1.4-1.fc9.ppc requires /usr/bin/repl-monitor.pl fedora-ds-admin-1.1.4-1.fc9.ppc requires /bin/sh fedora-ds-admin-1.1.4-1.fc9.ppc requires /sbin/chkconfig fedora-ds-admin-1.1.4-1.fc9.ppc64 requires /bin/sh fedora-ds-admin-1.1.4-1.fc9.ppc64 requires /usr/bin/env fedora-ds-admin-1.1.4-1.fc9.ppc64 requires /sbin/service fedora-ds-admin-1.1.4-1.fc9.ppc64 requires /sbin/ldconfig fedora-ds-admin-1.1.4-1.fc9.ppc64 requires /usr/bin/repl-monitor.pl fedora-ds-admin-1.1.4-1.fc9.ppc64 requires /bin/sh fedora-ds-admin-1.1.4-1.fc9.ppc64 requires /sbin/chkconfig fedora-ds-base-1.1.0.1-4.fc9.ppc requires /usr/bin/perl fedora-ds-base-1.1.0.1-4.fc9.ppc requires /sbin/ldconfig fedora-ds-base-1.1.0.1-4.fc9.ppc requires /bin/sh fedora-ds-base-1.1.0.1-4.fc9.ppc requires /sbin/service fedora-ds-base-1.1.0.1-4.fc9.ppc requires /sbin/chkconfig fedora-ds-base-1.1.0.1-4.fc9.ppc requires /usr/bin/env fedora-ds-base-1.1.0.1-4.fc9.ppc requires /bin/sh fedora-ds-base-1.1.0.1-4.fc9.ppc64 requires /sbin/ldconfig fedora-ds-base-1.1.0.1-4.fc9.ppc64 requires /usr/bin/perl fedora-ds-base-1.1.0.1-4.fc9.ppc64 requires /usr/bin/env fedora-ds-base-1.1.0.1-4.fc9.ppc64 requires /bin/sh fedora-ds-base-1.1.0.1-4.fc9.ppc64 requires /sbin/service fedora-ds-base-1.1.0.1-4.fc9.ppc64 requires /sbin/chkconfig fedora-ds-base-1.1.0.1-4.fc9.ppc64 requires /bin/sh fedora-ds-dsgw-1.1.0-1.fc9.ppc requires /usr/bin/env fedora-ds-dsgw-1.1.0-1.fc9.ppc requires /etc/dirsrv/admin-serv/httpd.conf fedora-ds-dsgw-1.1.0-1.fc9.ppc requires /bin/sh fedora-icon-theme-1.0.0-1.fc8.noarch requires /bin/sh fedora-idm-console-1.1.1-2.fc9.ppc requires /bin/sh fedora-logos-9.0.0-3.fc10.noarch requires /bin/sh fedora-logos-9.0.0-3.fc10.noarch requires /bin/sh fedora-packager-0.3.0-1.fc9.noarch requires /bin/bash fedora-packager-0.3.0-1.fc9.noarch requires /usr/bin/python fedora-release-notes-9.0.1-1.noarch requires /bin/sh fedora-usermgmt-core-0.10-1.fc8.noarch requires /bin/bash fedora-usermgmt-devel-0.10-1.fc8.noarch requires /etc/rpm fedora-usermgmt-shadow-utils-0.10-1.fc8.noarch requires /bin/sh fedora-usermgmt-shadow-utils-0.10-1.fc8.noarch requires /usr/sbin/update-alternatives fedora-usermgmt-shadow-utils-0.10-1.fc8.noarch requires /bin/sh fedora-usermgmt-shadow-utils-0.10-1.fc8.noarch requires /etc/fedora/usermgmt feh-1.3.4-8.fc9.ppc requires /usr/bin/perl feh-1.3.4-8.fc9.ppc requires /bin/bash festival-1.96-4.fc9.ppc requires /bin/sh festival-docs-1.4.2-4.fc9.ppc requires /bin/sh festival-docs-1.4.2-4.fc9.ppc requires /sbin/install-info festival-lib-1.96-4.fc9.ppc requires /sbin/ldconfig festival-lib-1.96-4.fc9.ppc64 requires /sbin/ldconfig festival-speechtools-libs-1.2.96-4.fc9.ppc requires /sbin/ldconfig festival-speechtools-libs-1.2.96-4.fc9.ppc64 requires /sbin/ldconfig festival-speechtools-utils-1.2.96-4.fc9.ppc requires /usr/bin/perl festival-speechtools-utils-1.2.96-4.fc9.ppc requires /bin/sh fftw-3.1.2-6.fc9.ppc requires /sbin/install-info fftw-3.1.2-6.fc9.ppc requires /sbin/ldconfig fftw-3.1.2-6.fc9.ppc requires /bin/sh fftw-3.1.2-6.fc9.ppc64 requires /sbin/install-info fftw-3.1.2-6.fc9.ppc64 requires /sbin/ldconfig fftw-3.1.2-6.fc9.ppc64 requires /bin/sh fftw-devel-3.1.2-6.fc9.ppc requires /bin/sh fftw-devel-3.1.2-6.fc9.ppc64 requires /bin/sh fftw2-2.1.5-16.fc9.ppc requires /sbin/ldconfig fftw2-2.1.5-16.fc9.ppc64 requires /sbin/ldconfig fftw2-devel-2.1.5-16.fc9.ppc requires /bin/sh fftw2-devel-2.1.5-16.fc9.ppc64 requires /bin/sh fig2ps-1.3.6-2.fc7.noarch requires /usr/bin/perl file-libs-4.23-5.fc9.ppc requires /sbin/ldconfig file-libs-4.23-5.fc9.ppc64 requires /sbin/ldconfig file-roller-2.23.1-1.fc10.ppc requires /bin/sh filelight-1.0-12.fc9.ppc requires /bin/sh fillets-ng-0.8.0-1.fc9.ppc requires /bin/sh finch-2.4.1-3.fc10.ppc requires /sbin/ldconfig finch-2.4.1-3.fc10.ppc64 requires /sbin/ldconfig 1:findutils-4.4.0-1.fc10.ppc requires /bin/sh 1:findutils-4.4.0-1.fc10.ppc requires /sbin/install-info fio-1.20-1.fc10.ppc requires /bin/bash firefox-3.0-0.59.cvs20080408.fc10.ppc requires /bin/sh firefox-3.0-0.59.cvs20080408.fc10.ppc requires /bin/sh firestarter-1.0.3-18.fc9.ppc requires /bin/sh firestarter-1.0.3-18.fc9.ppc requires /bin/sh firmware-tools-1.5.6-1.fc8.noarch requires /usr/bin/python2 firmware-tools-1.5.6-1.fc8.noarch requires /bin/sh firmware-tools-1.5.6-1.fc8.noarch requires /usr/bin/python firstaidkit-0.1.1-4.fc9.noarch requires /usr/bin/python firstaidkit-devel-0.1.1-4.fc9.noarch requires /bin/bash firstboot-1.98-1.fc10.ppc requires /bin/sh firstboot-1.98-1.fc10.ppc requires /bin/bash firstboot-1.98-1.fc10.ppc requires /usr/bin/python2 fish-1.23.0-2.fc9.ppc requires /bin/sh fityk-0.8.1-13.fc9.ppc requires /bin/sh fityk-0.8.1-13.fc9.ppc64 requires /bin/sh flac-1.2.1-4.fc9.ppc requires /sbin/ldconfig flac-1.2.1-4.fc9.ppc64 requires /sbin/ldconfig flagpoll-0.9.1-2.fc9.noarch requires /usr/bin/python flawfinder-1.27-3.fc8.noarch requires /usr/bin/env flex-2.5.35-2.fc10.ppc requires /bin/sh flex-2.5.35-2.fc10.ppc requires /sbin/install-info flim-1.14.8-3.fc8.noarch requires /sbin/install-info flite-1.3-9.fc9.ppc requires /sbin/ldconfig flite-1.3-9.fc9.ppc64 requires /sbin/ldconfig flobopuyo-0.20-4.fc9.ppc requires /bin/sh flow-tools-0.68.4-1.fc9.ppc requires /bin/sh flow-tools-0.68.4-1.fc9.ppc requires /bin/env flow-tools-0.68.4-1.fc9.ppc requires /bin/sh flow-tools-0.68.4-1.fc9.ppc64 requires /bin/sh flow-tools-0.68.4-1.fc9.ppc64 requires /bin/env flow-tools-0.68.4-1.fc9.ppc64 requires /bin/sh fltk-1.1.8-1.fc9.ppc requires /sbin/ldconfig fltk-1.1.8-1.fc9.ppc64 requires /sbin/ldconfig fltk-devel-1.1.8-1.fc9.ppc requires /bin/sh fltk-devel-1.1.8-1.fc9.ppc64 requires /bin/sh fltk-fluid-1.1.8-1.fc9.ppc requires /bin/sh fluidsynth-libs-1.0.7-11.a.fc9.ppc requires /sbin/ldconfig fluidsynth-libs-1.0.7-11.a.fc9.ppc64 requires /sbin/ldconfig flumotion-0.4.2-5.fc9.ppc requires /usr/bin/python flumotion-0.4.2-5.fc9.ppc requires /bin/bash flumotion-0.4.2-5.fc9.ppc requires /bin/sh fluxbox-1.0.0-5.fc9.ppc requires /usr/bin/env fluxbox-1.0.0-5.fc9.ppc requires /bin/sh fluxstyle-1.0.1-2.fc7.noarch requires /usr/bin/env fmio-2.0.8-11.fc9.ppc requires /sbin/ldconfig fmio-2.0.8-11.fc9.ppc requires /usr/bin/python fmt-ptrn-java-1.3.17-1.fc9.ppc requires /sbin/ldconfig fmt-ptrn-java-1.3.17-1.fc9.ppc64 requires /sbin/ldconfig fmtools-1.0.2-3.fc9.ppc requires /bin/sh fnfx-0.3-11.fc9.ppc requires /bin/sh fnfx-0.3-11.fc9.ppc requires /bin/bash fnfx-0.3-11.fc9.ppc requires /sbin/chkconfig fnfx-0.3-11.fc9.ppc requires /sbin/service fontconfig-2.5.0-2.fc9.ppc requires /bin/sh fontconfig-2.5.0-2.fc9.ppc requires /sbin/ldconfig fontconfig-2.5.0-2.fc9.ppc64 requires /bin/sh fontconfig-2.5.0-2.fc9.ppc64 requires /sbin/ldconfig fontforge-20080309-1.fc9.ppc requires /usr/bin/fontforge fontforge-20080309-1.fc9.ppc requires /sbin/ldconfig fontforge-20080309-1.fc9.ppc64 requires /usr/bin/fontforge fontforge-20080309-1.fc9.ppc64 requires /sbin/ldconfig fontmatrix-0.4.2-1.fc9.ppc requires /bin/sh fonts-ISO8859-2-1.0-18.fc8.noarch requires /bin/sh fonts-ISO8859-2-100dpi-1.0-18.fc8.noarch requires /bin/sh fonts-ISO8859-2-75dpi-1.0-18.fc8.noarch requires /bin/sh fonts-KOI8-R-1.0-10.fc8.noarch requires /usr/bin/perl fonts-hebrew-fancy-0.20051122-2.fc7.noarch requires /bin/sh fonts-japanese-0.20061016-13.fc9.noarch requires /bin/sh fonts-truetype-apl-4.22.1-3.fc10.ppc requires /bin/sh fonts-x11-apl-4.22.1-3.fc10.ppc requires /bin/sh fonttools-2.0-0.11.20060223cvs.fc7.ppc requires /usr/bin/python fontypython-0.2.0-6.fc7.noarch requires /usr/bin/python foomatic-3.0.2-60.fc10.ppc requires /bin/sh foomatic-3.0.2-60.fc10.ppc requires /usr/bin/perl foomatic-3.0.2-60.fc10.ppc requires /bin/bash fpc-2.2.0-12.fc10.ppc requires /bin/sh fpc-src-2.2.0-12.fc10.ppc requires /bin/sh fpc-src-2.2.0-12.fc10.ppc requires /usr/bin/env freealut-1.1.0-6.fc9.ppc requires /sbin/ldconfig freealut-1.1.0-6.fc9.ppc64 requires /sbin/ldconfig freealut-devel-1.1.0-6.fc9.ppc requires /bin/sh freealut-devel-1.1.0-6.fc9.ppc64 requires /bin/sh freeciv-2.1.4-1.fc10.ppc requires /bin/sh freecol-0.7.3-2.fc9.noarch requires /bin/bash freecol-0.7.3-2.fc9.noarch requires /bin/sh freedoom-0.5-3.fc8.noarch requires /bin/sh freedroid-1.0.2-9.fc9.ppc requires /bin/sh freedroidrpg-0.10.3-2.fc9.ppc requires /bin/sh freefont-20060126-4.fc7.noarch requires /bin/sh freeglut-2.4.0-14.fc9.ppc requires /sbin/ldconfig freeglut-2.4.0-14.fc9.ppc64 requires /sbin/ldconfig freehdl-0.0.6-1.fc9.ppc requires /bin/sh freehdl-0.0.6-1.fc9.ppc requires /sbin/install-info freehdl-0.0.6-1.fc9.ppc requires /sbin/ldconfig freehdl-0.0.6-1.fc9.ppc requires /usr/bin/perl freehdl-0.0.6-1.fc9.ppc requires /bin/sh freehdl-0.0.6-1.fc9.ppc64 requires /bin/sh freehdl-0.0.6-1.fc9.ppc64 requires /sbin/install-info freehdl-0.0.6-1.fc9.ppc64 requires /sbin/ldconfig freehdl-0.0.6-1.fc9.ppc64 requires /usr/bin/perl freehdl-0.0.6-1.fc9.ppc64 requires /bin/sh freeimage-3.10.0-1.fc9.ppc requires /sbin/ldconfig freeimage-3.10.0-1.fc9.ppc64 requires /sbin/ldconfig freenx-0.7.1-5.fc9.ppc requires /bin/sh freenx-0.7.1-5.fc9.ppc requires /bin/bash freenx-0.7.1-5.fc9.ppc requires /usr/bin/expect freenx-server-0.7.2-8.fc10.ppc requires /bin/sh freenx-server-0.7.2-8.fc10.ppc requires /usr/bin/expect freenx-server-0.7.2-8.fc10.ppc requires /usr/lib/nx freenx-server-0.7.2-8.fc10.ppc requires /bin/bash freenx-server-0.7.2-8.fc10.ppc requires /usr/lib/cups/backend freenx-server-0.7.2-8.fc10.ppc requires /bin/sh freeradius-2.0.2-2.fc9.ppc requires /bin/sh freeradius-2.0.2-2.fc9.ppc requires /sbin/ldconfig freeradius-2.0.2-2.fc9.ppc requires /usr/bin/perl freeradius-2.0.2-2.fc9.ppc requires /bin/sh freeradius-2.0.2-2.fc9.ppc requires /sbin/chkconfig freeradius-dialupadmin-2.0.2-2.fc9.ppc requires /usr/bin/perl freeradius-utils-2.0.2-2.fc9.ppc requires /usr/bin/perl freeradius-utils-2.0.2-2.fc9.ppc requires /bin/sh freetalk-3.0-2.fc9.ppc requires /sbin/install-info freetalk-3.0-2.fc9.ppc requires /bin/sh freetalk-3.0-2.fc9.ppc requires /bin/sh freetds-0.64-11.fc9.ppc requires /sbin/ldconfig freetds-0.64-11.fc9.ppc64 requires /sbin/ldconfig freetennis-0.4.8-11.fc10.ppc requires /bin/sh freetype-2.3.5-4.fc9.ppc requires /sbin/ldconfig freetype-2.3.5-4.fc9.ppc requires /bin/sh freetype-2.3.5-4.fc9.ppc64 requires /sbin/ldconfig freetype-2.3.5-4.fc9.ppc64 requires /bin/sh freetype-devel-2.3.5-4.fc9.ppc requires /bin/sh freetype-devel-2.3.5-4.fc9.ppc64 requires /bin/sh freetype1-1.4-0.5.pre.fc9.ppc requires /sbin/ldconfig freetype1-1.4-0.5.pre.fc9.ppc64 requires /sbin/ldconfig fribidi-0.19.1-2.fc9.ppc requires /sbin/ldconfig fribidi-0.19.1-2.fc9.ppc64 requires /sbin/ldconfig frozen-bubble-2.1.0-8.fc9.ppc requires /usr/bin/perl frozen-bubble-2.1.0-8.fc9.ppc requires /bin/sh frozen-bubble-server-2.1.0-8.fc9.ppc requires /bin/sh frozen-bubble-server-2.1.0-8.fc9.ppc requires /bin/sh frysk-0.2.1-2.fc9.ppc64 requires /sbin/ldconfig frysk-0.2.1-2.fc9.ppc64 requires /bin/sh frysk-devel-0.2.1-2.fc9.ppc64 requires /usr/bin/env frysk-devel-0.2.1-2.fc9.ppc64 requires /bin/bash frysk-devel-0.2.1-2.fc9.ppc64 requires /bin/sh fslint-2.24-1.fc8.noarch requires /bin/bash fslint-2.24-1.fc8.noarch requires /usr/bin/env fslint-2.24-1.fc8.noarch requires /bin/sh fslint-2.24-1.fc8.noarch requires /usr/bin/python ftgl-2.1.2-8.fc9.ppc requires /sbin/ldconfig ftgl-2.1.2-8.fc9.ppc64 requires /sbin/ldconfig ftnchek-3.3.1-7.fc9.ppc requires /bin/sh ftnchek-emacs-3.3.1-7.fc9.ppc requires /usr/share/emacs/site-lisp ftplib-3.1-4.fc9.ppc requires /sbin/ldconfig ftplib-3.1-4.fc9.ppc64 requires /sbin/ldconfig func-0.18-1.fc9.noarch requires /bin/sh func-0.18-1.fc9.noarch requires /bin/sh func-0.18-1.fc9.noarch requires /usr/bin/python funtools-1.4.0-7.fc9.ppc requires /bin/sh funtools-libs-1.4.0-7.fc9.ppc requires /sbin/ldconfig funtools-libs-1.4.0-7.fc9.ppc64 requires /sbin/ldconfig fuse-2.7.3-2.fc9.ppc requires /sbin/MAKEDEV fuse-2.7.3-2.fc9.ppc requires /bin/sh fuse-2.7.3-2.fc9.ppc requires /sbin/service fuse-2.7.3-2.fc9.ppc requires /bin/sh fuse-2.7.3-2.fc9.ppc requires /sbin/chkconfig fuse-encfs-1.4.2-2.fc10.ppc requires /sbin/ldconfig fuse-encfs-1.4.2-2.fc10.ppc requires /bin/sh fuse-encfs-1.4.2-2.fc10.ppc64 requires /sbin/ldconfig fuse-encfs-1.4.2-2.fc10.ppc64 requires /bin/sh fuse-gmailfs-0.8.0-1.fc9.noarch requires /usr/bin/env fuse-libs-2.7.3-2.fc9.ppc requires /sbin/ldconfig fuse-libs-2.7.3-2.fc9.ppc64 requires /sbin/ldconfig fuse-s3fs-0.5-1.fc10.noarch requires /usr/bin/python fusion-icon-0.1.0-0.2.5e2dc9git.fc9.noarch requires /bin/sh fusion-icon-0.1.0-0.2.5e2dc9git.fc9.noarch requires /usr/bin/python fvwm-2.5.24-2.fc9.ppc requires /usr/bin/python fvwm-2.5.24-2.fc9.ppc requires /usr/bin/mimeopen fvwm-2.5.24-2.fc9.ppc requires /usr/bin/perl fvwm-2.5.24-2.fc9.ppc requires /bin/sh fwbackups-1.43.1-6.fc9.noarch requires /bin/bash fwbackups-1.43.1-6.fc9.noarch requires /usr/bin/python fwbuilder-2.1.16-2.fc9.ppc requires /bin/sh fwfstab-0.03-2.fc9.noarch requires /bin/sh fwrestart-1.05-1.fc8.noarch requires /usr/bin/env fyre-1.0.1-5.fc9.ppc requires /sbin/service fyre-1.0.1-5.fc9.ppc requires /bin/bash fyre-1.0.1-5.fc9.ppc requires /sbin/chkconfig fyre-1.0.1-5.fc9.ppc requires /bin/sh g-wrap-1.9.9-5.fc9.ppc requires /sbin/ldconfig g-wrap-1.9.9-5.fc9.ppc requires /sbin/install-info g-wrap-1.9.9-5.fc9.ppc64 requires /sbin/ldconfig g-wrap-1.9.9-5.fc9.ppc64 requires /sbin/install-info g-wrap-devel-1.9.9-5.fc9.ppc requires /bin/sh g-wrap-devel-1.9.9-5.fc9.ppc requires /bin/sh g-wrap-devel-1.9.9-5.fc9.ppc64 requires /bin/sh g-wrap-devel-1.9.9-5.fc9.ppc64 requires /bin/sh g2banking-2.3.3-3.fc9.ppc requires /sbin/ldconfig g2banking-2.3.3-3.fc9.ppc64 requires /sbin/ldconfig g2banking-devel-2.3.3-3.fc9.ppc requires /bin/sh g2banking-devel-2.3.3-3.fc9.ppc64 requires /bin/sh gai-0.5.10-14.fc9.ppc requires /sbin/ldconfig gai-0.5.10-14.fc9.ppc64 requires /sbin/ldconfig gajim-0.11.4-2.fc9.ppc requires /usr/bin/env gajim-0.11.4-2.fc9.ppc requires /bin/bash gajim-0.11.4-2.fc9.ppc requires /bin/sh galeon-2.0.5-1.fc9.ppc requires /bin/sh gallery2-2.2.4-4.fc10.noarch requires /bin/sh gallery2-2.2.4-4.fc10.noarch requires /usr/bin/perl gallery2-2.2.4-4.fc10.noarch requires /usr/bin/php gallery2-2.2.4-4.fc10.noarch requires /bin/sh galternatives-0.13.4-5.fc9.noarch requires /usr/sbin/update-alternatives galternatives-0.13.4-5.fc9.noarch requires /usr/bin/python gambas-ide-1.0.19-6.fc9.ppc requires /usr/bin/gbx gambas-runtime-1.0.19-6.fc9.ppc requires /usr/bin/gbx games-menus-0.3.2-1.fc9.noarch requires /bin/sh gamin-0.1.9-5.fc9.ppc requires /bin/sh gamin-0.1.9-5.fc9.ppc64 requires /bin/sh gamin-python-0.1.9-5.fc9.ppc requires /usr/bin/env gammu-1.18.91-1.fc9.ppc requires /bin/bash gammu-1.18.91-1.fc9.ppc requires /bin/sh gammu-libs-1.18.91-1.fc9.ppc requires /sbin/ldconfig gammu-libs-1.18.91-1.fc9.ppc64 requires /sbin/ldconfig ganglia-3.0.7-1.fc9.ppc requires /bin/sh ganglia-3.0.7-1.fc9.ppc requires /bin/sh ganglia-3.0.7-1.fc9.ppc64 requires /bin/sh ganglia-3.0.7-1.fc9.ppc64 requires /bin/sh ganglia-devel-3.0.7-1.fc9.ppc requires /sbin/ldconfig ganglia-devel-3.0.7-1.fc9.ppc64 requires /sbin/ldconfig ganglia-gmetad-3.0.7-1.fc9.ppc requires /bin/sh ganglia-gmetad-3.0.7-1.fc9.ppc requires /sbin/service ganglia-gmetad-3.0.7-1.fc9.ppc requires /bin/sh ganglia-gmetad-3.0.7-1.fc9.ppc requires /sbin/chkconfig ganglia-gmond-3.0.7-1.fc9.ppc requires /bin/sh ganglia-gmond-3.0.7-1.fc9.ppc requires /sbin/service ganglia-gmond-3.0.7-1.fc9.ppc requires /bin/sh ganglia-gmond-3.0.7-1.fc9.ppc requires /sbin/chkconfig ganymed-ssh2-210-6.fc9.ppc requires /usr/bin/rebuild-gcj-db ganyremote-2.8-2.fc10.noarch requires /usr/bin/env gauche-0.8.13-1.fc9.ppc requires /bin/sh gauche-0.8.13-1.fc9.ppc requires /usr/bin/gosh gauche-0.8.13-1.fc9.ppc requires /sbin/install-info gauche-0.8.13-1.fc9.ppc requires /sbin/ldconfig gauche-gl-0.4.4-3.fc9.ppc requires /bin/sh gauche-gl-0.4.4-3.fc9.ppc requires /sbin/install-info gauche-gl-0.4.4-3.fc9.ppc requires /bin/sh gauche-gtk-0.4.1-17.fc9.ppc requires /bin/sh gawk-3.1.5-17.fc9.ppc requires /bin/sh gawk-3.1.5-17.fc9.ppc requires /bin/mktemp gawk-3.1.5-17.fc9.ppc requires /sbin/install-info gawk-3.1.5-17.fc9.ppc requires /bin/sh gazpacho-0.7.2-2.fc8.noarch requires /usr/bin/python gbrainy-0.61-5.fc9.ppc requires /bin/sh gbrainy-0.61-5.fc9.ppc requires /bin/bash gc-7.1-1.fc10.ppc requires /sbin/ldconfig gc-7.1-1.fc10.ppc64 requires /sbin/ldconfig gcalctool-5.23.1-1.fc10.ppc requires /bin/sh gcc-4.3.0-8.ppc requires /bin/sh gcc-4.3.0-8.ppc requires /sbin/install-info gcc-4.3.0-8.ppc requires /bin/sh gcc-gfortran-4.3.0-8.ppc requires /bin/sh gcc-gfortran-4.3.0-8.ppc requires /sbin/install-info gcc-gnat-4.3.0-8.ppc requires /bin/sh gcc-gnat-4.3.0-8.ppc requires /sbin/install-info gcc-java-4.3.0-8.ppc requires /bin/sh gcc-java-4.3.0-8.ppc requires /sbin/install-info gcc-java-4.3.0-8.ppc requires /usr/share/java/eclipse-ecj.jar gcdmaster-1.2.2-4.fc9.ppc requires /bin/sh gchempaint-0.8.7-2.fc9.ppc requires /bin/sh gcin-1.3.9-2.fc9.ppc requires /bin/sh gcin-1.3.9-2.fc9.ppc requires /usr/sbin/alternatives gcin-1.3.9-2.fc9.ppc requires /bin/bash gcin-1.3.9-2.fc9.ppc64 requires /bin/sh gcin-1.3.9-2.fc9.ppc64 requires /usr/sbin/alternatives gcin-1.3.9-2.fc9.ppc64 requires /bin/bash 1:gcombust-0.1.55-13.ppc requires /bin/sh gcompris-8.4.5-1.fc10.ppc requires /sbin/install-info gcompris-8.4.5-1.fc10.ppc requires /bin/sh gconf-editor-2.22.0-1.fc9.ppc requires /bin/sh gconfmm26-2.22.0-1.fc9.ppc requires /bin/sh gconfmm26-2.22.0-1.fc9.ppc requires /sbin/ldconfig gconfmm26-2.22.0-1.fc9.ppc64 requires /bin/sh gconfmm26-2.22.0-1.fc9.ppc64 requires /sbin/ldconfig gcstar-1.3.2-1.fc9.noarch requires /usr/bin/perl gcstar-1.3.2-1.fc9.noarch requires /bin/sh gd-2.0.35-5.fc9.ppc requires /sbin/ldconfig gd-2.0.35-5.fc9.ppc64 requires /sbin/ldconfig gd-devel-2.0.35-5.fc9.ppc requires /bin/sh gd-devel-2.0.35-5.fc9.ppc64 requires /bin/sh gd-progs-2.0.35-5.fc9.ppc requires /usr/bin/perl gdal-1.5.1-5.fc9.ppc requires /sbin/ldconfig gdal-1.5.1-5.fc9.ppc64 requires /sbin/ldconfig gdal-devel-1.5.1-5.fc9.ppc requires /bin/sh gdal-devel-1.5.1-5.fc9.ppc64 requires /bin/sh gdal-python-1.5.1-5.fc9.ppc requires /usr/bin/env gdb-6.8-5.fc10.ppc requires /bin/sh gdb-6.8-5.fc10.ppc requires /sbin/install-info gdb-6.8-5.fc10.ppc requires /bin/sh gdb-6.8-5.fc10.ppc64 requires /bin/sh gdb-6.8-5.fc10.ppc64 requires /sbin/install-info gdb-6.8-5.fc10.ppc64 requires /bin/sh gdbm-1.8.0-28.fc9.ppc requires /sbin/ldconfig gdbm-1.8.0-28.fc9.ppc64 requires /sbin/ldconfig gdbm-devel-1.8.0-28.fc9.ppc requires /bin/sh gdbm-devel-1.8.0-28.fc9.ppc requires /sbin/install-info gdbm-devel-1.8.0-28.fc9.ppc64 requires /bin/sh gdbm-devel-1.8.0-28.fc9.ppc64 requires /sbin/install-info gdeskcal-1.01-1.fc7.noarch requires /bin/sh gdeskcal-1.01-1.fc7.noarch requires /usr/bin/env gdesklets-0.36-1.fc9.ppc requires /usr/bin/env gdesklets-0.36-1.fc9.ppc requires /bin/sh gdevilspie-0.31-2.fc10.noarch requires /usr/bin/python 1:gdk-pixbuf-0.22.0-36.fc9.ppc requires /sbin/ldconfig 1:gdk-pixbuf-0.22.0-36.fc9.ppc64 requires /sbin/ldconfig 1:gdk-pixbuf-devel-0.22.0-36.fc9.ppc requires /bin/sh 1:gdk-pixbuf-devel-0.22.0-36.fc9.ppc64 requires /bin/sh 1:gdm-2.22.0-6.fc10.ppc requires /bin/sh 1:gdm-2.22.0-6.fc10.ppc requires /usr/sbin/useradd 1:gdm-2.22.0-6.fc10.ppc requires /sbin/nologin 1:gdm-2.22.0-6.fc10.ppc requires /bin/sh gdome2-0.8.1-6.2.fc9.ppc requires /sbin/ldconfig gdome2-0.8.1-6.2.fc9.ppc64 requires /sbin/ldconfig gdome2-devel-0.8.1-6.2.fc9.ppc requires /bin/sh gdome2-devel-0.8.1-6.2.fc9.ppc64 requires /bin/sh gds2pov-0.20080229-1.fc9.ppc requires /sbin/ldconfig gds2pov-0.20080229-1.fc9.ppc64 requires /sbin/ldconfig geant321-2006-29.fc9.ppc requires /bin/sh geant321-g77-2006-29.fc9.ppc requires /bin/sh geda-gattrib-20080127-2.fc9.ppc requires /bin/sh geda-gnetlist-20080127-1.fc9.ppc requires /usr/bin/gawk geda-gnetlist-20080127-1.fc9.ppc requires /bin/bash geda-gschem-20080127-2.fc9.ppc requires /bin/sh geda-gschem-20080127-2.fc9.ppc requires /bin/sh geda-utils-20080127-1.fc9.ppc requires /usr/bin/env geda-utils-20080127-1.fc9.ppc requires /usr/bin/python geda-utils-20080127-1.fc9.ppc requires /usr/bin/perl geda-utils-20080127-1.fc9.ppc requires /bin/bash 1:gedit-2.23.1-1.fc10.ppc requires /bin/sh 1:gedit-2.23.1-1.fc10.ppc requires /bin/sh gedit-plugins-2.22.0-1.fc9.ppc requires /bin/sh geeqie-1.0-0.4.alpha1.fc10.ppc requires /bin/sh gegl-0.0.16-1.fc9.ppc requires /sbin/ldconfig gegl-0.0.16-1.fc9.ppc64 requires /sbin/ldconfig gemdropx-0.9-4.fc9.ppc requires /bin/sh gengetopt-2.22-1.fc9.ppc requires /bin/sh gengetopt-2.22-1.fc9.ppc requires /sbin/install-info genisoimage-1.1.6-11.fc9.ppc requires /bin/sh genisoimage-1.1.6-11.fc9.ppc requires /usr/sbin/alternatives genisoimage-1.1.6-11.fc9.ppc requires /bin/sh genisoimage-1.1.6-11.fc9.ppc requires /usr/bin/perl gentium-fonts-1.02-5.fc7.noarch requires /bin/sh geoclue-0.11.1-4.fc10.ppc requires /sbin/ldconfig geoclue-0.11.1-4.fc10.ppc64 requires /sbin/ldconfig geomview-1.9.4-8.fc9.ppc requires /bin/sh geomview-1.9.4-8.fc9.ppc requires /sbin/install-info geomview-1.9.4-8.fc9.ppc requires /bin/sh geomview-libs-1.9.4-8.fc9.ppc requires /sbin/ldconfig geomview-libs-1.9.4-8.fc9.ppc64 requires /sbin/ldconfig geoqo-0.96-5.fc9.noarch requires /usr/bin/perl geos-3.0.0-3.fc10.ppc requires /sbin/ldconfig geos-3.0.0-3.fc10.ppc64 requires /sbin/ldconfig geos-devel-3.0.0-3.fc10.ppc requires /bin/sh geos-devel-3.0.0-3.fc10.ppc64 requires /bin/sh gerbv-2.0.0-1.fc9.ppc requires /usr/bin/perl gerbv-2.0.0-1.fc9.ppc requires /bin/sh geronimo-specs-1.0-1.M2.2jpp.12.ppc requires /bin/sh getmail-4.8.1-1.fc9.noarch requires /usr/bin/python gettext-0.17-5.fc10.ppc requires /bin/sh gettext-0.17-5.fc10.ppc requires /sbin/install-info gettext-0.17-5.fc10.ppc requires /usr/bin/python gettext-0.17-5.fc10.ppc requires /sbin/ldconfig gettext-0.17-5.fc10.ppc requires /bin/sh gettext-0.17-5.fc10.ppc64 requires /bin/sh gettext-0.17-5.fc10.ppc64 requires /sbin/install-info gettext-0.17-5.fc10.ppc64 requires /usr/bin/python gettext-0.17-5.fc10.ppc64 requires /sbin/ldconfig gettext-0.17-5.fc10.ppc64 requires /bin/sh gettext-devel-0.17-5.fc10.ppc requires /bin/sh gettext-devel-0.17-5.fc10.ppc requires /sbin/install-info gettext-devel-0.17-5.fc10.ppc requires /sbin/ldconfig gettext-devel-0.17-5.fc10.ppc requires /bin/sh gettext-devel-0.17-5.fc10.ppc64 requires /bin/sh gettext-devel-0.17-5.fc10.ppc64 requires /sbin/install-info gettext-devel-0.17-5.fc10.ppc64 requires /sbin/ldconfig gettext-devel-0.17-5.fc10.ppc64 requires /bin/sh gfa-0.4.1-6.fc9.ppc requires /bin/sh gforth-0.6.2-12.fc9.ppc requires /bin/sh gforth-0.6.2-12.fc9.ppc requires /usr/bin/gforth gforth-0.6.2-12.fc9.ppc requires /sbin/install-info gforth-0.6.2-12.fc9.ppc requires /bin/sh gfs-artemisia-fonts-20070415-6.fc10.noarch requires /bin/sh gfs-baskerville-fonts-20070327-7.fc10.noarch requires /bin/sh gfs-bodoni-classic-fonts-20070415-6.fc10.noarch requires /bin/sh gfs-bodoni-fonts-20070415-5.fc10.noarch requires /bin/sh gfs-complutum-fonts-20070413-7.fc10.noarch requires /bin/sh gfs-didot-classic-fonts-20070415-5.fc10.noarch requires /bin/sh gfs-didot-fonts-20070616-6.fc10.noarch requires /bin/sh gfs-gazis-fonts-20080318-2.fc10.noarch requires /bin/sh gfs-neohellenic-fonts-20070415-5.fc10.noarch requires /bin/sh gfs-olga-fonts-20060908-5.fc10.noarch requires /bin/sh gfs-porson-fonts-20060908-7.fc10.noarch requires /bin/sh gfs-solomos-fonts-20071114-6.fc10.noarch requires /bin/sh gfs-theokritos-fonts-20070415-6.fc10.noarch requires /bin/sh gfs2-utils-2.03.00-4.fc10.ppc requires /bin/sh gfs2-utils-2.03.00-4.fc10.ppc requires /bin/bash gfs2-utils-2.03.00-4.fc10.ppc requires /sbin/chkconfig gfs2-utils-2.03.00-4.fc10.ppc requires /sbin/service 2:gftp-2.0.18-3.fc9.ppc requires /bin/sh gg2-libs-2.3.0-9.fc9.ppc requires /sbin/ldconfig gg2-libs-2.3.0-9.fc9.ppc64 requires /sbin/ldconfig ggobi-2.1.7-1.fc9.ppc requires /sbin/ldconfig ggobi-2.1.7-1.fc9.ppc64 requires /sbin/ldconfig ggz-client-libs-0.0.14.1-1.fc9.ppc requires /sbin/ldconfig ggz-client-libs-0.0.14.1-1.fc9.ppc64 requires /sbin/ldconfig ggz-gtk-client-0.0.14.1-1.fc9.ppc requires /sbin/ldconfig ggz-gtk-client-0.0.14.1-1.fc9.ppc64 requires /sbin/ldconfig ghc-6.8.2-2.fc9.ppc requires /bin/sh ghc-6.8.2-2.fc9.ppc requires /usr/bin/perl ghc-6.8.2-2.fc9.ppc requires /bin/sh ghc682-6.8.2-2.fc9.ppc requires /bin/sh ghc682-6.8.2-2.fc9.ppc requires /usr/bin/perl ghc682-6.8.2-2.fc9.ppc requires /bin/sh ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires /usr/bin/ghc-pkg-6.8.2 ghc682-gtk2hs-0.9.12.1-8.fc9.ppc requires /bin/sh ghdl-0.26-0.94svn.7.fc10.ppc requires /bin/sh ghdl-0.26-0.94svn.7.fc10.ppc requires /sbin/install-info ghex-2.22.0-1.ppc requires /sbin/ldconfig ghex-2.22.0-1.ppc requires /bin/sh ghex-2.22.0-1.ppc64 requires /bin/sh ghex-2.22.0-1.ppc64 requires /sbin/ldconfig ghostscript-8.62-3.fc9.ppc requires /sbin/ldconfig ghostscript-8.62-3.fc9.ppc requires /usr/bin/perl ghostscript-8.62-3.fc9.ppc requires /bin/sh ghostscript-8.62-3.fc9.ppc64 requires /sbin/ldconfig ghostscript-8.62-3.fc9.ppc64 requires /usr/bin/perl ghostscript-8.62-3.fc9.ppc64 requires /bin/sh ghostscript-devel-8.62-3.fc9.ppc requires /bin/sh ghostscript-devel-8.62-3.fc9.ppc64 requires /bin/sh ghostscript-fonts-5.50-18.fc8.noarch requires /bin/sh ghostscript-fonts-5.50-18.fc8.noarch requires /usr/bin/mkfontscale ghostscript-fonts-5.50-18.fc8.noarch requires /usr/bin/mkfontdir giblib-1.2.4-11.ppc requires /sbin/ldconfig giblib-1.2.4-11.ppc64 requires /sbin/ldconfig giblib-devel-1.2.4-11.ppc requires /bin/sh giblib-devel-1.2.4-11.ppc64 requires /bin/sh giflib-4.1.3-9.ppc requires /sbin/ldconfig giflib-4.1.3-9.ppc64 requires /sbin/ldconfig giflib-utils-4.1.3-9.ppc requires /usr/bin/perl giflib-utils-4.1.3-9.ppc requires /bin/sh gift-0.11.8.1-10.fc9.ppc requires /sbin/ldconfig gift-0.11.8.1-10.fc9.ppc requires /usr/bin/perl gift-0.11.8.1-10.fc9.ppc requires /bin/bash gift-0.11.8.1-10.fc9.ppc64 requires /sbin/ldconfig gift-0.11.8.1-10.fc9.ppc64 requires /usr/bin/perl gift-0.11.8.1-10.fc9.ppc64 requires /bin/bash gift-gnutella-0.0.11-5.fc9.ppc requires /sbin/ldconfig giggle-0.4-2.fc9.ppc requires /bin/sh gimmage-0.2.3-2.fc9.ppc requires /bin/sh gimmie-0.2.8-2.fc9.ppc requires /usr/bin/python gimmie-0.2.8-2.fc9.ppc requires /bin/sh 2:gimp-2.4.5-1.fc9.ppc requires /usr/bin/update-desktop-database 2:gimp-2.4.5-1.fc9.ppc requires /usr/bin/env 2:gimp-2.4.5-1.fc9.ppc requires /bin/bash 2:gimp-2.4.5-1.fc9.ppc requires /bin/sh 2:gimp-2.4.5-1.fc9.ppc requires /bin/sh 2:gimp-libs-2.4.5-1.fc9.ppc requires /sbin/ldconfig 2:gimp-libs-2.4.5-1.fc9.ppc64 requires /sbin/ldconfig ginac-1.4.3-1.fc10.ppc requires /sbin/ldconfig ginac-1.4.3-1.fc10.ppc requires /sbin/install-info ginac-1.4.3-1.fc10.ppc64 requires /sbin/ldconfig ginac-1.4.3-1.fc10.ppc64 requires /sbin/install-info ginac-devel-1.4.3-1.fc10.ppc requires /bin/sh ginac-devel-1.4.3-1.fc10.ppc64 requires /bin/sh ginac-utils-1.4.3-1.fc10.ppc requires /bin/sh git-1.5.5.1-1.fc10.ppc requires /usr/bin/perl git-1.5.5.1-1.fc10.ppc requires /bin/sh git-arch-1.5.5.1-1.fc10.ppc requires /usr/bin/perl git-cvs-1.5.5.1-1.fc10.ppc requires /usr/bin/perl git-email-1.5.5.1-1.fc10.ppc requires /usr/bin/perl git-gui-1.5.5.1-1.fc10.ppc requires /bin/sh git-svn-1.5.5.1-1.fc10.ppc requires /usr/bin/perl gitk-1.5.5.1-1.fc10.ppc requires /bin/sh gitweb-1.5.5.1-1.fc10.ppc requires /usr/bin/perl gjots2-2.3.4-8.fc10.noarch requires /bin/sh gjots2-2.3.4-8.fc10.noarch requires /usr/bin/env gkrellm-2.3.1-3.fc9.ppc requires /bin/sh gkrellm-daemon-2.3.1-3.fc9.ppc requires /sbin/service gkrellm-daemon-2.3.1-3.fc9.ppc requires /bin/bash gkrellm-daemon-2.3.1-3.fc9.ppc requires /sbin/chkconfig gkrellm-daemon-2.3.1-3.fc9.ppc requires /bin/sh gkrellm-weather-2.0.7-6.fc9.ppc requires /usr/bin/perl glabels-2.2.2-1.fc10.ppc requires /sbin/ldconfig glabels-2.2.2-1.fc10.ppc requires /bin/sh glabels-doc-2.2.2-1.fc10.ppc requires /bin/sh glabels-libs-2.2.2-1.fc10.ppc requires /sbin/ldconfig glabels-libs-2.2.2-1.fc10.ppc64 requires /sbin/ldconfig glade3-3.4.4-1.fc9.ppc requires /bin/sh glade3-libgladeui-3.4.4-1.fc9.ppc requires /sbin/ldconfig glade3-libgladeui-3.4.4-1.fc9.ppc64 requires /sbin/ldconfig glaxium-0.5-4.fc9.ppc requires /bin/sh glew-1.5.0-2.fc9.ppc requires /sbin/ldconfig glew-1.5.0-2.fc9.ppc64 requires /sbin/ldconfig glglobe-0.2-6.fc9.ppc requires /bin/sh 1:glib-1.2.10-29.fc9.ppc requires /sbin/ldconfig 1:glib-1.2.10-29.fc9.ppc64 requires /sbin/ldconfig 1:glib-devel-1.2.10-29.fc9.ppc requires /bin/sh 1:glib-devel-1.2.10-29.fc9.ppc64 requires /bin/sh glib-java-0.2.6-12.fc9.ppc requires /sbin/ldconfig glib-java-0.2.6-12.fc9.ppc requires /sbin/ldconfig glib-java-0.2.6-12.fc9.ppc64 requires /sbin/ldconfig glib-java-0.2.6-12.fc9.ppc64 requires /sbin/ldconfig glib2-2.16.3-5.fc10.ppc requires /sbin/ldconfig glib2-2.16.3-5.fc10.ppc64 requires /sbin/ldconfig glib2-devel-2.16.3-5.fc10.ppc requires /usr/bin/perl glib2-devel-2.16.3-5.fc10.ppc requires /bin/sh glib2-devel-2.16.3-5.fc10.ppc64 requires /usr/bin/perl glib2-devel-2.16.3-5.fc10.ppc64 requires /bin/sh glibc-2.8.90-2.ppc requires /usr/sbin/glibc_post_upgrade.ppc glibc-2.8.90-2.ppc requires /sbin/ldconfig glibc-2.8.90-2.ppc64 requires /usr/sbin/glibc_post_upgrade.ppc64 glibc-2.8.90-2.ppc64 requires /sbin/ldconfig glibc-common-2.8.90-2.ppc requires /usr/sbin/build-locale-archive glibc-common-2.8.90-2.ppc requires /bin/bash glibc-common-2.8.90-2.ppc requires /usr/sbin/tzdata-update glibc-common-2.8.90-2.ppc requires /bin/sh glibc-devel-2.8.90-2.ppc requires /bin/sh glibc-devel-2.8.90-2.ppc requires /sbin/install-info glibc-devel-2.8.90-2.ppc64 requires /bin/sh glibc-devel-2.8.90-2.ppc64 requires /sbin/install-info glibc-headers-2.8.90-2.ppc requires /bin/sh glibc-utils-2.8.90-2.ppc requires /sbin/ldconfig glibc-utils-2.8.90-2.ppc requires /bin/bash glibc-utils-2.8.90-2.ppc requires /usr/bin/perl glibmm24-2.16.0-1.fc9.ppc requires /sbin/ldconfig glibmm24-2.16.0-1.fc9.ppc64 requires /sbin/ldconfig glibmm24-devel-2.16.0-1.fc9.ppc requires /usr/bin/perl glibmm24-devel-2.16.0-1.fc9.ppc64 requires /usr/bin/perl glimmer-3.02-3.fc9.ppc requires /bin/csh glimmer-3.02-3.fc9.ppc requires /bin/awk glipper-1.0-3.fc9.ppc requires /usr/bin/env glipper-1.0-3.fc9.ppc requires /bin/sh glitz-0.5.6-6.fc9.ppc requires /sbin/ldconfig glitz-0.5.6-6.fc9.ppc64 requires /sbin/ldconfig glitz-glx-0.5.6-6.fc9.ppc requires /sbin/ldconfig glitz-glx-0.5.6-6.fc9.ppc64 requires /sbin/ldconfig gliv-1.9.6-3.fc9.ppc requires /bin/sh glob2-0.9.3-1.fc10.ppc requires /bin/sh global-5.4-2.fc9.ppc requires /bin/sh glom-1.6.15-1.fc9.ppc requires /sbin/ldconfig glom-1.6.15-1.fc9.ppc requires /bin/sh glom-1.6.15-1.fc9.ppc64 requires /bin/sh glom-1.6.15-1.fc9.ppc64 requires /sbin/ldconfig glpi-0.70.2-3.fc10.noarch requires /bin/sh glpi-0.70.2-3.fc10.noarch requires /sbin/service glpi-0.70.2-3.fc10.noarch requires /etc/logrotate.d glpi-mass-ocs-import-1.1-1.fc9.noarch requires /bin/sh glpi-mass-ocs-import-1.1-1.fc9.noarch requires /bin/sh glpi-mass-ocs-import-1.1-1.fc9.noarch requires /etc/cron.d glpk-4.28-1.fc10.ppc requires /sbin/ldconfig glpk-4.28-1.fc10.ppc64 requires /sbin/ldconfig glpk-utils-4.28-1.fc10.ppc requires /bin/sh glump-0.9.11-3.fc8.noarch requires /usr/bin/python glunarclock-0.32.4-11.fc9.ppc requires /bin/sh glusterfs-client-1.3.9-1.fc10.ppc requires /bin/sh glusterfs-libs-1.3.9-1.fc10.ppc requires /sbin/ldconfig glusterfs-libs-1.3.9-1.fc10.ppc64 requires /sbin/ldconfig glusterfs-server-1.3.9-1.fc10.ppc requires /bin/sh glusterfs-server-1.3.9-1.fc10.ppc requires /bin/sh glyph-keeper-0.32-4.fc9.ppc requires /sbin/ldconfig glyph-keeper-0.32-4.fc9.ppc64 requires /sbin/ldconfig gmediaserver-0.13.0-3.fc9.ppc requires /bin/sh gmediaserver-0.13.0-3.fc9.ppc requires /sbin/install-info gmediaserver-0.13.0-3.fc9.ppc requires /bin/bash gmediaserver-0.13.0-3.fc9.ppc requires /sbin/chkconfig gmfsk-0.7-0.5.pre1.fc9.ppc requires /bin/sh gmime-2.2.19-1.fc10.ppc requires /sbin/ldconfig gmime-2.2.19-1.fc10.ppc64 requires /sbin/ldconfig gmime-devel-2.2.19-1.fc10.ppc requires /bin/sh gmime-devel-2.2.19-1.fc10.ppc64 requires /bin/sh gmp-4.2.2-7.fc9.ppc requires /sbin/ldconfig gmp-4.2.2-7.fc9.ppc64 requires /sbin/ldconfig gmp-devel-4.2.2-7.fc9.ppc requires /bin/sh gmp-devel-4.2.2-7.fc9.ppc requires /sbin/install-info gmp-devel-4.2.2-7.fc9.ppc64 requires /bin/sh gmp-devel-4.2.2-7.fc9.ppc64 requires /sbin/install-info gmpc-0.15.5.0-3.fc9.ppc requires /bin/sh gmyth-0.7.1-1.fc9.ppc requires /sbin/ldconfig gmyth-0.7.1-1.fc9.ppc64 requires /sbin/ldconfig gnash-0.8.2-2.fc9.ppc requires /bin/sh gnash-0.8.2-2.fc9.ppc requires /sbin/install-info gnash-0.8.2-2.fc9.ppc requires /sbin/ldconfig gnash-0.8.2-2.fc9.ppc requires /bin/sh gnash-plugin-0.8.2-2.fc9.ppc requires /usr/lib/mozilla/plugins gnet2-2.0.7-11.fc9.ppc requires /sbin/ldconfig gnet2-2.0.7-11.fc9.ppc64 requires /sbin/ldconfig gnochm-0.9.11-2.fc9.noarch requires /bin/sh gnochm-0.9.11-2.fc9.noarch requires /usr/bin/python gnofract4d-3.8-1.fc9.ppc requires /usr/bin/env gnofract4d-3.8-1.fc9.ppc requires /usr/bin/python gnofract4d-3.8-1.fc9.ppc requires /bin/sh gnokii-0.6.24-1.fc9.ppc requires /bin/sh gnokii-0.6.24-1.fc9.ppc requires /usr/sbin/groupadd gnokii-0.6.24-1.fc9.ppc requires /sbin/ldconfig gnokii-0.6.24-1.fc9.ppc64 requires /bin/sh gnokii-0.6.24-1.fc9.ppc64 requires /sbin/ldconfig gnokii-0.6.24-1.fc9.ppc64 requires /usr/sbin/groupadd gnokii-smsd-0.6.24-1.fc9.ppc requires /usr/sbin/useradd gnokii-smsd-0.6.24-1.fc9.ppc requires /bin/bash gnokii-smsd-0.6.24-1.fc9.ppc requires /bin/sh gnokii-smsd-0.6.24-1.fc9.ppc requires /sbin/chkconfig gnokii-smsd-0.6.24-1.fc9.ppc requires /bin/sh gnome-applet-music-2.3.1-1.fc10.ppc requires /bin/sh gnome-applet-music-2.3.1-1.fc10.ppc requires /usr/bin/env gnome-applet-netspeed-0.14-3.fc9.ppc requires /bin/sh gnome-applet-sensors-1.8.2-2.fc9.ppc requires /bin/sh gnome-applet-sshmenu-3.15-5.fc9.noarch requires /bin/sh gnome-applet-sshmenu-3.15-5.fc9.noarch requires /usr/bin/ruby gnome-applet-timer-2.0.1-1.fc9.ppc requires /bin/sh gnome-applet-timer-2.0.1-1.fc9.ppc requires /usr/bin/env 1:gnome-applets-2.23.2-1.fc10.ppc requires /bin/sh 1:gnome-applets-2.23.2-1.fc10.ppc requires /usr/bin/env gnome-bluetooth-0.11.0-3.fc9.ppc requires /bin/sh gnome-bluetooth-libs-0.11.0-3.fc9.ppc requires /sbin/ldconfig gnome-bluetooth-libs-0.11.0-3.fc9.ppc64 requires /sbin/ldconfig gnome-build-0.2.4-1.fc9.ppc requires /sbin/ldconfig gnome-build-0.2.4-1.fc9.ppc requires /usr/bin/perl gnome-build-0.2.4-1.fc9.ppc64 requires /sbin/ldconfig gnome-build-0.2.4-1.fc9.ppc64 requires /usr/bin/perl gnome-chemistry-utils-0.8.7-1.fc9.ppc requires /bin/sh gnome-chemistry-utils-0.8.7-1.fc9.ppc64 requires /bin/sh gnome-chemistry-utils-mozplugin-0.8.7-1.fc9.ppc requires /usr/lib/mozilla/plugins gnome-commander-1.2.5-1.fc9.ppc requires /bin/sh gnome-common-2.18.0-1.fc8.noarch requires /bin/sh gnome-compiz-manager-0.10.4-4.fc9.ppc requires /sbin/ldconfig gnome-compiz-manager-0.10.4-4.fc9.ppc requires /bin/sh gnome-compiz-manager-0.10.4-4.fc9.ppc64 requires /bin/sh gnome-compiz-manager-0.10.4-4.fc9.ppc64 requires /sbin/ldconfig gnome-desktop-2.23.2-0.2008.05.14.1.fc10.ppc requires /usr/bin/python gnome-desktop-2.23.2-0.2008.05.14.1.fc10.ppc requires /sbin/ldconfig gnome-desktop-2.23.2-0.2008.05.14.1.fc10.ppc64 requires /usr/bin/python gnome-desktop-2.23.2-0.2008.05.14.1.fc10.ppc64 requires /sbin/ldconfig gnome-device-manager-0.2-3.fc9.ppc requires /bin/sh gnome-device-manager-devel-0.2-3.fc9.ppc requires /sbin/ldconfig gnome-device-manager-devel-0.2-3.fc9.ppc64 requires /sbin/ldconfig gnome-device-manager-libs-0.2-3.fc9.ppc requires /sbin/ldconfig gnome-device-manager-libs-0.2-3.fc9.ppc64 requires /sbin/ldconfig gnome-do-0.4.2.0-1.fc10.ppc requires /bin/sh gnome-doc-utils-0.12.2-1.fc9.noarch requires /bin/sh gnome-doc-utils-0.12.2-1.fc9.noarch requires /usr/bin/python 1:gnome-games-2.23.1-2.fc10.ppc requires /bin/sh 1:gnome-games-2.23.1-2.fc10.ppc requires /usr/bin/env gnome-genius-1.0.2-3.fc9.ppc requires /bin/sh gnome-icon-theme-2.22.0-6.fc9.noarch requires /bin/sh gnome-keyring-2.22.1-1.fc9.ppc requires /sbin/ldconfig gnome-keyring-2.22.1-1.fc9.ppc requires /bin/sh gnome-keyring-2.22.1-1.fc9.ppc64 requires /bin/sh gnome-keyring-2.22.1-1.fc9.ppc64 requires /sbin/ldconfig gnome-keyring-manager-2.20.0-2.fc9.ppc requires /bin/sh gnome-launch-box-0.4-9.fc10.ppc requires /bin/sh 1:gnome-libs-1.4.2-8.fc9.ppc requires /sbin/ldconfig 1:gnome-libs-1.4.2-8.fc9.ppc requires /bin/sh 1:gnome-libs-1.4.2-8.fc9.ppc64 requires /sbin/ldconfig 1:gnome-libs-1.4.2-8.fc9.ppc64 requires /bin/sh 1:gnome-libs-devel-1.4.2-8.fc9.ppc requires /bin/sh 1:gnome-libs-devel-1.4.2-8.fc9.ppc requires /usr/bin/perl 1:gnome-libs-devel-1.4.2-8.fc9.ppc64 requires /bin/sh 1:gnome-libs-devel-1.4.2-8.fc9.ppc64 requires /usr/bin/perl gnome-mag-0.15.0-2.fc9.ppc requires /sbin/ldconfig gnome-mag-0.15.0-2.fc9.ppc64 requires /sbin/ldconfig gnome-media-2.23.1.1-2.fc10.ppc requires /bin/sh gnome-media-2.23.1.1-2.fc10.ppc64 requires /bin/sh gnome-menus-2.23.1-1.fc10.ppc requires /sbin/ldconfig gnome-menus-2.23.1-1.fc10.ppc64 requires /sbin/ldconfig gnome-mount-0.8-1.fc9.ppc requires /bin/sh gnome-nds-thumbnailer-1.0.2-1.fc9.ppc requires /bin/sh gnome-netstatus-2.12.1-4.fc9.ppc requires /bin/sh gnome-nettool-2.22.0-1.fc9.ppc requires /bin/sh gnome-packagekit-0.2.1-2.20080508.fc10.ppc requires /bin/sh gnome-packagekit-0.2.1-2.20080508.fc10.ppc requires /usr/bin/python gnome-panel-2.23.2.1-1.fc10.ppc requires /bin/sh gnome-password-generator-1.5-2.fc9.noarch requires /bin/sh gnome-password-generator-1.5-2.fc9.noarch requires /usr/bin/python gnome-phone-manager-0.51-2.fc10.ppc requires /bin/sh gnome-pilot-2.0.16-2.fc9.ppc requires /bin/sh gnome-pilot-2.0.16-2.fc9.ppc64 requires /bin/sh gnome-pilot-conduits-2.0.16-1.fc9.ppc requires /sbin/ldconfig gnome-power-manager-2.22.1-1.fc9.ppc requires /bin/sh gnome-power-manager-2.22.1-1.fc9.ppc requires /bin/sh gnome-ppp-0.3.23-5.fc9.ppc requires /bin/sh gnome-python2-bonobo-2.22.0-2.fc9.ppc requires /usr/bin/env gnome-python2-bonobo-2.22.0-2.fc9.ppc requires /bin/sh gnome-python2-gconf-2.22.0-2.fc9.ppc requires /usr/bin/env gnome-python2-gnomeprint-2.22.0-4.fc10.ppc requires /usr/bin/env gnome-python2-gnomevfs-2.22.0-2.fc9.ppc requires /usr/bin/env gnome-python2-libegg-2.19.1-15.fc9.ppc requires /usr/bin/python gnome-scan-0.6-2.fc9.ppc requires /bin/sh gnome-scan-libs-0.6-2.fc9.ppc requires /sbin/ldconfig gnome-scan-libs-0.6-2.fc9.ppc64 requires /sbin/ldconfig gnome-schedule-2.0.2-1.fc9.noarch requires /bin/sh gnome-schedule-2.0.2-1.fc9.noarch requires /bin/sh gnome-screensaver-2.23.3-0.2008.05.14.1.fc10.ppc requires /bin/sh gnome-session-2.23.2.2-3.fc10.ppc requires /bin/sh gnome-session-2.23.2.2-3.fc10.ppc requires /bin/sh gnome-settings-daemon-2.23.2-0.2008.05.14.2.fc10.ppc requires /bin/sh gnome-sharp-2.16.1-1.fc9.ppc requires /sbin/ldconfig gnome-sharp-2.16.1-1.fc9.ppc requires /bin/sh gnome-specimen-0.3-1.fc8.noarch requires /bin/sh gnome-specimen-0.3-1.fc8.noarch requires /usr/bin/python gnome-speech-0.4.19-1.fc10.ppc requires /sbin/ldconfig gnome-speech-0.4.19-1.fc10.ppc64 requires /sbin/ldconfig gnome-system-monitor-2.22.1-5.fc9.ppc requires /bin/sh gnome-terminal-2.22.1-1.fc9.ppc requires /bin/sh gnome-themes-2.23.1-1.fc10.noarch requires /bin/sh gnome-translate-0.99-12.fc9.ppc requires /bin/sh gnome-user-docs-2.22.0-1.fc9.noarch requires /bin/sh gnome-user-share-0.31-1.fc9.ppc requires /bin/sh 1:gnome-utils-2.20.0.1-5.fc10.ppc requires /bin/sh 1:gnome-utils-2.20.0.1-5.fc10.ppc64 requires /bin/sh gnome-vfs2-2.22.0-1.fc9.ppc requires /bin/sh gnome-vfs2-2.22.0-1.fc9.ppc requires /sbin/ldconfig gnome-vfs2-2.22.0-1.fc9.ppc64 requires /bin/sh gnome-vfs2-2.22.0-1.fc9.ppc64 requires /sbin/ldconfig gnome-vfs2-monikers-2.15.3-5.fc9.ppc requires /sbin/ldconfig gnome-vfsmm26-2.22.0-1.fc9.ppc requires /bin/sh gnome-vfsmm26-2.22.0-1.fc9.ppc requires /sbin/ldconfig gnome-vfsmm26-2.22.0-1.fc9.ppc64 requires /bin/sh gnome-vfsmm26-2.22.0-1.fc9.ppc64 requires /sbin/ldconfig gnome-volume-manager-2.22.5-1.fc10.ppc requires /bin/sh gnome-volume-manager-2.22.5-1.fc10.ppc requires /bin/sh gnome-web-photo-0.3-11.fc9.ppc requires /bin/sh gnomebaker-0.6.2-2.1.fc9.ppc requires /bin/sh gnomecatalog-0.3.4-3.fc9.noarch requires /usr/bin/python gnomeradio-1.7-5.fc9.ppc requires /bin/sh gnomesword-2.3.3-2.fc9.ppc requires /bin/sh gnotime-2.3.0-1.fc9.ppc requires /bin/sh gnotime-2.3.0-1.fc9.ppc requires /bin/sh gnu-getopt-1.0.12-4jpp.1.ppc requires /bin/sh gnu-getopt-javadoc-1.0.12-4jpp.1.ppc requires /bin/sh gnu-getopt-javadoc-1.0.12-4jpp.1.ppc requires /bin/ln gnu-getopt-javadoc-1.0.12-4jpp.1.ppc requires /bin/rm gnubg-20061119-14.fc9.ppc requires /sbin/install-info gnubg-20061119-14.fc9.ppc requires /bin/sh gnubiff-2.2.7-4.fc9.ppc requires /sbin/install-info gnubiff-2.2.7-4.fc9.ppc requires /bin/sh gnucap-0.35-4.fc9.ppc requires /bin/sh gnucash-2.2.4-1.fc9.ppc requires /sbin/ldconfig gnucash-2.2.4-1.fc9.ppc requires /usr/bin/perl gnucash-2.2.4-1.fc9.ppc requires /bin/sh gnucash-2.2.4-1.fc9.ppc requires /bin/sh gnucash-docs-2.2.0-2.fc8.noarch requires /bin/sh gnucash-docs-2.2.0-2.fc8.noarch requires /usr/bin/scrollkeeper-update gnue-common-0.6.9-4.fc10.noarch requires /usr/bin/python gnugo-3.6-6.fc9.ppc requires /bin/sh 1:gnumeric-1.8.2-2.fc9.ppc requires /sbin/ldconfig 1:gnumeric-1.8.2-2.fc9.ppc requires /bin/sh 1:gnumeric-1.8.2-2.fc9.ppc64 requires /bin/sh 1:gnumeric-1.8.2-2.fc9.ppc64 requires /sbin/ldconfig 1:gnumeric-plugins-extras-1.8.2-2.fc9.ppc requires /usr/bin/perl gnupg-1.4.9-1.fc9.ppc requires /bin/sh gnupg-1.4.9-1.fc9.ppc requires /sbin/install-info gnupg-1.4.9-1.fc9.ppc requires /bin/sh gnupg2-2.0.9-1.fc9.ppc requires /bin/sh gnupg2-2.0.9-1.fc9.ppc requires /sbin/install-info gnupg2-2.0.9-1.fc9.ppc requires /bin/sh gnuplot-4.2.3-1.fc10.ppc requires /sbin/install-info gnuplot-4.2.3-1.fc10.ppc requires /bin/sh gnuradio-3.1.1-4.fc9.ppc requires /sbin/ldconfig gnuradio-3.1.1-4.fc9.ppc64 requires /sbin/ldconfig gnuradio-devel-3.1.1-4.fc9.ppc requires /sbin/ldconfig gnuradio-devel-3.1.1-4.fc9.ppc64 requires /sbin/ldconfig gnustep-make-2.0.4-9.fc9.ppc requires /bin/sh gnutls-2.0.4-2.fc9.ppc requires /sbin/ldconfig gnutls-2.0.4-2.fc9.ppc64 requires /sbin/ldconfig gnutls-devel-2.0.4-2.fc9.ppc requires /bin/sh gnutls-devel-2.0.4-2.fc9.ppc requires /sbin/install-info gnutls-devel-2.0.4-2.fc9.ppc requires /bin/sh gnutls-devel-2.0.4-2.fc9.ppc64 requires /bin/sh gnutls-devel-2.0.4-2.fc9.ppc64 requires /sbin/install-info gnutls-devel-2.0.4-2.fc9.ppc64 requires /bin/sh gobby-0.4.5-3.fc9.ppc requires /bin/sh goffice-0.6.2-1.fc9.ppc requires /sbin/ldconfig goffice-0.6.2-1.fc9.ppc64 requires /sbin/ldconfig goffice04-0.4.3-3.fc9.ppc requires /sbin/ldconfig goffice04-0.4.3-3.fc9.ppc64 requires /sbin/ldconfig gok-1.3.7-3.fc9.ppc requires /bin/sh gonvert-0.2.19-3.fc9.noarch requires /usr/bin/python goocanvas-0.9-4.fc9.ppc requires /sbin/ldconfig goocanvas-0.9-4.fc9.ppc64 requires /sbin/ldconfig goocanvasmm-0.4.0-3.fc9.ppc requires /sbin/ldconfig goocanvasmm-0.4.0-3.fc9.ppc64 requires /sbin/ldconfig gossip-0.29-2.fc10.ppc requires /bin/sh gourmet-0.13.4-3.fc9.noarch requires /usr/bin/python gpa-0.7.6-5.fc10.ppc requires /bin/sh gpar2-0.3-6.fc9.ppc requires /bin/sh gparted-0.3.7-1.fc10.ppc requires /bin/bash gparted-0.3.7-1.fc10.ppc requires /bin/sh gperf-3.0.3-4.fc9.ppc requires /bin/sh gperf-3.0.3-4.fc9.ppc requires /sbin/install-info gpgme-1.1.6-3.fc9.ppc requires /sbin/ldconfig gpgme-1.1.6-3.fc9.ppc64 requires /sbin/ldconfig gpgme-devel-1.1.6-3.fc9.ppc requires /bin/sh gpgme-devel-1.1.6-3.fc9.ppc requires /sbin/install-info gpgme-devel-1.1.6-3.fc9.ppc requires /bin/sh gpgme-devel-1.1.6-3.fc9.ppc64 requires /bin/sh gpgme-devel-1.1.6-3.fc9.ppc64 requires /sbin/install-info gpgme-devel-1.1.6-3.fc9.ppc64 requires /bin/sh gphoto2-2.4.0-10.fc9.ppc requires /bin/sh gphoto2-2.4.0-10.fc9.ppc requires /bin/bash gphoto2-2.4.0-10.fc9.ppc64 requires /bin/sh gphoto2-2.4.0-10.fc9.ppc64 requires /bin/bash gphoto2-devel-2.4.0-10.fc9.ppc requires /bin/sh gphoto2-devel-2.4.0-10.fc9.ppc64 requires /bin/sh gpixpod-0.6.2-3.fc9.ppc requires /bin/bash gpm-1.20.1-90.fc9.ppc requires /bin/sh gpm-1.20.1-90.fc9.ppc requires /sbin/ldconfig gpm-1.20.1-90.fc9.ppc requires /bin/bash gpm-1.20.1-90.fc9.ppc requires /sbin/chkconfig gpm-1.20.1-90.fc9.ppc requires /sbin/install-info gpm-1.20.1-90.fc9.ppc64 requires /bin/sh gpm-1.20.1-90.fc9.ppc64 requires /sbin/ldconfig gpm-1.20.1-90.fc9.ppc64 requires /bin/bash gpm-1.20.1-90.fc9.ppc64 requires /sbin/chkconfig gpm-1.20.1-90.fc9.ppc64 requires /sbin/install-info gpodder-0.11.1-2.fc9.noarch requires /bin/sh gpodder-0.11.1-2.fc9.noarch requires /usr/bin/python gpredict-0.9.0-3.fc9.ppc requires /bin/sh gpsd-2.37-2.fc9.ppc requires /sbin/ldconfig gpsd-2.37-2.fc9.ppc requires /usr/bin/env gpsd-2.37-2.fc9.ppc64 requires /usr/bin/env gpsd-2.37-2.fc9.ppc64 requires /sbin/ldconfig gpsd-clients-2.37-2.fc9.ppc requires /usr/bin/env gpsd-devel-2.37-2.fc9.ppc requires /usr/bin/env gpsd-devel-2.37-2.fc9.ppc64 requires /usr/bin/env gpsdrive-2.09-5.fc9.ppc requires /sbin/ldconfig gpsdrive-2.09-5.fc9.ppc requires /bin/bash gpsdrive-2.09-5.fc9.ppc requires /bin/sh gpsdrive-2.09-5.fc9.ppc requires /usr/bin/perl gpsdrive-2.09-5.fc9.ppc64 requires /sbin/ldconfig gpsdrive-2.09-5.fc9.ppc64 requires /bin/bash gpsdrive-2.09-5.fc9.ppc64 requires /bin/sh gpsdrive-2.09-5.fc9.ppc64 requires /usr/bin/perl gpsim-0.22.0-5.fc8.ppc requires /sbin/ldconfig gpsim-0.22.0-5.fc8.ppc64 requires /sbin/ldconfig gpsman-6.3.2-3.fc9.noarch requires /bin/sh gq-1.3.4-1.fc9.ppc requires /bin/sh gquilt-0.20-3.fc9.noarch requires /bin/sh gquilt-0.20-3.fc9.noarch requires /bin/bash gqview-2.0.4-9.ppc requires /bin/sh grace-5.1.21-9.fc9.ppc requires /bin/sh grace-5.1.21-9.fc9.ppc requires /bin/sh gramps-2.2.10-1.fc9.noarch requires /bin/sh gramps-2.2.10-1.fc9.noarch requires /bin/sh graphviz-2.16.1-0.5.fc9.ppc requires /bin/sh graphviz-2.16.1-0.5.fc9.ppc requires /sbin/ldconfig graphviz-2.16.1-0.5.fc9.ppc requires /bin/sh graphviz-2.16.1-0.5.fc9.ppc64 requires /bin/sh graphviz-2.16.1-0.5.fc9.ppc64 requires /sbin/ldconfig graphviz-2.16.1-0.5.fc9.ppc64 requires /bin/sh graphviz-devil-2.16.1-0.5.fc9.ppc requires /bin/sh graphviz-gd-2.16.1-0.5.fc9.ppc requires /bin/sh graphviz-gd-2.16.1-0.5.fc9.ppc requires /sbin/ldconfig graphviz-gd-2.16.1-0.5.fc9.ppc requires /usr/bin/dot graphviz-tcl-2.16.1-0.5.fc9.ppc requires /bin/sh grass-6.3.0-0.4.RC6.fc9.ppc requires /usr/bin/python grass-6.3.0-0.4.RC6.fc9.ppc requires /bin/bash grass-6.3.0-0.4.RC6.fc9.ppc requires /bin/sh grass-libs-6.3.0-0.4.RC6.fc9.ppc requires /sbin/ldconfig grass-libs-6.3.0-0.4.RC6.fc9.ppc64 requires /sbin/ldconfig grep-2.5.1-59.fc9.ppc requires /bin/sh grep-2.5.1-59.fc9.ppc requires /sbin/install-info grepmail-5.3033-4.fc9.noarch requires /usr/bin/perl gresistor-0.0.1-11.fc8.noarch requires /bin/sh gresistor-0.0.1-11.fc8.noarch requires /usr/bin/python greyhounds-0.8-0.3.prealpha.fc9.ppc requires /bin/sh greylistd-0.8.3.2-8.fc7.noarch requires /bin/sh greylistd-0.8.3.2-8.fc7.noarch requires /bin/bash greylistd-0.8.3.2-8.fc7.noarch requires /sbin/chkconfig greylistd-0.8.3.2-8.fc7.noarch requires /usr/bin/python greylistd-0.8.3.2-8.fc7.noarch requires /sbin/service grhino-0.16.0-5.fc9.ppc requires /bin/sh gridengine-6.1u4-1.fc10.ppc requires /bin/sh gridengine-6.1u4-1.fc10.ppc requires /bin/ksh gridengine-6.1u4-1.fc10.ppc requires /usr/sbin/alternatives gridengine-6.1u4-1.fc10.ppc requires /bin/csh gridengine-6.1u4-1.fc10.ppc requires /sbin/ldconfig gridengine-6.1u4-1.fc10.ppc requires /usr/sbin/alternatives gridengine-6.1u4-1.fc10.ppc requires /bin/sh gridengine-6.1u4-1.fc10.ppc64 requires /bin/sh gridengine-6.1u4-1.fc10.ppc64 requires /bin/csh gridengine-6.1u4-1.fc10.ppc64 requires /bin/ksh gridengine-6.1u4-1.fc10.ppc64 requires /usr/sbin/alternatives gridengine-6.1u4-1.fc10.ppc64 requires /sbin/ldconfig gridengine-6.1u4-1.fc10.ppc64 requires /usr/sbin/alternatives gridengine-6.1u4-1.fc10.ppc64 requires /bin/sh gridengine-devel-6.1u4-1.fc10.ppc requires /bin/csh gridengine-devel-6.1u4-1.fc10.ppc requires /bin/sh gridengine-devel-6.1u4-1.fc10.ppc64 requires /bin/csh gridengine-devel-6.1u4-1.fc10.ppc64 requires /bin/sh gridengine-execd-6.1u4-1.fc10.ppc requires /bin/sh gridengine-execd-6.1u4-1.fc10.ppc requires /sbin/service gridengine-execd-6.1u4-1.fc10.ppc requires /bin/sh gridengine-execd-6.1u4-1.fc10.ppc requires /sbin/chkconfig gridengine-qmaster-6.1u4-1.fc10.ppc requires /bin/sh gridengine-qmaster-6.1u4-1.fc10.ppc requires /sbin/service gridengine-qmaster-6.1u4-1.fc10.ppc requires /bin/sh gridengine-qmaster-6.1u4-1.fc10.ppc requires /sbin/chkconfig grig-0.7.2-5.fc9.ppc requires /bin/sh grisbi-0.5.9-5.fc9.ppc requires /bin/sh groff-1.18.1.4-14.fc9.ppc requires /bin/sh groff-1.18.1.4-14.fc9.ppc requires /bin/sed groff-1.18.1.4-14.fc9.ppc requires /sbin/install-info groff-1.18.1.4-14.fc9.ppc requires /bin/bash groff-1.18.1.4-14.fc9.ppc requires /bin/sh groff-perl-1.18.1.4-14.fc9.ppc requires /usr/bin/perl groff-perl-1.18.1.4-14.fc9.ppc requires /bin/sh grsync-0.6.1-2.fc9.ppc requires /bin/bash gruler-0.8-3.fc9.noarch requires /usr/bin/ruby gruler-0.8-3.fc9.noarch requires /bin/bash gscan2pdf-0.9.21-2.fc9.noarch requires /bin/sh gscan2pdf-0.9.21-2.fc9.noarch requires /usr/bin/perl gshutdown-0.2-3.fc9.ppc requires /bin/sh gsl-1.10-10.fc9.ppc requires /sbin/ldconfig gsl-1.10-10.fc9.ppc64 requires /sbin/ldconfig gsl-devel-1.10-10.fc9.ppc requires /bin/sh gsl-devel-1.10-10.fc9.ppc requires /sbin/install-info gsl-devel-1.10-10.fc9.ppc requires /bin/sh gsl-devel-1.10-10.fc9.ppc64 requires /bin/sh gsl-devel-1.10-10.fc9.ppc64 requires /sbin/install-info gsl-devel-1.10-10.fc9.ppc64 requires /bin/sh gsm-1.0.12-6.fc9.ppc requires /sbin/ldconfig gsm-1.0.12-6.fc9.ppc64 requires /sbin/ldconfig gsoap-2.7.10-4.fc9.ppc requires /sbin/ldconfig gsoap-2.7.10-4.fc9.ppc64 requires /sbin/ldconfig gst-inspector-0.3-5.fc9.noarch requires /bin/sh gst-inspector-0.3-5.fc9.noarch requires /usr/bin/python gstream-1.6-2.fc9.ppc requires /sbin/ldconfig gstream-1.6-2.fc9.ppc64 requires /sbin/ldconfig gstream-devel-1.6-2.fc9.ppc requires /bin/sh gstream-devel-1.6-2.fc9.ppc requires /sbin/install-info gstream-devel-1.6-2.fc9.ppc64 requires /bin/sh gstream-devel-1.6-2.fc9.ppc64 requires /sbin/install-info gstreamer-0.10.19-1.fc9.ppc requires /sbin/ldconfig gstreamer-0.10.19-1.fc9.ppc requires /bin/sh gstreamer-0.10.19-1.fc9.ppc64 requires /sbin/ldconfig gstreamer-0.10.19-1.fc9.ppc64 requires /bin/sh gstreamer-devel-0.10.19-1.fc9.ppc requires /bin/sh gstreamer-devel-0.10.19-1.fc9.ppc64 requires /bin/sh gstreamer-plugins-base-0.10.19-1.fc9.ppc requires /usr/bin/perl gstreamer-plugins-base-0.10.19-1.fc9.ppc64 requires /usr/bin/perl gstreamer-plugins-farsight-0.12.8-1.fc10.ppc requires /sbin/ldconfig gstreamer-plugins-good-0.10.8-1.fc10.ppc requires /bin/sh gt5-1.4.0-4.fc9.noarch requires /bin/sh gthumb-2.10.8-3.fc10.ppc requires /bin/sh gthumb-2.10.8-3.fc10.ppc requires /bin/bash 1:gtk+-1.2.10-61.fc9.ppc requires /sbin/ldconfig 1:gtk+-1.2.10-61.fc9.ppc64 requires /sbin/ldconfig 1:gtk+-devel-1.2.10-61.fc9.ppc requires /bin/sh 1:gtk+-devel-1.2.10-61.fc9.ppc64 requires /bin/sh gtk+extra-2.1.1-8.fc9.ppc requires /sbin/ldconfig gtk+extra-2.1.1-8.fc9.ppc64 requires /sbin/ldconfig gtk-doc-1.10-1.fc10.noarch requires /bin/sh gtk-doc-1.10-1.fc10.noarch requires /usr/bin/perl gtk-doc-1.10-1.fc10.noarch requires /bin/sh gtk-doc-1.10-1.fc10.noarch requires /usr/bin/cmp gtk-doc-1.10-1.fc10.noarch requires /usr/bin/python gtk-recordmydesktop-0.3.7-1.fc9.noarch requires /usr/bin/python gtk-sharp-1.0.10-12.fc7.ppc requires /bin/sh gtk-sharp-gapi-1.0.10-12.fc7.ppc requires /usr/bin/perl gtk-sharp-gapi-1.0.10-12.fc7.ppc requires /bin/sh gtk-sharp2-2.10.3-2.fc9.ppc requires /sbin/ldconfig gtk-sharp2-gapi-2.10.3-2.fc9.ppc requires /usr/bin/perl gtk-sharp2-gapi-2.10.3-2.fc9.ppc requires /bin/sh gtk-vnc-0.3.6-1.fc10.ppc requires /sbin/ldconfig gtk-vnc-0.3.6-1.fc10.ppc64 requires /sbin/ldconfig gtk2-2.13.0-2.fc10.ppc requires /bin/sh gtk2-2.13.0-2.fc10.ppc requires /bin/sh gtk2-2.13.0-2.fc10.ppc64 requires /bin/sh gtk2-2.13.0-2.fc10.ppc64 requires /bin/sh gtk2-devel-2.13.0-2.fc10.ppc requires /usr/bin/env gtk2-devel-2.13.0-2.fc10.ppc64 requires /usr/bin/env gtkdatabox-0.8.2.2-2.fc9.ppc requires /sbin/ldconfig gtkdatabox-0.8.2.2-2.fc9.ppc64 requires /sbin/ldconfig gtkglarea2-1.99.0-8.fc9.ppc requires /sbin/ldconfig gtkglarea2-1.99.0-8.fc9.ppc64 requires /sbin/ldconfig gtkglext-libs-1.2.0-6.fc9.ppc requires /bin/sh gtkglext-libs-1.2.0-6.fc9.ppc64 requires /bin/sh gtkglextmm-1.2.0-6.fc9.ppc requires /sbin/ldconfig gtkglextmm-1.2.0-6.fc9.ppc requires /bin/sh gtkglextmm-1.2.0-6.fc9.ppc64 requires /bin/sh gtkglextmm-1.2.0-6.fc9.ppc64 requires /sbin/ldconfig gtkhtml2-2.11.1-3.fc9.ppc requires /sbin/ldconfig gtkhtml2-2.11.1-3.fc9.ppc64 requires /sbin/ldconfig gtkhtml3-3.23.2-4.fc10.ppc requires /sbin/ldconfig gtkhtml3-3.23.2-4.fc10.ppc64 requires /sbin/ldconfig gtkimageview-1.5.0-2.fc9.ppc requires /sbin/ldconfig gtkimageview-1.5.0-2.fc9.ppc64 requires /sbin/ldconfig gtkmathview-0.7.6-7.fc9.ppc requires /sbin/ldconfig gtkmathview-0.7.6-7.fc9.ppc64 requires /sbin/ldconfig gtkmm24-2.12.5-1.fc9.ppc requires /sbin/ldconfig gtkmm24-2.12.5-1.fc9.ppc64 requires /sbin/ldconfig gtkmozembedmm-1.4.2.cvs20060817-17.fc9.ppc requires /sbin/ldconfig gtkmozembedmm-1.4.2.cvs20060817-17.fc9.ppc64 requires /sbin/ldconfig gtkpod-0.99.12-2.fc9.ppc requires /usr/bin/python gtkpod-0.99.12-2.fc9.ppc requires /bin/bash gtkpod-0.99.12-2.fc9.ppc requires /bin/sh gtkpod-0.99.12-2.fc9.ppc requires /usr/bin/awk gtkpod-0.99.12-2.fc9.ppc requires /usr/bin/perl gtkpod-0.99.12-2.fc9.ppc requires /bin/sh 1:gtksourceview-1.8.5-4.fc9.ppc requires /sbin/ldconfig 1:gtksourceview-1.8.5-4.fc9.ppc64 requires /sbin/ldconfig gtksourceview2-2.2.1-1.fc9.ppc requires /sbin/ldconfig gtksourceview2-2.2.1-1.fc9.ppc64 requires /sbin/ldconfig gtkspell-2.0.11-8.fc9.ppc requires /sbin/ldconfig gtkspell-2.0.11-8.fc9.ppc64 requires /sbin/ldconfig gtkterm-0.99.5-9.fc9.ppc requires /bin/sh gtorrentviewer-0.2b-15.fc9.ppc requires /bin/sh gtranslator-1.1.7-8.fc9.ppc requires /bin/sh gtranslator-1.1.7-8.fc9.ppc requires /bin/sh gts-0.7.6-9.fc9.ppc requires /sbin/ldconfig gts-0.7.6-9.fc9.ppc requires /bin/sh gts-0.7.6-9.fc9.ppc64 requires /sbin/ldconfig gts-0.7.6-9.fc9.ppc64 requires /bin/sh gts-devel-0.7.6-9.fc9.ppc requires /bin/sh gts-devel-0.7.6-9.fc9.ppc64 requires /bin/sh gtypist-2.7-6.fc9.ppc requires /bin/sh gtypist-2.7-6.fc9.ppc requires /usr/bin/perl gtypist-2.7-6.fc9.ppc requires /sbin/install-info gucharmap-2.22.1-1.fc9.ppc requires /bin/sh gucharmap-2.22.1-1.fc9.ppc64 requires /bin/sh guichan-0.7.1-1.fc9.ppc requires /sbin/ldconfig guichan-0.7.1-1.fc9.ppc64 requires /sbin/ldconfig 5:guile-1.8.5-1.fc10.ppc requires /bin/sh 5:guile-1.8.5-1.fc10.ppc requires /sbin/install-info 5:guile-1.8.5-1.fc10.ppc requires /sbin/ldconfig 5:guile-1.8.5-1.fc10.ppc requires /bin/sh 5:guile-1.8.5-1.fc10.ppc64 requires /bin/sh 5:guile-1.8.5-1.fc10.ppc64 requires /sbin/install-info 5:guile-1.8.5-1.fc10.ppc64 requires /sbin/ldconfig 5:guile-1.8.5-1.fc10.ppc64 requires /bin/sh guile-cairo-1.4.0-6.fc9.ppc requires /sbin/ldconfig guile-cairo-1.4.0-6.fc9.ppc requires /sbin/install-info guile-cairo-1.4.0-6.fc9.ppc requires /bin/sh guile-cairo-1.4.0-6.fc9.ppc64 requires /bin/sh guile-cairo-1.4.0-6.fc9.ppc64 requires /sbin/ldconfig guile-cairo-1.4.0-6.fc9.ppc64 requires /sbin/install-info 5:guile-devel-1.8.5-1.fc10.ppc requires /usr/bin/guile 5:guile-devel-1.8.5-1.fc10.ppc requires /bin/sh 5:guile-devel-1.8.5-1.fc10.ppc64 requires /usr/bin/guile 5:guile-devel-1.8.5-1.fc10.ppc64 requires /bin/sh guile-gnome-platform-2.15.93-6.fc8.ppc requires /bin/sh guile-gnome-platform-2.15.93-6.fc8.ppc requires /sbin/install-info guile-gnome-platform-2.15.93-6.fc8.ppc requires /sbin/ldconfig guile-gnome-platform-2.15.93-6.fc8.ppc requires /bin/sh guile-lib-0.1.6-1.fc9.noarch requires /bin/sh guile-lib-0.1.6-1.fc9.noarch requires /sbin/install-info guilt-0.30-1.fc8.noarch requires /bin/sh gutenprint-5.0.2-2.fc9.ppc requires /sbin/ldconfig gutenprint-5.0.2-2.fc9.ppc64 requires /sbin/ldconfig gutenprint-cups-5.0.2-2.fc9.ppc requires /bin/sh gutenprint-cups-5.0.2-2.fc9.ppc requires /usr/bin/perl gutenprint-foomatic-5.0.2-2.fc9.ppc requires /bin/sh gutenprint-foomatic-5.0.2-2.fc9.ppc requires /usr/bin/python gv-3.6.3-3.fc9.ppc requires /bin/sh gv-3.6.3-3.fc9.ppc requires /sbin/install-info gv-3.6.3-3.fc9.ppc requires /usr/bin/update-desktop-database gv-3.6.3-3.fc9.ppc requires /usr/bin/update-mime-database gvfs-0.2.3-10.fc10.ppc requires /bin/sh gvfs-0.2.3-10.fc10.ppc requires /bin/sh gvfs-0.2.3-10.fc10.ppc64 requires /bin/sh gvfs-0.2.3-10.fc10.ppc64 requires /bin/sh gwave-2-7.20070514snap.fc9.ppc requires /usr/bin/perl gwave-2-7.20070514snap.fc9.ppc requires /bin/sh gwenhywfar-2.6.2-2.fc9.ppc requires /sbin/ldconfig gwenhywfar-2.6.2-2.fc9.ppc64 requires /sbin/ldconfig gwenhywfar-devel-2.6.2-2.fc9.ppc requires /bin/sh gwenhywfar-devel-2.6.2-2.fc9.ppc64 requires /bin/sh gwget-0.99-5.fc9.ppc requires /bin/sh gxine-0.5.902-1.fc10.ppc requires /bin/sh gypsy-0.6-3.fc10.ppc requires /sbin/ldconfig gypsy-0.6-3.fc10.ppc64 requires /sbin/ldconfig gzip-1.3.12-6.fc9.ppc requires /bin/sh gzip-1.3.12-6.fc9.ppc requires /bin/sh gzip-1.3.12-6.fc9.ppc requires /sbin/install-info hackedbox-0.8.5-5.fc9.ppc requires /bin/bash hackedbox-0.8.5-5.fc9.ppc requires /bin/sh haddock-2.0.0.0-2.fc9.ppc requires /bin/sh hal-0.5.11-1.fc10.ppc requires /bin/sh hal-0.5.11-1.fc10.ppc requires /usr/sbin/useradd hal-0.5.11-1.fc10.ppc requires /usr/bin/polkit-auth hal-0.5.11-1.fc10.ppc requires /sbin/ldconfig hal-0.5.11-1.fc10.ppc requires /bin/bash hal-0.5.11-1.fc10.ppc requires /bin/sh hal-cups-utils-0.6.16-3.fc9.ppc requires /bin/sh hal-cups-utils-0.6.16-3.fc9.ppc requires /bin/env hal-cups-utils-0.6.16-3.fc9.ppc requires /bin/sh halberd-0.2.2-2.fc8.noarch requires /usr/bin/python halevt-0.0.8-1.fc9.ppc requires /bin/sh halevt-0.0.8-1.fc9.ppc requires /sbin/chkconfig halevt-0.0.8-1.fc9.ppc requires /bin/sh halevt-0.0.8-1.fc9.ppc requires /sbin/service hamlib-1.2.7-1.fc9.ppc requires /sbin/ldconfig hamlib-1.2.7-1.fc9.ppc64 requires /sbin/ldconfig hamlib-c++-1.2.7-1.fc9.ppc requires /sbin/ldconfig hamlib-c++-1.2.7-1.fc9.ppc64 requires /sbin/ldconfig hamlib-tcl-1.2.7-1.fc9.ppc requires /sbin/ldconfig hamster-applet-0.4-1.fc10.ppc requires /usr/bin/env hamster-applet-0.4-1.fc10.ppc requires /bin/sh haproxy-1.3.14.3-1.fc9.ppc requires /bin/sh haproxy-1.3.14.3-1.fc9.ppc requires /sbin/chkconfig haproxy-1.3.14.3-1.fc9.ppc requires /usr/sbin/useradd haproxy-1.3.14.3-1.fc9.ppc requires /bin/sh haproxy-1.3.14.3-1.fc9.ppc requires /sbin/service harminv-1.3.1-10.fc9.ppc requires /sbin/ldconfig harminv-1.3.1-10.fc9.ppc64 requires /sbin/ldconfig hatari-1.0.1-1.fc9.ppc requires /bin/sh hawknl-1.68-3.fc9.ppc requires /sbin/ldconfig hawknl-1.68-3.fc9.ppc64 requires /sbin/ldconfig hddtemp-0.3-0.15.beta15.fc9.ppc requires /bin/sh hddtemp-0.3-0.15.beta15.fc9.ppc requires /usr/bin/consolehelper hddtemp-0.3-0.15.beta15.fc9.ppc requires /bin/bash hddtemp-0.3-0.15.beta15.fc9.ppc requires /sbin/chkconfig hdf-4.2r3-2.fc9.ppc requires /bin/sh hdf5-1.8.0.snap5-2.fc10.ppc requires /sbin/ldconfig hdf5-1.8.0.snap5-2.fc10.ppc64 requires /sbin/ldconfig hdf5-devel-1.8.0.snap5-2.fc10.ppc requires /bin/bash hdf5-devel-1.8.0.snap5-2.fc10.ppc requires /bin/sh hdf5-devel-1.8.0.snap5-2.fc10.ppc64 requires /bin/bash hdf5-devel-1.8.0.snap5-2.fc10.ppc64 requires /bin/sh heartbeat-2.1.3-1.fc9.ppc requires /bin/sh heartbeat-2.1.3-1.fc9.ppc requires /usr/bin/python heartbeat-2.1.3-1.fc9.ppc requires /sbin/ldconfig heartbeat-2.1.3-1.fc9.ppc requires /bin/sh heartbeat-2.1.3-1.fc9.ppc requires /sbin/chkconfig heartbeat-2.1.3-1.fc9.ppc64 requires /bin/sh heartbeat-2.1.3-1.fc9.ppc64 requires /usr/bin/python heartbeat-2.1.3-1.fc9.ppc64 requires /sbin/ldconfig heartbeat-2.1.3-1.fc9.ppc64 requires /bin/sh heartbeat-2.1.3-1.fc9.ppc64 requires /sbin/chkconfig heartbeat-gui-2.1.3-1.fc9.ppc requires /usr/bin/python hedgewars-0.9.3-1.fc10.ppc requires /bin/sh help2man-1.36.4-2.fc9.noarch requires /usr/bin/perl help2man-1.36.4-2.fc9.noarch requires /sbin/install-info help2man-1.36.4-2.fc9.noarch requires /bin/sh hercules-3.05-4.fc9.ppc requires /usr/bin/perl hercules-3.05-4.fc9.ppc requires /bin/sh hesinfo-3.1.0-3.ppc requires /sbin/ldconfig hesiod-3.1.0-10.ppc requires /sbin/ldconfig hesiod-3.1.0-10.ppc64 requires /sbin/ldconfig hevea-1.10-1.fc9.ppc requires /usr/bin/texhash hevea-1.10-1.fc9.ppc requires /bin/sh hfsutils-3.2.6-14.fc9.ppc requires /bin/sh hgsvn-0.1.5-3.fc9.noarch requires /usr/bin/python hicolor-icon-theme-0.10-4.noarch requires /bin/sh higlayout-1.0-2.fc9.ppc requires /bin/sh higlayout-javadoc-1.0-2.fc9.ppc requires /bin/sh hippo-canvas-0.2.31-1.fc10.ppc requires /sbin/ldconfig hippo-canvas-0.2.31-1.fc10.ppc64 requires /sbin/ldconfig homebank-3.8-1.fc9.ppc requires /bin/sh horde-3.1.7-2.fc9.noarch requires /bin/sh horde-3.1.7-2.fc9.noarch requires /usr/bin/php horde-3.1.7-2.fc9.noarch requires /bin/sh horde-3.1.7-2.fc9.noarch requires /sbin/service hotwire-0.721-1.fc9.noarch requires /bin/sh hotwire-0.721-1.fc9.noarch requires /usr/bin/python hpic-0.52.2-6.fc9.ppc requires /sbin/ldconfig hpic-0.52.2-6.fc9.ppc64 requires /sbin/ldconfig hplip-2.8.2-3.fc10.ppc requires /bin/sh hplip-2.8.2-3.fc10.ppc requires /usr/bin/env hplip-2.8.2-3.fc10.ppc requires /usr/bin/python hplip-2.8.2-3.fc10.ppc requires /sbin/service hplip-2.8.2-3.fc10.ppc requires /sbin/chkconfig hplip-gui-2.8.2-3.fc10.ppc requires /bin/sh hplip-gui-2.8.2-3.fc10.ppc requires /usr/bin/env hspell-1.0-8.fc9.ppc requires /usr/bin/perl 1:hsqldb-1.8.0.9-2jpp.1.fc9.ppc requires /bin/sh 1:hsqldb-1.8.0.9-2jpp.1.fc9.ppc requires /bin/ln 1:hsqldb-1.8.0.9-2jpp.1.fc9.ppc requires /bin/rm 1:hsqldb-1.8.0.9-2jpp.1.fc9.ppc requires /bin/sh 1:hsqldb-demo-1.8.0.9-2jpp.1.fc9.ppc requires /bin/sh 1:hsqldb-javadoc-1.8.0.9-2jpp.1.fc9.ppc requires /bin/sh 1:hsqldb-javadoc-1.8.0.9-2jpp.1.fc9.ppc requires /bin/rm 1:hsqldb-javadoc-1.8.0.9-2jpp.1.fc9.ppc requires /bin/ln ht2html-2.0-5.fc6.noarch requires /bin/sh ht2html-2.0-5.fc6.noarch requires /usr/bin/env 4:htdig-3.2.0-0.1.b6.fc10.ppc requires /bin/sh html-xml-utils-3.7-5.fc9.ppc requires /bin/bash html-xml-utils-3.7-5.fc9.ppc requires /usr/bin/perl html2ps-1.0-0.1.b5.fc10.noarch requires /usr/bin/perl html401-dtds-4.01-19991224.5.noarch requires /bin/sh html401-dtds-4.01-19991224.5.noarch requires /usr/bin/install-catalog htmldoc-1.8.27-6.fc9.ppc requires /bin/sh htmlview-4.0.0-3.fc7.noarch requires /bin/bash httpd-2.2.8-3.ppc requires /bin/sh httpd-2.2.8-3.ppc requires /usr/sbin/useradd httpd-2.2.8-3.ppc requires /etc/mime.types httpd-2.2.8-3.ppc requires /bin/bash httpd-2.2.8-3.ppc requires /bin/sh httpd-devel-2.2.8-3.ppc requires /usr/bin/perl httpd-devel-2.2.8-3.ppc requires /bin/sh httpd-devel-2.2.8-3.ppc64 requires /usr/bin/perl httpd-devel-2.2.8-3.ppc64 requires /bin/sh httrack-3.42-9.fc9.ppc requires /sbin/ldconfig httrack-3.42-9.fc9.ppc requires /bin/bash httrack-3.42-9.fc9.ppc64 requires /sbin/ldconfig httrack-3.42-9.fc9.ppc64 requires /bin/bash hugin-0.7.0-0.3.20080218svn.fc9.ppc requires /bin/sh hugin-base-0.7.0-0.3.20080218svn.fc9.ppc requires /sbin/ldconfig hugin-base-0.7.0-0.3.20080218svn.fc9.ppc requires /bin/sh hugin-base-0.7.0-0.3.20080218svn.fc9.ppc64 requires /sbin/ldconfig hugin-base-0.7.0-0.3.20080218svn.fc9.ppc64 requires /bin/sh hugs98-2006.09-4.fc9.ppc requires /bin/sh hunspell-1.2.2-3.fc10.ppc requires /sbin/ldconfig hunspell-1.2.2-3.fc10.ppc64 requires /sbin/ldconfig hunspell-devel-1.2.2-3.fc10.ppc requires /usr/bin/perl hunspell-devel-1.2.2-3.fc10.ppc64 requires /usr/bin/perl hunt-1.5-7.fc9.ppc requires /bin/sh hwbrowser-0.42-1.fc9.noarch requires /bin/sh hydrogen-0.9.3-13.fc9.ppc requires /bin/sh hydrogen-0.9.3-13.fc9.ppc requires /bin/sh hyperestraier-1.4.13-2.fc9.ppc requires /sbin/ldconfig hyperestraier-1.4.13-2.fc9.ppc requires /bin/sh hyperestraier-1.4.13-2.fc9.ppc64 requires /sbin/ldconfig hyperestraier-1.4.13-2.fc9.ppc64 requires /bin/sh hyperestraier-devel-1.4.13-2.fc9.ppc requires /bin/sh hyperestraier-devel-1.4.13-2.fc9.ppc64 requires /bin/sh hyperestraier-java-1.4.13-2.fc9.ppc requires /sbin/ldconfig hyperestraier-java-1.4.13-2.fc9.ppc64 requires /sbin/ldconfig hyperestraier-perl-1.4.13-2.fc9.ppc requires /usr/bin/perl hyphen-2.4-1.fc10.ppc requires /sbin/ldconfig hyphen-2.4-1.fc10.ppc64 requires /sbin/ldconfig hyphen-devel-2.4-1.fc10.ppc requires /usr/bin/perl hyphen-devel-2.4-1.fc10.ppc64 requires /usr/bin/perl i2c-tools-3.0.0-3.fc9.ppc requires /usr/bin/perl ibmonitor-1.4-1.noarch requires /usr/bin/perl ice-3.2.1-17.fc9.ppc requires /usr/bin/env ice-3.2.1-17.fc9.ppc requires /sbin/ldconfig ice-servers-3.2.1-17.fc9.ppc requires /bin/sh ice-servers-3.2.1-17.fc9.ppc requires /bin/bash ice-servers-3.2.1-17.fc9.ppc requires /sbin/chkconfig ice-servers-3.2.1-17.fc9.ppc requires /sbin/service icecast-2.3.1-5.fc9.ppc requires /bin/sh icecast-2.3.1-5.fc9.ppc requires /usr/sbin/useradd icecast-2.3.1-5.fc9.ppc requires /sbin/service icecast-2.3.1-5.fc9.ppc requires /bin/sh icecast-2.3.1-5.fc9.ppc requires /sbin/chkconfig icecream-0.8.0-11.20080117svn.fc9.ppc requires /bin/sh icecream-0.8.0-11.20080117svn.fc9.ppc requires /usr/bin/env icecream-0.8.0-11.20080117svn.fc9.ppc requires /bin/sh icecream-0.8.0-11.20080117svn.fc9.ppc64 requires /bin/sh icecream-0.8.0-11.20080117svn.fc9.ppc64 requires /usr/bin/env icecream-0.8.0-11.20080117svn.fc9.ppc64 requires /bin/sh icedax-1.1.6-11.fc9.ppc requires /bin/sh icedax-1.1.6-11.fc9.ppc requires /usr/sbin/alternatives icedax-1.1.6-11.fc9.ppc requires /bin/sh icegrid-gui-3.2.1-17.fc9.ppc requires /bin/sh ices-2.0.1-6.fc9.ppc requires /bin/sh ices-2.0.1-6.fc9.ppc requires /sbin/service ices-2.0.1-6.fc9.ppc requires /bin/sh ices-2.0.1-6.fc9.ppc requires /sbin/chkconfig icewm-xdgmenu-1.2.35-4.fc9.ppc requires /bin/sh icewm-xdgmenu-1.2.35-4.fc9.ppc requires /usr/bin/python icon-naming-utils-0.8.6-2.fc9.noarch requires /usr/bin/perl icu4j-3.6.1-2jpp.6.fc9.ppc requires /bin/sh id3lib-3.8.3-20.fc9.ppc requires /sbin/ldconfig id3lib-3.8.3-20.fc9.ppc64 requires /sbin/ldconfig idw-gpl-1.5.0-5.fc10.ppc requires /bin/sh ifd-egate-0.05-20.ppc requires /bin/sh ifm-5.1-6.fc9.ppc requires /usr/bin/wish ifm-5.1-6.fc9.ppc requires /usr/bin/perl ifplugd-0.28-11.fc9.ppc requires /bin/sh ifplugd-0.28-11.fc9.ppc requires /bin/bash ifplugd-0.28-11.fc9.ppc requires /bin/sh igraph-0.5-13.fc9.ppc requires /sbin/install-info igraph-0.5-13.fc9.ppc requires /sbin/ldconfig igraph-0.5-13.fc9.ppc64 requires /sbin/ldconfig igraph-0.5-13.fc9.ppc64 requires /sbin/install-info igraph-devel-0.5-13.fc9.ppc requires /bin/sh igraph-devel-0.5-13.fc9.ppc64 requires /bin/sh iksemel-1.3-4.fc9.ppc requires /sbin/ldconfig iksemel-1.3-4.fc9.ppc64 requires /sbin/ldconfig iksemel-devel-1.3-4.fc9.ppc requires /sbin/install-info iksemel-devel-1.3-4.fc9.ppc requires /bin/sh iksemel-devel-1.3-4.fc9.ppc64 requires /sbin/install-info iksemel-devel-1.3-4.fc9.ppc64 requires /bin/sh ilmbase-1.0.1-2.fc9.ppc requires /sbin/ldconfig ilmbase-1.0.1-2.fc9.ppc64 requires /sbin/ldconfig im-chooser-0.99.6-4.fc10.ppc requires /usr/sbin/alternatives imake-1.0.2-6.fc9.ppc requires /usr/bin/perl imake-1.0.2-6.fc9.ppc requires /bin/sh imapsync-1.249-1.fc8.noarch requires /usr/bin/perl 1:imlib-1.9.15-7.fc9.ppc requires /sbin/ldconfig 1:imlib-1.9.15-7.fc9.ppc64 requires /sbin/ldconfig 1:imlib-devel-1.9.15-7.fc9.ppc requires /usr/share/aclocal 1:imlib-devel-1.9.15-7.fc9.ppc requires /bin/sh 1:imlib-devel-1.9.15-7.fc9.ppc64 requires /usr/share/aclocal 1:imlib-devel-1.9.15-7.fc9.ppc64 requires /bin/sh imlib2-1.4.0-5.fc9.ppc requires /sbin/ldconfig imlib2-1.4.0-5.fc9.ppc64 requires /sbin/ldconfig imlib2-devel-1.4.0-5.fc9.ppc requires /bin/sh imlib2-devel-1.4.0-5.fc9.ppc64 requires /bin/sh imsettings-0.99.6-4.fc10.ppc requires /bin/dbus-send imsettings-0.99.6-4.fc10.ppc requires /bin/sh imsettings-libs-0.99.6-4.fc10.ppc requires /sbin/ldconfig imsettings-libs-0.99.6-4.fc10.ppc64 requires /sbin/ldconfig inadyn-1.96.2-3.fc9.ppc requires /bin/sh inadyn-1.96.2-3.fc9.ppc requires /sbin/chkconfig inadyn-1.96.2-3.fc9.ppc requires /sbin/service inchi-1.0.2-0.3.fc9.ppc requires /sbin/ldconfig inchi-1.0.2-0.3.fc9.ppc64 requires /sbin/ldconfig incollector-1.0-6.fc9.ppc requires /bin/sh inconsolata-fonts-1.009-1.fc9.noarch requires /bin/sh incron-0.5.7-1.fc9.ppc requires /bin/sh incron-0.5.7-1.fc9.ppc requires /bin/bash incron-0.5.7-1.fc9.ppc requires /sbin/chkconfig incron-0.5.7-1.fc9.ppc requires /sbin/service indent-2.2.10-1.fc9.ppc requires /bin/sh indent-2.2.10-1.fc9.ppc requires /sbin/install-info info-4.12-1.fc10.ppc requires /bin/sh initng-0.6.10.2-2.fc9.ppc requires /bin/sh initng-0.6.10.2-2.fc9.ppc requires /bin/sh initng-conf-gtk-0.5.1-4.fc9.ppc requires /bin/sh initng-ifiles-0.1.4-5.fc9.ppc requires /bin/sh initng-ifiles-0.1.4-5.fc9.ppc requires /bin/sh initng-ifiles-0.1.4-5.fc9.ppc requires /sbin/ldconfig initng-ifiles-0.1.4-5.fc9.ppc requires /bin/bash initng-lib-0.6.10.2-2.fc9.ppc requires /sbin/ldconfig initng-lib-0.6.10.2-2.fc9.ppc64 requires /sbin/ldconfig initscripts-8.76.1-1.ppc requires /bin/sh initscripts-8.76.1-1.ppc requires /bin/sed initscripts-8.76.1-1.ppc requires /etc/redhat-release initscripts-8.76.1-1.ppc requires /sbin/runuser initscripts-8.76.1-1.ppc requires /sbin/sysctl initscripts-8.76.1-1.ppc requires /bin/awk initscripts-8.76.1-1.ppc requires /bin/sed initscripts-8.76.1-1.ppc requires /sbin/pidof initscripts-8.76.1-1.ppc requires /sbin/fuser initscripts-8.76.1-1.ppc requires /bin/bash initscripts-8.76.1-1.ppc requires /sbin/arping initscripts-8.76.1-1.ppc requires /bin/sh initscripts-8.76.1-1.ppc requires /bin/grep initscripts-8.76.1-1.ppc requires /bin/find initscripts-8.76.1-1.ppc requires /usr/sbin/groupadd initscripts-8.76.1-1.ppc requires /sbin/chkconfig initscripts-8.76.1-1.ppc requires /sbin/ip inkscape-0.46-2.fc9.ppc requires /usr/bin/perl inkscape-0.46-2.fc9.ppc requires /bin/sh inkscape-0.46-2.fc9.ppc requires /usr/bin/env inkscape-0.46-2.fc9.ppc requires /bin/sh inn-2.4.4-1.fc10.ppc requires /bin/sh inn-2.4.4-1.fc10.ppc requires /usr/lib/news/lib/innshellvars.pl inn-2.4.4-1.fc10.ppc requires /bin/bash inn-2.4.4-1.fc10.ppc requires /bin/sh inn-2.4.4-1.fc10.ppc requires /usr/bin/perl innotop-1.6.0-2.fc9.noarch requires /usr/bin/perl inotify-tools-3.13-1.fc9.ppc requires /sbin/ldconfig inotify-tools-3.13-1.fc9.ppc64 requires /sbin/ldconfig international-time-0.0.2-4.fc8.noarch requires /bin/sh international-time-0.0.2-4.fc8.noarch requires /usr/bin/python intltool-0.37.1-1.fc9.ppc requires /usr/bin/perl intltool-0.37.1-1.fc9.ppc requires /bin/sh iotop-0.1-3.fc9.noarch requires /usr/bin/python iozone-3-5.fc9.ppc requires /bin/sh ip-sentinel-0.12-11.fc9.ppc requires /bin/sh ip-sentinel-sysv-0.12-11.fc9.ppc requires /bin/sh ip-sentinel-sysv-0.12-11.fc9.ppc requires /bin/bash ip-sentinel-sysv-0.12-11.fc9.ppc requires /sbin/chkconfig ipa-admintools-1.0.0-5.fc10.ppc requires /usr/bin/python ipa-client-1.0.0-5.fc10.ppc requires /usr/bin/python ipa-radius-admintools-1.0.0-5.fc10.ppc requires /usr/bin/python ipa-radius-server-1.0.0-5.fc10.ppc requires /usr/bin/python ipa-server-1.0.0-5.fc10.ppc requires /bin/sh ipa-server-1.0.0-5.fc10.ppc requires /usr/bin/python ipa-server-1.0.0-5.fc10.ppc requires /bin/sh ipa-server-selinux-1.0.0-5.fc10.ppc requires /bin/sh ipcalculator-0.41-6.fc9.noarch requires /usr/bin/perl ipcalculator-cgi-0.41-6.fc9.noarch requires /usr/bin/perl ipe-6.0-0.24.pre30.fc9.ppc requires /sbin/ldconfig ipe-6.0-0.24.pre30.fc9.ppc64 requires /sbin/ldconfig iproute-2.6.25-1.fc10.ppc requires /bin/bash iprutils-2.2.8-2.fc9.ppc requires /bin/sh iprutils-2.2.8-2.fc9.ppc requires /bin/sh ipsec-tools-0.7-13.fc9.ppc requires /bin/sh ipsec-tools-0.7-13.fc9.ppc requires /bin/bash ipsec-tools-0.7-13.fc9.ppc requires /bin/sh iptables-1.4.0-4.fc9.ppc requires /bin/sh iptables-1.4.0-4.fc9.ppc requires /bin/sh iptables-ipv6-1.4.0-4.fc9.ppc requires /bin/sh iptables-ipv6-1.4.0-4.fc9.ppc requires /bin/sh iputils-20071127-2.fc9.ppc requires /bin/sh iputils-20071127-2.fc9.ppc requires /bin/bash iputils-20071127-2.fc9.ppc requires /sbin/chkconfig iputils-20071127-2.fc9.ppc requires /sbin/service ipv6calc-0.71.0-2.fc9.ppc requires /usr/bin/perl ipv6calc-0.71.0-2.fc9.ppc requires /bin/sh ipvsadm-1.24-11.ppc requires /bin/sh ipvsadm-1.24-11.ppc requires /bin/bash ipvsadm-1.24-11.ppc requires /sbin/chkconfig ipvsadm-1.24-11.ppc requires /bin/sh ipxripd-0.8-5.fc9.ppc requires /bin/sh ipxripd-0.8-5.fc9.ppc requires /sbin/chkconfig ipxripd-0.8-5.fc9.ppc requires /bin/sh ipxripd-0.8-5.fc9.ppc requires /sbin/service ipython-0.8.2-1.fc9.noarch requires /usr/bin/env ipython-0.8.2-1.fc9.noarch requires /usr/bin/python ircd-hybrid-7.2.3-5.fc9.ppc requires /bin/sh ircd-hybrid-7.2.3-5.fc9.ppc requires /sbin/service ircd-hybrid-7.2.3-5.fc9.ppc requires /bin/sh ircd-hybrid-7.2.3-5.fc9.ppc requires /sbin/chkconfig irda-utils-0.9.18-4.fc9.ppc requires /bin/sh irda-utils-0.9.18-4.fc9.ppc requires /sbin/chkconfig irda-utils-0.9.18-4.fc9.ppc requires /bin/sh 2:irqbalance-0.55-9.fc10.ppc requires /bin/sh 2:irqbalance-0.55-9.fc10.ppc requires /sbin/chkconfig 2:irqbalance-0.55-9.fc10.ppc requires /bin/sh 2:irqbalance-0.55-9.fc10.ppc requires /sbin/service irsim-9.7.50-2.fc9.ppc requires /bin/sh iscsi-initiator-utils-6.2.0.868-0.7.fc9.ppc requires /bin/sh iscsi-initiator-utils-6.2.0.868-0.7.fc9.ppc requires /bin/sh iscsi-initiator-utils-6.2.0.868-0.7.fc9.ppc requires /sbin/service isdn4k-utils-3.2-58.fc9.ppc requires /bin/sh isdn4k-utils-3.2-58.fc9.ppc requires /bin/ln isdn4k-utils-3.2-58.fc9.ppc requires /sbin/ldconfig isdn4k-utils-3.2-58.fc9.ppc requires /bin/bash isdn4k-utils-3.2-58.fc9.ppc requires /bin/sh isdn4k-utils-3.2-58.fc9.ppc requires /usr/bin/perl isdn4k-utils-3.2-58.fc9.ppc requires /sbin/chkconfig isdn4k-utils-3.2-58.fc9.ppc64 requires /bin/sh isdn4k-utils-3.2-58.fc9.ppc64 requires /bin/ln isdn4k-utils-3.2-58.fc9.ppc64 requires /sbin/ldconfig isdn4k-utils-3.2-58.fc9.ppc64 requires /bin/bash isdn4k-utils-3.2-58.fc9.ppc64 requires /bin/sh isdn4k-utils-3.2-58.fc9.ppc64 requires /usr/bin/perl isdn4k-utils-3.2-58.fc9.ppc64 requires /sbin/chkconfig isicom-3.05-20.fc9.ppc requires /bin/sh isicom-3.05-20.fc9.ppc requires /sbin/chkconfig isicom-3.05-20.fc9.ppc requires /bin/sh isicom-3.05-20.fc9.ppc requires /sbin/service isight-firmware-tools-1.0.2-2.fc9.ppc requires /bin/sh isight-firmware-tools-1.0.2-2.fc9.ppc requires /sbin/install-info isns-utils-0.91-0.0.fc9.ppc requires /bin/sh isns-utils-0.91-0.0.fc9.ppc requires /sbin/service isns-utils-0.91-0.0.fc9.ppc requires /sbin/chkconfig isns-utils-0.91-0.0.fc9.ppc requires /bin/sh isomaster-1.3.1-1.fc9.ppc requires /bin/sh isomaster-1.3.1-1.fc9.ppc requires /bin/sh istanbul-0.2.2-7.fc10.ppc requires /usr/bin/python isync-1.0.4-1.fc9.ppc requires /bin/sh itpp-4.0.0-2.fc9.ppc requires /sbin/ldconfig itpp-4.0.0-2.fc9.ppc64 requires /sbin/ldconfig itpp-devel-4.0.0-2.fc9.ppc requires /bin/sh itpp-devel-4.0.0-2.fc9.ppc64 requires /bin/sh iverilog-0.9.20080314-1.fc9.ppc requires /bin/sh iwidgets-4.0.2-1.fc9.noarch requires /bin/sh jabberd-2.1.23-1.fc9.ppc requires /bin/sh jabberd-2.1.23-1.fc9.ppc requires /sbin/service jabberd-2.1.23-1.fc9.ppc requires /bin/bash jabbim-0.4-0.4.20080407svn.fc9.noarch requires /bin/sh jabbim-0.4-0.4.20080407svn.fc9.noarch requires /usr/bin/env jabbim-0.4-0.4.20080407svn.fc9.noarch requires /bin/sh jabbin-2.0-0.6.beta2a.fc9.ppc requires /bin/sh jack-audio-connection-kit-0.109.2-1.fc9.1.ppc requires /bin/sh jack-audio-connection-kit-0.109.2-1.fc9.1.ppc requires /sbin/ldconfig jack-audio-connection-kit-0.109.2-1.fc9.1.ppc64 requires /bin/sh jack-audio-connection-kit-0.109.2-1.fc9.1.ppc64 requires /sbin/ldconfig jack-rack-1.4.7-1.fc9.ppc requires /usr/bin/python jadetex-3.13-2.fc9.noarch requires /bin/sh jadetex-3.13-2.fc9.noarch requires /bin/sh jakarta-commons-beanutils-1.7.0-6jpp.1.ppc requires /bin/sh jakarta-commons-beanutils-javadoc-1.7.0-6jpp.1.ppc requires /bin/sh jakarta-commons-beanutils-javadoc-1.7.0-6jpp.1.ppc requires /bin/rm jakarta-commons-beanutils-javadoc-1.7.0-6jpp.1.ppc requires /bin/ln jakarta-commons-cli-1.0-7jpp_10.fc9.ppc requires /usr/bin/rebuild-gcj-db jakarta-commons-codec-1.3-9jpp.2.fc9.ppc requires /bin/sh jakarta-commons-collections-3.2-2jpp.2.fc9.ppc requires /bin/sh jakarta-commons-collections-testframework-3.2-2jpp.2.fc9.ppc requires /bin/sh jakarta-commons-collections-tomcat5-3.2-2jpp.2.fc9.ppc requires /bin/sh 1:jakarta-commons-daemon-1.0.1-6jpp.5.fc9.ppc requires /bin/sh 1:jakarta-commons-daemon-javadoc-1.0.1-6jpp.5.fc9.ppc requires /bin/rm 1:jakarta-commons-daemon-javadoc-1.0.1-6jpp.5.fc9.ppc requires /bin/ln jakarta-commons-dbcp-1.2.1-11jpp.3.fc9.ppc requires /bin/sh jakarta-commons-dbcp-1.2.1-11jpp.3.fc9.ppc requires /usr/sbin/update-alternatives jakarta-commons-dbcp-javadoc-1.2.1-11jpp.3.fc9.ppc requires /bin/rm jakarta-commons-dbcp-javadoc-1.2.1-11jpp.3.fc9.ppc requires /bin/ln jakarta-commons-dbcp-tomcat5-1.2.1-11jpp.3.fc9.ppc requires /bin/sh jakarta-commons-digester-1.7-7jpp.2.ppc requires /bin/sh jakarta-commons-digester-javadoc-1.7-7jpp.2.ppc requires /bin/sh jakarta-commons-digester-javadoc-1.7-7jpp.2.ppc requires /bin/rm jakarta-commons-digester-javadoc-1.7-7jpp.2.ppc requires /bin/ln 1:jakarta-commons-discovery-0.4-3jpp.1.fc9.ppc requires /bin/sh 1:jakarta-commons-discovery-javadoc-0.4-3jpp.1.fc9.ppc requires /bin/rm 1:jakarta-commons-discovery-javadoc-0.4-3jpp.1.fc9.ppc requires /bin/ln jakarta-commons-el-1.0-9jpp.2.fc9.ppc requires /bin/sh jakarta-commons-el-javadoc-1.0-9jpp.2.fc9.ppc requires /bin/sh jakarta-commons-el-javadoc-1.0-9jpp.2.fc9.ppc requires /bin/ln jakarta-commons-el-javadoc-1.0-9jpp.2.fc9.ppc requires /bin/rm 1:jakarta-commons-fileupload-1.0-7jpp.2.fc9.ppc requires /bin/sh 1:jakarta-commons-httpclient-3.1-0jpp.1.fc9.ppc requires /bin/sh 1:jakarta-commons-httpclient-javadoc-3.1-0jpp.1.fc9.ppc requires /bin/rm 1:jakarta-commons-httpclient-javadoc-3.1-0jpp.1.fc9.ppc requires /bin/ln jakarta-commons-io-1.3.2-1jpp.1.fc9.noarch requires /bin/sh jakarta-commons-lang-2.3-2jpp.1.fc9.ppc requires /bin/sh jakarta-commons-launcher-1.1-2jpp.3.fc9.ppc requires /bin/sh jakarta-commons-launcher-javadoc-1.1-2jpp.3.fc9.ppc requires /bin/sh jakarta-commons-launcher-javadoc-1.1-2jpp.3.fc9.ppc requires /bin/rm jakarta-commons-launcher-javadoc-1.1-2jpp.3.fc9.ppc requires /bin/ln jakarta-commons-logging-1.0.4-7jpp.5.fc9.ppc requires /bin/sh jakarta-commons-logging-javadoc-1.0.4-7jpp.5.fc9.ppc requires /bin/sh jakarta-commons-logging-javadoc-1.0.4-7jpp.5.fc9.ppc requires /bin/rm jakarta-commons-logging-javadoc-1.0.4-7jpp.5.fc9.ppc requires /bin/ln jakarta-commons-modeler-2.0-4jpp.2.fc9.ppc requires /bin/sh jakarta-commons-net-1.4.1-4jpp.1.fc9.noarch requires /bin/sh jakarta-commons-pool-1.3-10jpp.3.fc9.ppc requires /bin/sh jakarta-commons-pool-tomcat5-1.3-10jpp.3.fc9.ppc requires /bin/sh jakarta-commons-validator-1.1.4-6jpp.2.fc9.ppc requires /bin/sh jakarta-commons-validator-javadoc-1.1.4-6jpp.2.fc9.ppc requires /bin/sh jakarta-commons-validator-javadoc-1.1.4-6jpp.2.fc9.ppc requires /bin/rm jakarta-commons-validator-javadoc-1.1.4-6jpp.2.fc9.ppc requires /bin/ln jakarta-oro-2.0.8-4jpp.1.ppc requires /bin/sh jakarta-oro-javadoc-2.0.8-4jpp.1.ppc requires /bin/sh jakarta-oro-javadoc-2.0.8-4jpp.1.ppc requires /bin/ln jakarta-oro-javadoc-2.0.8-4jpp.1.ppc requires /bin/rm jakarta-taglibs-standard-1.1.1-9jpp.1.fc9.ppc requires /bin/sh jasper-libs-1.900.1-8.fc9.ppc requires /sbin/ldconfig jasper-libs-1.900.1-8.fc9.ppc64 requires /sbin/ldconfig java-1.5.0-gcj-1.5.0.0-21.fc9.ppc requires /bin/sh java-1.5.0-gcj-1.5.0.0-21.fc9.ppc requires /usr/bin/gcj-dbtool java-1.5.0-gcj-1.5.0.0-21.fc9.ppc requires /usr/bin/gij java-1.5.0-gcj-1.5.0.0-21.fc9.ppc requires /usr/sbin/alternatives java-1.5.0-gcj-1.5.0.0-21.fc9.ppc requires /usr/sbin/alternatives java-1.5.0-gcj-1.5.0.0-21.fc9.ppc requires /usr/lib/security/classpath.security java-1.5.0-gcj-1.5.0.0-21.fc9.ppc requires /bin/bash java-1.5.0-gcj-1.5.0.0-21.fc9.ppc requires /usr/bin/rebuild-gcj-db java-1.5.0-gcj-1.5.0.0-21.fc9.ppc requires /bin/sh java-1.5.0-gcj-1.5.0.0-21.fc9.ppc requires /usr/bin/gij java-1.5.0-gcj-devel-1.5.0.0-21.fc9.ppc requires /bin/sh java-1.5.0-gcj-devel-1.5.0.0-21.fc9.ppc requires /usr/bin/gij java-1.5.0-gcj-devel-1.5.0.0-21.fc9.ppc requires /usr/bin/gcj java-1.5.0-gcj-devel-1.5.0.0-21.fc9.ppc requires /usr/sbin/alternatives java-1.5.0-gcj-devel-1.5.0.0-21.fc9.ppc requires /usr/bin/env java-1.5.0-gcj-devel-1.5.0.0-21.fc9.ppc requires /bin/sh java-1.5.0-gcj-devel-1.5.0.0-21.fc9.ppc requires /usr/bin/gcj java-1.5.0-gcj-src-1.5.0.0-21.fc9.ppc requires /usr/bin/gij java-1.5.0-gcj-src-1.5.0.0-21.fc9.ppc requires /bin/sh java-1.5.0-gcj-src-1.5.0.0-21.fc9.ppc requires /usr/bin/gij 1:java-1.6.0-openjdk-1.6.0.0-0.12.b09.fc9.ppc requires /bin/sh 1:java-1.6.0-openjdk-1.6.0.0-0.12.b09.fc9.ppc requires /usr/bin/update-desktop-database 1:java-1.6.0-openjdk-1.6.0.0-0.12.b09.fc9.ppc requires /usr/sbin/alternatives 1:java-1.6.0-openjdk-1.6.0.0-0.12.b09.fc9.ppc64 requires /bin/sh 1:java-1.6.0-openjdk-1.6.0.0-0.12.b09.fc9.ppc64 requires /usr/bin/update-desktop-database 1:java-1.6.0-openjdk-1.6.0.0-0.12.b09.fc9.ppc64 requires /usr/sbin/alternatives 1:java-1.6.0-openjdk-demo-1.6.0.0-0.12.b09.fc9.ppc requires /bin/sh 1:java-1.6.0-openjdk-devel-1.6.0.0-0.12.b09.fc9.ppc requires /bin/sh 1:java-1.6.0-openjdk-devel-1.6.0.0-0.12.b09.fc9.ppc requires /usr/sbin/alternatives 1:java-1.6.0-openjdk-devel-1.6.0.0-0.12.b09.fc9.ppc requires /bin/sh 1:java-1.6.0-openjdk-devel-1.6.0.0-0.12.b09.fc9.ppc64 requires /bin/sh 1:java-1.6.0-openjdk-devel-1.6.0.0-0.12.b09.fc9.ppc64 requires /usr/sbin/alternatives 1:java-1.6.0-openjdk-devel-1.6.0.0-0.12.b09.fc9.ppc64 requires /bin/sh 1:java-1.6.0-openjdk-javadoc-1.6.0.0-0.12.b09.fc9.ppc requires /usr/sbin/alternatives 1:java-1.6.0-openjdk-javadoc-1.6.0.0-0.12.b09.fc9.ppc requires /bin/sh 1:java-1.6.0-openjdk-plugin-1.6.0.0-0.12.b09.fc9.ppc requires /usr/lib/mozilla/plugins 1:java-1.6.0-openjdk-plugin-1.6.0.0-0.12.b09.fc9.ppc requires /usr/sbin/alternatives 1:java-1.6.0-openjdk-plugin-1.6.0.0-0.12.b09.fc9.ppc requires /bin/sh 1:java_cup-0.10-0.k.6jpp.2.ppc requires /bin/sh 1:java_cup-javadoc-0.10-0.k.6jpp.2.ppc requires /bin/sh 1:java_cup-javadoc-0.10-0.k.6jpp.2.ppc requires /bin/rm 1:java_cup-javadoc-0.10-0.k.6jpp.2.ppc requires /bin/ln javacc-4.0-4jpp.4.ppc requires /bin/sh javacc-4.0-4jpp.4.ppc requires /bin/sh jcommon-1.0.12-4.fc10.ppc requires /bin/sh jcommon-serializer-0.2.0-3.fc10.ppc requires /bin/sh jcommon-xml-1.0.12-4.fc10.ppc requires /bin/sh jd-2.0.0-0.4.svn2053_trunk.fc10.ppc requires /bin/sh jday-2.4-3.fc9.ppc requires /sbin/ldconfig jday-2.4-3.fc9.ppc64 requires /sbin/ldconfig jdepend-2.6-7jpp.3.ppc requires /bin/sh jdepend-javadoc-2.6-7jpp.3.ppc requires /bin/sh jdepend-javadoc-2.6-7jpp.3.ppc requires /bin/rm jdepend-javadoc-2.6-7jpp.3.ppc requires /bin/ln jdom-1.0-5jpp.2.fc9.ppc requires /bin/sh jdom-javadoc-1.0-5jpp.2.fc9.ppc requires /bin/sh jdom-javadoc-1.0-5jpp.2.fc9.ppc requires /bin/rm jdom-javadoc-1.0-5jpp.2.fc9.ppc requires /bin/ln jetty-5.1.12-1jpp.9.fc8.ppc requires /bin/sh jetty-5.1.12-1jpp.9.fc8.ppc requires /sbin/chkconfig jetty-5.1.12-1jpp.9.fc8.ppc requires /bin/sh jgroups-2.2.9.2-3jpp.2.ppc requires /bin/sh jgroups-javadoc-2.2.9.2-3jpp.2.ppc requires /bin/sh jgroups-javadoc-2.2.9.2-3jpp.2.ppc requires /bin/rm jgroups-javadoc-2.2.9.2-3jpp.2.ppc requires /bin/ln jigdo-0.7.3-6.fc9.ppc requires /bin/sh jlex-1.2.6-6jpp.1.ppc requires /bin/sh jlex-javadoc-1.2.6-6jpp.1.ppc requires /bin/sh jlex-javadoc-1.2.6-6jpp.1.ppc requires /bin/rm jlex-javadoc-1.2.6-6jpp.1.ppc requires /bin/ln jline-0.9.94-0jpp.1.fc9.noarch requires /bin/sh jline-0.9.94-0jpp.1.fc9.noarch requires /bin/stty john-1.7.0.2-6.fc9.ppc requires /bin/sh jokosher-1.0-0.2.20080216svn.fc9.noarch requires /bin/sh jokosher-1.0-0.2.20080216svn.fc9.noarch requires /usr/bin/python jomolhari-fonts-0.003-5.fc10.noarch requires /bin/sh joni-1.0.2-4.fc9.ppc requires /bin/sh jpackage-utils-1.7.5-1jpp.1.fc9.noarch requires /bin/sh jpgalleg-2.5-3.fc9.ppc requires /sbin/ldconfig jpgalleg-2.5-3.fc9.ppc64 requires /sbin/ldconfig jpilot-0.99.9-6.fc9.ppc requires /sbin/ldconfig jrefactory-2.8.9-7jpp.4.fc9.ppc requires /bin/sh jrtplib-3.7.1-4.fc9.ppc requires /sbin/ldconfig jrtplib-3.7.1-4.fc9.ppc64 requires /sbin/ldconfig jruby-1.1.1-5.fc10.noarch requires /bin/bash jruby-1.1.1-5.fc10.noarch requires /usr/bin/env js-1.70-2.fc9.ppc requires /sbin/ldconfig js-1.70-2.fc9.ppc64 requires /sbin/ldconfig jsch-0.1.31-2jpp.3.fc9.ppc requires /bin/sh jsch-demo-0.1.31-2jpp.3.fc9.ppc requires /bin/sh jsch-demo-0.1.31-2jpp.3.fc9.ppc requires /bin/rm jsch-demo-0.1.31-2jpp.3.fc9.ppc requires /bin/ln jsch-javadoc-0.1.31-2jpp.3.fc9.ppc requires /bin/sh jsch-javadoc-0.1.31-2jpp.3.fc9.ppc requires /bin/rm jsch-javadoc-0.1.31-2jpp.3.fc9.ppc requires /bin/ln jthread-1.2.1-4.fc9.ppc requires /sbin/ldconfig jthread-1.2.1-4.fc9.ppc64 requires /sbin/ldconfig 2:jtidy-1.0-0.2.r7dev.1jpp.2.fc9.ppc requires /bin/sh 2:jtidy-javadoc-1.0-0.2.r7dev.1jpp.2.fc9.ppc requires /bin/rm 2:jtidy-javadoc-1.0-0.2.r7dev.1jpp.2.fc9.ppc requires /bin/ln junit-3.8.2-4jpp.3.fc9.ppc requires /bin/sh jwhois-4.0-7.fc9.ppc requires /bin/sh jwhois-4.0-7.fc9.ppc requires /sbin/install-info jython-2.2.1-0.1.Release_2_2_1.1jpp.1.fc9.ppc requires /bin/sh jython-demo-2.2.1-0.1.Release_2_2_1.1jpp.1.fc9.ppc requires /bin/sh jzlib-1.0.7-5jpp.1.ppc requires /bin/sh jzlib-demo-1.0.7-5jpp.1.ppc requires /bin/sh jzlib-demo-1.0.7-5jpp.1.ppc requires /bin/rm jzlib-demo-1.0.7-5jpp.1.ppc requires /bin/ln jzlib-javadoc-1.0.7-5jpp.1.ppc requires /bin/sh jzlib-javadoc-1.0.7-5jpp.1.ppc requires /bin/rm jzlib-javadoc-1.0.7-5jpp.1.ppc requires /bin/ln k3b-1.0.4-9.fc10.ppc requires /bin/sh k3b-1.0.4-9.fc10.ppc64 requires /bin/sh k3d-0.6.7.0-7.fc10.ppc requires /sbin/ldconfig k3d-0.6.7.0-7.fc10.ppc requires /bin/bash k3d-0.6.7.0-7.fc10.ppc requires /bin/sh k3d-0.6.7.0-7.fc10.ppc requires /bin/sh k3d-0.6.7.0-7.fc10.ppc64 requires /sbin/ldconfig k3d-0.6.7.0-7.fc10.ppc64 requires /bin/sh k3d-0.6.7.0-7.fc10.ppc64 requires /bin/bash k3d-0.6.7.0-7.fc10.ppc64 requires /bin/sh k3d-devel-0.6.7.0-7.fc10.ppc requires /bin/sh k3d-devel-0.6.7.0-7.fc10.ppc64 requires /bin/sh kacst-fonts-1.6.2-2.fc8.noarch requires /bin/sh kadu-0.6.0-3.fc9.ppc requires /bin/sh kadu-dcopexport-0.6.0-3.fc9.ppc requires /bin/sh kadu-devel-0.6.0-3.fc9.ppc requires /bin/sh kadu-devel-0.6.0-3.fc9.ppc64 requires /bin/sh kaffeine-0.8.6-4.fc9.ppc requires /bin/sh kaffeine-libs-0.8.6-4.fc9.ppc requires /sbin/ldconfig kaffeine-libs-0.8.6-4.fc9.ppc64 requires /sbin/ldconfig kakasi-2.3.4-26.fc9.ppc requires /sbin/ldconfig kakasi-2.3.4-26.fc9.ppc requires /bin/sh kannel-1.4.1-7.ppc requires /bin/sh kannel-1.4.1-7.ppc requires /bin/sh kannel-devel-1.4.1-7.ppc requires /bin/sh kannel-devel-1.4.1-7.ppc64 requires /bin/sh kanyremote-4.8-1.fc10.noarch requires /usr/bin/env kasablanca-0.4.0.2-12.fc9.ppc requires /bin/sh katapult-0.3.2.1-3.fc9.ppc requires /bin/sh katapult-0.3.2.1-3.fc9.ppc64 requires /bin/sh 1:kawa-1.9.1-5.fc9.ppc requires /bin/sh 1:kawa-1.9.1-5.fc9.ppc requires /bin/sh kbackup-0.5.3-4.fc9.ppc requires /bin/sh kbanking-2.3.3-3.fc9.ppc requires /sbin/ldconfig kbanking-2.3.3-3.fc9.ppc64 requires /sbin/ldconfig kbanking-devel-2.3.3-3.fc9.ppc requires /bin/sh kbanking-devel-2.3.3-3.fc9.ppc64 requires /bin/sh kbd-1.12-31.fc9.ppc requires /bin/bash kbd-1.12-31.fc9.ppc requires /bin/sh kbibtex-0.2.1-19.fc9.ppc requires /bin/sh kbilliards-0.8.7b-7.fc9.ppc requires /bin/sh kcbench-0.3-1.1.noarch requires /bin/bash kcbench-0.3-1.1.noarch requires /usr/bin/bc kcbench-0.3-1.1.noarch requires /usr/bin/time kcbench-data-2.6.25-0.1-3.noarch requires /usr/bin/perl kcbench-data-2.6.25-0.1-3.noarch requires /bin/bash kcbench-data-2.6.25-0.1-3.noarch requires /usr/bin/env kcbench-data-2.6.25-0.1-3.noarch requires /bin/sh kcbench-data-2.6.25-0.1-3.noarch requires /usr/bin/python kcemirror-0.1.5-4.fc9.ppc requires /bin/sh kchmviewer-4.0-0.2.beta2.fc9.ppc requires /bin/sh kcoloredit-4.0.3-2.fc9.ppc requires /bin/sh 1:kdbg-2.1.0-2.fc9.ppc requires /bin/sh kde-settings-4.0-22.fc9.1.noarch requires /bin/sh kde-settings-4.0-22.fc9.1.noarch requires /bin/sh kde-settings-kdm-4.0-22.fc9.1.noarch requires /bin/sh kde-settings-kdm-4.0-22.fc9.1.noarch requires /bin/sh 1:kdeaccessibility-4.0.72-1.fc10.ppc requires /bin/sh 1:kdeaccessibility-4.0.72-1.fc10.ppc requires /sbin/ldconfig 1:kdeaccessibility-4.0.72-1.fc10.ppc64 requires /bin/sh 1:kdeaccessibility-4.0.72-1.fc10.ppc64 requires /sbin/ldconfig kdeaddons-atlantikdesigner-3.5.9-1.fc9.ppc requires /bin/sh 7:kdeadmin-4.0.72-1.fc10.ppc requires /bin/sh 7:kdeadmin-4.0.72-1.fc10.ppc requires /usr/bin/env 7:kdeadmin-4.0.72-1.fc10.ppc requires /sbin/ldconfig 7:kdeadmin-kpackage-4.0.72-1.fc10.ppc requires /bin/sh kdeartwork-icons-4.0.72-1.fc10.ppc requires /bin/sh 6:kdebase-4.0.72-2.fc10.ppc requires /bin/sh 6:kdebase-4.0.72-2.fc10.ppc requires /bin/sh 6:kdebase-libs-4.0.72-2.fc10.ppc requires /sbin/ldconfig 6:kdebase-libs-4.0.72-2.fc10.ppc64 requires /sbin/ldconfig kdebase-runtime-4.0.72-2.fc10.ppc requires /sbin/ldconfig kdebase-runtime-4.0.72-2.fc10.ppc requires /usr/bin/perl kdebase-runtime-4.0.72-2.fc10.ppc requires /bin/sh kdebase-runtime-4.0.72-2.fc10.ppc requires /bin/sh kdebase-workspace-4.0.72-3.fc10.ppc requires /usr/bin/perl kdebase-workspace-4.0.72-3.fc10.ppc requires /bin/sh kdebase-workspace-4.0.72-3.fc10.ppc requires /bin/sh kdebase-workspace-libs-4.0.72-3.fc10.ppc requires /sbin/ldconfig kdebase-workspace-libs-4.0.72-3.fc10.ppc64 requires /sbin/ldconfig kdebase3-3.5.9-10.fc9.ppc requires /usr/bin/perl kdebase3-3.5.9-10.fc9.ppc requires /bin/sh kdebase3-3.5.9-10.fc9.ppc requires /bin/sh kdebase3-libs-3.5.9-10.fc9.ppc requires /sbin/ldconfig kdebase3-libs-3.5.9-10.fc9.ppc64 requires /sbin/ldconfig kdebindings-4.0.72-1.fc10.ppc requires /sbin/ldconfig kdebindings-4.0.72-1.fc10.ppc requires /usr/bin/env kdebindings-4.0.72-1.fc10.ppc requires /bin/sh kdebindings-4.0.72-1.fc10.ppc64 requires /sbin/ldconfig kdebindings-4.0.72-1.fc10.ppc64 requires /bin/sh kdebindings-4.0.72-1.fc10.ppc64 requires /usr/bin/env kdebluetooth-1.0-0.41.beta8.fc9.ppc requires /bin/sh kdebluetooth-1.0-0.41.beta8.fc9.ppc requires /bin/bash kdebluetooth-1.0-0.41.beta8.fc9.ppc requires /bin/sh kdebluetooth-1.0-0.41.beta8.fc9.ppc requires /usr/bin/kdesu kdeedu-4.0.72-2.fc10.ppc requires /bin/sh kdeedu-4.0.72-2.fc10.ppc requires /usr/bin/env kdeedu-kstars-4.0.72-2.fc10.ppc requires /bin/sh kdeedu-libs-4.0.72-2.fc10.ppc requires /sbin/ldconfig kdeedu-libs-4.0.72-2.fc10.ppc64 requires /sbin/ldconfig 6:kdegames-4.0.72-2.fc10.ppc requires /bin/sh 6:kdegames-libs-4.0.72-2.fc10.ppc requires /sbin/ldconfig 6:kdegames-libs-4.0.72-2.fc10.ppc64 requires /sbin/ldconfig kdegames3-3.5.9-1.fc9.ppc requires /bin/sh kdegames3-libs-3.5.9-1.fc9.ppc requires /sbin/ldconfig kdegames3-libs-3.5.9-1.fc9.ppc64 requires /sbin/ldconfig 7:kdegraphics-4.0.72-2.fc10.ppc requires /bin/sh 7:kdegraphics-libs-4.0.72-2.fc10.ppc requires /sbin/ldconfig 7:kdegraphics-libs-4.0.72-2.fc10.ppc64 requires /sbin/ldconfig 6:kdelibs-4.0.72-4.fc10.ppc requires /sbin/ldconfig 6:kdelibs-4.0.72-4.fc10.ppc requires /usr/bin/perl 6:kdelibs-4.0.72-4.fc10.ppc requires /bin/sh 6:kdelibs-4.0.72-4.fc10.ppc requires /bin/sh 6:kdelibs-4.0.72-4.fc10.ppc64 requires /sbin/ldconfig 6:kdelibs-4.0.72-4.fc10.ppc64 requires /usr/bin/perl 6:kdelibs-4.0.72-4.fc10.ppc64 requires /bin/sh 6:kdelibs-4.0.72-4.fc10.ppc64 requires /bin/sh 6:kdelibs-devel-4.0.72-4.fc10.ppc requires /bin/sh 6:kdelibs-devel-4.0.72-4.fc10.ppc64 requires /bin/sh kdelibs3-3.5.9-10.fc10.ppc requires /sbin/ldconfig kdelibs3-3.5.9-10.fc10.ppc requires /usr/bin/perl kdelibs3-3.5.9-10.fc10.ppc requires /bin/sh kdelibs3-3.5.9-10.fc10.ppc requires /bin/sh kdelibs3-3.5.9-10.fc10.ppc64 requires /sbin/ldconfig kdelibs3-3.5.9-10.fc10.ppc64 requires /usr/bin/perl kdelibs3-3.5.9-10.fc10.ppc64 requires /bin/sh kdelibs3-3.5.9-10.fc10.ppc64 requires /bin/sh kdelibs3-devel-3.5.9-10.fc10.ppc requires /bin/sh kdelibs3-devel-3.5.9-10.fc10.ppc64 requires /bin/sh 6:kdemultimedia-4.0.72-1.fc10.ppc requires /bin/sh 6:kdemultimedia-4.0.72-1.fc10.ppc requires /usr/bin/env 6:kdemultimedia-4.0.72-1.fc10.ppc requires /usr/bin/perl 6:kdemultimedia-libs-4.0.72-1.fc10.ppc requires /sbin/ldconfig 6:kdemultimedia-libs-4.0.72-1.fc10.ppc64 requires /sbin/ldconfig 7:kdenetwork-4.0.72-2.fc10.ppc requires /usr/bin/perl 7:kdenetwork-4.0.72-2.fc10.ppc requires /bin/sh 7:kdenetwork-4.0.72-2.fc10.ppc requires /bin/sh 7:kdenetwork-libs-4.0.72-2.fc10.ppc requires /sbin/ldconfig 7:kdenetwork-libs-4.0.72-2.fc10.ppc64 requires /sbin/ldconfig 6:kdepim-3.5.9-9.fc9.ppc requires /sbin/ldconfig 6:kdepim-3.5.9-9.fc9.ppc requires /usr/bin/perl 6:kdepim-3.5.9-9.fc9.ppc requires /bin/sh 6:kdepim-3.5.9-9.fc9.ppc requires /usr/bin/env 6:kdepim-3.5.9-9.fc9.ppc requires /bin/sh 6:kdepim-libs-3.5.9-9.fc9.ppc requires /sbin/ldconfig 6:kdepim-libs-3.5.9-9.fc9.ppc64 requires /sbin/ldconfig kdepimlibs-4.0.72-2.fc10.ppc requires /sbin/ldconfig kdepimlibs-4.0.72-2.fc10.ppc requires /usr/bin/perl kdepimlibs-4.0.72-2.fc10.ppc64 requires /sbin/ldconfig kdepimlibs-4.0.72-2.fc10.ppc64 requires /usr/bin/perl kdesdk-4.0.72-1.fc10.ppc requires /usr/bin/perl kdesdk-4.0.72-1.fc10.ppc requires /bin/sh kdesdk-4.0.72-1.fc10.ppc requires /usr/bin/env kdesdk-4.0.72-1.fc10.ppc requires /bin/bash kdesdk-4.0.72-1.fc10.ppc requires /bin/sh kdesdk-libs-4.0.72-1.fc10.ppc requires /sbin/ldconfig kdesdk-libs-4.0.72-1.fc10.ppc64 requires /sbin/ldconfig kdesvn-0.14.3-1.fc10.ppc requires /bin/sh kdesvn-0.14.3-1.fc10.ppc requires /bin/sh kdesvn-0.14.3-1.fc10.ppc64 requires /bin/sh kdesvn-0.14.3-1.fc10.ppc64 requires /bin/sh 7:kdetoys-4.0.72-1.fc10.ppc requires /bin/sh 7:kdetoys-4.0.72-1.fc10.ppc requires /sbin/ldconfig 7:kdetoys-4.0.72-1.fc10.ppc64 requires /bin/sh 7:kdetoys-4.0.72-1.fc10.ppc64 requires /sbin/ldconfig kdetv-0.8.9-10.fc9.ppc requires /bin/sh kdetv-0.8.9-10.fc9.ppc64 requires /bin/sh 6:kdeutils-4.0.72-1.fc10.ppc requires /sbin/ldconfig 6:kdeutils-4.0.72-1.fc10.ppc requires /bin/sh 6:kdeutils-4.0.72-1.fc10.ppc64 requires /bin/sh 6:kdeutils-4.0.72-1.fc10.ppc64 requires /sbin/ldconfig 9:kdevelop-3.5.1-4.fc9.ppc requires /bin/sh 9:kdevelop-3.5.1-4.fc9.ppc requires /usr/bin/perl 9:kdevelop-libs-3.5.1-4.fc9.ppc requires /sbin/ldconfig 9:kdevelop-libs-3.5.1-4.fc9.ppc64 requires /sbin/ldconfig 6:kdewebdev-3.5.9-3.fc9.ppc requires /bin/sh 6:kdewebdev-3.5.9-3.fc9.ppc requires /usr/bin/perl 6:kdewebdev-3.5.9-3.fc9.ppc requires /bin/sh 6:kdewebdev-libs-3.5.9-3.fc9.ppc requires /sbin/ldconfig 6:kdewebdev-libs-3.5.9-3.fc9.ppc64 requires /sbin/ldconfig kdiff3-0.9.92-13.fc9.ppc requires /bin/sh kdirstat-2.5.3-8.fc9.ppc requires /bin/sh kdirstat-2.5.3-8.fc9.ppc requires /usr/bin/perl kdissert-1.0.7-4.fc9.ppc requires /bin/sh kdnssd-avahi-0.1.3-0.6.20080116svn.fc9.ppc requires /sbin/ldconfig kdnssd-avahi-0.1.3-0.6.20080116svn.fc9.ppc64 requires /sbin/ldconfig keepalived-1.1.15-5.fc10.ppc requires /bin/sh keepalived-1.1.15-5.fc10.ppc requires /sbin/chkconfig keepalived-1.1.15-5.fc10.ppc requires /bin/sh keepalived-1.1.15-5.fc10.ppc requires /sbin/service keepassx-0.3.1-1.fc9.ppc requires /bin/sh kernel-2.6.25.2-5.fc10.ppc requires /bin/sh kernel-2.6.25.2-5.fc10.ppc requires /bin/sh kernel-2.6.25.2-5.fc10.ppc64 requires /bin/sh kernel-2.6.25.2-5.fc10.ppc64 requires /bin/sh kernel-bootwrapper-2.6.25.2-5.fc10.ppc requires /bin/sh kernel-devel-2.6.25.2-5.fc10.ppc requires /usr/bin/find kernel-devel-2.6.25.2-5.fc10.ppc requires /bin/sh kernel-devel-2.6.25.2-5.fc10.ppc64 requires /usr/bin/find kernel-devel-2.6.25.2-5.fc10.ppc64 requires /bin/sh kernel-kdump-devel-2.6.25.2-5.fc10.ppc64 requires /usr/bin/find kernel-smp-2.6.25.2-5.fc10.ppc requires /bin/sh kernel-smp-2.6.25.2-5.fc10.ppc requires /bin/sh kernel-smp-devel-2.6.25.2-5.fc10.ppc requires /usr/bin/find kernel-smp-devel-2.6.25.2-5.fc10.ppc requires /bin/sh kerneloops-0.10-11.fc9.ppc requires /bin/sh kerneloops-0.10-11.fc9.ppc requires /bin/bash kerry-0.2.1-7.fc9.ppc requires /bin/sh kerry-0.2.1-7.fc9.ppc requires /bin/sh ketchup-0.9.8-1.fc8.noarch requires /usr/bin/python keurocalc-1.0.0-2.rc2.fc9.ppc requires /bin/sh kexec-tools-1.102pre-10.fc10.ppc requires /bin/sh kexec-tools-1.102pre-10.fc10.ppc requires /usr/bin/perl kexec-tools-1.102pre-10.fc10.ppc requires /bin/bash kexec-tools-1.102pre-10.fc10.ppc requires /bin/sh keychain-2.6.8-3.fc9.noarch requires /bin/sh keyjnote-0.10.2-1.fc9.noarch requires /usr/bin/env keyutils-1.2-3.fc9.ppc requires /bin/sh keyutils-libs-1.2-3.fc9.ppc requires /sbin/ldconfig keyutils-libs-1.2-3.fc9.ppc64 requires /sbin/ldconfig kflickr-0.9.1-2.fc9.ppc requires /bin/sh kftpgrabber-0.8.1-6.fc9.ppc requires /bin/sh kftpgrabber-0.8.1-6.fc9.ppc requires /sbin/ldconfig kftpgrabber-0.8.1-6.fc9.ppc64 requires /bin/sh kftpgrabber-0.8.1-6.fc9.ppc64 requires /sbin/ldconfig kgrab-0.1.1-6.fc9.ppc requires /bin/sh kgtk-0.9.4-3.fc9.ppc requires /bin/bash kicad-2007.07.09-3.fc9.ppc requires /bin/sh kiconedit-4.0.3-2.fc9.ppc requires /bin/sh kid3-1.0-1.fc9.ppc requires /bin/sh kile-2.0.1-1.fc10.ppc requires /bin/sh kile-2.0.1-1.fc10.ppc requires /usr/bin/perl kinput2-v3.1-38.fc9.ppc requires /bin/sh kinput2-v3.1-38.fc9.ppc requires /usr/sbin/alternatives kinput2-v3.1-38.fc9.ppc requires /usr/sbin/alternatives kinput2-v3.1-38.fc9.ppc requires /bin/sh kio_sword-0.3-6.fc9.ppc requires /bin/sh kiosktool-1.0-10.fc9.ppc requires /bin/sh kipi-plugins-0.1.5-2.fc10.ppc requires /sbin/ldconfig kipi-plugins-0.1.5-2.fc10.ppc requires /bin/bash kipi-plugins-0.1.5-2.fc10.ppc64 requires /sbin/ldconfig kipi-plugins-0.1.5-2.fc10.ppc64 requires /bin/bash kismet-0.0.2007.10.R1-3.fc9.ppc requires /bin/sh kismet-0.0.2007.10.R1-3.fc9.ppc requires /etc/cron.daily kismet-0.0.2007.10.R1-3.fc9.ppc requires /bin/sh kismet-extras-0.0.2007.10.R1-3.fc9.ppc requires /usr/bin/perl kismet-extras-0.0.2007.10.R1-3.fc9.ppc requires libMagick.so.10 kita-0.177.3-12.fc9.2.ppc requires /bin/sh kita-0.177.3-12.fc9.2.ppc requires /sbin/ldconfig kita-0.177.3-12.fc9.2.ppc64 requires /bin/sh kita-0.177.3-12.fc9.2.ppc64 requires /sbin/ldconfig kitsune-2.0-4.fc9.ppc requires /bin/sh klamav-0.42-3.fc9.ppc requires /bin/sh kleansweep-0.2.9-7.fc9.ppc requires /bin/sh kleansweep-0.2.9-7.fc9.ppc requires /usr/bin/env klear-0.7.0-1.svn113.fc9.ppc requires /bin/sh kmenu-gnome-0.7.1-1.fc9.noarch requires /bin/sh kmid-2.0-0.6.20080213svn.fc9.ppc requires /bin/sh kmid-2.0-0.6.20080213svn.fc9.ppc requires /sbin/ldconfig kmid-2.0-0.6.20080213svn.fc9.ppc64 requires /sbin/ldconfig kmid-2.0-0.6.20080213svn.fc9.ppc64 requires /bin/sh kmobiletools-0.4.3.3-4.fc9.ppc requires /bin/sh kmplayer-0.10.0c-4.fc9.ppc requires /bin/sh kmymoney2-0.9-1.fc10.ppc requires /bin/sh kmymoney2-libs-0.9-1.fc10.ppc requires /sbin/ldconfig kmymoney2-libs-0.9-1.fc10.ppc64 requires /sbin/ldconfig knetstats-1.6.1-8.fc9.ppc requires /bin/sh kodos-2.4.9-4.fc8.noarch requires /usr/bin/env kodos-2.4.9-4.fc8.noarch requires /usr/bin/python koffice-core-1.6.3-15.fc9.ppc requires /bin/sh koffice-filters-1.6.3-15.fc9.ppc requires /sbin/ldconfig koffice-filters-1.6.3-15.fc9.ppc64 requires /sbin/ldconfig koffice-karbon-1.6.3-15.fc9.ppc requires libWand.so.10 koffice-karbon-1.6.3-15.fc9.ppc requires libMagick.so.10 koffice-kchart-1.6.3-15.fc9.ppc requires /sbin/ldconfig koffice-kchart-1.6.3-15.fc9.ppc64 requires /sbin/ldconfig koffice-kexi-1.6.3-15.fc9.ppc requires /sbin/ldconfig koffice-kexi-1.6.3-15.fc9.ppc requires /bin/sh koffice-kexi-1.6.3-15.fc9.ppc64 requires /sbin/ldconfig koffice-kexi-1.6.3-15.fc9.ppc64 requires /bin/sh koffice-kpresenter-1.6.3-15.fc9.ppc requires /sbin/ldconfig koffice-kpresenter-1.6.3-15.fc9.ppc requires /usr/bin/perl koffice-kpresenter-1.6.3-15.fc9.ppc64 requires /sbin/ldconfig koffice-kpresenter-1.6.3-15.fc9.ppc64 requires /usr/bin/perl koffice-kugar-1.6.3-15.fc9.ppc requires /sbin/ldconfig koffice-kugar-1.6.3-15.fc9.ppc64 requires /sbin/ldconfig koffice-kword-1.6.3-15.fc9.ppc requires /sbin/ldconfig koffice-kword-1.6.3-15.fc9.ppc64 requires /sbin/ldconfig koffice-libs-1.6.3-15.fc9.ppc requires /sbin/ldconfig koffice-libs-1.6.3-15.fc9.ppc requires libWand.so.10 koffice-libs-1.6.3-15.fc9.ppc requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.ppc64 requires /sbin/ldconfig koffice-libs-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) koji-1.2.3-1.fc9.noarch requires /usr/bin/python koji-builder-1.2.3-1.fc9.noarch requires /bin/sh koji-builder-1.2.3-1.fc9.noarch requires /usr/bin/git koji-builder-1.2.3-1.fc9.noarch requires /sbin/chkconfig koji-builder-1.2.3-1.fc9.noarch requires /usr/bin/svn koji-builder-1.2.3-1.fc9.noarch requires /usr/sbin/useradd koji-builder-1.2.3-1.fc9.noarch requires /usr/bin/cvs koji-builder-1.2.3-1.fc9.noarch requires /bin/sh koji-builder-1.2.3-1.fc9.noarch requires /usr/bin/python koji-builder-1.2.3-1.fc9.noarch requires /sbin/service koji-utils-1.2.3-1.fc9.noarch requires /bin/sh koji-utils-1.2.3-1.fc9.noarch requires /bin/sh koji-utils-1.2.3-1.fc9.noarch requires /usr/bin/python komparator-0.9-1.fc9.ppc requires /bin/sh konq-plugins-4.0.3-0.3.20080409svn.fc9.ppc requires /bin/sh konq-plugins-4.0.3-0.3.20080409svn.fc9.ppc requires /usr/bin/env konversation-1.0.1-6.fc9.ppc requires /bin/sh konversation-1.0.1-6.fc9.ppc requires /usr/bin/env konversation-1.0.1-6.fc9.ppc requires /bin/bash konversation-1.0.1-6.fc9.ppc requires /bin/sh konversation-1.0.1-6.fc9.ppc requires /usr/bin/perl kooldock-0.4.6-4.fc9.ppc requires /bin/sh kover-3-3.ppc requires /bin/sh koverartist-0.5-11.fc9.ppc requires /bin/sh kpathsea-2007-31.fc10.ppc requires /bin/sh kpathsea-2007-31.fc10.ppc requires /sbin/restorecon kpathsea-2007-31.fc10.ppc64 requires /bin/sh kpathsea-2007-31.fc10.ppc64 requires /sbin/restorecon kphotoalbum-3.1.1-2.fc10.ppc requires /bin/sh kphotobymail-0.4.1-1.fc7.noarch requires /usr/bin/env kpolynome-0.1.2-12.fc9.ppc requires /bin/sh kpowersave-0.7.3-3.fc9.ppc requires /bin/sh krb5-devel-1.6.3-10.fc9.ppc requires /bin/sh krb5-devel-1.6.3-10.fc9.ppc64 requires /bin/sh krb5-libs-1.6.3-10.fc9.ppc requires /sbin/ldconfig krb5-libs-1.6.3-10.fc9.ppc64 requires /sbin/ldconfig krb5-server-1.6.3-10.fc9.ppc requires /bin/sh krb5-server-1.6.3-10.fc9.ppc requires /sbin/install-info krb5-server-1.6.3-10.fc9.ppc requires /bin/bash krb5-server-1.6.3-10.fc9.ppc requires /bin/sh krb5-server-1.6.3-10.fc9.ppc requires /sbin/chkconfig krb5-workstation-1.6.3-10.fc9.ppc requires /bin/sh krb5-workstation-1.6.3-10.fc9.ppc requires /sbin/install-info krb5-workstation-1.6.3-10.fc9.ppc requires /bin/sh krb5-workstation-clients-1.6.3-10.fc9.ppc requires /bin/sh krb5-workstation-clients-1.6.3-10.fc9.ppc requires /sbin/install-info krb5-workstation-clients-1.6.3-10.fc9.ppc requires /bin/sh krb5-workstation-servers-1.6.3-10.fc9.ppc requires /bin/sh krb5-workstation-servers-1.6.3-10.fc9.ppc requires /etc/pam.d/remote krb5-workstation-servers-1.6.3-10.fc9.ppc requires /sbin/install-info krb5-workstation-servers-1.6.3-10.fc9.ppc requires /bin/bash krb5-workstation-servers-1.6.3-10.fc9.ppc requires /bin/sh krecipes-0.9.1-9.fc9.ppc requires /bin/sh kreetingkard-0.7.1-2.fc9.2.ppc requires /bin/sh krename-3.0.14-4.fc9.ppc requires /bin/sh krusader-1.80.0-5.fc9.ppc requires /bin/sh kscope-1.6.1-4.fc9.ppc requires /bin/sh ksensors-0.7.3-16.fc9.ppc requires /bin/sh ksh-20080202-1.fc9.ppc requires /bin/sh ksh-20080202-1.fc9.ppc requires /bin/sh kshutdown-1.0.1-2.fc9.ppc requires /bin/sh ksig-1.1-0.5.20080213.fc9.ppc requires /bin/sh ksirk-1.7-6.fc9.ppc requires /bin/sh ksirk-1.7-6.fc9.ppc requires /bin/bash ksmarttray-0.52-54.fc9.ppc requires /usr/bin/kdesu kst-1.6.0-2.fc10.ppc requires /sbin/ldconfig kst-1.6.0-2.fc10.ppc64 requires /sbin/ldconfig ksynaptics-0.3.3-5.fc9.ppc requires /bin/sh ktechlab-0.3.69-5.fc8.ppc requires /bin/sh ktorrent-3.0.2-3.fc10.ppc requires /bin/sh ktorrent-3.0.2-3.fc10.ppc64 requires /bin/sh kudzu-1.2.85-1.ppc requires /sbin/chkconfig kudzu-1.2.85-1.ppc requires /bin/sh labyrinth-0.4.0-1.fc10.noarch requires /bin/sh labyrinth-0.4.0-1.fc10.noarch requires /usr/bin/env lacewing-1.10-10.fc9.ppc requires /bin/sh lagan-2.0-2.fc9.ppc requires /usr/bin/env lagan-2.0-2.fc9.ppc requires /usr/bin/perl 2:lam-7.1.2-11.fc9.ppc requires /bin/sh 2:lam-7.1.2-11.fc9.ppc requires /usr/bin/env 2:lam-7.1.2-11.fc9.ppc requires /sbin/ldconfig 2:lam-7.1.2-11.fc9.ppc requires /usr/sbin/alternatives 2:lam-7.1.2-11.fc9.ppc requires /bin/sh 2:lam-devel-7.1.2-11.fc9.ppc requires /bin/sh 2:lam-devel-7.1.2-11.fc9.ppc requires /sbin/ldconfig 2:lam-devel-7.1.2-11.fc9.ppc requires /usr/sbin/alternatives 2:lam-devel-7.1.2-11.fc9.ppc64 requires /bin/sh 2:lam-devel-7.1.2-11.fc9.ppc64 requires /sbin/ldconfig 2:lam-devel-7.1.2-11.fc9.ppc64 requires /usr/sbin/alternatives 2:lam-libs-7.1.2-11.fc9.ppc requires /bin/sh 2:lam-libs-7.1.2-11.fc9.ppc requires /sbin/ldconfig 2:lam-libs-7.1.2-11.fc9.ppc requires /usr/sbin/alternatives 2:lam-libs-7.1.2-11.fc9.ppc64 requires /bin/sh 2:lam-libs-7.1.2-11.fc9.ppc64 requires /sbin/ldconfig 2:lam-libs-7.1.2-11.fc9.ppc64 requires /usr/sbin/alternatives lapack-3.1.1-3.fc9.ppc requires /sbin/ldconfig lapack-3.1.1-3.fc9.ppc64 requires /sbin/ldconfig lash-0.5.4-2.fc9.ppc requires /sbin/install-info lash-0.5.4-2.fc9.ppc requires /bin/sh lash-0.5.4-2.fc9.ppc64 requires /bin/sh lash-0.5.4-2.fc9.ppc64 requires /sbin/install-info lasi-1.1.0-1.fc9.ppc requires /sbin/ldconfig lasi-1.1.0-1.fc9.ppc64 requires /sbin/ldconfig lat-1.2.3-3.fc9.ppc requires /bin/sh lat-1.2.3-3.fc9.ppc requires /bin/sh latex-mk-1.8-2.fc7.noarch requires /bin/sh latex-mk-1.8-2.fc7.noarch requires /sbin/install-info latex-mk-1.8-2.fc7.noarch requires /bin/sh latex2html-2002.2.1-8.fc9.noarch requires /bin/sh latex2html-2002.2.1-8.fc9.noarch requires /usr/bin/perl latexmk-3.20-1.fc8.noarch requires /usr/bin/perl lbrickbuster2-2.6-0.9.beta7.fc8.ppc requires /bin/sh lcdproc-0.5.2-4.fc9.ppc requires /bin/sh lcdproc-0.5.2-4.fc9.ppc requires /usr/bin/perl lcdproc-0.5.2-4.fc9.ppc requires /bin/sh lcdproc-0.5.2-4.fc9.ppc requires /sbin/chkconfig lcms-libs-1.17-4.fc9.ppc requires /sbin/ldconfig lcms-libs-1.17-4.fc9.ppc64 requires /sbin/ldconfig lcov-1.4-2.fc6.noarch requires /usr/bin/perl lcov-1.4-2.fc6.noarch requires /usr/bin/gcov ldapjdk-4.18-1.fc9.ppc requires /bin/sh ldirectord-2.1.3-1.fc9.ppc requires /bin/sh ldirectord-2.1.3-1.fc9.ppc requires /sbin/ldconfig ldirectord-2.1.3-1.fc9.ppc requires /usr/bin/perl ldirectord-2.1.3-1.fc9.ppc requires /bin/sh ldirectord-2.1.3-1.fc9.ppc requires /sbin/chkconfig ldm-2.0.4-1.fc9.ppc requires /bin/sh ldns-1.2.2-3.fc9.ppc requires /sbin/ldconfig leafnode-1.11.6-3.fc9.ppc requires /bin/sh leafpad-0.8.13-1.fc9.ppc requires /bin/sh less-418-3.fc9.ppc requires /bin/sh lesstif-0.95.0-23.fc9.ppc requires /sbin/ldconfig lesstif-0.95.0-23.fc9.ppc64 requires /sbin/ldconfig lesstif-clients-0.95.0-23.fc9.ppc requires /bin/sh lesstif-devel-0.95.0-23.fc9.ppc requires /bin/sh lesstif-devel-0.95.0-23.fc9.ppc64 requires /bin/sh lftp-3.7.1-1.fc10.ppc requires /sbin/ldconfig lftp-3.7.1-1.fc10.ppc requires /usr/bin/perl lftp-3.7.1-1.fc10.ppc requires /bin/sh lftp-3.7.1-1.fc10.ppc64 requires /sbin/ldconfig lftp-3.7.1-1.fc10.ppc64 requires /usr/bin/perl lftp-3.7.1-1.fc10.ppc64 requires /bin/sh lib3ds-1.3.0-2.fc9.ppc requires /sbin/ldconfig lib3ds-1.3.0-2.fc9.ppc64 requires /sbin/ldconfig lib3ds-devel-1.3.0-2.fc9.ppc requires /bin/sh lib3ds-devel-1.3.0-2.fc9.ppc64 requires /bin/sh lib765-0.4.1-3.fc9.ppc requires /sbin/ldconfig lib765-0.4.1-3.fc9.ppc64 requires /sbin/ldconfig libAfterImage-1.15-4.fc9.ppc requires /sbin/ldconfig libAfterImage-1.15-4.fc9.ppc64 requires /sbin/ldconfig libAfterImage-devel-1.15-4.fc9.ppc requires /bin/sh libAfterImage-devel-1.15-4.fc9.ppc64 requires /bin/sh libEMF-1.0.3-7.fc9.ppc requires /sbin/ldconfig libEMF-1.0.3-7.fc9.ppc64 requires /sbin/ldconfig libFS-1.0.0-7.fc9.ppc requires /sbin/ldconfig libFS-1.0.0-7.fc9.ppc64 requires /sbin/ldconfig libFoundation-1.1.3-11.fc9.ppc requires /sbin/ldconfig libFoundation-1.1.3-11.fc9.ppc64 requires /sbin/ldconfig libHX-1.15-1.fc10.ppc requires /sbin/ldconfig libHX-1.15-1.fc10.ppc64 requires /sbin/ldconfig libICE-1.0.4-3.fc9.ppc requires /sbin/ldconfig libICE-1.0.4-3.fc9.ppc64 requires /sbin/ldconfig libIDL-0.8.10-2.fc9.ppc requires /sbin/ldconfig libIDL-0.8.10-2.fc9.ppc64 requires /sbin/ldconfig libIDL-devel-0.8.10-2.fc9.ppc requires /bin/sh libIDL-devel-0.8.10-2.fc9.ppc requires /sbin/install-info libIDL-devel-0.8.10-2.fc9.ppc requires /bin/sh libIDL-devel-0.8.10-2.fc9.ppc64 requires /bin/sh libIDL-devel-0.8.10-2.fc9.ppc64 requires /sbin/install-info libIDL-devel-0.8.10-2.fc9.ppc64 requires /bin/sh libRmath-2.7.0-2.fc10.ppc requires /bin/sh libSM-1.0.2-5.fc9.ppc requires /sbin/ldconfig libSM-1.0.2-5.fc9.ppc64 requires /sbin/ldconfig libX11-1.1.4-1.fc9.ppc requires /sbin/ldconfig libX11-1.1.4-1.fc9.ppc64 requires /sbin/ldconfig libXNVCtrl-169.12-1.fc9.ppc requires /sbin/ldconfig libXNVCtrl-169.12-1.fc9.ppc64 requires /sbin/ldconfig libXScrnSaver-1.1.2-4.fc9.ppc requires /sbin/ldconfig libXScrnSaver-1.1.2-4.fc9.ppc64 requires /sbin/ldconfig libXTrap-1.0.0-5.fc9.ppc requires /sbin/ldconfig libXTrap-1.0.0-5.fc9.ppc64 requires /sbin/ldconfig libXau-1.0.3-5.fc9.ppc requires /sbin/ldconfig libXau-1.0.3-5.fc9.ppc64 requires /sbin/ldconfig libXaw-1.0.4-2.fc9.ppc requires /sbin/ldconfig libXaw-1.0.4-2.fc9.ppc64 requires /sbin/ldconfig libXcomposite-0.4.0-4.fc9.ppc requires /sbin/ldconfig libXcomposite-0.4.0-4.fc9.ppc64 requires /sbin/ldconfig libXcursor-1.1.9-2.fc9.ppc requires /sbin/ldconfig libXcursor-1.1.9-2.fc9.ppc64 requires /sbin/ldconfig libXdamage-1.1.1-4.fc9.ppc requires /sbin/ldconfig libXdamage-1.1.1-4.fc9.ppc64 requires /sbin/ldconfig libXdmcp-1.0.2-5.fc9.ppc requires /sbin/ldconfig libXdmcp-1.0.2-5.fc9.ppc64 requires /sbin/ldconfig libXevie-1.0.2-3.fc9.ppc requires /sbin/ldconfig libXevie-1.0.2-3.fc9.ppc64 requires /sbin/ldconfig libXext-1.0.4-1.fc9.ppc requires /sbin/ldconfig libXext-1.0.4-1.fc9.ppc64 requires /sbin/ldconfig libXfixes-4.0.3-3.fc9.ppc requires /sbin/ldconfig libXfixes-4.0.3-3.fc9.ppc64 requires /sbin/ldconfig libXfont-1.3.1-4.fc9.ppc requires /sbin/ldconfig libXfont-1.3.1-4.fc9.ppc64 requires /sbin/ldconfig libXfontcache-1.0.4-5.fc9.ppc requires /sbin/ldconfig libXfontcache-1.0.4-5.fc9.ppc64 requires /sbin/ldconfig libXft-2.1.12-5.fc9.ppc requires /sbin/ldconfig libXft-2.1.12-5.fc9.ppc64 requires /sbin/ldconfig libXi-1.1.3-4.fc9.ppc requires /sbin/ldconfig libXi-1.1.3-4.fc9.ppc64 requires /sbin/ldconfig libXinerama-1.0.3-1.fc9.ppc requires /sbin/ldconfig libXinerama-1.0.3-1.fc9.ppc64 requires /sbin/ldconfig libXmu-1.0.4-1.fc9.ppc requires /sbin/ldconfig libXmu-1.0.4-1.fc9.ppc64 requires /sbin/ldconfig libXp-1.0.0-11.fc9.ppc requires /sbin/ldconfig libXp-1.0.0-11.fc9.ppc64 requires /sbin/ldconfig libXpm-3.5.7-4.fc9.ppc requires /sbin/ldconfig libXpm-3.5.7-4.fc9.ppc64 requires /sbin/ldconfig libXrandr-1.2.2-3.fc9.ppc requires /sbin/ldconfig libXrandr-1.2.2-3.fc9.ppc64 requires /sbin/ldconfig libXrender-0.9.4-3.fc9.ppc requires /sbin/ldconfig libXrender-0.9.4-3.fc9.ppc64 requires /sbin/ldconfig libXres-1.0.3-4.fc9.ppc requires /sbin/ldconfig libXres-1.0.3-4.fc9.ppc64 requires /sbin/ldconfig libXt-1.0.4-5.fc9.ppc requires /sbin/ldconfig libXt-1.0.4-5.fc9.ppc64 requires /sbin/ldconfig libXtst-1.0.3-3.fc9.ppc requires /sbin/ldconfig libXtst-1.0.3-3.fc9.ppc64 requires /sbin/ldconfig libXv-1.0.3-5.fc9.ppc requires /sbin/ldconfig libXv-1.0.3-5.fc9.ppc64 requires /sbin/ldconfig libXvMC-1.0.4-4.fc9.ppc requires /sbin/ldconfig libXvMC-1.0.4-4.fc9.ppc64 requires /sbin/ldconfig libXxf86dga-1.0.2-2.fc9.ppc requires /sbin/ldconfig libXxf86dga-1.0.2-2.fc9.ppc64 requires /sbin/ldconfig libXxf86misc-1.0.1-5.fc9.ppc requires /sbin/ldconfig libXxf86misc-1.0.1-5.fc9.ppc64 requires /sbin/ldconfig libXxf86vm-1.0.1-5.fc9.ppc requires /sbin/ldconfig libXxf86vm-1.0.1-5.fc9.ppc64 requires /sbin/ldconfig libacl-2.2.47-1.fc9.ppc requires /sbin/ldconfig libacl-2.2.47-1.fc9.ppc64 requires /sbin/ldconfig libaio-0.3.106-4.2.ppc requires /sbin/ldconfig libaio-0.3.106-4.2.ppc64 requires /sbin/ldconfig libannodex-0.7.3-10.fc9.ppc requires /bin/sh libannodex-0.7.3-10.fc9.ppc requires /sbin/ldconfig libannodex-0.7.3-10.fc9.ppc64 requires /bin/sh libannodex-0.7.3-10.fc9.ppc64 requires /sbin/ldconfig libao-0.8.8-4.fc9.ppc requires /sbin/ldconfig libao-0.8.8-4.fc9.ppc64 requires /sbin/ldconfig libao-devel-0.8.8-4.fc9.ppc requires /usr/lib/libao.so.2 libao-devel-0.8.8-4.fc9.ppc64 requires /usr/lib64/libao.so.2 libapreq2-2.09-0.15.rc2.fc9.ppc requires /bin/sh libapreq2-2.09-0.15.rc2.fc9.ppc requires /sbin/ldconfig libapreq2-2.09-0.15.rc2.fc9.ppc64 requires /bin/sh libapreq2-2.09-0.15.rc2.fc9.ppc64 requires /sbin/ldconfig libapreq2-devel-2.09-0.15.rc2.fc9.ppc requires /bin/sh libapreq2-devel-2.09-0.15.rc2.fc9.ppc64 requires /bin/sh libarchive-2.4.17-1.fc9.ppc requires /sbin/ldconfig libarchive-2.4.17-1.fc9.ppc64 requires /sbin/ldconfig libart_lgpl-2.3.20-1.fc9.ppc requires /sbin/ldconfig libart_lgpl-2.3.20-1.fc9.ppc64 requires /sbin/ldconfig libart_lgpl-devel-2.3.20-1.fc9.ppc requires /bin/sh libart_lgpl-devel-2.3.20-1.fc9.ppc64 requires /bin/sh libassa-3.5.0-2.ppc requires /sbin/ldconfig libassa-3.5.0-2.ppc64 requires /sbin/ldconfig libassuan-devel-1.0.4-3.fc9.ppc requires /bin/sh libassuan-devel-1.0.4-3.fc9.ppc requires /sbin/install-info libassuan-devel-1.0.4-3.fc9.ppc requires /bin/sh libassuan-devel-1.0.4-3.fc9.ppc64 requires /bin/sh libassuan-devel-1.0.4-3.fc9.ppc64 requires /sbin/install-info libassuan-devel-1.0.4-3.fc9.ppc64 requires /bin/sh libast-0.7.1-0.6.20080502cvs.fc10.ppc requires /sbin/ldconfig libast-0.7.1-0.6.20080502cvs.fc10.ppc64 requires /sbin/ldconfig libast-devel-0.7.1-0.6.20080502cvs.fc10.ppc requires /bin/sh libast-devel-0.7.1-0.6.20080502cvs.fc10.ppc64 requires /bin/sh libattr-2.4.41-1.fc9.ppc requires /sbin/ldconfig libattr-2.4.41-1.fc9.ppc64 requires /sbin/ldconfig libavc1394-0.5.3-2.fc9.ppc requires /sbin/ldconfig libavc1394-0.5.3-2.fc9.ppc64 requires /sbin/ldconfig libax25-0.0.11-3.fc9.ppc requires /sbin/ldconfig libax25-0.0.11-3.fc9.ppc64 requires /sbin/ldconfig libbeagle-0.3.5-1.fc9.ppc requires /sbin/ldconfig libbeagle-0.3.5-1.fc9.ppc64 requires /sbin/ldconfig libbinio-1.4-9.fc9.ppc requires /sbin/ldconfig libbinio-1.4-9.fc9.ppc64 requires /sbin/ldconfig libbinio-devel-1.4-9.fc9.ppc requires /bin/sh libbinio-devel-1.4-9.fc9.ppc requires /sbin/install-info libbinio-devel-1.4-9.fc9.ppc64 requires /bin/sh libbinio-devel-1.4-9.fc9.ppc64 requires /sbin/install-info libbonobo-2.22.0-3.fc10.ppc requires /sbin/ldconfig libbonobo-2.22.0-3.fc10.ppc requires /usr/bin/perl libbonobo-2.22.0-3.fc10.ppc64 requires /sbin/ldconfig libbonobo-2.22.0-3.fc10.ppc64 requires /usr/bin/perl libbonoboui-2.22.0-2.fc9.ppc requires /sbin/ldconfig libbonoboui-2.22.0-2.fc9.ppc64 requires /sbin/ldconfig libbtctl-0.10.0-2.fc9.ppc requires /sbin/ldconfig libbtctl-0.10.0-2.fc9.ppc64 requires /sbin/ldconfig libburn-0.4.0-2.fc9.ppc requires /sbin/ldconfig libburn-0.4.0-2.fc9.ppc64 requires /sbin/ldconfig libc-client-2007a1-3.fc9.ppc requires /sbin/ldconfig libc-client-2007a1-3.fc9.ppc64 requires /sbin/ldconfig libcaca-0.99-0.4.beta11.fc9.ppc requires /sbin/ldconfig libcaca-0.99-0.4.beta11.fc9.ppc64 requires /sbin/ldconfig libcaca-devel-0.99-0.4.beta11.fc9.ppc requires /bin/sh libcaca-devel-0.99-0.4.beta11.fc9.ppc64 requires /bin/sh libcap-2.06-4.fc9.ppc requires /sbin/ldconfig libcap-2.06-4.fc9.ppc64 requires /sbin/ldconfig libcapseo-0.2.0-0.1.20080323git1c5f3e5.fc10.ppc requires /sbin/ldconfig libcapseo-0.2.0-0.1.20080323git1c5f3e5.fc10.ppc64 requires /sbin/ldconfig libcdaudio-0.99.12p2-9.fc9.ppc requires /sbin/ldconfig libcdaudio-0.99.12p2-9.fc9.ppc64 requires /sbin/ldconfig libcdaudio-devel-0.99.12p2-9.fc9.ppc requires /bin/sh libcdaudio-devel-0.99.12p2-9.fc9.ppc64 requires /bin/sh libcddb-1.3.0-4.fc9.ppc requires /sbin/ldconfig libcddb-1.3.0-4.fc9.ppc64 requires /sbin/ldconfig libcdio-0.79-3.fc9.ppc requires /bin/sh libcdio-0.79-3.fc9.ppc requires /sbin/install-info libcdio-0.79-3.fc9.ppc requires /sbin/ldconfig libcdio-0.79-3.fc9.ppc64 requires /sbin/install-info libcdio-0.79-3.fc9.ppc64 requires /sbin/ldconfig libcdio-0.79-3.fc9.ppc64 requires /bin/sh libcgi-1.0-8.fc9.ppc requires /sbin/ldconfig libcgi-1.0-8.fc9.ppc64 requires /sbin/ldconfig libchewing-0.3.0-11.fc10.ppc requires /sbin/ldconfig libchewing-0.3.0-11.fc10.ppc64 requires /sbin/ldconfig libchmxx-0.2-2.fc9.ppc requires /sbin/ldconfig libchmxx-0.2-2.fc9.ppc64 requires /sbin/ldconfig libcmml-0.9.1-5.fc9.ppc requires /sbin/ldconfig libcmml-0.9.1-5.fc9.ppc64 requires /sbin/ldconfig libcmpiutil-0.3-1.fc9.ppc requires /sbin/ldconfig libcmpiutil-0.3-1.fc9.ppc64 requires /sbin/ldconfig libcompizconfig-0.7.2-1.fc9.ppc requires /sbin/ldconfig libconcord-0.20-5.fc10.ppc requires /sbin/ldconfig libconcord-0.20-5.fc10.ppc64 requires /sbin/ldconfig libconfig-1.2.1-2.fc9.ppc requires /sbin/ldconfig libconfig-1.2.1-2.fc9.ppc64 requires /sbin/ldconfig libconfig-devel-1.2.1-2.fc9.ppc requires /bin/sh libconfig-devel-1.2.1-2.fc9.ppc requires /sbin/install-info libconfig-devel-1.2.1-2.fc9.ppc64 requires /bin/sh libconfig-devel-1.2.1-2.fc9.ppc64 requires /sbin/install-info libconfuse-2.6-1.fc9.ppc requires /sbin/ldconfig libconfuse-2.6-1.fc9.ppc64 requires /sbin/ldconfig libcroco-0.6.1-5.fc9.ppc requires /bin/sh libcroco-0.6.1-5.fc9.ppc64 requires /bin/sh libcroco-devel-0.6.1-5.fc9.ppc requires /bin/sh libcroco-devel-0.6.1-5.fc9.ppc64 requires /bin/sh libctl-3.0.2-6.fc9.ppc requires /sbin/ldconfig libctl-3.0.2-6.fc9.ppc64 requires /sbin/ldconfig libctl-devel-3.0.2-6.fc9.ppc requires /bin/sh libctl-devel-3.0.2-6.fc9.ppc64 requires /bin/sh libcurl-7.18.1-2.fc10.ppc requires /sbin/ldconfig libcurl-7.18.1-2.fc10.ppc64 requires /sbin/ldconfig libcurl-devel-7.18.1-2.fc10.ppc requires /bin/sh libcurl-devel-7.18.1-2.fc10.ppc64 requires /bin/sh libdaemon-0.12-3.fc9.ppc requires /sbin/ldconfig libdaemon-0.12-3.fc9.ppc64 requires /sbin/ldconfig libdap-3.7.10-2.fc9.ppc requires /sbin/ldconfig libdap-3.7.10-2.fc9.ppc64 requires /sbin/ldconfig libdap-devel-3.7.10-2.fc9.ppc requires /bin/sh libdap-devel-3.7.10-2.fc9.ppc64 requires /bin/sh libdar-2.3.6-3.fc9.ppc requires /sbin/ldconfig libdar-2.3.6-3.fc9.ppc64 requires /sbin/ldconfig libdbi-0.8.3-1.fc9.ppc requires /sbin/ldconfig libdbi-0.8.3-1.fc9.ppc64 requires /sbin/ldconfig libdbi-drivers-0.8.3-1.fc9.ppc requires /sbin/ldconfig libdc1394-2.0.2-1.fc10.ppc requires /sbin/ldconfig libdc1394-2.0.2-1.fc10.ppc64 requires /sbin/ldconfig libdhcp-1.99.8-1.fc10.ppc requires /sbin/ldconfig libdhcp-1.99.8-1.fc10.ppc64 requires /sbin/ldconfig 12:libdhcp4client-4.0.0-15.fc10.ppc requires /sbin/ldconfig 12:libdhcp4client-4.0.0-15.fc10.ppc64 requires /sbin/ldconfig libdhcp6client-1.0.15-1.fc10.ppc requires /sbin/ldconfig libdhcp6client-1.0.15-1.fc10.ppc64 requires /sbin/ldconfig libdiscid-0.1.1-6.fc9.ppc requires /sbin/ldconfig libdiscid-0.1.1-6.fc9.ppc64 requires /sbin/ldconfig libdmx-1.0.2-5.fc9.ppc requires /sbin/ldconfig libdmx-1.0.2-5.fc9.ppc64 requires /sbin/ldconfig libdnet-1.12-3.fc9.ppc requires /sbin/ldconfig libdnet-1.12-3.fc9.ppc64 requires /sbin/ldconfig libdnet-devel-1.12-3.fc9.ppc requires /bin/sh libdnet-devel-1.12-3.fc9.ppc64 requires /bin/sh libdockapp-0.6.2-1.fc10.ppc requires /sbin/ldconfig libdockapp-0.6.2-1.fc10.ppc64 requires /sbin/ldconfig libdockapp-fonts-0.6.2-1.fc10.ppc requires /bin/sh libdrm-2.4.0-0.11.fc9.ppc requires /sbin/ldconfig libdrm-2.4.0-0.11.fc9.ppc64 requires /sbin/ldconfig libdsk-1.2.1-1.fc9.ppc requires /sbin/ldconfig libdsk-1.2.1-1.fc9.ppc64 requires /sbin/ldconfig libdstr-20080124-1.fc9.ppc requires /sbin/ldconfig libdstr-20080124-1.fc9.ppc64 requires /sbin/ldconfig libdv-1.0.0-4.fc9.ppc requires /sbin/ldconfig libdv-1.0.0-4.fc9.ppc64 requires /sbin/ldconfig libdvdnav-4.1.1-6.fc9.ppc requires /sbin/ldconfig libdvdnav-4.1.1-6.fc9.ppc64 requires /sbin/ldconfig libdvdnav-devel-4.1.1-6.fc9.ppc requires /bin/sh libdvdnav-devel-4.1.1-6.fc9.ppc64 requires /bin/sh libdvdread-4.1.1-6.fc9.ppc requires /sbin/ldconfig libdvdread-4.1.1-6.fc9.ppc64 requires /sbin/ldconfig libdwarves1-1.6-1.ppc requires /sbin/ldconfig libdwarves1-1.6-1.ppc64 requires /sbin/ldconfig libeXosip2-3.1.0-1.fc9.ppc requires /sbin/ldconfig libeXosip2-3.1.0-1.fc9.ppc64 requires /sbin/ldconfig libebml-0.7.8-1.fc9.ppc requires /sbin/ldconfig libebml-0.7.8-1.fc9.ppc64 requires /sbin/ldconfig libedit-2.10-4.20070831cvs.fc9.ppc requires /sbin/ldconfig libedit-2.10-4.20070831cvs.fc9.ppc64 requires /sbin/ldconfig libepc-0.3.5-1.fc10.ppc requires /sbin/ldconfig libepc-0.3.5-1.fc10.ppc64 requires /sbin/ldconfig libepc-ui-0.3.5-1.fc10.ppc requires /sbin/ldconfig libepc-ui-0.3.5-1.fc10.ppc64 requires /sbin/ldconfig liberation-fonts-1.0-4.fc9.noarch requires /bin/sh libesmtp-1.0.4-7.fc9.ppc requires /sbin/ldconfig libesmtp-1.0.4-7.fc9.ppc64 requires /sbin/ldconfig libesmtp-devel-1.0.4-7.fc9.ppc requires /bin/sh libesmtp-devel-1.0.4-7.fc9.ppc64 requires /bin/sh libetpan-0.52-5.fc9.ppc requires /sbin/ldconfig libetpan-0.52-5.fc9.ppc64 requires /sbin/ldconfig libetpan-devel-0.52-5.fc9.ppc requires /bin/sh libetpan-devel-0.52-5.fc9.ppc64 requires /bin/sh libevent-1.3e-2.fc9.ppc requires /sbin/ldconfig libevent-1.3e-2.fc9.ppc64 requires /sbin/ldconfig libevent-devel-1.3e-2.fc9.ppc requires /usr/bin/env libevent-devel-1.3e-2.fc9.ppc64 requires /usr/bin/env libewf-20080501-1.fc10.ppc requires /sbin/ldconfig libewf-20080501-1.fc10.ppc64 requires /sbin/ldconfig libexif-0.6.16-1.fc9.ppc requires /sbin/ldconfig libexif-0.6.16-1.fc9.ppc64 requires /sbin/ldconfig libextractor-0.5.19a-1.fc9.ppc requires /sbin/install-info libextractor-0.5.19a-1.fc9.ppc requires /sbin/ldconfig libextractor-0.5.19a-1.fc9.ppc requires /bin/sh libextractor-0.5.19a-1.fc9.ppc64 requires /bin/sh libextractor-0.5.19a-1.fc9.ppc64 requires /sbin/ldconfig libextractor-0.5.19a-1.fc9.ppc64 requires /sbin/install-info libextractor-devel-0.5.19a-1.fc9.ppc requires /usr/lib/pkgconfig libextractor-devel-0.5.19a-1.fc9.ppc64 requires /usr/lib64/pkgconfig libextractor-plugins-thumbnailgtk-0.5.19a-1.fc9.ppc requires /usr/sbin/update-alternatives libextractor-plugins-thumbnailgtk-0.5.19a-1.fc9.ppc requires /bin/sh libextractor-plugins-thumbnailqt-0.5.19a-1.fc9.ppc requires /bin/sh libextractor-plugins-thumbnailqt-0.5.19a-1.fc9.ppc requires /usr/sbin/update-alternatives libffi-3.0.1-1.fc9.ppc requires /sbin/ldconfig libffi-3.0.1-1.fc9.ppc64 requires /sbin/ldconfig libffi-devel-3.0.1-1.fc9.ppc requires /bin/sh libffi-devel-3.0.1-1.fc9.ppc requires /sbin/install-info libffi-devel-3.0.1-1.fc9.ppc64 requires /bin/sh libffi-devel-3.0.1-1.fc9.ppc64 requires /sbin/install-info libfishsound-0.9.1-1.fc9.ppc requires /sbin/ldconfig libfishsound-0.9.1-1.fc9.ppc64 requires /sbin/ldconfig libflaim-4.9.1052-1.fc9.ppc requires /sbin/ldconfig libflaim-4.9.1052-1.fc9.ppc64 requires /sbin/ldconfig libfontenc-1.0.4-5.fc9.ppc requires /sbin/ldconfig libfontenc-1.0.4-5.fc9.ppc64 requires /sbin/ldconfig libfprint-0.0.5-6.fc10.ppc requires /sbin/ldconfig libfprint-0.0.5-6.fc10.ppc64 requires /sbin/ldconfig libfreebob-1.0.7-4.fc9.ppc requires /sbin/ldconfig libfreebob-1.0.7-4.fc9.ppc64 requires /sbin/ldconfig libfwbuilder-2.1.16-2.fc9.ppc requires /sbin/ldconfig libfwbuilder-2.1.16-2.fc9.ppc64 requires /sbin/ldconfig libfwbuilder-devel-2.1.16-2.fc9.ppc requires /bin/sh libfwbuilder-devel-2.1.16-2.fc9.ppc64 requires /bin/sh libgadu-1.8.0-1.fc9.ppc requires /sbin/ldconfig libgadu-1.8.0-1.fc9.ppc64 requires /sbin/ldconfig libgail-gnome-1.20.0-2.fc9.ppc requires /sbin/ldconfig libgail-gnome-1.20.0-2.fc9.ppc64 requires /sbin/ldconfig libgalago-0.5.2-7.fc9.ppc requires /sbin/ldconfig libgalago-0.5.2-7.fc9.ppc64 requires /sbin/ldconfig libgalago-gtk-0.5.0-7.fc9.ppc requires /sbin/ldconfig libgalago-gtk-0.5.0-7.fc9.ppc64 requires /sbin/ldconfig libgcc-4.3.0-8.ppc requires /usr/sbin/libgcc_post_upgrade libgcc-4.3.0-8.ppc64 requires /usr/sbin/libgcc_post_upgrade libgcj-4.3.0-8.ppc requires /bin/sh libgcj-4.3.0-8.ppc requires /sbin/install-info libgcj-4.3.0-8.ppc requires /sbin/ldconfig libgcj-4.3.0-8.ppc64 requires /sbin/install-info libgcj-4.3.0-8.ppc64 requires /sbin/ldconfig libgcj-4.3.0-8.ppc64 requires /bin/sh libgcj-devel-4.3.0-8.ppc requires /usr/lib/libgcj.so.9 libgcj-devel-4.3.0-8.ppc requires /usr/lib/libz.so libgcj-devel-4.3.0-8.ppc requires /bin/awk libgcj-devel-4.3.0-8.ppc64 requires /usr/lib64/libgcj.so.9 libgcj-devel-4.3.0-8.ppc64 requires /bin/awk libgcj-devel-4.3.0-8.ppc64 requires /usr/lib64/libz.so libgconf-java-2.12.4-10.fc9.ppc requires /sbin/ldconfig libgconf-java-2.12.4-10.fc9.ppc64 requires /sbin/ldconfig libgconf-java-devel-2.12.4-10.fc9.ppc requires /bin/sh libgconf-java-devel-2.12.4-10.fc9.ppc64 requires /bin/sh libgcroots-0.2.1-3.fc9.ppc requires /sbin/ldconfig libgcroots-0.2.1-3.fc9.ppc64 requires /sbin/ldconfig libgcrypt-1.4.0-3.ppc requires /sbin/ldconfig libgcrypt-1.4.0-3.ppc64 requires /sbin/ldconfig libgcrypt-devel-1.4.0-3.ppc requires /bin/sh libgcrypt-devel-1.4.0-3.ppc requires /sbin/install-info libgcrypt-devel-1.4.0-3.ppc requires /bin/sh libgcrypt-devel-1.4.0-3.ppc64 requires /bin/sh libgcrypt-devel-1.4.0-3.ppc64 requires /sbin/install-info libgcrypt-devel-1.4.0-3.ppc64 requires /bin/sh 1:libgda-3.1.2-3.fc9.ppc requires /sbin/ldconfig 1:libgda-3.1.2-3.fc9.ppc64 requires /sbin/ldconfig 1:libgda-devel-3.1.2-3.fc9.ppc requires /bin/sh 1:libgda-devel-3.1.2-3.fc9.ppc64 requires /bin/sh libgdamm-3.0.0-1.fc9.ppc requires /sbin/ldconfig libgdamm-3.0.0-1.fc9.ppc64 requires /sbin/ldconfig libgdiplus-1.9-4.fc9.ppc requires /sbin/ldconfig libgdiplus-1.9-4.fc9.ppc64 requires /sbin/ldconfig libgdl-0.7.11-1.fc9.ppc requires /sbin/ldconfig libgdl-0.7.11-1.fc9.ppc64 requires /sbin/ldconfig libgeda-20080127-1.fc9.ppc requires /sbin/ldconfig libgeda-20080127-1.fc9.ppc requires /bin/sh libgeda-20080127-1.fc9.ppc64 requires /bin/sh libgeda-20080127-1.fc9.ppc64 requires /sbin/ldconfig libgee-0.1.1-3.fc9.ppc requires /sbin/ldconfig libgee-0.1.1-3.fc9.ppc64 requires /sbin/ldconfig libgeotiff-1.2.4-3.fc9.ppc requires /sbin/ldconfig libgeotiff-1.2.4-3.fc9.ppc64 requires /sbin/ldconfig libgfortran-4.3.0-8.ppc requires /sbin/ldconfig libgfortran-4.3.0-8.ppc64 requires /sbin/ldconfig libggz-0.0.14.1-1.fc9.ppc requires /sbin/ldconfig libggz-0.0.14.1-1.fc9.ppc64 requires /sbin/ldconfig libgii-1.0.2-6.fc9.ppc requires /sbin/ldconfig libgii-1.0.2-6.fc9.ppc64 requires /sbin/ldconfig 1:libglade-0.17-21.fc9.ppc requires /sbin/ldconfig 1:libglade-0.17-21.fc9.ppc64 requires /sbin/ldconfig 1:libglade-devel-0.17-21.fc9.ppc requires /usr/bin/env 1:libglade-devel-0.17-21.fc9.ppc requires /bin/sh 1:libglade-devel-0.17-21.fc9.ppc64 requires /usr/bin/env 1:libglade-devel-0.17-21.fc9.ppc64 requires /bin/sh libglade-java-2.12.5-8.fc9.ppc requires /sbin/ldconfig libglade-java-2.12.5-8.fc9.ppc64 requires /sbin/ldconfig libglade2-2.6.2-5.fc9.ppc requires /sbin/ldconfig libglade2-2.6.2-5.fc9.ppc64 requires /sbin/ldconfig libglade2-devel-2.6.2-5.fc9.ppc requires /usr/bin/python libglade2-devel-2.6.2-5.fc9.ppc64 requires /usr/bin/python libglademm24-2.6.6-1.fc9.ppc requires /sbin/ldconfig libglademm24-2.6.6-1.fc9.ppc requires /bin/sh libglademm24-2.6.6-1.fc9.ppc64 requires /bin/sh libglademm24-2.6.6-1.fc9.ppc64 requires /sbin/ldconfig libgnat-4.3.0-8.ppc requires /sbin/ldconfig libgnome-2.22.0-3.fc9.ppc requires /bin/sh libgnome-2.22.0-3.fc9.ppc requires /sbin/ldconfig libgnome-2.22.0-3.fc9.ppc64 requires /bin/sh libgnome-2.22.0-3.fc9.ppc64 requires /sbin/ldconfig libgnome-java-2.12.4-8.fc9.ppc requires /sbin/ldconfig libgnome-java-2.12.4-8.fc9.ppc64 requires /sbin/ldconfig libgnomecanvas-2.20.1.1-2.fc9.ppc requires /sbin/ldconfig libgnomecanvas-2.20.1.1-2.fc9.ppc64 requires /sbin/ldconfig libgnomecanvasmm26-2.22.0-1.fc9.ppc requires /sbin/ldconfig libgnomecanvasmm26-2.22.0-1.fc9.ppc requires /bin/sh libgnomecanvasmm26-2.22.0-1.fc9.ppc64 requires /bin/sh libgnomecanvasmm26-2.22.0-1.fc9.ppc64 requires /sbin/ldconfig libgnomecups-0.2.3-3.fc9.ppc requires /sbin/ldconfig libgnomecups-0.2.3-3.fc9.ppc64 requires /sbin/ldconfig 1:libgnomedb-3.0.0-6.fc9.ppc requires /sbin/ldconfig 1:libgnomedb-3.0.0-6.fc9.ppc requires /bin/sh 1:libgnomedb-3.0.0-6.fc9.ppc64 requires /bin/sh 1:libgnomedb-3.0.0-6.fc9.ppc64 requires /sbin/ldconfig 1:libgnomedb-devel-3.0.0-6.fc9.ppc requires /bin/sh 1:libgnomedb-devel-3.0.0-6.fc9.ppc64 requires /bin/sh libgnomedbmm-2.9.5-4.fc9.ppc requires /sbin/ldconfig libgnomedbmm-2.9.5-4.fc9.ppc64 requires /sbin/ldconfig libgnomekbd-2.23.2-1.fc10.ppc requires /bin/sh libgnomekbd-2.23.2-1.fc10.ppc64 requires /bin/sh libgnomemm26-2.22.0-1.ppc requires /sbin/ldconfig libgnomemm26-2.22.0-1.ppc requires /bin/sh libgnomemm26-2.22.0-1.ppc64 requires /bin/sh libgnomemm26-2.22.0-1.ppc64 requires /sbin/ldconfig libgnomeprint22-2.18.4-1.fc9.ppc requires /sbin/ldconfig libgnomeprint22-2.18.4-1.fc9.ppc64 requires /sbin/ldconfig libgnomeprintui22-2.18.2-1.fc9.ppc requires /sbin/ldconfig libgnomeprintui22-2.18.2-1.fc9.ppc64 requires /sbin/ldconfig libgnomeui-2.22.1-2.fc9.ppc requires /sbin/ldconfig libgnomeui-2.22.1-2.fc9.ppc64 requires /sbin/ldconfig libgnomeuimm26-2.22.0-1.fc9.ppc requires /sbin/ldconfig libgnomeuimm26-2.22.0-1.fc9.ppc requires /bin/sh libgnomeuimm26-2.22.0-1.fc9.ppc64 requires /bin/sh libgnomeuimm26-2.22.0-1.fc9.ppc64 requires /sbin/ldconfig libgomp-4.3.0-8.ppc requires /bin/sh libgomp-4.3.0-8.ppc requires /sbin/ldconfig libgomp-4.3.0-8.ppc requires /sbin/install-info libgomp-4.3.0-8.ppc64 requires /bin/sh libgomp-4.3.0-8.ppc64 requires /sbin/ldconfig libgomp-4.3.0-8.ppc64 requires /sbin/install-info libgpg-error-1.6-2.ppc requires /sbin/ldconfig libgpg-error-1.6-2.ppc64 requires /sbin/ldconfig libgpg-error-devel-1.6-2.ppc requires /bin/sh libgpg-error-devel-1.6-2.ppc64 requires /bin/sh libgpod-0.6.0-5.fc10.ppc requires /sbin/ldconfig libgpod-0.6.0-5.fc10.ppc64 requires /sbin/ldconfig libgringotts-1.2.1-4.fc9.ppc requires /sbin/ldconfig libgringotts-1.2.1-4.fc9.ppc64 requires /sbin/ldconfig libgsasl-0.2.18-6.fc9.ppc requires /sbin/ldconfig libgsasl-0.2.18-6.fc9.ppc64 requires /sbin/ldconfig libgsf-1.14.8-1.fc9.ppc requires /bin/sh libgsf-1.14.8-1.fc9.ppc requires /sbin/ldconfig libgsf-1.14.8-1.fc9.ppc64 requires /bin/sh libgsf-1.14.8-1.fc9.ppc64 requires /sbin/ldconfig libgsf-gnome-1.14.8-1.fc9.ppc requires /sbin/ldconfig libgsf-gnome-1.14.8-1.fc9.ppc64 requires /sbin/ldconfig libgssapi-0.11-3.fc9.ppc requires /sbin/ldconfig libgssapi-0.11-3.fc9.ppc64 requires /sbin/ldconfig libgssglue-0.1-5.fc9.ppc requires /sbin/ldconfig libgssglue-0.1-5.fc9.ppc64 requires /sbin/ldconfig libgstroke-0.5.1-17.fc9.ppc requires /sbin/ldconfig libgstroke-0.5.1-17.fc9.ppc64 requires /sbin/ldconfig libgtk-java-2.8.7-7.fc9.ppc requires /sbin/ldconfig libgtk-java-2.8.7-7.fc9.ppc64 requires /sbin/ldconfig libgtk-java-devel-2.8.7-7.fc9.ppc requires /bin/sh libgtk-java-devel-2.8.7-7.fc9.ppc64 requires /bin/sh libgtksourceviewmm-0.3.1-1.fc8.ppc requires /sbin/ldconfig libgtksourceviewmm-0.3.1-1.fc8.ppc64 requires /sbin/ldconfig libgtop2-2.22.1-1.fc9.ppc requires /sbin/ldconfig libgtop2-2.22.1-1.fc9.ppc64 requires /sbin/ldconfig libgweather-2.23.2-1.fc10.ppc requires /sbin/ldconfig libgweather-2.23.2-1.fc10.ppc requires /bin/sh libgweather-2.23.2-1.fc10.ppc64 requires /bin/sh libgweather-2.23.2-1.fc10.ppc64 requires /sbin/ldconfig libhangul-0.0.6-4.fc9.ppc requires /sbin/ldconfig libhangul-0.0.6-4.fc9.ppc64 requires /sbin/ldconfig libhugetlbfs-1.1-6.fc9.ppc requires /bin/bash libhugetlbfs-test-1.1-6.fc9.ppc requires /bin/bash libibverbs-1.1.1-3.fc9.ppc requires /sbin/ldconfig libibverbs-1.1.1-3.fc9.ppc64 requires /sbin/ldconfig libical-0.30-1.fc9.ppc requires /sbin/ldconfig libical-0.30-1.fc9.ppc64 requires /sbin/ldconfig libical-devel-0.30-1.fc9.ppc requires /bin/sh libical-devel-0.30-1.fc9.ppc64 requires /bin/sh libicu-3.8.1-7.fc9.ppc requires /sbin/ldconfig libicu-3.8.1-7.fc9.ppc64 requires /sbin/ldconfig libicu-devel-3.8.1-7.fc9.ppc requires /bin/sh libicu-devel-3.8.1-7.fc9.ppc64 requires /bin/sh libid3tag-0.15.1b-6.fc10.ppc requires /sbin/ldconfig libid3tag-0.15.1b-6.fc10.ppc64 requires /sbin/ldconfig libident-0.32-2.fc9.ppc requires /sbin/ldconfig libident-0.32-2.fc9.ppc64 requires /sbin/ldconfig libident-tools-0.32-2.fc9.ppc requires /bin/sh libidn-0.6.14-7.ppc requires /bin/sh libidn-0.6.14-7.ppc requires /sbin/ldconfig libidn-0.6.14-7.ppc requires /sbin/install-info libidn-0.6.14-7.ppc64 requires /bin/sh libidn-0.6.14-7.ppc64 requires /sbin/ldconfig libidn-0.6.14-7.ppc64 requires /sbin/install-info libiec61883-1.1.0-4.fc9.ppc requires /sbin/ldconfig libiec61883-1.1.0-4.fc9.ppc64 requires /sbin/ldconfig libieee1284-0.2.11-3.fc9.ppc requires /sbin/ldconfig libieee1284-0.2.11-3.fc9.ppc64 requires /sbin/ldconfig libifp-1.0.0.2-7.fc9.ppc requires /sbin/ldconfig libifp-1.0.0.2-7.fc9.ppc requires /bin/bash libifp-1.0.0.2-7.fc9.ppc64 requires /sbin/ldconfig libifp-1.0.0.2-7.fc9.ppc64 requires /bin/bash libipoddevice-0.5.3-4.fc9.ppc requires /sbin/ldconfig libipoddevice-0.5.3-4.fc9.ppc64 requires /sbin/ldconfig libiptcdata-1.0.2-2.fc9.ppc requires /sbin/ldconfig libiptcdata-1.0.2-2.fc9.ppc64 requires /sbin/ldconfig libisofs-0.2.8-3.fc9.ppc requires /sbin/ldconfig libisofs-0.2.8-3.fc9.ppc64 requires /sbin/ldconfig libitl-0.6.4-4.fc9.ppc requires /sbin/ldconfig libitl-0.6.4-4.fc9.ppc64 requires /sbin/ldconfig libjingle-0.3.11-8.fc9.ppc requires /sbin/ldconfig libjingle-0.3.11-8.fc9.ppc64 requires /sbin/ldconfig libjpeg-6b-41.fc9.ppc requires /sbin/ldconfig libjpeg-6b-41.fc9.ppc64 requires /sbin/ldconfig libkdcraw-0.1.4-1.fc10.ppc requires /bin/sh libkdcraw-0.1.4-1.fc10.ppc64 requires /bin/sh libkexif-0.2.5-4.fc9.ppc requires /sbin/ldconfig libkexif-0.2.5-4.fc9.ppc64 requires /sbin/ldconfig libkexiv2-0.1.7-1.fc10.ppc requires /sbin/ldconfig libkexiv2-0.1.7-1.fc10.ppc64 requires /sbin/ldconfig libkipi-0.1.6-1.fc10.ppc requires /bin/sh libkipi-0.1.6-1.fc10.ppc64 requires /bin/sh libksba-1.0.3-2.fc9.ppc requires /sbin/ldconfig libksba-1.0.3-2.fc9.ppc64 requires /sbin/ldconfig libksba-devel-1.0.3-2.fc9.ppc requires /sbin/install-info libksba-devel-1.0.3-2.fc9.ppc requires /bin/sh libksba-devel-1.0.3-2.fc9.ppc requires /bin/sh libksba-devel-1.0.3-2.fc9.ppc64 requires /sbin/install-info libksba-devel-1.0.3-2.fc9.ppc64 requires /bin/sh libksba-devel-1.0.3-2.fc9.ppc64 requires /bin/sh liblo-0.24-2.fc9.ppc requires /sbin/ldconfig liblo-0.24-2.fc9.ppc64 requires /sbin/ldconfig liblqr-1-0.1.0-5.fc9.ppc requires /sbin/ldconfig liblqr-1-0.1.0-5.fc9.ppc64 requires /sbin/ldconfig liblrdf-0.4.0-13.fc9.ppc requires /sbin/ldconfig liblrdf-0.4.0-13.fc9.ppc64 requires /sbin/ldconfig libmal-0.31-8.fc9.ppc requires /sbin/ldconfig libmal-0.31-8.fc9.ppc64 requires /sbin/ldconfig libmalaga-7.12-1.fc9.ppc requires /sbin/ldconfig libmalaga-7.12-1.fc9.ppc64 requires /sbin/ldconfig libmatchbox-1.9-3.fc9.ppc requires /sbin/ldconfig libmatchbox-1.9-3.fc9.ppc64 requires /sbin/ldconfig libmatheval-1.1.5-2.fc9.ppc requires /sbin/ldconfig libmatheval-1.1.5-2.fc9.ppc64 requires /sbin/ldconfig libmatheval-devel-1.1.5-2.fc9.ppc requires /bin/sh libmatheval-devel-1.1.5-2.fc9.ppc requires /sbin/install-info libmatheval-devel-1.1.5-2.fc9.ppc64 requires /bin/sh libmatheval-devel-1.1.5-2.fc9.ppc64 requires /sbin/install-info libmatroska-0.8.1-3.fc9.ppc requires /sbin/ldconfig libmatroska-0.8.1-3.fc9.ppc64 requires /sbin/ldconfig libmcrypt-2.5.8-5.fc9.ppc requires /sbin/ldconfig libmcrypt-2.5.8-5.fc9.ppc64 requires /sbin/ldconfig libmcrypt-devel-2.5.8-5.fc9.ppc requires /bin/sh libmcrypt-devel-2.5.8-5.fc9.ppc64 requires /bin/sh libmikmod-3.2.0-3.beta2.fc9.ppc requires /sbin/ldconfig libmikmod-3.2.0-3.beta2.fc9.ppc64 requires /sbin/ldconfig libmikmod-devel-3.2.0-3.beta2.fc9.ppc requires /bin/sh libmikmod-devel-3.2.0-3.beta2.fc9.ppc requires /bin/sh libmikmod-devel-3.2.0-3.beta2.fc9.ppc64 requires /bin/sh libmikmod-devel-3.2.0-3.beta2.fc9.ppc64 requires /bin/sh libmng-1.0.9-6.1.ppc requires /sbin/ldconfig libmng-1.0.9-6.1.ppc64 requires /sbin/ldconfig libmodelfile-0.1.92-5.fc9.ppc requires /sbin/ldconfig libmodelfile-0.1.92-5.fc9.ppc64 requires /sbin/ldconfig 1:libmodplug-0.8.4-3.fc9.ppc requires /sbin/ldconfig 1:libmodplug-0.8.4-3.fc9.ppc64 requires /sbin/ldconfig libmowgli-0.5.0-2.fc9.ppc requires /sbin/ldconfig libmowgli-0.5.0-2.fc9.ppc64 requires /sbin/ldconfig libmp4v2-1.5.0.1-6.fc9.ppc requires /sbin/ldconfig libmp4v2-1.5.0.1-6.fc9.ppc64 requires /sbin/ldconfig libmpcdec-1.2.6-4.fc9.ppc requires /sbin/ldconfig libmpcdec-1.2.6-4.fc9.ppc64 requires /sbin/ldconfig libmpd-0.15.0-3.fc9.ppc requires /sbin/ldconfig libmpd-0.15.0-3.fc9.ppc64 requires /sbin/ldconfig libmspack-0.0-0.5.20060920alpha.fc9.ppc requires /sbin/ldconfig libmspack-0.0-0.5.20060920alpha.fc9.ppc64 requires /sbin/ldconfig libmtp-0.2.6.1-1.fc9.ppc requires /sbin/ldconfig libmtp-0.2.6.1-1.fc9.ppc64 requires /sbin/ldconfig libmudflap-4.3.0-8.ppc requires /sbin/ldconfig libmudflap-4.3.0-8.ppc64 requires /sbin/ldconfig libmusicbrainz-2.1.5-6.fc9.ppc requires /sbin/ldconfig libmusicbrainz-2.1.5-6.fc9.ppc64 requires /sbin/ldconfig libnasl-2.2.10-5.fc9.ppc requires /sbin/ldconfig libnasl-2.2.10-5.fc9.ppc64 requires /sbin/ldconfig libnasl-devel-2.2.10-5.fc9.ppc requires /bin/sh libnasl-devel-2.2.10-5.fc9.ppc64 requires /bin/sh libnc-dap-3.7.0-9.fc9.ppc requires /sbin/ldconfig libnc-dap-3.7.0-9.fc9.ppc64 requires /sbin/ldconfig libnc-dap-devel-3.7.0-9.fc9.ppc requires /bin/sh libnc-dap-devel-3.7.0-9.fc9.ppc64 requires /bin/sh libnemesi-0.6.4-0.3.rc2.fc9.ppc requires /sbin/ldconfig libnemesi-0.6.4-0.3.rc2.fc9.ppc64 requires /sbin/ldconfig libnet-devel-1.1.2.1-12.fc9.ppc requires /bin/sh libnet-devel-1.1.2.1-12.fc9.ppc64 requires /bin/sh libnet10-1.0.2a-14.fc9.ppc requires /bin/sh libnetfilter_conntrack-0.0.89-0.1.svn7356.fc9.ppc requires /sbin/ldconfig libnetfilter_conntrack-0.0.89-0.1.svn7356.fc9.ppc64 requires /sbin/ldconfig libnetfilter_log-0.0.13-6.fc9.ppc requires /sbin/ldconfig libnetfilter_log-0.0.13-6.fc9.ppc64 requires /sbin/ldconfig libnetfilter_queue-0.0.15-4.fc9.ppc requires /sbin/ldconfig libnetfilter_queue-0.0.15-4.fc9.ppc64 requires /sbin/ldconfig libnfnetlink-0.0.33-0.1.svn7211.fc9.ppc requires /sbin/ldconfig libnfnetlink-0.0.33-0.1.svn7211.fc9.ppc64 requires /sbin/ldconfig libnids-1.22-4.fc9.ppc requires /sbin/ldconfig libnids-1.22-4.fc9.ppc64 requires /sbin/ldconfig libnjb-2.2.6-3.fc9.ppc requires /sbin/ldconfig libnjb-2.2.6-3.fc9.ppc64 requires /sbin/ldconfig libnl-1.1-3.fc9.ppc requires /sbin/ldconfig libnl-1.1-3.fc9.ppc64 requires /sbin/ldconfig libnotify-0.4.4-10.fc9.ppc requires /bin/sh libnotify-0.4.4-10.fc9.ppc64 requires /bin/sh libnova-0.12.1-3.fc10.ppc requires /sbin/ldconfig libnova-0.12.1-3.fc10.ppc64 requires /sbin/ldconfig libnss-mysql-1.5-7.fc9.ppc requires /sbin/ldconfig libnss-mysql-1.5-7.fc9.ppc64 requires /sbin/ldconfig libntlm-0.4.2-1.fc9.ppc requires /sbin/ldconfig libntlm-0.4.2-1.fc9.ppc64 requires /sbin/ldconfig libobjc-4.3.0-8.ppc requires /sbin/ldconfig libobjc-4.3.0-8.ppc64 requires /sbin/ldconfig libofa-0.9.3-13.fc9.ppc requires /sbin/ldconfig libofa-0.9.3-13.fc9.ppc64 requires /sbin/ldconfig libofx-0.8.3-5.ppc requires /sbin/ldconfig libofx-0.8.3-5.ppc64 requires /sbin/ldconfig 2:libogg-1.1.3-9.fc9.ppc requires /sbin/ldconfig 2:libogg-1.1.3-9.fc9.ppc64 requires /sbin/ldconfig liboggz-0.9.5-2.fc9.ppc requires /sbin/ldconfig liboggz-0.9.5-2.fc9.ppc requires /bin/sh liboggz-0.9.5-2.fc9.ppc64 requires /sbin/ldconfig liboggz-0.9.5-2.fc9.ppc64 requires /bin/sh liboil-0.3.14-1.fc9.ppc requires /sbin/ldconfig liboil-0.3.14-1.fc9.ppc64 requires /sbin/ldconfig libopendaap-0.4.0-5.fc9.ppc requires /sbin/ldconfig libopendaap-0.4.0-5.fc9.ppc64 requires /sbin/ldconfig libopenraw-0.0.5-1.fc9.ppc requires /sbin/ldconfig libopenraw-0.0.5-1.fc9.ppc64 requires /sbin/ldconfig libopenraw-gnome-0.0.5-1.fc9.ppc requires /sbin/ldconfig libopenraw-gnome-0.0.5-1.fc9.ppc64 requires /sbin/ldconfig libopensync-0.36-2.fc9.ppc requires /sbin/ldconfig libopensync-0.36-2.fc9.ppc64 requires /sbin/ldconfig libopensync-plugin-google-calendar-0.35-2.fc9.ppc requires /usr/bin/env libopensync-plugin-kdepim-0.35-2.fc9.ppc requires /sbin/ldconfig libopm-0.1-7.20050731cvs.fc9.ppc requires /sbin/ldconfig libopm-0.1-7.20050731cvs.fc9.ppc64 requires /sbin/ldconfig liborigin-20071119-3.fc10.ppc requires /sbin/ldconfig liborigin-20071119-3.fc10.ppc64 requires /sbin/ldconfig libosip2-3.1.0-1.fc9.ppc requires /sbin/ldconfig libosip2-3.1.0-1.fc9.ppc64 requires /sbin/ldconfig libotf-0.9.7-4.fc10.ppc requires /sbin/ldconfig libotf-0.9.7-4.fc10.ppc64 requires /sbin/ldconfig libotf-devel-0.9.7-4.fc10.ppc requires /bin/sh libotf-devel-0.9.7-4.fc10.ppc64 requires /bin/sh libotr-3.1.0-2.fc9.ppc requires /sbin/ldconfig libotr-3.1.0-2.fc9.ppc64 requires /sbin/ldconfig libp11-0.2.3-2.fc9.ppc requires /sbin/ldconfig libp11-0.2.3-2.fc9.ppc64 requires /sbin/ldconfig libpanelappletmm-2.22.0-1.fc9.ppc requires /sbin/ldconfig libpanelappletmm-2.22.0-1.fc9.ppc64 requires /sbin/ldconfig libpano12-2.8.6-2.fc9.ppc requires /sbin/ldconfig libpano12-2.8.6-2.fc9.ppc64 requires /sbin/ldconfig libpano13-2.9.12-5.fc9.ppc requires /sbin/ldconfig libpano13-2.9.12-5.fc9.ppc64 requires /sbin/ldconfig libpaper-1.1.23-2.fc9.ppc requires /sbin/ldconfig libpaper-1.1.23-2.fc9.ppc requires /bin/bash libpaper-1.1.23-2.fc9.ppc64 requires /sbin/ldconfig libpaper-1.1.23-2.fc9.ppc64 requires /bin/bash libpar2-0.2-5.fc9.ppc requires /sbin/ldconfig libpar2-0.2-5.fc9.ppc64 requires /sbin/ldconfig 14:libpcap-0.9.8-2.fc9.ppc requires /sbin/ldconfig 14:libpcap-0.9.8-2.fc9.ppc64 requires /sbin/ldconfig libpciaccess-0.10-2.fc9.ppc requires /sbin/ldconfig libpciaccess-0.10-2.fc9.ppc64 requires /sbin/ldconfig 2:libpng-1.2.24-1.fc9.ppc requires /sbin/ldconfig 2:libpng-1.2.24-1.fc9.ppc64 requires /sbin/ldconfig 2:libpng-devel-1.2.24-1.fc9.ppc requires /bin/sh 2:libpng-devel-1.2.24-1.fc9.ppc64 requires /bin/sh libpng10-1.0.37-1.fc10.ppc requires /sbin/ldconfig libpng10-1.0.37-1.fc10.ppc64 requires /sbin/ldconfig libpolyxmass-0.9.1-2.fc9.ppc requires /sbin/ldconfig libpolyxmass-0.9.1-2.fc9.ppc64 requires /sbin/ldconfig libpqxx-2.6.8-10.fc9.ppc requires /sbin/ldconfig libpqxx-2.6.8-10.fc9.ppc64 requires /sbin/ldconfig libpqxx-devel-2.6.8-10.fc9.ppc requires /bin/sh libpqxx-devel-2.6.8-10.fc9.ppc64 requires /bin/sh libprelude-0.9.17.1-1.fc10.ppc requires /sbin/ldconfig libprelude-0.9.17.1-1.fc10.ppc requires /bin/sh libprelude-0.9.17.1-1.fc10.ppc64 requires /sbin/ldconfig libprelude-0.9.17.1-1.fc10.ppc64 requires /bin/sh libprelude-devel-0.9.17.1-1.fc10.ppc requires /bin/sh libprelude-devel-0.9.17.1-1.fc10.ppc64 requires /bin/sh libpreludedb-0.9.14.1-2.fc9.ppc requires /sbin/ldconfig libpreludedb-0.9.14.1-2.fc9.ppc64 requires /sbin/ldconfig libpreludedb-devel-0.9.14.1-2.fc9.ppc requires /bin/sh libpreludedb-devel-0.9.14.1-2.fc9.ppc64 requires /bin/sh libpri-1.4.3-2.fc9.ppc requires /sbin/ldconfig libpri-1.4.3-2.fc9.ppc64 requires /sbin/ldconfig libpurple-2.4.1-3.fc10.ppc requires /usr/bin/env libpurple-2.4.1-3.fc10.ppc requires /sbin/ldconfig libpurple-2.4.1-3.fc10.ppc requires /bin/sh libpurple-2.4.1-3.fc10.ppc64 requires /usr/bin/env libpurple-2.4.1-3.fc10.ppc64 requires /sbin/ldconfig libpurple-2.4.1-3.fc10.ppc64 requires /bin/sh libqalculate-0.9.6-4.fc9.ppc requires /sbin/ldconfig libqalculate-0.9.6-4.fc9.ppc64 requires /sbin/ldconfig librapi-0.11-2.fc9.ppc requires /sbin/ldconfig librapi-0.11-2.fc9.ppc requires /bin/bash librapi-0.11-2.fc9.ppc64 requires /sbin/ldconfig librapi-0.11-2.fc9.ppc64 requires /bin/bash libraw1394-1.3.0-6.fc9.ppc requires /sbin/ldconfig libraw1394-1.3.0-6.fc9.ppc64 requires /sbin/ldconfig librdmacm-1.0.7-1.fc9.ppc requires /sbin/ldconfig librdmacm-1.0.7-1.fc9.ppc64 requires /sbin/ldconfig librdmacm-devel-1.0.7-1.fc9.ppc requires /usr/include/infiniband/verbs.h librdmacm-devel-1.0.7-1.fc9.ppc64 requires /usr/include/infiniband/verbs.h libreadline-java-0.8.0-20.fc9.ppc requires /bin/sh librelp-0.1.1-2.fc10.ppc requires /bin/sh librelp-0.1.1-2.fc10.ppc requires /sbin/ldconfig librelp-0.1.1-2.fc10.ppc64 requires /bin/sh librelp-0.1.1-2.fc10.ppc64 requires /sbin/ldconfig librfid-0.2.0-1.fc9.ppc requires /sbin/ldconfig librfid-0.2.0-1.fc9.ppc64 requires /sbin/ldconfig librra-0.11-2.fc9.ppc requires /sbin/ldconfig librra-0.11-2.fc9.ppc64 requires /sbin/ldconfig librsvg2-2.22.2-1.fc9.ppc requires /usr/bin/env librsvg2-2.22.2-1.fc9.ppc requires /bin/sh librsvg2-2.22.2-1.fc9.ppc64 requires /bin/sh librsvg2-2.22.2-1.fc9.ppc64 requires /usr/bin/env librsync-0.9.7-12.fc9.ppc requires /sbin/ldconfig librsync-0.9.7-12.fc9.ppc64 requires /sbin/ldconfig librtas-1.3.3-3.fc9.ppc requires /sbin/ldconfig librtas-1.3.3-3.fc9.ppc64 requires /sbin/ldconfig librtfcomp-1.1-3.fc9.ppc requires /sbin/ldconfig librtfcomp-1.1-3.fc9.ppc64 requires /sbin/ldconfig librx-1.5-10.fc9.ppc requires /sbin/ldconfig librx-1.5-10.fc9.ppc64 requires /sbin/ldconfig librx-devel-1.5-10.fc9.ppc requires /bin/sh librx-devel-1.5-10.fc9.ppc64 requires /bin/sh libsamplerate-0.1.3-1.fc10.ppc requires /sbin/ldconfig libsamplerate-0.1.3-1.fc10.ppc64 requires /sbin/ldconfig libsane-hpaio-2.8.2-3.fc10.ppc requires /bin/sh libscigraphica-2.1.1-8.fc9.ppc requires /sbin/ldconfig libscigraphica-2.1.1-8.fc9.ppc64 requires /sbin/ldconfig libselinux-2.0.64-2.fc10.ppc requires /bin/sh libselinux-2.0.64-2.fc10.ppc requires /sbin/ldconfig libselinux-2.0.64-2.fc10.ppc64 requires /bin/sh libselinux-2.0.64-2.fc10.ppc64 requires /sbin/ldconfig libsemanage-2.0.25-1.fc10.ppc requires /sbin/ldconfig libsemanage-2.0.25-1.fc10.ppc64 requires /sbin/ldconfig libsepol-2.0.26-1.fc9.ppc requires /bin/sh libsepol-2.0.26-1.fc9.ppc requires /sbin/ldconfig libsepol-2.0.26-1.fc9.ppc64 requires /bin/sh libsepol-2.0.26-1.fc9.ppc64 requires /sbin/ldconfig libsexy-0.1.11-8.fc10.ppc requires /sbin/ldconfig libsexy-0.1.11-8.fc10.ppc64 requires /sbin/ldconfig libsexymm-0.1.9-5.fc9.ppc requires /sbin/ldconfig libsexymm-0.1.9-5.fc9.ppc64 requires /sbin/ldconfig libshout-2.2.2-3.fc9.ppc requires /sbin/ldconfig libshout-2.2.2-3.fc9.ppc64 requires /sbin/ldconfig libsidplay-1.36.57-17.ppc requires /sbin/ldconfig libsidplay-1.36.57-17.ppc64 requires /sbin/ldconfig libsieve-2.2.6-3.fc9.ppc requires /sbin/ldconfig libsieve-2.2.6-3.fc9.ppc64 requires /sbin/ldconfig libsigc++-1.2.7-6.fc9.ppc requires /sbin/ldconfig libsigc++-1.2.7-6.fc9.ppc64 requires /sbin/ldconfig libsigc++20-2.2.2-1.fc9.ppc requires /bin/sh libsigc++20-2.2.2-1.fc9.ppc requires /sbin/ldconfig libsigc++20-2.2.2-1.fc9.ppc64 requires /bin/sh libsigc++20-2.2.2-1.fc9.ppc64 requires /sbin/ldconfig libsigsegv-2.4-6.fc9.ppc requires /sbin/ldconfig libsigsegv-2.4-6.fc9.ppc64 requires /sbin/ldconfig libsilc-1.1.7-1.fc9.ppc requires /sbin/ldconfig libsilc-1.1.7-1.fc9.ppc64 requires /sbin/ldconfig libsmbclient-3.2.0-1.pre3.10.fc10.ppc requires /bin/sh libsmbclient-3.2.0-1.pre3.10.fc10.ppc64 requires /bin/sh libsmi-0.4.8-1.fc10.ppc requires /sbin/ldconfig libsmi-0.4.8-1.fc10.ppc requires /bin/sh libsmi-0.4.8-1.fc10.ppc64 requires /sbin/ldconfig libsmi-0.4.8-1.fc10.ppc64 requires /bin/sh libsndfile-1.0.17-3.fc9.ppc requires /sbin/ldconfig libsndfile-1.0.17-3.fc9.ppc64 requires /sbin/ldconfig libsoup-2.23.1-1.fc10.ppc requires /sbin/ldconfig libsoup-2.23.1-1.fc10.ppc64 requires /sbin/ldconfig libsoup22-2.2.105-2.fc9.ppc requires /sbin/ldconfig libsoup22-2.2.105-2.fc9.ppc64 requires /sbin/ldconfig libspectre-0.2.0-2.fc9.ppc requires /sbin/ldconfig libspectre-0.2.0-2.fc9.ppc64 requires /sbin/ldconfig libspectrum-0.4.0-2.fc9.ppc requires /sbin/ldconfig libspectrum-0.4.0-2.fc9.ppc64 requires /sbin/ldconfig libssh2-0.18-7.fc9.ppc requires /sbin/ldconfig libssh2-0.18-7.fc9.ppc64 requires /sbin/ldconfig libstatgrab-0.16-1.fc9.ppc requires /sbin/ldconfig libstatgrab-0.16-1.fc9.ppc64 requires /sbin/ldconfig libstdc++-4.3.0-8.ppc requires /sbin/ldconfig libstdc++-4.3.0-8.ppc64 requires /sbin/ldconfig libstdc++-devel-4.3.0-8.ppc requires /usr/lib/libstdc++.so.6 libstdc++-devel-4.3.0-8.ppc64 requires /usr/lib64/libstdc++.so.6 libstroke-0.5.1-17.fc9.ppc requires /sbin/ldconfig libstroke-0.5.1-17.fc9.ppc64 requires /sbin/ldconfig libsvm-2.86-13.fc10.ppc requires /sbin/ldconfig libsvm-2.86-13.fc10.ppc64 requires /sbin/ldconfig libsvm-python-2.86-13.fc10.ppc requires /usr/bin/env libsvm-svm-toy-gtk-2.86-13.fc10.ppc requires /bin/sh 1:libswt3-gtk2-3.3.2-11.fc9.ppc requires /usr/bin/rebuild-gcj-db libsx-2.05-15.fc9.ppc requires /sbin/ldconfig libsx-2.05-15.fc9.ppc64 requires /sbin/ldconfig libsynce-0.11-3.fc9.ppc requires /sbin/ldconfig libsynce-0.11-3.fc9.ppc64 requires /sbin/ldconfig libsyncml-0.4.5-2.fc9.ppc requires /sbin/ldconfig libsyncml-0.4.5-2.fc9.ppc64 requires /sbin/ldconfig libsysfs-2.1.0-3.fc9.ppc requires /sbin/ldconfig libsysfs-2.1.0-3.fc9.ppc64 requires /sbin/ldconfig libtalloc-1.2.0-10.fc10.ppc requires /bin/sh libtalloc-1.2.0-10.fc10.ppc64 requires /bin/sh libtar-1.2.11-11.fc10.ppc requires /sbin/ldconfig libtar-1.2.11-11.fc10.ppc64 requires /sbin/ldconfig libtasn1-1.3-1.fc9.ppc requires /sbin/ldconfig libtasn1-1.3-1.fc9.ppc64 requires /sbin/ldconfig libtasn1-devel-1.3-1.fc9.ppc requires /bin/sh libtasn1-devel-1.3-1.fc9.ppc requires /bin/bash libtasn1-devel-1.3-1.fc9.ppc requires /sbin/install-info libtasn1-devel-1.3-1.fc9.ppc64 requires /bin/sh libtasn1-devel-1.3-1.fc9.ppc64 requires /bin/bash libtasn1-devel-1.3-1.fc9.ppc64 requires /sbin/install-info libtcd-2.2.3-1.fc9.2.ppc requires /sbin/ldconfig libtcd-2.2.3-1.fc9.2.ppc64 requires /sbin/ldconfig libtdb-1.1.1-10.fc10.ppc requires /bin/sh libtdb-1.1.1-10.fc10.ppc64 requires /bin/sh libtelepathy-0.3.3-1.fc9.ppc requires /sbin/ldconfig libtelepathy-0.3.3-1.fc9.ppc64 requires /sbin/ldconfig libtextcat-2.2-5.fc9.ppc requires /sbin/ldconfig libtextcat-2.2-5.fc9.ppc64 requires /sbin/ldconfig libthai-0.1.9-4.fc9.ppc requires /sbin/ldconfig libthai-0.1.9-4.fc9.ppc64 requires /sbin/ldconfig libtheora-1.0beta3-2.fc10.ppc requires /sbin/ldconfig libtheora-1.0beta3-2.fc10.ppc64 requires /sbin/ldconfig libtidy-0.99.0-17.20070615.fc9.ppc requires /sbin/ldconfig libtidy-0.99.0-17.20070615.fc9.ppc64 requires /sbin/ldconfig libtiff-3.8.2-10.fc9.ppc requires /sbin/ldconfig libtiff-3.8.2-10.fc9.ppc64 requires /sbin/ldconfig libtimidity-0.1.0-6.fc9.ppc requires /sbin/ldconfig libtimidity-0.1.0-6.fc9.ppc64 requires /sbin/ldconfig libtirpc-0.1.7-18.fc9.ppc requires /sbin/ldconfig libtirpc-0.1.7-18.fc9.ppc64 requires /sbin/ldconfig libtirpc-devel-0.1.7-18.fc9.ppc requires /bin/sh libtirpc-devel-0.1.7-18.fc9.ppc64 requires /bin/sh libtlen-0-0.7.20060309.fc9.ppc requires /sbin/ldconfig libtlen-0-0.7.20060309.fc9.ppc64 requires /sbin/ldconfig libtomcrypt-1.17-9.fc9.ppc requires /sbin/ldconfig libtomcrypt-1.17-9.fc9.ppc64 requires /sbin/ldconfig libtommath-0.41-8.fc9.ppc requires /sbin/ldconfig libtommath-0.41-8.fc9.ppc64 requires /sbin/ldconfig libtomoe-gtk-0.6.0-3.fc9.ppc requires /sbin/ldconfig libtomoe-gtk-0.6.0-3.fc9.ppc64 requires /sbin/ldconfig libtomoe-gtk-devel-0.6.0-3.fc9.ppc requires /sbin/ldconfig libtomoe-gtk-devel-0.6.0-3.fc9.ppc64 requires /sbin/ldconfig libtool-1.5.24-6.fc9.ppc requires /bin/sh libtool-1.5.24-6.fc9.ppc requires /sbin/install-info libtool-1.5.24-6.fc9.ppc requires /bin/sh libtool-ltdl-1.5.24-6.fc9.ppc requires /sbin/ldconfig libtool-ltdl-1.5.24-6.fc9.ppc64 requires /sbin/ldconfig libtorque-2.1.10-5.fc9.ppc requires /sbin/ldconfig libtorque-2.1.10-5.fc9.ppc64 requires /sbin/ldconfig libtorque-devel-2.1.10-5.fc9.ppc requires /bin/sh libtorque-devel-2.1.10-5.fc9.ppc64 requires /bin/sh libtorrent-0.11.8-4.fc9.ppc requires /sbin/ldconfig libtorrent-0.11.8-4.fc9.ppc64 requires /sbin/ldconfig libtranslate-0.99-14.fc9.ppc requires /sbin/ldconfig libtranslate-0.99-14.fc9.ppc64 requires /sbin/ldconfig libtunepimp-0.5.3-11.fc9.ppc requires /sbin/ldconfig libtunepimp-0.5.3-11.fc9.ppc64 requires /sbin/ldconfig libtwin-0.0.2-8.fc10.ppc requires /sbin/ldconfig libtwin-0.0.2-8.fc10.ppc64 requires /sbin/ldconfig libuninameslist-0.0-8.20060907.ppc requires /sbin/ldconfig libuninameslist-0.0-8.20060907.ppc64 requires /sbin/ldconfig libunwind-0.99-0.5.frysk20070405cvs.fc9.ppc64 requires /sbin/ldconfig libupnp-1.6.6-1.fc10.ppc requires /sbin/ldconfig libupnp-1.6.6-1.fc10.ppc64 requires /sbin/ldconfig libusb-0.1.12-15.fc9.ppc requires /sbin/ldconfig libusb-0.1.12-15.fc9.ppc64 requires /sbin/ldconfig libusb-devel-0.1.12-15.fc9.ppc requires /bin/sh libusb-devel-0.1.12-15.fc9.ppc64 requires /bin/sh libuser-0.56.9-1.ppc requires /sbin/ldconfig libuser-0.56.9-1.ppc64 requires /sbin/ldconfig libutempter-1.1.5-2.fc9.ppc requires /bin/sh libutempter-1.1.5-2.fc9.ppc requires /sbin/ldconfig libutempter-1.1.5-2.fc9.ppc64 requires /bin/sh libutempter-1.1.5-2.fc9.ppc64 requires /sbin/ldconfig libvirt-0.4.2-5.fc10.ppc requires /bin/sh libvirt-0.4.2-5.fc10.ppc requires /usr/sbin/lokkit libvirt-0.4.2-5.fc10.ppc requires /bin/sh libvirt-0.4.2-5.fc10.ppc requires /usr/bin/qemu-img libvirt-0.4.2-5.fc10.ppc64 requires /bin/sh libvirt-0.4.2-5.fc10.ppc64 requires /usr/sbin/lokkit libvirt-0.4.2-5.fc10.ppc64 requires /bin/sh libvirt-cim-0.3-4.fc9.ppc requires /bin/sh libvirt-cim-0.3-4.fc9.ppc requires /sbin/ldconfig libvirt-cim-0.3-4.fc9.ppc requires /bin/bash libvirt-cim-0.3-4.fc9.ppc requires /bin/sh libvirt-cim-0.3-4.fc9.ppc64 requires /bin/sh libvirt-cim-0.3-4.fc9.ppc64 requires /sbin/ldconfig libvirt-cim-0.3-4.fc9.ppc64 requires /bin/bash libvirt-cim-0.3-4.fc9.ppc64 requires /bin/sh libvirt-devel-0.4.2-5.fc10.ppc requires /usr/bin/python libvirt-devel-0.4.2-5.fc10.ppc64 requires /usr/bin/python libvirt-python-0.4.2-5.fc10.ppc requires /usr/bin/python libvisual-0.4.0-6.fc9.ppc requires /sbin/ldconfig libvisual-0.4.0-6.fc9.ppc64 requires /sbin/ldconfig libvncserver-0.9.1-3.fc10.ppc requires /sbin/ldconfig libvncserver-0.9.1-3.fc10.ppc64 requires /sbin/ldconfig libvncserver-devel-0.9.1-3.fc10.ppc requires /bin/sh libvncserver-devel-0.9.1-3.fc10.ppc64 requires /bin/sh libvoikko-1.7-0.1.rc2.fc10.ppc requires /sbin/ldconfig libvoikko-1.7-0.1.rc2.fc10.ppc64 requires /sbin/ldconfig libvolume_id-121-1.20080516git.fc10.ppc requires /sbin/ldconfig libvolume_id-121-1.20080516git.fc10.ppc64 requires /sbin/ldconfig 1:libvorbis-1.2.0-4.fc10.ppc requires /sbin/ldconfig 1:libvorbis-1.2.0-4.fc10.ppc64 requires /sbin/ldconfig libvpd-2.0.1-1.fc9.ppc requires /sbin/ldconfig libvpd-2.0.1-1.fc9.ppc64 requires /sbin/ldconfig libvte-java-0.12.1-11.fc9.ppc requires /sbin/ldconfig libvte-java-0.12.1-11.fc9.ppc64 requires /sbin/ldconfig libwcs-3.7.0-2.fc9.ppc requires /sbin/ldconfig libwcs-3.7.0-2.fc9.ppc64 requires /sbin/ldconfig libwiimote-0.4-6.fc9.ppc requires /sbin/ldconfig libwiimote-0.4-6.fc9.ppc64 requires /sbin/ldconfig libwmf-0.2.8.4-18.fc9.ppc requires /usr/bin/update-gdk-pixbuf-loaders libwmf-0.2.8.4-18.fc9.ppc requires /bin/sh libwmf-0.2.8.4-18.fc9.ppc requires /bin/sh libwmf-0.2.8.4-18.fc9.ppc64 requires /bin/sh libwmf-0.2.8.4-18.fc9.ppc64 requires /usr/bin/update-gdk-pixbuf-loaders libwmf-0.2.8.4-18.fc9.ppc64 requires /bin/sh libwmf-devel-0.2.8.4-18.fc9.ppc requires /bin/sh libwmf-devel-0.2.8.4-18.fc9.ppc64 requires /bin/sh libwmf-lite-0.2.8.4-18.fc9.ppc requires /sbin/ldconfig libwmf-lite-0.2.8.4-18.fc9.ppc64 requires /sbin/ldconfig libwnck-2.22.1-1.fc9.ppc requires /sbin/ldconfig libwnck-2.22.1-1.fc9.ppc64 requires /sbin/ldconfig libwpd-0.8.14-1.fc9.ppc requires /sbin/ldconfig libwpd-0.8.14-1.fc9.ppc64 requires /sbin/ldconfig libwvstreams-4.4.1-4.fc9.ppc requires /sbin/ldconfig libwvstreams-4.4.1-4.fc9.ppc64 requires /sbin/ldconfig libxcb-1.1-4.fc9.ppc requires /sbin/ldconfig libxcb-1.1-4.fc9.ppc64 requires /sbin/ldconfig libxfce4mcs-4.4.2-2.fc9.ppc requires /sbin/ldconfig libxfce4mcs-4.4.2-2.fc9.ppc64 requires /sbin/ldconfig libxfce4util-4.4.2-2.fc9.ppc requires /sbin/ldconfig libxfce4util-4.4.2-2.fc9.ppc64 requires /sbin/ldconfig libxfcegui4-4.4.2-2.fc9.ppc requires /bin/sh libxfcegui4-4.4.2-2.fc9.ppc64 requires /bin/sh libxkbfile-1.0.4-5.fc9.ppc requires /sbin/ldconfig libxkbfile-1.0.4-5.fc9.ppc64 requires /sbin/ldconfig libxklavier-3.6-1.fc10.ppc requires /sbin/ldconfig libxklavier-3.6-1.fc10.ppc64 requires /sbin/ldconfig 1:libxml-1.8.17-19.fc9.ppc requires /sbin/ldconfig 1:libxml-1.8.17-19.fc9.ppc64 requires /sbin/ldconfig libxml++-2.22.0-1.fc9.ppc requires /sbin/ldconfig libxml++-2.22.0-1.fc9.ppc64 requires /sbin/ldconfig libxml++-devel-2.22.0-1.fc9.ppc requires /bin/sh libxml++-devel-2.22.0-1.fc9.ppc64 requires /bin/sh 1:libxml-devel-1.8.17-19.fc9.ppc requires /bin/sh 1:libxml-devel-1.8.17-19.fc9.ppc64 requires /bin/sh libxml2-2.6.32-2.fc10.ppc requires /bin/sh libxml2-2.6.32-2.fc10.ppc64 requires /bin/sh libxml2-devel-2.6.32-2.fc10.ppc requires /bin/sh libxml2-devel-2.6.32-2.fc10.ppc requires /usr/bin/python libxml2-devel-2.6.32-2.fc10.ppc64 requires /bin/sh libxml2-devel-2.6.32-2.fc10.ppc64 requires /usr/bin/python libxml2-python-2.6.32-2.fc10.ppc requires /usr/bin/python libxslt-1.1.24-1.fc10.ppc requires /bin/sh libxslt-1.1.24-1.fc10.ppc64 requires /bin/sh libxslt-devel-1.1.24-1.fc10.ppc requires /bin/sh libxslt-devel-1.1.24-1.fc10.ppc64 requires /bin/sh libxslt-python-1.1.24-1.fc10.ppc requires /usr/bin/python libyaz-3.0.26-1.fc10.ppc requires /sbin/ldconfig libyaz-3.0.26-1.fc10.ppc64 requires /sbin/ldconfig libyaz-devel-3.0.26-1.fc10.ppc requires /usr/bin/tclsh libyaz-devel-3.0.26-1.fc10.ppc requires /bin/sh libyaz-devel-3.0.26-1.fc10.ppc64 requires /usr/bin/tclsh libyaz-devel-3.0.26-1.fc10.ppc64 requires /bin/sh libytnef-1.5-3.fc9.ppc requires /sbin/ldconfig libytnef-1.5-3.fc9.ppc64 requires /sbin/ldconfig libzip-0.8-5.fc9.ppc requires /sbin/ldconfig libzip-0.8-5.fc9.ppc64 requires /sbin/ldconfig libzzub-0.2.3-12.fc9.ppc requires /sbin/ldconfig licq-1.3.5-2.fc10.ppc requires /usr/bin/perl licq-1.3.5-2.fc10.ppc requires /bin/sh licq-auto-reply-1.3.5-2.fc10.ppc requires /bin/bash liferea-1.4.13-3.fc9.ppc requires /bin/sh liferea-1.4.13-3.fc9.ppc requires /bin/sh lightning-1.2-13.fc9.ppc requires /bin/sh lightning-1.2-13.fc9.ppc requires /bin/sh lightning-1.2-13.fc9.ppc requires /sbin/install-info lighttpd-1.4.19-4.fc10.ppc requires /bin/sh lighttpd-1.4.19-4.fc10.ppc requires /usr/sbin/useradd lighttpd-1.4.19-4.fc10.ppc requires /sbin/service lighttpd-1.4.19-4.fc10.ppc requires /bin/sh lighttpd-1.4.19-4.fc10.ppc requires /sbin/chkconfig lilypond-2.10.33-1.fc8.ppc requires /sbin/install-info lilypond-2.10.33-1.fc8.ppc requires /usr/bin/python lilypond-2.10.33-1.fc8.ppc requires /usr/bin/guile lilypond-2.10.33-1.fc8.ppc requires /bin/sh lineakd-0.9-5.fc6.ppc requires /bin/sh lineakd-0.9-5.fc6.ppc requires /sbin/ldconfig lineakd-0.9-5.fc6.ppc64 requires /bin/sh lineakd-0.9-5.fc6.ppc64 requires /sbin/ldconfig link-grammar-4.2.5-2.fc9.ppc requires /sbin/ldconfig link-grammar-4.2.5-2.fc9.ppc64 requires /sbin/ldconfig linkage-0.1.4-6.fc9.ppc requires /bin/sh linkage-0.1.4-6.fc9.ppc64 requires /bin/sh linkchecker-4.7-11.fc9.ppc requires /usr/bin/python linphone-2.1.1-1.fc9.ppc requires /sbin/ldconfig linphone-2.1.1-1.fc9.ppc64 requires /sbin/ldconfig linux-atm-2.5.0-5.ppc requires /usr/bin/perl linux-atm-2.5.0-5.ppc requires /bin/sh linux-atm-libs-2.5.0-5.ppc requires /sbin/ldconfig linux-atm-libs-2.5.0-5.ppc64 requires /sbin/ldconfig linux-igd-1.0-5.fc9.ppc requires /bin/sh linux-igd-1.0-5.fc9.ppc requires /bin/bash linux-igd-1.0-5.fc9.ppc requires /sbin/chkconfig linux-igd-1.0-5.fc9.ppc requires /sbin/service linux-libertine-fonts-2.7.9-1.fc9.noarch requires /bin/sh linuxdoc-tools-0.9.21-16.fc9.ppc requires /bin/sh linuxdoc-tools-0.9.21-16.fc9.ppc requires /usr/bin/perl linuxwacom-0.7.9.8-7.fc10.ppc requires /sbin/ldconfig linuxwacom-0.7.9.8-7.fc10.ppc64 requires /sbin/ldconfig liquidwar-5.6.4-4.fc9.ppc requires /bin/sh liquidwar-5.6.4-4.fc9.ppc requires /sbin/install-info liquidwar-server-5.6.4-4.fc9.ppc requires /bin/sh liquidwar-server-5.6.4-4.fc9.ppc requires /sbin/chkconfig liquidwar-server-5.6.4-4.fc9.ppc requires /usr/sbin/useradd liquidwar-server-5.6.4-4.fc9.ppc requires /bin/sh liquidwar-server-5.6.4-4.fc9.ppc requires /sbin/service lirc-0.8.3-1.fc10.ppc requires /bin/sh lirc-0.8.3-1.fc10.ppc requires /sbin/ldconfig lirc-0.8.3-1.fc10.ppc requires /bin/sh lirc-0.8.3-1.fc10.ppc requires /sbin/chkconfig lirc-libs-0.8.3-1.fc10.ppc requires /sbin/ldconfig lirc-libs-0.8.3-1.fc10.ppc64 requires /sbin/ldconfig listen-0.5-18.fc9.ppc requires /usr/bin/puid listen-0.5-18.fc9.ppc requires /usr/bin/env listen-0.5-18.fc9.ppc requires /sbin/ldconfig listen-0.5-18.fc9.ppc requires /bin/sh livecd-tools-017-1.fc9.ppc requires /bin/bash livecd-tools-017-1.fc9.ppc requires /usr/bin/python lklug-fonts-0.2.2-5.fc8.noarch requires /bin/sh lksctp-tools-1.0.7-3.fc9.ppc requires /sbin/ldconfig lksctp-tools-1.0.7-3.fc9.ppc requires /bin/sh lksctp-tools-1.0.7-3.fc9.ppc64 requires /sbin/ldconfig lksctp-tools-1.0.7-3.fc9.ppc64 requires /bin/sh llvm-2.2-3.fc9.ppc requires /sbin/ldconfig llvm-devel-2.2-3.fc9.ppc requires /usr/bin/perl llvm-devel-2.2-3.fc9.ppc64 requires /usr/bin/perl lm_sensors-3.0.1-5.fc9.ppc requires /bin/sh lm_sensors-3.0.1-5.fc9.ppc requires /sbin/ldconfig lm_sensors-3.0.1-5.fc9.ppc requires /bin/bash lm_sensors-3.0.1-5.fc9.ppc requires /bin/sh lm_sensors-3.0.1-5.fc9.ppc requires /usr/bin/perl lm_sensors-3.0.1-5.fc9.ppc64 requires /bin/sh lm_sensors-3.0.1-5.fc9.ppc64 requires /sbin/ldconfig lm_sensors-3.0.1-5.fc9.ppc64 requires /bin/bash lm_sensors-3.0.1-5.fc9.ppc64 requires /bin/sh lm_sensors-3.0.1-5.fc9.ppc64 requires /usr/bin/perl lm_sensors-sensord-3.0.1-5.fc9.ppc requires /bin/sh lm_sensors-sensord-3.0.1-5.fc9.ppc requires /bin/sh lmarbles-1.0.7-9.ppc requires /bin/sh lock-keys-applet-1.0-14.fc9.ppc requires /bin/sh lockdev-1.0.1-12.fc9.1.ppc requires /bin/sh lockdev-1.0.1-12.fc9.1.ppc requires /sbin/ldconfig lockdev-1.0.1-12.fc9.1.ppc64 requires /bin/sh lockdev-1.0.1-12.fc9.1.ppc64 requires /sbin/ldconfig log4j-1.2.14-4jpp.1.fc9.ppc requires /bin/sh log4j-1.2.14-4jpp.1.fc9.ppc requires /bin/sh log4j-javadoc-1.2.14-4jpp.1.fc9.ppc requires /bin/sh log4j-javadoc-1.2.14-4jpp.1.fc9.ppc requires /bin/rm log4j-javadoc-1.2.14-4jpp.1.fc9.ppc requires /bin/ln logrotate-3.7.6-4.fc10.ppc requires /bin/sh logwatch-7.3.6-22.fc10.noarch requires /usr/bin/perl lohit-fonts-bengali-2.2.1-2.fc9.noarch requires /bin/sh lohit-fonts-gujarati-2.2.1-2.fc9.noarch requires /bin/sh lohit-fonts-hindi-2.2.1-2.fc9.noarch requires /bin/sh lohit-fonts-kannada-2.2.1-2.fc9.noarch requires /bin/sh lohit-fonts-malayalam-2.2.1-2.fc9.noarch requires /bin/sh lohit-fonts-oriya-2.2.1-2.fc9.noarch requires /bin/sh lohit-fonts-punjabi-2.2.1-2.fc9.noarch requires /bin/sh lohit-fonts-tamil-2.2.1-2.fc9.noarch requires /bin/sh lohit-fonts-telugu-2.2.1-2.fc9.noarch requires /bin/sh loki-lib-0.1.6-6.fc9.ppc requires /sbin/ldconfig loki-lib-0.1.6-6.fc9.ppc64 requires /sbin/ldconfig londonlaw-0.2.1-3.fc9.noarch requires /bin/sh londonlaw-0.2.1-3.fc9.noarch requires /usr/bin/python loudmouth-1.3.4-1.fc9.ppc requires /sbin/ldconfig loudmouth-1.3.4-1.fc9.ppc64 requires /sbin/ldconfig lpsolve-5.5.0.12-1.fc9.ppc requires /sbin/ldconfig lsvpd-1.6.3-1.fc9.ppc requires /usr/sbin/vpdupdate ltsp-client-5.1.7-2.fc9.ppc requires /bin/bash ltsp-client-5.1.7-2.fc9.ppc requires /bin/sh ltsp-server-5.1.7-2.fc9.ppc requires /bin/sh ltsp-server-5.1.7-2.fc9.ppc requires /usr/bin/perl ltsp-server-5.1.7-2.fc9.ppc requires /bin/bash ltsp-server-5.1.7-2.fc9.ppc requires /bin/sh ltsp-server-5.1.7-2.fc9.ppc requires /usr/bin/python ltsp-utils-0.25-4.fc6.noarch requires /usr/bin/perl ltspfs-0.5.2-1.fc9.ppc requires /usr/bin/python ltspfsd-0.5.2-1.fc9.ppc requires /bin/sh luadoc-3.0.1-1.fc8.noarch requires /usr/bin/env lucene-2.3.1-2jpp.0.fc10.ppc requires /bin/sh lucene-javadoc-2.3.1-2jpp.0.fc10.ppc requires /bin/sh luma-2.4-3.fc9.noarch requires /usr/bin/env lush-1.2.1-2.fc9.ppc requires /bin/sh lvm2-2.02.33-11.fc9.ppc requires /bin/bash lvm2-2.02.33-11.fc9.ppc requires /bin/sh lvm2-cluster-2.02.33-11.fc9.ppc requires /bin/sh lvm2-cluster-2.02.33-11.fc9.ppc requires /bin/bash lvm2-cluster-2.02.33-11.fc9.ppc requires /bin/sh lwp-2.4-1.fc10.ppc requires /sbin/ldconfig lwp-2.4-1.fc10.ppc64 requires /sbin/ldconfig lxappearance-0.2-1.fc10.ppc requires /bin/sh lybniz-1.3.2-1.fc9.noarch requires /bin/sh lybniz-1.3.2-1.fc9.noarch requires /usr/bin/python lynx-2.8.6-13.fc9.ppc requires /bin/sh lyx-1.5.5-1.fc10.ppc requires /bin/sh lyx-1.5.5-1.fc10.ppc requires /usr/bin/env lyx-1.5.5-1.fc10.ppc requires /usr/bin/python lyx-1.5.5-1.fc10.ppc requires /usr/bin/texhash lyx-1.5.5-1.fc10.ppc requires /bin/sh lzma-4.32.5-1.fc9.ppc requires /bin/sh lzma-libs-4.32.5-1.fc9.ppc requires /sbin/ldconfig lzma-libs-4.32.5-1.fc9.ppc64 requires /sbin/ldconfig lzo-2.03-1.fc10.ppc requires /sbin/ldconfig lzo-2.03-1.fc10.ppc64 requires /sbin/ldconfig lzo-minilzo-2.03-1.fc10.ppc requires /sbin/ldconfig lzo-minilzo-2.03-1.fc10.ppc64 requires /sbin/ldconfig m17n-contrib-1.1.6-3.fc9.noarch requires /usr/bin/gawk m17n-db-1.5.1-3.fc9.noarch requires /bin/sh m17n-lib-1.5.1-1.fc9.ppc requires /sbin/ldconfig m17n-lib-1.5.1-1.fc9.ppc64 requires /sbin/ldconfig m2crypto-0.18.2-4.ppc requires /usr/bin/env m4-1.4.11-1.fc10.ppc requires /bin/sh m4-1.4.11-1.fc10.ppc requires /sbin/install-info mISDN-1.1.5-2.fc9.ppc requires /bin/sh mISDN-1.1.5-2.fc9.ppc requires /sbin/ldconfig mISDN-1.1.5-2.fc9.ppc64 requires /bin/sh mISDN-1.1.5-2.fc9.ppc64 requires /sbin/ldconfig macchanger-1.5.0-4.fc9.ppc requires /bin/sh macchanger-1.5.0-4.fc9.ppc requires /sbin/install-info mach-0.9.2-4.fc9.ppc requires /bin/sh mach-0.9.2-4.fc9.ppc requires /usr/bin/python mach-0.9.2-4.fc9.ppc64 requires /bin/sh mach-0.9.2-4.fc9.ppc64 requires /usr/bin/python machineball-1.0-5.fc9.ppc requires /bin/sh madan-fonts-1.0-6.fc8.noarch requires /bin/sh magic-7.5.116-1.fc9.ppc requires /bin/sh magic-7.5.116-1.fc9.ppc requires /usr/bin/tclsh magic-7.5.116-1.fc9.ppc requires /bin/awk magic-7.5.116-1.fc9.ppc requires /usr/bin/wish magic-7.5.116-1.fc9.ppc requires /bin/sh magicmaze-1.0.2-1.fc9.ppc requires /bin/sh magicor-1.1-0.1.rc1.fc9.noarch requires /bin/sh magicor-1.1-0.1.rc1.fc9.noarch requires /usr/bin/python mail-notification-5.3-1.fc9.ppc requires /bin/sh maildrop-2.0.4-6.fc9.ppc requires /bin/sh mailgraph-1.14-2.fc9.noarch requires /bin/sh mailgraph-1.14-2.fc9.noarch requires /bin/bash mailgraph-1.14-2.fc9.noarch requires /usr/bin/perl mailgraph-selinux-1.14-2.fc9.noarch requires /usr/sbin/semodule mailgraph-selinux-1.14-2.fc9.noarch requires /sbin/fixfiles mailgraph-selinux-1.14-2.fc9.noarch requires /bin/sh mailgraph-selinux-1.14-2.fc9.noarch requires /sbin/restorecon 3:mailman-2.1.10-1.fc10.ppc requires /bin/sh 3:mailman-2.1.10-1.fc10.ppc requires /usr/bin/env 3:mailman-2.1.10-1.fc10.ppc requires /usr/bin/python 3:mailman-2.1.10-1.fc10.ppc requires /sbin/service 3:mailman-2.1.10-1.fc10.ppc requires /bin/sh 3:mailman-2.1.10-1.fc10.ppc requires /sbin/chkconfig 1:make-3.81-12.fc9.ppc requires /bin/sh 1:make-3.81-12.fc9.ppc requires /sbin/install-info malaga-7.12-1.fc9.ppc requires /sbin/install-info malaga-7.12-1.fc9.ppc requires /bin/sh man-1.6f-6.fc10.ppc requires /bin/sh man-1.6f-6.fc10.ppc requires /bin/bash man-1.6f-6.fc10.ppc requires /bin/sh manaworld-0.0.24-1.fc9.ppc requires /bin/sh manedit-0.8.1-3.fc9.ppc requires /bin/sh manedit-0.8.1-3.fc9.ppc requires /bin/sh maniadrive-1.2-8.fc9.ppc requires /bin/sh mantis-1.1.1-1.fc9.noarch requires /usr/bin/php mantis-config-httpd-1.1.1-1.fc9.noarch requires /bin/sh mantis-config-httpd-1.1.1-1.fc9.noarch requires /etc/httpd/conf.d mapserver-python-5.0.2-2.fc9.ppc requires /bin/sh maradns-1.3.07.08-1.fc9.ppc requires /bin/sh maradns-1.3.07.08-1.fc9.ppc requires /bin/bash maradns-1.3.07.08-1.fc9.ppc requires /sbin/chkconfig maradns-1.3.07.08-1.fc9.ppc requires /sbin/service mash-0.3.6-1.fc9.noarch requires /usr/bin/python2 mash-0.3.6-1.fc9.noarch requires /usr/bin/python mathml-fonts-1.0-21.fc6.noarch requires /bin/sh mathml-fonts-1.0-21.fc6.noarch requires /bin/bash mathml-fonts-1.0-21.fc6.noarch requires /bin/sh maven-doxia-1.0-0.2.a7.2jpp.6.fc9.ppc requires /bin/sh maven-jxr-1.0-2jpp.5.fc9.ppc requires /bin/sh maven-scm-1.0-0.2.b3.1jpp.3.fc9.ppc requires /bin/sh maven-scm-javadoc-1.0-0.2.b3.1jpp.3.fc9.ppc requires /bin/rm maven-scm-javadoc-1.0-0.2.b3.1jpp.3.fc9.ppc requires /bin/ls maven-scm-test-1.0-0.2.b3.1jpp.3.fc9.ppc requires /bin/sh maven-shared-1.0-4jpp.4.fc9.ppc requires /bin/sh maven-shared-file-management-1.0-4jpp.4.fc9.ppc requires /bin/sh maven-shared-plugin-testing-harness-1.0-4jpp.4.fc9.ppc requires /bin/sh maven-surefire-1.5.3-2jpp.5.fc9.ppc requires /bin/sh maven-surefire-booter-1.5.3-2jpp.5.fc9.ppc requires /bin/sh maven-surefire-booter-javadoc-1.5.3-2jpp.5.fc9.ppc requires /bin/rm maven-surefire-booter-javadoc-1.5.3-2jpp.5.fc9.ppc requires /bin/ln maven-surefire-javadoc-1.5.3-2jpp.5.fc9.ppc requires /bin/rm maven-surefire-javadoc-1.5.3-2jpp.5.fc9.ppc requires /bin/ln maven2-2.0.4-10jpp.10.fc9.ppc requires /bin/sh maven2-2.0.4-10jpp.10.fc9.ppc requires /bin/rmdir maven2-2.0.4-10jpp.10.fc9.ppc requires /bin/sh maven2-plugin-ant-2.0.4-10jpp.10.fc9.ppc requires /bin/sh maven2-plugin-antlr-2.0.4-10jpp.10.fc9.ppc requires /bin/sh maven2-plugin-antrun-2.0.4-10jpp.10.fc9.ppc requires /bin/sh maven2-plugin-assembly-2.0.4-10jpp.10.fc9.ppc requires /bin/sh maven2-plugin-checkstyle-2.0.4-10jpp.10.fc9.ppc requires /bin/sh maven2-plugin-clean-2.0.4-10jpp.10.fc9.ppc requires /bin/sh maven2-plugin-compiler-2.0.4-10jpp.10.fc9.ppc requires /bin/sh maven2-plugin-dependency-2.0.4-10jpp.10.fc9.ppc requires /bin/sh maven2-plugin-deploy-2.0.4-10jpp.10.fc9.ppc requires /bin/sh maven2-plugin-ear-2.0.4-10jpp.10.fc9.ppc requires /bin/sh maven2-plugin-eclipse-2.0.4-10jpp.10.fc9.ppc requires /bin/sh maven2-plugin-ejb-2.0.4-10jpp.10.fc9.ppc requires /bin/sh maven2-plugin-help-2.0.4-10jpp.10.fc9.ppc requires /bin/sh maven2-plugin-idea-2.0.4-10jpp.10.fc9.ppc requires /bin/sh maven2-plugin-install-2.0.4-10jpp.10.fc9.ppc requires /bin/sh maven2-plugin-jar-2.0.4-10jpp.10.fc9.ppc requires /bin/sh maven2-plugin-javadoc-2.0.4-10jpp.10.fc9.ppc requires /bin/sh maven2-plugin-jxr-2.0.4-10jpp.10.fc9.ppc requires /bin/sh maven2-plugin-one-2.0.4-10jpp.10.fc9.ppc requires /bin/sh maven2-plugin-plugin-2.0.4-10jpp.10.fc9.ppc requires /bin/sh maven2-plugin-pmd-2.0.4-10jpp.10.fc9.ppc requires /bin/sh maven2-plugin-project-info-reports-2.0.4-10jpp.10.fc9.ppc requires /bin/sh maven2-plugin-rar-2.0.4-10jpp.10.fc9.ppc requires /bin/sh maven2-plugin-release-2.0.4-10jpp.10.fc9.ppc requires /bin/sh maven2-plugin-repository-2.0.4-10jpp.10.fc9.ppc requires /bin/sh maven2-plugin-resources-2.0.4-10jpp.10.fc9.ppc requires /bin/sh maven2-plugin-site-2.0.4-10jpp.10.fc9.ppc requires /bin/sh maven2-plugin-source-2.0.4-10jpp.10.fc9.ppc requires /bin/sh maven2-plugin-surefire-2.0.4-10jpp.10.fc9.ppc requires /bin/sh maven2-plugin-surefire-report-2.0.4-10jpp.10.fc9.ppc requires /bin/sh maven2-plugin-verifier-2.0.4-10jpp.10.fc9.ppc requires /bin/sh maxima-5.14.0-4.fc9.ppc requires /bin/sh maxima-5.14.0-4.fc9.ppc requires /bin/bash maxima-5.14.0-4.fc9.ppc requires /sbin/install-info maxima-5.14.0-4.fc9.ppc requires /bin/sh maxima-gui-5.14.0-4.fc9.ppc requires /bin/sh maxima-gui-5.14.0-4.fc9.ppc requires /bin/sh mboxgrep-0.7.9-5.fc9.ppc requires /bin/sh mboxgrep-0.7.9-5.fc9.ppc requires /sbin/install-info 1:mc-4.6.2-3.pre1.fc9.ppc requires /usr/bin/perl 1:mc-4.6.2-3.pre1.fc9.ppc requires /bin/sh mcs-libs-0.6.0-4.fc9.ppc requires /sbin/ldconfig mcs-libs-0.6.0-4.fc9.ppc64 requires /sbin/ldconfig mcstrans-0.2.11-1.fc10.ppc requires /bin/sh mcstrans-0.2.11-1.fc10.ppc requires /bin/bash mcstrans-0.2.11-1.fc10.ppc requires /sbin/chkconfig mcstrans-0.2.11-1.fc10.ppc requires /sbin/service mdadm-2.6.4-4.fc9.ppc requires /bin/sh mdadm-2.6.4-4.fc9.ppc requires /bin/bash mdadm-2.6.4-4.fc9.ppc requires /sbin/chkconfig mdadm-2.6.4-4.fc9.ppc requires /sbin/service mdbtools-libs-0.6-0.4.cvs20051109.fc9.ppc requires /sbin/ldconfig mdbtools-libs-0.6-0.4.cvs20051109.fc9.ppc64 requires /sbin/ldconfig mdsplib-0.11-6.fc9.ppc requires /sbin/ldconfig mdsplib-0.11-6.fc9.ppc64 requires /sbin/ldconfig meanwhile-1.0.2-6.fc9.ppc requires /sbin/ldconfig meanwhile-1.0.2-6.fc9.ppc64 requires /sbin/ldconfig mecab-0.97-1.fc9.ppc requires /sbin/ldconfig mecab-0.97-1.fc9.ppc64 requires /sbin/ldconfig mecab-devel-0.97-1.fc9.ppc requires /bin/sh mecab-devel-0.97-1.fc9.ppc64 requires /bin/sh mecab-ipadic-2.7.0.20070801-1.fc8.ppc requires /bin/sh mecab-ipadic-EUCJP-2.7.0.20070801-1.fc8.ppc requires /bin/sh mecab-jumandic-5.1.20070304-1.fc7.1.ppc requires /bin/sh mecab-jumandic-EUCJP-5.1.20070304-1.fc7.1.ppc requires /bin/sh mediatomb-0.11.0-1.fc9.ppc requires /bin/sh mediatomb-0.11.0-1.fc9.ppc requires /sbin/service mediatomb-0.11.0-1.fc9.ppc requires /bin/sh mediatomb-0.11.0-1.fc9.ppc requires /sbin/chkconfig mediawiki-1.10.4-39.fc9.ppc requires /usr/bin/env mediawiki-1.10.4-39.fc9.ppc requires /bin/bash mediawiki-1.10.4-39.fc9.ppc requires /bin/sh mediawiki-1.10.4-39.fc9.ppc requires /usr/bin/perl meld-1.1.5-4.fc9.noarch requires /bin/sh meld-1.1.5-4.fc9.noarch requires /usr/bin/env memcached-1.2.4-4.fc9.ppc requires /bin/sh memcached-1.2.4-4.fc9.ppc requires /sbin/service memcached-1.2.4-4.fc9.ppc requires /usr/bin/perl memcached-1.2.4-4.fc9.ppc requires /bin/sh memcached-1.2.4-4.fc9.ppc requires /sbin/chkconfig memcached-selinux-1.2.4-4.fc9.ppc requires /bin/sh mencal-2.3-1.fc8.noarch requires /usr/bin/perl mercator-0.2.5-4.fc9.ppc requires /sbin/ldconfig mercator-0.2.5-4.fc9.ppc64 requires /sbin/ldconfig mercurial-1.0-4.fc9.ppc requires /usr/bin/env mercurial-1.0-4.fc9.ppc requires /bin/sh mercurial-1.0-4.fc9.ppc requires /usr/bin/python mercurial-hgk-1.0-4.fc9.ppc requires /usr/bin/env mesa-libGL-7.1-0.29.fc9.ppc requires /sbin/ldconfig mesa-libGL-7.1-0.29.fc9.ppc64 requires /sbin/ldconfig mesa-libGLU-7.1-0.29.fc9.ppc requires /sbin/ldconfig mesa-libGLU-7.1-0.29.fc9.ppc64 requires /sbin/ldconfig mesa-libGLw-6.5.1-5.fc9.ppc requires /sbin/ldconfig mesa-libGLw-6.5.1-5.fc9.ppc64 requires /sbin/ldconfig mesa-libOSMesa-7.1-0.29.fc9.ppc requires /sbin/ldconfig mesa-libOSMesa-7.1-0.29.fc9.ppc64 requires /sbin/ldconfig metacafe-dl-2007.10.09-1.fc9.noarch requires /usr/bin/env metacity-2.23.13-1.fc10.ppc requires /bin/sh metacity-2.23.13-1.fc10.ppc requires /sbin/ldconfig metacity-2.23.13-1.fc10.ppc64 requires /bin/sh metacity-2.23.13-1.fc10.ppc64 requires /sbin/ldconfig metakit-2.4.9.7-5.fc9.ppc requires /sbin/ldconfig metamonitor-0.4.5-5.fc9.ppc requires /bin/sh metapixel-1.0.2-3.fc9.ppc requires /usr/bin/perl methane-1.4.7-4.fc9.ppc requires /bin/sh mew-common-6.0.51-1.fc10.ppc requires /bin/sh mew-common-6.0.51-1.fc10.ppc requires /usr/bin/env mew-common-6.0.51-1.fc10.ppc requires /sbin/install-info mew-common-6.0.51-1.fc10.ppc requires /bin/sh mfiler2-mdnd-4.0.9b-1.fc9.ppc requires /usr/bin/env mftrace-1.2.14-4.fc9.ppc requires /usr/bin/python mgetty-1.1.36-1.fc10.ppc requires /bin/sh mgetty-1.1.36-1.fc10.ppc requires /sbin/install-info mgetty-sendfax-1.1.36-1.fc10.ppc requires /bin/sh mgetty-sendfax-1.1.36-1.fc10.ppc requires /usr/sbin/useradd mgetty-sendfax-1.1.36-1.fc10.ppc requires /usr/bin/perl mgetty-sendfax-1.1.36-1.fc10.ppc requires /bin/sh mgopen-fonts-0.20050515-6.fc9.noarch requires /bin/sh mhash-0.9.9-5.ppc requires /sbin/ldconfig mhash-0.9.9-5.ppc64 requires /sbin/ldconfig mhgui-0.2-6.fc9.ppc requires /sbin/ldconfig mhgui-0.2-6.fc9.ppc64 requires /sbin/ldconfig mhonarc-2.6.16-4.fc8.noarch requires /usr/bin/perl miau-0.6.5-2.fc9.ppc requires /bin/sh miau-0.6.5-2.fc9.ppc requires /sbin/install-info migemo-0.40-9.fc7.noarch requires /usr/bin/env migrationtools-47-1.fc9.noarch requires /usr/share/migrationtools/migrate_common.ph migrationtools-47-1.fc9.noarch requires /usr/bin/perl migrationtools-47-1.fc9.noarch requires /bin/sh milter-greylist-4.0-2.fc9.ppc requires /bin/sh milter-greylist-sysv-4.0-2.fc9.ppc requires /sbin/chkconfig milter-greylist-sysv-4.0-2.fc9.ppc requires /bin/sh milter-greylist-sysv-4.0-2.fc9.ppc requires /bin/sh milter-regex-1.7-3.fc9.ppc requires /bin/sh milter-regex-1.7-3.fc9.ppc requires /sbin/chkconfig milter-regex-1.7-3.fc9.ppc requires /bin/sh mimedefang-2.64-1.fc9.ppc requires /bin/sh mimedefang-2.64-1.fc9.ppc requires /sbin/service mimedefang-2.64-1.fc9.ppc requires /bin/bash mimedefang-2.64-1.fc9.ppc requires /bin/sh mimedefang-2.64-1.fc9.ppc requires /usr/bin/perl mimedefang-2.64-1.fc9.ppc requires /sbin/chkconfig mimetex-1.60-4.fc9.ppc requires /var/www/cgi-bin mimetex-1.60-4.fc9.ppc requires /var/www/html mimetic-0.9.3-2.fc8.ppc requires /sbin/ldconfig mimetic-0.9.3-2.fc8.ppc64 requires /sbin/ldconfig minbar-0.2.1-6.fc9.ppc requires /bin/sh minicom-2.3-2.fc9.ppc requires /bin/sh minizip-1.2.3-18.fc9.ppc requires /sbin/ldconfig minizip-1.2.3-18.fc9.ppc64 requires /sbin/ldconfig mirage-0.9.3-1.fc9.ppc requires /bin/sh mirage-0.9.3-1.fc9.ppc requires /usr/bin/python mirrormagic-2.0.2-5.fc9.ppc requires /bin/sh mkdst-0.8-1.fc9.noarch requires /bin/sh mkinitrd-6.0.52-2.fc9.ppc requires /bin/bash mkinitrd-6.0.52-2.fc9.ppc requires /sbin/insmod.static mkinitrd-6.0.52-2.fc9.ppc requires /bin/sh mkinitrd-6.0.52-2.fc9.ppc requires /sbin/losetup mksh-33d-1.fc9.ppc requires /bin/sh mkvtoolnix-gui-2.1.0-2.fc9.ppc requires /bin/sh mlmmj-1.2.15-2.fc9.ppc requires /bin/sh mlocate-0.20-1.ppc requires /bin/sh mlocate-0.20-1.ppc requires /bin/sh mlton-20070826-12.fc9.ppc requires /usr/bin/perl mlton-20070826-12.fc9.ppc requires /usr/bin/env mlton-20070826-12.fc9.ppc requires /bin/sh mm-1.4.2-4.fc9.ppc requires /sbin/ldconfig mm-1.4.2-4.fc9.ppc64 requires /sbin/ldconfig mm-devel-1.4.2-4.fc9.ppc requires /bin/sh mm-devel-1.4.2-4.fc9.ppc64 requires /bin/sh mock-0.9.9-1.fc10.noarch requires /bin/sh mock-0.9.9-1.fc10.noarch requires /usr/bin/python mod_auth_ntlm_winbind-0.0.0-0.8.20070129svn713.fc9.ppc requires /bin/sh mod_fcgid-selinux-2.2-4.fc9.ppc requires /usr/sbin/semodule mod_fcgid-selinux-2.2-4.fc9.ppc requires /bin/sh mod_fcgid-selinux-2.2-4.fc9.ppc requires /sbin/restorecon mod_mono-1.2.6-2.1.fc9.ppc requires /sbin/ldconfig mod_nss-1.0.7-4.fc10.ppc requires /bin/sh mod_nss-1.0.7-4.fc10.ppc requires /bin/bash mod_perl-2.0.4-3.ppc requires /usr/bin/perl mod_revocator-1.0.2-4.fc9.ppc requires /sbin/ldconfig mod_revocator-1.0.2-4.fc9.ppc64 requires /sbin/ldconfig 1:mod_ssl-2.2.8-3.ppc requires /bin/sh 1:mod_ssl-2.2.8-3.ppc requires /bin/cat modello-1.0-0.1.a8.4jpp.3.fc7.noarch requires /bin/sh modello-1.0-0.1.a8.4jpp.3.fc7.noarch requires /bin/sh modello-javadoc-1.0-0.1.a8.4jpp.3.fc7.noarch requires /bin/rm modello-javadoc-1.0-0.1.a8.4jpp.3.fc7.noarch requires /bin/ln module-init-tools-3.4-13.fc9.ppc requires /bin/sh module-init-tools-3.4-13.fc9.ppc requires /bin/bash module-init-tools-3.4-13.fc9.ppc requires /sbin/chkconfig module-init-tools-3.4-13.fc9.ppc requires /bin/sh mogilefsd-2.17-5.fc9.noarch requires /bin/sh mogilefsd-2.17-5.fc9.noarch requires /sbin/service mogilefsd-2.17-5.fc9.noarch requires /sbin/chkconfig mogilefsd-2.17-5.fc9.noarch requires /bin/bash mogilefsd-2.17-5.fc9.noarch requires /usr/bin/perl mogstored-2.17-5.fc9.noarch requires /bin/sh mogstored-2.17-5.fc9.noarch requires /sbin/service mogstored-2.17-5.fc9.noarch requires /usr/bin/perl mogstored-2.17-5.fc9.noarch requires /bin/bash mogstored-2.17-5.fc9.noarch requires /sbin/chkconfig moin-1.6.3-1.fc10.noarch requires /usr/bin/env moin-1.6.3-1.fc10.noarch requires /usr/bin/python moin-latex-0-0.20051126.3.fc6.noarch requires /usr/bin/python mona-examples-1.4r10-1.fc10.ppc requires /bin/sh mona-libs-1.4r10-1.fc10.ppc requires /sbin/ldconfig mona-libs-1.4r10-1.fc10.ppc64 requires /sbin/ldconfig monit-4.10.1-7.fc9.ppc requires /bin/sh monit-4.10.1-7.fc9.ppc requires /sbin/service monit-4.10.1-7.fc9.ppc requires /bin/bash monit-4.10.1-7.fc9.ppc requires /sbin/chkconfig monitor-edid-1.16-4.fc9.ppc requires /usr/bin/perl monitor-edid-1.16-4.fc9.ppc requires /bin/sh monkey-bubble-0.4.0-9.fc9.ppc requires /bin/sh mono-addins-0.3.1-1.fc10.ppc requires /bin/sh mono-basic-1.9-4.fc10.ppc requires /bin/sh mono-core-1.9.1-2.fc10.ppc requires /bin/bash mono-core-1.9.1-2.fc10.ppc requires /bin/sh mono-data-1.9.1-2.fc10.ppc requires /bin/sh mono-devel-1.9.1-2.fc10.ppc requires /sbin/ldconfig mono-devel-1.9.1-2.fc10.ppc requires /bin/sh mono-extras-1.9.1-2.fc10.ppc requires /bin/sh mono-jscript-1.9.1-2.fc10.ppc requires /bin/sh mono-nunit-1.9.1-2.fc10.ppc requires /bin/sh mono-web-1.9.1-2.fc10.ppc requires /bin/sh mono-zeroconf-0.7.5-4.fc9.ppc requires /bin/bash monodoc-1.9-1.fc10.ppc requires /bin/sh monosim-1.3.0.2-1.fc9.ppc requires /bin/sh monotone-0.39-1.fc9.ppc requires /bin/sh monotone-0.39-1.fc9.ppc requires /sbin/install-info monotone-server-0.39-1.fc9.ppc requires /bin/sh monotone-server-0.39-1.fc9.ppc requires /sbin/chkconfig monotone-server-0.39-1.fc9.ppc requires /bin/sh monotone-server-0.39-1.fc9.ppc requires /sbin/service monsterz-0.7.1-3.fc9.ppc requires /bin/sh monsterz-0.7.1-3.fc9.ppc requires /usr/bin/env moodle-1.9-1.fc9.noarch requires /bin/sh moodle-1.9-1.fc9.noarch requires /usr/bin/perl moodle-1.9-1.fc9.noarch requires /bin/bash moodle-1.9-1.fc9.noarch requires /sbin/chkconfig moodle-1.9-1.fc9.noarch requires /usr/bin/php moodle-1.9-1.fc9.noarch requires /bin/sh moodle-1.9-1.fc9.noarch requires /sbin/service moodss-21.5-3.fc9.ppc requires /usr/bin/env moomps-5.8-3.fc9.ppc requires /bin/bash moomps-5.8-3.fc9.ppc requires /bin/sh moomps-5.8-3.fc9.ppc requires /sbin/chkconfig moomps-5.8-3.fc9.ppc requires /usr/bin/tclsh moomps-5.8-3.fc9.ppc requires /sbin/service moreutils-0.28-3.fc9.ppc requires /usr/bin/perl mosml-2.01-11.fc9.ppc requires /bin/sh mousepad-0.2.13-2.fc9.ppc requires /bin/sh mousetweaks-2.23.2-3.fc10.ppc requires /bin/sh mozilla-opensc-signer-0.11.4-4.fc9.ppc requires /usr/lib/mozilla/plugins mozldap-6.0.5-2.fc9.ppc requires /sbin/ldconfig mozldap-6.0.5-2.fc9.ppc64 requires /sbin/ldconfig mpc-0.12.1-2.fc9.ppc requires /bin/sh mpfr-2.3.0-3.fc9.ppc requires /sbin/ldconfig mpfr-2.3.0-3.fc9.ppc64 requires /sbin/ldconfig mpfr-devel-2.3.0-3.fc9.ppc requires /bin/sh mpfr-devel-2.3.0-3.fc9.ppc requires /sbin/install-info mpfr-devel-2.3.0-3.fc9.ppc64 requires /bin/sh mpfr-devel-2.3.0-3.fc9.ppc64 requires /sbin/install-info mrtg-2.16.1-2.fc10.ppc requires /bin/sh mrtg-2.16.1-2.fc10.ppc requires /sbin/service mrtg-2.16.1-2.fc10.ppc requires /usr/bin/perl mrtg-2.16.1-2.fc10.ppc requires /bin/sh msmtp-1.4.13-4.fc9.ppc requires /bin/sh msmtp-1.4.13-4.fc9.ppc requires /sbin/install-info 1:mt-daapd-0.2.4.2-2.fc10.ppc requires /bin/sh 1:mt-daapd-0.2.4.2-2.fc10.ppc requires /sbin/service 1:mt-daapd-0.2.4.2-2.fc10.ppc requires /bin/bash 1:mt-daapd-0.2.4.2-2.fc10.ppc requires /sbin/chkconfig 1:mt-daapd-0.2.4.2-2.fc10.ppc requires /usr/sbin/useradd mtd-utils-1.1.0-2.fc8.ppc requires /usr/bin/perl mtools-3.9.11-4.fc9.ppc requires /bin/sh mtools-3.9.11-4.fc9.ppc requires /bin/sh mtpaint-3.20-3.fc9.ppc requires /bin/sh mtx-1.3.11-3.fc9.ppc requires /bin/sh muParser-1.28-4.fc9.ppc requires /sbin/ldconfig muParser-1.28-4.fc9.ppc64 requires /sbin/ldconfig mugshot-1.1.95-1.fc9.ppc requires /usr/bin/python mugshot-1.1.95-1.fc9.ppc requires /bin/sh mugshot-1.1.95-1.fc9.ppc requires /bin/sh muine-0.8.8-9.fc9.ppc requires /bin/bash muine-0.8.8-9.fc9.ppc requires /bin/sh multican-0.0.5-4.fc9.ppc requires /sbin/ldconfig multican-0.0.5-4.fc9.ppc64 requires /sbin/ldconfig munin-1.2.5-4.fc9.noarch requires /bin/sh munin-1.2.5-4.fc9.noarch requires /usr/bin/perl munin-1.2.5-4.fc9.noarch requires /bin/sh munin-node-1.2.5-4.fc9.noarch requires /bin/sh munin-node-1.2.5-4.fc9.noarch requires /usr/bin/env munin-node-1.2.5-4.fc9.noarch requires /sbin/service munin-node-1.2.5-4.fc9.noarch requires /bin/bash munin-node-1.2.5-4.fc9.noarch requires /bin/sh munin-node-1.2.5-4.fc9.noarch requires /usr/bin/perl munin-node-1.2.5-4.fc9.noarch requires /sbin/chkconfig munipack-0.3.1-3.fc9.ppc requires /bin/sh museek+-0.1.13-3.fc9.ppc requires /usr/bin/env museek+-0.1.13-3.fc9.ppc requires /usr/bin/python musicbox-0.2.3-6.fc9.ppc requires /usr/bin/perl mussh-0.7-2.fc8.noarch requires /bin/bash 5:mutt-1.5.17-4.fc9.ppc requires /usr/bin/perl 1:mx4j-3.0.1-6jpp.4.ppc requires /bin/sh 1:mx4j-3.0.1-6jpp.4.ppc requires /usr/sbin/update-alternatives 1:mx4j-3.0.1-6jpp.4.ppc requires /bin/rm 1:mx4j-javadoc-3.0.1-6jpp.4.ppc requires /bin/sh 1:mx4j-javadoc-3.0.1-6jpp.4.ppc requires /bin/rm 1:mx4j-javadoc-3.0.1-6jpp.4.ppc requires /bin/ln mxml-2.2.2-8.fc9.ppc requires /sbin/ldconfig mxml-2.2.2-8.fc9.ppc64 requires /sbin/ldconfig mybashburn-1.0.2-3.fc8.noarch requires /usr/bin/env mybashburn-1.0.2-3.fc8.noarch requires /bin/sh mypaint-0.5.0-7.fc9.ppc requires /usr/bin/env mysql-5.0.51a-1.fc9.ppc requires /bin/sh mysql-5.0.51a-1.fc9.ppc requires /sbin/install-info mysql-5.0.51a-1.fc9.ppc requires /usr/bin/perl mysql-5.0.51a-1.fc9.ppc requires /bin/sh mysql++-3.0.3-1.fc10.ppc requires /sbin/ldconfig mysql++-3.0.3-1.fc10.ppc64 requires /sbin/ldconfig mysql-administrator-5.0r12-5.fc9.ppc requires /bin/sh mysql-bench-5.0.51a-1.fc9.ppc requires /usr/bin/perl 1:mysql-connector-java-3.1.12-5.fc9.ppc requires /bin/sh mysql-connector-odbc-3.51.24r1071-1.fc9.ppc requires /sbin/ldconfig mysql-libs-5.0.51a-1.fc9.ppc requires /bin/sh mysql-libs-5.0.51a-1.fc9.ppc requires /sbin/ldconfig mysql-libs-5.0.51a-1.fc9.ppc64 requires /bin/sh mysql-libs-5.0.51a-1.fc9.ppc64 requires /sbin/ldconfig mysql-query-browser-5.0r12-5.fc9.ppc requires /bin/sh mysql-server-5.0.51a-1.fc9.ppc requires /bin/sh mysql-server-5.0.51a-1.fc9.ppc requires /usr/sbin/useradd mysql-server-5.0.51a-1.fc9.ppc requires /bin/bash mysql-server-5.0.51a-1.fc9.ppc requires /bin/sh mysql-server-5.0.51a-1.fc9.ppc requires /usr/bin/perl mysql-server-5.0.51a-1.fc9.ppc requires /sbin/chkconfig mysql-test-5.0.51a-1.fc9.ppc requires /usr/bin/perl mysql-test-5.0.51a-1.fc9.ppc requires /bin/sh mytop-1.6-2.fc9.noarch requires /usr/bin/perl nabi-0.18-9.fc9.ppc requires /usr/sbin/alternatives nabi-0.18-9.fc9.ppc requires /bin/sh nafees-web-naskh-fonts-1.0-1.fc8.noarch requires /bin/sh nagios-2.11-3.fc9.ppc requires /bin/sh nagios-2.11-3.fc9.ppc requires /usr/bin/perl nagios-2.11-3.fc9.ppc requires /bin/sh nagios-plugins-1.4.11-4.fc10.ppc requires /bin/sh nagios-plugins-breeze-1.4.11-4.fc10.ppc requires /usr/bin/perl nagios-plugins-by_ssh-1.4.11-4.fc10.ppc requires /usr/bin/ssh nagios-plugins-dig-1.4.11-4.fc10.ppc requires /usr/bin/dig nagios-plugins-disk_smb-1.4.11-4.fc10.ppc requires /usr/bin/smbclient nagios-plugins-disk_smb-1.4.11-4.fc10.ppc requires /usr/bin/perl nagios-plugins-dns-1.4.11-4.fc10.ppc requires /usr/bin/nslookup nagios-plugins-file_age-1.4.11-4.fc10.ppc requires /usr/bin/perl nagios-plugins-flexlm-1.4.11-4.fc10.ppc requires /usr/bin/perl nagios-plugins-fping-1.4.11-4.fc10.ppc requires /usr/sbin/fping nagios-plugins-ifoperstatus-1.4.11-4.fc10.ppc requires /usr/bin/perl nagios-plugins-ifstatus-1.4.11-4.fc10.ppc requires /usr/bin/perl nagios-plugins-ircd-1.4.11-4.fc10.ppc requires /usr/bin/perl nagios-plugins-linux_raid-1.4.11-4.fc10.ppc requires /usr/bin/perl nagios-plugins-log-1.4.11-4.fc10.ppc requires /bin/egrep nagios-plugins-log-1.4.11-4.fc10.ppc requires /bin/mktemp nagios-plugins-log-1.4.11-4.fc10.ppc requires /bin/sh nagios-plugins-mailq-1.4.11-4.fc10.ppc requires /usr/bin/perl nagios-plugins-ntp-1.4.11-4.fc10.ppc requires /usr/sbin/ntpq nagios-plugins-ntp-1.4.11-4.fc10.ppc requires /usr/sbin/ntpdc nagios-plugins-ntp-1.4.11-4.fc10.ppc requires /usr/sbin/ntpdate nagios-plugins-oracle-1.4.11-4.fc10.ppc requires /bin/sh nagios-plugins-ping-1.4.11-4.fc10.ppc requires /bin/ping nagios-plugins-ping-1.4.11-4.fc10.ppc requires /bin/ping6 nagios-plugins-rpc-1.4.11-4.fc10.ppc requires /usr/bin/perl nagios-plugins-rpc-1.4.11-4.fc10.ppc requires /usr/sbin/rpcinfo nagios-plugins-snmp-1.4.11-4.fc10.ppc requires /usr/bin/snmpget nagios-plugins-snmp-1.4.11-4.fc10.ppc requires /usr/bin/snmpgetnext nagios-plugins-wave-1.4.11-4.fc10.ppc requires /usr/bin/perl naim-0.11.8.3.1-6.fc9.ppc requires /bin/sh namazu-2.0.18-1.fc9.ppc requires /usr/bin/perl namazu-devel-2.0.18-1.fc9.ppc requires /bin/sh namazu-devel-2.0.18-1.fc9.ppc64 requires /bin/sh namazu-libs-2.0.18-1.fc9.ppc requires /sbin/ldconfig namazu-libs-2.0.18-1.fc9.ppc64 requires /sbin/ldconfig nano-2.0.6-4.fc9.ppc requires /bin/sh nano-2.0.6-4.fc9.ppc requires /sbin/install-info nas-1.9.1-4.fc9.ppc requires /bin/sh nas-1.9.1-4.fc9.ppc requires /sbin/service nas-1.9.1-4.fc9.ppc requires /bin/bash nas-1.9.1-4.fc9.ppc requires /bin/sh nas-1.9.1-4.fc9.ppc requires /usr/bin/perl nas-libs-1.9.1-4.fc9.ppc requires /sbin/ldconfig nas-libs-1.9.1-4.fc9.ppc64 requires /sbin/ldconfig nash-6.0.52-2.fc9.ppc requires /bin/bash nash-6.0.52-2.fc9.ppc64 requires /bin/bash nasm-2.01-2.fc9.ppc requires /bin/sh nasm-2.01-2.fc9.ppc requires /sbin/install-info naturette-1.3-1.fc8.noarch requires /bin/sh naturette-1.3-1.fc8.noarch requires /bin/bash nautilus-2.23.2-2.fc10.ppc requires /bin/sh nautilus-actions-1.4.1-3.fc9.ppc requires /bin/sh nautilus-cd-burner-2.22.1-1.fc9.ppc requires /bin/sh nautilus-cd-burner-2.22.1-1.fc9.ppc64 requires /bin/sh nautilus-open-terminal-0.9-2.fc9.ppc requires /bin/sh nautilus-python-0.4.3-5.fc9.ppc requires /sbin/ldconfig nautilus-sendto-0.14.0-4.fc10.ppc requires /bin/sh nazghul-haxima-0.6.0-4.20080407cvs.fc9.ppc requires /bin/sh nbd-2.9.10-1.fc9.ppc requires /bin/sh nc-1.84-16.fc9.ppc requires /bin/sh ncl-5.0.0-11.fc9.ppc requires /bin/csh ncl-devel-5.0.0-11.fc9.ppc requires /bin/csh ncl-devel-5.0.0-11.fc9.ppc64 requires /bin/csh ncl-examples-5.0.0-11.fc9.ppc requires /bin/csh nco-3.9.3-1.fc9.ppc requires /bin/sh nco-3.9.3-1.fc9.ppc64 requires /bin/sh ncpfs-2.2.6-10.fc9.ppc requires /sbin/ldconfig ncpfs-2.2.6-10.fc9.ppc64 requires /sbin/ldconfig ncurses-devel-5.6-16.20080301.fc9.ppc requires /bin/sh ncurses-devel-5.6-16.20080301.fc9.ppc64 requires /bin/sh ncurses-libs-5.6-16.20080301.fc9.ppc requires /sbin/ldconfig ncurses-libs-5.6-16.20080301.fc9.ppc64 requires /sbin/ldconfig neXtaw-0.15.1-12.fc9.ppc requires /sbin/ldconfig neXtaw-0.15.1-12.fc9.ppc64 requires /sbin/ldconfig nedit-5.5-18.fc9.ppc requires /bin/sh nekohtml-0.9.5-4jpp.1.fc7.noarch requires /bin/sh nemiver-0.5.2-1.fc9.ppc requires /bin/sh nemiver-0.5.2-1.fc9.ppc64 requires /bin/sh neon-0.28.2-2.ppc requires /sbin/ldconfig neon-0.28.2-2.ppc64 requires /sbin/ldconfig neon-devel-0.28.2-2.ppc requires /bin/sh neon-devel-0.28.2-2.ppc64 requires /bin/sh nessus-core-2.2.10-4.fc9.ppc requires /bin/sh nessus-libraries-2.2.10-3.fc9.ppc requires /sbin/ldconfig nessus-libraries-2.2.10-3.fc9.ppc64 requires /sbin/ldconfig nessus-libraries-devel-2.2.10-3.fc9.ppc requires /bin/sh nessus-libraries-devel-2.2.10-3.fc9.ppc64 requires /bin/sh nessus-server-2.2.10-4.fc9.ppc requires /bin/sh nessus-server-2.2.10-4.fc9.ppc requires /sbin/service nessus-server-2.2.10-4.fc9.ppc requires /bin/sh nessus-server-2.2.10-4.fc9.ppc requires /sbin/chkconfig 1:net-snmp-5.4.1-15.fc10.ppc requires /bin/sh 1:net-snmp-5.4.1-15.fc10.ppc requires /bin/bash 1:net-snmp-5.4.1-15.fc10.ppc requires /bin/sh 1:net-snmp-5.4.1-15.fc10.ppc requires /usr/bin/perl 1:net-snmp-devel-5.4.1-15.fc10.ppc requires /bin/sh 1:net-snmp-devel-5.4.1-15.fc10.ppc64 requires /bin/sh 1:net-snmp-gui-5.4.1-15.fc10.ppc requires /usr/bin/perl 1:net-snmp-libs-5.4.1-15.fc10.ppc requires /sbin/ldconfig 1:net-snmp-libs-5.4.1-15.fc10.ppc64 requires /sbin/ldconfig 1:net-snmp-perl-5.4.1-15.fc10.ppc requires /usr/bin/perl 1:net-snmp-perl-5.4.1-15.fc10.ppc requires /bin/bash 1:net-snmp-utils-5.4.1-15.fc10.ppc requires /usr/bin/perl net-tools-1.60-87.fc9.ppc requires /bin/sh net-tools-1.60-87.fc9.ppc requires /sbin/chkconfig net-tools-1.60-87.fc9.ppc requires /bin/sh net-tools-1.60-87.fc9.ppc requires /sbin/service net6-1.3.5-3.fc9.ppc requires /sbin/ldconfig net6-1.3.5-3.fc9.ppc64 requires /sbin/ldconfig 4:netatalk-2.0.3-19.fc9.ppc requires /bin/sh 4:netatalk-2.0.3-19.fc9.ppc requires /sbin/service 4:netatalk-2.0.3-19.fc9.ppc requires /sbin/ldconfig 4:netatalk-2.0.3-19.fc9.ppc requires /usr/bin/perl 4:netatalk-2.0.3-19.fc9.ppc requires /bin/sh 4:netatalk-2.0.3-19.fc9.ppc requires /sbin/chkconfig 4:netatalk-devel-2.0.3-19.fc9.ppc requires /bin/sh 4:netatalk-devel-2.0.3-19.fc9.ppc64 requires /bin/sh netcdf-4.0.0-0.4.beta2.fc10.ppc requires /bin/sh netcdf-4.0.0-0.4.beta2.fc10.ppc64 requires /bin/sh netcdf-perl-1.2.3-7.fc9.ppc requires /usr/bin/perl netdump-server-0.7.16-22.fc9.ppc requires /sbin/service netdump-server-0.7.16-22.fc9.ppc requires /bin/sh netdump-server-0.7.16-22.fc9.ppc requires /usr/bin/ssh-keygen netdump-server-0.7.16-22.fc9.ppc requires /usr/bin/ssh netdump-server-0.7.16-22.fc9.ppc requires /bin/sh netdump-server-0.7.16-22.fc9.ppc requires /sbin/ifconfig netembryo-0.0.5-2.fc9.ppc requires /sbin/ldconfig netembryo-0.0.5-2.fc9.ppc64 requires /sbin/ldconfig netgen-1.3.7-15.fc9.ppc requires /bin/sh netgen-1.3.7-15.fc9.ppc requires /bin/csh netgen-1.3.7-15.fc9.ppc requires /bin/sh netgo-0.5-10.fc9.ppc requires /bin/sh nethack-3.4.3-17.fc9.ppc requires /bin/sh nethack-3.4.3-17.fc9.ppc requires /bin/sh nethack-vultures-2.1.0-10.fc8.ppc requires /bin/sh nethack-vultures-2.1.0-10.fc8.ppc requires /usr/sbin/groupadd nethack-vultures-2.1.0-10.fc8.ppc requires /bin/sh nethack-vultures-2.1.0-10.fc8.ppc requires /usr/bin/bzip2 netlabel_tools-0.17-7.fc9.ppc requires /bin/sh netmask-2.3.9-3.fc9.ppc requires /bin/sh netmask-2.3.9-3.fc9.ppc requires /sbin/install-info netpanzer-0.8.2-3.fc9.ppc requires /bin/sh netpbm-10.35.43-1.fc10.ppc requires /sbin/ldconfig netpbm-10.35.43-1.fc10.ppc64 requires /sbin/ldconfig netpbm-progs-10.35.43-1.fc10.ppc requires /usr/bin/perl netpbm-progs-10.35.43-1.fc10.ppc requires /bin/sh nettle-1.15-4.fc9.ppc requires /bin/sh nettle-1.15-4.fc9.ppc requires /sbin/ldconfig nettle-1.15-4.fc9.ppc requires /sbin/install-info nettle-1.15-4.fc9.ppc64 requires /bin/sh nettle-1.15-4.fc9.ppc64 requires /sbin/ldconfig nettle-1.15-4.fc9.ppc64 requires /sbin/install-info newscache-1.2-0.6.rc6.fc9.ppc requires /bin/sh newscache-1.2-0.6.rc6.fc9.ppc requires /sbin/service newscache-1.2-0.6.rc6.fc9.ppc requires /bin/bash newscache-1.2-0.6.rc6.fc9.ppc requires /sbin/chkconfig newsx-1.6-8.fc9.ppc requires /bin/sh newt-0.52.9-1.fc9.ppc requires /sbin/ldconfig newt-0.52.9-1.fc9.ppc64 requires /sbin/ldconfig nexcontrol-0.2-1.fc9.noarch requires /usr/bin/perl nexuiz-2.4-1.fc10.ppc requires /bin/sh 1:nfs-utils-1.1.2-5.fc10.ppc requires /sbin/nologin 1:nfs-utils-1.1.2-5.fc10.ppc requires /bin/bash 1:nfs-utils-1.1.2-5.fc10.ppc requires /bin/sh 1:nfs-utils-1.1.2-5.fc10.ppc requires /sbin/chkconfig 1:nfs-utils-1.1.2-5.fc10.ppc requires /bin/sh nfs-utils-lib-1.1.1-3.fc9.ppc requires /sbin/ldconfig nfs-utils-lib-1.1.1-3.fc9.ppc64 requires /sbin/ldconfig nginx-0.6.31-1.fc10.ppc requires /bin/sh nginx-0.6.31-1.fc10.ppc requires /bin/sh ngspice-doc-17-14.fc9.ppc requires /bin/sh ngspice-doc-17-14.fc9.ppc requires /sbin/install-info nikto-1.36-3.fc8.noarch requires /usr/bin/perl nip2-7.14.1-1.fc9.ppc requires /bin/sh nip2-7.14.1-1.fc9.ppc requires /bin/bash nip2-7.14.1-1.fc9.ppc requires libWand.so.10 nip2-7.14.1-1.fc9.ppc requires libMagick.so.10 njam-1.25-9.fc9.ppc requires /bin/sh 2:nmap-frontend-4.62-1.fc10.ppc requires /usr/bin/python nmh-1.3-RC1.1.fc10.ppc requires /bin/sh nntpgrab-core-0.2.90-1.fc10.ppc requires /sbin/ldconfig nntpgrab-core-0.2.90-1.fc10.ppc64 requires /sbin/ldconfig nogravity-2.00-6.fc9.ppc requires /bin/sh nogravity-2.00-6.fc9.ppc requires /bin/bash notecase-1.6.1-4.fc9.ppc requires /bin/sh notification-daemon-0.3.7-9.fc9.ppc requires /bin/sh nqc-3.1.6-2.fc9.ppc requires /bin/sh nqc-3.1.6-2.fc9.ppc requires /usr/sbin/groupadd nrpe-2.7-6.fc9.ppc requires /bin/sh nrpe-2.7-6.fc9.ppc requires /sbin/chkconfig nrpe-2.7-6.fc9.ppc requires /usr/sbin/useradd nrpe-2.7-6.fc9.ppc requires /bin/sh nrpe-2.7-6.fc9.ppc requires /sbin/service nsca-2.7.2-6.fc9.ppc requires /bin/sh nsca-2.7.2-6.fc9.ppc requires /sbin/chkconfig nsca-2.7.2-6.fc9.ppc requires /bin/sh nsca-2.7.2-6.fc9.ppc requires /sbin/service nscd-2.8.90-2.ppc requires /usr/sbin/userdel nscd-2.8.90-2.ppc requires /bin/sh nscd-2.8.90-2.ppc requires /usr/sbin/useradd nscd-2.8.90-2.ppc requires /bin/bash nscd-2.8.90-2.ppc requires /sbin/chkconfig nsd-3.0.7-3.fc9.ppc requires /bin/sh nsd-3.0.7-3.fc9.ppc requires /bin/bash nsd-3.0.7-3.fc9.ppc requires /bin/sh nspluginwrapper-0.9.91.5-27.fc9.ppc requires /bin/sh nspluginwrapper-0.9.91.5-27.fc9.ppc requires /usr/bin/linux32 nspluginwrapper-0.9.91.5-27.fc9.ppc requires /bin/sh nspr-4.7.0.99.2-2.fc9.ppc requires /bin/sh nspr-4.7.0.99.2-2.fc9.ppc64 requires /bin/sh nspr-devel-4.7.0.99.2-2.fc9.ppc requires /bin/sh nspr-devel-4.7.0.99.2-2.fc9.ppc64 requires /bin/sh nss-3.11.99.5-2.fc9.ppc requires /bin/sh nss-3.11.99.5-2.fc9.ppc64 requires /bin/sh nss-devel-3.11.99.5-2.fc9.ppc requires /bin/sh nss-devel-3.11.99.5-2.fc9.ppc64 requires /bin/sh nss-mdns-0.10-4.fc9.ppc requires /bin/sh nss-mdns-0.10-4.fc9.ppc requires /sbin/ldconfig nss-mdns-0.10-4.fc9.ppc64 requires /bin/sh nss-mdns-0.10-4.fc9.ppc64 requires /sbin/ldconfig nss_compat_ossl-0.9.2-4.fc9.ppc requires /sbin/ldconfig nss_compat_ossl-0.9.2-4.fc9.ppc64 requires /sbin/ldconfig nss_db-2.2-40.fc9.ppc requires /sbin/ldconfig nss_db-2.2-40.fc9.ppc64 requires /sbin/ldconfig nss_ldap-259-3.fc9.ppc requires /bin/sh nss_ldap-259-3.fc9.ppc requires /sbin/ldconfig nss_ldap-259-3.fc9.ppc64 requires /bin/sh nss_ldap-259-3.fc9.ppc64 requires /sbin/ldconfig 2:ntfs-3g-1.2506-1.fc10.ppc requires /sbin/ldconfig 2:ntfs-3g-1.2506-1.fc10.ppc64 requires /sbin/ldconfig ntfs-config-1.0-0.6.rc5.fc9.noarch requires /usr/bin/python2.5 ntp-4.2.4p4-6.fc9.ppc requires /bin/sh ntp-4.2.4p4-6.fc9.ppc requires /sbin/service ntp-4.2.4p4-6.fc9.ppc requires /bin/bash ntp-4.2.4p4-6.fc9.ppc requires /usr/bin/perl ntp-4.2.4p4-6.fc9.ppc requires /sbin/chkconfig numactl-2.0.0-1.fc10.ppc requires /sbin/ldconfig numactl-2.0.0-1.fc10.ppc requires /usr/bin/perl numactl-2.0.0-1.fc10.ppc64 requires /sbin/ldconfig numactl-2.0.0-1.fc10.ppc64 requires /usr/bin/perl numlockx-1.0-14.fc9.ppc requires /bin/sh numpy-1.0.3.1-2.fc9.ppc requires /usr/bin/env nut-2.2.2-1.fc10.ppc requires /sbin/service nut-2.2.2-1.fc10.ppc requires /sbin/chkconfig nut-2.2.2-1.fc10.ppc requires /bin/sh nut-cgi-2.2.2-1.fc10.ppc requires /bin/sh nut-client-2.2.2-1.fc10.ppc requires /bin/sh nut-client-2.2.2-1.fc10.ppc requires /bin/bash nut-client-2.2.2-1.fc10.ppc requires /usr/sbin/useradd nut-client-2.2.2-1.fc10.ppc requires /bin/sh nut-client-2.2.2-1.fc10.ppc64 requires /bin/sh nut-client-2.2.2-1.fc10.ppc64 requires /bin/bash nut-client-2.2.2-1.fc10.ppc64 requires /usr/sbin/useradd nut-client-2.2.2-1.fc10.ppc64 requires /bin/sh nvclock-gtk-0.8-0.6.b3a.fc10.ppc requires /bin/sh nx-3.2.0-27.fc9.ppc requires /bin/bash nx-3.2.0-27.fc9.ppc requires /bin/sh nyquist-2.37-2.fc9.ppc requires /bin/sh obby-0.4.4-3.fc9.ppc requires /sbin/ldconfig obby-0.4.4-3.fc9.ppc64 requires /sbin/ldconfig obconf-2.0.3-2.fc10.ppc requires /bin/sh obexftp-0.22-0.9.rc9.fc9.ppc requires /sbin/ldconfig obexftp-0.22-0.9.rc9.fc9.ppc64 requires /sbin/ldconfig obmenu-1.0-6.fc9.noarch requires /usr/bin/python ocaml-3.10.2-2.fc10.ppc requires /bin/sh ocaml-3.10.2-2.fc10.ppc requires /usr/bin/ocamlrun ocaml-camlidl-1.05-5.fc10.ppc requires /usr/bin/ocamlrun ocaml-camlp4-devel-3.10.2-2.fc10.ppc requires /usr/bin/ocamlrun ocaml-camlp4-devel-3.10.2-2.fc10.ppc64 requires /usr/bin/ocamlrun ocaml-camlp5-devel-5.08-3.fc10.ppc requires /bin/sh ocaml-camlp5-devel-5.08-3.fc10.ppc requires /usr/bin/ocamlrun ocaml-camlp5-devel-5.08-3.fc10.ppc64 requires /bin/sh ocaml-camlp5-devel-5.08-3.fc10.ppc64 requires /usr/bin/ocamlrun ocaml-deriving-0.1.1a-3.fc10.ppc requires /usr/bin/ocamlrun ocaml-docs-3.10.2-2.fc10.ppc requires /bin/sh ocaml-docs-3.10.2-2.fc10.ppc requires /sbin/install-info ocaml-findlib-1.2.1-3.fc10.ppc requires /bin/sh ocaml-findlib-devel-1.2.1-3.fc10.ppc requires /usr/bin/ocamlrun ocaml-findlib-devel-1.2.1-3.fc10.ppc64 requires /usr/bin/ocamlrun ocaml-gettext-devel-0.3.0-1.fc10.ppc requires /usr/bin/ocamlrun ocaml-gettext-devel-0.3.0-1.fc10.ppc64 requires /usr/bin/ocamlrun ocaml-gsl-devel-0.6.0-3.fc10.ppc requires /bin/sh ocaml-gsl-devel-0.6.0-3.fc10.ppc requires /sbin/install-info ocaml-gsl-devel-0.6.0-3.fc10.ppc64 requires /bin/sh ocaml-gsl-devel-0.6.0-3.fc10.ppc64 requires /sbin/install-info ocaml-lablgl-1.03-4.fc10.ppc requires /bin/sh ocaml-lablgtk-2.10.1-2.fc10.ppc requires /bin/sh ocaml-lablgtk-2.10.1-2.fc10.ppc requires /usr/bin/ocamlrun ocaml-lablgtk-devel-2.10.1-2.fc10.ppc requires /usr/bin/ocamlrun ocaml-lablgtk-devel-2.10.1-2.fc10.ppc64 requires /usr/bin/ocamlrun ocaml-labltk-3.10.2-2.fc10.ppc requires /bin/sh ocaml-labltk-devel-3.10.2-2.fc10.ppc requires /usr/bin/wish ocaml-labltk-devel-3.10.2-2.fc10.ppc requires /usr/bin/ocamlrun ocaml-labltk-devel-3.10.2-2.fc10.ppc64 requires /usr/bin/wish ocaml-labltk-devel-3.10.2-2.fc10.ppc64 requires /usr/bin/ocamlrun ocaml-ocamldoc-3.10.2-2.fc10.ppc requires /usr/bin/ocamlrun ocaml-perl4caml-0.9.5-5.fc10.ppc requires /usr/lib/perl5/5.10.0/ppc-linux-thread-multi/CORE/libperl.so ocaml-runtime-3.10.2-2.fc10.ppc requires /bin/sh ocfs2-tools-1.3.9-7.20080221git.fc8.ppc requires /sbin/service ocfs2-tools-1.3.9-7.20080221git.fc8.ppc requires /bin/bash ocfs2-tools-1.3.9-7.20080221git.fc8.ppc requires /bin/sh ocfs2console-1.3.9-7.20080221git.fc8.ppc requires /usr/bin/python ochusha-0.5.99.66-0.4.cvs070110.fc9.2.ppc requires /etc/pki/tls/cert.pem ochusha-0.5.99.66-0.4.cvs070110.fc9.2.ppc requires /bin/sh ochusha-0.5.99.66-0.4.cvs070110.fc9.2.ppc64 requires /bin/sh ochusha-0.5.99.66-0.4.cvs070110.fc9.2.ppc64 requires /etc/pki/tls/cert.pem ocrad-0.17-3.fc9.ppc requires /bin/sh ocrad-0.17-3.fc9.ppc requires /sbin/install-info ocsinventory-agent-0.0.9.2-1.fc10.noarch requires /etc/logrotate.d ocsinventory-agent-0.0.9.2-1.fc10.noarch requires /usr/bin/perl ocsinventory-agent-0.0.9.2-1.fc10.noarch requires /etc/cron.hourly ocsinventory-agent-0.0.9.2-1.fc10.noarch requires /bin/bash 6:octave-3.0.1-1.fc10.ppc requires /bin/sh 6:octave-3.0.1-1.fc10.ppc requires /sbin/install-info 6:octave-3.0.1-1.fc10.ppc requires /sbin/ldconfig 6:octave-3.0.1-1.fc10.ppc requires /bin/sh 6:octave-3.0.1-1.fc10.ppc64 requires /bin/sh 6:octave-3.0.1-1.fc10.ppc64 requires /sbin/install-info 6:octave-3.0.1-1.fc10.ppc64 requires /sbin/ldconfig 6:octave-3.0.1-1.fc10.ppc64 requires /bin/sh 6:octave-devel-3.0.1-1.fc10.ppc requires /bin/sh 6:octave-devel-3.0.1-1.fc10.ppc64 requires /bin/sh octave-forge-20080429-6.fc10.ppc requires /bin/sh octave-forge-20080429-6.fc10.ppc requires /bin/sh odccm-0.11-2.fc9.ppc requires /sbin/service odccm-0.11-2.fc9.ppc requires /bin/bash odccm-0.11-2.fc9.ppc requires /sbin/chkconfig odccm-0.11-2.fc9.ppc requires /bin/sh oddjob-0.29-2.fc9.ppc requires /bin/sh oddjob-0.29-2.fc9.ppc requires /bin/bash oddjob-0.29-2.fc9.ppc requires /sbin/chkconfig oddjob-0.29-2.fc9.ppc requires /bin/sh oddjob-0.29-2.fc9.ppc requires /sbin/service oddjob-libs-0.29-2.fc9.ppc requires /sbin/ldconfig oddjob-libs-0.29-2.fc9.ppc64 requires /sbin/ldconfig oddjob-mkhomedir-0.29-2.fc9.ppc requires /bin/sh oddjob-mkhomedir-0.29-2.fc9.ppc64 requires /bin/sh ode-0.9-4.fc9.ppc requires /sbin/ldconfig ode-0.9-4.fc9.ppc64 requires /sbin/ldconfig ode-devel-0.9-4.fc9.ppc requires /bin/sh ode-devel-0.9-4.fc9.ppc64 requires /bin/sh offlineimap-5.99.7-1.fc9.noarch requires /usr/bin/python ogdi-3.2.0-0.8.beta1.fc9.ppc requires /sbin/ldconfig ogdi-3.2.0-0.8.beta1.fc9.ppc64 requires /sbin/ldconfig ogdi-devel-3.2.0-0.8.beta1.fc9.ppc requires /bin/sh ogdi-devel-3.2.0-0.8.beta1.fc9.ppc64 requires /bin/sh oggconvert-0.3.0-14.fc9.noarch requires /usr/bin/python ogre-1.4.8-1.fc10.ppc requires /sbin/ldconfig ogre-1.4.8-1.fc10.ppc64 requires /sbin/ldconfig ogre-samples-1.4.8-1.fc10.ppc requires /bin/bash oidentd-2.0.8-5.fc9.ppc requires /bin/sh oidentd-2.0.8-5.fc9.ppc requires /sbin/chkconfig oidentd-2.0.8-5.fc9.ppc requires /bin/sh oidentd-2.0.8-5.fc9.ppc requires /sbin/service ois-1.0-4.fc9.ppc requires /sbin/ldconfig ois-1.0-4.fc9.ppc64 requires /sbin/ldconfig oki4linux-2.1gst-3.fc9.ppc requires /bin/sh oki4linux-2.1gst-3.fc9.ppc requires /usr/bin/perl oki4linux-2.1gst-3.fc9.ppc requires /sbin/chkconfig oki4linux-2.1gst-3.fc9.ppc requires /bin/sh oniguruma-5.9.1-1.fc9.2.ppc requires /sbin/ldconfig oniguruma-5.9.1-1.fc9.2.ppc64 requires /sbin/ldconfig oniguruma-devel-5.9.1-1.fc9.2.ppc requires /bin/sh oniguruma-devel-5.9.1-1.fc9.2.ppc64 requires /bin/sh online-desktop-0.2.28-1.fc10.ppc requires /usr/bin/env online-desktop-0.2.28-1.fc10.ppc requires /usr/bin/python online-desktop-0.2.28-1.fc10.ppc requires /bin/sh online-desktop-0.2.28-1.fc10.ppc requires /bin/sh online-desktop-flickr-0.2.28-1.fc10.ppc requires /bin/sh online-desktop-gmail-0.2.28-1.fc10.ppc requires /bin/sh online-desktop-google-calendar-0.2.28-1.fc10.ppc requires /bin/sh online-desktop-google-docs-0.2.28-1.fc10.ppc requires /bin/sh online-desktop-google-reader-0.2.28-1.fc10.ppc requires /bin/sh ooo2txt-0.0.6-3.fc9.noarch requires /usr/bin/perl oooqs2-1.0-3.fc6.ppc requires /bin/sh oorexx-devel-3.2.0-4.fc9.ppc requires /bin/sh oorexx-docs-3.2.0-4.fc9.ppc requires /usr/bin/rexx oorexx-libs-3.2.0-4.fc9.ppc requires /sbin/ldconfig opal-2.2.11-4.fc10.ppc requires /sbin/ldconfig opal-2.2.11-4.fc10.ppc64 requires /sbin/ldconfig openais-0.83-2.fc10.ppc requires /bin/sh openais-0.83-2.fc10.ppc requires /usr/sbin/useradd openais-0.83-2.fc10.ppc requires /bin/sh openais-0.83-2.fc10.ppc requires /sbin/chkconfig openais-0.83-2.fc10.ppc64 requires /bin/sh openais-0.83-2.fc10.ppc64 requires /usr/sbin/useradd openais-0.83-2.fc10.ppc64 requires /bin/sh openais-0.83-2.fc10.ppc64 requires /sbin/chkconfig openal-0.0.9-0.15.20060204cvs.fc9.ppc requires /sbin/ldconfig openal-0.0.9-0.15.20060204cvs.fc9.ppc64 requires /sbin/ldconfig openal-devel-0.0.9-0.15.20060204cvs.fc9.ppc requires /bin/sh openal-devel-0.0.9-0.15.20060204cvs.fc9.ppc64 requires /bin/sh openarena-0.7.6-1.fc10.noarch requires /bin/bash openbabel-2.2.0-0.3.b4.fc10.ppc requires /sbin/ldconfig openbabel-2.2.0-0.3.b4.fc10.ppc64 requires /sbin/ldconfig openbox-3.4.7.2-1.fc10.ppc requires /usr/bin/env openbox-3.4.7.2-1.fc10.ppc requires /bin/sh openbox-libs-3.4.7.2-1.fc10.ppc requires /sbin/ldconfig openbox-libs-3.4.7.2-1.fc10.ppc64 requires /sbin/ldconfig opencdk-0.6.6-1.fc9.ppc requires /sbin/ldconfig opencdk-0.6.6-1.fc9.ppc64 requires /sbin/ldconfig opencdk-devel-0.6.6-1.fc9.ppc requires /bin/sh opencdk-devel-0.6.6-1.fc9.ppc64 requires /bin/sh openct-0.6.14-4.fc9.ppc requires /bin/sh openct-0.6.14-4.fc9.ppc requires /sbin/ldconfig openct-0.6.14-4.fc9.ppc requires /usr/lib/ctapi openct-0.6.14-4.fc9.ppc requires /bin/sh openct-0.6.14-4.fc9.ppc requires /sbin/chkconfig openct-0.6.14-4.fc9.ppc64 requires /bin/sh openct-0.6.14-4.fc9.ppc64 requires /sbin/ldconfig openct-0.6.14-4.fc9.ppc64 requires /usr/lib64/ctapi openct-0.6.14-4.fc9.ppc64 requires /sbin/chkconfig openct-0.6.14-4.fc9.ppc64 requires /bin/sh opencv-1.0.0-8.fc10.ppc requires /sbin/ldconfig opencv-1.0.0-8.fc10.ppc64 requires /sbin/ldconfig opencv-python-1.0.0-8.fc10.ppc requires /usr/bin/env opencv-python-1.0.0-8.fc10.ppc requires /usr/bin/python opencv-python-1.0.0-8.fc10.ppc requires /sbin/ldconfig opengl-games-utils-0.1-5.fc9.noarch requires /bin/bash opengrok-0.6-9.hg275.fc9.noarch requires /bin/sh openhpi-2.10.2-1.fc9.ppc requires /sbin/service openhpi-2.10.2-1.fc9.ppc requires /bin/bash openhpi-2.10.2-1.fc9.ppc requires /bin/sh openhpi-2.10.2-1.fc9.ppc requires /sbin/chkconfig openhpi-2.10.2-1.fc9.ppc requires /bin/sh openhpi-libs-2.10.2-1.fc9.ppc requires /sbin/ldconfig openhpi-libs-2.10.2-1.fc9.ppc64 requires /sbin/ldconfig openhpi-subagent-2.3.4-2.fc10.ppc requires /sbin/service openhpi-subagent-2.3.4-2.fc10.ppc requires /bin/sh openhpi-subagent-2.3.4-2.fc10.ppc requires /sbin/chkconfig openhpi-subagent-2.3.4-2.fc10.ppc requires /bin/sh openjade-1.3.2-31.fc9.ppc requires /bin/sh openjade-1.3.2-31.fc9.ppc requires /sbin/ldconfig openjade-1.3.2-31.fc9.ppc64 requires /bin/sh openjade-1.3.2-31.fc9.ppc64 requires /sbin/ldconfig openjpeg-libs-1.3-2.fc9.ppc requires /sbin/ldconfig openjpeg-libs-1.3-2.fc9.ppc64 requires /sbin/ldconfig openldap-2.4.9-4.fc10.ppc requires /sbin/ldconfig openldap-2.4.9-4.fc10.ppc64 requires /sbin/ldconfig openldap-devel-2.4.9-4.fc10.ppc requires /sbin/ldconfig openldap-devel-2.4.9-4.fc10.ppc64 requires /sbin/ldconfig openldap-servers-2.4.9-4.fc10.ppc requires /sbin/runuser openldap-servers-2.4.9-4.fc10.ppc requires /bin/sh openldap-servers-2.4.9-4.fc10.ppc requires /usr/sbin/useradd openldap-servers-2.4.9-4.fc10.ppc requires /sbin/chkconfig openldap-servers-2.4.9-4.fc10.ppc requires /bin/bash openlierox-0.57-0.9.beta5.fc9.ppc requires /bin/sh openlierox-0.57-0.9.beta5.fc9.ppc requires /bin/bash openmpi-1.2.4-2.fc9.ppc requires /bin/sh openmpi-1.2.4-2.fc9.ppc requires /sbin/ldconfig openmpi-1.2.4-2.fc9.ppc requires /usr/sbin/alternatives openmpi-devel-1.2.4-2.fc9.ppc requires /bin/sh openmpi-devel-1.2.4-2.fc9.ppc requires /sbin/ldconfig openmpi-devel-1.2.4-2.fc9.ppc requires /usr/sbin/alternatives openmpi-devel-1.2.4-2.fc9.ppc64 requires /bin/sh openmpi-devel-1.2.4-2.fc9.ppc64 requires /sbin/ldconfig openmpi-devel-1.2.4-2.fc9.ppc64 requires /usr/sbin/alternatives openmpi-libs-1.2.4-2.fc9.ppc requires /bin/sh openmpi-libs-1.2.4-2.fc9.ppc requires /sbin/ldconfig openmpi-libs-1.2.4-2.fc9.ppc requires /usr/sbin/alternatives openmpi-libs-1.2.4-2.fc9.ppc64 requires /bin/sh openmpi-libs-1.2.4-2.fc9.ppc64 requires /sbin/ldconfig openmpi-libs-1.2.4-2.fc9.ppc64 requires /usr/sbin/alternatives openmsx-0.6.3-3.fc9.ppc requires /bin/sh openmsx-0.6.3-3.fc9.ppc requires /usr/bin/env openobex-1.3-11.fc9.ppc requires /sbin/ldconfig openobex-1.3-11.fc9.ppc64 requires /sbin/ldconfig 1:openoffice.org-base-3.0.0-0.0.12.1.fc10.ppc requires /bin/sh 1:openoffice.org-base-3.0.0-0.0.12.1.fc10.ppc requires /bin/sh 1:openoffice.org-brand-3.0.0-0.0.12.1.fc10.ppc requires /bin/sh 1:openoffice.org-brand-3.0.0-0.0.12.1.fc10.ppc requires /bin/sh 1:openoffice.org-calc-3.0.0-0.0.12.1.fc10.ppc requires /bin/sh 1:openoffice.org-calc-3.0.0-0.0.12.1.fc10.ppc requires /bin/sh 1:openoffice.org-core-3.0.0-0.0.12.1.fc10.ppc requires /bin/sh 1:openoffice.org-core-3.0.0-0.0.12.1.fc10.ppc requires /bin/sh 1:openoffice.org-devel-3.0.0-0.0.12.1.fc10.ppc requires /usr/bin/perl 1:openoffice.org-devel-3.0.0-0.0.12.1.fc10.ppc requires /usr/bin/python 1:openoffice.org-devel-3.0.0-0.0.12.1.fc10.ppc requires /bin/bash 1:openoffice.org-devel-3.0.0-0.0.12.1.fc10.ppc requires /bin/sh 1:openoffice.org-devel-3.0.0-0.0.12.1.fc10.ppc64 requires /usr/bin/perl 1:openoffice.org-devel-3.0.0-0.0.12.1.fc10.ppc64 requires /usr/bin/python 1:openoffice.org-devel-3.0.0-0.0.12.1.fc10.ppc64 requires /bin/bash 1:openoffice.org-devel-3.0.0-0.0.12.1.fc10.ppc64 requires /bin/sh 1:openoffice.org-draw-3.0.0-0.0.12.1.fc10.ppc requires /bin/sh 1:openoffice.org-draw-3.0.0-0.0.12.1.fc10.ppc requires /bin/sh openoffice.org-extendedPDF-1.4-4.fc9.noarch requires /bin/sh 1:openoffice.org-impress-3.0.0-0.0.12.1.fc10.ppc requires /bin/sh 1:openoffice.org-impress-3.0.0-0.0.12.1.fc10.ppc requires /bin/sh 1:openoffice.org-math-3.0.0-0.0.12.1.fc10.ppc requires /bin/sh 1:openoffice.org-math-3.0.0-0.0.12.1.fc10.ppc requires /bin/sh openoffice.org-ooolatex-4.0.0-0.5.beta2.fc9.noarch requires /bin/sh openoffice.org-ooolatex-4.0.0-0.5.beta2.fc9.noarch requires /usr/bin/dvips openoffice.org-ooolatex-4.0.0-0.5.beta2.fc9.noarch requires /usr/bin/latex 1:openoffice.org-presentation-minimizer-3.0.0-0.0.12.1.fc10.ppc requires /bin/sh 1:openoffice.org-presentation-minimizer-3.0.0-0.0.12.1.fc10.ppc requires openoffice.org-base-impress = 1:3.0.0-0.0.12.1.fc10 1:openoffice.org-presenter-screen-3.0.0-0.0.12.1.fc10.ppc requires /bin/sh 1:openoffice.org-presenter-screen-3.0.0-0.0.12.1.fc10.ppc requires openoffice.org-base-impress = 1:3.0.0-0.0.12.1.fc10 1:openoffice.org-report-builder-3.0.0-0.0.12.1.fc10.ppc requires /bin/sh 1:openoffice.org-sdk-3.0.0-0.0.12.1.fc10.ppc requires /bin/csh 1:openoffice.org-sdk-3.0.0-0.0.12.1.fc10.ppc requires /bin/sh 1:openoffice.org-ure-3.0.0-0.0.12.1.fc10.ppc requires /bin/sh openoffice.org-voikko-2.2-4.fc9.ppc requires /bin/sh 1:openoffice.org-writer-3.0.0-0.0.12.1.fc10.ppc requires /bin/sh 1:openoffice.org-writer-3.0.0-0.0.12.1.fc10.ppc requires /bin/sh openoffice.org-writer2latex-0.5-2.fc9.ppc requires /bin/sh opensc-0.11.4-4.fc9.ppc requires /sbin/ldconfig opensc-0.11.4-4.fc9.ppc64 requires /sbin/ldconfig opensc-devel-0.11.4-4.fc9.ppc requires /bin/sh opensc-devel-0.11.4-4.fc9.ppc64 requires /bin/sh openser-1.3.2-2.fc10.ppc requires /bin/sh openser-1.3.2-2.fc10.ppc requires /bin/bash openslp-1.2.1-9.fc9.ppc requires /sbin/ldconfig openslp-1.2.1-9.fc9.ppc64 requires /sbin/ldconfig openslp-server-1.2.1-9.fc9.ppc requires /bin/sh openslp-server-1.2.1-9.fc9.ppc requires /bin/bash openslp-server-1.2.1-9.fc9.ppc requires /sbin/service opensp-1.5.2-7.fc9.ppc requires /sbin/ldconfig opensp-1.5.2-7.fc9.ppc64 requires /sbin/ldconfig openssh-5.0p1-1.fc9.ppc requires /sbin/nologin openssh-clients-5.0p1-1.fc9.ppc requires /bin/sh openssh-server-5.0p1-1.fc9.ppc requires /bin/sh openssh-server-5.0p1-1.fc9.ppc requires /etc/pam.d/system-auth openssh-server-5.0p1-1.fc9.ppc requires /usr/sbin/useradd openssh-server-5.0p1-1.fc9.ppc requires /sbin/service openssh-server-5.0p1-1.fc9.ppc requires /bin/bash openssh-server-5.0p1-1.fc9.ppc requires /lib/security/pam_loginuid.so openssh-server-5.0p1-1.fc9.ppc requires /bin/sh openssl-0.9.8g-6.fc9.ppc requires /sbin/ldconfig openssl-0.9.8g-6.fc9.ppc requires /bin/sh openssl-0.9.8g-6.fc9.ppc64 requires /bin/sh openssl-0.9.8g-6.fc9.ppc64 requires /sbin/ldconfig openssl-perl-0.9.8g-6.fc9.ppc requires /usr/bin/perl openswan-2.6.09-2.fc9.ppc requires /bin/sh openswan-2.6.09-2.fc9.ppc requires /sbin/service openswan-2.6.09-2.fc9.ppc requires /usr/bin/perl openswan-2.6.09-2.fc9.ppc requires /bin/sh openswan-2.6.09-2.fc9.ppc requires /sbin/chkconfig openvpn-2.1-0.25.rc7.fc9.ppc requires /bin/sh openvpn-2.1-0.25.rc7.fc9.ppc requires /usr/sbin/useradd openvpn-2.1-0.25.rc7.fc9.ppc requires /sbin/service openvpn-2.1-0.25.rc7.fc9.ppc requires /bin/bash openvpn-2.1-0.25.rc7.fc9.ppc requires /bin/sh openvpn-2.1-0.25.rc7.fc9.ppc requires /sbin/chkconfig openvrml-0.17.5-5.fc9.ppc requires /sbin/ldconfig openvrml-0.17.5-5.fc9.ppc64 requires /sbin/ldconfig openvrml-gl-0.17.5-5.fc9.ppc requires /sbin/ldconfig openvrml-gl-0.17.5-5.fc9.ppc64 requires /sbin/ldconfig openvrml-xembed-0.17.5-5.fc9.ppc requires /sbin/install-info openvrml-xembed-0.17.5-5.fc9.ppc requires /bin/sh oprofile-0.9.3-17.fc9.ppc requires /bin/sh opyum-0.0.3-1.fc9.noarch requires /bin/sh opyum-0.0.3-1.fc9.noarch requires /usr/bin/python orage-4.4.2-3.fc9.ppc requires /bin/sh orange-0.3-7.cvs20051118.fc9.ppc requires /sbin/ldconfig orange-0.3-7.cvs20051118.fc9.ppc64 requires /sbin/ldconfig orca-2.23.2-1.fc10.ppc requires /bin/sh orca-2.23.2-1.fc10.ppc requires /bin/bash ortp-0.14.2-0.20080211.2.fc9.ppc requires /sbin/ldconfig ortp-0.14.2-0.20080211.2.fc9.ppc64 requires /sbin/ldconfig 1:osgal-0.6.1-4.fc10.ppc requires /sbin/ldconfig 1:osgal-0.6.1-4.fc10.ppc64 requires /sbin/ldconfig osgcal-0.1.46-6.fc10.ppc requires /sbin/ldconfig osgcal-0.1.46-6.fc10.ppc64 requires /sbin/ldconfig ots-libs-0.5.0-1.fc9.ppc requires /sbin/ldconfig ots-libs-0.5.0-1.fc9.ppc64 requires /sbin/ldconfig overgod-1.0-7.fc9.ppc requires /bin/sh oxine-0.7.1-1.fc10.ppc requires /bin/sh oxygen-icon-theme-4.0.72-2.fc10.noarch requires /bin/sh oxygen-icon-theme-scalable-4.0.72-2.fc10.noarch requires /bin/sh oyranos-devel-0.1.7-11.fc9.ppc requires /bin/sh oyranos-devel-0.1.7-11.fc9.ppc64 requires /bin/sh oyranos-libs-0.1.7-11.fc9.ppc requires /sbin/ldconfig oyranos-libs-0.1.7-11.fc9.ppc64 requires /sbin/ldconfig p0f-2.0.8-4.fc9.ppc requires /bin/sh p0rn-comfort-0.0.4-5.fc9.noarch requires /bin/sh p0rn-comfort-0.0.4-5.fc9.noarch requires /usr/bin/perl p0rn-comfort-0.0.4-5.fc9.noarch requires /bin/bash p7zip-4.51-4.fc9.ppc requires /bin/sh p7zip-plugins-4.51-4.fc9.ppc requires /bin/sh pAgenda-3.2-2.fc10.noarch requires /bin/sh pAgenda-3.2-2.fc10.noarch requires /usr/bin/env pachi-1.0-5.fc9.ppc requires /bin/sh pakchois-0.4-1.ppc requires /sbin/ldconfig pakchois-0.4-1.ppc64 requires /sbin/ldconfig paktype-fonts-2.0-2.fc8.noarch requires /bin/sh pam-1.0.1-2.fc10.ppc requires /bin/sh pam-1.0.1-2.fc10.ppc requires /sbin/ldconfig pam-1.0.1-2.fc10.ppc requires /bin/sh pam-1.0.1-2.fc10.ppc64 requires /bin/sh pam-1.0.1-2.fc10.ppc64 requires /sbin/ldconfig pam-1.0.1-2.fc10.ppc64 requires /bin/sh pam_mount-0.32-3.fc9.ppc requires /bin/sh pam_mount-0.32-3.fc9.ppc requires /bin/bash pam_mount-0.32-3.fc9.ppc requires /bin/sh pam_mount-0.32-3.fc9.ppc requires /usr/bin/perl pam_mount-0.32-3.fc9.ppc64 requires /bin/sh pam_mount-0.32-3.fc9.ppc64 requires /bin/bash pam_mount-0.32-3.fc9.ppc64 requires /bin/sh pam_mount-0.32-3.fc9.ppc64 requires /usr/bin/perl pango-1.21.1-1.fc10.ppc requires /bin/sh pango-1.21.1-1.fc10.ppc64 requires /bin/sh papyrus-0.7.1-3.fc9.ppc requires /sbin/ldconfig papyrus-0.7.1-3.fc9.ppc64 requires /sbin/ldconfig paraview-3.2.1-6.fc9.ppc requires /usr/bin/update-desktop-database paraview-3.2.1-6.fc9.ppc requires /bin/sh paraview-3.2.1-6.fc9.ppc64 requires /usr/bin/update-desktop-database paraview-3.2.1-6.fc9.ppc64 requires /bin/sh paraview-data-3.2.1-6.fc9.ppc requires /bin/sh paraview-data-3.2.1-6.fc9.ppc requires /usr/bin/update-mime-database paraview-mpi-3.2.1-6.fc9.ppc requires /usr/bin/update-desktop-database paraview-mpi-3.2.1-6.fc9.ppc requires /bin/sh paraview-mpi-3.2.1-6.fc9.ppc64 requires /usr/bin/update-desktop-database paraview-mpi-3.2.1-6.fc9.ppc64 requires /bin/sh pards-0.4-6.fc9.ppc requires /sbin/ldconfig pards-0.4-6.fc9.ppc64 requires /sbin/ldconfig pari-2.3.3-1.fc9.ppc requires /sbin/ldconfig pari-2.3.3-1.fc9.ppc64 requires /sbin/ldconfig pari-gp-2.3.3-1.fc9.ppc requires /usr/bin/perl pari-gp-2.3.3-1.fc9.ppc requires /bin/sh parted-1.8.8-5.fc9.ppc requires /bin/sh parted-1.8.8-5.fc9.ppc requires /sbin/install-info parted-1.8.8-5.fc9.ppc requires /sbin/ldconfig parted-1.8.8-5.fc9.ppc64 requires /bin/sh parted-1.8.8-5.fc9.ppc64 requires /sbin/install-info parted-1.8.8-5.fc9.ppc64 requires /sbin/ldconfig passivetex-1.25-8.fc9.noarch requires /bin/sh passivetex-1.25-8.fc9.noarch requires /bin/sh passwd-0.75-2.fc9.ppc requires /etc/pam.d/system-auth patchutils-0.2.31-5.fc9.ppc requires /usr/bin/perl patchutils-0.2.31-5.fc9.ppc requires /bin/bash patchutils-0.2.31-5.fc9.ppc requires /bin/sh patchy-2006-29.fc9.ppc requires /bin/sh patchy-g77-2006-29.fc9.ppc requires /bin/sh patchy-gfortran-2006-29.fc9.ppc requires /bin/sh paw-2006-29.fc9.ppc requires /bin/sh paw-2006-29.fc9.ppc requires /bin/sh paw-g77-2006-29.fc9.ppc requires /bin/sh paw-g77-2006-29.fc9.ppc requires /bin/sh paw-gfortran-2006-29.fc9.ppc requires /bin/sh paw-gfortran-2006-29.fc9.ppc requires /bin/sh pbstop-4.16-3.fc9.ppc requires /usr/bin/perl pcapdiff-0.1-3.fc9.noarch requires /usr/bin/env pcb-0.20080202-2.fc9.ppc requires /usr/bin/tclsh pcb-0.20080202-2.fc9.ppc requires /sbin/install-info pcb-0.20080202-2.fc9.ppc requires /usr/bin/wish pcb-0.20080202-2.fc9.ppc requires /usr/bin/perl pcb-0.20080202-2.fc9.ppc requires /bin/sh pcb-0.20080202-2.fc9.ppc requires /bin/sh pciutils-2.2.10-1.fc9.ppc requires /bin/sh pcmanfm-0.4.1.1-1.fc10.ppc requires /bin/sh pcmanx-gtk2-0.3.5-9.336svn.fc7.ppc requires /sbin/ldconfig pcmanx-gtk2-0.3.5-9.336svn.fc7.ppc64 requires /sbin/ldconfig pcre-7.3-3.fc9.ppc requires /sbin/ldconfig pcre-7.3-3.fc9.ppc64 requires /sbin/ldconfig pcre-devel-7.3-3.fc9.ppc requires /bin/sh pcre-devel-7.3-3.fc9.ppc64 requires /bin/sh pcsc-lite-1.4.4-3.fc9.ppc requires /bin/sh pcsc-lite-1.4.4-3.fc9.ppc requires /bin/sh pcsc-lite-1.4.4-3.fc9.ppc requires /sbin/chkconfig pcsc-lite-libs-1.4.4-3.fc9.ppc requires /sbin/ldconfig pcsc-lite-libs-1.4.4-3.fc9.ppc64 requires /sbin/ldconfig pcsc-lite-openct-0.6.14-4.fc9.ppc requires /bin/sh pcsc-tools-1.4.12-1.fc9.ppc requires /usr/bin/env pdfedit-0.3.2-4.fc9.ppc requires /bin/sh pdfjam-1.20-5.fc6.noarch requires /bin/sh pdns-2.9.21-4.fc9.ppc requires /bin/sh pdns-2.9.21-4.fc9.ppc requires /usr/sbin/useradd pdns-2.9.21-4.fc9.ppc requires /sbin/service pdns-2.9.21-4.fc9.ppc requires /bin/sh pdns-2.9.21-4.fc9.ppc requires /sbin/chkconfig pdns-recursor-3.1.6-1.fc10.ppc requires /bin/sh pdns-recursor-3.1.6-1.fc10.ppc requires /sbin/service pdns-recursor-3.1.6-1.fc10.ppc requires /bin/bash pdns-recursor-3.1.6-1.fc10.ppc requires /sbin/chkconfig pdsh-2.11-6.fc9.ppc requires /usr/bin/perl pekwm-0.1.5-5.fc7.ppc requires /usr/bin/env pengupop-2.2.2-3.fc9.ppc requires /bin/sh 4:perl-5.10.0-20.fc9.ppc requires /usr/bin/perl 4:perl-5.10.0-20.fc9.ppc64 requires /usr/bin/perl perl-Ace-1.91-4.fc9.noarch requires /usr/bin/perl perl-Archive-Tar-1.37-20.fc9.ppc requires /usr/bin/perl perl-Archive-Zip-1.23-1.fc10.noarch requires /usr/bin/perl perl-BerkeleyDB-0.34-1.fc10.ppc requires /usr/bin/perl perl-CPAN-1.9205-20.fc9.ppc requires /usr/bin/perl perl-CPANPLUS-0.84-20.fc9.ppc requires /usr/bin/perl perl-Calendar-Simple-1.19-1.fc9.noarch requires /usr/bin/perl perl-Catalyst-Devel-1.03-2.fc9.noarch requires /usr/bin/perl perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Cflow-1.053-9.fc9.ppc requires /usr/bin/perl perl-Convert-Binary-C-0.70-5.fc9.ppc requires /usr/bin/perl perl-Crypt-Primes-0.50-5.fc9.noarch requires /usr/bin/perl perl-Crypt-Random-1.25-5.fc9.noarch requires /usr/bin/perl perl-Curses-1.20-3.fc9.ppc requires /usr/bin/perl perl-DBD-XBase-0.241-7.fc9.noarch requires /usr/bin/perl perl-DBI-1.601-4.fc9.ppc requires /usr/bin/perl perl-DBI-Dumper-2.01-6.fc9.ppc requires /usr/bin/perl perl-Data-HexDump-0.02-4.fc9.noarch requires /usr/bin/perl perl-Data-Stag-0.10-4.fc9.noarch requires /usr/bin/perl perl-Devel-Cover-0.63-3.fc9.ppc requires /usr/bin/perl perl-Device-SerialPort-1.04-3.fc9.ppc requires /usr/bin/perl 1:perl-Digest-SHA-5.45-20.fc9.ppc requires /usr/bin/perl perl-ExtUtils-MakeMaker-6.36-20.fc9.ppc requires /usr/bin/perl perl-ExtUtils-MakeMaker-Coverage-0.05-4.fc9.noarch requires /usr/bin/perl 1:perl-ExtUtils-ParseXS-2.18-20.fc9.ppc requires /usr/bin/perl perl-File-Find-Rule-0.30-6.fc9.noarch requires /usr/bin/perl perl-File-MimeInfo-0.15-2.fc9.noarch requires /usr/bin/perl perl-File-Which-0.05-4.fc9.noarch requires /usr/bin/perl perl-Finance-YahooQuote-0.21-3.fc9.noarch requires /usr/bin/perl perl-GD-2.35-7.fc9.ppc requires /usr/bin/perl perl-GDTextUtil-0.86-11.fc9.noarch requires /bin/sh perl-Gearman-Server-1.09-2.fc9.noarch requires /usr/bin/perl perl-Gtk2-Ex-PodViewer-0.17-4.fc9.noarch requires /usr/bin/perl 1:perl-HTML-Mason-1.39-2.fc9.noarch requires /usr/bin/perl 1:perl-HTML-Mason-1.39-2.fc9.noarch requires /etc/httpd/conf.d perl-HTML-Tidy-1.08-3.fc9.ppc requires /usr/bin/perl 1:perl-HTML-Tree-3.23-4.fc9.noarch requires /usr/bin/perl perl-HTTP-DAV-0.31-2.fc9.noarch requires /usr/bin/perl perl-IO-stringy-2.110-8.fc9.noarch requires /usr/bin/perl perl-Image-ExifTool-7.25-1.fc10.noarch requires /usr/bin/perl perl-Image-Info-1.27-3.fc9.noarch requires /usr/share/X11/rgb.txt perl-Image-Size-3.1-3.fc9.noarch requires /usr/bin/perl perl-Kwiki-0.39-3.fc9.noarch requires /usr/bin/perl perl-Lingua-EN-Inflect-1.89-7.fc9.noarch requires /usr/bin/perl perl-Locale-Maketext-Lexicon-0.66-2.fc9.noarch requires /usr/bin/perl perl-MARC-Record-2.0.0-2.fc9.noarch requires /usr/bin/perl perl-MIME-Lite-3.01-6.fc9.noarch requires /usr/bin/perl perl-MIME-tools-5.426-1.fc9.noarch requires /usr/bin/perl perl-Mail-Mbox-MessageParser-1.5000-5.fc9.noarch requires /usr/bin/diff 1:perl-Module-Build-0.2808-20.fc9.ppc requires /usr/bin/perl perl-Module-CPANTS-Analyse-0.75-3.fc9.noarch requires /usr/bin/perl perl-Module-CoreList-2.14-20.fc9.ppc requires /usr/bin/perl perl-Module-Info-0.31-3.fc9.noarch requires /usr/bin/perl perl-Module-ScanDeps-0.84-1.fc10.noarch requires /usr/bin/perl perl-Module-Signature-0.55-3.fc9.noarch requires /usr/bin/perl perl-Module-Starter-1.42-5.fc9.noarch requires /usr/bin/perl perl-MogileFS-Utils-2.12-2.fc9.noarch requires /usr/bin/perl perl-Net-DNS-SEC-0.14-3.fc9.noarch requires /usr/bin/perl perl-Net-IP-1.25-8.fc9.noarch requires /usr/bin/perl perl-Net-IPv4Addr-0.10-3.fc9.noarch requires /usr/bin/perl perl-Net-NBName-0.26-3.fc9.noarch requires /usr/bin/perl perl-Net-Pcap-0.14-4.fc9.ppc requires /usr/bin/perl perl-Net-SNMP-5.2.0-2.fc9.noarch requires /usr/bin/perl perl-Net-Server-0.97-2.fc9.noarch requires /usr/bin/perl perl-Net-eBay-0.46-2.fc9.noarch requires /usr/bin/perl perl-PDL-2.4.3-12.fc9.ppc requires /usr/bin/perl perl-PPI-HTML-1.07-3.fc9.noarch requires /usr/bin/perl perl-PPI-Tester-0.06-5.fc9.noarch requires /usr/bin/perl perl-Parse-Yapp-1.05-38.fc9.noarch requires /usr/bin/perl perl-Perl-Critic-1.080-3.fc9.noarch requires /usr/bin/perl perl-Perl-MinimumVersion-0.15-5.fc9.noarch requires /usr/bin/perl perl-Perl6-Bible-0.30-5.fc9.noarch requires /usr/bin/perl perl-Pod-Coverage-0.19-3.fc9.noarch requires /usr/bin/perl perl-Pod-POM-0.17-9.fc9.noarch requires /usr/bin/perl perl-Pod-Readme-0.090-3.fc9.noarch requires /usr/bin/perl perl-Pod-Spell-1.01-4.fc9.noarch requires /usr/bin/perl perl-Pod-Tests-0.18-6.fc9.noarch requires /usr/bin/perl perl-Proc-ProcessTable-0.42-1.fc9.ppc requires /usr/bin/perl perl-Pugs-Compiler-Rule-0.28-2.fc9.noarch requires /usr/bin/env perl-RPM-Specfile-1.51-5.fc9.noarch requires /usr/bin/perl perl-Razor-Agent-2.84-4.fc9.ppc requires /usr/bin/perl perl-SGMLSpm-1.03ii-18.fc9.noarch requires /usr/bin/perl perl-SOAP-Lite-0.68-6.fc9.noarch requires /bin/env perl-SOAP-Lite-0.68-6.fc9.noarch requires /usr/bin/env perl-SQL-Translator-0.09000-1.fc9.noarch requires /usr/bin/perl perl-SVK-2.0.2-3.fc9.noarch requires /usr/bin/perl perl-SVN-Mirror-0.73-3.fc9.noarch requires /usr/bin/perl perl-Spreadsheet-WriteExcel-2.20-2.fc9.noarch requires /usr/bin/perl perl-String-ShellQuote-1.03-5.fc9.noarch requires /usr/bin/perl perl-Taint-Runtime-0.03-5.fc9.ppc requires /usr/bin/perl perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Template-Toolkit-2.19-4.fc9.ppc requires /usr/bin/perl perl-Test-AutoBuild-1.2.2-3.fc9.noarch requires /usr/bin/mkisofs perl-Test-AutoBuild-1.2.2-3.fc9.noarch requires /usr/bin/createrepo perl-Test-AutoBuild-1.2.2-3.fc9.noarch requires /usr/bin/xsltproc perl-Test-AutoBuild-1.2.2-3.fc9.noarch requires /usr/bin/perl perl-Test-AutoBuild-1.2.2-3.fc9.noarch requires /bin/sh perl-Test-AutoBuild-1.2.2-3.fc9.noarch requires /usr/bin/yum-arch perl-Test-AutoBuild-1.2.2-3.fc9.noarch requires /usr/bin/genbasedir perl-Test-AutoBuild-account-1.2.2-3.fc9.noarch requires /bin/sh perl-Test-Harness-2.64-20.fc9.ppc requires /usr/bin/perl perl-Test-Inline-2.208-2.fc9.noarch requires /usr/bin/perl perl-Test-Unit-0.25-4.fc9.noarch requires /usr/bin/perl perl-Text-RecordParser-1.2.1-4.fc9.noarch requires /usr/bin/perl perl-Text-Smart-1.0.2-1.fc10.noarch requires /usr/bin/perl perl-Tk-804.028-5.fc9.ppc requires /usr/bin/perl perl-Unicode-Map-0.112-14.fc9.ppc requires /usr/bin/perl perl-Unicode-Map8-0.12-17.fc9.ppc requires /usr/bin/perl perl-VCS-LibCVS-1.0002-3.fc9.noarch requires /usr/bin/perl perl-WWW-Mechanize-1.32-2.fc9.noarch requires /usr/bin/perl perl-WWW-Myspace-0.60-2.fc9.noarch requires /usr/bin/perl perl-WWW-Search-2.497-2.fc9.noarch requires /usr/bin/perl perl-Wx-0.81-1.fc9.ppc requires /usr/bin/perl perl-XML-Entities-0.03-1.fc9.noarch requires /usr/bin/perl perl-XML-Handler-YAWriter-0.23-5.fc9.noarch requires /usr/bin/perl 1:perl-XML-LibXML-1.65-5.fc9.ppc requires /bin/sh 1:perl-XML-LibXML-1.65-5.fc9.ppc requires /bin/sh perl-XML-SAX-0.16-5.fc9.noarch requires /bin/sh perl-XML-Tidy-1.2.54HJnFa-4.fc9.noarch requires /usr/bin/perl perl-XML-Twig-3.32-1.fc9.noarch requires /usr/bin/perl perl-XML-XPath-1.13-6.fc9.noarch requires /usr/bin/perl perl-XML-XQL-0.68-6.fc9.noarch requires /usr/bin/perl perl-YAML-0.66-3.fc9.noarch requires /usr/bin/perl perl-bioperl-1.5.2_102-12.fc9.noarch requires /usr/bin/perl perl-bioperl-run-1.5.2_100-3.fc9.noarch requires /usr/bin/perl 4:perl-devel-5.10.0-20.fc9.ppc requires /usr/bin/perl 4:perl-devel-5.10.0-20.fc9.ppc64 requires /usr/bin/perl 4:perl-libs-5.10.0-20.fc9.ppc requires /sbin/ldconfig 4:perl-libs-5.10.0-20.fc9.ppc64 requires /sbin/ldconfig perl-libwww-perl-5.808-7.fc9.noarch requires /usr/bin/perl perl-pmtools-1.10-1.fc9.noarch requires /usr/bin/perl perltidy-20071205-3.fc9.noarch requires /usr/bin/perl pessulus-2.16.2-2.fc7.noarch requires /usr/bin/env pessulus-2.16.2-2.fc7.noarch requires /usr/bin/python petitboot-0.0.1-7.fc8.ppc requires /bin/sh pexpect-2.3-1.fc9.noarch requires /usr/bin/env pfqueue-0.5.6-7.fc9.ppc requires /sbin/ldconfig pfqueue-0.5.6-7.fc9.ppc64 requires /sbin/ldconfig pgfouine-1.0-2.fc8.noarch requires /usr/bin/php pgp-tools-0.4.12-2.fc9.noarch requires /usr/bin/perl pgp-tools-0.4.12-2.fc9.noarch requires /bin/sh pharosc-8.3-1.fc8.noarch requires /bin/bash pharosc-alliance-8.3-1.fc8.noarch requires /bin/bash pharosc-alliance-devel-8.3-1.fc8.noarch requires /bin/bash pharosc-doc-8.3-1.fc8.noarch requires /bin/bash pharosc-magic-8.3-1.fc8.noarch requires /bin/bash pharosc-magic-devel-8.3-1.fc8.noarch requires /bin/bash pharosc-synopsys-8.3-1.fc8.noarch requires /bin/bash pharosc-xcircuit-8.3-1.fc8.noarch requires /bin/bash phasex-0.11.1-5.fc9.ppc requires /bin/sh photoml-0.25-1.fc9.noarch requires /usr/bin/perl photoml-0.25-1.fc9.noarch requires /bin/sh php-channel-phing-1.0.0-5.fc9.noarch requires /bin/sh php-channel-phing-1.0.0-5.fc9.noarch requires /usr/bin/pear php-channel-phpdb-1.0.0-4.fc8.noarch requires /bin/sh php-channel-phpdb-1.0.0-4.fc8.noarch requires /usr/bin/pear php-channel-phpunit-1.0-2.fc7.noarch requires /bin/sh php-channel-symfony-1.0.0-2.fc9.noarch requires /bin/sh php-channel-symfony-1.0.0-2.fc9.noarch requires /usr/bin/pear php-devel-5.2.5-7.fc9.ppc requires /bin/sh php-devel-5.2.5-7.fc9.ppc64 requires /bin/sh 1:php-eaccelerator-0.9.5.2-2.fc9.ppc requires /bin/sh php-embedded-5.2.5-7.fc9.ppc requires /sbin/ldconfig php-embedded-5.2.5-7.fc9.ppc64 requires /sbin/ldconfig php-magickwand-1.0.7-1.fc10.ppc requires libWand.so.10 php-magickwand-1.0.7-1.fc10.ppc requires libMagick.so.10 1:php-pear-1.7.1-2.fc9.noarch requires /bin/sh php-pear-Auth-SASL-1.0.2-4.fc6.noarch requires /bin/sh php-pear-Auth-SASL-1.0.2-4.fc6.noarch requires /usr/bin/pear php-pear-Benchmark-1.2.7-1.fc8.noarch requires /usr/bin/pear php-pear-Benchmark-1.2.7-1.fc8.noarch requires /bin/sh php-pear-Cache-1.5.5-0.2.RC4.fc8.noarch requires /usr/bin/pear php-pear-Cache-1.5.5-0.2.RC4.fc8.noarch requires /bin/sh php-pear-Cache-Lite-1.7.3-1.fc10.noarch requires /bin/sh php-pear-Cache-Lite-1.7.3-1.fc10.noarch requires /usr/bin/pear php-pear-Console-Color-1.0.2-1.fc7.noarch requires /usr/bin/pear php-pear-Console-Color-1.0.2-1.fc7.noarch requires /bin/sh php-pear-Console-Getargs-1.3.4-1.fc8.1.noarch requires /usr/bin/pear php-pear-Console-Getargs-1.3.4-1.fc8.1.noarch requires /bin/sh php-pear-Console-Table-1.1.1-1.fc9.noarch requires /usr/bin/pear php-pear-Console-Table-1.1.1-1.fc9.noarch requires /bin/sh php-pear-Crypt-CHAP-1.0.1-1.fc7.noarch requires /usr/bin/pear php-pear-Crypt-CHAP-1.0.1-1.fc7.noarch requires /bin/sh php-pear-DB-1.7.13-1.fc8.noarch requires /bin/sh php-pear-DB-1.7.13-1.fc8.noarch requires /usr/bin/pear php-pear-DB-1.7.13-1.fc8.noarch requires /bin/sh php-pear-DB-DataObject-1.8.8-1.fc9.noarch requires /usr/bin/pear php-pear-DB-DataObject-1.8.8-1.fc9.noarch requires /bin/sh php-pear-DB-DataObject-1.8.8-1.fc9.noarch requires /usr/bin/php php-pear-DB-DataObject-FormBuilder-1.0.0-0.5.RC7.fc7.noarch requires /usr/bin/pear php-pear-DB-DataObject-FormBuilder-1.0.0-0.5.RC7.fc7.noarch requires /bin/sh php-pear-DB-DataObject-FormBuilder-1.0.0-0.5.RC7.fc7.noarch requires /usr/bin/php php-pear-DB-QueryTool-1.1.2-1.fc9.noarch requires /usr/bin/pear php-pear-DB-QueryTool-1.1.2-1.fc9.noarch requires /bin/sh php-pear-Date-1.4.7-2.fc7.noarch requires /usr/bin/pear php-pear-Date-1.4.7-2.fc7.noarch requires /bin/sh php-pear-Date-Holidays-0.17.4-1.fc9.noarch requires /usr/bin/pear php-pear-Date-Holidays-0.17.4-1.fc9.noarch requires /bin/sh php-pear-Date-Holidays-0.17.4-1.fc9.noarch requires /usr/bin/php php-pear-File-1.3.0-1.fc8.noarch requires /usr/bin/pear php-pear-File-1.3.0-1.fc8.noarch requires /bin/sh php-pear-File-Find-1.3.0-1.fc9.noarch requires /usr/bin/pear php-pear-File-Find-1.3.0-1.fc9.noarch requires /bin/sh php-pear-File-Passwd-1.1.6-2.fc7.noarch requires /usr/bin/pear php-pear-File-Passwd-1.1.6-2.fc7.noarch requires /bin/sh php-pear-File-SMBPasswd-1.0.2-1.fc7.noarch requires /usr/bin/pear php-pear-File-SMBPasswd-1.0.2-1.fc7.noarch requires /bin/sh php-pear-HTML-Common-1.2.4-1.fc8.noarch requires /usr/bin/pear php-pear-HTML-Common-1.2.4-1.fc8.noarch requires /bin/sh php-pear-HTML-QuickForm-3.2.10-1.fc9.noarch requires /usr/bin/pear php-pear-HTML-QuickForm-3.2.10-1.fc9.noarch requires /bin/sh php-pear-HTML-QuickForm-ElementGrid-0.1.1-1.fc7.noarch requires /usr/bin/pear php-pear-HTML-QuickForm-ElementGrid-0.1.1-1.fc7.noarch requires /bin/sh php-pear-HTML-QuickForm-advmultiselect-1.4.1-1.fc10.noarch requires /usr/bin/pear php-pear-HTML-QuickForm-advmultiselect-1.4.1-1.fc10.noarch requires /bin/sh php-pear-HTML-Table-1.8.2-1.fc9.noarch requires /usr/bin/pear php-pear-HTML-Table-1.8.2-1.fc9.noarch requires /bin/sh php-pear-HTTP-1.4.0-8.fc8.noarch requires /bin/sh php-pear-HTTP-1.4.0-8.fc8.noarch requires /usr/bin/pear php-pear-HTTP-Request-1.4.2-1.fc9.noarch requires /usr/bin/pear php-pear-HTTP-Request-1.4.2-1.fc9.noarch requires /bin/sh php-pear-HTTP-Upload-0.9.1-2.fc9.noarch requires /usr/bin/pear php-pear-HTTP-Upload-0.9.1-2.fc9.noarch requires /bin/sh php-pear-Image-Canvas-0.3.1-1.fc8.noarch requires /usr/bin/pear php-pear-Image-Canvas-0.3.1-1.fc8.noarch requires /bin/sh php-pear-Image-Color-1.0.2-3.fc7.noarch requires /usr/bin/pear php-pear-Image-Color-1.0.2-3.fc7.noarch requires /bin/sh php-pear-Image-Graph-0.7.2-2.fc7.noarch requires /usr/bin/pear php-pear-Image-Graph-0.7.2-2.fc7.noarch requires /bin/sh php-pear-Image-GraphViz-1.2.1-2.fc7.noarch requires /usr/bin/pear php-pear-Image-GraphViz-1.2.1-2.fc7.noarch requires /bin/sh php-pear-Log-1.10.1-1.fc10.noarch requires /bin/sh php-pear-Log-1.10.1-1.fc10.noarch requires /usr/bin/pear php-pear-MDB2-2.4.1-2.fc9.noarch requires /usr/bin/pear php-pear-MDB2-2.4.1-2.fc9.noarch requires /bin/sh php-pear-MDB2-Driver-mysql-1.4.1-3.fc9.noarch requires /usr/bin/pear php-pear-MDB2-Driver-mysql-1.4.1-3.fc9.noarch requires /bin/sh php-pear-MDB2-Driver-mysqli-1.4.1-3.fc9.noarch requires /usr/bin/pear php-pear-MDB2-Driver-mysqli-1.4.1-3.fc9.noarch requires /bin/sh php-pear-Mail-1.1.14-2.fc8.noarch requires /bin/sh php-pear-Mail-1.1.14-2.fc8.noarch requires /usr/bin/pear php-pear-Mail-Mime-1.5.2-3.fc9.noarch requires /usr/bin/pear php-pear-Mail-Mime-1.5.2-3.fc9.noarch requires /bin/sh php-pear-Mail-mimeDecode-1.5.0-3.fc9.noarch requires /usr/bin/pear php-pear-Mail-mimeDecode-1.5.0-3.fc9.noarch requires /bin/sh php-pear-Math-Stats-0.9.0-0.1.beta3.fc7.noarch requires /usr/bin/pear php-pear-Math-Stats-0.9.0-0.1.beta3.fc7.noarch requires /bin/sh php-pear-Net-Curl-1.2.3-2.fc6.noarch requires /usr/bin/pear php-pear-Net-Curl-1.2.3-2.fc6.noarch requires /bin/sh php-pear-Net-DIME-0.3-1.fc7.noarch requires /usr/bin/pear php-pear-Net-DIME-0.3-1.fc7.noarch requires /bin/sh php-pear-Net-FTP-1.3.4-1.fc9.noarch requires /usr/bin/pear php-pear-Net-FTP-1.3.4-1.fc9.noarch requires /bin/sh php-pear-Net-POP3-1.3.6-2.fc7.noarch requires /usr/bin/pear php-pear-Net-POP3-1.3.6-2.fc7.noarch requires /bin/sh php-pear-Net-Ping-2.4.3-1.fc9.noarch requires /usr/bin/pear php-pear-Net-Ping-2.4.3-1.fc9.noarch requires /bin/sh php-pear-Net-Ping-2.4.3-1.fc9.noarch requires /bin/ping php-pear-Net-SMTP-1.3.0-1.fc10.noarch requires /bin/sh php-pear-Net-SMTP-1.3.0-1.fc10.noarch requires /usr/bin/pear php-pear-Net-Sieve-1.1.5-2.fc7.noarch requires /usr/bin/pear php-pear-Net-Sieve-1.1.5-2.fc7.noarch requires /bin/sh php-pear-Net-Socket-1.0.8-1.fc7.noarch requires /usr/bin/pear php-pear-Net-Socket-1.0.8-1.fc7.noarch requires /bin/sh php-pear-Net-Traceroute-0.21.1-2.fc8.noarch requires /usr/bin/pear php-pear-Net-Traceroute-0.21.1-2.fc8.noarch requires /bin/sh php-pear-Net-URL-1.0.15-1.fc8.noarch requires /usr/bin/pear php-pear-Net-URL-1.0.15-1.fc8.noarch requires /bin/sh php-pear-Net-URL-Mapper-0.9.0-2.fc9.noarch requires /usr/bin/pear php-pear-Net-URL-Mapper-0.9.0-2.fc9.noarch requires /bin/sh php-pear-Net-UserAgent-Detect-2.4.0-1.fc8.noarch requires /usr/bin/pear php-pear-Net-UserAgent-Detect-2.4.0-1.fc8.noarch requires /bin/sh php-pear-Numbers-Roman-1.0.2-2.fc9.noarch requires /usr/bin/pear php-pear-Numbers-Roman-1.0.2-2.fc9.noarch requires /bin/sh php-pear-Numbers-Words-0.15.0-2.fc7.noarch requires /usr/bin/pear php-pear-Numbers-Words-0.15.0-2.fc7.noarch requires /bin/sh php-pear-PEAR-Command-Packaging-0.1.2-5.fc6.noarch requires /usr/bin/pear php-pear-PEAR-Command-Packaging-0.1.2-5.fc6.noarch requires /bin/sh php-pear-PHP-CodeSniffer-1.0.1-1.fc9.noarch requires /usr/bin/pear php-pear-PHP-CodeSniffer-1.0.1-1.fc9.noarch requires /bin/sh php-pear-PHP-Compat-1.5.0-1.fc6.noarch requires /usr/bin/pear php-pear-PHP-Compat-1.5.0-1.fc6.noarch requires /bin/sh php-pear-PHP-CompatInfo-1.7.0-1.fc10.noarch requires /usr/bin/pear php-pear-PHP-CompatInfo-1.7.0-1.fc10.noarch requires /bin/sh php-pear-PHP-CompatInfo-1.7.0-1.fc10.noarch requires /usr/bin/php php-pear-PHPUnit-3.2.15-1.fc9.noarch requires /usr/bin/pear php-pear-PHPUnit-3.2.15-1.fc9.noarch requires /bin/sh php-pear-PHPUnit-3.2.15-1.fc9.noarch requires /usr/bin/php php-pear-Pager-2.4.4-1.fc8.noarch requires /usr/bin/pear php-pear-Pager-2.4.4-1.fc8.noarch requires /bin/sh php-pear-Payment-Process-0.6.5-1.fc6.noarch requires /usr/bin/pear php-pear-Payment-Process-0.6.5-1.fc6.noarch requires /bin/sh php-pear-Phlickr-0.2.7-2.fc8.noarch requires /usr/bin/pear php-pear-Phlickr-0.2.7-2.fc8.noarch requires /bin/sh php-pear-PhpDocumentor-1.4.1-2.fc9.noarch requires /usr/bin/pear php-pear-PhpDocumentor-1.4.1-2.fc9.noarch requires /bin/sh php-pear-SOAP-0.11.0-1.fc8.noarch requires /usr/bin/pear php-pear-SOAP-0.11.0-1.fc8.noarch requires /bin/sh php-pear-Services-Weather-1.4.2-1.fc7.noarch requires /usr/bin/pear php-pear-Services-Weather-1.4.2-1.fc7.noarch requires /bin/sh php-pear-Services-Weather-1.4.2-1.fc7.noarch requires /usr/bin/php php-pear-Structures-DataGrid-0.9.0-2.fc9.noarch requires /usr/bin/pear php-pear-Structures-DataGrid-0.9.0-2.fc9.noarch requires /bin/sh php-pear-Structures-DataGrid-DataSource-Array-0.1.4-1.fc9.noarch requires /usr/bin/pear php-pear-Structures-DataGrid-DataSource-Array-0.1.4-1.fc9.noarch requires /bin/sh php-pear-Structures-DataGrid-DataSource-DataObject-0.2.1-1.fc9.noarch requires /usr/bin/pear php-pear-Structures-DataGrid-DataSource-DataObject-0.2.1-1.fc9.noarch requires /bin/sh php-pear-Structures-DataGrid-DataSource-MDB2-0.1.11-1.fc9.noarch requires /usr/bin/pear php-pear-Structures-DataGrid-DataSource-MDB2-0.1.11-1.fc9.noarch requires /bin/sh php-pear-Structures-DataGrid-DataSource-RSS-0.1.1-1.fc7.noarch requires /usr/bin/pear php-pear-Structures-DataGrid-DataSource-RSS-0.1.1-1.fc7.noarch requires /bin/sh php-pear-Structures-DataGrid-Renderer-Pager-0.1.3-1.fc9.noarch requires /usr/bin/pear php-pear-Structures-DataGrid-Renderer-Pager-0.1.3-1.fc9.noarch requires /bin/sh php-pear-Structures-DataGrid-Renderer-Smarty-0.1.4-1.fc9.noarch requires /usr/bin/pear php-pear-Structures-DataGrid-Renderer-Smarty-0.1.4-1.fc9.noarch requires /bin/sh php-pear-Validate-0.8.1-1.fc9.noarch requires /usr/bin/pear php-pear-Validate-0.8.1-1.fc9.noarch requires /bin/sh php-pear-Validate-Finance-CreditCard-0.5.2-1.fc6.noarch requires /usr/bin/pear php-pear-Validate-Finance-CreditCard-0.5.2-1.fc6.noarch requires /bin/sh php-pear-XML-Beautifier-1.1-2.fc7.noarch requires /usr/bin/pear php-pear-XML-Beautifier-1.1-2.fc7.noarch requires /bin/sh php-pear-XML-Parser-1.2.8-2.fc8.noarch requires /bin/sh php-pear-XML-Parser-1.2.8-2.fc8.noarch requires /usr/bin/pear php-pear-XML-RSS-0.9.10-3.fc7.noarch requires /usr/bin/pear php-pear-XML-RSS-0.9.10-3.fc7.noarch requires /bin/sh php-pear-XML-Serializer-0.18.0-3.fc7.noarch requires /usr/bin/pear php-pear-XML-Serializer-0.18.0-3.fc7.noarch requires /bin/sh php-pear-XML-Util-1.1.4-2.fc7.noarch requires /usr/bin/pear php-pear-XML-Util-1.1.4-2.fc7.noarch requires /bin/sh php-pear-creole-1.1.0-5.fc8.noarch requires /usr/bin/pear php-pear-creole-1.1.0-5.fc8.noarch requires /bin/sh php-pear-pake-1.1.4-3.fc9.noarch requires /bin/sh php-pear-pake-1.1.4-3.fc9.noarch requires /usr/bin/pear php-pear-pake-1.1.4-3.fc9.noarch requires /bin/sh php-pear-phing-2.3.0-1.fc9.noarch requires /bin/sh php-pear-phing-2.3.0-1.fc9.noarch requires /usr/bin/pear php-pear-phing-2.3.0-1.fc9.noarch requires /bin/sh php-pecl-mailparse-2.1.4-1.fc9.ppc requires /bin/sh php-pecl-mailparse-2.1.4-1.fc9.ppc requires /usr/bin/pecl php-pecl-memcache-2.2.3-1.fc9.ppc requires /bin/sh php-pecl-memcache-2.2.3-1.fc9.ppc requires /usr/bin/pecl php-pecl-phar-1.2.3-3.fc9.ppc requires /bin/sh php-pecl-phar-1.2.3-3.fc9.ppc requires /usr/bin/pecl php-pecl-phar-1.2.3-3.fc9.ppc requires /usr/bin/php php-pecl-radius-1.2.5-5.fc10.ppc requires /bin/sh php-pecl-radius-1.2.5-5.fc10.ppc requires /usr/bin/pecl php-pecl-xdebug-2.0.2-4.fc9.ppc requires /bin/sh php-pecl-xdebug-2.0.2-4.fc9.ppc requires /usr/bin/pecl phpMyAdmin-2.11.6-1.fc10.noarch requires /usr/bin/perl phpMyAdmin-2.11.6-1.fc10.noarch requires /bin/bash phpMyAdmin-2.11.6-1.fc10.noarch requires /bin/sh phpPgAdmin-4.2-1.fc9.noarch requires /bin/sh phpPgAdmin-4.2-1.fc9.noarch requires /usr/bin/awk phpPgAdmin-4.2-1.fc9.noarch requires /sbin/service phpPgAdmin-4.2-1.fc9.noarch requires /bin/bash phpPgAdmin-4.2-1.fc9.noarch requires /usr/bin/php phpTodo-0.8.1-0.8.beta.fc8.noarch requires /bin/sh phpcs-1.0.1-1.fc9.noarch requires /usr/bin/php phpdoc-1.4.1-2.fc9.noarch requires /usr/bin/php phpldapadmin-1.1.0.5-1.fc9.noarch requires /bin/sh phpwapmail-0.9.2-1.fc9.noarch requires /bin/sh physfs-1.0.1-8.fc9.ppc requires /sbin/ldconfig physfs-1.0.1-8.fc9.ppc64 requires /sbin/ldconfig pic2aa-0.2.1-3.fc9.ppc requires /bin/sh picard-0.9.0-6.fc9.ppc requires /usr/bin/python piccolo-1.04-3jpp.2.fc9.ppc requires /bin/sh pida-0.5.1-6.fc9.ppc requires /usr/bin/env pida-0.5.1-6.fc9.ppc requires /usr/bin/python pida-0.5.1-6.fc9.ppc requires /bin/sh pidgin-2.4.1-3.fc10.ppc requires /bin/sh pigment-0.3.5-1.fc9.ppc requires /sbin/ldconfig pigment-0.3.5-1.fc9.ppc64 requires /sbin/ldconfig piklab-0.15.0-1.fc9.ppc requires /bin/sh pikloops-0.2.5-3.fc9.ppc requires /bin/sh 2:pilot-link-0.12.3-13.fc9.ppc requires /sbin/ldconfig 2:pilot-link-0.12.3-13.fc9.ppc requires /usr/bin/perl 2:pilot-link-0.12.3-13.fc9.ppc requires /usr/bin/env 2:pilot-link-0.12.3-13.fc9.ppc64 requires /usr/bin/env 2:pilot-link-0.12.3-13.fc9.ppc64 requires /sbin/ldconfig 2:pilot-link-0.12.3-13.fc9.ppc64 requires /usr/bin/perl pils-2.1.3-1.fc9.ppc requires /sbin/ldconfig pils-2.1.3-1.fc9.ppc64 requires /sbin/ldconfig pinball-0.3.1-11.fc9.ppc requires /bin/sh pinentry-0.7.4-5.fc9.ppc requires /bin/sh pinentry-0.7.4-5.fc9.ppc requires /usr/sbin/update-alternatives pinentry-0.7.4-5.fc9.ppc requires /sbin/install-info pinentry-gtk-0.7.4-5.fc9.ppc requires /usr/sbin/update-alternatives pinentry-gtk-0.7.4-5.fc9.ppc requires /bin/sh pinentry-qt-0.7.4-5.fc9.ppc requires /bin/sh pinentry-qt-0.7.4-5.fc9.ppc requires /usr/sbin/update-alternatives pinfo-0.6.9-7.fc9.ppc requires /bin/sh pingus-0.7.2-3.fc9.ppc requires /bin/sh pingus-0.7.2-3.fc9.ppc requires /usr/bin/guile pinot-0.85-1.fc10.ppc requires /bin/sh pioneers-0.12.2-1.fc10.ppc requires /bin/sh pipenightdreams-0.10.0-8.fc9.ppc requires /bin/sh pipepanic-0.1.3-5.fc9.ppc requires /bin/sh pitivi-0.11.1-2.fc9.noarch requires /usr/bin/env pixman-0.10.0-1.fc9.ppc requires /sbin/ldconfig pixman-0.10.0-1.fc9.ppc64 requires /sbin/ldconfig pl-5.6.47-7.fc9.ppc requires /bin/bash plague-0.4.4.1-4.fc7.noarch requires /bin/sh plague-0.4.4.1-4.fc7.noarch requires /bin/bash plague-0.4.4.1-4.fc7.noarch requires /sbin/chkconfig plague-0.4.4.1-4.fc7.noarch requires /usr/bin/python plague-0.4.4.1-4.fc7.noarch requires /sbin/service plague-builder-0.4.4.1-4.fc7.noarch requires /bin/sh plague-builder-0.4.4.1-4.fc7.noarch requires /bin/bash plague-builder-0.4.4.1-4.fc7.noarch requires /sbin/chkconfig plague-builder-0.4.4.1-4.fc7.noarch requires /usr/sbin/useradd plague-builder-0.4.4.1-4.fc7.noarch requires /usr/bin/python plague-builder-0.4.4.1-4.fc7.noarch requires /sbin/service plague-client-0.4.4.1-4.fc7.noarch requires /usr/bin/python plague-utils-0.4.4.1-4.fc7.noarch requires /usr/bin/python planet-2.0-5.fc9.noarch requires /usr/bin/python planets-0.1.13-2.fc9.ppc requires /bin/sh planner-0.14.3-2.fc10.ppc requires /usr/bin/scrollkeeper-update planner-0.14.3-2.fc10.ppc requires /bin/sh planner-0.14.3-2.fc10.ppc64 requires /bin/sh planner-0.14.3-2.fc10.ppc64 requires /usr/bin/scrollkeeper-update plexus-ant-factory-1.0-0.2.a1.1jpp.6.fc9.ppc requires /bin/sh plexus-ant-factory-javadoc-1.0-0.2.a1.1jpp.6.fc9.ppc requires /bin/rm plexus-ant-factory-javadoc-1.0-0.2.a1.1jpp.6.fc9.ppc requires /bin/ls plexus-appserver-1.0-0.2.a5.2jpp.4.fc9.ppc requires /bin/sh plexus-archiver-1.0-0.2.a7.1jpp.1.fc9.ppc requires /bin/sh plexus-bsh-factory-1.0-0.2.a7s.1jpp.6.fc9.ppc requires /bin/sh plexus-cdc-1.0-0.2.a4.1jpp.4.fc9.ppc requires /bin/sh plexus-i18n-1.0-0.b6.5jpp.2.fc9.noarch requires /bin/sh plexus-maven-plugin-1.2-2jpp.3.fc9.ppc requires /bin/sh plexus-runtime-builder-1.0-0.2.a9.1jpp.3.fc9.ppc requires /bin/sh plexus-velocity-1.1.2-3jpp.1.fc9.ppc requires /bin/sh plexus-xmlrpc-1.0-0.2.b4.2jpp.7.fc9.ppc requires /bin/sh plib-1.8.5-1.fc10.ppc requires /sbin/ldconfig plib-1.8.5-1.fc10.ppc64 requires /sbin/ldconfig plotmm-0.1.2-6.fc9.ppc requires /sbin/ldconfig plotmm-0.1.2-6.fc9.ppc64 requires /sbin/ldconfig plotutils-2.5-5.fc9.ppc requires /bin/sh plotutils-2.5-5.fc9.ppc requires /sbin/install-info plotutils-2.5-5.fc9.ppc requires /sbin/ldconfig plotutils-2.5-5.fc9.ppc64 requires /bin/sh plotutils-2.5-5.fc9.ppc64 requires /sbin/install-info plotutils-2.5-5.fc9.ppc64 requires /sbin/ldconfig plplot-5.9.0-1.fc9.ppc requires /usr/bin/env plplot-5.9.0-1.fc9.ppc requires /sbin/install-info plplot-5.9.0-1.fc9.ppc requires /sbin/ldconfig plplot-5.9.0-1.fc9.ppc requires /bin/bash plplot-5.9.0-1.fc9.ppc requires /bin/sh plplot-5.9.0-1.fc9.ppc requires /bin/sh plplot-ada-5.9.0-1.fc9.ppc requires /sbin/ldconfig plplot-ada-devel-5.9.0-1.fc9.ppc requires /bin/bash plplot-devel-5.9.0-1.fc9.ppc requires /bin/bash plplot-devel-5.9.0-1.fc9.ppc64 requires /bin/bash plplot-gnome-5.9.0-1.fc9.ppc requires /sbin/ldconfig plplot-gnome-5.9.0-1.fc9.ppc64 requires /sbin/ldconfig plplot-java-devel-5.9.0-1.fc9.ppc requires /bin/bash plplot-java-devel-5.9.0-1.fc9.ppc64 requires /bin/bash plplot-octave-5.9.0-1.fc9.ppc requires /sbin/ldconfig plplot-octave-5.9.0-1.fc9.ppc requires /bin/bash plplot-perl-5.9.0-1.fc9.ppc requires /bin/bash plplot-perl-5.9.0-1.fc9.ppc requires /usr/bin/env plplot-tk-5.9.0-1.fc9.ppc requires /sbin/ldconfig plplot-tk-5.9.0-1.fc9.ppc64 requires /sbin/ldconfig plplot-tk-devel-5.9.0-1.fc9.ppc requires /bin/sh plplot-tk-devel-5.9.0-1.fc9.ppc64 requires /bin/sh plt-scheme-372-1.fc9.ppc requires /bin/bash plt-scheme-372-1.fc9.ppc requires /bin/sh pm-utils-1.1.1-2.fc10.ppc requires /bin/sh pm-utils-1.1.1-2.fc10.ppc requires /bin/bash pm-utils-1.1.1-2.fc10.ppc requires /bin/sh pmd-3.6-1jpp.3.fc7.noarch requires /bin/bash pmount-0.9.17-2.fc9.ppc requires /bin/mount 1:pnm2ppa-1.04-15.fc9.ppc requires /bin/sh po4a-0.32-4.fc8.noarch requires /usr/bin/perl po4a-0.32-4.fc8.noarch requires /bin/sh podsleuth-0.6.0-5.fc10.ppc requires /bin/bash poedit-1.3.9-2.fc9.ppc requires /bin/sh poker-bot-1.5.0-1.fc10.noarch requires /bin/sh poker-bot-1.5.0-1.fc10.noarch requires /sbin/chkconfig poker-bot-1.5.0-1.fc10.noarch requires /bin/sh poker-bot-1.5.0-1.fc10.noarch requires /usr/bin/python poker-bot-1.5.0-1.fc10.noarch requires /sbin/service poker-engine-1.2.0-1.fc10.noarch requires /usr/bin/python poker-eval-134.0-2.fc9.ppc requires /sbin/ldconfig poker-eval-134.0-2.fc9.ppc64 requires /sbin/ldconfig poker-network-selinux-1.5.0-1.fc10.noarch requires /usr/sbin/semodule poker-network-selinux-1.5.0-1.fc10.noarch requires /sbin/fixfiles poker-network-selinux-1.5.0-1.fc10.noarch requires /bin/sh poker-network-selinux-1.5.0-1.fc10.noarch requires /usr/sbin/semanage poker-network-selinux-1.5.0-1.fc10.noarch requires /usr/sbin/setsebool poker-network-selinux-1.5.0-1.fc10.noarch requires /sbin/service poker-server-1.5.0-1.fc10.noarch requires /bin/sh poker-server-1.5.0-1.fc10.noarch requires /sbin/chkconfig poker-server-1.5.0-1.fc10.noarch requires /bin/sh poker-server-1.5.0-1.fc10.noarch requires /usr/bin/python poker-server-1.5.0-1.fc10.noarch requires /sbin/service poker-web-1.5.0-1.fc10.noarch requires /bin/sh poker2d-1.5.0-1.fc10.ppc requires /usr/bin/python2.5 poker2d-1.5.0-1.fc10.ppc requires /bin/sh poker3d-1.1.36-10.fc10.ppc requires /bin/sh poker3d-1.1.36-10.fc10.ppc requires /usr/libexec/poker3d/underware poker3d-1.1.36-10.fc10.ppc requires /bin/sh policycoreutils-2.0.49-2.fc10.ppc requires /bin/sh policycoreutils-2.0.49-2.fc10.ppc requires /bin/sed policycoreutils-2.0.49-2.fc10.ppc requires /bin/awk policycoreutils-2.0.49-2.fc10.ppc requires /usr/bin/python policycoreutils-2.0.49-2.fc10.ppc requires /sbin/service policycoreutils-2.0.49-2.fc10.ppc requires /usr/bin/diff policycoreutils-2.0.49-2.fc10.ppc requires /bin/mount policycoreutils-2.0.49-2.fc10.ppc requires /bin/egrep policycoreutils-2.0.49-2.fc10.ppc requires /bin/bash policycoreutils-2.0.49-2.fc10.ppc requires /bin/sh policycoreutils-2.0.49-2.fc10.ppc requires /sbin/chkconfig policycoreutils-gui-2.0.49-2.fc10.ppc requires /usr/bin/python polyml-libs-5.1-4.fc9.ppc requires /sbin/ldconfig pop-before-smtp-1.41-2.fc6.noarch requires /bin/sh pop-before-smtp-1.41-2.fc6.noarch requires /usr/bin/perl pop-before-smtp-1.41-2.fc6.noarch requires /bin/sh popt-1.13-3.fc9.ppc requires /sbin/ldconfig popt-1.13-3.fc9.ppc64 requires /sbin/ldconfig portaudio-19-5.fc9.ppc requires /sbin/ldconfig portaudio-19-5.fc9.ppc64 requires /sbin/ldconfig portecle-1.3-3.fc9.noarch requires /bin/sh portecle-1.3-3.fc9.noarch requires /bin/sh 2:postfix-2.5.1-2.fc9.ppc requires /bin/sh 2:postfix-2.5.1-2.fc9.ppc requires /usr/sbin/alternatives 2:postfix-2.5.1-2.fc9.ppc requires /usr/sbin/groupadd 2:postfix-2.5.1-2.fc9.ppc requires /usr/sbin/useradd 2:postfix-2.5.1-2.fc9.ppc requires /sbin/service 2:postfix-2.5.1-2.fc9.ppc requires /bin/bash 2:postfix-2.5.1-2.fc9.ppc requires /bin/sh 2:postfix-2.5.1-2.fc9.ppc requires /usr/bin/perl 2:postfix-2.5.1-2.fc9.ppc requires /sbin/chkconfig 2:postfix-2.5.1-2.fc9.ppc64 requires /bin/sh 2:postfix-2.5.1-2.fc9.ppc64 requires /usr/sbin/groupadd 2:postfix-2.5.1-2.fc9.ppc64 requires /usr/sbin/useradd 2:postfix-2.5.1-2.fc9.ppc64 requires /usr/sbin/alternatives 2:postfix-2.5.1-2.fc9.ppc64 requires /sbin/service 2:postfix-2.5.1-2.fc9.ppc64 requires /bin/bash 2:postfix-2.5.1-2.fc9.ppc64 requires /bin/sh 2:postfix-2.5.1-2.fc9.ppc64 requires /usr/bin/perl 2:postfix-2.5.1-2.fc9.ppc64 requires /sbin/chkconfig 2:postfix-pflogsumm-2.5.1-2.fc9.ppc requires /usr/bin/perl postgis-1.3.3-1.fc9.ppc requires /usr/bin/rebuild-gcj-db postgis-jdbc-1.3.3-1.fc9.ppc requires /usr/bin/rebuild-gcj-db postgresql-devel-8.3.1-3.fc10.ppc requires /bin/sh postgresql-devel-8.3.1-3.fc10.ppc64 requires /bin/sh postgresql-jdbc-8.3.603-1jpp.fc9.ppc requires /bin/sh postgresql-jdbc-8.3.603-1jpp.fc9.ppc requires /usr/bin/rebuild-gcj-db postgresql-libs-8.3.1-3.fc10.ppc requires /sbin/ldconfig postgresql-libs-8.3.1-3.fc10.ppc64 requires /sbin/ldconfig postgresql-odbc-08.03.0100-1.fc9.ppc requires /sbin/ldconfig postgresql-pgpool-3.4.1-2.fc9.1.ppc requires /bin/sh postgresql-pgpool-II-2.1-0.2.beta2.fc9.ppc requires /bin/sh postgresql-pgpool-II-2.1-0.2.beta2.fc9.ppc requires /sbin/ldconfig postgresql-pgpool-II-2.1-0.2.beta2.fc9.ppc requires /bin/sh postgresql-pgpool-II-2.1-0.2.beta2.fc9.ppc64 requires /bin/sh postgresql-pgpool-II-2.1-0.2.beta2.fc9.ppc64 requires /sbin/ldconfig postgresql-pgpool-II-2.1-0.2.beta2.fc9.ppc64 requires /bin/sh postgresql-pgpoolAdmin-1.0.0-7.fc8.noarch requires /bin/sh postgresql-plperl-8.3.1-3.fc10.ppc requires /sbin/ldconfig postgresql-plpython-8.3.1-3.fc10.ppc requires /sbin/ldconfig postgresql-pltcl-8.3.1-3.fc10.ppc requires /sbin/ldconfig postgresql-pltcl-8.3.1-3.fc10.ppc requires /bin/sh postgresql-python-8.3.1-3.fc10.ppc requires /usr/bin/env postgresql-server-8.3.1-3.fc10.ppc requires /bin/sh postgresql-server-8.3.1-3.fc10.ppc requires /usr/sbin/useradd postgresql-server-8.3.1-3.fc10.ppc requires /bin/sh postgresql-server-8.3.1-3.fc10.ppc requires /sbin/chkconfig postgresql-table_log-0.4.4-4.fc9.1.ppc requires /sbin/ldconfig postgresql-test-8.3.1-3.fc10.ppc requires /bin/sh postgresql-test-8.3.1-3.fc10.ppc requires /bin/sh postgresql_autodoc-1.31-1.fc9.noarch requires /usr/bin/perl postgrey-1.30-1.fc8.noarch requires /bin/sh postgrey-1.30-1.fc8.noarch requires /usr/sbin/useradd postgrey-1.30-1.fc8.noarch requires /sbin/service postgrey-1.30-1.fc8.noarch requires /usr/bin/perl postgrey-1.30-1.fc8.noarch requires /bin/sh postgrey-1.30-1.fc8.noarch requires /sbin/chkconfig postr-0.10-2.fc9.noarch requires /bin/sh postr-0.10-2.fc9.noarch requires /usr/bin/python powerman-1.0.32-5.fc9.ppc requires /bin/sh powerman-1.0.32-5.fc9.ppc requires /bin/sh powermanga-0.90-3.ppc requires /bin/sh powerpc-utils-1.0.6-3.fc9.ppc requires /usr/bin/perl powerpc-utils-1.0.6-3.fc9.ppc requires /bin/bash powerpc-utils-1.0.6-3.fc9.ppc requires /bin/sh powerpc-utils-papr-1.0.4-3.fc9.ppc requires /usr/bin/perl powerpc-utils-papr-1.0.4-3.fc9.ppc requires /bin/sh ppl-0.9-19.fc9.ppc requires /sbin/ldconfig ppl-0.9-19.fc9.ppc64 requires /sbin/ldconfig ppl-pwl-0.9-19.fc9.ppc requires /sbin/ldconfig ppl-pwl-0.9-19.fc9.ppc64 requires /sbin/ldconfig ppp-2.4.4-7.fc10.ppc requires /etc/pam.d/system-auth pptp-1.7.2-1.fc10.ppc requires /usr/bin/perl prelink-0.4.0-3.ppc requires /bin/sh prelink-0.4.0-3.ppc requires /bin/sh preload-0.4-6.fc9.ppc requires /bin/sh preload-0.4-6.fc9.ppc requires /bin/bash preload-0.4-6.fc9.ppc requires /sbin/chkconfig preload-0.4-6.fc9.ppc requires /sbin/service prelude-lml-0.9.12.2-1.fc10.ppc requires /bin/sh prelude-lml-0.9.12.2-1.fc10.ppc requires /sbin/service prelude-lml-0.9.12.2-1.fc10.ppc requires /bin/sh prelude-lml-0.9.12.2-1.fc10.ppc requires /sbin/chkconfig prelude-manager-0.9.12.1-1.fc10.ppc requires /bin/sh prelude-manager-0.9.12.1-1.fc10.ppc requires /sbin/service prelude-manager-0.9.12.1-1.fc10.ppc requires /bin/sh prelude-manager-0.9.12.1-1.fc10.ppc requires /sbin/chkconfig presto-utils-0.3.2-1.fc8.noarch requires /bin/sh presto-utils-0.3.2-1.fc8.noarch requires /usr/bin/python preupgrade-0.9.3-3.fc10.noarch requires /bin/sh preupgrade-0.9.3-3.fc10.noarch requires /bin/sh preupgrade-0.9.3-3.fc10.noarch requires /usr/bin/python prewikka-0.9.14-1.fc10.noarch requires /bin/sh prewikka-0.9.14-1.fc10.noarch requires /usr/bin/python privoxy-3.0.8-2.fc9.ppc requires /bin/sh privoxy-3.0.8-2.fc9.ppc requires /sbin/service privoxy-3.0.8-2.fc9.ppc requires /bin/sh privoxy-3.0.8-2.fc9.ppc requires /sbin/chkconfig procinfo-18-23.fc9.ppc requires /usr/bin/perl procmail-3.22-21.fc9.ppc requires /bin/sh procps-3.2.7-20.fc9.ppc requires /sbin/ldconfig professor-is-missing-0.1-3.fc8.noarch requires /bin/sh professor-is-missing-0.1-3.fc8.noarch requires /bin/bash proftpd-1.3.1-3.fc9.ppc requires /bin/sh proftpd-1.3.1-3.fc9.ppc requires /sbin/service proftpd-1.3.1-3.fc9.ppc requires /bin/sh proftpd-1.3.1-3.fc9.ppc requires /sbin/chkconfig proj-4.6.0-1.fc10.ppc requires /sbin/ldconfig proj-4.6.0-1.fc10.ppc64 requires /sbin/ldconfig proj-nad-4.6.0-1.fc10.ppc requires /bin/bash proxychains-3.1-5.fc9.ppc requires /sbin/ldconfig proxychains-3.1-5.fc9.ppc requires /bin/sh proxychains-3.1-5.fc9.ppc64 requires /sbin/ldconfig proxychains-3.1-5.fc9.ppc64 requires /bin/sh proxyknife-1.7-3.fc9.ppc requires /bin/sh proxyknife-1.7-3.fc9.ppc requires /sbin/install-info ps2eps-1.64-4.fc9.ppc requires /usr/bin/perl ps3pf-utils-2.1-2.fc9.ppc requires /bin/sh ps3pf-utils-libs-2.1-2.fc9.ppc requires /sbin/ldconfig ps3pf-utils-libs-2.1-2.fc9.ppc64 requires /sbin/ldconfig psacct-6.3.2-50.fc9.ppc requires /bin/sh psacct-6.3.2-50.fc9.ppc requires /sbin/chkconfig psacct-6.3.2-50.fc9.ppc requires /bin/bash psacct-6.3.2-50.fc9.ppc requires /sbin/install-info pscan-1.3-1.fc9.ppc requires /bin/sh psgml-1.2.5-6.fc7.noarch requires /bin/sh psi-0.11-4.fc9.ppc requires /bin/sh psi-0.11-4.fc9.ppc requires /bin/sh psiconv-0.9.8-1.fc8.ppc requires /sbin/ldconfig psiconv-0.9.8-1.fc8.ppc requires libWand.so.10 psiconv-0.9.8-1.fc8.ppc requires libMagick.so.10 psiconv-0.9.8-1.fc8.ppc64 requires libWand.so.10()(64bit) psiconv-0.9.8-1.fc8.ppc64 requires /sbin/ldconfig psiconv-0.9.8-1.fc8.ppc64 requires libMagick.so.10()(64bit) psiconv-devel-0.9.8-1.fc8.ppc requires /bin/sh psiconv-devel-0.9.8-1.fc8.ppc64 requires /bin/sh pstoedit-3.45-3.fc10.ppc requires /sbin/ldconfig pstoedit-3.45-3.fc10.ppc64 requires /sbin/ldconfig psutils-1.17-28.fc9.ppc requires /usr/bin/perl psutils-1.17-28.fc9.ppc requires /bin/sh pth-2.0.7-6.ppc requires /sbin/ldconfig pth-2.0.7-6.ppc64 requires /sbin/ldconfig pth-devel-2.0.7-6.ppc requires /bin/sh pth-devel-2.0.7-6.ppc64 requires /bin/sh publican-0.33-0.fc9.noarch requires /usr/bin/perl publican-0.33-0.fc9.noarch requires /bin/env publican-0.33-0.fc9.noarch requires /usr/bin/env pulseaudio-0.9.11-0.0.svn20080516.fc10.ppc requires /bin/sh pulseaudio-0.9.11-0.0.svn20080516.fc10.ppc requires /sbin/ldconfig pulseaudio-esound-compat-0.9.11-0.0.svn20080516.fc10.ppc requires /bin/sh pulseaudio-libs-0.9.11-0.0.svn20080516.fc10.ppc requires /sbin/ldconfig pulseaudio-libs-0.9.11-0.0.svn20080516.fc10.ppc64 requires /sbin/ldconfig pulseaudio-libs-glib2-0.9.11-0.0.svn20080516.fc10.ppc requires /sbin/ldconfig pulseaudio-libs-glib2-0.9.11-0.0.svn20080516.fc10.ppc64 requires /sbin/ldconfig pulseaudio-libs-zeroconf-0.9.11-0.0.svn20080516.fc10.ppc requires /sbin/ldconfig pulseaudio-libs-zeroconf-0.9.11-0.0.svn20080516.fc10.ppc64 requires /sbin/ldconfig pulseaudio-utils-0.9.11-0.0.svn20080516.fc10.ppc requires /bin/sh pulseaudio-utils-0.9.11-0.0.svn20080516.fc10.ppc64 requires /bin/sh pungi-1.2.18-1.fc9.noarch requires /usr/bin/python puppet-0.24.4-1.fc9.noarch requires /bin/sh puppet-0.24.4-1.fc9.noarch requires /usr/bin/ruby puppet-0.24.4-1.fc9.noarch requires /bin/bash puppet-server-0.24.4-1.fc9.noarch requires /bin/sh puppet-server-0.24.4-1.fc9.noarch requires /bin/bash puppet-server-0.24.4-1.fc9.noarch requires /usr/bin/ruby pure-ftpd-1.0.21-15.fc9.ppc requires /bin/sh pure-ftpd-1.0.21-15.fc9.ppc requires /usr/bin/python pure-ftpd-1.0.21-15.fc9.ppc requires /usr/bin/perl pure-ftpd-1.0.21-15.fc9.ppc requires /bin/bash pure-ftpd-selinux-1.0.21-15.fc9.ppc requires /bin/sh puretls-0.9-0.2.b5.5jpp.1.fc9.ppc requires /bin/sh puretls-demo-0.9-0.2.b5.5jpp.1.fc9.ppc requires /bin/sh puretls-demo-0.9-0.2.b5.5jpp.1.fc9.ppc requires /usr/bin/perl pvm-3.4.5-9.fc9.ppc requires /bin/csh pvm-3.4.5-9.fc9.ppc requires /bin/sh pvm-3.4.5-9.fc9.ppc requires /bin/sh pvm-gui-3.4.5-9.fc9.ppc requires /bin/csh pvm-gui-3.4.5-9.fc9.ppc requires /bin/sh pwlib-1.10.10-6.fc9.ppc requires /sbin/ldconfig pwlib-1.10.10-6.fc9.ppc64 requires /sbin/ldconfig pwlib-devel-1.10.10-6.fc9.ppc requires /bin/sh pwlib-devel-1.10.10-6.fc9.ppc64 requires /bin/sh pybackpack-0.5.4-2.fc9.noarch requires /usr/bin/python pybliographer-1.2.11-2.fc9.noarch requires /bin/sh pybliographer-1.2.11-2.fc9.noarch requires /bin/sh pybliographer-1.2.11-2.fc9.noarch requires /usr/bin/python pycairo-1.4.12-3.fc10.ppc requires /usr/bin/env pychecker-0.8.17-4.noarch requires /bin/sh pychess-0.8-2.fc9.noarch requires /usr/bin/python pychess-0.8-2.fc9.noarch requires /usr/bin/env pydict-0.3.0-11.fc8.noarch requires /bin/sh pyflakes-0.2.1-3.fc7.noarch requires /usr/bin/python pyflowtools-0.3.3-1.fc9.ppc requires /usr/bin/env pygsl-0.9.1-8.fc9.ppc requires /usr/bin/env pygtk2-2.12.1-6.fc9.ppc requires /usr/bin/env pygtk2-2.12.1-6.fc9.ppc requires /usr/bin/python pygtk2-codegen-2.12.1-6.fc9.ppc requires /bin/sh pygtkglext-1.1.0-4.fc9.ppc requires /usr/bin/env pyicq-t-0.8-4.b.fc9.noarch requires /bin/sh pyicq-t-0.8-4.b.fc9.noarch requires /bin/bash pyicq-t-0.8-4.b.fc9.noarch requires /sbin/chkconfig pyicq-t-0.8-4.b.fc9.noarch requires /usr/bin/env pyicq-t-0.8-4.b.fc9.noarch requires /sbin/service pyjigdo-0.3.0-1.fc10.noarch requires /usr/bin/python pykickstart-1.34-1.fc10.noarch requires /usr/bin/python pylint-0.14.0-1.fc9.noarch requires /usr/bin/python pylint-gui-0.14.0-1.fc9.noarch requires /usr/bin/python pypar2-1.4-1.fc8.noarch requires /bin/sh pypar2-1.4-1.fc8.noarch requires /usr/bin/python pypoker-eval-135.0-1.fc9.ppc requires /sbin/ldconfig pyscript-0.6.1-2.fc9.noarch requires /usr/bin/python python-2.5.1-25.fc9.ppc requires /bin/sh python-2.5.1-25.fc9.ppc requires /usr/bin/python2.5 python-2.5.1-25.fc9.ppc requires /usr/bin/env python-4Suite-XML-1.0.2-3.ppc requires /usr/bin/env python-Coherence-0.5.0-1.fc9.noarch requires /usr/bin/python python-ZSI-2.0-3.fc9.noarch requires /usr/bin/env python-ZSI-2.0-3.fc9.noarch requires /usr/bin/python python-amara-1.2.0.2-2.fc8.noarch requires /usr/bin/python python-bugzilla-0.3-1.fc9.noarch requires /usr/bin/python python-cheetah-2.0.1-2.fc9.ppc requires /usr/bin/python python-clientform-0.2.7-2.fc9.noarch requires /usr/bin/env python-demjson-1.3-2.fc9.noarch requires /usr/bin/python python-devel-2.5.1-25.fc9.ppc requires /bin/sh python-devel-2.5.1-25.fc9.ppc64 requires /bin/sh python-dialog-2.7-7.fc8.noarch requires /usr/bin/env python-docutils-0.4-8.fc9.noarch requires /usr/bin/python python-durus-3.5-3.fc7.ppc requires /usr/bin/python python-exif-1.0.7-4.fc9.noarch requires /bin/bash python-exif-1.0.7-4.fc9.noarch requires /usr/bin/env python-eyed3-0.6.15-1.fc9.noarch requires /usr/bin/env python-formencode-1.0-1.fc9.noarch requires /bin/sh python-formencode-1.0-1.fc9.noarch requires /usr/bin/python python-igraph-0.5-5.fc9.ppc requires /usr/bin/python python-imaging-devel-1.1.6-9.fc9.ppc requires /usr/bin/env python-imaging-devel-1.1.6-9.fc9.ppc requires /usr/bin/python python-imaging-devel-1.1.6-9.fc9.ppc64 requires /usr/bin/env python-imaging-devel-1.1.6-9.fc9.ppc64 requires /usr/bin/python python-inotify-examples-0.7.1-2.fc9.ppc requires /bin/sh python-inotify-examples-0.7.1-2.fc9.ppc requires /usr/bin/env python-kaa-metadata-0.7.3-1.fc9.ppc requires /usr/bin/python python-kid-0.9.6-2.fc8.noarch requires /usr/bin/env python-kiwi-1.9.21-1.fc10.noarch requires /usr/bin/python python-kiwi-docs-1.9.21-1.fc10.noarch requires /usr/bin/env python-libgmail-0.1.8-2.fc9.noarch requires /usr/bin/env python-libgmail-docs-0.3-6.fc9.noarch requires /usr/bin/env python-libs-2.5.1-25.fc9.ppc requires /sbin/ldconfig python-libs-2.5.1-25.fc9.ppc64 requires /sbin/ldconfig python-logilab-common-0.28.0-1.fc9.noarch requires /usr/bin/python python-matplotlib-0.91.2-2.fc9.ppc requires /usr/bin/env python-mechanize-0.1.6-0.2.b.fc9.noarch requires /usr/bin/python python-musicbrainz2-0.5.0-2.fc9.noarch requires /usr/bin/python python-mutagen-1.13-2.fc9.noarch requires /usr/bin/python python-nevow-0.9.29-2.fc9.noarch requires /usr/bin/python 1:python-nltk-0.9.2-1.fc9.noarch requires /usr/bin/env 1:python-nltk-0.9.2-1.fc9.noarch requires /usr/bin/python python-nose-0.10.1-1.fc9.noarch requires /usr/bin/python python-numarray-1.5.2-6.fc9.ppc requires /usr/bin/env python-numarray-1.5.2-6.fc9.ppc requires /bin/sh python-paste-script-1.6.2-2.fc9.noarch requires /usr/bin/env python-paste-script-1.6.2-2.fc9.noarch requires /usr/bin/python python-pp-1.5.3-1.fc9.noarch requires /usr/bin/python python-pyblock-0.31-2.ppc requires /usr/bin/python python-pygments-0.9-2.fc9.noarch requires /usr/bin/python python-pyspf-2.0.3-1.fc8.noarch requires /usr/bin/python python-qpid-0.2-10.fc9.noarch requires /usr/bin/env python-setuptools-0.6c7-2.fc8.noarch requires /usr/bin/python python-setuptools-devel-0.6c7-2.fc8.noarch requires /usr/bin/python python-simpletal-4.1-5.fc7.noarch requires /usr/bin/python python-sqlobject-0.10.1-1.fc10.noarch requires /usr/bin/python python-tag-0.94.1-1.fc10.ppc requires /usr/bin/env python-test-2.5.1-25.fc9.ppc requires /usr/bin/env python-tools-2.5.1-25.fc9.ppc requires /bin/bash python-tools-2.5.1-25.fc9.ppc requires /usr/bin/env python-tools-2.5.1-25.fc9.ppc requires /bin/sh python-tools-2.5.1-25.fc9.ppc requires /usr/bin/python python-tpg-3.1.0-4.fc7.noarch requires /usr/bin/python python-tunepimp-0.5.3-11.fc9.ppc requires /usr/bin/env python-twisted-conch-0.8.0-4.fc9.ppc requires /usr/libexec/twisted-dropin-cache python-twisted-conch-0.8.0-4.fc9.ppc requires /usr/bin/python python-twisted-core-2.5.0-4.fc9.ppc requires /usr/libexec/twisted-dropin-cache python-twisted-core-2.5.0-4.fc9.ppc requires /usr/bin/env python-twisted-core-2.5.0-4.fc9.ppc requires /usr/bin/python python-twisted-lore-0.2.0-6.fc9.ppc requires /usr/libexec/twisted-dropin-cache python-twisted-lore-0.2.0-6.fc9.ppc requires /usr/bin/python python-twisted-mail-0.4.0-4.fc9.ppc requires /usr/libexec/twisted-dropin-cache python-twisted-mail-0.4.0-4.fc9.ppc requires /bin/sh python-twisted-mail-0.4.0-4.fc9.ppc requires /usr/bin/python python-twisted-names-0.4.0-3.fc9.ppc requires /usr/libexec/twisted-dropin-cache python-twisted-news-0.3.0-3.fc9.ppc requires /usr/libexec/twisted-dropin-cache python-twisted-web-0.7.0-3.fc9.ppc requires /usr/libexec/twisted-dropin-cache python-twisted-words-0.5.0-3.fc9.ppc requires /usr/libexec/twisted-dropin-cache python-twisted-words-0.5.0-3.fc9.ppc requires /usr/bin/python python-twyt-0.8-1.fc9.noarch requires /usr/bin/python python-urlgrabber-3.0.0-7.fc10.noarch requires /usr/bin/python python-virtinst-0.300.3-6.fc10.noarch requires /usr/bin/python python-vobject-0.6.0-2.fc9.noarch requires /usr/bin/python python-which-1.1.0-3.fc9.noarch requires /bin/sh pyzor-0.4.0-11.fc7.noarch requires /usr/bin/python q-7.10-3.fc9.ppc requires /bin/sh q-7.10-3.fc9.ppc requires /sbin/install-info q-7.10-3.fc9.ppc requires /sbin/ldconfig q-7.10-3.fc9.ppc requires /bin/sh q-7.10-3.fc9.ppc requires libMagick.so.10 q-7.10-3.fc9.ppc64 requires /bin/sh q-7.10-3.fc9.ppc64 requires /sbin/install-info q-7.10-3.fc9.ppc64 requires libMagick.so.10()(64bit) q-7.10-3.fc9.ppc64 requires /sbin/ldconfig q-7.10-3.fc9.ppc64 requires /bin/sh q-devel-7.10-3.fc9.ppc requires /bin/sh q-devel-7.10-3.fc9.ppc64 requires /bin/sh qa-assistant-0.4.90.5-2.fc6.noarch requires /bin/sh qa-assistant-0.4.90.5-2.fc6.noarch requires /usr/bin/xmlcatalog qa-assistant-0.4.90.5-2.fc6.noarch requires /usr/bin/python qalculate-gtk-0.9.6-4.fc9.ppc requires /bin/sh qalculate-kde-0.9.6-5.fc9.ppc requires /bin/sh qascade-0.1-10.fc9.ppc requires /bin/sh qbanking-2.3.3-3.fc9.ppc requires /sbin/ldconfig qbanking-2.3.3-3.fc9.ppc64 requires /sbin/ldconfig qbanking-devel-2.3.3-3.fc9.ppc requires /bin/sh qbanking-devel-2.3.3-3.fc9.ppc64 requires /bin/sh qca-1.0-10.fc9.ppc requires /sbin/ldconfig qca-1.0-10.fc9.ppc64 requires /sbin/ldconfig qca2-2.0.0-2.fc9.ppc requires /sbin/ldconfig qca2-2.0.0-2.fc9.ppc64 requires /sbin/ldconfig qcad-2.0.5.0-8.fc9.ppc requires /bin/sh qct-1.5-6.fc9.ppc requires /usr/bin/env qct-1.5-6.fc9.ppc requires /usr/bin/python qdbm-1.8.77-3.fc9.ppc requires /sbin/ldconfig qdbm-1.8.77-3.fc9.ppc64 requires /sbin/ldconfig qdbm++-1.8.77-3.fc9.ppc requires /sbin/ldconfig qdbm++-1.8.77-3.fc9.ppc64 requires /sbin/ldconfig qdbm-java-1.8.77-3.fc9.ppc requires /sbin/ldconfig qdbm-java-1.8.77-3.fc9.ppc64 requires /sbin/ldconfig qdbm-perl-1.8.77-3.fc9.ppc requires /usr/bin/perl qemu-0.9.1-7.fc10.ppc requires /bin/sh qemu-0.9.1-7.fc10.ppc requires /sbin/service qemu-0.9.1-7.fc10.ppc requires /bin/sh qemu-0.9.1-7.fc10.ppc requires /sbin/chkconfig qemu-launcher-1.7.4-4.fc9.noarch requires /bin/sh qemu-launcher-1.7.4-4.fc9.noarch requires /usr/bin/perl qfaxreader-0.3.1-9.fc9.3.ppc requires /bin/sh qgis-0.9.1-5.fc9.ppc requires libgeos.so.2 qgis-0.9.1-5.fc9.ppc requires /usr/bin/python qgis-0.9.1-5.fc9.ppc requires /sbin/ldconfig qgis-grass-0.9.1-5.fc9.ppc requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.ppc requires /sbin/ldconfig qhull-2003.1-10.fc9.ppc requires /sbin/ldconfig qhull-2003.1-10.fc9.ppc64 requires /sbin/ldconfig qimageblitz-0.0.4-0.4.svn706674.fc9.ppc requires /sbin/ldconfig qimageblitz-0.0.4-0.4.svn706674.fc9.ppc64 requires /sbin/ldconfig qiv-2.0-9.fc9.ppc requires /bin/sh qjackctl-0.3.1a-6.fc9.ppc requires /bin/sh qmmp-0.1.5-2.fc9.ppc requires /bin/sh qmmp-0.1.5-2.fc9.ppc requires /sbin/ldconfig qof-0.7.5-2.fc9.ppc requires /sbin/ldconfig qof-0.7.5-2.fc9.ppc64 requires /sbin/ldconfig qpxtool-0.6.1-9.fc9.ppc requires /sbin/ldconfig qpxtool-0.6.1-9.fc9.ppc64 requires /sbin/ldconfig qscintilla-2.2-1.fc10.ppc requires /sbin/ldconfig qscintilla-2.2-1.fc10.ppc64 requires /sbin/ldconfig qstars-0.4-6.fc9.ppc requires /bin/sh qstars-xscreensaver-0.4-6.fc9.ppc requires /bin/sh qsynth-0.2.5-7.fc9.ppc requires /bin/sh 1:qt-4.4.0-3.fc10.ppc requires /sbin/ldconfig 1:qt-4.4.0-3.fc10.ppc requires /bin/bash 1:qt-4.4.0-3.fc10.ppc64 requires /sbin/ldconfig 1:qt-4.4.0-3.fc10.ppc64 requires /bin/bash 1:qt-devel-4.4.0-3.fc10.ppc requires /bin/sh 1:qt-devel-4.4.0-3.fc10.ppc requires /bin/bash 1:qt-devel-4.4.0-3.fc10.ppc64 requires /bin/sh 1:qt-devel-4.4.0-3.fc10.ppc64 requires /bin/bash 1:qt-doc-4.4.0-3.fc10.ppc requires /bin/bash qt-qsa-1.1.5-5.fc9.ppc requires /sbin/ldconfig qt-qsa-1.1.5-5.fc9.ppc64 requires /sbin/ldconfig qt-recordmydesktop-0.3.7-1.fc9.noarch requires /usr/bin/python 1:qt-x11-4.4.0-3.fc10.ppc requires /bin/sh 1:qt-x11-4.4.0-3.fc10.ppc requires /bin/bash 1:qt-x11-4.4.0-3.fc10.ppc64 requires /bin/sh 1:qt-x11-4.4.0-3.fc10.ppc64 requires /bin/bash qt3-3.3.8b-12.fc9.ppc requires /etc/ld.so.conf.d qt3-3.3.8b-12.fc9.ppc requires /sbin/ldconfig qt3-3.3.8b-12.fc9.ppc64 requires /etc/ld.so.conf.d qt3-3.3.8b-12.fc9.ppc64 requires /sbin/ldconfig qt3-devel-3.3.8b-12.fc9.ppc requires /usr/bin/perl qt3-devel-3.3.8b-12.fc9.ppc64 requires /usr/bin/perl qtpfsgui-1.9.2-1.fc10.ppc requires /bin/sh quagga-0.99.9-6.fc9.ppc requires /bin/sh quagga-0.99.9-6.fc9.ppc requires /sbin/install-info quagga-0.99.9-6.fc9.ppc requires /bin/bash quagga-contrib-0.99.9-6.fc9.ppc requires /usr/bin/perl quake3-1.34-0.9.rc4.fc9.ppc requires /bin/bash quake3-demo-1.34-0.9.rc4.fc9.ppc requires /bin/sh quake3-demo-1.34-0.9.rc4.fc9.ppc requires /bin/bash quarry-0.2.0-3.fc9.ppc requires /bin/sh qucs-0.0.14-1.fc9.ppc requires /usr/bin/perl qucs-0.0.14-1.fc9.ppc requires /bin/sh quesa-1.8-1.fc9.ppc requires /sbin/ldconfig quesa-1.8-1.fc9.ppc64 requires /sbin/ldconfig quesoglc-0.7.1-1.fc10.ppc requires /sbin/ldconfig quesoglc-0.7.1-1.fc10.ppc64 requires /sbin/ldconfig queuegraph-1.1-3.fc9.noarch requires /usr/bin/perl queuegraph-1.1-3.fc9.noarch requires /bin/sh queuegraph-selinux-1.1-3.fc9.noarch requires /usr/sbin/semodule queuegraph-selinux-1.1-3.fc9.noarch requires /sbin/fixfiles queuegraph-selinux-1.1-3.fc9.noarch requires /bin/sh queuegraph-selinux-1.1-3.fc9.noarch requires /sbin/restorecon quilt-0.46-5.fc9.ppc requires /usr/bin/perl quilt-0.46-5.fc9.ppc requires /bin/bash quodlibet-1.0-3.fc9.ppc requires /usr/bin/env qwt-5.0.2-6.fc9.ppc requires /sbin/ldconfig qwt-5.0.2-6.fc9.ppc64 requires /sbin/ldconfig qwtplot3d-0.2.7-6.fc9.ppc requires /sbin/ldconfig qwtplot3d-0.2.7-6.fc9.ppc64 requires /sbin/ldconfig qwtplot3d-qt4-0.2.7-6.fc9.ppc requires /sbin/ldconfig qwtplot3d-qt4-0.2.7-6.fc9.ppc64 requires /sbin/ldconfig radiusclient-ng-0.5.6-3.fc9.ppc requires /sbin/ldconfig radiusclient-ng-0.5.6-3.fc9.ppc64 requires /sbin/ldconfig radiusclient-ng-utils-0.5.6-3.fc9.ppc requires /bin/sh radvd-1.1-3.fc10.ppc requires /usr/sbin/userdel radvd-1.1-3.fc10.ppc requires /bin/sh radvd-1.1-3.fc10.ppc requires /usr/sbin/useradd radvd-1.1-3.fc10.ppc requires /bin/sh rafkill-1.2.2-7.fc9.ppc requires /bin/sh raidem-0.3.1-8.fc9.ppc requires /bin/sh raptor-1.4.16-2.fc9.ppc requires /sbin/ldconfig raptor-1.4.16-2.fc9.ppc64 requires /sbin/ldconfig raptor-devel-1.4.16-2.fc9.ppc requires /bin/sh raptor-devel-1.4.16-2.fc9.ppc64 requires /bin/sh rarian-0.8.0-1.fc9.ppc requires /sbin/ldconfig rarian-0.8.0-1.fc9.ppc64 requires /sbin/ldconfig rarian-compat-0.8.0-1.fc9.ppc requires /bin/sh rarian-compat-0.8.0-1.fc9.ppc requires /bin/bash rarian-compat-0.8.0-1.fc9.ppc requires /bin/sh rarpd-ss981107-26.1.fc9.ppc requires /bin/sh rarpd-ss981107-26.1.fc9.ppc requires /bin/bash rarpd-ss981107-26.1.fc9.ppc requires /sbin/chkconfig rasqal-0.9.15-1.fc9.ppc requires /sbin/ldconfig rasqal-0.9.15-1.fc9.ppc64 requires /sbin/ldconfig rasqal-devel-0.9.15-1.fc9.ppc requires /bin/sh rasqal-devel-0.9.15-1.fc9.ppc64 requires /bin/sh ratpoison-1.4.1-2.fc9.ppc requires /bin/sh ratpoison-1.4.1-2.fc9.ppc requires /usr/bin/perl ratpoison-1.4.1-2.fc9.ppc requires /bin/bash ratpoison-1.4.1-2.fc9.ppc requires /sbin/install-info ratpoison-1.4.1-2.fc9.ppc requires /bin/sh rawstudio-1.0-1.fc10.ppc requires /bin/sh raydium-1.2-8.fc9.ppc requires /sbin/ldconfig raydium-1.2-8.fc9.ppc64 requires /sbin/ldconfig rb_libtorrent-0.12.1-1.fc9.ppc requires /sbin/ldconfig rb_libtorrent-0.12.1-1.fc9.ppc64 requires /sbin/ldconfig rblcheck-1.5-15.fc9.ppc requires /bin/sh rbldnsd-0.996b-1.fc9.ppc requires /bin/sh rbldnsd-0.996b-1.fc9.ppc requires /bin/bash rbldnsd-0.996b-1.fc9.ppc requires /sbin/chkconfig rdiff-backup-1.0.5-7.fc9.ppc requires /usr/bin/python 1:readahead-1.4.2-5.fc9.ppc requires /bin/sh 1:readahead-1.4.2-5.fc9.ppc requires /bin/gawk 1:readahead-1.4.2-5.fc9.ppc requires /sbin/service 1:readahead-1.4.2-5.fc9.ppc requires /bin/bash 1:readahead-1.4.2-5.fc9.ppc requires /bin/sh 1:readahead-1.4.2-5.fc9.ppc requires /sbin/chkconfig readline-5.2-13.fc9.ppc requires /bin/sh readline-5.2-13.fc9.ppc requires /sbin/ldconfig readline-5.2-13.fc9.ppc requires /sbin/install-info readline-5.2-13.fc9.ppc64 requires /bin/sh readline-5.2-13.fc9.ppc64 requires /sbin/ldconfig readline-5.2-13.fc9.ppc64 requires /sbin/install-info readline-devel-5.2-13.fc9.ppc requires /bin/sh readline-devel-5.2-13.fc9.ppc requires /sbin/install-info readline-devel-5.2-13.fc9.ppc64 requires /sbin/install-info readline-devel-5.2-13.fc9.ppc64 requires /bin/sh recode-3.6-26.fc9.ppc requires /bin/sh recode-3.6-26.fc9.ppc requires /sbin/ldconfig recode-3.6-26.fc9.ppc requires /sbin/install-info recode-3.6-26.fc9.ppc64 requires /bin/sh recode-3.6-26.fc9.ppc64 requires /sbin/ldconfig recode-3.6-26.fc9.ppc64 requires /sbin/install-info redet-8.23-3.fc9.noarch requires /bin/sh redet-8.23-3.fc9.noarch requires /bin/sh redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/tty redhat-lsb-3.1-19.fc8.ppc requires /bin/cp redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/uniq redhat-lsb-3.1-19.fc8.ppc requires /bin/dd redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/pax redhat-lsb-3.1-19.fc8.ppc requires /bin/stty redhat-lsb-3.1-19.fc8.ppc requires /bin/ls redhat-lsb-3.1-19.fc8.ppc requires /bin/echo redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/tee redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/id redhat-lsb-3.1-19.fc8.ppc requires /bin/gzip redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/ipcrm redhat-lsb-3.1-19.fc8.ppc requires /bin/mknod redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/chfn redhat-lsb-3.1-19.fc8.ppc requires /bin/gettext redhat-lsb-3.1-19.fc8.ppc requires /bin/more redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/nohup redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/patch redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/make redhat-lsb-3.1-19.fc8.ppc requires /bin/touch redhat-lsb-3.1-19.fc8.ppc requires /bin/pwd redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/mkfifo redhat-lsb-3.1-19.fc8.ppc requires /bin/mv redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/join redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/fold redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/col redhat-lsb-3.1-19.fc8.ppc requires /bin/tar redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/msgfmt redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/tsort redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/crontab redhat-lsb-3.1-19.fc8.ppc requires /usr/lib/lsb/remove_initd redhat-lsb-3.1-19.fc8.ppc requires /bin/gunzip redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/file redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/tail redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/chsh redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/csplit redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/find redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/at redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/od redhat-lsb-3.1-19.fc8.ppc requires /bin/mailx redhat-lsb-3.1-19.fc8.ppc requires /bin/hostname redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/ar redhat-lsb-3.1-19.fc8.ppc requires /bin/chgrp redhat-lsb-3.1-19.fc8.ppc requires /bin/true redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/wc redhat-lsb-3.1-19.fc8.ppc requires /bin/mount redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/md5sum redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/du redhat-lsb-3.1-19.fc8.ppc requires /bin/egrep redhat-lsb-3.1-19.fc8.ppc requires /bin/rm redhat-lsb-3.1-19.fc8.ppc requires /bin/basename redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/locale redhat-lsb-3.1-19.fc8.ppc requires /bin/df redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/paste redhat-lsb-3.1-19.fc8.ppc requires /usr/sbin/groupadd redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/killall redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/dirname redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/localedef redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/head redhat-lsb-3.1-19.fc8.ppc requires /bin/dmesg redhat-lsb-3.1-19.fc8.ppc requires /bin/sed redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/pr redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/logname redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/batch redhat-lsb-3.1-19.fc8.ppc requires /bin/awk redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/tr redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/bc redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/cmp redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/passwd redhat-lsb-3.1-19.fc8.ppc requires /bin/date redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/expand redhat-lsb-3.1-19.fc8.ppc requires /bin/chmod redhat-lsb-3.1-19.fc8.ppc requires /bin/rmdir redhat-lsb-3.1-19.fc8.ppc requires /bin/sleep redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/newgrp redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/expr redhat-lsb-3.1-19.fc8.ppc requires /bin/uname redhat-lsb-3.1-19.fc8.ppc requires /bin/ln redhat-lsb-3.1-19.fc8.ppc requires /bin/nice redhat-lsb-3.1-19.fc8.ppc requires /bin/cpio redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/install redhat-lsb-3.1-19.fc8.ppc requires /bin/su redhat-lsb-3.1-19.fc8.ppc requires /sbin/pidof redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/pathchk redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/groups redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/ipcs redhat-lsb-3.1-19.fc8.ppc requires /bin/bash redhat-lsb-3.1-19.fc8.ppc requires /bin/env redhat-lsb-3.1-19.fc8.ppc requires /bin/fgrep redhat-lsb-3.1-19.fc8.ppc requires /bin/grep redhat-lsb-3.1-19.fc8.ppc requires /bin/sort redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/iconv redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/split redhat-lsb-3.1-19.fc8.ppc requires /usr/sbin/groupdel redhat-lsb-3.1-19.fc8.ppc requires /bin/false redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/cksum redhat-lsb-3.1-19.fc8.ppc requires /bin/ed redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/man redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/logger redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/m4 redhat-lsb-3.1-19.fc8.ppc requires /bin/ps redhat-lsb-3.1-19.fc8.ppc requires /bin/cat redhat-lsb-3.1-19.fc8.ppc requires /usr/sbin/groupmod redhat-lsb-3.1-19.fc8.ppc requires /bin/cut redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/gencat redhat-lsb-3.1-19.fc8.ppc requires /usr/lib/lsb/install_initd redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/strip redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/nl redhat-lsb-3.1-19.fc8.ppc requires /sbin/shutdown redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/xargs redhat-lsb-3.1-19.fc8.ppc requires /bin/mkdir redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/time redhat-lsb-3.1-19.fc8.ppc requires /usr/sbin/userdel redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/unexpand redhat-lsb-3.1-19.fc8.ppc requires /bin/umount redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/getconf redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/diff redhat-lsb-3.1-19.fc8.ppc requires /usr/sbin/useradd redhat-lsb-3.1-19.fc8.ppc requires /sbin/fuser redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/printf redhat-lsb-3.1-19.fc8.ppc requires /usr/sbin/usermod redhat-lsb-3.1-19.fc8.ppc requires /bin/sh redhat-lsb-3.1-19.fc8.ppc requires /bin/kill redhat-lsb-3.1-19.fc8.ppc requires /bin/sync redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/renice redhat-lsb-3.1-19.fc8.ppc requires /bin/mktemp redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/test redhat-lsb-3.1-19.fc8.ppc requires /usr/bin/comm redhat-lsb-3.1-19.fc8.ppc requires /bin/chown redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/tty redhat-lsb-3.1-19.fc8.ppc64 requires /bin/cp redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/uniq redhat-lsb-3.1-19.fc8.ppc64 requires /bin/dd redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/pax redhat-lsb-3.1-19.fc8.ppc64 requires /bin/stty redhat-lsb-3.1-19.fc8.ppc64 requires /bin/ls redhat-lsb-3.1-19.fc8.ppc64 requires /bin/echo redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/tee redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/id redhat-lsb-3.1-19.fc8.ppc64 requires /bin/gzip redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/ipcrm redhat-lsb-3.1-19.fc8.ppc64 requires /bin/mknod redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/chfn redhat-lsb-3.1-19.fc8.ppc64 requires /bin/gettext redhat-lsb-3.1-19.fc8.ppc64 requires /bin/more redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/nohup redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/patch redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/make redhat-lsb-3.1-19.fc8.ppc64 requires /bin/touch redhat-lsb-3.1-19.fc8.ppc64 requires /bin/pwd redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/mkfifo redhat-lsb-3.1-19.fc8.ppc64 requires /usr/lib64/lsb/remove_initd redhat-lsb-3.1-19.fc8.ppc64 requires /bin/mv redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/join redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/fold redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/col redhat-lsb-3.1-19.fc8.ppc64 requires /bin/tar redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/msgfmt redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/tsort redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/crontab redhat-lsb-3.1-19.fc8.ppc64 requires /bin/gunzip redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/file redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/tail redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/chsh redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/csplit redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/find redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/at redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/od redhat-lsb-3.1-19.fc8.ppc64 requires /bin/mailx redhat-lsb-3.1-19.fc8.ppc64 requires /bin/hostname redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/ar redhat-lsb-3.1-19.fc8.ppc64 requires /bin/chgrp redhat-lsb-3.1-19.fc8.ppc64 requires /bin/true redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/wc redhat-lsb-3.1-19.fc8.ppc64 requires /bin/mount redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/md5sum redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/du redhat-lsb-3.1-19.fc8.ppc64 requires /bin/egrep redhat-lsb-3.1-19.fc8.ppc64 requires /bin/rm redhat-lsb-3.1-19.fc8.ppc64 requires /bin/basename redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/locale redhat-lsb-3.1-19.fc8.ppc64 requires /bin/df redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/paste redhat-lsb-3.1-19.fc8.ppc64 requires /usr/sbin/groupadd redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/killall redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/dirname redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/localedef redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/head redhat-lsb-3.1-19.fc8.ppc64 requires /bin/dmesg redhat-lsb-3.1-19.fc8.ppc64 requires /bin/sed redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/pr redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/logname redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/batch redhat-lsb-3.1-19.fc8.ppc64 requires /bin/awk redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/tr redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/bc redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/cmp redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/passwd redhat-lsb-3.1-19.fc8.ppc64 requires /bin/date redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/expand redhat-lsb-3.1-19.fc8.ppc64 requires /bin/chmod redhat-lsb-3.1-19.fc8.ppc64 requires /usr/lib64/lsb/install_initd redhat-lsb-3.1-19.fc8.ppc64 requires /bin/rmdir redhat-lsb-3.1-19.fc8.ppc64 requires /bin/sleep redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/newgrp redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/expr redhat-lsb-3.1-19.fc8.ppc64 requires /bin/uname redhat-lsb-3.1-19.fc8.ppc64 requires /bin/ln redhat-lsb-3.1-19.fc8.ppc64 requires /bin/nice redhat-lsb-3.1-19.fc8.ppc64 requires /bin/cpio redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/install redhat-lsb-3.1-19.fc8.ppc64 requires /bin/su redhat-lsb-3.1-19.fc8.ppc64 requires /sbin/pidof redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/pathchk redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/groups redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/ipcs redhat-lsb-3.1-19.fc8.ppc64 requires /bin/bash redhat-lsb-3.1-19.fc8.ppc64 requires /bin/env redhat-lsb-3.1-19.fc8.ppc64 requires /bin/fgrep redhat-lsb-3.1-19.fc8.ppc64 requires /bin/grep redhat-lsb-3.1-19.fc8.ppc64 requires /bin/sort redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/iconv redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/split redhat-lsb-3.1-19.fc8.ppc64 requires /usr/sbin/groupdel redhat-lsb-3.1-19.fc8.ppc64 requires /bin/false redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/cksum redhat-lsb-3.1-19.fc8.ppc64 requires /bin/ed redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/man redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/logger redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/m4 redhat-lsb-3.1-19.fc8.ppc64 requires /bin/ps redhat-lsb-3.1-19.fc8.ppc64 requires /bin/cat redhat-lsb-3.1-19.fc8.ppc64 requires /usr/sbin/groupmod redhat-lsb-3.1-19.fc8.ppc64 requires /bin/cut redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/gencat redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/strip redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/nl redhat-lsb-3.1-19.fc8.ppc64 requires /sbin/shutdown redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/xargs redhat-lsb-3.1-19.fc8.ppc64 requires /bin/mkdir redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/time redhat-lsb-3.1-19.fc8.ppc64 requires /usr/sbin/userdel redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/unexpand redhat-lsb-3.1-19.fc8.ppc64 requires /bin/umount redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/getconf redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/diff redhat-lsb-3.1-19.fc8.ppc64 requires /usr/sbin/useradd redhat-lsb-3.1-19.fc8.ppc64 requires /sbin/fuser redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/printf redhat-lsb-3.1-19.fc8.ppc64 requires /usr/sbin/usermod redhat-lsb-3.1-19.fc8.ppc64 requires /bin/sh redhat-lsb-3.1-19.fc8.ppc64 requires /bin/kill redhat-lsb-3.1-19.fc8.ppc64 requires /bin/sync redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/renice redhat-lsb-3.1-19.fc8.ppc64 requires /bin/mktemp redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/test redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/comm redhat-lsb-3.1-19.fc8.ppc64 requires /bin/chown redhat-menus-8.9.11-3.fc9.noarch requires /bin/sh redhat-rpm-config-9.0.3-1.fc10.noarch requires /usr/bin/perl redhat-rpm-config-9.0.3-1.fc10.noarch requires /bin/bash redhat-rpm-config-9.0.3-1.fc10.noarch requires /bin/sh redland-1.0.7-1.fc9.ppc requires /sbin/ldconfig redland-1.0.7-1.fc9.ppc64 requires /sbin/ldconfig redland-devel-1.0.7-1.fc9.ppc requires /bin/sh redland-devel-1.0.7-1.fc9.ppc64 requires /bin/sh redmode-1.0-2.fc9.noarch requires /bin/bash referencer-1.1.2-1.fc10.ppc requires /bin/sh regexp-1.5-2jpp.1.fc9.ppc requires /bin/sh regexp-javadoc-1.5-2jpp.1.fc9.ppc requires /bin/sh regexp-javadoc-1.5-2jpp.1.fc9.ppc requires /bin/rm regexp-javadoc-1.5-2jpp.1.fc9.ppc requires /bin/ln regexxer-0.9-3.fc9.ppc requires /bin/sh rekall-2.4.6-4.fc9.ppc requires /bin/sh rekall-2.4.6-4.fc9.ppc requires /bin/sh rekall-2.4.6-4.fc9.ppc64 requires /bin/sh rekall-2.4.6-4.fc9.ppc64 requires /bin/sh rekall-extra-2.4.6-4.fc9.ppc requires /sbin/ldconfig rekall-extra-2.4.6-4.fc9.ppc64 requires /sbin/ldconfig rekall-mysql-2.4.6-4.fc9.ppc requires /sbin/ldconfig rekall-mysql-2.4.6-4.fc9.ppc64 requires /sbin/ldconfig rekall-odbc-2.4.6-4.fc9.ppc requires /sbin/ldconfig rekall-odbc-2.4.6-4.fc9.ppc64 requires /sbin/ldconfig rekall-postgresql-2.4.6-4.fc9.ppc requires /sbin/ldconfig rekall-postgresql-2.4.6-4.fc9.ppc64 requires /sbin/ldconfig rekall-python-2.4.6-4.fc9.ppc requires /sbin/ldconfig rekall-python-2.4.6-4.fc9.ppc64 requires /sbin/ldconfig rekall-sqlite-2.4.6-4.fc9.ppc requires /sbin/ldconfig rekall-sqlite-2.4.6-4.fc9.ppc64 requires /sbin/ldconfig remctl-2.11-6.fc9.ppc requires /sbin/ldconfig remctl-2.11-6.fc9.ppc64 requires /sbin/ldconfig remind-03.01.04-1.fc9.ppc requires /usr/bin/perl remind-03.01.04-1.fc9.ppc requires /bin/sh remind-gui-03.01.04-1.fc9.ppc requires /bin/sh renrot-0.25-4.fc9.noarch requires /usr/bin/perl renrot-0.25-4.fc9.noarch requires /bin/sh repoman-0.9-3.fc8.noarch requires /bin/sh repoman-0.9-3.fc8.noarch requires /usr/bin/env repoview-0.6.2-1.fc9.noarch requires /usr/bin/python resapplet-0.1.1-7.fc9.ppc requires /bin/sh revelation-0.4.11-4.1.ppc requires /bin/sh revelation-0.4.11-4.1.ppc requires /usr/bin/env rgmanager-2.0.23-3.fc9.ppc requires /bin/sh rgmanager-2.0.23-3.fc9.ppc requires /sbin/findfs rgmanager-2.0.23-3.fc9.ppc requires /bin/bash rgmanager-2.0.23-3.fc9.ppc requires /bin/sh rgmanager-2.0.23-3.fc9.ppc requires /sbin/chkconfig rhpl-0.215-3.ppc requires /usr/bin/python rhythmbox-0.11.5-9.fc9.ppc requires /bin/sh rhythmbox-0.11.5-9.fc9.ppc requires libtotem-plparser.so.10 rhythmbox-0.11.5-9.fc9.ppc64 requires /bin/sh rhythmbox-0.11.5-9.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) rinetd-0.62-7.fc9.ppc requires /bin/sh rinetd-0.62-7.fc9.ppc requires /sbin/chkconfig rinetd-0.62-7.fc9.ppc requires /bin/sh rinetd-0.62-7.fc9.ppc requires /sbin/service rkhunter-1.3.2-2.fc9.noarch requires /usr/bin/perl rkhunter-1.3.2-2.fc9.noarch requires /bin/sh rkward-0.5.0b-2.fc10.ppc requires /bin/sh rkward-0.5.0b-2.fc10.ppc requires /bin/sh rlog-1.3.7-6.fc9.ppc requires /sbin/ldconfig rlog-1.3.7-6.fc9.ppc64 requires /sbin/ldconfig 1:rng-utils-2.0-1.15.1.fc9.ppc requires /sbin/chkconfig 1:rng-utils-2.0-1.15.1.fc9.ppc requires /sbin/service roadstencil-fonts-1.0-2.fc10.noarch requires /bin/sh rogue-5.4.5-2.fc9.ppc requires /bin/sh rosegarden4-1.6.1-2.fc9.ppc requires /bin/sh rosegarden4-1.6.1-2.fc9.ppc requires /bin/bash rott-registered-1.0-5.fc9.ppc requires /bin/sh rott-registered-1.0-5.fc9.ppc requires /bin/bash rott-shareware-1.0-5.fc9.ppc requires /bin/sh rott-shareware-1.0-5.fc9.ppc requires /bin/bash roundcubemail-0.1-1.fc9.noarch requires /bin/sh roundup-1.4.4-1.fc9.noarch requires /bin/sh roundup-1.4.4-1.fc9.noarch requires /bin/bash roundup-1.4.4-1.fc9.noarch requires /sbin/chkconfig roundup-1.4.4-1.fc9.noarch requires /usr/bin/env roundup-1.4.4-1.fc9.noarch requires /usr/bin/python roundup-1.4.4-1.fc9.noarch requires /sbin/service roxterm-1.11.1-1.fc9.ppc requires /bin/sh rp-pppoe-3.8-3.fc9.ppc requires /bin/bash rp-pppoe-3.8-3.fc9.ppc requires /bin/sh rpc2-2.7-1.fc10.ppc requires /sbin/ldconfig rpc2-2.7-1.fc10.ppc64 requires /sbin/ldconfig rpcbind-0.1.4-14.fc9.ppc requires /usr/sbin/userdel rpcbind-0.1.4-14.fc9.ppc requires /bin/sh rpcbind-0.1.4-14.fc9.ppc requires /usr/sbin/groupadd rpcbind-0.1.4-14.fc9.ppc requires /usr/sbin/useradd rpcbind-0.1.4-14.fc9.ppc requires /bin/sh rpcbind-0.1.4-14.fc9.ppc requires /usr/sbin/groupdel rpcbind-0.1.4-14.fc9.ppc requires /sbin/chkconfig rpl-1.5.3-4.fc6.noarch requires /usr/bin/env rpm-4.4.2.3-2.fc9.ppc requires /bin/sh rpm-4.4.2.3-2.fc9.ppc requires /bin/bash rpm-4.4.2.3-2.fc9.ppc requires /bin/sh rpm-build-4.4.2.3-2.fc9.ppc requires /bin/bash rpm-build-4.4.2.3-2.fc9.ppc requires /bin/sh rpm-build-4.4.2.3-2.fc9.ppc requires /usr/bin/perl rpm-libs-4.4.2.3-2.fc9.ppc requires /sbin/ldconfig rpm-libs-4.4.2.3-2.fc9.ppc64 requires /sbin/ldconfig rpmdevtools-6.6-1.fc9.noarch requires /usr/bin/python rpmdevtools-6.6-1.fc9.noarch requires /bin/bash rpmdevtools-6.6-1.fc9.noarch requires /bin/sh rpmdevtools-6.6-1.fc9.noarch requires /usr/bin/perl rpmlint-0.82-3.fc9.noarch requires /bin/sh rpmlint-0.82-3.fc9.noarch requires /usr/bin/python rpmrebuild-2.2.2-1.fc10.noarch requires /bin/sh rpmrebuild-2.2.2-1.fc10.noarch requires /bin/bash rpmrebuild-2.2.2-1.fc10.noarch requires /bin/sh rpy-1.0.2-1.fc10.ppc requires /bin/sh rpy-1.0.2-1.fc10.ppc requires /sbin/install-info rrdtool-1.3-0.14.beta4.fc10.ppc requires /sbin/ldconfig rrdtool-1.3-0.14.beta4.fc10.ppc64 requires /sbin/ldconfig rrdtool-tcl-1.3-0.14.beta4.fc10.ppc requires /bin/sh rsh-server-0.17-50.fc10.ppc requires /etc/pam.d/system-auth rsibreak-0.8.0-5.fc9.ppc requires /bin/sh rsnapshot-1.3.0-1.fc8.noarch requires /bin/sh rsnapshot-1.3.0-1.fc8.noarch requires /usr/bin/perl rss-glx-0.8.1.p-19.fc9.ppc requires /usr/bin/env rss-glx-xscreensaver-0.8.1.p-19.fc9.ppc requires /bin/sh rss2email-2.62-1.1.noarch requires /bin/sh rss2email-2.62-1.1.noarch requires /usr/bin/python rsyslog-3.16.1-1.fc10.ppc requires /bin/sh rsyslog-3.16.1-1.fc10.ppc requires /sbin/service rsyslog-3.16.1-1.fc10.ppc requires /bin/bash rsyslog-3.16.1-1.fc10.ppc requires /bin/sh rsyslog-3.16.1-1.fc10.ppc requires /sbin/chkconfig rt3-3.6.6-5.fc9.noarch requires /usr/bin/perl rt3-3.6.6-5.fc9.noarch requires /bin/rm rt3-3.6.6-5.fc9.noarch requires /bin/sh rt3-mailgate-3.6.6-5.fc9.noarch requires /usr/bin/perl rubberband-1.0.1-1.fc9.ppc requires /sbin/ldconfig rubberband-1.0.1-1.fc9.ppc64 requires /sbin/ldconfig ruby-1.8.6.114-1.fc9.ppc requires /usr/bin/ruby ruby-cairo-1.5.1-1.fc9.ppc requires /usr/bin/env ruby-gettext-package-1.90.0-1.fc9.noarch requires /usr/bin/ruby ruby-gettext-package-doc-1.90.0-1.fc9.noarch requires /usr/bin/ruby ruby-gettext-package-doc-1.90.0-1.fc9.noarch requires /bin/sh ruby-gettext-package-doc-1.90.0-1.fc9.noarch requires /usr/bin/env ruby-gtk2-0.16.0-28.fc9.ppc requires /usr/bin/env ruby-hyperestraier-1.4.13-2.fc9.ppc requires /usr/bin/ruby ruby-irb-1.8.6.114-1.fc9.ppc requires /usr/bin/ruby ruby-libglade2-0.16.0-28.fc9.ppc requires /usr/bin/env ruby-libs-1.8.6.114-1.fc9.ppc requires /sbin/ldconfig ruby-libs-1.8.6.114-1.fc9.ppc64 requires /sbin/ldconfig ruby-panelapplet2-0.16.0-28.fc9.ppc requires /usr/bin/env ruby-panelapplet2-0.16.0-28.fc9.ppc requires /usr/bin/ruby ruby-poppler-0.16.0-28.fc9.ppc requires /usr/bin/env ruby-qdbm-1.8.77-3.fc9.ppc requires /usr/bin/ruby ruby-racc-1.4.5-2.fc6.noarch requires /usr/bin/ruby ruby-rdoc-1.8.6.114-1.fc9.ppc requires /usr/bin/ruby ruby-ri-1.8.6.114-1.fc9.ppc requires /usr/bin/ruby ruby-rsvg-0.16.0-28.fc9.ppc requires /usr/bin/env ruby-tcltk-1.8.6.114-1.fc9.ppc requires /usr/bin/env ruby-vte-0.16.0-28.fc9.ppc requires /usr/bin/env rubygem-activeldap-0.10.0-10.fc10.noarch requires /usr/bin/ruby rubygem-activeldap-0.10.0-10.fc10.noarch requires /usr/bin/env rubygem-activeldap-0.10.0-10.fc10.noarch requires /bin/sh rubygem-daemons-1.0.7-2.fc8.noarch requires /usr/bin/env rubygem-gem2rpm-0.5.3-1.fc10.noarch requires /usr/bin/env rubygem-gem_plugin-0.2.2-2.fc8.noarch requires /usr/bin/ruby rubygem-hoe-1.5.1-6.fc10.noarch requires /usr/bin/env rubygem-mongrel-1.0.1-6.fc9.ppc requires /usr/bin/ruby rubygem-mongrel-1.0.1-6.fc9.ppc requires /usr/bin/env rubygem-rails-2.0.2-2.fc9.noarch requires /usr/bin/ruby rubygem-rails-2.0.2-2.fc9.noarch requires /usr/bin/env rubygem-rake-0.8.1-2.fc10.noarch requires /usr/bin/ruby rubygem-rubyforge-0.4.5-2.fc10.noarch requires /usr/bin/env rubygem-zoom-0.4.1-2.fc9.3.ppc requires /usr/bin/ruby rubygems-0.9.4-1.fc8.noarch requires /usr/bin/ruby rubyripper-0.5.0-2.fc9.noarch requires /usr/bin/env rubyripper-gui-0.5.0-2.fc9.noarch requires /usr/bin/env rudecgi-5.1.0-2.fc9.ppc requires /sbin/ldconfig rudecgi-5.1.0-2.fc9.ppc64 requires /sbin/ldconfig rudeconfig-5.0.5-1.fc7.ppc requires /sbin/ldconfig rudeconfig-5.0.5-1.fc7.ppc64 requires /sbin/ldconfig rudesocket-1.3.0-2.fc9.ppc requires /sbin/ldconfig rudesocket-1.3.0-2.fc9.ppc64 requires /sbin/ldconfig rusers-server-0.17-53.fc9.ppc requires /bin/sh rusers-server-0.17-53.fc9.ppc requires /bin/bash rusers-server-0.17-53.fc9.ppc requires /sbin/chkconfig rusers-server-0.17-53.fc9.ppc requires /bin/sh rvm-1.15-1.fc10.ppc requires /sbin/ldconfig rvm-1.15-1.fc10.ppc64 requires /sbin/ldconfig rwall-server-0.17-28.fc9.ppc requires /bin/sh rwall-server-0.17-28.fc9.ppc requires /etc/init.d rwall-server-0.17-28.fc9.ppc requires /sbin/chkconfig rwall-server-0.17-28.fc9.ppc requires /bin/sh rwho-0.17-29.fc9.ppc requires /bin/sh rwho-0.17-29.fc9.ppc requires /sbin/chkconfig rwho-0.17-29.fc9.ppc requires /bin/sh rwho-0.17-29.fc9.ppc requires /etc/init.d rxvt-2.7.10-15.fc9.ppc requires /bin/sh sabayon-2.22.0-3.fc10.ppc requires /usr/bin/env sabayon-2.22.0-3.fc10.ppc requires /bin/sh sabayon-apply-2.22.0-3.fc10.ppc requires /bin/bash sabayon-apply-2.22.0-3.fc10.ppc requires /usr/bin/env safekeep-common-1.0.3-2.fc9.noarch requires /usr/bin/python safekeep-server-1.0.3-2.fc9.noarch requires /bin/sh safekeep-server-1.0.3-2.fc9.noarch requires /usr/sbin/groupadd safekeep-server-1.0.3-2.fc9.noarch requires /usr/sbin/useradd safekeep-server-1.0.3-2.fc9.noarch requires /bin/sh sagator-1.0.0-1.fc9.noarch requires /bin/sh sagator-1.0.0-1.fc9.noarch requires /sbin/chkconfig sagator-1.0.0-1.fc9.noarch requires /usr/bin/python2 sagator-1.0.0-1.fc9.noarch requires /bin/sh sagator-1.0.0-1.fc9.noarch requires /usr/bin/python sagator-1.0.0-1.fc9.noarch requires /sbin/service sage-0.2.0-3.fc9.ppc requires /sbin/ldconfig sage-0.2.0-3.fc9.ppc64 requires /sbin/ldconfig samba-3.2.0-1.pre3.10.fc10.ppc requires /bin/sh samba-3.2.0-1.pre3.10.fc10.ppc requires /sbin/service samba-3.2.0-1.pre3.10.fc10.ppc requires /bin/bash samba-3.2.0-1.pre3.10.fc10.ppc requires /bin/sh samba-3.2.0-1.pre3.10.fc10.ppc requires /usr/bin/perl samba-3.2.0-1.pre3.10.fc10.ppc requires /sbin/chkconfig samba-client-3.2.0-1.pre3.10.fc10.ppc requires /usr/bin/perl samba-client-3.2.0-1.pre3.10.fc10.ppc requires /bin/sh samba-common-3.2.0-1.pre3.10.fc10.ppc requires /bin/sh samba-common-3.2.0-1.pre3.10.fc10.ppc requires /usr/sbin/groupadd samba-common-3.2.0-1.pre3.10.fc10.ppc requires /sbin/service samba-common-3.2.0-1.pre3.10.fc10.ppc requires /sbin/chkconfig samba-common-3.2.0-1.pre3.10.fc10.ppc64 requires /bin/sh samba-common-3.2.0-1.pre3.10.fc10.ppc64 requires /usr/sbin/groupadd samba-common-3.2.0-1.pre3.10.fc10.ppc64 requires /sbin/service samba-common-3.2.0-1.pre3.10.fc10.ppc64 requires /sbin/chkconfig samba-winbind-3.2.0-1.pre3.10.fc10.ppc requires /bin/sh samba-winbind-3.2.0-1.pre3.10.fc10.ppc requires /usr/sbin/groupadd samba-winbind-3.2.0-1.pre3.10.fc10.ppc requires /sbin/service samba-winbind-3.2.0-1.pre3.10.fc10.ppc requires /bin/sh samba-winbind-3.2.0-1.pre3.10.fc10.ppc requires /sbin/chkconfig samba-winbind-3.2.0-1.pre3.10.fc10.ppc64 requires /bin/sh samba-winbind-3.2.0-1.pre3.10.fc10.ppc64 requires /usr/sbin/groupadd samba-winbind-3.2.0-1.pre3.10.fc10.ppc64 requires /sbin/service samba-winbind-3.2.0-1.pre3.10.fc10.ppc64 requires /bin/sh samba-winbind-3.2.0-1.pre3.10.fc10.ppc64 requires /sbin/chkconfig samyak-fonts-devanagari-1.2.0-2.fc9.noarch requires /bin/sh samyak-fonts-gujarati-1.2.0-2.fc9.noarch requires /bin/sh samyak-fonts-malayalam-1.2.0-2.fc9.noarch requires /bin/sh samyak-fonts-oriya-1.2.0-2.fc9.noarch requires /bin/sh samyak-fonts-tamil-1.2.0-2.fc9.noarch requires /bin/sh sane-backends-1.0.19-10.fc9.ppc requires /bin/bash sane-backends-devel-1.0.19-10.fc9.ppc requires /bin/sh sane-backends-devel-1.0.19-10.fc9.ppc64 requires /bin/sh sane-backends-libs-1.0.19-10.fc9.ppc requires /sbin/ldconfig sane-backends-libs-1.0.19-10.fc9.ppc64 requires /sbin/ldconfig sarai-fonts-1.0-4.fc9.noarch requires /bin/sh saxon-6.5.5-1jpp.2.fc7.noarch requires /bin/sh saxon-6.5.5-1jpp.2.fc7.noarch requires /usr/sbin/update-alternatives sazanami-fonts-gothic-0.20040629-4.20061016.fc8.noarch requires /bin/sh sazanami-fonts-mincho-0.20040629-4.20061016.fc8.noarch requires /bin/sh sbcl-1.0.13-1.fc9.ppc requires /bin/sh sbcl-1.0.13-1.fc9.ppc requires /sbin/install-info sblim-cmpi-base-1.5.4-7.fc7.ppc requires /bin/sh sblim-cmpi-base-1.5.4-7.fc7.ppc requires /sbin/ldconfig sblim-cmpi-base-1.5.4-7.fc7.ppc requires /bin/sh sblim-cmpi-base-1.5.4-7.fc7.ppc64 requires /bin/sh sblim-cmpi-base-1.5.4-7.fc7.ppc64 requires /sbin/ldconfig sblim-cmpi-base-1.5.4-7.fc7.ppc64 requires /bin/sh sblim-cmpi-base-test-1.5.4-7.fc7.ppc requires /usr/bin/perl sblim-cmpi-base-test-1.5.4-7.fc7.ppc requires /bin/bash sblim-cmpi-base-test-1.5.4-7.fc7.ppc requires /bin/sh sblim-testsuite-1.2.4-3.fc6.noarch requires /usr/bin/perl sblim-testsuite-1.2.4-3.fc6.noarch requires /bin/sh scalapack-1.7.5-2.fc9.ppc requires /sbin/ldconfig scalapack-1.7.5-2.fc9.ppc64 requires /sbin/ldconfig scanbuttond-0.2.3-12.fc9.ppc requires /bin/sh scanbuttond-0.2.3-12.fc9.ppc requires /sbin/service scanbuttond-0.2.3-12.fc9.ppc requires /sbin/ldconfig scanbuttond-0.2.3-12.fc9.ppc requires /bin/bash scanbuttond-0.2.3-12.fc9.ppc requires /bin/sh scanbuttond-0.2.3-12.fc9.ppc requires /sbin/chkconfig scapy-1.1.1-4.fc8.noarch requires /usr/bin/env schismtracker-0.5-0.7.rc1.fc9.ppc requires /bin/sh schroedinger-1.0.0-1.fc9.ppc requires /sbin/ldconfig schroedinger-1.0.0-1.fc9.ppc64 requires /sbin/ldconfig scidavis-0.1.3-2.fc10.ppc requires /bin/sh scim-1.4.7-23.fc10.ppc requires /usr/sbin/alternatives scim-1.4.7-23.fc10.ppc requires /bin/sh scim-1.4.7-23.fc10.ppc requires /bin/sh scim-bridge-gtk-0.4.15-5.fc9.ppc requires /bin/sh scim-bridge-gtk-0.4.15-5.fc9.ppc64 requires /bin/sh scim-gtk-1.4.7-23.fc10.ppc requires /bin/sh scim-gtk-1.4.7-23.fc10.ppc64 requires /bin/sh scim-input-pad-0.1.1-8.fc9.ppc requires /sbin/ldconfig scim-input-pad-0.1.1-8.fc9.ppc requires /bin/sh scim-input-pad-0.1.1-8.fc9.ppc64 requires /sbin/ldconfig scim-input-pad-0.1.1-8.fc9.ppc64 requires /bin/sh scim-libs-1.4.7-23.fc10.ppc requires /sbin/ldconfig scim-libs-1.4.7-23.fc10.ppc64 requires /sbin/ldconfig scim-python-pinyin-0.1.12-1.fc10.ppc requires /bin/sh scim-python-xingma-0.1.12-1.fc10.ppc requires /usr/bin/python scim-python-xingma-cangjie-0.1.12-1.fc10.ppc requires /bin/sh scim-python-xingma-erbi-0.1.12-1.fc10.ppc requires /bin/sh scim-python-xingma-wubi-0.1.12-1.fc10.ppc requires /bin/sh scim-python-xingma-zhengma-0.1.12-1.fc10.ppc requires /bin/sh scim-tables-0.5.7-5.fc9.ppc requires /sbin/ldconfig scim-tomoe-0.6.0-2.fc8.ppc requires /bin/sh scons-0.98.3-2.fc10.noarch requires /usr/bin/python scorched3d-41.3-2.fc9.ppc requires /bin/sh scorchwentbonkers-1.1-5.fc9.ppc requires /bin/sh scratchpad-0.3.0-4.fc9.ppc requires /bin/sh screen-4.0.3-11.fc9.ppc requires /bin/sh screen-4.0.3-11.fc9.ppc requires /sbin/install-info screen-4.0.3-11.fc9.ppc requires /usr/sbin/groupadd scribes-0.3.3.3-2.fc9.noarch requires /bin/sh scribes-0.3.3.3-2.fc9.noarch requires /usr/bin/env scribus-1.3.4-5.fc9.ppc requires /bin/sh scsi-target-utils-0.0-4.20071227snap.fc9.ppc requires /bin/sh scsi-target-utils-0.0-4.20071227snap.fc9.ppc requires /sbin/service scsi-target-utils-0.0-4.20071227snap.fc9.ppc requires /sbin/chkconfig scsi-target-utils-0.0-4.20071227snap.fc9.ppc requires /bin/sh scummvm-0.11.1-2.fc9.ppc requires /bin/sh scythia-0.9.3-2.2.fc9.ppc requires /bin/sh sdcc-2.6.0-12.fc9.ppc requires /bin/sh sdcc-libc-sources-2.6.0-12.fc9.ppc requires /bin/sh sdljava-0.9.1-9.fc9.ppc requires /bin/sh sdljava-demo-0.9.1-9.fc9.ppc requires /usr/share/fonts/dejavu/DejaVuSans-BoldOblique.ttf sdljava-demo-0.9.1-9.fc9.ppc requires /usr/share/fonts/dejavu/DejaVuSans-Bold.ttf sdljava-demo-0.9.1-9.fc9.ppc requires /usr/share/fonts/dejavu/DejaVuSans-Oblique.ttf sdljava-demo-0.9.1-9.fc9.ppc requires /usr/share/fonts/dejavu/DejaVuSans.ttf sdljava-demo-0.9.1-9.fc9.ppc requires /bin/sh sdljava-javadoc-0.9.1-9.fc9.ppc requires /bin/sh seahorse-2.22.1-1.fc9.ppc requires /bin/sh seahorse-2.22.1-1.fc9.ppc requires /bin/sh seahorse-2.22.1-1.fc9.ppc64 requires /bin/sh seahorse-2.22.1-1.fc9.ppc64 requires /bin/sh seahorse-adventures-1.0-2.fc8.noarch requires /bin/sh seahorse-adventures-1.0-2.fc8.noarch requires /usr/bin/env seahorse-adventures-1.0-2.fc8.noarch requires /usr/bin/python seamonkey-1.1.9-4.fc9.ppc requires /bin/sh seamonkey-1.1.9-4.fc9.ppc requires /bin/sh sear-0.6.3-10.fc9.ppc requires /bin/sh sec-2.4.1-1.fc8.noarch requires /bin/sh sec-2.4.1-1.fc8.noarch requires /bin/bash sec-2.4.1-1.fc8.noarch requires /usr/bin/perl sectool-0.7.3-1.fc10.noarch requires /usr/bin/env sectool-0.7.3-1.fc10.noarch requires /usr/bin/python sectool-gui-0.7.3-1.fc10.noarch requires /usr/bin/python sed-4.1.5-10.fc9.ppc requires /bin/sh sed-4.1.5-10.fc9.ppc requires /sbin/install-info seedit-2.2.0-2.fc9.ppc requires /bin/sh seedit-2.2.0-2.fc9.ppc requires /usr/bin/python seedit-gui-2.2.0-2.fc9.ppc requires /usr/bin/python seedit-policy-2.2.0-2.fc9.ppc requires /bin/sh seedit-policy-2.2.0-2.fc9.ppc requires /bin/sh seekwatcher-0.10-1.fc9.noarch requires /usr/bin/env selinux-policy-3.3.1-45.fc10.noarch requires /bin/sh selinux-policy-devel-3.3.1-45.fc10.noarch requires /bin/sh selinux-policy-devel-3.3.1-45.fc10.noarch requires /usr/bin/env selinux-policy-mls-3.3.1-45.fc10.noarch requires /bin/sh selinux-policy-targeted-3.3.1-45.fc10.noarch requires /bin/sh selinux-policy-targeted-3.3.1-45.fc10.noarch requires /bin/sh sendmail-8.14.2-4.fc9.ppc requires /bin/sh sendmail-8.14.2-4.fc9.ppc requires /usr/sbin/saslauthd sendmail-8.14.2-4.fc9.ppc requires /usr/sbin/alternatives sendmail-8.14.2-4.fc9.ppc requires /bin/bash sendmail-8.14.2-4.fc9.ppc64 requires /bin/sh sendmail-8.14.2-4.fc9.ppc64 requires /usr/sbin/saslauthd sendmail-8.14.2-4.fc9.ppc64 requires /bin/bash sendmail-8.14.2-4.fc9.ppc64 requires /usr/sbin/alternatives sendmail-cf-8.14.2-4.fc9.ppc requires /bin/sh sepostgresql-8.3.1-2.197.fc10.ppc requires /bin/sh sepostgresql-8.3.1-2.197.fc10.ppc requires /sbin/service sepostgresql-8.3.1-2.197.fc10.ppc requires /bin/sh sepostgresql-8.3.1-2.197.fc10.ppc requires /sbin/chkconfig seq24-0.8.7-8.fc8.ppc requires /bin/sh ser-0.9.6-14.fc9.ppc requires /bin/sh ser-0.9.6-14.fc9.ppc requires /sbin/service ser-0.9.6-14.fc9.ppc requires /bin/bash ser-0.9.6-14.fc9.ppc requires /bin/sh ser-0.9.6-14.fc9.ppc requires /sbin/chkconfig ser-mysql-0.9.6-14.fc9.ppc requires /bin/sh ser-postgresql-0.9.6-14.fc9.ppc requires /bin/sh ser2net-2.4-2.fc9.1.ppc requires /bin/sh ser2net-2.4-2.fc9.1.ppc requires /bin/sh ser2net-2.4-2.fc9.1.ppc requires /sbin/service sergueis-destiny-1.1-4.fc8.noarch requires /bin/sh sergueis-destiny-1.1-4.fc8.noarch requires /bin/bash serpentine-0.9-2.fc9.noarch requires /bin/sh serpentine-0.9-2.fc9.noarch requires /usr/bin/env setools-console-3.3.4-1.fc9.ppc requires /bin/sh setools-gui-3.3.4-1.fc9.ppc requires /bin/sh setools-libs-3.3.4-1.fc9.ppc requires /sbin/ldconfig setools-libs-3.3.4-1.fc9.ppc64 requires /sbin/ldconfig setools-libs-java-3.3.4-1.fc9.ppc requires /sbin/ldconfig setools-libs-java-3.3.4-1.fc9.ppc64 requires /sbin/ldconfig setools-libs-tcl-3.3.4-1.fc9.ppc requires /sbin/ldconfig setroubleshoot-2.0.6-1.fc9.noarch requires /bin/sh setroubleshoot-2.0.6-1.fc9.noarch requires /usr/bin/update-desktop-database setroubleshoot-plugins-2.0.4-5.fc9.noarch requires /bin/sh setroubleshoot-server-2.0.6-1.fc9.noarch requires /bin/sh setroubleshoot-server-2.0.6-1.fc9.noarch requires /bin/bash setroubleshoot-server-2.0.6-1.fc9.noarch requires /sbin/chkconfig setroubleshoot-server-2.0.6-1.fc9.noarch requires /usr/bin/python setroubleshoot-server-2.0.6-1.fc9.noarch requires /sbin/service sg3_utils-libs-1.25-4.fc9.ppc requires /sbin/ldconfig sg3_utils-libs-1.25-4.fc9.ppc64 requires /sbin/ldconfig sgml-common-0.6.3-23.fc9.noarch requires /bin/sh shapelib-1.2.10-16.20060304cvs.ppc requires /sbin/ldconfig shapelib-1.2.10-16.20060304cvs.ppc requires /bin/sh shapelib-1.2.10-16.20060304cvs.ppc64 requires /sbin/ldconfig shapelib-1.2.10-16.20060304cvs.ppc64 requires /bin/sh shared-mime-info-0.30-1.fc10.ppc requires /bin/sh sharutils-4.6.3-2.fc9.ppc requires /bin/sh sharutils-4.6.3-2.fc9.ppc requires /bin/bash sharutils-4.6.3-2.fc9.ppc requires /usr/bin/perl sharutils-4.6.3-2.fc9.ppc requires /sbin/install-info shippy-1.3.3.7-7.fc9.ppc requires /bin/sh shippy-common-1.3.3.7-7.fc9.ppc requires /bin/bash shorewall-common-4.0.10-2.fc10.noarch requires /bin/sh shorewall-common-4.0.10-2.fc10.noarch requires /sbin/chkconfig shorewall-common-4.0.10-2.fc10.noarch requires /bin/sh shorewall-common-4.0.10-2.fc10.noarch requires /sbin/service shorewall-lite-4.0.10-2.fc10.noarch requires /bin/sh shorewall-lite-4.0.10-2.fc10.noarch requires /sbin/chkconfig shorewall-lite-4.0.10-2.fc10.noarch requires /bin/sh shorewall-lite-4.0.10-2.fc10.noarch requires /sbin/service shorewall-perl-4.0.10-2.fc10.noarch requires /usr/bin/perl shorewall-shell-4.0.10-2.fc10.noarch requires /bin/sh showimg-0.9.5-16.fc9.ppc requires /sbin/ldconfig showimg-0.9.5-16.fc9.ppc64 requires /sbin/ldconfig siege-2.67-1.fc10.ppc requires /usr/bin/perl siege-2.67-1.fc10.ppc requires /bin/sh sigscheme-0.8.3-1.fc10.ppc requires /sbin/ldconfig sigscheme-0.8.3-1.fc10.ppc64 requires /sbin/ldconfig silkscreen-fonts-1.0-1.fc9.noarch requires /bin/sh simcoupe-1.0-4.fc10.ppc requires /bin/sh sinjdoc-0.5-6.fc9.ppc requires /bin/sh sinjdoc-0.5-6.fc9.ppc requires /bin/sh six-0.5.3-9.fc9.ppc requires /bin/sh skencil-0.6.17-18.20070606svn.fc9.ppc requires /bin/sh skencil-0.6.17-18.20070606svn.fc9.ppc requires /usr/bin/env skencil-0.6.17-18.20070606svn.fc9.ppc requires /usr/bin/python ski-devel-1.3.2-5.fc10.ppc requires /bin/sh ski-devel-1.3.2-5.fc10.ppc64 requires /bin/sh ski-libs-1.3.2-5.fc10.ppc requires /sbin/ldconfig ski-libs-1.3.2-5.fc10.ppc64 requires /sbin/ldconfig skstream-0.3.6-3.fc9.ppc requires /sbin/ldconfig skstream-0.3.6-3.fc9.ppc64 requires /sbin/ldconfig slang-2.1.3-3.fc9.ppc requires /sbin/ldconfig slang-2.1.3-3.fc9.ppc64 requires /sbin/ldconfig slang-slsh-2.1.3-3.fc9.ppc requires /usr/bin/env slib-3b1-1.fc9.noarch requires /bin/sh slib-3b1-1.fc9.noarch requires /sbin/install-info slim-1.3.0-4.fc9.ppc requires /sbin/shutdown slim-1.3.0-4.fc9.ppc requires /etc/pam.d slim-1.3.0-4.fc9.ppc requires /usr/bin/perl slim-1.3.0-4.fc9.ppc requires /bin/sh slingshot-0.8.1p-1.fc8.noarch requires /bin/sh slingshot-0.8.1p-1.fc8.noarch requires /bin/bash sloccount-2.26-7.fc9.ppc requires /usr/bin/perl sloccount-2.26-7.fc9.ppc requires /bin/sh slrn-pull-0.9.8.1pl1-8.20070716cvs.fc9.ppc requires /bin/sh smart-0.52-54.fc9.ppc requires /usr/bin/python smarteiffel-2.3-2.fc9.ppc requires /bin/sh 1:smartmontools-5.38-4.1.fc10.ppc requires /sbin/service 1:smartmontools-5.38-4.1.fc10.ppc requires /bin/bash 1:smartmontools-5.38-4.1.fc10.ppc requires /bin/sh 1:smartmontools-5.38-4.1.fc10.ppc requires /sbin/chkconfig 1:smartmontools-5.38-4.1.fc10.ppc requires /bin/sh 1:smartmontools-config-5.38-4.1.fc10.ppc requires /usr/bin/python smashteroid-1.11-4.fc9.ppc requires /bin/sh smb4k-0.9.4-1.fc10.ppc requires /bin/sh smb4k-0.9.4-1.fc10.ppc64 requires /bin/sh smbldap-tools-0.9.4-2.fc9.noarch requires /usr/bin/perl smc-fonts-dyuthi-04-6.fc9.noarch requires /bin/sh smc-fonts-meera-04-6.fc9.noarch requires /bin/sh smc-fonts-rachana-04-6.fc9.noarch requires /bin/sh smc-fonts-raghumalayalam-04-6.fc9.noarch requires /bin/sh smc-fonts-suruma-04-6.fc9.noarch requires /bin/sh smolt-1.1.1.1-4.fc9.noarch requires /bin/sh smolt-1.1.1.1-4.fc9.noarch requires /bin/bash smolt-1.1.1.1-4.fc9.noarch requires /sbin/chkconfig smolt-1.1.1.1-4.fc9.noarch requires /usr/sbin/groupadd smolt-1.1.1.1-4.fc9.noarch requires /usr/sbin/useradd smolt-1.1.1.1-4.fc9.noarch requires /usr/bin/python smolt-1.1.1.1-4.fc9.noarch requires /sbin/service smolt-server-1.1.1.1-4.fc9.noarch requires /usr/bin/python smstools-3.0.10-2.fc9.ppc requires /bin/sh smstools-3.0.10-2.fc9.ppc requires /bin/bash smstools-3.0.10-2.fc9.ppc requires /sbin/chkconfig smstools-3.0.10-2.fc9.ppc requires /bin/sh smstools-3.0.10-2.fc9.ppc requires /sbin/service snake-0.11-0.2.fc9.noarch requires /usr/bin/python snake-server-0.11-0.2.fc9.noarch requires /bin/sh snake-server-0.11-0.2.fc9.noarch requires /bin/sh snake-server-0.11-0.2.fc9.noarch requires /usr/bin/python snort-2.8.1-3.fc10.ppc requires /bin/sh snort-2.8.1-3.fc10.ppc requires /bin/sh snort-bloat-2.8.1-3.fc10.ppc requires /bin/sh snort-mysql-2.8.1-3.fc10.ppc requires /bin/sh snort-mysql+flexresp-2.8.1-3.fc10.ppc requires /bin/sh snort-plain+flexresp-2.8.1-3.fc10.ppc requires /bin/sh snort-postgresql-2.8.1-3.fc10.ppc requires /bin/sh snort-postgresql+flexresp-2.8.1-3.fc10.ppc requires /bin/sh snort-snmp-2.8.1-3.fc10.ppc requires /bin/sh snort-snmp+flexresp-2.8.1-3.fc10.ppc requires /bin/sh snownews-1.5.8-2.fc9.ppc requires /usr/bin/perl sofia-sip-1.12.8-1.fc9.ppc requires /sbin/ldconfig sofia-sip-1.12.8-1.fc9.ppc64 requires /sbin/ldconfig sofia-sip-devel-1.12.8-1.fc9.ppc requires /usr/bin/env sofia-sip-devel-1.12.8-1.fc9.ppc64 requires /usr/bin/env sofia-sip-glib-1.12.8-1.fc9.ppc requires /sbin/ldconfig sofia-sip-glib-1.12.8-1.fc9.ppc64 requires /sbin/ldconfig solarwolf-1.5-2.fc8.noarch requires /bin/sh solarwolf-1.5-2.fc8.noarch requires /usr/bin/env solfege-3.10.4-1.fc10.ppc requires /bin/bash solfege-3.10.4-1.fc10.ppc requires /bin/sh solfege-3.10.4-1.fc10.ppc requires /usr/bin/python sonata-1.5.1-1.fc10.ppc requires /usr/bin/python sonic-visualiser-1.2-1.fc9.ppc requires /bin/sh sooperlooper-1.6.2-1.fc9.ppc requires /bin/sh soprano-2.0.98-1.fc10.ppc requires /sbin/ldconfig soprano-2.0.98-1.fc10.ppc64 requires /sbin/ldconfig soprano-apidocs-2.0.98-1.fc10.ppc requires /usr/bin/perl sos-1.8-1.fc8.noarch requires /bin/bash sos-1.8-1.fc8.noarch requires /usr/bin/env sound-juicer-2.22.0-3.fc10.ppc requires /bin/sh soundconverter-1.2.0-1.fc10.noarch requires /bin/sh soundconverter-1.2.0-1.fc10.noarch requires /usr/bin/python soundtouch-1.3.1-10.fc9.ppc requires /sbin/ldconfig soundtouch-1.3.1-10.fc9.ppc64 requires /sbin/ldconfig source-highlight-2.8-2.fc9.ppc requires /bin/sh source-highlight-2.8-2.fc9.ppc requires /sbin/install-info source-highlight-2.8-2.fc9.ppc requires /bin/sh sox-14.0.1-1.fc9.ppc requires /sbin/ldconfig sox-14.0.1-1.fc9.ppc64 requires /sbin/ldconfig spamass-milter-0.3.1-7.fc9.ppc requires /bin/sh spamass-milter-0.3.1-7.fc9.ppc requires /sbin/service spamass-milter-0.3.1-7.fc9.ppc requires /bin/bash spamass-milter-0.3.1-7.fc9.ppc requires /sbin/chkconfig spamassassin-3.2.4-4.fc9.ppc requires /sbin/chkconfig spamassassin-3.2.4-4.fc9.ppc requires /usr/bin/perl spamassassin-3.2.4-4.fc9.ppc requires /bin/sh spamassassin-3.2.4-4.fc9.ppc requires /sbin/service spamassassin-3.2.4-4.fc9.ppc requires /bin/bash spamassassin-3.2.4-4.fc9.ppc requires /bin/sh spambayes-1.0.4-5.fc8.noarch requires /usr/bin/python spampd-2.30-4.noarch requires /bin/sh spampd-2.30-4.noarch requires /usr/bin/perl spampd-2.30-4.noarch requires /sbin/chkconfig spampd-2.30-4.noarch requires /bin/sh spampd-2.30-4.noarch requires /sbin/service spandsp-0.0.4-0.10.pre18.fc9.ppc requires /sbin/ldconfig spandsp-0.0.4-0.10.pre18.fc9.ppc64 requires /sbin/ldconfig sparse-0.4.1-2.fc9.ppc requires /usr/bin/perl specto-0.2.2-1.fc9.noarch requires /bin/sh specto-0.2.2-1.fc9.noarch requires /usr/bin/python speedcrunch-0.9-3.fc9.ppc requires /bin/sh speex-1.2-0.9.beta3.ppc requires /sbin/ldconfig speex-1.2-0.9.beta3.ppc64 requires /sbin/ldconfig spr-07.15.00-1.fc9.ppc requires /sbin/ldconfig spr-07.15.00-1.fc9.ppc64 requires /sbin/ldconfig sqlgrey-1.7.5-1.fc7.noarch requires /bin/sh sqlgrey-1.7.5-1.fc7.noarch requires /usr/bin/perl sqlgrey-1.7.5-1.fc7.noarch requires /bin/bash sqlgrey-1.7.5-1.fc7.noarch requires /sbin/chkconfig sqlgrey-1.7.5-1.fc7.noarch requires /bin/sh sqlgrey-1.7.5-1.fc7.noarch requires /sbin/service sqlite-3.5.8-1.fc10.ppc requires /sbin/ldconfig sqlite-3.5.8-1.fc10.ppc64 requires /sbin/ldconfig sqliteman-1.0.1-4.fc9.ppc requires /bin/sh 7:squid-3.0.STABLE5-2.fc10.ppc requires /bin/sh 7:squid-3.0.STABLE5-2.fc10.ppc requires /sbin/service 7:squid-3.0.STABLE5-2.fc10.ppc requires /bin/bash 7:squid-3.0.STABLE5-2.fc10.ppc requires /bin/sh 7:squid-3.0.STABLE5-2.fc10.ppc requires /usr/bin/perl 7:squid-3.0.STABLE5-2.fc10.ppc requires /sbin/chkconfig squidGuard-1.2.0-18.fc9.ppc requires /bin/sh squidGuard-1.2.0-18.fc9.ppc requires /usr/bin/chcon squidGuard-1.2.0-18.fc9.ppc requires /bin/bash squidGuard-1.2.0-18.fc9.ppc requires /usr/bin/perl squidGuard-1.2.0-18.fc9.ppc requires /sbin/chkconfig squirrelmail-1.4.13-1.fc9.noarch requires /usr/bin/env squirrelmail-1.4.13-1.fc9.noarch requires /bin/sh ss5-3.5.9-7.ppc requires /bin/sh ss5-3.5.9-7.ppc requires /bin/sh sshfp-1.1.2-1.fc7.noarch requires /usr/bin/python sshmenu-3.15-5.fc9.noarch requires /usr/bin/ruby ssmtp-2.61-11.5.fc9.3.ppc requires /bin/sh ssmtp-2.61-11.5.fc9.3.ppc requires /usr/sbin/alternatives stardict-3.0.1-8.fc9.ppc requires /bin/sh starplot-0.95.4-6.fc9.ppc requires /bin/sh starplot-gliese3-0.95-2.fc9.noarch requires /bin/sh starplot-yale5-0.95-2.fc9.noarch requires /bin/sh startup-notification-0.9-4.fc9.ppc requires /sbin/ldconfig startup-notification-0.9-4.fc9.ppc64 requires /sbin/ldconfig statgrab-tools-0.16-1.fc9.ppc requires /usr/bin/perl statserial-1.1-41.fc9.ppc requires /bin/bash stgit-0.14.2-1.fc9.noarch requires /bin/sh stgit-0.14.2-1.fc9.noarch requires /usr/bin/python stix-fonts-0.9-6.fc9.noarch requires /bin/sh stix-fonts-integrals-0.9-6.fc9.noarch requires /bin/sh stix-fonts-pua-0.9-6.fc9.noarch requires /bin/sh stix-fonts-sizes-0.9-6.fc9.noarch requires /bin/sh stix-fonts-variants-0.9-6.fc9.noarch requires /bin/sh stonith-2.1.3-1.fc9.ppc requires /usr/bin/python stonith-2.1.3-1.fc9.ppc requires /sbin/ldconfig stonith-2.1.3-1.fc9.ppc requires /usr/bin/perl stonith-2.1.3-1.fc9.ppc requires /bin/sh stonith-2.1.3-1.fc9.ppc64 requires /usr/bin/python stonith-2.1.3-1.fc9.ppc64 requires /sbin/ldconfig stonith-2.1.3-1.fc9.ppc64 requires /usr/bin/perl stonith-2.1.3-1.fc9.ppc64 requires /bin/sh stormbaancoureur-2.1.4-1.fc10.ppc requires /bin/sh stow-1.3.3-6.fc8.noarch requires /usr/bin/perl stow-1.3.3-6.fc8.noarch requires /sbin/install-info stow-1.3.3-6.fc8.noarch requires /bin/sh stratagus-2.2.4-4.fc9.ppc requires /usr/bin/env straw-0.27-12.fc9.noarch requires /bin/sh straw-0.27-12.fc9.noarch requires /usr/bin/python streamtuner-0.99.99-17.fc9.ppc requires /bin/sh strigi-libs-0.5.9-2.fc10.ppc requires /sbin/ldconfig strigi-libs-0.5.9-2.fc10.ppc64 requires /sbin/ldconfig struts-1.2.9-5jpp.9.fc9.ppc requires /bin/sh struts-javadoc-1.2.9-5jpp.9.fc9.ppc requires /bin/sh struts-javadoc-1.2.9-5jpp.9.fc9.ppc requires /bin/rm struts-javadoc-1.2.9-5jpp.9.fc9.ppc requires /bin/ln struts-webapps-tomcat5-1.2.9-5jpp.9.fc9.ppc requires /bin/sh struts-webapps-tomcat5-1.2.9-5jpp.9.fc9.ppc requires /bin/ln struts-webapps-tomcat5-1.2.9-5jpp.9.fc9.ppc requires /bin/rm stunnel-4.22-1.ppc requires /usr/bin/perl sub2srt-0.5.3-3.fc8.noarch requires /usr/bin/perl subversion-1.4.6-7.ppc requires /usr/bin/env subversion-1.4.6-7.ppc requires /usr/bin/python subversion-1.4.6-7.ppc requires /sbin/ldconfig subversion-1.4.6-7.ppc requires /bin/bash subversion-1.4.6-7.ppc requires /bin/sh subversion-1.4.6-7.ppc requires /usr/bin/perl subversion-1.4.6-7.ppc64 requires /usr/bin/env subversion-1.4.6-7.ppc64 requires /usr/bin/python subversion-1.4.6-7.ppc64 requires /sbin/ldconfig subversion-1.4.6-7.ppc64 requires /bin/bash subversion-1.4.6-7.ppc64 requires /bin/sh subversion-1.4.6-7.ppc64 requires /usr/bin/perl subversion-javahl-1.4.6-7.ppc requires /sbin/ldconfig subversion-javahl-1.4.6-7.ppc64 requires /sbin/ldconfig subversion-perl-1.4.6-7.ppc requires /sbin/ldconfig subversion-perl-1.4.6-7.ppc64 requires /sbin/ldconfig subversion-ruby-1.4.6-7.ppc requires /sbin/ldconfig subversion-ruby-1.4.6-7.ppc64 requires /sbin/ldconfig suck-4.3.2-22.fc9.ppc requires /usr/bin/perl suck-4.3.2-22.fc9.ppc requires /bin/sh sudo-1.6.9p13-6.fc10.ppc requires /bin/sh sudo-1.6.9p13-6.fc10.ppc requires /etc/pam.d/system-auth sugar-0.79.4-2.fc10.ppc requires /bin/sh sugar-0.79.4-2.fc10.ppc requires /usr/bin/env sugar-0.79.4-2.fc10.ppc requires /bin/sh sugar-artwork-0.79.1-1.fc9.ppc requires /bin/sh sugar-artwork-0.79.1-1.fc9.ppc64 requires /bin/sh sugar-datastore-0.6.0-1.fc9.noarch requires /usr/bin/env sugar-journal-79-3.fc9.noarch requires /usr/bin/env sugar-presence-service-0.79.0-1.fc9.noarch requires /usr/bin/env suitesparse-3.1.0-1.fc9.ppc requires /sbin/ldconfig suitesparse-3.1.0-1.fc9.ppc64 requires /sbin/ldconfig sunbird-0.8-3.fc9.ppc requires /bin/sh sunbird-0.8-3.fc9.ppc requires libhunspell.so.1 sunbird-0.8-3.fc9.ppc requires /bin/sh sundials-2.3.0-6.fc9.ppc requires /sbin/ldconfig sundials-2.3.0-6.fc9.ppc64 requires /sbin/ldconfig sundials-devel-2.3.0-6.fc9.ppc requires /bin/sh sundials-devel-2.3.0-6.fc9.ppc64 requires /bin/sh supertuxkart-0.4-2.fc10.ppc requires /bin/sh supervisor-2.1-4.fc9.noarch requires /bin/sh supervisor-2.1-4.fc9.noarch requires /bin/bash supervisor-2.1-4.fc9.noarch requires /sbin/chkconfig supervisor-2.1-4.fc9.noarch requires /usr/bin/python supervisor-2.1-4.fc9.noarch requires /sbin/service surfraw-1.0.7-3.fc8.noarch requires /bin/sh svn2cl-0.10-1.noarch requires /bin/sh svncpp-0.9.6-1.fc9.ppc requires /sbin/ldconfig svncpp-0.9.6-1.fc9.ppc64 requires /sbin/ldconfig svnkit-1.1.4-3.fc9.ppc requires /usr/bin/rebuild-gcj-db svnmailer-1.0.8-3.fc7.noarch requires /usr/bin/python svrcore-4.0.4-2.fc9.ppc requires /sbin/ldconfig svrcore-4.0.4-2.fc9.ppc64 requires /sbin/ldconfig swaks-20061116.0-1.fc8.noarch requires /usr/bin/perl swatch-3.2.1-2.fc9.noarch requires /usr/bin/perl sweep-0.9.2-2.fc9.ppc requires /bin/sh swfdec-0.6.6-1.fc10.ppc requires /sbin/ldconfig swfdec-0.6.6-1.fc10.ppc64 requires /sbin/ldconfig swfdec-gnome-2.22.0-1.fc9.ppc requires /bin/sh swfdec-gtk-0.6.6-1.fc10.ppc requires /sbin/ldconfig swfdec-gtk-0.6.6-1.fc10.ppc requires /bin/sh swfdec-gtk-0.6.6-1.fc10.ppc64 requires /bin/sh swfdec-gtk-0.6.6-1.fc10.ppc64 requires /sbin/ldconfig swfdec-mozilla-0.6.0-1.fc9.ppc requires /usr/lib/mozilla/plugins swig-1.3.35-2.fc10.ppc requires /sbin/ldconfig swing-layout-1.0.3-2.fc9.ppc requires /bin/sh switchdesk-4.0.9-2.noarch requires /bin/bash switchdesk-gui-4.0.9-2.noarch requires /usr/bin/env sword-1.5.10-3.fc9.ppc requires /sbin/ldconfig sword-1.5.10-3.fc9.ppc64 requires /sbin/ldconfig syck-0.61-4.3.fc9.ppc requires /sbin/ldconfig syck-0.61-4.3.fc9.ppc64 requires /sbin/ldconfig synaptic-0.57.2-16.fc9.ppc requires /bin/sh synce-gnome-0.11-2.fc9.noarch requires /usr/bin/env synce-kde-0.9.1-3.fc9.ppc requires /bin/sh synce-kde-0.9.1-3.fc9.ppc requires /bin/sh synce-kpm-0.11-3.fc9.noarch requires /usr/bin/python synce-serial-0.11-2.fc9.ppc requires /bin/sh synce-sync-engine-0.11-6.fc9.noarch requires /usr/bin/python syncevolution-0.7-2.fc10.ppc requires /usr/bin/env sysconftool-0.15-3.fc6.noarch requires /usr/bin/perl syslog-ng-2.0.8-1.fc9.ppc requires /bin/sh syslog-ng-2.0.8-1.fc9.ppc requires /bin/sh sysreport-1.4.4-1.noarch requires /bin/bash sysreport-1.4.4-1.noarch requires /usr/bin/tr sysstat-8.0.4-4.fc10.ppc requires /bin/cp sysstat-8.0.4-4.fc10.ppc requires /usr/bin/id sysstat-8.0.4-4.fc10.ppc requires /etc/cron.d sysstat-8.0.4-4.fc10.ppc requires /bin/chmod sysstat-8.0.4-4.fc10.ppc requires /bin/mkdir sysstat-8.0.4-4.fc10.ppc requires /usr/bin/install sysstat-8.0.4-4.fc10.ppc requires /sbin/chkconfig sysstat-8.0.4-4.fc10.ppc requires /bin/sh sysstat-8.0.4-4.fc10.ppc requires /bin/mv sysstat-8.0.4-4.fc10.ppc requires /bin/grep sysstat-8.0.4-4.fc10.ppc requires /bin/sh system-config-audit-0.4.6-7.fc10.ppc requires /bin/sh system-config-bind-4.0.6-1.fc9.noarch requires /bin/sh system-config-bind-4.0.6-1.fc9.noarch requires /usr/bin/python system-config-cluster-1.0.53-1.0.noarch requires /usr/bin/python2 system-config-cluster-1.0.53-1.0.noarch requires /sbin/chkconfig system-config-date-1.9.31-1.fc10.noarch requires /bin/sh system-config-date-1.9.31-1.fc10.noarch requires /bin/sh system-config-date-1.9.31-1.fc10.noarch requires /usr/bin/python system-config-display-1.0.51-9.fc9.noarch requires /bin/sh system-config-display-1.0.51-9.fc9.noarch requires /usr/bin/Xorg system-config-display-1.0.51-9.fc9.noarch requires /bin/sh system-config-display-1.0.51-9.fc9.noarch requires /usr/bin/python2 system-config-firewall-1.2.7-1.fc9.noarch requires /bin/sh system-config-firewall-1.2.7-1.fc9.noarch requires /bin/sh system-config-firewall-1.2.7-1.fc9.noarch requires /usr/bin/python system-config-firewall-tui-1.2.7-1.fc9.noarch requires /usr/bin/python 5:system-config-httpd-1.4.4-1.fc8.noarch requires /bin/sh 5:system-config-httpd-1.4.4-1.fc8.noarch requires /bin/sh system-config-kdump-1.0.13-2.fc9.noarch requires /bin/sh system-config-kdump-1.0.13-2.fc9.noarch requires /bin/sh system-config-keyboard-1.2.15-2.fc9.noarch requires /bin/sh system-config-keyboard-1.2.15-2.fc9.noarch requires /bin/sh system-config-kickstart-2.7.16-1.fc9.noarch requires /bin/sh system-config-kickstart-2.7.16-1.fc9.noarch requires /usr/bin/python2 system-config-language-1.2.15-3.fc10.noarch requires /bin/sh system-config-language-1.2.15-3.fc10.noarch requires /bin/sh system-config-lvm-1.1.4-1.0.fc9.noarch requires /sbin/chkconfig system-config-lvm-1.1.4-1.0.fc9.noarch requires /usr/bin/python2 system-config-netboot-0.1.45.2-1.fc10.noarch requires /bin/sh system-config-netboot-0.1.45.2-1.fc10.noarch requires /usr/bin/python system-config-netboot-cmd-0.1.45.2-1.fc10.noarch requires /bin/sh system-config-netboot-cmd-0.1.45.2-1.fc10.noarch requires /bin/bash system-config-netboot-cmd-0.1.45.2-1.fc10.noarch requires /usr/bin/python system-config-network-1.5.7-1.fc9.noarch requires /usr/bin/python system-config-network-tui-1.5.7-1.fc9.noarch requires /bin/sh system-config-network-tui-1.5.7-1.fc9.noarch requires /usr/bin/python system-config-nfs-1.3.40-1.fc9.noarch requires /bin/sh system-config-nfs-1.3.40-1.fc9.noarch requires /usr/bin/python system-config-printer-0.9.91-1.fc10.ppc requires /bin/sh system-config-printer-0.9.91-1.fc10.ppc requires /usr/bin/env system-config-printer-0.9.91-1.fc10.ppc requires /bin/sh system-config-printer-0.9.91-1.fc10.ppc requires /usr/bin/python system-config-printer-libs-0.9.91-1.fc10.ppc requires /usr/bin/env system-config-printer-libs-0.9.91-1.fc10.ppc requires /usr/bin/python system-config-rootpassword-1.99.4-1.fc9.noarch requires /bin/sh system-config-rootpassword-1.99.4-1.fc9.noarch requires /bin/sh system-config-samba-1.2.63-1.fc9.noarch requires /bin/sh system-config-samba-1.2.63-1.fc9.noarch requires /usr/bin/python system-config-services-0.99.15-1.fc9.noarch requires /bin/sh system-config-services-0.99.15-1.fc9.noarch requires /usr/bin/python system-config-users-1.2.80-1.fc10.noarch requires /bin/sh system-config-users-1.2.80-1.fc10.noarch requires /usr/bin/pgrep system-config-users-1.2.80-1.fc10.noarch requires /bin/sh system-config-users-1.2.80-1.fc10.noarch requires /usr/bin/python system-config-vsftpd-0.5.1-1.fc10.noarch requires /usr/bin/env system-config-vsftpd-0.5.1-1.fc10.noarch requires /bin/sh system-summary-0.0.3-2.fc9.noarch requires /usr/bin/python system-switch-java-1.1.2-1.fc8.noarch requires /usr/bin/env system-switch-mail-0.5.26-2.noarch requires /usr/bin/python systemtap-0.6.2-1.fc9.ppc64 requires /bin/bash systemtap-0.6.2-1.fc9.ppc64 requires /usr/bin/stap systemtap-runtime-0.6.2-1.fc9.ppc64 requires /bin/sh sysusage-2.6-3.fc9.noarch requires /usr/bin/perl sysvinit-tools-2.86-24.ppc requires /bin/sh t1lib-5.1.2-2.fc9.ppc requires /bin/sh t1lib-5.1.2-2.fc9.ppc requires /sbin/ldconfig t1lib-5.1.2-2.fc9.ppc requires /bin/sh t1lib-5.1.2-2.fc9.ppc64 requires /bin/sh t1lib-5.1.2-2.fc9.ppc64 requires /sbin/ldconfig t1lib-5.1.2-2.fc9.ppc64 requires /bin/sh taglib-1.5-1.fc9.ppc requires /sbin/ldconfig taglib-1.5-1.fc9.ppc64 requires /sbin/ldconfig taglib-devel-1.5-1.fc9.ppc requires /bin/sh taglib-devel-1.5-1.fc9.ppc64 requires /bin/sh tagsoup-1.0.1-2jpp.1.fc9.ppc requires /bin/sh tagtool-0.12.3-4.fc9.ppc requires /bin/sh tailor-0.9.30-1.fc9.noarch requires /usr/bin/python taipeifonts-1.2-5.fc9.noarch requires /bin/sh tango-icon-theme-0.8.1-1.fc8.noarch requires /bin/sh tango-icon-theme-extras-0.1.0-1.fc7.noarch requires /bin/sh tanukiwrapper-3.2.3-2jpp.1.fc9.ppc requires /bin/sh tanukiwrapper-javadoc-3.2.3-2jpp.1.fc9.ppc requires /bin/sh tanukiwrapper-javadoc-3.2.3-2jpp.1.fc9.ppc requires /bin/rm tanukiwrapper-javadoc-3.2.3-2jpp.1.fc9.ppc requires /bin/ln 2:tar-1.19-3.fc9.ppc requires /bin/sh 2:tar-1.19-3.fc9.ppc requires /sbin/install-info taskcoach-0.69.1-2.fc9.noarch requires /bin/sh taskcoach-0.69.1-2.fc9.noarch requires /usr/bin/env taskcoach-0.69.1-2.fc9.noarch requires /usr/bin/python taskjuggler-2.4.1-1.fc10.ppc requires /bin/sh tasks-0.12-2.fc10.ppc requires /bin/sh taxipilot-0.9.2-6.fc9.ppc requires /bin/sh taxipilot-0.9.2-6.fc9.ppc64 requires /bin/sh tcd-utils-20061127-1.fc9.3.ppc requires /bin/sh 1:tcl-8.5.1-4.fc10.ppc requires /sbin/ldconfig 1:tcl-8.5.1-4.fc10.ppc64 requires /sbin/ldconfig tclabc-1.1.0-1.fc9.ppc requires /bin/sh tcldebugger-1.4-6.20061030cvs.fc9.noarch requires /bin/sh tclhttpd-3.5.1-19.fc9.ppc requires /bin/sh tclhttpd-3.5.1-19.fc9.ppc requires /sbin/chkconfig tclhttpd-3.5.1-19.fc9.ppc requires /bin/sh tclhttpd-3.5.1-19.fc9.ppc requires /sbin/service tcllib-1.10-2.fc9.noarch requires /bin/sh tclpro-1.5.0-11.20061030cvs.fc9.noarch requires /bin/sh tclx-8.4.0-10.fc9.ppc requires /sbin/ldconfig tcp_wrappers-libs-7.6-52.fc9.ppc requires /sbin/ldconfig tcp_wrappers-libs-7.6-52.fc9.ppc64 requires /sbin/ldconfig 14:tcpdump-3.9.8-4.fc9.ppc requires /bin/sh tcpreplay-3.3.0-1.fc10.ppc requires /usr/sbin/tcpdump tcsh-6.15-4.fc9.ppc requires /bin/sh teckit-2.2.1-3.fc9.ppc requires /sbin/ldconfig teckit-2.2.1-3.fc9.ppc64 requires /sbin/ldconfig teckit-devel-2.2.1-3.fc9.ppc requires /sbin/ldconfig teckit-devel-2.2.1-3.fc9.ppc64 requires /sbin/ldconfig tecnoballz-0.92-4.fc9.ppc requires /bin/sh teg-0.11.2-15.fc9.ppc requires /bin/sh telepathy-butterfly-0.3.1-1.fc9.noarch requires /usr/bin/python telepathy-glib-0.7.8-1.fc10.ppc requires /sbin/ldconfig telepathy-glib-0.7.8-1.fc10.ppc64 requires /sbin/ldconfig telepathy-mission-control-4.64-1.fc9.ppc requires /sbin/ldconfig telepathy-mission-control-4.64-1.fc9.ppc64 requires /sbin/ldconfig tellico-1.3.1-1.fc9.ppc requires /bin/sh tellico-1.3.1-1.fc9.ppc requires /usr/bin/env tempest-xscreensaver-0-0.6.20070929.fc9.ppc requires /bin/sh terminus-font-x11-4.20-8.fc8.noarch requires /bin/sh terminus-font-x11-4.20-8.fc8.noarch requires /usr/bin/fc-cache terminus-font-x11-4.20-8.fc8.noarch requires /usr/bin/mkfontdir testoob-1.13-4.fc9.noarch requires /usr/bin/env testoob-1.13-4.fc9.noarch requires /usr/bin/python tetex-IEEEtran-1.7.1-1.fc8.noarch requires /usr/bin/texhash tetex-IEEEtran-1.7.1-1.fc8.noarch requires /bin/sh tetex-IEEEtran-1.7.1-1.fc8.noarch requires /bin/sh tetex-bytefield-1.2a-3.fc6.noarch requires /bin/sh tetex-bytefield-1.2a-3.fc6.noarch requires /usr/bin/texhash tetex-dvipost-1.1-9.fc9.ppc requires /usr/bin/texhash tetex-elsevier-0.1.20071024-1.fc9.noarch requires /usr/bin/texhash tetex-eurofont-1.1.3-6.fc6.noarch requires /bin/sh tetex-font-cm-lgc-0.5-9.fc9.noarch requires /bin/sh tetex-font-kerkis-2.0-15.fc9.noarch requires /bin/sh tetex-fonts-hebrew-0.1-8.fc9.noarch requires /usr/bin/texhash tetex-fonts-hebrew-0.1-8.fc9.noarch requires /usr/bin/updmap-sys tetex-fonts-hebrew-0.1-8.fc9.noarch requires /bin/sh tetex-perltex-1.3-1.fc6.noarch requires /usr/bin/texhash tetex-perltex-1.3-1.fc6.noarch requires /usr/bin/perl tetex-perltex-1.3-1.fc6.noarch requires /bin/sh tetex-prosper-1.5-3.fc6.noarch requires /usr/bin/texhash tetex-prosper-1.5-3.fc6.noarch requires /bin/sh tetex-tex4ht-1.0.2008_02_28_2058-3.fc9.ppc requires /usr/bin/texhash tetex-tex4ht-1.0.2008_02_28_2058-3.fc9.ppc requires /usr/bin/perl tetex-tex4ht-1.0.2008_02_28_2058-3.fc9.ppc requires /usr/bin/dvipng tetex-tex4ht-1.0.2008_02_28_2058-3.fc9.ppc requires /bin/sh tetex-tex4ht-1.0.2008_02_28_2058-3.fc9.ppc requires /bin/sh tetex-unicode-0-7.20041017.fc6.noarch requires /bin/sh tetrinetx-1.13.16-4.fc9.ppc requires /bin/sh tetrinetx-1.13.16-4.fc9.ppc requires /sbin/chkconfig tetrinetx-1.13.16-4.fc9.ppc requires /usr/sbin/useradd tetrinetx-1.13.16-4.fc9.ppc requires /bin/sh tex-preview-11.85-7.fc9.noarch requires /bin/sh texi2html-1.78-3.fc8.noarch requires /bin/sh texi2html-1.78-3.fc8.noarch requires /usr/bin/perl texi2html-1.78-3.fc8.noarch requires /sbin/install-info texinfo-4.12-1.fc10.ppc requires /bin/sh texinfo-4.12-1.fc10.ppc requires /sbin/install-info texinfo-tex-4.12-1.fc10.ppc requires /bin/sh texinfo-tex-4.12-1.fc10.ppc requires /bin/sh texinfo-tex-4.12-1.fc10.ppc requires /usr/bin/texconfig-sys texlive-2007-31.fc10.ppc requires /bin/sh texlive-2007-31.fc10.ppc requires /usr/bin/fmtutil texlive-2007-31.fc10.ppc requires /bin/bash texlive-2007-31.fc10.ppc requires /bin/sh texlive-2007-31.fc10.ppc requires /sbin/restorecon texlive-afm-2007-31.fc10.ppc requires /bin/sh texlive-afm-2007-31.fc10.ppc requires /sbin/restorecon texlive-context-2007-31.fc10.ppc requires /bin/sh texlive-context-2007-31.fc10.ppc requires /sbin/restorecon texlive-context-2007-31.fc10.ppc requires /usr/bin/env texlive-context-2007-31.fc10.ppc requires /bin/sh texlive-doc-2007-31.fc10.ppc requires /usr/bin/env texlive-doc-2007-31.fc10.ppc requires /bin/sh texlive-dvips-2007-31.fc10.ppc requires /bin/sh texlive-dvips-2007-31.fc10.ppc requires /bin/sh texlive-dvips-2007-31.fc10.ppc requires /sbin/restorecon texlive-dviutils-2007-31.fc10.ppc requires /bin/sh texlive-dviutils-2007-31.fc10.ppc requires /sbin/restorecon texlive-dviutils-2007-31.fc10.ppc requires /bin/sh texlive-east-asian-2007-31.fc10.ppc requires /bin/sh texlive-east-asian-2007-31.fc10.ppc requires /bin/sh texlive-east-asian-2007-31.fc10.ppc requires /sbin/restorecon texlive-latex-2007-31.fc10.ppc requires /bin/sh texlive-latex-2007-31.fc10.ppc requires /sbin/install-info texlive-latex-2007-31.fc10.ppc requires /usr/bin/fmtutil texlive-latex-2007-31.fc10.ppc requires /bin/sh texlive-latex-2007-31.fc10.ppc requires /usr/bin/texconfig-sys texlive-latex-2007-31.fc10.ppc requires /usr/bin/fmtutil-sys texlive-latex-2007-31.fc10.ppc requires /sbin/restorecon texlive-texmf-2007-21.fc10.noarch requires /bin/sh texlive-texmf-2007-21.fc10.noarch requires /sbin/restorecon texlive-texmf-2007-21.fc10.noarch requires /bin/sh texlive-texmf-afm-2007-21.fc10.noarch requires /bin/sh texlive-texmf-afm-2007-21.fc10.noarch requires /sbin/restorecon texlive-texmf-context-2007-21.fc10.noarch requires /bin/sh texlive-texmf-context-2007-21.fc10.noarch requires /sbin/restorecon texlive-texmf-context-2007-21.fc10.noarch requires /usr/bin/env texlive-texmf-context-2007-21.fc10.noarch requires /bin/sh texlive-texmf-doc-2007-21.fc10.noarch requires /bin/sh texlive-texmf-doc-2007-21.fc10.noarch requires /sbin/restorecon texlive-texmf-doc-2007-21.fc10.noarch requires /usr/bin/perl texlive-texmf-doc-2007-21.fc10.noarch requires /usr/bin/env texlive-texmf-doc-2007-21.fc10.noarch requires /bin/sh texlive-texmf-dvips-2007-21.fc10.noarch requires /bin/sh texlive-texmf-dvips-2007-21.fc10.noarch requires /sbin/restorecon texlive-texmf-east-asian-2007-21.fc10.noarch requires /bin/sh texlive-texmf-east-asian-2007-21.fc10.noarch requires /sbin/restorecon texlive-texmf-fonts-2007-21.fc10.noarch requires /bin/sh texlive-texmf-fonts-2007-21.fc10.noarch requires /sbin/restorecon texlive-texmf-latex-2007-21.fc10.noarch requires /bin/sh texlive-texmf-latex-2007-21.fc10.noarch requires /sbin/restorecon texlive-texmf-xetex-2007-21.fc10.noarch requires /bin/sh texlive-texmf-xetex-2007-21.fc10.noarch requires /sbin/restorecon texlive-texmf-xetex-2007-21.fc10.noarch requires /usr/bin/perl texlive-utils-2007-31.fc10.ppc requires /usr/bin/env texlive-utils-2007-31.fc10.ppc requires /usr/bin/perl texlive-utils-2007-31.fc10.ppc requires /bin/sh texlive-xetex-2007-31.fc10.ppc requires /bin/sh texlive-xetex-2007-31.fc10.ppc requires /sbin/restorecon 1:texmaker-1.7-1.fc10.ppc requires /bin/sh textflow-0.2.3.1-1.fc10.noarch requires /usr/bin/python tftp-server-0.48-3.fc9.ppc requires /bin/sh tftp-server-0.48-3.fc9.ppc requires /sbin/service tgif-4.1.45-6.fc9.ppc requires /bin/sh tgif-4.1.45-6.fc9.ppc requires /bin/bash thaifonts-scalable-0.4.9-3.fc9.noarch requires /bin/sh themonospot-0.7.0.1-1.fc10.ppc requires /bin/sh thinkfinger-0.3-8.fc9.ppc requires /sbin/ldconfig thinkfinger-0.3-8.fc9.ppc64 requires /sbin/ldconfig thttpd-2.25b-16.fc9.ppc requires /bin/sh thttpd-2.25b-16.fc9.ppc requires /bin/bash thttpd-2.25b-16.fc9.ppc requires /sbin/chkconfig thttpd-2.25b-16.fc9.ppc requires /usr/sbin/groupadd thttpd-2.25b-16.fc9.ppc requires /usr/sbin/useradd thttpd-2.25b-16.fc9.ppc requires /bin/sh thttpd-2.25b-16.fc9.ppc requires /sbin/service thunar-archive-plugin-0.2.4-4.fc9.ppc requires /bin/sh thunar-archive-plugin-0.2.4-4.fc9.ppc requires /bin/sh thunar-shares-0.10-1.fc8.ppc requires /bin/sh thunar-volman-0.2.0-2.fc9.ppc requires /bin/sh thunar-volman-0.2.0-2.fc9.ppc requires /bin/sh thunderbird-2.0.0.14-1.fc10.ppc requires /bin/bash thunderbird-2.0.0.14-1.fc10.ppc requires /bin/sh thunderbird-2.0.0.14-1.fc10.ppc requires /bin/sh thunderbird-lightning-0.8-3.fc9.ppc requires libhunspell.so.1 thunderbird-lightning-0.8-3.fc9.ppc requires /bin/sh thunderbird-lightning-0.8-3.fc9.ppc requires /bin/sh tibetan-machine-uni-fonts-1.901-1.fc9.noarch requires /bin/sh tiger-3.2.1-8.fc9.ppc requires /usr/bin/perl tiger-3.2.1-8.fc9.ppc requires /bin/sh time-1.7-33.fc9.ppc requires /bin/sh time-1.7-33.fc9.ppc requires /sbin/install-info timidity++-2.13.2-16.fc10.ppc requires /bin/sh tin-1.8.3-4.fc9.ppc requires /usr/bin/perl tin-1.8.3-4.fc9.ppc requires /bin/sh tinyca2-0.7.5-3.fc7.noarch requires /usr/bin/perl tinyerp-4.2.2-1.fc9.noarch requires /bin/sh tinyerp-server-4.2.2-1.fc9.noarch requires /bin/sh tinyerp-server-4.2.2-1.fc9.noarch requires /usr/bin/python tinyerp-server-4.2.2-1.fc9.noarch requires /sbin/service tinyerp-server-4.2.2-1.fc9.noarch requires /bin/bash tinyerp-server-4.2.2-1.fc9.noarch requires /bin/sh tinyerp-server-4.2.2-1.fc9.noarch requires /sbin/chkconfig tinyproxy-1.6.3-2.fc10.ppc requires /bin/sh tinyproxy-1.6.3-2.fc10.ppc requires /bin/sh tinyxml-2.5.3-3.fc9.ppc requires /sbin/ldconfig tinyxml-2.5.3-3.fc9.ppc64 requires /sbin/ldconfig tiobench-0.3.3-7.1.ppc requires /usr/bin/perl tiresias-fonts-1.0-2.fc9.noarch requires /bin/sh 1:tix-8.4.2-5.fc9.ppc requires /etc/ld.so.conf.d 1:tix-8.4.2-5.fc9.ppc requires /sbin/ldconfig 1:tix-8.4.2-5.fc9.ppc64 requires /etc/ld.so.conf.d 1:tix-8.4.2-5.fc9.ppc64 requires /sbin/ldconfig 1:tk-8.5.1-4.fc10.ppc requires /bin/sh 1:tk-8.5.1-4.fc10.ppc requires /sbin/ldconfig 1:tk-8.5.1-4.fc10.ppc requires /bin/sh 1:tk-8.5.1-4.fc10.ppc64 requires /bin/sh 1:tk-8.5.1-4.fc10.ppc64 requires /sbin/ldconfig 1:tk-8.5.1-4.fc10.ppc64 requires /bin/sh tkcon-2.4-6.fc8.noarch requires /bin/sh tkcvs-8.1-1.fc9.noarch requires /bin/sh tkimg-1.3-0.10.20080505svn.fc10.ppc requires /sbin/ldconfig tklib-0.4.1-7.fc9.noarch requires /bin/sh tla-1.3.5-5.fc9.ppc requires /bin/sh tmda-1.1.12-1.fc8.noarch requires /usr/bin/python tmda-ofmipd-1.1.12-1.fc8.noarch requires /bin/sh tmda-ofmipd-1.1.12-1.fc8.noarch requires /bin/bash tmda-ofmipd-1.1.12-1.fc8.noarch requires /sbin/chkconfig tmda-ofmipd-1.1.12-1.fc8.noarch requires /usr/bin/python tmpwatch-2.9.13-2.ppc requires /bin/sh tn5250-0.17.3-19.fc9.ppc requires /bin/sh tn5250-0.17.3-19.fc9.ppc requires /usr/bin/tic tn5250-0.17.3-19.fc9.ppc requires /sbin/ldconfig tn5250-0.17.3-19.fc9.ppc requires /bin/sh tn5250-0.17.3-19.fc9.ppc64 requires /bin/sh tn5250-0.17.3-19.fc9.ppc64 requires /sbin/ldconfig tn5250-0.17.3-19.fc9.ppc64 requires /usr/bin/tic tn5250-0.17.3-19.fc9.ppc64 requires /bin/sh tn5250-devel-0.17.3-19.fc9.ppc requires /bin/sh tn5250-devel-0.17.3-19.fc9.ppc64 requires /bin/sh 2:tog-pegasus-2.7.0-7.fc10.ppc requires /sbin/ldconfig 2:tog-pegasus-2.7.0-7.fc10.ppc requires /bin/sh 2:tog-pegasus-2.7.0-7.fc10.ppc requires /bin/bash 2:tog-pegasus-2.7.0-7.fc10.ppc64 requires /sbin/ldconfig 2:tog-pegasus-2.7.0-7.fc10.ppc64 requires /bin/sh 2:tog-pegasus-2.7.0-7.fc10.ppc64 requires /bin/bash 2:tog-pegasus-devel-2.7.0-7.fc10.ppc requires /bin/sh 2:tog-pegasus-devel-2.7.0-7.fc10.ppc64 requires /bin/sh tokyocabinet-1.2.5-1.fc10.ppc requires /sbin/ldconfig tokyocabinet-1.2.5-1.fc10.ppc64 requires /sbin/ldconfig tolua++-1.0.92-7.fc9.ppc requires /sbin/ldconfig tolua++-1.0.92-7.fc9.ppc64 requires /sbin/ldconfig tomboy-0.10.1-2.fc9.ppc requires /usr/bin/env tomboy-0.10.1-2.fc9.ppc requires /bin/sh tomcat-native-1.1.13-1.fc9.ppc requires /sbin/ldconfig tomcat-native-1.1.13-1.fc9.ppc64 requires /sbin/ldconfig tomcat5-5.5.26-1jpp.2.fc9.ppc requires /bin/sh tomcat5-5.5.26-1jpp.2.fc9.ppc requires /usr/sbin/groupadd tomcat5-5.5.26-1jpp.2.fc9.ppc requires /usr/sbin/useradd tomcat5-5.5.26-1jpp.2.fc9.ppc requires /sbin/chkconfig tomcat5-5.5.26-1jpp.2.fc9.ppc requires /bin/bash tomcat5-5.5.26-1jpp.2.fc9.ppc requires /bin/sh tomcat5-5.5.26-1jpp.2.fc9.ppc requires /bin/rm tomcat5-admin-webapps-5.5.26-1jpp.2.fc9.ppc requires /bin/sh tomcat5-admin-webapps-5.5.26-1jpp.2.fc9.ppc requires /bin/rm tomcat5-common-lib-5.5.26-1jpp.2.fc9.ppc requires /bin/sh tomcat5-common-lib-5.5.26-1jpp.2.fc9.ppc requires /bin/rm tomcat5-jasper-5.5.26-1jpp.2.fc9.ppc requires /bin/sh tomcat5-jasper-eclipse-5.5.26-1jpp.2.fc9.ppc requires /bin/sh tomcat5-jsp-2.0-api-5.5.26-1jpp.2.fc9.ppc requires /bin/sh tomcat5-jsp-2.0-api-5.5.26-1jpp.2.fc9.ppc requires /sbin/chkconfig tomcat5-jsp-2.0-api-5.5.26-1jpp.2.fc9.ppc requires /usr/sbin/update-alternatives tomcat5-jsp-2.0-api-javadoc-5.5.26-1jpp.2.fc9.ppc requires /bin/sh tomcat5-jsp-2.0-api-javadoc-5.5.26-1jpp.2.fc9.ppc requires /bin/rm tomcat5-jsp-2.0-api-javadoc-5.5.26-1jpp.2.fc9.ppc requires /bin/ln tomcat5-server-lib-5.5.26-1jpp.2.fc9.ppc requires /bin/sh tomcat5-server-lib-5.5.26-1jpp.2.fc9.ppc requires /bin/rm tomcat5-servlet-2.4-api-5.5.26-1jpp.2.fc9.ppc requires /bin/sh tomcat5-servlet-2.4-api-5.5.26-1jpp.2.fc9.ppc requires /sbin/chkconfig tomcat5-servlet-2.4-api-5.5.26-1jpp.2.fc9.ppc requires /usr/sbin/update-alternatives tomcat5-servlet-2.4-api-javadoc-5.5.26-1jpp.2.fc9.ppc requires /bin/sh tomcat5-servlet-2.4-api-javadoc-5.5.26-1jpp.2.fc9.ppc requires /bin/rm tomcat5-servlet-2.4-api-javadoc-5.5.26-1jpp.2.fc9.ppc requires /bin/ln tomcat5-webapps-5.5.26-1jpp.2.fc9.ppc requires /bin/sh tomcat5-webapps-5.5.26-1jpp.2.fc9.ppc requires /bin/rm tomcat6-6.0.16-1jpp.7.fc9.noarch requires /bin/sh tomcat6-6.0.16-1jpp.7.fc9.noarch requires /sbin/chkconfig tomcat6-6.0.16-1jpp.7.fc9.noarch requires /sbin/service tomcat6-jsp-2.1-api-6.0.16-1jpp.7.fc9.noarch requires /bin/sh tomcat6-lib-6.0.16-1jpp.7.fc9.noarch requires /bin/sh tomcat6-servlet-2.5-api-6.0.16-1jpp.7.fc9.noarch requires /bin/sh tomcat6-webapps-6.0.16-1jpp.7.fc9.noarch requires /bin/sh tomoe-0.6.0-5.fc9.ppc requires /sbin/ldconfig tomoe-0.6.0-5.fc9.ppc64 requires /sbin/ldconfig tong-1.0-10.fc9.ppc requires /bin/sh toped-0.8.6-2.fc9.ppc requires /bin/sh toped-0.8.6-2.fc9.ppc64 requires /bin/sh tor-core-0.1.2.19-1.fc9.ppc requires /bin/sh tor-core-0.1.2.19-1.fc9.ppc requires /etc/logrotate.d tor-lsb-0.1.2.19-1.fc9.ppc requires /bin/sh tor-lsb-0.1.2.19-1.fc9.ppc requires /bin/sh torcs-1.3.0-6.fc9.ppc requires libplibssgaux.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibssg.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires /bin/bash torcs-1.3.0-6.fc9.ppc requires libplibsl.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibsm.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibsg.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibul.so.1.8.4 torque-2.1.10-5.fc9.ppc requires /bin/sh torque-2.1.10-5.fc9.ppc requires /bin/sh torque-client-2.1.10-5.fc9.ppc requires /bin/sh torque-gui-2.1.10-5.fc9.ppc requires /usr/bin/pbs_wish torque-gui-2.1.10-5.fc9.ppc requires /usr/bin/wish8.5 torque-mom-2.1.10-5.fc9.ppc requires /bin/sh torque-mom-2.1.10-5.fc9.ppc requires /bin/sh torque-scheduler-2.1.10-5.fc9.ppc requires /bin/sh torque-scheduler-2.1.10-5.fc9.ppc requires /bin/sh torque-server-2.1.10-5.fc9.ppc requires /bin/sh torque-server-2.1.10-5.fc9.ppc requires /bin/sh totem-2.23.2-2.fc9.ppc requires /bin/sh totem-2.23.2-2.fc9.ppc requires /usr/bin/python totem-2.23.2-2.fc9.ppc requires libtotem-plparser.so.10 totem-2.23.2-2.fc9.ppc requires /bin/sh totem-2.23.2-2.fc9.ppc64 requires /bin/sh totem-2.23.2-2.fc9.ppc64 requires /usr/bin/python totem-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) totem-2.23.2-2.fc9.ppc64 requires /bin/sh totem-gstreamer-2.23.2-2.fc9.ppc requires /bin/sh totem-gstreamer-2.23.2-2.fc9.ppc64 requires /bin/sh totem-mozplugin-2.23.2-2.fc9.ppc requires libtotem-plparser-mini.so.10 totem-mozplugin-2.23.2-2.fc9.ppc requires libtotem-plparser.so.10 totem-mythtv-2.23.2-2.fc9.ppc requires /bin/sh totem-nautilus-2.23.2-2.fc9.ppc requires libtotem-plparser.so.10 totem-pl-parser-2.23.1-2.fc10.ppc requires /sbin/ldconfig totem-pl-parser-2.23.1-2.fc10.ppc64 requires /sbin/ldconfig totem-xine-2.23.2-2.fc9.ppc requires /bin/sh totem-xine-2.23.2-2.fc9.ppc64 requires /bin/sh tpm-tools-1.3.1-5.fc9.ppc requires /sbin/ldconfig tpm-tools-1.3.1-5.fc9.ppc64 requires /sbin/ldconfig trac-0.10.4-2.fc9.noarch requires /usr/bin/python trackballs-1.1.4-6.fc9.ppc requires /bin/sh tracker-0.6.6-2.fc9.ppc requires /sbin/ldconfig tracker-0.6.6-2.fc9.ppc requires /bin/sh tracker-0.6.6-2.fc9.ppc64 requires /sbin/ldconfig tracker-0.6.6-2.fc9.ppc64 requires /bin/sh tracker-search-tool-0.6.6-2.fc9.ppc requires /bin/sh 1:transfig-3.2.5-2.fc9.ppc requires /bin/csh 1:transfig-3.2.5-2.fc9.ppc requires /bin/sh translate-toolkit-1.0.1-1.fc9.noarch requires /bin/bash translate-toolkit-1.0.1-1.fc9.noarch requires /usr/bin/python transmission-1.20-1.fc10.ppc requires /bin/sh tre-0.7.5-5.fc9.ppc requires /sbin/ldconfig tre-0.7.5-5.fc9.ppc64 requires /sbin/ldconfig treecc-0.3.8-5.fc9.ppc requires /bin/sh tremulous-1.1.0-6.fc9.ppc requires /bin/sh tripwire-2.4.1.2-5.fc9.ppc requires /bin/sh tripwire-2.4.1.2-5.fc9.ppc requires /bin/sh trousers-0.3.1-5.fc9.ppc requires /sbin/service trousers-0.3.1-5.fc9.ppc requires /sbin/ldconfig trousers-0.3.1-5.fc9.ppc requires /bin/bash trousers-0.3.1-5.fc9.ppc requires /sbin/chkconfig trousers-0.3.1-5.fc9.ppc requires /bin/sh trousers-0.3.1-5.fc9.ppc64 requires /bin/sh trousers-0.3.1-5.fc9.ppc64 requires /sbin/service trousers-0.3.1-5.fc9.ppc64 requires /sbin/chkconfig trousers-0.3.1-5.fc9.ppc64 requires /sbin/ldconfig trousers-0.3.1-5.fc9.ppc64 requires /bin/bash ttywatch-0.14-11.fc9.ppc requires /bin/sh ttywatch-0.14-11.fc9.ppc requires /sbin/chkconfig ttywatch-0.14-11.fc9.ppc requires /bin/sh ttywatch-0.14-11.fc9.ppc requires /sbin/service turba-2.1.7-1.fc9.noarch requires /usr/bin/perl turba-2.1.7-1.fc9.noarch requires /usr/bin/php turba-2.1.7-1.fc9.noarch requires /bin/sh 1:tuxpaint-0.9.17-3.fc9.ppc requires /usr/share/icons/hicolor/scalable 1:tuxpaint-0.9.17-3.fc9.ppc requires /bin/sh tuxpuck-0.8.2-6.fc10.ppc requires /bin/sh tvtime-1.0.2-2.fc9.ppc requires /bin/sh twitux-0.62-1.fc10.ppc requires /bin/sh ucarp-1.4-1.fc9.ppc requires /bin/sh ucarp-1.4-1.fc9.ppc requires /bin/bash ucarp-1.4-1.fc9.ppc requires /sbin/chkconfig ucarp-1.4-1.fc9.ppc requires /bin/sh ucarp-1.4-1.fc9.ppc requires /sbin/service ucblogo-5.5-10.fc9.ppc requires /bin/sh ucblogo-5.5-10.fc9.ppc requires /sbin/install-info ucl-1.03-8.fc9.ppc requires /sbin/ldconfig ucl-1.03-8.fc9.ppc64 requires /sbin/ldconfig udev-121-1.20080516git.fc10.ppc requires /bin/sh udev-121-1.20080516git.fc10.ppc requires /sbin/service udev-121-1.20080516git.fc10.ppc requires /bin/bash udev-121-1.20080516git.fc10.ppc requires /bin/sh udev-121-1.20080516git.fc10.ppc requires /sbin/chkconfig udev-packagekit-0.2.1-2.20080508.fc10.ppc requires /bin/sh ufraw-0.13-4.fc9.ppc requires /bin/sh ufraw-common-0.13-4.fc9.ppc requires /bin/sh uim-1.4.2-3.fc10.ppc requires /bin/sh uim-1.4.2-3.fc10.ppc requires /sbin/ldconfig uim-1.4.2-3.fc10.ppc requires /usr/sbin/alternatives uim-1.4.2-3.fc10.ppc64 requires /bin/sh uim-1.4.2-3.fc10.ppc64 requires /sbin/ldconfig uim-1.4.2-3.fc10.ppc64 requires /usr/sbin/alternatives uim-anthy-1.4.2-3.fc10.ppc requires /bin/sh uim-anthy-1.4.2-3.fc10.ppc requires /usr/bin/uim-module-manager uim-canna-1.4.2-3.fc10.ppc requires /bin/sh uim-canna-1.4.2-3.fc10.ppc requires /usr/bin/uim-module-manager uim-gnome-1.4.2-3.fc10.ppc requires /usr/sbin/bonobo-activation-sysconf uim-gnome-1.4.2-3.fc10.ppc requires /bin/sh uim-gtk2-1.4.2-3.fc10.ppc requires /bin/sh uim-m17n-1.4.2-3.fc10.ppc requires /bin/sh uim-m17n-1.4.2-3.fc10.ppc requires /usr/bin/uim-module-manager uim-skk-1.4.2-3.fc10.ppc requires /bin/sh uim-skk-1.4.2-3.fc10.ppc requires /usr/bin/uim-module-manager ularn-1.5p4-11.fc9.ppc requires /bin/sh ulogd-1.24-9.fc9.ppc requires /bin/sh ulogd-1.24-9.fc9.ppc requires /bin/sh unicap-0.2.19-3.fc9.ppc requires /sbin/ldconfig unicap-0.2.19-3.fc9.ppc64 requires /sbin/ldconfig uniconvertor-1.1.2-2.fc10.ppc requires /bin/sh uniconvertor-1.1.2-2.fc10.ppc requires /usr/bin/python unifdef-1.171-7.fc9.ppc requires /bin/sh unique-0.9.4-5.fc10.ppc requires /sbin/ldconfig unique-0.9.4-5.fc10.ppc64 requires /sbin/ldconfig unison213-2.13.16-10.fc9.ppc requires /usr/sbin/alternatives unison213-2.13.16-10.fc9.ppc requires /usr/sbin/alternatives unison213-2.13.16-10.fc9.ppc requires /bin/sh unison213-2.13.16-10.fc9.ppc requires /bin/sh unison227-2.27.57-8.fc9.ppc requires /usr/sbin/alternatives unison227-2.27.57-8.fc9.ppc requires /usr/sbin/alternatives unison227-2.27.57-8.fc9.ppc requires /bin/sh unison227-2.27.57-8.fc9.ppc requires /bin/sh units-1.87-2.fc9.ppc requires /bin/sh units-1.87-2.fc9.ppc requires /sbin/install-info unixODBC-2.2.12-7.fc9.ppc requires /sbin/ldconfig unixODBC-2.2.12-7.fc9.ppc64 requires /sbin/ldconfig unixODBC-kde-2.2.12-7.fc9.ppc requires /sbin/ldconfig unixODBC-kde-2.2.12-7.fc9.ppc64 requires /sbin/ldconfig unixcw-2.3-2.fc9.ppc requires /sbin/ldconfig unixcw-2.3-2.fc9.ppc64 requires /sbin/ldconfig unshield-0.5-8.fc9.ppc requires /sbin/ldconfig unshield-0.5-8.fc9.ppc64 requires /sbin/ldconfig unuran-1.2.4p1-1.fc10.ppc requires /bin/sh unuran-1.2.4p1-1.fc10.ppc requires /sbin/ldconfig unuran-1.2.4p1-1.fc10.ppc requires /sbin/install-info unuran-1.2.4p1-1.fc10.ppc64 requires /bin/sh unuran-1.2.4p1-1.fc10.ppc64 requires /sbin/ldconfig unuran-1.2.4p1-1.fc10.ppc64 requires /sbin/install-info unzip-5.52-9.fc9.ppc requires /bin/sh up-imapproxy-1.2.4-9.fc9.ppc requires /bin/sh up-imapproxy-1.2.4-9.fc9.ppc requires /sbin/service up-imapproxy-1.2.4-9.fc9.ppc requires /bin/bash up-imapproxy-1.2.4-9.fc9.ppc requires /sbin/chkconfig uqm-0.6.2-3.fc9.ppc requires /bin/sh urbanterror-1.34-0.9.rc4.fc9.ppc requires /bin/sh urbanterror-1.34-0.9.rc4.fc9.ppc requires /bin/bash urlview-0.9-4.fc9.ppc requires /bin/bash urw-fonts-2.4-5.fc9.noarch requires /bin/sh usermode-1.97-1.ppc requires /etc/pam.d/system-auth ushare-1.1a-4.fc9.ppc requires /bin/sh ushare-1.1a-4.fc9.ppc requires /sbin/service ushare-1.1a-4.fc9.ppc requires /usr/sbin/alternatives ushare-1.1a-4.fc9.ppc requires /usr/sbin/alternatives ushare-1.1a-4.fc9.ppc requires /bin/sh ushare-1.1a-4.fc9.ppc requires /sbin/chkconfig usrp-3.1.1-4.fc9.ppc requires /usr/bin/env usrp-3.1.1-4.fc9.ppc requires /sbin/ldconfig usrp-3.1.1-4.fc9.ppc64 requires /usr/bin/env usrp-3.1.1-4.fc9.ppc64 requires /sbin/ldconfig ustr-1.0.4-6.fc9.ppc requires /sbin/ldconfig ustr-1.0.4-6.fc9.ppc64 requires /sbin/ldconfig ustr-debug-1.0.4-6.fc9.ppc requires /sbin/ldconfig ustr-debug-1.0.4-6.fc9.ppc64 requires /sbin/ldconfig ustr-devel-1.0.4-6.fc9.ppc requires /bin/sh ustr-devel-1.0.4-6.fc9.ppc64 requires /bin/sh util-linux-ng-2.13.1-9.fc10.ppc requires /bin/sh util-linux-ng-2.13.1-9.fc10.ppc requires /sbin/install-info util-linux-ng-2.13.1-9.fc10.ppc requires /etc/pam.d/system-auth util-vserver-0.30.215-2.fc9.ppc requires /bin/sh util-vserver-0.30.215-2.fc9.ppc requires /usr/lib/util-vserver util-vserver-0.30.215-2.fc9.ppc requires /bin/bash util-vserver-0.30.215-2.fc9.ppc requires /usr/lib/util-vserver/sigexec util-vserver-0.30.215-2.fc9.ppc requires /bin/sh util-vserver-build-0.30.215-2.fc9.ppc requires /etc/vservers util-vserver-build-0.30.215-2.fc9.ppc requires /bin/sh util-vserver-build-0.30.215-2.fc9.ppc requires /bin/bash util-vserver-build-0.30.215-2.fc9.ppc requires /bin/sh util-vserver-core-0.30.215-2.fc9.ppc requires /bin/bash util-vserver-legacy-0.30.215-2.fc9.ppc requires /bin/bash util-vserver-legacy-0.30.215-2.fc9.ppc requires /bin/sh util-vserver-legacy-0.30.215-2.fc9.ppc requires /usr/bin/perl util-vserver-legacy-0.30.215-2.fc9.ppc requires /usr/lib/util-vserver util-vserver-legacy-0.30.215-2.fc9.ppc requires /sbin/chkconfig util-vserver-legacy-0.30.215-2.fc9.ppc requires /etc/rc.d/init.d util-vserver-legacy-0.30.215-2.fc9.ppc requires /bin/sh util-vserver-lib-0.30.215-2.fc9.ppc requires /sbin/ldconfig util-vserver-lib-0.30.215-2.fc9.ppc64 requires /sbin/ldconfig util-vserver-sysv-0.30.215-2.fc9.ppc requires /bin/sh util-vserver-sysv-0.30.215-2.fc9.ppc requires /bin/bash util-vserver-sysv-0.30.215-2.fc9.ppc requires /usr/lib/util-vserver util-vserver-sysv-0.30.215-2.fc9.ppc requires /sbin/chkconfig util-vserver-sysv-0.30.215-2.fc9.ppc requires /etc/rc.d/init.d util-vserver-sysv-0.30.215-2.fc9.ppc requires /bin/sh uucp-1.07-17.fc9.ppc requires /bin/sh uucp-1.07-17.fc9.ppc requires /bin/sh uucp-1.07-17.fc9.ppc requires /usr/bin/perl uucp-1.07-17.fc9.ppc requires /sbin/install-info uudeview-0.5.20-16.ppc requires /bin/sh uuid-1.6.1-3.fc9.ppc requires /sbin/ldconfig uuid-1.6.1-3.fc9.ppc64 requires /sbin/ldconfig uuid-c++-1.6.1-3.fc9.ppc requires /sbin/ldconfig uuid-c++-1.6.1-3.fc9.ppc64 requires /sbin/ldconfig uuid-dce-1.6.1-3.fc9.ppc requires /sbin/ldconfig uuid-dce-1.6.1-3.fc9.ppc64 requires /sbin/ldconfig uuid-devel-1.6.1-3.fc9.ppc requires /bin/sh uuid-devel-1.6.1-3.fc9.ppc requires /usr/lib/pkgconfig uuid-devel-1.6.1-3.fc9.ppc64 requires /usr/lib64/pkgconfig uuid-devel-1.6.1-3.fc9.ppc64 requires /bin/sh uuid-pgsql-1.6.1-3.fc9.ppc requires /usr/lib/pgsql uuid-pgsql-1.6.1-3.fc9.ppc requires /usr/share/pgsql uuid-php-1.6.1-3.fc9.ppc requires /usr/lib/php/modules uuidd-1.40.9-2.fc10.ppc requires /bin/sh uuidd-1.40.9-2.fc10.ppc requires /bin/bash uw-imap-2007a1-3.fc9.ppc requires /bin/sh vala-0.1.7-1.fc9.ppc requires /sbin/ldconfig vala-0.1.7-1.fc9.ppc64 requires /sbin/ldconfig vala-tools-0.1.7-1.fc9.ppc requires /bin/sh 1:valgrind-3.3.0-3.ppc requires /usr/bin/perl 1:valgrind-3.3.0-3.ppc64 requires /usr/bin/perl vamp-plugin-sdk-1.1b-4.fc9.ppc requires /sbin/ldconfig vamp-plugin-sdk-1.1b-4.fc9.ppc64 requires /sbin/ldconfig varconf-0.6.5-3.fc9.ppc requires /sbin/ldconfig varconf-0.6.5-3.fc9.ppc64 requires /sbin/ldconfig varnish-1.1.2-6.fc9.ppc requires /bin/sh varnish-1.1.2-6.fc9.ppc requires /sbin/service varnish-1.1.2-6.fc9.ppc requires /bin/sh varnish-1.1.2-6.fc9.ppc requires /sbin/chkconfig varnish-libs-1.1.2-6.fc9.ppc requires /sbin/ldconfig varnish-libs-1.1.2-6.fc9.ppc64 requires /sbin/ldconfig vavoom-1.27.1-1.fc9.ppc requires /bin/sh vavoom-1.27.1-1.fc9.ppc requires /bin/bash vblade-14-4.fc9.ppc requires /bin/sh vblade-14-4.fc9.ppc requires /sbin/chkconfig vblade-14-4.fc9.ppc requires /bin/sh vblade-14-4.fc9.ppc requires /sbin/service vdccm-0.10.1-3.fc9.ppc requires /sbin/ldconfig vdr-1.6.0-3.fc9.ppc requires /bin/sh vdr-1.6.0-3.fc9.ppc requires /bin/bash vdr-1.6.0-3.fc9.ppc requires /bin/sh vdr-1.6.0-3.fc9.ppc requires /usr/bin/perl vdr-1.6.0-3.fc9.ppc requires /sbin/chkconfig vdr-devel-1.6.0-3.fc9.ppc requires /bin/bash vdr-devel-1.6.0-3.fc9.ppc requires /usr/bin/perl vdr-devel-1.6.0-3.fc9.ppc64 requires /bin/bash vdr-devel-1.6.0-3.fc9.ppc64 requires /usr/bin/perl vdr-osdteletext-0.5.1-31.fc9.ppc requires /bin/sh vdr-skins-20061119-6.fc9.noarch requires /bin/sh vdr-text2skin-1.1-23.cvsext0.10.fc9.ppc requires /bin/sh vdradmin-am-3.6.1-1.fc8.noarch requires /bin/sh vdradmin-am-3.6.1-1.fc8.noarch requires /usr/bin/perl vdradmin-am-3.6.1-1.fc8.noarch requires /bin/sh vdradmin-am-3.6.1-1.fc8.noarch requires /sbin/chkconfig vdrift-20071226-3.fc9.ppc requires /bin/sh vecmath1.2-1.14-2.fc9.ppc requires /bin/sh vecmath1.2-javadoc-1.14-2.fc9.ppc requires /bin/sh vegastrike-0.5.0-2.fc10.ppc requires /usr/bin/perl vegastrike-0.5.0-2.fc10.ppc requires /bin/sh vegastrike-data-0.5.0-2.noarch requires /bin/sh vegastrike-data-0.5.0-2.noarch requires /usr/bin/python velocity-1.4-7jpp.1.ppc requires /bin/sh velocity-demo-1.4-7jpp.1.ppc requires /bin/sh velocity-javadoc-1.4-7jpp.1.ppc requires /bin/sh velocity-javadoc-1.4-7jpp.1.ppc requires /bin/rm velocity-javadoc-1.4-7jpp.1.ppc requires /bin/ln verbiste-0.1.22-1.fc9.ppc requires /sbin/ldconfig verbiste-0.1.22-1.fc9.ppc64 requires /sbin/ldconfig verbiste-gnome-0.1.22-1.fc9.ppc requires /bin/sh veusz-1.0-3.fc9.ppc requires /bin/sh veusz-1.0-3.fc9.ppc requires /usr/bin/env veusz-1.0-3.fc9.ppc requires /usr/bin/python viewvc-1.0.5-1.fc9.noarch requires /usr/bin/python vigra-1.5.0-4.fc9.ppc requires /sbin/ldconfig vigra-1.5.0-4.fc9.ppc64 requires /sbin/ldconfig vigra-devel-1.5.0-4.fc9.ppc requires /bin/sh vigra-devel-1.5.0-4.fc9.ppc64 requires /bin/sh 2:vim-X11-7.1.298-1.fc10.ppc requires /bin/sh 2:vim-X11-7.1.298-1.fc10.ppc requires /bin/sh 2:vim-common-7.1.298-1.fc10.ppc requires /bin/sh 2:vim-enhanced-7.1.298-1.fc10.ppc requires /bin/sh vim-vimoutliner-0.3.4-9.fc7.noarch requires /bin/sh vim-vimoutliner-0.3.4-9.fc7.noarch requires /usr/bin/perl vim-vimoutliner-0.3.4-9.fc7.noarch requires /usr/bin/python vinagre-2.23.1-1.fc10.ppc requires /bin/sh vino-2.22.1-1.fc9.ppc requires /bin/sh vips-7.14.1-1.fc9.ppc requires /sbin/ldconfig vips-7.14.1-1.fc9.ppc requires libWand.so.10 vips-7.14.1-1.fc9.ppc requires libMagick.so.10 vips-7.14.1-1.fc9.ppc64 requires /sbin/ldconfig vips-7.14.1-1.fc9.ppc64 requires libMagick.so.10()(64bit) vips-7.14.1-1.fc9.ppc64 requires libWand.so.10()(64bit) vips-python-7.14.1-1.fc9.ppc requires libWand.so.10 vips-python-7.14.1-1.fc9.ppc requires libMagick.so.10 vips-tools-7.14.1-1.fc9.ppc requires /bin/bash vips-tools-7.14.1-1.fc9.ppc requires /bin/sh vips-tools-7.14.1-1.fc9.ppc requires libWand.so.10 vips-tools-7.14.1-1.fc9.ppc requires libMagick.so.10 virt-manager-0.5.4-3.fc9.ppc requires /bin/sh virt-manager-0.5.4-3.fc9.ppc requires /bin/sh vkeybd-0.1.17a-7.fc9.ppc requires /bin/sh vkeybd-0.1.17a-7.fc9.ppc requires /usr/bin/wish vlock-1.3-26.fc9.ppc requires /etc/pam.d/system-auth vnc-4.1.2-30.fc10.ppc requires /bin/sh vnc-libs-4.1.2-30.fc10.ppc requires /bin/sh vnc-libs-4.1.2-30.fc10.ppc64 requires /bin/sh vnc-ltsp-config-4.0-4.fc9.noarch requires /bin/sh vnc-ltsp-config-4.0-4.fc9.noarch requires /bin/sh vnc-server-4.1.2-30.fc10.ppc requires /bin/sh vnc-server-4.1.2-30.fc10.ppc requires /usr/bin/env vnc-server-4.1.2-30.fc10.ppc requires /bin/bash vnstat-1.6-2.fc9.ppc requires /bin/sh vnstat-1.6-2.fc9.ppc requires /usr/sbin/useradd vodovod-1.10-2.fc9.ppc requires /bin/sh vodovod-1.10-2.fc9.ppc requires /bin/sh vpnc-0.5.1-5.fc9.ppc requires /bin/sh vpnc-consoleuser-0.5.1-5.fc9.ppc requires /bin/sh vsftpd-2.0.6-3.fc9.ppc requires /bin/sh vsftpd-2.0.6-3.fc9.ppc requires /sbin/service vsftpd-2.0.6-3.fc9.ppc requires /bin/bash vsftpd-2.0.6-3.fc9.ppc requires /lib/security/pam_loginuid.so vsftpd-2.0.6-3.fc9.ppc requires /sbin/chkconfig vte-0.16.13-1.fc9.ppc requires /sbin/ldconfig vte-0.16.13-1.fc9.ppc64 requires /sbin/ldconfig vte-devel-0.16.13-1.fc9.ppc requires /bin/sh vte-devel-0.16.13-1.fc9.ppc64 requires /bin/sh vtk-5.0.4-21.fc9.ppc requires /sbin/ldconfig vtk-5.0.4-21.fc9.ppc64 requires /sbin/ldconfig vtk-devel-5.0.4-21.fc9.ppc requires /usr/bin/env vtk-devel-5.0.4-21.fc9.ppc64 requires /usr/bin/env vtk-python-5.0.4-21.fc9.ppc requires /sbin/ldconfig vtk-python-5.0.4-21.fc9.ppc64 requires /sbin/ldconfig vtk-qt-5.0.4-21.fc9.ppc requires /sbin/ldconfig vtk-qt-5.0.4-21.fc9.ppc64 requires /sbin/ldconfig vtk-tcl-5.0.4-21.fc9.ppc requires /sbin/ldconfig vtk-tcl-5.0.4-21.fc9.ppc64 requires /sbin/ldconfig vtk-testing-5.0.4-21.fc9.ppc requires /usr/bin/tclsh vtk-testing-5.0.4-21.fc9.ppc requires /usr/bin/env vym-1.10.0-3.fc9.ppc requires /bin/sh vym-1.10.0-3.fc9.ppc requires /usr/bin/perl vym-1.10.0-3.fc9.ppc requires /bin/bash w3c-libwww-5.4.1-0.10.20060206cvs.fc9.ppc requires /sbin/ldconfig w3c-libwww-5.4.1-0.10.20060206cvs.fc9.ppc64 requires /sbin/ldconfig w3c-libwww-devel-5.4.1-0.10.20060206cvs.fc9.ppc requires /bin/sh w3c-libwww-devel-5.4.1-0.10.20060206cvs.fc9.ppc64 requires /bin/sh w3c-markup-validator-0.8.2-3.fc9.noarch requires /bin/sh w3c-markup-validator-0.8.2-3.fc9.noarch requires /usr/bin/perl w3c-markup-validator-libs-0.8.2-3.fc9.noarch requires /bin/sh w3m-0.5.2-10.fc10.ppc requires /usr/bin/perl w3m-el-common-1.4.4-7.fc9.noarch requires /bin/sh w3m-el-common-1.4.4-7.fc9.noarch requires /sbin/install-info waf-1.4.1-1.fc10.noarch requires /usr/bin/python wallpapoz-0.4.1-5.svn87_trunk.fc9.noarch requires /usr/bin/pgrep wallpapoz-0.4.1-5.svn87_trunk.fc9.noarch requires /usr/bin/kill wallpapoz-0.4.1-5.svn87_trunk.fc9.noarch requires /usr/bin/env wammu-0.26-2.fc9.noarch requires /usr/bin/python wavbreaker-0.9-3.fc9.ppc requires /bin/sh wavextract-1.0.0-3.fc9.noarch requires /usr/bin/env wavpack-4.41-2.fc9.ppc requires /sbin/ldconfig wavpack-4.41-2.fc9.ppc64 requires /sbin/ldconfig wbxml2-0.9.2-13.fc9.ppc requires /sbin/ldconfig wbxml2-0.9.2-13.fc9.ppc64 requires /sbin/ldconfig wdaemon-0.13-1.fc9.ppc requires /bin/sh wdaemon-0.13-1.fc9.ppc requires /bin/bash wdm-1.28-10.fc9.ppc requires /etc/pam.d wdm-1.28-10.fc9.ppc requires /sbin/shutdown wdm-1.28-10.fc9.ppc requires /bin/bash wdm-1.28-10.fc9.ppc requires /bin/sh wdm-1.28-10.fc9.ppc requires /usr/bin/perl web2png-2.5.1-4.fc9.ppc requires /usr/bin/env webalizer-2.01_10-36.ppc requires /bin/sh webalizer-2.01_10-36.ppc requires /usr/sbin/useradd webalizer-2.01_10-36.ppc requires /bin/bash websec-1.9.0-4.1.noarch requires /usr/bin/perl werken-xpath-0.9.4-1.beta.12jpp.2.ppc requires /bin/sh werken-xpath-javadoc-0.9.4-1.beta.12jpp.2.ppc requires /bin/sh werken-xpath-javadoc-0.9.4-1.beta.12jpp.2.ppc requires /bin/ln werken-xpath-javadoc-0.9.4-1.beta.12jpp.2.ppc requires /bin/rm wesnoth-1.4.2-1.fc10.ppc requires /bin/sh wesnoth-server-1.4.2-1.fc10.ppc requires /bin/sh wesnoth-server-1.4.2-1.fc10.ppc requires /bin/sh wesnoth-server-1.4.2-1.fc10.ppc requires /sbin/chkconfig wesnoth-server-1.4.2-1.fc10.ppc requires /usr/sbin/useradd wesnoth-tools-1.4.2-1.fc10.ppc requires /usr/bin/env wfmath-0.3.7-2.fc9.ppc requires /sbin/ldconfig wfmath-0.3.7-2.fc9.ppc64 requires /sbin/ldconfig wfut-1.1.0-5.fc9.ppc requires /bin/sh wget-1.11.2-1.fc10.ppc requires /bin/sh wget-1.11.2-1.fc10.ppc requires /sbin/install-info which-2.19-3.fc9.ppc requires /bin/sh which-2.19-3.fc9.ppc requires /sbin/install-info whysynth-dssi-20070418-2.fc9.ppc requires /bin/sh widelands-0-0.9.build11.fc9.ppc requires /bin/sh wifi-radar-1.9.6-3.fc6.noarch requires /usr/bin/python wifiroamd-1.12-1.fc8.noarch requires /bin/sh wildmidi-libs-0.2.2-4.fc9.ppc requires /sbin/ldconfig wildmidi-libs-0.2.2-4.fc9.ppc64 requires /sbin/ldconfig wings-0.99.02-1.fc9.ppc requires /bin/sh winpdb-1.3.8-1.fc10.noarch requires /usr/bin/env winpdb-1.3.8-1.fc10.noarch requires /usr/bin/python 1:wireless-tools-29-2.fc9.ppc requires /sbin/ldconfig 1:wireless-tools-29-2.fc9.ppc64 requires /sbin/ldconfig wireshark-1.0.0-2.fc9.ppc requires /sbin/ldconfig wireshark-1.0.0-2.fc9.ppc64 requires /sbin/ldconfig wkf-libs-1.3.11-2.fc9.ppc requires /sbin/ldconfig wkf-libs-1.3.11-2.fc9.ppc64 requires /sbin/ldconfig wklej-0.0.9-3.fc9.noarch requires /usr/bin/perl wlassistant-0.5.7-7.fc9.ppc requires /bin/sh wmx-6pl1-18.fc9.ppc requires /bin/bash wmx-6pl1-18.fc9.ppc requires /bin/sh wodim-1.1.6-11.fc9.ppc requires /bin/sh wodim-1.1.6-11.fc9.ppc requires /usr/sbin/alternatives wordwarvi-0.09-1.fc10.ppc requires /bin/sh worldofpadman-1.34-0.9.rc4.fc9.ppc requires /bin/bash worldofpadman-1.34-0.9.rc4.fc9.ppc requires /bin/sh worminator-3.0R2.1-8.fc9.ppc requires /bin/sh wormux-0.7.9-6.fc9.ppc requires /bin/sh wp_tray-0.5.3-7.fc9.ppc requires /bin/sh 1:wpa_supplicant-0.6.3-5.fc9.ppc requires /bin/sh 1:wpa_supplicant-0.6.3-5.fc9.ppc requires /bin/bash 1:wpa_supplicant-0.6.3-5.fc9.ppc requires /usr/bin/python wqy-bitmap-fonts-0.9.9-6.fc10.noarch requires /bin/sh wqy-unibit-fonts-1.1.0-4.fc8.noarch requires /bin/sh wqy-zenhei-fonts-0.5.23-0.fc9.noarch requires /bin/sh writer2latex-0.5-2.fc9.ppc requires /bin/sh ws-commons-util-1.0.1-6.fc8.ppc requires /usr/bin/rebuild-gcj-db wsdl4j-1.5.2-5jpp.2.fc9.ppc requires /bin/sh wsdl4j-javadoc-1.5.2-5jpp.2.fc9.ppc requires /bin/sh wsdl4j-javadoc-1.5.2-5jpp.2.fc9.ppc requires /bin/rm wsdl4j-javadoc-1.5.2-5jpp.2.fc9.ppc requires /bin/ln wuja-0.0.8-3.fc9.noarch requires /bin/sh wuja-0.0.8-3.fc9.noarch requires /usr/bin/python wv-1.2.4-4.fc9.ppc requires /sbin/ldconfig wv-1.2.4-4.fc9.ppc requires /bin/sh wv-1.2.4-4.fc9.ppc64 requires /sbin/ldconfig wv-1.2.4-4.fc9.ppc64 requires /bin/sh wv2-0.2.3-7.fc9.ppc requires /sbin/ldconfig wv2-0.2.3-7.fc9.ppc64 requires /sbin/ldconfig wv2-devel-0.2.3-7.fc9.ppc requires /bin/sh wv2-devel-0.2.3-7.fc9.ppc64 requires /bin/sh wxBase-2.8.7-2.fc9.ppc requires /sbin/ldconfig wxBase-2.8.7-2.fc9.ppc64 requires /sbin/ldconfig wxGTK-2.8.7-2.fc9.ppc requires /sbin/ldconfig wxGTK-2.8.7-2.fc9.ppc64 requires /sbin/ldconfig wxGTK-devel-2.8.7-2.fc9.ppc requires /bin/sh wxGTK-devel-2.8.7-2.fc9.ppc64 requires /bin/sh wxGTK-gl-2.8.7-2.fc9.ppc requires /sbin/ldconfig wxGTK-gl-2.8.7-2.fc9.ppc64 requires /sbin/ldconfig wxGlade-0.6.1-1.fc9.noarch requires /bin/sh wxGlade-0.6.1-1.fc9.noarch requires /bin/bash wxMaxima-0.7.4-3.fc9.ppc requires /bin/sh wxPython-2.8.7.1-2.fc9.ppc requires /usr/bin/env wxPython-2.8.7.1-2.fc9.ppc requires /usr/bin/python wxPython-2.8.7.1-2.fc9.ppc requires /bin/bash wxPython-2.8.7.1-2.fc9.ppc requires /bin/sh wxsvg-1.0-0.8.b10.fc10.ppc requires /sbin/ldconfig wxsvg-1.0-0.8.b10.fc10.ppc64 requires /sbin/ldconfig x11-ssh-askpass-1.2.4.1-4.fc9.ppc requires /usr/share/X11/app-defaults x3270-x11-3.3.6-5.fc9.ppc requires /bin/sh x3270-x11-3.3.6-5.fc9.ppc requires /usr/bin/mkfontdir xalan-c-1.10.0-4.fc9.ppc requires /sbin/ldconfig xalan-c-1.10.0-4.fc9.ppc64 requires /sbin/ldconfig xalan-c-doc-1.10.0-4.fc9.ppc requires /bin/sh xalan-j2-2.7.0-7jpp.2.fc9.ppc requires /bin/sh xalan-j2-2.7.0-7jpp.2.fc9.ppc requires /usr/sbin/update-alternatives xalan-j2-demo-2.7.0-7jpp.2.fc9.ppc requires /bin/sh xalan-j2-javadoc-2.7.0-7jpp.2.fc9.ppc requires /bin/sh xalan-j2-javadoc-2.7.0-7jpp.2.fc9.ppc requires /bin/rm xalan-j2-javadoc-2.7.0-7jpp.2.fc9.ppc requires /bin/ln xalan-j2-xsltc-2.7.0-7jpp.2.fc9.ppc requires /bin/sh xaos-3.2.3-3.fc9.ppc requires /bin/sh xaos-3.2.3-3.fc9.ppc requires /sbin/install-info xapian-core-devel-1.0.6-1.fc9.ppc requires /bin/sh xapian-core-devel-1.0.6-1.fc9.ppc64 requires /bin/sh xapian-core-libs-1.0.6-1.fc9.ppc requires /sbin/ldconfig xapian-core-libs-1.0.6-1.fc9.ppc64 requires /sbin/ldconfig xar-1.5.1-6.fc9.ppc requires /sbin/ldconfig xar-1.5.1-6.fc9.ppc64 requires /sbin/ldconfig xarchiver-0.4.9-0.6.20070103svn24249.fc9.ppc requires /bin/sh xarchiver-0.4.9-0.6.20070103svn24249.fc9.ppc requires /bin/sh xarchon-0.50-7.fc9.ppc requires /bin/sh xastir-1.9.2-5.fc10.ppc requires /usr/bin/env xastir-1.9.2-5.fc10.ppc requires /bin/bash xastir-1.9.2-5.fc10.ppc requires /bin/sh xastir-1.9.2-5.fc10.ppc requires /usr/bin/perl xawtv-3.95-8.fc9.ppc requires /bin/bash xbae-4.60.4-9.fc9.ppc requires /sbin/ldconfig xbae-4.60.4-9.fc9.ppc64 requires /sbin/ldconfig xbase-2.0.0-11.fc9.ppc requires /sbin/ldconfig xbase-2.0.0-11.fc9.ppc64 requires /sbin/ldconfig xbase-devel-2.0.0-11.fc9.ppc requires /bin/sh xbase-devel-2.0.0-11.fc9.ppc64 requires /bin/sh xbindkeys-1.8.2-2.fc9.ppc requires /bin/sh xblast-2.10.4-5.fc9.ppc requires /usr/share/fonts/bitstream-vera/Vera.ttf xblast-common-2.10.4-5.fc9.ppc requires /bin/sh xblast-common-2.10.4-5.fc9.ppc requires /bin/bash xboard-4.2.7-17.fc9.ppc requires /bin/sh xboard-4.2.7-17.fc9.ppc requires /usr/bin/perl xboard-4.2.7-17.fc9.ppc requires /bin/sh xbsql-0.11-11.fc9.ppc requires /sbin/ldconfig xbsql-0.11-11.fc9.ppc64 requires /sbin/ldconfig xca-0.6.4-4.fc9.ppc requires /bin/sh xca-0.6.4-4.fc9.ppc requires /bin/sh 1:xchat-2.8.4-15.fc9.ppc requires /bin/sh xchat-gnome-0.18-12.fc9.ppc requires /bin/sh xchm-1.14-1.fc9.ppc requires /bin/sh xcircuit-3.4.27-3.fc9.ppc requires /bin/sh xcircuit-3.4.27-3.fc9.ppc requires /bin/sh xclip-0.10-3.fc9.ppc requires /bin/sh xdelta-1.1.4-3.fc9.ppc requires /sbin/ldconfig xdelta-1.1.4-3.fc9.ppc64 requires /sbin/ldconfig xdelta-devel-1.1.4-3.fc9.ppc requires /bin/bash xdelta-devel-1.1.4-3.fc9.ppc64 requires /bin/bash xdg-user-dirs-0.10-1.fc9.ppc requires /bin/sh xdg-user-dirs-0.10-1.fc9.ppc requires /etc/X11/xinit/xinitrc.d xdg-utils-1.0.2-4.fc9.noarch requires /bin/bash xdg-utils-1.0.2-4.fc9.noarch requires /bin/sh xdoclet-1.2.3-9jpp.1.fc9.ppc requires /bin/sh xdvik-22.84.13-20.fc10.ppc requires /bin/sh xdvik-22.84.13-20.fc10.ppc requires /bin/sh xemacs-21.5.28-6.fc9.ppc requires /bin/sh xemacs-21.5.28-6.fc9.ppc requires /bin/sh xemacs-common-21.5.28-6.fc9.ppc requires /bin/sh xemacs-common-21.5.28-6.fc9.ppc requires /usr/sbin/alternatives xemacs-common-21.5.28-6.fc9.ppc requires /bin/sh xemacs-ess-5.3.7-1.fc10.noarch requires /bin/sh xemacs-info-21.5.28-6.fc9.ppc requires /bin/sh xemacs-info-21.5.28-6.fc9.ppc requires /sbin/install-info xemacs-nox-21.5.28-6.fc9.ppc requires /bin/sh xemacs-packages-extra-20070427-1.fc8.noarch requires /usr/bin/perl xemacs-packages-extra-20070427-1.fc8.noarch requires /usr/bin/env xemacs-packages-extra-20070427-1.fc8.noarch requires /bin/sh xerces-c-2.8.0-1.fc9.ppc requires /sbin/ldconfig xerces-c-2.8.0-1.fc9.ppc64 requires /sbin/ldconfig xerces-c27-2.7.0-4.fc9.ppc requires /sbin/ldconfig xerces-c27-2.7.0-4.fc9.ppc64 requires /sbin/ldconfig xerces-j2-2.7.1-10jpp.1.fc9.ppc requires /bin/sh xerces-j2-2.7.1-10jpp.1.fc9.ppc requires /usr/sbin/update-alternatives xerces-j2-demo-2.7.1-10jpp.1.fc9.ppc requires /bin/sh xfce-mcs-plugins-4.4.2-4.fc9.ppc requires /bin/sh xfce-utils-4.4.2-4.fc9.ppc requires /usr/bin/id xfce-utils-4.4.2-4.fc9.ppc requires /bin/sh xfce4-appfinder-4.4.2-2.fc9.ppc requires /bin/sh xfce4-battery-plugin-0.5.0-4.fc9.ppc requires /bin/sh xfce4-dev-tools-4.4.0-1.fc7.noarch requires /bin/sh xfce4-dict-plugin-0.3.0-1.fc9.ppc requires /bin/sh xfce4-eyes-plugin-4.4.0-4.fc9.ppc requires /bin/sh xfce4-fsguard-plugin-0.4.1-2.fc9.ppc requires /bin/sh xfce4-gsynaptics-mcs-plugin-1.0.0-1.fc9.ppc requires /bin/sh xfce4-mailwatch-plugin-1.0.1-8.fc9.ppc requires /bin/sh xfce4-mixer-4.4.2-2.fc9.ppc requires /bin/sh xfce4-mount-plugin-0.5.1-4.fc9.ppc requires /bin/sh xfce4-notes-plugin-1.6.1-2.fc9.ppc requires /bin/sh xfce4-panel-4.4.2-4.fc9.ppc requires /bin/sh xfce4-panel-4.4.2-4.fc9.ppc64 requires /bin/sh xfce4-sensors-plugin-0.10.99.2-4.fc9.ppc requires /bin/sh xfce4-session-4.4.2-3.fc10.ppc requires /bin/sh xfce4-session-4.4.2-3.fc10.ppc64 requires /bin/sh xfce4-session-engines-4.4.2-3.fc10.ppc requires /bin/sh xfce4-time-out-plugin-0.1.1-1.fc9.ppc requires /bin/sh xfce4-weather-plugin-0.6.2-3.fc9.ppc requires /bin/sh xfdesktop-4.4.2-3.fc9.ppc requires /bin/sh xfig-common-3.2.5-10.fc9.ppc requires /bin/sh xfig-common-3.2.5-10.fc9.ppc requires /bin/bash xforms-1.0.90-11.fc9.ppc requires /sbin/ldconfig xforms-1.0.90-11.fc9.ppc64 requires /sbin/ldconfig xfprint-4.4.2-2.fc9.ppc requires /bin/sh xfprint-4.4.2-2.fc9.ppc64 requires /bin/sh xfsprogs-2.9.8-1.fc10.ppc requires /sbin/ldconfig xfsprogs-2.9.8-1.fc10.ppc requires /bin/sh xfsprogs-2.9.8-1.fc10.ppc64 requires /sbin/ldconfig xfsprogs-2.9.8-1.fc10.ppc64 requires /bin/sh xfwm4-4.4.2-3.fc10.ppc requires /bin/sh xgalaxy-2.0.34-8.fc9.ppc requires /bin/sh xgrav-1.2.0-6.fc9.ppc requires /bin/sh xgridfit-1.5-2.fc9.noarch requires /usr/bin/xsltproc xguest-1.0.6-7.fc9.noarch requires /bin/sh xguest-1.0.6-7.fc9.noarch requires /bin/bash xhotkeys-0.9.8.3-5.fc9.noarch requires /bin/sh xhotkeys-0.9.8.3-5.fc9.noarch requires /bin/bash xhotkeys-0.9.8.3-5.fc9.noarch requires /usr/bin/python xhtml1-dtds-1.0-20020801.1.noarch requires /bin/sh xhtml1-dtds-1.0-20020801.1.noarch requires /usr/bin/xmlcatalog xhtml2ps-1.0-0.1.b5.fc10.noarch requires /usr/bin/wish xine-lib-1.1.12-3.fc10.ppc requires /sbin/ldconfig xine-lib-1.1.12-3.fc10.ppc64 requires /sbin/ldconfig xine-lib-devel-1.1.12-3.fc10.ppc requires /bin/sh xine-lib-devel-1.1.12-3.fc10.ppc64 requires /bin/sh 2:xinetd-2.3.14-18.fc9.ppc requires /etc/init.d 2:xinetd-2.3.14-18.fc9.ppc requires /sbin/service 2:xinetd-2.3.14-18.fc9.ppc requires /bin/bash 2:xinetd-2.3.14-18.fc9.ppc requires /sbin/chkconfig 2:xinetd-2.3.14-18.fc9.ppc requires /bin/sh xjavadoc-1.1-5jpp.3.fc9.ppc requires /bin/sh xjavadoc-javadoc-1.1-5jpp.3.fc9.ppc requires /bin/sh xjavadoc-javadoc-1.1-5jpp.3.fc9.ppc requires /bin/rm xjavadoc-javadoc-1.1-5jpp.3.fc9.ppc requires /bin/ln xl2tpd-1.1.12-2.fc9.ppc requires /bin/sh xl2tpd-1.1.12-2.fc9.ppc requires /sbin/chkconfig xl2tpd-1.1.12-2.fc9.ppc requires /bin/sh xl2tpd-1.1.12-2.fc9.ppc requires /sbin/service xlhtml-0.5-8.fc9.ppc requires /usr/bin/perl xlhtml-0.5-8.fc9.ppc requires /bin/csh xlhtml-0.5-8.fc9.ppc requires /bin/bash xlhtml-0.5-8.fc9.ppc requires /bin/sh xml-commons-apis-1.3.04-1jpp.1.fc9.ppc requires /bin/sh xml-commons-apis-javadoc-1.3.04-1jpp.1.fc9.ppc requires /bin/ln xml-commons-apis-javadoc-1.3.04-1jpp.1.fc9.ppc requires /bin/rm xml-commons-apis12-1.2.04-1jpp.4.fc9.ppc requires /bin/sh xml-commons-resolver-1.1-1jpp.12.ppc requires /bin/sh xml-commons-resolver-javadoc-1.1-1jpp.12.ppc requires /bin/sh xml-commons-resolver-javadoc-1.1-1jpp.12.ppc requires /bin/rm xml-commons-resolver-javadoc-1.1-1jpp.12.ppc requires /bin/ln 1:xml-commons-which-1.0-1.b2.0jpp.2.ppc requires /bin/sh xmlcopyeditor-1.1.0.6-4.fc9.ppc requires /bin/sh 1:xmldb-api-0.1-0.2.20011111cvs.1jpp.2.fc9.ppc requires /bin/sh xmlrpc-2.0.1-4jpp.3.fc9.ppc requires /bin/sh xmlrpc-c-1.13.8-2.fc9.ppc requires /sbin/ldconfig xmlrpc-c-1.13.8-2.fc9.ppc64 requires /sbin/ldconfig xmlrpc-c-devel-1.13.8-2.fc9.ppc requires /bin/sh xmlrpc-c-devel-1.13.8-2.fc9.ppc64 requires /bin/sh xmlsec1-1.2.9-10.1.ppc requires /bin/sh xmlsec1-1.2.9-10.1.ppc64 requires /bin/sh xmlsec1-devel-1.2.9-10.1.ppc requires /bin/sh xmlsec1-devel-1.2.9-10.1.ppc64 requires /bin/sh xmlsec1-gnutls-1.2.9-10.1.ppc requires /bin/sh xmlsec1-gnutls-1.2.9-10.1.ppc64 requires /bin/sh xmlsec1-openssl-1.2.9-10.1.ppc requires /bin/sh xmlsec1-openssl-1.2.9-10.1.ppc64 requires /bin/sh xmltex-20020625-11.fc9.noarch requires /bin/sh xmltex-20020625-11.fc9.noarch requires /bin/sh xmlto-0.0.20-3.fc10.ppc requires /bin/bash xmltoman-0.3-2.fc9.noarch requires /usr/bin/perl xmlunit-1.0-6jpp.1.fc9.ppc requires /bin/sh 1:xmms-1.2.10-38.fc9.ppc requires /bin/sh 1:xmms-1.2.10-38.fc9.ppc requires /usr/share/desktop-menu-patches/redhat-audio-player.desktop 1:xmms-1.2.10-38.fc9.ppc requires /bin/sh 1:xmms-devel-1.2.10-38.fc9.ppc requires /bin/sh 1:xmms-devel-1.2.10-38.fc9.ppc64 requires /bin/sh 1:xmms-libs-1.2.10-38.fc9.ppc requires /sbin/ldconfig 1:xmms-libs-1.2.10-38.fc9.ppc64 requires /sbin/ldconfig xmoto-0.4.2-1.fc9.ppc requires /bin/sh xmoto-edit-0.2.4-13.fc9.ppc requires /bin/sh xorg-x11-apps-7.3-3.fc9.ppc requires /bin/sh xorg-x11-filesystem-7.3-1.fc9.noarch requires /bin/bash xorg-x11-filesystem-7.3-1.fc9.noarch requires /bin/sh 1:xorg-x11-font-utils-7.2-4.fc9.ppc requires /bin/sh xorg-x11-fonts-100dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-75dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ISO8859-1-100dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ISO8859-1-75dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ISO8859-14-100dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ISO8859-14-75dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ISO8859-15-100dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ISO8859-15-75dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ISO8859-2-100dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ISO8859-2-75dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ISO8859-9-100dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ISO8859-9-75dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-Type1-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-cyrillic-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ethiopic-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-misc-7.2-6.fc9.noarch requires /bin/sh xorg-x11-server-Xorg-1.4.99.901-29.20080415.fc9.ppc requires /bin/sh xorg-x11-server-source-1.4.99.901-29.20080415.fc9.ppc requires /bin/sh 1:xorg-x11-xauth-1.0.2-4.fc9.ppc requires /bin/sh 1:xorg-x11-xdm-1.1.6-3.fc9.ppc requires /bin/sh 1:xorg-x11-xfs-1.0.5-2.fc9.ppc requires /bin/sh 1:xorg-x11-xfs-1.0.5-2.fc9.ppc requires /usr/bin/uniq 1:xorg-x11-xfs-1.0.5-2.fc9.ppc requires /usr/sbin/useradd 1:xorg-x11-xfs-1.0.5-2.fc9.ppc requires /usr/bin/find 1:xorg-x11-xfs-1.0.5-2.fc9.ppc requires /sbin/service 1:xorg-x11-xfs-1.0.5-2.fc9.ppc requires /sbin/nologin 1:xorg-x11-xfs-1.0.5-2.fc9.ppc requires /bin/bash 1:xorg-x11-xfs-1.0.5-2.fc9.ppc requires /bin/sh 1:xorg-x11-xfs-1.0.5-2.fc9.ppc requires /bin/sort 1:xorg-x11-xfs-1.0.5-2.fc9.ppc requires /sbin/chkconfig xorg-x11-xinit-1.0.7-6.fc9.ppc requires /bin/bash xorg-x11-xinit-1.0.7-6.fc9.ppc requires /bin/sh xorg-x11-xsm-1.0.2-7.fc9.ppc requires /bin/sh xosd-2.2.14-11.fc9.ppc requires /sbin/ldconfig xosd-2.2.14-11.fc9.ppc64 requires /sbin/ldconfig xosd-devel-2.2.14-11.fc9.ppc requires /bin/sh xosd-devel-2.2.14-11.fc9.ppc64 requires /bin/sh xournal-0.4.2.1-1.fc9.ppc requires /bin/sh xpa-libs-2.1.8-6.fc9.ppc requires /sbin/ldconfig xpa-libs-2.1.8-6.fc9.ppc64 requires /sbin/ldconfig 1:xpdf-3.02-6.fc9.ppc requires /bin/sh xpilot-ng-4.7.2-14.fc9.ppc requires /bin/sh xpilot-ng-selinux-4.7.2-14.fc9.ppc requires /usr/sbin/semodule xpilot-ng-selinux-4.7.2-14.fc9.ppc requires /sbin/fixfiles xpilot-ng-selinux-4.7.2-14.fc9.ppc requires /bin/sh xpilot-ng-selinux-4.7.2-14.fc9.ppc requires /usr/sbin/semanage xpilot-ng-selinux-4.7.2-14.fc9.ppc requires /usr/sbin/setsebool xpilot-ng-selinux-4.7.2-14.fc9.ppc requires /sbin/service xpilot-ng-server-4.7.2-14.fc9.ppc requires /bin/sh xpilot-ng-server-4.7.2-14.fc9.ppc requires /usr/bin/env xpilot-ng-server-4.7.2-14.fc9.ppc requires /sbin/service xpilot-ng-server-4.7.2-14.fc9.ppc requires /bin/sh xpilot-ng-server-4.7.2-14.fc9.ppc requires /sbin/chkconfig xplanet-1.2.0-3.fc9.2.ppc requires /usr/bin/perl xqilla-2.0.0-5.fc9.ppc requires /sbin/ldconfig xqilla-2.0.0-5.fc9.ppc64 requires /sbin/ldconfig xqilla10-1.0.2-5.fc9.ppc requires /sbin/ldconfig xqilla10-1.0.2-5.fc9.ppc64 requires /sbin/ldconfig xsane-gimp-0.995-3.fc9.ppc requires /bin/sh xsc-1.5-3.fc9.ppc requires /bin/sh xscorch-0.2.0-12.fc8.ppc requires /usr/bin/env 1:xscreensaver-base-5.05-3.fc9.ppc requires /bin/sh 1:xscreensaver-base-5.05-3.fc9.ppc requires /etc/pam.d/system-auth 1:xscreensaver-base-5.05-3.fc9.ppc requires /usr/bin/perl 1:xscreensaver-base-5.05-3.fc9.ppc requires /bin/bash 1:xscreensaver-extras-5.05-3.fc9.ppc requires /usr/bin/perl 1:xscreensaver-extras-5.05-3.fc9.ppc requires /bin/sh xsp-1.9.1-2.fc10.ppc requires /bin/sh xstar-xscreensaver-2.2.0-3.fc9.ppc requires /bin/sh xterm-235-1.fc10.ppc requires /bin/sh xtide-2.10-2.fc9.ppc requires /bin/sh xtide-2.10-2.fc9.ppc requires /sbin/service xtide-2.10-2.fc9.ppc requires /bin/sh xtide-2.10-2.fc9.ppc requires /sbin/chkconfig xtide-common-2.10-2.fc9.ppc requires /bin/sh xu4-1.1-0.4.cvs20070510.fc9.ppc requires /bin/sh xu4-1.1-0.4.cvs20070510.fc9.ppc requires /bin/bash xulrunner-1.9-0.63.cvs20080516.fc10.ppc requires /bin/sh xulrunner-1.9-0.63.cvs20080516.fc10.ppc requires /bin/sh xulrunner-1.9-0.63.cvs20080516.fc10.ppc64 requires /bin/sh xulrunner-1.9-0.63.cvs20080516.fc10.ppc64 requires /bin/sh xyz-gallery-0.1-1.fc9.noarch requires /usr/bin/perl xzgv-0.9-4.fc9.ppc requires /sbin/install-info xzgv-0.9-4.fc9.ppc requires /bin/sh yaboot-1.3.13-12.fc9.ppc requires /bin/sh yadex-1.7.0-10.fc9.ppc requires /bin/sh yafc-1.1.1-10.fc9.ppc requires /bin/sh yafc-1.1.1-10.fc9.ppc requires /sbin/install-info yafray-0.0.9-7.fc9.ppc requires /sbin/ldconfig yakuake-2.9.1-1.fc9.ppc requires /bin/sh yanone-kaffeesatz-fonts-20061120-3.fc9.noarch requires /bin/sh yap-5.1.1-9.fc9.ppc requires /bin/sh yap-5.1.1-9.fc9.ppc requires /sbin/install-info yap-5.1.1-9.fc9.ppc requires /sbin/ldconfig yasm-0.7.0-1.fc10.ppc requires /sbin/ldconfig yelp-2.22.1-1.fc9.ppc requires /bin/sh youtube-dl-2008.01.24-1.fc9.noarch requires /usr/bin/env 3:ypbind-1.20.4-4.fc9.ppc requires /bin/bash 3:ypbind-1.20.4-4.fc9.ppc requires /sbin/chkconfig 3:ypbind-1.20.4-4.fc9.ppc requires /bin/sh ypserv-2.19-9.fc9.ppc requires /bin/sh ypserv-2.19-9.fc9.ppc requires /sbin/service ypserv-2.19-9.fc9.ppc requires /usr/bin/awk ypserv-2.19-9.fc9.ppc requires /bin/bash ypserv-2.19-9.fc9.ppc requires /bin/sh ypserv-2.19-9.fc9.ppc requires /sbin/chkconfig yum-3.2.16-1.fc10.noarch requires /usr/bin/python yum-arch-2.2.2-2.fc7.noarch requires /usr/bin/python yum-cron-0.8.2-1.fc9.noarch requires /bin/sh yum-cron-0.8.2-1.fc9.noarch requires /bin/bash yum-cron-0.8.2-1.fc9.noarch requires /sbin/chkconfig yum-cron-0.8.2-1.fc9.noarch requires /bin/sh yum-cron-0.8.2-1.fc9.noarch requires /sbin/service yum-updateonboot-1.1.13-2.fc9.noarch requires /bin/sh yum-updateonboot-1.1.13-2.fc9.noarch requires /bin/bash 1:yum-updatesd-0.9-1.fc9.noarch requires /bin/sh 1:yum-updatesd-0.9-1.fc9.noarch requires /bin/bash 1:yum-updatesd-0.9-1.fc9.noarch requires /usr/bin/python 1:yum-updatesd-0.9-1.fc9.noarch requires /sbin/chkconfig 1:yum-updatesd-0.9-1.fc9.noarch requires /sbin/service yum-utils-1.1.13-2.fc9.noarch requires /usr/bin/python yumex-2.0.4-1.fc9.noarch requires /bin/bash yumex-2.0.4-1.fc9.noarch requires /usr/bin/env yumex-2.0.4-1.fc9.noarch requires /usr/bin/python zabbix-1.4.5-3.fc10.ppc requires /bin/sh zabbix-1.4.5-3.fc10.ppc requires /usr/sbin/useradd zabbix-1.4.5-3.fc10.ppc requires /sbin/service zabbix-1.4.5-3.fc10.ppc requires /bin/sh zabbix-1.4.5-3.fc10.ppc requires /sbin/chkconfig zabbix-agent-1.4.5-3.fc10.ppc requires /bin/sh zabbix-agent-1.4.5-3.fc10.ppc requires /usr/sbin/useradd zabbix-agent-1.4.5-3.fc10.ppc requires /sbin/service zabbix-agent-1.4.5-3.fc10.ppc requires /bin/sh zabbix-agent-1.4.5-3.fc10.ppc requires /sbin/chkconfig zaptel-1.4.10.1-1.fc10.ppc requires /sbin/chkconfig zaptel-1.4.10.1-1.fc10.ppc requires /bin/sh zaptel-1.4.10.1-1.fc10.ppc requires /bin/sh zaptel-1.4.10.1-1.fc10.ppc requires /sbin/service zaptel-lib-1.4.10.1-1.fc10.ppc requires /sbin/ldconfig zaptel-lib-1.4.10.1-1.fc10.ppc64 requires /sbin/ldconfig zasx-1.30-6.fc9.ppc requires /bin/sh zenity-2.23.1-1.fc10.ppc requires /bin/sh zeroinstall-injector-0.32-1.fc9.noarch requires /bin/sh zeroinstall-injector-0.32-1.fc9.noarch requires /usr/bin/env zeroinstall-injector-0.32-1.fc9.noarch requires /usr/bin/python zile-2.2.19-3.fc9.ppc requires /bin/sh zlib-1.2.3-18.fc9.ppc requires /sbin/ldconfig zlib-1.2.3-18.fc9.ppc64 requires /sbin/ldconfig zoneminder-1.22.3-14.fc10.ppc requires /bin/sh zoneminder-1.22.3-14.fc10.ppc requires /sbin/service zoneminder-1.22.3-14.fc10.ppc requires /usr/bin/perl zoneminder-1.22.3-14.fc10.ppc requires /bin/sh zoneminder-1.22.3-14.fc10.ppc requires /sbin/chkconfig zsh-4.3.4-7.fc9.ppc requires /bin/sh zsh-4.3.4-7.fc9.ppc requires /sbin/install-info zsh-4.3.4-7.fc9.ppc requires /bin/sh zsh-4.3.4-7.fc9.ppc requires /bin/zsh zvbi-0.2.30-1.fc9.ppc requires /bin/sh zvbi-0.2.30-1.fc9.ppc requires /sbin/service zvbi-0.2.30-1.fc9.ppc requires /sbin/chkconfig zvbi-0.2.30-1.fc9.ppc requires /bin/sh zvbi-0.2.30-1.fc9.ppc64 requires /bin/sh zvbi-0.2.30-1.fc9.ppc64 requires /sbin/service zvbi-0.2.30-1.fc9.ppc64 requires /bin/sh zvbi-0.2.30-1.fc9.ppc64 requires /sbin/chkconfig zvbi-fonts-0.2.30-1.fc9.ppc requires /bin/sh zynaddsubfx-2.2.1-18.fc9.ppc requires /bin/sh zziplib-0.13.49-5.fc9.ppc requires /sbin/ldconfig zziplib-0.13.49-5.fc9.ppc64 requires /sbin/ldconfig Broken deps for ppc64 ---------------------------------------------------------- 8Kingdoms-1.1.0-6.fc9.ppc64 requires /bin/sh AcetoneISO-6.7-5.fc9.ppc64 requires /bin/bash AcetoneISO2-2.0.2-3.fc10.ppc64 requires /bin/bash AllegroOGG-1.0.3-4.fc9.ppc64 requires /sbin/ldconfig BackupPC-3.1.0-2.fc9.noarch requires /bin/sh BackupPC-3.1.0-2.fc9.noarch requires /usr/sbin/useradd BackupPC-3.1.0-2.fc9.noarch requires /usr/bin/perl BackupPC-3.1.0-2.fc9.noarch requires /bin/sh BackupPC-3.1.0-2.fc9.noarch requires /usr/sbin/usermod BlockOutII-2.3-5.fc9.ppc64 requires /bin/sh CCfits-2.0-1.fc9.ppc64 requires /sbin/ldconfig CGAL-3.3.1-11.fc9.ppc64 requires /sbin/ldconfig CGAL-devel-3.3.1-11.fc9.ppc64 requires /etc/profile.d CGAL-devel-3.3.1-11.fc9.ppc64 requires /bin/sh CTL-1.4.1-6.fc9.ppc64 requires /sbin/ldconfig Canna-3.7p3-23.fc9.ppc64 requires /bin/sh Canna-3.7p3-23.fc9.ppc64 requires /sbin/chkconfig Canna-3.7p3-23.fc9.ppc64 requires /bin/bash Canna-3.7p3-23.fc9.ppc64 requires /bin/chown Canna-3.7p3-23.fc9.ppc64 requires /bin/grep Canna-3.7p3-23.fc9.ppc64 requires /bin/sh Canna-3.7p3-23.fc9.ppc64 requires /sbin/service Canna-3.7p3-23.fc9.ppc64 requires /etc/services Canna-libs-3.7p3-23.fc9.ppc64 requires /sbin/ldconfig CastPodder-5.0-8.fc6.noarch requires /bin/bash CastPodder-5.0-8.fc6.noarch requires /usr/bin/env CastPodder-5.0-8.fc6.noarch requires /bin/sh CastPodder-5.0-8.fc6.noarch requires /usr/bin/python ClanLib-0.8.1-1.fc9.ppc64 requires /sbin/ldconfig ClanLib06-0.6.5-12.fc9.ppc64 requires /sbin/ldconfig ClanLib06-devel-0.6.5-12.fc9.ppc64 requires /bin/sh Coin2-2.5.0-4.fc9.ppc64 requires /sbin/ldconfig Coin2-devel-2.5.0-4.fc9.ppc64 requires /bin/sh ConsoleKit-0.2.10-3.fc9.ppc64 requires /bin/sh ConsoleKit-0.2.10-3.fc9.ppc64 requires /bin/sh CriticalMass-1.0.2-5.fc9.ppc64 requires /bin/sh Cython-0.9.6.13.1-3.fc10.noarch requires /usr/bin/python DevIL-1.6.8-0.15.rc2.fc9.ppc64 requires /sbin/ldconfig DevIL-ILUT-1.6.8-0.15.rc2.fc9.ppc64 requires /sbin/ldconfig Django-0.96.1-2.fc9.noarch requires /usr/bin/env Django-0.96.1-2.fc9.noarch requires /usr/bin/python Django-docs-0.96.1-2.fc9.noarch requires /usr/bin/env ElectricFence-2.2.2-25.fc9.ppc64 requires /sbin/ldconfig ElectricFence-2.2.2-25.fc9.ppc64 requires /bin/bash FlightGear-1.0.0-3.fc10.ppc64 requires /bin/sh GConf2-2.22.0-7.fc10.ppc64 requires /bin/sh GConf2-2.22.0-7.fc10.ppc64 requires /sbin/ldconfig GConf2-2.22.0-7.fc10.ppc64 requires /usr/bin/killall GREYCstoration-gui-2.8-1.fc9.ppc64 requires /bin/sh GREYCstoration-gui-2.8-1.fc9.ppc64 requires /bin/sh GeoIP-1.4.4-2.fc9.ppc64 requires /sbin/ldconfig GraphicsMagick-1.1.10-3.fc9.ppc64 requires /sbin/ldconfig GraphicsMagick-c++-1.1.10-3.fc9.ppc64 requires /sbin/ldconfig GraphicsMagick-c++-devel-1.1.10-3.fc9.ppc64 requires /bin/sh GraphicsMagick-devel-1.1.10-3.fc9.ppc64 requires /bin/sh Hermes-1.3.3-14.fc9.ppc64 requires /sbin/ldconfig HippoDraw-1.21.1-4.fc9.ppc64 requires /bin/sh ImageMagick-6.4.0.10-1.fc10.ppc64 requires /sbin/ldconfig ImageMagick-c++-6.4.0.10-1.fc10.ppc64 requires /sbin/ldconfig ImageMagick-c++-devel-6.4.0.10-1.fc10.ppc64 requires /bin/sh ImageMagick-devel-6.4.0.10-1.fc10.ppc64 requires /bin/sh Inventor-2.1.5-31.fc9.ppc64 requires /usr/share/fonts/liberation/LiberationSerif-BoldItalic.ttf Inventor-2.1.5-31.fc9.ppc64 requires /usr/share/fonts/liberation/LiberationSans-Regular.ttf Inventor-2.1.5-31.fc9.ppc64 requires /usr/share/fonts/liberation/LiberationMono-Italic.ttf Inventor-2.1.5-31.fc9.ppc64 requires /usr/share/fonts/liberation/LiberationMono-BoldItalic.ttf Inventor-2.1.5-31.fc9.ppc64 requires /usr/share/fonts/liberation/LiberationSerif-Regular.ttf Inventor-2.1.5-31.fc9.ppc64 requires /usr/share/fonts/liberation/LiberationSans-BoldItalic.ttf Inventor-2.1.5-31.fc9.ppc64 requires /usr/share/fonts/liberation/LiberationMono-Bold.ttf Inventor-2.1.5-31.fc9.ppc64 requires /usr/share/fonts/liberation/LiberationSans-Bold.ttf Inventor-2.1.5-31.fc9.ppc64 requires /sbin/ldconfig Inventor-2.1.5-31.fc9.ppc64 requires /usr/share/fonts/liberation/LiberationSerif-Bold.ttf Inventor-2.1.5-31.fc9.ppc64 requires /usr/share/fonts/liberation/LiberationSerif-Italic.ttf Inventor-2.1.5-31.fc9.ppc64 requires /usr/share/fonts/liberation/LiberationMono-Regular.ttf Inventor-2.1.5-31.fc9.ppc64 requires /bin/sh Inventor-2.1.5-31.fc9.ppc64 requires /usr/share/fonts/liberation/LiberationSans-Italic.ttf Inventor-demos-2.1.5-31.fc9.ppc64 requires /bin/sh InventorXt-2.1.5-31.fc9.ppc64 requires /sbin/ldconfig InventorXt-2.1.5-31.fc9.ppc64 requires /usr/bin/xmessage Io-language-20071010-5.fc9.ppc64 requires /sbin/ldconfig JSDoc-1.10.2-4.fc8.noarch requires /usr/bin/perl KoboDeluxe-0.5.1-2.fc9.ppc64 requires /bin/sh KoboDeluxe-0.5.1-2.fc9.ppc64 requires /usr/sbin/groupadd MAKEDEV-3.23-4.ppc64 requires /bin/sh Macaulay2-1.1-1.fc9.ppc64 requires /bin/sh Macaulay2-1.1-1.fc9.ppc64 requires /bin/sh Maelstrom-3.0.6-15.ppc64 requires /bin/sh MagicPoint-1.11b-6.fc9.ppc64 requires /usr/bin/perl MegaMek-0.30.11-3.fc9.ppc64 requires /bin/sh MegaMek-0.30.11-3.fc9.ppc64 requires /usr/bin/perl MegaMek-0.30.11-3.fc9.ppc64 requires /bin/sh Miro-1.2.3-2.fc10.ppc64 requires /bin/sh Miro-1.2.3-2.fc10.ppc64 requires /usr/bin/python Miro-1.2.3-2.fc10.ppc64 requires /bin/sh 1:NetworkManager-0.7.0-0.9.3.svn3669.fc10.ppc64 requires /bin/sh 1:NetworkManager-0.7.0-0.9.3.svn3669.fc10.ppc64 requires /bin/sh 1:NetworkManager-glib-0.7.0-0.9.3.svn3669.fc10.ppc64 requires /sbin/ldconfig 1:NetworkManager-gnome-0.7.0-0.9.3.svn3669.fc10.ppc64 requires /bin/sh 1:NetworkManager-openvpn-0.7.0-10.svn3632.fc10.ppc64 requires /bin/sh 1:NetworkManager-openvpn-0.7.0-10.svn3632.fc10.ppc64 requires /usr/bin/update-desktop-database 1:NetworkManager-openvpn-0.7.0-10.svn3632.fc10.ppc64 requires /sbin/ldconfig 1:NetworkManager-vpnc-0.7.0-0.7.7.svn3627.fc10.ppc64 requires /bin/sh 1:NetworkManager-vpnc-0.7.0-0.7.7.svn3627.fc10.ppc64 requires /sbin/ldconfig 1:ORBit-0.5.17-23.fc9.ppc64 requires /sbin/ldconfig 1:ORBit-0.5.17-23.fc9.ppc64 requires /sbin/install-info 1:ORBit-devel-0.5.17-23.fc9.ppc64 requires /bin/sh 1:ORBit-devel-0.5.17-23.fc9.ppc64 requires /bin/sh ORBit2-2.14.12-3.fc9.ppc64 requires /sbin/ldconfig ORBit2-devel-2.14.12-3.fc9.ppc64 requires /bin/sh OpenEXR-libs-1.6.1-4.fc10.ppc64 requires /sbin/ldconfig OpenEXR_CTL-libs-1.0.1-4.fc9.ppc64 requires /sbin/ldconfig OpenEXR_Viewers-1.0.1-2.fc10.ppc64 requires /bin/sh OpenEXR_Viewers-1.0.1-2.fc10.ppc64 requires /usr/sbin/alternatives OpenIPMI-2.0.13-2.fc9.ppc64 requires /bin/sh OpenIPMI-2.0.13-2.fc9.ppc64 requires /bin/sh OpenIPMI-libs-2.0.13-2.fc9.ppc64 requires /sbin/ldconfig OpenSceneGraph-libs-2.4.0-2.fc10.ppc64 requires /sbin/ldconfig OpenThreads-2.4.0-2.fc10.ppc64 requires /sbin/ldconfig PackageKit-0.2.1-2.20080508.fc10.ppc64 requires /usr/bin/python PackageKit-0.2.1-2.20080508.fc10.ppc64 requires /bin/bash PackageKit-0.2.1-2.20080508.fc10.ppc64 requires /bin/sh PackageKit-libs-0.2.1-2.20080508.fc10.ppc64 requires /sbin/ldconfig Perlbal-1.70-1.fc9.noarch requires /bin/sh Perlbal-1.70-1.fc9.noarch requires /sbin/service Perlbal-1.70-1.fc9.noarch requires /bin/bash Perlbal-1.70-1.fc9.noarch requires /usr/bin/perl Perlbal-1.70-1.fc9.noarch requires /sbin/chkconfig Pixie-2.2.3-3.fc9.ppc64 requires /sbin/ldconfig PolicyKit-0.8-2.fc9.ppc64 requires /bin/sh PolicyKit-0.8-2.fc9.ppc64 requires /usr/sbin/useradd PolicyKit-0.8-2.fc9.ppc64 requires /sbin/ldconfig Pound-2.4-1.fc9.ppc64 requires /bin/sh Pound-2.4-1.fc9.ppc64 requires /usr/sbin/groupadd Pound-2.4-1.fc9.ppc64 requires /usr/sbin/useradd Pound-2.4-1.fc9.ppc64 requires /sbin/service Pound-2.4-1.fc9.ppc64 requires /bin/bash Pound-2.4-1.fc9.ppc64 requires /sbin/chkconfig PyKDE-3.16.1-1.fc9.ppc64 requires /usr/bin/env PyKDE-devel-3.16.1-1.fc9.ppc64 requires /usr/bin/env PyQt-examples-3.17.4-4.fc9.ppc64 requires /usr/bin/env PyQt4-4.4-1.fc10.ppc64 requires /usr/bin/env PyQt4-devel-4.4-1.fc10.ppc64 requires /bin/sh PySolFC-1.1-6.fc9.noarch requires /usr/bin/env PySolFC-1.1-6.fc9.noarch requires /bin/sh PySolFC-1.1-6.fc9.noarch requires /usr/bin/python PyX-0.10-4.fc9.ppc64 requires /usr/bin/env PyXML-0.8.4-9.ppc64 requires /usr/bin/python Pyrex-0.9.6.4-2.fc10.noarch requires /usr/bin/python PythonCAD-0.1.36-3.fc9.noarch requires /bin/sh PythonCAD-0.1.36-3.fc9.noarch requires /usr/bin/env PythonCAD-0.1.36-3.fc9.noarch requires /usr/bin/python QuantLib-0.9.0-5.fc9.ppc64 requires /sbin/ldconfig QuantLib-devel-0.9.0-5.fc9.ppc64 requires /bin/sh R-2.7.0-2.fc10.ppc64 requires /bin/sh R-2.7.0-2.fc10.ppc64 requires /bin/bash R-2.7.0-2.fc10.ppc64 requires /bin/sh R-2.7.0-2.fc10.ppc64 requires /usr/bin/perl R-BSgenome.Celegans.UCSC.ce2-1.2.0-5.noarch requires /bin/sh R-BSgenome.Dmelanogaster.FlyBase.r51-1.3.1-3.noarch requires /bin/sh R-Biobase-1.16.1-5.fc9.ppc64 requires /bin/sh R-Biobase-1.16.1-5.fc9.ppc64 requires /bin/bash R-BufferedMatrix-1.4.0-1.fc10.ppc64 requires /bin/sh R-BufferedMatrixMethods-1.3.0-3.fc9.ppc64 requires /bin/sh R-DynDoc-1.18.0-1.fc10.noarch requires /bin/sh R-Matrix-0.999375-4.fc9.ppc64 requires /bin/sh R-RScaLAPACK-0.5.1-11.fc9.2.ppc64 requires /bin/sh R-RScaLAPACK-0.5.1-11.fc9.2.ppc64 requires /bin/sh R-abind-1.1-2.fc9.noarch requires /bin/sh R-acepack-1.3-4.fc9.ppc64 requires /bin/sh R-affyio-1.8.0-1.fc10.ppc64 requires /bin/sh R-car-1.2-3.fc10.noarch requires /bin/sh R-hdf5-1.6.6-6.fc10.ppc64 requires /bin/sh R-hgu95av2probe-2.0.0-1.fc9.noarch requires /bin/sh R-mAr-1.1-13.fc9.ppc64 requires /bin/sh R-maanova-1.9.0-2.fc9.ppc64 requires /bin/sh R-multcomp-1.0-1.fc9.noarch requires /bin/sh R-multtest-1.18.0-4.fc9.ppc64 requires /bin/sh R-mvtnorm-0.8-4.fc9.ppc64 requires /bin/sh R-pls-2.1-2.fc9.noarch requires /bin/sh R-qvalue-1.12.0-2.fc9.noarch requires /bin/sh R-rlecuyer-0.1-6.fc9.ppc64 requires /bin/sh R-systemfit-0.8-7.fc9.noarch requires /bin/sh R-tkWidgets-1.16.0-2.fc9.noarch requires /bin/sh R-waveslim-1.6.1-2.fc9.ppc64 requires /bin/sh R-wavethresh-2.2-9.fc9.ppc64 requires /bin/sh R-widgetTools-1.15.0-2.fc9.noarch requires /bin/sh Ri-li-2.0.1-3.fc9.ppc64 requires /bin/sh SAASound-3.2-5.fc10.ppc64 requires /sbin/ldconfig SDL-1.2.13-3.fc9.ppc64 requires /sbin/ldconfig SDL-devel-1.2.13-3.fc9.ppc64 requires /bin/sh SDL_Pango-0.1.2-8.ppc64 requires /sbin/ldconfig SDL_gfx-2.0.16-5.fc9.ppc64 requires /sbin/ldconfig SDL_image-1.2.6-6.fc9.ppc64 requires /sbin/ldconfig SDL_mixer-1.2.8-8.fc9.ppc64 requires /sbin/ldconfig SDL_net-1.2.7-4.fc9.ppc64 requires /sbin/ldconfig SDL_sound-1.0.3-1.fc10.ppc64 requires /sbin/ldconfig SDL_ttf-2.0.9-4.fc9.ppc64 requires /sbin/ldconfig SILLY-0.1.0-5.fc9.ppc64 requires /sbin/ldconfig SIMVoleon-2.0.1-7.fc9.ppc64 requires /bin/sh SIMVoleon-2.0.1-7.fc9.ppc64 requires /sbin/ldconfig SIMVoleon-devel-2.0.1-7.fc9.ppc64 requires /bin/sh ScientificPython-2.6-12.fc9.ppc64 requires /usr/bin/python SimGear-1.0.0-4.fc10.ppc64 requires /sbin/ldconfig SoQt-1.4.1-9.fc9.ppc64 requires /bin/sh SoQt-1.4.1-9.fc9.ppc64 requires /sbin/ldconfig SoQt-devel-1.4.1-9.fc9.ppc64 requires /usr/share/aclocal SoQt-devel-1.4.1-9.fc9.ppc64 requires /bin/sh Sprog-0.14-13.fc9.noarch requires /usr/bin/perl TeXmacs-1.0.6.14-1.fc9.ppc64 requires /bin/sh TeXmacs-1.0.6.14-1.fc9.ppc64 requires /usr/bin/env TeXmacs-1.0.6.14-1.fc9.ppc64 requires /bin/bash TeXmacs-1.0.6.14-1.fc9.ppc64 requires /bin/sh Terminal-0.2.8-3.fc9.ppc64 requires /bin/sh Terminal-0.2.8-3.fc9.ppc64 requires /bin/sh Thunar-0.9.0-4.fc9.ppc64 requires /bin/sh Thunar-0.9.0-4.fc9.ppc64 requires /bin/sh TnL-data-071111-1.fc9.noarch requires /bin/sh TurboGears-1.0.4.4-2.fc9.noarch requires /usr/bin/python VLGothic-fonts-20080429-1.fc10.noarch requires /bin/sh VLGothic-fonts-proportional-20080429-1.fc10.noarch requires /bin/sh WINGs-devel-0.92.0-17.fc9.ppc64 requires /bin/sh WINGs-libs-0.92.0-17.fc9.ppc64 requires /sbin/ldconfig WebKit-gtk-1.0.0-0.10.svn32531.fc10.ppc64 requires /sbin/ldconfig WindowMaker-0.92.0-17.fc9.ppc64 requires /sbin/ldconfig WindowMaker-0.92.0-17.fc9.ppc64 requires /usr/bin/perl WindowMaker-0.92.0-17.fc9.ppc64 requires /bin/sh WindowMaker-devel-0.92.0-17.fc9.ppc64 requires /bin/sh WritRecogn-0.1.9-0.fc10.ppc64 requires /bin/sh Xaw3d-1.5E-11.1.ppc64 requires /sbin/ldconfig Zim-0.23-2.fc9.noarch requires /usr/bin/perl a2ps-4.14-3.fc10.ppc64 requires /sbin/install-info a2ps-4.14-3.fc10.ppc64 requires /sbin/ldconfig a2ps-4.14-3.fc10.ppc64 requires /usr/bin/perl a2ps-4.14-3.fc10.ppc64 requires /bin/sh a2ps-4.14-3.fc10.ppc64 requires /bin/sh aalib-devel-1.4.0-0.15.rc5.fc9.ppc64 requires /bin/sh aalib-devel-1.4.0-0.15.rc5.fc9.ppc64 requires /sbin/install-info aalib-devel-1.4.0-0.15.rc5.fc9.ppc64 requires /bin/sh aalib-libs-1.4.0-0.15.rc5.fc9.ppc64 requires /sbin/ldconfig abcde-2.3.99.6-6.noarch requires /bin/bash abcde-2.3.99.6-6.noarch requires /bin/sh abcde-2.3.99.6-6.noarch requires /usr/bin/python 1:abiword-2.6.3-1.fc9.ppc64 requires /bin/sh 1:abiword-2.6.3-1.fc9.ppc64 requires /bin/sh 1:abiword-2.6.3-1.fc9.ppc64 requires /usr/bin/perl abuse-0.7.1-1.fc9.ppc64 requires /bin/sh abyssinica-fonts-1.0-2.fc8.noarch requires /bin/sh ack-1.78-1.fc9.noarch requires /usr/bin/perl adanaxisgpl-1.2.5-2.fc9.ppc64 requires /bin/sh adaptx-0.9.13-5jpp.3.fc9.ppc64 requires /bin/sh adaptx-javadoc-0.9.13-5jpp.3.fc9.ppc64 requires /bin/sh adaptx-javadoc-0.9.13-5jpp.3.fc9.ppc64 requires /bin/rm adaptx-javadoc-0.9.13-5jpp.3.fc9.ppc64 requires /bin/ln adime-2.2.1-7.fc9.ppc64 requires /sbin/ldconfig adime-devel-2.2.1-7.fc9.ppc64 requires /bin/sh adime-devel-2.2.1-7.fc9.ppc64 requires /sbin/install-info adminutil-1.1.6-1.fc9.ppc64 requires /sbin/ldconfig adns-1.4-3.fc9.ppc64 requires /sbin/ldconfig adplug-2.1-6.fc9.ppc64 requires /sbin/ldconfig adplug-devel-2.1-6.fc9.ppc64 requires /bin/sh adplug-devel-2.1-6.fc9.ppc64 requires /sbin/install-info afflib-3.1.6-1.fc9.ppc64 requires /sbin/ldconfig agave-0.4.2-7.fc9.ppc64 requires /bin/sh agg-2.5-6.fc9.ppc64 requires /sbin/ldconfig agistudio-1.2.3-7.fc9.ppc64 requires /bin/sh aiccu-2007.01.15-3.fc9.ppc64 requires /bin/sh aiccu-2007.01.15-3.fc9.ppc64 requires /bin/sh 1:aiksaurus-1.2.1-15.fc6.ppc64 requires /sbin/ldconfig 1:aiksaurus-gtk-1.2.1-15.fc6.ppc64 requires /bin/sh aircrack-ng-0.9.3-1.fc9.ppc64 requires /bin/sh akode-2.0.2-5.fc9.ppc64 requires /sbin/ldconfig akode-devel-2.0.2-5.fc9.ppc64 requires /bin/sh akonadi-0.80.0-2.fc10.ppc64 requires /bin/sh akonadi-0.80.0-2.fc10.ppc64 requires /sbin/ldconfig alacarte-0.11.5-1.fc9.noarch requires /bin/sh alacarte-0.11.5-1.fc9.noarch requires /usr/bin/python2.5 alchemist-1.0.37-4.fc9.ppc64 requires /usr/bin/python alchemist-1.0.37-4.fc9.ppc64 requires /sbin/ldconfig alex4-1.0-6.fc9.ppc64 requires /bin/sh alexandria-0.6.3-4.fc9.noarch requires /bin/sh alexandria-0.6.3-4.fc9.noarch requires /usr/bin/env alfont-2.0.6-4.fc9.ppc64 requires /sbin/ldconfig alienarena-6.10-6.fc9.ppc64 requires /bin/bash alienarena-data-20071011-2.fc9.noarch requires /bin/sh alienblaster-1.1.0-4.fc9.ppc64 requires /bin/sh alienblaster-1.1.0-4.fc9.ppc64 requires /bin/bash alleggl-0.4.3-3.fc9.ppc64 requires /sbin/ldconfig allegro-4.2.2-10.fc10.ppc64 requires /sbin/ldconfig allegro-devel-4.2.2-10.fc10.ppc64 requires /bin/sh allegro-devel-4.2.2-10.fc10.ppc64 requires /sbin/install-info allegro-devel-4.2.2-10.fc10.ppc64 requires /bin/sh alleyoop-0.9.3-4.fc9.ppc64 requires /bin/sh alliance-5.0-13.20070718snap.fc9.ppc64 requires /bin/sh alliance-5.0-13.20070718snap.fc9.ppc64 requires /bin/sh alltray-0.70-2.fc9.ppc64 requires /sbin/ldconfig alphabet-soup-1.1-4.fc9.ppc64 requires /bin/sh alsa-lib-1.0.16-3.fc9.ppc64 requires /sbin/ldconfig alsa-lib-1.0.16-3.fc9.ppc64 requires /bin/sh alsa-oss-1.0.15-0.1.fc9.ppc64 requires /bin/sh alsa-oss-libs-1.0.15-0.1.fc9.ppc64 requires /sbin/ldconfig alsa-utils-1.0.16-3.fc10.ppc64 requires /bin/bash 5:am-utils-6.1.5-8.fc9.ppc64 requires /bin/sh 5:am-utils-6.1.5-8.fc9.ppc64 requires /bin/sh 5:am-utils-6.1.5-8.fc9.ppc64 requires /sbin/install-info 5:am-utils-6.1.5-8.fc9.ppc64 requires /bin/grep 5:am-utils-6.1.5-8.fc9.ppc64 requires /usr/bin/perl 5:am-utils-6.1.5-8.fc9.ppc64 requires /bin/bash 5:am-utils-6.1.5-8.fc9.ppc64 requires /sbin/chkconfig amanda-2.5.2p1-10.fc9.ppc64 requires /bin/sh amanda-2.5.2p1-10.fc9.ppc64 requires /sbin/ldconfig amanda-2.5.2p1-10.fc9.ppc64 requires /usr/bin/Mail amanda-client-2.5.2p1-10.fc9.ppc64 requires /bin/sh amanda-client-2.5.2p1-10.fc9.ppc64 requires /sbin/service amanda-client-2.5.2p1-10.fc9.ppc64 requires /bin/sh amanda-server-2.5.2p1-10.fc9.ppc64 requires /bin/sh amanda-server-2.5.2p1-10.fc9.ppc64 requires /sbin/service amanda-server-2.5.2p1-10.fc9.ppc64 requires /usr/bin/perl amanda-server-2.5.2p1-10.fc9.ppc64 requires /bin/sh amanith-0.3-9.fc9.ppc64 requires /sbin/ldconfig amarok-1.4.8-5.fc9.ppc64 requires /bin/sh amarok-1.4.8-5.fc9.ppc64 requires /usr/bin/env amarokFS-0.5-3.fc9.ppc64 requires /bin/sh amarokFS-0.5-3.fc9.ppc64 requires /usr/bin/env amavisd-new-2.5.2-2.fc8.noarch requires /bin/sh amavisd-new-2.5.2-2.fc8.noarch requires /usr/sbin/useradd amavisd-new-2.5.2-2.fc8.noarch requires /sbin/service amavisd-new-2.5.2-2.fc8.noarch requires /usr/sbin/clamd amavisd-new-2.5.2-2.fc8.noarch requires /usr/bin/ar amavisd-new-2.5.2-2.fc8.noarch requires /usr/sbin/tmpwatch amavisd-new-2.5.2-2.fc8.noarch requires /etc/cron.daily amavisd-new-2.5.2-2.fc8.noarch requires /bin/bash amavisd-new-2.5.2-2.fc8.noarch requires /bin/sh amavisd-new-2.5.2-2.fc8.noarch requires /usr/bin/perl amavisd-new-2.5.2-2.fc8.noarch requires /etc/clamd.d amavisd-new-2.5.2-2.fc8.noarch requires /sbin/chkconfig amoebax-0.2.0-3.fc9.ppc64 requires /bin/sh amsn-0.97-3.fc9.ppc64 requires /bin/sh amsn-0.97-3.fc9.ppc64 requires /usr/bin/tclsh amsn-0.97-3.fc9.ppc64 requires /usr/bin/env amsn-0.97-3.fc9.ppc64 requires /usr/bin/wish amsn-0.97-3.fc9.ppc64 requires /bin/sh amtterm-1.0-2.fc9.ppc64 requires /usr/bin/perl anaconda-11.4.1.1-1.ppc64 requires /bin/sh anaconda-11.4.1.1-1.ppc64 requires /usr/bin/python anaconda-11.4.1.1-1.ppc64 requires /bin/sh anaconda-runtime-11.4.1.1-1.ppc64 requires /usr/bin/env anaconda-runtime-11.4.1.1-1.ppc64 requires /usr/bin/python anaconda-runtime-11.4.1.1-1.ppc64 requires /bin/bash anaconda-runtime-11.4.1.1-1.ppc64 requires /bin/sh anacron-2.3-59.fc9.ppc64 requires /bin/sh anacron-2.3-59.fc9.ppc64 requires /sbin/chkconfig anacron-2.3-59.fc9.ppc64 requires /bin/sh anacron-2.3-59.fc9.ppc64 requires /sbin/service and-1.2.2-6.fc9.ppc64 requires /bin/sh and-1.2.2-6.fc9.ppc64 requires /sbin/chkconfig and-1.2.2-6.fc9.ppc64 requires /bin/sh and-1.2.2-6.fc9.ppc64 requires /sbin/service angrydd-1.0.1-3.fc8.noarch requires /bin/sh angrydd-1.0.1-3.fc8.noarch requires /usr/bin/env animorph-0.3-3.fc9.ppc64 requires /sbin/ldconfig 1:anjuta-2.2.3-7.fc9.ppc64 requires /bin/sh 1:anjuta-2.2.3-7.fc9.ppc64 requires /sbin/ldconfig 1:anjuta-2.2.3-7.fc9.ppc64 requires /usr/bin/perl 1:anjuta-2.2.3-7.fc9.ppc64 requires /bin/bash 1:anjuta-doc-2.2.3-7.fc9.ppc64 requires /bin/sh ant-1.7.0-1jpp.4.fc9.ppc64 requires /bin/sh ant-antlr-1.7.0-1jpp.4.fc9.ppc64 requires /bin/sh ant-apache-bcel-1.7.0-1jpp.4.fc9.ppc64 requires /bin/sh ant-apache-bsf-1.7.0-1jpp.4.fc9.ppc64 requires /bin/sh ant-apache-log4j-1.7.0-1jpp.4.fc9.ppc64 requires /bin/sh ant-apache-oro-1.7.0-1jpp.4.fc9.ppc64 requires /bin/sh ant-apache-regexp-1.7.0-1jpp.4.fc9.ppc64 requires /bin/sh ant-apache-resolver-1.7.0-1jpp.4.fc9.ppc64 requires /bin/sh ant-commons-logging-1.7.0-1jpp.4.fc9.ppc64 requires /bin/sh ant-commons-net-1.7.0-1jpp.4.fc9.ppc64 requires /bin/sh ant-contrib-1.0-0.5.b2.fc9.ppc64 requires /bin/sh ant-javamail-1.7.0-1jpp.4.fc9.ppc64 requires /bin/sh ant-jdepend-1.7.0-1jpp.4.fc9.ppc64 requires /bin/sh ant-jmf-1.7.0-1jpp.4.fc9.ppc64 requires /bin/sh ant-jsch-1.7.0-1jpp.4.fc9.ppc64 requires /bin/sh ant-junit-1.7.0-1jpp.4.fc9.ppc64 requires /bin/sh ant-nodeps-1.7.0-1jpp.4.fc9.ppc64 requires /bin/sh ant-scripts-1.7.0-1jpp.4.fc9.ppc64 requires /usr/bin/python ant-swing-1.7.0-1jpp.4.fc9.ppc64 requires /bin/sh ant-trax-1.7.0-1jpp.4.fc9.ppc64 requires /bin/sh anthy-9100e-2.fc9.ppc64 requires /sbin/ldconfig antiword-0.37-7.fc9.ppc64 requires /bin/sh antlr-2.7.7-1jpp.7.fc9.ppc64 requires /usr/sbin/update-alternatives antlr-2.7.7-1jpp.7.fc9.ppc64 requires /bin/sh antlr-2.7.7-1jpp.7.fc9.ppc64 requires /bin/sh antlr-javadoc-2.7.7-1jpp.7.fc9.ppc64 requires /bin/sh antlr-javadoc-2.7.7-1jpp.7.fc9.ppc64 requires /bin/rm antlr-javadoc-2.7.7-1jpp.7.fc9.ppc64 requires /bin/ln ants-1.4-4.fc9.ppc64 requires /bin/sh anyremote-data-4.4-1.fc8.ppc64 requires /usr/bin/env aoetools-23-1.fc9.ppc64 requires /bin/bash aoetools-23-1.fc9.ppc64 requires /bin/sh apcupsd-3.14.3-2.1.fc9.ppc64 requires /bin/sh apcupsd-3.14.3-2.1.fc9.ppc64 requires /sbin/service apcupsd-3.14.3-2.1.fc9.ppc64 requires /bin/sh apcupsd-3.14.3-2.1.fc9.ppc64 requires /sbin/chkconfig apcupsd-3.14.3-2.1.fc9.ppc64 requires /bin/mail apg-2.3.0b-6.fc9.ppc64 requires /bin/sh aplus-fsf-4.22.1-3.fc10.ppc64 requires /sbin/ldconfig apollon-1.0.1-13.fc9.ppc64 requires /bin/sh apollon-libs-1.0.1-13.fc9.ppc64 requires /sbin/ldconfig apr-1.2.12-2.fc9.ppc64 requires /sbin/ldconfig apr-devel-1.2.12-2.fc9.ppc64 requires /bin/sh apr-util-1.2.12-5.fc9.ppc64 requires /sbin/ldconfig apr-util-devel-1.2.12-5.fc9.ppc64 requires /bin/sh aprsd-2.2.5-15.3.fc9.ppc64 requires /bin/sh aprsd-2.2.5-15.3.fc9.ppc64 requires /sbin/service aprsd-2.2.5-15.3.fc9.ppc64 requires /bin/bash aprsd-2.2.5-15.3.fc9.ppc64 requires /sbin/chkconfig apt-0.5.15lorg3.94-3.fc9.ppc64 requires /bin/sh apt-0.5.15lorg3.94-3.fc9.ppc64 requires /sbin/ldconfig apt-0.5.15lorg3.94-3.fc9.ppc64 requires /bin/bash apt-0.5.15lorg3.94-3.fc9.ppc64 requires /bin/sh aqbanking-2.3.3-3.fc9.ppc64 requires /sbin/ldconfig aqbanking-devel-2.3.3-3.fc9.ppc64 requires /bin/sh aqsis-1.2.0-8.fc9.ppc64 requires /sbin/ldconfig aqsis-1.2.0-8.fc9.ppc64 requires /usr/bin/env aqsis-data-1.2.0-8.fc9.ppc64 requires /bin/bash archivemail-0.7.2-1.fc9.noarch requires /usr/bin/env archmage-0.1.9-2.fc9.noarch requires /usr/bin/python ardour-2.4.1-1.fc9.ppc64 requires /bin/sh ardour-2.4.1-1.fc9.ppc64 requires /bin/sh argus-2.0.6.fixes.1-15.fc9.ppc64 requires /sbin/chkconfig argus-2.0.6.fixes.1-15.fc9.ppc64 requires /bin/sh argus-2.0.6.fixes.1-15.fc9.ppc64 requires /bin/sh arj-3.10.22-4.fc9.ppc64 requires /bin/sh arm-gp2x-linux-gcc-4.1.2-8.fc9.ppc64 requires /bin/sh armacycles-ad-0.2.8.2.1-6.fc9.ppc64 requires /bin/sh armacycles-ad-0.2.8.2.1-6.fc9.ppc64 requires /bin/bash armacycles-ad-dedicated-0.2.8.2.1-6.fc9.ppc64 requires /bin/bash arp-scan-1.6-2.fc9.ppc64 requires /usr/bin/perl arpack-2.1-7.fc9.ppc64 requires /sbin/ldconfig arptables_jf-0.0.8-12.fc9.ppc64 requires /bin/sh arptables_jf-0.0.8-12.fc9.ppc64 requires /bin/sh 14:arpwatch-2.1a15-8.fc9.ppc64 requires /bin/sh 14:arpwatch-2.1a15-8.fc9.ppc64 requires /bin/bash 14:arpwatch-2.1a15-8.fc9.ppc64 requires /sbin/chkconfig 14:arpwatch-2.1a15-8.fc9.ppc64 requires /bin/sh 14:arpwatch-2.1a15-8.fc9.ppc64 requires /sbin/service arrows-0.6-6.fc9.ppc64 requires /bin/sh 8:arts-1.5.9-3.fc10.ppc64 requires /sbin/ldconfig 8:arts-1.5.9-3.fc10.ppc64 requires /bin/sh 8:arts-devel-1.5.9-3.fc10.ppc64 requires /bin/sh artwiz-aleczapka-fonts-1.3-5.fc8.1.noarch requires /bin/sh asc-2.1.0.0-1.fc10.ppc64 requires /bin/sh asciidoc-8.2.5-2.fc9.noarch requires /usr/bin/env asm2-2.2.3-2jpp.1.fc9.noarch requires /bin/sh 12:aspell-0.60.6-1.fc10.ppc64 requires /bin/sh 12:aspell-0.60.6-1.fc10.ppc64 requires /sbin/install-info 12:aspell-0.60.6-1.fc10.ppc64 requires /sbin/ldconfig 12:aspell-0.60.6-1.fc10.ppc64 requires /bin/sh 12:aspell-devel-0.60.6-1.fc10.ppc64 requires /bin/sh 12:aspell-devel-0.60.6-1.fc10.ppc64 requires /sbin/install-info 12:aspell-devel-0.60.6-1.fc10.ppc64 requires /bin/sh asterisk-1.6.0-0.13.beta8.fc10.ppc64 requires /bin/sh asterisk-1.6.0-0.13.beta8.fc10.ppc64 requires /usr/sbin/groupadd asterisk-1.6.0-0.13.beta8.fc10.ppc64 requires /usr/sbin/useradd asterisk-1.6.0-0.13.beta8.fc10.ppc64 requires /sbin/service asterisk-1.6.0-0.13.beta8.fc10.ppc64 requires /bin/bash asterisk-1.6.0-0.13.beta8.fc10.ppc64 requires /bin/sh asterisk-1.6.0-0.13.beta8.fc10.ppc64 requires /sbin/chkconfig asterisk-misdn-1.6.0-0.13.beta8.fc10.ppc64 requires /bin/sh asterisk-misdn-1.6.0-0.13.beta8.fc10.ppc64 requires /usr/sbin/usermod asterisk-voicemail-1.6.0-0.13.beta8.fc10.ppc64 requires /usr/bin/sox asterisk-zaptel-1.6.0-0.13.beta8.fc10.ppc64 requires /bin/sh asterisk-zaptel-1.6.0-0.13.beta8.fc10.ppc64 requires /usr/sbin/usermod astromenace-1.2-8.fc9.ppc64 requires /bin/sh asylum-0.2.3-3.fc9.ppc64 requires /bin/sh asymptote-1.42-3.fc10.ppc64 requires /bin/sh asymptote-1.42-3.fc10.ppc64 requires /usr/bin/env at-3.1.10-23.fc9.ppc64 requires /bin/sh at-3.1.10-23.fc9.ppc64 requires /bin/bash at-3.1.10-23.fc9.ppc64 requires /bin/sh at-spi-1.22.1-2.fc10.ppc64 requires /sbin/ldconfig aterm-1.0.1-2.fc9.ppc64 requires /bin/sh atk-1.22.0-1.fc9.ppc64 requires /sbin/ldconfig atlas-3.6.0-15.fc10.ppc64 requires /sbin/ldconfig atlas-3.6.0-15.fc10.ppc64 requires /etc/ld.so.conf.d atlascpp-0.6.1-3.fc9.ppc64 requires /sbin/ldconfig atomorun-1.1-0.8.pre2.fc9.ppc64 requires /bin/sh atop-1.23-7.fc10.ppc64 requires /bin/sh atop-1.23-7.fc10.ppc64 requires /bin/bash atop-1.23-7.fc10.ppc64 requires /sbin/chkconfig atop-1.23-7.fc10.ppc64 requires /sbin/service audacious-1.4.6-1.fc9.ppc64 requires /bin/sh audacious-devel-1.4.6-1.fc9.ppc64 requires /sbin/ldconfig audacious-libs-1.4.6-1.fc9.ppc64 requires /sbin/ldconfig audacious-plugins-1.4.5-1.fc9.ppc64 requires /bin/sh audacious-plugins-1.4.5-1.fc9.ppc64 requires /sbin/ldconfig audacity-1.3.5-0.4.beta.fc10.ppc64 requires /bin/sh audio-convert-mod-3.45.4-1.fc10.noarch requires /bin/bash audio-entropyd-1.0.1-2.fc9.ppc64 requires /bin/sh audio-entropyd-1.0.1-2.fc9.ppc64 requires /bin/sh 1:audiofile-0.2.6-8.fc9.ppc64 requires /sbin/ldconfig 1:audiofile-devel-0.2.6-8.fc9.ppc64 requires /bin/sh audispd-plugins-1.7.3-1.fc10.ppc64 requires /usr/sbin/semodule audispd-plugins-1.7.3-1.fc10.ppc64 requires /bin/sh audispd-plugins-1.7.3-1.fc10.ppc64 requires /sbin/restorecon audit-1.7.3-1.fc10.ppc64 requires /bin/sh audit-1.7.3-1.fc10.ppc64 requires /bin/bash audit-libs-1.7.3-1.fc10.ppc64 requires /sbin/ldconfig audit-viewer-0.2-2.fc10.ppc64 requires /bin/sh audit-viewer-0.2-2.fc10.ppc64 requires /bin/sh augeas-libs-0.1.1-1.fc10.ppc64 requires /sbin/ldconfig aumix-2.8-17.fc9.ppc64 requires /bin/sh auriferous-1.0.1-5.fc9.ppc64 requires /bin/sh authconfig-5.4.2-1.fc9.ppc64 requires /usr/bin/python authconfig-5.4.2-1.fc9.ppc64 requires /bin/sh authconfig-gtk-5.4.2-1.fc9.ppc64 requires /usr/bin/python authd-1.4.3-19.fc9.ppc64 requires /bin/sh autobuild-applet-1.0.3-5.fc9.ppc64 requires /bin/sh autobuild-applet-1.0.3-5.fc9.ppc64 requires /usr/bin/python autoconf-2.62-1.fc10.noarch requires /bin/sh autoconf-2.62-1.fc10.noarch requires /sbin/install-info autoconf-2.62-1.fc10.noarch requires /usr/bin/perl autoconf-2.62-1.fc10.noarch requires /bin/sh autoconf213-2.13-18.fc8.noarch requires /bin/sh autoconf213-2.13-18.fc8.noarch requires /usr/bin/perl autoconf213-2.13-18.fc8.noarch requires /sbin/install-info autoconf213-2.13-18.fc8.noarch requires /bin/sh autodir-0.99.9-5.fc9.ppc64 requires /bin/sh autodir-0.99.9-5.fc9.ppc64 requires /sbin/service autodir-0.99.9-5.fc9.ppc64 requires /bin/sh autodir-0.99.9-5.fc9.ppc64 requires /sbin/chkconfig autodownloader-0.2.0-6.fc9.noarch requires /usr/bin/env 1:autofs-5.0.3-16.ppc64 requires /bin/sh 1:autofs-5.0.3-16.ppc64 requires /bin/ps 1:autofs-5.0.3-16.ppc64 requires /sbin/service 1:autofs-5.0.3-16.ppc64 requires /bin/bash 1:autofs-5.0.3-16.ppc64 requires /sbin/chkconfig autogen-5.9.4-4.fc9.ppc64 requires /bin/sh autogen-5.9.4-4.fc9.ppc64 requires /sbin/install-info autogen-libopts-5.9.4-4.fc9.ppc64 requires /sbin/ldconfig autogen-libopts-devel-5.9.4-4.fc9.ppc64 requires /bin/sh automake-1.10.1-2.noarch requires /bin/sh automake-1.10.1-2.noarch requires /sbin/install-info automake-1.10.1-2.noarch requires /bin/sh automake-1.10.1-2.noarch requires /usr/bin/perl automake14-1.4p6-15.fc7.noarch requires /bin/sh automake14-1.4p6-15.fc7.noarch requires /usr/bin/perl automake14-1.4p6-15.fc7.noarch requires /sbin/install-info automake14-1.4p6-15.fc7.noarch requires /bin/sh automake15-1.5-23.noarch requires /bin/sh automake15-1.5-23.noarch requires /usr/bin/perl automake15-1.5-23.noarch requires /sbin/install-info automake15-1.5-23.noarch requires /bin/sh automake16-1.6.3-14.noarch requires /bin/sh automake16-1.6.3-14.noarch requires /sbin/install-info automake16-1.6.3-14.noarch requires /bin/sh automake16-1.6.3-14.noarch requires /usr/bin/perl automake17-1.7.9-11.noarch requires /bin/sh automake17-1.7.9-11.noarch requires /sbin/install-info automake17-1.7.9-11.noarch requires /bin/sh automake17-1.7.9-11.noarch requires /usr/bin/perl autossh-1.4a-1.fc9.ppc64 requires /usr/bin/ssh autotrace-0.31.1-16.fc9.ppc64 requires libWand.so.10()(64bit) autotrace-0.31.1-16.fc9.ppc64 requires /sbin/ldconfig autotrace-0.31.1-16.fc9.ppc64 requires libMagick.so.10()(64bit) autotrace-devel-0.31.1-16.fc9.ppc64 requires /bin/sh avahi-0.6.22-10.fc9.ppc64 requires /bin/sh avahi-0.6.22-10.fc9.ppc64 requires /bin/sh avahi-autoipd-0.6.22-10.fc9.ppc64 requires /bin/sh avahi-autoipd-0.6.22-10.fc9.ppc64 requires /bin/sh avahi-compat-howl-0.6.22-10.fc9.ppc64 requires /sbin/ldconfig avahi-compat-libdns_sd-0.6.22-10.fc9.ppc64 requires /sbin/ldconfig avahi-dnsconfd-0.6.22-10.fc9.ppc64 requires /bin/sh avahi-dnsconfd-0.6.22-10.fc9.ppc64 requires /bin/sh avahi-glib-0.6.22-10.fc9.ppc64 requires /sbin/ldconfig avahi-gobject-0.6.22-10.fc9.ppc64 requires /sbin/ldconfig avahi-qt3-0.6.22-10.fc9.ppc64 requires /sbin/ldconfig avahi-tools-0.6.22-10.fc9.ppc64 requires /usr/bin/python avahi-ui-0.6.22-10.fc9.ppc64 requires /sbin/ldconfig avalon-framework-4.1.4-3jpp.14.fc9.ppc64 requires /bin/sh avalon-framework-javadoc-4.1.4-3jpp.14.fc9.ppc64 requires /bin/rm avalon-framework-javadoc-4.1.4-3jpp.14.fc9.ppc64 requires /bin/ln avalon-logkit-1.2-5jpp.5.fc9.ppc64 requires /bin/sh avalon-logkit-javadoc-1.2-5jpp.5.fc9.ppc64 requires /bin/sh avalon-logkit-javadoc-1.2-5jpp.5.fc9.ppc64 requires /bin/rm avalon-logkit-javadoc-1.2-5jpp.5.fc9.ppc64 requires /bin/ln avant-window-navigator-0.2.6-8.fc9.ppc64 requires /bin/sh avant-window-navigator-0.2.6-8.fc9.ppc64 requires /usr/bin/env avant-window-navigator-0.2.6-8.fc9.ppc64 requires /usr/bin/python avant-window-navigator-0.2.6-8.fc9.ppc64 requires /bin/bash avarice-2.6-2.fc9.ppc64 requires /usr/bin/perl avarice-2.6-2.fc9.ppc64 requires /bin/sh avr-gcc-4.1.2-6.fc9.ppc64 requires /bin/sh avr-libc-1.4.6-4.fc8.noarch requires /bin/sh avrdude-5.5-3.fc9.ppc64 requires /bin/sh avrdude-5.5-3.fc9.ppc64 requires /sbin/install-info awn-extras-applets-0.2.6-4.fc9.ppc64 requires /bin/sh awn-extras-applets-0.2.6-4.fc9.ppc64 requires /usr/bin/python awn-extras-applets-0.2.6-4.fc9.ppc64 requires /usr/bin/env awstats-6.7-3.fc9.noarch requires /bin/bash awstats-6.7-3.fc9.noarch requires /usr/bin/perl awstats-6.7-3.fc9.noarch requires /bin/sh awstats-6.7-3.fc9.noarch requires /sbin/service awstats-selinux-6.7-3.fc9.noarch requires /bin/sh ax25-tools-0.0.8-2.fc9.ppc64 requires /bin/sh axis-1.2.1-3jpp.8.fc9.ppc64 requires /bin/sh azureus-3.0.4.2-14.fc9.ppc64 requires /bin/sh azureus-3.0.4.2-14.fc9.ppc64 requires /bin/sh babel-0.9.2-1.fc9.noarch requires /usr/bin/python babl-0.0.20-1.fc9.ppc64 requires /sbin/ldconfig bacula-client-2.0.3-13.fc9.ppc64 requires /bin/sh bacula-client-2.0.3-13.fc9.ppc64 requires /sbin/service bacula-client-2.0.3-13.fc9.ppc64 requires /bin/bash bacula-client-2.0.3-13.fc9.ppc64 requires /sbin/chkconfig bacula-common-2.0.3-13.fc9.ppc64 requires /bin/sh bacula-common-2.0.3-13.fc9.ppc64 requires /bin/sh bacula-director-common-2.0.3-13.fc9.ppc64 requires /bin/sh bacula-director-common-2.0.3-13.fc9.ppc64 requires /bin/bash bacula-director-common-2.0.3-13.fc9.ppc64 requires /bin/sh bacula-director-common-2.0.3-13.fc9.ppc64 requires /usr/bin/perl bacula-director-mysql-2.0.3-13.fc9.ppc64 requires /bin/sh bacula-director-mysql-2.0.3-13.fc9.ppc64 requires /bin/sh bacula-director-postgresql-2.0.3-13.fc9.ppc64 requires /bin/sh bacula-director-postgresql-2.0.3-13.fc9.ppc64 requires /bin/sh bacula-director-sqlite-2.0.3-13.fc9.ppc64 requires /bin/sh bacula-director-sqlite-2.0.3-13.fc9.ppc64 requires /bin/sh bacula-storage-common-2.0.3-13.fc9.ppc64 requires /bin/sh bacula-storage-common-2.0.3-13.fc9.ppc64 requires /usr/bin/python bacula-storage-common-2.0.3-13.fc9.ppc64 requires /bin/bash bacula-storage-common-2.0.3-13.fc9.ppc64 requires /bin/sh bacula-storage-mysql-2.0.3-13.fc9.ppc64 requires /bin/sh bacula-storage-postgresql-2.0.3-13.fc9.ppc64 requires /bin/sh bacula-storage-sqlite-2.0.3-13.fc9.ppc64 requires /bin/sh baekmuk-bdf-fonts-2.2-5.fc9.noarch requires /bin/sh baekmuk-ttf-fonts-batang-2.2-7.fc9.noarch requires /bin/sh baekmuk-ttf-fonts-dotum-2.2-7.fc9.noarch requires /bin/sh baekmuk-ttf-fonts-gulim-2.2-7.fc9.noarch requires /bin/sh baekmuk-ttf-fonts-hline-2.2-7.fc9.noarch requires /bin/sh bakery-2.4.4-2.fc9.ppc64 requires /sbin/ldconfig ballbuster-1.0-5.fc9.ppc64 requires /bin/sh ballz-1.0-3.fc9.ppc64 requires /bin/sh balsa-2.3.23-1.fc9.ppc64 requires /bin/sh barcode-0.98-11.fc9.ppc64 requires /bin/sh barcode-0.98-11.fc9.ppc64 requires /sbin/install-info bash-3.2-22.fc9.ppc64 requires /bin/sh bash-3.2-22.fc9.ppc64 requires /bin/bash bash-3.2-22.fc9.ppc64 requires /bin/sh bash-completion-20060301-10.noarch requires /bin/sh basket-1.0.2-5.fc9.ppc64 requires /bin/sh bazaar-1.4.2-11.fc9.ppc64 requires /usr/bin/gawk bc-1.06-33.fc9.ppc64 requires /bin/sh bc-1.06-33.fc9.ppc64 requires /sbin/install-info bcel-5.2-4jpp.2.fc9.ppc64 requires /bin/sh bcfg2-0.9.5.7-1.fc9.noarch requires /bin/sh bcfg2-0.9.5.7-1.fc9.noarch requires /sbin/chkconfig bcfg2-0.9.5.7-1.fc9.noarch requires /bin/sh bcfg2-0.9.5.7-1.fc9.noarch requires /usr/bin/python bcfg2-0.9.5.7-1.fc9.noarch requires /sbin/service bcfg2-server-0.9.5.7-1.fc9.noarch requires /bin/sh bcfg2-server-0.9.5.7-1.fc9.noarch requires /usr/bin/openssl bcfg2-server-0.9.5.7-1.fc9.noarch requires /sbin/chkconfig bcfg2-server-0.9.5.7-1.fc9.noarch requires /bin/sh bcfg2-server-0.9.5.7-1.fc9.noarch requires /usr/bin/python bcfg2-server-0.9.5.7-1.fc9.noarch requires /sbin/service 1:bdftruncate-7.2-4.fc9.ppc64 requires /usr/bin/perl bea-stax-1.2.0-0.2.rc1.2jpp.1.fc9.ppc64 requires /bin/sh bea-stax-api-1.2.0-0.2.rc1.2jpp.1.fc9.ppc64 requires /bin/sh berusky-1.1-8.fc9.ppc64 requires /bin/sh bes-3.5.3-3.fc9.ppc64 requires /bin/sh bes-3.5.3-3.fc9.ppc64 requires /sbin/ldconfig bes-3.5.3-3.fc9.ppc64 requires /bin/sh bes-devel-3.5.3-3.fc9.ppc64 requires /bin/sh bibexport-2.10-2.fc9.noarch requires /usr/bin/texhash bibexport-2.10-2.fc9.noarch requires /bin/sh bibexport-2.10-2.fc9.noarch requires /bin/sh bibletime-1.6.5-4.fc9.ppc64 requires /bin/sh bibus-1.4.1-4.fc9.noarch requires /usr/bin/env bigboard-0.5.33-2.fc10.ppc64 requires /bin/sh bigboard-0.5.33-2.fc10.ppc64 requires /bin/sh biloba-0.6-1.fc10.ppc64 requires /bin/sh 32:bind-9.5.0-33.rc1.fc10.ppc64 requires /bin/sh 32:bind-9.5.0-33.rc1.fc10.ppc64 requires /bin/bash 32:bind-9.5.0-33.rc1.fc10.ppc64 requires /bin/sh 32:bind-chroot-9.5.0-33.rc1.fc10.ppc64 requires /bin/sh 32:bind-chroot-9.5.0-33.rc1.fc10.ppc64 requires /bin/bash 32:bind-chroot-9.5.0-33.rc1.fc10.ppc64 requires /bin/sh 32:bind-devel-9.5.0-33.rc1.fc10.ppc64 requires /bin/sh 32:bind-libs-9.5.0-33.rc1.fc10.ppc64 requires /sbin/ldconfig 32:bind-sdb-9.5.0-33.rc1.fc10.ppc64 requires /bin/sh binutils-2.18.50.0.6-2.ppc64 requires /bin/sh binutils-2.18.50.0.6-2.ppc64 requires /sbin/ldconfig binutils-2.18.50.0.6-2.ppc64 requires /sbin/install-info binutils-2.18.50.0.6-2.ppc64 requires /bin/sh binutils-devel-2.18.50.0.6-2.ppc64 requires /bin/sh binutils-devel-2.18.50.0.6-2.ppc64 requires /sbin/install-info bison-2.3-5.fc9.ppc64 requires /bin/sh bison-2.3-5.fc9.ppc64 requires /sbin/install-info bit-0.4.1-3.fc9.ppc64 requires /sbin/ldconfig bitbake-1.8.8-1.fc8.noarch requires /usr/bin/python bitgtkmm-0.4.0-2.fc7.ppc64 requires /sbin/ldconfig bitlbee-1.2-1.fc9.ppc64 requires /bin/sh bitlbee-1.2-1.fc9.ppc64 requires /sbin/service bitmap-1.0.3-4.fc9.ppc64 requires /bin/sh bitmap-fonts-0.3-5.2.fc9.noarch requires /bin/sh bitmap-fonts-cjk-0.3-5.2.fc9.noarch requires /bin/sh bitstream-vera-fonts-1.10-8.noarch requires /bin/sh bittorrent-4.4.0-6.fc9.noarch requires /bin/sh bittorrent-4.4.0-6.fc9.noarch requires /bin/bash bittorrent-4.4.0-6.fc9.noarch requires /sbin/chkconfig bittorrent-4.4.0-6.fc9.noarch requires /usr/sbin/useradd bittorrent-4.4.0-6.fc9.noarch requires /usr/bin/python bittorrent-4.4.0-6.fc9.noarch requires /sbin/service bittorrent-4.4.0-6.fc9.noarch requires /usr/sbin/usermod bittorrent-gui-4.4.0-6.fc9.noarch requires /bin/sh bittorrent-gui-4.4.0-6.fc9.noarch requires /usr/bin/python blackbox-0.70.1-11.ppc64 requires /sbin/ldconfig blackbox-0.70.1-11.ppc64 requires /bin/sh blacs-1.1-26.fc9.1.ppc64 requires /sbin/ldconfig blas-3.1.1-3.fc9.ppc64 requires /sbin/ldconfig blender-2.46-0.3.fc10.ppc64 requires /bin/sh blender-2.46-0.3.fc10.ppc64 requires /bin/sh blitz-0.9-7.fc9.ppc64 requires /sbin/ldconfig blitz-0.9-7.fc9.ppc64 requires /sbin/install-info blitz-devel-0.9-7.fc9.ppc64 requires /bin/sh blktrace-0.0-0.9.20080103162505.fc9.ppc64 requires /bin/sh blobAndConquer-0.93-1.fc10.ppc64 requires /bin/sh blobby-0.6-0.7.a.fc8.ppc64 requires /bin/sh blobwars-1.07-2.fc9.ppc64 requires /bin/sh blogtk-1.1-9.fc9.noarch requires /usr/bin/env blogtk-1.1-9.fc9.noarch requires /bin/sh blt-2.4-27.fc9.ppc64 requires /sbin/ldconfig blt-2.4-27.fc9.ppc64 requires /usr/bin/wish blt-2.4-27.fc9.ppc64 requires /usr/bin/tclsh bluecurve-icon-theme-8.0.2-1.fc9.noarch requires /bin/sh bluefish-1.0.7-4.fc9.ppc64 requires /bin/sh bluez-gnome-0.25-1.fc9.ppc64 requires /bin/sh bluez-libs-3.31-1.fc10.ppc64 requires /sbin/ldconfig bluez-utils-3.31-1.fc10.ppc64 requires /bin/sh bluez-utils-3.31-1.fc10.ppc64 requires /sbin/service bluez-utils-3.31-1.fc10.ppc64 requires /sbin/chkconfig bluez-utils-3.31-1.fc10.ppc64 requires /bin/sh bmpx-0.40.13-11.fc9.ppc64 requires /bin/sh bmpx-0.40.13-11.fc9.ppc64 requires /bin/sh boa-0.94.14-0.10.rc21.fc9.ppc64 requires /bin/sh boa-0.94.14-0.10.rc21.fc9.ppc64 requires /bin/bash boa-0.94.14-0.10.rc21.fc9.ppc64 requires /etc/mime.types boa-0.94.14-0.10.rc21.fc9.ppc64 requires /sbin/chkconfig boa-0.94.14-0.10.rc21.fc9.ppc64 requires /usr/sbin/useradd boa-0.94.14-0.10.rc21.fc9.ppc64 requires /sbin/service bochs-dlxlinux-2.3.6-3.fc9.ppc64 requires /bin/sh bodhi-client-0.4.10-3.fc9.noarch requires /usr/bin/python bodhi-server-0.4.10-3.fc9.noarch requires /usr/bin/python bodhi-server-0.4.10-3.fc9.noarch requires /usr/bin/env bogl-0.1.18-14.ppc64 requires /sbin/ldconfig bogl-devel-0.1.18-14.ppc64 requires /usr/bin/perl bogofilter-1.1.6-2.fc9.ppc64 requires /bin/sh bogofilter-1.1.6-2.fc9.ppc64 requires /usr/bin/perl boinc-client-5.10.45-13.20080315svn.fc10.ppc64 requires /bin/sh boinc-client-5.10.45-13.20080315svn.fc10.ppc64 requires /bin/sh boinc-manager-5.10.45-13.20080315svn.fc10.ppc64 requires /bin/sh bolzplatz2006-1.0.3-6.fc9.ppc64 requires /bin/sh bolzplatz2006-1.0.3-6.fc9.ppc64 requires /bin/sh bombardier-0.8.2.2-8.fc9.ppc64 requires /bin/sh bonnie++-1.03a-9.fc9.ppc64 requires /usr/bin/perl bontmia-0.14-2.fc8.noarch requires /bin/bash boolstuff-0.1.11-5.fc9.ppc64 requires /sbin/ldconfig boost-1.34.1-13.fc9.ppc64 requires /sbin/ldconfig bootchart-0.9-9.fc9.ppc64 requires /bin/sh bootchart-0.9-9.fc9.ppc64 requires /bin/sh bootparamd-0.17-27.fc9.ppc64 requires /bin/sh bootparamd-0.17-27.fc9.ppc64 requires /sbin/chkconfig bootparamd-0.17-27.fc9.ppc64 requires /bin/sh bootparamd-0.17-27.fc9.ppc64 requires /sbin/service boswars-2.5-1.fc9.ppc64 requires /bin/sh bouml-4.3.3-1.fc10.ppc64 requires /bin/sh bouml-4.3.3-1.fc10.ppc64 requires /bin/sh bouncycastle-1.39-1.fc10.ppc64 requires /bin/sh bpython-0.3.1-2.fc10.noarch requires /usr/bin/python brasero-0.7.1-4.fc10.ppc64 requires /bin/sh brazil-2.3-3.fc10.ppc64 requires /usr/bin/rebuild-gcj-db brazil-demo-2.3-3.fc10.ppc64 requires /usr/bin/tclsh brazil-demo-2.3-3.fc10.ppc64 requires /bin/sh brettfont-fonts-20080506-2.fc10.noarch requires /bin/sh brltty-3.9-2.2.fc9.ppc64 requires /bin/sh brltty-3.9-2.2.fc9.ppc64 requires /bin/bash brltty-3.9-2.2.fc9.ppc64 requires /bin/sh 1:broffice.org-base-3.0.0-0.0.12.1.fc10.ppc64 requires /bin/sh 1:broffice.org-base-3.0.0-0.0.12.1.fc10.ppc64 requires /bin/sh 1:broffice.org-brand-3.0.0-0.0.12.1.fc10.ppc64 requires /bin/sh 1:broffice.org-brand-3.0.0-0.0.12.1.fc10.ppc64 requires /bin/sh 1:broffice.org-calc-3.0.0-0.0.12.1.fc10.ppc64 requires /bin/sh 1:broffice.org-calc-3.0.0-0.0.12.1.fc10.ppc64 requires /bin/sh 1:broffice.org-draw-3.0.0-0.0.12.1.fc10.ppc64 requires /bin/sh 1:broffice.org-draw-3.0.0-0.0.12.1.fc10.ppc64 requires /bin/sh 1:broffice.org-impress-3.0.0-0.0.12.1.fc10.ppc64 requires /bin/sh 1:broffice.org-impress-3.0.0-0.0.12.1.fc10.ppc64 requires /bin/sh 1:broffice.org-math-3.0.0-0.0.12.1.fc10.ppc64 requires /bin/sh 1:broffice.org-math-3.0.0-0.0.12.1.fc10.ppc64 requires /bin/sh 1:broffice.org-writer-3.0.0-0.0.12.1.fc10.ppc64 requires /bin/sh 1:broffice.org-writer-3.0.0-0.0.12.1.fc10.ppc64 requires /bin/sh brutus-keyring-devel-0.9.0-6.fc8.ppc64 requires /sbin/ldconfig bsd-games-2.17-23.fc9.ppc64 requires /bin/sh bsd-games-2.17-23.fc9.ppc64 requires /usr/sbin/groupadd bsd-games-2.17-23.fc9.ppc64 requires /bin/sh bsf-2.3.0-12jpp.2.fc9.ppc64 requires /bin/sh bsh-1.3.0-12jpp.3.fc9.ppc64 requires /bin/sh bsh-demo-1.3.0-12jpp.3.fc9.ppc64 requires /usr/bin/env bsh-desktop-1.3.0-12jpp.3.fc9.ppc64 requires /bin/sh 1:bug-buddy-2.22.0-3.fc10.ppc64 requires /bin/sh bugzilla-3.0.4-1.fc10.noarch requires /bin/sh bugzilla-3.0.4-1.fc10.noarch requires /bin/sh bugzilla-3.0.4-1.fc10.noarch requires /usr/bin/perl bugzilla-contrib-3.0.4-1.fc10.noarch requires /usr/bin/env bugzilla-contrib-3.0.4-1.fc10.noarch requires /usr/bin/python bugzilla-contrib-3.0.4-1.fc10.noarch requires /usr/bin/perl bugzilla-contrib-3.0.4-1.fc10.noarch requires /bin/sh bugzilla-contrib-3.0.4-1.fc10.noarch requires /usr/bin/ruby bugzilla-doc-3.0.4-1.fc10.noarch requires /usr/bin/perl buildbot-0.7.7-2.fc9.noarch requires /usr/bin/env buildbot-0.7.7-2.fc9.noarch requires /usr/bin/python buoh-0.8.2-4.fc9.ppc64 requires /bin/sh bwbar-1.2.3-2.ppc64 requires /bin/sh bwbar-1.2.3-2.ppc64 requires /bin/bash bwbar-1.2.3-2.ppc64 requires /sbin/service byzanz-0.1.1-6.fc9.ppc64 requires /bin/sh bzip2-1.0.5-1.fc9.ppc64 requires /bin/sh bzip2-libs-1.0.5-1.fc9.ppc64 requires /sbin/ldconfig bzr-1.4-2.fc10.ppc64 requires /usr/bin/python bzr-gtk-0.94.0-1.fc10.ppc64 requires /usr/bin/python c-ares-1.5.1-2.fc9.ppc64 requires /sbin/ldconfig cachefilesd-0.7-4.fc9.ppc64 requires /bin/sh cachefilesd-0.7-4.fc9.ppc64 requires /bin/bash cachefilesd-0.7-4.fc9.ppc64 requires /sbin/chkconfig cachefilesd-0.7-4.fc9.ppc64 requires /sbin/service cacti-0.8.7b-1.fc9.noarch requires /bin/sh cacti-0.8.7b-1.fc9.noarch requires /usr/bin/perl cacti-0.8.7b-1.fc9.noarch requires /usr/sbin/useradd cacti-0.8.7b-1.fc9.noarch requires /usr/bin/php cacti-0.8.7b-1.fc9.noarch requires /bin/sh cacti-0.8.7b-1.fc9.noarch requires /sbin/service cairo-1.6.4-1.fc9.ppc64 requires /sbin/ldconfig cairo-clock-0.3.4-1.fc9.ppc64 requires /sbin/ldconfig cairo-dock-1.5.5.4-4.date20080506.fc10.ppc64 requires /bin/sh cairo-dock-plug-ins-1.5.5.4-4.date20080506.fc10.ppc64 requires /bin/bash cairo-dock-plug-ins-1.5.5.4-4.date20080506.fc10.ppc64 requires /bin/sh cairo-java-1.0.5-9.fc9.ppc64 requires /sbin/ldconfig cairomm-1.5.0-1.fc9.ppc64 requires /sbin/ldconfig cal3d-0.11.0-6.fc9.ppc64 requires /sbin/ldconfig calc-libs-2.12.2.1-12.fc9.ppc64 requires /sbin/ldconfig calc-stdrc-2.12.2.1-12.fc9.ppc64 requires /usr/bin/calc callweaver-1.2-0.4.rc5.20071230.fc9.ppc64 requires /bin/sh callweaver-1.2-0.4.rc5.20071230.fc9.ppc64 requires /sbin/chkconfig callweaver-1.2-0.4.rc5.20071230.fc9.ppc64 requires /bin/bash callweaver-1.2-0.4.rc5.20071230.fc9.ppc64 requires /bin/sh callweaver-misdn-1.2-0.4.rc5.20071230.fc9.ppc64 requires /bin/sh callweaver-ogi-1.2-0.4.rc5.20071230.fc9.ppc64 requires /usr/bin/perl callweaver-zaptel-1.2-0.4.rc5.20071230.fc9.ppc64 requires /bin/sh castor-0.9.5-2jpp.8.fc9.ppc64 requires /bin/sh castor-0.9.5-2jpp.8.fc9.ppc64 requires /bin/sh castor-demo-0.9.5-2jpp.8.fc9.ppc64 requires /bin/sh castor-test-0.9.5-2jpp.8.fc9.ppc64 requires /bin/sh castor-xml-0.9.5-2jpp.8.fc9.ppc64 requires /bin/sh catdoc-0.94.2-4.fc9.ppc64 requires /usr/bin/wish catfish-0.3-1.fc8.noarch requires /usr/bin/locate catfish-0.3-1.fc8.noarch requires /usr/bin/env catfish-0.3-1.fc8.noarch requires /usr/bin/find ccache-2.4-13.fc9.ppc64 requires /bin/sh ccache-2.4-13.fc9.ppc64 requires /bin/sh ccid-1.2.1-4.fc9.ppc64 requires /bin/sh ccrtp-1.6.0-1.fc9.ppc64 requires /sbin/ldconfig ccrtp-devel-1.6.0-1.fc9.ppc64 requires /bin/sh ccrtp-devel-1.6.0-1.fc9.ppc64 requires /sbin/install-info cdlabelgen-4.0.0-1.fc8.noarch requires /usr/bin/perl cdogs-data-0.4-3.fc8.noarch requires /bin/sh cdparanoia-libs-alpha9.8-30.ppc64 requires /bin/sh cegui-0.5.0b-7.fc9.ppc64 requires /sbin/ldconfig celestia-1.5.0-1.fc9.ppc64 requires /bin/sh cellwriter-1.3.3-1.fc10.ppc64 requires /bin/sh 1:centerim-4.22.4-1.fc9.ppc64 requires /usr/bin/perl cernlib-2006-29.fc9.ppc64 requires /sbin/ldconfig cernlib-g77-2006-29.fc9.ppc64 requires /sbin/ldconfig cernlib-g77-utils-2006-29.fc9.ppc64 requires /bin/bash cernlib-g77-utils-2006-29.fc9.ppc64 requires /bin/sh cernlib-packlib-2006-29.fc9.ppc64 requires /bin/sh cernlib-packlib-g77-2006-29.fc9.ppc64 requires /bin/sh cernlib-packlib-gfortran-2006-29.fc9.ppc64 requires /bin/sh cernlib-utils-2006-29.fc9.ppc64 requires /bin/bash cernlib-utils-2006-29.fc9.ppc64 requires /bin/sh certmaster-0.19-1.fc9.noarch requires /bin/sh certmaster-0.19-1.fc9.noarch requires /bin/sh certmaster-0.19-1.fc9.noarch requires /usr/bin/python cfengine-2.2.6-1.fc10.ppc64 requires /bin/sh cfengine-2.2.6-1.fc10.ppc64 requires /sbin/install-info cfengine-2.2.6-1.fc10.ppc64 requires /sbin/service cfengine-2.2.6-1.fc10.ppc64 requires /bin/bash cfengine-2.2.6-1.fc10.ppc64 requires /bin/sh cfengine-2.2.6-1.fc10.ppc64 requires /sbin/chkconfig cfitsio-3.060-3.fc9.ppc64 requires /sbin/ldconfig cfv-1.18.1-4.fc8.1.noarch requires /usr/bin/env cgdb-0.6.4-3.fc9.ppc64 requires /bin/sh cgdb-0.6.4-3.fc9.ppc64 requires /sbin/install-info cgoban-1.9.14-9.fc9.ppc64 requires /bin/sh charis-fonts-4.100-5.fc9.noarch requires /bin/sh check-0.9.5-2.fc9.1.ppc64 requires /bin/sh check-0.9.5-2.fc9.1.ppc64 requires /sbin/ldconfig check-0.9.5-2.fc9.1.ppc64 requires /sbin/install-info checkgmail-1.13-3.fc9.noarch requires /usr/bin/perl checkstyle-4.1-4jpp.3.fc9.noarch requires /bin/sh checkstyle-4.1-4jpp.3.fc9.noarch requires /usr/bin/perl checkstyle-optional-4.1-4jpp.3.fc9.noarch requires /bin/sh cheese-2.23.2-1.fc10.ppc64 requires /bin/sh cheese-2.23.2-1.fc10.ppc64 requires /bin/sh chemical-mime-data-0.1.94-3.fc8.noarch requires /bin/sh chemtool-1.6.11-3.fc9.ppc64 requires /bin/sh chess-1.0-14.fc10.ppc64 requires /bin/sh chess-1.0-14.fc10.ppc64 requires /usr/share/fonts/bitstream-vera/Vera.ttf childsplay-0.90.2-1.fc9.noarch requires /bin/sh childsplay-0.90.2-1.fc9.noarch requires /usr/bin/env childsplay-0.90.2-1.fc9.noarch requires /usr/bin/python chkrootkit-0.48-7.fc9.ppc64 requires /usr/bin/consolehelper chkrootkit-0.48-7.fc9.ppc64 requires /bin/sh chmlib-0.39-7.fc9.ppc64 requires /sbin/ldconfig chmsee-1.0.0-2.36.fc9.ppc64 requires /bin/sh cinepaint-0.22.1-7.fc9.ppc64 requires /bin/sh cinepaint-0.22.1-7.fc9.ppc64 requires /bin/sh cinepaint-devel-0.22.1-7.fc9.ppc64 requires /bin/sh cinepaint-libs-0.22.1-7.fc9.ppc64 requires /sbin/ldconfig cinepaint-libs-0.22.1-7.fc9.ppc64 requires /usr/bin/env cjkunifonts-ukai-0.1.20060928-4.fc8.noarch requires /bin/sh cjkunifonts-uming-0.1.20060928-4.fc8.noarch requires /bin/sh clamav-devel-0.93-1.fc9.ppc64 requires /usr/lib64/pkgconfig clamav-devel-0.93-1.fc9.ppc64 requires /bin/bash clamav-devel-0.93-1.fc9.ppc64 requires /bin/sh clamav-filesystem-0.93-1.fc9.ppc64 requires /bin/sh clamav-lib-0.93-1.fc9.ppc64 requires /sbin/ldconfig clamav-milter-core-0.93-1.fc9.ppc64 requires /bin/sh clamav-milter-sysv-0.93-1.fc9.ppc64 requires /bin/sh clamav-milter-sysv-0.93-1.fc9.ppc64 requires /etc/rc.d/init.d clamav-milter-sysv-0.93-1.fc9.ppc64 requires /bin/sh clamav-server-0.93-1.fc9.ppc64 requires /bin/bash clamav-server-sysv-0.93-1.fc9.ppc64 requires /etc/rc.d/init.d clamav-update-0.93-1.fc9.ppc64 requires /bin/sh clamav-update-0.93-1.fc9.ppc64 requires /etc/cron.d clamav-update-0.93-1.fc9.ppc64 requires /bin/bash clamav-update-0.93-1.fc9.ppc64 requires /bin/chown clamav-update-0.93-1.fc9.ppc64 requires /bin/chmod clanbomber-1.05-8.fc9.ppc64 requires /bin/sh classads-1.0-1.fc9.ppc64 requires /sbin/ldconfig classpathx-jaf-1.0-11jpp.1.fc9.ppc64 requires /bin/sh classpathx-jaf-1.0-11jpp.1.fc9.ppc64 requires /usr/sbin/update-alternatives classpathx-jaf-1.0-11jpp.1.fc9.ppc64 requires /bin/sh classpathx-jaf-javadoc-1.0-11jpp.1.fc9.ppc64 requires /bin/rm classpathx-jaf-javadoc-1.0-11jpp.1.fc9.ppc64 requires /bin/ln classpathx-mail-1.1.1-5jpp.3.ppc64 requires /bin/sh classpathx-mail-1.1.1-5jpp.3.ppc64 requires /usr/sbin/update-alternatives classpathx-mail-1.1.1-5jpp.3.ppc64 requires /bin/sh classpathx-mail-javadoc-1.1.1-5jpp.3.ppc64 requires /bin/sh classpathx-mail-javadoc-1.1.1-5jpp.3.ppc64 requires /bin/ln classpathx-mail-javadoc-1.1.1-5jpp.3.ppc64 requires /bin/rm cleanfeed-0.95.7b-21.1.1.noarch requires /usr/bin/perl climm-0.6.2-1.fc9.ppc64 requires /bin/sh clips-libs-6.24-25.fc9.ppc64 requires /sbin/ldconfig clipsmm-0.0.7-4.fc9.ppc64 requires /sbin/ldconfig cln-1.2.2-1.fc10.ppc64 requires /sbin/ldconfig cln-1.2.2-1.fc10.ppc64 requires /sbin/install-info cln-devel-1.2.2-1.fc10.ppc64 requires /bin/sh clonekeen-0.8.3-4.fc9.ppc64 requires /bin/sh clonekeen-0.8.3-4.fc9.ppc64 requires /bin/bash cloudy-libs-07.02.01-4.fc9.ppc64 requires /sbin/ldconfig clusterssh-3.22-1.fc9.noarch requires /bin/sh clusterssh-3.22-1.fc9.noarch requires /usr/bin/perl clutter-0.6.0-1.fc9.ppc64 requires /sbin/ldconfig clutter-gst-0.6.1-1.fc9.ppc64 requires /sbin/ldconfig clutter-gtk-0.6.0-1.fc9.ppc64 requires /sbin/ldconfig cmake-gui-2.6.0-1.fc10.ppc64 requires /bin/sh cman-2.0.60-6.fc10.ppc64 requires /bin/sh cman-2.0.60-6.fc10.ppc64 requires /usr/bin/python cman-2.0.60-6.fc10.ppc64 requires /bin/bash cman-2.0.60-6.fc10.ppc64 requires /usr/bin/perl cman-2.0.60-6.fc10.ppc64 requires /sbin/chkconfig cmigemo-1.3-0.6.c_MIT.fc9.2.ppc64 requires /sbin/ldconfig cobbler-0.8.2-1.fc9.noarch requires /bin/sh cobbler-0.8.2-1.fc9.noarch requires /sbin/chkconfig cobbler-0.8.2-1.fc9.noarch requires /sbin/service coco-coq-0.1-3.fc8.noarch requires /bin/sh coco-coq-0.1-3.fc8.noarch requires /bin/bash coda-backup-6.9.3-1.fc10.ppc64 requires /usr/bin/perl coda-backup-6.9.3-1.fc10.ppc64 requires /bin/sh coda-client-6.9.3-1.fc10.ppc64 requires /bin/sh coda-client-6.9.3-1.fc10.ppc64 requires /usr/bin/python coda-client-6.9.3-1.fc10.ppc64 requires /usr/bin/perl coda-client-6.9.3-1.fc10.ppc64 requires /bin/sh coda-server-6.9.3-1.fc10.ppc64 requires /bin/sh coda-server-6.9.3-1.fc10.ppc64 requires /bin/sh codeblocks-8.02-1.fc9.ppc64 requires /bin/sh codeblocks-contrib-libs-8.02-1.fc9.ppc64 requires /sbin/ldconfig codeblocks-libs-8.02-1.fc9.ppc64 requires /sbin/ldconfig codeina-0.10.1-8.fc9.noarch requires /usr/bin/env codeina-0.10.1-8.fc9.noarch requires /bin/sh cogito-0.18.2-2.fc7.noarch requires /bin/bash cogito-0.18.2-2.fc7.noarch requires /usr/bin/env cohoba-0.0.4-5.fc7.noarch requires /bin/sh cohoba-0.0.4-5.fc7.noarch requires /usr/bin/env coldet-1.2-4.fc9.ppc64 requires /sbin/ldconfig collectd-4.3.2-9.fc10.ppc64 requires /bin/sh collectd-4.3.2-9.fc10.ppc64 requires /bin/bash colordiff-1.0.7-2.fc9.noarch requires /usr/bin/perl colordiff-1.0.7-2.fc9.noarch requires /bin/sh comedilib-0.8.1-1.fc10.ppc64 requires /sbin/ldconfig comedilib-0.8.1-1.fc10.ppc64 requires /bin/sh comix-3.6.4-6.fc9.noarch requires /bin/sh comix-3.6.4-6.fc9.noarch requires /usr/bin/env comix-3.6.4-6.fc9.noarch requires /usr/bin/jpegtran commoncpp2-1.6.1-1.fc9.ppc64 requires /sbin/ldconfig commoncpp2-devel-1.6.1-1.fc9.ppc64 requires /bin/sh commoncpp2-devel-1.6.1-1.fc9.ppc64 requires /sbin/install-info commoncpp2-devel-1.6.1-1.fc9.ppc64 requires /bin/sh compat-db-4.5.20-5.fc9.ppc64 requires /sbin/ldconfig compat-erlang-R10B-11.9.fc9.ppc64 requires /bin/sh compat-erlang-R10B-11.9.fc9.ppc64 requires /bin/sh compat-expat1-1.95.8-4.ppc64 requires /sbin/ldconfig compat-flex-2.5.4a-4.fc9.ppc64 requires /bin/sh compat-flex-2.5.4a-4.fc9.ppc64 requires /sbin/install-info compat-gcc-34-g77-3.4.6-9.ppc64 requires /bin/sh compat-gcc-34-g77-3.4.6-9.ppc64 requires /sbin/install-info compat-guichan05-0.5.0-8.fc9.ppc64 requires /sbin/ldconfig compat-guile-16-1.6.7-8.fc9.ppc64 requires /sbin/ldconfig compat-guile-16-1.6.7-8.fc9.ppc64 requires /bin/sh compat-guile-16-devel-1.6.7-8.fc9.ppc64 requires /usr/bin/guile-1.6 compat-guile-16-devel-1.6.7-8.fc9.ppc64 requires /bin/sh compat-libf2c-34-3.4.6-9.ppc64 requires /sbin/ldconfig compat-libgfortran-41-4.1.2-36.ppc64 requires /sbin/ldconfig compat-libosip2-2.2.2-16.fc9.ppc64 requires /sbin/ldconfig compat-libstdc++-33-3.2.3-63.ppc64 requires /sbin/ldconfig compat-wxGTK26-2.6.4-2.ppc64 requires /sbin/ldconfig compat-wxGTK26-devel-2.6.4-2.ppc64 requires /bin/sh compface-1.5.2-7.ppc64 requires /sbin/ldconfig concurrent-1.3.4-8jpp.1.fc9.ppc64 requires /bin/sh condor-7.0.0-8.fc9.ppc64 requires /bin/sh condor-7.0.0-8.fc9.ppc64 requires /usr/bin/env condor-7.0.0-8.fc9.ppc64 requires /sbin/service condor-7.0.0-8.fc9.ppc64 requires /bin/bash condor-7.0.0-8.fc9.ppc64 requires /bin/sh condor-7.0.0-8.fc9.ppc64 requires /usr/bin/perl condor-7.0.0-8.fc9.ppc64 requires /sbin/chkconfig conduit-0.3.8-1.fc9.noarch requires /bin/sh conduit-0.3.8-1.fc9.noarch requires /bin/bash conduit-0.3.8-1.fc9.noarch requires /usr/bin/env conduit-0.3.8-1.fc9.noarch requires /usr/bin/python cone-0.74-3.fc9.ppc64 requires /bin/sh cone-0.74-3.fc9.ppc64 requires /usr/bin/perl cone-0.74-3.fc9.ppc64 requires /bin/sh cone-0.74-3.fc9.ppc64 requires /usr/bin/perl conexus-0.5.3-4.fc9.ppc64 requires /sbin/ldconfig conexusmm-0.5.0-3.fc7.ppc64 requires /sbin/ldconfig conglomerate-0.9.1-5.fc9.ppc64 requires /bin/sh conman-0.2.1-1.fc10.ppc64 requires /bin/sh conman-0.2.1-1.fc10.ppc64 requires /sbin/chkconfig conman-0.2.1-1.fc10.ppc64 requires /usr/bin/env conman-0.2.1-1.fc10.ppc64 requires /bin/sh conman-0.2.1-1.fc10.ppc64 requires /sbin/service conman-0.2.1-1.fc10.ppc64 requires /usr/bin/expect conmux-0.0-7.493svn.fc10.noarch requires /bin/sh conmux-0.0-7.493svn.fc10.noarch requires /sbin/service conmux-0.0-7.493svn.fc10.noarch requires /usr/bin/expect conmux-0.0-7.493svn.fc10.noarch requires /usr/bin/perl conmux-0.0-7.493svn.fc10.noarch requires /bin/sh conmux-0.0-7.493svn.fc10.noarch requires /sbin/chkconfig conmux-client-0.0-7.493svn.fc10.noarch requires /usr/bin/perl conserver-8.1.16-5.fc9.ppc64 requires /sbin/chkconfig conserver-8.1.16-5.fc9.ppc64 requires /bin/sh conserver-8.1.16-5.fc9.ppc64 requires /bin/sh conserver-8.1.16-5.fc9.ppc64 requires /sbin/service conserver-client-8.1.16-5.fc9.ppc64 requires /bin/sh contacts-0.8-3.fc10.ppc64 requires /bin/sh 1:control-center-2.23.1-3.fc10.ppc64 requires /bin/sh 1:control-center-2.23.1-3.fc10.ppc64 requires /bin/sh convmv-1.12-1.fc9.noarch requires /usr/bin/perl cook-2.30-2.fc9.ppc64 requires /usr/bin/perl coolkey-1.1.0-6.fc9.ppc64 requires /bin/sh coreutils-6.11-2.fc10.ppc64 requires /bin/sh coreutils-6.11-2.fc10.ppc64 requires /sbin/install-info cowsay-3.03-4.fc8.noarch requires /usr/bin/perl cowsay-3.03-4.fc8.noarch requires /bin/sh cpan2rpm-2.028-2.fc8.1.noarch requires /usr/bin/perl cpanspec-1.75-1.fc10.noarch requires /usr/bin/repoquery cpanspec-1.75-1.fc10.noarch requires /usr/bin/perl cpanspec-1.75-1.fc10.noarch requires /bin/sh cpanspec-1.75-1.fc10.noarch requires /usr/bin/curl cpio-2.9-7.fc9.ppc64 requires /bin/sh cpio-2.9-7.fc9.ppc64 requires /sbin/install-info cpl-4.1.0-1.fc9.ppc64 requires /sbin/ldconfig cpp-4.3.0-8.ppc64 requires /bin/sh cpp-4.3.0-8.ppc64 requires /sbin/install-info cppunit-1.12.0-5.fc9.ppc64 requires /sbin/ldconfig cppunit-devel-1.12.0-5.fc9.ppc64 requires /bin/sh 1:cpufreq-utils-002-1.1.42.fc9.ppc64 requires /sbin/ldconfig 1:cpuspeed-1.2.1-5.fc9.ppc64 requires /bin/sh 1:cpuspeed-1.2.1-5.fc9.ppc64 requires /sbin/chkconfig 1:cpuspeed-1.2.1-5.fc9.ppc64 requires /bin/sh 1:cpuspeed-1.2.1-5.fc9.ppc64 requires /sbin/service crack-5.0a-8.fc9.ppc64 requires /bin/sh crack-5.0a-8.fc9.ppc64 requires /bin/bash crack-5.0a-8.fc9.ppc64 requires /bin/sh crack-attack-1.1.14-13.fc9.ppc64 requires /bin/sh cracklib-2.8.12-2.ppc64 requires /sbin/ldconfig cracklib-2.8.12-2.ppc64 requires /sbin/ldconfig cracklib-2.8.12-2.ppc64 requires /bin/sh createrepo-0.9.5-2.fc9.noarch requires /usr/bin/python createrepo-0.9.5-2.fc9.noarch requires /bin/sh createrepo-0.9.5-2.fc9.noarch requires /usr/bin/env crm114-0-1.7.20070810.fc9.ppc64 requires /usr/bin/crm cronie-1.0-5.fc9.ppc64 requires /bin/sh cronie-1.0-5.fc9.ppc64 requires /sbin/service cronie-1.0-5.fc9.ppc64 requires /bin/bash cronie-1.0-5.fc9.ppc64 requires /bin/sh cronie-1.0-5.fc9.ppc64 requires /sbin/chkconfig cronolog-1.6.2-7.fc9.ppc64 requires /bin/sh cronolog-1.6.2-7.fc9.ppc64 requires /usr/bin/perl cronolog-1.6.2-7.fc9.ppc64 requires /sbin/install-info crontabs-1.10-21.fc10.noarch requires /bin/bash crossfire-1.10.0-4.fc9.ppc64 requires /bin/sh crossfire-1.10.0-4.fc9.ppc64 requires /sbin/service crossfire-1.10.0-4.fc9.ppc64 requires /bin/bash crossfire-1.10.0-4.fc9.ppc64 requires /bin/sh crossfire-1.10.0-4.fc9.ppc64 requires /usr/bin/perl crossfire-1.10.0-4.fc9.ppc64 requires /sbin/chkconfig crossfire-client-1.10.0-4.fc9.ppc64 requires /bin/sh crossfire-maps-1.10.0-3.fc8.noarch requires /bin/bash crossfire-maps-1.10.0-3.fc8.noarch requires /usr/bin/perl crossfire-selinux-1.10.0-4.fc9.ppc64 requires /usr/sbin/semodule crossfire-selinux-1.10.0-4.fc9.ppc64 requires /sbin/fixfiles crossfire-selinux-1.10.0-4.fc9.ppc64 requires /bin/sh crossfire-selinux-1.10.0-4.fc9.ppc64 requires /usr/sbin/semanage crossfire-selinux-1.10.0-4.fc9.ppc64 requires /sbin/service crossvc-1.5.2-4.fc9.ppc64 requires /bin/sh cryptix-3.2.0-10jpp.2.ppc64 requires /bin/sh cryptix-asn1-20011119-8jpp.3.ppc64 requires /bin/sh cryptix-javadoc-3.2.0-10jpp.2.ppc64 requires /bin/sh cryptix-javadoc-3.2.0-10jpp.2.ppc64 requires /bin/rm cryptix-javadoc-3.2.0-10jpp.2.ppc64 requires /bin/ln crypto-utils-2.3-10.ppc64 requires /bin/bash cryptsetup-luks-1.0.6-2.fc9.ppc64 requires /sbin/ldconfig crystal-1.0.5-3.fc9.ppc64 requires /sbin/ldconfig crystal-stacker-1.5-6.fc9.ppc64 requires /bin/sh crystal-stacker-theme-editor-1.5-6.fc9.ppc64 requires /bin/sh crystalsvg-icon-theme-4.0.72-1.fc10.ppc64 requires /bin/sh cscope-15.6-1.fc9.ppc64 requires /bin/sh csmash-0.6.6-18.ppc64 requires /bin/sh csound-5.03.0-16.fc9.ppc64 requires /sbin/ldconfig csound-java-5.03.0-16.fc9.ppc64 requires /bin/sh csound-java-5.03.0-16.fc9.ppc64 requires /sbin/ldconfig csound-tk-5.03.0-16.fc9.ppc64 requires /usr/bin/perl csound-tk-5.03.0-16.fc9.ppc64 requires /usr/bin/wish ctapi-common-1.1-4.fc9.ppc64 requires /bin/sh ctapi-cyberjack-3.0.5-2.fc9.ppc64 requires /sbin/ldconfig ctapi-cyberjack-3.0.5-2.fc9.ppc64 requires /usr/lib64/ctapi ctapi-cyberjack-pcsc-3.0.5-2.fc9.ppc64 requires /bin/sh ctapi-cyberjack-tools-3.0.5-2.fc9.ppc64 requires /bin/sh cuetools-1.4.0-0.2.svn305.fc10.ppc64 requires /sbin/ldconfig cuetools-1.4.0-0.2.svn305.fc10.ppc64 requires /bin/sh culmus-fonts-0.101-4.fc8.noarch requires /bin/sh 1:cups-1.3.7-2.fc10.ppc64 requires /bin/sh 1:cups-1.3.7-2.fc10.ppc64 requires /usr/sbin/alternatives 1:cups-1.3.7-2.fc10.ppc64 requires /sbin/service 1:cups-1.3.7-2.fc10.ppc64 requires /bin/bash 1:cups-1.3.7-2.fc10.ppc64 requires /bin/sh 1:cups-1.3.7-2.fc10.ppc64 requires /usr/bin/perl 1:cups-1.3.7-2.fc10.ppc64 requires /sbin/chkconfig 1:cups-devel-1.3.7-2.fc10.ppc64 requires /bin/sh 1:cups-libs-1.3.7-2.fc10.ppc64 requires /sbin/ldconfig cups-pdf-2.4.7-1.fc9.ppc64 requires /bin/sh cvs-1.11.22-13.fc9.ppc64 requires /bin/sh cvs-1.11.22-13.fc9.ppc64 requires /sbin/install-info cvs-1.11.22-13.fc9.ppc64 requires /usr/bin/perl cvs-1.11.22-13.fc9.ppc64 requires /bin/sh cvs2cl-2.67-1.fc8.noarch requires /usr/bin/perl cvs2svn-2.1.1-1.fc10.noarch requires /usr/bin/python cvsplot-1.7.4-6.fc8.noarch requires /usr/bin/perl cvsutils-0.2.3-6.fc8.noarch requires /usr/bin/perl cvsutils-0.2.3-6.fc8.noarch requires /bin/sh cvsweb-3.0.6-3.fc6.noarch requires /usr/bin/perl cwiid-0.6.00-7.fc10.ppc64 requires /sbin/ldconfig cwrite-0.1.24-2.fc9.ppc64 requires /bin/sh cwrite-0.1.24-2.fc9.ppc64 requires /sbin/install-info cycle-0.3.1-4.fc7.noarch requires /usr/bin/env cyphesis-0.5.15-6.fc9.ppc64 requires /bin/sh cyphesis-0.5.15-6.fc9.ppc64 requires /sbin/service cyphesis-0.5.15-6.fc9.ppc64 requires /bin/sh cyphesis-0.5.15-6.fc9.ppc64 requires /sbin/chkconfig cyphesis-selinux-0.5.15-6.fc9.ppc64 requires /usr/sbin/semodule cyphesis-selinux-0.5.15-6.fc9.ppc64 requires /sbin/fixfiles cyphesis-selinux-0.5.15-6.fc9.ppc64 requires /bin/sh cyphesis-selinux-0.5.15-6.fc9.ppc64 requires /usr/sbin/semanage cyphesis-selinux-0.5.15-6.fc9.ppc64 requires /usr/sbin/setsebool cyphesis-selinux-0.5.15-6.fc9.ppc64 requires /sbin/service cyrus-imapd-2.3.11-1.fc9.ppc64 requires /bin/sh cyrus-imapd-2.3.11-1.fc9.ppc64 requires /sbin/service cyrus-imapd-2.3.11-1.fc9.ppc64 requires /usr/bin/perl cyrus-imapd-2.3.11-1.fc9.ppc64 requires /bin/sh cyrus-imapd-2.3.11-1.fc9.ppc64 requires /sbin/chkconfig cyrus-imapd-perl-2.3.11-1.fc9.ppc64 requires /usr/bin/perl cyrus-imapd-utils-2.3.11-1.fc9.ppc64 requires /usr/sbin/userdel cyrus-imapd-utils-2.3.11-1.fc9.ppc64 requires /bin/sh cyrus-imapd-utils-2.3.11-1.fc9.ppc64 requires /usr/sbin/groupadd cyrus-imapd-utils-2.3.11-1.fc9.ppc64 requires /bin/sh cyrus-imapd-utils-2.3.11-1.fc9.ppc64 requires /usr/sbin/groupdel cyrus-imapd-utils-2.3.11-1.fc9.ppc64 requires /usr/sbin/useradd cyrus-sasl-2.1.22-13.fc9.ppc64 requires /bin/sh cyrus-sasl-2.1.22-13.fc9.ppc64 requires /sbin/service cyrus-sasl-2.1.22-13.fc9.ppc64 requires /bin/bash cyrus-sasl-lib-2.1.22-13.fc9.ppc64 requires /sbin/ldconfig d-feet-0.1.8-1.fc9.noarch requires /bin/sh d-feet-0.1.8-1.fc9.noarch requires /usr/bin/python d4x-2.5.7.1-8.fc9.ppc64 requires /bin/sh dap-freeform_handler-3.7.7-2.fc9.ppc64 requires /sbin/ldconfig dap-freeform_handler-3.7.7-2.fc9.ppc64 requires /bin/sh dap-hdf4_handler-3.7.7-3.fc9.ppc64 requires /bin/sh dap-netcdf_handler-3.7.8-3.fc9.ppc64 requires /sbin/ldconfig dap-netcdf_handler-3.7.8-3.fc9.ppc64 requires /bin/sh dap-server-3.8.4-3.fc9.ppc64 requires /bin/sh dap-server-cgi-3.8.4-3.fc9.ppc64 requires /usr/bin/perl dasher-4.9.0-1.fc10.ppc64 requires /bin/sh dates-0.4.6-1.fc10.ppc64 requires /bin/sh dates-0.4.6-1.fc10.ppc64 requires /sbin/ldconfig dayplanner-0.8.1-3.fc9.noarch requires /bin/sh dayplanner-0.8.1-3.fc9.noarch requires /usr/bin/perl db4-4.6.21-5.fc9.ppc64 requires /sbin/ldconfig db4-tcl-4.6.21-5.fc9.ppc64 requires /sbin/ldconfig 1:dbh-1.0.24-6.fc9.ppc64 requires /sbin/ldconfig dblatex-0.2.8-2.fc9.1.noarch requires /usr/bin/texhash dblatex-0.2.8-2.fc9.1.noarch requires /usr/bin/env dbmail-2.2.9-1.fc10.ppc64 requires /bin/sh dbmail-2.2.9-1.fc10.ppc64 requires /bin/bash dbmail-2.2.9-1.fc10.ppc64 requires /bin/sh dbus-1.2.1-3.fc10.ppc64 requires /bin/sh dbus-1.2.1-3.fc10.ppc64 requires /usr/sbin/useradd dbus-1.2.1-3.fc10.ppc64 requires /bin/sh dbus-glib-0.74-6.fc9.ppc64 requires /sbin/ldconfig dbus-libs-1.2.1-3.fc10.ppc64 requires /sbin/ldconfig dbus-qt-0.70-4.fc9.ppc64 requires /sbin/ldconfig dbus-qt3-0.8-5.fc9.ppc64 requires /sbin/ldconfig dbus-x11-1.2.1-3.fc10.ppc64 requires /bin/sh dbxml-2.3.10-12.fc9.ppc64 requires /sbin/ldconfig dclib-0.3.11-4.fc9.ppc64 requires /sbin/ldconfig dd2-0.2.2-3.fc9.ppc64 requires /bin/sh dd_rescue-1.14-7.fc9.ppc64 requires /bin/bash ddclient-3.7.3-1.fc9.noarch requires /bin/sh ddclient-3.7.3-1.fc9.noarch requires /usr/bin/perl ddclient-3.7.3-1.fc9.noarch requires /sbin/chkconfig ddclient-3.7.3-1.fc9.noarch requires /usr/sbin/groupadd ddclient-3.7.3-1.fc9.noarch requires /usr/sbin/useradd ddclient-3.7.3-1.fc9.noarch requires /bin/sh ddd-3.3.11-18.fc9.ppc64 requires /bin/sh ddd-3.3.11-18.fc9.ppc64 requires /sbin/install-info ddrescue-1.8-2.fc9.ppc64 requires /bin/sh ddrescue-1.8-2.fc9.ppc64 requires /sbin/install-info ddskk-12.2.0-11.fc7.noarch requires /bin/sh ddskk-12.2.0-11.fc7.noarch requires /sbin/install-info debootstrap-1.0.8-1.fc9.noarch requires /bin/sh 1:dejagnu-1.4.4-11.fc9.noarch requires /bin/sh 1:dejagnu-1.4.4-11.fc9.noarch requires /bin/sh dejavu-fonts-2.24-3.fc9.noarch requires /bin/sh dejavu-fonts-experimental-2.24-3.fc9.noarch requires /bin/sh dejavu-lgc-fonts-2.24-3.fc9.noarch requires /bin/sh deltarpm-3.4-10.fc9.ppc64 requires /usr/bin/perl deluge-0.5.9.0-1.fc10.ppc64 requires /bin/sh deluge-0.5.9.0-1.fc10.ppc64 requires /usr/bin/env deluge-0.5.9.0-1.fc10.ppc64 requires /usr/bin/python deluge-0.5.9.0-1.fc10.ppc64 requires /bin/bash deluge-0.5.9.0-1.fc10.ppc64 requires /bin/sh denyhosts-2.6-8.fc9.noarch requires /bin/sh denyhosts-2.6-8.fc9.noarch requires /bin/bash denyhosts-2.6-8.fc9.noarch requires /usr/bin/env denyhosts-2.6-8.fc9.noarch requires /bin/env denyhosts-2.6-8.fc9.noarch requires /bin/sh denyhosts-2.6-8.fc9.noarch requires /usr/bin/python deskbar-applet-2.23.2-1.fc10.ppc64 requires /bin/sh deskbar-applet-2.23.2-1.fc10.ppc64 requires /usr/bin/env desktop-data-model-1.2.4-1.fc10.ppc64 requires /bin/sh desktop-data-model-1.2.4-1.fc10.ppc64 requires /sbin/ldconfig desktop-file-utils-0.15-3.fc10.ppc64 requires /bin/sh devhelp-0.19-4.fc9.ppc64 requires /bin/sh device-mapper-libs-1.02.24-11.fc9.ppc64 requires /sbin/ldconfig device-mapper-multipath-0.4.7-15.fc10.ppc64 requires /bin/sh device-mapper-multipath-0.4.7-15.fc10.ppc64 requires /bin/bash dgae-1.1-3.fc8.noarch requires /bin/sh dgae-1.1-3.fc8.noarch requires /bin/bash 12:dhclient-4.0.0-15.fc10.ppc64 requires /bin/bash 12:dhcp-4.0.0-15.fc10.ppc64 requires /bin/sh 12:dhcp-4.0.0-15.fc10.ppc64 requires /bin/sh dhcp-forwarder-0.7-14.fc9.ppc64 requires /bin/sh dhcp-forwarder-sysv-0.7-14.fc9.ppc64 requires /bin/sh dhcp-forwarder-sysv-0.7-14.fc9.ppc64 requires /bin/bash dhcp-forwarder-sysv-0.7-14.fc9.ppc64 requires /sbin/chkconfig dhcpv6-1.0.15-1.fc10.ppc64 requires /bin/sh dhcpv6-1.0.15-1.fc10.ppc64 requires /bin/sh 1:dia-0.96.1-6.fc10.ppc64 requires /bin/sh 1:dia-0.96.1-6.fc10.ppc64 requires /usr/bin/env dialog-1.1-5.20080316.fc10.ppc64 requires /sbin/ldconfig dialog-devel-1.1-5.20080316.fc10.ppc64 requires /bin/sh dictd-1.10.11-2.ppc64 requires /bin/sh dictd-1.10.11-2.ppc64 requires /bin/sh diffutils-2.8.1-21.fc9.ppc64 requires /bin/sh diffutils-2.8.1-21.fc9.ppc64 requires /sbin/install-info digikam-0.9.4-0.1.beta4.fc10.ppc64 requires /bin/sh digikam-0.9.4-0.1.beta4.fc10.ppc64 requires /usr/bin/perl digikam-0.9.4-0.1.beta4.fc10.ppc64 requires /bin/sh dillo-0.8.6-7.fc9.ppc64 requires /usr/bin/perl dirac-0.9.1-2.fc9.ppc64 requires /usr/bin/perl dirac-libs-0.9.1-2.fc9.ppc64 requires /sbin/ldconfig dircproxy-1.2.0-0.7.beta2.fc9.ppc64 requires /bin/sh dircproxy-1.2.0-0.7.beta2.fc9.ppc64 requires /usr/bin/perl dircproxy-1.2.0-0.7.beta2.fc9.ppc64 requires /bin/sh directfb-1.0.0-4.fc9.ppc64 requires /sbin/ldconfig directfb-devel-1.0.0-4.fc9.ppc64 requires /bin/sh dirmngr-1.0.1-2.fc9.ppc64 requires /bin/sh dirmngr-1.0.1-2.fc9.ppc64 requires /sbin/install-info dirvish-1.2.1-2.fc6.noarch requires /usr/bin/perl distcache-1.4.5-17.ppc64 requires /bin/sh distcache-1.4.5-17.ppc64 requires /sbin/ldconfig distcache-1.4.5-17.ppc64 requires /bin/bash distcache-1.4.5-17.ppc64 requires /sbin/chkconfig distcache-1.4.5-17.ppc64 requires /sbin/service distcc-2.18.3-4.fc9.ppc64 requires /bin/sh distcc-server-2.18.3-4.fc9.ppc64 requires /sbin/chkconfig distcc-server-2.18.3-4.fc9.ppc64 requires /bin/sh distcc-server-2.18.3-4.fc9.ppc64 requires /bin/sh djvulibre-3.5.20-2.fc9.ppc64 requires /bin/sh djvulibre-3.5.20-2.fc9.ppc64 requires /sbin/ldconfig djvulibre-3.5.20-2.fc9.ppc64 requires /bin/bash djvulibre-3.5.20-2.fc9.ppc64 requires /bin/sh djvulibre-libs-3.5.20-2.fc9.ppc64 requires /sbin/ldconfig dkim-milter-2.5.1-5.fc9.ppc64 requires /bin/sh dkim-milter-2.5.1-5.fc9.ppc64 requires /sbin/service dkim-milter-2.5.1-5.fc9.ppc64 requires /bin/sh dkim-milter-2.5.1-5.fc9.ppc64 requires /bin/bash dkim-milter-2.5.1-5.fc9.ppc64 requires /sbin/chkconfig dkms-2.0.19-1.fc9.noarch requires /bin/sh dkms-2.0.19-1.fc9.noarch requires /bin/bash dkms-2.0.19-1.fc9.noarch requires /bin/sh dmraid-1.0.0.rc14-6.fc9.ppc64 requires /sbin/ldconfig dnsmasq-2.41-0.8.fc9.ppc64 requires /bin/sh dnsmasq-2.41-0.8.fc9.ppc64 requires /bin/sed dnsmasq-2.41-0.8.fc9.ppc64 requires /sbin/chkconfig dnsmasq-2.41-0.8.fc9.ppc64 requires /bin/grep dnsmasq-2.41-0.8.fc9.ppc64 requires /bin/sh dnsmasq-2.41-0.8.fc9.ppc64 requires /sbin/service dnssec-tools-1.3.2-2.fc9.ppc64 requires /usr/bin/perl dnssec-tools-libs-1.3.2-2.fc9.ppc64 requires /sbin/ldconfig dnssec-tools-libs-devel-1.3.2-2.fc9.ppc64 requires /bin/sh docbook-dtds-1.0-36.fc10.noarch requires /bin/sh docbook-simple-1.1-3.fc9.noarch requires /bin/sh docbook-slides-3.4.0-3.fc9.noarch requires /bin/sh docbook-style-dsssl-1.79-5.fc9.noarch requires /bin/sh docbook-style-dsssl-1.79-5.fc9.noarch requires /usr/bin/perl docbook-style-xsl-1.73.2-9.fc9.noarch requires /bin/sh docbook-utils-0.6.14-13.fc9.noarch requires /usr/bin/perl docbook-utils-0.6.14-13.fc9.noarch requires /bin/sh docbook-utils-pdf-0.6.14-13.fc9.noarch requires /bin/sh docbook2X-0.8.8-3.fc9.ppc64 requires /bin/sh docbook2X-0.8.8-3.fc9.ppc64 requires /sbin/install-info docbook2X-0.8.8-3.fc9.ppc64 requires /usr/bin/sgml2xml docbook2X-0.8.8-3.fc9.ppc64 requires /usr/bin/perl docbook2X-0.8.8-3.fc9.ppc64 requires /bin/sh dogtail-0.6.90-1.381.fc9.noarch requires /bin/sh dogtail-0.6.90-1.381.fc9.noarch requires /usr/bin/python dom4j-demo-1.6.1-2jpp.3.fc8.noarch requires /bin/sh doodle-0.6.7-2.fc9.ppc64 requires /sbin/ldconfig dot2tex-2.7.0-4.fc9.noarch requires /usr/bin/python dotconf-1.0.13-6.fc9.ppc64 requires /sbin/ldconfig dotconf-devel-1.0.13-6.fc9.ppc64 requires /bin/sh doulos-fonts-4.100-1.fc9.noarch requires /bin/sh 1:dovecot-1.0.13-6.fc9.ppc64 requires /usr/sbin/userdel 1:dovecot-1.0.13-6.fc9.ppc64 requires /bin/mv 1:dovecot-1.0.13-6.fc9.ppc64 requires /usr/sbin/useradd 1:dovecot-1.0.13-6.fc9.ppc64 requires /bin/sh 1:dovecot-1.0.13-6.fc9.ppc64 requires /sbin/service 1:dovecot-1.0.13-6.fc9.ppc64 requires /bin/touch 1:dovecot-1.0.13-6.fc9.ppc64 requires /bin/bash 1:dovecot-1.0.13-6.fc9.ppc64 requires /bin/sh 1:dovecot-1.0.13-6.fc9.ppc64 requires /usr/sbin/groupdel 1:dovecot-1.0.13-6.fc9.ppc64 requires /sbin/chkconfig 1:dovecot-1.0.13-6.fc9.ppc64 requires /bin/rm drawtiming-0.6.2-3.fc9.ppc64 requires libWand.so.10()(64bit) drawtiming-0.6.2-3.fc9.ppc64 requires libMagick++.so.10()(64bit) drawtiming-0.6.2-3.fc9.ppc64 requires libMagick.so.10()(64bit) drgeo-1.1.0-12.fc9.ppc64 requires /bin/bash driconf-0.9.1-7.fc9.noarch requires /usr/bin/python driftnet-0.1.6-16.20040426cvs.fc9.ppc64 requires /usr/bin/consolehelper drivel-2.1.1-0.5.20071130svn.fc9.ppc64 requires /bin/sh dropbear-0.50-3.fc9.ppc64 requires /bin/sh dropbear-0.50-3.fc9.ppc64 requires /bin/bash dropbear-0.50-3.fc9.ppc64 requires /sbin/service 1:drpython-3.11.0-2.fc9.noarch requires /bin/bash 1:drpython-3.11.0-2.fc9.noarch requires /usr/bin/env 1:drpython-3.11.0-2.fc9.noarch requires /bin/sh 1:drpython-3.11.0-2.fc9.noarch requires /usr/bin/python ds9-5.1-4.fc9.ppc64 requires /bin/sh dstat-0.6.7-3.fc10.noarch requires /usr/bin/env dtdparser-1.21-4jpp.2.fc9.ppc64 requires /bin/sh duel3-0.1-0.5.20060225.fc9.ppc64 requires /bin/sh dumb-0.9.3-7.fc9.ppc64 requires /sbin/ldconfig duplicity-0.4.11-1.fc10.ppc64 requires /usr/bin/python dvdauthor-0.6.14-5.fc9.ppc64 requires /bin/sh dvipdfm-0.13.2d-38.fc10.ppc64 requires /bin/sh dvipdfm-0.13.2d-38.fc10.ppc64 requires /bin/sh dvipdfm-0.13.2d-38.fc10.ppc64 requires /usr/bin/mktexlsr dvipdfmx-0-0.20.20071115cvs.fc9.ppc64 requires /bin/sh dvipdfmx-0-0.20.20071115cvs.fc9.ppc64 requires /usr/bin/mktexlsr dvipng-1.9-50.fc9.ppc64 requires /bin/sh dvipng-1.9-50.fc9.ppc64 requires /sbin/install-info dwarves-1.6-1.ppc64 requires /usr/bin/python dx-4.4.4-6.fc9.ppc64 requires libMagick.so.10()(64bit) dx-4.4.4-6.fc9.ppc64 requires /bin/sh dx-4.4.4-6.fc9.ppc64 requires libWand.so.10()(64bit) dx-libs-4.4.4-6.fc9.ppc64 requires libMagick.so.10()(64bit) dx-libs-4.4.4-6.fc9.ppc64 requires libWand.so.10()(64bit) dx-libs-4.4.4-6.fc9.ppc64 requires /sbin/ldconfig dxcc-20080225-4.fc9.noarch requires /usr/bin/perl dxcc-gui-20080225-4.fc9.noarch requires /bin/bash dxpc-3.9.1-0.3.b1.fc9.ppc64 requires /bin/bash dynamite-0.1-9.fc9.ppc64 requires /sbin/ldconfig e16-0.16.8.13-2.fc10.ppc64 requires /usr/bin/perl e16-0.16.8.13-2.fc10.ppc64 requires /bin/sh e16-epplets-0.10-3.fc10.ppc64 requires /sbin/ldconfig e16-themes-0.16.8.0.2-1.fc10.noarch requires /bin/sh e2fsprogs-1.40.9-2.fc10.ppc64 requires /bin/sh e2fsprogs-devel-1.40.9-2.fc10.ppc64 requires /bin/sh e2fsprogs-devel-1.40.9-2.fc10.ppc64 requires /sbin/install-info e2fsprogs-devel-1.40.9-2.fc10.ppc64 requires /bin/sh e2fsprogs-libs-1.40.9-2.fc10.ppc64 requires /sbin/ldconfig eb-4.3.2-1.fc9.ppc64 requires /sbin/ldconfig eb-4.3.2-1.fc9.ppc64 requires /usr/bin/perl eblook-1.6.1-3.fc9.ppc64 requires /bin/sh ebtables-2.0.8-5.fc9.ppc64 requires /bin/sh ebtables-2.0.8-5.fc9.ppc64 requires /sbin/service ebtables-2.0.8-5.fc9.ppc64 requires /usr/bin/perl ebtables-2.0.8-5.fc9.ppc64 requires /bin/bash ebtables-2.0.8-5.fc9.ppc64 requires /sbin/chkconfig echo-icon-theme-0.3.89.0-0.1.git51c57605.fc10.noarch requires /bin/sh ecl-0.9j-2.fc9.ppc64 requires /bin/sh ecl-0.9j-2.fc9.ppc64 requires /bin/sh eclipse-checkstyle-4.0.1-10.fc9.ppc64 requires /bin/sh 1:eclipse-ecj-3.3.2-11.fc9.ppc64 requires /usr/bin/rebuild-gcj-db 1:eclipse-ecj-3.3.2-11.fc9.ppc64 requires /bin/sh eclipse-egit-0.3.1-0.fc9.ppc64 requires /usr/bin/rebuild-gcj-db eclipse-epic-0.6.23-1.fc9.ppc64 requires /usr/bin/rebuild-gcj-db 1:eclipse-jdt-3.3.2-11.fc9.ppc64 requires /usr/bin/rebuild-gcj-db 1:eclipse-jdt-3.3.2-11.fc9.ppc64 requires /bin/sh 1:eclipse-pde-3.3.2-11.fc9.ppc64 requires /usr/bin/rebuild-gcj-db 1:eclipse-pde-3.3.2-11.fc9.ppc64 requires /bin/bash 1:eclipse-pde-runtime-3.3.2-11.fc9.ppc64 requires /usr/bin/rebuild-gcj-db 1:eclipse-platform-3.3.2-11.fc9.ppc64 requires /bin/sh 1:eclipse-platform-3.3.2-11.fc9.ppc64 requires /usr/lib64/eclipse/plugins/org.eclipse.swt.gtk.linux.ppc64_3.3.2.v3349.jar 1:eclipse-pydev-1.3.14-1.fc9.ppc64 requires /usr/bin/rebuild-gcj-db eclipse-quickrex-3.5.0-7.fc9.ppc64 requires /bin/sh 1:eclipse-rcp-3.3.2-11.fc9.ppc64 requires /usr/bin/rebuild-gcj-db 1:eclipse-rcp-3.3.2-11.fc9.ppc64 requires /usr/lib64/eclipse/plugins/org.eclipse.swt.gtk.linux.ppc64_3.3.2.v3349.jar eclipse-setools-3.3.2.4-1.fc9.ppc64 requires /bin/sh eclipse-slide-1.3.8-1.fc9.noarch requires /bin/sh eclipse-subclipse-1.2.4-9.fc9.ppc64 requires /usr/bin/rebuild-gcj-db ecore-0.9.9.042-3.fc10.ppc64 requires /sbin/ldconfig ecryptfs-utils-40-0.fc9.ppc64 requires /sbin/ldconfig ed-0.8-2.fc9.ppc64 requires /bin/sh ed-0.8-2.fc9.ppc64 requires /sbin/install-info ed2k_hash-gui-0.4.0-7.fc9.ppc64 requires /bin/sh edje-0.5.0.042-3.fc10.ppc64 requires /sbin/ldconfig edje-0.5.0.042-3.fc10.ppc64 requires /bin/sh edrip-fonts-20080330-1.fc9.noarch requires /bin/sh edsadmin-1.0-2.fc9.noarch requires /bin/sh eel2-2.23.1-1.fc10.ppc64 requires /sbin/ldconfig eet-1.0.0-1.fc10.ppc64 requires /sbin/ldconfig efax-0.9a-1.001114.fc9.ppc64 requires /bin/sh efont-unicode-bdf-0.4.2-7.fc8.noarch requires /bin/sh efreet-0.0.3.042-3.fc10.ppc64 requires /sbin/ldconfig egd-0.9-2.fc9.noarch requires /usr/bin/perl eggdrop-1.6.19-1.fc10.ppc64 requires /bin/sh egoboo-2.7.5-4.fc9.ppc64 requires /bin/sh egoboo-data-2.7.5-1.fc9.noarch requires /bin/sh ekg-1.7-6.fc9.ppc64 requires /usr/bin/luit ekg-1.7-6.fc9.ppc64 requires /usr/bin/perl ekg-1.7-6.fc9.ppc64 requires /bin/sh ekg2-devel-0.1.1-4.fc9.ppc64 requires /bin/sh ekiga-2.0.12-2.fc10.ppc64 requires /bin/sh ekiga-2.0.12-2.fc10.ppc64 requires /bin/sh ekiga-2.0.12-2.fc10.ppc64 requires /usr/bin/scrollkeeper-update electronics-menu-1.0-1.fc9.noarch requires /bin/sh elektra-0.6.10-6.fc9.ppc64 requires /bin/sh elektra-0.6.10-6.fc9.ppc64 requires /sbin/service elektra-0.6.10-6.fc9.ppc64 requires /sbin/ldconfig elektra-0.6.10-6.fc9.ppc64 requires /bin/bash elektra-0.6.10-6.fc9.ppc64 requires /sbin/chkconfig elfutils-0.135-1.fc10.ppc64 requires /bin/sh elfutils-libelf-0.135-1.fc10.ppc64 requires /sbin/ldconfig elfutils-libs-0.135-1.fc10.ppc64 requires /sbin/ldconfig elisa-0.3.2-1.fc8.noarch requires /usr/bin/python elsa-1.4-3.fc9.ppc64 requires /usr/bin/env elsa-1.4-3.fc9.ppc64 requires /bin/sh em8300-0.16.4-1.fc9.ppc64 requires /bin/sh em8300-0.16.4-1.fc9.ppc64 requires /etc/security/console.perms.d em8300-0.16.4-1.fc9.ppc64 requires /etc/alsa/cards em8300-devel-0.16.4-1.fc9.ppc64 requires /usr/bin/perl em8300-utils-0.16.4-1.fc9.ppc64 requires /usr/bin/perl 1:emacs-22.2-4.fc9.ppc64 requires /bin/sh 1:emacs-22.2-4.fc9.ppc64 requires /bin/sh emacs-auctex-11.85-7.fc9.noarch requires /bin/sh emacs-auctex-11.85-7.fc9.noarch requires /sbin/install-info emacs-bbdb-2.35-8.fc8.noarch requires /bin/sh 1:emacs-common-22.2-4.fc9.ppc64 requires /bin/sh 1:emacs-common-22.2-4.fc9.ppc64 requires /usr/bin/perl 1:emacs-common-22.2-4.fc9.ppc64 requires /usr/sbin/alternatives 1:emacs-common-22.2-4.fc9.ppc64 requires /sbin/install-info 1:emacs-common-22.2-4.fc9.ppc64 requires /bin/sh emacs-common-ebib-1.5.2-3.fc9.noarch requires /bin/sh emacs-common-ebib-1.5.2-3.fc9.noarch requires /sbin/install-info emacs-common-ess-5.3.7-1.fc10.noarch requires /bin/sh emacs-common-ess-5.3.7-1.fc10.noarch requires /sbin/install-info emacs-common-muse-3.12-1.fc9.noarch requires /bin/sh emacs-common-muse-3.12-1.fc9.noarch requires /sbin/install-info emacs-ess-5.3.7-1.fc10.noarch requires /bin/sh 1:emacs-nox-22.2-4.fc9.ppc64 requires /bin/sh 1:emacs-nox-22.2-4.fc9.ppc64 requires /bin/sh emacs-nxml-mode-0.20041004-6.fc8.noarch requires /bin/sh emacs-vm-8.0.9.544-1.fc9.ppc64 requires /bin/sh emacs-vm-8.0.9.544-1.fc9.ppc64 requires /sbin/install-info emacspeak-26-3.fc8.noarch requires /bin/sh emacspeak-26-3.fc8.noarch requires /usr/bin/perl emacspeak-26-3.fc8.noarch requires /usr/bin/tclsh emacspeak-26-3.fc8.noarch requires /bin/sh embryo-0.9.1.042-5.fc10.ppc64 requires /sbin/ldconfig emesene-1.0-1.fc9.noarch requires /usr/bin/env empathy-0.23.2-1.fc10.ppc64 requires /bin/sh empathy-libs-0.23.2-1.fc10.ppc64 requires /sbin/ldconfig enca-1.9-4.fc9.ppc64 requires /sbin/ldconfig 1:enchant-1.3.0-4.fc10.ppc64 requires /sbin/ldconfig enemies-of-carlotta-1.2.4-1.fc7.noarch requires /usr/bin/python enet-1.1-3.fc9.ppc64 requires /sbin/ldconfig enigma-1.01-6.2.ppc64 requires /bin/sh enscript-1.6.4-9.fc9.ppc64 requires /bin/sh enscript-1.6.4-9.fc9.ppc64 requires /usr/bin/perl enscript-1.6.4-9.fc9.ppc64 requires /sbin/install-info enscript-1.6.4-9.fc9.ppc64 requires /bin/sh environment-modules-3.2.6-5.fc9.ppc64 requires /bin/sh eog-2.23.2-1.fc10.ppc64 requires /bin/sh epdfview-0.1.6-3.fc9.ppc64 requires /bin/sh epeg-0.9.1.042-4.fc10.ppc64 requires /sbin/ldconfig epiphany-2.22.1.1-1.fc9.ppc64 requires /bin/sh epiphany-extensions-2.22.1-1.fc9.ppc64 requires /bin/sh epydoc-3.0.1-1.fc9.noarch requires /usr/bin/python epylog-1.0.3-7.fc9.noarch requires /bin/sh epylog-1.0.3-7.fc9.noarch requires /usr/bin/python eric-4.1.2-2.fc9.noarch requires /bin/sh eric-4.1.2-2.fc9.noarch requires /usr/bin/env eric-4.1.2-2.fc9.noarch requires /bin/sh eric-4.1.2-2.fc9.noarch requires /usr/bin/python eris-1.3.13-2.fc9.ppc64 requires /sbin/ldconfig erlang-R12B-1.1.fc9.ppc64 requires /bin/sh erlang-R12B-1.1.fc9.ppc64 requires /bin/sh eruby-libs-1.0.5-11.ppc64 requires /sbin/ldconfig escape-200704130-8.fc9.ppc64 requires /bin/sh esmtp-0.6.0-4.fc9.ppc64 requires /bin/sh esmtp-0.6.0-4.fc9.ppc64 requires /bin/bash esmtp-0.6.0-4.fc9.ppc64 requires /usr/sbin/alternatives 1:esound-devel-0.2.38-7.fc9.ppc64 requires /bin/sh 1:esound-libs-0.2.38-7.fc9.ppc64 requires /sbin/ldconfig 1:esound-tools-0.2.38-7.fc9.ppc64 requires /bin/sh espeak-1.31-5.fc9.ppc64 requires /sbin/ldconfig eterm-0.9.4-10.fc9.ppc64 requires /sbin/ldconfig eterm-0.9.4-10.fc9.ppc64 requires /usr/bin/perl eterm-0.9.4-10.fc9.ppc64 requires /bin/sh etherape-0.9.7-6.fc9.ppc64 requires /bin/sh etherbat-1.0.1-4.fc9.ppc64 requires /usr/bin/ruby ettercap-0.7.3-22.fc9.ppc64 requires /bin/sh ettercap-0.7.3-22.fc9.ppc64 requires /usr/sbin/alternatives ettercap-gtk-0.7.3-22.fc9.ppc64 requires /bin/sh ettercap-gtk-0.7.3-22.fc9.ppc64 requires /usr/sbin/alternatives evas-0.9.9.042-3.fc10.ppc64 requires /sbin/ldconfig eventlog-0.2.5-9.fc9.ppc64 requires /sbin/ldconfig evince-2.22.1.1-1.fc9.ppc64 requires /bin/sh evolution-2.23.2-1.fc10.ppc64 requires /bin/sh evolution-2.23.2-1.fc10.ppc64 requires /usr/bin/perl evolution-bogofilter-2.23.2-1.fc10.ppc64 requires /bin/sh evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires /sbin/ldconfig evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-data-server-2.23.2-2.fc10.ppc64 requires /sbin/ldconfig evolution-exchange-2.23.2-1.fc10.ppc64 requires /bin/sh evolution-python-0.0.4-3.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) evolution-rss-0.0.8-7.fc9.ppc64 requires /bin/sh evolution-rss-0.0.8-7.fc9.ppc64 requires /sbin/ldconfig evolution-webcal-2.21.92-2.fc10.ppc64 requires /bin/sh evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) ewftools-20080501-1.fc10.ppc64 requires /usr/bin/python2.5 exaile-0.2.13-1.fc9.ppc64 requires /bin/sh exempi-2.0.0-1.fc9.ppc64 requires /sbin/ldconfig exim-4.69-5.fc10.ppc64 requires /bin/sh exim-4.69-5.fc10.ppc64 requires /usr/sbin/alternatives exim-4.69-5.fc10.ppc64 requires /usr/sbin/groupadd exim-4.69-5.fc10.ppc64 requires /usr/sbin/useradd exim-4.69-5.fc10.ppc64 requires /sbin/service exim-4.69-5.fc10.ppc64 requires /etc/aliases exim-4.69-5.fc10.ppc64 requires /bin/bash exim-4.69-5.fc10.ppc64 requires /bin/sh exim-4.69-5.fc10.ppc64 requires /usr/bin/perl exim-4.69-5.fc10.ppc64 requires /sbin/chkconfig exim-clamav-4.69-5.fc10.ppc64 requires /bin/sh exim-clamav-4.69-5.fc10.ppc64 requires /sbin/chkconfig exim-clamav-4.69-5.fc10.ppc64 requires /sbin/service exim-greylist-4.69-5.fc10.ppc64 requires /etc/cron.daily exim-greylist-4.69-5.fc10.ppc64 requires /bin/bash exim-greylist-4.69-5.fc10.ppc64 requires /bin/sh exim-mon-4.69-5.fc10.ppc64 requires /bin/sh exiv2-libs-0.16-2.fc9.ppc64 requires /sbin/ldconfig exo-0.3.4-2.fc9.ppc64 requires /bin/sh exo-0.3.4-2.fc9.ppc64 requires /usr/bin/env exo-0.3.4-2.fc9.ppc64 requires /bin/sh expat-2.0.1-5.ppc64 requires /sbin/ldconfig expect-5.43.0-13.fc9.ppc64 requires /bin/sh expectk-5.43.0-13.fc9.ppc64 requires /bin/sh ez-ipupdate-3.0.11-0.17.b8.fc9.ppc64 requires /bin/sh ez-ipupdate-3.0.11-0.17.b8.fc9.ppc64 requires /sbin/chkconfig ez-ipupdate-3.0.11-0.17.b8.fc9.ppc64 requires /usr/sbin/groupadd ez-ipupdate-3.0.11-0.17.b8.fc9.ppc64 requires /usr/sbin/useradd fRaBs-2.11-1.fc9.noarch requires /bin/sh facter-1.3.8-1.fc8.noarch requires /usr/bin/ruby fail2ban-0.8.2-13.fc9.noarch requires /bin/sh fail2ban-0.8.2-13.fc9.noarch requires /bin/bash fail2ban-0.8.2-13.fc9.noarch requires /sbin/chkconfig fail2ban-0.8.2-13.fc9.noarch requires /usr/bin/python fail2ban-0.8.2-13.fc9.noarch requires /sbin/service fakechroot-2.5-13.fc9.ppc64 requires /bin/sh fakeroot-1.6.4-16.fc9.ppc64 requires /bin/sh fakeroot-1.6.4-16.fc9.ppc64 requires /usr/bin/getopt fann-2.0.0-4.1.fc9.ppc64 requires /sbin/ldconfig fantasdic-1.0-0.1.beta5.fc9.noarch requires /bin/sh fantasdic-1.0-0.1.beta5.fc9.noarch requires /usr/bin/ruby farsight-0.1.28-1.fc10.ppc64 requires /sbin/ldconfig fbg-0.9.1-2.fc9.ppc64 requires /bin/sh fbida-fbgs-2.06-5.fc9.ppc64 requires /bin/bash fbreader-0.8.12-2.fc9.ppc64 requires /sbin/ldconfig fbset-2.1-25.fc9.ppc64 requires /usr/bin/perl fcgi-2.4.0-5.fc9.ppc64 requires /sbin/ldconfig fcron-3.0.3-4.fc9.ppc64 requires /bin/sh fcron-3.0.3-4.fc9.ppc64 requires /sbin/chkconfig fcron-3.0.3-4.fc9.ppc64 requires /usr/sbin/useradd fcron-3.0.3-4.fc9.ppc64 requires /bin/sh fcron-3.0.3-4.fc9.ppc64 requires /sbin/service fedora-ds-admin-1.1.4-1.fc9.ppc64 requires /bin/sh fedora-ds-admin-1.1.4-1.fc9.ppc64 requires /usr/bin/env fedora-ds-admin-1.1.4-1.fc9.ppc64 requires /sbin/service fedora-ds-admin-1.1.4-1.fc9.ppc64 requires /sbin/ldconfig fedora-ds-admin-1.1.4-1.fc9.ppc64 requires /usr/bin/repl-monitor.pl fedora-ds-admin-1.1.4-1.fc9.ppc64 requires /bin/sh fedora-ds-admin-1.1.4-1.fc9.ppc64 requires /sbin/chkconfig fedora-ds-base-1.1.0.1-4.fc9.ppc64 requires /sbin/ldconfig fedora-ds-base-1.1.0.1-4.fc9.ppc64 requires /usr/bin/perl fedora-ds-base-1.1.0.1-4.fc9.ppc64 requires /usr/bin/env fedora-ds-base-1.1.0.1-4.fc9.ppc64 requires /bin/sh fedora-ds-base-1.1.0.1-4.fc9.ppc64 requires /sbin/service fedora-ds-base-1.1.0.1-4.fc9.ppc64 requires /sbin/chkconfig fedora-ds-base-1.1.0.1-4.fc9.ppc64 requires /bin/sh fedora-ds-dsgw-1.1.0-1.fc9.ppc64 requires /usr/bin/env fedora-ds-dsgw-1.1.0-1.fc9.ppc64 requires /etc/dirsrv/admin-serv/httpd.conf fedora-ds-dsgw-1.1.0-1.fc9.ppc64 requires /bin/sh fedora-icon-theme-1.0.0-1.fc8.noarch requires /bin/sh fedora-idm-console-1.1.1-2.fc9.ppc64 requires /bin/sh fedora-logos-9.0.0-3.fc10.noarch requires /bin/sh fedora-logos-9.0.0-3.fc10.noarch requires /bin/sh fedora-packager-0.3.0-1.fc9.noarch requires /bin/bash fedora-packager-0.3.0-1.fc9.noarch requires /usr/bin/python fedora-release-notes-9.0.1-1.noarch requires /bin/sh fedora-usermgmt-core-0.10-1.fc8.noarch requires /bin/bash fedora-usermgmt-devel-0.10-1.fc8.noarch requires /etc/rpm fedora-usermgmt-shadow-utils-0.10-1.fc8.noarch requires /bin/sh fedora-usermgmt-shadow-utils-0.10-1.fc8.noarch requires /usr/sbin/update-alternatives fedora-usermgmt-shadow-utils-0.10-1.fc8.noarch requires /bin/sh fedora-usermgmt-shadow-utils-0.10-1.fc8.noarch requires /etc/fedora/usermgmt feh-1.3.4-8.fc9.ppc64 requires /usr/bin/perl feh-1.3.4-8.fc9.ppc64 requires /bin/bash festival-1.96-4.fc9.ppc64 requires /bin/sh festival-docs-1.4.2-4.fc9.ppc64 requires /bin/sh festival-docs-1.4.2-4.fc9.ppc64 requires /sbin/install-info festival-lib-1.96-4.fc9.ppc64 requires /sbin/ldconfig festival-speechtools-libs-1.2.96-4.fc9.ppc64 requires /sbin/ldconfig festival-speechtools-utils-1.2.96-4.fc9.ppc64 requires /usr/bin/perl festival-speechtools-utils-1.2.96-4.fc9.ppc64 requires /bin/sh fftw-3.1.2-6.fc9.ppc64 requires /sbin/install-info fftw-3.1.2-6.fc9.ppc64 requires /sbin/ldconfig fftw-3.1.2-6.fc9.ppc64 requires /bin/sh fftw-devel-3.1.2-6.fc9.ppc64 requires /bin/sh fftw2-2.1.5-16.fc9.ppc64 requires /sbin/ldconfig fftw2-devel-2.1.5-16.fc9.ppc64 requires /bin/sh fig2ps-1.3.6-2.fc7.noarch requires /usr/bin/perl file-libs-4.23-5.fc9.ppc64 requires /sbin/ldconfig file-roller-2.23.1-1.fc10.ppc64 requires /bin/sh filelight-1.0-12.fc9.ppc64 requires /bin/sh fillets-ng-0.8.0-1.fc9.ppc64 requires /bin/sh finch-2.4.1-3.fc10.ppc64 requires /sbin/ldconfig 1:findutils-4.4.0-1.fc10.ppc64 requires /bin/sh 1:findutils-4.4.0-1.fc10.ppc64 requires /sbin/install-info fio-1.20-1.fc10.ppc64 requires /bin/bash firefox-3.0-0.59.cvs20080408.fc10.ppc64 requires /bin/sh firefox-3.0-0.59.cvs20080408.fc10.ppc64 requires /bin/sh firestarter-1.0.3-18.fc9.ppc64 requires /bin/sh firestarter-1.0.3-18.fc9.ppc64 requires /bin/sh firmware-tools-1.5.6-1.fc8.noarch requires /usr/bin/python2 firmware-tools-1.5.6-1.fc8.noarch requires /bin/sh firmware-tools-1.5.6-1.fc8.noarch requires /usr/bin/python firstaidkit-0.1.1-4.fc9.noarch requires /usr/bin/python firstaidkit-devel-0.1.1-4.fc9.noarch requires /bin/bash firstboot-1.98-1.fc10.ppc64 requires /bin/sh firstboot-1.98-1.fc10.ppc64 requires /bin/bash firstboot-1.98-1.fc10.ppc64 requires /usr/bin/python2 fish-1.23.0-2.fc9.ppc64 requires /bin/sh fityk-0.8.1-13.fc9.ppc64 requires /bin/sh flac-1.2.1-4.fc9.ppc64 requires /sbin/ldconfig flagpoll-0.9.1-2.fc9.noarch requires /usr/bin/python flawfinder-1.27-3.fc8.noarch requires /usr/bin/env flex-2.5.35-2.fc10.ppc64 requires /bin/sh flex-2.5.35-2.fc10.ppc64 requires /sbin/install-info flim-1.14.8-3.fc8.noarch requires /sbin/install-info flite-1.3-9.fc9.ppc64 requires /sbin/ldconfig flobopuyo-0.20-4.fc9.ppc64 requires /bin/sh flow-tools-0.68.4-1.fc9.ppc64 requires /bin/sh flow-tools-0.68.4-1.fc9.ppc64 requires /bin/env flow-tools-0.68.4-1.fc9.ppc64 requires /bin/sh fltk-1.1.8-1.fc9.ppc64 requires /sbin/ldconfig fltk-devel-1.1.8-1.fc9.ppc64 requires /bin/sh fltk-fluid-1.1.8-1.fc9.ppc64 requires /bin/sh fluidsynth-libs-1.0.7-11.a.fc9.ppc64 requires /sbin/ldconfig flumotion-0.4.2-5.fc9.ppc64 requires /bin/sh flumotion-0.4.2-5.fc9.ppc64 requires /usr/bin/python flumotion-0.4.2-5.fc9.ppc64 requires /bin/bash fluxbox-1.0.0-5.fc9.ppc64 requires /usr/bin/env fluxbox-1.0.0-5.fc9.ppc64 requires /bin/sh fluxstyle-1.0.1-2.fc7.noarch requires /usr/bin/env fmio-2.0.8-11.fc9.ppc64 requires /sbin/ldconfig fmio-2.0.8-11.fc9.ppc64 requires /usr/bin/python fmt-ptrn-java-1.3.17-1.fc9.ppc64 requires /sbin/ldconfig fmtools-1.0.2-3.fc9.ppc64 requires /bin/sh fnfx-0.3-11.fc9.ppc64 requires /bin/sh fnfx-0.3-11.fc9.ppc64 requires /bin/bash fnfx-0.3-11.fc9.ppc64 requires /sbin/chkconfig fnfx-0.3-11.fc9.ppc64 requires /sbin/service fontconfig-2.5.0-2.fc9.ppc64 requires /bin/sh fontconfig-2.5.0-2.fc9.ppc64 requires /sbin/ldconfig fontforge-20080309-1.fc9.ppc64 requires /usr/bin/fontforge fontforge-20080309-1.fc9.ppc64 requires /sbin/ldconfig fontmatrix-0.4.2-1.fc9.ppc64 requires /bin/sh fonts-ISO8859-2-1.0-18.fc8.noarch requires /bin/sh fonts-ISO8859-2-100dpi-1.0-18.fc8.noarch requires /bin/sh fonts-ISO8859-2-75dpi-1.0-18.fc8.noarch requires /bin/sh fonts-KOI8-R-1.0-10.fc8.noarch requires /usr/bin/perl fonts-hebrew-fancy-0.20051122-2.fc7.noarch requires /bin/sh fonts-japanese-0.20061016-13.fc9.noarch requires /bin/sh fonts-truetype-apl-4.22.1-3.fc10.ppc64 requires /bin/sh fonts-x11-apl-4.22.1-3.fc10.ppc64 requires /bin/sh fonttools-2.0-0.11.20060223cvs.fc7.ppc64 requires /usr/bin/python fontypython-0.2.0-6.fc7.noarch requires /usr/bin/python foomatic-3.0.2-60.fc10.ppc64 requires /usr/bin/perl foomatic-3.0.2-60.fc10.ppc64 requires /bin/bash foomatic-3.0.2-60.fc10.ppc64 requires /bin/sh fpc-2.2.0-12.fc10.ppc64 requires /bin/sh fpc-src-2.2.0-12.fc10.ppc64 requires /bin/sh fpc-src-2.2.0-12.fc10.ppc64 requires /usr/bin/env freealut-1.1.0-6.fc9.ppc64 requires /sbin/ldconfig freealut-devel-1.1.0-6.fc9.ppc64 requires /bin/sh freeciv-2.1.4-1.fc10.ppc64 requires /bin/sh freecol-0.7.3-2.fc9.noarch requires /bin/bash freecol-0.7.3-2.fc9.noarch requires /bin/sh freedoom-0.5-3.fc8.noarch requires /bin/sh freedroid-1.0.2-9.fc9.ppc64 requires /bin/sh freedroidrpg-0.10.3-2.fc9.ppc64 requires /bin/sh freefont-20060126-4.fc7.noarch requires /bin/sh freeglut-2.4.0-14.fc9.ppc64 requires /sbin/ldconfig freehdl-0.0.6-1.fc9.ppc64 requires /bin/sh freehdl-0.0.6-1.fc9.ppc64 requires /sbin/install-info freehdl-0.0.6-1.fc9.ppc64 requires /sbin/ldconfig freehdl-0.0.6-1.fc9.ppc64 requires /usr/bin/perl freehdl-0.0.6-1.fc9.ppc64 requires /bin/sh freeimage-3.10.0-1.fc9.ppc64 requires /sbin/ldconfig freenx-0.7.1-5.fc9.ppc64 requires /bin/sh freenx-0.7.1-5.fc9.ppc64 requires /bin/bash freenx-0.7.1-5.fc9.ppc64 requires /usr/bin/expect freenx-server-0.7.2-8.fc10.ppc64 requires /bin/sh freenx-server-0.7.2-8.fc10.ppc64 requires /usr/bin/expect freenx-server-0.7.2-8.fc10.ppc64 requires /bin/bash freenx-server-0.7.2-8.fc10.ppc64 requires /usr/lib64/nx freenx-server-0.7.2-8.fc10.ppc64 requires /usr/lib/cups/backend freenx-server-0.7.2-8.fc10.ppc64 requires /bin/sh freeradius-2.0.2-2.fc9.ppc64 requires /bin/sh freeradius-2.0.2-2.fc9.ppc64 requires /sbin/ldconfig freeradius-2.0.2-2.fc9.ppc64 requires /usr/bin/perl freeradius-2.0.2-2.fc9.ppc64 requires /bin/sh freeradius-2.0.2-2.fc9.ppc64 requires /sbin/chkconfig freeradius-dialupadmin-2.0.2-2.fc9.ppc64 requires /usr/bin/perl freeradius-utils-2.0.2-2.fc9.ppc64 requires /bin/sh freeradius-utils-2.0.2-2.fc9.ppc64 requires /usr/bin/perl freetalk-3.0-2.fc9.ppc64 requires /bin/sh freetalk-3.0-2.fc9.ppc64 requires /sbin/install-info freetalk-3.0-2.fc9.ppc64 requires /bin/sh freetds-0.64-11.fc9.ppc64 requires /sbin/ldconfig freetennis-0.4.8-11.fc10.ppc64 requires /bin/sh freetype-2.3.5-4.fc9.ppc64 requires /sbin/ldconfig freetype-2.3.5-4.fc9.ppc64 requires /bin/sh freetype-devel-2.3.5-4.fc9.ppc64 requires /bin/sh freetype1-1.4-0.5.pre.fc9.ppc64 requires /sbin/ldconfig fribidi-0.19.1-2.fc9.ppc64 requires /sbin/ldconfig frozen-bubble-2.1.0-8.fc9.ppc64 requires /bin/sh frozen-bubble-2.1.0-8.fc9.ppc64 requires /usr/bin/perl frozen-bubble-server-2.1.0-8.fc9.ppc64 requires /bin/sh frozen-bubble-server-2.1.0-8.fc9.ppc64 requires /bin/sh frysk-0.2.1-2.fc9.ppc64 requires /sbin/ldconfig frysk-0.2.1-2.fc9.ppc64 requires /bin/sh frysk-devel-0.2.1-2.fc9.ppc64 requires /usr/bin/env frysk-devel-0.2.1-2.fc9.ppc64 requires /bin/bash frysk-devel-0.2.1-2.fc9.ppc64 requires /bin/sh fslint-2.24-1.fc8.noarch requires /bin/bash fslint-2.24-1.fc8.noarch requires /usr/bin/env fslint-2.24-1.fc8.noarch requires /bin/sh fslint-2.24-1.fc8.noarch requires /usr/bin/python ftgl-2.1.2-8.fc9.ppc64 requires /sbin/ldconfig ftnchek-3.3.1-7.fc9.ppc64 requires /bin/sh ftnchek-emacs-3.3.1-7.fc9.ppc64 requires /usr/share/emacs/site-lisp ftplib-3.1-4.fc9.ppc64 requires /sbin/ldconfig func-0.18-1.fc9.noarch requires /bin/sh func-0.18-1.fc9.noarch requires /bin/sh func-0.18-1.fc9.noarch requires /usr/bin/python funtools-1.4.0-7.fc9.ppc64 requires /bin/sh funtools-libs-1.4.0-7.fc9.ppc64 requires /sbin/ldconfig fuse-2.7.3-2.fc9.ppc64 requires /bin/sh fuse-2.7.3-2.fc9.ppc64 requires /sbin/MAKEDEV fuse-2.7.3-2.fc9.ppc64 requires /sbin/chkconfig fuse-2.7.3-2.fc9.ppc64 requires /bin/sh fuse-2.7.3-2.fc9.ppc64 requires /sbin/service fuse-encfs-1.4.2-2.fc10.ppc64 requires /sbin/ldconfig fuse-encfs-1.4.2-2.fc10.ppc64 requires /bin/sh fuse-gmailfs-0.8.0-1.fc9.noarch requires /usr/bin/env fuse-libs-2.7.3-2.fc9.ppc64 requires /sbin/ldconfig fuse-s3fs-0.5-1.fc10.noarch requires /usr/bin/python fvwm-2.5.24-2.fc9.ppc64 requires /usr/bin/python fvwm-2.5.24-2.fc9.ppc64 requires /usr/bin/mimeopen fvwm-2.5.24-2.fc9.ppc64 requires /usr/bin/perl fvwm-2.5.24-2.fc9.ppc64 requires /bin/sh fwbackups-1.43.1-6.fc9.noarch requires /bin/bash fwbackups-1.43.1-6.fc9.noarch requires /usr/bin/python fwbuilder-2.1.16-2.fc9.ppc64 requires /bin/sh fwfstab-0.03-2.fc9.noarch requires /bin/sh fwrestart-1.05-1.fc8.noarch requires /usr/bin/env fyre-1.0.1-5.fc9.ppc64 requires /bin/sh fyre-1.0.1-5.fc9.ppc64 requires /sbin/service fyre-1.0.1-5.fc9.ppc64 requires /bin/bash fyre-1.0.1-5.fc9.ppc64 requires /sbin/chkconfig g-wrap-1.9.9-5.fc9.ppc64 requires /sbin/ldconfig g-wrap-1.9.9-5.fc9.ppc64 requires /sbin/install-info g-wrap-devel-1.9.9-5.fc9.ppc64 requires /bin/sh g-wrap-devel-1.9.9-5.fc9.ppc64 requires /bin/sh g2banking-2.3.3-3.fc9.ppc64 requires /sbin/ldconfig g2banking-devel-2.3.3-3.fc9.ppc64 requires /bin/sh gai-0.5.10-14.fc9.ppc64 requires /sbin/ldconfig gajim-0.11.4-2.fc9.ppc64 requires /usr/bin/env gajim-0.11.4-2.fc9.ppc64 requires /bin/bash gajim-0.11.4-2.fc9.ppc64 requires /bin/sh galeon-2.0.5-1.fc9.ppc64 requires /bin/sh gallery2-2.2.4-4.fc10.noarch requires /bin/sh gallery2-2.2.4-4.fc10.noarch requires /usr/bin/perl gallery2-2.2.4-4.fc10.noarch requires /usr/bin/php gallery2-2.2.4-4.fc10.noarch requires /bin/sh galternatives-0.13.4-5.fc9.noarch requires /usr/sbin/update-alternatives galternatives-0.13.4-5.fc9.noarch requires /usr/bin/python games-menus-0.3.2-1.fc9.noarch requires /bin/sh gamin-0.1.9-5.fc9.ppc64 requires /bin/sh gamin-python-0.1.9-5.fc9.ppc64 requires /usr/bin/env gammu-1.18.91-1.fc9.ppc64 requires /bin/bash gammu-1.18.91-1.fc9.ppc64 requires /bin/sh gammu-libs-1.18.91-1.fc9.ppc64 requires /sbin/ldconfig ganglia-3.0.7-1.fc9.ppc64 requires /bin/sh ganglia-3.0.7-1.fc9.ppc64 requires /bin/sh ganglia-devel-3.0.7-1.fc9.ppc64 requires /sbin/ldconfig ganglia-gmetad-3.0.7-1.fc9.ppc64 requires /bin/sh ganglia-gmetad-3.0.7-1.fc9.ppc64 requires /sbin/chkconfig ganglia-gmetad-3.0.7-1.fc9.ppc64 requires /bin/sh ganglia-gmetad-3.0.7-1.fc9.ppc64 requires /sbin/service ganglia-gmond-3.0.7-1.fc9.ppc64 requires /bin/sh ganglia-gmond-3.0.7-1.fc9.ppc64 requires /sbin/service ganglia-gmond-3.0.7-1.fc9.ppc64 requires /bin/sh ganglia-gmond-3.0.7-1.fc9.ppc64 requires /sbin/chkconfig ganymed-ssh2-210-6.fc9.ppc64 requires /usr/bin/rebuild-gcj-db ganyremote-2.8-2.fc10.noarch requires /usr/bin/env gawk-3.1.5-17.fc9.ppc64 requires /bin/sh gawk-3.1.5-17.fc9.ppc64 requires /bin/mktemp gawk-3.1.5-17.fc9.ppc64 requires /sbin/install-info gawk-3.1.5-17.fc9.ppc64 requires /bin/sh gazpacho-0.7.2-2.fc8.noarch requires /usr/bin/python gc-7.1-1.fc10.ppc64 requires /sbin/ldconfig gcalctool-5.23.1-1.fc10.ppc64 requires /bin/sh gcc-4.3.0-8.ppc64 requires /bin/sh gcc-4.3.0-8.ppc64 requires /sbin/install-info gcc-4.3.0-8.ppc64 requires /bin/sh gcc-gfortran-4.3.0-8.ppc64 requires /bin/sh gcc-gfortran-4.3.0-8.ppc64 requires /sbin/install-info gcc-java-4.3.0-8.ppc64 requires /bin/sh gcc-java-4.3.0-8.ppc64 requires /sbin/install-info gcc-java-4.3.0-8.ppc64 requires /usr/share/java/eclipse-ecj.jar gcdmaster-1.2.2-4.fc9.ppc64 requires /bin/sh gchempaint-0.8.7-2.fc9.ppc64 requires /bin/sh gcin-1.3.9-2.fc9.ppc64 requires /bin/sh gcin-1.3.9-2.fc9.ppc64 requires /usr/sbin/alternatives gcin-1.3.9-2.fc9.ppc64 requires /bin/bash 1:gcombust-0.1.55-13.ppc64 requires /bin/sh gcompris-8.4.5-1.fc10.ppc64 requires /bin/sh gcompris-8.4.5-1.fc10.ppc64 requires /sbin/install-info gconf-editor-2.22.0-1.fc9.ppc64 requires /bin/sh gconfmm26-2.22.0-1.fc9.ppc64 requires /bin/sh gconfmm26-2.22.0-1.fc9.ppc64 requires /sbin/ldconfig gcstar-1.3.2-1.fc9.noarch requires /usr/bin/perl gcstar-1.3.2-1.fc9.noarch requires /bin/sh gd-2.0.35-5.fc9.ppc64 requires /sbin/ldconfig gd-devel-2.0.35-5.fc9.ppc64 requires /bin/sh gd-progs-2.0.35-5.fc9.ppc64 requires /usr/bin/perl gdal-1.5.1-5.fc9.ppc64 requires /sbin/ldconfig gdal-devel-1.5.1-5.fc9.ppc64 requires /bin/sh gdal-python-1.5.1-5.fc9.ppc64 requires /usr/bin/env gdb-6.8-5.fc10.ppc64 requires /bin/sh gdb-6.8-5.fc10.ppc64 requires /sbin/install-info gdb-6.8-5.fc10.ppc64 requires /bin/sh gdbm-1.8.0-28.fc9.ppc64 requires /sbin/ldconfig gdbm-devel-1.8.0-28.fc9.ppc64 requires /bin/sh gdbm-devel-1.8.0-28.fc9.ppc64 requires /sbin/install-info gdeskcal-1.01-1.fc7.noarch requires /bin/sh gdeskcal-1.01-1.fc7.noarch requires /usr/bin/env gdesklets-0.36-1.fc9.ppc64 requires /bin/sh gdesklets-0.36-1.fc9.ppc64 requires /usr/bin/env gdevilspie-0.31-2.fc10.noarch requires /usr/bin/python 1:gdk-pixbuf-0.22.0-36.fc9.ppc64 requires /sbin/ldconfig 1:gdk-pixbuf-devel-0.22.0-36.fc9.ppc64 requires /bin/sh 1:gdm-2.22.0-6.fc10.ppc64 requires /bin/sh 1:gdm-2.22.0-6.fc10.ppc64 requires /usr/sbin/useradd 1:gdm-2.22.0-6.fc10.ppc64 requires /sbin/nologin 1:gdm-2.22.0-6.fc10.ppc64 requires /bin/sh gdome2-0.8.1-6.2.fc9.ppc64 requires /sbin/ldconfig gdome2-devel-0.8.1-6.2.fc9.ppc64 requires /bin/sh gds2pov-0.20080229-1.fc9.ppc64 requires /sbin/ldconfig geant321-2006-29.fc9.ppc64 requires /bin/sh geant321-g77-2006-29.fc9.ppc64 requires /bin/sh geda-gattrib-20080127-2.fc9.ppc64 requires /bin/sh geda-gnetlist-20080127-1.fc9.ppc64 requires /usr/bin/gawk geda-gnetlist-20080127-1.fc9.ppc64 requires /bin/bash geda-gschem-20080127-2.fc9.ppc64 requires /bin/sh geda-gschem-20080127-2.fc9.ppc64 requires /bin/sh geda-utils-20080127-1.fc9.ppc64 requires /usr/bin/env geda-utils-20080127-1.fc9.ppc64 requires /usr/bin/python geda-utils-20080127-1.fc9.ppc64 requires /usr/bin/perl geda-utils-20080127-1.fc9.ppc64 requires /bin/bash 1:gedit-2.23.1-1.fc10.ppc64 requires /bin/sh 1:gedit-2.23.1-1.fc10.ppc64 requires /bin/sh gedit-plugins-2.22.0-1.fc9.ppc64 requires /bin/sh geeqie-1.0-0.4.alpha1.fc10.ppc64 requires /bin/sh gegl-0.0.16-1.fc9.ppc64 requires /sbin/ldconfig gemdropx-0.9-4.fc9.ppc64 requires /bin/sh gengetopt-2.22-1.fc9.ppc64 requires /bin/sh gengetopt-2.22-1.fc9.ppc64 requires /sbin/install-info genisoimage-1.1.6-11.fc9.ppc64 requires /bin/sh genisoimage-1.1.6-11.fc9.ppc64 requires /usr/sbin/alternatives genisoimage-1.1.6-11.fc9.ppc64 requires /bin/sh genisoimage-1.1.6-11.fc9.ppc64 requires /usr/bin/perl gentium-fonts-1.02-5.fc7.noarch requires /bin/sh geoclue-0.11.1-4.fc10.ppc64 requires /sbin/ldconfig geomview-1.9.4-8.fc9.ppc64 requires /bin/sh geomview-1.9.4-8.fc9.ppc64 requires /sbin/install-info geomview-1.9.4-8.fc9.ppc64 requires /bin/sh geomview-libs-1.9.4-8.fc9.ppc64 requires /sbin/ldconfig geoqo-0.96-5.fc9.noarch requires /usr/bin/perl geos-3.0.0-3.fc10.ppc64 requires /sbin/ldconfig geos-devel-3.0.0-3.fc10.ppc64 requires /bin/sh gerbv-2.0.0-1.fc9.ppc64 requires /bin/sh gerbv-2.0.0-1.fc9.ppc64 requires /usr/bin/perl geronimo-specs-1.0-1.M2.2jpp.12.ppc64 requires /bin/sh getmail-4.8.1-1.fc9.noarch requires /usr/bin/python gettext-0.17-5.fc10.ppc64 requires /bin/sh gettext-0.17-5.fc10.ppc64 requires /sbin/install-info gettext-0.17-5.fc10.ppc64 requires /usr/bin/python gettext-0.17-5.fc10.ppc64 requires /sbin/ldconfig gettext-0.17-5.fc10.ppc64 requires /bin/sh gettext-devel-0.17-5.fc10.ppc64 requires /bin/sh gettext-devel-0.17-5.fc10.ppc64 requires /sbin/install-info gettext-devel-0.17-5.fc10.ppc64 requires /sbin/ldconfig gettext-devel-0.17-5.fc10.ppc64 requires /bin/sh gfa-0.4.1-6.fc9.ppc64 requires /bin/sh gforth-0.6.2-12.fc9.ppc64 requires /bin/sh gforth-0.6.2-12.fc9.ppc64 requires /usr/bin/gforth gforth-0.6.2-12.fc9.ppc64 requires /sbin/install-info gforth-0.6.2-12.fc9.ppc64 requires /bin/sh gfs-artemisia-fonts-20070415-6.fc10.noarch requires /bin/sh gfs-baskerville-fonts-20070327-7.fc10.noarch requires /bin/sh gfs-bodoni-classic-fonts-20070415-6.fc10.noarch requires /bin/sh gfs-bodoni-fonts-20070415-5.fc10.noarch requires /bin/sh gfs-complutum-fonts-20070413-7.fc10.noarch requires /bin/sh gfs-didot-classic-fonts-20070415-5.fc10.noarch requires /bin/sh gfs-didot-fonts-20070616-6.fc10.noarch requires /bin/sh gfs-gazis-fonts-20080318-2.fc10.noarch requires /bin/sh gfs-neohellenic-fonts-20070415-5.fc10.noarch requires /bin/sh gfs-olga-fonts-20060908-5.fc10.noarch requires /bin/sh gfs-porson-fonts-20060908-7.fc10.noarch requires /bin/sh gfs-solomos-fonts-20071114-6.fc10.noarch requires /bin/sh gfs-theokritos-fonts-20070415-6.fc10.noarch requires /bin/sh gfs2-utils-2.03.00-4.fc10.ppc64 requires /bin/sh gfs2-utils-2.03.00-4.fc10.ppc64 requires /bin/bash gfs2-utils-2.03.00-4.fc10.ppc64 requires /sbin/chkconfig gfs2-utils-2.03.00-4.fc10.ppc64 requires /sbin/service 2:gftp-2.0.18-3.fc9.ppc64 requires /bin/sh gg2-libs-2.3.0-9.fc9.ppc64 requires /sbin/ldconfig ggobi-2.1.7-1.fc9.ppc64 requires /sbin/ldconfig ggz-client-libs-0.0.14.1-1.fc9.ppc64 requires /sbin/ldconfig ggz-gtk-client-0.0.14.1-1.fc9.ppc64 requires /sbin/ldconfig ghex-2.22.0-1.ppc64 requires /bin/sh ghex-2.22.0-1.ppc64 requires /sbin/ldconfig ghostscript-8.62-3.fc9.ppc64 requires /sbin/ldconfig ghostscript-8.62-3.fc9.ppc64 requires /usr/bin/perl ghostscript-8.62-3.fc9.ppc64 requires /bin/sh ghostscript-devel-8.62-3.fc9.ppc64 requires /bin/sh ghostscript-fonts-5.50-18.fc8.noarch requires /bin/sh ghostscript-fonts-5.50-18.fc8.noarch requires /usr/bin/mkfontscale ghostscript-fonts-5.50-18.fc8.noarch requires /usr/bin/mkfontdir giblib-1.2.4-11.ppc64 requires /sbin/ldconfig giblib-devel-1.2.4-11.ppc64 requires /bin/sh giflib-4.1.3-9.ppc64 requires /sbin/ldconfig giflib-utils-4.1.3-9.ppc64 requires /usr/bin/perl giflib-utils-4.1.3-9.ppc64 requires /bin/sh gift-0.11.8.1-10.fc9.ppc64 requires /sbin/ldconfig gift-0.11.8.1-10.fc9.ppc64 requires /usr/bin/perl gift-0.11.8.1-10.fc9.ppc64 requires /bin/bash gift-gnutella-0.0.11-5.fc9.ppc64 requires /sbin/ldconfig giggle-0.4-2.fc9.ppc64 requires /bin/sh gimmage-0.2.3-2.fc9.ppc64 requires /bin/sh gimmie-0.2.8-2.fc9.ppc64 requires /bin/sh gimmie-0.2.8-2.fc9.ppc64 requires /usr/bin/python 2:gimp-2.4.5-1.fc9.ppc64 requires /bin/sh 2:gimp-2.4.5-1.fc9.ppc64 requires /usr/bin/update-desktop-database 2:gimp-2.4.5-1.fc9.ppc64 requires /usr/bin/env 2:gimp-2.4.5-1.fc9.ppc64 requires /bin/bash 2:gimp-2.4.5-1.fc9.ppc64 requires /bin/sh 2:gimp-libs-2.4.5-1.fc9.ppc64 requires /sbin/ldconfig ginac-1.4.3-1.fc10.ppc64 requires /sbin/ldconfig ginac-1.4.3-1.fc10.ppc64 requires /sbin/install-info ginac-devel-1.4.3-1.fc10.ppc64 requires /bin/sh ginac-utils-1.4.3-1.fc10.ppc64 requires /bin/sh git-1.5.5.1-1.fc10.ppc64 requires /usr/bin/perl git-1.5.5.1-1.fc10.ppc64 requires /bin/sh git-arch-1.5.5.1-1.fc10.ppc64 requires /usr/bin/perl git-cvs-1.5.5.1-1.fc10.ppc64 requires /usr/bin/perl git-email-1.5.5.1-1.fc10.ppc64 requires /usr/bin/perl git-gui-1.5.5.1-1.fc10.ppc64 requires /bin/sh git-svn-1.5.5.1-1.fc10.ppc64 requires /usr/bin/perl gitk-1.5.5.1-1.fc10.ppc64 requires /bin/sh gitweb-1.5.5.1-1.fc10.ppc64 requires /usr/bin/perl gjots2-2.3.4-8.fc10.noarch requires /bin/sh gjots2-2.3.4-8.fc10.noarch requires /usr/bin/env gkrellm-2.3.1-3.fc9.ppc64 requires /bin/sh gkrellm-daemon-2.3.1-3.fc9.ppc64 requires /bin/sh gkrellm-daemon-2.3.1-3.fc9.ppc64 requires /bin/bash gkrellm-daemon-2.3.1-3.fc9.ppc64 requires /sbin/chkconfig gkrellm-daemon-2.3.1-3.fc9.ppc64 requires /sbin/service gkrellm-weather-2.0.7-6.fc9.ppc64 requires /usr/bin/perl glabels-2.2.2-1.fc10.ppc64 requires /bin/sh glabels-2.2.2-1.fc10.ppc64 requires /sbin/ldconfig glabels-doc-2.2.2-1.fc10.ppc64 requires /bin/sh glabels-libs-2.2.2-1.fc10.ppc64 requires /sbin/ldconfig glade3-3.4.4-1.fc9.ppc64 requires /bin/sh glade3-libgladeui-3.4.4-1.fc9.ppc64 requires /sbin/ldconfig glaxium-0.5-4.fc9.ppc64 requires /bin/sh glew-1.5.0-2.fc9.ppc64 requires /sbin/ldconfig glglobe-0.2-6.fc9.ppc64 requires /bin/sh 1:glib-1.2.10-29.fc9.ppc64 requires /sbin/ldconfig 1:glib-devel-1.2.10-29.fc9.ppc64 requires /bin/sh glib-java-0.2.6-12.fc9.ppc64 requires /sbin/ldconfig glib-java-0.2.6-12.fc9.ppc64 requires /sbin/ldconfig glib2-2.16.3-5.fc10.ppc64 requires /sbin/ldconfig glib2-devel-2.16.3-5.fc10.ppc64 requires /usr/bin/perl glib2-devel-2.16.3-5.fc10.ppc64 requires /bin/sh glibc-2.8.90-2.ppc64 requires /usr/sbin/glibc_post_upgrade.ppc64 glibc-2.8.90-2.ppc64 requires /sbin/ldconfig glibc-common-2.8.90-2.ppc64 requires /usr/sbin/build-locale-archive glibc-common-2.8.90-2.ppc64 requires /bin/bash glibc-common-2.8.90-2.ppc64 requires /usr/sbin/tzdata-update glibc-common-2.8.90-2.ppc64 requires /bin/sh glibc-devel-2.8.90-2.ppc64 requires /bin/sh glibc-devel-2.8.90-2.ppc64 requires /sbin/install-info glibc-headers-2.8.90-2.ppc64 requires /bin/sh glibc-utils-2.8.90-2.ppc64 requires /sbin/ldconfig glibc-utils-2.8.90-2.ppc64 requires /bin/bash glibc-utils-2.8.90-2.ppc64 requires /usr/bin/perl glibmm24-2.16.0-1.fc9.ppc64 requires /sbin/ldconfig glibmm24-devel-2.16.0-1.fc9.ppc64 requires /usr/bin/perl glimmer-3.02-3.fc9.ppc64 requires /bin/csh glimmer-3.02-3.fc9.ppc64 requires /bin/awk glipper-1.0-3.fc9.ppc64 requires /bin/sh glipper-1.0-3.fc9.ppc64 requires /usr/bin/env glitz-0.5.6-6.fc9.ppc64 requires /sbin/ldconfig glitz-glx-0.5.6-6.fc9.ppc64 requires /sbin/ldconfig gliv-1.9.6-3.fc9.ppc64 requires /bin/sh glob2-0.9.3-1.fc10.ppc64 requires /bin/sh global-5.4-2.fc9.ppc64 requires /bin/sh glom-1.6.15-1.fc9.ppc64 requires /bin/sh glom-1.6.15-1.fc9.ppc64 requires /sbin/ldconfig glpi-0.70.2-3.fc10.noarch requires /bin/sh glpi-0.70.2-3.fc10.noarch requires /sbin/service glpi-0.70.2-3.fc10.noarch requires /etc/logrotate.d glpi-mass-ocs-import-1.1-1.fc9.noarch requires /bin/sh glpi-mass-ocs-import-1.1-1.fc9.noarch requires /bin/sh glpi-mass-ocs-import-1.1-1.fc9.noarch requires /etc/cron.d glpk-4.28-1.fc10.ppc64 requires /sbin/ldconfig glpk-utils-4.28-1.fc10.ppc64 requires /bin/sh glump-0.9.11-3.fc8.noarch requires /usr/bin/python glunarclock-0.32.4-11.fc9.ppc64 requires /bin/sh glusterfs-client-1.3.9-1.fc10.ppc64 requires /bin/sh glusterfs-libs-1.3.9-1.fc10.ppc64 requires /sbin/ldconfig glusterfs-server-1.3.9-1.fc10.ppc64 requires /bin/sh glusterfs-server-1.3.9-1.fc10.ppc64 requires /bin/sh glyph-keeper-0.32-4.fc9.ppc64 requires /sbin/ldconfig gmediaserver-0.13.0-3.fc9.ppc64 requires /bin/sh gmediaserver-0.13.0-3.fc9.ppc64 requires /sbin/install-info gmediaserver-0.13.0-3.fc9.ppc64 requires /bin/bash gmediaserver-0.13.0-3.fc9.ppc64 requires /sbin/chkconfig gmfsk-0.7-0.5.pre1.fc9.ppc64 requires /bin/sh gmime-2.2.19-1.fc10.ppc64 requires /sbin/ldconfig gmime-devel-2.2.19-1.fc10.ppc64 requires /bin/sh gmp-4.2.2-7.fc9.ppc64 requires /sbin/ldconfig gmp-devel-4.2.2-7.fc9.ppc64 requires /bin/sh gmp-devel-4.2.2-7.fc9.ppc64 requires /sbin/install-info gmpc-0.15.5.0-3.fc9.ppc64 requires /bin/sh gmyth-0.7.1-1.fc9.ppc64 requires /sbin/ldconfig gnash-0.8.2-2.fc9.ppc64 requires /bin/sh gnash-0.8.2-2.fc9.ppc64 requires /sbin/install-info gnash-0.8.2-2.fc9.ppc64 requires /sbin/ldconfig gnash-0.8.2-2.fc9.ppc64 requires /bin/sh gnash-plugin-0.8.2-2.fc9.ppc64 requires /usr/lib64/mozilla/plugins gnet2-2.0.7-11.fc9.ppc64 requires /sbin/ldconfig gnochm-0.9.11-2.fc9.noarch requires /bin/sh gnochm-0.9.11-2.fc9.noarch requires /usr/bin/python gnofract4d-3.8-1.fc9.ppc64 requires /bin/sh gnofract4d-3.8-1.fc9.ppc64 requires /usr/bin/env gnofract4d-3.8-1.fc9.ppc64 requires /usr/bin/python gnokii-0.6.24-1.fc9.ppc64 requires /bin/sh gnokii-0.6.24-1.fc9.ppc64 requires /sbin/ldconfig gnokii-0.6.24-1.fc9.ppc64 requires /usr/sbin/groupadd gnokii-smsd-0.6.24-1.fc9.ppc64 requires /bin/sh gnokii-smsd-0.6.24-1.fc9.ppc64 requires /bin/bash gnokii-smsd-0.6.24-1.fc9.ppc64 requires /sbin/chkconfig gnokii-smsd-0.6.24-1.fc9.ppc64 requires /usr/sbin/useradd gnokii-smsd-0.6.24-1.fc9.ppc64 requires /bin/sh gnome-applet-music-2.3.1-1.fc10.ppc64 requires /bin/sh gnome-applet-music-2.3.1-1.fc10.ppc64 requires /usr/bin/env gnome-applet-netspeed-0.14-3.fc9.ppc64 requires /bin/sh gnome-applet-sensors-1.8.2-2.fc9.ppc64 requires /bin/sh gnome-applet-sshmenu-3.15-5.fc9.noarch requires /bin/sh gnome-applet-sshmenu-3.15-5.fc9.noarch requires /usr/bin/ruby gnome-applet-timer-2.0.1-1.fc9.ppc64 requires /bin/sh gnome-applet-timer-2.0.1-1.fc9.ppc64 requires /usr/bin/env 1:gnome-applets-2.23.2-1.fc10.ppc64 requires /bin/sh 1:gnome-applets-2.23.2-1.fc10.ppc64 requires /usr/bin/env gnome-bluetooth-0.11.0-3.fc9.ppc64 requires /bin/sh gnome-bluetooth-libs-0.11.0-3.fc9.ppc64 requires /sbin/ldconfig gnome-build-0.2.4-1.fc9.ppc64 requires /sbin/ldconfig gnome-build-0.2.4-1.fc9.ppc64 requires /usr/bin/perl gnome-chemistry-utils-0.8.7-1.fc9.ppc64 requires /bin/sh gnome-chemistry-utils-mozplugin-0.8.7-1.fc9.ppc64 requires /usr/lib64/mozilla/plugins gnome-commander-1.2.5-1.fc9.ppc64 requires /bin/sh gnome-common-2.18.0-1.fc8.noarch requires /bin/sh gnome-compiz-manager-0.10.4-4.fc9.ppc64 requires /bin/sh gnome-compiz-manager-0.10.4-4.fc9.ppc64 requires /sbin/ldconfig gnome-desktop-2.23.2-0.2008.05.14.1.fc10.ppc64 requires /usr/bin/python gnome-desktop-2.23.2-0.2008.05.14.1.fc10.ppc64 requires /sbin/ldconfig gnome-device-manager-0.2-3.fc9.ppc64 requires /bin/sh gnome-device-manager-devel-0.2-3.fc9.ppc64 requires /sbin/ldconfig gnome-device-manager-libs-0.2-3.fc9.ppc64 requires /sbin/ldconfig gnome-doc-utils-0.12.2-1.fc9.noarch requires /bin/sh gnome-doc-utils-0.12.2-1.fc9.noarch requires /usr/bin/python 1:gnome-games-2.23.1-2.fc10.ppc64 requires /bin/sh 1:gnome-games-2.23.1-2.fc10.ppc64 requires /usr/bin/env gnome-genius-1.0.2-3.fc9.ppc64 requires /bin/sh gnome-icon-theme-2.22.0-6.fc9.noarch requires /bin/sh gnome-keyring-2.22.1-1.fc9.ppc64 requires /bin/sh gnome-keyring-2.22.1-1.fc9.ppc64 requires /sbin/ldconfig gnome-keyring-manager-2.20.0-2.fc9.ppc64 requires /bin/sh gnome-launch-box-0.4-9.fc10.ppc64 requires /bin/sh 1:gnome-libs-1.4.2-8.fc9.ppc64 requires /sbin/ldconfig 1:gnome-libs-1.4.2-8.fc9.ppc64 requires /bin/sh 1:gnome-libs-devel-1.4.2-8.fc9.ppc64 requires /bin/sh 1:gnome-libs-devel-1.4.2-8.fc9.ppc64 requires /usr/bin/perl gnome-mag-0.15.0-2.fc9.ppc64 requires /sbin/ldconfig gnome-media-2.23.1.1-2.fc10.ppc64 requires /bin/sh gnome-menus-2.23.1-1.fc10.ppc64 requires /sbin/ldconfig gnome-mount-0.8-1.fc9.ppc64 requires /bin/sh gnome-nds-thumbnailer-1.0.2-1.fc9.ppc64 requires /bin/sh gnome-netstatus-2.12.1-4.fc9.ppc64 requires /bin/sh gnome-nettool-2.22.0-1.fc9.ppc64 requires /bin/sh gnome-packagekit-0.2.1-2.20080508.fc10.ppc64 requires /bin/sh gnome-packagekit-0.2.1-2.20080508.fc10.ppc64 requires /usr/bin/python gnome-panel-2.23.2.1-1.fc10.ppc64 requires /bin/sh gnome-password-generator-1.5-2.fc9.noarch requires /bin/sh gnome-password-generator-1.5-2.fc9.noarch requires /usr/bin/python gnome-phone-manager-0.51-2.fc10.ppc64 requires /bin/sh gnome-pilot-2.0.16-2.fc9.ppc64 requires /bin/sh gnome-pilot-conduits-2.0.16-1.fc9.ppc64 requires /sbin/ldconfig gnome-power-manager-2.22.1-1.fc9.ppc64 requires /bin/sh gnome-power-manager-2.22.1-1.fc9.ppc64 requires /bin/sh gnome-ppp-0.3.23-5.fc9.ppc64 requires /bin/sh gnome-python2-bonobo-2.22.0-2.fc9.ppc64 requires /usr/bin/env gnome-python2-bonobo-2.22.0-2.fc9.ppc64 requires /bin/sh gnome-python2-gconf-2.22.0-2.fc9.ppc64 requires /usr/bin/env gnome-python2-gnomeprint-2.22.0-4.fc10.ppc64 requires /usr/bin/env gnome-python2-gnomevfs-2.22.0-2.fc9.ppc64 requires /usr/bin/env gnome-python2-libegg-2.19.1-15.fc9.ppc64 requires /usr/bin/python gnome-scan-0.6-2.fc9.ppc64 requires /bin/sh gnome-scan-libs-0.6-2.fc9.ppc64 requires /sbin/ldconfig gnome-schedule-2.0.2-1.fc9.noarch requires /bin/sh gnome-schedule-2.0.2-1.fc9.noarch requires /bin/sh gnome-screensaver-2.23.3-0.2008.05.14.1.fc10.ppc64 requires /bin/sh gnome-session-2.23.2.2-3.fc10.ppc64 requires /bin/sh gnome-session-2.23.2.2-3.fc10.ppc64 requires /bin/sh gnome-settings-daemon-2.23.2-0.2008.05.14.2.fc10.ppc64 requires /bin/sh gnome-specimen-0.3-1.fc8.noarch requires /bin/sh gnome-specimen-0.3-1.fc8.noarch requires /usr/bin/python gnome-speech-0.4.19-1.fc10.ppc64 requires /sbin/ldconfig gnome-system-monitor-2.22.1-5.fc9.ppc64 requires /bin/sh gnome-terminal-2.22.1-1.fc9.ppc64 requires /bin/sh gnome-themes-2.23.1-1.fc10.noarch requires /bin/sh gnome-translate-0.99-12.fc9.ppc64 requires /bin/sh gnome-user-docs-2.22.0-1.fc9.noarch requires /bin/sh gnome-user-share-0.31-1.fc9.ppc64 requires /bin/sh 1:gnome-utils-2.20.0.1-5.fc10.ppc64 requires /bin/sh gnome-vfs2-2.22.0-1.fc9.ppc64 requires /bin/sh gnome-vfs2-2.22.0-1.fc9.ppc64 requires /sbin/ldconfig gnome-vfs2-monikers-2.15.3-5.fc9.ppc64 requires /sbin/ldconfig gnome-vfsmm26-2.22.0-1.fc9.ppc64 requires /bin/sh gnome-vfsmm26-2.22.0-1.fc9.ppc64 requires /sbin/ldconfig gnome-volume-manager-2.22.5-1.fc10.ppc64 requires /bin/sh gnome-volume-manager-2.22.5-1.fc10.ppc64 requires /bin/sh gnome-web-photo-0.3-11.fc9.ppc64 requires /bin/sh gnomebaker-0.6.2-2.1.fc9.ppc64 requires /bin/sh gnomecatalog-0.3.4-3.fc9.noarch requires /usr/bin/python gnomeradio-1.7-5.fc9.ppc64 requires /bin/sh gnomesword-2.3.3-2.fc9.ppc64 requires /bin/sh gnotime-2.3.0-1.fc9.ppc64 requires /bin/sh gnotime-2.3.0-1.fc9.ppc64 requires /bin/sh gnu-getopt-1.0.12-4jpp.1.ppc64 requires /bin/sh gnu-getopt-javadoc-1.0.12-4jpp.1.ppc64 requires /bin/sh gnu-getopt-javadoc-1.0.12-4jpp.1.ppc64 requires /bin/ln gnu-getopt-javadoc-1.0.12-4jpp.1.ppc64 requires /bin/rm gnubg-20061119-14.fc9.ppc64 requires /bin/sh gnubg-20061119-14.fc9.ppc64 requires /sbin/install-info gnubiff-2.2.7-4.fc9.ppc64 requires /bin/sh gnubiff-2.2.7-4.fc9.ppc64 requires /sbin/install-info gnucap-0.35-4.fc9.ppc64 requires /bin/sh gnucash-2.2.4-1.fc9.ppc64 requires /bin/sh gnucash-2.2.4-1.fc9.ppc64 requires /sbin/ldconfig gnucash-2.2.4-1.fc9.ppc64 requires /usr/bin/perl gnucash-2.2.4-1.fc9.ppc64 requires /bin/sh gnucash-docs-2.2.0-2.fc8.noarch requires /bin/sh gnucash-docs-2.2.0-2.fc8.noarch requires /usr/bin/scrollkeeper-update gnue-common-0.6.9-4.fc10.noarch requires /usr/bin/python gnugo-3.6-6.fc9.ppc64 requires /bin/sh 1:gnumeric-1.8.2-2.fc9.ppc64 requires /bin/sh 1:gnumeric-1.8.2-2.fc9.ppc64 requires /sbin/ldconfig 1:gnumeric-plugins-extras-1.8.2-2.fc9.ppc64 requires /usr/bin/perl gnupg-1.4.9-1.fc9.ppc64 requires /bin/sh gnupg-1.4.9-1.fc9.ppc64 requires /sbin/install-info gnupg-1.4.9-1.fc9.ppc64 requires /bin/sh gnupg2-2.0.9-1.fc9.ppc64 requires /bin/sh gnupg2-2.0.9-1.fc9.ppc64 requires /sbin/install-info gnupg2-2.0.9-1.fc9.ppc64 requires /bin/sh gnuplot-4.2.3-1.fc10.ppc64 requires /bin/sh gnuplot-4.2.3-1.fc10.ppc64 requires /sbin/install-info gnuradio-3.1.1-4.fc9.ppc64 requires /sbin/ldconfig gnuradio-devel-3.1.1-4.fc9.ppc64 requires /sbin/ldconfig gnustep-make-2.0.4-9.fc9.ppc64 requires /bin/sh gnutls-2.0.4-2.fc9.ppc64 requires /sbin/ldconfig gnutls-devel-2.0.4-2.fc9.ppc64 requires /bin/sh gnutls-devel-2.0.4-2.fc9.ppc64 requires /sbin/install-info gnutls-devel-2.0.4-2.fc9.ppc64 requires /bin/sh gobby-0.4.5-3.fc9.ppc64 requires /bin/sh goffice-0.6.2-1.fc9.ppc64 requires /sbin/ldconfig goffice04-0.4.3-3.fc9.ppc64 requires /sbin/ldconfig gok-1.3.7-3.fc9.ppc64 requires /bin/sh gonvert-0.2.19-3.fc9.noarch requires /usr/bin/python goocanvas-0.9-4.fc9.ppc64 requires /sbin/ldconfig goocanvasmm-0.4.0-3.fc9.ppc64 requires /sbin/ldconfig gossip-0.29-2.fc10.ppc64 requires /bin/sh gourmet-0.13.4-3.fc9.noarch requires /usr/bin/python gpa-0.7.6-5.fc10.ppc64 requires /bin/sh gpar2-0.3-6.fc9.ppc64 requires /bin/sh gparted-0.3.7-1.fc10.ppc64 requires /bin/sh gparted-0.3.7-1.fc10.ppc64 requires /bin/bash gperf-3.0.3-4.fc9.ppc64 requires /bin/sh gperf-3.0.3-4.fc9.ppc64 requires /sbin/install-info gpgme-1.1.6-3.fc9.ppc64 requires /sbin/ldconfig gpgme-devel-1.1.6-3.fc9.ppc64 requires /bin/sh gpgme-devel-1.1.6-3.fc9.ppc64 requires /sbin/install-info gpgme-devel-1.1.6-3.fc9.ppc64 requires /bin/sh gphoto2-2.4.0-10.fc9.ppc64 requires /bin/sh gphoto2-2.4.0-10.fc9.ppc64 requires /bin/bash gphoto2-devel-2.4.0-10.fc9.ppc64 requires /bin/sh gpixpod-0.6.2-3.fc9.ppc64 requires /bin/bash gpm-1.20.1-90.fc9.ppc64 requires /bin/sh gpm-1.20.1-90.fc9.ppc64 requires /sbin/ldconfig gpm-1.20.1-90.fc9.ppc64 requires /bin/bash gpm-1.20.1-90.fc9.ppc64 requires /sbin/chkconfig gpm-1.20.1-90.fc9.ppc64 requires /sbin/install-info gpodder-0.11.1-2.fc9.noarch requires /bin/sh gpodder-0.11.1-2.fc9.noarch requires /usr/bin/python gpredict-0.9.0-3.fc9.ppc64 requires /bin/sh gpsd-2.37-2.fc9.ppc64 requires /usr/bin/env gpsd-2.37-2.fc9.ppc64 requires /sbin/ldconfig gpsd-clients-2.37-2.fc9.ppc64 requires /usr/bin/env gpsd-devel-2.37-2.fc9.ppc64 requires /usr/bin/env gpsdrive-2.09-5.fc9.ppc64 requires /sbin/ldconfig gpsdrive-2.09-5.fc9.ppc64 requires /bin/bash gpsdrive-2.09-5.fc9.ppc64 requires /bin/sh gpsdrive-2.09-5.fc9.ppc64 requires /usr/bin/perl gpsim-0.22.0-5.fc8.ppc64 requires /sbin/ldconfig gpsman-6.3.2-3.fc9.noarch requires /bin/sh gq-1.3.4-1.fc9.ppc64 requires /bin/sh gquilt-0.20-3.fc9.noarch requires /bin/sh gquilt-0.20-3.fc9.noarch requires /bin/bash gqview-2.0.4-9.ppc64 requires /bin/sh grace-5.1.21-9.fc9.ppc64 requires /bin/sh grace-5.1.21-9.fc9.ppc64 requires /bin/sh gramps-2.2.10-1.fc9.noarch requires /bin/sh gramps-2.2.10-1.fc9.noarch requires /bin/sh graphviz-2.16.1-0.5.fc9.ppc64 requires /bin/sh graphviz-2.16.1-0.5.fc9.ppc64 requires /sbin/ldconfig graphviz-2.16.1-0.5.fc9.ppc64 requires /bin/sh graphviz-devil-2.16.1-0.5.fc9.ppc64 requires /bin/sh graphviz-gd-2.16.1-0.5.fc9.ppc64 requires /bin/sh graphviz-gd-2.16.1-0.5.fc9.ppc64 requires /sbin/ldconfig graphviz-gd-2.16.1-0.5.fc9.ppc64 requires /usr/bin/dot graphviz-tcl-2.16.1-0.5.fc9.ppc64 requires /bin/sh grass-6.3.0-0.4.RC6.fc9.ppc64 requires /usr/bin/python grass-6.3.0-0.4.RC6.fc9.ppc64 requires /bin/bash grass-6.3.0-0.4.RC6.fc9.ppc64 requires /bin/sh grass-libs-6.3.0-0.4.RC6.fc9.ppc64 requires /sbin/ldconfig grep-2.5.1-59.fc9.ppc64 requires /bin/sh grep-2.5.1-59.fc9.ppc64 requires /sbin/install-info grepmail-5.3033-4.fc9.noarch requires /usr/bin/perl gresistor-0.0.1-11.fc8.noarch requires /bin/sh gresistor-0.0.1-11.fc8.noarch requires /usr/bin/python greyhounds-0.8-0.3.prealpha.fc9.ppc64 requires /bin/sh greylistd-0.8.3.2-8.fc7.noarch requires /bin/sh greylistd-0.8.3.2-8.fc7.noarch requires /bin/bash greylistd-0.8.3.2-8.fc7.noarch requires /sbin/chkconfig greylistd-0.8.3.2-8.fc7.noarch requires /usr/bin/python greylistd-0.8.3.2-8.fc7.noarch requires /sbin/service grhino-0.16.0-5.fc9.ppc64 requires /bin/sh gridengine-6.1u4-1.fc10.ppc64 requires /bin/sh gridengine-6.1u4-1.fc10.ppc64 requires /bin/csh gridengine-6.1u4-1.fc10.ppc64 requires /bin/ksh gridengine-6.1u4-1.fc10.ppc64 requires /usr/sbin/alternatives gridengine-6.1u4-1.fc10.ppc64 requires /sbin/ldconfig gridengine-6.1u4-1.fc10.ppc64 requires /usr/sbin/alternatives gridengine-6.1u4-1.fc10.ppc64 requires /bin/sh gridengine-devel-6.1u4-1.fc10.ppc64 requires /bin/csh gridengine-devel-6.1u4-1.fc10.ppc64 requires /bin/sh gridengine-execd-6.1u4-1.fc10.ppc64 requires /bin/sh gridengine-execd-6.1u4-1.fc10.ppc64 requires /sbin/service gridengine-execd-6.1u4-1.fc10.ppc64 requires /bin/sh gridengine-execd-6.1u4-1.fc10.ppc64 requires /sbin/chkconfig gridengine-qmaster-6.1u4-1.fc10.ppc64 requires /bin/sh gridengine-qmaster-6.1u4-1.fc10.ppc64 requires /sbin/service gridengine-qmaster-6.1u4-1.fc10.ppc64 requires /bin/sh gridengine-qmaster-6.1u4-1.fc10.ppc64 requires /sbin/chkconfig grig-0.7.2-5.fc9.ppc64 requires /bin/sh grisbi-0.5.9-5.fc9.ppc64 requires /bin/sh groff-1.18.1.4-14.fc9.ppc64 requires /bin/sh groff-1.18.1.4-14.fc9.ppc64 requires /bin/sed groff-1.18.1.4-14.fc9.ppc64 requires /sbin/install-info groff-1.18.1.4-14.fc9.ppc64 requires /bin/bash groff-1.18.1.4-14.fc9.ppc64 requires /bin/sh groff-perl-1.18.1.4-14.fc9.ppc64 requires /usr/bin/perl groff-perl-1.18.1.4-14.fc9.ppc64 requires /bin/sh grsync-0.6.1-2.fc9.ppc64 requires /bin/bash gruler-0.8-3.fc9.noarch requires /usr/bin/ruby gruler-0.8-3.fc9.noarch requires /bin/bash gscan2pdf-0.9.21-2.fc9.noarch requires /bin/sh gscan2pdf-0.9.21-2.fc9.noarch requires /usr/bin/perl gshutdown-0.2-3.fc9.ppc64 requires /bin/sh gsl-1.10-10.fc9.ppc64 requires /sbin/ldconfig gsl-devel-1.10-10.fc9.ppc64 requires /bin/sh gsl-devel-1.10-10.fc9.ppc64 requires /sbin/install-info gsl-devel-1.10-10.fc9.ppc64 requires /bin/sh gsm-1.0.12-6.fc9.ppc64 requires /sbin/ldconfig gsoap-2.7.10-4.fc9.ppc64 requires /sbin/ldconfig gst-inspector-0.3-5.fc9.noarch requires /bin/sh gst-inspector-0.3-5.fc9.noarch requires /usr/bin/python gstream-1.6-2.fc9.ppc64 requires /sbin/ldconfig gstream-devel-1.6-2.fc9.ppc64 requires /bin/sh gstream-devel-1.6-2.fc9.ppc64 requires /sbin/install-info gstreamer-0.10.19-1.fc9.ppc64 requires /sbin/ldconfig gstreamer-0.10.19-1.fc9.ppc64 requires /bin/sh gstreamer-devel-0.10.19-1.fc9.ppc64 requires /bin/sh gstreamer-plugins-base-0.10.19-1.fc9.ppc64 requires /usr/bin/perl gstreamer-plugins-farsight-0.12.8-1.fc10.ppc64 requires /sbin/ldconfig gstreamer-plugins-good-0.10.8-1.fc10.ppc64 requires /bin/sh gt5-1.4.0-4.fc9.noarch requires /bin/sh gthumb-2.10.8-3.fc10.ppc64 requires /bin/sh gthumb-2.10.8-3.fc10.ppc64 requires /bin/bash 1:gtk+-1.2.10-61.fc9.ppc64 requires /sbin/ldconfig 1:gtk+-devel-1.2.10-61.fc9.ppc64 requires /bin/sh gtk+extra-2.1.1-8.fc9.ppc64 requires /sbin/ldconfig gtk-doc-1.10-1.fc10.noarch requires /bin/sh gtk-doc-1.10-1.fc10.noarch requires /usr/bin/perl gtk-doc-1.10-1.fc10.noarch requires /bin/sh gtk-doc-1.10-1.fc10.noarch requires /usr/bin/cmp gtk-doc-1.10-1.fc10.noarch requires /usr/bin/python gtk-recordmydesktop-0.3.7-1.fc9.noarch requires /usr/bin/python gtk-vnc-0.3.6-1.fc10.ppc64 requires /sbin/ldconfig gtk2-2.13.0-2.fc10.ppc64 requires /bin/sh gtk2-2.13.0-2.fc10.ppc64 requires /bin/sh gtk2-devel-2.13.0-2.fc10.ppc64 requires /usr/bin/env gtkdatabox-0.8.2.2-2.fc9.ppc64 requires /sbin/ldconfig gtkglarea2-1.99.0-8.fc9.ppc64 requires /sbin/ldconfig gtkglext-libs-1.2.0-6.fc9.ppc64 requires /bin/sh gtkglextmm-1.2.0-6.fc9.ppc64 requires /bin/sh gtkglextmm-1.2.0-6.fc9.ppc64 requires /sbin/ldconfig gtkhtml2-2.11.1-3.fc9.ppc64 requires /sbin/ldconfig gtkhtml3-3.23.2-4.fc10.ppc64 requires /sbin/ldconfig gtkimageview-1.5.0-2.fc9.ppc64 requires /sbin/ldconfig gtkmathview-0.7.6-7.fc9.ppc64 requires /sbin/ldconfig gtkmm24-2.12.5-1.fc9.ppc64 requires /sbin/ldconfig gtkmozembedmm-1.4.2.cvs20060817-17.fc9.ppc64 requires /sbin/ldconfig gtkpod-0.99.12-2.fc9.ppc64 requires /bin/sh gtkpod-0.99.12-2.fc9.ppc64 requires /usr/bin/python gtkpod-0.99.12-2.fc9.ppc64 requires /usr/bin/awk gtkpod-0.99.12-2.fc9.ppc64 requires /bin/bash gtkpod-0.99.12-2.fc9.ppc64 requires /bin/sh gtkpod-0.99.12-2.fc9.ppc64 requires /usr/bin/perl 1:gtksourceview-1.8.5-4.fc9.ppc64 requires /sbin/ldconfig gtksourceview2-2.2.1-1.fc9.ppc64 requires /sbin/ldconfig gtkspell-2.0.11-8.fc9.ppc64 requires /sbin/ldconfig gtkterm-0.99.5-9.fc9.ppc64 requires /bin/sh gtorrentviewer-0.2b-15.fc9.ppc64 requires /bin/sh gtranslator-1.1.7-8.fc9.ppc64 requires /bin/sh gtranslator-1.1.7-8.fc9.ppc64 requires /bin/sh gts-0.7.6-9.fc9.ppc64 requires /sbin/ldconfig gts-0.7.6-9.fc9.ppc64 requires /bin/sh gts-devel-0.7.6-9.fc9.ppc64 requires /bin/sh gtypist-2.7-6.fc9.ppc64 requires /bin/sh gtypist-2.7-6.fc9.ppc64 requires /usr/bin/perl gtypist-2.7-6.fc9.ppc64 requires /sbin/install-info gucharmap-2.22.1-1.fc9.ppc64 requires /bin/sh guichan-0.7.1-1.fc9.ppc64 requires /sbin/ldconfig 5:guile-1.8.5-1.fc10.ppc64 requires /bin/sh 5:guile-1.8.5-1.fc10.ppc64 requires /sbin/install-info 5:guile-1.8.5-1.fc10.ppc64 requires /sbin/ldconfig 5:guile-1.8.5-1.fc10.ppc64 requires /bin/sh guile-cairo-1.4.0-6.fc9.ppc64 requires /bin/sh guile-cairo-1.4.0-6.fc9.ppc64 requires /sbin/ldconfig guile-cairo-1.4.0-6.fc9.ppc64 requires /sbin/install-info 5:guile-devel-1.8.5-1.fc10.ppc64 requires /usr/bin/guile 5:guile-devel-1.8.5-1.fc10.ppc64 requires /bin/sh guile-lib-0.1.6-1.fc9.noarch requires /bin/sh guile-lib-0.1.6-1.fc9.noarch requires /sbin/install-info guilt-0.30-1.fc8.noarch requires /bin/sh gutenprint-5.0.2-2.fc9.ppc64 requires /sbin/ldconfig gutenprint-cups-5.0.2-2.fc9.ppc64 requires /bin/sh gutenprint-cups-5.0.2-2.fc9.ppc64 requires /usr/bin/perl gutenprint-foomatic-5.0.2-2.fc9.ppc64 requires /bin/sh gutenprint-foomatic-5.0.2-2.fc9.ppc64 requires /usr/bin/python gv-3.6.3-3.fc9.ppc64 requires /bin/sh gv-3.6.3-3.fc9.ppc64 requires /sbin/install-info gv-3.6.3-3.fc9.ppc64 requires /usr/bin/update-desktop-database gv-3.6.3-3.fc9.ppc64 requires /usr/bin/update-mime-database gvfs-0.2.3-10.fc10.ppc64 requires /bin/sh gvfs-0.2.3-10.fc10.ppc64 requires /bin/sh gwenhywfar-2.6.2-2.fc9.ppc64 requires /sbin/ldconfig gwenhywfar-devel-2.6.2-2.fc9.ppc64 requires /bin/sh gwget-0.99-5.fc9.ppc64 requires /bin/sh gxine-0.5.902-1.fc10.ppc64 requires /bin/sh gypsy-0.6-3.fc10.ppc64 requires /sbin/ldconfig gzip-1.3.12-6.fc9.ppc64 requires /bin/sh gzip-1.3.12-6.fc9.ppc64 requires /bin/sh gzip-1.3.12-6.fc9.ppc64 requires /sbin/install-info hackedbox-0.8.5-5.fc9.ppc64 requires /bin/bash hackedbox-0.8.5-5.fc9.ppc64 requires /bin/sh hal-0.5.11-1.fc10.ppc64 requires /bin/sh hal-0.5.11-1.fc10.ppc64 requires /usr/sbin/useradd hal-0.5.11-1.fc10.ppc64 requires /usr/bin/polkit-auth hal-0.5.11-1.fc10.ppc64 requires /sbin/ldconfig hal-0.5.11-1.fc10.ppc64 requires /bin/bash hal-0.5.11-1.fc10.ppc64 requires /bin/sh hal-cups-utils-0.6.16-3.fc9.ppc64 requires /bin/sh hal-cups-utils-0.6.16-3.fc9.ppc64 requires /bin/env hal-cups-utils-0.6.16-3.fc9.ppc64 requires /bin/sh halberd-0.2.2-2.fc8.noarch requires /usr/bin/python halevt-0.0.8-1.fc9.ppc64 requires /bin/sh halevt-0.0.8-1.fc9.ppc64 requires /sbin/chkconfig halevt-0.0.8-1.fc9.ppc64 requires /bin/sh halevt-0.0.8-1.fc9.ppc64 requires /sbin/service hamlib-1.2.7-1.fc9.ppc64 requires /sbin/ldconfig hamlib-c++-1.2.7-1.fc9.ppc64 requires /sbin/ldconfig hamlib-tcl-1.2.7-1.fc9.ppc64 requires /sbin/ldconfig hamster-applet-0.4-1.fc10.ppc64 requires /bin/sh hamster-applet-0.4-1.fc10.ppc64 requires /usr/bin/env haproxy-1.3.14.3-1.fc9.ppc64 requires /bin/sh haproxy-1.3.14.3-1.fc9.ppc64 requires /sbin/chkconfig haproxy-1.3.14.3-1.fc9.ppc64 requires /usr/sbin/useradd haproxy-1.3.14.3-1.fc9.ppc64 requires /bin/sh haproxy-1.3.14.3-1.fc9.ppc64 requires /sbin/service harminv-1.3.1-10.fc9.ppc64 requires /sbin/ldconfig hatari-1.0.1-1.fc9.ppc64 requires /bin/sh hawknl-1.68-3.fc9.ppc64 requires /sbin/ldconfig hddtemp-0.3-0.15.beta15.fc9.ppc64 requires /bin/sh hddtemp-0.3-0.15.beta15.fc9.ppc64 requires /usr/bin/consolehelper hddtemp-0.3-0.15.beta15.fc9.ppc64 requires /bin/bash hddtemp-0.3-0.15.beta15.fc9.ppc64 requires /sbin/chkconfig hdf-4.2r3-2.fc9.ppc64 requires /bin/sh hdf5-1.8.0.snap5-2.fc10.ppc64 requires /sbin/ldconfig hdf5-devel-1.8.0.snap5-2.fc10.ppc64 requires /bin/bash hdf5-devel-1.8.0.snap5-2.fc10.ppc64 requires /bin/sh heartbeat-2.1.3-1.fc9.ppc64 requires /bin/sh heartbeat-2.1.3-1.fc9.ppc64 requires /usr/bin/python heartbeat-2.1.3-1.fc9.ppc64 requires /sbin/ldconfig heartbeat-2.1.3-1.fc9.ppc64 requires /bin/sh heartbeat-2.1.3-1.fc9.ppc64 requires /sbin/chkconfig heartbeat-gui-2.1.3-1.fc9.ppc64 requires /usr/bin/python hedgewars-0.9.3-1.fc10.ppc64 requires /bin/sh help2man-1.36.4-2.fc9.noarch requires /usr/bin/perl help2man-1.36.4-2.fc9.noarch requires /sbin/install-info help2man-1.36.4-2.fc9.noarch requires /bin/sh hercules-3.05-4.fc9.ppc64 requires /usr/bin/perl hercules-3.05-4.fc9.ppc64 requires /bin/sh hesinfo-3.1.0-3.ppc64 requires /sbin/ldconfig hesiod-3.1.0-10.ppc64 requires /sbin/ldconfig hfsutils-3.2.6-14.fc9.ppc64 requires /bin/sh hgsvn-0.1.5-3.fc9.noarch requires /usr/bin/python hicolor-icon-theme-0.10-4.noarch requires /bin/sh higlayout-1.0-2.fc9.ppc64 requires /bin/sh higlayout-javadoc-1.0-2.fc9.ppc64 requires /bin/sh hippo-canvas-0.2.31-1.fc10.ppc64 requires /sbin/ldconfig homebank-3.8-1.fc9.ppc64 requires /bin/sh horde-3.1.7-2.fc9.noarch requires /bin/sh horde-3.1.7-2.fc9.noarch requires /usr/bin/php horde-3.1.7-2.fc9.noarch requires /bin/sh horde-3.1.7-2.fc9.noarch requires /sbin/service hotwire-0.721-1.fc9.noarch requires /bin/sh hotwire-0.721-1.fc9.noarch requires /usr/bin/python hpic-0.52.2-6.fc9.ppc64 requires /sbin/ldconfig hplip-2.8.2-3.fc10.ppc64 requires /bin/sh hplip-2.8.2-3.fc10.ppc64 requires /usr/bin/env hplip-2.8.2-3.fc10.ppc64 requires /usr/bin/python hplip-2.8.2-3.fc10.ppc64 requires /sbin/service hplip-2.8.2-3.fc10.ppc64 requires /sbin/chkconfig hplip-gui-2.8.2-3.fc10.ppc64 requires /bin/sh hplip-gui-2.8.2-3.fc10.ppc64 requires /usr/bin/env hspell-1.0-8.fc9.ppc64 requires /usr/bin/perl 1:hsqldb-1.8.0.9-2jpp.1.fc9.ppc64 requires /bin/sh 1:hsqldb-1.8.0.9-2jpp.1.fc9.ppc64 requires /bin/ln 1:hsqldb-1.8.0.9-2jpp.1.fc9.ppc64 requires /bin/rm 1:hsqldb-1.8.0.9-2jpp.1.fc9.ppc64 requires /bin/sh 1:hsqldb-demo-1.8.0.9-2jpp.1.fc9.ppc64 requires /bin/sh 1:hsqldb-javadoc-1.8.0.9-2jpp.1.fc9.ppc64 requires /bin/sh 1:hsqldb-javadoc-1.8.0.9-2jpp.1.fc9.ppc64 requires /bin/rm 1:hsqldb-javadoc-1.8.0.9-2jpp.1.fc9.ppc64 requires /bin/ln ht2html-2.0-5.fc6.noarch requires /bin/sh ht2html-2.0-5.fc6.noarch requires /usr/bin/env 4:htdig-3.2.0-0.1.b6.fc10.ppc64 requires /bin/sh html-xml-utils-3.7-5.fc9.ppc64 requires /bin/bash html-xml-utils-3.7-5.fc9.ppc64 requires /usr/bin/perl html2ps-1.0-0.1.b5.fc10.noarch requires /usr/bin/perl html401-dtds-4.01-19991224.5.noarch requires /bin/sh html401-dtds-4.01-19991224.5.noarch requires /usr/bin/install-catalog htmldoc-1.8.27-6.fc9.ppc64 requires /bin/sh htmlview-4.0.0-3.fc7.noarch requires /bin/bash httpd-2.2.8-3.ppc64 requires /bin/sh httpd-2.2.8-3.ppc64 requires /usr/sbin/useradd httpd-2.2.8-3.ppc64 requires /etc/mime.types httpd-2.2.8-3.ppc64 requires /bin/bash httpd-2.2.8-3.ppc64 requires /bin/sh httpd-devel-2.2.8-3.ppc64 requires /usr/bin/perl httpd-devel-2.2.8-3.ppc64 requires /bin/sh httrack-3.42-9.fc9.ppc64 requires /sbin/ldconfig httrack-3.42-9.fc9.ppc64 requires /bin/bash hugin-0.7.0-0.3.20080218svn.fc9.ppc64 requires /bin/sh hugin-base-0.7.0-0.3.20080218svn.fc9.ppc64 requires /sbin/ldconfig hugin-base-0.7.0-0.3.20080218svn.fc9.ppc64 requires /bin/sh hunspell-1.2.2-3.fc10.ppc64 requires /sbin/ldconfig hunspell-devel-1.2.2-3.fc10.ppc64 requires /usr/bin/perl hunt-1.5-7.fc9.ppc64 requires /bin/sh hwbrowser-0.42-1.fc9.noarch requires /bin/sh hydrogen-0.9.3-13.fc9.ppc64 requires /bin/sh hydrogen-0.9.3-13.fc9.ppc64 requires /bin/sh hyperestraier-1.4.13-2.fc9.ppc64 requires /sbin/ldconfig hyperestraier-1.4.13-2.fc9.ppc64 requires /bin/sh hyperestraier-devel-1.4.13-2.fc9.ppc64 requires /bin/sh hyperestraier-java-1.4.13-2.fc9.ppc64 requires /sbin/ldconfig hyperestraier-perl-1.4.13-2.fc9.ppc64 requires /usr/bin/perl hyphen-2.4-1.fc10.ppc64 requires /sbin/ldconfig hyphen-devel-2.4-1.fc10.ppc64 requires /usr/bin/perl i2c-tools-3.0.0-3.fc9.ppc64 requires /usr/bin/perl ibmonitor-1.4-1.noarch requires /usr/bin/perl icecast-2.3.1-5.fc9.ppc64 requires /usr/sbin/useradd icecast-2.3.1-5.fc9.ppc64 requires /bin/sh icecast-2.3.1-5.fc9.ppc64 requires /sbin/service icecast-2.3.1-5.fc9.ppc64 requires /bin/sh icecast-2.3.1-5.fc9.ppc64 requires /sbin/chkconfig icecream-0.8.0-11.20080117svn.fc9.ppc64 requires /bin/sh icecream-0.8.0-11.20080117svn.fc9.ppc64 requires /usr/bin/env icecream-0.8.0-11.20080117svn.fc9.ppc64 requires /bin/sh icedax-1.1.6-11.fc9.ppc64 requires /bin/sh icedax-1.1.6-11.fc9.ppc64 requires /usr/sbin/alternatives icedax-1.1.6-11.fc9.ppc64 requires /bin/sh ices-2.0.1-6.fc9.ppc64 requires /bin/sh ices-2.0.1-6.fc9.ppc64 requires /sbin/service ices-2.0.1-6.fc9.ppc64 requires /bin/sh ices-2.0.1-6.fc9.ppc64 requires /sbin/chkconfig icewm-xdgmenu-1.2.35-4.fc9.ppc64 requires /bin/sh icewm-xdgmenu-1.2.35-4.fc9.ppc64 requires /usr/bin/python icon-naming-utils-0.8.6-2.fc9.noarch requires /usr/bin/perl icu4j-3.6.1-2jpp.6.fc9.ppc64 requires /bin/sh id3lib-3.8.3-20.fc9.ppc64 requires /sbin/ldconfig idw-gpl-1.5.0-5.fc10.ppc64 requires /bin/sh ifd-egate-0.05-20.ppc64 requires /bin/sh ifm-5.1-6.fc9.ppc64 requires /usr/bin/perl ifm-5.1-6.fc9.ppc64 requires /usr/bin/wish ifplugd-0.28-11.fc9.ppc64 requires /bin/sh ifplugd-0.28-11.fc9.ppc64 requires /bin/bash ifplugd-0.28-11.fc9.ppc64 requires /bin/sh igraph-0.5-13.fc9.ppc64 requires /sbin/ldconfig igraph-0.5-13.fc9.ppc64 requires /sbin/install-info igraph-devel-0.5-13.fc9.ppc64 requires /bin/sh iksemel-1.3-4.fc9.ppc64 requires /sbin/ldconfig iksemel-devel-1.3-4.fc9.ppc64 requires /sbin/install-info iksemel-devel-1.3-4.fc9.ppc64 requires /bin/sh ilmbase-1.0.1-2.fc9.ppc64 requires /sbin/ldconfig im-chooser-0.99.6-4.fc10.ppc64 requires /usr/sbin/alternatives imake-1.0.2-6.fc9.ppc64 requires /usr/bin/perl imake-1.0.2-6.fc9.ppc64 requires /bin/sh imapsync-1.249-1.fc8.noarch requires /usr/bin/perl 1:imlib-1.9.15-7.fc9.ppc64 requires /sbin/ldconfig 1:imlib-devel-1.9.15-7.fc9.ppc64 requires /usr/share/aclocal 1:imlib-devel-1.9.15-7.fc9.ppc64 requires /bin/sh imlib2-1.4.0-5.fc9.ppc64 requires /sbin/ldconfig imlib2-devel-1.4.0-5.fc9.ppc64 requires /bin/sh imsettings-0.99.6-4.fc10.ppc64 requires /bin/sh imsettings-0.99.6-4.fc10.ppc64 requires /bin/dbus-send imsettings-libs-0.99.6-4.fc10.ppc64 requires /sbin/ldconfig inadyn-1.96.2-3.fc9.ppc64 requires /bin/sh inadyn-1.96.2-3.fc9.ppc64 requires /sbin/chkconfig inadyn-1.96.2-3.fc9.ppc64 requires /sbin/service inchi-1.0.2-0.3.fc9.ppc64 requires /sbin/ldconfig inconsolata-fonts-1.009-1.fc9.noarch requires /bin/sh incron-0.5.7-1.fc9.ppc64 requires /bin/sh incron-0.5.7-1.fc9.ppc64 requires /bin/bash incron-0.5.7-1.fc9.ppc64 requires /sbin/chkconfig incron-0.5.7-1.fc9.ppc64 requires /sbin/service indent-2.2.10-1.fc9.ppc64 requires /bin/sh indent-2.2.10-1.fc9.ppc64 requires /sbin/install-info info-4.12-1.fc10.ppc64 requires /bin/sh initng-0.6.10.2-2.fc9.ppc64 requires /bin/sh initng-0.6.10.2-2.fc9.ppc64 requires /bin/sh initng-conf-gtk-0.5.1-4.fc9.ppc64 requires /bin/sh initng-ifiles-0.1.4-5.fc9.ppc64 requires /bin/sh initng-ifiles-0.1.4-5.fc9.ppc64 requires /bin/sh initng-ifiles-0.1.4-5.fc9.ppc64 requires /sbin/ldconfig initng-ifiles-0.1.4-5.fc9.ppc64 requires /bin/bash initng-lib-0.6.10.2-2.fc9.ppc64 requires /sbin/ldconfig initscripts-8.76.1-1.ppc64 requires /bin/sh initscripts-8.76.1-1.ppc64 requires /bin/sed initscripts-8.76.1-1.ppc64 requires /etc/redhat-release initscripts-8.76.1-1.ppc64 requires /sbin/runuser initscripts-8.76.1-1.ppc64 requires /sbin/sysctl initscripts-8.76.1-1.ppc64 requires /bin/awk initscripts-8.76.1-1.ppc64 requires /bin/sed initscripts-8.76.1-1.ppc64 requires /sbin/pidof initscripts-8.76.1-1.ppc64 requires /sbin/fuser initscripts-8.76.1-1.ppc64 requires /bin/bash initscripts-8.76.1-1.ppc64 requires /sbin/arping initscripts-8.76.1-1.ppc64 requires /bin/sh initscripts-8.76.1-1.ppc64 requires /bin/grep initscripts-8.76.1-1.ppc64 requires /bin/find initscripts-8.76.1-1.ppc64 requires /usr/sbin/groupadd initscripts-8.76.1-1.ppc64 requires /sbin/chkconfig initscripts-8.76.1-1.ppc64 requires /sbin/ip inkscape-0.46-2.fc9.ppc64 requires /bin/sh inkscape-0.46-2.fc9.ppc64 requires /usr/bin/env inkscape-0.46-2.fc9.ppc64 requires /bin/sh inkscape-0.46-2.fc9.ppc64 requires /usr/bin/perl inn-2.4.4-1.fc10.ppc64 requires /bin/sh inn-2.4.4-1.fc10.ppc64 requires /usr/lib/news/lib/innshellvars.pl inn-2.4.4-1.fc10.ppc64 requires /bin/bash inn-2.4.4-1.fc10.ppc64 requires /bin/sh inn-2.4.4-1.fc10.ppc64 requires /usr/bin/perl innotop-1.6.0-2.fc9.noarch requires /usr/bin/perl inotify-tools-3.13-1.fc9.ppc64 requires /sbin/ldconfig international-time-0.0.2-4.fc8.noarch requires /bin/sh international-time-0.0.2-4.fc8.noarch requires /usr/bin/python intltool-0.37.1-1.fc9.ppc64 requires /usr/bin/perl intltool-0.37.1-1.fc9.ppc64 requires /bin/sh iotop-0.1-3.fc9.noarch requires /usr/bin/python iozone-3-5.fc9.ppc64 requires /bin/sh ip-sentinel-0.12-11.fc9.ppc64 requires /bin/sh ip-sentinel-sysv-0.12-11.fc9.ppc64 requires /bin/sh ip-sentinel-sysv-0.12-11.fc9.ppc64 requires /bin/bash ip-sentinel-sysv-0.12-11.fc9.ppc64 requires /sbin/chkconfig ipa-admintools-1.0.0-5.fc10.ppc64 requires /usr/bin/python ipa-client-1.0.0-5.fc10.ppc64 requires /usr/bin/python ipa-radius-admintools-1.0.0-5.fc10.ppc64 requires /usr/bin/python ipa-radius-server-1.0.0-5.fc10.ppc64 requires /usr/bin/python ipa-server-1.0.0-5.fc10.ppc64 requires /bin/sh ipa-server-1.0.0-5.fc10.ppc64 requires /usr/bin/python ipa-server-1.0.0-5.fc10.ppc64 requires /bin/sh ipa-server-selinux-1.0.0-5.fc10.ppc64 requires /bin/sh ipcalculator-0.41-6.fc9.noarch requires /usr/bin/perl ipcalculator-cgi-0.41-6.fc9.noarch requires /usr/bin/perl ipe-6.0-0.24.pre30.fc9.ppc64 requires /sbin/ldconfig iproute-2.6.25-1.fc10.ppc64 requires /bin/bash iprutils-2.2.8-2.fc9.ppc64 requires /bin/sh iprutils-2.2.8-2.fc9.ppc64 requires /bin/sh ipsec-tools-0.7-13.fc9.ppc64 requires /bin/sh ipsec-tools-0.7-13.fc9.ppc64 requires /bin/sh ipsec-tools-0.7-13.fc9.ppc64 requires /bin/bash iptables-1.4.0-4.fc9.ppc64 requires /bin/sh iptables-1.4.0-4.fc9.ppc64 requires /bin/sh iptables-ipv6-1.4.0-4.fc9.ppc64 requires /bin/sh iptables-ipv6-1.4.0-4.fc9.ppc64 requires /bin/sh iputils-20071127-2.fc9.ppc64 requires /bin/sh iputils-20071127-2.fc9.ppc64 requires /bin/bash iputils-20071127-2.fc9.ppc64 requires /sbin/chkconfig iputils-20071127-2.fc9.ppc64 requires /sbin/service ipv6calc-0.71.0-2.fc9.ppc64 requires /usr/bin/perl ipv6calc-0.71.0-2.fc9.ppc64 requires /bin/sh ipvsadm-1.24-11.ppc64 requires /bin/sh ipvsadm-1.24-11.ppc64 requires /bin/bash ipvsadm-1.24-11.ppc64 requires /sbin/chkconfig ipvsadm-1.24-11.ppc64 requires /bin/sh ipxripd-0.8-5.fc9.ppc64 requires /bin/sh ipxripd-0.8-5.fc9.ppc64 requires /sbin/chkconfig ipxripd-0.8-5.fc9.ppc64 requires /bin/sh ipxripd-0.8-5.fc9.ppc64 requires /sbin/service ipython-0.8.2-1.fc9.noarch requires /usr/bin/env ipython-0.8.2-1.fc9.noarch requires /usr/bin/python ircd-hybrid-7.2.3-5.fc9.ppc64 requires /bin/sh ircd-hybrid-7.2.3-5.fc9.ppc64 requires /sbin/service ircd-hybrid-7.2.3-5.fc9.ppc64 requires /bin/sh ircd-hybrid-7.2.3-5.fc9.ppc64 requires /sbin/chkconfig irda-utils-0.9.18-4.fc9.ppc64 requires /bin/sh irda-utils-0.9.18-4.fc9.ppc64 requires /sbin/chkconfig irda-utils-0.9.18-4.fc9.ppc64 requires /bin/sh 2:irqbalance-0.55-9.fc10.ppc64 requires /bin/sh 2:irqbalance-0.55-9.fc10.ppc64 requires /sbin/chkconfig 2:irqbalance-0.55-9.fc10.ppc64 requires /bin/sh 2:irqbalance-0.55-9.fc10.ppc64 requires /sbin/service iscsi-initiator-utils-6.2.0.868-0.7.fc9.ppc64 requires /bin/sh iscsi-initiator-utils-6.2.0.868-0.7.fc9.ppc64 requires /bin/sh iscsi-initiator-utils-6.2.0.868-0.7.fc9.ppc64 requires /sbin/service isdn4k-utils-3.2-58.fc9.ppc64 requires /bin/sh isdn4k-utils-3.2-58.fc9.ppc64 requires /bin/ln isdn4k-utils-3.2-58.fc9.ppc64 requires /sbin/ldconfig isdn4k-utils-3.2-58.fc9.ppc64 requires /bin/bash isdn4k-utils-3.2-58.fc9.ppc64 requires /bin/sh isdn4k-utils-3.2-58.fc9.ppc64 requires /usr/bin/perl isdn4k-utils-3.2-58.fc9.ppc64 requires /sbin/chkconfig isicom-3.05-20.fc9.ppc64 requires /bin/sh isicom-3.05-20.fc9.ppc64 requires /sbin/chkconfig isicom-3.05-20.fc9.ppc64 requires /bin/sh isicom-3.05-20.fc9.ppc64 requires /sbin/service isight-firmware-tools-1.0.2-2.fc9.ppc64 requires /bin/sh isight-firmware-tools-1.0.2-2.fc9.ppc64 requires /sbin/install-info isns-utils-0.91-0.0.fc9.ppc64 requires /bin/sh isns-utils-0.91-0.0.fc9.ppc64 requires /sbin/service isns-utils-0.91-0.0.fc9.ppc64 requires /sbin/chkconfig isns-utils-0.91-0.0.fc9.ppc64 requires /bin/sh isomaster-1.3.1-1.fc9.ppc64 requires /bin/sh isomaster-1.3.1-1.fc9.ppc64 requires /bin/sh istanbul-0.2.2-7.fc10.ppc64 requires /usr/bin/python isync-1.0.4-1.fc9.ppc64 requires /bin/sh itpp-4.0.0-2.fc9.ppc64 requires /sbin/ldconfig itpp-devel-4.0.0-2.fc9.ppc64 requires /bin/sh iverilog-0.9.20080314-1.fc9.ppc64 requires /bin/sh iwidgets-4.0.2-1.fc9.noarch requires /bin/sh jabberd-2.1.23-1.fc9.ppc64 requires /bin/sh jabberd-2.1.23-1.fc9.ppc64 requires /sbin/service jabberd-2.1.23-1.fc9.ppc64 requires /bin/bash jabbim-0.4-0.4.20080407svn.fc9.noarch requires /bin/sh jabbim-0.4-0.4.20080407svn.fc9.noarch requires /usr/bin/env jabbim-0.4-0.4.20080407svn.fc9.noarch requires /bin/sh jabbin-2.0-0.6.beta2a.fc9.ppc64 requires /bin/sh jack-audio-connection-kit-0.109.2-1.fc9.1.ppc64 requires /bin/sh jack-audio-connection-kit-0.109.2-1.fc9.1.ppc64 requires /sbin/ldconfig jack-rack-1.4.7-1.fc9.ppc64 requires /usr/bin/python jadetex-3.13-2.fc9.noarch requires /bin/sh jadetex-3.13-2.fc9.noarch requires /bin/sh jakarta-commons-beanutils-1.7.0-6jpp.1.ppc64 requires /bin/sh jakarta-commons-beanutils-javadoc-1.7.0-6jpp.1.ppc64 requires /bin/sh jakarta-commons-beanutils-javadoc-1.7.0-6jpp.1.ppc64 requires /bin/rm jakarta-commons-beanutils-javadoc-1.7.0-6jpp.1.ppc64 requires /bin/ln jakarta-commons-cli-1.0-7jpp_10.fc9.ppc64 requires /usr/bin/rebuild-gcj-db jakarta-commons-codec-1.3-9jpp.2.fc9.ppc64 requires /bin/sh jakarta-commons-collections-3.2-2jpp.2.fc9.ppc64 requires /bin/sh jakarta-commons-collections-testframework-3.2-2jpp.2.fc9.ppc64 requires /bin/sh jakarta-commons-collections-tomcat5-3.2-2jpp.2.fc9.ppc64 requires /bin/sh 1:jakarta-commons-daemon-1.0.1-6jpp.5.fc9.ppc64 requires /bin/sh 1:jakarta-commons-daemon-javadoc-1.0.1-6jpp.5.fc9.ppc64 requires /bin/rm 1:jakarta-commons-daemon-javadoc-1.0.1-6jpp.5.fc9.ppc64 requires /bin/ln jakarta-commons-dbcp-1.2.1-11jpp.3.fc9.ppc64 requires /bin/sh jakarta-commons-dbcp-1.2.1-11jpp.3.fc9.ppc64 requires /usr/sbin/update-alternatives jakarta-commons-dbcp-javadoc-1.2.1-11jpp.3.fc9.ppc64 requires /bin/rm jakarta-commons-dbcp-javadoc-1.2.1-11jpp.3.fc9.ppc64 requires /bin/ln jakarta-commons-dbcp-tomcat5-1.2.1-11jpp.3.fc9.ppc64 requires /bin/sh jakarta-commons-digester-1.7-7jpp.2.ppc64 requires /bin/sh jakarta-commons-digester-javadoc-1.7-7jpp.2.ppc64 requires /bin/sh jakarta-commons-digester-javadoc-1.7-7jpp.2.ppc64 requires /bin/rm jakarta-commons-digester-javadoc-1.7-7jpp.2.ppc64 requires /bin/ln 1:jakarta-commons-discovery-0.4-3jpp.1.fc9.ppc64 requires /bin/sh 1:jakarta-commons-discovery-javadoc-0.4-3jpp.1.fc9.ppc64 requires /bin/rm 1:jakarta-commons-discovery-javadoc-0.4-3jpp.1.fc9.ppc64 requires /bin/ln jakarta-commons-el-1.0-9jpp.2.fc9.ppc64 requires /bin/sh jakarta-commons-el-javadoc-1.0-9jpp.2.fc9.ppc64 requires /bin/sh jakarta-commons-el-javadoc-1.0-9jpp.2.fc9.ppc64 requires /bin/ln jakarta-commons-el-javadoc-1.0-9jpp.2.fc9.ppc64 requires /bin/rm 1:jakarta-commons-fileupload-1.0-7jpp.2.fc9.ppc64 requires /bin/sh 1:jakarta-commons-httpclient-3.1-0jpp.1.fc9.ppc64 requires /bin/sh 1:jakarta-commons-httpclient-javadoc-3.1-0jpp.1.fc9.ppc64 requires /bin/rm 1:jakarta-commons-httpclient-javadoc-3.1-0jpp.1.fc9.ppc64 requires /bin/ln jakarta-commons-io-1.3.2-1jpp.1.fc9.noarch requires /bin/sh jakarta-commons-lang-2.3-2jpp.1.fc9.ppc64 requires /bin/sh jakarta-commons-launcher-1.1-2jpp.3.fc9.ppc64 requires /bin/sh jakarta-commons-launcher-javadoc-1.1-2jpp.3.fc9.ppc64 requires /bin/sh jakarta-commons-launcher-javadoc-1.1-2jpp.3.fc9.ppc64 requires /bin/rm jakarta-commons-launcher-javadoc-1.1-2jpp.3.fc9.ppc64 requires /bin/ln jakarta-commons-logging-1.0.4-7jpp.5.fc9.ppc64 requires /bin/sh jakarta-commons-logging-javadoc-1.0.4-7jpp.5.fc9.ppc64 requires /bin/sh jakarta-commons-logging-javadoc-1.0.4-7jpp.5.fc9.ppc64 requires /bin/rm jakarta-commons-logging-javadoc-1.0.4-7jpp.5.fc9.ppc64 requires /bin/ln jakarta-commons-modeler-2.0-4jpp.2.fc9.ppc64 requires /bin/sh jakarta-commons-net-1.4.1-4jpp.1.fc9.noarch requires /bin/sh jakarta-commons-pool-1.3-10jpp.3.fc9.ppc64 requires /bin/sh jakarta-commons-pool-tomcat5-1.3-10jpp.3.fc9.ppc64 requires /bin/sh jakarta-commons-validator-1.1.4-6jpp.2.fc9.ppc64 requires /bin/sh jakarta-commons-validator-javadoc-1.1.4-6jpp.2.fc9.ppc64 requires /bin/sh jakarta-commons-validator-javadoc-1.1.4-6jpp.2.fc9.ppc64 requires /bin/rm jakarta-commons-validator-javadoc-1.1.4-6jpp.2.fc9.ppc64 requires /bin/ln jakarta-oro-2.0.8-4jpp.1.ppc64 requires /bin/sh jakarta-oro-javadoc-2.0.8-4jpp.1.ppc64 requires /bin/sh jakarta-oro-javadoc-2.0.8-4jpp.1.ppc64 requires /bin/ln jakarta-oro-javadoc-2.0.8-4jpp.1.ppc64 requires /bin/rm jakarta-taglibs-standard-1.1.1-9jpp.1.fc9.ppc64 requires /bin/sh jasper-libs-1.900.1-8.fc9.ppc64 requires /sbin/ldconfig java-1.5.0-gcj-1.5.0.0-21.fc9.ppc64 requires /bin/sh java-1.5.0-gcj-1.5.0.0-21.fc9.ppc64 requires /usr/bin/gcj-dbtool java-1.5.0-gcj-1.5.0.0-21.fc9.ppc64 requires /usr/bin/gij java-1.5.0-gcj-1.5.0.0-21.fc9.ppc64 requires /usr/sbin/alternatives java-1.5.0-gcj-1.5.0.0-21.fc9.ppc64 requires /usr/sbin/alternatives java-1.5.0-gcj-1.5.0.0-21.fc9.ppc64 requires /bin/bash java-1.5.0-gcj-1.5.0.0-21.fc9.ppc64 requires /usr/bin/rebuild-gcj-db java-1.5.0-gcj-1.5.0.0-21.fc9.ppc64 requires /bin/sh java-1.5.0-gcj-1.5.0.0-21.fc9.ppc64 requires /usr/lib64/security/classpath.security java-1.5.0-gcj-1.5.0.0-21.fc9.ppc64 requires /usr/bin/gij java-1.5.0-gcj-devel-1.5.0.0-21.fc9.ppc64 requires /bin/sh java-1.5.0-gcj-devel-1.5.0.0-21.fc9.ppc64 requires /usr/bin/gij java-1.5.0-gcj-devel-1.5.0.0-21.fc9.ppc64 requires /usr/bin/gcj java-1.5.0-gcj-devel-1.5.0.0-21.fc9.ppc64 requires /usr/sbin/alternatives java-1.5.0-gcj-devel-1.5.0.0-21.fc9.ppc64 requires /usr/bin/env java-1.5.0-gcj-devel-1.5.0.0-21.fc9.ppc64 requires /bin/sh java-1.5.0-gcj-devel-1.5.0.0-21.fc9.ppc64 requires /usr/bin/gcj java-1.5.0-gcj-src-1.5.0.0-21.fc9.ppc64 requires /usr/bin/gij java-1.5.0-gcj-src-1.5.0.0-21.fc9.ppc64 requires /bin/sh java-1.5.0-gcj-src-1.5.0.0-21.fc9.ppc64 requires /usr/bin/gij 1:java-1.6.0-openjdk-1.6.0.0-0.12.b09.fc9.ppc64 requires /bin/sh 1:java-1.6.0-openjdk-1.6.0.0-0.12.b09.fc9.ppc64 requires /usr/bin/update-desktop-database 1:java-1.6.0-openjdk-1.6.0.0-0.12.b09.fc9.ppc64 requires /usr/sbin/alternatives 1:java-1.6.0-openjdk-demo-1.6.0.0-0.12.b09.fc9.ppc64 requires /bin/sh 1:java-1.6.0-openjdk-devel-1.6.0.0-0.12.b09.fc9.ppc64 requires /bin/sh 1:java-1.6.0-openjdk-devel-1.6.0.0-0.12.b09.fc9.ppc64 requires /usr/sbin/alternatives 1:java-1.6.0-openjdk-devel-1.6.0.0-0.12.b09.fc9.ppc64 requires /bin/sh 1:java-1.6.0-openjdk-javadoc-1.6.0.0-0.12.b09.fc9.ppc64 requires /usr/sbin/alternatives 1:java-1.6.0-openjdk-javadoc-1.6.0.0-0.12.b09.fc9.ppc64 requires /bin/sh 1:java-1.6.0-openjdk-plugin-1.6.0.0-0.12.b09.fc9.ppc64 requires /bin/sh 1:java-1.6.0-openjdk-plugin-1.6.0.0-0.12.b09.fc9.ppc64 requires /usr/lib64/mozilla/plugins 1:java-1.6.0-openjdk-plugin-1.6.0.0-0.12.b09.fc9.ppc64 requires /usr/sbin/alternatives 1:java_cup-0.10-0.k.6jpp.2.ppc64 requires /bin/sh 1:java_cup-javadoc-0.10-0.k.6jpp.2.ppc64 requires /bin/sh 1:java_cup-javadoc-0.10-0.k.6jpp.2.ppc64 requires /bin/rm 1:java_cup-javadoc-0.10-0.k.6jpp.2.ppc64 requires /bin/ln javacc-4.0-4jpp.4.ppc64 requires /bin/sh javacc-4.0-4jpp.4.ppc64 requires /bin/sh jcommon-1.0.12-4.fc10.ppc64 requires /bin/sh jcommon-serializer-0.2.0-3.fc10.ppc64 requires /bin/sh jcommon-xml-1.0.12-4.fc10.ppc64 requires /bin/sh jd-2.0.0-0.4.svn2053_trunk.fc10.ppc64 requires /bin/sh jday-2.4-3.fc9.ppc64 requires /sbin/ldconfig jdepend-2.6-7jpp.3.ppc64 requires /bin/sh jdepend-javadoc-2.6-7jpp.3.ppc64 requires /bin/sh jdepend-javadoc-2.6-7jpp.3.ppc64 requires /bin/rm jdepend-javadoc-2.6-7jpp.3.ppc64 requires /bin/ln jdom-1.0-5jpp.2.fc9.ppc64 requires /bin/sh jdom-javadoc-1.0-5jpp.2.fc9.ppc64 requires /bin/sh jdom-javadoc-1.0-5jpp.2.fc9.ppc64 requires /bin/rm jdom-javadoc-1.0-5jpp.2.fc9.ppc64 requires /bin/ln jetty-5.1.12-1jpp.9.fc8.ppc64 requires /bin/sh jetty-5.1.12-1jpp.9.fc8.ppc64 requires /sbin/chkconfig jetty-5.1.12-1jpp.9.fc8.ppc64 requires /bin/sh jgroups-2.2.9.2-3jpp.2.ppc64 requires /bin/sh jgroups-javadoc-2.2.9.2-3jpp.2.ppc64 requires /bin/sh jgroups-javadoc-2.2.9.2-3jpp.2.ppc64 requires /bin/rm jgroups-javadoc-2.2.9.2-3jpp.2.ppc64 requires /bin/ln jigdo-0.7.3-6.fc9.ppc64 requires /bin/sh jlex-1.2.6-6jpp.1.ppc64 requires /bin/sh jlex-javadoc-1.2.6-6jpp.1.ppc64 requires /bin/sh jlex-javadoc-1.2.6-6jpp.1.ppc64 requires /bin/rm jlex-javadoc-1.2.6-6jpp.1.ppc64 requires /bin/ln jline-0.9.94-0jpp.1.fc9.noarch requires /bin/sh jline-0.9.94-0jpp.1.fc9.noarch requires /bin/stty john-1.7.0.2-6.fc9.ppc64 requires /bin/sh jokosher-1.0-0.2.20080216svn.fc9.noarch requires /bin/sh jokosher-1.0-0.2.20080216svn.fc9.noarch requires /usr/bin/python jomolhari-fonts-0.003-5.fc10.noarch requires /bin/sh joni-1.0.2-4.fc9.ppc64 requires /bin/sh jpackage-utils-1.7.5-1jpp.1.fc9.noarch requires /bin/sh jpgalleg-2.5-3.fc9.ppc64 requires /sbin/ldconfig jpilot-0.99.9-6.fc9.ppc64 requires /sbin/ldconfig jrefactory-2.8.9-7jpp.4.fc9.ppc64 requires /bin/sh jrtplib-3.7.1-4.fc9.ppc64 requires /sbin/ldconfig jruby-1.1.1-5.fc10.noarch requires /bin/bash jruby-1.1.1-5.fc10.noarch requires /usr/bin/env js-1.70-2.fc9.ppc64 requires /sbin/ldconfig jsch-0.1.31-2jpp.3.fc9.ppc64 requires /bin/sh jsch-demo-0.1.31-2jpp.3.fc9.ppc64 requires /bin/sh jsch-demo-0.1.31-2jpp.3.fc9.ppc64 requires /bin/rm jsch-demo-0.1.31-2jpp.3.fc9.ppc64 requires /bin/ln jsch-javadoc-0.1.31-2jpp.3.fc9.ppc64 requires /bin/sh jsch-javadoc-0.1.31-2jpp.3.fc9.ppc64 requires /bin/rm jsch-javadoc-0.1.31-2jpp.3.fc9.ppc64 requires /bin/ln jthread-1.2.1-4.fc9.ppc64 requires /sbin/ldconfig 2:jtidy-1.0-0.2.r7dev.1jpp.2.fc9.ppc64 requires /bin/sh 2:jtidy-javadoc-1.0-0.2.r7dev.1jpp.2.fc9.ppc64 requires /bin/rm 2:jtidy-javadoc-1.0-0.2.r7dev.1jpp.2.fc9.ppc64 requires /bin/ln junit-3.8.2-4jpp.3.fc9.ppc64 requires /bin/sh jwhois-4.0-7.fc9.ppc64 requires /bin/sh jwhois-4.0-7.fc9.ppc64 requires /sbin/install-info jython-2.2.1-0.1.Release_2_2_1.1jpp.1.fc9.ppc64 requires /bin/sh jython-demo-2.2.1-0.1.Release_2_2_1.1jpp.1.fc9.ppc64 requires /bin/sh jzlib-1.0.7-5jpp.1.ppc64 requires /bin/sh jzlib-demo-1.0.7-5jpp.1.ppc64 requires /bin/sh jzlib-demo-1.0.7-5jpp.1.ppc64 requires /bin/rm jzlib-demo-1.0.7-5jpp.1.ppc64 requires /bin/ln jzlib-javadoc-1.0.7-5jpp.1.ppc64 requires /bin/sh jzlib-javadoc-1.0.7-5jpp.1.ppc64 requires /bin/rm jzlib-javadoc-1.0.7-5jpp.1.ppc64 requires /bin/ln k3b-1.0.4-9.fc10.ppc64 requires /bin/sh k3d-0.6.7.0-7.fc10.ppc64 requires /sbin/ldconfig k3d-0.6.7.0-7.fc10.ppc64 requires /bin/sh k3d-0.6.7.0-7.fc10.ppc64 requires /bin/bash k3d-0.6.7.0-7.fc10.ppc64 requires /bin/sh k3d-devel-0.6.7.0-7.fc10.ppc64 requires /bin/sh kacst-fonts-1.6.2-2.fc8.noarch requires /bin/sh kadu-0.6.0-3.fc9.ppc64 requires /bin/sh kadu-dcopexport-0.6.0-3.fc9.ppc64 requires /bin/sh kadu-devel-0.6.0-3.fc9.ppc64 requires /bin/sh kaffeine-0.8.6-4.fc9.ppc64 requires /bin/sh kaffeine-libs-0.8.6-4.fc9.ppc64 requires /sbin/ldconfig kakasi-2.3.4-26.fc9.ppc64 requires /sbin/ldconfig kakasi-2.3.4-26.fc9.ppc64 requires /bin/sh kannel-1.4.1-7.ppc64 requires /bin/sh kannel-1.4.1-7.ppc64 requires /bin/sh kannel-devel-1.4.1-7.ppc64 requires /bin/sh kanyremote-4.8-1.fc10.noarch requires /usr/bin/env kasablanca-0.4.0.2-12.fc9.ppc64 requires /bin/sh katapult-0.3.2.1-3.fc9.ppc64 requires /bin/sh 1:kawa-1.9.1-5.fc9.ppc64 requires /bin/sh 1:kawa-1.9.1-5.fc9.ppc64 requires /bin/sh kbackup-0.5.3-4.fc9.ppc64 requires /bin/sh kbanking-2.3.3-3.fc9.ppc64 requires /sbin/ldconfig kbanking-devel-2.3.3-3.fc9.ppc64 requires /bin/sh kbd-1.12-31.fc9.ppc64 requires /bin/bash kbd-1.12-31.fc9.ppc64 requires /bin/sh kbibtex-0.2.1-19.fc9.ppc64 requires /bin/sh kbilliards-0.8.7b-7.fc9.ppc64 requires /bin/sh kcbench-0.3-1.1.noarch requires /bin/bash kcbench-0.3-1.1.noarch requires /usr/bin/bc kcbench-0.3-1.1.noarch requires /usr/bin/time kcbench-data-2.6.25-0.1-3.noarch requires /usr/bin/perl kcbench-data-2.6.25-0.1-3.noarch requires /bin/bash kcbench-data-2.6.25-0.1-3.noarch requires /usr/bin/env kcbench-data-2.6.25-0.1-3.noarch requires /bin/sh kcbench-data-2.6.25-0.1-3.noarch requires /usr/bin/python kcemirror-0.1.5-4.fc9.ppc64 requires /bin/sh kchmviewer-4.0-0.2.beta2.fc9.ppc64 requires /bin/sh kcoloredit-4.0.3-2.fc9.ppc64 requires /bin/sh 1:kdbg-2.1.0-2.fc9.ppc64 requires /bin/sh kde-settings-4.0-22.fc9.1.noarch requires /bin/sh kde-settings-4.0-22.fc9.1.noarch requires /bin/sh kde-settings-kdm-4.0-22.fc9.1.noarch requires /bin/sh kde-settings-kdm-4.0-22.fc9.1.noarch requires /bin/sh 1:kdeaccessibility-4.0.72-1.fc10.ppc64 requires /bin/sh 1:kdeaccessibility-4.0.72-1.fc10.ppc64 requires /sbin/ldconfig kdeaddons-atlantikdesigner-3.5.9-1.fc9.ppc64 requires /bin/sh 7:kdeadmin-4.0.72-1.fc10.ppc64 requires /bin/sh 7:kdeadmin-4.0.72-1.fc10.ppc64 requires /usr/bin/env 7:kdeadmin-4.0.72-1.fc10.ppc64 requires /sbin/ldconfig 7:kdeadmin-kpackage-4.0.72-1.fc10.ppc64 requires /bin/sh kdeartwork-icons-4.0.72-1.fc10.ppc64 requires /bin/sh 6:kdebase-4.0.72-2.fc10.ppc64 requires /bin/sh 6:kdebase-4.0.72-2.fc10.ppc64 requires /bin/sh 6:kdebase-libs-4.0.72-2.fc10.ppc64 requires /sbin/ldconfig kdebase-runtime-4.0.72-2.fc10.ppc64 requires /sbin/ldconfig kdebase-runtime-4.0.72-2.fc10.ppc64 requires /usr/bin/perl kdebase-runtime-4.0.72-2.fc10.ppc64 requires /bin/sh kdebase-runtime-4.0.72-2.fc10.ppc64 requires /bin/sh kdebase-workspace-4.0.72-3.fc10.ppc64 requires /usr/bin/perl kdebase-workspace-4.0.72-3.fc10.ppc64 requires /bin/sh kdebase-workspace-4.0.72-3.fc10.ppc64 requires /bin/sh kdebase-workspace-libs-4.0.72-3.fc10.ppc64 requires /sbin/ldconfig kdebase3-3.5.9-10.fc9.ppc64 requires /usr/bin/perl kdebase3-3.5.9-10.fc9.ppc64 requires /bin/sh kdebase3-3.5.9-10.fc9.ppc64 requires /bin/sh kdebase3-libs-3.5.9-10.fc9.ppc64 requires /sbin/ldconfig kdebindings-4.0.72-1.fc10.ppc64 requires /sbin/ldconfig kdebindings-4.0.72-1.fc10.ppc64 requires /bin/sh kdebindings-4.0.72-1.fc10.ppc64 requires /usr/bin/env kdebluetooth-1.0-0.41.beta8.fc9.ppc64 requires /bin/sh kdebluetooth-1.0-0.41.beta8.fc9.ppc64 requires /bin/bash kdebluetooth-1.0-0.41.beta8.fc9.ppc64 requires /bin/sh kdebluetooth-1.0-0.41.beta8.fc9.ppc64 requires /usr/bin/kdesu kdeedu-4.0.72-2.fc10.ppc64 requires /bin/sh kdeedu-4.0.72-2.fc10.ppc64 requires /usr/bin/env kdeedu-kstars-4.0.72-2.fc10.ppc64 requires /bin/sh kdeedu-libs-4.0.72-2.fc10.ppc64 requires /sbin/ldconfig 6:kdegames-4.0.72-2.fc10.ppc64 requires /bin/sh 6:kdegames-libs-4.0.72-2.fc10.ppc64 requires /sbin/ldconfig kdegames3-3.5.9-1.fc9.ppc64 requires /bin/sh kdegames3-libs-3.5.9-1.fc9.ppc64 requires /sbin/ldconfig 7:kdegraphics-4.0.72-2.fc10.ppc64 requires /bin/sh 7:kdegraphics-libs-4.0.72-2.fc10.ppc64 requires /sbin/ldconfig 6:kdelibs-4.0.72-4.fc10.ppc64 requires /sbin/ldconfig 6:kdelibs-4.0.72-4.fc10.ppc64 requires /usr/bin/perl 6:kdelibs-4.0.72-4.fc10.ppc64 requires /bin/sh 6:kdelibs-4.0.72-4.fc10.ppc64 requires /bin/sh 6:kdelibs-devel-4.0.72-4.fc10.ppc64 requires /bin/sh kdelibs3-3.5.9-10.fc10.ppc64 requires /sbin/ldconfig kdelibs3-3.5.9-10.fc10.ppc64 requires /usr/bin/perl kdelibs3-3.5.9-10.fc10.ppc64 requires /bin/sh kdelibs3-3.5.9-10.fc10.ppc64 requires /bin/sh kdelibs3-devel-3.5.9-10.fc10.ppc64 requires /bin/sh 6:kdemultimedia-4.0.72-1.fc10.ppc64 requires /bin/sh 6:kdemultimedia-4.0.72-1.fc10.ppc64 requires /usr/bin/env 6:kdemultimedia-4.0.72-1.fc10.ppc64 requires /usr/bin/perl 6:kdemultimedia-libs-4.0.72-1.fc10.ppc64 requires /sbin/ldconfig 7:kdenetwork-4.0.72-2.fc10.ppc64 requires /usr/bin/perl 7:kdenetwork-4.0.72-2.fc10.ppc64 requires /bin/sh 7:kdenetwork-4.0.72-2.fc10.ppc64 requires /bin/sh 7:kdenetwork-libs-4.0.72-2.fc10.ppc64 requires /sbin/ldconfig 6:kdepim-3.5.9-9.fc9.ppc64 requires /sbin/ldconfig 6:kdepim-3.5.9-9.fc9.ppc64 requires /usr/bin/perl 6:kdepim-3.5.9-9.fc9.ppc64 requires /bin/sh 6:kdepim-3.5.9-9.fc9.ppc64 requires /usr/bin/env 6:kdepim-3.5.9-9.fc9.ppc64 requires /bin/sh 6:kdepim-libs-3.5.9-9.fc9.ppc64 requires /sbin/ldconfig kdepimlibs-4.0.72-2.fc10.ppc64 requires /sbin/ldconfig kdepimlibs-4.0.72-2.fc10.ppc64 requires /usr/bin/perl kdesdk-4.0.72-1.fc10.ppc64 requires /usr/bin/perl kdesdk-4.0.72-1.fc10.ppc64 requires /bin/sh kdesdk-4.0.72-1.fc10.ppc64 requires /usr/bin/env kdesdk-4.0.72-1.fc10.ppc64 requires /bin/bash kdesdk-4.0.72-1.fc10.ppc64 requires /bin/sh kdesdk-libs-4.0.72-1.fc10.ppc64 requires /sbin/ldconfig kdesvn-0.14.3-1.fc10.ppc64 requires /bin/sh kdesvn-0.14.3-1.fc10.ppc64 requires /bin/sh 7:kdetoys-4.0.72-1.fc10.ppc64 requires /bin/sh 7:kdetoys-4.0.72-1.fc10.ppc64 requires /sbin/ldconfig kdetv-0.8.9-10.fc9.ppc64 requires /bin/sh 6:kdeutils-4.0.72-1.fc10.ppc64 requires /bin/sh 6:kdeutils-4.0.72-1.fc10.ppc64 requires /sbin/ldconfig 9:kdevelop-3.5.1-4.fc9.ppc64 requires /bin/sh 9:kdevelop-3.5.1-4.fc9.ppc64 requires /usr/bin/perl 9:kdevelop-libs-3.5.1-4.fc9.ppc64 requires /sbin/ldconfig 6:kdewebdev-3.5.9-3.fc9.ppc64 requires /bin/sh 6:kdewebdev-3.5.9-3.fc9.ppc64 requires /bin/sh 6:kdewebdev-3.5.9-3.fc9.ppc64 requires /usr/bin/perl 6:kdewebdev-libs-3.5.9-3.fc9.ppc64 requires /sbin/ldconfig kdiff3-0.9.92-13.fc9.ppc64 requires /bin/sh kdirstat-2.5.3-8.fc9.ppc64 requires /bin/sh kdirstat-2.5.3-8.fc9.ppc64 requires /usr/bin/perl kdissert-1.0.7-4.fc9.ppc64 requires /bin/sh kdnssd-avahi-0.1.3-0.6.20080116svn.fc9.ppc64 requires /sbin/ldconfig keepalived-1.1.15-5.fc10.ppc64 requires /bin/sh keepalived-1.1.15-5.fc10.ppc64 requires /sbin/chkconfig keepalived-1.1.15-5.fc10.ppc64 requires /bin/sh keepalived-1.1.15-5.fc10.ppc64 requires /sbin/service keepassx-0.3.1-1.fc9.ppc64 requires /bin/sh kernel-2.6.25.2-5.fc10.ppc64 requires /bin/sh kernel-2.6.25.2-5.fc10.ppc64 requires /bin/sh kernel-bootwrapper-2.6.25.2-5.fc10.ppc64 requires /bin/sh kernel-devel-2.6.25.2-5.fc10.ppc64 requires /usr/bin/find kernel-devel-2.6.25.2-5.fc10.ppc64 requires /bin/sh kernel-kdump-devel-2.6.25.2-5.fc10.ppc64 requires /usr/bin/find kerneloops-0.10-11.fc9.ppc64 requires /bin/sh kerneloops-0.10-11.fc9.ppc64 requires /bin/bash ketchup-0.9.8-1.fc8.noarch requires /usr/bin/python keurocalc-1.0.0-2.rc2.fc9.ppc64 requires /bin/sh kexec-tools-1.102pre-10.fc10.ppc64 requires /bin/sh kexec-tools-1.102pre-10.fc10.ppc64 requires /usr/bin/perl kexec-tools-1.102pre-10.fc10.ppc64 requires /bin/bash kexec-tools-1.102pre-10.fc10.ppc64 requires /bin/sh keychain-2.6.8-3.fc9.noarch requires /bin/sh keyjnote-0.10.2-1.fc9.noarch requires /usr/bin/env keyutils-1.2-3.fc9.ppc64 requires /bin/sh keyutils-libs-1.2-3.fc9.ppc64 requires /sbin/ldconfig kflickr-0.9.1-2.fc9.ppc64 requires /bin/sh kftpgrabber-0.8.1-6.fc9.ppc64 requires /bin/sh kftpgrabber-0.8.1-6.fc9.ppc64 requires /sbin/ldconfig kgrab-0.1.1-6.fc9.ppc64 requires /bin/sh kgtk-0.9.4-3.fc9.ppc64 requires /bin/bash kicad-2007.07.09-3.fc9.ppc64 requires /bin/sh kiconedit-4.0.3-2.fc9.ppc64 requires /bin/sh kid3-1.0-1.fc9.ppc64 requires /bin/sh kile-2.0.1-1.fc10.ppc64 requires /bin/sh kile-2.0.1-1.fc10.ppc64 requires /usr/bin/perl kinput2-v3.1-38.fc9.ppc64 requires /bin/sh kinput2-v3.1-38.fc9.ppc64 requires /usr/sbin/alternatives kinput2-v3.1-38.fc9.ppc64 requires /usr/sbin/alternatives kinput2-v3.1-38.fc9.ppc64 requires /bin/sh kio_sword-0.3-6.fc9.ppc64 requires /bin/sh kiosktool-1.0-10.fc9.ppc64 requires /bin/sh kipi-plugins-0.1.5-2.fc10.ppc64 requires /sbin/ldconfig kipi-plugins-0.1.5-2.fc10.ppc64 requires /bin/bash kismet-0.0.2007.10.R1-3.fc9.ppc64 requires /bin/sh kismet-0.0.2007.10.R1-3.fc9.ppc64 requires /etc/cron.daily kismet-0.0.2007.10.R1-3.fc9.ppc64 requires /bin/sh kismet-extras-0.0.2007.10.R1-3.fc9.ppc64 requires libMagick.so.10()(64bit) kismet-extras-0.0.2007.10.R1-3.fc9.ppc64 requires /usr/bin/perl kita-0.177.3-12.fc9.2.ppc64 requires /bin/sh kita-0.177.3-12.fc9.2.ppc64 requires /sbin/ldconfig kitsune-2.0-4.fc9.ppc64 requires /bin/sh klamav-0.42-3.fc9.ppc64 requires /bin/sh kleansweep-0.2.9-7.fc9.ppc64 requires /bin/sh kleansweep-0.2.9-7.fc9.ppc64 requires /usr/bin/env klear-0.7.0-1.svn113.fc9.ppc64 requires /bin/sh kmenu-gnome-0.7.1-1.fc9.noarch requires /bin/sh kmid-2.0-0.6.20080213svn.fc9.ppc64 requires /sbin/ldconfig kmid-2.0-0.6.20080213svn.fc9.ppc64 requires /bin/sh kmobiletools-0.4.3.3-4.fc9.ppc64 requires /bin/sh kmplayer-0.10.0c-4.fc9.ppc64 requires /bin/sh kmymoney2-0.9-1.fc10.ppc64 requires /bin/sh kmymoney2-libs-0.9-1.fc10.ppc64 requires /sbin/ldconfig knetstats-1.6.1-8.fc9.ppc64 requires /bin/sh kodos-2.4.9-4.fc8.noarch requires /usr/bin/env kodos-2.4.9-4.fc8.noarch requires /usr/bin/python koffice-core-1.6.3-15.fc9.ppc64 requires /bin/sh koffice-filters-1.6.3-15.fc9.ppc64 requires /sbin/ldconfig koffice-karbon-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) koffice-kchart-1.6.3-15.fc9.ppc64 requires /sbin/ldconfig koffice-kexi-1.6.3-15.fc9.ppc64 requires /sbin/ldconfig koffice-kexi-1.6.3-15.fc9.ppc64 requires /bin/sh koffice-kpresenter-1.6.3-15.fc9.ppc64 requires /sbin/ldconfig koffice-kpresenter-1.6.3-15.fc9.ppc64 requires /usr/bin/perl koffice-kugar-1.6.3-15.fc9.ppc64 requires /sbin/ldconfig koffice-kword-1.6.3-15.fc9.ppc64 requires /sbin/ldconfig koffice-libs-1.6.3-15.fc9.ppc64 requires /sbin/ldconfig koffice-libs-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) koji-1.2.3-1.fc9.noarch requires /usr/bin/python koji-builder-1.2.3-1.fc9.noarch requires /bin/sh koji-builder-1.2.3-1.fc9.noarch requires /usr/bin/git koji-builder-1.2.3-1.fc9.noarch requires /sbin/chkconfig koji-builder-1.2.3-1.fc9.noarch requires /usr/bin/svn koji-builder-1.2.3-1.fc9.noarch requires /usr/sbin/useradd koji-builder-1.2.3-1.fc9.noarch requires /usr/bin/cvs koji-builder-1.2.3-1.fc9.noarch requires /bin/sh koji-builder-1.2.3-1.fc9.noarch requires /usr/bin/python koji-builder-1.2.3-1.fc9.noarch requires /sbin/service koji-utils-1.2.3-1.fc9.noarch requires /bin/sh koji-utils-1.2.3-1.fc9.noarch requires /bin/sh koji-utils-1.2.3-1.fc9.noarch requires /usr/bin/python komparator-0.9-1.fc9.ppc64 requires /bin/sh konq-plugins-4.0.3-0.3.20080409svn.fc9.ppc64 requires /bin/sh konq-plugins-4.0.3-0.3.20080409svn.fc9.ppc64 requires /usr/bin/env konversation-1.0.1-6.fc9.ppc64 requires /bin/sh konversation-1.0.1-6.fc9.ppc64 requires /usr/bin/env konversation-1.0.1-6.fc9.ppc64 requires /bin/bash konversation-1.0.1-6.fc9.ppc64 requires /bin/sh konversation-1.0.1-6.fc9.ppc64 requires /usr/bin/perl kooldock-0.4.6-4.fc9.ppc64 requires /bin/sh kover-3-3.ppc64 requires /bin/sh koverartist-0.5-11.fc9.ppc64 requires /bin/sh kpathsea-2007-31.fc10.ppc64 requires /bin/sh kpathsea-2007-31.fc10.ppc64 requires /sbin/restorecon kphotoalbum-3.1.1-2.fc10.ppc64 requires /bin/sh kphotobymail-0.4.1-1.fc7.noarch requires /usr/bin/env kpolynome-0.1.2-12.fc9.ppc64 requires /bin/sh kpowersave-0.7.3-3.fc9.ppc64 requires /bin/sh krb5-devel-1.6.3-10.fc9.ppc64 requires /bin/sh krb5-libs-1.6.3-10.fc9.ppc64 requires /sbin/ldconfig krb5-server-1.6.3-10.fc9.ppc64 requires /bin/sh krb5-server-1.6.3-10.fc9.ppc64 requires /sbin/install-info krb5-server-1.6.3-10.fc9.ppc64 requires /bin/bash krb5-server-1.6.3-10.fc9.ppc64 requires /bin/sh krb5-server-1.6.3-10.fc9.ppc64 requires /sbin/chkconfig krb5-workstation-1.6.3-10.fc9.ppc64 requires /bin/sh krb5-workstation-1.6.3-10.fc9.ppc64 requires /sbin/install-info krb5-workstation-1.6.3-10.fc9.ppc64 requires /bin/sh krb5-workstation-clients-1.6.3-10.fc9.ppc64 requires /bin/sh krb5-workstation-clients-1.6.3-10.fc9.ppc64 requires /sbin/install-info krb5-workstation-clients-1.6.3-10.fc9.ppc64 requires /bin/sh krb5-workstation-servers-1.6.3-10.fc9.ppc64 requires /bin/sh krb5-workstation-servers-1.6.3-10.fc9.ppc64 requires /etc/pam.d/remote krb5-workstation-servers-1.6.3-10.fc9.ppc64 requires /sbin/install-info krb5-workstation-servers-1.6.3-10.fc9.ppc64 requires /bin/bash krb5-workstation-servers-1.6.3-10.fc9.ppc64 requires /bin/sh krecipes-0.9.1-9.fc9.ppc64 requires /bin/sh kreetingkard-0.7.1-2.fc9.2.ppc64 requires /bin/sh krename-3.0.14-4.fc9.ppc64 requires /bin/sh krusader-1.80.0-5.fc9.ppc64 requires /bin/sh kscope-1.6.1-4.fc9.ppc64 requires /bin/sh ksensors-0.7.3-16.fc9.ppc64 requires /bin/sh ksh-20080202-1.fc9.ppc64 requires /bin/sh ksh-20080202-1.fc9.ppc64 requires /bin/sh kshutdown-1.0.1-2.fc9.ppc64 requires /bin/sh ksig-1.1-0.5.20080213.fc9.ppc64 requires /bin/sh ksirk-1.7-6.fc9.ppc64 requires /bin/sh ksirk-1.7-6.fc9.ppc64 requires /bin/bash ksmarttray-0.52-54.fc9.ppc64 requires /usr/bin/kdesu kst-1.6.0-2.fc10.ppc64 requires /sbin/ldconfig ksynaptics-0.3.3-5.fc9.ppc64 requires /bin/sh ktechlab-0.3.69-5.fc8.ppc64 requires /bin/sh ktorrent-3.0.2-3.fc10.ppc64 requires /bin/sh kudzu-1.2.85-1.ppc64 requires /sbin/chkconfig kudzu-1.2.85-1.ppc64 requires /bin/sh labyrinth-0.4.0-1.fc10.noarch requires /bin/sh labyrinth-0.4.0-1.fc10.noarch requires /usr/bin/env lacewing-1.10-10.fc9.ppc64 requires /bin/sh lagan-2.0-2.fc9.ppc64 requires /usr/bin/env lagan-2.0-2.fc9.ppc64 requires /usr/bin/perl 2:lam-7.1.2-11.fc9.ppc64 requires /bin/sh 2:lam-7.1.2-11.fc9.ppc64 requires /usr/bin/env 2:lam-7.1.2-11.fc9.ppc64 requires /sbin/ldconfig 2:lam-7.1.2-11.fc9.ppc64 requires /usr/sbin/alternatives 2:lam-7.1.2-11.fc9.ppc64 requires /bin/sh 2:lam-devel-7.1.2-11.fc9.ppc64 requires /bin/sh 2:lam-devel-7.1.2-11.fc9.ppc64 requires /sbin/ldconfig 2:lam-devel-7.1.2-11.fc9.ppc64 requires /usr/sbin/alternatives 2:lam-libs-7.1.2-11.fc9.ppc64 requires /bin/sh 2:lam-libs-7.1.2-11.fc9.ppc64 requires /sbin/ldconfig 2:lam-libs-7.1.2-11.fc9.ppc64 requires /usr/sbin/alternatives lapack-3.1.1-3.fc9.ppc64 requires /sbin/ldconfig lash-0.5.4-2.fc9.ppc64 requires /bin/sh lash-0.5.4-2.fc9.ppc64 requires /sbin/install-info lasi-1.1.0-1.fc9.ppc64 requires /sbin/ldconfig latex-mk-1.8-2.fc7.noarch requires /bin/sh latex-mk-1.8-2.fc7.noarch requires /sbin/install-info latex-mk-1.8-2.fc7.noarch requires /bin/sh latex2html-2002.2.1-8.fc9.noarch requires /bin/sh latex2html-2002.2.1-8.fc9.noarch requires /usr/bin/perl latexmk-3.20-1.fc8.noarch requires /usr/bin/perl lbrickbuster2-2.6-0.9.beta7.fc8.ppc64 requires /bin/sh lcdproc-0.5.2-4.fc9.ppc64 requires /bin/sh lcdproc-0.5.2-4.fc9.ppc64 requires /usr/bin/perl lcdproc-0.5.2-4.fc9.ppc64 requires /bin/sh lcdproc-0.5.2-4.fc9.ppc64 requires /sbin/chkconfig lcms-libs-1.17-4.fc9.ppc64 requires /sbin/ldconfig lcov-1.4-2.fc6.noarch requires /usr/bin/perl lcov-1.4-2.fc6.noarch requires /usr/bin/gcov ldapjdk-4.18-1.fc9.ppc64 requires /bin/sh ldirectord-2.1.3-1.fc9.ppc64 requires /bin/sh ldirectord-2.1.3-1.fc9.ppc64 requires /sbin/ldconfig ldirectord-2.1.3-1.fc9.ppc64 requires /usr/bin/perl ldirectord-2.1.3-1.fc9.ppc64 requires /bin/sh ldirectord-2.1.3-1.fc9.ppc64 requires /sbin/chkconfig ldm-2.0.4-1.fc9.ppc64 requires /bin/sh ldns-1.2.2-3.fc9.ppc64 requires /sbin/ldconfig leafnode-1.11.6-3.fc9.ppc64 requires /bin/sh leafpad-0.8.13-1.fc9.ppc64 requires /bin/sh less-418-3.fc9.ppc64 requires /bin/sh lesstif-0.95.0-23.fc9.ppc64 requires /sbin/ldconfig lesstif-clients-0.95.0-23.fc9.ppc64 requires /bin/sh lesstif-devel-0.95.0-23.fc9.ppc64 requires /bin/sh lftp-3.7.1-1.fc10.ppc64 requires /sbin/ldconfig lftp-3.7.1-1.fc10.ppc64 requires /usr/bin/perl lftp-3.7.1-1.fc10.ppc64 requires /bin/sh lib3ds-1.3.0-2.fc9.ppc64 requires /sbin/ldconfig lib3ds-devel-1.3.0-2.fc9.ppc64 requires /bin/sh lib765-0.4.1-3.fc9.ppc64 requires /sbin/ldconfig libAfterImage-1.15-4.fc9.ppc64 requires /sbin/ldconfig libAfterImage-devel-1.15-4.fc9.ppc64 requires /bin/sh libEMF-1.0.3-7.fc9.ppc64 requires /sbin/ldconfig libFS-1.0.0-7.fc9.ppc64 requires /sbin/ldconfig libFoundation-1.1.3-11.fc9.ppc64 requires /sbin/ldconfig libHX-1.15-1.fc10.ppc64 requires /sbin/ldconfig libICE-1.0.4-3.fc9.ppc64 requires /sbin/ldconfig libIDL-0.8.10-2.fc9.ppc64 requires /sbin/ldconfig libIDL-devel-0.8.10-2.fc9.ppc64 requires /bin/sh libIDL-devel-0.8.10-2.fc9.ppc64 requires /sbin/install-info libIDL-devel-0.8.10-2.fc9.ppc64 requires /bin/sh libRmath-2.7.0-2.fc10.ppc64 requires /bin/sh libSM-1.0.2-5.fc9.ppc64 requires /sbin/ldconfig libX11-1.1.4-1.fc9.ppc64 requires /sbin/ldconfig libXNVCtrl-169.12-1.fc9.ppc64 requires /sbin/ldconfig libXScrnSaver-1.1.2-4.fc9.ppc64 requires /sbin/ldconfig libXTrap-1.0.0-5.fc9.ppc64 requires /sbin/ldconfig libXau-1.0.3-5.fc9.ppc64 requires /sbin/ldconfig libXaw-1.0.4-2.fc9.ppc64 requires /sbin/ldconfig libXcomposite-0.4.0-4.fc9.ppc64 requires /sbin/ldconfig libXcursor-1.1.9-2.fc9.ppc64 requires /sbin/ldconfig libXdamage-1.1.1-4.fc9.ppc64 requires /sbin/ldconfig libXdmcp-1.0.2-5.fc9.ppc64 requires /sbin/ldconfig libXevie-1.0.2-3.fc9.ppc64 requires /sbin/ldconfig libXext-1.0.4-1.fc9.ppc64 requires /sbin/ldconfig libXfixes-4.0.3-3.fc9.ppc64 requires /sbin/ldconfig libXfont-1.3.1-4.fc9.ppc64 requires /sbin/ldconfig libXfontcache-1.0.4-5.fc9.ppc64 requires /sbin/ldconfig libXft-2.1.12-5.fc9.ppc64 requires /sbin/ldconfig libXi-1.1.3-4.fc9.ppc64 requires /sbin/ldconfig libXinerama-1.0.3-1.fc9.ppc64 requires /sbin/ldconfig libXmu-1.0.4-1.fc9.ppc64 requires /sbin/ldconfig libXp-1.0.0-11.fc9.ppc64 requires /sbin/ldconfig libXpm-3.5.7-4.fc9.ppc64 requires /sbin/ldconfig libXrandr-1.2.2-3.fc9.ppc64 requires /sbin/ldconfig libXrender-0.9.4-3.fc9.ppc64 requires /sbin/ldconfig libXres-1.0.3-4.fc9.ppc64 requires /sbin/ldconfig libXt-1.0.4-5.fc9.ppc64 requires /sbin/ldconfig libXtst-1.0.3-3.fc9.ppc64 requires /sbin/ldconfig libXv-1.0.3-5.fc9.ppc64 requires /sbin/ldconfig libXvMC-1.0.4-4.fc9.ppc64 requires /sbin/ldconfig libXxf86dga-1.0.2-2.fc9.ppc64 requires /sbin/ldconfig libXxf86misc-1.0.1-5.fc9.ppc64 requires /sbin/ldconfig libXxf86vm-1.0.1-5.fc9.ppc64 requires /sbin/ldconfig libacl-2.2.47-1.fc9.ppc64 requires /sbin/ldconfig libaio-0.3.106-4.2.ppc64 requires /sbin/ldconfig libannodex-0.7.3-10.fc9.ppc64 requires /bin/sh libannodex-0.7.3-10.fc9.ppc64 requires /sbin/ldconfig libao-0.8.8-4.fc9.ppc64 requires /sbin/ldconfig libao-devel-0.8.8-4.fc9.ppc64 requires /usr/lib64/libao.so.2 libapreq2-2.09-0.15.rc2.fc9.ppc64 requires /bin/sh libapreq2-2.09-0.15.rc2.fc9.ppc64 requires /sbin/ldconfig libapreq2-devel-2.09-0.15.rc2.fc9.ppc64 requires /bin/sh libarchive-2.4.17-1.fc9.ppc64 requires /sbin/ldconfig libart_lgpl-2.3.20-1.fc9.ppc64 requires /sbin/ldconfig libart_lgpl-devel-2.3.20-1.fc9.ppc64 requires /bin/sh libassa-3.5.0-2.ppc64 requires /sbin/ldconfig libassuan-devel-1.0.4-3.fc9.ppc64 requires /bin/sh libassuan-devel-1.0.4-3.fc9.ppc64 requires /sbin/install-info libassuan-devel-1.0.4-3.fc9.ppc64 requires /bin/sh libast-0.7.1-0.6.20080502cvs.fc10.ppc64 requires /sbin/ldconfig libast-devel-0.7.1-0.6.20080502cvs.fc10.ppc64 requires /bin/sh libattr-2.4.41-1.fc9.ppc64 requires /sbin/ldconfig libavc1394-0.5.3-2.fc9.ppc64 requires /sbin/ldconfig libax25-0.0.11-3.fc9.ppc64 requires /sbin/ldconfig libbeagle-0.3.5-1.fc9.ppc64 requires /sbin/ldconfig libbinio-1.4-9.fc9.ppc64 requires /sbin/ldconfig libbinio-devel-1.4-9.fc9.ppc64 requires /bin/sh libbinio-devel-1.4-9.fc9.ppc64 requires /sbin/install-info libbonobo-2.22.0-3.fc10.ppc64 requires /sbin/ldconfig libbonobo-2.22.0-3.fc10.ppc64 requires /usr/bin/perl libbonoboui-2.22.0-2.fc9.ppc64 requires /sbin/ldconfig libbtctl-0.10.0-2.fc9.ppc64 requires /sbin/ldconfig libburn-0.4.0-2.fc9.ppc64 requires /sbin/ldconfig libc-client-2007a1-3.fc9.ppc64 requires /sbin/ldconfig libcaca-0.99-0.4.beta11.fc9.ppc64 requires /sbin/ldconfig libcaca-devel-0.99-0.4.beta11.fc9.ppc64 requires /bin/sh libcap-2.06-4.fc9.ppc64 requires /sbin/ldconfig libcapseo-0.2.0-0.1.20080323git1c5f3e5.fc10.ppc64 requires /sbin/ldconfig libcdaudio-0.99.12p2-9.fc9.ppc64 requires /sbin/ldconfig libcdaudio-devel-0.99.12p2-9.fc9.ppc64 requires /bin/sh libcddb-1.3.0-4.fc9.ppc64 requires /sbin/ldconfig libcdio-0.79-3.fc9.ppc64 requires /sbin/install-info libcdio-0.79-3.fc9.ppc64 requires /sbin/ldconfig libcdio-0.79-3.fc9.ppc64 requires /bin/sh libcgi-1.0-8.fc9.ppc64 requires /sbin/ldconfig libchewing-0.3.0-11.fc10.ppc64 requires /sbin/ldconfig libchmxx-0.2-2.fc9.ppc64 requires /sbin/ldconfig libcmml-0.9.1-5.fc9.ppc64 requires /sbin/ldconfig libcmpiutil-0.3-1.fc9.ppc64 requires /sbin/ldconfig libconcord-0.20-5.fc10.ppc64 requires /sbin/ldconfig libconfig-1.2.1-2.fc9.ppc64 requires /sbin/ldconfig libconfig-devel-1.2.1-2.fc9.ppc64 requires /bin/sh libconfig-devel-1.2.1-2.fc9.ppc64 requires /sbin/install-info libconfuse-2.6-1.fc9.ppc64 requires /sbin/ldconfig libcroco-0.6.1-5.fc9.ppc64 requires /bin/sh libcroco-devel-0.6.1-5.fc9.ppc64 requires /bin/sh libctl-3.0.2-6.fc9.ppc64 requires /sbin/ldconfig libctl-devel-3.0.2-6.fc9.ppc64 requires /bin/sh libcurl-7.18.1-2.fc10.ppc64 requires /sbin/ldconfig libcurl-devel-7.18.1-2.fc10.ppc64 requires /bin/sh libdaemon-0.12-3.fc9.ppc64 requires /sbin/ldconfig libdap-3.7.10-2.fc9.ppc64 requires /sbin/ldconfig libdap-devel-3.7.10-2.fc9.ppc64 requires /bin/sh libdar-2.3.6-3.fc9.ppc64 requires /sbin/ldconfig libdbi-0.8.3-1.fc9.ppc64 requires /sbin/ldconfig libdbi-drivers-0.8.3-1.fc9.ppc64 requires /sbin/ldconfig libdc1394-2.0.2-1.fc10.ppc64 requires /sbin/ldconfig libdhcp-1.99.8-1.fc10.ppc64 requires /sbin/ldconfig 12:libdhcp4client-4.0.0-15.fc10.ppc64 requires /sbin/ldconfig libdhcp6client-1.0.15-1.fc10.ppc64 requires /sbin/ldconfig libdiscid-0.1.1-6.fc9.ppc64 requires /sbin/ldconfig libdmx-1.0.2-5.fc9.ppc64 requires /sbin/ldconfig libdnet-1.12-3.fc9.ppc64 requires /sbin/ldconfig libdnet-devel-1.12-3.fc9.ppc64 requires /bin/sh libdockapp-0.6.2-1.fc10.ppc64 requires /sbin/ldconfig libdockapp-fonts-0.6.2-1.fc10.ppc64 requires /bin/sh libdrm-2.4.0-0.11.fc9.ppc64 requires /sbin/ldconfig libdsk-1.2.1-1.fc9.ppc64 requires /sbin/ldconfig libdstr-20080124-1.fc9.ppc64 requires /sbin/ldconfig libdv-1.0.0-4.fc9.ppc64 requires /sbin/ldconfig libdvdnav-4.1.1-6.fc9.ppc64 requires /sbin/ldconfig libdvdnav-devel-4.1.1-6.fc9.ppc64 requires /bin/sh libdvdread-4.1.1-6.fc9.ppc64 requires /sbin/ldconfig libdwarves1-1.6-1.ppc64 requires /sbin/ldconfig libeXosip2-3.1.0-1.fc9.ppc64 requires /sbin/ldconfig libebml-0.7.8-1.fc9.ppc64 requires /sbin/ldconfig libedit-2.10-4.20070831cvs.fc9.ppc64 requires /sbin/ldconfig libepc-0.3.5-1.fc10.ppc64 requires /sbin/ldconfig libepc-ui-0.3.5-1.fc10.ppc64 requires /sbin/ldconfig liberation-fonts-1.0-4.fc9.noarch requires /bin/sh libesmtp-1.0.4-7.fc9.ppc64 requires /sbin/ldconfig libesmtp-devel-1.0.4-7.fc9.ppc64 requires /bin/sh libetpan-0.52-5.fc9.ppc64 requires /sbin/ldconfig libetpan-devel-0.52-5.fc9.ppc64 requires /bin/sh libevent-1.3e-2.fc9.ppc64 requires /sbin/ldconfig libevent-devel-1.3e-2.fc9.ppc64 requires /usr/bin/env libewf-20080501-1.fc10.ppc64 requires /sbin/ldconfig libexif-0.6.16-1.fc9.ppc64 requires /sbin/ldconfig libextractor-0.5.19a-1.fc9.ppc64 requires /bin/sh libextractor-0.5.19a-1.fc9.ppc64 requires /sbin/ldconfig libextractor-0.5.19a-1.fc9.ppc64 requires /sbin/install-info libextractor-devel-0.5.19a-1.fc9.ppc64 requires /usr/lib64/pkgconfig libextractor-plugins-thumbnailgtk-0.5.19a-1.fc9.ppc64 requires /bin/sh libextractor-plugins-thumbnailgtk-0.5.19a-1.fc9.ppc64 requires /usr/sbin/update-alternatives libextractor-plugins-thumbnailqt-0.5.19a-1.fc9.ppc64 requires /bin/sh libextractor-plugins-thumbnailqt-0.5.19a-1.fc9.ppc64 requires /usr/sbin/update-alternatives libffi-3.0.1-1.fc9.ppc64 requires /sbin/ldconfig libffi-devel-3.0.1-1.fc9.ppc64 requires /bin/sh libffi-devel-3.0.1-1.fc9.ppc64 requires /sbin/install-info libfishsound-0.9.1-1.fc9.ppc64 requires /sbin/ldconfig libflaim-4.9.1052-1.fc9.ppc64 requires /sbin/ldconfig libfontenc-1.0.4-5.fc9.ppc64 requires /sbin/ldconfig libfprint-0.0.5-6.fc10.ppc64 requires /sbin/ldconfig libfreebob-1.0.7-4.fc9.ppc64 requires /sbin/ldconfig libfwbuilder-2.1.16-2.fc9.ppc64 requires /sbin/ldconfig libfwbuilder-devel-2.1.16-2.fc9.ppc64 requires /bin/sh libgadu-1.8.0-1.fc9.ppc64 requires /sbin/ldconfig libgail-gnome-1.20.0-2.fc9.ppc64 requires /sbin/ldconfig libgalago-0.5.2-7.fc9.ppc64 requires /sbin/ldconfig libgalago-gtk-0.5.0-7.fc9.ppc64 requires /sbin/ldconfig libgcc-4.3.0-8.ppc64 requires /usr/sbin/libgcc_post_upgrade libgcj-4.3.0-8.ppc64 requires /sbin/install-info libgcj-4.3.0-8.ppc64 requires /sbin/ldconfig libgcj-4.3.0-8.ppc64 requires /bin/sh libgcj-devel-4.3.0-8.ppc64 requires /usr/lib64/libgcj.so.9 libgcj-devel-4.3.0-8.ppc64 requires /bin/awk libgcj-devel-4.3.0-8.ppc64 requires /usr/lib64/libz.so libgconf-java-2.12.4-10.fc9.ppc64 requires /sbin/ldconfig libgconf-java-devel-2.12.4-10.fc9.ppc64 requires /bin/sh libgcroots-0.2.1-3.fc9.ppc64 requires /sbin/ldconfig libgcrypt-1.4.0-3.ppc64 requires /sbin/ldconfig libgcrypt-devel-1.4.0-3.ppc64 requires /bin/sh libgcrypt-devel-1.4.0-3.ppc64 requires /sbin/install-info libgcrypt-devel-1.4.0-3.ppc64 requires /bin/sh 1:libgda-3.1.2-3.fc9.ppc64 requires /sbin/ldconfig 1:libgda-devel-3.1.2-3.fc9.ppc64 requires /bin/sh libgdamm-3.0.0-1.fc9.ppc64 requires /sbin/ldconfig libgdiplus-1.9-4.fc9.ppc64 requires /sbin/ldconfig libgdl-0.7.11-1.fc9.ppc64 requires /sbin/ldconfig libgeda-20080127-1.fc9.ppc64 requires /bin/sh libgeda-20080127-1.fc9.ppc64 requires /sbin/ldconfig libgee-0.1.1-3.fc9.ppc64 requires /sbin/ldconfig libgeotiff-1.2.4-3.fc9.ppc64 requires /sbin/ldconfig libgfortran-4.3.0-8.ppc64 requires /sbin/ldconfig libggz-0.0.14.1-1.fc9.ppc64 requires /sbin/ldconfig libgii-1.0.2-6.fc9.ppc64 requires /sbin/ldconfig 1:libglade-0.17-21.fc9.ppc64 requires /sbin/ldconfig 1:libglade-devel-0.17-21.fc9.ppc64 requires /usr/bin/env 1:libglade-devel-0.17-21.fc9.ppc64 requires /bin/sh libglade-java-2.12.5-8.fc9.ppc64 requires /sbin/ldconfig libglade2-2.6.2-5.fc9.ppc64 requires /sbin/ldconfig libglade2-devel-2.6.2-5.fc9.ppc64 requires /usr/bin/python libglademm24-2.6.6-1.fc9.ppc64 requires /bin/sh libglademm24-2.6.6-1.fc9.ppc64 requires /sbin/ldconfig libgnome-2.22.0-3.fc9.ppc64 requires /bin/sh libgnome-2.22.0-3.fc9.ppc64 requires /sbin/ldconfig libgnome-java-2.12.4-8.fc9.ppc64 requires /sbin/ldconfig libgnomecanvas-2.20.1.1-2.fc9.ppc64 requires /sbin/ldconfig libgnomecanvasmm26-2.22.0-1.fc9.ppc64 requires /bin/sh libgnomecanvasmm26-2.22.0-1.fc9.ppc64 requires /sbin/ldconfig libgnomecups-0.2.3-3.fc9.ppc64 requires /sbin/ldconfig 1:libgnomedb-3.0.0-6.fc9.ppc64 requires /bin/sh 1:libgnomedb-3.0.0-6.fc9.ppc64 requires /sbin/ldconfig 1:libgnomedb-devel-3.0.0-6.fc9.ppc64 requires /bin/sh libgnomedbmm-2.9.5-4.fc9.ppc64 requires /sbin/ldconfig libgnomekbd-2.23.2-1.fc10.ppc64 requires /bin/sh libgnomemm26-2.22.0-1.ppc64 requires /bin/sh libgnomemm26-2.22.0-1.ppc64 requires /sbin/ldconfig libgnomeprint22-2.18.4-1.fc9.ppc64 requires /sbin/ldconfig libgnomeprintui22-2.18.2-1.fc9.ppc64 requires /sbin/ldconfig libgnomeui-2.22.1-2.fc9.ppc64 requires /sbin/ldconfig libgnomeuimm26-2.22.0-1.fc9.ppc64 requires /bin/sh libgnomeuimm26-2.22.0-1.fc9.ppc64 requires /sbin/ldconfig libgomp-4.3.0-8.ppc64 requires /bin/sh libgomp-4.3.0-8.ppc64 requires /sbin/ldconfig libgomp-4.3.0-8.ppc64 requires /sbin/install-info libgpg-error-1.6-2.ppc64 requires /sbin/ldconfig libgpg-error-devel-1.6-2.ppc64 requires /bin/sh libgpod-0.6.0-5.fc10.ppc64 requires /sbin/ldconfig libgringotts-1.2.1-4.fc9.ppc64 requires /sbin/ldconfig libgsasl-0.2.18-6.fc9.ppc64 requires /sbin/ldconfig libgsf-1.14.8-1.fc9.ppc64 requires /bin/sh libgsf-1.14.8-1.fc9.ppc64 requires /sbin/ldconfig libgsf-gnome-1.14.8-1.fc9.ppc64 requires /sbin/ldconfig libgssapi-0.11-3.fc9.ppc64 requires /sbin/ldconfig libgssglue-0.1-5.fc9.ppc64 requires /sbin/ldconfig libgstroke-0.5.1-17.fc9.ppc64 requires /sbin/ldconfig libgtk-java-2.8.7-7.fc9.ppc64 requires /sbin/ldconfig libgtk-java-devel-2.8.7-7.fc9.ppc64 requires /bin/sh libgtksourceviewmm-0.3.1-1.fc8.ppc64 requires /sbin/ldconfig libgtop2-2.22.1-1.fc9.ppc64 requires /sbin/ldconfig libgweather-2.23.2-1.fc10.ppc64 requires /bin/sh libgweather-2.23.2-1.fc10.ppc64 requires /sbin/ldconfig libhangul-0.0.6-4.fc9.ppc64 requires /sbin/ldconfig libhugetlbfs-1.1-6.fc9.ppc64 requires /bin/bash libhugetlbfs-test-1.1-6.fc9.ppc64 requires /bin/bash libibverbs-1.1.1-3.fc9.ppc64 requires /sbin/ldconfig libical-0.30-1.fc9.ppc64 requires /sbin/ldconfig libical-devel-0.30-1.fc9.ppc64 requires /bin/sh libicu-3.8.1-7.fc9.ppc64 requires /sbin/ldconfig libicu-devel-3.8.1-7.fc9.ppc64 requires /bin/sh libid3tag-0.15.1b-6.fc10.ppc64 requires /sbin/ldconfig libident-0.32-2.fc9.ppc64 requires /sbin/ldconfig libident-tools-0.32-2.fc9.ppc64 requires /bin/sh libidn-0.6.14-7.ppc64 requires /bin/sh libidn-0.6.14-7.ppc64 requires /sbin/ldconfig libidn-0.6.14-7.ppc64 requires /sbin/install-info libiec61883-1.1.0-4.fc9.ppc64 requires /sbin/ldconfig libieee1284-0.2.11-3.fc9.ppc64 requires /sbin/ldconfig libifp-1.0.0.2-7.fc9.ppc64 requires /sbin/ldconfig libifp-1.0.0.2-7.fc9.ppc64 requires /bin/bash libipoddevice-0.5.3-4.fc9.ppc64 requires /sbin/ldconfig libiptcdata-1.0.2-2.fc9.ppc64 requires /sbin/ldconfig libisofs-0.2.8-3.fc9.ppc64 requires /sbin/ldconfig libitl-0.6.4-4.fc9.ppc64 requires /sbin/ldconfig libjingle-0.3.11-8.fc9.ppc64 requires /sbin/ldconfig libjpeg-6b-41.fc9.ppc64 requires /sbin/ldconfig libkdcraw-0.1.4-1.fc10.ppc64 requires /bin/sh libkexif-0.2.5-4.fc9.ppc64 requires /sbin/ldconfig libkexiv2-0.1.7-1.fc10.ppc64 requires /sbin/ldconfig libkipi-0.1.6-1.fc10.ppc64 requires /bin/sh libksba-1.0.3-2.fc9.ppc64 requires /sbin/ldconfig libksba-devel-1.0.3-2.fc9.ppc64 requires /sbin/install-info libksba-devel-1.0.3-2.fc9.ppc64 requires /bin/sh libksba-devel-1.0.3-2.fc9.ppc64 requires /bin/sh liblo-0.24-2.fc9.ppc64 requires /sbin/ldconfig liblqr-1-0.1.0-5.fc9.ppc64 requires /sbin/ldconfig liblrdf-0.4.0-13.fc9.ppc64 requires /sbin/ldconfig libmal-0.31-8.fc9.ppc64 requires /sbin/ldconfig libmalaga-7.12-1.fc9.ppc64 requires /sbin/ldconfig libmatchbox-1.9-3.fc9.ppc64 requires /sbin/ldconfig libmatheval-1.1.5-2.fc9.ppc64 requires /sbin/ldconfig libmatheval-devel-1.1.5-2.fc9.ppc64 requires /bin/sh libmatheval-devel-1.1.5-2.fc9.ppc64 requires /sbin/install-info libmatroska-0.8.1-3.fc9.ppc64 requires /sbin/ldconfig libmcrypt-2.5.8-5.fc9.ppc64 requires /sbin/ldconfig libmcrypt-devel-2.5.8-5.fc9.ppc64 requires /bin/sh libmikmod-3.2.0-3.beta2.fc9.ppc64 requires /sbin/ldconfig libmikmod-devel-3.2.0-3.beta2.fc9.ppc64 requires /bin/sh libmikmod-devel-3.2.0-3.beta2.fc9.ppc64 requires /bin/sh libmng-1.0.9-6.1.ppc64 requires /sbin/ldconfig libmodelfile-0.1.92-5.fc9.ppc64 requires /sbin/ldconfig 1:libmodplug-0.8.4-3.fc9.ppc64 requires /sbin/ldconfig libmowgli-0.5.0-2.fc9.ppc64 requires /sbin/ldconfig libmp4v2-1.5.0.1-6.fc9.ppc64 requires /sbin/ldconfig libmpcdec-1.2.6-4.fc9.ppc64 requires /sbin/ldconfig libmpd-0.15.0-3.fc9.ppc64 requires /sbin/ldconfig libmspack-0.0-0.5.20060920alpha.fc9.ppc64 requires /sbin/ldconfig libmtp-0.2.6.1-1.fc9.ppc64 requires /sbin/ldconfig libmudflap-4.3.0-8.ppc64 requires /sbin/ldconfig libmusicbrainz-2.1.5-6.fc9.ppc64 requires /sbin/ldconfig libnasl-2.2.10-5.fc9.ppc64 requires /sbin/ldconfig libnasl-devel-2.2.10-5.fc9.ppc64 requires /bin/sh libnc-dap-3.7.0-9.fc9.ppc64 requires /sbin/ldconfig libnc-dap-devel-3.7.0-9.fc9.ppc64 requires /bin/sh libnemesi-0.6.4-0.3.rc2.fc9.ppc64 requires /sbin/ldconfig libnet-devel-1.1.2.1-12.fc9.ppc64 requires /bin/sh libnet10-1.0.2a-14.fc9.ppc64 requires /bin/sh libnetfilter_conntrack-0.0.89-0.1.svn7356.fc9.ppc64 requires /sbin/ldconfig libnetfilter_log-0.0.13-6.fc9.ppc64 requires /sbin/ldconfig libnetfilter_queue-0.0.15-4.fc9.ppc64 requires /sbin/ldconfig libnfnetlink-0.0.33-0.1.svn7211.fc9.ppc64 requires /sbin/ldconfig libnids-1.22-4.fc9.ppc64 requires /sbin/ldconfig libnjb-2.2.6-3.fc9.ppc64 requires /sbin/ldconfig libnl-1.1-3.fc9.ppc64 requires /sbin/ldconfig libnotify-0.4.4-10.fc9.ppc64 requires /bin/sh libnova-0.12.1-3.fc10.ppc64 requires /sbin/ldconfig libnss-mysql-1.5-7.fc9.ppc64 requires /sbin/ldconfig libntlm-0.4.2-1.fc9.ppc64 requires /sbin/ldconfig libobjc-4.3.0-8.ppc64 requires /sbin/ldconfig libofa-0.9.3-13.fc9.ppc64 requires /sbin/ldconfig libofx-0.8.3-5.ppc64 requires /sbin/ldconfig 2:libogg-1.1.3-9.fc9.ppc64 requires /sbin/ldconfig liboggz-0.9.5-2.fc9.ppc64 requires /sbin/ldconfig liboggz-0.9.5-2.fc9.ppc64 requires /bin/sh liboil-0.3.14-1.fc9.ppc64 requires /sbin/ldconfig libopendaap-0.4.0-5.fc9.ppc64 requires /sbin/ldconfig libopenraw-0.0.5-1.fc9.ppc64 requires /sbin/ldconfig libopenraw-gnome-0.0.5-1.fc9.ppc64 requires /sbin/ldconfig libopensync-0.36-2.fc9.ppc64 requires /sbin/ldconfig libopensync-plugin-google-calendar-0.35-2.fc9.ppc64 requires /usr/bin/env libopensync-plugin-kdepim-0.35-2.fc9.ppc64 requires /sbin/ldconfig libopm-0.1-7.20050731cvs.fc9.ppc64 requires /sbin/ldconfig liborigin-20071119-3.fc10.ppc64 requires /sbin/ldconfig libosip2-3.1.0-1.fc9.ppc64 requires /sbin/ldconfig libotf-0.9.7-4.fc10.ppc64 requires /sbin/ldconfig libotf-devel-0.9.7-4.fc10.ppc64 requires /bin/sh libotr-3.1.0-2.fc9.ppc64 requires /sbin/ldconfig libp11-0.2.3-2.fc9.ppc64 requires /sbin/ldconfig libpanelappletmm-2.22.0-1.fc9.ppc64 requires /sbin/ldconfig libpano12-2.8.6-2.fc9.ppc64 requires /sbin/ldconfig libpano13-2.9.12-5.fc9.ppc64 requires /sbin/ldconfig libpaper-1.1.23-2.fc9.ppc64 requires /sbin/ldconfig libpaper-1.1.23-2.fc9.ppc64 requires /bin/bash libpar2-0.2-5.fc9.ppc64 requires /sbin/ldconfig 14:libpcap-0.9.8-2.fc9.ppc64 requires /sbin/ldconfig libpciaccess-0.10-2.fc9.ppc64 requires /sbin/ldconfig 2:libpng-1.2.24-1.fc9.ppc64 requires /sbin/ldconfig 2:libpng-devel-1.2.24-1.fc9.ppc64 requires /bin/sh libpng10-1.0.37-1.fc10.ppc64 requires /sbin/ldconfig libpolyxmass-0.9.1-2.fc9.ppc64 requires /sbin/ldconfig libpqxx-2.6.8-10.fc9.ppc64 requires /sbin/ldconfig libpqxx-devel-2.6.8-10.fc9.ppc64 requires /bin/sh libprelude-0.9.17.1-1.fc10.ppc64 requires /sbin/ldconfig libprelude-0.9.17.1-1.fc10.ppc64 requires /bin/sh libprelude-devel-0.9.17.1-1.fc10.ppc64 requires /bin/sh libpreludedb-0.9.14.1-2.fc9.ppc64 requires /sbin/ldconfig libpreludedb-devel-0.9.14.1-2.fc9.ppc64 requires /bin/sh libpri-1.4.3-2.fc9.ppc64 requires /sbin/ldconfig libpurple-2.4.1-3.fc10.ppc64 requires /usr/bin/env libpurple-2.4.1-3.fc10.ppc64 requires /sbin/ldconfig libpurple-2.4.1-3.fc10.ppc64 requires /bin/sh libqalculate-0.9.6-4.fc9.ppc64 requires /sbin/ldconfig librapi-0.11-2.fc9.ppc64 requires /sbin/ldconfig librapi-0.11-2.fc9.ppc64 requires /bin/bash libraw1394-1.3.0-6.fc9.ppc64 requires /sbin/ldconfig librdmacm-1.0.7-1.fc9.ppc64 requires /sbin/ldconfig librdmacm-devel-1.0.7-1.fc9.ppc64 requires /usr/include/infiniband/verbs.h libreadline-java-0.8.0-20.fc9.ppc64 requires /bin/sh librelp-0.1.1-2.fc10.ppc64 requires /bin/sh librelp-0.1.1-2.fc10.ppc64 requires /sbin/ldconfig librfid-0.2.0-1.fc9.ppc64 requires /sbin/ldconfig librra-0.11-2.fc9.ppc64 requires /sbin/ldconfig librsvg2-2.22.2-1.fc9.ppc64 requires /bin/sh librsvg2-2.22.2-1.fc9.ppc64 requires /usr/bin/env librsync-0.9.7-12.fc9.ppc64 requires /sbin/ldconfig librtas-1.3.3-3.fc9.ppc64 requires /sbin/ldconfig librtfcomp-1.1-3.fc9.ppc64 requires /sbin/ldconfig librx-1.5-10.fc9.ppc64 requires /sbin/ldconfig librx-devel-1.5-10.fc9.ppc64 requires /bin/sh libsamplerate-0.1.3-1.fc10.ppc64 requires /sbin/ldconfig libsane-hpaio-2.8.2-3.fc10.ppc64 requires /bin/sh libscigraphica-2.1.1-8.fc9.ppc64 requires /sbin/ldconfig libselinux-2.0.64-2.fc10.ppc64 requires /bin/sh libselinux-2.0.64-2.fc10.ppc64 requires /sbin/ldconfig libsemanage-2.0.25-1.fc10.ppc64 requires /sbin/ldconfig libsepol-2.0.26-1.fc9.ppc64 requires /bin/sh libsepol-2.0.26-1.fc9.ppc64 requires /sbin/ldconfig libsexy-0.1.11-8.fc10.ppc64 requires /sbin/ldconfig libsexymm-0.1.9-5.fc9.ppc64 requires /sbin/ldconfig libshout-2.2.2-3.fc9.ppc64 requires /sbin/ldconfig libsidplay-1.36.57-17.ppc64 requires /sbin/ldconfig libsieve-2.2.6-3.fc9.ppc64 requires /sbin/ldconfig libsigc++-1.2.7-6.fc9.ppc64 requires /sbin/ldconfig libsigc++20-2.2.2-1.fc9.ppc64 requires /bin/sh libsigc++20-2.2.2-1.fc9.ppc64 requires /sbin/ldconfig libsigsegv-2.4-6.fc9.ppc64 requires /sbin/ldconfig libsilc-1.1.7-1.fc9.ppc64 requires /sbin/ldconfig libsmbclient-3.2.0-1.pre3.10.fc10.ppc64 requires /bin/sh libsmi-0.4.8-1.fc10.ppc64 requires /sbin/ldconfig libsmi-0.4.8-1.fc10.ppc64 requires /bin/sh libsndfile-1.0.17-3.fc9.ppc64 requires /sbin/ldconfig libsoup-2.23.1-1.fc10.ppc64 requires /sbin/ldconfig libsoup22-2.2.105-2.fc9.ppc64 requires /sbin/ldconfig libspectre-0.2.0-2.fc9.ppc64 requires /sbin/ldconfig libspectrum-0.4.0-2.fc9.ppc64 requires /sbin/ldconfig libssh2-0.18-7.fc9.ppc64 requires /sbin/ldconfig libstatgrab-0.16-1.fc9.ppc64 requires /sbin/ldconfig libstdc++-4.3.0-8.ppc64 requires /sbin/ldconfig libstdc++-devel-4.3.0-8.ppc64 requires /usr/lib64/libstdc++.so.6 libstroke-0.5.1-17.fc9.ppc64 requires /sbin/ldconfig libsvm-2.86-13.fc10.ppc64 requires /sbin/ldconfig libsvm-python-2.86-13.fc10.ppc64 requires /usr/bin/env libsvm-svm-toy-gtk-2.86-13.fc10.ppc64 requires /bin/sh 1:libswt3-gtk2-3.3.2-11.fc9.ppc64 requires /usr/bin/rebuild-gcj-db libsx-2.05-15.fc9.ppc64 requires /sbin/ldconfig libsynce-0.11-3.fc9.ppc64 requires /sbin/ldconfig libsyncml-0.4.5-2.fc9.ppc64 requires /sbin/ldconfig libsysfs-2.1.0-3.fc9.ppc64 requires /sbin/ldconfig libtalloc-1.2.0-10.fc10.ppc64 requires /bin/sh libtar-1.2.11-11.fc10.ppc64 requires /sbin/ldconfig libtasn1-1.3-1.fc9.ppc64 requires /sbin/ldconfig libtasn1-devel-1.3-1.fc9.ppc64 requires /bin/sh libtasn1-devel-1.3-1.fc9.ppc64 requires /bin/bash libtasn1-devel-1.3-1.fc9.ppc64 requires /sbin/install-info libtcd-2.2.3-1.fc9.2.ppc64 requires /sbin/ldconfig libtdb-1.1.1-10.fc10.ppc64 requires /bin/sh libtelepathy-0.3.3-1.fc9.ppc64 requires /sbin/ldconfig libtextcat-2.2-5.fc9.ppc64 requires /sbin/ldconfig libthai-0.1.9-4.fc9.ppc64 requires /sbin/ldconfig libtheora-1.0beta3-2.fc10.ppc64 requires /sbin/ldconfig libtidy-0.99.0-17.20070615.fc9.ppc64 requires /sbin/ldconfig libtiff-3.8.2-10.fc9.ppc64 requires /sbin/ldconfig libtimidity-0.1.0-6.fc9.ppc64 requires /sbin/ldconfig libtirpc-0.1.7-18.fc9.ppc64 requires /sbin/ldconfig libtirpc-devel-0.1.7-18.fc9.ppc64 requires /bin/sh libtlen-0-0.7.20060309.fc9.ppc64 requires /sbin/ldconfig libtomcrypt-1.17-9.fc9.ppc64 requires /sbin/ldconfig libtommath-0.41-8.fc9.ppc64 requires /sbin/ldconfig libtomoe-gtk-0.6.0-3.fc9.ppc64 requires /sbin/ldconfig libtomoe-gtk-devel-0.6.0-3.fc9.ppc64 requires /sbin/ldconfig libtool-1.5.24-6.fc9.ppc64 requires /bin/sh libtool-1.5.24-6.fc9.ppc64 requires /sbin/install-info libtool-1.5.24-6.fc9.ppc64 requires /bin/sh libtool-ltdl-1.5.24-6.fc9.ppc64 requires /sbin/ldconfig libtorque-2.1.10-5.fc9.ppc64 requires /sbin/ldconfig libtorque-devel-2.1.10-5.fc9.ppc64 requires /bin/sh libtorrent-0.11.8-4.fc9.ppc64 requires /sbin/ldconfig libtranslate-0.99-14.fc9.ppc64 requires /sbin/ldconfig libtunepimp-0.5.3-11.fc9.ppc64 requires /sbin/ldconfig libtwin-0.0.2-8.fc10.ppc64 requires /sbin/ldconfig libuninameslist-0.0-8.20060907.ppc64 requires /sbin/ldconfig libunwind-0.99-0.5.frysk20070405cvs.fc9.ppc64 requires /sbin/ldconfig libupnp-1.6.6-1.fc10.ppc64 requires /sbin/ldconfig libusb-0.1.12-15.fc9.ppc64 requires /sbin/ldconfig libusb-devel-0.1.12-15.fc9.ppc64 requires /bin/sh libuser-0.56.9-1.ppc64 requires /sbin/ldconfig libutempter-1.1.5-2.fc9.ppc64 requires /bin/sh libutempter-1.1.5-2.fc9.ppc64 requires /sbin/ldconfig libvirt-0.4.2-5.fc10.ppc64 requires /bin/sh libvirt-0.4.2-5.fc10.ppc64 requires /usr/sbin/lokkit libvirt-0.4.2-5.fc10.ppc64 requires /bin/sh libvirt-cim-0.3-4.fc9.ppc64 requires /bin/sh libvirt-cim-0.3-4.fc9.ppc64 requires /sbin/ldconfig libvirt-cim-0.3-4.fc9.ppc64 requires /bin/bash libvirt-cim-0.3-4.fc9.ppc64 requires /bin/sh libvirt-devel-0.4.2-5.fc10.ppc64 requires /usr/bin/python libvirt-python-0.4.2-5.fc10.ppc64 requires /usr/bin/python libvisual-0.4.0-6.fc9.ppc64 requires /sbin/ldconfig libvncserver-0.9.1-3.fc10.ppc64 requires /sbin/ldconfig libvncserver-devel-0.9.1-3.fc10.ppc64 requires /bin/sh libvoikko-1.7-0.1.rc2.fc10.ppc64 requires /sbin/ldconfig libvolume_id-121-1.20080516git.fc10.ppc64 requires /sbin/ldconfig 1:libvorbis-1.2.0-4.fc10.ppc64 requires /sbin/ldconfig libvpd-2.0.1-1.fc9.ppc64 requires /sbin/ldconfig libvte-java-0.12.1-11.fc9.ppc64 requires /sbin/ldconfig libwcs-3.7.0-2.fc9.ppc64 requires /sbin/ldconfig libwiimote-0.4-6.fc9.ppc64 requires /sbin/ldconfig libwmf-0.2.8.4-18.fc9.ppc64 requires /bin/sh libwmf-0.2.8.4-18.fc9.ppc64 requires /usr/bin/update-gdk-pixbuf-loaders libwmf-0.2.8.4-18.fc9.ppc64 requires /bin/sh libwmf-devel-0.2.8.4-18.fc9.ppc64 requires /bin/sh libwmf-lite-0.2.8.4-18.fc9.ppc64 requires /sbin/ldconfig libwnck-2.22.1-1.fc9.ppc64 requires /sbin/ldconfig libwpd-0.8.14-1.fc9.ppc64 requires /sbin/ldconfig libwvstreams-4.4.1-4.fc9.ppc64 requires /sbin/ldconfig libxcb-1.1-4.fc9.ppc64 requires /sbin/ldconfig libxfce4mcs-4.4.2-2.fc9.ppc64 requires /sbin/ldconfig libxfce4util-4.4.2-2.fc9.ppc64 requires /sbin/ldconfig libxfcegui4-4.4.2-2.fc9.ppc64 requires /bin/sh libxkbfile-1.0.4-5.fc9.ppc64 requires /sbin/ldconfig libxklavier-3.6-1.fc10.ppc64 requires /sbin/ldconfig 1:libxml-1.8.17-19.fc9.ppc64 requires /sbin/ldconfig libxml++-2.22.0-1.fc9.ppc64 requires /sbin/ldconfig libxml++-devel-2.22.0-1.fc9.ppc64 requires /bin/sh 1:libxml-devel-1.8.17-19.fc9.ppc64 requires /bin/sh libxml2-2.6.32-2.fc10.ppc64 requires /bin/sh libxml2-devel-2.6.32-2.fc10.ppc64 requires /bin/sh libxml2-devel-2.6.32-2.fc10.ppc64 requires /usr/bin/python libxml2-python-2.6.32-2.fc10.ppc64 requires /usr/bin/python libxslt-1.1.24-1.fc10.ppc64 requires /bin/sh libxslt-devel-1.1.24-1.fc10.ppc64 requires /bin/sh libxslt-python-1.1.24-1.fc10.ppc64 requires /usr/bin/python libyaz-3.0.26-1.fc10.ppc64 requires /sbin/ldconfig libyaz-devel-3.0.26-1.fc10.ppc64 requires /usr/bin/tclsh libyaz-devel-3.0.26-1.fc10.ppc64 requires /bin/sh libytnef-1.5-3.fc9.ppc64 requires /sbin/ldconfig libzip-0.8-5.fc9.ppc64 requires /sbin/ldconfig licq-1.3.5-2.fc10.ppc64 requires /usr/bin/perl licq-1.3.5-2.fc10.ppc64 requires /bin/sh licq-auto-reply-1.3.5-2.fc10.ppc64 requires /bin/bash liferea-1.4.13-3.fc9.ppc64 requires /bin/sh liferea-1.4.13-3.fc9.ppc64 requires /bin/sh lighttpd-1.4.19-4.fc10.ppc64 requires /bin/sh lighttpd-1.4.19-4.fc10.ppc64 requires /usr/sbin/useradd lighttpd-1.4.19-4.fc10.ppc64 requires /sbin/service lighttpd-1.4.19-4.fc10.ppc64 requires /bin/sh lighttpd-1.4.19-4.fc10.ppc64 requires /sbin/chkconfig lilypond-2.10.33-1.fc8.ppc64 requires /bin/sh lilypond-2.10.33-1.fc8.ppc64 requires /sbin/install-info lilypond-2.10.33-1.fc8.ppc64 requires /usr/bin/python lilypond-2.10.33-1.fc8.ppc64 requires /usr/bin/guile lineakd-0.9-5.fc6.ppc64 requires /bin/sh lineakd-0.9-5.fc6.ppc64 requires /sbin/ldconfig link-grammar-4.2.5-2.fc9.ppc64 requires /sbin/ldconfig linkage-0.1.4-6.fc9.ppc64 requires /bin/sh linkchecker-4.7-11.fc9.ppc64 requires /usr/bin/python linphone-2.1.1-1.fc9.ppc64 requires /sbin/ldconfig linux-atm-2.5.0-5.ppc64 requires /usr/bin/perl linux-atm-2.5.0-5.ppc64 requires /bin/sh linux-atm-libs-2.5.0-5.ppc64 requires /sbin/ldconfig linux-igd-1.0-5.fc9.ppc64 requires /bin/sh linux-igd-1.0-5.fc9.ppc64 requires /bin/bash linux-igd-1.0-5.fc9.ppc64 requires /sbin/chkconfig linux-igd-1.0-5.fc9.ppc64 requires /sbin/service linux-libertine-fonts-2.7.9-1.fc9.noarch requires /bin/sh linuxdoc-tools-0.9.21-16.fc9.ppc64 requires /bin/sh linuxdoc-tools-0.9.21-16.fc9.ppc64 requires /usr/bin/perl linuxwacom-0.7.9.8-7.fc10.ppc64 requires /sbin/ldconfig liquidwar-5.6.4-4.fc9.ppc64 requires /bin/sh liquidwar-5.6.4-4.fc9.ppc64 requires /sbin/install-info liquidwar-server-5.6.4-4.fc9.ppc64 requires /bin/sh liquidwar-server-5.6.4-4.fc9.ppc64 requires /sbin/chkconfig liquidwar-server-5.6.4-4.fc9.ppc64 requires /usr/sbin/useradd liquidwar-server-5.6.4-4.fc9.ppc64 requires /bin/sh liquidwar-server-5.6.4-4.fc9.ppc64 requires /sbin/service lirc-0.8.3-1.fc10.ppc64 requires /bin/sh lirc-0.8.3-1.fc10.ppc64 requires /sbin/chkconfig lirc-0.8.3-1.fc10.ppc64 requires /sbin/ldconfig lirc-0.8.3-1.fc10.ppc64 requires /bin/sh lirc-libs-0.8.3-1.fc10.ppc64 requires /sbin/ldconfig listen-0.5-18.fc9.ppc64 requires /usr/bin/puid listen-0.5-18.fc9.ppc64 requires /usr/bin/env listen-0.5-18.fc9.ppc64 requires /sbin/ldconfig listen-0.5-18.fc9.ppc64 requires /bin/sh livecd-tools-017-1.fc9.ppc64 requires yaboot livecd-tools-017-1.fc9.ppc64 requires /bin/bash livecd-tools-017-1.fc9.ppc64 requires /usr/bin/python lklug-fonts-0.2.2-5.fc8.noarch requires /bin/sh lksctp-tools-1.0.7-3.fc9.ppc64 requires /sbin/ldconfig lksctp-tools-1.0.7-3.fc9.ppc64 requires /bin/sh llvm-2.2-3.fc9.ppc64 requires /sbin/ldconfig llvm-devel-2.2-3.fc9.ppc64 requires /usr/bin/perl lm_sensors-3.0.1-5.fc9.ppc64 requires /bin/sh lm_sensors-3.0.1-5.fc9.ppc64 requires /sbin/ldconfig lm_sensors-3.0.1-5.fc9.ppc64 requires /bin/bash lm_sensors-3.0.1-5.fc9.ppc64 requires /bin/sh lm_sensors-3.0.1-5.fc9.ppc64 requires /usr/bin/perl lm_sensors-sensord-3.0.1-5.fc9.ppc64 requires /bin/sh lm_sensors-sensord-3.0.1-5.fc9.ppc64 requires /bin/sh lmarbles-1.0.7-9.ppc64 requires /bin/sh lock-keys-applet-1.0-14.fc9.ppc64 requires /bin/sh lockdev-1.0.1-12.fc9.1.ppc64 requires /bin/sh lockdev-1.0.1-12.fc9.1.ppc64 requires /sbin/ldconfig log4j-1.2.14-4jpp.1.fc9.ppc64 requires /bin/sh log4j-1.2.14-4jpp.1.fc9.ppc64 requires /bin/sh log4j-javadoc-1.2.14-4jpp.1.fc9.ppc64 requires /bin/sh log4j-javadoc-1.2.14-4jpp.1.fc9.ppc64 requires /bin/rm log4j-javadoc-1.2.14-4jpp.1.fc9.ppc64 requires /bin/ln logrotate-3.7.6-4.fc10.ppc64 requires /bin/sh logwatch-7.3.6-22.fc10.noarch requires /usr/bin/perl lohit-fonts-bengali-2.2.1-2.fc9.noarch requires /bin/sh lohit-fonts-gujarati-2.2.1-2.fc9.noarch requires /bin/sh lohit-fonts-hindi-2.2.1-2.fc9.noarch requires /bin/sh lohit-fonts-kannada-2.2.1-2.fc9.noarch requires /bin/sh lohit-fonts-malayalam-2.2.1-2.fc9.noarch requires /bin/sh lohit-fonts-oriya-2.2.1-2.fc9.noarch requires /bin/sh lohit-fonts-punjabi-2.2.1-2.fc9.noarch requires /bin/sh lohit-fonts-tamil-2.2.1-2.fc9.noarch requires /bin/sh lohit-fonts-telugu-2.2.1-2.fc9.noarch requires /bin/sh loki-lib-0.1.6-6.fc9.ppc64 requires /sbin/ldconfig londonlaw-0.2.1-3.fc9.noarch requires /bin/sh londonlaw-0.2.1-3.fc9.noarch requires /usr/bin/python loudmouth-1.3.4-1.fc9.ppc64 requires /sbin/ldconfig lpsolve-5.5.0.12-1.fc9.ppc64 requires /sbin/ldconfig lsvpd-1.6.3-1.fc9.ppc64 requires /usr/sbin/vpdupdate ltsp-client-5.1.7-2.fc9.ppc64 requires /bin/bash ltsp-client-5.1.7-2.fc9.ppc64 requires /bin/sh ltsp-server-5.1.7-2.fc9.ppc64 requires /bin/sh ltsp-server-5.1.7-2.fc9.ppc64 requires /usr/bin/perl ltsp-server-5.1.7-2.fc9.ppc64 requires /bin/bash ltsp-server-5.1.7-2.fc9.ppc64 requires /bin/sh ltsp-server-5.1.7-2.fc9.ppc64 requires /usr/bin/python ltsp-utils-0.25-4.fc6.noarch requires /usr/bin/perl ltspfs-0.5.2-1.fc9.ppc64 requires /usr/bin/python ltspfsd-0.5.2-1.fc9.ppc64 requires /bin/sh luadoc-3.0.1-1.fc8.noarch requires /usr/bin/env lucene-2.3.1-2jpp.0.fc10.ppc64 requires /bin/sh lucene-javadoc-2.3.1-2jpp.0.fc10.ppc64 requires /bin/sh luma-2.4-3.fc9.noarch requires /usr/bin/env lvm2-2.02.33-11.fc9.ppc64 requires /bin/bash lvm2-2.02.33-11.fc9.ppc64 requires /bin/sh lvm2-cluster-2.02.33-11.fc9.ppc64 requires /bin/sh lvm2-cluster-2.02.33-11.fc9.ppc64 requires /bin/bash lvm2-cluster-2.02.33-11.fc9.ppc64 requires /bin/sh lwp-2.4-1.fc10.ppc64 requires /sbin/ldconfig lxappearance-0.2-1.fc10.ppc64 requires /bin/sh lybniz-1.3.2-1.fc9.noarch requires /bin/sh lybniz-1.3.2-1.fc9.noarch requires /usr/bin/python lynx-2.8.6-13.fc9.ppc64 requires /bin/sh lyx-1.5.5-1.fc10.ppc64 requires /bin/sh lyx-1.5.5-1.fc10.ppc64 requires /usr/bin/env lyx-1.5.5-1.fc10.ppc64 requires /usr/bin/python lyx-1.5.5-1.fc10.ppc64 requires /usr/bin/texhash lyx-1.5.5-1.fc10.ppc64 requires /bin/sh lzma-4.32.5-1.fc9.ppc64 requires /bin/sh lzma-libs-4.32.5-1.fc9.ppc64 requires /sbin/ldconfig lzo-2.03-1.fc10.ppc64 requires /sbin/ldconfig lzo-minilzo-2.03-1.fc10.ppc64 requires /sbin/ldconfig m17n-contrib-1.1.6-3.fc9.noarch requires /usr/bin/gawk m17n-db-1.5.1-3.fc9.noarch requires /bin/sh m17n-lib-1.5.1-1.fc9.ppc64 requires /sbin/ldconfig m2crypto-0.18.2-4.ppc64 requires /usr/bin/env m4-1.4.11-1.fc10.ppc64 requires /bin/sh m4-1.4.11-1.fc10.ppc64 requires /sbin/install-info mISDN-1.1.5-2.fc9.ppc64 requires /bin/sh mISDN-1.1.5-2.fc9.ppc64 requires /sbin/ldconfig macchanger-1.5.0-4.fc9.ppc64 requires /bin/sh macchanger-1.5.0-4.fc9.ppc64 requires /sbin/install-info mach-0.9.2-4.fc9.ppc64 requires /bin/sh mach-0.9.2-4.fc9.ppc64 requires /usr/bin/python machineball-1.0-5.fc9.ppc64 requires /bin/sh madan-fonts-1.0-6.fc8.noarch requires /bin/sh magic-7.5.116-1.fc9.ppc64 requires /bin/sh magic-7.5.116-1.fc9.ppc64 requires /usr/bin/tclsh magic-7.5.116-1.fc9.ppc64 requires /bin/awk magic-7.5.116-1.fc9.ppc64 requires /usr/bin/wish magic-7.5.116-1.fc9.ppc64 requires /bin/sh magicmaze-1.0.2-1.fc9.ppc64 requires /bin/sh magicor-1.1-0.1.rc1.fc9.noarch requires /bin/sh magicor-1.1-0.1.rc1.fc9.noarch requires /usr/bin/python mail-notification-5.3-1.fc9.ppc64 requires /bin/sh maildrop-2.0.4-6.fc9.ppc64 requires /bin/sh mailgraph-1.14-2.fc9.noarch requires /bin/sh mailgraph-1.14-2.fc9.noarch requires /bin/bash mailgraph-1.14-2.fc9.noarch requires /usr/bin/perl mailgraph-selinux-1.14-2.fc9.noarch requires /usr/sbin/semodule mailgraph-selinux-1.14-2.fc9.noarch requires /sbin/fixfiles mailgraph-selinux-1.14-2.fc9.noarch requires /bin/sh mailgraph-selinux-1.14-2.fc9.noarch requires /sbin/restorecon 3:mailman-2.1.10-1.fc10.ppc64 requires /bin/sh 3:mailman-2.1.10-1.fc10.ppc64 requires /sbin/chkconfig 3:mailman-2.1.10-1.fc10.ppc64 requires /usr/bin/env 3:mailman-2.1.10-1.fc10.ppc64 requires /bin/sh 3:mailman-2.1.10-1.fc10.ppc64 requires /usr/bin/python 3:mailman-2.1.10-1.fc10.ppc64 requires /sbin/service 1:make-3.81-12.fc9.ppc64 requires /bin/sh 1:make-3.81-12.fc9.ppc64 requires /sbin/install-info malaga-7.12-1.fc9.ppc64 requires /bin/sh malaga-7.12-1.fc9.ppc64 requires /sbin/install-info man-1.6f-6.fc10.ppc64 requires /bin/sh man-1.6f-6.fc10.ppc64 requires /bin/bash man-1.6f-6.fc10.ppc64 requires /bin/sh manaworld-0.0.24-1.fc9.ppc64 requires /bin/sh manedit-0.8.1-3.fc9.ppc64 requires /bin/sh manedit-0.8.1-3.fc9.ppc64 requires /bin/sh maniadrive-1.2-8.fc9.ppc64 requires /bin/sh mantis-1.1.1-1.fc9.noarch requires /usr/bin/php mantis-config-httpd-1.1.1-1.fc9.noarch requires /bin/sh mantis-config-httpd-1.1.1-1.fc9.noarch requires /etc/httpd/conf.d mapserver-python-5.0.2-2.fc9.ppc64 requires /bin/sh maradns-1.3.07.08-1.fc9.ppc64 requires /bin/sh maradns-1.3.07.08-1.fc9.ppc64 requires /bin/bash maradns-1.3.07.08-1.fc9.ppc64 requires /sbin/chkconfig maradns-1.3.07.08-1.fc9.ppc64 requires /sbin/service mash-0.3.6-1.fc9.noarch requires /usr/bin/python2 mash-0.3.6-1.fc9.noarch requires /usr/bin/python mathml-fonts-1.0-21.fc6.noarch requires /bin/sh mathml-fonts-1.0-21.fc6.noarch requires /bin/bash mathml-fonts-1.0-21.fc6.noarch requires /bin/sh mboxgrep-0.7.9-5.fc9.ppc64 requires /bin/sh mboxgrep-0.7.9-5.fc9.ppc64 requires /sbin/install-info 1:mc-4.6.2-3.pre1.fc9.ppc64 requires /usr/bin/perl 1:mc-4.6.2-3.pre1.fc9.ppc64 requires /bin/sh mcs-libs-0.6.0-4.fc9.ppc64 requires /sbin/ldconfig mcstrans-0.2.11-1.fc10.ppc64 requires /bin/sh mcstrans-0.2.11-1.fc10.ppc64 requires /bin/bash mcstrans-0.2.11-1.fc10.ppc64 requires /sbin/chkconfig mcstrans-0.2.11-1.fc10.ppc64 requires /sbin/service mdadm-2.6.4-4.fc9.ppc64 requires /bin/sh mdadm-2.6.4-4.fc9.ppc64 requires /bin/bash mdadm-2.6.4-4.fc9.ppc64 requires /sbin/chkconfig mdadm-2.6.4-4.fc9.ppc64 requires /sbin/service mdbtools-libs-0.6-0.4.cvs20051109.fc9.ppc64 requires /sbin/ldconfig mdsplib-0.11-6.fc9.ppc64 requires /sbin/ldconfig meanwhile-1.0.2-6.fc9.ppc64 requires /sbin/ldconfig mecab-0.97-1.fc9.ppc64 requires /sbin/ldconfig mecab-devel-0.97-1.fc9.ppc64 requires /bin/sh mecab-ipadic-2.7.0.20070801-1.fc8.ppc64 requires /bin/sh mecab-ipadic-EUCJP-2.7.0.20070801-1.fc8.ppc64 requires /bin/sh mecab-jumandic-5.1.20070304-1.fc7.1.ppc64 requires /bin/sh mecab-jumandic-EUCJP-5.1.20070304-1.fc7.1.ppc64 requires /bin/sh mediatomb-0.11.0-1.fc9.ppc64 requires /bin/sh mediatomb-0.11.0-1.fc9.ppc64 requires /sbin/service mediatomb-0.11.0-1.fc9.ppc64 requires /bin/sh mediatomb-0.11.0-1.fc9.ppc64 requires /sbin/chkconfig mediawiki-1.10.4-39.fc9.ppc64 requires /usr/bin/env mediawiki-1.10.4-39.fc9.ppc64 requires /bin/bash mediawiki-1.10.4-39.fc9.ppc64 requires /bin/sh mediawiki-1.10.4-39.fc9.ppc64 requires /usr/bin/perl meld-1.1.5-4.fc9.noarch requires /bin/sh meld-1.1.5-4.fc9.noarch requires /usr/bin/env memcached-1.2.4-4.fc9.ppc64 requires /bin/sh memcached-1.2.4-4.fc9.ppc64 requires /sbin/service memcached-1.2.4-4.fc9.ppc64 requires /usr/bin/perl memcached-1.2.4-4.fc9.ppc64 requires /bin/sh memcached-1.2.4-4.fc9.ppc64 requires /sbin/chkconfig memcached-selinux-1.2.4-4.fc9.ppc64 requires /bin/sh mencal-2.3-1.fc8.noarch requires /usr/bin/perl mercator-0.2.5-4.fc9.ppc64 requires /sbin/ldconfig mercurial-1.0-4.fc9.ppc64 requires /usr/bin/python mercurial-1.0-4.fc9.ppc64 requires /usr/bin/env mercurial-1.0-4.fc9.ppc64 requires /bin/sh mercurial-hgk-1.0-4.fc9.ppc64 requires /usr/bin/env mesa-libGL-7.1-0.29.fc9.ppc64 requires /sbin/ldconfig mesa-libGLU-7.1-0.29.fc9.ppc64 requires /sbin/ldconfig mesa-libGLw-6.5.1-5.fc9.ppc64 requires /sbin/ldconfig mesa-libOSMesa-7.1-0.29.fc9.ppc64 requires /sbin/ldconfig metacafe-dl-2007.10.09-1.fc9.noarch requires /usr/bin/env metacity-2.23.13-1.fc10.ppc64 requires /bin/sh metacity-2.23.13-1.fc10.ppc64 requires /sbin/ldconfig metakit-2.4.9.7-5.fc9.ppc64 requires /sbin/ldconfig metamonitor-0.4.5-5.fc9.ppc64 requires /bin/sh metapixel-1.0.2-3.fc9.ppc64 requires /usr/bin/perl methane-1.4.7-4.fc9.ppc64 requires /bin/sh mew-common-6.0.51-1.fc10.ppc64 requires /bin/sh mew-common-6.0.51-1.fc10.ppc64 requires /usr/bin/env mew-common-6.0.51-1.fc10.ppc64 requires /sbin/install-info mew-common-6.0.51-1.fc10.ppc64 requires /bin/sh mfiler2-mdnd-4.0.9b-1.fc9.ppc64 requires /usr/bin/env mftrace-1.2.14-4.fc9.ppc64 requires /usr/bin/python mgetty-1.1.36-1.fc10.ppc64 requires /bin/sh mgetty-1.1.36-1.fc10.ppc64 requires /sbin/install-info mgetty-sendfax-1.1.36-1.fc10.ppc64 requires /bin/sh mgetty-sendfax-1.1.36-1.fc10.ppc64 requires /usr/sbin/useradd mgetty-sendfax-1.1.36-1.fc10.ppc64 requires /usr/bin/perl mgetty-sendfax-1.1.36-1.fc10.ppc64 requires /bin/sh mgopen-fonts-0.20050515-6.fc9.noarch requires /bin/sh mhash-0.9.9-5.ppc64 requires /sbin/ldconfig mhgui-0.2-6.fc9.ppc64 requires /sbin/ldconfig mhonarc-2.6.16-4.fc8.noarch requires /usr/bin/perl miau-0.6.5-2.fc9.ppc64 requires /bin/sh miau-0.6.5-2.fc9.ppc64 requires /sbin/install-info migemo-0.40-9.fc7.noarch requires /usr/bin/env migrationtools-47-1.fc9.noarch requires /usr/share/migrationtools/migrate_common.ph migrationtools-47-1.fc9.noarch requires /usr/bin/perl migrationtools-47-1.fc9.noarch requires /bin/sh milter-greylist-4.0-2.fc9.ppc64 requires /bin/sh milter-greylist-sysv-4.0-2.fc9.ppc64 requires /sbin/chkconfig milter-greylist-sysv-4.0-2.fc9.ppc64 requires /bin/sh milter-greylist-sysv-4.0-2.fc9.ppc64 requires /bin/sh milter-regex-1.7-3.fc9.ppc64 requires /bin/sh milter-regex-1.7-3.fc9.ppc64 requires /sbin/chkconfig milter-regex-1.7-3.fc9.ppc64 requires /bin/sh mimedefang-2.64-1.fc9.ppc64 requires /bin/sh mimedefang-2.64-1.fc9.ppc64 requires /sbin/service mimedefang-2.64-1.fc9.ppc64 requires /bin/bash mimedefang-2.64-1.fc9.ppc64 requires /bin/sh mimedefang-2.64-1.fc9.ppc64 requires /usr/bin/perl mimedefang-2.64-1.fc9.ppc64 requires /sbin/chkconfig mimetex-1.60-4.fc9.ppc64 requires /var/www/cgi-bin mimetex-1.60-4.fc9.ppc64 requires /var/www/html mimetic-0.9.3-2.fc8.ppc64 requires /sbin/ldconfig minbar-0.2.1-6.fc9.ppc64 requires /bin/sh minicom-2.3-2.fc9.ppc64 requires /bin/sh minizip-1.2.3-18.fc9.ppc64 requires /sbin/ldconfig mirage-0.9.3-1.fc9.ppc64 requires /bin/sh mirage-0.9.3-1.fc9.ppc64 requires /usr/bin/python mirrormagic-2.0.2-5.fc9.ppc64 requires /bin/sh mkdst-0.8-1.fc9.noarch requires /bin/sh mkinitrd-6.0.52-2.fc9.ppc64 requires /bin/bash mkinitrd-6.0.52-2.fc9.ppc64 requires /sbin/insmod.static mkinitrd-6.0.52-2.fc9.ppc64 requires /bin/sh mkinitrd-6.0.52-2.fc9.ppc64 requires /sbin/losetup mksh-33d-1.fc9.ppc64 requires /bin/sh mkvtoolnix-gui-2.1.0-2.fc9.ppc64 requires /bin/sh mlmmj-1.2.15-2.fc9.ppc64 requires /bin/sh mlocate-0.20-1.ppc64 requires /bin/sh mlocate-0.20-1.ppc64 requires /bin/sh mm-1.4.2-4.fc9.ppc64 requires /sbin/ldconfig mm-devel-1.4.2-4.fc9.ppc64 requires /bin/sh mock-0.9.9-1.fc10.noarch requires /bin/sh mock-0.9.9-1.fc10.noarch requires /usr/bin/python mod_auth_ntlm_winbind-0.0.0-0.8.20070129svn713.fc9.ppc64 requires /bin/sh mod_fcgid-selinux-2.2-4.fc9.ppc64 requires /usr/sbin/semodule mod_fcgid-selinux-2.2-4.fc9.ppc64 requires /bin/sh mod_fcgid-selinux-2.2-4.fc9.ppc64 requires /sbin/restorecon mod_nss-1.0.7-4.fc10.ppc64 requires /bin/sh mod_nss-1.0.7-4.fc10.ppc64 requires /bin/bash mod_perl-2.0.4-3.ppc64 requires /usr/bin/perl mod_revocator-1.0.2-4.fc9.ppc64 requires /sbin/ldconfig 1:mod_ssl-2.2.8-3.ppc64 requires /bin/sh 1:mod_ssl-2.2.8-3.ppc64 requires /bin/cat modello-1.0-0.1.a8.4jpp.3.fc7.noarch requires /bin/sh modello-1.0-0.1.a8.4jpp.3.fc7.noarch requires /bin/sh modello-javadoc-1.0-0.1.a8.4jpp.3.fc7.noarch requires /bin/rm modello-javadoc-1.0-0.1.a8.4jpp.3.fc7.noarch requires /bin/ln module-init-tools-3.4-13.fc9.ppc64 requires /bin/sh module-init-tools-3.4-13.fc9.ppc64 requires /bin/bash module-init-tools-3.4-13.fc9.ppc64 requires /sbin/chkconfig module-init-tools-3.4-13.fc9.ppc64 requires /bin/sh mogilefsd-2.17-5.fc9.noarch requires /bin/sh mogilefsd-2.17-5.fc9.noarch requires /sbin/service mogilefsd-2.17-5.fc9.noarch requires /sbin/chkconfig mogilefsd-2.17-5.fc9.noarch requires /bin/bash mogilefsd-2.17-5.fc9.noarch requires /usr/bin/perl mogstored-2.17-5.fc9.noarch requires /bin/sh mogstored-2.17-5.fc9.noarch requires /sbin/service mogstored-2.17-5.fc9.noarch requires /usr/bin/perl mogstored-2.17-5.fc9.noarch requires /bin/bash mogstored-2.17-5.fc9.noarch requires /sbin/chkconfig moin-1.6.3-1.fc10.noarch requires /usr/bin/env moin-1.6.3-1.fc10.noarch requires /usr/bin/python moin-latex-0-0.20051126.3.fc6.noarch requires /usr/bin/python mona-examples-1.4r10-1.fc10.ppc64 requires /bin/sh mona-libs-1.4r10-1.fc10.ppc64 requires /sbin/ldconfig monit-4.10.1-7.fc9.ppc64 requires /bin/sh monit-4.10.1-7.fc9.ppc64 requires /bin/bash monit-4.10.1-7.fc9.ppc64 requires /sbin/chkconfig monit-4.10.1-7.fc9.ppc64 requires /sbin/service monitor-edid-1.16-4.fc9.ppc64 requires /usr/bin/perl monitor-edid-1.16-4.fc9.ppc64 requires /bin/sh monkey-bubble-0.4.0-9.fc9.ppc64 requires /bin/sh monotone-0.39-1.fc9.ppc64 requires /bin/sh monotone-0.39-1.fc9.ppc64 requires /sbin/install-info monotone-server-0.39-1.fc9.ppc64 requires /bin/sh monotone-server-0.39-1.fc9.ppc64 requires /sbin/chkconfig monotone-server-0.39-1.fc9.ppc64 requires /bin/sh monotone-server-0.39-1.fc9.ppc64 requires /sbin/service monsterz-0.7.1-3.fc9.ppc64 requires /bin/sh monsterz-0.7.1-3.fc9.ppc64 requires /usr/bin/env moodle-1.9-1.fc9.noarch requires /bin/sh moodle-1.9-1.fc9.noarch requires /usr/bin/perl moodle-1.9-1.fc9.noarch requires /bin/bash moodle-1.9-1.fc9.noarch requires /sbin/chkconfig moodle-1.9-1.fc9.noarch requires /usr/bin/php moodle-1.9-1.fc9.noarch requires /bin/sh moodle-1.9-1.fc9.noarch requires /sbin/service moodss-21.5-3.fc9.ppc64 requires /usr/bin/env moomps-5.8-3.fc9.ppc64 requires /bin/bash moomps-5.8-3.fc9.ppc64 requires /bin/sh moomps-5.8-3.fc9.ppc64 requires /sbin/chkconfig moomps-5.8-3.fc9.ppc64 requires /usr/bin/tclsh moomps-5.8-3.fc9.ppc64 requires /sbin/service moreutils-0.28-3.fc9.ppc64 requires /usr/bin/perl mousepad-0.2.13-2.fc9.ppc64 requires /bin/sh mousetweaks-2.23.2-3.fc10.ppc64 requires /bin/sh mozilla-opensc-signer-0.11.4-4.fc9.ppc64 requires /usr/lib64/mozilla/plugins mozldap-6.0.5-2.fc9.ppc64 requires /sbin/ldconfig mpc-0.12.1-2.fc9.ppc64 requires /bin/sh mpfr-2.3.0-3.fc9.ppc64 requires /sbin/ldconfig mpfr-devel-2.3.0-3.fc9.ppc64 requires /bin/sh mpfr-devel-2.3.0-3.fc9.ppc64 requires /sbin/install-info mrtg-2.16.1-2.fc10.ppc64 requires /bin/sh mrtg-2.16.1-2.fc10.ppc64 requires /sbin/service mrtg-2.16.1-2.fc10.ppc64 requires /usr/bin/perl mrtg-2.16.1-2.fc10.ppc64 requires /bin/sh msmtp-1.4.13-4.fc9.ppc64 requires /bin/sh msmtp-1.4.13-4.fc9.ppc64 requires /sbin/install-info 1:mt-daapd-0.2.4.2-2.fc10.ppc64 requires /bin/sh 1:mt-daapd-0.2.4.2-2.fc10.ppc64 requires /usr/sbin/useradd 1:mt-daapd-0.2.4.2-2.fc10.ppc64 requires /sbin/service 1:mt-daapd-0.2.4.2-2.fc10.ppc64 requires /bin/bash 1:mt-daapd-0.2.4.2-2.fc10.ppc64 requires /sbin/chkconfig mtd-utils-1.1.0-2.fc8.ppc64 requires /usr/bin/perl mtools-3.9.11-4.fc9.ppc64 requires /bin/sh mtools-3.9.11-4.fc9.ppc64 requires /bin/sh mtpaint-3.20-3.fc9.ppc64 requires /bin/sh mtx-1.3.11-3.fc9.ppc64 requires /bin/sh muParser-1.28-4.fc9.ppc64 requires /sbin/ldconfig mugshot-1.1.95-1.fc9.ppc64 requires /bin/sh mugshot-1.1.95-1.fc9.ppc64 requires /usr/bin/python mugshot-1.1.95-1.fc9.ppc64 requires /bin/sh multican-0.0.5-4.fc9.ppc64 requires /sbin/ldconfig munin-1.2.5-4.fc9.noarch requires /bin/sh munin-1.2.5-4.fc9.noarch requires /usr/bin/perl munin-1.2.5-4.fc9.noarch requires /bin/sh munin-node-1.2.5-4.fc9.noarch requires /bin/sh munin-node-1.2.5-4.fc9.noarch requires /usr/bin/env munin-node-1.2.5-4.fc9.noarch requires /sbin/service munin-node-1.2.5-4.fc9.noarch requires /bin/bash munin-node-1.2.5-4.fc9.noarch requires /bin/sh munin-node-1.2.5-4.fc9.noarch requires /usr/bin/perl munin-node-1.2.5-4.fc9.noarch requires /sbin/chkconfig munipack-0.3.1-3.fc9.ppc64 requires /bin/sh museek+-0.1.13-3.fc9.ppc64 requires /usr/bin/env museek+-0.1.13-3.fc9.ppc64 requires /usr/bin/python musicbox-0.2.3-6.fc9.ppc64 requires /usr/bin/perl mussh-0.7-2.fc8.noarch requires /bin/bash 5:mutt-1.5.17-4.fc9.ppc64 requires /usr/bin/perl 1:mx4j-3.0.1-6jpp.4.ppc64 requires /bin/sh 1:mx4j-3.0.1-6jpp.4.ppc64 requires /usr/sbin/update-alternatives 1:mx4j-3.0.1-6jpp.4.ppc64 requires /bin/rm 1:mx4j-javadoc-3.0.1-6jpp.4.ppc64 requires /bin/sh 1:mx4j-javadoc-3.0.1-6jpp.4.ppc64 requires /bin/rm 1:mx4j-javadoc-3.0.1-6jpp.4.ppc64 requires /bin/ln mxml-2.2.2-8.fc9.ppc64 requires /sbin/ldconfig mybashburn-1.0.2-3.fc8.noarch requires /usr/bin/env mybashburn-1.0.2-3.fc8.noarch requires /bin/sh mypaint-0.5.0-7.fc9.ppc64 requires /usr/bin/env mysql-5.0.51a-1.fc9.ppc64 requires /bin/sh mysql-5.0.51a-1.fc9.ppc64 requires /sbin/install-info mysql-5.0.51a-1.fc9.ppc64 requires /usr/bin/perl mysql-5.0.51a-1.fc9.ppc64 requires /bin/sh mysql++-3.0.3-1.fc10.ppc64 requires /sbin/ldconfig mysql-administrator-5.0r12-5.fc9.ppc64 requires /bin/sh mysql-bench-5.0.51a-1.fc9.ppc64 requires /usr/bin/perl 1:mysql-connector-java-3.1.12-5.fc9.ppc64 requires /bin/sh mysql-connector-odbc-3.51.24r1071-1.fc9.ppc64 requires /sbin/ldconfig mysql-libs-5.0.51a-1.fc9.ppc64 requires /bin/sh mysql-libs-5.0.51a-1.fc9.ppc64 requires /sbin/ldconfig mysql-query-browser-5.0r12-5.fc9.ppc64 requires /bin/sh mysql-server-5.0.51a-1.fc9.ppc64 requires /bin/sh mysql-server-5.0.51a-1.fc9.ppc64 requires /usr/sbin/useradd mysql-server-5.0.51a-1.fc9.ppc64 requires /bin/bash mysql-server-5.0.51a-1.fc9.ppc64 requires /bin/sh mysql-server-5.0.51a-1.fc9.ppc64 requires /usr/bin/perl mysql-server-5.0.51a-1.fc9.ppc64 requires /sbin/chkconfig mysql-test-5.0.51a-1.fc9.ppc64 requires /usr/bin/perl mysql-test-5.0.51a-1.fc9.ppc64 requires /bin/sh mytop-1.6-2.fc9.noarch requires /usr/bin/perl nabi-0.18-9.fc9.ppc64 requires /bin/sh nabi-0.18-9.fc9.ppc64 requires /usr/sbin/alternatives nafees-web-naskh-fonts-1.0-1.fc8.noarch requires /bin/sh nagios-2.11-3.fc9.ppc64 requires /bin/sh nagios-2.11-3.fc9.ppc64 requires /usr/bin/perl nagios-2.11-3.fc9.ppc64 requires /bin/sh nagios-plugins-1.4.11-4.fc10.ppc64 requires /bin/sh nagios-plugins-breeze-1.4.11-4.fc10.ppc64 requires /usr/bin/perl nagios-plugins-by_ssh-1.4.11-4.fc10.ppc64 requires /usr/bin/ssh nagios-plugins-dig-1.4.11-4.fc10.ppc64 requires /usr/bin/dig nagios-plugins-disk_smb-1.4.11-4.fc10.ppc64 requires /usr/bin/smbclient nagios-plugins-disk_smb-1.4.11-4.fc10.ppc64 requires /usr/bin/perl nagios-plugins-dns-1.4.11-4.fc10.ppc64 requires /usr/bin/nslookup nagios-plugins-file_age-1.4.11-4.fc10.ppc64 requires /usr/bin/perl nagios-plugins-flexlm-1.4.11-4.fc10.ppc64 requires /usr/bin/perl nagios-plugins-fping-1.4.11-4.fc10.ppc64 requires /usr/sbin/fping nagios-plugins-ifoperstatus-1.4.11-4.fc10.ppc64 requires /usr/bin/perl nagios-plugins-ifstatus-1.4.11-4.fc10.ppc64 requires /usr/bin/perl nagios-plugins-ircd-1.4.11-4.fc10.ppc64 requires /usr/bin/perl nagios-plugins-linux_raid-1.4.11-4.fc10.ppc64 requires /usr/bin/perl nagios-plugins-log-1.4.11-4.fc10.ppc64 requires /bin/egrep nagios-plugins-log-1.4.11-4.fc10.ppc64 requires /bin/mktemp nagios-plugins-log-1.4.11-4.fc10.ppc64 requires /bin/sh nagios-plugins-mailq-1.4.11-4.fc10.ppc64 requires /usr/bin/perl nagios-plugins-ntp-1.4.11-4.fc10.ppc64 requires /usr/sbin/ntpq nagios-plugins-ntp-1.4.11-4.fc10.ppc64 requires /usr/sbin/ntpdc nagios-plugins-ntp-1.4.11-4.fc10.ppc64 requires /usr/sbin/ntpdate nagios-plugins-oracle-1.4.11-4.fc10.ppc64 requires /bin/sh nagios-plugins-ping-1.4.11-4.fc10.ppc64 requires /bin/ping nagios-plugins-ping-1.4.11-4.fc10.ppc64 requires /bin/ping6 nagios-plugins-rpc-1.4.11-4.fc10.ppc64 requires /usr/bin/perl nagios-plugins-rpc-1.4.11-4.fc10.ppc64 requires /usr/sbin/rpcinfo nagios-plugins-snmp-1.4.11-4.fc10.ppc64 requires /usr/bin/snmpget nagios-plugins-snmp-1.4.11-4.fc10.ppc64 requires /usr/bin/snmpgetnext nagios-plugins-wave-1.4.11-4.fc10.ppc64 requires /usr/bin/perl naim-0.11.8.3.1-6.fc9.ppc64 requires /bin/sh namazu-2.0.18-1.fc9.ppc64 requires /usr/bin/perl namazu-devel-2.0.18-1.fc9.ppc64 requires /bin/sh namazu-libs-2.0.18-1.fc9.ppc64 requires /sbin/ldconfig nano-2.0.6-4.fc9.ppc64 requires /bin/sh nano-2.0.6-4.fc9.ppc64 requires /sbin/install-info nas-1.9.1-4.fc9.ppc64 requires /bin/sh nas-1.9.1-4.fc9.ppc64 requires /sbin/service nas-1.9.1-4.fc9.ppc64 requires /bin/bash nas-1.9.1-4.fc9.ppc64 requires /bin/sh nas-1.9.1-4.fc9.ppc64 requires /usr/bin/perl nas-libs-1.9.1-4.fc9.ppc64 requires /sbin/ldconfig nash-6.0.52-2.fc9.ppc64 requires /bin/bash nasm-2.01-2.fc9.ppc64 requires /bin/sh nasm-2.01-2.fc9.ppc64 requires /sbin/install-info naturette-1.3-1.fc8.noarch requires /bin/sh naturette-1.3-1.fc8.noarch requires /bin/bash nautilus-2.23.2-2.fc10.ppc64 requires /bin/sh nautilus-actions-1.4.1-3.fc9.ppc64 requires /bin/sh nautilus-cd-burner-2.22.1-1.fc9.ppc64 requires /bin/sh nautilus-open-terminal-0.9-2.fc9.ppc64 requires /bin/sh nautilus-python-0.4.3-5.fc9.ppc64 requires /sbin/ldconfig nautilus-sendto-0.14.0-4.fc10.ppc64 requires /bin/sh nazghul-haxima-0.6.0-4.20080407cvs.fc9.ppc64 requires /bin/sh nbd-2.9.10-1.fc9.ppc64 requires /bin/sh nc-1.84-16.fc9.ppc64 requires /bin/sh ncl-5.0.0-11.fc9.ppc64 requires /bin/csh ncl-devel-5.0.0-11.fc9.ppc64 requires /bin/csh ncl-examples-5.0.0-11.fc9.ppc64 requires /bin/csh nco-3.9.3-1.fc9.ppc64 requires /bin/sh ncpfs-2.2.6-10.fc9.ppc64 requires /sbin/ldconfig ncurses-devel-5.6-16.20080301.fc9.ppc64 requires /bin/sh ncurses-libs-5.6-16.20080301.fc9.ppc64 requires /sbin/ldconfig neXtaw-0.15.1-12.fc9.ppc64 requires /sbin/ldconfig nedit-5.5-18.fc9.ppc64 requires /bin/sh nekohtml-0.9.5-4jpp.1.fc7.noarch requires /bin/sh nemiver-0.5.2-1.fc9.ppc64 requires /bin/sh neon-0.28.2-2.ppc64 requires /sbin/ldconfig neon-devel-0.28.2-2.ppc64 requires /bin/sh nessus-core-2.2.10-4.fc9.ppc64 requires /bin/sh nessus-libraries-2.2.10-3.fc9.ppc64 requires /sbin/ldconfig nessus-libraries-devel-2.2.10-3.fc9.ppc64 requires /bin/sh nessus-server-2.2.10-4.fc9.ppc64 requires /bin/sh nessus-server-2.2.10-4.fc9.ppc64 requires /sbin/service nessus-server-2.2.10-4.fc9.ppc64 requires /sbin/chkconfig nessus-server-2.2.10-4.fc9.ppc64 requires /bin/sh 1:net-snmp-5.4.1-15.fc10.ppc64 requires /bin/sh 1:net-snmp-5.4.1-15.fc10.ppc64 requires /bin/bash 1:net-snmp-5.4.1-15.fc10.ppc64 requires /bin/sh 1:net-snmp-5.4.1-15.fc10.ppc64 requires /usr/bin/perl 1:net-snmp-devel-5.4.1-15.fc10.ppc64 requires /bin/sh 1:net-snmp-gui-5.4.1-15.fc10.ppc64 requires /usr/bin/perl 1:net-snmp-libs-5.4.1-15.fc10.ppc64 requires /sbin/ldconfig 1:net-snmp-perl-5.4.1-15.fc10.ppc64 requires /usr/bin/perl 1:net-snmp-perl-5.4.1-15.fc10.ppc64 requires /bin/bash 1:net-snmp-utils-5.4.1-15.fc10.ppc64 requires /usr/bin/perl net-tools-1.60-87.fc9.ppc64 requires /bin/sh net-tools-1.60-87.fc9.ppc64 requires /sbin/chkconfig net-tools-1.60-87.fc9.ppc64 requires /bin/sh net-tools-1.60-87.fc9.ppc64 requires /sbin/service net6-1.3.5-3.fc9.ppc64 requires /sbin/ldconfig 4:netatalk-2.0.3-19.fc9.ppc64 requires /bin/sh 4:netatalk-2.0.3-19.fc9.ppc64 requires /sbin/service 4:netatalk-2.0.3-19.fc9.ppc64 requires /sbin/ldconfig 4:netatalk-2.0.3-19.fc9.ppc64 requires /usr/bin/perl 4:netatalk-2.0.3-19.fc9.ppc64 requires /bin/sh 4:netatalk-2.0.3-19.fc9.ppc64 requires /sbin/chkconfig 4:netatalk-devel-2.0.3-19.fc9.ppc64 requires /bin/sh netcdf-4.0.0-0.4.beta2.fc10.ppc64 requires /bin/sh netcdf-perl-1.2.3-7.fc9.ppc64 requires /usr/bin/perl netdump-server-0.7.16-22.fc9.ppc64 requires /bin/sh netdump-server-0.7.16-22.fc9.ppc64 requires /usr/bin/ssh-keygen netdump-server-0.7.16-22.fc9.ppc64 requires /usr/bin/ssh netdump-server-0.7.16-22.fc9.ppc64 requires /bin/sh netdump-server-0.7.16-22.fc9.ppc64 requires /sbin/ifconfig netdump-server-0.7.16-22.fc9.ppc64 requires /sbin/service netembryo-0.0.5-2.fc9.ppc64 requires /sbin/ldconfig netgen-1.3.7-15.fc9.ppc64 requires /bin/sh netgen-1.3.7-15.fc9.ppc64 requires /bin/csh netgen-1.3.7-15.fc9.ppc64 requires /bin/sh netgo-0.5-10.fc9.ppc64 requires /bin/sh nethack-3.4.3-17.fc9.ppc64 requires /bin/sh nethack-3.4.3-17.fc9.ppc64 requires /bin/sh nethack-vultures-2.1.0-10.fc8.ppc64 requires /bin/sh nethack-vultures-2.1.0-10.fc8.ppc64 requires /usr/bin/bzip2 nethack-vultures-2.1.0-10.fc8.ppc64 requires /usr/sbin/groupadd nethack-vultures-2.1.0-10.fc8.ppc64 requires /bin/sh netlabel_tools-0.17-7.fc9.ppc64 requires /bin/sh netmask-2.3.9-3.fc9.ppc64 requires /bin/sh netmask-2.3.9-3.fc9.ppc64 requires /sbin/install-info netpanzer-0.8.2-3.fc9.ppc64 requires /bin/sh netpbm-10.35.43-1.fc10.ppc64 requires /sbin/ldconfig netpbm-progs-10.35.43-1.fc10.ppc64 requires /usr/bin/perl netpbm-progs-10.35.43-1.fc10.ppc64 requires /bin/sh nettle-1.15-4.fc9.ppc64 requires /bin/sh nettle-1.15-4.fc9.ppc64 requires /sbin/ldconfig nettle-1.15-4.fc9.ppc64 requires /sbin/install-info newscache-1.2-0.6.rc6.fc9.ppc64 requires /bin/sh newscache-1.2-0.6.rc6.fc9.ppc64 requires /sbin/service newscache-1.2-0.6.rc6.fc9.ppc64 requires /bin/bash newscache-1.2-0.6.rc6.fc9.ppc64 requires /sbin/chkconfig newsx-1.6-8.fc9.ppc64 requires /bin/sh newt-0.52.9-1.fc9.ppc64 requires /sbin/ldconfig nexcontrol-0.2-1.fc9.noarch requires /usr/bin/perl nexuiz-2.4-1.fc10.ppc64 requires /bin/sh 1:nfs-utils-1.1.2-5.fc10.ppc64 requires /bin/sh 1:nfs-utils-1.1.2-5.fc10.ppc64 requires /bin/sh 1:nfs-utils-1.1.2-5.fc10.ppc64 requires /sbin/nologin 1:nfs-utils-1.1.2-5.fc10.ppc64 requires /bin/bash 1:nfs-utils-1.1.2-5.fc10.ppc64 requires /sbin/chkconfig nfs-utils-lib-1.1.1-3.fc9.ppc64 requires /sbin/ldconfig nginx-0.6.31-1.fc10.ppc64 requires /bin/sh nginx-0.6.31-1.fc10.ppc64 requires /bin/sh ngspice-doc-17-14.fc9.ppc64 requires /bin/sh ngspice-doc-17-14.fc9.ppc64 requires /sbin/install-info nikto-1.36-3.fc8.noarch requires /usr/bin/perl nip2-7.14.1-1.fc9.ppc64 requires /bin/sh nip2-7.14.1-1.fc9.ppc64 requires libMagick.so.10()(64bit) nip2-7.14.1-1.fc9.ppc64 requires /bin/bash nip2-7.14.1-1.fc9.ppc64 requires libWand.so.10()(64bit) njam-1.25-9.fc9.ppc64 requires /bin/sh 2:nmap-frontend-4.62-1.fc10.ppc64 requires /usr/bin/python nmh-1.3-RC1.1.fc10.ppc64 requires /bin/sh nntpgrab-core-0.2.90-1.fc10.ppc64 requires /sbin/ldconfig nogravity-2.00-6.fc9.ppc64 requires /bin/sh nogravity-2.00-6.fc9.ppc64 requires /bin/bash notecase-1.6.1-4.fc9.ppc64 requires /bin/sh notification-daemon-0.3.7-9.fc9.ppc64 requires /bin/sh nqc-3.1.6-2.fc9.ppc64 requires /bin/sh nqc-3.1.6-2.fc9.ppc64 requires /usr/sbin/groupadd nrpe-2.7-6.fc9.ppc64 requires /bin/sh nrpe-2.7-6.fc9.ppc64 requires /sbin/chkconfig nrpe-2.7-6.fc9.ppc64 requires /usr/sbin/useradd nrpe-2.7-6.fc9.ppc64 requires /bin/sh nrpe-2.7-6.fc9.ppc64 requires /sbin/service nsca-2.7.2-6.fc9.ppc64 requires /bin/sh nsca-2.7.2-6.fc9.ppc64 requires /sbin/chkconfig nsca-2.7.2-6.fc9.ppc64 requires /bin/sh nsca-2.7.2-6.fc9.ppc64 requires /sbin/service nscd-2.8.90-2.ppc64 requires /usr/sbin/userdel nscd-2.8.90-2.ppc64 requires /bin/sh nscd-2.8.90-2.ppc64 requires /usr/sbin/useradd nscd-2.8.90-2.ppc64 requires /bin/bash nscd-2.8.90-2.ppc64 requires /sbin/chkconfig nsd-3.0.7-3.fc9.ppc64 requires /bin/sh nsd-3.0.7-3.fc9.ppc64 requires /bin/bash nsd-3.0.7-3.fc9.ppc64 requires /bin/sh nspr-4.7.0.99.2-2.fc9.ppc64 requires /bin/sh nspr-devel-4.7.0.99.2-2.fc9.ppc64 requires /bin/sh nss-3.11.99.5-2.fc9.ppc64 requires /bin/sh nss-devel-3.11.99.5-2.fc9.ppc64 requires /bin/sh nss-mdns-0.10-4.fc9.ppc64 requires /bin/sh nss-mdns-0.10-4.fc9.ppc64 requires /sbin/ldconfig nss_compat_ossl-0.9.2-4.fc9.ppc64 requires /sbin/ldconfig nss_db-2.2-40.fc9.ppc64 requires /sbin/ldconfig nss_ldap-259-3.fc9.ppc64 requires /bin/sh nss_ldap-259-3.fc9.ppc64 requires /sbin/ldconfig 2:ntfs-3g-1.2506-1.fc10.ppc64 requires /sbin/ldconfig ntfs-config-1.0-0.6.rc5.fc9.noarch requires /usr/bin/python2.5 ntp-4.2.4p4-6.fc9.ppc64 requires /bin/sh ntp-4.2.4p4-6.fc9.ppc64 requires /sbin/service ntp-4.2.4p4-6.fc9.ppc64 requires /bin/bash ntp-4.2.4p4-6.fc9.ppc64 requires /usr/bin/perl ntp-4.2.4p4-6.fc9.ppc64 requires /sbin/chkconfig numactl-2.0.0-1.fc10.ppc64 requires /sbin/ldconfig numactl-2.0.0-1.fc10.ppc64 requires /usr/bin/perl numlockx-1.0-14.fc9.ppc64 requires /bin/sh numpy-1.0.3.1-2.fc9.ppc64 requires /usr/bin/env nut-2.2.2-1.fc10.ppc64 requires /bin/sh nut-2.2.2-1.fc10.ppc64 requires /sbin/service nut-2.2.2-1.fc10.ppc64 requires /sbin/chkconfig nut-cgi-2.2.2-1.fc10.ppc64 requires /bin/sh nut-client-2.2.2-1.fc10.ppc64 requires /bin/sh nut-client-2.2.2-1.fc10.ppc64 requires /bin/bash nut-client-2.2.2-1.fc10.ppc64 requires /usr/sbin/useradd nut-client-2.2.2-1.fc10.ppc64 requires /bin/sh nvclock-gtk-0.8-0.6.b3a.fc10.ppc64 requires /bin/sh nx-3.2.0-27.fc9.ppc64 requires /bin/bash nx-3.2.0-27.fc9.ppc64 requires /bin/sh nyquist-2.37-2.fc9.ppc64 requires /bin/sh obby-0.4.4-3.fc9.ppc64 requires /sbin/ldconfig obconf-2.0.3-2.fc10.ppc64 requires /bin/sh obexftp-0.22-0.9.rc9.fc9.ppc64 requires /sbin/ldconfig obmenu-1.0-6.fc9.noarch requires /usr/bin/python ocaml-3.10.2-2.fc10.ppc64 requires /bin/sh ocaml-3.10.2-2.fc10.ppc64 requires /usr/bin/ocamlrun ocaml-camlidl-1.05-5.fc10.ppc64 requires /usr/bin/ocamlrun ocaml-camlp4-devel-3.10.2-2.fc10.ppc64 requires /usr/bin/ocamlrun ocaml-camlp5-devel-5.08-3.fc10.ppc64 requires /bin/sh ocaml-camlp5-devel-5.08-3.fc10.ppc64 requires /usr/bin/ocamlrun ocaml-deriving-0.1.1a-3.fc10.ppc64 requires /usr/bin/ocamlrun ocaml-docs-3.10.2-2.fc10.ppc64 requires /bin/sh ocaml-docs-3.10.2-2.fc10.ppc64 requires /sbin/install-info ocaml-findlib-1.2.1-3.fc10.ppc64 requires /bin/sh ocaml-findlib-devel-1.2.1-3.fc10.ppc64 requires /usr/bin/ocamlrun ocaml-gettext-devel-0.3.0-1.fc10.ppc64 requires /usr/bin/ocamlrun ocaml-gsl-devel-0.6.0-3.fc10.ppc64 requires /bin/sh ocaml-gsl-devel-0.6.0-3.fc10.ppc64 requires /sbin/install-info ocaml-lablgl-1.03-4.fc10.ppc64 requires /bin/sh ocaml-lablgtk-2.10.1-2.fc10.ppc64 requires /bin/sh ocaml-lablgtk-2.10.1-2.fc10.ppc64 requires /usr/bin/ocamlrun ocaml-lablgtk-devel-2.10.1-2.fc10.ppc64 requires /usr/bin/ocamlrun ocaml-labltk-3.10.2-2.fc10.ppc64 requires /bin/sh ocaml-labltk-devel-3.10.2-2.fc10.ppc64 requires /usr/bin/wish ocaml-labltk-devel-3.10.2-2.fc10.ppc64 requires /usr/bin/ocamlrun ocaml-ocamldoc-3.10.2-2.fc10.ppc64 requires /usr/bin/ocamlrun ocaml-perl4caml-0.9.5-5.fc10.ppc64 requires /usr/lib64/perl5/5.10.0/ppc64-linux-thread-multi/CORE/libperl.so ocaml-runtime-3.10.2-2.fc10.ppc64 requires /bin/sh ocfs2-tools-1.3.9-7.20080221git.fc8.ppc64 requires /bin/sh ocfs2-tools-1.3.9-7.20080221git.fc8.ppc64 requires /sbin/service ocfs2-tools-1.3.9-7.20080221git.fc8.ppc64 requires /bin/bash ocfs2console-1.3.9-7.20080221git.fc8.ppc64 requires /usr/bin/python ochusha-0.5.99.66-0.4.cvs070110.fc9.2.ppc64 requires /bin/sh ochusha-0.5.99.66-0.4.cvs070110.fc9.2.ppc64 requires /etc/pki/tls/cert.pem ocrad-0.17-3.fc9.ppc64 requires /bin/sh ocrad-0.17-3.fc9.ppc64 requires /sbin/install-info ocsinventory-agent-0.0.9.2-1.fc10.noarch requires /etc/logrotate.d ocsinventory-agent-0.0.9.2-1.fc10.noarch requires /usr/bin/perl ocsinventory-agent-0.0.9.2-1.fc10.noarch requires /etc/cron.hourly ocsinventory-agent-0.0.9.2-1.fc10.noarch requires /bin/bash 6:octave-3.0.1-1.fc10.ppc64 requires /bin/sh 6:octave-3.0.1-1.fc10.ppc64 requires /sbin/install-info 6:octave-3.0.1-1.fc10.ppc64 requires /sbin/ldconfig 6:octave-3.0.1-1.fc10.ppc64 requires /bin/sh 6:octave-devel-3.0.1-1.fc10.ppc64 requires /bin/sh octave-forge-20080429-6.fc10.ppc64 requires /bin/sh octave-forge-20080429-6.fc10.ppc64 requires /bin/sh odccm-0.11-2.fc9.ppc64 requires /bin/sh odccm-0.11-2.fc9.ppc64 requires /sbin/service odccm-0.11-2.fc9.ppc64 requires /sbin/chkconfig odccm-0.11-2.fc9.ppc64 requires /bin/bash oddjob-0.29-2.fc9.ppc64 requires /bin/sh oddjob-0.29-2.fc9.ppc64 requires /bin/bash oddjob-0.29-2.fc9.ppc64 requires /sbin/chkconfig oddjob-0.29-2.fc9.ppc64 requires /bin/sh oddjob-0.29-2.fc9.ppc64 requires /sbin/service oddjob-libs-0.29-2.fc9.ppc64 requires /sbin/ldconfig oddjob-mkhomedir-0.29-2.fc9.ppc64 requires /bin/sh ode-0.9-4.fc9.ppc64 requires /sbin/ldconfig ode-devel-0.9-4.fc9.ppc64 requires /bin/sh offlineimap-5.99.7-1.fc9.noarch requires /usr/bin/python ogdi-3.2.0-0.8.beta1.fc9.ppc64 requires /sbin/ldconfig ogdi-devel-3.2.0-0.8.beta1.fc9.ppc64 requires /bin/sh oggconvert-0.3.0-14.fc9.noarch requires /usr/bin/python ogre-1.4.8-1.fc10.ppc64 requires /sbin/ldconfig ogre-samples-1.4.8-1.fc10.ppc64 requires /bin/bash oidentd-2.0.8-5.fc9.ppc64 requires /bin/sh oidentd-2.0.8-5.fc9.ppc64 requires /sbin/chkconfig oidentd-2.0.8-5.fc9.ppc64 requires /bin/sh oidentd-2.0.8-5.fc9.ppc64 requires /sbin/service ois-1.0-4.fc9.ppc64 requires /sbin/ldconfig oki4linux-2.1gst-3.fc9.ppc64 requires /bin/sh oki4linux-2.1gst-3.fc9.ppc64 requires /usr/bin/perl oki4linux-2.1gst-3.fc9.ppc64 requires /sbin/chkconfig oki4linux-2.1gst-3.fc9.ppc64 requires /bin/sh oniguruma-5.9.1-1.fc9.2.ppc64 requires /sbin/ldconfig oniguruma-devel-5.9.1-1.fc9.2.ppc64 requires /bin/sh online-desktop-0.2.28-1.fc10.ppc64 requires /bin/sh online-desktop-0.2.28-1.fc10.ppc64 requires /usr/bin/env online-desktop-0.2.28-1.fc10.ppc64 requires /usr/bin/python online-desktop-0.2.28-1.fc10.ppc64 requires /bin/sh online-desktop-flickr-0.2.28-1.fc10.ppc64 requires /bin/sh online-desktop-gmail-0.2.28-1.fc10.ppc64 requires /bin/sh online-desktop-google-calendar-0.2.28-1.fc10.ppc64 requires /bin/sh online-desktop-google-docs-0.2.28-1.fc10.ppc64 requires /bin/sh online-desktop-google-reader-0.2.28-1.fc10.ppc64 requires /bin/sh ooo2txt-0.0.6-3.fc9.noarch requires /usr/bin/perl oooqs2-1.0-3.fc6.ppc64 requires /bin/sh opal-2.2.11-4.fc10.ppc64 requires /sbin/ldconfig openais-0.83-2.fc10.ppc64 requires /bin/sh openais-0.83-2.fc10.ppc64 requires /usr/sbin/useradd openais-0.83-2.fc10.ppc64 requires /bin/sh openais-0.83-2.fc10.ppc64 requires /sbin/chkconfig openal-0.0.9-0.15.20060204cvs.fc9.ppc64 requires /sbin/ldconfig openal-devel-0.0.9-0.15.20060204cvs.fc9.ppc64 requires /bin/sh openarena-0.7.6-1.fc10.noarch requires /bin/bash openbabel-2.2.0-0.3.b4.fc10.ppc64 requires /sbin/ldconfig openbox-3.4.7.2-1.fc10.ppc64 requires /usr/bin/env openbox-3.4.7.2-1.fc10.ppc64 requires /bin/sh openbox-libs-3.4.7.2-1.fc10.ppc64 requires /sbin/ldconfig opencdk-0.6.6-1.fc9.ppc64 requires /sbin/ldconfig opencdk-devel-0.6.6-1.fc9.ppc64 requires /bin/sh openct-0.6.14-4.fc9.ppc64 requires /bin/sh openct-0.6.14-4.fc9.ppc64 requires /sbin/ldconfig openct-0.6.14-4.fc9.ppc64 requires /usr/lib64/ctapi openct-0.6.14-4.fc9.ppc64 requires /sbin/chkconfig openct-0.6.14-4.fc9.ppc64 requires /bin/sh opencv-1.0.0-8.fc10.ppc64 requires /sbin/ldconfig opencv-python-1.0.0-8.fc10.ppc64 requires /usr/bin/env opencv-python-1.0.0-8.fc10.ppc64 requires /usr/bin/python opencv-python-1.0.0-8.fc10.ppc64 requires /sbin/ldconfig opengl-games-utils-0.1-5.fc9.noarch requires /bin/bash opengrok-0.6-9.hg275.fc9.noarch requires /bin/sh openhpi-2.10.2-1.fc9.ppc64 requires /bin/sh openhpi-2.10.2-1.fc9.ppc64 requires /sbin/service openhpi-2.10.2-1.fc9.ppc64 requires /sbin/chkconfig openhpi-2.10.2-1.fc9.ppc64 requires /bin/bash openhpi-2.10.2-1.fc9.ppc64 requires /bin/sh openhpi-libs-2.10.2-1.fc9.ppc64 requires /sbin/ldconfig openhpi-subagent-2.3.4-2.fc10.ppc64 requires /bin/sh openhpi-subagent-2.3.4-2.fc10.ppc64 requires /sbin/service openhpi-subagent-2.3.4-2.fc10.ppc64 requires /sbin/chkconfig openhpi-subagent-2.3.4-2.fc10.ppc64 requires /bin/sh openjade-1.3.2-31.fc9.ppc64 requires /bin/sh openjade-1.3.2-31.fc9.ppc64 requires /sbin/ldconfig openjpeg-libs-1.3-2.fc9.ppc64 requires /sbin/ldconfig openldap-2.4.9-4.fc10.ppc64 requires /sbin/ldconfig openldap-devel-2.4.9-4.fc10.ppc64 requires /sbin/ldconfig openldap-servers-2.4.9-4.fc10.ppc64 requires /sbin/runuser openldap-servers-2.4.9-4.fc10.ppc64 requires /bin/sh openldap-servers-2.4.9-4.fc10.ppc64 requires /sbin/chkconfig openldap-servers-2.4.9-4.fc10.ppc64 requires /usr/sbin/useradd openldap-servers-2.4.9-4.fc10.ppc64 requires /bin/bash openlierox-0.57-0.9.beta5.fc9.ppc64 requires /bin/sh openlierox-0.57-0.9.beta5.fc9.ppc64 requires /bin/bash openmpi-1.2.4-2.fc9.ppc64 requires /bin/sh openmpi-1.2.4-2.fc9.ppc64 requires /sbin/ldconfig openmpi-1.2.4-2.fc9.ppc64 requires /usr/sbin/alternatives openmpi-devel-1.2.4-2.fc9.ppc64 requires /bin/sh openmpi-devel-1.2.4-2.fc9.ppc64 requires /sbin/ldconfig openmpi-devel-1.2.4-2.fc9.ppc64 requires /usr/sbin/alternatives openmpi-libs-1.2.4-2.fc9.ppc64 requires /bin/sh openmpi-libs-1.2.4-2.fc9.ppc64 requires /sbin/ldconfig openmpi-libs-1.2.4-2.fc9.ppc64 requires /usr/sbin/alternatives openmsx-0.6.3-3.fc9.ppc64 requires /bin/sh openmsx-0.6.3-3.fc9.ppc64 requires /usr/bin/env openobex-1.3-11.fc9.ppc64 requires /sbin/ldconfig 1:openoffice.org-base-3.0.0-0.0.12.1.fc10.ppc64 requires /bin/sh 1:openoffice.org-base-3.0.0-0.0.12.1.fc10.ppc64 requires /bin/sh 1:openoffice.org-brand-3.0.0-0.0.12.1.fc10.ppc64 requires /bin/sh 1:openoffice.org-brand-3.0.0-0.0.12.1.fc10.ppc64 requires /bin/sh 1:openoffice.org-calc-3.0.0-0.0.12.1.fc10.ppc64 requires /bin/sh 1:openoffice.org-calc-3.0.0-0.0.12.1.fc10.ppc64 requires /bin/sh 1:openoffice.org-core-3.0.0-0.0.12.1.fc10.ppc64 requires /bin/sh 1:openoffice.org-core-3.0.0-0.0.12.1.fc10.ppc64 requires /bin/sh 1:openoffice.org-devel-3.0.0-0.0.12.1.fc10.ppc64 requires /usr/bin/perl 1:openoffice.org-devel-3.0.0-0.0.12.1.fc10.ppc64 requires /usr/bin/python 1:openoffice.org-devel-3.0.0-0.0.12.1.fc10.ppc64 requires /bin/bash 1:openoffice.org-devel-3.0.0-0.0.12.1.fc10.ppc64 requires /bin/sh 1:openoffice.org-draw-3.0.0-0.0.12.1.fc10.ppc64 requires /bin/sh 1:openoffice.org-draw-3.0.0-0.0.12.1.fc10.ppc64 requires /bin/sh openoffice.org-extendedPDF-1.4-4.fc9.noarch requires /bin/sh 1:openoffice.org-impress-3.0.0-0.0.12.1.fc10.ppc64 requires /bin/sh 1:openoffice.org-impress-3.0.0-0.0.12.1.fc10.ppc64 requires /bin/sh 1:openoffice.org-math-3.0.0-0.0.12.1.fc10.ppc64 requires /bin/sh 1:openoffice.org-math-3.0.0-0.0.12.1.fc10.ppc64 requires /bin/sh openoffice.org-ooolatex-4.0.0-0.5.beta2.fc9.noarch requires /bin/sh openoffice.org-ooolatex-4.0.0-0.5.beta2.fc9.noarch requires /usr/bin/dvips openoffice.org-ooolatex-4.0.0-0.5.beta2.fc9.noarch requires /usr/bin/latex 1:openoffice.org-presentation-minimizer-3.0.0-0.0.12.1.fc10.ppc64 requires /bin/sh 1:openoffice.org-presentation-minimizer-3.0.0-0.0.12.1.fc10.ppc64 requires openoffice.org-base-impress = 1:3.0.0-0.0.12.1.fc10 1:openoffice.org-presenter-screen-3.0.0-0.0.12.1.fc10.ppc64 requires /bin/sh 1:openoffice.org-presenter-screen-3.0.0-0.0.12.1.fc10.ppc64 requires openoffice.org-base-impress = 1:3.0.0-0.0.12.1.fc10 1:openoffice.org-report-builder-3.0.0-0.0.12.1.fc10.ppc64 requires /bin/sh 1:openoffice.org-sdk-3.0.0-0.0.12.1.fc10.ppc64 requires /bin/csh 1:openoffice.org-sdk-3.0.0-0.0.12.1.fc10.ppc64 requires /bin/sh 1:openoffice.org-ure-3.0.0-0.0.12.1.fc10.ppc64 requires /bin/sh openoffice.org-voikko-2.2-4.fc9.ppc64 requires /bin/sh 1:openoffice.org-writer-3.0.0-0.0.12.1.fc10.ppc64 requires /bin/sh 1:openoffice.org-writer-3.0.0-0.0.12.1.fc10.ppc64 requires /bin/sh openoffice.org-writer2latex-0.5-2.fc9.ppc64 requires /bin/sh opensc-0.11.4-4.fc9.ppc64 requires /sbin/ldconfig opensc-devel-0.11.4-4.fc9.ppc64 requires /bin/sh openser-1.3.2-2.fc10.ppc64 requires /bin/sh openser-1.3.2-2.fc10.ppc64 requires /bin/bash openslp-1.2.1-9.fc9.ppc64 requires /sbin/ldconfig openslp-server-1.2.1-9.fc9.ppc64 requires /bin/sh openslp-server-1.2.1-9.fc9.ppc64 requires /bin/bash openslp-server-1.2.1-9.fc9.ppc64 requires /sbin/service opensp-1.5.2-7.fc9.ppc64 requires /sbin/ldconfig openssh-5.0p1-1.fc9.ppc64 requires /sbin/nologin openssh-clients-5.0p1-1.fc9.ppc64 requires /bin/sh openssh-server-5.0p1-1.fc9.ppc64 requires /bin/sh openssh-server-5.0p1-1.fc9.ppc64 requires /lib64/security/pam_loginuid.so openssh-server-5.0p1-1.fc9.ppc64 requires /etc/pam.d/system-auth openssh-server-5.0p1-1.fc9.ppc64 requires /usr/sbin/useradd openssh-server-5.0p1-1.fc9.ppc64 requires /sbin/service openssh-server-5.0p1-1.fc9.ppc64 requires /bin/bash openssh-server-5.0p1-1.fc9.ppc64 requires /bin/sh openssl-0.9.8g-6.fc9.ppc64 requires /bin/sh openssl-0.9.8g-6.fc9.ppc64 requires /sbin/ldconfig openssl-perl-0.9.8g-6.fc9.ppc64 requires /usr/bin/perl openswan-2.6.09-2.fc9.ppc64 requires /bin/sh openswan-2.6.09-2.fc9.ppc64 requires /sbin/service openswan-2.6.09-2.fc9.ppc64 requires /bin/sh openswan-2.6.09-2.fc9.ppc64 requires /usr/bin/perl openswan-2.6.09-2.fc9.ppc64 requires /sbin/chkconfig openvpn-2.1-0.25.rc7.fc9.ppc64 requires /bin/sh openvpn-2.1-0.25.rc7.fc9.ppc64 requires /usr/sbin/useradd openvpn-2.1-0.25.rc7.fc9.ppc64 requires /sbin/service openvpn-2.1-0.25.rc7.fc9.ppc64 requires /bin/bash openvpn-2.1-0.25.rc7.fc9.ppc64 requires /bin/sh openvpn-2.1-0.25.rc7.fc9.ppc64 requires /sbin/chkconfig openvrml-0.17.5-5.fc9.ppc64 requires /sbin/ldconfig openvrml-gl-0.17.5-5.fc9.ppc64 requires /sbin/ldconfig openvrml-xembed-0.17.5-5.fc9.ppc64 requires /bin/sh openvrml-xembed-0.17.5-5.fc9.ppc64 requires /sbin/install-info oprofile-0.9.3-17.fc9.ppc64 requires /bin/sh opyum-0.0.3-1.fc9.noarch requires /bin/sh opyum-0.0.3-1.fc9.noarch requires /usr/bin/python orage-4.4.2-3.fc9.ppc64 requires /bin/sh orange-0.3-7.cvs20051118.fc9.ppc64 requires /sbin/ldconfig orca-2.23.2-1.fc10.ppc64 requires /bin/sh orca-2.23.2-1.fc10.ppc64 requires /bin/bash ortp-0.14.2-0.20080211.2.fc9.ppc64 requires /sbin/ldconfig 1:osgal-0.6.1-4.fc10.ppc64 requires /sbin/ldconfig osgcal-0.1.46-6.fc10.ppc64 requires /sbin/ldconfig ots-libs-0.5.0-1.fc9.ppc64 requires /sbin/ldconfig overgod-1.0-7.fc9.ppc64 requires /bin/sh oxine-0.7.1-1.fc10.ppc64 requires /bin/sh oxygen-icon-theme-4.0.72-2.fc10.noarch requires /bin/sh oxygen-icon-theme-scalable-4.0.72-2.fc10.noarch requires /bin/sh oyranos-devel-0.1.7-11.fc9.ppc64 requires /bin/sh oyranos-libs-0.1.7-11.fc9.ppc64 requires /sbin/ldconfig p0f-2.0.8-4.fc9.ppc64 requires /bin/sh p0rn-comfort-0.0.4-5.fc9.noarch requires /bin/sh p0rn-comfort-0.0.4-5.fc9.noarch requires /usr/bin/perl p0rn-comfort-0.0.4-5.fc9.noarch requires /bin/bash p7zip-4.51-4.fc9.ppc64 requires /bin/sh p7zip-plugins-4.51-4.fc9.ppc64 requires /bin/sh pAgenda-3.2-2.fc10.noarch requires /bin/sh pAgenda-3.2-2.fc10.noarch requires /usr/bin/env pachi-1.0-5.fc9.ppc64 requires /bin/sh pakchois-0.4-1.ppc64 requires /sbin/ldconfig paktype-fonts-2.0-2.fc8.noarch requires /bin/sh pam-1.0.1-2.fc10.ppc64 requires /bin/sh pam-1.0.1-2.fc10.ppc64 requires /sbin/ldconfig pam-1.0.1-2.fc10.ppc64 requires /bin/sh pam_mount-0.32-3.fc9.ppc64 requires /bin/sh pam_mount-0.32-3.fc9.ppc64 requires /bin/bash pam_mount-0.32-3.fc9.ppc64 requires /bin/sh pam_mount-0.32-3.fc9.ppc64 requires /usr/bin/perl pango-1.21.1-1.fc10.ppc64 requires /bin/sh papyrus-0.7.1-3.fc9.ppc64 requires /sbin/ldconfig paraview-3.2.1-6.fc9.ppc64 requires /usr/bin/update-desktop-database paraview-3.2.1-6.fc9.ppc64 requires /bin/sh paraview-data-3.2.1-6.fc9.ppc64 requires /bin/sh paraview-data-3.2.1-6.fc9.ppc64 requires /usr/bin/update-mime-database paraview-mpi-3.2.1-6.fc9.ppc64 requires /usr/bin/update-desktop-database paraview-mpi-3.2.1-6.fc9.ppc64 requires /bin/sh pards-0.4-6.fc9.ppc64 requires /sbin/ldconfig pari-2.3.3-1.fc9.ppc64 requires /sbin/ldconfig pari-gp-2.3.3-1.fc9.ppc64 requires /usr/bin/perl pari-gp-2.3.3-1.fc9.ppc64 requires /bin/sh parted-1.8.8-5.fc9.ppc64 requires /bin/sh parted-1.8.8-5.fc9.ppc64 requires /sbin/install-info parted-1.8.8-5.fc9.ppc64 requires /sbin/ldconfig passivetex-1.25-8.fc9.noarch requires /bin/sh passivetex-1.25-8.fc9.noarch requires /bin/sh passwd-0.75-2.fc9.ppc64 requires /etc/pam.d/system-auth patchutils-0.2.31-5.fc9.ppc64 requires /usr/bin/perl patchutils-0.2.31-5.fc9.ppc64 requires /bin/bash patchutils-0.2.31-5.fc9.ppc64 requires /bin/sh patchy-2006-29.fc9.ppc64 requires /bin/sh patchy-g77-2006-29.fc9.ppc64 requires /bin/sh patchy-gfortran-2006-29.fc9.ppc64 requires /bin/sh paw-2006-29.fc9.ppc64 requires /bin/sh paw-2006-29.fc9.ppc64 requires /bin/sh paw-g77-2006-29.fc9.ppc64 requires /bin/sh paw-g77-2006-29.fc9.ppc64 requires /bin/sh paw-gfortran-2006-29.fc9.ppc64 requires /bin/sh paw-gfortran-2006-29.fc9.ppc64 requires /bin/sh pbstop-4.16-3.fc9.ppc64 requires /usr/bin/perl pcapdiff-0.1-3.fc9.noarch requires /usr/bin/env pcb-0.20080202-2.fc9.ppc64 requires /bin/sh pcb-0.20080202-2.fc9.ppc64 requires /usr/bin/tclsh pcb-0.20080202-2.fc9.ppc64 requires /sbin/install-info pcb-0.20080202-2.fc9.ppc64 requires /usr/bin/wish pcb-0.20080202-2.fc9.ppc64 requires /usr/bin/perl pcb-0.20080202-2.fc9.ppc64 requires /bin/sh pciutils-2.2.10-1.fc9.ppc64 requires /bin/sh pcmanfm-0.4.1.1-1.fc10.ppc64 requires /bin/sh pcmanx-gtk2-0.3.5-9.336svn.fc7.ppc64 requires /sbin/ldconfig pcre-7.3-3.fc9.ppc64 requires /sbin/ldconfig pcre-devel-7.3-3.fc9.ppc64 requires /bin/sh pcsc-lite-1.4.4-3.fc9.ppc64 requires /bin/sh pcsc-lite-1.4.4-3.fc9.ppc64 requires /sbin/chkconfig pcsc-lite-1.4.4-3.fc9.ppc64 requires /bin/sh pcsc-lite-libs-1.4.4-3.fc9.ppc64 requires /sbin/ldconfig pcsc-lite-openct-0.6.14-4.fc9.ppc64 requires /bin/sh pcsc-tools-1.4.12-1.fc9.ppc64 requires /usr/bin/env pdfedit-0.3.2-4.fc9.ppc64 requires /bin/sh pdfjam-1.20-5.fc6.noarch requires /bin/sh pdns-2.9.21-4.fc9.ppc64 requires /bin/sh pdns-2.9.21-4.fc9.ppc64 requires /usr/sbin/useradd pdns-2.9.21-4.fc9.ppc64 requires /sbin/service pdns-2.9.21-4.fc9.ppc64 requires /bin/sh pdns-2.9.21-4.fc9.ppc64 requires /sbin/chkconfig pdns-recursor-3.1.6-1.fc10.ppc64 requires /bin/sh pdns-recursor-3.1.6-1.fc10.ppc64 requires /sbin/service pdns-recursor-3.1.6-1.fc10.ppc64 requires /bin/bash pdns-recursor-3.1.6-1.fc10.ppc64 requires /sbin/chkconfig pdsh-2.11-6.fc9.ppc64 requires /usr/bin/perl pekwm-0.1.5-5.fc7.ppc64 requires /usr/bin/env pengupop-2.2.2-3.fc9.ppc64 requires /bin/sh 4:perl-5.10.0-20.fc9.ppc64 requires /usr/bin/perl perl-Ace-1.91-4.fc9.noarch requires /usr/bin/perl perl-Archive-Tar-1.37-20.fc9.ppc64 requires /usr/bin/perl perl-Archive-Zip-1.23-1.fc10.noarch requires /usr/bin/perl perl-BerkeleyDB-0.34-1.fc10.ppc64 requires /usr/bin/perl perl-CPAN-1.9205-20.fc9.ppc64 requires /usr/bin/perl perl-CPANPLUS-0.84-20.fc9.ppc64 requires /usr/bin/perl perl-Calendar-Simple-1.19-1.fc9.noarch requires /usr/bin/perl perl-Catalyst-Devel-1.03-2.fc9.noarch requires /usr/bin/perl perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Cflow-1.053-9.fc9.ppc64 requires /usr/bin/perl perl-Convert-Binary-C-0.70-5.fc9.ppc64 requires /usr/bin/perl perl-Crypt-Primes-0.50-5.fc9.noarch requires /usr/bin/perl perl-Crypt-Random-1.25-5.fc9.noarch requires /usr/bin/perl perl-Curses-1.20-3.fc9.ppc64 requires /usr/bin/perl perl-DBD-XBase-0.241-7.fc9.noarch requires /usr/bin/perl perl-DBI-1.601-4.fc9.ppc64 requires /usr/bin/perl perl-DBI-Dumper-2.01-6.fc9.ppc64 requires /usr/bin/perl perl-Data-HexDump-0.02-4.fc9.noarch requires /usr/bin/perl perl-Data-Stag-0.10-4.fc9.noarch requires /usr/bin/perl perl-Devel-Cover-0.63-3.fc9.ppc64 requires /usr/bin/perl perl-Device-SerialPort-1.04-3.fc9.ppc64 requires /usr/bin/perl 1:perl-Digest-SHA-5.45-20.fc9.ppc64 requires /usr/bin/perl perl-ExtUtils-MakeMaker-6.36-20.fc9.ppc64 requires /usr/bin/perl perl-ExtUtils-MakeMaker-Coverage-0.05-4.fc9.noarch requires /usr/bin/perl 1:perl-ExtUtils-ParseXS-2.18-20.fc9.ppc64 requires /usr/bin/perl perl-File-Find-Rule-0.30-6.fc9.noarch requires /usr/bin/perl perl-File-MimeInfo-0.15-2.fc9.noarch requires /usr/bin/perl perl-File-Which-0.05-4.fc9.noarch requires /usr/bin/perl perl-Finance-YahooQuote-0.21-3.fc9.noarch requires /usr/bin/perl perl-GD-2.35-7.fc9.ppc64 requires /usr/bin/perl perl-GDTextUtil-0.86-11.fc9.noarch requires /bin/sh perl-Gearman-Server-1.09-2.fc9.noarch requires /usr/bin/perl perl-Gtk2-Ex-PodViewer-0.17-4.fc9.noarch requires /usr/bin/perl 1:perl-HTML-Mason-1.39-2.fc9.noarch requires /usr/bin/perl 1:perl-HTML-Mason-1.39-2.fc9.noarch requires /etc/httpd/conf.d perl-HTML-Tidy-1.08-3.fc9.ppc64 requires /usr/bin/perl 1:perl-HTML-Tree-3.23-4.fc9.noarch requires /usr/bin/perl perl-HTTP-DAV-0.31-2.fc9.noarch requires /usr/bin/perl perl-IO-stringy-2.110-8.fc9.noarch requires /usr/bin/perl perl-Image-ExifTool-7.25-1.fc10.noarch requires /usr/bin/perl perl-Image-Info-1.27-3.fc9.noarch requires /usr/share/X11/rgb.txt perl-Image-Size-3.1-3.fc9.noarch requires /usr/bin/perl perl-Kwiki-0.39-3.fc9.noarch requires /usr/bin/perl perl-Lingua-EN-Inflect-1.89-7.fc9.noarch requires /usr/bin/perl perl-Locale-Maketext-Lexicon-0.66-2.fc9.noarch requires /usr/bin/perl perl-MARC-Record-2.0.0-2.fc9.noarch requires /usr/bin/perl perl-MIME-Lite-3.01-6.fc9.noarch requires /usr/bin/perl perl-MIME-tools-5.426-1.fc9.noarch requires /usr/bin/perl perl-Mail-Mbox-MessageParser-1.5000-5.fc9.noarch requires /usr/bin/diff 1:perl-Module-Build-0.2808-20.fc9.ppc64 requires /usr/bin/perl perl-Module-CPANTS-Analyse-0.75-3.fc9.noarch requires /usr/bin/perl perl-Module-CoreList-2.14-20.fc9.ppc64 requires /usr/bin/perl perl-Module-Info-0.31-3.fc9.noarch requires /usr/bin/perl perl-Module-ScanDeps-0.84-1.fc10.noarch requires /usr/bin/perl perl-Module-Signature-0.55-3.fc9.noarch requires /usr/bin/perl perl-Module-Starter-1.42-5.fc9.noarch requires /usr/bin/perl perl-MogileFS-Utils-2.12-2.fc9.noarch requires /usr/bin/perl perl-Net-DNS-SEC-0.14-3.fc9.noarch requires /usr/bin/perl perl-Net-IP-1.25-8.fc9.noarch requires /usr/bin/perl perl-Net-IPv4Addr-0.10-3.fc9.noarch requires /usr/bin/perl perl-Net-NBName-0.26-3.fc9.noarch requires /usr/bin/perl perl-Net-Pcap-0.14-4.fc9.ppc64 requires /usr/bin/perl perl-Net-SNMP-5.2.0-2.fc9.noarch requires /usr/bin/perl perl-Net-Server-0.97-2.fc9.noarch requires /usr/bin/perl perl-Net-eBay-0.46-2.fc9.noarch requires /usr/bin/perl perl-PDL-2.4.3-12.fc9.ppc64 requires /usr/bin/perl perl-PPI-HTML-1.07-3.fc9.noarch requires /usr/bin/perl perl-PPI-Tester-0.06-5.fc9.noarch requires /usr/bin/perl perl-Parse-Yapp-1.05-38.fc9.noarch requires /usr/bin/perl perl-Perl-Critic-1.080-3.fc9.noarch requires /usr/bin/perl perl-Perl-MinimumVersion-0.15-5.fc9.noarch requires /usr/bin/perl perl-Perl6-Bible-0.30-5.fc9.noarch requires /usr/bin/perl perl-Pod-Coverage-0.19-3.fc9.noarch requires /usr/bin/perl perl-Pod-POM-0.17-9.fc9.noarch requires /usr/bin/perl perl-Pod-Readme-0.090-3.fc9.noarch requires /usr/bin/perl perl-Pod-Spell-1.01-4.fc9.noarch requires /usr/bin/perl perl-Pod-Tests-0.18-6.fc9.noarch requires /usr/bin/perl perl-Proc-ProcessTable-0.42-1.fc9.ppc64 requires /usr/bin/perl perl-Pugs-Compiler-Rule-0.28-2.fc9.noarch requires /usr/bin/env perl-RPM-Specfile-1.51-5.fc9.noarch requires /usr/bin/perl perl-Razor-Agent-2.84-4.fc9.ppc64 requires /usr/bin/perl perl-SGMLSpm-1.03ii-18.fc9.noarch requires /usr/bin/perl perl-SOAP-Lite-0.68-6.fc9.noarch requires /bin/env perl-SOAP-Lite-0.68-6.fc9.noarch requires /usr/bin/env perl-SQL-Translator-0.09000-1.fc9.noarch requires /usr/bin/perl perl-SVK-2.0.2-3.fc9.noarch requires /usr/bin/perl perl-SVN-Mirror-0.73-3.fc9.noarch requires /usr/bin/perl perl-Spreadsheet-WriteExcel-2.20-2.fc9.noarch requires /usr/bin/perl perl-String-ShellQuote-1.03-5.fc9.noarch requires /usr/bin/perl perl-Taint-Runtime-0.03-5.fc9.ppc64 requires /usr/bin/perl perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Template-Toolkit-2.19-4.fc9.ppc64 requires /usr/bin/perl perl-Test-AutoBuild-1.2.2-3.fc9.noarch requires /usr/bin/mkisofs perl-Test-AutoBuild-1.2.2-3.fc9.noarch requires /usr/bin/createrepo perl-Test-AutoBuild-1.2.2-3.fc9.noarch requires /usr/bin/xsltproc perl-Test-AutoBuild-1.2.2-3.fc9.noarch requires /usr/bin/perl perl-Test-AutoBuild-1.2.2-3.fc9.noarch requires /bin/sh perl-Test-AutoBuild-1.2.2-3.fc9.noarch requires /usr/bin/yum-arch perl-Test-AutoBuild-1.2.2-3.fc9.noarch requires /usr/bin/genbasedir perl-Test-AutoBuild-account-1.2.2-3.fc9.noarch requires /bin/sh perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 perl-Test-Harness-2.64-20.fc9.ppc64 requires /usr/bin/perl perl-Test-Inline-2.208-2.fc9.noarch requires /usr/bin/perl perl-Test-Unit-0.25-4.fc9.noarch requires /usr/bin/perl perl-Text-RecordParser-1.2.1-4.fc9.noarch requires /usr/bin/perl perl-Text-Smart-1.0.2-1.fc10.noarch requires /usr/bin/perl perl-Tk-804.028-5.fc9.ppc64 requires /usr/bin/perl perl-Unicode-Map-0.112-14.fc9.ppc64 requires /usr/bin/perl perl-Unicode-Map8-0.12-17.fc9.ppc64 requires /usr/bin/perl perl-VCS-LibCVS-1.0002-3.fc9.noarch requires /usr/bin/perl perl-WWW-Mechanize-1.32-2.fc9.noarch requires /usr/bin/perl perl-WWW-Myspace-0.60-2.fc9.noarch requires /usr/bin/perl perl-WWW-Search-2.497-2.fc9.noarch requires /usr/bin/perl perl-Wx-0.81-1.fc9.ppc64 requires /usr/bin/perl perl-XML-Entities-0.03-1.fc9.noarch requires /usr/bin/perl perl-XML-Handler-YAWriter-0.23-5.fc9.noarch requires /usr/bin/perl 1:perl-XML-LibXML-1.65-5.fc9.ppc64 requires /bin/sh 1:perl-XML-LibXML-1.65-5.fc9.ppc64 requires /bin/sh perl-XML-SAX-0.16-5.fc9.noarch requires /bin/sh perl-XML-Tidy-1.2.54HJnFa-4.fc9.noarch requires /usr/bin/perl perl-XML-Twig-3.32-1.fc9.noarch requires /usr/bin/perl perl-XML-XPath-1.13-6.fc9.noarch requires /usr/bin/perl perl-XML-XQL-0.68-6.fc9.noarch requires /usr/bin/perl perl-YAML-0.66-3.fc9.noarch requires /usr/bin/perl perl-bioperl-1.5.2_102-12.fc9.noarch requires /usr/bin/perl perl-bioperl-run-1.5.2_100-3.fc9.noarch requires /usr/bin/perl 4:perl-devel-5.10.0-20.fc9.ppc64 requires /usr/bin/perl 4:perl-libs-5.10.0-20.fc9.ppc64 requires /sbin/ldconfig perl-libwww-perl-5.808-7.fc9.noarch requires /usr/bin/perl perl-pmtools-1.10-1.fc9.noarch requires /usr/bin/perl perltidy-20071205-3.fc9.noarch requires /usr/bin/perl pessulus-2.16.2-2.fc7.noarch requires /usr/bin/env pessulus-2.16.2-2.fc7.noarch requires /usr/bin/python petitboot-0.0.1-7.fc8.ppc64 requires /bin/sh pexpect-2.3-1.fc9.noarch requires /usr/bin/env pfqueue-0.5.6-7.fc9.ppc64 requires /sbin/ldconfig pgfouine-1.0-2.fc8.noarch requires /usr/bin/php pgp-tools-0.4.12-2.fc9.noarch requires /usr/bin/perl pgp-tools-0.4.12-2.fc9.noarch requires /bin/sh pharosc-8.3-1.fc8.noarch requires /bin/bash pharosc-alliance-8.3-1.fc8.noarch requires /bin/bash pharosc-alliance-devel-8.3-1.fc8.noarch requires /bin/bash pharosc-doc-8.3-1.fc8.noarch requires /bin/bash pharosc-magic-8.3-1.fc8.noarch requires /bin/bash pharosc-magic-devel-8.3-1.fc8.noarch requires /bin/bash pharosc-synopsys-8.3-1.fc8.noarch requires /bin/bash pharosc-xcircuit-8.3-1.fc8.noarch requires /bin/bash phasex-0.11.1-5.fc9.ppc64 requires /bin/sh photoml-0.25-1.fc9.noarch requires /usr/bin/perl photoml-0.25-1.fc9.noarch requires /bin/sh php-channel-phing-1.0.0-5.fc9.noarch requires /bin/sh php-channel-phing-1.0.0-5.fc9.noarch requires /usr/bin/pear php-channel-phpdb-1.0.0-4.fc8.noarch requires /bin/sh php-channel-phpdb-1.0.0-4.fc8.noarch requires /usr/bin/pear php-channel-phpunit-1.0-2.fc7.noarch requires /bin/sh php-channel-symfony-1.0.0-2.fc9.noarch requires /bin/sh php-channel-symfony-1.0.0-2.fc9.noarch requires /usr/bin/pear php-devel-5.2.5-7.fc9.ppc64 requires /bin/sh 1:php-eaccelerator-0.9.5.2-2.fc9.ppc64 requires /bin/sh php-embedded-5.2.5-7.fc9.ppc64 requires /sbin/ldconfig php-magickwand-1.0.7-1.fc10.ppc64 requires libWand.so.10()(64bit) php-magickwand-1.0.7-1.fc10.ppc64 requires libMagick.so.10()(64bit) 1:php-pear-1.7.1-2.fc9.noarch requires /bin/sh php-pear-Auth-SASL-1.0.2-4.fc6.noarch requires /bin/sh php-pear-Auth-SASL-1.0.2-4.fc6.noarch requires /usr/bin/pear php-pear-Benchmark-1.2.7-1.fc8.noarch requires /usr/bin/pear php-pear-Benchmark-1.2.7-1.fc8.noarch requires /bin/sh php-pear-Cache-1.5.5-0.2.RC4.fc8.noarch requires /usr/bin/pear php-pear-Cache-1.5.5-0.2.RC4.fc8.noarch requires /bin/sh php-pear-Cache-Lite-1.7.3-1.fc10.noarch requires /bin/sh php-pear-Cache-Lite-1.7.3-1.fc10.noarch requires /usr/bin/pear php-pear-Console-Color-1.0.2-1.fc7.noarch requires /usr/bin/pear php-pear-Console-Color-1.0.2-1.fc7.noarch requires /bin/sh php-pear-Console-Getargs-1.3.4-1.fc8.1.noarch requires /usr/bin/pear php-pear-Console-Getargs-1.3.4-1.fc8.1.noarch requires /bin/sh php-pear-Console-Table-1.1.1-1.fc9.noarch requires /usr/bin/pear php-pear-Console-Table-1.1.1-1.fc9.noarch requires /bin/sh php-pear-Crypt-CHAP-1.0.1-1.fc7.noarch requires /usr/bin/pear php-pear-Crypt-CHAP-1.0.1-1.fc7.noarch requires /bin/sh php-pear-DB-1.7.13-1.fc8.noarch requires /bin/sh php-pear-DB-1.7.13-1.fc8.noarch requires /usr/bin/pear php-pear-DB-1.7.13-1.fc8.noarch requires /bin/sh php-pear-DB-DataObject-1.8.8-1.fc9.noarch requires /usr/bin/pear php-pear-DB-DataObject-1.8.8-1.fc9.noarch requires /bin/sh php-pear-DB-DataObject-1.8.8-1.fc9.noarch requires /usr/bin/php php-pear-DB-DataObject-FormBuilder-1.0.0-0.5.RC7.fc7.noarch requires /usr/bin/pear php-pear-DB-DataObject-FormBuilder-1.0.0-0.5.RC7.fc7.noarch requires /bin/sh php-pear-DB-DataObject-FormBuilder-1.0.0-0.5.RC7.fc7.noarch requires /usr/bin/php php-pear-DB-QueryTool-1.1.2-1.fc9.noarch requires /usr/bin/pear php-pear-DB-QueryTool-1.1.2-1.fc9.noarch requires /bin/sh php-pear-Date-1.4.7-2.fc7.noarch requires /usr/bin/pear php-pear-Date-1.4.7-2.fc7.noarch requires /bin/sh php-pear-Date-Holidays-0.17.4-1.fc9.noarch requires /usr/bin/pear php-pear-Date-Holidays-0.17.4-1.fc9.noarch requires /bin/sh php-pear-Date-Holidays-0.17.4-1.fc9.noarch requires /usr/bin/php php-pear-File-1.3.0-1.fc8.noarch requires /usr/bin/pear php-pear-File-1.3.0-1.fc8.noarch requires /bin/sh php-pear-File-Find-1.3.0-1.fc9.noarch requires /usr/bin/pear php-pear-File-Find-1.3.0-1.fc9.noarch requires /bin/sh php-pear-File-Passwd-1.1.6-2.fc7.noarch requires /usr/bin/pear php-pear-File-Passwd-1.1.6-2.fc7.noarch requires /bin/sh php-pear-File-SMBPasswd-1.0.2-1.fc7.noarch requires /usr/bin/pear php-pear-File-SMBPasswd-1.0.2-1.fc7.noarch requires /bin/sh php-pear-HTML-Common-1.2.4-1.fc8.noarch requires /usr/bin/pear php-pear-HTML-Common-1.2.4-1.fc8.noarch requires /bin/sh php-pear-HTML-QuickForm-3.2.10-1.fc9.noarch requires /usr/bin/pear php-pear-HTML-QuickForm-3.2.10-1.fc9.noarch requires /bin/sh php-pear-HTML-QuickForm-ElementGrid-0.1.1-1.fc7.noarch requires /usr/bin/pear php-pear-HTML-QuickForm-ElementGrid-0.1.1-1.fc7.noarch requires /bin/sh php-pear-HTML-QuickForm-advmultiselect-1.4.1-1.fc10.noarch requires /usr/bin/pear php-pear-HTML-QuickForm-advmultiselect-1.4.1-1.fc10.noarch requires /bin/sh php-pear-HTML-Table-1.8.2-1.fc9.noarch requires /usr/bin/pear php-pear-HTML-Table-1.8.2-1.fc9.noarch requires /bin/sh php-pear-HTTP-1.4.0-8.fc8.noarch requires /bin/sh php-pear-HTTP-1.4.0-8.fc8.noarch requires /usr/bin/pear php-pear-HTTP-Request-1.4.2-1.fc9.noarch requires /usr/bin/pear php-pear-HTTP-Request-1.4.2-1.fc9.noarch requires /bin/sh php-pear-HTTP-Upload-0.9.1-2.fc9.noarch requires /usr/bin/pear php-pear-HTTP-Upload-0.9.1-2.fc9.noarch requires /bin/sh php-pear-Image-Canvas-0.3.1-1.fc8.noarch requires /usr/bin/pear php-pear-Image-Canvas-0.3.1-1.fc8.noarch requires /bin/sh php-pear-Image-Color-1.0.2-3.fc7.noarch requires /usr/bin/pear php-pear-Image-Color-1.0.2-3.fc7.noarch requires /bin/sh php-pear-Image-Graph-0.7.2-2.fc7.noarch requires /usr/bin/pear php-pear-Image-Graph-0.7.2-2.fc7.noarch requires /bin/sh php-pear-Image-GraphViz-1.2.1-2.fc7.noarch requires /usr/bin/pear php-pear-Image-GraphViz-1.2.1-2.fc7.noarch requires /bin/sh php-pear-Log-1.10.1-1.fc10.noarch requires /bin/sh php-pear-Log-1.10.1-1.fc10.noarch requires /usr/bin/pear php-pear-MDB2-2.4.1-2.fc9.noarch requires /usr/bin/pear php-pear-MDB2-2.4.1-2.fc9.noarch requires /bin/sh php-pear-MDB2-Driver-mysql-1.4.1-3.fc9.noarch requires /usr/bin/pear php-pear-MDB2-Driver-mysql-1.4.1-3.fc9.noarch requires /bin/sh php-pear-MDB2-Driver-mysqli-1.4.1-3.fc9.noarch requires /usr/bin/pear php-pear-MDB2-Driver-mysqli-1.4.1-3.fc9.noarch requires /bin/sh php-pear-Mail-1.1.14-2.fc8.noarch requires /bin/sh php-pear-Mail-1.1.14-2.fc8.noarch requires /usr/bin/pear php-pear-Mail-Mime-1.5.2-3.fc9.noarch requires /usr/bin/pear php-pear-Mail-Mime-1.5.2-3.fc9.noarch requires /bin/sh php-pear-Mail-mimeDecode-1.5.0-3.fc9.noarch requires /usr/bin/pear php-pear-Mail-mimeDecode-1.5.0-3.fc9.noarch requires /bin/sh php-pear-Math-Stats-0.9.0-0.1.beta3.fc7.noarch requires /usr/bin/pear php-pear-Math-Stats-0.9.0-0.1.beta3.fc7.noarch requires /bin/sh php-pear-Net-Curl-1.2.3-2.fc6.noarch requires /usr/bin/pear php-pear-Net-Curl-1.2.3-2.fc6.noarch requires /bin/sh php-pear-Net-DIME-0.3-1.fc7.noarch requires /usr/bin/pear php-pear-Net-DIME-0.3-1.fc7.noarch requires /bin/sh php-pear-Net-FTP-1.3.4-1.fc9.noarch requires /usr/bin/pear php-pear-Net-FTP-1.3.4-1.fc9.noarch requires /bin/sh php-pear-Net-POP3-1.3.6-2.fc7.noarch requires /usr/bin/pear php-pear-Net-POP3-1.3.6-2.fc7.noarch requires /bin/sh php-pear-Net-Ping-2.4.3-1.fc9.noarch requires /usr/bin/pear php-pear-Net-Ping-2.4.3-1.fc9.noarch requires /bin/sh php-pear-Net-Ping-2.4.3-1.fc9.noarch requires /bin/ping php-pear-Net-SMTP-1.3.0-1.fc10.noarch requires /bin/sh php-pear-Net-SMTP-1.3.0-1.fc10.noarch requires /usr/bin/pear php-pear-Net-Sieve-1.1.5-2.fc7.noarch requires /usr/bin/pear php-pear-Net-Sieve-1.1.5-2.fc7.noarch requires /bin/sh php-pear-Net-Socket-1.0.8-1.fc7.noarch requires /usr/bin/pear php-pear-Net-Socket-1.0.8-1.fc7.noarch requires /bin/sh php-pear-Net-Traceroute-0.21.1-2.fc8.noarch requires /usr/bin/pear php-pear-Net-Traceroute-0.21.1-2.fc8.noarch requires /bin/sh php-pear-Net-URL-1.0.15-1.fc8.noarch requires /usr/bin/pear php-pear-Net-URL-1.0.15-1.fc8.noarch requires /bin/sh php-pear-Net-URL-Mapper-0.9.0-2.fc9.noarch requires /usr/bin/pear php-pear-Net-URL-Mapper-0.9.0-2.fc9.noarch requires /bin/sh php-pear-Net-UserAgent-Detect-2.4.0-1.fc8.noarch requires /usr/bin/pear php-pear-Net-UserAgent-Detect-2.4.0-1.fc8.noarch requires /bin/sh php-pear-Numbers-Roman-1.0.2-2.fc9.noarch requires /usr/bin/pear php-pear-Numbers-Roman-1.0.2-2.fc9.noarch requires /bin/sh php-pear-Numbers-Words-0.15.0-2.fc7.noarch requires /usr/bin/pear php-pear-Numbers-Words-0.15.0-2.fc7.noarch requires /bin/sh php-pear-PEAR-Command-Packaging-0.1.2-5.fc6.noarch requires /usr/bin/pear php-pear-PEAR-Command-Packaging-0.1.2-5.fc6.noarch requires /bin/sh php-pear-PHP-CodeSniffer-1.0.1-1.fc9.noarch requires /usr/bin/pear php-pear-PHP-CodeSniffer-1.0.1-1.fc9.noarch requires /bin/sh php-pear-PHP-Compat-1.5.0-1.fc6.noarch requires /usr/bin/pear php-pear-PHP-Compat-1.5.0-1.fc6.noarch requires /bin/sh php-pear-PHP-CompatInfo-1.7.0-1.fc10.noarch requires /usr/bin/pear php-pear-PHP-CompatInfo-1.7.0-1.fc10.noarch requires /bin/sh php-pear-PHP-CompatInfo-1.7.0-1.fc10.noarch requires /usr/bin/php php-pear-PHPUnit-3.2.15-1.fc9.noarch requires /usr/bin/pear php-pear-PHPUnit-3.2.15-1.fc9.noarch requires /bin/sh php-pear-PHPUnit-3.2.15-1.fc9.noarch requires /usr/bin/php php-pear-Pager-2.4.4-1.fc8.noarch requires /usr/bin/pear php-pear-Pager-2.4.4-1.fc8.noarch requires /bin/sh php-pear-Payment-Process-0.6.5-1.fc6.noarch requires /usr/bin/pear php-pear-Payment-Process-0.6.5-1.fc6.noarch requires /bin/sh php-pear-Phlickr-0.2.7-2.fc8.noarch requires /usr/bin/pear php-pear-Phlickr-0.2.7-2.fc8.noarch requires /bin/sh php-pear-PhpDocumentor-1.4.1-2.fc9.noarch requires /usr/bin/pear php-pear-PhpDocumentor-1.4.1-2.fc9.noarch requires /bin/sh php-pear-SOAP-0.11.0-1.fc8.noarch requires /usr/bin/pear php-pear-SOAP-0.11.0-1.fc8.noarch requires /bin/sh php-pear-Services-Weather-1.4.2-1.fc7.noarch requires /usr/bin/pear php-pear-Services-Weather-1.4.2-1.fc7.noarch requires /bin/sh php-pear-Services-Weather-1.4.2-1.fc7.noarch requires /usr/bin/php php-pear-Structures-DataGrid-0.9.0-2.fc9.noarch requires /usr/bin/pear php-pear-Structures-DataGrid-0.9.0-2.fc9.noarch requires /bin/sh php-pear-Structures-DataGrid-DataSource-Array-0.1.4-1.fc9.noarch requires /usr/bin/pear php-pear-Structures-DataGrid-DataSource-Array-0.1.4-1.fc9.noarch requires /bin/sh php-pear-Structures-DataGrid-DataSource-DataObject-0.2.1-1.fc9.noarch requires /usr/bin/pear php-pear-Structures-DataGrid-DataSource-DataObject-0.2.1-1.fc9.noarch requires /bin/sh php-pear-Structures-DataGrid-DataSource-MDB2-0.1.11-1.fc9.noarch requires /usr/bin/pear php-pear-Structures-DataGrid-DataSource-MDB2-0.1.11-1.fc9.noarch requires /bin/sh php-pear-Structures-DataGrid-DataSource-RSS-0.1.1-1.fc7.noarch requires /usr/bin/pear php-pear-Structures-DataGrid-DataSource-RSS-0.1.1-1.fc7.noarch requires /bin/sh php-pear-Structures-DataGrid-Renderer-Pager-0.1.3-1.fc9.noarch requires /usr/bin/pear php-pear-Structures-DataGrid-Renderer-Pager-0.1.3-1.fc9.noarch requires /bin/sh php-pear-Structures-DataGrid-Renderer-Smarty-0.1.4-1.fc9.noarch requires /usr/bin/pear php-pear-Structures-DataGrid-Renderer-Smarty-0.1.4-1.fc9.noarch requires /bin/sh php-pear-Validate-0.8.1-1.fc9.noarch requires /usr/bin/pear php-pear-Validate-0.8.1-1.fc9.noarch requires /bin/sh php-pear-Validate-Finance-CreditCard-0.5.2-1.fc6.noarch requires /usr/bin/pear php-pear-Validate-Finance-CreditCard-0.5.2-1.fc6.noarch requires /bin/sh php-pear-XML-Beautifier-1.1-2.fc7.noarch requires /usr/bin/pear php-pear-XML-Beautifier-1.1-2.fc7.noarch requires /bin/sh php-pear-XML-Parser-1.2.8-2.fc8.noarch requires /bin/sh php-pear-XML-Parser-1.2.8-2.fc8.noarch requires /usr/bin/pear php-pear-XML-RSS-0.9.10-3.fc7.noarch requires /usr/bin/pear php-pear-XML-RSS-0.9.10-3.fc7.noarch requires /bin/sh php-pear-XML-Serializer-0.18.0-3.fc7.noarch requires /usr/bin/pear php-pear-XML-Serializer-0.18.0-3.fc7.noarch requires /bin/sh php-pear-XML-Util-1.1.4-2.fc7.noarch requires /usr/bin/pear php-pear-XML-Util-1.1.4-2.fc7.noarch requires /bin/sh php-pear-creole-1.1.0-5.fc8.noarch requires /usr/bin/pear php-pear-creole-1.1.0-5.fc8.noarch requires /bin/sh php-pear-pake-1.1.4-3.fc9.noarch requires /bin/sh php-pear-pake-1.1.4-3.fc9.noarch requires /usr/bin/pear php-pear-pake-1.1.4-3.fc9.noarch requires /bin/sh php-pear-phing-2.3.0-1.fc9.noarch requires /bin/sh php-pear-phing-2.3.0-1.fc9.noarch requires /usr/bin/pear php-pear-phing-2.3.0-1.fc9.noarch requires /bin/sh php-pecl-mailparse-2.1.4-1.fc9.ppc64 requires /bin/sh php-pecl-mailparse-2.1.4-1.fc9.ppc64 requires /usr/bin/pecl php-pecl-memcache-2.2.3-1.fc9.ppc64 requires /bin/sh php-pecl-memcache-2.2.3-1.fc9.ppc64 requires /usr/bin/pecl php-pecl-phar-1.2.3-3.fc9.ppc64 requires /bin/sh php-pecl-phar-1.2.3-3.fc9.ppc64 requires /usr/bin/pecl php-pecl-phar-1.2.3-3.fc9.ppc64 requires /usr/bin/php php-pecl-radius-1.2.5-5.fc10.ppc64 requires /bin/sh php-pecl-radius-1.2.5-5.fc10.ppc64 requires /usr/bin/pecl php-pecl-xdebug-2.0.2-4.fc9.ppc64 requires /bin/sh php-pecl-xdebug-2.0.2-4.fc9.ppc64 requires /usr/bin/pecl phpMyAdmin-2.11.6-1.fc10.noarch requires /usr/bin/perl phpMyAdmin-2.11.6-1.fc10.noarch requires /bin/bash phpMyAdmin-2.11.6-1.fc10.noarch requires /bin/sh phpPgAdmin-4.2-1.fc9.noarch requires /bin/sh phpPgAdmin-4.2-1.fc9.noarch requires /usr/bin/awk phpPgAdmin-4.2-1.fc9.noarch requires /sbin/service phpPgAdmin-4.2-1.fc9.noarch requires /bin/bash phpPgAdmin-4.2-1.fc9.noarch requires /usr/bin/php phpTodo-0.8.1-0.8.beta.fc8.noarch requires /bin/sh phpcs-1.0.1-1.fc9.noarch requires /usr/bin/php phpdoc-1.4.1-2.fc9.noarch requires /usr/bin/php phpldapadmin-1.1.0.5-1.fc9.noarch requires /bin/sh phpwapmail-0.9.2-1.fc9.noarch requires /bin/sh physfs-1.0.1-8.fc9.ppc64 requires /sbin/ldconfig pic2aa-0.2.1-3.fc9.ppc64 requires /bin/sh picard-0.9.0-6.fc9.ppc64 requires /usr/bin/python piccolo-1.04-3jpp.2.fc9.ppc64 requires /bin/sh pida-0.5.1-6.fc9.ppc64 requires /bin/sh pida-0.5.1-6.fc9.ppc64 requires /usr/bin/env pida-0.5.1-6.fc9.ppc64 requires /usr/bin/python pidgin-2.4.1-3.fc10.ppc64 requires /bin/sh pigment-0.3.5-1.fc9.ppc64 requires /sbin/ldconfig piklab-0.15.0-1.fc9.ppc64 requires /bin/sh pikloops-0.2.5-3.fc9.ppc64 requires /bin/sh 2:pilot-link-0.12.3-13.fc9.ppc64 requires /usr/bin/env 2:pilot-link-0.12.3-13.fc9.ppc64 requires /sbin/ldconfig 2:pilot-link-0.12.3-13.fc9.ppc64 requires /usr/bin/perl pils-2.1.3-1.fc9.ppc64 requires /sbin/ldconfig pinball-0.3.1-11.fc9.ppc64 requires /bin/sh pinentry-0.7.4-5.fc9.ppc64 requires /bin/sh pinentry-0.7.4-5.fc9.ppc64 requires /usr/sbin/update-alternatives pinentry-0.7.4-5.fc9.ppc64 requires /sbin/install-info pinentry-gtk-0.7.4-5.fc9.ppc64 requires /bin/sh pinentry-gtk-0.7.4-5.fc9.ppc64 requires /usr/sbin/update-alternatives pinentry-qt-0.7.4-5.fc9.ppc64 requires /bin/sh pinentry-qt-0.7.4-5.fc9.ppc64 requires /usr/sbin/update-alternatives pinfo-0.6.9-7.fc9.ppc64 requires /bin/sh pingus-0.7.2-3.fc9.ppc64 requires /bin/sh pingus-0.7.2-3.fc9.ppc64 requires /usr/bin/guile pinot-0.85-1.fc10.ppc64 requires /bin/sh pioneers-0.12.2-1.fc10.ppc64 requires /bin/sh pipenightdreams-0.10.0-8.fc9.ppc64 requires /bin/sh pipepanic-0.1.3-5.fc9.ppc64 requires /bin/sh pitivi-0.11.1-2.fc9.noarch requires /usr/bin/env pixman-0.10.0-1.fc9.ppc64 requires /sbin/ldconfig plague-0.4.4.1-4.fc7.noarch requires /bin/sh plague-0.4.4.1-4.fc7.noarch requires /bin/bash plague-0.4.4.1-4.fc7.noarch requires /sbin/chkconfig plague-0.4.4.1-4.fc7.noarch requires /usr/bin/python plague-0.4.4.1-4.fc7.noarch requires /sbin/service plague-builder-0.4.4.1-4.fc7.noarch requires /bin/sh plague-builder-0.4.4.1-4.fc7.noarch requires /bin/bash plague-builder-0.4.4.1-4.fc7.noarch requires /sbin/chkconfig plague-builder-0.4.4.1-4.fc7.noarch requires /usr/sbin/useradd plague-builder-0.4.4.1-4.fc7.noarch requires /usr/bin/python plague-builder-0.4.4.1-4.fc7.noarch requires /sbin/service plague-client-0.4.4.1-4.fc7.noarch requires /usr/bin/python plague-utils-0.4.4.1-4.fc7.noarch requires /usr/bin/python planet-2.0-5.fc9.noarch requires /usr/bin/python planner-0.14.3-2.fc10.ppc64 requires /bin/sh planner-0.14.3-2.fc10.ppc64 requires /usr/bin/scrollkeeper-update plexus-archiver-1.0-0.2.a7.1jpp.1.fc9.ppc64 requires /bin/sh plexus-i18n-1.0-0.b6.5jpp.2.fc9.noarch requires /bin/sh plexus-velocity-1.1.2-3jpp.1.fc9.ppc64 requires /bin/sh plib-1.8.5-1.fc10.ppc64 requires /sbin/ldconfig plotmm-0.1.2-6.fc9.ppc64 requires /sbin/ldconfig plotutils-2.5-5.fc9.ppc64 requires /bin/sh plotutils-2.5-5.fc9.ppc64 requires /sbin/install-info plotutils-2.5-5.fc9.ppc64 requires /sbin/ldconfig plplot-5.9.0-1.fc9.ppc64 requires /bin/sh plplot-5.9.0-1.fc9.ppc64 requires /usr/bin/env plplot-5.9.0-1.fc9.ppc64 requires /sbin/install-info plplot-5.9.0-1.fc9.ppc64 requires /sbin/ldconfig plplot-5.9.0-1.fc9.ppc64 requires /bin/bash plplot-5.9.0-1.fc9.ppc64 requires /bin/sh plplot-devel-5.9.0-1.fc9.ppc64 requires /bin/bash plplot-gnome-5.9.0-1.fc9.ppc64 requires /sbin/ldconfig plplot-java-devel-5.9.0-1.fc9.ppc64 requires /bin/bash plplot-octave-5.9.0-1.fc9.ppc64 requires /sbin/ldconfig plplot-octave-5.9.0-1.fc9.ppc64 requires /bin/bash plplot-perl-5.9.0-1.fc9.ppc64 requires /bin/bash plplot-perl-5.9.0-1.fc9.ppc64 requires /usr/bin/env plplot-tk-5.9.0-1.fc9.ppc64 requires /sbin/ldconfig plplot-tk-devel-5.9.0-1.fc9.ppc64 requires /bin/sh pm-utils-1.1.1-2.fc10.ppc64 requires /bin/sh pm-utils-1.1.1-2.fc10.ppc64 requires /bin/bash pm-utils-1.1.1-2.fc10.ppc64 requires /bin/sh pmd-3.6-1jpp.3.fc7.noarch requires /bin/bash pmount-0.9.17-2.fc9.ppc64 requires /bin/mount 1:pnm2ppa-1.04-15.fc9.ppc64 requires /bin/sh po4a-0.32-4.fc8.noarch requires /usr/bin/perl po4a-0.32-4.fc8.noarch requires /bin/sh poedit-1.3.9-2.fc9.ppc64 requires /bin/sh poker-bot-1.5.0-1.fc10.noarch requires /bin/sh poker-bot-1.5.0-1.fc10.noarch requires /sbin/chkconfig poker-bot-1.5.0-1.fc10.noarch requires /bin/sh poker-bot-1.5.0-1.fc10.noarch requires /usr/bin/python poker-bot-1.5.0-1.fc10.noarch requires /sbin/service poker-engine-1.2.0-1.fc10.noarch requires /usr/bin/python poker-eval-134.0-2.fc9.ppc64 requires /sbin/ldconfig poker-network-selinux-1.5.0-1.fc10.noarch requires /usr/sbin/semodule poker-network-selinux-1.5.0-1.fc10.noarch requires /sbin/fixfiles poker-network-selinux-1.5.0-1.fc10.noarch requires /bin/sh poker-network-selinux-1.5.0-1.fc10.noarch requires /usr/sbin/semanage poker-network-selinux-1.5.0-1.fc10.noarch requires /usr/sbin/setsebool poker-network-selinux-1.5.0-1.fc10.noarch requires /sbin/service poker-server-1.5.0-1.fc10.noarch requires /bin/sh poker-server-1.5.0-1.fc10.noarch requires /sbin/chkconfig poker-server-1.5.0-1.fc10.noarch requires /bin/sh poker-server-1.5.0-1.fc10.noarch requires /usr/bin/python poker-server-1.5.0-1.fc10.noarch requires /sbin/service poker-web-1.5.0-1.fc10.noarch requires /bin/sh poker2d-1.5.0-1.fc10.ppc64 requires /bin/sh poker2d-1.5.0-1.fc10.ppc64 requires /usr/bin/python2.5 poker3d-1.1.36-10.fc10.ppc64 requires /bin/sh poker3d-1.1.36-10.fc10.ppc64 requires /usr/libexec/poker3d/underware poker3d-1.1.36-10.fc10.ppc64 requires /bin/sh policycoreutils-2.0.49-2.fc10.ppc64 requires /bin/sh policycoreutils-2.0.49-2.fc10.ppc64 requires /bin/sed policycoreutils-2.0.49-2.fc10.ppc64 requires /bin/mount policycoreutils-2.0.49-2.fc10.ppc64 requires /bin/awk policycoreutils-2.0.49-2.fc10.ppc64 requires /usr/bin/python policycoreutils-2.0.49-2.fc10.ppc64 requires /sbin/service policycoreutils-2.0.49-2.fc10.ppc64 requires /usr/bin/diff policycoreutils-2.0.49-2.fc10.ppc64 requires /bin/egrep policycoreutils-2.0.49-2.fc10.ppc64 requires /bin/bash policycoreutils-2.0.49-2.fc10.ppc64 requires /bin/sh policycoreutils-2.0.49-2.fc10.ppc64 requires /sbin/chkconfig policycoreutils-gui-2.0.49-2.fc10.ppc64 requires /usr/bin/python pop-before-smtp-1.41-2.fc6.noarch requires /bin/sh pop-before-smtp-1.41-2.fc6.noarch requires /usr/bin/perl pop-before-smtp-1.41-2.fc6.noarch requires /bin/sh popt-1.13-3.fc9.ppc64 requires /sbin/ldconfig portaudio-19-5.fc9.ppc64 requires /sbin/ldconfig portecle-1.3-3.fc9.noarch requires /bin/sh portecle-1.3-3.fc9.noarch requires /bin/sh 2:postfix-2.5.1-2.fc9.ppc64 requires /bin/sh 2:postfix-2.5.1-2.fc9.ppc64 requires /usr/sbin/groupadd 2:postfix-2.5.1-2.fc9.ppc64 requires /usr/sbin/useradd 2:postfix-2.5.1-2.fc9.ppc64 requires /usr/sbin/alternatives 2:postfix-2.5.1-2.fc9.ppc64 requires /sbin/service 2:postfix-2.5.1-2.fc9.ppc64 requires /bin/bash 2:postfix-2.5.1-2.fc9.ppc64 requires /bin/sh 2:postfix-2.5.1-2.fc9.ppc64 requires /usr/bin/perl 2:postfix-2.5.1-2.fc9.ppc64 requires /sbin/chkconfig 2:postfix-pflogsumm-2.5.1-2.fc9.ppc64 requires /usr/bin/perl postgis-1.3.3-1.fc9.ppc64 requires /usr/bin/rebuild-gcj-db postgis-jdbc-1.3.3-1.fc9.ppc64 requires /usr/bin/rebuild-gcj-db postgresql-devel-8.3.1-3.fc10.ppc64 requires /bin/sh postgresql-jdbc-8.3.603-1jpp.fc9.ppc64 requires /bin/sh postgresql-jdbc-8.3.603-1jpp.fc9.ppc64 requires /usr/bin/rebuild-gcj-db postgresql-libs-8.3.1-3.fc10.ppc64 requires /sbin/ldconfig postgresql-odbc-08.03.0100-1.fc9.ppc64 requires /sbin/ldconfig postgresql-pgpool-3.4.1-2.fc9.1.ppc64 requires /bin/sh postgresql-pgpool-II-2.1-0.2.beta2.fc9.ppc64 requires /bin/sh postgresql-pgpool-II-2.1-0.2.beta2.fc9.ppc64 requires /sbin/ldconfig postgresql-pgpool-II-2.1-0.2.beta2.fc9.ppc64 requires /bin/sh postgresql-pgpoolAdmin-1.0.0-7.fc8.noarch requires /bin/sh postgresql-plperl-8.3.1-3.fc10.ppc64 requires /sbin/ldconfig postgresql-plpython-8.3.1-3.fc10.ppc64 requires /sbin/ldconfig postgresql-pltcl-8.3.1-3.fc10.ppc64 requires /sbin/ldconfig postgresql-pltcl-8.3.1-3.fc10.ppc64 requires /bin/sh postgresql-python-8.3.1-3.fc10.ppc64 requires /usr/bin/env postgresql-server-8.3.1-3.fc10.ppc64 requires /bin/sh postgresql-server-8.3.1-3.fc10.ppc64 requires /usr/sbin/useradd postgresql-server-8.3.1-3.fc10.ppc64 requires /bin/sh postgresql-server-8.3.1-3.fc10.ppc64 requires /sbin/chkconfig postgresql-table_log-0.4.4-4.fc9.1.ppc64 requires /sbin/ldconfig postgresql-test-8.3.1-3.fc10.ppc64 requires /bin/sh postgresql-test-8.3.1-3.fc10.ppc64 requires /bin/sh postgresql_autodoc-1.31-1.fc9.noarch requires /usr/bin/perl postgrey-1.30-1.fc8.noarch requires /bin/sh postgrey-1.30-1.fc8.noarch requires /usr/sbin/useradd postgrey-1.30-1.fc8.noarch requires /sbin/service postgrey-1.30-1.fc8.noarch requires /usr/bin/perl postgrey-1.30-1.fc8.noarch requires /bin/sh postgrey-1.30-1.fc8.noarch requires /sbin/chkconfig postr-0.10-2.fc9.noarch requires /bin/sh postr-0.10-2.fc9.noarch requires /usr/bin/python powerman-1.0.32-5.fc9.ppc64 requires /bin/sh powerman-1.0.32-5.fc9.ppc64 requires /bin/sh powermanga-0.90-3.ppc64 requires /bin/sh powerpc-utils-1.0.6-3.fc9.ppc64 requires /usr/bin/perl powerpc-utils-1.0.6-3.fc9.ppc64 requires /bin/bash powerpc-utils-1.0.6-3.fc9.ppc64 requires /bin/sh powerpc-utils-papr-1.0.4-3.fc9.ppc64 requires /usr/bin/perl powerpc-utils-papr-1.0.4-3.fc9.ppc64 requires /bin/sh ppc64-utils-0.14-2.fc9.ppc64 requires yaboot ppl-0.9-19.fc9.ppc64 requires /sbin/ldconfig ppl-pwl-0.9-19.fc9.ppc64 requires /sbin/ldconfig ppp-2.4.4-7.fc10.ppc64 requires /etc/pam.d/system-auth pptp-1.7.2-1.fc10.ppc64 requires /usr/bin/perl prelink-0.4.0-3.ppc64 requires /bin/sh prelink-0.4.0-3.ppc64 requires /bin/sh preload-0.4-6.fc9.ppc64 requires /bin/sh preload-0.4-6.fc9.ppc64 requires /bin/bash preload-0.4-6.fc9.ppc64 requires /sbin/chkconfig preload-0.4-6.fc9.ppc64 requires /sbin/service prelude-lml-0.9.12.2-1.fc10.ppc64 requires /bin/sh prelude-lml-0.9.12.2-1.fc10.ppc64 requires /sbin/chkconfig prelude-lml-0.9.12.2-1.fc10.ppc64 requires /bin/sh prelude-lml-0.9.12.2-1.fc10.ppc64 requires /sbin/service prelude-manager-0.9.12.1-1.fc10.ppc64 requires /bin/sh prelude-manager-0.9.12.1-1.fc10.ppc64 requires /sbin/service prelude-manager-0.9.12.1-1.fc10.ppc64 requires /bin/sh prelude-manager-0.9.12.1-1.fc10.ppc64 requires /sbin/chkconfig presto-utils-0.3.2-1.fc8.noarch requires /bin/sh presto-utils-0.3.2-1.fc8.noarch requires /usr/bin/python preupgrade-0.9.3-3.fc10.noarch requires /bin/sh preupgrade-0.9.3-3.fc10.noarch requires /bin/sh preupgrade-0.9.3-3.fc10.noarch requires /usr/bin/python prewikka-0.9.14-1.fc10.noarch requires /bin/sh prewikka-0.9.14-1.fc10.noarch requires /usr/bin/python privoxy-3.0.8-2.fc9.ppc64 requires /bin/sh privoxy-3.0.8-2.fc9.ppc64 requires /sbin/chkconfig privoxy-3.0.8-2.fc9.ppc64 requires /bin/sh privoxy-3.0.8-2.fc9.ppc64 requires /sbin/service procinfo-18-23.fc9.ppc64 requires /usr/bin/perl procmail-3.22-21.fc9.ppc64 requires /bin/sh procps-3.2.7-20.fc9.ppc64 requires /sbin/ldconfig professor-is-missing-0.1-3.fc8.noarch requires /bin/sh professor-is-missing-0.1-3.fc8.noarch requires /bin/bash proftpd-1.3.1-3.fc9.ppc64 requires /bin/sh proftpd-1.3.1-3.fc9.ppc64 requires /sbin/service proftpd-1.3.1-3.fc9.ppc64 requires /bin/sh proftpd-1.3.1-3.fc9.ppc64 requires /sbin/chkconfig proj-4.6.0-1.fc10.ppc64 requires /sbin/ldconfig proj-nad-4.6.0-1.fc10.ppc64 requires /bin/bash proxychains-3.1-5.fc9.ppc64 requires /sbin/ldconfig proxychains-3.1-5.fc9.ppc64 requires /bin/sh proxyknife-1.7-3.fc9.ppc64 requires /bin/sh proxyknife-1.7-3.fc9.ppc64 requires /sbin/install-info ps2eps-1.64-4.fc9.ppc64 requires /usr/bin/perl ps3pf-utils-2.1-2.fc9.ppc64 requires /bin/sh ps3pf-utils-libs-2.1-2.fc9.ppc64 requires /sbin/ldconfig psacct-6.3.2-50.fc9.ppc64 requires /bin/sh psacct-6.3.2-50.fc9.ppc64 requires /sbin/chkconfig psacct-6.3.2-50.fc9.ppc64 requires /bin/bash psacct-6.3.2-50.fc9.ppc64 requires /sbin/install-info pscan-1.3-1.fc9.ppc64 requires /bin/sh psgml-1.2.5-6.fc7.noarch requires /bin/sh psi-0.11-4.fc9.ppc64 requires /bin/sh psi-0.11-4.fc9.ppc64 requires /bin/sh psiconv-0.9.8-1.fc8.ppc64 requires libWand.so.10()(64bit) psiconv-0.9.8-1.fc8.ppc64 requires /sbin/ldconfig psiconv-0.9.8-1.fc8.ppc64 requires libMagick.so.10()(64bit) psiconv-devel-0.9.8-1.fc8.ppc64 requires /bin/sh pstoedit-3.45-3.fc10.ppc64 requires /sbin/ldconfig psutils-1.17-28.fc9.ppc64 requires /usr/bin/perl psutils-1.17-28.fc9.ppc64 requires /bin/sh pth-2.0.7-6.ppc64 requires /sbin/ldconfig pth-devel-2.0.7-6.ppc64 requires /bin/sh publican-0.33-0.fc9.noarch requires /usr/bin/perl publican-0.33-0.fc9.noarch requires /bin/env publican-0.33-0.fc9.noarch requires /usr/bin/env pulseaudio-0.9.11-0.0.svn20080516.fc10.ppc64 requires /bin/sh pulseaudio-0.9.11-0.0.svn20080516.fc10.ppc64 requires /sbin/ldconfig pulseaudio-esound-compat-0.9.11-0.0.svn20080516.fc10.ppc64 requires /bin/sh pulseaudio-libs-0.9.11-0.0.svn20080516.fc10.ppc64 requires /sbin/ldconfig pulseaudio-libs-glib2-0.9.11-0.0.svn20080516.fc10.ppc64 requires /sbin/ldconfig pulseaudio-libs-zeroconf-0.9.11-0.0.svn20080516.fc10.ppc64 requires /sbin/ldconfig pulseaudio-utils-0.9.11-0.0.svn20080516.fc10.ppc64 requires /bin/sh pungi-1.2.18-1.fc9.noarch requires /usr/bin/python puppet-0.24.4-1.fc9.noarch requires /bin/sh puppet-0.24.4-1.fc9.noarch requires /usr/bin/ruby puppet-0.24.4-1.fc9.noarch requires /bin/bash puppet-server-0.24.4-1.fc9.noarch requires /bin/sh puppet-server-0.24.4-1.fc9.noarch requires /bin/bash puppet-server-0.24.4-1.fc9.noarch requires /usr/bin/ruby pure-ftpd-1.0.21-15.fc9.ppc64 requires /bin/sh pure-ftpd-1.0.21-15.fc9.ppc64 requires /usr/bin/python pure-ftpd-1.0.21-15.fc9.ppc64 requires /usr/bin/perl pure-ftpd-1.0.21-15.fc9.ppc64 requires /bin/bash pure-ftpd-selinux-1.0.21-15.fc9.ppc64 requires /bin/sh puretls-0.9-0.2.b5.5jpp.1.fc9.ppc64 requires /bin/sh puretls-demo-0.9-0.2.b5.5jpp.1.fc9.ppc64 requires /bin/sh puretls-demo-0.9-0.2.b5.5jpp.1.fc9.ppc64 requires /usr/bin/perl pvm-3.4.5-9.fc9.ppc64 requires /bin/csh pvm-3.4.5-9.fc9.ppc64 requires /bin/sh pvm-3.4.5-9.fc9.ppc64 requires /bin/sh pvm-gui-3.4.5-9.fc9.ppc64 requires /bin/csh pvm-gui-3.4.5-9.fc9.ppc64 requires /bin/sh pwlib-1.10.10-6.fc9.ppc64 requires /sbin/ldconfig pwlib-devel-1.10.10-6.fc9.ppc64 requires /bin/sh pybackpack-0.5.4-2.fc9.noarch requires /usr/bin/python pybliographer-1.2.11-2.fc9.noarch requires /bin/sh pybliographer-1.2.11-2.fc9.noarch requires /bin/sh pybliographer-1.2.11-2.fc9.noarch requires /usr/bin/python pycairo-1.4.12-3.fc10.ppc64 requires /usr/bin/env pychecker-0.8.17-4.noarch requires /bin/sh pychess-0.8-2.fc9.noarch requires /usr/bin/python pychess-0.8-2.fc9.noarch requires /usr/bin/env pydict-0.3.0-11.fc8.noarch requires /bin/sh pyflakes-0.2.1-3.fc7.noarch requires /usr/bin/python pyflowtools-0.3.3-1.fc9.ppc64 requires /usr/bin/env pygsl-0.9.1-8.fc9.ppc64 requires /usr/bin/env pygtk2-2.12.1-6.fc9.ppc64 requires /usr/bin/env pygtk2-2.12.1-6.fc9.ppc64 requires /usr/bin/python pygtk2-codegen-2.12.1-6.fc9.ppc64 requires /bin/sh pygtkglext-1.1.0-4.fc9.ppc64 requires /usr/bin/env pyicq-t-0.8-4.b.fc9.noarch requires /bin/sh pyicq-t-0.8-4.b.fc9.noarch requires /bin/bash pyicq-t-0.8-4.b.fc9.noarch requires /sbin/chkconfig pyicq-t-0.8-4.b.fc9.noarch requires /usr/bin/env pyicq-t-0.8-4.b.fc9.noarch requires /sbin/service pyjigdo-0.3.0-1.fc10.noarch requires /usr/bin/python pykickstart-1.34-1.fc10.noarch requires /usr/bin/python pylint-0.14.0-1.fc9.noarch requires /usr/bin/python pylint-gui-0.14.0-1.fc9.noarch requires /usr/bin/python pypar2-1.4-1.fc8.noarch requires /bin/sh pypar2-1.4-1.fc8.noarch requires /usr/bin/python pypoker-eval-135.0-1.fc9.ppc64 requires /sbin/ldconfig pyscript-0.6.1-2.fc9.noarch requires /usr/bin/python python-2.5.1-25.fc9.ppc64 requires /usr/bin/env python-2.5.1-25.fc9.ppc64 requires /bin/sh python-2.5.1-25.fc9.ppc64 requires /usr/bin/python2.5 python-4Suite-XML-1.0.2-3.ppc64 requires /usr/bin/env python-Coherence-0.5.0-1.fc9.noarch requires /usr/bin/python python-ZSI-2.0-3.fc9.noarch requires /usr/bin/env python-ZSI-2.0-3.fc9.noarch requires /usr/bin/python python-amara-1.2.0.2-2.fc8.noarch requires /usr/bin/python python-bugzilla-0.3-1.fc9.noarch requires /usr/bin/python python-cheetah-2.0.1-2.fc9.ppc64 requires /usr/bin/python python-clientform-0.2.7-2.fc9.noarch requires /usr/bin/env python-demjson-1.3-2.fc9.noarch requires /usr/bin/python python-devel-2.5.1-25.fc9.ppc64 requires /bin/sh python-dialog-2.7-7.fc8.noarch requires /usr/bin/env python-docutils-0.4-8.fc9.noarch requires /usr/bin/python python-durus-3.5-3.fc7.ppc64 requires /usr/bin/python python-exif-1.0.7-4.fc9.noarch requires /bin/bash python-exif-1.0.7-4.fc9.noarch requires /usr/bin/env python-eyed3-0.6.15-1.fc9.noarch requires /usr/bin/env python-formencode-1.0-1.fc9.noarch requires /bin/sh python-formencode-1.0-1.fc9.noarch requires /usr/bin/python python-igraph-0.5-5.fc9.ppc64 requires /usr/bin/python python-imaging-devel-1.1.6-9.fc9.ppc64 requires /usr/bin/env python-imaging-devel-1.1.6-9.fc9.ppc64 requires /usr/bin/python python-inotify-examples-0.7.1-2.fc9.ppc64 requires /bin/sh python-inotify-examples-0.7.1-2.fc9.ppc64 requires /usr/bin/env python-kaa-metadata-0.7.3-1.fc9.ppc64 requires /usr/bin/python python-kid-0.9.6-2.fc8.noarch requires /usr/bin/env python-kiwi-1.9.21-1.fc10.noarch requires /usr/bin/python python-kiwi-docs-1.9.21-1.fc10.noarch requires /usr/bin/env python-libgmail-0.1.8-2.fc9.noarch requires /usr/bin/env python-libgmail-docs-0.3-6.fc9.noarch requires /usr/bin/env python-libs-2.5.1-25.fc9.ppc64 requires /sbin/ldconfig python-logilab-common-0.28.0-1.fc9.noarch requires /usr/bin/python python-matplotlib-0.91.2-2.fc9.ppc64 requires /usr/bin/env python-mechanize-0.1.6-0.2.b.fc9.noarch requires /usr/bin/python python-musicbrainz2-0.5.0-2.fc9.noarch requires /usr/bin/python python-mutagen-1.13-2.fc9.noarch requires /usr/bin/python python-nevow-0.9.29-2.fc9.noarch requires /usr/bin/python 1:python-nltk-0.9.2-1.fc9.noarch requires /usr/bin/env 1:python-nltk-0.9.2-1.fc9.noarch requires /usr/bin/python python-nose-0.10.1-1.fc9.noarch requires /usr/bin/python python-numarray-1.5.2-6.fc9.ppc64 requires /usr/bin/env python-numarray-1.5.2-6.fc9.ppc64 requires /bin/sh python-paste-script-1.6.2-2.fc9.noarch requires /usr/bin/env python-paste-script-1.6.2-2.fc9.noarch requires /usr/bin/python python-pp-1.5.3-1.fc9.noarch requires /usr/bin/python python-pyblock-0.31-2.ppc64 requires /usr/bin/python python-pygments-0.9-2.fc9.noarch requires /usr/bin/python python-pyspf-2.0.3-1.fc8.noarch requires /usr/bin/python python-qpid-0.2-10.fc9.noarch requires /usr/bin/env python-setuptools-0.6c7-2.fc8.noarch requires /usr/bin/python python-setuptools-devel-0.6c7-2.fc8.noarch requires /usr/bin/python python-simpletal-4.1-5.fc7.noarch requires /usr/bin/python python-sqlobject-0.10.1-1.fc10.noarch requires /usr/bin/python python-tag-0.94.1-1.fc10.ppc64 requires /usr/bin/env python-test-2.5.1-25.fc9.ppc64 requires /usr/bin/env python-tools-2.5.1-25.fc9.ppc64 requires /bin/bash python-tools-2.5.1-25.fc9.ppc64 requires /usr/bin/env python-tools-2.5.1-25.fc9.ppc64 requires /bin/sh python-tools-2.5.1-25.fc9.ppc64 requires /usr/bin/python python-tpg-3.1.0-4.fc7.noarch requires /usr/bin/python python-tunepimp-0.5.3-11.fc9.ppc64 requires /usr/bin/env python-twisted-conch-0.8.0-4.fc9.ppc64 requires /usr/libexec/twisted-dropin-cache python-twisted-conch-0.8.0-4.fc9.ppc64 requires /usr/bin/python python-twisted-core-2.5.0-4.fc9.ppc64 requires /usr/bin/python python-twisted-core-2.5.0-4.fc9.ppc64 requires /usr/libexec/twisted-dropin-cache python-twisted-core-2.5.0-4.fc9.ppc64 requires /usr/bin/env python-twisted-lore-0.2.0-6.fc9.ppc64 requires /usr/libexec/twisted-dropin-cache python-twisted-lore-0.2.0-6.fc9.ppc64 requires /usr/bin/python python-twisted-mail-0.4.0-4.fc9.ppc64 requires /usr/libexec/twisted-dropin-cache python-twisted-mail-0.4.0-4.fc9.ppc64 requires /bin/sh python-twisted-mail-0.4.0-4.fc9.ppc64 requires /usr/bin/python python-twisted-names-0.4.0-3.fc9.ppc64 requires /usr/libexec/twisted-dropin-cache python-twisted-news-0.3.0-3.fc9.ppc64 requires /usr/libexec/twisted-dropin-cache python-twisted-web-0.7.0-3.fc9.ppc64 requires /usr/libexec/twisted-dropin-cache python-twisted-words-0.5.0-3.fc9.ppc64 requires /usr/libexec/twisted-dropin-cache python-twisted-words-0.5.0-3.fc9.ppc64 requires /usr/bin/python python-twyt-0.8-1.fc9.noarch requires /usr/bin/python python-urlgrabber-3.0.0-7.fc10.noarch requires /usr/bin/python python-virtinst-0.300.3-6.fc10.noarch requires /usr/bin/python python-vobject-0.6.0-2.fc9.noarch requires /usr/bin/python python-which-1.1.0-3.fc9.noarch requires /bin/sh pyzor-0.4.0-11.fc7.noarch requires /usr/bin/python q-7.10-3.fc9.ppc64 requires /bin/sh q-7.10-3.fc9.ppc64 requires /sbin/install-info q-7.10-3.fc9.ppc64 requires libMagick.so.10()(64bit) q-7.10-3.fc9.ppc64 requires /sbin/ldconfig q-7.10-3.fc9.ppc64 requires /bin/sh q-devel-7.10-3.fc9.ppc64 requires /bin/sh qa-assistant-0.4.90.5-2.fc6.noarch requires /bin/sh qa-assistant-0.4.90.5-2.fc6.noarch requires /usr/bin/xmlcatalog qa-assistant-0.4.90.5-2.fc6.noarch requires /usr/bin/python qalculate-gtk-0.9.6-4.fc9.ppc64 requires /bin/sh qalculate-kde-0.9.6-5.fc9.ppc64 requires /bin/sh qascade-0.1-10.fc9.ppc64 requires /bin/sh qbanking-2.3.3-3.fc9.ppc64 requires /sbin/ldconfig qbanking-devel-2.3.3-3.fc9.ppc64 requires /bin/sh qca-1.0-10.fc9.ppc64 requires /sbin/ldconfig qca2-2.0.0-2.fc9.ppc64 requires /sbin/ldconfig qcad-2.0.5.0-8.fc9.ppc64 requires /bin/sh qct-1.5-6.fc9.ppc64 requires /usr/bin/env qct-1.5-6.fc9.ppc64 requires /usr/bin/python qdbm-1.8.77-3.fc9.ppc64 requires /sbin/ldconfig qdbm++-1.8.77-3.fc9.ppc64 requires /sbin/ldconfig qdbm-java-1.8.77-3.fc9.ppc64 requires /sbin/ldconfig qdbm-perl-1.8.77-3.fc9.ppc64 requires /usr/bin/perl qfaxreader-0.3.1-9.fc9.3.ppc64 requires /bin/sh qgis-0.9.1-5.fc9.ppc64 requires /usr/bin/python qgis-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) qgis-0.9.1-5.fc9.ppc64 requires /sbin/ldconfig qgis-grass-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.ppc64 requires /sbin/ldconfig qhull-2003.1-10.fc9.ppc64 requires /sbin/ldconfig qimageblitz-0.0.4-0.4.svn706674.fc9.ppc64 requires /sbin/ldconfig qiv-2.0-9.fc9.ppc64 requires /bin/sh qjackctl-0.3.1a-6.fc9.ppc64 requires /bin/sh qmmp-0.1.5-2.fc9.ppc64 requires /bin/sh qmmp-0.1.5-2.fc9.ppc64 requires /sbin/ldconfig qof-0.7.5-2.fc9.ppc64 requires /sbin/ldconfig qpxtool-0.6.1-9.fc9.ppc64 requires /sbin/ldconfig qscintilla-2.2-1.fc10.ppc64 requires /sbin/ldconfig qstars-0.4-6.fc9.ppc64 requires /bin/sh qstars-xscreensaver-0.4-6.fc9.ppc64 requires /bin/sh qsynth-0.2.5-7.fc9.ppc64 requires /bin/sh 1:qt-4.4.0-3.fc10.ppc64 requires /sbin/ldconfig 1:qt-4.4.0-3.fc10.ppc64 requires /bin/bash 1:qt-devel-4.4.0-3.fc10.ppc64 requires /bin/sh 1:qt-devel-4.4.0-3.fc10.ppc64 requires /bin/bash 1:qt-doc-4.4.0-3.fc10.ppc64 requires /bin/bash qt-qsa-1.1.5-5.fc9.ppc64 requires /sbin/ldconfig qt-recordmydesktop-0.3.7-1.fc9.noarch requires /usr/bin/python 1:qt-x11-4.4.0-3.fc10.ppc64 requires /bin/sh 1:qt-x11-4.4.0-3.fc10.ppc64 requires /bin/bash qt3-3.3.8b-12.fc9.ppc64 requires /etc/ld.so.conf.d qt3-3.3.8b-12.fc9.ppc64 requires /sbin/ldconfig qt3-devel-3.3.8b-12.fc9.ppc64 requires /usr/bin/perl qtpfsgui-1.9.2-1.fc10.ppc64 requires /bin/sh quagga-0.99.9-6.fc9.ppc64 requires /bin/sh quagga-0.99.9-6.fc9.ppc64 requires /sbin/install-info quagga-0.99.9-6.fc9.ppc64 requires /bin/bash quagga-contrib-0.99.9-6.fc9.ppc64 requires /usr/bin/perl quake3-1.34-0.9.rc4.fc9.ppc64 requires /bin/bash quake3-demo-1.34-0.9.rc4.fc9.ppc64 requires /bin/sh quake3-demo-1.34-0.9.rc4.fc9.ppc64 requires /bin/bash quarry-0.2.0-3.fc9.ppc64 requires /bin/sh qucs-0.0.14-1.fc9.ppc64 requires /usr/bin/perl qucs-0.0.14-1.fc9.ppc64 requires /bin/sh quesa-1.8-1.fc9.ppc64 requires /sbin/ldconfig quesoglc-0.7.1-1.fc10.ppc64 requires /sbin/ldconfig queuegraph-1.1-3.fc9.noarch requires /usr/bin/perl queuegraph-1.1-3.fc9.noarch requires /bin/sh queuegraph-selinux-1.1-3.fc9.noarch requires /usr/sbin/semodule queuegraph-selinux-1.1-3.fc9.noarch requires /sbin/fixfiles queuegraph-selinux-1.1-3.fc9.noarch requires /bin/sh queuegraph-selinux-1.1-3.fc9.noarch requires /sbin/restorecon quilt-0.46-5.fc9.ppc64 requires /usr/bin/perl quilt-0.46-5.fc9.ppc64 requires /bin/bash quodlibet-1.0-3.fc9.ppc64 requires /usr/bin/env qwt-5.0.2-6.fc9.ppc64 requires /sbin/ldconfig qwtplot3d-0.2.7-6.fc9.ppc64 requires /sbin/ldconfig qwtplot3d-qt4-0.2.7-6.fc9.ppc64 requires /sbin/ldconfig radiusclient-ng-0.5.6-3.fc9.ppc64 requires /sbin/ldconfig radiusclient-ng-utils-0.5.6-3.fc9.ppc64 requires /bin/sh radvd-1.1-3.fc10.ppc64 requires /usr/sbin/userdel radvd-1.1-3.fc10.ppc64 requires /bin/sh radvd-1.1-3.fc10.ppc64 requires /usr/sbin/useradd radvd-1.1-3.fc10.ppc64 requires /bin/sh rafkill-1.2.2-7.fc9.ppc64 requires /bin/sh raidem-0.3.1-8.fc9.ppc64 requires /bin/sh raptor-1.4.16-2.fc9.ppc64 requires /sbin/ldconfig raptor-devel-1.4.16-2.fc9.ppc64 requires /bin/sh rarian-0.8.0-1.fc9.ppc64 requires /sbin/ldconfig rarian-compat-0.8.0-1.fc9.ppc64 requires /bin/sh rarian-compat-0.8.0-1.fc9.ppc64 requires /bin/bash rarian-compat-0.8.0-1.fc9.ppc64 requires /bin/sh rarpd-ss981107-26.1.fc9.ppc64 requires /bin/sh rarpd-ss981107-26.1.fc9.ppc64 requires /bin/bash rarpd-ss981107-26.1.fc9.ppc64 requires /sbin/chkconfig rasqal-0.9.15-1.fc9.ppc64 requires /sbin/ldconfig rasqal-devel-0.9.15-1.fc9.ppc64 requires /bin/sh ratpoison-1.4.1-2.fc9.ppc64 requires /bin/sh ratpoison-1.4.1-2.fc9.ppc64 requires /usr/bin/perl ratpoison-1.4.1-2.fc9.ppc64 requires /bin/bash ratpoison-1.4.1-2.fc9.ppc64 requires /sbin/install-info ratpoison-1.4.1-2.fc9.ppc64 requires /bin/sh rawstudio-1.0-1.fc10.ppc64 requires /bin/sh raydium-1.2-8.fc9.ppc64 requires /sbin/ldconfig rb_libtorrent-0.12.1-1.fc9.ppc64 requires /sbin/ldconfig rblcheck-1.5-15.fc9.ppc64 requires /bin/sh rbldnsd-0.996b-1.fc9.ppc64 requires /bin/sh rbldnsd-0.996b-1.fc9.ppc64 requires /bin/bash rbldnsd-0.996b-1.fc9.ppc64 requires /sbin/chkconfig rdiff-backup-1.0.5-7.fc9.ppc64 requires /usr/bin/python 1:readahead-1.4.2-5.fc9.ppc64 requires /bin/sh 1:readahead-1.4.2-5.fc9.ppc64 requires /bin/bash 1:readahead-1.4.2-5.fc9.ppc64 requires /bin/gawk 1:readahead-1.4.2-5.fc9.ppc64 requires /sbin/chkconfig 1:readahead-1.4.2-5.fc9.ppc64 requires /bin/sh 1:readahead-1.4.2-5.fc9.ppc64 requires /sbin/service readline-5.2-13.fc9.ppc64 requires /bin/sh readline-5.2-13.fc9.ppc64 requires /sbin/ldconfig readline-5.2-13.fc9.ppc64 requires /sbin/install-info readline-devel-5.2-13.fc9.ppc64 requires /sbin/install-info readline-devel-5.2-13.fc9.ppc64 requires /bin/sh recode-3.6-26.fc9.ppc64 requires /bin/sh recode-3.6-26.fc9.ppc64 requires /sbin/ldconfig recode-3.6-26.fc9.ppc64 requires /sbin/install-info redet-8.23-3.fc9.noarch requires /bin/sh redet-8.23-3.fc9.noarch requires /bin/sh redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/tty redhat-lsb-3.1-19.fc8.ppc64 requires /bin/cp redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/uniq redhat-lsb-3.1-19.fc8.ppc64 requires /bin/dd redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/pax redhat-lsb-3.1-19.fc8.ppc64 requires /bin/stty redhat-lsb-3.1-19.fc8.ppc64 requires /bin/ls redhat-lsb-3.1-19.fc8.ppc64 requires /bin/echo redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/tee redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/id redhat-lsb-3.1-19.fc8.ppc64 requires /bin/gzip redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/ipcrm redhat-lsb-3.1-19.fc8.ppc64 requires /bin/mknod redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/chfn redhat-lsb-3.1-19.fc8.ppc64 requires /bin/gettext redhat-lsb-3.1-19.fc8.ppc64 requires /bin/more redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/nohup redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/patch redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/make redhat-lsb-3.1-19.fc8.ppc64 requires /bin/touch redhat-lsb-3.1-19.fc8.ppc64 requires /bin/pwd redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/mkfifo redhat-lsb-3.1-19.fc8.ppc64 requires /usr/lib64/lsb/remove_initd redhat-lsb-3.1-19.fc8.ppc64 requires /bin/mv redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/join redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/fold redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/col redhat-lsb-3.1-19.fc8.ppc64 requires /bin/tar redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/msgfmt redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/tsort redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/crontab redhat-lsb-3.1-19.fc8.ppc64 requires /bin/gunzip redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/file redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/tail redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/chsh redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/csplit redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/find redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/at redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/od redhat-lsb-3.1-19.fc8.ppc64 requires /bin/mailx redhat-lsb-3.1-19.fc8.ppc64 requires /bin/hostname redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/ar redhat-lsb-3.1-19.fc8.ppc64 requires /bin/chgrp redhat-lsb-3.1-19.fc8.ppc64 requires /bin/true redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/wc redhat-lsb-3.1-19.fc8.ppc64 requires /bin/mount redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/md5sum redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/du redhat-lsb-3.1-19.fc8.ppc64 requires /bin/egrep redhat-lsb-3.1-19.fc8.ppc64 requires /bin/rm redhat-lsb-3.1-19.fc8.ppc64 requires /bin/basename redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/locale redhat-lsb-3.1-19.fc8.ppc64 requires /bin/df redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/paste redhat-lsb-3.1-19.fc8.ppc64 requires /usr/sbin/groupadd redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/killall redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/dirname redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/localedef redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/head redhat-lsb-3.1-19.fc8.ppc64 requires /bin/dmesg redhat-lsb-3.1-19.fc8.ppc64 requires /bin/sed redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/pr redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/logname redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/batch redhat-lsb-3.1-19.fc8.ppc64 requires /bin/awk redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/tr redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/bc redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/cmp redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/passwd redhat-lsb-3.1-19.fc8.ppc64 requires /bin/date redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/expand redhat-lsb-3.1-19.fc8.ppc64 requires /bin/chmod redhat-lsb-3.1-19.fc8.ppc64 requires /usr/lib64/lsb/install_initd redhat-lsb-3.1-19.fc8.ppc64 requires /bin/rmdir redhat-lsb-3.1-19.fc8.ppc64 requires /bin/sleep redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/newgrp redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/expr redhat-lsb-3.1-19.fc8.ppc64 requires /bin/uname redhat-lsb-3.1-19.fc8.ppc64 requires /bin/ln redhat-lsb-3.1-19.fc8.ppc64 requires /bin/nice redhat-lsb-3.1-19.fc8.ppc64 requires /bin/cpio redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/install redhat-lsb-3.1-19.fc8.ppc64 requires /bin/su redhat-lsb-3.1-19.fc8.ppc64 requires /sbin/pidof redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/pathchk redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/groups redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/ipcs redhat-lsb-3.1-19.fc8.ppc64 requires /bin/bash redhat-lsb-3.1-19.fc8.ppc64 requires /bin/env redhat-lsb-3.1-19.fc8.ppc64 requires /bin/fgrep redhat-lsb-3.1-19.fc8.ppc64 requires /bin/grep redhat-lsb-3.1-19.fc8.ppc64 requires /bin/sort redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/iconv redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/split redhat-lsb-3.1-19.fc8.ppc64 requires /usr/sbin/groupdel redhat-lsb-3.1-19.fc8.ppc64 requires /bin/false redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/cksum redhat-lsb-3.1-19.fc8.ppc64 requires /bin/ed redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/man redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/logger redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/m4 redhat-lsb-3.1-19.fc8.ppc64 requires /bin/ps redhat-lsb-3.1-19.fc8.ppc64 requires /bin/cat redhat-lsb-3.1-19.fc8.ppc64 requires /usr/sbin/groupmod redhat-lsb-3.1-19.fc8.ppc64 requires /bin/cut redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/gencat redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/strip redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/nl redhat-lsb-3.1-19.fc8.ppc64 requires /sbin/shutdown redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/xargs redhat-lsb-3.1-19.fc8.ppc64 requires /bin/mkdir redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/time redhat-lsb-3.1-19.fc8.ppc64 requires /usr/sbin/userdel redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/unexpand redhat-lsb-3.1-19.fc8.ppc64 requires /bin/umount redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/getconf redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/diff redhat-lsb-3.1-19.fc8.ppc64 requires /usr/sbin/useradd redhat-lsb-3.1-19.fc8.ppc64 requires /sbin/fuser redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/printf redhat-lsb-3.1-19.fc8.ppc64 requires /usr/sbin/usermod redhat-lsb-3.1-19.fc8.ppc64 requires /bin/sh redhat-lsb-3.1-19.fc8.ppc64 requires /bin/kill redhat-lsb-3.1-19.fc8.ppc64 requires /bin/sync redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/renice redhat-lsb-3.1-19.fc8.ppc64 requires /bin/mktemp redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/test redhat-lsb-3.1-19.fc8.ppc64 requires /usr/bin/comm redhat-lsb-3.1-19.fc8.ppc64 requires /bin/chown redhat-menus-8.9.11-3.fc9.noarch requires /bin/sh redhat-rpm-config-9.0.3-1.fc10.noarch requires /usr/bin/perl redhat-rpm-config-9.0.3-1.fc10.noarch requires /bin/bash redhat-rpm-config-9.0.3-1.fc10.noarch requires /bin/sh redland-1.0.7-1.fc9.ppc64 requires /sbin/ldconfig redland-devel-1.0.7-1.fc9.ppc64 requires /bin/sh redmode-1.0-2.fc9.noarch requires /bin/bash referencer-1.1.2-1.fc10.ppc64 requires /bin/sh regexp-1.5-2jpp.1.fc9.ppc64 requires /bin/sh regexp-javadoc-1.5-2jpp.1.fc9.ppc64 requires /bin/sh regexp-javadoc-1.5-2jpp.1.fc9.ppc64 requires /bin/rm regexp-javadoc-1.5-2jpp.1.fc9.ppc64 requires /bin/ln regexxer-0.9-3.fc9.ppc64 requires /bin/sh rekall-2.4.6-4.fc9.ppc64 requires /bin/sh rekall-2.4.6-4.fc9.ppc64 requires /bin/sh rekall-extra-2.4.6-4.fc9.ppc64 requires /sbin/ldconfig rekall-mysql-2.4.6-4.fc9.ppc64 requires /sbin/ldconfig rekall-odbc-2.4.6-4.fc9.ppc64 requires /sbin/ldconfig rekall-postgresql-2.4.6-4.fc9.ppc64 requires /sbin/ldconfig rekall-python-2.4.6-4.fc9.ppc64 requires /sbin/ldconfig rekall-sqlite-2.4.6-4.fc9.ppc64 requires /sbin/ldconfig remctl-2.11-6.fc9.ppc64 requires /sbin/ldconfig remind-03.01.04-1.fc9.ppc64 requires /usr/bin/perl remind-03.01.04-1.fc9.ppc64 requires /bin/sh remind-gui-03.01.04-1.fc9.ppc64 requires /bin/sh renrot-0.25-4.fc9.noarch requires /usr/bin/perl renrot-0.25-4.fc9.noarch requires /bin/sh repoman-0.9-3.fc8.noarch requires /bin/sh repoman-0.9-3.fc8.noarch requires /usr/bin/env repoview-0.6.2-1.fc9.noarch requires /usr/bin/python resapplet-0.1.1-7.fc9.ppc64 requires /bin/sh revelation-0.4.11-4.1.ppc64 requires /bin/sh revelation-0.4.11-4.1.ppc64 requires /usr/bin/env rgmanager-2.0.23-3.fc9.ppc64 requires /bin/sh rgmanager-2.0.23-3.fc9.ppc64 requires /sbin/findfs rgmanager-2.0.23-3.fc9.ppc64 requires /bin/bash rgmanager-2.0.23-3.fc9.ppc64 requires /bin/sh rgmanager-2.0.23-3.fc9.ppc64 requires /sbin/chkconfig rhpl-0.215-3.ppc64 requires /usr/bin/python rhythmbox-0.11.5-9.fc9.ppc64 requires /bin/sh rhythmbox-0.11.5-9.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) rinetd-0.62-7.fc9.ppc64 requires /bin/sh rinetd-0.62-7.fc9.ppc64 requires /sbin/chkconfig rinetd-0.62-7.fc9.ppc64 requires /bin/sh rinetd-0.62-7.fc9.ppc64 requires /sbin/service rkhunter-1.3.2-2.fc9.noarch requires /usr/bin/perl rkhunter-1.3.2-2.fc9.noarch requires /bin/sh rkward-0.5.0b-2.fc10.ppc64 requires /bin/sh rkward-0.5.0b-2.fc10.ppc64 requires /bin/sh rlog-1.3.7-6.fc9.ppc64 requires /sbin/ldconfig 1:rng-utils-2.0-1.15.1.fc9.ppc64 requires /sbin/chkconfig 1:rng-utils-2.0-1.15.1.fc9.ppc64 requires /sbin/service roadstencil-fonts-1.0-2.fc10.noarch requires /bin/sh rogue-5.4.5-2.fc9.ppc64 requires /bin/sh rosegarden4-1.6.1-2.fc9.ppc64 requires /bin/sh rosegarden4-1.6.1-2.fc9.ppc64 requires /bin/bash rott-registered-1.0-5.fc9.ppc64 requires /bin/sh rott-registered-1.0-5.fc9.ppc64 requires /bin/bash rott-shareware-1.0-5.fc9.ppc64 requires /bin/sh rott-shareware-1.0-5.fc9.ppc64 requires /bin/bash roundcubemail-0.1-1.fc9.noarch requires /bin/sh roundup-1.4.4-1.fc9.noarch requires /bin/sh roundup-1.4.4-1.fc9.noarch requires /bin/bash roundup-1.4.4-1.fc9.noarch requires /sbin/chkconfig roundup-1.4.4-1.fc9.noarch requires /usr/bin/env roundup-1.4.4-1.fc9.noarch requires /usr/bin/python roundup-1.4.4-1.fc9.noarch requires /sbin/service roxterm-1.11.1-1.fc9.ppc64 requires /bin/sh rp-pppoe-3.8-3.fc9.ppc64 requires /bin/bash rp-pppoe-3.8-3.fc9.ppc64 requires /bin/sh rpc2-2.7-1.fc10.ppc64 requires /sbin/ldconfig rpcbind-0.1.4-14.fc9.ppc64 requires /usr/sbin/userdel rpcbind-0.1.4-14.fc9.ppc64 requires /bin/sh rpcbind-0.1.4-14.fc9.ppc64 requires /usr/sbin/groupadd rpcbind-0.1.4-14.fc9.ppc64 requires /usr/sbin/useradd rpcbind-0.1.4-14.fc9.ppc64 requires /bin/sh rpcbind-0.1.4-14.fc9.ppc64 requires /usr/sbin/groupdel rpcbind-0.1.4-14.fc9.ppc64 requires /sbin/chkconfig rpl-1.5.3-4.fc6.noarch requires /usr/bin/env rpm-4.4.2.3-2.fc9.ppc64 requires /bin/sh rpm-4.4.2.3-2.fc9.ppc64 requires /bin/bash rpm-4.4.2.3-2.fc9.ppc64 requires /bin/sh rpm-build-4.4.2.3-2.fc9.ppc64 requires /bin/bash rpm-build-4.4.2.3-2.fc9.ppc64 requires /bin/sh rpm-build-4.4.2.3-2.fc9.ppc64 requires /usr/bin/perl rpm-libs-4.4.2.3-2.fc9.ppc64 requires /sbin/ldconfig rpmdevtools-6.6-1.fc9.noarch requires /usr/bin/python rpmdevtools-6.6-1.fc9.noarch requires /bin/bash rpmdevtools-6.6-1.fc9.noarch requires /bin/sh rpmdevtools-6.6-1.fc9.noarch requires /usr/bin/perl rpmlint-0.82-3.fc9.noarch requires /bin/sh rpmlint-0.82-3.fc9.noarch requires /usr/bin/python rpmrebuild-2.2.2-1.fc10.noarch requires /bin/sh rpmrebuild-2.2.2-1.fc10.noarch requires /bin/bash rpmrebuild-2.2.2-1.fc10.noarch requires /bin/sh rpy-1.0.2-1.fc10.ppc64 requires /bin/sh rpy-1.0.2-1.fc10.ppc64 requires /sbin/install-info rrdtool-1.3-0.14.beta4.fc10.ppc64 requires /sbin/ldconfig rrdtool-tcl-1.3-0.14.beta4.fc10.ppc64 requires /bin/sh rsh-server-0.17-50.fc10.ppc64 requires /etc/pam.d/system-auth rsibreak-0.8.0-5.fc9.ppc64 requires /bin/sh rsnapshot-1.3.0-1.fc8.noarch requires /bin/sh rsnapshot-1.3.0-1.fc8.noarch requires /usr/bin/perl rss-glx-0.8.1.p-19.fc9.ppc64 requires /usr/bin/env rss-glx-xscreensaver-0.8.1.p-19.fc9.ppc64 requires /bin/sh rss2email-2.62-1.1.noarch requires /bin/sh rss2email-2.62-1.1.noarch requires /usr/bin/python rsyslog-3.16.1-1.fc10.ppc64 requires /bin/sh rsyslog-3.16.1-1.fc10.ppc64 requires /sbin/service rsyslog-3.16.1-1.fc10.ppc64 requires /bin/bash rsyslog-3.16.1-1.fc10.ppc64 requires /bin/sh rsyslog-3.16.1-1.fc10.ppc64 requires /sbin/chkconfig rt3-3.6.6-5.fc9.noarch requires /usr/bin/perl rt3-3.6.6-5.fc9.noarch requires /bin/rm rt3-3.6.6-5.fc9.noarch requires /bin/sh rt3-mailgate-3.6.6-5.fc9.noarch requires /usr/bin/perl rubberband-1.0.1-1.fc9.ppc64 requires /sbin/ldconfig ruby-1.8.6.114-1.fc9.ppc64 requires /usr/bin/ruby ruby-cairo-1.5.1-1.fc9.ppc64 requires /usr/bin/env ruby-gettext-package-1.90.0-1.fc9.noarch requires /usr/bin/ruby ruby-gettext-package-doc-1.90.0-1.fc9.noarch requires /usr/bin/ruby ruby-gettext-package-doc-1.90.0-1.fc9.noarch requires /bin/sh ruby-gettext-package-doc-1.90.0-1.fc9.noarch requires /usr/bin/env ruby-gtk2-0.16.0-28.fc9.ppc64 requires /usr/bin/env ruby-hyperestraier-1.4.13-2.fc9.ppc64 requires /usr/bin/ruby ruby-irb-1.8.6.114-1.fc9.ppc64 requires /usr/bin/ruby ruby-libglade2-0.16.0-28.fc9.ppc64 requires /usr/bin/env ruby-libs-1.8.6.114-1.fc9.ppc64 requires /sbin/ldconfig ruby-panelapplet2-0.16.0-28.fc9.ppc64 requires /usr/bin/env ruby-panelapplet2-0.16.0-28.fc9.ppc64 requires /usr/bin/ruby ruby-poppler-0.16.0-28.fc9.ppc64 requires /usr/bin/env ruby-qdbm-1.8.77-3.fc9.ppc64 requires /usr/bin/ruby ruby-racc-1.4.5-2.fc6.noarch requires /usr/bin/ruby ruby-rdoc-1.8.6.114-1.fc9.ppc64 requires /usr/bin/ruby ruby-ri-1.8.6.114-1.fc9.ppc64 requires /usr/bin/ruby ruby-rsvg-0.16.0-28.fc9.ppc64 requires /usr/bin/env ruby-tcltk-1.8.6.114-1.fc9.ppc64 requires /usr/bin/env ruby-vte-0.16.0-28.fc9.ppc64 requires /usr/bin/env rubygem-activeldap-0.10.0-10.fc10.noarch requires /usr/bin/ruby rubygem-activeldap-0.10.0-10.fc10.noarch requires /usr/bin/env rubygem-activeldap-0.10.0-10.fc10.noarch requires /bin/sh rubygem-daemons-1.0.7-2.fc8.noarch requires /usr/bin/env rubygem-gem2rpm-0.5.3-1.fc10.noarch requires /usr/bin/env rubygem-gem_plugin-0.2.2-2.fc8.noarch requires /usr/bin/ruby rubygem-hoe-1.5.1-6.fc10.noarch requires /usr/bin/env rubygem-mongrel-1.0.1-6.fc9.ppc64 requires /usr/bin/ruby rubygem-mongrel-1.0.1-6.fc9.ppc64 requires /usr/bin/env rubygem-rails-2.0.2-2.fc9.noarch requires /usr/bin/ruby rubygem-rails-2.0.2-2.fc9.noarch requires /usr/bin/env rubygem-rake-0.8.1-2.fc10.noarch requires /usr/bin/ruby rubygem-rubyforge-0.4.5-2.fc10.noarch requires /usr/bin/env rubygem-zoom-0.4.1-2.fc9.3.ppc64 requires /usr/bin/ruby rubygems-0.9.4-1.fc8.noarch requires /usr/bin/ruby rubyripper-0.5.0-2.fc9.noarch requires /usr/bin/env rubyripper-gui-0.5.0-2.fc9.noarch requires /usr/bin/env rudecgi-5.1.0-2.fc9.ppc64 requires /sbin/ldconfig rudeconfig-5.0.5-1.fc7.ppc64 requires /sbin/ldconfig rudesocket-1.3.0-2.fc9.ppc64 requires /sbin/ldconfig rusers-server-0.17-53.fc9.ppc64 requires /bin/sh rusers-server-0.17-53.fc9.ppc64 requires /bin/bash rusers-server-0.17-53.fc9.ppc64 requires /sbin/chkconfig rusers-server-0.17-53.fc9.ppc64 requires /bin/sh rvm-1.15-1.fc10.ppc64 requires /sbin/ldconfig rwall-server-0.17-28.fc9.ppc64 requires /bin/sh rwall-server-0.17-28.fc9.ppc64 requires /etc/init.d rwall-server-0.17-28.fc9.ppc64 requires /sbin/chkconfig rwall-server-0.17-28.fc9.ppc64 requires /bin/sh rwho-0.17-29.fc9.ppc64 requires /bin/sh rwho-0.17-29.fc9.ppc64 requires /sbin/chkconfig rwho-0.17-29.fc9.ppc64 requires /bin/sh rwho-0.17-29.fc9.ppc64 requires /etc/init.d rxvt-2.7.10-15.fc9.ppc64 requires /bin/sh sabayon-2.22.0-3.fc10.ppc64 requires /bin/sh sabayon-2.22.0-3.fc10.ppc64 requires /usr/bin/env sabayon-apply-2.22.0-3.fc10.ppc64 requires /bin/bash sabayon-apply-2.22.0-3.fc10.ppc64 requires /usr/bin/env safekeep-common-1.0.3-2.fc9.noarch requires /usr/bin/python safekeep-server-1.0.3-2.fc9.noarch requires /bin/sh safekeep-server-1.0.3-2.fc9.noarch requires /usr/sbin/groupadd safekeep-server-1.0.3-2.fc9.noarch requires /usr/sbin/useradd safekeep-server-1.0.3-2.fc9.noarch requires /bin/sh sagator-1.0.0-1.fc9.noarch requires /bin/sh sagator-1.0.0-1.fc9.noarch requires /sbin/chkconfig sagator-1.0.0-1.fc9.noarch requires /usr/bin/python2 sagator-1.0.0-1.fc9.noarch requires /bin/sh sagator-1.0.0-1.fc9.noarch requires /usr/bin/python sagator-1.0.0-1.fc9.noarch requires /sbin/service sage-0.2.0-3.fc9.ppc64 requires /sbin/ldconfig samba-3.2.0-1.pre3.10.fc10.ppc64 requires /bin/sh samba-3.2.0-1.pre3.10.fc10.ppc64 requires /sbin/service samba-3.2.0-1.pre3.10.fc10.ppc64 requires /bin/bash samba-3.2.0-1.pre3.10.fc10.ppc64 requires /bin/sh samba-3.2.0-1.pre3.10.fc10.ppc64 requires /usr/bin/perl samba-3.2.0-1.pre3.10.fc10.ppc64 requires /sbin/chkconfig samba-client-3.2.0-1.pre3.10.fc10.ppc64 requires /usr/bin/perl samba-client-3.2.0-1.pre3.10.fc10.ppc64 requires /bin/sh samba-common-3.2.0-1.pre3.10.fc10.ppc64 requires /bin/sh samba-common-3.2.0-1.pre3.10.fc10.ppc64 requires /usr/sbin/groupadd samba-common-3.2.0-1.pre3.10.fc10.ppc64 requires /sbin/service samba-common-3.2.0-1.pre3.10.fc10.ppc64 requires /sbin/chkconfig samba-winbind-3.2.0-1.pre3.10.fc10.ppc64 requires /bin/sh samba-winbind-3.2.0-1.pre3.10.fc10.ppc64 requires /usr/sbin/groupadd samba-winbind-3.2.0-1.pre3.10.fc10.ppc64 requires /sbin/service samba-winbind-3.2.0-1.pre3.10.fc10.ppc64 requires /bin/sh samba-winbind-3.2.0-1.pre3.10.fc10.ppc64 requires /sbin/chkconfig samyak-fonts-devanagari-1.2.0-2.fc9.noarch requires /bin/sh samyak-fonts-gujarati-1.2.0-2.fc9.noarch requires /bin/sh samyak-fonts-malayalam-1.2.0-2.fc9.noarch requires /bin/sh samyak-fonts-oriya-1.2.0-2.fc9.noarch requires /bin/sh samyak-fonts-tamil-1.2.0-2.fc9.noarch requires /bin/sh sane-backends-1.0.19-10.fc9.ppc64 requires /bin/bash sane-backends-devel-1.0.19-10.fc9.ppc64 requires /bin/sh sane-backends-libs-1.0.19-10.fc9.ppc64 requires /sbin/ldconfig sarai-fonts-1.0-4.fc9.noarch requires /bin/sh saxon-6.5.5-1jpp.2.fc7.noarch requires /bin/sh saxon-6.5.5-1jpp.2.fc7.noarch requires /usr/sbin/update-alternatives sazanami-fonts-gothic-0.20040629-4.20061016.fc8.noarch requires /bin/sh sazanami-fonts-mincho-0.20040629-4.20061016.fc8.noarch requires /bin/sh sblim-cmpi-base-1.5.4-7.fc7.ppc64 requires /bin/sh sblim-cmpi-base-1.5.4-7.fc7.ppc64 requires /sbin/ldconfig sblim-cmpi-base-1.5.4-7.fc7.ppc64 requires /bin/sh sblim-cmpi-base-test-1.5.4-7.fc7.ppc64 requires /usr/bin/perl sblim-cmpi-base-test-1.5.4-7.fc7.ppc64 requires /bin/bash sblim-cmpi-base-test-1.5.4-7.fc7.ppc64 requires /bin/sh sblim-testsuite-1.2.4-3.fc6.noarch requires /usr/bin/perl sblim-testsuite-1.2.4-3.fc6.noarch requires /bin/sh scalapack-1.7.5-2.fc9.ppc64 requires /sbin/ldconfig scanbuttond-0.2.3-12.fc9.ppc64 requires /bin/sh scanbuttond-0.2.3-12.fc9.ppc64 requires /sbin/service scanbuttond-0.2.3-12.fc9.ppc64 requires /sbin/chkconfig scanbuttond-0.2.3-12.fc9.ppc64 requires /sbin/ldconfig scanbuttond-0.2.3-12.fc9.ppc64 requires /bin/bash scanbuttond-0.2.3-12.fc9.ppc64 requires /bin/sh scapy-1.1.1-4.fc8.noarch requires /usr/bin/env schismtracker-0.5-0.7.rc1.fc9.ppc64 requires /bin/sh schroedinger-1.0.0-1.fc9.ppc64 requires /sbin/ldconfig scidavis-0.1.3-2.fc10.ppc64 requires /bin/sh scim-1.4.7-23.fc10.ppc64 requires /bin/sh scim-1.4.7-23.fc10.ppc64 requires /usr/sbin/alternatives scim-1.4.7-23.fc10.ppc64 requires /bin/sh scim-bridge-gtk-0.4.15-5.fc9.ppc64 requires /bin/sh scim-gtk-1.4.7-23.fc10.ppc64 requires /bin/sh scim-input-pad-0.1.1-8.fc9.ppc64 requires /sbin/ldconfig scim-input-pad-0.1.1-8.fc9.ppc64 requires /bin/sh scim-libs-1.4.7-23.fc10.ppc64 requires /sbin/ldconfig scim-python-pinyin-0.1.12-1.fc10.ppc64 requires /bin/sh scim-python-xingma-0.1.12-1.fc10.ppc64 requires /usr/bin/python scim-python-xingma-cangjie-0.1.12-1.fc10.ppc64 requires /bin/sh scim-python-xingma-erbi-0.1.12-1.fc10.ppc64 requires /bin/sh scim-python-xingma-wubi-0.1.12-1.fc10.ppc64 requires /bin/sh scim-python-xingma-zhengma-0.1.12-1.fc10.ppc64 requires /bin/sh scim-tables-0.5.7-5.fc9.ppc64 requires /sbin/ldconfig scim-tomoe-0.6.0-2.fc8.ppc64 requires /bin/sh scons-0.98.3-2.fc10.noarch requires /usr/bin/python scorched3d-41.3-2.fc9.ppc64 requires /bin/sh scorchwentbonkers-1.1-5.fc9.ppc64 requires /bin/sh scratchpad-0.3.0-4.fc9.ppc64 requires /bin/sh screen-4.0.3-11.fc9.ppc64 requires /bin/sh screen-4.0.3-11.fc9.ppc64 requires /usr/sbin/groupadd screen-4.0.3-11.fc9.ppc64 requires /sbin/install-info scribes-0.3.3.3-2.fc9.noarch requires /bin/sh scribes-0.3.3.3-2.fc9.noarch requires /usr/bin/env scribus-1.3.4-5.fc9.ppc64 requires /bin/sh scsi-target-utils-0.0-4.20071227snap.fc9.ppc64 requires /bin/sh scsi-target-utils-0.0-4.20071227snap.fc9.ppc64 requires /sbin/service scsi-target-utils-0.0-4.20071227snap.fc9.ppc64 requires /sbin/chkconfig scsi-target-utils-0.0-4.20071227snap.fc9.ppc64 requires /bin/sh scummvm-0.11.1-2.fc9.ppc64 requires /bin/sh scythia-0.9.3-2.2.fc9.ppc64 requires /bin/sh sdcc-2.6.0-12.fc9.ppc64 requires /bin/sh sdcc-libc-sources-2.6.0-12.fc9.ppc64 requires /bin/sh sdljava-0.9.1-9.fc9.ppc64 requires /bin/sh sdljava-demo-0.9.1-9.fc9.ppc64 requires /usr/share/fonts/dejavu/DejaVuSans-BoldOblique.ttf sdljava-demo-0.9.1-9.fc9.ppc64 requires /usr/share/fonts/dejavu/DejaVuSans-Bold.ttf sdljava-demo-0.9.1-9.fc9.ppc64 requires /usr/share/fonts/dejavu/DejaVuSans-Oblique.ttf sdljava-demo-0.9.1-9.fc9.ppc64 requires /usr/share/fonts/dejavu/DejaVuSans.ttf sdljava-demo-0.9.1-9.fc9.ppc64 requires /bin/sh sdljava-javadoc-0.9.1-9.fc9.ppc64 requires /bin/sh seahorse-2.22.1-1.fc9.ppc64 requires /bin/sh seahorse-2.22.1-1.fc9.ppc64 requires /bin/sh seahorse-adventures-1.0-2.fc8.noarch requires /bin/sh seahorse-adventures-1.0-2.fc8.noarch requires /usr/bin/env seahorse-adventures-1.0-2.fc8.noarch requires /usr/bin/python seamonkey-1.1.9-4.fc9.ppc64 requires /bin/sh seamonkey-1.1.9-4.fc9.ppc64 requires /bin/sh sear-0.6.3-10.fc9.ppc64 requires /bin/sh sec-2.4.1-1.fc8.noarch requires /bin/sh sec-2.4.1-1.fc8.noarch requires /bin/bash sec-2.4.1-1.fc8.noarch requires /usr/bin/perl sectool-0.7.3-1.fc10.noarch requires /usr/bin/env sectool-0.7.3-1.fc10.noarch requires /usr/bin/python sectool-gui-0.7.3-1.fc10.noarch requires /usr/bin/python sed-4.1.5-10.fc9.ppc64 requires /bin/sh sed-4.1.5-10.fc9.ppc64 requires /sbin/install-info seedit-2.2.0-2.fc9.ppc64 requires /usr/bin/python seedit-2.2.0-2.fc9.ppc64 requires /bin/sh seedit-gui-2.2.0-2.fc9.ppc64 requires /usr/bin/python seedit-policy-2.2.0-2.fc9.ppc64 requires /bin/sh seedit-policy-2.2.0-2.fc9.ppc64 requires /bin/sh seekwatcher-0.10-1.fc9.noarch requires /usr/bin/env selinux-policy-3.3.1-45.fc10.noarch requires /bin/sh selinux-policy-devel-3.3.1-45.fc10.noarch requires /bin/sh selinux-policy-devel-3.3.1-45.fc10.noarch requires /usr/bin/env selinux-policy-mls-3.3.1-45.fc10.noarch requires /bin/sh selinux-policy-targeted-3.3.1-45.fc10.noarch requires /bin/sh selinux-policy-targeted-3.3.1-45.fc10.noarch requires /bin/sh sendmail-8.14.2-4.fc9.ppc64 requires /bin/sh sendmail-8.14.2-4.fc9.ppc64 requires /usr/sbin/saslauthd sendmail-8.14.2-4.fc9.ppc64 requires /bin/bash sendmail-8.14.2-4.fc9.ppc64 requires /usr/sbin/alternatives sendmail-cf-8.14.2-4.fc9.ppc64 requires /bin/sh sepostgresql-8.3.1-2.197.fc10.ppc64 requires /bin/sh sepostgresql-8.3.1-2.197.fc10.ppc64 requires /sbin/service sepostgresql-8.3.1-2.197.fc10.ppc64 requires /bin/sh sepostgresql-8.3.1-2.197.fc10.ppc64 requires /sbin/chkconfig seq24-0.8.7-8.fc8.ppc64 requires /bin/sh ser-0.9.6-14.fc9.ppc64 requires /bin/sh ser-0.9.6-14.fc9.ppc64 requires /bin/bash ser-0.9.6-14.fc9.ppc64 requires /sbin/chkconfig ser-0.9.6-14.fc9.ppc64 requires /bin/sh ser-0.9.6-14.fc9.ppc64 requires /sbin/service ser-mysql-0.9.6-14.fc9.ppc64 requires /bin/sh ser-postgresql-0.9.6-14.fc9.ppc64 requires /bin/sh ser2net-2.4-2.fc9.1.ppc64 requires /bin/sh ser2net-2.4-2.fc9.1.ppc64 requires /bin/sh ser2net-2.4-2.fc9.1.ppc64 requires /sbin/service sergueis-destiny-1.1-4.fc8.noarch requires /bin/sh sergueis-destiny-1.1-4.fc8.noarch requires /bin/bash serpentine-0.9-2.fc9.noarch requires /bin/sh serpentine-0.9-2.fc9.noarch requires /usr/bin/env setools-console-3.3.4-1.fc9.ppc64 requires /bin/sh setools-gui-3.3.4-1.fc9.ppc64 requires /bin/sh setools-libs-3.3.4-1.fc9.ppc64 requires /sbin/ldconfig setools-libs-java-3.3.4-1.fc9.ppc64 requires /sbin/ldconfig setools-libs-tcl-3.3.4-1.fc9.ppc64 requires /sbin/ldconfig setroubleshoot-2.0.6-1.fc9.noarch requires /bin/sh setroubleshoot-2.0.6-1.fc9.noarch requires /usr/bin/update-desktop-database setroubleshoot-plugins-2.0.4-5.fc9.noarch requires /bin/sh setroubleshoot-server-2.0.6-1.fc9.noarch requires /bin/sh setroubleshoot-server-2.0.6-1.fc9.noarch requires /bin/bash setroubleshoot-server-2.0.6-1.fc9.noarch requires /sbin/chkconfig setroubleshoot-server-2.0.6-1.fc9.noarch requires /usr/bin/python setroubleshoot-server-2.0.6-1.fc9.noarch requires /sbin/service sg3_utils-libs-1.25-4.fc9.ppc64 requires /sbin/ldconfig sgml-common-0.6.3-23.fc9.noarch requires /bin/sh shapelib-1.2.10-16.20060304cvs.ppc64 requires /sbin/ldconfig shapelib-1.2.10-16.20060304cvs.ppc64 requires /bin/sh shared-mime-info-0.30-1.fc10.ppc64 requires /bin/sh sharutils-4.6.3-2.fc9.ppc64 requires /bin/sh sharutils-4.6.3-2.fc9.ppc64 requires /bin/bash sharutils-4.6.3-2.fc9.ppc64 requires /usr/bin/perl sharutils-4.6.3-2.fc9.ppc64 requires /sbin/install-info shippy-1.3.3.7-7.fc9.ppc64 requires /bin/sh shippy-common-1.3.3.7-7.fc9.ppc64 requires /bin/bash shorewall-common-4.0.10-2.fc10.noarch requires /bin/sh shorewall-common-4.0.10-2.fc10.noarch requires /sbin/chkconfig shorewall-common-4.0.10-2.fc10.noarch requires /bin/sh shorewall-common-4.0.10-2.fc10.noarch requires /sbin/service shorewall-lite-4.0.10-2.fc10.noarch requires /bin/sh shorewall-lite-4.0.10-2.fc10.noarch requires /sbin/chkconfig shorewall-lite-4.0.10-2.fc10.noarch requires /bin/sh shorewall-lite-4.0.10-2.fc10.noarch requires /sbin/service shorewall-perl-4.0.10-2.fc10.noarch requires /usr/bin/perl shorewall-shell-4.0.10-2.fc10.noarch requires /bin/sh showimg-0.9.5-16.fc9.ppc64 requires /sbin/ldconfig siege-2.67-1.fc10.ppc64 requires /usr/bin/perl siege-2.67-1.fc10.ppc64 requires /bin/sh sigscheme-0.8.3-1.fc10.ppc64 requires /sbin/ldconfig silkscreen-fonts-1.0-1.fc9.noarch requires /bin/sh simcoupe-1.0-4.fc10.ppc64 requires /bin/sh sinjdoc-0.5-6.fc9.ppc64 requires /bin/sh sinjdoc-0.5-6.fc9.ppc64 requires /bin/sh six-0.5.3-9.fc9.ppc64 requires /bin/sh skencil-0.6.17-18.20070606svn.fc9.ppc64 requires /bin/sh skencil-0.6.17-18.20070606svn.fc9.ppc64 requires /usr/bin/env skencil-0.6.17-18.20070606svn.fc9.ppc64 requires /usr/bin/python ski-devel-1.3.2-5.fc10.ppc64 requires /bin/sh ski-libs-1.3.2-5.fc10.ppc64 requires /sbin/ldconfig skstream-0.3.6-3.fc9.ppc64 requires /sbin/ldconfig slang-2.1.3-3.fc9.ppc64 requires /sbin/ldconfig slang-slsh-2.1.3-3.fc9.ppc64 requires /usr/bin/env slib-3b1-1.fc9.noarch requires /bin/sh slib-3b1-1.fc9.noarch requires /sbin/install-info slim-1.3.0-4.fc9.ppc64 requires /sbin/shutdown slim-1.3.0-4.fc9.ppc64 requires /etc/pam.d slim-1.3.0-4.fc9.ppc64 requires /usr/bin/perl slim-1.3.0-4.fc9.ppc64 requires /bin/sh slingshot-0.8.1p-1.fc8.noarch requires /bin/sh slingshot-0.8.1p-1.fc8.noarch requires /bin/bash sloccount-2.26-7.fc9.ppc64 requires /usr/bin/perl sloccount-2.26-7.fc9.ppc64 requires /bin/sh slrn-pull-0.9.8.1pl1-8.20070716cvs.fc9.ppc64 requires /bin/sh smart-0.52-54.fc9.ppc64 requires /usr/bin/python smarteiffel-2.3-2.fc9.ppc64 requires /bin/sh 1:smartmontools-5.38-4.1.fc10.ppc64 requires /bin/sh 1:smartmontools-5.38-4.1.fc10.ppc64 requires /bin/bash 1:smartmontools-5.38-4.1.fc10.ppc64 requires /sbin/chkconfig 1:smartmontools-5.38-4.1.fc10.ppc64 requires /bin/sh 1:smartmontools-5.38-4.1.fc10.ppc64 requires /sbin/service 1:smartmontools-config-5.38-4.1.fc10.ppc64 requires /usr/bin/python smashteroid-1.11-4.fc9.ppc64 requires /bin/sh smb4k-0.9.4-1.fc10.ppc64 requires /bin/sh smbldap-tools-0.9.4-2.fc9.noarch requires /usr/bin/perl smc-fonts-dyuthi-04-6.fc9.noarch requires /bin/sh smc-fonts-meera-04-6.fc9.noarch requires /bin/sh smc-fonts-rachana-04-6.fc9.noarch requires /bin/sh smc-fonts-raghumalayalam-04-6.fc9.noarch requires /bin/sh smc-fonts-suruma-04-6.fc9.noarch requires /bin/sh smolt-1.1.1.1-4.fc9.noarch requires /bin/sh smolt-1.1.1.1-4.fc9.noarch requires /bin/bash smolt-1.1.1.1-4.fc9.noarch requires /sbin/chkconfig smolt-1.1.1.1-4.fc9.noarch requires /usr/sbin/groupadd smolt-1.1.1.1-4.fc9.noarch requires /usr/sbin/useradd smolt-1.1.1.1-4.fc9.noarch requires /usr/bin/python smolt-1.1.1.1-4.fc9.noarch requires /sbin/service smolt-server-1.1.1.1-4.fc9.noarch requires /usr/bin/python smstools-3.0.10-2.fc9.ppc64 requires /bin/sh smstools-3.0.10-2.fc9.ppc64 requires /bin/bash smstools-3.0.10-2.fc9.ppc64 requires /sbin/chkconfig smstools-3.0.10-2.fc9.ppc64 requires /bin/sh smstools-3.0.10-2.fc9.ppc64 requires /sbin/service snake-0.11-0.2.fc9.noarch requires /usr/bin/python snake-server-0.11-0.2.fc9.noarch requires /bin/sh snake-server-0.11-0.2.fc9.noarch requires /bin/sh snake-server-0.11-0.2.fc9.noarch requires /usr/bin/python snort-2.8.1-3.fc10.ppc64 requires /bin/sh snort-2.8.1-3.fc10.ppc64 requires /bin/sh snort-bloat-2.8.1-3.fc10.ppc64 requires /bin/sh snort-mysql-2.8.1-3.fc10.ppc64 requires /bin/sh snort-mysql+flexresp-2.8.1-3.fc10.ppc64 requires /bin/sh snort-plain+flexresp-2.8.1-3.fc10.ppc64 requires /bin/sh snort-postgresql-2.8.1-3.fc10.ppc64 requires /bin/sh snort-postgresql+flexresp-2.8.1-3.fc10.ppc64 requires /bin/sh snort-snmp-2.8.1-3.fc10.ppc64 requires /bin/sh snort-snmp+flexresp-2.8.1-3.fc10.ppc64 requires /bin/sh snownews-1.5.8-2.fc9.ppc64 requires /usr/bin/perl sofia-sip-1.12.8-1.fc9.ppc64 requires /sbin/ldconfig sofia-sip-devel-1.12.8-1.fc9.ppc64 requires /usr/bin/env sofia-sip-glib-1.12.8-1.fc9.ppc64 requires /sbin/ldconfig solarwolf-1.5-2.fc8.noarch requires /bin/sh solarwolf-1.5-2.fc8.noarch requires /usr/bin/env solfege-3.10.4-1.fc10.ppc64 requires /bin/bash solfege-3.10.4-1.fc10.ppc64 requires /bin/sh solfege-3.10.4-1.fc10.ppc64 requires /usr/bin/python sonata-1.5.1-1.fc10.ppc64 requires /usr/bin/python sonic-visualiser-1.2-1.fc9.ppc64 requires /bin/sh sooperlooper-1.6.2-1.fc9.ppc64 requires /bin/sh soprano-2.0.98-1.fc10.ppc64 requires /sbin/ldconfig soprano-apidocs-2.0.98-1.fc10.ppc64 requires /usr/bin/perl sos-1.8-1.fc8.noarch requires /bin/bash sos-1.8-1.fc8.noarch requires /usr/bin/env sound-juicer-2.22.0-3.fc10.ppc64 requires /bin/sh soundconverter-1.2.0-1.fc10.noarch requires /bin/sh soundconverter-1.2.0-1.fc10.noarch requires /usr/bin/python soundtouch-1.3.1-10.fc9.ppc64 requires /sbin/ldconfig source-highlight-2.8-2.fc9.ppc64 requires /bin/sh source-highlight-2.8-2.fc9.ppc64 requires /sbin/install-info source-highlight-2.8-2.fc9.ppc64 requires /bin/sh sox-14.0.1-1.fc9.ppc64 requires /sbin/ldconfig spamass-milter-0.3.1-7.fc9.ppc64 requires /bin/sh spamass-milter-0.3.1-7.fc9.ppc64 requires /sbin/service spamass-milter-0.3.1-7.fc9.ppc64 requires /bin/bash spamass-milter-0.3.1-7.fc9.ppc64 requires /sbin/chkconfig spamassassin-3.2.4-4.fc9.ppc64 requires /sbin/chkconfig spamassassin-3.2.4-4.fc9.ppc64 requires /usr/bin/perl spamassassin-3.2.4-4.fc9.ppc64 requires /bin/sh spamassassin-3.2.4-4.fc9.ppc64 requires /sbin/service spamassassin-3.2.4-4.fc9.ppc64 requires /bin/bash spamassassin-3.2.4-4.fc9.ppc64 requires /bin/sh spambayes-1.0.4-5.fc8.noarch requires /usr/bin/python spampd-2.30-4.noarch requires /bin/sh spampd-2.30-4.noarch requires /usr/bin/perl spampd-2.30-4.noarch requires /sbin/chkconfig spampd-2.30-4.noarch requires /bin/sh spampd-2.30-4.noarch requires /sbin/service spandsp-0.0.4-0.10.pre18.fc9.ppc64 requires /sbin/ldconfig sparse-0.4.1-2.fc9.ppc64 requires /usr/bin/perl specto-0.2.2-1.fc9.noarch requires /bin/sh specto-0.2.2-1.fc9.noarch requires /usr/bin/python speedcrunch-0.9-3.fc9.ppc64 requires /bin/sh speex-1.2-0.9.beta3.ppc64 requires /sbin/ldconfig spr-07.15.00-1.fc9.ppc64 requires /sbin/ldconfig sqlgrey-1.7.5-1.fc7.noarch requires /bin/sh sqlgrey-1.7.5-1.fc7.noarch requires /usr/bin/perl sqlgrey-1.7.5-1.fc7.noarch requires /bin/bash sqlgrey-1.7.5-1.fc7.noarch requires /sbin/chkconfig sqlgrey-1.7.5-1.fc7.noarch requires /bin/sh sqlgrey-1.7.5-1.fc7.noarch requires /sbin/service sqlite-3.5.8-1.fc10.ppc64 requires /sbin/ldconfig sqliteman-1.0.1-4.fc9.ppc64 requires /bin/sh 7:squid-3.0.STABLE5-2.fc10.ppc64 requires /bin/sh 7:squid-3.0.STABLE5-2.fc10.ppc64 requires /sbin/service 7:squid-3.0.STABLE5-2.fc10.ppc64 requires /bin/bash 7:squid-3.0.STABLE5-2.fc10.ppc64 requires /bin/sh 7:squid-3.0.STABLE5-2.fc10.ppc64 requires /usr/bin/perl 7:squid-3.0.STABLE5-2.fc10.ppc64 requires /sbin/chkconfig squidGuard-1.2.0-18.fc9.ppc64 requires /bin/sh squidGuard-1.2.0-18.fc9.ppc64 requires /usr/bin/chcon squidGuard-1.2.0-18.fc9.ppc64 requires /bin/bash squidGuard-1.2.0-18.fc9.ppc64 requires /usr/bin/perl squidGuard-1.2.0-18.fc9.ppc64 requires /sbin/chkconfig squirrelmail-1.4.13-1.fc9.noarch requires /usr/bin/env squirrelmail-1.4.13-1.fc9.noarch requires /bin/sh ss5-3.5.9-7.ppc64 requires /bin/sh ss5-3.5.9-7.ppc64 requires /bin/sh sshfp-1.1.2-1.fc7.noarch requires /usr/bin/python sshmenu-3.15-5.fc9.noarch requires /usr/bin/ruby ssmtp-2.61-11.5.fc9.3.ppc64 requires /bin/sh ssmtp-2.61-11.5.fc9.3.ppc64 requires /usr/sbin/alternatives stardict-3.0.1-8.fc9.ppc64 requires /bin/sh starplot-0.95.4-6.fc9.ppc64 requires /bin/sh starplot-gliese3-0.95-2.fc9.noarch requires /bin/sh starplot-yale5-0.95-2.fc9.noarch requires /bin/sh startup-notification-0.9-4.fc9.ppc64 requires /sbin/ldconfig statgrab-tools-0.16-1.fc9.ppc64 requires /usr/bin/perl statserial-1.1-41.fc9.ppc64 requires /bin/bash stgit-0.14.2-1.fc9.noarch requires /bin/sh stgit-0.14.2-1.fc9.noarch requires /usr/bin/python stix-fonts-0.9-6.fc9.noarch requires /bin/sh stix-fonts-integrals-0.9-6.fc9.noarch requires /bin/sh stix-fonts-pua-0.9-6.fc9.noarch requires /bin/sh stix-fonts-sizes-0.9-6.fc9.noarch requires /bin/sh stix-fonts-variants-0.9-6.fc9.noarch requires /bin/sh stonith-2.1.3-1.fc9.ppc64 requires /usr/bin/python stonith-2.1.3-1.fc9.ppc64 requires /sbin/ldconfig stonith-2.1.3-1.fc9.ppc64 requires /usr/bin/perl stonith-2.1.3-1.fc9.ppc64 requires /bin/sh stormbaancoureur-2.1.4-1.fc10.ppc64 requires /bin/sh stow-1.3.3-6.fc8.noarch requires /usr/bin/perl stow-1.3.3-6.fc8.noarch requires /sbin/install-info stow-1.3.3-6.fc8.noarch requires /bin/sh stratagus-2.2.4-4.fc9.ppc64 requires /usr/bin/env straw-0.27-12.fc9.noarch requires /bin/sh straw-0.27-12.fc9.noarch requires /usr/bin/python streamtuner-0.99.99-17.fc9.ppc64 requires /bin/sh strigi-libs-0.5.9-2.fc10.ppc64 requires /sbin/ldconfig struts-1.2.9-5jpp.9.fc9.ppc64 requires /bin/sh struts-javadoc-1.2.9-5jpp.9.fc9.ppc64 requires /bin/sh struts-javadoc-1.2.9-5jpp.9.fc9.ppc64 requires /bin/rm struts-javadoc-1.2.9-5jpp.9.fc9.ppc64 requires /bin/ln struts-webapps-tomcat5-1.2.9-5jpp.9.fc9.ppc64 requires /bin/sh struts-webapps-tomcat5-1.2.9-5jpp.9.fc9.ppc64 requires /bin/ln struts-webapps-tomcat5-1.2.9-5jpp.9.fc9.ppc64 requires /bin/rm stunnel-4.22-1.ppc64 requires /usr/bin/perl sub2srt-0.5.3-3.fc8.noarch requires /usr/bin/perl subversion-1.4.6-7.ppc64 requires /usr/bin/env subversion-1.4.6-7.ppc64 requires /usr/bin/python subversion-1.4.6-7.ppc64 requires /sbin/ldconfig subversion-1.4.6-7.ppc64 requires /bin/bash subversion-1.4.6-7.ppc64 requires /bin/sh subversion-1.4.6-7.ppc64 requires /usr/bin/perl subversion-javahl-1.4.6-7.ppc64 requires /sbin/ldconfig subversion-perl-1.4.6-7.ppc64 requires /sbin/ldconfig subversion-ruby-1.4.6-7.ppc64 requires /sbin/ldconfig suck-4.3.2-22.fc9.ppc64 requires /bin/sh suck-4.3.2-22.fc9.ppc64 requires /usr/bin/perl sudo-1.6.9p13-6.fc10.ppc64 requires /bin/sh sudo-1.6.9p13-6.fc10.ppc64 requires /etc/pam.d/system-auth sugar-0.79.4-2.fc10.ppc64 requires /bin/sh sugar-0.79.4-2.fc10.ppc64 requires /usr/bin/env sugar-0.79.4-2.fc10.ppc64 requires /bin/sh sugar-artwork-0.79.1-1.fc9.ppc64 requires /bin/sh sugar-datastore-0.6.0-1.fc9.noarch requires /usr/bin/env sugar-journal-79-3.fc9.noarch requires /usr/bin/env sugar-presence-service-0.79.0-1.fc9.noarch requires /usr/bin/env suitesparse-3.1.0-1.fc9.ppc64 requires /sbin/ldconfig sunbird-0.8-3.fc9.ppc64 requires /bin/sh sunbird-0.8-3.fc9.ppc64 requires /bin/sh sunbird-0.8-3.fc9.ppc64 requires libhunspell.so.1()(64bit) sundials-2.3.0-6.fc9.ppc64 requires /sbin/ldconfig sundials-devel-2.3.0-6.fc9.ppc64 requires /bin/sh supertuxkart-0.4-2.fc10.ppc64 requires /bin/sh supervisor-2.1-4.fc9.noarch requires /bin/sh supervisor-2.1-4.fc9.noarch requires /bin/bash supervisor-2.1-4.fc9.noarch requires /sbin/chkconfig supervisor-2.1-4.fc9.noarch requires /usr/bin/python supervisor-2.1-4.fc9.noarch requires /sbin/service surfraw-1.0.7-3.fc8.noarch requires /bin/sh svn2cl-0.10-1.noarch requires /bin/sh svncpp-0.9.6-1.fc9.ppc64 requires /sbin/ldconfig svnkit-1.1.4-3.fc9.ppc64 requires /usr/bin/rebuild-gcj-db svnmailer-1.0.8-3.fc7.noarch requires /usr/bin/python svrcore-4.0.4-2.fc9.ppc64 requires /sbin/ldconfig swaks-20061116.0-1.fc8.noarch requires /usr/bin/perl swatch-3.2.1-2.fc9.noarch requires /usr/bin/perl sweep-0.9.2-2.fc9.ppc64 requires /bin/sh swfdec-0.6.6-1.fc10.ppc64 requires /sbin/ldconfig swfdec-gnome-2.22.0-1.fc9.ppc64 requires /bin/sh swfdec-gtk-0.6.6-1.fc10.ppc64 requires /bin/sh swfdec-gtk-0.6.6-1.fc10.ppc64 requires /sbin/ldconfig swfdec-mozilla-0.6.0-1.fc9.ppc64 requires /usr/lib64/mozilla/plugins swig-1.3.35-2.fc10.ppc64 requires /sbin/ldconfig swing-layout-1.0.3-2.fc9.ppc64 requires /bin/sh switchdesk-4.0.9-2.noarch requires /bin/bash switchdesk-gui-4.0.9-2.noarch requires /usr/bin/env sword-1.5.10-3.fc9.ppc64 requires /sbin/ldconfig syck-0.61-4.3.fc9.ppc64 requires /sbin/ldconfig synaptic-0.57.2-16.fc9.ppc64 requires /bin/sh synce-gnome-0.11-2.fc9.noarch requires /usr/bin/env synce-kde-0.9.1-3.fc9.ppc64 requires /bin/sh synce-kde-0.9.1-3.fc9.ppc64 requires /bin/sh synce-kpm-0.11-3.fc9.noarch requires /usr/bin/python synce-serial-0.11-2.fc9.ppc64 requires /bin/sh synce-sync-engine-0.11-6.fc9.noarch requires /usr/bin/python syncevolution-0.7-2.fc10.ppc64 requires /usr/bin/env sysconftool-0.15-3.fc6.noarch requires /usr/bin/perl syslog-ng-2.0.8-1.fc9.ppc64 requires /bin/sh syslog-ng-2.0.8-1.fc9.ppc64 requires /bin/sh sysreport-1.4.4-1.noarch requires /bin/bash sysreport-1.4.4-1.noarch requires /usr/bin/tr sysstat-8.0.4-4.fc10.ppc64 requires /bin/cp sysstat-8.0.4-4.fc10.ppc64 requires /bin/sh sysstat-8.0.4-4.fc10.ppc64 requires /usr/bin/id sysstat-8.0.4-4.fc10.ppc64 requires /etc/cron.d sysstat-8.0.4-4.fc10.ppc64 requires /bin/chmod sysstat-8.0.4-4.fc10.ppc64 requires /bin/mkdir sysstat-8.0.4-4.fc10.ppc64 requires /usr/bin/install sysstat-8.0.4-4.fc10.ppc64 requires /sbin/chkconfig sysstat-8.0.4-4.fc10.ppc64 requires /bin/sh sysstat-8.0.4-4.fc10.ppc64 requires /bin/mv sysstat-8.0.4-4.fc10.ppc64 requires /bin/grep system-config-audit-0.4.6-7.fc10.ppc64 requires /bin/sh system-config-bind-4.0.6-1.fc9.noarch requires /bin/sh system-config-bind-4.0.6-1.fc9.noarch requires /usr/bin/python system-config-cluster-1.0.53-1.0.noarch requires /usr/bin/python2 system-config-cluster-1.0.53-1.0.noarch requires /sbin/chkconfig system-config-date-1.9.31-1.fc10.noarch requires /bin/sh system-config-date-1.9.31-1.fc10.noarch requires /bin/sh system-config-date-1.9.31-1.fc10.noarch requires /usr/bin/python system-config-display-1.0.51-9.fc9.noarch requires /bin/sh system-config-display-1.0.51-9.fc9.noarch requires /usr/bin/Xorg system-config-display-1.0.51-9.fc9.noarch requires /bin/sh system-config-display-1.0.51-9.fc9.noarch requires /usr/bin/python2 system-config-firewall-1.2.7-1.fc9.noarch requires /bin/sh system-config-firewall-1.2.7-1.fc9.noarch requires /bin/sh system-config-firewall-1.2.7-1.fc9.noarch requires /usr/bin/python system-config-firewall-tui-1.2.7-1.fc9.noarch requires /usr/bin/python 5:system-config-httpd-1.4.4-1.fc8.noarch requires /bin/sh 5:system-config-httpd-1.4.4-1.fc8.noarch requires /bin/sh system-config-kdump-1.0.13-2.fc9.noarch requires /bin/sh system-config-kdump-1.0.13-2.fc9.noarch requires /bin/sh system-config-keyboard-1.2.15-2.fc9.noarch requires /bin/sh system-config-keyboard-1.2.15-2.fc9.noarch requires /bin/sh system-config-kickstart-2.7.16-1.fc9.noarch requires /bin/sh system-config-kickstart-2.7.16-1.fc9.noarch requires /usr/bin/python2 system-config-language-1.2.15-3.fc10.noarch requires /bin/sh system-config-language-1.2.15-3.fc10.noarch requires /bin/sh system-config-lvm-1.1.4-1.0.fc9.noarch requires /sbin/chkconfig system-config-lvm-1.1.4-1.0.fc9.noarch requires /usr/bin/python2 system-config-netboot-0.1.45.2-1.fc10.noarch requires /bin/sh system-config-netboot-0.1.45.2-1.fc10.noarch requires /usr/bin/python system-config-netboot-cmd-0.1.45.2-1.fc10.noarch requires /bin/sh system-config-netboot-cmd-0.1.45.2-1.fc10.noarch requires /bin/bash system-config-netboot-cmd-0.1.45.2-1.fc10.noarch requires /usr/bin/python system-config-network-1.5.7-1.fc9.noarch requires /usr/bin/python system-config-network-tui-1.5.7-1.fc9.noarch requires /bin/sh system-config-network-tui-1.5.7-1.fc9.noarch requires /usr/bin/python system-config-nfs-1.3.40-1.fc9.noarch requires /bin/sh system-config-nfs-1.3.40-1.fc9.noarch requires /usr/bin/python system-config-printer-0.9.91-1.fc10.ppc64 requires /bin/sh system-config-printer-0.9.91-1.fc10.ppc64 requires /usr/bin/env system-config-printer-0.9.91-1.fc10.ppc64 requires /bin/sh system-config-printer-0.9.91-1.fc10.ppc64 requires /usr/bin/python system-config-printer-libs-0.9.91-1.fc10.ppc64 requires /usr/bin/python system-config-printer-libs-0.9.91-1.fc10.ppc64 requires /usr/bin/env system-config-rootpassword-1.99.4-1.fc9.noarch requires /bin/sh system-config-rootpassword-1.99.4-1.fc9.noarch requires /bin/sh system-config-samba-1.2.63-1.fc9.noarch requires /bin/sh system-config-samba-1.2.63-1.fc9.noarch requires /usr/bin/python system-config-services-0.99.15-1.fc9.noarch requires /bin/sh system-config-services-0.99.15-1.fc9.noarch requires /usr/bin/python system-config-users-1.2.80-1.fc10.noarch requires /bin/sh system-config-users-1.2.80-1.fc10.noarch requires /usr/bin/pgrep system-config-users-1.2.80-1.fc10.noarch requires /bin/sh system-config-users-1.2.80-1.fc10.noarch requires /usr/bin/python system-config-vsftpd-0.5.1-1.fc10.noarch requires /usr/bin/env system-config-vsftpd-0.5.1-1.fc10.noarch requires /bin/sh system-summary-0.0.3-2.fc9.noarch requires /usr/bin/python system-switch-java-1.1.2-1.fc8.noarch requires /usr/bin/env system-switch-mail-0.5.26-2.noarch requires /usr/bin/python systemtap-0.6.2-1.fc9.ppc64 requires /bin/bash systemtap-0.6.2-1.fc9.ppc64 requires /usr/bin/stap systemtap-runtime-0.6.2-1.fc9.ppc64 requires /bin/sh systemtap-testsuite-0.6.2-1.fc9.ppc64 requires /usr/bin/perl systemtap-testsuite-0.6.2-1.fc9.ppc64 requires /bin/bash systemtap-testsuite-0.6.2-1.fc9.ppc64 requires /usr/bin/tclsh systemtap-testsuite-0.6.2-1.fc9.ppc64 requires /usr/bin/stap systemtap-testsuite-0.6.2-1.fc9.ppc64 requires /usr/bin/env systemtap-testsuite-0.6.2-1.fc9.ppc64 requires /bin/sh sysusage-2.6-3.fc9.noarch requires /usr/bin/perl sysvinit-tools-2.86-24.ppc64 requires /bin/sh t1lib-5.1.2-2.fc9.ppc64 requires /bin/sh t1lib-5.1.2-2.fc9.ppc64 requires /sbin/ldconfig t1lib-5.1.2-2.fc9.ppc64 requires /bin/sh taglib-1.5-1.fc9.ppc64 requires /sbin/ldconfig taglib-devel-1.5-1.fc9.ppc64 requires /bin/sh tagsoup-1.0.1-2jpp.1.fc9.ppc64 requires /bin/sh tagtool-0.12.3-4.fc9.ppc64 requires /bin/sh tailor-0.9.30-1.fc9.noarch requires /usr/bin/python taipeifonts-1.2-5.fc9.noarch requires /bin/sh tango-icon-theme-0.8.1-1.fc8.noarch requires /bin/sh tango-icon-theme-extras-0.1.0-1.fc7.noarch requires /bin/sh tanukiwrapper-3.2.3-2jpp.1.fc9.ppc64 requires /bin/sh tanukiwrapper-javadoc-3.2.3-2jpp.1.fc9.ppc64 requires /bin/sh tanukiwrapper-javadoc-3.2.3-2jpp.1.fc9.ppc64 requires /bin/rm tanukiwrapper-javadoc-3.2.3-2jpp.1.fc9.ppc64 requires /bin/ln 2:tar-1.19-3.fc9.ppc64 requires /bin/sh 2:tar-1.19-3.fc9.ppc64 requires /sbin/install-info taskcoach-0.69.1-2.fc9.noarch requires /bin/sh taskcoach-0.69.1-2.fc9.noarch requires /usr/bin/env taskcoach-0.69.1-2.fc9.noarch requires /usr/bin/python taskjuggler-2.4.1-1.fc10.ppc64 requires /bin/sh tasks-0.12-2.fc10.ppc64 requires /bin/sh taxipilot-0.9.2-6.fc9.ppc64 requires /bin/sh tcd-utils-20061127-1.fc9.3.ppc64 requires /bin/sh 1:tcl-8.5.1-4.fc10.ppc64 requires /sbin/ldconfig tclabc-1.1.0-1.fc9.ppc64 requires /bin/sh tcldebugger-1.4-6.20061030cvs.fc9.noarch requires /bin/sh tclhttpd-3.5.1-19.fc9.ppc64 requires /bin/sh tclhttpd-3.5.1-19.fc9.ppc64 requires /sbin/chkconfig tclhttpd-3.5.1-19.fc9.ppc64 requires /bin/sh tclhttpd-3.5.1-19.fc9.ppc64 requires /sbin/service tcllib-1.10-2.fc9.noarch requires /bin/sh tclpro-1.5.0-11.20061030cvs.fc9.noarch requires /bin/sh tclx-8.4.0-10.fc9.ppc64 requires /sbin/ldconfig tcp_wrappers-libs-7.6-52.fc9.ppc64 requires /sbin/ldconfig 14:tcpdump-3.9.8-4.fc9.ppc64 requires /bin/sh tcpreplay-3.3.0-1.fc10.ppc64 requires /usr/sbin/tcpdump tcsh-6.15-4.fc9.ppc64 requires /bin/sh teckit-2.2.1-3.fc9.ppc64 requires /sbin/ldconfig teckit-devel-2.2.1-3.fc9.ppc64 requires /sbin/ldconfig tecnoballz-0.92-4.fc9.ppc64 requires /bin/sh teg-0.11.2-15.fc9.ppc64 requires /bin/sh telepathy-butterfly-0.3.1-1.fc9.noarch requires /usr/bin/python telepathy-glib-0.7.8-1.fc10.ppc64 requires /sbin/ldconfig telepathy-mission-control-4.64-1.fc9.ppc64 requires /sbin/ldconfig tellico-1.3.1-1.fc9.ppc64 requires /bin/sh tellico-1.3.1-1.fc9.ppc64 requires /usr/bin/env tempest-xscreensaver-0-0.6.20070929.fc9.ppc64 requires /bin/sh terminus-font-x11-4.20-8.fc8.noarch requires /bin/sh terminus-font-x11-4.20-8.fc8.noarch requires /usr/bin/fc-cache terminus-font-x11-4.20-8.fc8.noarch requires /usr/bin/mkfontdir testoob-1.13-4.fc9.noarch requires /usr/bin/env testoob-1.13-4.fc9.noarch requires /usr/bin/python tetex-IEEEtran-1.7.1-1.fc8.noarch requires /usr/bin/texhash tetex-IEEEtran-1.7.1-1.fc8.noarch requires /bin/sh tetex-IEEEtran-1.7.1-1.fc8.noarch requires /bin/sh tetex-bytefield-1.2a-3.fc6.noarch requires /bin/sh tetex-bytefield-1.2a-3.fc6.noarch requires /usr/bin/texhash tetex-dvipost-1.1-9.fc9.ppc64 requires /usr/bin/texhash tetex-elsevier-0.1.20071024-1.fc9.noarch requires /usr/bin/texhash tetex-eurofont-1.1.3-6.fc6.noarch requires /bin/sh tetex-font-cm-lgc-0.5-9.fc9.noarch requires /bin/sh tetex-font-kerkis-2.0-15.fc9.noarch requires /bin/sh tetex-fonts-hebrew-0.1-8.fc9.noarch requires /usr/bin/texhash tetex-fonts-hebrew-0.1-8.fc9.noarch requires /usr/bin/updmap-sys tetex-fonts-hebrew-0.1-8.fc9.noarch requires /bin/sh tetex-perltex-1.3-1.fc6.noarch requires /usr/bin/texhash tetex-perltex-1.3-1.fc6.noarch requires /usr/bin/perl tetex-perltex-1.3-1.fc6.noarch requires /bin/sh tetex-prosper-1.5-3.fc6.noarch requires /usr/bin/texhash tetex-prosper-1.5-3.fc6.noarch requires /bin/sh tetex-tex4ht-1.0.2008_02_28_2058-3.fc9.ppc64 requires /usr/bin/texhash tetex-tex4ht-1.0.2008_02_28_2058-3.fc9.ppc64 requires /usr/bin/perl tetex-tex4ht-1.0.2008_02_28_2058-3.fc9.ppc64 requires /usr/bin/dvipng tetex-tex4ht-1.0.2008_02_28_2058-3.fc9.ppc64 requires /bin/sh tetex-tex4ht-1.0.2008_02_28_2058-3.fc9.ppc64 requires /bin/sh tetex-unicode-0-7.20041017.fc6.noarch requires /bin/sh tetrinetx-1.13.16-4.fc9.ppc64 requires /bin/sh tetrinetx-1.13.16-4.fc9.ppc64 requires /sbin/chkconfig tetrinetx-1.13.16-4.fc9.ppc64 requires /usr/sbin/useradd tetrinetx-1.13.16-4.fc9.ppc64 requires /bin/sh tex-preview-11.85-7.fc9.noarch requires /bin/sh texi2html-1.78-3.fc8.noarch requires /bin/sh texi2html-1.78-3.fc8.noarch requires /usr/bin/perl texi2html-1.78-3.fc8.noarch requires /sbin/install-info texinfo-4.12-1.fc10.ppc64 requires /bin/sh texinfo-4.12-1.fc10.ppc64 requires /sbin/install-info texinfo-tex-4.12-1.fc10.ppc64 requires /bin/sh texinfo-tex-4.12-1.fc10.ppc64 requires /bin/sh texinfo-tex-4.12-1.fc10.ppc64 requires /usr/bin/texconfig-sys texlive-2007-31.fc10.ppc64 requires /bin/sh texlive-2007-31.fc10.ppc64 requires /usr/bin/fmtutil texlive-2007-31.fc10.ppc64 requires /bin/bash texlive-2007-31.fc10.ppc64 requires /bin/sh texlive-2007-31.fc10.ppc64 requires /sbin/restorecon texlive-afm-2007-31.fc10.ppc64 requires /bin/sh texlive-afm-2007-31.fc10.ppc64 requires /sbin/restorecon texlive-context-2007-31.fc10.ppc64 requires /bin/sh texlive-context-2007-31.fc10.ppc64 requires /sbin/restorecon texlive-context-2007-31.fc10.ppc64 requires /usr/bin/env texlive-context-2007-31.fc10.ppc64 requires /bin/sh texlive-doc-2007-31.fc10.ppc64 requires /usr/bin/env texlive-doc-2007-31.fc10.ppc64 requires /bin/sh texlive-dvips-2007-31.fc10.ppc64 requires /bin/sh texlive-dvips-2007-31.fc10.ppc64 requires /sbin/restorecon texlive-dvips-2007-31.fc10.ppc64 requires /bin/sh texlive-dviutils-2007-31.fc10.ppc64 requires /bin/sh texlive-dviutils-2007-31.fc10.ppc64 requires /sbin/restorecon texlive-dviutils-2007-31.fc10.ppc64 requires /bin/sh texlive-east-asian-2007-31.fc10.ppc64 requires /bin/sh texlive-east-asian-2007-31.fc10.ppc64 requires /sbin/restorecon texlive-east-asian-2007-31.fc10.ppc64 requires /bin/sh texlive-latex-2007-31.fc10.ppc64 requires /usr/bin/fmtutil-sys texlive-latex-2007-31.fc10.ppc64 requires /bin/sh texlive-latex-2007-31.fc10.ppc64 requires /usr/bin/fmtutil texlive-latex-2007-31.fc10.ppc64 requires /sbin/restorecon texlive-latex-2007-31.fc10.ppc64 requires /sbin/install-info texlive-latex-2007-31.fc10.ppc64 requires /bin/sh texlive-latex-2007-31.fc10.ppc64 requires /usr/bin/texconfig-sys texlive-texmf-2007-21.fc10.noarch requires /bin/sh texlive-texmf-2007-21.fc10.noarch requires /sbin/restorecon texlive-texmf-2007-21.fc10.noarch requires /bin/sh texlive-texmf-afm-2007-21.fc10.noarch requires /bin/sh texlive-texmf-afm-2007-21.fc10.noarch requires /sbin/restorecon texlive-texmf-context-2007-21.fc10.noarch requires /bin/sh texlive-texmf-context-2007-21.fc10.noarch requires /sbin/restorecon texlive-texmf-context-2007-21.fc10.noarch requires /usr/bin/env texlive-texmf-context-2007-21.fc10.noarch requires /bin/sh texlive-texmf-doc-2007-21.fc10.noarch requires /bin/sh texlive-texmf-doc-2007-21.fc10.noarch requires /sbin/restorecon texlive-texmf-doc-2007-21.fc10.noarch requires /usr/bin/perl texlive-texmf-doc-2007-21.fc10.noarch requires /usr/bin/env texlive-texmf-doc-2007-21.fc10.noarch requires /bin/sh texlive-texmf-dvips-2007-21.fc10.noarch requires /bin/sh texlive-texmf-dvips-2007-21.fc10.noarch requires /sbin/restorecon texlive-texmf-east-asian-2007-21.fc10.noarch requires /bin/sh texlive-texmf-east-asian-2007-21.fc10.noarch requires /sbin/restorecon texlive-texmf-fonts-2007-21.fc10.noarch requires /bin/sh texlive-texmf-fonts-2007-21.fc10.noarch requires /sbin/restorecon texlive-texmf-latex-2007-21.fc10.noarch requires /bin/sh texlive-texmf-latex-2007-21.fc10.noarch requires /sbin/restorecon texlive-texmf-xetex-2007-21.fc10.noarch requires /bin/sh texlive-texmf-xetex-2007-21.fc10.noarch requires /sbin/restorecon texlive-texmf-xetex-2007-21.fc10.noarch requires /usr/bin/perl texlive-utils-2007-31.fc10.ppc64 requires /usr/bin/perl texlive-utils-2007-31.fc10.ppc64 requires /bin/sh texlive-utils-2007-31.fc10.ppc64 requires /usr/bin/env texlive-xetex-2007-31.fc10.ppc64 requires /bin/sh texlive-xetex-2007-31.fc10.ppc64 requires /sbin/restorecon 1:texmaker-1.7-1.fc10.ppc64 requires /bin/sh textflow-0.2.3.1-1.fc10.noarch requires /usr/bin/python tftp-server-0.48-3.fc9.ppc64 requires /bin/sh tftp-server-0.48-3.fc9.ppc64 requires /sbin/service tgif-4.1.45-6.fc9.ppc64 requires /bin/sh tgif-4.1.45-6.fc9.ppc64 requires /bin/bash thaifonts-scalable-0.4.9-3.fc9.noarch requires /bin/sh thinkfinger-0.3-8.fc9.ppc64 requires /sbin/ldconfig thttpd-2.25b-16.fc9.ppc64 requires /bin/sh thttpd-2.25b-16.fc9.ppc64 requires /bin/bash thttpd-2.25b-16.fc9.ppc64 requires /sbin/chkconfig thttpd-2.25b-16.fc9.ppc64 requires /usr/sbin/groupadd thttpd-2.25b-16.fc9.ppc64 requires /usr/sbin/useradd thttpd-2.25b-16.fc9.ppc64 requires /bin/sh thttpd-2.25b-16.fc9.ppc64 requires /sbin/service thunar-archive-plugin-0.2.4-4.fc9.ppc64 requires /bin/sh thunar-archive-plugin-0.2.4-4.fc9.ppc64 requires /bin/sh thunar-shares-0.10-1.fc8.ppc64 requires /bin/sh thunar-volman-0.2.0-2.fc9.ppc64 requires /bin/sh thunar-volman-0.2.0-2.fc9.ppc64 requires /bin/sh thunderbird-2.0.0.14-1.fc10.ppc64 requires /bin/sh thunderbird-2.0.0.14-1.fc10.ppc64 requires /bin/bash thunderbird-2.0.0.14-1.fc10.ppc64 requires /bin/sh thunderbird-lightning-0.8-3.fc9.ppc64 requires /bin/sh thunderbird-lightning-0.8-3.fc9.ppc64 requires /bin/sh thunderbird-lightning-0.8-3.fc9.ppc64 requires libhunspell.so.1()(64bit) tibetan-machine-uni-fonts-1.901-1.fc9.noarch requires /bin/sh tiger-3.2.1-8.fc9.ppc64 requires /usr/bin/perl tiger-3.2.1-8.fc9.ppc64 requires /bin/sh time-1.7-33.fc9.ppc64 requires /bin/sh time-1.7-33.fc9.ppc64 requires /sbin/install-info timidity++-2.13.2-16.fc10.ppc64 requires /bin/sh tin-1.8.3-4.fc9.ppc64 requires /usr/bin/perl tin-1.8.3-4.fc9.ppc64 requires /bin/sh tinyca2-0.7.5-3.fc7.noarch requires /usr/bin/perl tinyerp-4.2.2-1.fc9.noarch requires /bin/sh tinyerp-server-4.2.2-1.fc9.noarch requires /bin/sh tinyerp-server-4.2.2-1.fc9.noarch requires /usr/bin/python tinyerp-server-4.2.2-1.fc9.noarch requires /sbin/service tinyerp-server-4.2.2-1.fc9.noarch requires /bin/bash tinyerp-server-4.2.2-1.fc9.noarch requires /bin/sh tinyerp-server-4.2.2-1.fc9.noarch requires /sbin/chkconfig tinyproxy-1.6.3-2.fc10.ppc64 requires /bin/sh tinyproxy-1.6.3-2.fc10.ppc64 requires /bin/sh tinyxml-2.5.3-3.fc9.ppc64 requires /sbin/ldconfig tiobench-0.3.3-7.1.ppc64 requires /usr/bin/perl tiresias-fonts-1.0-2.fc9.noarch requires /bin/sh 1:tix-8.4.2-5.fc9.ppc64 requires /etc/ld.so.conf.d 1:tix-8.4.2-5.fc9.ppc64 requires /sbin/ldconfig 1:tk-8.5.1-4.fc10.ppc64 requires /bin/sh 1:tk-8.5.1-4.fc10.ppc64 requires /sbin/ldconfig 1:tk-8.5.1-4.fc10.ppc64 requires /bin/sh tkcon-2.4-6.fc8.noarch requires /bin/sh tkcvs-8.1-1.fc9.noarch requires /bin/sh tkimg-1.3-0.10.20080505svn.fc10.ppc64 requires /sbin/ldconfig tklib-0.4.1-7.fc9.noarch requires /bin/sh tla-1.3.5-5.fc9.ppc64 requires /bin/sh tmda-1.1.12-1.fc8.noarch requires /usr/bin/python tmda-ofmipd-1.1.12-1.fc8.noarch requires /bin/sh tmda-ofmipd-1.1.12-1.fc8.noarch requires /bin/bash tmda-ofmipd-1.1.12-1.fc8.noarch requires /sbin/chkconfig tmda-ofmipd-1.1.12-1.fc8.noarch requires /usr/bin/python tmpwatch-2.9.13-2.ppc64 requires /bin/sh tn5250-0.17.3-19.fc9.ppc64 requires /bin/sh tn5250-0.17.3-19.fc9.ppc64 requires /sbin/ldconfig tn5250-0.17.3-19.fc9.ppc64 requires /usr/bin/tic tn5250-0.17.3-19.fc9.ppc64 requires /bin/sh tn5250-devel-0.17.3-19.fc9.ppc64 requires /bin/sh 2:tog-pegasus-2.7.0-7.fc10.ppc64 requires /sbin/ldconfig 2:tog-pegasus-2.7.0-7.fc10.ppc64 requires /bin/sh 2:tog-pegasus-2.7.0-7.fc10.ppc64 requires /bin/bash 2:tog-pegasus-devel-2.7.0-7.fc10.ppc64 requires /bin/sh tokyocabinet-1.2.5-1.fc10.ppc64 requires /sbin/ldconfig tolua++-1.0.92-7.fc9.ppc64 requires /sbin/ldconfig tomcat-native-1.1.13-1.fc9.ppc64 requires /sbin/ldconfig tomcat5-5.5.26-1jpp.2.fc9.ppc64 requires /bin/sh tomcat5-5.5.26-1jpp.2.fc9.ppc64 requires /usr/sbin/groupadd tomcat5-5.5.26-1jpp.2.fc9.ppc64 requires /usr/sbin/useradd tomcat5-5.5.26-1jpp.2.fc9.ppc64 requires /sbin/chkconfig tomcat5-5.5.26-1jpp.2.fc9.ppc64 requires /bin/bash tomcat5-5.5.26-1jpp.2.fc9.ppc64 requires /bin/sh tomcat5-5.5.26-1jpp.2.fc9.ppc64 requires /bin/rm tomcat5-admin-webapps-5.5.26-1jpp.2.fc9.ppc64 requires /bin/sh tomcat5-admin-webapps-5.5.26-1jpp.2.fc9.ppc64 requires /bin/rm tomcat5-common-lib-5.5.26-1jpp.2.fc9.ppc64 requires /bin/sh tomcat5-common-lib-5.5.26-1jpp.2.fc9.ppc64 requires /bin/rm tomcat5-jasper-5.5.26-1jpp.2.fc9.ppc64 requires /bin/sh tomcat5-jasper-eclipse-5.5.26-1jpp.2.fc9.ppc64 requires /bin/sh tomcat5-jsp-2.0-api-5.5.26-1jpp.2.fc9.ppc64 requires /bin/sh tomcat5-jsp-2.0-api-5.5.26-1jpp.2.fc9.ppc64 requires /sbin/chkconfig tomcat5-jsp-2.0-api-5.5.26-1jpp.2.fc9.ppc64 requires /usr/sbin/update-alternatives tomcat5-jsp-2.0-api-javadoc-5.5.26-1jpp.2.fc9.ppc64 requires /bin/sh tomcat5-jsp-2.0-api-javadoc-5.5.26-1jpp.2.fc9.ppc64 requires /bin/rm tomcat5-jsp-2.0-api-javadoc-5.5.26-1jpp.2.fc9.ppc64 requires /bin/ln tomcat5-server-lib-5.5.26-1jpp.2.fc9.ppc64 requires /bin/sh tomcat5-server-lib-5.5.26-1jpp.2.fc9.ppc64 requires /bin/rm tomcat5-servlet-2.4-api-5.5.26-1jpp.2.fc9.ppc64 requires /bin/sh tomcat5-servlet-2.4-api-5.5.26-1jpp.2.fc9.ppc64 requires /sbin/chkconfig tomcat5-servlet-2.4-api-5.5.26-1jpp.2.fc9.ppc64 requires /usr/sbin/update-alternatives tomcat5-servlet-2.4-api-javadoc-5.5.26-1jpp.2.fc9.ppc64 requires /bin/sh tomcat5-servlet-2.4-api-javadoc-5.5.26-1jpp.2.fc9.ppc64 requires /bin/rm tomcat5-servlet-2.4-api-javadoc-5.5.26-1jpp.2.fc9.ppc64 requires /bin/ln tomcat5-webapps-5.5.26-1jpp.2.fc9.ppc64 requires /bin/sh tomcat5-webapps-5.5.26-1jpp.2.fc9.ppc64 requires /bin/rm tomcat6-6.0.16-1jpp.7.fc9.noarch requires /bin/sh tomcat6-6.0.16-1jpp.7.fc9.noarch requires /sbin/chkconfig tomcat6-6.0.16-1jpp.7.fc9.noarch requires /sbin/service tomcat6-jsp-2.1-api-6.0.16-1jpp.7.fc9.noarch requires /bin/sh tomcat6-lib-6.0.16-1jpp.7.fc9.noarch requires /bin/sh tomcat6-servlet-2.5-api-6.0.16-1jpp.7.fc9.noarch requires /bin/sh tomcat6-webapps-6.0.16-1jpp.7.fc9.noarch requires /bin/sh tomoe-0.6.0-5.fc9.ppc64 requires /sbin/ldconfig tong-1.0-10.fc9.ppc64 requires /bin/sh toped-0.8.6-2.fc9.ppc64 requires /bin/sh tor-core-0.1.2.19-1.fc9.ppc64 requires /bin/sh tor-core-0.1.2.19-1.fc9.ppc64 requires /etc/logrotate.d tor-lsb-0.1.2.19-1.fc9.ppc64 requires /bin/sh tor-lsb-0.1.2.19-1.fc9.ppc64 requires /bin/sh torcs-1.3.0-6.fc9.ppc64 requires libplibsg.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibul.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibsm.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibssgaux.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires /bin/bash torcs-1.3.0-6.fc9.ppc64 requires libplibssg.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibsl.so.1.8.4()(64bit) torque-2.1.10-5.fc9.ppc64 requires /bin/sh torque-2.1.10-5.fc9.ppc64 requires /bin/sh torque-client-2.1.10-5.fc9.ppc64 requires /bin/sh torque-gui-2.1.10-5.fc9.ppc64 requires /usr/bin/pbs_wish torque-gui-2.1.10-5.fc9.ppc64 requires /usr/bin/wish8.5 torque-mom-2.1.10-5.fc9.ppc64 requires /bin/sh torque-mom-2.1.10-5.fc9.ppc64 requires /bin/sh torque-scheduler-2.1.10-5.fc9.ppc64 requires /bin/sh torque-scheduler-2.1.10-5.fc9.ppc64 requires /bin/sh torque-server-2.1.10-5.fc9.ppc64 requires /bin/sh torque-server-2.1.10-5.fc9.ppc64 requires /bin/sh totem-2.23.2-2.fc9.ppc64 requires /bin/sh totem-2.23.2-2.fc9.ppc64 requires /usr/bin/python totem-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) totem-2.23.2-2.fc9.ppc64 requires /bin/sh totem-gstreamer-2.23.2-2.fc9.ppc64 requires /bin/sh totem-mozplugin-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.ppc64 requires libtotem-plparser-mini.so.10()(64bit) totem-mythtv-2.23.2-2.fc9.ppc64 requires /bin/sh totem-nautilus-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) totem-pl-parser-2.23.1-2.fc10.ppc64 requires /sbin/ldconfig totem-xine-2.23.2-2.fc9.ppc64 requires /bin/sh tpm-tools-1.3.1-5.fc9.ppc64 requires /sbin/ldconfig trac-0.10.4-2.fc9.noarch requires /usr/bin/python trackballs-1.1.4-6.fc9.ppc64 requires /bin/sh tracker-0.6.6-2.fc9.ppc64 requires /sbin/ldconfig tracker-0.6.6-2.fc9.ppc64 requires /bin/sh tracker-search-tool-0.6.6-2.fc9.ppc64 requires /bin/sh 1:transfig-3.2.5-2.fc9.ppc64 requires /bin/csh 1:transfig-3.2.5-2.fc9.ppc64 requires /bin/sh translate-toolkit-1.0.1-1.fc9.noarch requires /bin/bash translate-toolkit-1.0.1-1.fc9.noarch requires /usr/bin/python transmission-1.20-1.fc10.ppc64 requires /bin/sh tre-0.7.5-5.fc9.ppc64 requires /sbin/ldconfig treecc-0.3.8-5.fc9.ppc64 requires /bin/sh tremulous-1.1.0-6.fc9.ppc64 requires /bin/sh tripwire-2.4.1.2-5.fc9.ppc64 requires /bin/sh tripwire-2.4.1.2-5.fc9.ppc64 requires /bin/sh trousers-0.3.1-5.fc9.ppc64 requires /bin/sh trousers-0.3.1-5.fc9.ppc64 requires /sbin/service trousers-0.3.1-5.fc9.ppc64 requires /sbin/chkconfig trousers-0.3.1-5.fc9.ppc64 requires /sbin/ldconfig trousers-0.3.1-5.fc9.ppc64 requires /bin/bash ttywatch-0.14-11.fc9.ppc64 requires /bin/sh ttywatch-0.14-11.fc9.ppc64 requires /sbin/chkconfig ttywatch-0.14-11.fc9.ppc64 requires /bin/sh ttywatch-0.14-11.fc9.ppc64 requires /sbin/service turba-2.1.7-1.fc9.noarch requires /usr/bin/perl turba-2.1.7-1.fc9.noarch requires /usr/bin/php turba-2.1.7-1.fc9.noarch requires /bin/sh 1:tuxpaint-0.9.17-3.fc9.ppc64 requires /usr/share/icons/hicolor/scalable 1:tuxpaint-0.9.17-3.fc9.ppc64 requires /bin/sh tuxpuck-0.8.2-6.fc10.ppc64 requires /bin/sh tvtime-1.0.2-2.fc9.ppc64 requires /bin/sh twitux-0.62-1.fc10.ppc64 requires /bin/sh ucarp-1.4-1.fc9.ppc64 requires /bin/sh ucarp-1.4-1.fc9.ppc64 requires /bin/bash ucarp-1.4-1.fc9.ppc64 requires /sbin/chkconfig ucarp-1.4-1.fc9.ppc64 requires /bin/sh ucarp-1.4-1.fc9.ppc64 requires /sbin/service ucblogo-5.5-10.fc9.ppc64 requires /bin/sh ucblogo-5.5-10.fc9.ppc64 requires /sbin/install-info ucl-1.03-8.fc9.ppc64 requires /sbin/ldconfig udev-121-1.20080516git.fc10.ppc64 requires /bin/sh udev-121-1.20080516git.fc10.ppc64 requires /sbin/service udev-121-1.20080516git.fc10.ppc64 requires /bin/bash udev-121-1.20080516git.fc10.ppc64 requires /bin/sh udev-121-1.20080516git.fc10.ppc64 requires /sbin/chkconfig udev-packagekit-0.2.1-2.20080508.fc10.ppc64 requires /bin/sh ufraw-0.13-4.fc9.ppc64 requires /bin/sh ufraw-common-0.13-4.fc9.ppc64 requires /bin/sh uim-1.4.2-3.fc10.ppc64 requires /bin/sh uim-1.4.2-3.fc10.ppc64 requires /sbin/ldconfig uim-1.4.2-3.fc10.ppc64 requires /usr/sbin/alternatives uim-anthy-1.4.2-3.fc10.ppc64 requires /bin/sh uim-anthy-1.4.2-3.fc10.ppc64 requires /usr/bin/uim-module-manager uim-canna-1.4.2-3.fc10.ppc64 requires /bin/sh uim-canna-1.4.2-3.fc10.ppc64 requires /usr/bin/uim-module-manager uim-gnome-1.4.2-3.fc10.ppc64 requires /bin/sh uim-gnome-1.4.2-3.fc10.ppc64 requires /usr/sbin/bonobo-activation-sysconf uim-gtk2-1.4.2-3.fc10.ppc64 requires /bin/sh uim-m17n-1.4.2-3.fc10.ppc64 requires /bin/sh uim-m17n-1.4.2-3.fc10.ppc64 requires /usr/bin/uim-module-manager uim-skk-1.4.2-3.fc10.ppc64 requires /bin/sh uim-skk-1.4.2-3.fc10.ppc64 requires /usr/bin/uim-module-manager ularn-1.5p4-11.fc9.ppc64 requires /bin/sh ulogd-1.24-9.fc9.ppc64 requires /bin/sh ulogd-1.24-9.fc9.ppc64 requires /bin/sh unicap-0.2.19-3.fc9.ppc64 requires /sbin/ldconfig uniconvertor-1.1.2-2.fc10.ppc64 requires /usr/bin/python uniconvertor-1.1.2-2.fc10.ppc64 requires /bin/sh unifdef-1.171-7.fc9.ppc64 requires /bin/sh unique-0.9.4-5.fc10.ppc64 requires /sbin/ldconfig unison213-2.13.16-10.fc9.ppc64 requires /bin/sh unison213-2.13.16-10.fc9.ppc64 requires /usr/sbin/alternatives unison213-2.13.16-10.fc9.ppc64 requires /usr/sbin/alternatives unison213-2.13.16-10.fc9.ppc64 requires /bin/sh unison227-2.27.57-8.fc9.ppc64 requires /bin/sh unison227-2.27.57-8.fc9.ppc64 requires /usr/sbin/alternatives unison227-2.27.57-8.fc9.ppc64 requires /usr/sbin/alternatives unison227-2.27.57-8.fc9.ppc64 requires /bin/sh units-1.87-2.fc9.ppc64 requires /bin/sh units-1.87-2.fc9.ppc64 requires /sbin/install-info unixODBC-2.2.12-7.fc9.ppc64 requires /sbin/ldconfig unixODBC-kde-2.2.12-7.fc9.ppc64 requires /sbin/ldconfig unixcw-2.3-2.fc9.ppc64 requires /sbin/ldconfig unshield-0.5-8.fc9.ppc64 requires /sbin/ldconfig unuran-1.2.4p1-1.fc10.ppc64 requires /bin/sh unuran-1.2.4p1-1.fc10.ppc64 requires /sbin/ldconfig unuran-1.2.4p1-1.fc10.ppc64 requires /sbin/install-info unzip-5.52-9.fc9.ppc64 requires /bin/sh up-imapproxy-1.2.4-9.fc9.ppc64 requires /bin/sh up-imapproxy-1.2.4-9.fc9.ppc64 requires /bin/bash up-imapproxy-1.2.4-9.fc9.ppc64 requires /sbin/chkconfig up-imapproxy-1.2.4-9.fc9.ppc64 requires /sbin/service uqm-0.6.2-3.fc9.ppc64 requires /bin/sh urbanterror-1.34-0.9.rc4.fc9.ppc64 requires /bin/sh urbanterror-1.34-0.9.rc4.fc9.ppc64 requires /bin/bash urlview-0.9-4.fc9.ppc64 requires /bin/bash urw-fonts-2.4-5.fc9.noarch requires /bin/sh usermode-1.97-1.ppc64 requires /etc/pam.d/system-auth ushare-1.1a-4.fc9.ppc64 requires /bin/sh ushare-1.1a-4.fc9.ppc64 requires /usr/sbin/alternatives ushare-1.1a-4.fc9.ppc64 requires /sbin/chkconfig ushare-1.1a-4.fc9.ppc64 requires /usr/sbin/alternatives ushare-1.1a-4.fc9.ppc64 requires /bin/sh ushare-1.1a-4.fc9.ppc64 requires /sbin/service usrp-3.1.1-4.fc9.ppc64 requires /usr/bin/env usrp-3.1.1-4.fc9.ppc64 requires /sbin/ldconfig ustr-1.0.4-6.fc9.ppc64 requires /sbin/ldconfig ustr-debug-1.0.4-6.fc9.ppc64 requires /sbin/ldconfig ustr-devel-1.0.4-6.fc9.ppc64 requires /bin/sh util-linux-ng-2.13.1-9.fc10.ppc64 requires /bin/sh util-linux-ng-2.13.1-9.fc10.ppc64 requires /etc/pam.d/system-auth util-linux-ng-2.13.1-9.fc10.ppc64 requires /sbin/install-info util-vserver-0.30.215-2.fc9.ppc64 requires /bin/sh util-vserver-0.30.215-2.fc9.ppc64 requires /usr/lib64/util-vserver/sigexec util-vserver-0.30.215-2.fc9.ppc64 requires /bin/bash util-vserver-0.30.215-2.fc9.ppc64 requires /bin/sh util-vserver-0.30.215-2.fc9.ppc64 requires /usr/lib64/util-vserver util-vserver-build-0.30.215-2.fc9.ppc64 requires /bin/sh util-vserver-build-0.30.215-2.fc9.ppc64 requires /bin/bash util-vserver-build-0.30.215-2.fc9.ppc64 requires /bin/sh util-vserver-build-0.30.215-2.fc9.ppc64 requires /etc/vservers util-vserver-core-0.30.215-2.fc9.ppc64 requires /bin/bash util-vserver-legacy-0.30.215-2.fc9.ppc64 requires /bin/bash util-vserver-legacy-0.30.215-2.fc9.ppc64 requires /bin/sh util-vserver-legacy-0.30.215-2.fc9.ppc64 requires /usr/bin/perl util-vserver-legacy-0.30.215-2.fc9.ppc64 requires /usr/lib64/util-vserver util-vserver-legacy-0.30.215-2.fc9.ppc64 requires /sbin/chkconfig util-vserver-legacy-0.30.215-2.fc9.ppc64 requires /etc/rc.d/init.d util-vserver-legacy-0.30.215-2.fc9.ppc64 requires /bin/sh util-vserver-lib-0.30.215-2.fc9.ppc64 requires /sbin/ldconfig util-vserver-sysv-0.30.215-2.fc9.ppc64 requires /bin/sh util-vserver-sysv-0.30.215-2.fc9.ppc64 requires /bin/bash util-vserver-sysv-0.30.215-2.fc9.ppc64 requires /usr/lib64/util-vserver util-vserver-sysv-0.30.215-2.fc9.ppc64 requires /sbin/chkconfig util-vserver-sysv-0.30.215-2.fc9.ppc64 requires /etc/rc.d/init.d util-vserver-sysv-0.30.215-2.fc9.ppc64 requires /bin/sh uucp-1.07-17.fc9.ppc64 requires /bin/sh uucp-1.07-17.fc9.ppc64 requires /bin/sh uucp-1.07-17.fc9.ppc64 requires /usr/bin/perl uucp-1.07-17.fc9.ppc64 requires /sbin/install-info uudeview-0.5.20-16.ppc64 requires /bin/sh uuid-1.6.1-3.fc9.ppc64 requires /sbin/ldconfig uuid-c++-1.6.1-3.fc9.ppc64 requires /sbin/ldconfig uuid-dce-1.6.1-3.fc9.ppc64 requires /sbin/ldconfig uuid-devel-1.6.1-3.fc9.ppc64 requires /usr/lib64/pkgconfig uuid-devel-1.6.1-3.fc9.ppc64 requires /bin/sh uuid-pgsql-1.6.1-3.fc9.ppc64 requires /usr/share/pgsql uuid-pgsql-1.6.1-3.fc9.ppc64 requires /usr/lib64/pgsql uuid-php-1.6.1-3.fc9.ppc64 requires /usr/lib64/php/modules uuidd-1.40.9-2.fc10.ppc64 requires /bin/sh uuidd-1.40.9-2.fc10.ppc64 requires /bin/bash uw-imap-2007a1-3.fc9.ppc64 requires /bin/sh vala-0.1.7-1.fc9.ppc64 requires /sbin/ldconfig vala-tools-0.1.7-1.fc9.ppc64 requires /bin/sh 1:valgrind-3.3.0-3.ppc64 requires /usr/bin/perl vamp-plugin-sdk-1.1b-4.fc9.ppc64 requires /sbin/ldconfig varconf-0.6.5-3.fc9.ppc64 requires /sbin/ldconfig varnish-1.1.2-6.fc9.ppc64 requires /bin/sh varnish-1.1.2-6.fc9.ppc64 requires /sbin/service varnish-1.1.2-6.fc9.ppc64 requires /bin/sh varnish-1.1.2-6.fc9.ppc64 requires /sbin/chkconfig varnish-libs-1.1.2-6.fc9.ppc64 requires /sbin/ldconfig vavoom-1.27.1-1.fc9.ppc64 requires /bin/sh vavoom-1.27.1-1.fc9.ppc64 requires /bin/bash vblade-14-4.fc9.ppc64 requires /bin/sh vblade-14-4.fc9.ppc64 requires /sbin/chkconfig vblade-14-4.fc9.ppc64 requires /bin/sh vblade-14-4.fc9.ppc64 requires /sbin/service vdccm-0.10.1-3.fc9.ppc64 requires /sbin/ldconfig vdr-1.6.0-3.fc9.ppc64 requires /bin/sh vdr-1.6.0-3.fc9.ppc64 requires /bin/bash vdr-1.6.0-3.fc9.ppc64 requires /bin/sh vdr-1.6.0-3.fc9.ppc64 requires /usr/bin/perl vdr-1.6.0-3.fc9.ppc64 requires /sbin/chkconfig vdr-devel-1.6.0-3.fc9.ppc64 requires /bin/bash vdr-devel-1.6.0-3.fc9.ppc64 requires /usr/bin/perl vdr-osdteletext-0.5.1-31.fc9.ppc64 requires /bin/sh vdr-skins-20061119-6.fc9.noarch requires /bin/sh vdr-text2skin-1.1-23.cvsext0.10.fc9.ppc64 requires /bin/sh vdradmin-am-3.6.1-1.fc8.noarch requires /bin/sh vdradmin-am-3.6.1-1.fc8.noarch requires /usr/bin/perl vdradmin-am-3.6.1-1.fc8.noarch requires /bin/sh vdradmin-am-3.6.1-1.fc8.noarch requires /sbin/chkconfig vdrift-20071226-3.fc9.ppc64 requires /bin/sh vecmath1.2-1.14-2.fc9.ppc64 requires /bin/sh vecmath1.2-javadoc-1.14-2.fc9.ppc64 requires /bin/sh vegastrike-0.5.0-2.fc10.ppc64 requires /usr/bin/perl vegastrike-0.5.0-2.fc10.ppc64 requires /bin/sh vegastrike-data-0.5.0-2.noarch requires /bin/sh vegastrike-data-0.5.0-2.noarch requires /usr/bin/python velocity-1.4-7jpp.1.ppc64 requires /bin/sh velocity-demo-1.4-7jpp.1.ppc64 requires /bin/sh velocity-javadoc-1.4-7jpp.1.ppc64 requires /bin/sh velocity-javadoc-1.4-7jpp.1.ppc64 requires /bin/rm velocity-javadoc-1.4-7jpp.1.ppc64 requires /bin/ln verbiste-0.1.22-1.fc9.ppc64 requires /sbin/ldconfig verbiste-gnome-0.1.22-1.fc9.ppc64 requires /bin/sh veusz-1.0-3.fc9.ppc64 requires /bin/sh veusz-1.0-3.fc9.ppc64 requires /usr/bin/env veusz-1.0-3.fc9.ppc64 requires /usr/bin/python viewvc-1.0.5-1.fc9.noarch requires /usr/bin/python vigra-1.5.0-4.fc9.ppc64 requires /sbin/ldconfig vigra-devel-1.5.0-4.fc9.ppc64 requires /bin/sh 2:vim-X11-7.1.298-1.fc10.ppc64 requires /bin/sh 2:vim-X11-7.1.298-1.fc10.ppc64 requires /bin/sh 2:vim-common-7.1.298-1.fc10.ppc64 requires /bin/sh 2:vim-enhanced-7.1.298-1.fc10.ppc64 requires /bin/sh vim-vimoutliner-0.3.4-9.fc7.noarch requires /bin/sh vim-vimoutliner-0.3.4-9.fc7.noarch requires /usr/bin/perl vim-vimoutliner-0.3.4-9.fc7.noarch requires /usr/bin/python vinagre-2.23.1-1.fc10.ppc64 requires /bin/sh vino-2.22.1-1.fc9.ppc64 requires /bin/sh vips-7.14.1-1.fc9.ppc64 requires /sbin/ldconfig vips-7.14.1-1.fc9.ppc64 requires libMagick.so.10()(64bit) vips-7.14.1-1.fc9.ppc64 requires libWand.so.10()(64bit) vips-python-7.14.1-1.fc9.ppc64 requires libMagick.so.10()(64bit) vips-python-7.14.1-1.fc9.ppc64 requires libWand.so.10()(64bit) vips-tools-7.14.1-1.fc9.ppc64 requires libMagick.so.10()(64bit) vips-tools-7.14.1-1.fc9.ppc64 requires /bin/bash vips-tools-7.14.1-1.fc9.ppc64 requires /bin/sh vips-tools-7.14.1-1.fc9.ppc64 requires libWand.so.10()(64bit) virt-manager-0.5.4-3.fc9.ppc64 requires /bin/sh virt-manager-0.5.4-3.fc9.ppc64 requires /bin/sh vkeybd-0.1.17a-7.fc9.ppc64 requires /bin/sh vkeybd-0.1.17a-7.fc9.ppc64 requires /usr/bin/wish vlock-1.3-26.fc9.ppc64 requires /etc/pam.d/system-auth vnc-4.1.2-30.fc10.ppc64 requires /bin/sh vnc-libs-4.1.2-30.fc10.ppc64 requires /bin/sh vnc-ltsp-config-4.0-4.fc9.noarch requires /bin/sh vnc-ltsp-config-4.0-4.fc9.noarch requires /bin/sh vnc-server-4.1.2-30.fc10.ppc64 requires /bin/sh vnc-server-4.1.2-30.fc10.ppc64 requires /usr/bin/env vnc-server-4.1.2-30.fc10.ppc64 requires /bin/bash vnstat-1.6-2.fc9.ppc64 requires /bin/sh vnstat-1.6-2.fc9.ppc64 requires /usr/sbin/useradd vodovod-1.10-2.fc9.ppc64 requires /bin/sh vodovod-1.10-2.fc9.ppc64 requires /bin/sh vpnc-0.5.1-5.fc9.ppc64 requires /bin/sh vpnc-consoleuser-0.5.1-5.fc9.ppc64 requires /bin/sh vsftpd-2.0.6-3.fc9.ppc64 requires /bin/sh vsftpd-2.0.6-3.fc9.ppc64 requires /lib64/security/pam_loginuid.so vsftpd-2.0.6-3.fc9.ppc64 requires /sbin/service vsftpd-2.0.6-3.fc9.ppc64 requires /bin/bash vsftpd-2.0.6-3.fc9.ppc64 requires /sbin/chkconfig vte-0.16.13-1.fc9.ppc64 requires /sbin/ldconfig vte-devel-0.16.13-1.fc9.ppc64 requires /bin/sh vtk-5.0.4-21.fc9.ppc64 requires /sbin/ldconfig vtk-devel-5.0.4-21.fc9.ppc64 requires /usr/bin/env vtk-python-5.0.4-21.fc9.ppc64 requires /sbin/ldconfig vtk-qt-5.0.4-21.fc9.ppc64 requires /sbin/ldconfig vtk-tcl-5.0.4-21.fc9.ppc64 requires /sbin/ldconfig vtk-testing-5.0.4-21.fc9.ppc64 requires /usr/bin/tclsh vtk-testing-5.0.4-21.fc9.ppc64 requires /usr/bin/env vym-1.10.0-3.fc9.ppc64 requires /bin/sh vym-1.10.0-3.fc9.ppc64 requires /bin/bash vym-1.10.0-3.fc9.ppc64 requires /usr/bin/perl w3c-libwww-5.4.1-0.10.20060206cvs.fc9.ppc64 requires /sbin/ldconfig w3c-libwww-devel-5.4.1-0.10.20060206cvs.fc9.ppc64 requires /bin/sh w3c-markup-validator-0.8.2-3.fc9.noarch requires /bin/sh w3c-markup-validator-0.8.2-3.fc9.noarch requires /usr/bin/perl w3c-markup-validator-libs-0.8.2-3.fc9.noarch requires /bin/sh w3m-0.5.2-10.fc10.ppc64 requires /usr/bin/perl w3m-el-common-1.4.4-7.fc9.noarch requires /bin/sh w3m-el-common-1.4.4-7.fc9.noarch requires /sbin/install-info waf-1.4.1-1.fc10.noarch requires /usr/bin/python wallpapoz-0.4.1-5.svn87_trunk.fc9.noarch requires /usr/bin/pgrep wallpapoz-0.4.1-5.svn87_trunk.fc9.noarch requires /usr/bin/kill wallpapoz-0.4.1-5.svn87_trunk.fc9.noarch requires /usr/bin/env wammu-0.26-2.fc9.noarch requires /usr/bin/python wavbreaker-0.9-3.fc9.ppc64 requires /bin/sh wavextract-1.0.0-3.fc9.noarch requires /usr/bin/env wavpack-4.41-2.fc9.ppc64 requires /sbin/ldconfig wbxml2-0.9.2-13.fc9.ppc64 requires /sbin/ldconfig wdaemon-0.13-1.fc9.ppc64 requires /bin/sh wdaemon-0.13-1.fc9.ppc64 requires /bin/bash wdm-1.28-10.fc9.ppc64 requires /sbin/shutdown wdm-1.28-10.fc9.ppc64 requires /etc/pam.d wdm-1.28-10.fc9.ppc64 requires /bin/bash wdm-1.28-10.fc9.ppc64 requires /bin/sh wdm-1.28-10.fc9.ppc64 requires /usr/bin/perl web2png-2.5.1-4.fc9.ppc64 requires /usr/bin/env webalizer-2.01_10-36.ppc64 requires /bin/sh webalizer-2.01_10-36.ppc64 requires /bin/bash webalizer-2.01_10-36.ppc64 requires /usr/sbin/useradd websec-1.9.0-4.1.noarch requires /usr/bin/perl werken-xpath-0.9.4-1.beta.12jpp.2.ppc64 requires /bin/sh werken-xpath-javadoc-0.9.4-1.beta.12jpp.2.ppc64 requires /bin/sh werken-xpath-javadoc-0.9.4-1.beta.12jpp.2.ppc64 requires /bin/ln werken-xpath-javadoc-0.9.4-1.beta.12jpp.2.ppc64 requires /bin/rm wesnoth-1.4.2-1.fc10.ppc64 requires /bin/sh wesnoth-server-1.4.2-1.fc10.ppc64 requires /bin/sh wesnoth-server-1.4.2-1.fc10.ppc64 requires /bin/sh wesnoth-server-1.4.2-1.fc10.ppc64 requires /sbin/chkconfig wesnoth-server-1.4.2-1.fc10.ppc64 requires /usr/sbin/useradd wesnoth-tools-1.4.2-1.fc10.ppc64 requires /usr/bin/env wfmath-0.3.7-2.fc9.ppc64 requires /sbin/ldconfig wfut-1.1.0-5.fc9.ppc64 requires /bin/sh wget-1.11.2-1.fc10.ppc64 requires /bin/sh wget-1.11.2-1.fc10.ppc64 requires /sbin/install-info which-2.19-3.fc9.ppc64 requires /bin/sh which-2.19-3.fc9.ppc64 requires /sbin/install-info whysynth-dssi-20070418-2.fc9.ppc64 requires /bin/sh widelands-0-0.9.build11.fc9.ppc64 requires /bin/sh wifi-radar-1.9.6-3.fc6.noarch requires /usr/bin/python wifiroamd-1.12-1.fc8.noarch requires /bin/sh wildmidi-libs-0.2.2-4.fc9.ppc64 requires /sbin/ldconfig wings-0.99.02-1.fc9.ppc64 requires /bin/sh winpdb-1.3.8-1.fc10.noarch requires /usr/bin/env winpdb-1.3.8-1.fc10.noarch requires /usr/bin/python 1:wireless-tools-29-2.fc9.ppc64 requires /sbin/ldconfig wireshark-1.0.0-2.fc9.ppc64 requires /sbin/ldconfig wkf-libs-1.3.11-2.fc9.ppc64 requires /sbin/ldconfig wklej-0.0.9-3.fc9.noarch requires /usr/bin/perl wlassistant-0.5.7-7.fc9.ppc64 requires /bin/sh wmx-6pl1-18.fc9.ppc64 requires /bin/bash wmx-6pl1-18.fc9.ppc64 requires /bin/sh wodim-1.1.6-11.fc9.ppc64 requires /bin/sh wodim-1.1.6-11.fc9.ppc64 requires /usr/sbin/alternatives wordwarvi-0.09-1.fc10.ppc64 requires /bin/sh worldofpadman-1.34-0.9.rc4.fc9.ppc64 requires /bin/bash worldofpadman-1.34-0.9.rc4.fc9.ppc64 requires /bin/sh worminator-3.0R2.1-8.fc9.ppc64 requires /bin/sh wormux-0.7.9-6.fc9.ppc64 requires /bin/sh wp_tray-0.5.3-7.fc9.ppc64 requires /bin/sh 1:wpa_supplicant-0.6.3-5.fc9.ppc64 requires /bin/sh 1:wpa_supplicant-0.6.3-5.fc9.ppc64 requires /bin/bash 1:wpa_supplicant-0.6.3-5.fc9.ppc64 requires /usr/bin/python wqy-bitmap-fonts-0.9.9-6.fc10.noarch requires /bin/sh wqy-unibit-fonts-1.1.0-4.fc8.noarch requires /bin/sh wqy-zenhei-fonts-0.5.23-0.fc9.noarch requires /bin/sh writer2latex-0.5-2.fc9.ppc64 requires /bin/sh wsdl4j-1.5.2-5jpp.2.fc9.ppc64 requires /bin/sh wsdl4j-javadoc-1.5.2-5jpp.2.fc9.ppc64 requires /bin/sh wsdl4j-javadoc-1.5.2-5jpp.2.fc9.ppc64 requires /bin/rm wsdl4j-javadoc-1.5.2-5jpp.2.fc9.ppc64 requires /bin/ln wuja-0.0.8-3.fc9.noarch requires /bin/sh wuja-0.0.8-3.fc9.noarch requires /usr/bin/python wv-1.2.4-4.fc9.ppc64 requires /sbin/ldconfig wv-1.2.4-4.fc9.ppc64 requires /bin/sh wv2-0.2.3-7.fc9.ppc64 requires /sbin/ldconfig wv2-devel-0.2.3-7.fc9.ppc64 requires /bin/sh wxBase-2.8.7-2.fc9.ppc64 requires /sbin/ldconfig wxGTK-2.8.7-2.fc9.ppc64 requires /sbin/ldconfig wxGTK-devel-2.8.7-2.fc9.ppc64 requires /bin/sh wxGTK-gl-2.8.7-2.fc9.ppc64 requires /sbin/ldconfig wxGlade-0.6.1-1.fc9.noarch requires /bin/sh wxGlade-0.6.1-1.fc9.noarch requires /bin/bash wxPython-2.8.7.1-2.fc9.ppc64 requires /usr/bin/env wxPython-2.8.7.1-2.fc9.ppc64 requires /usr/bin/python wxPython-2.8.7.1-2.fc9.ppc64 requires /bin/bash wxPython-2.8.7.1-2.fc9.ppc64 requires /bin/sh wxsvg-1.0-0.8.b10.fc10.ppc64 requires /sbin/ldconfig x11-ssh-askpass-1.2.4.1-4.fc9.ppc64 requires /usr/share/X11/app-defaults x3270-x11-3.3.6-5.fc9.ppc64 requires /bin/sh x3270-x11-3.3.6-5.fc9.ppc64 requires /usr/bin/mkfontdir xalan-c-1.10.0-4.fc9.ppc64 requires /sbin/ldconfig xalan-c-doc-1.10.0-4.fc9.ppc64 requires /bin/sh xalan-j2-2.7.0-7jpp.2.fc9.ppc64 requires /bin/sh xalan-j2-2.7.0-7jpp.2.fc9.ppc64 requires /usr/sbin/update-alternatives xalan-j2-demo-2.7.0-7jpp.2.fc9.ppc64 requires /bin/sh xalan-j2-javadoc-2.7.0-7jpp.2.fc9.ppc64 requires /bin/sh xalan-j2-javadoc-2.7.0-7jpp.2.fc9.ppc64 requires /bin/rm xalan-j2-javadoc-2.7.0-7jpp.2.fc9.ppc64 requires /bin/ln xalan-j2-xsltc-2.7.0-7jpp.2.fc9.ppc64 requires /bin/sh xaos-3.2.3-3.fc9.ppc64 requires /bin/sh xaos-3.2.3-3.fc9.ppc64 requires /sbin/install-info xapian-core-devel-1.0.6-1.fc9.ppc64 requires /bin/sh xapian-core-libs-1.0.6-1.fc9.ppc64 requires /sbin/ldconfig xar-1.5.1-6.fc9.ppc64 requires /sbin/ldconfig xarchiver-0.4.9-0.6.20070103svn24249.fc9.ppc64 requires /bin/sh xarchiver-0.4.9-0.6.20070103svn24249.fc9.ppc64 requires /bin/sh xarchon-0.50-7.fc9.ppc64 requires /bin/sh xastir-1.9.2-5.fc10.ppc64 requires /usr/bin/env xastir-1.9.2-5.fc10.ppc64 requires /bin/bash xastir-1.9.2-5.fc10.ppc64 requires /bin/sh xastir-1.9.2-5.fc10.ppc64 requires /usr/bin/perl xawtv-3.95-8.fc9.ppc64 requires /bin/bash xbae-4.60.4-9.fc9.ppc64 requires /sbin/ldconfig xbase-2.0.0-11.fc9.ppc64 requires /sbin/ldconfig xbase-devel-2.0.0-11.fc9.ppc64 requires /bin/sh xbindkeys-1.8.2-2.fc9.ppc64 requires /bin/sh xblast-2.10.4-5.fc9.ppc64 requires /usr/share/fonts/bitstream-vera/Vera.ttf xblast-common-2.10.4-5.fc9.ppc64 requires /bin/sh xblast-common-2.10.4-5.fc9.ppc64 requires /bin/bash xboard-4.2.7-17.fc9.ppc64 requires /bin/sh xboard-4.2.7-17.fc9.ppc64 requires /usr/bin/perl xboard-4.2.7-17.fc9.ppc64 requires /bin/sh xbsql-0.11-11.fc9.ppc64 requires /sbin/ldconfig 1:xchat-2.8.4-15.fc9.ppc64 requires /bin/sh xchat-gnome-0.18-12.fc9.ppc64 requires /bin/sh xchm-1.14-1.fc9.ppc64 requires /bin/sh xcircuit-3.4.27-3.fc9.ppc64 requires /bin/sh xcircuit-3.4.27-3.fc9.ppc64 requires /bin/sh xclip-0.10-3.fc9.ppc64 requires /bin/sh xdelta-1.1.4-3.fc9.ppc64 requires /sbin/ldconfig xdelta-devel-1.1.4-3.fc9.ppc64 requires /bin/bash xdg-user-dirs-0.10-1.fc9.ppc64 requires /bin/sh xdg-user-dirs-0.10-1.fc9.ppc64 requires /etc/X11/xinit/xinitrc.d xdg-utils-1.0.2-4.fc9.noarch requires /bin/bash xdg-utils-1.0.2-4.fc9.noarch requires /bin/sh xdoclet-1.2.3-9jpp.1.fc9.ppc64 requires /bin/sh xdvik-22.84.13-20.fc10.ppc64 requires /bin/sh xdvik-22.84.13-20.fc10.ppc64 requires /bin/sh xemacs-21.5.28-6.fc9.ppc64 requires /bin/sh xemacs-21.5.28-6.fc9.ppc64 requires /bin/sh xemacs-common-21.5.28-6.fc9.ppc64 requires /bin/sh xemacs-common-21.5.28-6.fc9.ppc64 requires /usr/sbin/alternatives xemacs-common-21.5.28-6.fc9.ppc64 requires /bin/sh xemacs-ess-5.3.7-1.fc10.noarch requires /bin/sh xemacs-info-21.5.28-6.fc9.ppc64 requires /bin/sh xemacs-info-21.5.28-6.fc9.ppc64 requires /sbin/install-info xemacs-nox-21.5.28-6.fc9.ppc64 requires /bin/sh xemacs-packages-extra-20070427-1.fc8.noarch requires /usr/bin/perl xemacs-packages-extra-20070427-1.fc8.noarch requires /usr/bin/env xemacs-packages-extra-20070427-1.fc8.noarch requires /bin/sh xerces-c-2.8.0-1.fc9.ppc64 requires /sbin/ldconfig xerces-c27-2.7.0-4.fc9.ppc64 requires /sbin/ldconfig xerces-j2-2.7.1-10jpp.1.fc9.ppc64 requires /bin/sh xerces-j2-2.7.1-10jpp.1.fc9.ppc64 requires /usr/sbin/update-alternatives xerces-j2-demo-2.7.1-10jpp.1.fc9.ppc64 requires /bin/sh xfce-mcs-plugins-4.4.2-4.fc9.ppc64 requires /bin/sh xfce-utils-4.4.2-4.fc9.ppc64 requires /usr/bin/id xfce-utils-4.4.2-4.fc9.ppc64 requires /bin/sh xfce4-appfinder-4.4.2-2.fc9.ppc64 requires /bin/sh xfce4-battery-plugin-0.5.0-4.fc9.ppc64 requires /bin/sh xfce4-dev-tools-4.4.0-1.fc7.noarch requires /bin/sh xfce4-dict-plugin-0.3.0-1.fc9.ppc64 requires /bin/sh xfce4-eyes-plugin-4.4.0-4.fc9.ppc64 requires /bin/sh xfce4-fsguard-plugin-0.4.1-2.fc9.ppc64 requires /bin/sh xfce4-mailwatch-plugin-1.0.1-8.fc9.ppc64 requires /bin/sh xfce4-mixer-4.4.2-2.fc9.ppc64 requires /bin/sh xfce4-mount-plugin-0.5.1-4.fc9.ppc64 requires /bin/sh xfce4-notes-plugin-1.6.1-2.fc9.ppc64 requires /bin/sh xfce4-panel-4.4.2-4.fc9.ppc64 requires /bin/sh xfce4-sensors-plugin-0.10.99.2-4.fc9.ppc64 requires /bin/sh xfce4-session-4.4.2-3.fc10.ppc64 requires /bin/sh xfce4-session-engines-4.4.2-3.fc10.ppc64 requires /bin/sh xfce4-time-out-plugin-0.1.1-1.fc9.ppc64 requires /bin/sh xfce4-weather-plugin-0.6.2-3.fc9.ppc64 requires /bin/sh xfdesktop-4.4.2-3.fc9.ppc64 requires /bin/sh xfig-common-3.2.5-10.fc9.ppc64 requires /bin/sh xfig-common-3.2.5-10.fc9.ppc64 requires /bin/bash xforms-1.0.90-11.fc9.ppc64 requires /sbin/ldconfig xfprint-4.4.2-2.fc9.ppc64 requires /bin/sh xfsprogs-2.9.8-1.fc10.ppc64 requires /sbin/ldconfig xfsprogs-2.9.8-1.fc10.ppc64 requires /bin/sh xfwm4-4.4.2-3.fc10.ppc64 requires /bin/sh xgalaxy-2.0.34-8.fc9.ppc64 requires /bin/sh xgrav-1.2.0-6.fc9.ppc64 requires /bin/sh xgridfit-1.5-2.fc9.noarch requires /usr/bin/xsltproc xguest-1.0.6-7.fc9.noarch requires /bin/sh xguest-1.0.6-7.fc9.noarch requires /bin/bash xhotkeys-0.9.8.3-5.fc9.noarch requires /bin/sh xhotkeys-0.9.8.3-5.fc9.noarch requires /bin/bash xhotkeys-0.9.8.3-5.fc9.noarch requires /usr/bin/python xhtml1-dtds-1.0-20020801.1.noarch requires /bin/sh xhtml1-dtds-1.0-20020801.1.noarch requires /usr/bin/xmlcatalog xhtml2ps-1.0-0.1.b5.fc10.noarch requires /usr/bin/wish xine-lib-1.1.12-3.fc10.ppc64 requires /sbin/ldconfig xine-lib-devel-1.1.12-3.fc10.ppc64 requires /bin/sh 2:xinetd-2.3.14-18.fc9.ppc64 requires /etc/init.d 2:xinetd-2.3.14-18.fc9.ppc64 requires /bin/sh 2:xinetd-2.3.14-18.fc9.ppc64 requires /sbin/service 2:xinetd-2.3.14-18.fc9.ppc64 requires /bin/bash 2:xinetd-2.3.14-18.fc9.ppc64 requires /sbin/chkconfig xjavadoc-1.1-5jpp.3.fc9.ppc64 requires /bin/sh xjavadoc-javadoc-1.1-5jpp.3.fc9.ppc64 requires /bin/sh xjavadoc-javadoc-1.1-5jpp.3.fc9.ppc64 requires /bin/rm xjavadoc-javadoc-1.1-5jpp.3.fc9.ppc64 requires /bin/ln xl2tpd-1.1.12-2.fc9.ppc64 requires /bin/sh xl2tpd-1.1.12-2.fc9.ppc64 requires /sbin/chkconfig xl2tpd-1.1.12-2.fc9.ppc64 requires /bin/sh xl2tpd-1.1.12-2.fc9.ppc64 requires /sbin/service xlhtml-0.5-8.fc9.ppc64 requires /usr/bin/perl xlhtml-0.5-8.fc9.ppc64 requires /bin/csh xlhtml-0.5-8.fc9.ppc64 requires /bin/bash xlhtml-0.5-8.fc9.ppc64 requires /bin/sh xml-commons-apis-1.3.04-1jpp.1.fc9.ppc64 requires /bin/sh xml-commons-apis-javadoc-1.3.04-1jpp.1.fc9.ppc64 requires /bin/ln xml-commons-apis-javadoc-1.3.04-1jpp.1.fc9.ppc64 requires /bin/rm xml-commons-apis12-1.2.04-1jpp.4.fc9.ppc64 requires /bin/sh xml-commons-resolver-1.1-1jpp.12.ppc64 requires /bin/sh xml-commons-resolver-javadoc-1.1-1jpp.12.ppc64 requires /bin/sh xml-commons-resolver-javadoc-1.1-1jpp.12.ppc64 requires /bin/rm xml-commons-resolver-javadoc-1.1-1jpp.12.ppc64 requires /bin/ln 1:xml-commons-which-1.0-1.b2.0jpp.2.ppc64 requires /bin/sh xmlcopyeditor-1.1.0.6-4.fc9.ppc64 requires /bin/sh 1:xmldb-api-0.1-0.2.20011111cvs.1jpp.2.fc9.ppc64 requires /bin/sh xmlrpc-2.0.1-4jpp.3.fc9.ppc64 requires /bin/sh xmlrpc-c-1.13.8-2.fc9.ppc64 requires /sbin/ldconfig xmlrpc-c-devel-1.13.8-2.fc9.ppc64 requires /bin/sh xmlsec1-1.2.9-10.1.ppc64 requires /bin/sh xmlsec1-devel-1.2.9-10.1.ppc64 requires /bin/sh xmlsec1-gnutls-1.2.9-10.1.ppc64 requires /bin/sh xmlsec1-openssl-1.2.9-10.1.ppc64 requires /bin/sh xmltex-20020625-11.fc9.noarch requires /bin/sh xmltex-20020625-11.fc9.noarch requires /bin/sh xmlto-0.0.20-3.fc10.ppc64 requires /bin/bash xmltoman-0.3-2.fc9.noarch requires /usr/bin/perl xmlunit-1.0-6jpp.1.fc9.ppc64 requires /bin/sh 1:xmms-1.2.10-38.fc9.ppc64 requires /bin/sh 1:xmms-1.2.10-38.fc9.ppc64 requires /usr/share/desktop-menu-patches/redhat-audio-player.desktop 1:xmms-1.2.10-38.fc9.ppc64 requires /bin/sh 1:xmms-devel-1.2.10-38.fc9.ppc64 requires /bin/sh 1:xmms-libs-1.2.10-38.fc9.ppc64 requires /sbin/ldconfig xmoto-0.4.2-1.fc9.ppc64 requires /bin/sh xmoto-edit-0.2.4-13.fc9.ppc64 requires /bin/sh xorg-x11-apps-7.3-3.fc9.ppc64 requires /bin/sh xorg-x11-filesystem-7.3-1.fc9.noarch requires /bin/bash xorg-x11-filesystem-7.3-1.fc9.noarch requires /bin/sh 1:xorg-x11-font-utils-7.2-4.fc9.ppc64 requires /bin/sh xorg-x11-fonts-100dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-75dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ISO8859-1-100dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ISO8859-1-75dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ISO8859-14-100dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ISO8859-14-75dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ISO8859-15-100dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ISO8859-15-75dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ISO8859-2-100dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ISO8859-2-75dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ISO8859-9-100dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ISO8859-9-75dpi-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-Type1-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-cyrillic-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-ethiopic-7.2-6.fc9.noarch requires /bin/sh xorg-x11-fonts-misc-7.2-6.fc9.noarch requires /bin/sh xorg-x11-server-Xorg-1.4.99.901-29.20080415.fc9.ppc64 requires /bin/sh xorg-x11-server-source-1.4.99.901-29.20080415.fc9.ppc64 requires /bin/sh 1:xorg-x11-xauth-1.0.2-4.fc9.ppc64 requires /bin/sh 1:xorg-x11-xdm-1.1.6-3.fc9.ppc64 requires /bin/sh 1:xorg-x11-xfs-1.0.5-2.fc9.ppc64 requires /bin/sh 1:xorg-x11-xfs-1.0.5-2.fc9.ppc64 requires /usr/bin/uniq 1:xorg-x11-xfs-1.0.5-2.fc9.ppc64 requires /usr/sbin/useradd 1:xorg-x11-xfs-1.0.5-2.fc9.ppc64 requires /usr/bin/find 1:xorg-x11-xfs-1.0.5-2.fc9.ppc64 requires /sbin/service 1:xorg-x11-xfs-1.0.5-2.fc9.ppc64 requires /sbin/nologin 1:xorg-x11-xfs-1.0.5-2.fc9.ppc64 requires /bin/bash 1:xorg-x11-xfs-1.0.5-2.fc9.ppc64 requires /bin/sh 1:xorg-x11-xfs-1.0.5-2.fc9.ppc64 requires /bin/sort 1:xorg-x11-xfs-1.0.5-2.fc9.ppc64 requires /sbin/chkconfig xorg-x11-xinit-1.0.7-6.fc9.ppc64 requires /bin/bash xorg-x11-xinit-1.0.7-6.fc9.ppc64 requires /bin/sh xorg-x11-xsm-1.0.2-7.fc9.ppc64 requires /bin/sh xosd-2.2.14-11.fc9.ppc64 requires /sbin/ldconfig xosd-devel-2.2.14-11.fc9.ppc64 requires /bin/sh xournal-0.4.2.1-1.fc9.ppc64 requires /bin/sh xpa-libs-2.1.8-6.fc9.ppc64 requires /sbin/ldconfig 1:xpdf-3.02-6.fc9.ppc64 requires /bin/sh xpilot-ng-4.7.2-14.fc9.ppc64 requires /bin/sh xpilot-ng-selinux-4.7.2-14.fc9.ppc64 requires /usr/sbin/semodule xpilot-ng-selinux-4.7.2-14.fc9.ppc64 requires /sbin/fixfiles xpilot-ng-selinux-4.7.2-14.fc9.ppc64 requires /bin/sh xpilot-ng-selinux-4.7.2-14.fc9.ppc64 requires /usr/sbin/semanage xpilot-ng-selinux-4.7.2-14.fc9.ppc64 requires /usr/sbin/setsebool xpilot-ng-selinux-4.7.2-14.fc9.ppc64 requires /sbin/service xpilot-ng-server-4.7.2-14.fc9.ppc64 requires /bin/sh xpilot-ng-server-4.7.2-14.fc9.ppc64 requires /sbin/chkconfig xpilot-ng-server-4.7.2-14.fc9.ppc64 requires /usr/bin/env xpilot-ng-server-4.7.2-14.fc9.ppc64 requires /bin/sh xpilot-ng-server-4.7.2-14.fc9.ppc64 requires /sbin/service xplanet-1.2.0-3.fc9.2.ppc64 requires /usr/bin/perl xqilla-2.0.0-5.fc9.ppc64 requires /sbin/ldconfig xqilla10-1.0.2-5.fc9.ppc64 requires /sbin/ldconfig xsane-gimp-0.995-3.fc9.ppc64 requires /bin/sh xsc-1.5-3.fc9.ppc64 requires /bin/sh xscorch-0.2.0-12.fc8.ppc64 requires /usr/bin/env 1:xscreensaver-base-5.05-3.fc9.ppc64 requires /etc/pam.d/system-auth 1:xscreensaver-base-5.05-3.fc9.ppc64 requires /usr/bin/perl 1:xscreensaver-base-5.05-3.fc9.ppc64 requires /bin/bash 1:xscreensaver-base-5.05-3.fc9.ppc64 requires /bin/sh 1:xscreensaver-extras-5.05-3.fc9.ppc64 requires /usr/bin/perl 1:xscreensaver-extras-5.05-3.fc9.ppc64 requires /bin/sh xstar-xscreensaver-2.2.0-3.fc9.ppc64 requires /bin/sh xterm-235-1.fc10.ppc64 requires /bin/sh xtide-2.10-2.fc9.ppc64 requires /bin/sh xtide-2.10-2.fc9.ppc64 requires /sbin/service xtide-2.10-2.fc9.ppc64 requires /bin/sh xtide-2.10-2.fc9.ppc64 requires /sbin/chkconfig xtide-common-2.10-2.fc9.ppc64 requires /bin/sh xu4-1.1-0.4.cvs20070510.fc9.ppc64 requires /bin/sh xu4-1.1-0.4.cvs20070510.fc9.ppc64 requires /bin/bash xulrunner-1.9-0.63.cvs20080516.fc10.ppc64 requires /bin/sh xulrunner-1.9-0.63.cvs20080516.fc10.ppc64 requires /bin/sh xyz-gallery-0.1-1.fc9.noarch requires /usr/bin/perl xzgv-0.9-4.fc9.ppc64 requires /bin/sh xzgv-0.9-4.fc9.ppc64 requires /sbin/install-info yadex-1.7.0-10.fc9.ppc64 requires /bin/sh yafc-1.1.1-10.fc9.ppc64 requires /bin/sh yafc-1.1.1-10.fc9.ppc64 requires /sbin/install-info yafray-0.0.9-7.fc9.ppc64 requires /sbin/ldconfig yakuake-2.9.1-1.fc9.ppc64 requires /bin/sh yanone-kaffeesatz-fonts-20061120-3.fc9.noarch requires /bin/sh yap-5.1.1-9.fc9.ppc64 requires /bin/sh yap-5.1.1-9.fc9.ppc64 requires /sbin/ldconfig yap-5.1.1-9.fc9.ppc64 requires /sbin/install-info yasm-0.7.0-1.fc10.ppc64 requires /sbin/ldconfig yelp-2.22.1-1.fc9.ppc64 requires /bin/sh youtube-dl-2008.01.24-1.fc9.noarch requires /usr/bin/env 3:ypbind-1.20.4-4.fc9.ppc64 requires /bin/sh 3:ypbind-1.20.4-4.fc9.ppc64 requires /sbin/chkconfig 3:ypbind-1.20.4-4.fc9.ppc64 requires /bin/bash ypserv-2.19-9.fc9.ppc64 requires /bin/sh ypserv-2.19-9.fc9.ppc64 requires /sbin/service ypserv-2.19-9.fc9.ppc64 requires /usr/bin/awk ypserv-2.19-9.fc9.ppc64 requires /bin/bash ypserv-2.19-9.fc9.ppc64 requires /bin/sh ypserv-2.19-9.fc9.ppc64 requires /sbin/chkconfig yum-3.2.16-1.fc10.noarch requires /usr/bin/python yum-arch-2.2.2-2.fc7.noarch requires /usr/bin/python yum-cron-0.8.2-1.fc9.noarch requires /bin/sh yum-cron-0.8.2-1.fc9.noarch requires /bin/bash yum-cron-0.8.2-1.fc9.noarch requires /sbin/chkconfig yum-cron-0.8.2-1.fc9.noarch requires /bin/sh yum-cron-0.8.2-1.fc9.noarch requires /sbin/service yum-updateonboot-1.1.13-2.fc9.noarch requires /bin/sh yum-updateonboot-1.1.13-2.fc9.noarch requires /bin/bash 1:yum-updatesd-0.9-1.fc9.noarch requires /bin/sh 1:yum-updatesd-0.9-1.fc9.noarch requires /bin/bash 1:yum-updatesd-0.9-1.fc9.noarch requires /usr/bin/python 1:yum-updatesd-0.9-1.fc9.noarch requires /sbin/chkconfig 1:yum-updatesd-0.9-1.fc9.noarch requires /sbin/service yum-utils-1.1.13-2.fc9.noarch requires /usr/bin/python yumex-2.0.4-1.fc9.noarch requires /bin/bash yumex-2.0.4-1.fc9.noarch requires /usr/bin/env yumex-2.0.4-1.fc9.noarch requires /usr/bin/python zabbix-1.4.5-3.fc10.ppc64 requires /bin/sh zabbix-1.4.5-3.fc10.ppc64 requires /usr/sbin/useradd zabbix-1.4.5-3.fc10.ppc64 requires /sbin/service zabbix-1.4.5-3.fc10.ppc64 requires /bin/sh zabbix-1.4.5-3.fc10.ppc64 requires /sbin/chkconfig zabbix-agent-1.4.5-3.fc10.ppc64 requires /bin/sh zabbix-agent-1.4.5-3.fc10.ppc64 requires /sbin/chkconfig zabbix-agent-1.4.5-3.fc10.ppc64 requires /usr/sbin/useradd zabbix-agent-1.4.5-3.fc10.ppc64 requires /bin/sh zabbix-agent-1.4.5-3.fc10.ppc64 requires /sbin/service zaptel-1.4.10.1-1.fc10.ppc64 requires /sbin/chkconfig zaptel-1.4.10.1-1.fc10.ppc64 requires /bin/sh zaptel-1.4.10.1-1.fc10.ppc64 requires /bin/sh zaptel-1.4.10.1-1.fc10.ppc64 requires /sbin/service zaptel-lib-1.4.10.1-1.fc10.ppc64 requires /sbin/ldconfig zasx-1.30-6.fc9.ppc64 requires /bin/sh zenity-2.23.1-1.fc10.ppc64 requires /bin/sh zeroinstall-injector-0.32-1.fc9.noarch requires /bin/sh zeroinstall-injector-0.32-1.fc9.noarch requires /usr/bin/env zeroinstall-injector-0.32-1.fc9.noarch requires /usr/bin/python zile-2.2.19-3.fc9.ppc64 requires /bin/sh zlib-1.2.3-18.fc9.ppc64 requires /sbin/ldconfig zoneminder-1.22.3-14.fc10.ppc64 requires /bin/sh zoneminder-1.22.3-14.fc10.ppc64 requires /sbin/service zoneminder-1.22.3-14.fc10.ppc64 requires /usr/bin/perl zoneminder-1.22.3-14.fc10.ppc64 requires /bin/sh zoneminder-1.22.3-14.fc10.ppc64 requires /sbin/chkconfig zsh-4.3.4-7.fc9.ppc64 requires /bin/sh zsh-4.3.4-7.fc9.ppc64 requires /sbin/install-info zsh-4.3.4-7.fc9.ppc64 requires /bin/sh zsh-4.3.4-7.fc9.ppc64 requires /bin/zsh zvbi-0.2.30-1.fc9.ppc64 requires /bin/sh zvbi-0.2.30-1.fc9.ppc64 requires /sbin/service zvbi-0.2.30-1.fc9.ppc64 requires /bin/sh zvbi-0.2.30-1.fc9.ppc64 requires /sbin/chkconfig zvbi-fonts-0.2.30-1.fc9.ppc64 requires /bin/sh zynaddsubfx-2.2.1-18.fc9.ppc64 requires /bin/sh zziplib-0.13.49-5.fc9.ppc64 requires /sbin/ldconfig From mattdm at mattdm.org Sat May 17 11:28:56 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 17 May 2008 07:28:56 -0400 Subject: NetworkManager: I want to believe, but... [was Re: F9 potential service network bug?] In-Reply-To: <604aa7910805161527j6b193c6dj2af4248155d5cdaf@mail.gmail.com> References: <3da3b5b40805161502w62f372dseca0ab6310e44447@mail.gmail.com> <1210975852.6805.10.camel@localhost.localdomain> <3da3b5b40805161522i2300f1cdhb1fc7b074084873f@mail.gmail.com> <604aa7910805161527j6b193c6dj2af4248155d5cdaf@mail.gmail.com> Message-ID: <20080517112856.GA18698@jadzia.bu.edu> On Fri, May 16, 2008 at 02:27:00PM -0800, Jeff Spaleta wrote: > NM doesn't handle all usage cases yet, which is why the legacy network > stack is still available for people who need it. So, the FeatureMoreNetworkManager wiki page says that NetworkManager is supposed to have new "Chuck Norris" features like supporting static IP addresses. It didn't work for me on a fresh F9 install, which then was a headache etc etc. (Even sytem-config-network had the right info, yet interface kept coming up dhcp.) So, as the Feature page says, it sure would be an advantage if it worked. Except, uh, what advantage does this bring me once it's set up? Why have a daemon and applet and dbus infrastructure monitoring something which by definition *is not going to change*? I'm not trying to troll -- I just don't get it. It seems like there's nothing in the "plus" column here. What am I missing? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Sat May 17 11:34:35 2008 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 17 May 2008 07:34:35 -0400 Subject: NetworkManager: I want to believe, but... [was Re: F9 potential service network bug?] In-Reply-To: <20080517112856.GA18698@jadzia.bu.edu> References: <3da3b5b40805161502w62f372dseca0ab6310e44447@mail.gmail.com> <1210975852.6805.10.camel@localhost.localdomain> <3da3b5b40805161522i2300f1cdhb1fc7b074084873f@mail.gmail.com> <604aa7910805161527j6b193c6dj2af4248155d5cdaf@mail.gmail.com> <20080517112856.GA18698@jadzia.bu.edu> Message-ID: <1211024075.4060.50.camel@localhost.localdomain> On Sat, 2008-05-17 at 07:28 -0400, Matthew Miller wrote: > > So, the FeatureMoreNetworkManager wiki page says that NetworkManager is > supposed to have new "Chuck Norris" features like supporting static IP > addresses. It didn't work for me on a fresh F9 install, which then was a > headache etc etc. (Even sytem-config-network had the right info, yet > interface kept coming up dhcp.) So, as the Feature page says, it sure would > be an advantage if it worked. > > Except, uh, what advantage does this bring me once it's set up? Why have a > daemon and applet and dbus infrastructure monitoring something which by > definition *is not going to change*? > > I'm not trying to troll -- I just don't get it. It seems like there's > nothing in the "plus" column here. What am I missing? Now this is interesting, because this same exact case works for me. Do install, configure static during install, upon boot static comes up. Please post your ifconfig files as they came from the installer when things weren't working. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From gary at mlbassoc.com Sat May 17 11:37:15 2008 From: gary at mlbassoc.com (Gary Thomas) Date: Sat, 17 May 2008 05:37:15 -0600 Subject: NetworkManager: I want to believe, but... [was Re: F9 potential service network bug?] In-Reply-To: <1211024075.4060.50.camel@localhost.localdomain> References: <3da3b5b40805161502w62f372dseca0ab6310e44447@mail.gmail.com> <1210975852.6805.10.camel@localhost.localdomain> <3da3b5b40805161522i2300f1cdhb1fc7b074084873f@mail.gmail.com> <604aa7910805161527j6b193c6dj2af4248155d5cdaf@mail.gmail.com> <20080517112856.GA18698@jadzia.bu.edu> <1211024075.4060.50.camel@localhost.localdomain> Message-ID: <482EC36B.3050803@mlbassoc.com> Jesse Keating wrote: > On Sat, 2008-05-17 at 07:28 -0400, Matthew Miller wrote: >> So, the FeatureMoreNetworkManager wiki page says that NetworkManager is >> supposed to have new "Chuck Norris" features like supporting static IP >> addresses. It didn't work for me on a fresh F9 install, which then was a >> headache etc etc. (Even sytem-config-network had the right info, yet >> interface kept coming up dhcp.) So, as the Feature page says, it sure would >> be an advantage if it worked. >> >> Except, uh, what advantage does this bring me once it's set up? Why have a >> daemon and applet and dbus infrastructure monitoring something which by >> definition *is not going to change*? >> >> I'm not trying to troll -- I just don't get it. It seems like there's >> nothing in the "plus" column here. What am I missing? > > Now this is interesting, because this same exact case works for me. Do > install, configure static during install, upon boot static comes up. What if you install via LiveCD? It doesn't ask anything about network setup in this case. -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ From sundaram at fedoraproject.org Sat May 17 11:41:53 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 17 May 2008 17:11:53 +0530 Subject: NetworkManager: I want to believe, but... [was Re: F9 potential service network bug?] In-Reply-To: <482EC36B.3050803@mlbassoc.com> References: <3da3b5b40805161502w62f372dseca0ab6310e44447@mail.gmail.com> <1210975852.6805.10.camel@localhost.localdomain> <3da3b5b40805161522i2300f1cdhb1fc7b074084873f@mail.gmail.com> <604aa7910805161527j6b193c6dj2af4248155d5cdaf@mail.gmail.com> <20080517112856.GA18698@jadzia.bu.edu> <1211024075.4060.50.camel@localhost.localdomain> <482EC36B.3050803@mlbassoc.com> Message-ID: <482EC481.9000304@fedoraproject.org> Gary Thomas wrote: > > What if you install via LiveCD? It doesn't ask anything about network > setup in this case. There should be pretty much no difference since Live CD's use Anaconda to perform the installation too. Up until the last release, NetworkManager was only turned when installed via a Live CD but that isn't the case with Fedora 9 release and it is turned on by default regardless of how you install it. Rahul From gary at mlbassoc.com Sat May 17 11:44:07 2008 From: gary at mlbassoc.com (Gary Thomas) Date: Sat, 17 May 2008 05:44:07 -0600 Subject: NetworkManager: I want to believe, but... [was Re: F9 potential service network bug?] In-Reply-To: <482EC481.9000304@fedoraproject.org> References: <3da3b5b40805161502w62f372dseca0ab6310e44447@mail.gmail.com> <1210975852.6805.10.camel@localhost.localdomain> <3da3b5b40805161522i2300f1cdhb1fc7b074084873f@mail.gmail.com> <604aa7910805161527j6b193c6dj2af4248155d5cdaf@mail.gmail.com> <20080517112856.GA18698@jadzia.bu.edu> <1211024075.4060.50.camel@localhost.localdomain> <482EC36B.3050803@mlbassoc.com> <482EC481.9000304@fedoraproject.org> Message-ID: <482EC507.1030707@mlbassoc.com> Rahul Sundaram wrote: > Gary Thomas wrote: > >> >> What if you install via LiveCD? It doesn't ask anything about network >> setup in this case. > > There should be pretty much no difference since Live CD's use Anaconda > to perform the installation too. Up until the last release, > NetworkManager was only turned when installed via a Live CD but that > isn't the case with Fedora 9 release and it is turned on by default > regardless of how you install it. I was pointing out that Jesse's comment about setting up the static IP *during* install doesn't apply in this case. That may be the source of the difference in behaviour that Matt is seeing. -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ From jkeating at redhat.com Sat May 17 11:52:15 2008 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 17 May 2008 07:52:15 -0400 Subject: rawhide report: 20080517 changes In-Reply-To: <20080517103836.1CA49209D25@releng1.fedora.phx.redhat.com> References: <20080517103836.1CA49209D25@releng1.fedora.phx.redhat.com> Message-ID: <1211025135.4060.53.camel@localhost.localdomain> On Sat, 2008-05-17 at 10:38 +0000, Rawhide wrote (a whole lot of lies): > Broken deps for Everything So yeah, these broken deps are a bit of a lie. Initial investigation looks like something might have gone wrong with the new yum in rawhide, but Seth is currently investigating to be sure. I wont rule out any number of other fun that could have caused this. Please do not submit any builds to "fix" these "broken" deps. Once we get a fixed package in place I'll re-generate the rawhide report and get a proper broken dep list. Isn't rawhide fun?! -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From rawhide at fedoraproject.org Sat May 17 12:10:56 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Sat, 17 May 2008 12:10:56 +0000 (UTC) Subject: rawhide report: 20080517 changes (resend) Message-ID: <20080517121056.2FEDC209D22@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080516/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080517/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package unique Unique instance support for applications New package lwp LWP thread library New package inksmoto Inksmoto Level Editor is the new xmoto level editor New package efreet An implementation of several specifications from freedesktop.org New package coda Coda distributed file system New package rpc2 RPC2 library New package cairo-dock Light eye-candy fully themable animated dock New package gypsy Gypsy is a GPS multiplexing daemon New package geoclue Geoclue is a modular geoinformation service New package rvm RVM library New package mod_bw Bandwidth Limiter For Apache Updated Packages: perl-Text-Diff-HTML-0.05-1.fc10 ------------------------------- * Fri May 16 18:00:00 2008 Steven Pritchard 0.05-1 - Update to 0.05. poker2d-1.5.0-1.fc10 -------------------- * Fri May 16 18:00:00 2008 Christopher Stone 1.5.0-1 - Upstream sync - Remove no longer needed configure patch - Remove autoreconf because it is no longer needed - Remove build requirements on gettext and libtool rtpproxy-1.1-0.3.beta.200804031.fc10 ------------------------------------ * Fri May 16 18:00:00 2008 Peter Lemenkov - 1.1-0.3.beta.200804031 - Snapshot 20080403.1 system-config-printer-0.9.91-1.fc10 ----------------------------------- * Fri May 16 18:00:00 2008 Tim Waugh 0.9.91-1 - No longer requires system-install-packages (bug #444645). - Added pysmbc. Build requires libsmbclient-devel. - Don't install consolehelper bits any more as they are no longer needed. - 0.9.91: - User interface overhaul, part 2. siege-2.67-1.fc10 ----------------- * Fri May 16 18:00:00 2008 Allisson Azevedo 2.67-1 - Update to 2.67 - Update License policycoreutils-2.0.49-2.fc10 ----------------------------- * Fri May 16 18:00:00 2008 Dan Walsh 2.0.49-2 - Fix listing of types in gui * Mon May 12 18:00:00 2008 Dan Walsh 2.0.49-1 - Update to upstream * Remove security_check_context calls for prefix validation from semanage. * Change setfiles and restorecon to not relabel if the file already has the correct context value even if -F/force is specified. * Mon May 12 18:00:00 2008 Dan Walsh 2.0.47-3 - Remove /usr/share/locale/sr at Latn/LC_MESSAGES/policycoreutils.mo gdl-0.9-0.rc1.3.fc10 -------------------- * Fri May 16 18:00:00 2008 - Orion Poplawski - 0.9-0.rc1.3 - Update to latest cvs - Add patch to handle new ImageMagick - Update netcdf locations * Mon Apr 28 18:00:00 2008 - Orion Poplawski - 0.9-0.rc1.2 - Rebuild for new ImageMagick udev-121-1.20080516git.fc10 --------------------------- * Fri May 16 18:00:00 2008 Harald Hoyer 121-1.20080516git - version 121 + latest git fixes * Thu Apr 24 18:00:00 2008 Harald Hoyer 120-6.20080421git - added input/hp_ilo_mouse symlink paps-0.6.8-6.fc10 ----------------- * Fri May 16 18:00:00 2008 Akira TAGOH - 0.6.8-6 - paps-cups.patch: Fix printing with -o landscape in CUPS. (#222137) - paps-autoconf262.patch: Fix an error on autoreconf. perl-Module-ScanDeps-0.84-1.fc10 -------------------------------- * Fri May 16 18:00:00 2008 Steven Pritchard 0.84-1 - Update to 0.84. ocaml-omake-0.9.8.5-3.fc10 -------------------------- * Fri May 16 18:00:00 2008 Richard W.M. Jones - 0.9.8.5-3 - Rebuild with OCaml 3.10.2-2 (fixes bz 445545). poker-engine-1.2.0-1.fc10 ------------------------- * Fri May 16 18:00:00 2008 Christopher Stone 1.2.0-1 - Upstream sync glusterfs-1.3.9-1.fc10 ---------------------- * Fri May 16 18:00:00 2008 Matthias Saou 1.3.9-1 - Update to 1.3.9. libsexy-0.1.11-8.fc10 --------------------- * Fri May 16 18:00:00 2008 Brian Pepple - 0.1.11-8 - Add requires for libxml2-devel to devel. (#446842) tuxpuck-0.8.2-6.fc10 -------------------- * Fri May 16 18:00:00 2008 Jon Ciesla 0.8.2-6 - FTBFS rebuild, BZ440791. perl-MasonX-Interp-WithCallbacks-1.18-1.fc10 -------------------------------------------- * Fri May 16 18:00:00 2008 Steven Pritchard 1.18-1 - Update to 1.18. nntpgrab-0.2.90-1.fc10 ---------------------- * Sat May 17 18:00:00 2008 Erik van Pienbroek - 0.2.90-1 - Update to version 0.2.90 (0.3 beta 1) containing lots of new features - Added a -server subpackage - Added a -web subpackage - All the plugins are now moved to /usr/lib/nntpgrab dhcp-4.0.0-15.fc10 ------------------ * Fri May 16 18:00:00 2008 David Cantrell - 12:4.0.0-15 - Set close-on-exec on dhclient.leases for SELinux (#446632) ghdl-0.26-0.94svn.7.fc10 ------------------------ * Fri May 16 18:00:00 2008 Thomas Sailer - 0.26-0.94svn.7 - update to svn94 libdc1394-2.0.2-1.fc10 ---------------------- * Mon May 12 18:00:00 2008 Tim Niemueller - 2.0.2-1 - Update to latest stable release 2.0.2 scim-sinhala-0.3.0-1.fc10 ------------------------- * Fri May 16 18:00:00 2008 Pravin Satpute - 0.3.0-1 - update to scim-sayura 0.3.0 from upstream - upated spec file as per new tarball libfprint-0.0.5-6.fc10 ---------------------- * Tue May 13 18:00:00 2008 Pingou 0.0.5-6 - Correction on the Build Requires * Tue May 13 18:00:00 2008 Pingou 0.0.5-5 - Correction on the Build Requires * Tue May 13 18:00:00 2008 Pingou 0.0.5-4 - Update the Build Requires due to the change on ImageMagick swig-1.3.35-2.fc10 ------------------ * Fri May 16 18:00:00 2008 Adam Tkac 1.3.35-2 - readded swig-arch.patch, will be kept downstream pulseaudio-0.9.11-0.0.svn20080516.fc10 -------------------------------------- * Fri May 16 18:00:00 2008 Matthias Clasen 0.9.11-0.0.svn20080516 - Update to an svn snapshot of the 'glitch-free' rewrite of pulseaudio nautilus-2.23.2-2.fc10 ---------------------- * Fri May 16 18:00:00 2008 Tomas Bzatek - 2.23.2-2 - Add treeview XDS drag&drop support (#446760) * Tue May 13 18:00:00 2008 Tomas Bzatek - 2.23.2-1 - Update to 2.23.2 fuse-s3fs-0.5-1.fc10 -------------------- * Fri May 16 18:00:00 2008 Neil Horman 0.5-1 - Updated s3fs to upstream version 0.5 augeas-0.1.1-1.fc10 ------------------- * Fri May 16 18:00:00 2008 David Lutterkort - 0.1.1-1 - New version * Fri May 2 18:00:00 2008 David Lutterkort - 0.1.0-2 - Fixes according to Fedora review ipa-1.0.0-5.fc10 ---------------- * Fri May 16 18:00:00 2008 Rob Crittenden - 1.0.0-5 - Set fedora-ds-base minimum version to 1.1.0.1-4 and mod_nss minimum version to 1.0.7-4 so we pick up the NSS fixes. - Add selinux-policy-base(post) to Requires (446496) GConf2-2.22.0-7.fc10 -------------------- * Wed May 14 18:00:00 2008 Ray Strode - 2.22.0-7 - update add_seconds patch to not remove timeouts that aren't created anymore gnome-python2-desktop-2.22.0-4.fc10 ----------------------------------- * Tue May 13 18:00:00 2008 Matthew Barnes - 2.22.0-4.fc10 - Rebuild against newer libedataserver and libtotem-plparser. * Tue Apr 29 18:00:00 2008 Matthew Barnes - 2.22.0-3.fc10 - gnome-python2-evolution obsoletes evolution-python (RH bug #444263). telepathy-gabble-0.7.6-1.fc10 ----------------------------- * Fri May 16 18:00:00 2008 Brian Pepple - 0.7.6-1 - Update to 0.7.6. perl-Params-CallbackRequest-1.18-1.fc10 --------------------------------------- * Fri May 16 18:00:00 2008 Steven Pritchard 1.18-1 - Update to 1.18. Broken deps for i386 ---------------------------------------------------------- LabPlot-1.5.1.6-4.fc8.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libMagick.so.10 autotrace-0.31.1-16.fc9.i386 requires libWand.so.10 autotrace-0.31.1-16.fc9.i386 requires libMagick.so.10 drawtiming-0.6.2-3.fc9.i386 requires libMagick++.so.10 drawtiming-0.6.2-3.fc9.i386 requires libWand.so.10 drawtiming-0.6.2-3.fc9.i386 requires libMagick.so.10 dx-4.4.4-6.fc9.i386 requires libWand.so.10 dx-4.4.4-6.fc9.i386 requires libMagick.so.10 dx-libs-4.4.4-6.fc9.i386 requires libWand.so.10 dx-libs-4.4.4-6.fc9.i386 requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-python-0.0.4-3.fc9.i386 requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.i386 requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-1.2.so.11 kismet-extras-0.0.2007.10.R1-3.fc9.i386 requires libMagick.so.10 koffice-karbon-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-karbon-1.6.3-15.fc9.i386 requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libMagick.so.10 nip2-7.14.1-1.fc9.i386 requires libWand.so.10 nip2-7.14.1-1.fc9.i386 requires libMagick.so.10 1:openoffice.org-presentation-minimizer-3.0.0-0.0.12.1.fc10.i386 requires openoffice.org-base-impress = 1:3.0.0-0.0.12.1.fc10 1:openoffice.org-presenter-screen-3.0.0-0.0.12.1.fc10.i386 requires openoffice.org-base-impress = 1:3.0.0-0.0.12.1.fc10 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) php-magickwand-1.0.7-1.fc10.i386 requires libWand.so.10 php-magickwand-1.0.7-1.fc10.i386 requires libMagick.so.10 psiconv-0.9.8-1.fc8.i386 requires libWand.so.10 psiconv-0.9.8-1.fc8.i386 requires libMagick.so.10 q-7.10-3.fc9.i386 requires libMagick.so.10 qgis-0.9.1-5.fc9.i386 requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.i386 requires libgeos.so.2 rhythmbox-0.11.5-9.fc9.i386 requires libtotem-plparser.so.10 sunbird-0.8-3.fc9.i386 requires libhunspell.so.1 thunderbird-lightning-0.8-3.fc9.i386 requires libhunspell.so.1 torcs-1.3.0-6.fc9.i386 requires libplibssgaux.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibssg.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibsl.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibsm.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibsg.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibul.so.1.8.4 totem-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 totem-mozplugin-2.23.2-2.fc9.i386 requires libtotem-plparser-mini.so.10 totem-mozplugin-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 totem-nautilus-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 vips-7.14.1-1.fc9.i386 requires libWand.so.10 vips-7.14.1-1.fc9.i386 requires libMagick.so.10 vips-python-7.14.1-1.fc9.i386 requires libWand.so.10 vips-python-7.14.1-1.fc9.i386 requires libMagick.so.10 vips-tools-7.14.1-1.fc9.i386 requires libWand.so.10 vips-tools-7.14.1-1.fc9.i386 requires libMagick.so.10 Broken deps for x86_64 ---------------------------------------------------------- LabPlot-1.5.1.6-4.fc8.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libMagick.so.10 LabPlot-1.5.1.6-4.fc8.x86_64 requires libMagick++.so.10()(64bit) LabPlot-1.5.1.6-4.fc8.x86_64 requires libMagick.so.10()(64bit) LabPlot-1.5.1.6-4.fc8.x86_64 requires libWand.so.10()(64bit) autotrace-0.31.1-16.fc9.i386 requires libWand.so.10 autotrace-0.31.1-16.fc9.i386 requires libMagick.so.10 autotrace-0.31.1-16.fc9.x86_64 requires libWand.so.10()(64bit) autotrace-0.31.1-16.fc9.x86_64 requires libMagick.so.10()(64bit) drawtiming-0.6.2-3.fc9.x86_64 requires libWand.so.10()(64bit) drawtiming-0.6.2-3.fc9.x86_64 requires libMagick++.so.10()(64bit) drawtiming-0.6.2-3.fc9.x86_64 requires libMagick.so.10()(64bit) dx-4.4.4-6.fc9.x86_64 requires libMagick.so.10()(64bit) dx-4.4.4-6.fc9.x86_64 requires libWand.so.10()(64bit) dx-libs-4.4.4-6.fc9.i386 requires libWand.so.10 dx-libs-4.4.4-6.fc9.i386 requires libMagick.so.10 dx-libs-4.4.4-6.fc9.x86_64 requires libMagick.so.10()(64bit) dx-libs-4.4.4-6.fc9.x86_64 requires libWand.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libWand.so.10()(64bit) evolution-python-0.0.4-3.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx kismet-extras-0.0.2007.10.R1-3.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.x86_64 requires libWand.so.10()(64bit) koffice-libs-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.x86_64 requires libWand.so.10()(64bit) nip2-7.14.1-1.fc9.x86_64 requires libMagick.so.10()(64bit) nip2-7.14.1-1.fc9.x86_64 requires libWand.so.10()(64bit) 1:openoffice.org-presentation-minimizer-3.0.0-0.0.12.1.fc10.x86_64 requires openoffice.org-base-impress = 1:3.0.0-0.0.12.1.fc10 1:openoffice.org-presenter-screen-3.0.0-0.0.12.1.fc10.x86_64 requires openoffice.org-base-impress = 1:3.0.0-0.0.12.1.fc10 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) php-magickwand-1.0.7-1.fc10.x86_64 requires libWand.so.10()(64bit) php-magickwand-1.0.7-1.fc10.x86_64 requires libMagick.so.10()(64bit) psiconv-0.9.8-1.fc8.i386 requires libWand.so.10 psiconv-0.9.8-1.fc8.i386 requires libMagick.so.10 psiconv-0.9.8-1.fc8.x86_64 requires libWand.so.10()(64bit) psiconv-0.9.8-1.fc8.x86_64 requires libMagick.so.10()(64bit) q-7.10-3.fc9.i386 requires libMagick.so.10 qgis-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) rhythmbox-0.11.5-9.fc9.i386 requires libtotem-plparser.so.10 rhythmbox-0.11.5-9.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) sunbird-0.8-3.fc9.x86_64 requires libhunspell.so.1()(64bit) thunderbird-lightning-0.8-3.fc9.x86_64 requires libhunspell.so.1()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibsg.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibul.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibssgaux.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibsm.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibssg.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibsl.so.1.8.4()(64bit) totem-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 totem-2.23.2-2.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.x86_64 requires libtotem-plparser-mini.so.10()(64bit) totem-nautilus-2.23.2-2.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) vips-7.14.1-1.fc9.i386 requires libWand.so.10 vips-7.14.1-1.fc9.i386 requires libMagick.so.10 vips-7.14.1-1.fc9.x86_64 requires libMagick.so.10()(64bit) vips-7.14.1-1.fc9.x86_64 requires libWand.so.10()(64bit) vips-python-7.14.1-1.fc9.x86_64 requires libMagick.so.10()(64bit) vips-python-7.14.1-1.fc9.x86_64 requires libWand.so.10()(64bit) vips-tools-7.14.1-1.fc9.x86_64 requires libMagick.so.10()(64bit) vips-tools-7.14.1-1.fc9.x86_64 requires libWand.so.10()(64bit) Broken deps for ppc ---------------------------------------------------------- LabPlot-1.5.1.6-4.fc8.ppc requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.ppc requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.ppc requires libMagick.so.10 autotrace-0.31.1-16.fc9.ppc requires libWand.so.10 autotrace-0.31.1-16.fc9.ppc requires libMagick.so.10 autotrace-0.31.1-16.fc9.ppc64 requires libWand.so.10()(64bit) autotrace-0.31.1-16.fc9.ppc64 requires libMagick.so.10()(64bit) drawtiming-0.6.2-3.fc9.ppc requires libMagick++.so.10 drawtiming-0.6.2-3.fc9.ppc requires libWand.so.10 drawtiming-0.6.2-3.fc9.ppc requires libMagick.so.10 dx-4.4.4-6.fc9.ppc requires libWand.so.10 dx-4.4.4-6.fc9.ppc requires libMagick.so.10 dx-libs-4.4.4-6.fc9.ppc requires libWand.so.10 dx-libs-4.4.4-6.fc9.ppc requires libMagick.so.10 dx-libs-4.4.4-6.fc9.ppc64 requires libMagick.so.10()(64bit) dx-libs-4.4.4-6.fc9.ppc64 requires libWand.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.ppc requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.ppc requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-python-0.0.4-3.fc9.ppc requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.ppc requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-1.2.so.11 kismet-extras-0.0.2007.10.R1-3.fc9.ppc requires libMagick.so.10 koffice-karbon-1.6.3-15.fc9.ppc requires libWand.so.10 koffice-karbon-1.6.3-15.fc9.ppc requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.ppc requires libWand.so.10 koffice-libs-1.6.3-15.fc9.ppc requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) nip2-7.14.1-1.fc9.ppc requires libWand.so.10 nip2-7.14.1-1.fc9.ppc requires libMagick.so.10 1:openoffice.org-presentation-minimizer-3.0.0-0.0.12.1.fc10.ppc requires openoffice.org-base-impress = 1:3.0.0-0.0.12.1.fc10 1:openoffice.org-presenter-screen-3.0.0-0.0.12.1.fc10.ppc requires openoffice.org-base-impress = 1:3.0.0-0.0.12.1.fc10 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) php-magickwand-1.0.7-1.fc10.ppc requires libWand.so.10 php-magickwand-1.0.7-1.fc10.ppc requires libMagick.so.10 psiconv-0.9.8-1.fc8.ppc requires libWand.so.10 psiconv-0.9.8-1.fc8.ppc requires libMagick.so.10 psiconv-0.9.8-1.fc8.ppc64 requires libWand.so.10()(64bit) psiconv-0.9.8-1.fc8.ppc64 requires libMagick.so.10()(64bit) q-7.10-3.fc9.ppc requires libMagick.so.10 q-7.10-3.fc9.ppc64 requires libMagick.so.10()(64bit) qgis-0.9.1-5.fc9.ppc requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.ppc requires libgeos.so.2 rhythmbox-0.11.5-9.fc9.ppc requires libtotem-plparser.so.10 rhythmbox-0.11.5-9.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) sunbird-0.8-3.fc9.ppc requires libhunspell.so.1 thunderbird-lightning-0.8-3.fc9.ppc requires libhunspell.so.1 torcs-1.3.0-6.fc9.ppc requires libplibssgaux.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibssg.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibsl.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibsm.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibsg.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibul.so.1.8.4 totem-2.23.2-2.fc9.ppc requires libtotem-plparser.so.10 totem-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.ppc requires libtotem-plparser-mini.so.10 totem-mozplugin-2.23.2-2.fc9.ppc requires libtotem-plparser.so.10 totem-nautilus-2.23.2-2.fc9.ppc requires libtotem-plparser.so.10 vips-7.14.1-1.fc9.ppc requires libWand.so.10 vips-7.14.1-1.fc9.ppc requires libMagick.so.10 vips-7.14.1-1.fc9.ppc64 requires libMagick.so.10()(64bit) vips-7.14.1-1.fc9.ppc64 requires libWand.so.10()(64bit) vips-python-7.14.1-1.fc9.ppc requires libWand.so.10 vips-python-7.14.1-1.fc9.ppc requires libMagick.so.10 vips-tools-7.14.1-1.fc9.ppc requires libWand.so.10 vips-tools-7.14.1-1.fc9.ppc requires libMagick.so.10 Broken deps for ppc64 ---------------------------------------------------------- autotrace-0.31.1-16.fc9.ppc64 requires libWand.so.10()(64bit) autotrace-0.31.1-16.fc9.ppc64 requires libMagick.so.10()(64bit) drawtiming-0.6.2-3.fc9.ppc64 requires libWand.so.10()(64bit) drawtiming-0.6.2-3.fc9.ppc64 requires libMagick++.so.10()(64bit) drawtiming-0.6.2-3.fc9.ppc64 requires libMagick.so.10()(64bit) dx-4.4.4-6.fc9.ppc64 requires libMagick.so.10()(64bit) dx-4.4.4-6.fc9.ppc64 requires libWand.so.10()(64bit) dx-libs-4.4.4-6.fc9.ppc64 requires libMagick.so.10()(64bit) dx-libs-4.4.4-6.fc9.ppc64 requires libWand.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-python-0.0.4-3.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) kismet-extras-0.0.2007.10.R1-3.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot nip2-7.14.1-1.fc9.ppc64 requires libMagick.so.10()(64bit) nip2-7.14.1-1.fc9.ppc64 requires libWand.so.10()(64bit) 1:openoffice.org-presentation-minimizer-3.0.0-0.0.12.1.fc10.ppc64 requires openoffice.org-base-impress = 1:3.0.0-0.0.12.1.fc10 1:openoffice.org-presenter-screen-3.0.0-0.0.12.1.fc10.ppc64 requires openoffice.org-base-impress = 1:3.0.0-0.0.12.1.fc10 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 php-magickwand-1.0.7-1.fc10.ppc64 requires libWand.so.10()(64bit) php-magickwand-1.0.7-1.fc10.ppc64 requires libMagick.so.10()(64bit) ppc64-utils-0.14-2.fc9.ppc64 requires yaboot psiconv-0.9.8-1.fc8.ppc64 requires libWand.so.10()(64bit) psiconv-0.9.8-1.fc8.ppc64 requires libMagick.so.10()(64bit) q-7.10-3.fc9.ppc64 requires libMagick.so.10()(64bit) qgis-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) rhythmbox-0.11.5-9.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) sunbird-0.8-3.fc9.ppc64 requires libhunspell.so.1()(64bit) thunderbird-lightning-0.8-3.fc9.ppc64 requires libhunspell.so.1()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibsg.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibul.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibsm.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibssgaux.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibssg.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibsl.so.1.8.4()(64bit) totem-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.ppc64 requires libtotem-plparser-mini.so.10()(64bit) totem-nautilus-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) vips-7.14.1-1.fc9.ppc64 requires libMagick.so.10()(64bit) vips-7.14.1-1.fc9.ppc64 requires libWand.so.10()(64bit) vips-python-7.14.1-1.fc9.ppc64 requires libMagick.so.10()(64bit) vips-python-7.14.1-1.fc9.ppc64 requires libWand.so.10()(64bit) vips-tools-7.14.1-1.fc9.ppc64 requires libMagick.so.10()(64bit) vips-tools-7.14.1-1.fc9.ppc64 requires libWand.so.10()(64bit) From jkeating at redhat.com Sat May 17 12:13:00 2008 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 17 May 2008 08:13:00 -0400 Subject: rawhide report: 20080517 changes In-Reply-To: <1211025135.4060.53.camel@localhost.localdomain> References: <20080517103836.1CA49209D25@releng1.fedora.phx.redhat.com> <1211025135.4060.53.camel@localhost.localdomain> Message-ID: <1211026380.4060.56.camel@localhost.localdomain> On Sat, 2008-05-17 at 07:52 -0400, Jesse Keating wrote: > Once we > get a fixed package in place I'll re-generate the rawhide report and get > a proper broken dep list. Ok, Seth was right, there was a one line change needed in yum to fix it's ability to resolve file deps. I've submitted a yum build for this and also fixed the machine that generates the rawhide report and resent a new report with an accurate list of broken dependencies. Sorry for the extra noise! -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From cra at WPI.EDU Sat May 17 13:52:49 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Sat, 17 May 2008 09:52:49 -0400 Subject: I have a big mouth... In-Reply-To: <604aa7910805161029i1573ca51v11c144007c0254f3@mail.gmail.com> References: <604aa7910805161029i1573ca51v11c144007c0254f3@mail.gmail.com> Message-ID: <20080517135249.GB20674@angus.ind.WPI.EDU> On Fri, May 16, 2008 at 09:29:20AM -0800, Jeff Spaleta wrote: > http://www.informationweek.com/blog/main/archives/2008/05/hats_off_for_fe.html > > First comment in the comment section. Since i love flashing my board > creds as much as possible. I want to make sure everyone else is aware > of my attempts at sullying the Fedora Board's reputation. Ironically, I can't get the comment section to show up in Fedora 9's FF3. From debarshi.ray at gmail.com Sat May 17 14:00:40 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Sat, 17 May 2008 19:30:40 +0530 Subject: I have a big mouth... In-Reply-To: <20080517135249.GB20674@angus.ind.WPI.EDU> References: <604aa7910805161029i1573ca51v11c144007c0254f3@mail.gmail.com> <20080517135249.GB20674@angus.ind.WPI.EDU> Message-ID: <3170f42f0805170700y7671f2cbs4689721d8253511e@mail.gmail.com> > Ironically, I can't get the comment section to show up in Fedora 9's > FF3. Neither could I on Fedora 8's Epiphany. Cheerio, Debarshi -- "From what we get, we can make a living; what we give, however, makes a life." -- Arthur Ashe From gbillios at gmail.com Sat May 17 14:02:45 2008 From: gbillios at gmail.com (George Billios) Date: Sat, 17 May 2008 17:02:45 +0300 Subject: I have a big mouth... In-Reply-To: <20080517135249.GB20674@angus.ind.WPI.EDU> References: <604aa7910805161029i1573ca51v11c144007c0254f3@mail.gmail.com> <20080517135249.GB20674@angus.ind.WPI.EDU> Message-ID: <482EE585.4040201@gmail.com> Nah, its a problem with the site, worked earlier for me but now not! -------- Original Message -------- Subject: Re:I have a big mouth... From: Chuck Anderson To: fedora-devel-list at redhat.com Date: Sat 17 May 2008 04:52:49 PM EEST > On Fri, May 16, 2008 at 09:29:20AM -0800, Jeff Spaleta wrote: >> http://www.informationweek.com/blog/main/archives/2008/05/hats_off_for_fe.html >> >> First comment in the comment section. Since i love flashing my board >> creds as much as possible. I want to make sure everyone else is aware >> of my attempts at sullying the Fedora Board's reputation. > > Ironically, I can't get the comment section to show up in Fedora 9's > FF3. > From clydekunkel7734 at cox.net Sat May 17 14:30:59 2008 From: clydekunkel7734 at cox.net (Clyde E. Kunkel) Date: Sat, 17 May 2008 10:30:59 -0400 Subject: Glitch-Free PulseAudio in Rawhide In-Reply-To: <20080517101616.GA16071@tango.0pointer.de> References: <20080517101616.GA16071@tango.0pointer.de> Message-ID: <482EEC23.8080109@cox.net> Lennart Poettering wrote: > Heya! > > Since yesterday glitch-free PulseAudio is available in Rawhide, > breaking your sound setups. > > Please make sure to read this mail I posted to the PA ML a few minutes back, > especially those people who have HDA audio hw and want to play with this: > > https://tango.0pointer.de/pipermail/pulseaudio-discuss/2008-May/001837.html > > Lennart > Installed 20080517. Using gnome sound preferences devices tab with playback set to autodetect, test sound comes thru, but no sound when hitting various play buttons on sounds tab. Also, pulse audio volume control fails with connection refused. Rawhide, up-to-date as of 20080517. [root at P5K-EWIFI ~]# rpm -q pulseaudio pulseaudio-0.9.11-0.0.svn20080516.fc10.i386 --------------------------------- Regards, Old Fart -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: gnome-settings-sound.desktop URL: From lmacken at redhat.com Sat May 17 14:42:16 2008 From: lmacken at redhat.com (Luke Macken) Date: Sat, 17 May 2008 10:42:16 -0400 Subject: Bodhi documentation for new packages In-Reply-To: <482D9905.70000@garden.org> References: <481F5F85.7080203@garden.org> <20080506224247.GA3372@x300> <482D9905.70000@garden.org> Message-ID: <20080517144216.GA4349@x300> On Fri, May 16, 2008 at 10:24:05AM -0400, Aaron S. Hawley wrote: > [Please, Cc me replies, thanks.] > > Luke Macken wrote: >> On Mon, May 05, 2008 at 03:27:01PM -0400, Aaron S. Hawley wrote: >>> >>> >>> The directions for joining Fedora as a package maintainer[1] are really >>> great. Unfortunately, they trail off at the end when it comes to >>> important tasks of making the package live using the Bodhi system, >>> section "Request updates to released Fedoras for your new package". I >>> ran into this roadblock last month, and it hasn't improved since. >>> >>> As a new maintainer, I know very little about the updates infrastructure >>> of Fedora, which I predict is assumed knowledge about using Bodhi. This >>> is probably unfair to new maintainers. Here's my proposal for what this >>> section should say. It is also what I did, so I'm sure it needs >>> correction, and let me know so I can get my new package (gnue-common) >>> live. Thanks for Fedora, /a >> >> Thanks for taking the time to give feedback and help improve our documentation. >> I completely agree that the updates/bodhi docs need some work. Come F9, >> I hope to have a lot of new bodhi features and changes to existing >> workflow deployed, so I'll be tweaking the documentation a lot then. >> >>> -- BEGIN -- >>> >>> The first field asks for the name of the "Package". This will feature a >>> name completion system, but is currently broken. It uses the tag used in >>> Fedora CVS and the Koji build system, e.g. >>> --.fc9. >> >> The build completion is no longer broken. It doesn't not query by tag >> (yet, at least), it simply offers all builds for the given package. >> >>> For new packages, choose "enhancement" as the "type" of update. >> >> Correct, for now. Spot and I discussed this yesterday and we thought it >> would probably be a good idea to add another type of update specifically >> for new packages. This would allow tools like PackageKit to say "Hey, >> check out the newest packages in Fedora that you could possibly install!" >> >>> Keep the "Request" as "testing". >> >> It's probably best to leave this up to the developer pushing the update. >> I originally made bodhi force packages to go through testing first, but >> many people complained and had their reasons for wanting pushing directly >> to stable. >> >>> There are no bugs that are related to any new package, so leave the >>> "Bugs" field blank. >> >> New packages could possibly add their Review Request bug to the update, >> which will have bodhi automatically close it when it gets pushed. >> >>> For new packages, add a copy of the package's description in the "Notes" >>> section so end users will know what it is.[2] >> >> This sounds fine. >> >> Cheers, >> luke > > Luke, I had a chance to rewrite the instructions for adding new packages > with Bodhi using your response. I can throw them on the Wiki if you like. > > --BEGIN-- > > The first field asks for the name of the "Package". This field will > auto-complete the package name found in the Koji build system, e.g. > --.fc9. If completion doesn't work, just > enter the package build name yourself. > > For new packages, choose "enhancement" as the "type" of update. > > Put the "Request" as "testing" if you want to put the package through > testing first, see [:QA: Fedora Quality Assurance]. Put "stable" if you > want to push the package directly to stable. > > There are no bugs that are related to any new package, so leave the "Bugs" > field blank. In the future, the bug number for the Review Request bug > might be entered here for Bodhi to automatically close when it gets pushed > to the request update status. There's nothing stopping people from entering the review bug in now, and it's actually done quite frequently. I don't see any reason to not recommend doing this. > For new packages, add a copy of the package's description in the "Notes" > section so end users will know what the package is. Other than what I mentioned above, this looks fine. Feel free to update the wiki once you change that. Thanks! luke From bernie at codewiz.org Sat May 17 15:17:10 2008 From: bernie at codewiz.org (Bernie Innocenti) Date: Sat, 17 May 2008 17:17:10 +0200 Subject: Strange broken dependency warning In-Reply-To: <20080517100455.017CC209D27@releng1.fedora.phx.redhat.com> References: <20080517100455.017CC209D27@releng1.fedora.phx.redhat.com> Message-ID: <482EF6F6.4020301@codewiz.org> Should I take this warning seriously? buildsys at fedoraproject.org wrote: > nafees-web-naskh-fonts has broken dependencies in the development tree: > On ppc: > nafees-web-naskh-fonts-1.0-1.fc8.noarch requires /bin/sh > On x86_64: > nafees-web-naskh-fonts-1.0-1.fc8.noarch requires /bin/sh > On i386: > nafees-web-naskh-fonts-1.0-1.fc8.noarch requires /bin/sh > On ppc64: > nafees-web-naskh-fonts-1.0-1.fc8.noarch requires /bin/sh > Please resolve this as soon as possible. -- \___/ _| X | Bernie Innocenti - http://www.codewiz.org/ \|_O_| "It's an education project, not a laptop project!" From sundaram at fedoraproject.org Sat May 17 15:21:58 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 17 May 2008 20:51:58 +0530 Subject: Strange broken dependency warning In-Reply-To: <482EF6F6.4020301@codewiz.org> References: <20080517100455.017CC209D27@releng1.fedora.phx.redhat.com> <482EF6F6.4020301@codewiz.org> Message-ID: <482EF816.7010404@fedoraproject.org> Bernie Innocenti wrote: > Should I take this warning seriously? > Hi, No. Jesse Keating explained the reason in an earlier post to this list. You can ignore this issue for now. Rahul > buildsys at fedoraproject.org wrote: >> nafees-web-naskh-fonts has broken dependencies in the development tree: >> On ppc: >> nafees-web-naskh-fonts-1.0-1.fc8.noarch requires /bin/sh >> On x86_64: >> nafees-web-naskh-fonts-1.0-1.fc8.noarch requires /bin/sh >> On i386: >> nafees-web-naskh-fonts-1.0-1.fc8.noarch requires /bin/sh >> On ppc64: >> nafees-web-naskh-fonts-1.0-1.fc8.noarch requires /bin/sh >> Please resolve this as soon as possible. > From thomas.moschny at gmail.com Sat May 17 15:46:50 2008 From: thomas.moschny at gmail.com (Thomas Moschny) Date: Sat, 17 May 2008 17:46:50 +0200 Subject: Bodhi documentation for new packages In-Reply-To: <20080517144216.GA4349@x300> References: <481F5F85.7080203@garden.org> <20080506224247.GA3372@x300> <482D9905.70000@garden.org> <20080517144216.GA4349@x300> Message-ID: 2008/5/17, Luke Macken : >> There are no bugs that are related to any new package, so leave the "Bugs" >> >> field blank. In the future, the bug number for the Review Request bug >> might be entered here for Bodhi to automatically close when it gets pushed >> to the request update status. > > There's nothing stopping people from entering the review bug in now, and > it's actually done quite frequently. I don't see any reason to not > recommend doing this. In fact bodhi already automatically closes the review ticket when the package arrives in at least one of the stable repositories. This doesn't seem to be widely known, and I already saw complaints if the ticket wasn't manually closed by the packager fast enough. - Thomas From enrico.scholz at informatik.tu-chemnitz.de Sat May 17 15:50:05 2008 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 17 May 2008 17:50:05 +0200 Subject: rhgb no more In-Reply-To: <200805150959.28963.sgrubb@redhat.com> (Steve Grubb's message of "Thu, 15 May 2008 09:59:28 -0400") References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> <200805150824.08419.sgrubb@redhat.com> <1210856530.4615.2.camel@localhost.localdomain> <200805150959.28963.sgrubb@redhat.com> Message-ID: <87y769hqvm.fsf@sheridan.bigo.ensc.de> Steve Grubb writes: > I have it as low in init priority as I can get it. It even starts before > rsyslog. If a graphical boot does not honor the settings in the init scripts, > what am I supposed to do? Is there another directory that I need to drop a > file into that gets picked up by the boot sequence? Put this into /etc/event.d/auditd | start on starting syslog-ng | start on starting rsyslog | stop on stopped syslog-ng | stop on stopped rsyslog | | exec /sbin/auditd -n Enrico From jaroslav at aster.pl Sat May 17 16:18:26 2008 From: jaroslav at aster.pl (=?utf-8?q?Jaros=C5=82aw_G=C3=B3rny?=) Date: Sat, 17 May 2008 18:18:26 +0200 Subject: passwd does not work after f8 -> f9 upgrade Message-ID: <200805171818.26894.jaroslav@aster.pl> Hi, I've searched BZ, but not found anything similar. Couple of days ago I've upgraded to f9 with plain old "yum update". The process went smoothly, but now I'm not able to use passwd. Any try to change password (directly as a user, or as a root) fails: [root at moonstone cracklib]# LANG=C passwd testowy Changing password for user testowy. New UNIX password: /usr/share/cracklib/pw_dict: error reading header PWOpen: Success appropriate fragment of strace looks like this: write(2, "New UNIX password: ", 19) = 19 read(0, "lame_password\n", 511) = 14 ioctl(0, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig icanon echo ...}) = 0 write(2, "\n", 1) = 1 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 ioctl(0, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig icanon echo ...}) = 0 open("/usr/share/cracklib/pw_dict.pwd", O_RDONLY) = 4 open("/usr/share/cracklib/pw_dict.pwi", O_RDONLY) = 5 open("/usr/share/cracklib/pw_dict.hwm", O_RDONLY) = 6 fstat64(5, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb80d9000 read(5, "", 4096) = 0 write(2, "/usr/share/cracklib/pw_dict: err"..., 50) = 50 close(5) = 0 munmap(0xb80d9000, 4096) = 0 close(4) = 0 close(6) = 0 write(2, "PWOpen: Success\n", 16) = 16 exit_group(-1) = ? If this should be reported in BZ, I'll do it. Any tips to solve this really appreciated. Thanks, regards, -- jg From kagesenshi.87 at gmail.com Sat May 17 16:54:57 2008 From: kagesenshi.87 at gmail.com (Izhar Firdaus) Date: Sun, 18 May 2008 00:54:57 +0800 Subject: passwd does not work after f8 -> f9 upgrade In-Reply-To: <200805171818.26894.jaroslav@aster.pl> References: <200805171818.26894.jaroslav@aster.pl> Message-ID: On Sun, May 18, 2008 at 12:18 AM, Jaros?aw G?rny wrote: > Hi, > I've searched BZ, but not found anything similar. > Couple of days ago I've upgraded to f9 with plain old "yum update". The > process went smoothly, but now I'm not able to use passwd. Any try to change > password (directly as a user, or as a root) fails: > > > [root at moonstone cracklib]# LANG=C passwd testowy > Changing password for user testowy. > New UNIX password: > /usr/share/cracklib/pw_dict: error reading header > PWOpen: Success > > > appropriate fragment of strace looks like this: > > > write(2, "New UNIX password: ", 19) = 19 > read(0, "lame_password\n", 511) = 14 > ioctl(0, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig icanon echo ...}) = 0 > write(2, "\n", 1) = 1 > rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 > ioctl(0, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig icanon echo ...}) = 0 > open("/usr/share/cracklib/pw_dict.pwd", O_RDONLY) = 4 > open("/usr/share/cracklib/pw_dict.pwi", O_RDONLY) = 5 > open("/usr/share/cracklib/pw_dict.hwm", O_RDONLY) = 6 > fstat64(5, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = > 0xb80d9000 > read(5, "", 4096) = 0 > write(2, "/usr/share/cracklib/pw_dict: err"..., 50) = 50 > close(5) = 0 > munmap(0xb80d9000, 4096) = 0 > close(4) = 0 > close(6) = 0 > write(2, "PWOpen: Success\n", 16) = 16 > exit_group(-1) = ? > > > > If this should be reported in BZ, I'll do it. Any tips to solve this really > appreciated. Thanks, > > regards, sounds like a broken file to me, try: rpm -V cracklib-dicts and see whether theres any broken files from that package. you may want to run package-cleanup --problems just in case somehow happened missing dependencies .. -- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? http://fedoraproject.org/wiki/MohdIzharFirdaus http://blog.kagesenshi.org 92C2 B295 B40B B3DC 6866 5011 5BD2 584A 8A5D 7331 From jaroslav at aster.pl Sat May 17 17:19:20 2008 From: jaroslav at aster.pl (=?utf-8?q?Jaros=C5=82aw_G=C3=B3rny?=) Date: Sat, 17 May 2008 19:19:20 +0200 Subject: passwd does not work after f8 -> f9 upgrade In-Reply-To: References: <200805171818.26894.jaroslav@aster.pl> Message-ID: <200805171919.20791.jaroslav@aster.pl> Hi, Saturday 17 of May 2008 18:54:57 Izhar Firdaus napisa?(a): > On Sun, May 18, 2008 at 12:18 AM, Jaros?aw G?rny wrote: > > Hi, > > I've searched BZ, but not found anything similar. > > Couple of days ago I've upgraded to f9 with plain old "yum update". The > > process went smoothly, but now I'm not able to use passwd. Any try to > > change password (directly as a user, or as a root) fails: > > (...) > sounds like a broken file to me, > > try: > > rpm -V cracklib-dicts Yes, You're right. That was the case. Reinstalling cracklib-dicts solved this. > > you may want to run package-cleanup --problems just in case somehow > happened missing dependencies .. > no, no dependency problems detected. I wonder why this files were corrupted? Anyway, thanks a lot! regards, -- jg From david at xn--kremla-iuad.se Sat May 17 11:35:29 2008 From: david at xn--kremla-iuad.se (David Andersson) Date: Sat, 17 May 2008 13:35:29 +0200 Subject: Glitch-Free PulseAudio in Rawhide In-Reply-To: <20080517101616.GA16071@tango.0pointer.de> References: <20080517101616.GA16071@tango.0pointer.de> Message-ID: <1211024129.3482.3.camel@localhost.localdomain> l?r 2008-05-17 klockan 12:16 +0200 skrev Lennart Poettering: > Heya! > > Since yesterday glitch-free PulseAudio is available in Rawhide, > breaking your sound setups. Hi. Downloaded pulseaudio and friends from koji this morning, and unless I comment out "load-module module-default-device-restore" in /etc/pulse/default.pa Pulseaudio bails out with a "E: module-default-device-restore.c: Assertion 'u' failed at modules/module-default-device-restore.c:161, function module_default_device_restore_LTX_pa__init(). Aborting." From mclasen at redhat.com Sat May 17 18:03:31 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Sat, 17 May 2008 14:03:31 -0400 Subject: Glitch-Free PulseAudio in Rawhide In-Reply-To: References: <20080517101616.GA16071@tango.0pointer.de> Message-ID: <1211047411.27042.0.camel@localhost.localdomain> On Sat, 2008-05-17 at 12:31 +0200, drago01 wrote: > On Sat, May 17, 2008 at 12:16 PM, Lennart Poettering > wrote: > > Heya! > > > > Since yesterday glitch-free PulseAudio is available in Rawhide, > > breaking your sound setups. > > > > Please make sure to read this mail I posted to the PA ML a few minutes back, > > especially those people who have HDA audio hw and want to play with this: > > > > https://tango.0pointer.de/pipermail/pulseaudio-discuss/2008-May/001837.html > > > > Lennart > > Can we get this patch into the rawhide kernel to make testing easier? > https://bugzilla.redhat.com/show_bug.cgi?id=446967 From cjdahlin at ncsu.edu Sat May 17 18:15:52 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Sat, 17 May 2008 14:15:52 -0400 Subject: Glitch-Free PulseAudio in Rawhide In-Reply-To: <20080517101616.GA16071@tango.0pointer.de> References: <20080517101616.GA16071@tango.0pointer.de> Message-ID: <482F20D8.7030801@ncsu.edu> Lennart Poettering wrote: > Heya! > > Since yesterday glitch-free PulseAudio is available in Rawhide, > breaking your sound setups. > > Please make sure to read this mail I posted to the PA ML a few minutes back, > especially those people who have HDA audio hw and want to play with this: > > https://tango.0pointer.de/pipermail/pulseaudio-discuss/2008-May/001837.html > > Lennart > > For those of us who, regrettably, haven't been following PA development as closely as we should, could you outline what "glitch-free" entails in concrete terms? --CJD From lmacken at redhat.com Sat May 17 18:23:12 2008 From: lmacken at redhat.com (Luke Macken) Date: Sat, 17 May 2008 14:23:12 -0400 Subject: Bodhi documentation for new packages In-Reply-To: References: <481F5F85.7080203@garden.org> <20080506224247.GA3372@x300> <482D9905.70000@garden.org> <20080517144216.GA4349@x300> Message-ID: <20080517182312.GA3172@x300.lan.matignonit.com> On Sat, May 17, 2008 at 05:46:50PM +0200, Thomas Moschny wrote: > 2008/5/17, Luke Macken : > >> There are no bugs that are related to any new package, so leave the "Bugs" > >> > >> field blank. In the future, the bug number for the Review Request bug > >> might be entered here for Bodhi to automatically close when it gets pushed > >> to the request update status. > > > > There's nothing stopping people from entering the review bug in now, and > > it's actually done quite frequently. I don't see any reason to not > > recommend doing this. > > In fact bodhi already automatically closes the review ticket when the > package arrives in at least one of the stable repositories. Right, but only when the review bug number is added to the update. luke From walters at verbum.org Sat May 17 18:26:57 2008 From: walters at verbum.org (Colin Walters) Date: Sat, 17 May 2008 14:26:57 -0400 Subject: Glitch-Free PulseAudio in Rawhide In-Reply-To: <482F20D8.7030801@ncsu.edu> References: <20080517101616.GA16071@tango.0pointer.de> <482F20D8.7030801@ncsu.edu> Message-ID: On Sat, May 17, 2008 at 2:15 PM, Casey Dahlin wrote: > > For those of us who, regrettably, haven't been following PA development as > closely as we should, could you outline what "glitch-free" entails in > concrete terms? http://0pointer.de/blog/projects/pulse-glitch-free.html From sundaram at fedoraproject.org Sat May 17 20:39:57 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 18 May 2008 02:09:57 +0530 Subject: Bodhi documentation for new packages In-Reply-To: <20080517182312.GA3172@x300.lan.matignonit.com> References: <481F5F85.7080203@garden.org> <20080506224247.GA3372@x300> <482D9905.70000@garden.org> <20080517144216.GA4349@x300> <20080517182312.GA3172@x300.lan.matignonit.com> Message-ID: <482F429D.3010402@fedoraproject.org> Luke Macken wrote: > On Sat, May 17, 2008 at 05:46:50PM +0200, Thomas Moschny wrote: >> 2008/5/17, Luke Macken : >>>> There are no bugs that are related to any new package, so leave the "Bugs" >>>> >>>> field blank. In the future, the bug number for the Review Request bug >>>> might be entered here for Bodhi to automatically close when it gets pushed >>>> to the request update status. >>> There's nothing stopping people from entering the review bug in now, and >>> it's actually done quite frequently. I don't see any reason to not >>> recommend doing this. >> In fact bodhi already automatically closes the review ticket when the >> package arrives in at least one of the stable repositories. > > Right, but only when the review bug number is added to the update. Why isn't this automatic? Rahul From jkeating at redhat.com Sat May 17 20:56:09 2008 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 17 May 2008 16:56:09 -0400 Subject: Bodhi documentation for new packages In-Reply-To: <482F429D.3010402@fedoraproject.org> References: <481F5F85.7080203@garden.org> <20080506224247.GA3372@x300> <482D9905.70000@garden.org> <20080517144216.GA4349@x300> <20080517182312.GA3172@x300.lan.matignonit.com> <482F429D.3010402@fedoraproject.org> Message-ID: <1211057769.4060.65.camel@localhost.localdomain> On Sun, 2008-05-18 at 02:09 +0530, Rahul Sundaram wrote: > >> In fact bodhi already automatically closes the review ticket when the > >> package arrives in at least one of the stable repositories. > > > > Right, but only when the review bug number is added to the update. > > Why isn't this automatic? Because Bodhi doesn't have ESP? Without the update submitter telling bodhi that this is a new package that has a review bug to close how is bodhi supposed to guess this, let alone guess what the review bug is, or that this particular update should close the review bug? Even more interesting considering that current guidelines are about getting the package in /rawhide/ and closing the bug when it's in /rawhide/ and currently we don't use bodhi for rawhide... -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Sat May 17 21:03:54 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 18 May 2008 02:33:54 +0530 Subject: Bodhi documentation for new packages In-Reply-To: <1211057769.4060.65.camel@localhost.localdomain> References: <481F5F85.7080203@garden.org> <20080506224247.GA3372@x300> <482D9905.70000@garden.org> <20080517144216.GA4349@x300> <20080517182312.GA3172@x300.lan.matignonit.com> <482F429D.3010402@fedoraproject.org> <1211057769.4060.65.camel@localhost.localdomain> Message-ID: <482F483A.4000301@fedoraproject.org> Jesse Keating wrote: > On Sun, 2008-05-18 at 02:09 +0530, Rahul Sundaram wrote: >>>> In fact bodhi already automatically closes the review ticket when the >>>> package arrives in at least one of the stable repositories. >>> Right, but only when the review bug number is added to the update. >> Why isn't this automatic? > > Because Bodhi doesn't have ESP? Without the update submitter telling > bodhi that this is a new package that has a review bug to close how is > bodhi supposed to guess this, let alone guess what the review bug is, or > that this particular update should close the review bug? Bodhi knows when it's a new package since package maintainers provide this information. pkgdb already knows a lot of information that can used too. Package review requests follow a standardized format. It should be possible to query bugzilla to get the bugzilla report number. It can do this when the package hits the non-rawhide branches if it hasn't been manually closed by the package submitter already. Rahul From mschwendt at gmail.com Sat May 17 21:28:14 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Sat, 17 May 2008 23:28:14 +0200 Subject: Bodhi documentation for new packages In-Reply-To: <482F483A.4000301@fedoraproject.org> References: <481F5F85.7080203@garden.org> <20080506224247.GA3372@x300> <482D9905.70000@garden.org> <20080517144216.GA4349@x300> <20080517182312.GA3172@x300.lan.matignonit.com> <482F429D.3010402@fedoraproject.org> <1211057769.4060.65.camel@localhost.localdomain> <482F483A.4000301@fedoraproject.org> Message-ID: <20080517232814.8c2e87f0.mschwendt@gmail.com> On Sun, 18 May 2008 02:33:54 +0530, Rahul Sundaram wrote: > Jesse Keating wrote: > > On Sun, 2008-05-18 at 02:09 +0530, Rahul Sundaram wrote: > >>>> In fact bodhi already automatically closes the review ticket when the > >>>> package arrives in at least one of the stable repositories. > >>> Right, but only when the review bug number is added to the update. > >> Why isn't this automatic? > > > > Because Bodhi doesn't have ESP? Without the update submitter telling > > bodhi that this is a new package that has a review bug to close how is > > bodhi supposed to guess this, let alone guess what the review bug is, or > > that this particular update should close the review bug? > > Bodhi knows when it's a new package since package maintainers provide > this information. pkgdb already knows a lot of information that can used > too. Package review requests follow a standardized format. It should be > possible to query bugzilla to get the bugzilla report number. It can do > this when the package hits the non-rawhide branches if it hasn't been > manually closed by the package submitter already. It would be an unimportant implementation detail. Better spend time on fixing the many bodhi bugs, such as lack of sorting (of comments, of updates, of pkg evrs). From sundaram at fedoraproject.org Sat May 17 21:38:37 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 18 May 2008 03:08:37 +0530 Subject: Bodhi documentation for new packages In-Reply-To: <20080517232814.8c2e87f0.mschwendt@gmail.com> References: <481F5F85.7080203@garden.org> <20080506224247.GA3372@x300> <482D9905.70000@garden.org> <20080517144216.GA4349@x300> <20080517182312.GA3172@x300.lan.matignonit.com> <482F429D.3010402@fedoraproject.org> <1211057769.4060.65.camel@localhost.localdomain> <482F483A.4000301@fedoraproject.org> <20080517232814.8c2e87f0.mschwendt@gmail.com> Message-ID: <482F505D.50401@fedoraproject.org> Michael Schwendt wrote: > On Sun, 18 May 2008 02:33:54 +0530, Rahul Sundaram wrote: > >> Jesse Keating wrote: >>> On Sun, 2008-05-18 at 02:09 +0530, Rahul Sundaram wrote: >>>>>> In fact bodhi already automatically closes the review ticket when the >>>>>> package arrives in at least one of the stable repositories. >>>>> Right, but only when the review bug number is added to the update. >>>> Why isn't this automatic? >>> Because Bodhi doesn't have ESP? Without the update submitter telling >>> bodhi that this is a new package that has a review bug to close how is >>> bodhi supposed to guess this, let alone guess what the review bug is, or >>> that this particular update should close the review bug? >> Bodhi knows when it's a new package since package maintainers provide >> this information. pkgdb already knows a lot of information that can used >> too. Package review requests follow a standardized format. It should be >> possible to query bugzilla to get the bugzilla report number. It can do >> this when the package hits the non-rawhide branches if it hasn't been >> manually closed by the package submitter already. > > It would be an unimportant implementation detail. Better spend time on > fixing the many bodhi bugs, such as lack of sorting (of comments, of > updates, of pkg evrs). Sure, it is not a either or thing however. Prioritizing other bugs or enhancements if fine by me. If you do want to implement it, I am just providing some ideas that does not involve "ESP". Rahul From wacker at octothorp.org Sat May 17 22:02:50 2008 From: wacker at octothorp.org (William F. Acker WB2FLW +1-303-722-7209) Date: Sat, 17 May 2008 16:02:50 -0600 (MDT) Subject: Looking for the latest version of asterisk-strip.sh Message-ID: Hi all, with the release of asterisk-1.6.0-0.12.beta7.1, it was discovered that we needed to strip the tarball again. However, the script doesn't seem to have been re-included in the SRPM. Does anyone know where I can find the one that includes the latest removals? I'd like to build beta9 since there's a good chance that it fixes some of the bugs that have been bugging me. TIA. Bill in Denver From vonbrand at inf.utfsm.cl Sat May 17 00:39:55 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Fri, 16 May 2008 20:39:55 -0400 Subject: X, Gnome broken Message-ID: <200805170039.m4H0dtYC010521@laptop13.inf.utfsm.cl> glibc-2.8.90-1.i686.rpm breaks X somehow. Needed to go back. gnome-session-2.23.1.1-1.fc10.i386.rpm crashes, I had to go back one here. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From vonbrand at inf.utfsm.cl Sat May 17 01:40:53 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Fri, 16 May 2008 21:40:53 -0400 Subject: I have a big mouth... In-Reply-To: <482DCBD2.2070205@gmail.com> References: <604aa7910805161029i1573ca51v11c144007c0254f3@mail.gmail.com> <482DCBD2.2070205@gmail.com> Message-ID: <200805170140.m4H1erxs015127@laptop13.inf.utfsm.cl> Suren Karapetyan wrote: > Jeff Spaleta wrote: > > http://www.informationweek.com/blog/main/archives/2008/05/hats_off_for_fe.html > > First comment in the comment section. Since i love flashing my board > > creds as much as possible. I want to make sure everyone else is aware > > of my attempts at sullying the Fedora Board's reputation. > > -jef I for one can't see any comments... > GREAT!!! > > > But what really upsets me, is the apparent reality that derived > > distributions based on Debian take Debian completely and utterly for > > granted. That has to stop. > > Liked this part the most. > Giving back is one of the main principles which drive FOSS. > A distro which is based on another one SHOULD give the work it does > back to the one it is based on. > A distro which uses a FOSS program SHOULD give back the patches it > creates to upstream. > If a distro manages to translate KDE it SHOULD commit the translations > upstream. > > Very close relationships with upstream is one of the main things which > makes me use Fedora (well at thirst it was bleeding edge software, but > it's just a result of following upstream closely). > And that's the main problem I have with FreeBSD. I don't like the > concept of a "base" packages, which have been forked years ago. > And also I don't like the idea of writing "our own grep", "our own > find", "our own date", ... > That's the way I thought when I was 12. I did't like using "other's" > software: I wanted to have "my own". > That's the way Microsoft did with OOXML. They did't want to use > "other's" standards, they wanted to have their own "standard". > And even more... They didn't want to use "other's" standard for > storing dates, they wanted to have their own "standard". > > PS: The last part seems to be off-topic :) If you look at the *BSD philosophy, for them GPLed stuff just isn't free enough. So, just like some sofware isn't free enough for Fedora's standards, they see themselves in the need to forego some stuff or write their own replacements. [Please, don't start a BSD vs GPL or some such flamewar over this] -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From pemboa at gmail.com Sat May 17 22:09:54 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Sat, 17 May 2008 17:09:54 -0500 Subject: I have a big mouth... In-Reply-To: <200805170140.m4H1erxs015127@laptop13.inf.utfsm.cl> References: <604aa7910805161029i1573ca51v11c144007c0254f3@mail.gmail.com> <482DCBD2.2070205@gmail.com> <200805170140.m4H1erxs015127@laptop13.inf.utfsm.cl> Message-ID: <16de708d0805171509o4064d065hdbf1fb13836d5fac@mail.gmail.com> On Fri, May 16, 2008 at 8:40 PM, Horst H. von Brand wrote: > Suren Karapetyan wrote: >> Jeff Spaleta wrote: >> > http://www.informationweek.com/blog/main/archives/2008/05/hats_off_for_fe.html >> > First comment in the comment section. Since i love flashing my board >> > creds as much as possible. I want to make sure everyone else is aware >> > of my attempts at sullying the Fedora Board's reputation. >> > -jef > > I for one can't see any comments... I do, Firefox2/WindowsServer2003 maybe its biased against Linux users. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From cra at WPI.EDU Sat May 17 23:13:26 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Sat, 17 May 2008 19:13:26 -0400 Subject: I have a big mouth... In-Reply-To: <16de708d0805171509o4064d065hdbf1fb13836d5fac@mail.gmail.com> References: <604aa7910805161029i1573ca51v11c144007c0254f3@mail.gmail.com> <482DCBD2.2070205@gmail.com> <200805170140.m4H1erxs015127@laptop13.inf.utfsm.cl> <16de708d0805171509o4064d065hdbf1fb13836d5fac@mail.gmail.com> Message-ID: <20080517231326.GA24901@angus.ind.WPI.EDU> On Sat, May 17, 2008 at 05:09:54PM -0500, Arthur Pemberton wrote: > On Fri, May 16, 2008 at 8:40 PM, Horst H. von Brand wrote: > > Suren Karapetyan wrote: > >> Jeff Spaleta wrote: > >> > http://www.informationweek.com/blog/main/archives/2008/05/hats_off_for_fe.html > >> > First comment in the comment section. Since i love flashing my board > >> > creds as much as possible. I want to make sure everyone else is aware > >> > of my attempts at sullying the Fedora Board's reputation. > >> > -jef > > > > I for one can't see any comments... > > I do, Firefox2/WindowsServer2003 maybe its biased against Linux users. It appears to work fine on MacOS X Safari 3.1.1 and FF 2.0.0.14. I tried User Agent Switcher with FF3 on F9, and it doesn't make a difference what user agent I try (IE7 Vista, NS 4.8 Vista, Opera 9.25 Vista)--it still doesn't show any comments section. So this doesn't appear to be a deliberate user agent-based bias. From bnocera at redhat.com Sat May 17 23:16:12 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Sun, 18 May 2008 00:16:12 +0100 Subject: I have a big mouth... In-Reply-To: <604aa7910805161029i1573ca51v11c144007c0254f3@mail.gmail.com> References: <604aa7910805161029i1573ca51v11c144007c0254f3@mail.gmail.com> Message-ID: <1211066172.3070.385.camel@cookie.hadess.net> On Fri, 2008-05-16 at 09:29 -0800, Jeff Spaleta wrote: > http://www.informationweek.com/blog/main/archives/2008/05/hats_off_for_fe.html > > First comment in the comment section. Since i love flashing my board > creds as much as possible. I want to make sure everyone else is aware > of my attempts at sullying the Fedora Board's reputation. Except that I don't agree. I wouldn't swap the Fedora/RH maintainers of the most critical parts of my system with their equivalents in most other distributions. FWIW hadess at debian.org still works... From bnocera at redhat.com Sun May 18 00:04:43 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Sun, 18 May 2008 01:04:43 +0100 Subject: NetworkManager: I want to believe, but... [was Re: F9 potential service network bug?] In-Reply-To: <20080517112856.GA18698@jadzia.bu.edu> References: <3da3b5b40805161502w62f372dseca0ab6310e44447@mail.gmail.com> <1210975852.6805.10.camel@localhost.localdomain> <3da3b5b40805161522i2300f1cdhb1fc7b074084873f@mail.gmail.com> <604aa7910805161527j6b193c6dj2af4248155d5cdaf@mail.gmail.com> <20080517112856.GA18698@jadzia.bu.edu> Message-ID: <1211069083.3070.392.camel@cookie.hadess.net> On Sat, 2008-05-17 at 07:28 -0400, Matthew Miller wrote: > On Fri, May 16, 2008 at 02:27:00PM -0800, Jeff Spaleta wrote: > > NM doesn't handle all usage cases yet, which is why the legacy network > > stack is still available for people who need it. > > So, the FeatureMoreNetworkManager wiki page says that NetworkManager is > supposed to have new "Chuck Norris" features like supporting static IP > addresses. It didn't work for me on a fresh F9 install, which then was a > headache etc etc. (Even sytem-config-network had the right info, yet > interface kept coming up dhcp.) So, as the Feature page says, it sure would > be an advantage if it worked. > > Except, uh, what advantage does this bring me once it's set up? Why have a > daemon and applet and dbus infrastructure monitoring something which by > definition *is not going to change*? > > I'm not trying to troll -- I just don't get it. It seems like there's > nothing in the "plus" column here. What am I missing? The pluses are that: - it should be able to boot up faster (note the should) - it informs applications that you're connected to the network (say, you unplug the network, the router dies, or the driver for your network card drops you off the network) - and finally, it will allow routing over multiple connections in the future (so static wired, and wireless routed over the wired, or all the wired routed over a WWAN in case your internet connection breaks). From bnocera at redhat.com Sun May 18 00:05:12 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Sun, 18 May 2008 01:05:12 +0100 Subject: X, Gnome broken In-Reply-To: <200805170039.m4H0dtYC010521@laptop13.inf.utfsm.cl> References: <200805170039.m4H0dtYC010521@laptop13.inf.utfsm.cl> Message-ID: <1211069112.3070.394.camel@cookie.hadess.net> On Fri, 2008-05-16 at 20:39 -0400, Horst H. von Brand wrote: > glibc-2.8.90-1.i686.rpm breaks X somehow. Needed to go back. > gnome-session-2.23.1.1-1.fc10.i386.rpm crashes, I had to go back one here. File bugs instead. From rodd at clarkson.id.au Sun May 18 00:06:24 2008 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Sun, 18 May 2008 10:06:24 +1000 Subject: Glitch-Free PulseAudio in Rawhide In-Reply-To: <20080517101616.GA16071@tango.0pointer.de> References: <20080517101616.GA16071@tango.0pointer.de> Message-ID: <1211069184.14575.2.camel@localhost.localdomain> On Sat, 2008-05-17 at 12:16 +0200, Lennart Poettering wrote: > Heya! > > Since yesterday glitch-free PulseAudio is available in Rawhide, > breaking your sound setups. It's been over 12 hours and nobody's pointed out the inherent humor in this comment. If it's 'glitch-free' then why has it broken? ;-] he he he Sounds like glitch free audio has some glitches. rofl. R. -- "It's a fine line between denial and faith. It's much better on my side" From darrellpf at gmail.com Sun May 18 00:20:45 2008 From: darrellpf at gmail.com (darrell pfeifer) Date: Sat, 17 May 2008 17:20:45 -0700 Subject: Glitch-Free PulseAudio in Rawhide In-Reply-To: <1211069184.14575.2.camel@localhost.localdomain> References: <20080517101616.GA16071@tango.0pointer.de> <1211069184.14575.2.camel@localhost.localdomain> Message-ID: On Sat, May 17, 2008 at 5:06 PM, Rodd Clarkson wrote: > On Sat, 2008-05-17 at 12:16 +0200, Lennart Poettering wrote: > > Heya! > > > > Since yesterday glitch-free PulseAudio is available in Rawhide, > > breaking your sound setups. > > It's been over 12 hours and nobody's pointed out the inherent humor in > this comment. > > If it's 'glitch-free' then why has it broken? ;-] he he he Sounds like > glitch free audio has some glitches. rofl. > > > I'm not sure I understand the rationale of purposely breaking sound for most people in rawhide. While the fedora kernel guys are speedy, it could be a while before a kernel with the patch appears. I know rawhide people take their chances. Still, I would have thought waiting a bit for the kernel to sync up with the patch would have been a more prudent option. darrell -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundaram at fedoraproject.org Sun May 18 00:41:57 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 18 May 2008 06:11:57 +0530 Subject: Glitch-Free PulseAudio in Rawhide In-Reply-To: References: <20080517101616.GA16071@tango.0pointer.de> <1211069184.14575.2.camel@localhost.localdomain> Message-ID: <482F7B55.9080605@fedoraproject.org> darrell pfeifer wrote: > I'm not sure I understand the rationale of purposely breaking sound for > most people in rawhide. While the fedora kernel guys are speedy, it > could be a while before a kernel with the patch appears. > > I know rawhide people take their chances. Still, I would have thought > waiting a bit for the kernel to sync up with the patch would have been a > more prudent option. I would gladly sync my data to a non-development version of Fedora and continue to use rawhide on my main box (and presumably file more bug reports) if such things were better coordinated. I still do something similar but usually more to the end of the development cycle ~ last couple of months or so. This isn't just for getting better feedback from testers but also making rawhide a better development environment. The recent yum or glibc issues in rawhide would have affected a lot of developers too. We haven't had a shabby job of this at all but we could certainly do it better. Rahul From kagesenshi.87 at gmail.com Sun May 18 03:27:52 2008 From: kagesenshi.87 at gmail.com (Izhar Firdaus) Date: Sun, 18 May 2008 11:27:52 +0800 Subject: passwd does not work after f8 -> f9 upgrade In-Reply-To: <200805171919.20791.jaroslav@aster.pl> References: <200805171818.26894.jaroslav@aster.pl> <200805171919.20791.jaroslav@aster.pl> Message-ID: On Sun, May 18, 2008 at 1:19 AM, Jaros?aw G?rny wrote: > Hi, > > Saturday 17 of May 2008 18:54:57 Izhar Firdaus napisa?(a): >> On Sun, May 18, 2008 at 12:18 AM, Jaros?aw G?rny wrote: >> > Hi, >> > I've searched BZ, but not found anything similar. >> > Couple of days ago I've upgraded to f9 with plain old "yum update". The >> > process went smoothly, but now I'm not able to use passwd. Any try to >> > change password (directly as a user, or as a root) fails: >> > > (...) > >> sounds like a broken file to me, >> >> try: >> >> rpm -V cracklib-dicts > > Yes, You're right. That was the case. Reinstalling cracklib-dicts solved this. > >> >> you may want to run package-cleanup --problems just in case somehow >> happened missing dependencies .. >> > > no, no dependency problems detected. > I wonder why this files were corrupted? No idea myself, broken packages happens several times a year with me .. So i make it a habit to verify my installed RPMs before concluding something is a bug ... I'm guessing it might be interrupted transactions, harddisk problem, some other apps did modification and break stuff (eg: the daily prelink) .. or ..a hidden bug somewhere in rpm or yum which couldn't be easily reproduced ... > Anyway, thanks a lot! np -- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? http://fedoraproject.org/wiki/MohdIzharFirdaus http://blog.kagesenshi.org 92C2 B295 B40B B3DC 6866 5011 5BD2 584A 8A5D 7331 From kevin.kofler at chello.at Sun May 18 05:44:54 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 18 May 2008 05:44:54 +0000 (UTC) Subject: Glitch-Free PulseAudio in Rawhide References: <20080517101616.GA16071@tango.0pointer.de> Message-ID: Lennart Poettering 0pointer.de> writes: > Since yesterday glitch-free PulseAudio is available in Rawhide, Too bad what we actually need is BUG-FREE PulseAudio. ;-) (And no, I'm not just talking about the regressions, but about all the longstanding bugs: http://bugz.fedoraproject.org/pulseaudio .) Kevin Kofler From cjdahlin at ncsu.edu Sun May 18 06:15:05 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Sun, 18 May 2008 02:15:05 -0400 Subject: Glitch-Free PulseAudio in Rawhide In-Reply-To: References: <20080517101616.GA16071@tango.0pointer.de> <482F20D8.7030801@ncsu.edu> Message-ID: <482FC969.20409@ncsu.edu> Colin Walters wrote: > On Sat, May 17, 2008 at 2:15 PM, Casey Dahlin wrote: > >> For those of us who, regrettably, haven't been following PA development as >> closely as we should, could you outline what "glitch-free" entails in >> concrete terms? >> > > http://0pointer.de/blog/projects/pulse-glitch-free.html > > Ahh. Looks interesting :) --CJD From surenkarapetyan at gmail.com Sun May 18 06:40:25 2008 From: surenkarapetyan at gmail.com (Suren Karapetyan) Date: Sun, 18 May 2008 11:40:25 +0500 Subject: I have a big mouth... In-Reply-To: <20080517231326.GA24901@angus.ind.WPI.EDU> References: <604aa7910805161029i1573ca51v11c144007c0254f3@mail.gmail.com> <482DCBD2.2070205@gmail.com> <200805170140.m4H1erxs015127@laptop13.inf.utfsm.cl> <16de708d0805171509o4064d065hdbf1fb13836d5fac@mail.gmail.com> <20080517231326.GA24901@angus.ind.WPI.EDU> Message-ID: <482FCF59.3070404@gmail.com> Chuck Anderson wrote: > On Sat, May 17, 2008 at 05:09:54PM -0500, Arthur Pemberton wrote: >> On Fri, May 16, 2008 at 8:40 PM, Horst H. von Brand wrote: >>> Suren Karapetyan wrote: >>>> Jeff Spaleta wrote: >>>>> http://www.informationweek.com/blog/main/archives/2008/05/hats_off_for_fe.html >>>>> First comment in the comment section. Since i love flashing my board >>>>> creds as much as possible. I want to make sure everyone else is aware >>>>> of my attempts at sullying the Fedora Board's reputation. >>>>> -jef >>> I for one can't see any comments... >> I do, Firefox2/WindowsServer2003 maybe its biased against Linux users. > > It appears to work fine on MacOS X Safari 3.1.1 and FF 2.0.0.14. > > I tried User Agent Switcher with FF3 on F9, and it doesn't make a > difference what user agent I try (IE7 Vista, NS 4.8 Vista, Opera 9.25 > Vista)--it still doesn't show any comments section. So this doesn't > appear to be a deliberate user agent-based bias. > It has nothing to do with the browser You use. It's just server-related problem. Not quite sure but looks like comments are loaded from here: http://www.informationweek.com/btgcommunity/communityjs/780;jsessionid=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX?forum=13&key=33669&cmpJiveUser= And sometimes it just starts giving HTTP 500s HTTP Status 500 - type Exception report message description The server encountered an internal error () that prevented it from fulfilling this request. exception java.lang.NullPointerException com.jivesoftware.forum.proxy.ForumFactoryProxy.getForumThread(ForumFactoryProxy.java:167) com.jivesoftware.forum.everywhere.CommunityEverywhereServlet.loadProperties(CommunityEverywhereServlet.java:229) com.jivesoftware.forum.everywhere.CommunityEverywhereServlet.doGet(CommunityEverywhereServlet.java:70) javax.servlet.http.HttpServlet.service(HttpServlet.java:689) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) com.opensymphony.webwork.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:189) com.jivesoftware.base.action.util.JiveFilterDispatcher.doFilter(JiveFilterDispatcher.java:54) com.jivesoftware.base.util.webwork.JiveActionContextCleanUp.doFilter(JiveActionContextCleanUp.java:63) note The full stack trace of the root cause is available in the Apache Tomcat/5.5.20 logs. Apache Tomcat/5.5.20 Looks like some sort of load-balancing problem (one of servers dead :), document not synced) So don't worry and be happy :) From kanarip at kanarip.com Sun May 18 09:17:29 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 18 May 2008 11:17:29 +0200 Subject: Recomposing with generic-logos Message-ID: <482FF429.3000005@kanarip.com> Hello, I'm recomposing Fedora without fedora-logos, and instead using the generic-logos package, in order to get de-branded installation media (so that others can re-brand Fedora). The result shows[1], while tty3 shows[2]; it seems there's no fonts loaded -or they cannot be found for some reason. The requirements for fedora-logos and generic-logos however are similar, which leads me to conclude everything appropriate /is/ in fact being pulled in a transaction set. I'm wondering what else may be going wrong. I was thinking this may be caused by different %postinstall scripts for the fedora-logos and generic-logos packages[3], but I'm not sure it is. Then, nim-nim mentioned on #fedora-devel it could have to do with fonts packages. I composed the DVD with full debug logging on, so it's rather large[4] (and bloated -18MB). I've grepped on font to get anything related to fonts[5] (~352K). Could someone give me a push in the right direction? Thank you in advance ;-) Kind regards, Jeroen van Meeuwen -kanarip [1] http://kanarip.fedorapeople.org/generic-logos-compose.png [2] http://kanarip.fedorapeople.org/generic-logos-compose-vty3.png [3] http://fpaste.org/paste/2227 [4] http://kanarip.fedorapeople.org/generic-logos-compose-debug.log [5] http://kanarip.fedorapeople.org/generic-logos-compose-debug-fonts.log From rawhide at fedoraproject.org Sun May 18 09:57:57 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Sun, 18 May 2008 09:57:57 +0000 (UTC) Subject: rawhide report: 20080518 changes Message-ID: <20080518095757.2532C209D24@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080517/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080518/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package notification-daemon-engine-nodoka The Nodoka theme engine for the notification daemon New package e_dbus Wrappers around dbus for EFL based applications New package vegastrike-music Music for Vega Strike New package epsilon Small, display independent, and quick thumbnailing library Updated Packages: python-twyt-0.8.5-1.fc10 ------------------------ * Sun May 18 18:00:00 2008 Andy Price - 0.8.5-1 - Updated to 0.8.5 nettle-1.15-5.fc10 ------------------ * Thu Apr 10 18:00:00 2008 Ian Weller 1.15-5 - Moved static lib to -static anyremote-4.4-1.fc9 ------------------- control-center-2.23.1-4.fc10 ---------------------------- * Sat May 17 18:00:00 2008 Matthias Clasen - 2.23.1-4 - Support notication themes in the appearance capplet pidgin-2.4.2-1.fc10 ------------------- * Sat May 17 18:00:00 2008 Stu Tomlinson 2.4.2-1 - 2.4.2 freeradius-2.0.3-3.fc9 ---------------------- * Fri May 16 18:00:00 2008 - 2.0.3-3 - # Temporary fix for bug #446864, turn off optimization * Fri Apr 18 18:00:00 2008 John Dennis - 2.0.3-2 - remove support for radrelay, it's different now - turn off default inclusion of SQL config files in radiusd.conf since SQL is an optional RPM install - remove mssql config files * Thu Apr 17 18:00:00 2008 John Dennis - 2.0.3-1 - Upgrade to current upstream 2.0.3 release - Many thanks to Enrico Scholz for his spec file suggestions incorporated here - Resolve: bug #438665: Contains files owned by buildsystem - Add dialupadmin-mysql, dialupadmin-postgresql, dialupadmin-ldap subpackages to further partition external dependencies. - Clean up some unnecessary requires dependencies - Add versioned requires between subpackages rkhunter-1.3.2-3.fc10 --------------------- * Mon Apr 28 18:00:00 2008 Kevin Fenzi - 1.3.2-3 - Change cron to run after prelink - bug #438622 firefox-3.0-0.63.cvs20080516.fc10 --------------------------------- * Wed Apr 16 18:00:00 2008 Christopher Aillon 3.0-0.63 - Update to latest trunk (2008-05-16) * Wed Apr 16 18:00:00 2008 Christopher Aillon 3.0-0.61 - Update to latest trunk (2008-04-16) * Mon Apr 14 18:00:00 2008 Christopher Aillon 3.0-0.60 - Update to latest trunk (2008-04-14) snake-0.11-0.4.fc9 ------------------ * Wed Apr 16 18:00:00 2008 James Laska 0.11-0.4 - ticket#13 - snake-install-tui will politely display "No boot images found" - ticket#43 - snake-install-tui won't choke on a mal-formed .treeinfo - ticket#49 - snake/uri.py uses virtinst ImageFetcher code and will perform nfs [u]mounts as needed - ticket#32 - fixed snake/log such that any verbosity settings apply to the root logger * Wed Mar 26 18:00:00 2008 James Laska 0.11-0.3 - ticket#50 - Updated include release number in tarball name flashrom-0-0.9.20080517svn3332.fc10 ----------------------------------- * Sat May 17 18:00:00 2008 Peter Lemenkov 0-0.9.20080517svn3332 - Fixed %patch0 * Sat May 17 18:00:00 2008 Peter Lemenkov 0-0.8.20080517svn3332 - Support Pm49FL004/2 Block Locking Registers - Add support for the Atmel AT25DF321 SPI flash - Lots of new SST flash chip IDs - Add lots of ATMEL SPI flash chips - Add SST39VF512, SST39VF010, SST39VF040 support - Add ICH9 detection to flashrom - Support for the Winbond W39V080FA series of chips - Support for flashing on the Kontron 986LCD-M board - Add board_enable for Artec Group DBE61 and DBE62 fedora-package-config-apt-9.89-1 -------------------------------- * Sat May 17 18:00:00 2008 Axel Thimm - 9.89-1 - Update sources. linux-igd-1.0-6.fc10 -------------------- * Sat May 17 18:00:00 2008 Masahiro Hasegawa - 1.0-6 - Fix dependencies exempi-2.0.1-1.fc10 ------------------- * Sat May 17 18:00:00 2008 Deji Akingunola - 2.0.1-1 - Update to 2.0.1 kdesdk-4.0.72-2.fc10 -------------------- * Fri May 16 18:00:00 2008 Rex Dieter 4.0.72-2 - %description: +kate vegastrike-data-0.5.0-3 ----------------------- * Sat May 17 18:00:00 2008 Hans de Goede 0.5.0-3 - Remove playlist patch, the license issues around the songs which the patch removed from the playlist, have been solved blobAndConquer-0.93-2.fc10 -------------------------- * Sat May 17 18:00:00 2008 Hans de Goede 0.93-2 - Fix only the last line of in between levels cutscenes text showing (449295) cairo-dock-1.5.5.4-5.svn990_trunk.fc10 -------------------------------------- python-urlgrabber-3.0.0-8.fc10 ------------------------------ * Sun May 18 18:00:00 2008 James Antill 3.0.0-8 - Tweak progress output so it's hopefully less confusing - Add dynamic resizing ability to progress bar - Resolves: bug#437197 qosmic-1.3.2-1.fc10 ------------------- * Thu Apr 10 18:00:00 2008 Ian Weller 1.3.2-1 - Updated upstream php-pear-Net-FTP-1.3.6-1.fc10 ----------------------------- * Thu May 8 18:00:00 2008 Remi Collet 1.3.6-1 - new version boinc-client-5.10.45-14.20080315svn.fc10 ---------------------------------------- perl-Apache-DBI-1.07-1.fc10 --------------------------- * Sat May 17 18:00:00 2008 Remi Collet 1.07-1 - update to 1.07 postgresql-8.3.1-5.fc10 ----------------------- * Sat May 17 18:00:00 2008 Tom Lane 8.3.1-5 - rebuild because of buildsystem hiccup * Sat May 17 18:00:00 2008 Tom Lane 8.3.1-4 - Enable LDAP support Resolves: #445315 - Use -Wl,--as-needed to suppress bogus dependencies for libraries that are really only needed by some of the subpackages nautilus-actions-1.4.1-4.fc10 ----------------------------- * Sat May 17 18:00:00 2008 Deji Akingunola - 1.4.1-4 - Fix the nautilus-extension directory kernel-2.6.26-0.13.rc2.git5.fc10 -------------------------------- * Fri May 16 18:00:00 2008 Dave Jones - Enable CONFIG_SND_SERIAL_U16550 * Fri May 16 18:00:00 2008 Dave Jones - 2.6.26-rc2-git5 * Thu May 15 18:00:00 2008 Eric Sandeen - ext3/4: fix uninitialized bs in ext3/4_xattr_set_handle() * Wed May 14 18:00:00 2008 Eric Paris - fix may sleep in allocation for previous deffered context patch - replace selinux specific knowledge of ioctls with a generic ioctl implementation * Mon May 12 18:00:00 2008 Kyle McMartin - Linux 2.6.25.3 * Fri May 9 18:00:00 2008 John W. Linville 2.6.25.2-7 - Regroup wireless patches as prep for 2.6.26 and F10 cycles * Fri May 9 18:00:00 2008 Eric Paris - support deffered context validation in selinux. aka rpm can lay down illegal labels. (won't upstream until .27 opens) beagle-0.3.7-4.fc10 ------------------- * Sat May 17 18:00:00 2008 Adel Gadllah - 0.3.7-4 - Backport buildfix from trunk (r4737) * Sat May 17 18:00:00 2008 Adel Gadllah - 0.3.7-3 - Fix firefox extension installation terminus-font-4.26-2.fc10 ------------------------- * Sun May 18 18:00:00 2008 Hans Ulrich Niedermann - 4.26-2 - Update README.fedora for console fonts with answers. - Make sure scriptlets never fail. - Use -f option with fc-cache. - Remove dependency on fontconfig. * Thu May 1 18:00:00 2008 Hans Ulrich Niedermann - 4.26-1 - Upstream release 4.26: - full set of greek characters - about 50 small fixes and (hopefully) improvements. - New BuildRoot tag in spec file. - Ship new font files in packages. - Ship README on console font encodings. kde-settings-4.0-23.fc9 ----------------------- * Fri May 16 18:00:00 2008 Rex Dieter 4.0-23 - don't set XDG_CONFIG_DIRS (#249109) drawtiming-0.6.2-3.fc10 ----------------------- gdal-1.5.1-6.fc9 ---------------- * Wed Apr 16 18:00:00 2008 Balint Cristian - 1.5.1-6 - disable fortify source, it crash gdal for now. Broken deps for i386 ---------------------------------------------------------- LabPlot-1.5.1.6-4.fc8.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libMagick.so.10 dx-4.4.4-6.fc9.i386 requires libWand.so.10 dx-4.4.4-6.fc9.i386 requires libMagick.so.10 dx-libs-4.4.4-6.fc9.i386 requires libWand.so.10 dx-libs-4.4.4-6.fc9.i386 requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-python-0.0.4-3.fc9.i386 requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.i386 requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-1.2.so.11 kismet-extras-0.0.2007.10.R1-3.fc9.i386 requires libMagick.so.10 koffice-karbon-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-karbon-1.6.3-15.fc9.i386 requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libMagick.so.10 nip2-7.14.1-1.fc9.i386 requires libWand.so.10 nip2-7.14.1-1.fc9.i386 requires libMagick.so.10 1:openoffice.org-presentation-minimizer-3.0.0-0.0.12.1.fc10.i386 requires openoffice.org-base-impress = 1:3.0.0-0.0.12.1.fc10 1:openoffice.org-presenter-screen-3.0.0-0.0.12.1.fc10.i386 requires openoffice.org-base-impress = 1:3.0.0-0.0.12.1.fc10 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) psiconv-0.9.8-1.fc8.i386 requires libWand.so.10 psiconv-0.9.8-1.fc8.i386 requires libMagick.so.10 q-7.10-3.fc9.i386 requires libMagick.so.10 qgis-0.9.1-5.fc9.i386 requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.i386 requires libgeos.so.2 sunbird-0.8-3.fc9.i386 requires libhunspell.so.1 thunderbird-lightning-0.8-3.fc9.i386 requires libhunspell.so.1 torcs-1.3.0-6.fc9.i386 requires libplibssgaux.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibssg.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibsl.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibsm.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibsg.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibul.so.1.8.4 totem-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 totem-mozplugin-2.23.2-2.fc9.i386 requires libtotem-plparser-mini.so.10 totem-mozplugin-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 totem-nautilus-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 vips-7.14.1-1.fc9.i386 requires libWand.so.10 vips-7.14.1-1.fc9.i386 requires libMagick.so.10 vips-python-7.14.1-1.fc9.i386 requires libWand.so.10 vips-python-7.14.1-1.fc9.i386 requires libMagick.so.10 vips-tools-7.14.1-1.fc9.i386 requires libWand.so.10 vips-tools-7.14.1-1.fc9.i386 requires libMagick.so.10 Broken deps for x86_64 ---------------------------------------------------------- LabPlot-1.5.1.6-4.fc8.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libMagick.so.10 LabPlot-1.5.1.6-4.fc8.x86_64 requires libMagick++.so.10()(64bit) LabPlot-1.5.1.6-4.fc8.x86_64 requires libMagick.so.10()(64bit) LabPlot-1.5.1.6-4.fc8.x86_64 requires libWand.so.10()(64bit) dx-4.4.4-6.fc9.x86_64 requires libMagick.so.10()(64bit) dx-4.4.4-6.fc9.x86_64 requires libWand.so.10()(64bit) dx-libs-4.4.4-6.fc9.i386 requires libWand.so.10 dx-libs-4.4.4-6.fc9.i386 requires libMagick.so.10 dx-libs-4.4.4-6.fc9.x86_64 requires libMagick.so.10()(64bit) dx-libs-4.4.4-6.fc9.x86_64 requires libWand.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libWand.so.10()(64bit) evolution-python-0.0.4-3.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx kismet-extras-0.0.2007.10.R1-3.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.x86_64 requires libWand.so.10()(64bit) koffice-libs-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.x86_64 requires libWand.so.10()(64bit) nip2-7.14.1-1.fc9.x86_64 requires libMagick.so.10()(64bit) nip2-7.14.1-1.fc9.x86_64 requires libWand.so.10()(64bit) 1:openoffice.org-presentation-minimizer-3.0.0-0.0.12.1.fc10.x86_64 requires openoffice.org-base-impress = 1:3.0.0-0.0.12.1.fc10 1:openoffice.org-presenter-screen-3.0.0-0.0.12.1.fc10.x86_64 requires openoffice.org-base-impress = 1:3.0.0-0.0.12.1.fc10 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) psiconv-0.9.8-1.fc8.i386 requires libWand.so.10 psiconv-0.9.8-1.fc8.i386 requires libMagick.so.10 psiconv-0.9.8-1.fc8.x86_64 requires libWand.so.10()(64bit) psiconv-0.9.8-1.fc8.x86_64 requires libMagick.so.10()(64bit) q-7.10-3.fc9.i386 requires libMagick.so.10 qgis-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) sunbird-0.8-3.fc9.x86_64 requires libhunspell.so.1()(64bit) thunderbird-lightning-0.8-3.fc9.x86_64 requires libhunspell.so.1()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibsg.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibul.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibssgaux.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibsm.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibssg.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibsl.so.1.8.4()(64bit) totem-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 totem-2.23.2-2.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.x86_64 requires libtotem-plparser-mini.so.10()(64bit) totem-nautilus-2.23.2-2.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) vips-7.14.1-1.fc9.i386 requires libWand.so.10 vips-7.14.1-1.fc9.i386 requires libMagick.so.10 vips-7.14.1-1.fc9.x86_64 requires libMagick.so.10()(64bit) vips-7.14.1-1.fc9.x86_64 requires libWand.so.10()(64bit) vips-python-7.14.1-1.fc9.x86_64 requires libMagick.so.10()(64bit) vips-python-7.14.1-1.fc9.x86_64 requires libWand.so.10()(64bit) vips-tools-7.14.1-1.fc9.x86_64 requires libMagick.so.10()(64bit) vips-tools-7.14.1-1.fc9.x86_64 requires libWand.so.10()(64bit) Broken deps for ppc ---------------------------------------------------------- LabPlot-1.5.1.6-4.fc8.ppc requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.ppc requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.ppc requires libMagick.so.10 dx-4.4.4-6.fc9.ppc requires libWand.so.10 dx-4.4.4-6.fc9.ppc requires libMagick.so.10 dx-libs-4.4.4-6.fc9.ppc requires libWand.so.10 dx-libs-4.4.4-6.fc9.ppc requires libMagick.so.10 dx-libs-4.4.4-6.fc9.ppc64 requires libMagick.so.10()(64bit) dx-libs-4.4.4-6.fc9.ppc64 requires libWand.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.ppc requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.ppc requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-python-0.0.4-3.fc9.ppc requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.ppc requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-1.2.so.11 kismet-extras-0.0.2007.10.R1-3.fc9.ppc requires libMagick.so.10 koffice-karbon-1.6.3-15.fc9.ppc requires libWand.so.10 koffice-karbon-1.6.3-15.fc9.ppc requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.ppc requires libWand.so.10 koffice-libs-1.6.3-15.fc9.ppc requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) nip2-7.14.1-1.fc9.ppc requires libWand.so.10 nip2-7.14.1-1.fc9.ppc requires libMagick.so.10 1:openoffice.org-presentation-minimizer-3.0.0-0.0.12.1.fc10.ppc requires openoffice.org-base-impress = 1:3.0.0-0.0.12.1.fc10 1:openoffice.org-presenter-screen-3.0.0-0.0.12.1.fc10.ppc requires openoffice.org-base-impress = 1:3.0.0-0.0.12.1.fc10 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) psiconv-0.9.8-1.fc8.ppc requires libWand.so.10 psiconv-0.9.8-1.fc8.ppc requires libMagick.so.10 psiconv-0.9.8-1.fc8.ppc64 requires libWand.so.10()(64bit) psiconv-0.9.8-1.fc8.ppc64 requires libMagick.so.10()(64bit) q-7.10-3.fc9.ppc requires libMagick.so.10 q-7.10-3.fc9.ppc64 requires libMagick.so.10()(64bit) qgis-0.9.1-5.fc9.ppc requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.ppc requires libgeos.so.2 sunbird-0.8-3.fc9.ppc requires libhunspell.so.1 thunderbird-lightning-0.8-3.fc9.ppc requires libhunspell.so.1 torcs-1.3.0-6.fc9.ppc requires libplibssgaux.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibssg.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibsl.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibsm.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibsg.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibul.so.1.8.4 totem-2.23.2-2.fc9.ppc requires libtotem-plparser.so.10 totem-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.ppc requires libtotem-plparser-mini.so.10 totem-mozplugin-2.23.2-2.fc9.ppc requires libtotem-plparser.so.10 totem-nautilus-2.23.2-2.fc9.ppc requires libtotem-plparser.so.10 vips-7.14.1-1.fc9.ppc requires libWand.so.10 vips-7.14.1-1.fc9.ppc requires libMagick.so.10 vips-7.14.1-1.fc9.ppc64 requires libMagick.so.10()(64bit) vips-7.14.1-1.fc9.ppc64 requires libWand.so.10()(64bit) vips-python-7.14.1-1.fc9.ppc requires libWand.so.10 vips-python-7.14.1-1.fc9.ppc requires libMagick.so.10 vips-tools-7.14.1-1.fc9.ppc requires libWand.so.10 vips-tools-7.14.1-1.fc9.ppc requires libMagick.so.10 Broken deps for ppc64 ---------------------------------------------------------- dx-4.4.4-6.fc9.ppc64 requires libMagick.so.10()(64bit) dx-4.4.4-6.fc9.ppc64 requires libWand.so.10()(64bit) dx-libs-4.4.4-6.fc9.ppc64 requires libMagick.so.10()(64bit) dx-libs-4.4.4-6.fc9.ppc64 requires libWand.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-python-0.0.4-3.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) kismet-extras-0.0.2007.10.R1-3.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot nip2-7.14.1-1.fc9.ppc64 requires libMagick.so.10()(64bit) nip2-7.14.1-1.fc9.ppc64 requires libWand.so.10()(64bit) 1:openoffice.org-presentation-minimizer-3.0.0-0.0.12.1.fc10.ppc64 requires openoffice.org-base-impress = 1:3.0.0-0.0.12.1.fc10 1:openoffice.org-presenter-screen-3.0.0-0.0.12.1.fc10.ppc64 requires openoffice.org-base-impress = 1:3.0.0-0.0.12.1.fc10 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot psiconv-0.9.8-1.fc8.ppc64 requires libWand.so.10()(64bit) psiconv-0.9.8-1.fc8.ppc64 requires libMagick.so.10()(64bit) q-7.10-3.fc9.ppc64 requires libMagick.so.10()(64bit) qgis-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) sunbird-0.8-3.fc9.ppc64 requires libhunspell.so.1()(64bit) thunderbird-lightning-0.8-3.fc9.ppc64 requires libhunspell.so.1()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibsg.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibul.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibsm.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibssgaux.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibssg.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibsl.so.1.8.4()(64bit) totem-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.ppc64 requires libtotem-plparser-mini.so.10()(64bit) totem-nautilus-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) vips-7.14.1-1.fc9.ppc64 requires libMagick.so.10()(64bit) vips-7.14.1-1.fc9.ppc64 requires libWand.so.10()(64bit) vips-python-7.14.1-1.fc9.ppc64 requires libMagick.so.10()(64bit) vips-python-7.14.1-1.fc9.ppc64 requires libWand.so.10()(64bit) vips-tools-7.14.1-1.fc9.ppc64 requires libMagick.so.10()(64bit) vips-tools-7.14.1-1.fc9.ppc64 requires libWand.so.10()(64bit) From email.ahmedkamal at googlemail.com Sun May 18 10:33:41 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Sun, 18 May 2008 13:33:41 +0300 Subject: F9 Xen dom0 hangs at: Relinquishing VGA console Message-ID: <3da3b5b40805180333j52de2419gf15340d9571ec257@mail.gmail.com> So, it totally does not boot, and hangs everytime with the message in the subject. Is there any tricks to boot that kernel ? Is there any testing/development kernel out there I can use to boot Xen dom0 on F9 ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.mailhot at laposte.net Sun May 18 11:40:34 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 18 May 2008 13:40:34 +0200 (CEST) Subject: GNU Unifont update In-Reply-To: <482BB8E3.9060402@gmail.com> References: <482BB8E3.9060402@gmail.com> Message-ID: <57687.81.64.151.204.1211110834.squirrel@rousalka.dyndns.org> Le Jeu 15 mai 2008 06:15, Qianqian Fang a ?crit : Hi, > I think this will probably be interesting to the people in this list. > > With the blessing from Roman Czyborra, the former maintainer of > GNU Unifont, Paul Hardy, a volunteer developer from CA, is now > officially maintaining this widely used dual-width bitmap font. ... > http://unifoundry.com/unifont.html > > It would be nice to see this extensively updated GNU Unifont > pushed through all branches for Fedora. I will keep you posted > or send Paul directly here to announce his release. Does this mean the WQY fonts are deprecated now and should be replaced with GNU unifont ? If that's the case you need to start a rename procedure and modify the comps files of branches unifont will be pushed to. If that's not the case, and WQY and GNU Unifont fonts will exist in parallel from now on, we need to find a packager for GNU unifont. I'd say the current WQY packager is best placed to take unifont up :p Regards, -- Nicolas Mailhot From pasik at iki.fi Sun May 18 11:49:28 2008 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Sun, 18 May 2008 14:49:28 +0300 Subject: F9 Xen dom0 hangs at: Relinquishing VGA console In-Reply-To: <3da3b5b40805180333j52de2419gf15340d9571ec257@mail.gmail.com> References: <3da3b5b40805180333j52de2419gf15340d9571ec257@mail.gmail.com> Message-ID: <20080518114928.GE4455@edu.joroinen.fi> On Sun, May 18, 2008 at 01:33:41PM +0300, Ahmed Kamal wrote: > So, it totally does not boot, and hangs everytime with the message in the > subject. Is there any tricks to boot that kernel ? Is there any > testing/development kernel out there I can use to boot Xen dom0 on F9 ? kernel-xen in F9 does not support dom0 features, so it won't work. Check fedora-xen list archives for status/progress of the dom0 work.. I don't think there are any binary packages with dom0 patches yet. This feature-page should have up-to-date information about dom0 support: http://fedoraproject.org/wiki/Features/XenPvopsDom0 See also: https://www.redhat.com/archives/fedora-xen/2008-May/msg00006.html -- Pasi From martin.sourada at gmail.com Sun May 18 12:46:16 2008 From: martin.sourada at gmail.com (Martin Sourada) Date: Sun, 18 May 2008 14:46:16 +0200 Subject: Epiphany/Midori + WebKit "Usage experiences" Message-ID: <1211114777.1487.14.camel@pc-notebook> Hi, I am a happy epiphany user and as such I am concerned about it's transition to WebKit backend. I noticed there is already, at least, one web browser using WebKit in Fedora repos - Midori, so I installed it (about a month ago) and when in need in fast access to web browser (I use to save sessions in Ephy and there are lots of pages to load before it's usable) I use Midori. Today I've built epiphany from svn with the WebKit backend and decided to write short summary about it's usability. First, a build issue. Where can I find m4 macro AM_CHECK_PYTHON_HEADERS? Epiphany needs it, but it's not available in python-devel. And now for the runtime :) First let me say that on the contrary of it being svn snapshot it seems so far pretty usable, IMHO more usable than ephy with XULRunner during the pre F-9 transition... Now some WebKit related issues I noticed both in Epiphany and Midori: * fedoraforum.org displays white page (out of the tens, maybe hundreds of pages I tried, this is the only one with the issue :-/) * ftp protocol seems to be not fully implemented - it just prints some sort of directory listing (without any formating) and that's all... * the performance is sometimes sluggish, especially during page loading the webbrowser freezes for a while, or is really slow * traditional linux copy&paste (mouse select) is broken * cannot log into websites with pop-up dialog boxes * In epiphany, open in new tab option is missing I'll probably start looking for/filling bugs upstream when I have enough time to do so. If anyone experience these issues as well and is aware of relevant bug #, let me know :) Thanks, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From dcbw at redhat.com Sun May 18 13:22:11 2008 From: dcbw at redhat.com (Dan Williams) Date: Sun, 18 May 2008 09:22:11 -0400 Subject: NetworkManager: I want to believe, but... [was Re: F9 potential service network bug?] In-Reply-To: <482EC507.1030707@mlbassoc.com> References: <3da3b5b40805161502w62f372dseca0ab6310e44447@mail.gmail.com> <1210975852.6805.10.camel@localhost.localdomain> <3da3b5b40805161522i2300f1cdhb1fc7b074084873f@mail.gmail.com> <604aa7910805161527j6b193c6dj2af4248155d5cdaf@mail.gmail.com> <20080517112856.GA18698@jadzia.bu.edu> <1211024075.4060.50.camel@localhost.localdomain> <482EC36B.3050803@mlbassoc.com> <482EC481.9000304@fedoraproject.org> <482EC507.1030707@mlbassoc.com> Message-ID: <1211116931.686.1.camel@localhost.localdomain> On Sat, 2008-05-17 at 05:44 -0600, Gary Thomas wrote: > Rahul Sundaram wrote: > > Gary Thomas wrote: > > > >> > >> What if you install via LiveCD? It doesn't ask anything about network > >> setup in this case. > > > > There should be pretty much no difference since Live CD's use Anaconda > > to perform the installation too. Up until the last release, > > NetworkManager was only turned when installed via a Live CD but that > > isn't the case with Fedora 9 release and it is turned on by default > > regardless of how you install it. > > I was pointing out that Jesse's comment about setting up the static > IP *during* install doesn't apply in this case. That may be the > source of the difference in behaviour that Matt is seeing. The LiveCD does ask for network setup. Dan From nicolas.mailhot at laposte.net Sun May 18 15:00:26 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 18 May 2008 17:00:26 +0200 (CEST) Subject: GNU Unifont update In-Reply-To: <48303EAB.4030702@gmail.com> References: <482BB8E3.9060402@gmail.com> <57687.81.64.151.204.1211110834.squirrel@rousalka.dyndns.org> <48303EAB.4030702@gmail.com> Message-ID: <45738.81.64.151.204.1211122826.squirrel@rousalka.dyndns.org> Le Dim 18 mai 2008 16:35, Qianqian Fang a ?crit : > For now, maybe keeping both packages in parallel is the best. ? > The maintaining expense for both packages is not that much though. > I would be glad to maintain GNU Unifont, or show Paul how to do that > if he wants. The spec files for both packages can be almost identical. That would probably best as I've still not found a motherlode of new font packagers. Don't hesitate to ask on the list if you have any problem! Regards, -- Nicolas Mailhot From fedora at camperquake.de Sun May 18 16:16:16 2008 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sun, 18 May 2008 18:16:16 +0200 Subject: F9 (bug?) Superblock features different from backup In-Reply-To: <48261ACA.1030907@redhat.com> References: <3da3b5b40805101439y56886e24h2c2a2b36681e7783@mail.gmail.com> <48261ACA.1030907@redhat.com> Message-ID: <20080518181616.55c02aa9@lain.camperquake.de> Hi. On Sat, 10 May 2008 16:59:38 -0500, Eric Sandeen wrote > Problem is, the kernel sets things on the fly, but does not update the > backups. This is ... annoying... because then it causes the full > fsck. And why doesn't the kernel propagate those flags (on umount, for example)? From ssorce at redhat.com Sun May 18 17:00:21 2008 From: ssorce at redhat.com (Simo Sorce) Date: Sun, 18 May 2008 13:00:21 -0400 Subject: X, Gnome broken In-Reply-To: <1211069112.3070.394.camel@cookie.hadess.net> References: <200805170039.m4H0dtYC010521@laptop13.inf.utfsm.cl> <1211069112.3070.394.camel@cookie.hadess.net> Message-ID: <1211130021.5793.9.camel@localhost.localdomain> On Sun, 2008-05-18 at 01:05 +0100, Bastien Nocera wrote: > On Fri, 2008-05-16 at 20:39 -0400, Horst H. von Brand wrote: > > glibc-2.8.90-1.i686.rpm breaks X somehow. Needed to go back. > > gnome-session-2.23.1.1-1.fc10.i386.rpm crashes, I had to go back one here. > > File bugs instead. s/instead/too/ -- Simo Sorce * Red Hat, Inc * New York From sandeen at redhat.com Sun May 18 17:59:42 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Sun, 18 May 2008 12:59:42 -0500 Subject: F9 (bug?) Superblock features different from backup In-Reply-To: <20080518181616.55c02aa9@lain.camperquake.de> References: <3da3b5b40805101439y56886e24h2c2a2b36681e7783@mail.gmail.com> <48261ACA.1030907@redhat.com> <20080518181616.55c02aa9@lain.camperquake.de> Message-ID: <48306E8E.6010304@redhat.com> Ralf Ertzinger wrote: > Hi. > > On Sat, 10 May 2008 16:59:38 -0500, Eric Sandeen wrote > >> Problem is, the kernel sets things on the fly, but does not update the >> backups. This is ... annoying... because then it causes the full >> fsck. > > And why doesn't the kernel propagate those flags (on umount, for example)? Well, if the kernel is going to set things on the fly (which IMHO it shouldn't) then it should do it properly (from the perspective of fsck) on all backup superblocks. As to why it doesn't? No good answer for you. -Eric From mail at robertoragusa.it Sun May 18 18:35:20 2008 From: mail at robertoragusa.it (Roberto Ragusa) Date: Sun, 18 May 2008 20:35:20 +0200 Subject: F8 -> F9 but keeping KDE3: technically feasible? Message-ID: <483076E8.70601@robertoragusa.it> Hi all, do you think it can be possible to upgrade a F8 to F9 with exclusion of the KDE packages? My idea would be to keep qt, qt4 and kde* packages from F8, and upgrade all the rest. Will I run into serious issues about collateral dependencies, e.g. pulseaudio<->artsd, NM, misc dbus/hal things, etc...? What is the best way to attempt such a thing? Can I run anaconda in a "minimal" mode to upgrade only the basic stuff and then proceed with yum? Upgrade F8->F9 exclusively via yum? Hints kindly accepted. -- Roberto Ragusa mail at robertoragusa.it From mzerqung at 0pointer.de Sun May 18 19:19:58 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Sun, 18 May 2008 21:19:58 +0200 Subject: Glitch-Free PulseAudio in Rawhide In-Reply-To: <1211024129.3482.3.camel@localhost.localdomain> References: <20080517101616.GA16071@tango.0pointer.de> <1211024129.3482.3.camel@localhost.localdomain> Message-ID: <20080518191958.GB19530@tango.0pointer.de> On Sat, 17.05.08 13:35, David Andersson (david at k?rem?la.se) wrote: > > l?r 2008-05-17 klockan 12:16 +0200 skrev Lennart Poettering: > > Heya! > > > > Since yesterday glitch-free PulseAudio is available in Rawhide, > > breaking your sound setups. > Hi. Downloaded pulseaudio and friends from koji this morning, and unless > I comment out "load-module module-default-device-restore" > in /etc/pulse/default.pa Pulseaudio bails out with a "E: > module-default-device-restore.c: Assertion 'u' failed at > modules/module-default-device-restore.c:161, function > module_default_device_restore_LTX_pa__init(). Aborting." Fixed upstream in r2463 and thanks to Mathias this was fixed even earlier in Rawhide. Please don't spam fedora-devel with bug reports. Direct them to upstream BTS (strongly preferred) or to bz. Please help to increase the signal-to-noise ration on fedora-devel a bit by not misusing it as a BTS! Thank you, Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Sun May 18 20:02:25 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Sun, 18 May 2008 22:02:25 +0200 Subject: Glitch-Free PulseAudio in Rawhide In-Reply-To: References: <20080517101616.GA16071@tango.0pointer.de> Message-ID: <20080518200225.GC19530@tango.0pointer.de> On Sun, 18.05.08 05:44, Kevin Kofler (kevin.kofler at chello.at) wrote: > > Lennart Poettering 0pointer.de> writes: > > Since yesterday glitch-free PulseAudio is available in Rawhide, > > Too bad what we actually need is BUG-FREE PulseAudio. ;-) (And no, I'm not just > talking about the regressions, but about all the longstanding bugs: > http://bugz.fedoraproject.org/pulseaudio .) Ah, "bug-free" software. I love the idea. Unfortunately there is no such thing. I am not sure what you want. Most of these bugs are either waiting for more feedback from the reporter, are wishlist bugs, are obsolete, or are merely kept around to track issues outside of PA (i.e. closed-source sw not working with our compat foo). Maybe you should actually have a look inside these reports before starting to complain? And even better, instead of complaining maybe you should just help me fix the remaining issues? It's Free Software, you know? I think you are victim of the misconception that PA itself is horrendously buggy. However, please keep in mind what we are doing here: we have added a completely new layer to our software stack and need to make sure that the vast number of audio applications which are already out there are adapted to work with this new layer. Those apps sometimes make assumptions about how sound hw works that can never be kept by PA, sometimes they violate the existing APIs and sometimes are closed source. Now put these things together with the large number of applications out there and maybe you get and idea why the way to kick-ass audio on Linux is as rocky as it is. Also, if you claim that I neglect longstanding important bugs, then please be more specific and tell me exactly the bug numbers. Thank you, Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From rawhide at fedoraproject.org Mon May 19 10:29:33 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Mon, 19 May 2008 10:29:33 +0000 (UTC) Subject: rawhide report: 20080519 changes Message-ID: <20080519102933.F3CDE209D2B@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080518/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080519/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package GLC_Player GLC_Player is an Open Source software used to view 3d models (OBJ Format) New package alsa-firmware Firmware for several ALSA-supported sound cards New package GLC_lib C++ class library for OpenGL application based on Qt 4 Updated Packages: netcdf-4.0.0-0.5.beta2.fc10 --------------------------- * Sun May 18 18:00:00 2008 Patrice Dumas - 4.0.0-0.5.beta2 - use %{_fmoddir} - don't use %makeinstall anyremote-4.5-1.fc10 -------------------- * Sun May 18 18:00:00 2008 Mikhail Fedotov - 4.5-1 - Better integration with anyremote2http - "-http" command line parameter was added. system-config-printer-0.9.91-2.fc10 ----------------------------------- * Sun May 18 18:00:00 2008 Tim Waugh 0.9.91-2 - Fixed icon search path. php-pear-1.7.2-2.fc10 --------------------- * Sun May 18 18:00:00 2008 Remi Collet 1:1.7.2-2 - revert to install-pear.php script 1.31 (for cfg_dir) * Sun May 18 18:00:00 2008 Remi Collet 1:1.7.2-1 - update to 1.7.2 - Update install-pear.php script (1.32) psiconv-0.9.8-1.fc10 -------------------- alsa-tools-1.0.16-3.fc10 ------------------------ * Sun May 18 18:00:00 2008 Tim Jackson - 1.0.16-3 - Really enable firmware subpackage * Sun May 18 18:00:00 2008 Tim Jackson - 1.0.16-2 - Enable firmware subpackage - the accompanying alsa-firmware package is finally in Fedora getmail-4.8.1-3.fc10 -------------------- * Sun May 18 18:00:00 2008 - 4.8.1-2 - Updated python_sitelib header to build on rawhide dx-4.4.4-6.fc10 --------------- ruby-cairo-1.6.1-1.fc10 ----------------------- * Sun May 18 18:00:00 2008 Allisson Azevedo 1.6.1-1 - Update to 1.6.1 pulseaudio-0.9.11-0.1.svn20080516.fc10 -------------------------------------- * Sat May 17 18:00:00 2008 Matthias Clasen 0.9.11-0.1.svn20080516 - Fix a wrong assertion in module-default-device-restore superiotool-0-0.11.20080518svn3319.fc10 --------------------------------------- * Sun May 18 18:00:00 2008 Peter Lemenkov 0-0.11.20080518svn3319 - Fixed installation * Sun May 18 18:00:00 2008 Peter Lemenkov 0-0.10.20080518svn3319 - Add support for dumping ITE IT8718F EC registers - Detect SMSC SCH5027 - Small cleanups sugar-toolkit-0.79.7-1.fc10 --------------------------- * Sun May 18 18:00:00 2008 Tomeu Vizoso - 0.79.7-1 - Misc. fixes. ocaml-bitmatch-1.2-1.fc10 ------------------------- * Sun May 18 18:00:00 2008 Richard W.M. Jones - 1.2-1 - New upstream release 1.2. - Build and distribute the examples. * Sun May 18 18:00:00 2008 Richard W.M. Jones - 1.0-3 - New upstream release 1.0. - New upstream URL and download location. - Use RPM percent-configure in build section. sugar-artwork-0.79.3-1.fc10 --------------------------- * Sun May 18 18:00:00 2008 Tomeu Vizoso - 0.79.3 - Misc. icon fixes. * Wed Apr 9 18:00:00 2008 Tomeu Vizoso - 0.79.2 - Misc. icon fixes. openoffice.org-3.0.0-0.0.12.2.fc10 ---------------------------------- * Fri May 16 18:00:00 2008 Caolan McNamara - 1:3.0.0-0.12.2 - I misspelled the damn Requires evolution-data-server-2.23.2-3.fc10 ----------------------------------- * Sun May 18 18:00:00 2008 Matthew Barnes - 2.23.2-3.fc10 - Add patch for GNOME bug #531439 (GPG passphrases destroy passwords). a2ps-4.14-4.fc10 ---------------- * Sun May 18 18:00:00 2008 Patrice Dumas 4.14-4 - remove dots in node names, patch from Vitezslav Crhonek (bug #445971) q-7.10-3.fc10 ------------- Broken deps for i386 ---------------------------------------------------------- LabPlot-1.5.1.6-4.fc8.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libMagick.so.10 conduit-0.3.10-1.fc10.noarch requires gnome-python-desktop conduit-0.3.10-1.fc10.noarch requires gnome-python-extras evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-python-0.0.4-3.fc9.i386 requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.i386 requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-1.2.so.11 kismet-extras-0.0.2007.10.R1-3.fc9.i386 requires libMagick.so.10 koffice-karbon-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-karbon-1.6.3-15.fc9.i386 requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libMagick.so.10 nip2-7.14.1-1.fc9.i386 requires libWand.so.10 nip2-7.14.1-1.fc9.i386 requires libMagick.so.10 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) qgis-0.9.1-5.fc9.i386 requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.i386 requires libgeos.so.2 sunbird-0.8-3.fc9.i386 requires libhunspell.so.1 thunderbird-lightning-0.8-3.fc9.i386 requires libhunspell.so.1 torcs-1.3.0-6.fc9.i386 requires libplibssgaux.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibssg.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibsl.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibsm.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibsg.so.1.8.4 torcs-1.3.0-6.fc9.i386 requires libplibul.so.1.8.4 totem-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 totem-mozplugin-2.23.2-2.fc9.i386 requires libtotem-plparser-mini.so.10 totem-mozplugin-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 totem-nautilus-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 Broken deps for x86_64 ---------------------------------------------------------- LabPlot-1.5.1.6-4.fc8.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libMagick.so.10 LabPlot-1.5.1.6-4.fc8.x86_64 requires libMagick++.so.10()(64bit) LabPlot-1.5.1.6-4.fc8.x86_64 requires libMagick.so.10()(64bit) LabPlot-1.5.1.6-4.fc8.x86_64 requires libWand.so.10()(64bit) conduit-0.3.10-1.fc10.noarch requires gnome-python-desktop conduit-0.3.10-1.fc10.noarch requires gnome-python-extras evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libWand.so.10()(64bit) evolution-python-0.0.4-3.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx kismet-extras-0.0.2007.10.R1-3.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.x86_64 requires libWand.so.10()(64bit) koffice-libs-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.x86_64 requires libWand.so.10()(64bit) nip2-7.14.1-1.fc9.x86_64 requires libMagick.so.10()(64bit) nip2-7.14.1-1.fc9.x86_64 requires libWand.so.10()(64bit) perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) qgis-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) sunbird-0.8-3.fc9.x86_64 requires libhunspell.so.1()(64bit) thunderbird-lightning-0.8-3.fc9.x86_64 requires libhunspell.so.1()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibsg.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibul.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibssgaux.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibsm.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibssg.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.x86_64 requires libplibsl.so.1.8.4()(64bit) totem-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 totem-2.23.2-2.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.x86_64 requires libtotem-plparser-mini.so.10()(64bit) totem-nautilus-2.23.2-2.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) Broken deps for ppc ---------------------------------------------------------- LabPlot-1.5.1.6-4.fc8.ppc requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.ppc requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.ppc requires libMagick.so.10 alsa-firmware-1.0.16-1.fc10.noarch requires alsa-tools-firmware >= 0:1.0.16 conduit-0.3.10-1.fc10.noarch requires gnome-python-desktop conduit-0.3.10-1.fc10.noarch requires gnome-python-extras evolution-brutus-1.2.11-2.fc9.ppc requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.ppc requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.ppc requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-python-0.0.4-3.fc9.ppc requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.ppc requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-1.2.so.11 kismet-extras-0.0.2007.10.R1-3.fc9.ppc requires libMagick.so.10 koffice-karbon-1.6.3-15.fc9.ppc requires libWand.so.10 koffice-karbon-1.6.3-15.fc9.ppc requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.ppc requires libWand.so.10 koffice-libs-1.6.3-15.fc9.ppc requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) nip2-7.14.1-1.fc9.ppc requires libWand.so.10 nip2-7.14.1-1.fc9.ppc requires libMagick.so.10 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) qgis-0.9.1-5.fc9.ppc requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.ppc requires libgeos.so.2 sunbird-0.8-3.fc9.ppc requires libhunspell.so.1 thunderbird-lightning-0.8-3.fc9.ppc requires libhunspell.so.1 torcs-1.3.0-6.fc9.ppc requires libplibssgaux.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibssg.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibsl.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibsm.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibsg.so.1.8.4 torcs-1.3.0-6.fc9.ppc requires libplibul.so.1.8.4 totem-2.23.2-2.fc9.ppc requires libtotem-plparser.so.10 totem-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.ppc requires libtotem-plparser-mini.so.10 totem-mozplugin-2.23.2-2.fc9.ppc requires libtotem-plparser.so.10 totem-nautilus-2.23.2-2.fc9.ppc requires libtotem-plparser.so.10 Broken deps for ppc64 ---------------------------------------------------------- alsa-firmware-1.0.16-1.fc10.noarch requires alsa-tools-firmware >= 0:1.0.16 conduit-0.3.10-1.fc10.noarch requires gnome-python-desktop conduit-0.3.10-1.fc10.noarch requires gnome-python-extras evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-python-0.0.4-3.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) kismet-extras-0.0.2007.10.R1-3.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot nip2-7.14.1-1.fc9.ppc64 requires libMagick.so.10()(64bit) nip2-7.14.1-1.fc9.ppc64 requires libWand.so.10()(64bit) perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot qgis-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) sunbird-0.8-3.fc9.ppc64 requires libhunspell.so.1()(64bit) thunderbird-lightning-0.8-3.fc9.ppc64 requires libhunspell.so.1()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibsg.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibul.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibsm.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibssgaux.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibssg.so.1.8.4()(64bit) torcs-1.3.0-6.fc9.ppc64 requires libplibsl.so.1.8.4()(64bit) totem-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.ppc64 requires libtotem-plparser-mini.so.10()(64bit) totem-nautilus-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) From paul at all-the-johnsons.co.uk Mon May 19 12:53:30 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Mon, 19 May 2008 13:53:30 +0100 Subject: s-c-soundcard gone? Message-ID: <1211201610.4569.5.camel@T7.Linux> Hi, Has system-config-soundcard vanished? It's not showing up anywhere and for some reason, my main card has vanished from the alsa list! TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Mon May 19 13:07:30 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 19 May 2008 18:37:30 +0530 Subject: s-c-soundcard gone? In-Reply-To: <1211201610.4569.5.camel@T7.Linux> References: <1211201610.4569.5.camel@T7.Linux> Message-ID: <48317B92.2080708@fedoraproject.org> Paul wrote: > Hi, > > Has system-config-soundcard vanished? It's not showing up anywhere and > for some reason, my main card has vanished from the alsa list! http://docs.fedoraproject.org/release-notes/f9/en_US/sn-PackageNotes.html#sn-sound-card-utility-changes Rahul From dhuff at redhat.com Mon May 19 13:11:40 2008 From: dhuff at redhat.com (David Huff) Date: Mon, 19 May 2008 09:11:40 -0400 Subject: livecd-creator and selinux, status at the end of week 1 In-Reply-To: <1210965549.2717.23.camel@localhost.localdomain> References: <1210965549.2717.23.camel@localhost.localdomain> Message-ID: <48317C8C.7050606@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Paris wrote: | I've spent pretty much all week flailing around try to get | livecd-creator working with selinux enforcing with F10 as both the host | and the image. Next week begins the journey of working on making old | composes work on F10. Where do I stand? Well, it seems to work! I | booted an image and logged in. | I have seen similar issues with the appliance-tools Im working on (thincrust.net). On thing I have noticed is that kickstart.py only likes crypted passwds, so make sure you use the --iscrytped option in the ks file. I have also noticed another problem, if you set selinux disabled via the kickstart and try to set no root passwd, by excluding a rootpw line in the ks, you get an error similar too: "only root can do that" I think this is due to selinux context on the host you are building the image on. I saw this running a F9 client on a F9 host, from your post on Friday, I will try generating a rwahide image on a rawhide host and see if I have similar results. - -D - -- David Huff Red Hat, Raleigh, NC Mobile: 919-796-3553 Office: 919-754-4129 GPG Key ID: 6A20BBF7 GPG Fingerprint: FE13 8AF6 0E58 D92E A4E1 2D0A 71C1 CADF 6A20 BBF7 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFIMXyMccHK32ogu/cRAqHBAJ9/wy2a9+iVt86IXsJ9Qa8ZgChRYwCfaF5b i6DfEG3ZIXpb6IOsH5BBlxE= =BEb4 -----END PGP SIGNATURE----- From cra at WPI.EDU Mon May 19 13:23:33 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 19 May 2008 09:23:33 -0400 Subject: I have a big mouth... In-Reply-To: <482FCF59.3070404@gmail.com> References: <604aa7910805161029i1573ca51v11c144007c0254f3@mail.gmail.com> <482DCBD2.2070205@gmail.com> <200805170140.m4H1erxs015127@laptop13.inf.utfsm.cl> <16de708d0805171509o4064d065hdbf1fb13836d5fac@mail.gmail.com> <20080517231326.GA24901@angus.ind.WPI.EDU> <482FCF59.3070404@gmail.com> Message-ID: <20080519132333.GA14454@angus.ind.WPI.EDU> On Sun, May 18, 2008 at 11:40:25AM +0500, Suren Karapetyan wrote: > Chuck Anderson wrote: >>>> I for one can't see any comments... >>> I do, Firefox2/WindowsServer2003 maybe its biased against Linux users. >> >> It appears to work fine on MacOS X Safari 3.1.1 and FF 2.0.0.14. >> >> I tried User Agent Switcher with FF3 on F9, and it doesn't make a >> difference what user agent I try (IE7 Vista, NS 4.8 Vista, Opera 9.25 >> Vista)--it still doesn't show any comments section. So this doesn't >> appear to be a deliberate user agent-based bias. >> > > It has nothing to do with the browser You use. > It's just server-related problem. Not quite sure but looks like comments > are loaded from here: > http://www.informationweek.com/btgcommunity/communityjs/780;jsessionid=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX?forum=13&key=33669&cmpJiveUser= > And sometimes it just starts giving HTTP 500s I don't agree with this. I have two machines behind the same NAT gateway, therefore they are using the same public source IP address to connect to the web server. One is Mac OS X, and works fine with both browsers, and the other is my Fedora 9 box which doesn't work at all, hasn't worked all weekend, and still doesn't work today. I tried both machines simultaneously, and the Mac consistently works fine, while the F9 box doesn't. Additionally, I just tried Konqueror on F9, and it works fine. Tis is definately a problem with at least my F9 Firefox 3 setup. Ok, I do have some extensions, namely NoScript, Flashblock, and User Agent Switcher. I just said "Allow Scripts Globally" and it is now working. I guess some not-so-obvious third party site needs to run a script for the comments section to work. From eparis at redhat.com Mon May 19 13:34:46 2008 From: eparis at redhat.com (Eric Paris) Date: Mon, 19 May 2008 09:34:46 -0400 Subject: livecd-creator and selinux, status at the end of week 1 In-Reply-To: <48317C8C.7050606@redhat.com> References: <1210965549.2717.23.camel@localhost.localdomain> <48317C8C.7050606@redhat.com> Message-ID: <1211204086.3013.6.camel@localhost.localdomain> On Mon, 2008-05-19 at 09:11 -0400, David Huff wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Eric Paris wrote: > | I've spent pretty much all week flailing around try to get > | livecd-creator working with selinux enforcing with F10 as both the host > | and the image. Next week begins the journey of working on making old > | composes work on F10. Where do I stand? Well, it seems to work! I > | booted an image and logged in. > | > > > I have seen similar issues with the appliance-tools Im working on > (thincrust.net). On thing I have noticed is that kickstart.py only > likes crypted passwds, so make sure you use the --iscrytped option in > the ks file. > > I have also noticed another problem, if you set selinux disabled via the > kickstart and try to set no root passwd, by excluding a rootpw > line in the ks, you get an error similar too: > > "only root can do that" > > I think this is due to selinux context on the host you are > building the image on. I saw this running a F9 client on a F9 host, > from your post on Friday, I will try generating a rwahide image on a > rawhide host and see if I have similar results. If you wouldn't mind opening a BZ, for now lets open it against libselinux assign it to me and let me know all of the problems you have run into involving passwd. I think I understand all of that cruft now. -Eric From jeff at ocjtech.us Mon May 19 13:52:41 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Mon, 19 May 2008 08:52:41 -0500 Subject: Looking for the latest version of asterisk-strip.sh In-Reply-To: References: Message-ID: <935ead450805190652u1104eaf2scb404acafc67788c@mail.gmail.com> On Sat, May 17, 2008 at 5:02 PM, William F. Acker WB2FLW +1-303-722-7209 wrote: > > with the release of asterisk-1.6.0-0.12.beta7.1, it was discovered that > we needed to strip the tarball again. However, the script doesn't seem to > have been re-included in the SRPM. Oops, my bad. I'll re-add it to the next release. > Does anyone know where I can find the > one that includes the latest removals? http://cvs.fedoraproject.org/viewcvs/rpms/asterisk/devel/asterisk-strip.sh?rev=1.3&view=auto > I'd like to build beta9 since > there's a good chance that it fixes some of the bugs that have been bugging > me. I started building a version of beta9 last week but didn't get it done before taking off for a weekend camping trip. I'll hopefully have a new build completed today. Jeff From surenkarapetyan at gmail.com Mon May 19 14:35:26 2008 From: surenkarapetyan at gmail.com (Suren Karapetyan) Date: Mon, 19 May 2008 19:35:26 +0500 Subject: I have a big mouth... In-Reply-To: <20080519132333.GA14454@angus.ind.WPI.EDU> References: <604aa7910805161029i1573ca51v11c144007c0254f3@mail.gmail.com> <482DCBD2.2070205@gmail.com> <200805170140.m4H1erxs015127@laptop13.inf.utfsm.cl> <16de708d0805171509o4064d065hdbf1fb13836d5fac@mail.gmail.com> <20080517231326.GA24901@angus.ind.WPI.EDU> <482FCF59.3070404@gmail.com> <20080519132333.GA14454@angus.ind.WPI.EDU> Message-ID: <4831902E.9000804@gmail.com> Chuck Anderson wrote: > On Sun, May 18, 2008 at 11:40:25AM +0500, Suren Karapetyan wrote: >> Chuck Anderson wrote: >>>>> I for one can't see any comments... >>>> I do, Firefox2/WindowsServer2003 maybe its biased against Linux users. >>> It appears to work fine on MacOS X Safari 3.1.1 and FF 2.0.0.14. >>> >>> I tried User Agent Switcher with FF3 on F9, and it doesn't make a >>> difference what user agent I try (IE7 Vista, NS 4.8 Vista, Opera 9.25 >>> Vista)--it still doesn't show any comments section. So this doesn't >>> appear to be a deliberate user agent-based bias. >>> >> It has nothing to do with the browser You use. >> It's just server-related problem. Not quite sure but looks like comments >> are loaded from here: >> http://www.informationweek.com/btgcommunity/communityjs/780;jsessionid=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX?forum=13&key=33669&cmpJiveUser= >> And sometimes it just starts giving HTTP 500s > > I don't agree with this. I have two machines behind the same NAT > gateway, therefore they are using the same public source IP address to > connect to the web server. One is Mac OS X, and works fine with both > browsers, and the other is my Fedora 9 box which doesn't work at all, > hasn't worked all weekend, and still doesn't work today. I tried both > machines simultaneously, and the Mac consistently works fine, while > the F9 box doesn't. > > Additionally, I just tried Konqueror on F9, and it works fine. > > Tis is definately a problem with at least my F9 Firefox 3 setup. Ok, > I do have some extensions, namely NoScript, Flashblock, and User Agent > Switcher. I just said "Allow Scripts Globally" and it is now working. > I guess some not-so-obvious third party site needs to run a script for > the comments section to work. > It worked for me under F9 using both FF and Konq. Then it just stopped working (I didn't change anything) with both FF and Konq. And there was a guy who reported that this didn't work under MAC neither with Safari nor with FF. And now it works with both (for me). So my conclusion is: something wrong on the server-side (somewhere inside the highly-optimized load-balancers) or inside the too UNunderstandable JavaScript which tries to load the comments from the server. From aaronh at garden.org Mon May 19 15:11:50 2008 From: aaronh at garden.org (Aaron S. Hawley) Date: Mon, 19 May 2008 11:11:50 -0400 Subject: Bodhi documentation for new packages In-Reply-To: <482D9905.70000@garden.org> References: <481F5F85.7080203@garden.org> <20080506224247.GA3372@x300> <482D9905.70000@garden.org> Message-ID: <483198B6.1000807@garden.org> [Please, Cc me replies, thanks.] Aaron S. Hawley wrote: > > Luke, I had a chance to rewrite the instructions for adding new packages > with Bodhi using your response. I can throw them on the Wiki if you like. I updated the Wiki with the new instructions. Modify them as needed directly on the Wiki. From jeff at ocjtech.us Mon May 19 16:14:42 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Mon, 19 May 2008 11:14:42 -0500 Subject: Looking for the latest version of asterisk-strip.sh In-Reply-To: <935ead450805190652u1104eaf2scb404acafc67788c@mail.gmail.com> References: <935ead450805190652u1104eaf2scb404acafc67788c@mail.gmail.com> Message-ID: <935ead450805190914p181fcfb6rf987653e94f9327c@mail.gmail.com> On Mon, May 19, 2008 at 8:52 AM, Jeffrey Ollie wrote: > > I'll hopefully have a new build completed today. Rawhide: http://koji.fedoraproject.org/koji/taskinfo?taskID=617561 F-9: http://koji.fedoraproject.org/koji/taskinfo?taskID=617677 Jeff From skvidal at fedoraproject.org Mon May 19 16:33:30 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 19 May 2008 12:33:30 -0400 Subject: changes at planet fedora Message-ID: <1211214812.3095.0.camel@cutter> Hi all, I?m making some changes with how we build up the list of folks/rss feeds for the fedora planet. We?re making it more self-service and a bit easier to maintain for the admin group (and specifically easier for me to put up with). For all the people currently on the planet please follow these instructions to make sure your feed stays on there: http://skvidal.fedorapeople.org/docs/planet-addition.html These instructions will be added to the wiki after the wiki migration happens next week. Let me know what problems you have, too. thanks, -sv From jspaleta at gmail.com Mon May 19 16:47:40 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 19 May 2008 08:47:40 -0800 Subject: changes at planet fedora In-Reply-To: <1211214812.3095.0.camel@cutter> References: <1211214812.3095.0.camel@cutter> Message-ID: <604aa7910805190947md1f2e87h4b144be223ed9dc5@mail.gmail.com> On Mon, May 19, 2008 at 8:33 AM, seth vidal wrote: > Hi all, > I'm making some changes with how we build up the list of folks/rss > feeds for the fedora planet. We're making it more self-service and a bit > easier to maintain for the admin group (and specifically easier for me > to put up with). For all the people currently on the planet please > follow these instructions to make sure your feed stays on there: > > http://skvidal.fedorapeople.org/docs/planet-addition.html > > These instructions will be added to the wiki after the wiki migration > happens next week. > > Let me know what problems you have, too. Do you plan to keep the hackergochi images available where they are at http://planet.fedoraproject.org/heads ? or do people need to migrate their current faces over to their people space? -jef"what I really want to know is when is someone going to design a Fedora theme'd Wesnoth campaign using our hackergochi for the hero characters"spaleta From John.Mizell at tch.com Mon May 19 16:50:08 2008 From: John.Mizell at tch.com (John.Mizell at tch.com) Date: Mon, 19 May 2008 10:50:08 -0600 Subject: GDM setup Message-ID: It seem that there is not an setup gui for GDM now in fedora 9. I also checked to see the documentation at http://live.gnome.org/GDM/2.22/Configuration but it it not clear on how to enable remote x11 apps to display locally. Is there a work around and will this be added in a gui setup later on? John Mizell Systems Administrator TCH 4185 Harrison Blvd. Suite 202 Ogden, Utah 84403 801-624-4604 From skvidal at fedoraproject.org Mon May 19 16:43:36 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 19 May 2008 12:43:36 -0400 Subject: changes at planet fedora In-Reply-To: <604aa7910805190947md1f2e87h4b144be223ed9dc5@mail.gmail.com> References: <1211214812.3095.0.camel@cutter> <604aa7910805190947md1f2e87h4b144be223ed9dc5@mail.gmail.com> Message-ID: <1211215419.3095.2.camel@cutter> On Mon, 2008-05-19 at 08:47 -0800, Jeff Spaleta wrote: > On Mon, May 19, 2008 at 8:33 AM, seth vidal wrote: > > Hi all, > > I'm making some changes with how we build up the list of folks/rss > > feeds for the fedora planet. We're making it more self-service and a bit > > easier to maintain for the admin group (and specifically easier for me > > to put up with). For all the people currently on the planet please > > follow these instructions to make sure your feed stays on there: > > > > http://skvidal.fedorapeople.org/docs/planet-addition.html > > > > These instructions will be added to the wiki after the wiki migration > > happens next week. > > > > Let me know what problems you have, too. > > Do you plan to keep the hackergochi images available where they are at > http://planet.fedoraproject.org/heads ? or do people need to migrate > their current faces over to their people space? Please migrate them to your people space. -sv From mclasen at redhat.com Mon May 19 17:00:37 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 19 May 2008 13:00:37 -0400 Subject: GDM setup In-Reply-To: References: Message-ID: <1211216437.4776.2.camel@localhost.localdomain> On Mon, 2008-05-19 at 10:50 -0600, John.Mizell at tch.com wrote: > It seem that there is not an setup gui for GDM now in fedora 9. I also > checked to see the documentation at > http://live.gnome.org/GDM/2.22/Configuration but it it not clear on how to > enable remote x11 apps to display locally. > Is there a work around and will this be added in a gui setup later on? Just having remote X11 apps display locally does not really involve gdm and should work fine in F9. If you are talking about xdmcp, them yes, that does not currently work. The basic support for it is there, but it is not quite complete, afaik. From rda at rincon.com Mon May 19 17:02:12 2008 From: rda at rincon.com (Bob Arendt) Date: Mon, 19 May 2008 10:02:12 -0700 Subject: GDM setup In-Reply-To: References: Message-ID: <4831B294.3070609@rincon.com> John.Mizell at tch.com wrote: > It seem that there is not an setup gui for GDM now in fedora 9. I also > checked to see the documentation at > http://live.gnome.org/GDM/2.22/Configuration but it it not clear on how to > enable remote x11 apps to display locally. > Is there a work around and will this be added in a gui setup later on? > > John Mizell > Systems Administrator > TCH > 4185 Harrison Blvd. Suite 202 > Ogden, Utah 84403 > 801-624-4604 > I'm at a loss as well - I've been using this crude hack: mv /usr/bin/Xorg /usr/bin/Xorg.bin cat > /usr/bin/Xorg < References: <1211216437.4776.2.camel@localhost.localdomain> Message-ID: <4831BA78.4000206@rincon.com> Matthias Clasen wrote: > On Mon, 2008-05-19 at 10:50 -0600, John.Mizell at tch.com wrote: >> It seem that there is not an setup gui for GDM now in fedora 9. I also >> checked to see the documentation at >> http://live.gnome.org/GDM/2.22/Configuration but it it not clear on how to >> enable remote x11 apps to display locally. >> Is there a work around and will this be added in a gui setup later on? > > Just having remote X11 apps display locally does not really involve gdm > and should work fine in F9. If you are talking about xdmcp, them yes, > that does not currently work. The basic support for it is there, but it > is not quite complete, afaik. > Actually, it does involve gdm. When starting the Xserver, gdm tacks on a "-nolisten tcp" argument, inhibiting direct display to the Xserver. You can work around this using "ssh -X" to tunnel the X-display, but this may break some existing work-flows. There used to be a config param in /etc/gdm/custom.conf to set DisallowTCP=false to acheive this. An equivalent setting doesn't show up in the new gdm schemas. From mclasen at redhat.com Mon May 19 17:42:45 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 19 May 2008 13:42:45 -0400 Subject: GDM setup In-Reply-To: <4831BA78.4000206@rincon.com> References: <1211216437.4776.2.camel@localhost.localdomain> <4831BA78.4000206@rincon.com> Message-ID: <1211218965.4776.7.camel@localhost.localdomain> On Mon, 2008-05-19 at 10:35 -0700, Bob Arendt wrote: > Matthias Clasen wrote: > > On Mon, 2008-05-19 at 10:50 -0600, John.Mizell at tch.com wrote: > >> It seem that there is not an setup gui for GDM now in fedora 9. I also > >> checked to see the documentation at > >> http://live.gnome.org/GDM/2.22/Configuration but it it not clear on how to > >> enable remote x11 apps to display locally. > >> Is there a work around and will this be added in a gui setup later on? > > > > Just having remote X11 apps display locally does not really involve gdm > > and should work fine in F9. If you are talking about xdmcp, them yes, > > that does not currently work. The basic support for it is there, but it > > is not quite complete, afaik. > > > Actually, it does involve gdm. When starting the Xserver, gdm tacks on > a "-nolisten tcp" argument, inhibiting direct display to the Xserver. > You can work around this using "ssh -X" to tunnel the X-display, but this > may break some existing work-flows. There used to be a config param > in /etc/gdm/custom.conf to set DisallowTCP=false to acheive this. An > equivalent setting doesn't show up in the new gdm schemas. Yeah, I guess for me 'remote X' is synonymous to 'ssh -X' (or rather -Y nowadays). Really, the right thing to do is to update those existing work-flows. The default firewall configuration won't let straight X connections through, anyway.... Is there some specific reason why ssh tunneling does not work for you ? From opensource at till.name Mon May 19 18:02:38 2008 From: opensource at till.name (Till Maas) Date: Mon, 19 May 2008 20:02:38 +0200 Subject: hook into rpm install/update/deletion of any package (for etckeeper) Message-ID: <200805192002.44554.opensource@till.name> Hiyas, is it possible to hook into rpm in a way that an arbitray programm is run whenever a package is installed, updated or deleted? I want to test etckeeper: http://kitenet.net/~joey/code/etckeeper/ This programm creates a repository for /etc and keeps track of changes that are done there via package updates and therefore it needs to hook into rpm as far as I can see. Is it maybe possible to do this with something like %trigger? Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From katzj at redhat.com Mon May 19 18:16:34 2008 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 19 May 2008 14:16:34 -0400 Subject: hook into rpm install/update/deletion of any package (for etckeeper) In-Reply-To: <200805192002.44554.opensource@till.name> References: <200805192002.44554.opensource@till.name> Message-ID: <1211220994.18476.36.camel@aglarond.local> On Mon, 2008-05-19 at 20:02 +0200, Till Maas wrote: > is it possible to hook into rpm in a way that an arbitray programm is run > whenever a package is installed, updated or deleted? Not really. Your best bet is probably going to be to go the route of using a yum plugin and then remove /usr/lib/rpm/rpm[ie] ;-) Jeremy From jos at xos.nl Mon May 19 18:18:14 2008 From: jos at xos.nl (Jos Vos) Date: Mon, 19 May 2008 20:18:14 +0200 Subject: hook into rpm install/update/deletion of any package (for etckeeper) In-Reply-To: <200805192002.44554.opensource@till.name> References: <200805192002.44554.opensource@till.name> Message-ID: <20080519181814.GA19486@jasmine.xos.nl> On Mon, May 19, 2008 at 08:02:38PM +0200, Till Maas wrote: > is it possible to hook into rpm in a way that an arbitray programm is run > whenever a package is installed, updated or deleted? > > I want to test etckeeper: > http://kitenet.net/~joey/code/etckeeper/ > This programm creates a repository for /etc and keeps track of changes that > are done there via package updates and therefore it needs to hook into rpm as > far as I can see. Is it maybe possible to do this with something > like %trigger? With %trigger you have to specify the package that fires the trigger. So, no, that cannot be used to catch all packages, only for packages for which you create a %trigger (in another package). -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From skvidal at fedoraproject.org Mon May 19 18:11:43 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 19 May 2008 14:11:43 -0400 Subject: hook into rpm install/update/deletion of any package (for etckeeper) In-Reply-To: <200805192002.44554.opensource@till.name> References: <200805192002.44554.opensource@till.name> Message-ID: <1211220705.3095.9.camel@cutter> On Mon, 2008-05-19 at 20:02 +0200, Till Maas wrote: > Hiyas, > > is it possible to hook into rpm in a way that an arbitray programm is run > whenever a package is installed, updated or deleted? > > I want to test etckeeper: > http://kitenet.net/~joey/code/etckeeper/ > This programm creates a repository for /etc and keeps track of changes that > are done there via package updates and therefore it needs to hook into rpm as > far as I can see. Is it maybe possible to do this with something > like %trigger? > don't do it in a trigger. You may consider looking at a yum plugin like this one: http://www.mail-archive.com/yum-devel at linux.duke.edu/msg00193.html and modifying it for your needs. -sv From notting at redhat.com Mon May 19 18:19:24 2008 From: notting at redhat.com (Bill Nottingham) Date: Mon, 19 May 2008 14:19:24 -0400 Subject: rhgb no more In-Reply-To: <87y769hqvm.fsf@sheridan.bigo.ensc.de> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> <200805150824.08419.sgrubb@redhat.com> <1210856530.4615.2.camel@localhost.localdomain> <200805150959.28963.sgrubb@redhat.com> <87y769hqvm.fsf@sheridan.bigo.ensc.de> Message-ID: <20080519181924.GE27865@nostromo.devel.redhat.com> Enrico Scholz (enrico.scholz at informatik.tu-chemnitz.de) said: > Steve Grubb writes: > > > I have it as low in init priority as I can get it. It even starts before > > rsyslog. If a graphical boot does not honor the settings in the init scripts, > > what am I supposed to do? Is there another directory that I need to drop a > > file into that gets picked up by the boot sequence? > > Put this into /etc/event.d/auditd > > | start on starting syslog-ng > | start on starting rsyslog > | stop on stopped syslog-ng > | stop on stopped rsyslog > | > | exec /sbin/auditd -n Note that this makes it impossible for the admin to disable if they want to without removing the package. I would not go down this road just yet. Bill From rda at rincon.com Mon May 19 18:28:39 2008 From: rda at rincon.com (Bob Arendt) Date: Mon, 19 May 2008 11:28:39 -0700 Subject: GDM setup In-Reply-To: <1211218965.4776.7.camel@localhost.localdomain> References: <1211216437.4776.2.camel@localhost.localdomain> <4831BA78.4000206@rincon.com> <1211218965.4776.7.camel@localhost.localdomain> Message-ID: <4831C6D7.70607@rincon.com> Matthias Clasen wrote: > On Mon, 2008-05-19 at 10:35 -0700, Bob Arendt wrote: >> Matthias Clasen wrote: >>> On Mon, 2008-05-19 at 10:50 -0600, John.Mizell at tch.com wrote: >>>> It seem that there is not an setup gui for GDM now in fedora 9. I also >>>> checked to see the documentation at >>>> http://live.gnome.org/GDM/2.22/Configuration but it it not clear on how to >>>> enable remote x11 apps to display locally. >>>> Is there a work around and will this be added in a gui setup later on? >>> Just having remote X11 apps display locally does not really involve gdm >>> and should work fine in F9. If you are talking about xdmcp, them yes, >>> that does not currently work. The basic support for it is there, but it >>> is not quite complete, afaik. >>> >> Actually, it does involve gdm. When starting the Xserver, gdm tacks on >> a "-nolisten tcp" argument, inhibiting direct display to the Xserver. >> You can work around this using "ssh -X" to tunnel the X-display, but this >> may break some existing work-flows. There used to be a config param >> in /etc/gdm/custom.conf to set DisallowTCP=false to acheive this. An >> equivalent setting doesn't show up in the new gdm schemas. > > Yeah, I guess for me 'remote X' is synonymous to 'ssh -X' (or rather -Y > nowadays). Really, the right thing to do is to update those existing > work-flows. The default firewall configuration won't let straight X > connections through, anyway.... > > Is there some specific reason why ssh tunneling does not work for you ? > ssh tunnelling does work for me, today. But a couple of places I work with have a very non-hetrogeneous mix of server-display-to-client applications delivered since ~1998. They're running local, secure networks without external connection, so security's taken care of. Some fairly twitchy displays. It would take someone a lot of work to hunt down and modify all the scripts that have been dumped at these places over the years. It would be one of those "discovery by breakage" sort of things. The extra processing overhead of ssh encryption may or may not be a factor .. but it's not really required in these deployments. So while I heartily approve of applying "-nolisten tcp" by default, having the capability to re-enable remote X11 saves a *lot* of needless re-engineering. From opensource at till.name Mon May 19 18:31:35 2008 From: opensource at till.name (Till Maas) Date: Mon, 19 May 2008 20:31:35 +0200 Subject: hook into rpm install/update/deletion of any package (for etckeeper) In-Reply-To: <1211220705.3095.9.camel@cutter> References: <200805192002.44554.opensource@till.name> <1211220705.3095.9.camel@cutter> Message-ID: <200805192031.36555.opensource@till.name> On Mon May 19 2008, seth vidal wrote: > You may consider looking at a yum plugin like this one: > > http://www.mail-archive.com/yum-devel at linux.duke.edu/msg00193.html > > > and modifying it for your needs. I knew there are yum plugins and etckeeper will probably need one, but it would not be enough for me, because I also often install packages via rpm when I built them myself. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From skvidal at fedoraproject.org Mon May 19 18:35:27 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 19 May 2008 14:35:27 -0400 Subject: hook into rpm install/update/deletion of any package (for etckeeper) In-Reply-To: <200805192031.36555.opensource@till.name> References: <200805192002.44554.opensource@till.name> <1211220705.3095.9.camel@cutter> <200805192031.36555.opensource@till.name> Message-ID: <1211222130.3095.11.camel@cutter> On Mon, 2008-05-19 at 20:31 +0200, Till Maas wrote: > On Mon May 19 2008, seth vidal wrote: > > > You may consider looking at a yum plugin like this one: > > > > http://www.mail-archive.com/yum-devel at linux.duke.edu/msg00193.html > > > > > > and modifying it for your needs. > > I knew there are yum plugins and etckeeper will probably need one, but it > would not be enough for me, because I also often install packages via rpm > when I built them myself. > May I Introduce you to yum install /path/to/some/file.rpm :) -sv From fedora at dm.cobite.com Mon May 19 18:44:56 2008 From: fedora at dm.cobite.com (David Mansfield) Date: Mon, 19 May 2008 14:44:56 -0400 Subject: plans to improve dual head support in system-config-display etc? Message-ID: <1211222696.3486.5.camel@localhost.localdomain> Just curious about the direction this is going w.r.t xrandr 1.2 type displays. I have an ATI and many co-workers have Nvidia with multiple monitors attached which work great using the new xrandr based configuration. But sadly s-c-d doesn't really understand this in F9. It only understands dual head in the old xinerama sense. Also, xorg.conf seems pretty poor for a users individual prefs. as to what resolutions to use, as it's system-global not per-user. Can someone point me towards any prior discussion on how this is 'supposed' to work in F10/future? Thanks, David From cmadams at hiwaay.net Mon May 19 18:47:47 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 19 May 2008 13:47:47 -0500 Subject: hook into rpm install/update/deletion of any package (for etckeeper) In-Reply-To: <200805192031.36555.opensource@till.name> References: <200805192002.44554.opensource@till.name> <1211220705.3095.9.camel@cutter> <200805192031.36555.opensource@till.name> Message-ID: <20080519184747.GD1519793@hiwaay.net> Once upon a time, Till Maas said: > I knew there are yum plugins and etckeeper will probably need one, but it > would not be enough for me, because I also often install packages via rpm > when I built them myself. You could write a daemon that monitors /etc with inotify. Alternately, replace rpm with a wrapper script that does your monitoring. -- 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 Mon May 19 18:56:22 2008 From: jos at xos.nl (Jos Vos) Date: Mon, 19 May 2008 20:56:22 +0200 Subject: hook into rpm install/update/deletion of any package (for etckeeper) In-Reply-To: <1211222130.3095.11.camel@cutter> References: <200805192002.44554.opensource@till.name> <1211220705.3095.9.camel@cutter> <200805192031.36555.opensource@till.name> <1211222130.3095.11.camel@cutter> Message-ID: <20080519185622.GA20317@jasmine.xos.nl> On Mon, May 19, 2008 at 02:35:27PM -0400, seth vidal wrote: > May I Introduce you to yum install /path/to/some/file.rpm :) s/install/localinstall/, or has this been changed in newer versions? -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From cjdahlin at ncsu.edu Mon May 19 18:57:20 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Mon, 19 May 2008 14:57:20 -0400 Subject: hook into rpm install/update/deletion of any package (for etckeeper) In-Reply-To: <20080519185622.GA20317@jasmine.xos.nl> References: <200805192002.44554.opensource@till.name> <1211220705.3095.9.camel@cutter> <200805192031.36555.opensource@till.name> <1211222130.3095.11.camel@cutter> <20080519185622.GA20317@jasmine.xos.nl> Message-ID: <4831CD90.4060803@ncsu.edu> Jos Vos wrote: > On Mon, May 19, 2008 at 02:35:27PM -0400, seth vidal wrote: > > >> May I Introduce you to yum install /path/to/some/file.rpm :) >> > > s/install/localinstall/, or has this been changed in newer versions? > > I think yum has always been able to figure out if you meant localinstall when you said install. Its a crapshoot though. --CJD From notting at redhat.com Mon May 19 19:01:07 2008 From: notting at redhat.com (Bill Nottingham) Date: Mon, 19 May 2008 15:01:07 -0400 Subject: F9 potential service network bug? In-Reply-To: References: <3da3b5b40805161502w62f372dseca0ab6310e44447@mail.gmail.com> <1210975852.6805.10.camel@localhost.localdomain> <3da3b5b40805161522i2300f1cdhb1fc7b074084873f@mail.gmail.com> <604aa7910805161527j6b193c6dj2af4248155d5cdaf@mail.gmail.com> <1210989429.24740.14.camel@localhost.localdomain> Message-ID: <20080519190107.GF27865@nostromo.devel.redhat.com> Paul Wouters (paul at xelerance.com) said: > Mine was from a non-LiveCD. The ifcfg files generated look fine: > > # Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 > DEVICE=eth0 > BOOTPROTO=static > HWADDR=00:d0:b7:85:f6:03 > ONBOOT=no > DHCP_HOSTNAME=bofh.xelerance.com > > # Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet > DEVICE=eth1 > BOOTPROTO=static > HWADDR=00:0c:76:bc:9b:d1 > IPADDR=193.110.157.17 > NETMASK=255.255.255.248 > ONBOOT=yes > > eth0 has (or had) no link during install. > > To be it looked like despite being confgured with BOOTPROTO=static, the > avahi daemon and NetworkManager got started, and one of them started > doing dhcp. The static IP did appear as an additiona IP on the eth1 > interface, but since the DHCP was the main address, my public ip address > changed. ONBOOT=no means that NM won't try to automatically bring it up. That may be what you're seeing. Bill From skvidal at fedoraproject.org Mon May 19 19:01:21 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 19 May 2008 15:01:21 -0400 Subject: hook into rpm install/update/deletion of any package (for etckeeper) In-Reply-To: <20080519185622.GA20317@jasmine.xos.nl> References: <200805192002.44554.opensource@till.name> <1211220705.3095.9.camel@cutter> <200805192031.36555.opensource@till.name> <1211222130.3095.11.camel@cutter> <20080519185622.GA20317@jasmine.xos.nl> Message-ID: <1211223737.3095.13.camel@cutter> On Mon, 2008-05-19 at 20:56 +0200, Jos Vos wrote: > On Mon, May 19, 2008 at 02:35:27PM -0400, seth vidal wrote: > > > May I Introduce you to yum install /path/to/some/file.rpm :) > > s/install/localinstall/, or has this been changed in newer versions? > it's been that way for quite a while ,actually. install will look at the argument and if it looks like a path and the file exists then it will use it. -sv From eparis at redhat.com Mon May 19 19:14:03 2008 From: eparis at redhat.com (Eric Paris) Date: Mon, 19 May 2008 15:14:03 -0400 Subject: livecd-creator and selinux, status at the end of week 1 In-Reply-To: <1210965549.2717.23.camel@localhost.localdomain> References: <1210965549.2717.23.camel@localhost.localdomain> Message-ID: <1211224443.2728.2.camel@localhost.localdomain> On Fri, 2008-05-16 at 15:19 -0400, Eric Paris wrote: > I've spent pretty much all week flailing around try to get > livecd-creator working with selinux enforcing with F10 as both the host > and the image. Next week begins the journey of working on making old > composes work on F10. Where do I stand? Well, it seems to work! I > booted an image and logged in. Today I tried flipped my repos to point at F7 and tried to build. Didn't see any selinux messages but crap still hit the fan on boot (eventual kernel panic complaining about no root and killing init) Anyway, I also decided to see what would happen if I flipped my kickstart file to selinux --disabled while leaving the system enforcing. Sorta boom. Installing selinux-policy-targeted got really pissed off: libsepol.policydb_write: Discarding booleans and conditional rules libsepol.policydb_write: Discarding booleans and conditional rules libsepol.context_read_and_validate: invalid security context libsepol.policydb_to_image: new policy image is invalid libsepol.policydb_to_image: could not create policy image /usr/sbin/load_policy: Can't load policy: No such file or directory libsemanage.semanage_reload_policy: load_policy returned error code 2. libsemanage.semanage_install_active: Could not copy /etc/selinux/targeted/modules/active/policy.kern to /etc/selinux/targeted/policy/policy.21. But something tells me its still going to work just fine once the build finishes. Anyway. -Eric From sundaram at fedoraproject.org Mon May 19 19:14:50 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 20 May 2008 00:44:50 +0530 Subject: plans to improve dual head support in system-config-display etc? In-Reply-To: <1211222696.3486.5.camel@localhost.localdomain> References: <1211222696.3486.5.camel@localhost.localdomain> Message-ID: <4831D1AA.1040809@fedoraproject.org> David Mansfield wrote: > Just curious about the direction this is going w.r.t xrandr 1.2 type > displays. > > I have an ATI and many co-workers have Nvidia with multiple monitors > attached which work great using the new xrandr based configuration. But > sadly s-c-d doesn't really understand this in F9. It only understands > dual head in the old xinerama sense. > > Also, xorg.conf seems pretty poor for a users individual prefs. as to > what resolutions to use, as it's system-global not per-user. > > Can someone point me towards any prior discussion on how this is > 'supposed' to work in F10/future? I am not sure you have seen the work done in Fedora 9 on this http://fedoraproject.org/wiki/Features/RandrSupport http://fedoraproject.org/wiki/Releases/9/ReleaseSummary has a screenshot and some details too. Rahul From skvidal at fedoraproject.org Mon May 19 19:01:45 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 19 May 2008 15:01:45 -0400 Subject: hook into rpm install/update/deletion of any package (for etckeeper) In-Reply-To: <4831CD90.4060803@ncsu.edu> References: <200805192002.44554.opensource@till.name> <1211220705.3095.9.camel@cutter> <200805192031.36555.opensource@till.name> <1211222130.3095.11.camel@cutter> <20080519185622.GA20317@jasmine.xos.nl> <4831CD90.4060803@ncsu.edu> Message-ID: <1211223794.3095.14.camel@cutter> On Mon, 2008-05-19 at 14:57 -0400, Casey Dahlin wrote: > Jos Vos wrote: > > On Mon, May 19, 2008 at 02:35:27PM -0400, seth vidal wrote: > > > > > >> May I Introduce you to yum install /path/to/some/file.rpm :) > >> > > > > s/install/localinstall/, or has this been changed in newer versions? > > > > > I think yum has always been able to figure out if you meant localinstall > when you said install. Its a crapshoot though. a crapshoot? It's been that way since at least the 2.6 series, I think. -sv From cjdahlin at ncsu.edu Mon May 19 19:16:11 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Mon, 19 May 2008 15:16:11 -0400 Subject: hook into rpm install/update/deletion of any package (for etckeeper) In-Reply-To: <1211223794.3095.14.camel@cutter> References: <200805192002.44554.opensource@till.name> <1211220705.3095.9.camel@cutter> <200805192031.36555.opensource@till.name> <1211222130.3095.11.camel@cutter> <20080519185622.GA20317@jasmine.xos.nl> <4831CD90.4060803@ncsu.edu> <1211223794.3095.14.camel@cutter> Message-ID: <4831D1FB.7060500@ncsu.edu> seth vidal wrote: > On Mon, 2008-05-19 at 14:57 -0400, Casey Dahlin wrote: > >> Jos Vos wrote: >> >>> On Mon, May 19, 2008 at 02:35:27PM -0400, seth vidal wrote: >>> >>> >>> >>>> May I Introduce you to yum install /path/to/some/file.rpm :) >>>> >>>> >>> s/install/localinstall/, or has this been changed in newer versions? >>> >>> >>> >> I think yum has always been able to figure out if you meant localinstall >> when you said install. Its a crapshoot though. >> > > a crapshoot? > > It's been that way since at least the 2.6 series, I think. > > -sv > > > A crapshoot as in if there happens to be a package named fubar.rpm you're screwed. --CJD From sds at tycho.nsa.gov Mon May 19 19:30:38 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 19 May 2008 15:30:38 -0400 Subject: livecd-creator and selinux, status at the end of week 1 In-Reply-To: <1211224443.2728.2.camel@localhost.localdomain> References: <1210965549.2717.23.camel@localhost.localdomain> <1211224443.2728.2.camel@localhost.localdomain> Message-ID: <1211225438.7486.69.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2008-05-19 at 15:14 -0400, Eric Paris wrote: > On Fri, 2008-05-16 at 15:19 -0400, Eric Paris wrote: > > I've spent pretty much all week flailing around try to get > > livecd-creator working with selinux enforcing with F10 as both the host > > and the image. Next week begins the journey of working on making old > > composes work on F10. Where do I stand? Well, it seems to work! I > > booted an image and logged in. > > Today I tried flipped my repos to point at F7 and tried to build. > Didn't see any selinux messages but crap still hit the fan on boot > (eventual kernel panic complaining about no root and killing init) So the interesting question there is whether the image was missing files or just mislabeled? > Anyway, I also decided to see what would happen if I flipped my > kickstart file to selinux --disabled while leaving the system enforcing. > Sorta boom. Installing selinux-policy-targeted got really pissed off: > > libsepol.policydb_write: Discarding booleans and conditional rules > libsepol.policydb_write: Discarding booleans and conditional rules > libsepol.context_read_and_validate: invalid security context > libsepol.policydb_to_image: new policy image is invalid > libsepol.policydb_to_image: could not create policy image > /usr/sbin/load_policy: Can't load policy: No such file or directory > libsemanage.semanage_reload_policy: load_policy returned error code 2. > libsemanage.semanage_install_active: Could not > copy /etc/selinux/targeted/modules/active/policy.kern > to /etc/selinux/targeted/policy/policy.21. If you are going to build a selinux disabled image, then I assume you'd want to fake the chroot into seeing SELinux as disabled too so that it doesn't try to do things like load policy (as above). Which would mean bind mounting a file over /proc/filesystems in the chroot to obscure the presence of selinuxfs. > But something tells me its still going to work just fine once the build > finishes. Anyway. -- Stephen Smalley National Security Agency From skvidal at fedoraproject.org Mon May 19 19:24:47 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 19 May 2008 15:24:47 -0400 Subject: hook into rpm install/update/deletion of any package (for etckeeper) In-Reply-To: <4831D1FB.7060500@ncsu.edu> References: <200805192002.44554.opensource@till.name> <1211220705.3095.9.camel@cutter> <200805192031.36555.opensource@till.name> <1211222130.3095.11.camel@cutter> <20080519185622.GA20317@jasmine.xos.nl> <4831CD90.4060803@ncsu.edu> <1211223794.3095.14.camel@cutter> <4831D1FB.7060500@ncsu.edu> Message-ID: <1211225089.3095.20.camel@cutter> On Mon, 2008-05-19 at 15:16 -0400, Casey Dahlin wrote: > seth vidal wrote: > > On Mon, 2008-05-19 at 14:57 -0400, Casey Dahlin wrote: > > > >> Jos Vos wrote: > >> > >>> On Mon, May 19, 2008 at 02:35:27PM -0400, seth vidal wrote: > >>> > >>> > >>> > >>>> May I Introduce you to yum install /path/to/some/file.rpm :) > >>>> > >>>> > >>> s/install/localinstall/, or has this been changed in newer versions? > >>> > >>> > >>> > >> I think yum has always been able to figure out if you meant localinstall > >> when you said install. Its a crapshoot though. > >> > > > > a crapshoot? > > > > It's been that way since at least the 2.6 series, I think. > > > > -sv > > > > > > > A crapshoot as in if there happens to be a package named fubar.rpm > you're screwed. actually, not. the args passed to install are handled: - local pkg (if os.path.exists() and endswidth('.rpm') - remote available pkgs -sv From opensource at till.name Mon May 19 19:32:04 2008 From: opensource at till.name (Till Maas) Date: Mon, 19 May 2008 21:32:04 +0200 Subject: hook into rpm install/update/deletion of any package (for etckeeper) In-Reply-To: <1211222130.3095.11.camel@cutter> References: <200805192002.44554.opensource@till.name> <200805192031.36555.opensource@till.name> <1211222130.3095.11.camel@cutter> Message-ID: <200805192132.11563.opensource@till.name> On Mon May 19 2008, seth vidal wrote: > On Mon, 2008-05-19 at 20:31 +0200, Till Maas wrote: > > I knew there are yum plugins and etckeeper will probably need one, but it > > would not be enough for me, because I also often install packages via rpm > > when I built them myself. > > May I Introduce you to yum install /path/to/some/file.rpm :) Thank you, but this way I fear that I install unsigned rpms from a repository because my locally built rpms are not signed (otherwise they are broken, because rpms does not support the keylength of my gpg key) and therefore afaik I had to disable the check for gpg signatures. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From dcbw at redhat.com Mon May 19 19:36:33 2008 From: dcbw at redhat.com (Dan Williams) Date: Mon, 19 May 2008 15:36:33 -0400 Subject: F9 potential service network bug? In-Reply-To: References: <3da3b5b40805161502w62f372dseca0ab6310e44447@mail.gmail.com> <1210975852.6805.10.camel@localhost.localdomain> <3da3b5b40805161522i2300f1cdhb1fc7b074084873f@mail.gmail.com> <604aa7910805161527j6b193c6dj2af4248155d5cdaf@mail.gmail.com> <1210989429.24740.14.camel@localhost.localdomain> Message-ID: <1211225793.5389.2.camel@localhost.localdomain> On Fri, 2008-05-16 at 23:47 -0400, Paul Wouters wrote: > On Fri, 16 May 2008, Chris Ricker wrote: > > > > I've personally tested static IP addressing with static DNS servers with > > > anaconda on the F9 release LiveCD, and it worked fine for me through > > > multiple tests. What's not working for you? Can you attach the ifcfg > > > files anaconda generated right after you installed? > > > > Multiple people (including me) have put non-working examples in the mother > > of all NM bugzilla tickets ;-) > > > > Have you tried non-LiveCD? > > Mine was from a non-LiveCD. The ifcfg files generated look fine: > > # Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 > DEVICE=eth0 > BOOTPROTO=static > HWADDR=00:d0:b7:85:f6:03 > ONBOOT=no > DHCP_HOSTNAME=bofh.xelerance.com Bill figured this one out. > # Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet > DEVICE=eth1 > BOOTPROTO=static > HWADDR=00:0c:76:bc:9b:d1 > IPADDR=193.110.157.17 > NETMASK=255.255.255.248 > ONBOOT=yes And for this one, I'm building: http://koji.fedoraproject.org/koji/taskinfo?taskID=618281 which will pull the gateway out of /etc/sysconfig/network, which seems to be where the non-LiveCD installer puts the gateway. Not sure why the livecd and the non-livecd cases are different, but this update should fix it. Dan > eth0 has (or had) no link during install. > > To be it looked like despite being confgured with BOOTPROTO=static, the > avahi daemon and NetworkManager got started, and one of them started > doing dhcp. The static IP did appear as an additiona IP on the eth1 > interface, but since the DHCP was the main address, my public ip address > changed. > > Paul > From skvidal at fedoraproject.org Mon May 19 19:29:53 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 19 May 2008 15:29:53 -0400 Subject: hook into rpm install/update/deletion of any package (for etckeeper) In-Reply-To: <200805192132.11563.opensource@till.name> References: <200805192002.44554.opensource@till.name> <200805192031.36555.opensource@till.name> <1211222130.3095.11.camel@cutter> <200805192132.11563.opensource@till.name> Message-ID: <1211225394.3095.23.camel@cutter> On Mon, 2008-05-19 at 21:32 +0200, Till Maas wrote: > On Mon May 19 2008, seth vidal wrote: > > On Mon, 2008-05-19 at 20:31 +0200, Till Maas wrote: > > > > I knew there are yum plugins and etckeeper will probably need one, but it > > > would not be enough for me, because I also often install packages via rpm > > > when I built them myself. > > > > May I Introduce you to yum install /path/to/some/file.rpm :) > > Thank you, but this way I fear that I install unsigned rpms from a repository > because my locally built rpms are not signed (otherwise they are broken, > because rpms does not support the keylength of my gpg key) and therefore > afaik I had to disable the check for gpg signatures. no, you don't yum --nogpgcheck install /path/to/some/file.rpm OR you set gpgcheck=0 in yum.conf under [main] and set gpgcheck=1 in each of your [repo] sections. That way your repos always default to gpg checking and your local installs do not. if you so desired. -sv From eparis at redhat.com Mon May 19 19:41:41 2008 From: eparis at redhat.com (Eric Paris) Date: Mon, 19 May 2008 15:41:41 -0400 Subject: livecd-creator and selinux, status at the end of week 1 In-Reply-To: <1211225438.7486.69.camel@moss-spartans.epoch.ncsc.mil> References: <1210965549.2717.23.camel@localhost.localdomain> <1211224443.2728.2.camel@localhost.localdomain> <1211225438.7486.69.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1211226101.2728.4.camel@localhost.localdomain> On Mon, 2008-05-19 at 15:30 -0400, Stephen Smalley wrote: > On Mon, 2008-05-19 at 15:14 -0400, Eric Paris wrote: > > On Fri, 2008-05-16 at 15:19 -0400, Eric Paris wrote: > > > I've spent pretty much all week flailing around try to get > > > livecd-creator working with selinux enforcing with F10 as both the host > > > and the image. Next week begins the journey of working on making old > > > composes work on F10. Where do I stand? Well, it seems to work! I > > > booted an image and logged in. > > > > Today I tried flipped my repos to point at F7 and tried to build. > > Didn't see any selinux messages but crap still hit the fan on boot > > (eventual kernel panic complaining about no root and killing init) > > So the interesting question there is whether the image was missing files > or just mislabeled? Well in the F8 example kickstart I see this bit of craziness: # make the initrd we care about rm -f /boot/initrd*.img cp /etc/sysconfig/mkinitrd /etc/mayflower.conf ver=`ls /boot/vmlinuz* |head -n 1 |sed -e 's;/boot/vmlinuz-;;'` /usr/lib/livecd-creator/mayflower -f /boot/initrd-$ver.img $ver rm -f /etc/mayflower.conf which leads me to believe F7 probably needs something similar that I don't have with my basically blank kickstart file. -Eric From tmz at pobox.com Mon May 19 19:42:43 2008 From: tmz at pobox.com (Todd Zullinger) Date: Mon, 19 May 2008 15:42:43 -0400 Subject: hook into rpm install/update/deletion of any package (for etckeeper) In-Reply-To: <200805192132.11563.opensource@till.name> References: <200805192002.44554.opensource@till.name> <200805192031.36555.opensource@till.name> <1211222130.3095.11.camel@cutter> <200805192132.11563.opensource@till.name> Message-ID: <20080519194243.GA12622@inocybe.teonanacatl.org> Till Maas wrote: > Thank you, but this way I fear that I install unsigned rpms from a > repository because my locally built rpms are not signed (otherwise > they are broken, because rpms does not support the keylength of my > gpg key) and therefore afaik I had to disable the check for gpg > signatures. So no signature is preferable to creating a key of more standard size for use in signing your custom packages? -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ No sense being pessimistic, it probably wouldn't work anyway -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From notting at redhat.com Mon May 19 19:47:43 2008 From: notting at redhat.com (Bill Nottingham) Date: Mon, 19 May 2008 15:47:43 -0400 Subject: Recomposing with generic-logos In-Reply-To: <482FF429.3000005@kanarip.com> References: <482FF429.3000005@kanarip.com> Message-ID: <20080519194743.GG27865@nostromo.devel.redhat.com> Jeroen van Meeuwen (kanarip at kanarip.com) said: > I'm recomposing Fedora without fedora-logos, and instead using the > generic-logos package, in order to get de-branded installation media (so > that others can re-brand Fedora). > > The result shows[1], while tty3 shows[2]; it seems there's no fonts loaded > -or they cannot be found for some reason. The requirements for fedora-logos > and generic-logos however are similar, which leads me to conclude > everything appropriate /is/ in fact being pulled in a transaction set. I'm > wondering what else may be going wrong. > > I was thinking this may be caused by different %postinstall scripts for the > fedora-logos and generic-logos packages[3], but I'm not sure it is. > > Then, nim-nim mentioned on #fedora-devel it could have to do with fonts > packages. I composed the DVD with full debug logging on, so it's rather > large[4] (and bloated -18MB). I've grepped on font to get anything related > to fonts[5] (~352K). > > Could someone give me a push in the right direction? Can you compare the package set on the compose? By 'result' you mean the installer, not live, correct? What appears to have happend is you didn't include the @fonts group in your compose, so you have no fonts for anaconda to use. Bill From opensource at till.name Mon May 19 20:12:00 2008 From: opensource at till.name (Till Maas) Date: Mon, 19 May 2008 22:12:00 +0200 Subject: hook into rpm install/update/deletion of any package (for etckeeper) In-Reply-To: <20080519194243.GA12622@inocybe.teonanacatl.org> References: <200805192002.44554.opensource@till.name> <200805192132.11563.opensource@till.name> <20080519194243.GA12622@inocybe.teonanacatl.org> Message-ID: <200805192212.08506.opensource@till.name> On Mon May 19 2008, Todd Zullinger wrote: > Till Maas wrote: > > Thank you, but this way I fear that I install unsigned rpms from a > > repository because my locally built rpms are not signed (otherwise > > they are broken, because rpms does not support the keylength of my > > gpg key) and therefore afaik I had to disable the check for gpg > > signatures. > > So no signature is preferable to creating a key of more standard size > for use in signing your custom packages? I can still provide gpg signatures with gpg: gpg --armor --detach-sign foo.rpm This also allows the receipient to check the signature without giving my key ultimate trust for any rpm, which is afaik what happens when someone imports a gpg key into rpm. Also do not distribute rpms via unsecure channels to my machines and having a third private gpg key for this without gaining much. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From dlutter at redhat.com Mon May 19 21:21:56 2008 From: dlutter at redhat.com (David Lutterkort) Date: Mon, 19 May 2008 21:21:56 +0000 Subject: hook into rpm install/update/deletion of any package (for etckeeper) In-Reply-To: <20080519184747.GD1519793@hiwaay.net> References: <200805192002.44554.opensource@till.name> <1211220705.3095.9.camel@cutter> <200805192031.36555.opensource@till.name> <20080519184747.GD1519793@hiwaay.net> Message-ID: <1211232116.29522.246.camel@localhost.localdomain> On Mon, 2008-05-19 at 13:47 -0500, Chris Adams wrote: > Once upon a time, Till Maas said: > > I knew there are yum plugins and etckeeper will probably need one, but it > > would not be enough for me, because I also often install packages via rpm > > when I built them myself. > > You could write a daemon that monitors /etc with inotify. Alternately, > replace rpm with a wrapper script that does your monitoring. If you want that, cft[1] is your friend - it does exactly what you suggest. David [1] http://cft.et.redhat.com/ From ob.system at gmail.com Mon May 19 21:30:39 2008 From: ob.system at gmail.com (Oscar Victorio Calixto Bacho) Date: Mon, 19 May 2008 17:30:39 -0400 Subject: yum --skip-boken not work Message-ID: <6a28481b0805191430m702db96fvc5a56b4bc5ad7388@mail.gmail.com> Hi Guy yum --skip-broken update no work in today rawhide. exit said Skip-broken could not solve problems. It is totem problem. Oscar -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundaram at fedoraproject.org Mon May 19 21:33:00 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 20 May 2008 03:03:00 +0530 Subject: yum --skip-boken not work In-Reply-To: <6a28481b0805191430m702db96fvc5a56b4bc5ad7388@mail.gmail.com> References: <6a28481b0805191430m702db96fvc5a56b4bc5ad7388@mail.gmail.com> Message-ID: <4831F20C.2080604@fedoraproject.org> Oscar Victorio Calixto Bacho wrote: > Hi Guy > > yum --skip-broken update no work in today rawhide. > > exit said Skip-broken could not solve problems. It is totem problem. Providing the actual output would be useful. Rahul From lsof at nodata.co.uk Mon May 19 21:41:03 2008 From: lsof at nodata.co.uk (nodata) Date: Mon, 19 May 2008 23:41:03 +0200 Subject: rhgb no more In-Reply-To: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> Message-ID: <1211233263.5675.2.camel@sb-home> *ARGH!* Am Dienstag, den 13.05.2008, 13:07 -0400 schrieb Ray Strode: > 2) Hiding boot messages before gdm unless escape key is pressed. For So can you log them instead? (expletives goe here) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=151238 From ob.system at gmail.com Mon May 19 21:42:28 2008 From: ob.system at gmail.com (Oscar Victorio Calixto Bacho) Date: Mon, 19 May 2008 16:42:28 -0500 Subject: yum --skip-boken not work In-Reply-To: <4831F20C.2080604@fedoraproject.org> References: <6a28481b0805191430m702db96fvc5a56b4bc5ad7388@mail.gmail.com> <4831F20C.2080604@fedoraproject.org> Message-ID: <6a28481b0805191442o6b2052daq389c759c185b28ab@mail.gmail.com> Providing the actual output would be useful. > > Output: Skip-broken could not solve problems Error: Missing Dependency: libtotem-plparser.so.10 is needed by package totem-mozplugin-2.23.2-2.fc9.i386 (installed) Error: Missing Dependency: libtotem-plparser-mini.so.10 is needed by package totem-mozplugin-2.23.2-2.fc9.i386 (installed) Error: Missing Dependency: libtotem-plparser.so.10 is needed by package totem-nautilus-2.23.2-2.fc9.i386 (installed) Error: Missing Dependency: libtotem-plparser.so.10 is needed by package totem-2.23.2-2.fc9.i386 (installed) -------------- next part -------------- An HTML attachment was scrubbed... URL: From notting at redhat.com Mon May 19 21:58:03 2008 From: notting at redhat.com (Bill Nottingham) Date: Mon, 19 May 2008 17:58:03 -0400 Subject: rhgb no more In-Reply-To: <1211233263.5675.2.camel@sb-home> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> <1211233263.5675.2.camel@sb-home> Message-ID: <20080519215803.GQ27865@nostromo.devel.redhat.com> nodata (lsof at nodata.co.uk) said: > So can you log them instead? (expletives goe here) Yes, because cursing in people's faces is the best way to get your issues' attention. Yes, it's still not there. Yes, it sucks. Yes, I'm in some respects to blame. Once we get a solution that: - doesn't slow down boot excessively - doesn't cause issues with SELinux - actually works sanely it will be fixed. FYI, fixing this with upstart's logging was investigated during Fedora 9, but that was even *more* broken. Bill From mitr at volny.cz Mon May 19 22:08:38 2008 From: mitr at volny.cz (Miloslav =?UTF-8?Q?Trma=C4=8D?=) Date: Tue, 20 May 2008 00:08:38 +0200 Subject: boot.log (was Re: rhgb no more) In-Reply-To: <1211233263.5675.2.camel@sb-home> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> <1211233263.5675.2.camel@sb-home> Message-ID: <1211234918.11744.80.camel@amilo> nodata p??e v Po 19. 05. 2008 v 23:41 +0200: > So can you log them instead? (expletives goe here) > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=151238 This is becoming one of those tiresome bugs. Frankly, boot.log is _not_ that important, compared to many other bugs. If your system must be 100% reliable and you need to diagnose every problem, you need a logged remote console to capture kernel crashes and other urgent kernel messages. In other cases, just restarting the service/server and watching the output is usable, even if not perfect. The package maintainer has decided the bug is not that important, and has closed it _twice_ already. Screaming the bug is critical (without providing any arguments) doesn't make it so. As a maintainer eventually learns, you can't win a reopen war by closing the bug; you just train your eyes to skip the bug in your queries. So, this is Fedora - the best way to make this work is to provide working code. RHEL users can contact Red Hat support if they need boot.log for some reason - but, you might be surprised, it seems no RHEL user has asked Red Hat support to make boot.log work, at least as far as I can see. Mirek From wtogami at redhat.com Mon May 19 22:26:56 2008 From: wtogami at redhat.com (Warren Togami) Date: Mon, 19 May 2008 18:26:56 -0400 Subject: Fedora's vmlinuz broken with mkelfimage Message-ID: <4831FEB0.3030506@redhat.com> https://fedorahosted.org/k12linux/wiki/Notes/Coreboot Something about Fedora's vmlinuz fails to load the initrd when it is wrapped with mkelfimage. Full details at this page. mkelfimage is necessary to wrap the vmlinuz and initrd into a single bootable image if your hardware uses coreboot. qemu network booting exhibits the same broken behavior, so this should be easy for others to test without special coreboot hardware. My latest theory: Something about how the Fedora kernel is configured or built made it incompatible with mkelfimage. Ubuntu's recent kernels work while our Fedora kernels from F8 (and possibly all the way back to 2006 as OLPC encountered) are broken. http://people.redhat.com/wtogami/temp/config-2.6.24-16-generic Here is Ubuntu's kernel config file if anyone wants to compare it. Any ideas? Warren Togami wtogami at redhat.com From nicolas.mailhot at laposte.net Mon May 19 22:35:03 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 20 May 2008 00:35:03 +0200 (CEST) Subject: yum --skip-boken not work In-Reply-To: <6a28481b0805191430m702db96fvc5a56b4bc5ad7388@mail.gmail.com> References: <6a28481b0805191430m702db96fvc5a56b4bc5ad7388@mail.gmail.com> Message-ID: <43786.81.64.151.204.1211236503.squirrel@rousalka.dyndns.org> Le Lun 19 mai 2008 23:30, Oscar Victorio Calixto Bacho a ?crit : > Hi Guy > > yum --skip-broken update no work in today rawhide. > > exit said Skip-broken could not solve problems. It is totem problem. you need to use something like # yum --skip-broken -y update -x totem-pl-parser -x evolution-data-server -x evolution -x openssh-server -x rhythmbox -x ekiga -x evolution-webcal -x brasero -x pidgin -x gnome-panel -x control-center in rawhide like now. How did I arrive there? Because I'm smarter than the skip-broken algorithm. skip-broken is too dumb to realise that since totem-pl-parser can't be updated (because totem depends on the old version) it needs to be excluded. And once it's excluded all the new packages that depended directly or indirectly on totem-pl-parser need to be excluded too. So skip broken probably needs enhancing. I should do "if new bar can not be installed because foo(installed) depends on old bar exclude bar from the transaction ; if new baz can not be installed because it depended on now excluded new bar exclude it too. etc" Real-world non-cooked example: # yum --skip-broken -y update ? Skip-broken could not solve problems Error: Missing Dependency: pam >= 1.0.1-3 is needed by package openssh-server-5.0p1-2.fc10.x86_64 (rawhide) Error: Missing Dependency: libtotem-plparser.so.10()(64bit) is needed by package totem-2.23.2-3.fc9.x86_64 (installed) Error: Missing Dependency: libtotem-plparser.so.10()(64bit) is needed by package totem-nautilus-2.23.2-3.fc9.x86_64 (installed) Focus on (installed) conflicts first # rpm -q --whatprovides /usr/lib64/libtotem-plparser.so.10 totem-pl-parser-2.22.2-1.fc9.x86_64 # yum --skip-broken -y update -x totem-pl-parser ? Skip-broken could not solve problems Error: Missing Dependency: pam >= 1.0.1-3 is needed by package openssh-server-5.0p1-2.fc10.x86_64 (rawhide) Error: Missing Dependency: libcamel-1.2.so.11()(64bit) is needed by package totem-pl-parser-2.22.2-1.fc9.x86_64 (installed) Error: Missing Dependency: libtotem-plparser.so.12()(64bit) is needed by package brasero-0.7.1-4.fc10.x86_64 (rawhide) Error: Missing Dependency: libedataserver-1.2.so.9()(64bit) is needed by package totem-pl-parser-2.22.2-1.fc9.x86_64 (installed) Error: Missing Dependency: libtotem-plparser.so.12()(64bit) is needed by package rhythmbox-0.11.5-14.fc10.x86_64 (rawhide) # rpm -q --whatprovides /usr/lib64/libcamel-1.2.so.11 evolution-data-server-2.22.1-2.fc9.x86_64 # yum --skip-broken -y update -x totem-pl-parser -x evolution-data-server ? Skip-broken could not solve problems Error: Missing Dependency: libcamel-provider-1.2.so.12()(64bit) is needed by package evolution-2.23.2-1.fc10.x86_64 (rawhide) Error: Missing Dependency: pam >= 1.0.1-3 is needed by package openssh-server-5.0p1-2.fc10.x86_64 (rawhide) Error: Missing Dependency: libtotem-plparser.so.12()(64bit) is needed by package rhythmbox-0.11.5-14.fc10.x86_64 (rawhide) Error: Missing Dependency: libedataserver-1.2.so.11()(64bit) is needed by package ekiga-2.0.12-2.fc10.x86_64 (rawhide) Error: Missing Dependency: libedataserver-1.2.so.11()(64bit) is needed by package evolution-webcal-2.21.92-2.fc10.x86_64 (rawhide) Error: Missing Dependency: libtotem-plparser.so.12()(64bit) is needed by package brasero-0.7.1-4.fc10.x86_64 (rawhide) Error: Missing Dependency: libebackend-1.2.so.0()(64bit) is needed by package pidgin-2.4.2-1.fc10.x86_64 (rawhide) Error: Missing Dependency: evolution-data-server >= 2.23.1 is needed by package evolution-2.23.2-1.fc10.x86_64 (rawhide) Error: Missing Dependency: libedataserver-1.2.so.11()(64bit) is needed by package gnome-panel-2.23.2.1-1.fc10.x86_64 (rawhide) Error: Missing Dependency: libedataserver-1.2.so.11()(64bit) is needed by package evolution-2.23.2-1.fc10.x86_64 (rawhide) Error: Missing Dependency: libcamel-1.2.so.12()(64bit) is needed by package evolution-2.23.2-1.fc10.x86_64 (rawhide) Error: Missing Dependency: libedataserver-1.2.so.11()(64bit) is needed by package 1:control-center-2.23.1-4.fc10.x86_64 (rawhide) Error: Missing Dependency: libedataserver-1.2.so.11()(64bit) is needed by package pidgin-2.4.2-1.fc10.x86_64 (rawhide) No remaining (installed) problems. Time to kill the new stuff # yum --skip-broken -y update -x totem-pl-parser -x evolution-data-server -x evolution -x openssh-server -x rhythmbox -x ekiga -x evolution-webcal -x brasero -x pidgin -x gnome-panel -x control-center ? Packages skipped because of dependency problems: 1:control-center-filesystem-2.23.1-4.fc10.x86_64 from rawhide 1:gnome-applets-2.23.2-1.fc10.x86_64 from rawhide gnome-screensaver-2.23.3-0.2008.05.14.1.fc10.x86_64 from rawhide gnome-settings-daemon-2.23.2-0.2008.05.14.2.fc10.x86_64 from rawhide libgnomekbd-2.23.2-1.fc10.x86_64 from rawhide libgnomekbd-2.23.2-1.fc10.x86_64 from rawhide libpurple-2.4.2-1.fc10.x86_64 from rawhide openssh-5.0p1-2.fc10.x86_64 from rawhide openssh-askpass-5.0p1-2.fc10.x86_64 from rawhide openssh-clients-5.0p1-2.fc10.x86_64 from rawhide ? Transaction Summary ============================================================================= Install 9 Package(s) Update 18 Package(s) Remove 0 Package(s) It works! -- Nicolas Mailhot From ob.system at gmail.com Mon May 19 22:51:17 2008 From: ob.system at gmail.com (Oscar Victorio Calixto Bacho) Date: Mon, 19 May 2008 17:51:17 -0500 Subject: yum --skip-boken not work In-Reply-To: <43786.81.64.151.204.1211236503.squirrel@rousalka.dyndns.org> References: <6a28481b0805191430m702db96fvc5a56b4bc5ad7388@mail.gmail.com> <43786.81.64.151.204.1211236503.squirrel@rousalka.dyndns.org> Message-ID: <6a28481b0805191551r6a6f8056qe4957051162f2b64@mail.gmail.com> It works! > Thanks .. -------------- next part -------------- An HTML attachment was scrubbed... URL: From halfline at gmail.com Mon May 19 23:03:21 2008 From: halfline at gmail.com (Ray Strode) Date: Mon, 19 May 2008 19:03:21 -0400 Subject: rhgb no more In-Reply-To: <1211233263.5675.2.camel@sb-home> References: <45abe7d80805131007s7ffca4a5mb19165597e0c7985@mail.gmail.com> <1211233263.5675.2.camel@sb-home> Message-ID: <45abe7d80805191603o7265c4eav545ca174de6a693a@mail.gmail.com> Hi, On Mon, May 19, 2008 at 5:41 PM, nodata wrote: > *ARGH!* > > Am Dienstag, den 13.05.2008, 13:07 -0400 schrieb Ray Strode: >> 2) Hiding boot messages before gdm unless escape key is pressed. For > > So can you log them instead? (expletives goe here) Yes, they will be logged automatically. --Ray From bpepple at fedoraproject.org Mon May 19 23:34:20 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 19 May 2008 19:34:20 -0400 Subject: [2nd Reminder] FESCo Nominations Message-ID: <1211240060.5645.3.camel@kennedy> Hi all, This is a reminder that the nomination period for the upcoming FESCo election is still underway, and lasts until June 1st, 2008 0:00 UTC. If you wish to run for FESCo, please place your nomination on this page in the wiki: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Nominations For more information regarding the election, please refer to: http://fedoraproject.org/wiki/PackageMaintainers/Policy/FESCoElections Thanks, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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: 197 bytes Desc: This is a digitally signed message part URL: From paul at xelerance.com Tue May 20 00:09:04 2008 From: paul at xelerance.com (Paul Wouters) Date: Mon, 19 May 2008 20:09:04 -0400 (EDT) Subject: F9 potential service network bug? In-Reply-To: <20080519190107.GF27865@nostromo.devel.redhat.com> References: <3da3b5b40805161502w62f372dseca0ab6310e44447@mail.gmail.com> <1210975852.6805.10.camel@localhost.localdomain> <3da3b5b40805161522i2300f1cdhb1fc7b074084873f@mail.gmail.com> <604aa7910805161527j6b193c6dj2af4248155d5cdaf@mail.gmail.com> <1210989429.24740.14.camel@localhost.localdomain> <20080519190107.GF27865@nostromo.devel.redhat.com> Message-ID: On Mon, 19 May 2008, Bill Nottingham wrote: > > ONBOOT=yes > > > > To me it looked like despite being confgured with BOOTPROTO=static, the > > avahi daemon and NetworkManager got started, and one of them started > > doing dhcp. The static IP did appear as an additiona IP on the eth1 > > interface, but since the DHCP was the main address, my public ip address > > changed. > > ONBOOT=no means that NM won't try to automatically bring it up. That > may be what you're seeing. Are you saying that ONBOOT= changed its meaning from "start at boot or not" to "start at boot, but either with NM or without" ? What combination of BOOTPROTO= and ONBOOT= will both "start on boot" and "not use NM"? BOOTPROTO=static and ONBOOT=no. That would be odd (and breaking the API for ONBOOT without a proper migration on update) Paul From dcbw at redhat.com Tue May 20 00:57:56 2008 From: dcbw at redhat.com (Dan Williams) Date: Mon, 19 May 2008 20:57:56 -0400 Subject: F9 potential service network bug? In-Reply-To: References: <3da3b5b40805161502w62f372dseca0ab6310e44447@mail.gmail.com> <1210975852.6805.10.camel@localhost.localdomain> <3da3b5b40805161522i2300f1cdhb1fc7b074084873f@mail.gmail.com> <604aa7910805161527j6b193c6dj2af4248155d5cdaf@mail.gmail.com> <1210989429.24740.14.camel@localhost.localdomain> <20080519190107.GF27865@nostromo.devel.redhat.com> Message-ID: <1211245076.10827.32.camel@localhost.localdomain> On Mon, 2008-05-19 at 20:09 -0400, Paul Wouters wrote: > On Mon, 19 May 2008, Bill Nottingham wrote: > > > > ONBOOT=yes > > > > > > To me it looked like despite being confgured with BOOTPROTO=static, the > > > avahi daemon and NetworkManager got started, and one of them started > > > doing dhcp. The static IP did appear as an additiona IP on the eth1 > > > interface, but since the DHCP was the main address, my public ip address > > > changed. > > > > ONBOOT=no means that NM won't try to automatically bring it up. That > > may be what you're seeing. > > Are you saying that ONBOOT= changed its meaning from "start at boot or not" > to "start at boot, but either with NM or without" ? NM interprets ONBOOT=no as "don't autoconnect this configuration". They are just about the same thing. If you mark ONBOOT=no then NM won't bring the device up on boot. > What combination of BOOTPROTO= and ONBOOT= will both "start on boot" and > "not use NM"? BOOTPROTO=static and ONBOOT=no. That would be odd (and breaking > the API for ONBOOT without a proper migration on update) Try: NM_CONTROLLED=no ONBOOT=yes Dan From dimi at lattica.com Tue May 20 05:11:23 2008 From: dimi at lattica.com (Dimi Paun) Date: Tue, 20 May 2008 01:11:23 -0400 Subject: Glitch-Free PulseAudio in Rawhide In-Reply-To: <20080518200225.GC19530@tango.0pointer.de> References: <20080517101616.GA16071@tango.0pointer.de> <20080518200225.GC19530@tango.0pointer.de> Message-ID: <1211260283.6534.46.camel@dimi.lattica.com> On Sun, 2008-05-18 at 22:02 +0200, Lennart Poettering wrote: > Also, if you claim that I neglect longstanding important bugs, then > please be more specific and tell me exactly the bug numbers. https://bugzilla.redhat.com/show_bug.cgi?id=438594 PA crashes mathematically for me, and nobody seems to care, despite the fact that I run a fairly standard Fedora 8. The user experience is horrible too: * PA decides the exit/crash at random * Rhythmbox locks up hard, sometimes using 100% CPU * Volume Control gives a cryptic error about a connection being lost * Skype no longer works, in strange ways (i.e. Sound In fails) * Unless you know (how?!?) that you need a 'pulseaudio -D', you have to reboot the machine to get working sound And all this happens after 1-2h of listening to stuff. -- Dimi Paun Lattica, Inc. From kevin.kofler at chello.at Tue May 20 05:47:35 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 20 May 2008 05:47:35 +0000 (UTC) Subject: Glitch-Free PulseAudio in Rawhide References: <20080517101616.GA16071@tango.0pointer.de> <20080518200225.GC19530@tango.0pointer.de> Message-ID: Lennart Poettering 0pointer.de> writes: > Also, if you claim that I neglect longstanding important bugs, then > please be more specific and tell me exactly the bug numbers. There's this one: https://bugzilla.redhat.com/show_bug.cgi?id=438284 "Sometimes, PulseAudio fails to start" It might actually be a symptom of several completely different bugs. What I'm seeing in KDE is that sometimes, for no apparent reason, no PA is running, starting it with pulseaudio -D just starts it. But that only happens sometimes. I know this is not very useful as a bug report, I'll have to check the logs more carefully to see if I can figure out what happens: maybe PA starts up and then kills itself due to CPU overload? I'll let you know once I figure out more. Then there's this weird issue: https://bugzilla.redhat.com/show_bug.cgi?id=361891 The setup aRts->ALSA->alsa-plugins-pulseaudio->PA usually works (with very low CPU consumption), but sometimes the aRts process runs amok on the CPU (using over 90% CPU) and ends up killing itself due to CPU overload. This does NOT happen if you run aRts on the ALSA hardware device. Now it's hard to tell where exactly in the stack the bug is. And yes, we've tried setting up aRts to use the ESD protocol instead, that was even worse. Any ideas? (And I know aRts is legacy stuff, it might become less of an issue over time, still it would be nice if we could get the issues with the aRts+PA setup fixed.) If you think aRts is broken, we can of course fix it, but we need to know what's broken and why this only happens with PA. Kevin Kofler From seg at haxxed.com Tue May 20 06:05:06 2008 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 20 May 2008 01:05:06 -0500 Subject: Glitch-Free PulseAudio in Rawhide In-Reply-To: <1211260283.6534.46.camel@dimi.lattica.com> References: <20080517101616.GA16071@tango.0pointer.de> <20080518200225.GC19530@tango.0pointer.de> <1211260283.6534.46.camel@dimi.lattica.com> Message-ID: <1218b5bc0805192305g4a12aa19h5e50c7f68b676418@mail.gmail.com> On Tue, May 20, 2008 at 12:11 AM, Dimi Paun wrote: > The user experience is horrible too: > * PA decides the exit/crash at random > * Rhythmbox locks up hard, sometimes using 100% CPU > * Volume Control gives a cryptic error about a connection being lost > * Skype no longer works, in strange ways (i.e. Sound In fails) > * Unless you know (how?!?) that you need a 'pulseaudio -D', you > have to reboot the machine to get working sound Yes, PA suffers from "perfect programmer" syndrome. It fails at graceful failure recovery. You get cryptic errors when it dies, and offers no obvious way to restart it. Why is it not auto-restarted by the session manager? That would take care of things if it dies, but not if it wedges solid like what happened to me once. Did the lock file cleanup problem get fixed? I've taken to nuking PA off all my systems that support multiple channels in hardware. PA doesn't even take advantage of that. Aureal forever. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.kofler at chello.at Tue May 20 06:22:35 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 20 May 2008 06:22:35 +0000 (UTC) Subject: Glitch-Free PulseAudio in Rawhide References: <20080517101616.GA16071@tango.0pointer.de> <20080518200225.GC19530@tango.0pointer.de> <1211260283.6534.46.camel@dimi.lattica.com> <1218b5bc0805192305g4a12aa19h5e50c7f68b676418@mail.gmail.com> Message-ID: Callum Lerwick haxxed.com> writes: > Why is it not auto-restarted by the session manager? Or autospawned by the client library like aRts does. PA even supports this, why is this not the default? Yes, in a perfect world, PA should not crash, but respawning it if it did (maybe with a passive notification that PA had to be respawned because it crashed, bonus points if you can display the crash reason for things like aborts or assertion failures) is the robust way to handle things. Kevin Kofler From lemenkov at gmail.com Tue May 20 06:49:56 2008 From: lemenkov at gmail.com (Peter Lemenkov) Date: Tue, 20 May 2008 10:49:56 +0400 Subject: FYI: Possibility for SSL spoofing in recent Firefox 3 Message-ID: Hello All! For those who doesn't read blog at StartCom here is an interesting post: https://blog.startcom.org/?p=86 Looks like the designers of Firefox 3 did some questionable changes in design of Firefox 3. -- With best regards! From peter at thecodergeek.com Tue May 20 06:49:57 2008 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 19 May 2008 23:49:57 -0700 Subject: Offline: 2008-05-28 Through 2008-06-03 Message-ID: <1211266197.3448.44.camel@werewolf> Hi, all. As I posted on the Vacation wiki page, I'll be gone from May 28 through June 3 (or 2008-05-28 through 2008-06-03 for those that prefer ISO-8601 dates). I'm heading to New Jersey/New York to visit family, and will probably not have any 'Net access while there; but if so, it'll only be email checking and similar. I won't bring my electronic keys or certificates with me, so I'll have no commit or build capabilities while I'm away. I'd greatly appreciate it if the Fedora community would care for my packages [1] whilst I am away, especially watching for any security/crasher fixes or the like that may need swift action. Thanks! [1] https://admin.fedoraproject.org/pkgdb/users/packages/pgordon -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mike at cchtml.com Tue May 20 07:18:48 2008 From: mike at cchtml.com (Mike Cronenworth) Date: Tue, 20 May 2008 02:18:48 -0500 Subject: FYI: Possibility for SSL spoofing in recent Firefox 3 In-Reply-To: References: Message-ID: <48327B58.9050505@cchtml.com> -------- Original Message -------- Subject: FYI: Possibility for SSL spoofing in recent Firefox 3 From: Peter Lemenkov To: Development discussions related to Fedora Date: 05/20/2008 01:49 AM > Hello All! > For those who doesn't read blog at StartCom here is an interesting post: > > https://blog.startcom.org/?p=86 > > Looks like the designers of Firefox 3 did some questionable changes in > design of Firefox 3. > > Can ya digg it? (front page would guarantee some public traffic that would move Mozilla) http://digg.com/security/Firefox_3_RC1_Allows_Easier_SSL_Spoofing_Mozilla_Won_t_Fix Added a touch of sensationalism to the title for an added kick. From bruno at wolff.to Tue May 20 07:40:42 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Tue, 20 May 2008 02:40:42 -0500 Subject: FYI: Possibility for SSL spoofing in recent Firefox 3 In-Reply-To: References: Message-ID: <20080520074042.GE3504@wolff.to> On Tue, May 20, 2008 at 10:49:56 +0400, Peter Lemenkov wrote: > Hello All! > For those who doesn't read blog at StartCom here is an interesting post: > > https://blog.startcom.org/?p=86 > > Looks like the designers of Firefox 3 did some questionable changes in > design of Firefox 3. If you are looking at colored address bars or padlock icons to decide if you are at the site you intend to be, you are doing things incorrectly. Firefox 3 is actually better at letting you check you are at a site you intend to be, since it lets you both remove all of the root CA's and allows you to individually save certificates, so that you will actually notice when you see a new one and can carefully check it if you desire. This is still clunky, but its actually more useful than just relying on the site you are visiting paying protection money. From jamatos at fc.up.pt Tue May 20 08:15:45 2008 From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=) Date: Tue, 20 May 2008 09:15:45 +0100 Subject: yum --skip-boken not work In-Reply-To: <43786.81.64.151.204.1211236503.squirrel@rousalka.dyndns.org> References: <6a28481b0805191430m702db96fvc5a56b4bc5ad7388@mail.gmail.com> <43786.81.64.151.204.1211236503.squirrel@rousalka.dyndns.org> Message-ID: <200805200915.45970.jamatos@fc.up.pt> On Monday 19 May 2008 23:35:03 Nicolas Mailhot wrote: > Le Lun 19 mai 2008 23:30, Oscar Victorio Calixto Bacho a ?crit : > > Hi Guy > > > > yum --skip-broken update no work in today rawhide. > > > > exit said Skip-broken could not solve problems. It is totem problem. > > you need to use something like > > # yum --skip-broken -y update -x totem-pl-parser -x > evolution-data-server -x evolution -x openssh-server -x rhythmbox -x > ekiga -x evolution-webcal -x brasero -x pidgin -x gnome-panel -x > control-center > > in rawhide like now. How did I arrive there? Because I'm smarter than > the skip-broken algorithm. > > skip-broken is too dumb to realise that since totem-pl-parser can't be > updated (because totem depends on the old version) it needs to be > excluded. And once it's excluded all the new packages that depended > directly or indirectly on totem-pl-parser need to be excluded too. Actually if you update some packages in a separate transaction, and repeat this procedure, at a certain point --skip-broken will correctly exclude all those packages that you have excluded manually. So there is here some kind of threshold but I was unable to determine which one or what package was the culprit. > -- > Nicolas Mailhot -- Jos? Ab?lio From rjones at redhat.com Tue May 20 09:03:29 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 20 May 2008 10:03:29 +0100 Subject: Policy on Bodhi? Message-ID: <20080520090329.GA24612@amd.home.annexia.org> Is there a policy on Bodhi? I don't mean how to use it, I mean questions such as: - How long packages should stay in each state (pending / testing / updates)? - Can I push a package directly into a stable update without waiting around for testing? (if I know there's not going to be many testers, and I need it as a dep for another package) - Is it allowed / not-allowed to troll users into adding karma? Or at least to encourage them to put comments? Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From lordmorgul at gmail.com Tue May 20 09:12:06 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Tue, 20 May 2008 02:12:06 -0700 Subject: F8 -> F9 but keeping KDE3: technically feasible? In-Reply-To: <483076E8.70601@robertoragusa.it> References: <483076E8.70601@robertoragusa.it> Message-ID: <483295E6.8030404@gmail.com> Roberto Ragusa wrote: > Hi all, > > do you think it can be possible to upgrade a F8 to F9 with > exclusion of the KDE packages? > > My idea would be to keep qt, qt4 and kde* packages from F8, > and upgrade all the rest. > Will I run into serious issues about collateral dependencies, > e.g. pulseaudio<->artsd, NM, misc dbus/hal things, etc...? > > What is the best way to attempt such a thing? > Can I run anaconda in a "minimal" mode to upgrade > only the basic stuff and then proceed with yum? > Upgrade F8->F9 exclusively via yum? > > Hints kindly accepted. I believe you would have to go about this by running several (maybe many) yum upgrades separately. There is no good way to get that upgrade done with anaconda. You would need to construct some careful excludes for those yum upgrades so it would force those packages, and anything that depend on them, to get skipped. It probably will not be pretty.. it probably will take you forever to work through the upgrade.. and it will probably cause lots of packages to fail for deps. You're going to end up with a hybrid of F8/F9 that might be mostly F8 (at least as far as the kde apps or anything qt based are concerned you won't upgrade anything). You might run into issues due to glibc and the gcc change that will stop you cold, I don't know. Best way to find out is try running some yum commands without confirming the changes and see what a messy list of dependency problems you get. -- Andrew Farris www.lordmorgul.net gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29 From rjones at redhat.com Tue May 20 09:37:05 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 20 May 2008 10:37:05 +0100 Subject: Bodhi spam? Message-ID: <20080520093705.GA25663@amd.home.annexia.org> [Two unrelated Bodhi questions in the space of a few minutes ...] Is someone able to spam Bodhi? See: https://admin.fedoraproject.org/updates/F8/pending/ocaml-libvirt-0.4.1.1-2.fc8 Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From mzerqung at 0pointer.de Tue May 20 09:52:00 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 20 May 2008 11:52:00 +0200 Subject: Glitch-Free PulseAudio in Rawhide In-Reply-To: References: <20080517101616.GA16071@tango.0pointer.de> <20080518200225.GC19530@tango.0pointer.de> <1211260283.6534.46.camel@dimi.lattica.com> <1218b5bc0805192305g4a12aa19h5e50c7f68b676418@mail.gmail.com> Message-ID: <20080520095200.GA13762@tango.0pointer.de> On Tue, 20.05.08 06:22, Kevin Kofler (kevin.kofler at chello.at) wrote: > > Callum Lerwick haxxed.com> writes: > > Why is it not auto-restarted by the session manager? > > Or autospawned by the client library like aRts does. PA even supports this, why > is this not the default? Yes, in a perfect world, PA should not crash, but > respawning it if it did (maybe with a passive notification that PA had to be > respawned because it crashed, bonus points if you can display the crash reason > for things like aborts or assertion failures) is the robust way to handle > things. Because auto-spawning tapes over bugs. And it really should be run on session startup, not delayed until the first client connects. Why? Because there are certain services PA provides that are not dependant on local client usage. i.e. availability over the network, executing policy code one hardware pluggin, and so on and so on. And just respawning when we crash is taping over bugs, too. I am not generally opposed to it, though. However I fear it won't help much since PA's state is lost and thus all music would stop playing anyway. Most importantly however, PA is still run via a shell script "esd" from gnome-session, but not session managed. This certainly needs fixing. Regarding auto-spawning: most likely I will enable auto-spawning by default pretty soon -- but not because I like taping over bugs, but instead because we need better support of PA on the console, the a11y people need that. We don't have no session manager on the console, so it's difficult to start PA from one. It is going to be in addition to be started fro gnome-session. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From rawhide at fedoraproject.org Tue May 20 10:22:45 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Tue, 20 May 2008 10:22:45 +0000 (UTC) Subject: rawhide report: 20080520 changes Message-ID: <20080520102245.C6395209D29@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080519/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080520/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package ucview Image and video capture application using unicap toolkit New package perl-Math-BigInt-GMP Math::BigInt::GMP Perl module New package perl-Net-FTPServer Secure, extensible and configurable Perl FTP server New package cflow Analyzes C files charting control flow within the program New package aspell-ml GNU Aspell Malayalam Dictionary Package New package sublib A subtitle library New package gnome-subtitles Subtitle editor for Gnome New package perl-Parse-CPAN-Meta Parse META.yml and other similar CPAN metadata files New package virt-df Utility like 'df' for virtual guests Removed package evolution-python Updated Packages: gnome-packagekit-0.2.2-1.20080519.fc10 -------------------------------------- * Mon May 19 18:00:00 2008 Richard Hughes - 0.2.2-1.20080519 - Pull in a new snapshot from the unstable branch. * Fri May 16 18:00:00 2008 Richard Hughes - 0.2.1-3.20080508 - Add a BR on unique to make the client tools single instance xorg-x11-drv-nouveau-0.0.10-3.20080520git9c1d87f.fc10 ----------------------------------------------------- * Tue May 20 18:00:00 2008 Dave Airlie 0.0.10-3.20080520git9c1d87f - update to latest snapshot - enables randr12 asterisk-1.6.0-0.14.beta9.fc10 ------------------------------ * Mon May 19 18:00:00 2008 Jeffrey C. Ollie - 1.6.0-0.14.beta9 - Update to 1.6.0-beta9. - Update patches so that they apply cleanly. - Temporarily disable app_conference patch as it doesn't compile - config/scripts/postgres_cdr.sql has been merged into realtime_pgsql.sql - Re-add the asterisk-strip.sh script as a source file. lucene-2.3.1-3jpp.0.fc10 ------------------------ * Mon May 19 18:00:00 2008 Lubomir Rintel - 0:2.3.1-3jpp.0 - Correct gcj-compat dependencies, so that this builds on RHEL - Use --without gcj to disable gcj aot compilation efreet-0.5.0.043-1.fc10 ----------------------- * Mon May 19 18:00:00 2008 Pavel "Stalwart" Shevchuk - 0.5.0.043-1 - New upstream snapshot screen-4.0.3-12.fc10 -------------------- * Fri May 16 18:00:00 2008 Miroslav Lichvar - 4.0.3-12 - fix multiuser support (#446049) - fix building with new autoconf tk-8.5.2-1.fc10 --------------- * Mon May 19 18:00:00 2008 Marcela Maslanova - 1:8.5.2-1 - new version tk8.5.2 e_dbus-0.5.0.043-1.fc10 ----------------------- * Mon May 19 18:00:00 2008 Pavel "Stalwart" Shevchuk - 0.5.0.043-1 - New upstream snapshot nexuiz-2.4.2-1.fc10 ------------------- * Mon May 19 18:00:00 2008 Jon Ciesla - 2.4.2-1 - New upstream release. nexuiz-data-2.4.2-1.fc10 ------------------------ * Mon May 19 18:00:00 2008 Jon Ciesla - 2.4.2-1 - New upstream release. blender-2.46-1.fc10 ------------------- * Mon May 19 18:00:00 2008 Jochen Schmitt - 2.46-1 - New upstream release * Wed May 7 18:00:00 2008 Jochen Schmitt 2.46-0.3.1 - Some fixes for CVE-2008-1003 Broken deps for i386 ---------------------------------------------------------- LabPlot-1.5.1.6-4.fc8.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libMagick.so.10 basket-kontact-1.0.2-5.fc9.i386 requires libkpinterfaces.so.1 basket-kontact-1.0.2-5.fc9.i386 requires libkcal.so.2 basket-kontact-1.0.2-5.fc9.i386 requires libktnef.so.1 basket-kontact-1.0.2-5.fc9.i386 requires kdepim3 basket-kontact-1.0.2-5.fc9.i386 requires libkdepim.so.1 conduit-0.3.10-1.fc10.noarch requires gnome-python-desktop conduit-0.3.10-1.fc10.noarch requires gnome-python-extras edje-0.5.0.042-3.fc10.i386 requires libecore_directfb.so.0 epsilon-0.3.0.012-3.fc10.i386 requires libecore_directfb.so.0 epsilon-xine-0.3.0.012-3.fc10.i386 requires libecore_directfb.so.0 evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.i386 requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-1.2.so.11 kipi-plugins-0.1.5-2.fc10.i386 requires libkcal.so.2 kismet-extras-0.0.2007.10.R1-3.fc9.i386 requires libMagick.so.10 koffice-karbon-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-karbon-1.6.3-15.fc9.i386 requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libMagick.so.10 libopensync-plugin-kdepim-0.35-2.fc9.i386 requires libkcal.so.2 openssh-server-5.0p1-2.fc10.i386 requires pam >= 0:1.0.1-3 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) qgis-0.9.1-5.fc9.i386 requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.i386 requires libgeos.so.2 taskjuggler-2.4.1-1.fc10.i386 requires libkcal.so.2 taskjuggler-2.4.1-1.fc10.i386 requires libktnef.so.1 taskjuggler-libs-2.4.1-1.fc10.i386 requires libkcal.so.2 tellico-1.3.1-1.fc9.i386 requires libkcal.so.2 tellico-1.3.1-1.fc9.i386 requires libktnef.so.1 totem-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 totem-mozplugin-2.23.2-2.fc9.i386 requires libtotem-plparser-mini.so.10 totem-mozplugin-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 totem-nautilus-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 Broken deps for x86_64 ---------------------------------------------------------- LabPlot-1.5.1.6-4.fc8.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libMagick.so.10 LabPlot-1.5.1.6-4.fc8.x86_64 requires libMagick++.so.10()(64bit) LabPlot-1.5.1.6-4.fc8.x86_64 requires libMagick.so.10()(64bit) LabPlot-1.5.1.6-4.fc8.x86_64 requires libWand.so.10()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires libkcal.so.2()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires libkdepim.so.1()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires libktnef.so.1()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires kdepim3 basket-kontact-1.0.2-5.fc9.x86_64 requires libkpinterfaces.so.1()(64bit) conduit-0.3.10-1.fc10.noarch requires gnome-python-desktop conduit-0.3.10-1.fc10.noarch requires gnome-python-extras edje-0.5.0.042-3.fc10.i386 requires libecore_directfb.so.0 edje-0.5.0.042-3.fc10.x86_64 requires libecore_directfb.so.0()(64bit) epsilon-0.3.0.012-3.fc10.i386 requires libecore_directfb.so.0 epsilon-0.3.0.012-3.fc10.x86_64 requires libecore_directfb.so.0()(64bit) epsilon-xine-0.3.0.012-3.fc10.x86_64 requires libecore_directfb.so.0()(64bit) evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libWand.so.10()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx kipi-plugins-0.1.5-2.fc10.i386 requires libkcal.so.2 kipi-plugins-0.1.5-2.fc10.x86_64 requires libkcal.so.2()(64bit) kismet-extras-0.0.2007.10.R1-3.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.x86_64 requires libWand.so.10()(64bit) koffice-libs-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.x86_64 requires libWand.so.10()(64bit) libopensync-plugin-kdepim-0.35-2.fc9.x86_64 requires libkcal.so.2()(64bit) openssh-server-5.0p1-2.fc10.x86_64 requires pam >= 0:1.0.1-3 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) qgis-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) taskjuggler-2.4.1-1.fc10.x86_64 requires libkcal.so.2()(64bit) taskjuggler-2.4.1-1.fc10.x86_64 requires libktnef.so.1()(64bit) taskjuggler-libs-2.4.1-1.fc10.i386 requires libkcal.so.2 taskjuggler-libs-2.4.1-1.fc10.x86_64 requires libkcal.so.2()(64bit) tellico-1.3.1-1.fc9.x86_64 requires libkcal.so.2()(64bit) tellico-1.3.1-1.fc9.x86_64 requires libktnef.so.1()(64bit) totem-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 totem-2.23.2-2.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.x86_64 requires libtotem-plparser-mini.so.10()(64bit) totem-nautilus-2.23.2-2.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) Broken deps for ppc ---------------------------------------------------------- LabPlot-1.5.1.6-4.fc8.ppc requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.ppc requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.ppc requires libMagick.so.10 basket-kontact-1.0.2-5.fc9.ppc requires libkpinterfaces.so.1 basket-kontact-1.0.2-5.fc9.ppc requires libkcal.so.2 basket-kontact-1.0.2-5.fc9.ppc requires libktnef.so.1 basket-kontact-1.0.2-5.fc9.ppc requires kdepim3 basket-kontact-1.0.2-5.fc9.ppc requires libkdepim.so.1 conduit-0.3.10-1.fc10.noarch requires gnome-python-desktop conduit-0.3.10-1.fc10.noarch requires gnome-python-extras edje-0.5.0.042-3.fc10.ppc requires libecore_directfb.so.0 edje-0.5.0.042-3.fc10.ppc64 requires libecore_directfb.so.0()(64bit) epsilon-0.3.0.012-3.fc10.ppc requires libecore_directfb.so.0 epsilon-0.3.0.012-3.fc10.ppc64 requires libecore_directfb.so.0()(64bit) epsilon-xine-0.3.0.012-3.fc10.ppc requires libecore_directfb.so.0 evolution-brutus-1.2.11-2.fc9.ppc requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.ppc requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.ppc requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.ppc requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-1.2.so.11 kipi-plugins-0.1.5-2.fc10.ppc requires libkcal.so.2 kipi-plugins-0.1.5-2.fc10.ppc64 requires libkcal.so.2()(64bit) kismet-extras-0.0.2007.10.R1-3.fc9.ppc requires libMagick.so.10 koffice-karbon-1.6.3-15.fc9.ppc requires libWand.so.10 koffice-karbon-1.6.3-15.fc9.ppc requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.ppc requires libWand.so.10 koffice-libs-1.6.3-15.fc9.ppc requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) libopensync-plugin-kdepim-0.35-2.fc9.ppc requires libkcal.so.2 openssh-server-5.0p1-2.fc10.ppc requires pam >= 0:1.0.1-3 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) qgis-0.9.1-5.fc9.ppc requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.ppc requires libgeos.so.2 taskjuggler-2.4.1-1.fc10.ppc requires libkcal.so.2 taskjuggler-2.4.1-1.fc10.ppc requires libktnef.so.1 taskjuggler-libs-2.4.1-1.fc10.ppc requires libkcal.so.2 taskjuggler-libs-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) tellico-1.3.1-1.fc9.ppc requires libkcal.so.2 tellico-1.3.1-1.fc9.ppc requires libktnef.so.1 totem-2.23.2-2.fc9.ppc requires libtotem-plparser.so.10 totem-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.ppc requires libtotem-plparser-mini.so.10 totem-mozplugin-2.23.2-2.fc9.ppc requires libtotem-plparser.so.10 totem-nautilus-2.23.2-2.fc9.ppc requires libtotem-plparser.so.10 Broken deps for ppc64 ---------------------------------------------------------- basket-kontact-1.0.2-5.fc9.ppc64 requires libkcal.so.2()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires libkdepim.so.1()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires libktnef.so.1()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires kdepim3 basket-kontact-1.0.2-5.fc9.ppc64 requires libkpinterfaces.so.1()(64bit) conduit-0.3.10-1.fc10.noarch requires gnome-python-desktop conduit-0.3.10-1.fc10.noarch requires gnome-python-extras edje-0.5.0.042-3.fc10.ppc64 requires libecore_directfb.so.0()(64bit) epsilon-0.3.0.012-3.fc10.ppc64 requires libecore_directfb.so.0()(64bit) epsilon-xine-0.3.0.012-3.fc10.ppc64 requires libecore_directfb.so.0()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) kipi-plugins-0.1.5-2.fc10.ppc64 requires libkcal.so.2()(64bit) kismet-extras-0.0.2007.10.R1-3.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) libopensync-plugin-kdepim-0.35-2.fc9.ppc64 requires libkcal.so.2()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot openssh-server-5.0p1-2.fc10.ppc64 requires pam >= 0:1.0.1-3 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot qgis-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) taskjuggler-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) taskjuggler-2.4.1-1.fc10.ppc64 requires libktnef.so.1()(64bit) taskjuggler-libs-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) tellico-1.3.1-1.fc9.ppc64 requires libkcal.so.2()(64bit) tellico-1.3.1-1.fc9.ppc64 requires libktnef.so.1()(64bit) totem-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.ppc64 requires libtotem-plparser-mini.so.10()(64bit) totem-nautilus-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) From mzerqung at 0pointer.de Tue May 20 10:26:16 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 20 May 2008 12:26:16 +0200 Subject: Glitch-Free PulseAudio in Rawhide In-Reply-To: References: <20080517101616.GA16071@tango.0pointer.de> <20080518200225.GC19530@tango.0pointer.de> Message-ID: <20080520102615.GB13762@tango.0pointer.de> On Tue, 20.05.08 05:47, Kevin Kofler (kevin.kofler at chello.at) wrote: > > Lennart Poettering 0pointer.de> writes: > > Also, if you claim that I neglect longstanding important bugs, then > > please be more specific and tell me exactly the bug numbers. > > There's this one: > https://bugzilla.redhat.com/show_bug.cgi?id=438284 > "Sometimes, PulseAudio fails to start" > It might actually be a symptom of several completely different bugs. What I'm > seeing in KDE is that sometimes, for no apparent reason, no PA is running, > starting it with pulseaudio -D just starts it. But that only happens sometimes. > I know this is not very useful as a bug report, I'll have to check the logs > more carefully to see if I can figure out what happens: maybe PA starts up and > then kills itself due to CPU overload? I'll let you know once I figure out > more. I was pretty sure I fixed that issue, as I wrote in the bug report. /me reads the sources. Ah, ok, it's like this: I actually did fix this issue, but not completely. PA does check the exename of an existing PID file to check if it is actually pa that owns the PID if it is still running. However, I added this fix only when killing an existing daemon (i.e. -k), not when starting a new one. It's trivial to fix. Hmm, this bug seems to be triggered only by KDE. Apparently in KDE PA is not configured for module-x11-xsmp? (could anyone who actually runs KDE check this?) if that module is not loaded libX11 will forcibly terminate us as soon as the X11 connection goes away. This will cause the PID file to not be removed properly on shutdown. > Then there's this weird issue: > https://bugzilla.redhat.com/show_bug.cgi?id=361891 What's weird about this issue is primarily the setup (i.e. running arts on top of pa). If you stack sound servers like this it is a call for trouble. Just don't do it. Sound servers should live near the hardware, not on top of each other. I mean, it would be great if this worked fine, but please understand that bug reports where the first thing I think when reading it is "Oh my, why do they want to do weird things like that?" are not the kind of bug reports that become a top priority for me to fix. And the fact that it's a bug in conjunction with obsolete, bit-rotten C++ software doesn't help it either. If you trigger one of those CPU overload issues, than this is most likely due to the software entering some kind of busy loop. If you want to fix this, you need to find out why we enter this busy loop. Apparently the operation that should normally sleep for IO doesn't sleep for IO in this case. Usually this means that an IO condition that was signalled earlier was not handled as it should and thus not reset. Unfortunately bugs like this don't leave any useful coredumps, error messages or back traces and so can only be fixed by spending some time in gdb to figure out what happens. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Tue May 20 10:53:04 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 20 May 2008 12:53:04 +0200 Subject: Glitch-Free PulseAudio in Rawhide In-Reply-To: <1211260283.6534.46.camel@dimi.lattica.com> References: <20080517101616.GA16071@tango.0pointer.de> <20080518200225.GC19530@tango.0pointer.de> <1211260283.6534.46.camel@dimi.lattica.com> Message-ID: <20080520105304.GC13762@tango.0pointer.de> On Tue, 20.05.08 01:11, Dimi Paun (dimi at lattica.com) wrote: > > > On Sun, 2008-05-18 at 22:02 +0200, Lennart Poettering wrote: > > Also, if you claim that I neglect longstanding important bugs, then > > please be more specific and tell me exactly the bug numbers. > > https://bugzilla.redhat.com/show_bug.cgi?id=438594 > > PA crashes mathematically for me, and nobody seems to care, > despite the fact that I run a fairly standard Fedora 8. > > The user experience is horrible too: > * PA decides the exit/crash at random So, as I asked in the bug report, are you using the "multi" libasound plugin for your soundcard? (find out with the -v switch from aplay.) Also, have you touched default.pa or the other config files in any way? > * Rhythmbox locks up hard, sometimes using 100% CPU This is just a followup on the first item. the gst module tries to signal the error condition to gst. Fun thing is, gst locks up when doing this due to a deadlock. Apparently some of the methods of a gst are not allowed to signal any error conditions. I pinged the GST people, but never got a response from them whether this should be fixed in GST or in gst-pulse. I'll try to ping them again. There's a bug on bz.g.o about this. > * Volume Control gives a cryptic error about a connection being lost Is it really that cryptic? It says exactly what happened: the connection to the sound server is lost. > * Skype no longer works, in strange ways (i.e. Sound In fails) Ah, great, closed source software. That's where I especially like to fix bugs in. > * Unless you know (how?!?) that you need a 'pulseaudio -D', you > have to reboot the machine to get working sound I guess that's something one could say about 99% of all bugs. > And all this happens after 1-2h of listening to stuff. This is one bug, not 5. We probably should move further discussion about this back to BZ, and not continue spamming fedroa-devel. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From paul at all-the-johnsons.co.uk Tue May 20 11:35:50 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Tue, 20 May 2008 12:35:50 +0100 Subject: Shifting mount points for drives Message-ID: <1211283350.9944.6.camel@T7.Linux> Hi, I'm not sure if this needs to be filed as a bug and if it is, what component to shove it under! My machine has 4 HDDs, 3 DVDs (one is a CDRW, one is a DVD, one is a DVDRW), an internal zip and a floppy with card reader. /dev/sda and /dev/sdb are both on the motherboard IDE /dev/sdc and /dev/sdd (DVDRW and DVD/CDRW) are on the motherboard secondary IDE I have an IDE card in my machine as well which has the zip & DVD on one channel and the other two hard drives on the other channel. The Zip is set as master, DVD as secondary on their channel. For some reason, the two HDDs keep getting shifted in their drive numbers. If I have in /etc/fstab /dev/sde1 /mp3 /dev/sdf1 /web then things should be happy. But they're not. When I reboot, there is a good change that they will be /dev/sdc1 and /dev/sdd1 or /dev/sdf1 and /dev/sdg1 but it's rare that they're /dev/sde1 and /dev/sdf1. If I comment them out of fstab, then when I come to mount them, they are *always* /dev/sde1 and /dev/sdf1 Any clues as to why this would be? TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jwboyer at gmail.com Tue May 20 11:51:31 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 20 May 2008 06:51:31 -0500 Subject: Policy on Bodhi? In-Reply-To: <20080520090329.GA24612@amd.home.annexia.org> References: <20080520090329.GA24612@amd.home.annexia.org> Message-ID: <20080520065131.21baff80@vader.jdub.homelinux.org> On Tue, 20 May 2008 10:03:29 +0100 "Richard W.M. Jones" wrote: > > Is there a policy on Bodhi? I don't mean how to use it, I mean > questions such as: > > - How long packages should stay in each state (pending / testing / > updates)? Nothing set in stone. Simple rule of thumb is wait one week in testing. > - Can I push a package directly into a stable update without > waiting around for testing? (if I know there's not going to be > many testers, and I need it as a dep for another package) You can get buildroot overrides from rel-eng, so you don't need something in -stable to just build against it. If you have a pair of packages that depend on each other they should go into the various repos at the same time though. > - Is it allowed / not-allowed to troll users into adding karma? Or at > least to encourage them to put comments? Not sure exactly what you mean, but it's always welcome for users to provide feedback on packages. Either good or bad. Preferably, bad karma comments also have a bugzilla number in them. josh From limb at jcomserv.net Tue May 20 12:08:12 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 20 May 2008 07:08:12 -0500 (CDT) Subject: Shifting mount points for drives In-Reply-To: <1211283350.9944.6.camel@T7.Linux> References: <1211283350.9944.6.camel@T7.Linux> Message-ID: <25368.198.175.55.5.1211285292.squirrel@mail.jcomserv.net> > Hi, > > I'm not sure if this needs to be filed as a bug and if it is, what > component to shove it under! > > My machine has 4 HDDs, 3 DVDs (one is a CDRW, one is a DVD, one is a > DVDRW), an internal zip and a floppy with card reader. > > /dev/sda and /dev/sdb are both on the motherboard IDE > /dev/sdc and /dev/sdd (DVDRW and DVD/CDRW) are on the motherboard > secondary IDE > > I have an IDE card in my machine as well which has the zip & DVD on one > channel and the other two hard drives on the other channel. The Zip is > set as master, DVD as secondary on their channel. > > For some reason, the two HDDs keep getting shifted in their drive > numbers. If I have in /etc/fstab > > /dev/sde1 /mp3 > /dev/sdf1 /web > > then things should be happy. But they're not. When I reboot, there is a > good change that they will be /dev/sdc1 and /dev/sdd1 or /dev/sdf1 > and /dev/sdg1 but it's rare that they're /dev/sde1 and /dev/sdf1. > > If I comment them out of fstab, then when I come to mount them, they are > *always* /dev/sde1 and /dev/sdf1 > > Any clues as to why this would be? No, but the best solution is to have fstab refer to them by label, not device name. I can't remember when this took effect, the little man on my shoulder says maybe fc7? > TTFN > > Paul > -- > ???Sie k??nnen mich aufreizen und wirklich hei?? machen! > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- novus ordo absurdum From jeff at ocjtech.us Tue May 20 12:25:13 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Tue, 20 May 2008 07:25:13 -0500 Subject: Shifting mount points for drives In-Reply-To: <25368.198.175.55.5.1211285292.squirrel@mail.jcomserv.net> References: <1211283350.9944.6.camel@T7.Linux> <25368.198.175.55.5.1211285292.squirrel@mail.jcomserv.net> Message-ID: <935ead450805200525oe5d9af4wce0040f149cdde04@mail.gmail.com> On Tue, May 20, 2008 at 7:08 AM, Jon Ciesla wrote: > >> For some reason, the two HDDs keep getting shifted in their drive >> numbers. >> >> Any clues as to why this would be? Because device nodes like /dev/sd* get assigned depending on the order in which the kernel loads device drivers and in which order the device drivers discover the drives. The ordering has never been guaranteed to be the same, it's just much more noticeable now that much more stuff is hot-pluggable. > No, but the best solution is to have fstab refer to them by label, not > device name. I can't remember when this took effect, the little man on my > shoulder says maybe fc7? Even better is to refer to drives in fstab by UUID. Labels aren't unique, which can be a problem if you need to move disks between different systems. Mounting filesystems by UUID is supposed to happen by default if you install with F9. Jeff From walters at verbum.org Tue May 20 14:26:21 2008 From: walters at verbum.org (Colin Walters) Date: Tue, 20 May 2008 10:26:21 -0400 Subject: Glitch-Free PulseAudio in Rawhide In-Reply-To: <20080520095200.GA13762@tango.0pointer.de> References: <20080517101616.GA16071@tango.0pointer.de> <20080518200225.GC19530@tango.0pointer.de> <1211260283.6534.46.camel@dimi.lattica.com> <1218b5bc0805192305g4a12aa19h5e50c7f68b676418@mail.gmail.com> <20080520095200.GA13762@tango.0pointer.de> Message-ID: On Tue, May 20, 2008 at 5:52 AM, Lennart Poettering wrote: >but not because I like taping over bugs, but > instead because we need better support of PA on the console, the a11y > people need that. Er, what? Is there something that's not served by running a regular terminal emulator from the desktop session? From alan at redhat.com Tue May 20 14:28:51 2008 From: alan at redhat.com (Alan Cox) Date: Tue, 20 May 2008 10:28:51 -0400 Subject: Shifting mount points for drives In-Reply-To: <1211283350.9944.6.camel@T7.Linux> References: <1211283350.9944.6.camel@T7.Linux> Message-ID: <20080520142851.GE20794@devserv.devel.redhat.com> On Tue, May 20, 2008 at 12:35:50PM +0100, Paul wrote: > For some reason, the two HDDs keep getting shifted in their drive > numbers. If I have in /etc/fstab > > /dev/sde1 /mp3 > /dev/sdf1 /web Use labels or UUIDs > If I comment them out of fstab, then when I come to mount them, they are > *always* /dev/sde1 and /dev/sdf1 > > Any clues as to why this would be? Probably the order module loading is getting triggered. With modern systems hotplug and hot swappable drives it makes no sense to try and tie device names to constant places - so we don't. From ndbecker2 at gmail.com Tue May 20 14:31:51 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Tue, 20 May 2008 10:31:51 -0400 Subject: confused about my F-9 packages Message-ID: I don't understand what goes on with my packages. For example: Cython I see no Cython in current F9 (http://download.fedora.redhat.com/pub/fedora/linux/releases/9/Fedora/source/SRPMS/) I go to my source , F-9 directory: make tag build cvs tag -c Cython-0_9_6_13_1-3_fc9 ERROR: The tag Cython-0_9_6_13_1-3_fc9 is already applied on a different branch So, what should I do to fix this? From mschwendt at gmail.com Tue May 20 14:42:37 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 20 May 2008 16:42:37 +0200 Subject: confused about my F-9 packages In-Reply-To: References: Message-ID: <20080520164237.17e3019f.mschwendt@gmail.com> On Tue, 20 May 2008 10:31:51 -0400, Neal Becker wrote: > I don't understand what goes on with my packages. > > For example: Cython > > I see no Cython in current F9 > (http://download.fedora.redhat.com/pub/fedora/linux/releases/9/Fedora/source/SRPMS/) > Have you built it for F-9 before? (see koji) If yes, was it after the freeze? In that case, have you prepared an update for F-9 in the Updates System? > I go to my source , F-9 directory: > make tag build > cvs tag -c Cython-0_9_6_13_1-3_fc9 > ERROR: The tag Cython-0_9_6_13_1-3_fc9 is already applied on a different > branch > > So, what should I do to fix this? See "cvs log Cython.spec". It has been tagged before. Why not simply "cd F-9 && BUILD_FLAGS=--nowait make build"? Why do you want to tag it again? From mschwendt at gmail.com Tue May 20 14:45:44 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 20 May 2008 16:45:44 +0200 Subject: confused about my F-9 packages In-Reply-To: References: Message-ID: <20080520164544.2b515372.mschwendt@gmail.com> On Tue, 20 May 2008 10:31:51 -0400, Neal Becker wrote: > I don't understand what goes on with my packages. > > For example: Cython > > I see no Cython in current F9 > (http://download.fedora.redhat.com/pub/fedora/linux/releases/9/Fedora/source/SRPMS/) > > I go to my source , F-9 directory: > make tag build > cvs tag -c Cython-0_9_6_13_1-3_fc9 > ERROR: The tag Cython-0_9_6_13_1-3_fc9 is already applied on a different > branch > > So, what should I do to fix this? And in case it was tagged in "devel" for .fc9 prior to the branch, simply bump %release. From mschwendt at gmail.com Tue May 20 14:49:07 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 20 May 2008 16:49:07 +0200 Subject: confused about my F-9 packages In-Reply-To: <20080520164544.2b515372.mschwendt@gmail.com> References: <20080520164544.2b515372.mschwendt@gmail.com> Message-ID: <20080520164907.5badf09a.mschwendt@gmail.com> On Tue, 20 May 2008 16:45:44 +0200, Michael Schwendt wrote: > On Tue, 20 May 2008 10:31:51 -0400, Neal Becker wrote: > > > I don't understand what goes on with my packages. > > > > For example: Cython > > > > I see no Cython in current F9 > > (http://download.fedora.redhat.com/pub/fedora/linux/releases/9/Fedora/source/SRPMS/) > > > > I go to my source , F-9 directory: > > make tag build > > cvs tag -c Cython-0_9_6_13_1-3_fc9 > > ERROR: The tag Cython-0_9_6_13_1-3_fc9 is already applied on a different > > branch > > > > So, what should I do to fix this? > > And in case it was tagged in "devel" for .fc9 prior to the branch, > simply bump %release. cvs co -r Cython-0_9_6_13_1-3_fc9 Cython works fine here, so not clear what you want to achieve. From dennis at ausil.us Tue May 20 14:52:47 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 20 May 2008 09:52:47 -0500 Subject: confused about my F-9 packages In-Reply-To: <20080520164544.2b515372.mschwendt@gmail.com> References: <20080520164544.2b515372.mschwendt@gmail.com> Message-ID: <200805200952.48664.dennis@ausil.us> On Tuesday 20 May 2008, Michael Schwendt wrote: > On Tue, 20 May 2008 10:31:51 -0400, Neal Becker wrote: > > I don't understand what goes on with my packages. > > > > For example: Cython > > > > I see no Cython in current F9 > > (http://download.fedora.redhat.com/pub/fedora/linux/releases/9/Fedora/sou > >rce/SRPMS/) > > > > I go to my source , F-9 directory: > > make tag build > > cvs tag -c Cython-0_9_6_13_1-3_fc9 > > ERROR: The tag Cython-0_9_6_13_1-3_fc9 is already applied on a different > > branch > > > > So, what should I do to fix this? > > And in case it was tagged in "devel" for .fc9 prior to the branch, > simply bump %release. no need to do that. We fixed things so you can just run make build from the F-9 branch even if it was tagged in devel. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From dennis at ausil.us Tue May 20 14:54:29 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 20 May 2008 09:54:29 -0500 Subject: confused about my F-9 packages In-Reply-To: References: Message-ID: <200805200954.31226.dennis@ausil.us> On Tuesday 20 May 2008, Neal Becker wrote: > I don't understand what goes on with my packages. > > For example: Cython > > I see no Cython in current F9 > (http://download.fedora.redhat.com/pub/fedora/linux/releases/9/Fedora/sourc >e/SRPMS/) > > I go to my source , F-9 directory: > make tag build > cvs tag -c Cython-0_9_6_13_1-3_fc9 > ERROR: The tag Cython-0_9_6_13_1-3_fc9 is already applied on a different > branch > > So, what should I do to fix this? looking at http://koji.fedoraproject.org/koji/buildinfo?buildID=46214 you submitted it to late for inclusion in F-9 so you need to use bodhi and issue it as an update. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From lesmikesell at gmail.com Tue May 20 15:40:07 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 20 May 2008 10:40:07 -0500 Subject: Glitch-Free PulseAudio in Rawhide In-Reply-To: References: <20080517101616.GA16071@tango.0pointer.de> <20080518200225.GC19530@tango.0pointer.de> <1211260283.6534.46.camel@dimi.lattica.com> <1218b5bc0805192305g4a12aa19h5e50c7f68b676418@mail.gmail.com> <20080520095200.GA13762@tango.0pointer.de> Message-ID: <4832F0D7.7020406@gmail.com> Colin Walters wrote: >> but not because I like taping over bugs, but >> instead because we need better support of PA on the console, the a11y >> people need that. > > Er, what? Is there something that's not served by running a regular > terminal emulator from the desktop session? What 'desktop session'? What does keyboard/mouse/video have to do with sound? -- Les Mikesell lesmikesell at gmail.com From ndbecker2 at gmail.com Tue May 20 15:41:13 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Tue, 20 May 2008 11:41:13 -0400 Subject: confused about my F-9 packages References: <20080520164237.17e3019f.mschwendt@gmail.com> Message-ID: Michael Schwendt wrote: > On Tue, 20 May 2008 10:31:51 -0400, Neal Becker wrote: > >> I don't understand what goes on with my packages. >> >> For example: Cython >> >> I see no Cython in current F9 >> (http://download.fedora.redhat.com/pub/fedora/linux/releases/9/Fedora/source/SRPMS/) >> > > Have you built it for F-9 before? (see koji) > If yes, was it after the freeze? In that case, have you > prepared an update for F-9 in the Updates System? > >> I go to my source , F-9 directory: >> make tag build >> cvs tag -c Cython-0_9_6_13_1-3_fc9 >> ERROR: The tag Cython-0_9_6_13_1-3_fc9 is already applied on a different >> branch >> >> So, what should I do to fix this? > > See "cvs log Cython.spec". It has been tagged before. > > Why not simply "cd F-9 && BUILD_FLAGS=--nowait make build"? > Why do you want to tag it again? > So I need(ed) to make build each of my packages in F9, or they are not there? That's the way it seems. Also, what is this? make build /usr/bin/koji build dist-f9 'cvs://cvs.fedoraproject.org/cvs/pkgs?rpms/uncrustify/F-9#uncrustify-0_46-1_fc9' Usage: koji build [options] target URL (Specify the --help global option for a list of other help options) koji: error: Destination tag dist-f9 is locked make: *** [koji] Error 1 From dan at danny.cz Tue May 20 15:55:50 2008 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Tue, 20 May 2008 17:55:50 +0200 Subject: confused about my F-9 packages In-Reply-To: References: <20080520164237.17e3019f.mschwendt@gmail.com> Message-ID: <1211298950.3080.6.camel@localhost.localdomain> Neal Becker p??e v ?t 20. 05. 2008 v 11:41 -0400: > Michael Schwendt wrote: > > > On Tue, 20 May 2008 10:31:51 -0400, Neal Becker wrote: > > > >> I don't understand what goes on with my packages. > >> > >> For example: Cython > >> > >> I see no Cython in current F9 > >> > (http://download.fedora.redhat.com/pub/fedora/linux/releases/9/Fedora/source/SRPMS/) > >> > > > > Have you built it for F-9 before? (see koji) > > If yes, was it after the freeze? In that case, have you > > prepared an update for F-9 in the Updates System? > > > >> I go to my source , F-9 directory: > >> make tag build > >> cvs tag -c Cython-0_9_6_13_1-3_fc9 > >> ERROR: The tag Cython-0_9_6_13_1-3_fc9 is already applied on a different > >> branch > >> > >> So, what should I do to fix this? > > > > See "cvs log Cython.spec". It has been tagged before. > > > > Why not simply "cd F-9 && BUILD_FLAGS=--nowait make build"? > > Why do you want to tag it again? > > > So I need(ed) to make build each of my packages in F9, or they are not > there? That's the way it seems. > > Also, what is this? > make build > /usr/bin/koji build > dist-f9 'cvs://cvs.fedoraproject.org/cvs/pkgs?rpms/uncrustify/F-9#uncrustify-0_46-1_fc9' > Usage: koji build [options] target URL > (Specify the --help global option for a list of other help options) > > koji: error: Destination tag dist-f9 is locked > make: *** [koji] Error 1 > did you try (from the dir where are you doing "make build") cd .. cvs update ? So the "common" dir gets updated and then you should be able to build packages normally. One step in CVS was the F-9 branching and the second was enabling f9-updates, etc. They were done at different time. Dan From paul at all-the-johnsons.co.uk Tue May 20 16:49:32 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Tue, 20 May 2008 17:49:32 +0100 Subject: USB devices not being recognised Message-ID: <1211302172.4830.5.camel@T7.Linux> Hi, I have a Tevion USB IP phone which used to work under F9 rawhide without a problem. If I now plug it in while the system is powering up, the kernel complains (causes a loop condition). If I plug it in after I hit the desktop nothing happens - no LEDs light up or the sound system see it. I've inserted the modules (yealink, snd-usb-lib) that should be there, but nothing. It also makes no difference going through a hub or directly to the PC. It's not found. Any ideas? TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mschwendt at gmail.com Tue May 20 17:02:07 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 20 May 2008 19:02:07 +0200 Subject: confused about my F-9 packages In-Reply-To: References: <20080520164237.17e3019f.mschwendt@gmail.com> Message-ID: <20080520190207.4dd2d912.mschwendt@gmail.com> On Tue, 20 May 2008 11:41:13 -0400, Neal Becker wrote: > Michael Schwendt wrote: > > > On Tue, 20 May 2008 10:31:51 -0400, Neal Becker wrote: > > > >> I don't understand what goes on with my packages. > >> > >> For example: Cython > >> > >> I see no Cython in current F9 > >> > (http://download.fedora.redhat.com/pub/fedora/linux/releases/9/Fedora/source/SRPMS/) > >> > > > > Have you built it for F-9 before? (see koji) > > If yes, was it after the freeze? In that case, have you > > prepared an update for F-9 in the Updates System? > > > >> I go to my source , F-9 directory: > >> make tag build > >> cvs tag -c Cython-0_9_6_13_1-3_fc9 > >> ERROR: The tag Cython-0_9_6_13_1-3_fc9 is already applied on a different > >> branch > >> > >> So, what should I do to fix this? > > > > See "cvs log Cython.spec". It has been tagged before. > > > > Why not simply "cd F-9 && BUILD_FLAGS=--nowait make build"? > > Why do you want to tag it again? > > > So I need(ed) to make build each of my packages in F9, or they are not > there? That's the way it seems. When F9 development was frozen, you had to mail Release Engineering and ask for builds in "devel" to be included in F9. If you didn't mail, you could only add the builds via bodhi. Around 200 zero-day updates for F9 were prepared in bodhi. > Also, what is this? > make build > /usr/bin/koji build > dist-f9 'cvs://cvs.fedoraproject.org/cvs/pkgs?rpms/uncrustify/F-9#uncrustify-0_46-1_fc9' > Usage: koji build [options] target URL > (Specify the --help global option for a list of other help options) > > koji: error: Destination tag dist-f9 is locked > make: *** [koji] Error 1 Your "common/" working-copy is out-of-date. The koji build tag was updated to dist-f9-updates-candidate. cvs up all your package checkouts. From mclasen at redhat.com Tue May 20 17:18:43 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 20 May 2008 13:18:43 -0400 Subject: getting rid of vendor prefixes for desktop files Message-ID: <1211303923.8530.10.camel@localhost.localdomain> I'd like to discuss the idea of getting rid of vendor prefixes for desktop files in Fedora. Right now, we install desktop files with a mixture of vendor prefixes: gnome-, fedora-, redhat-, nothing. These prefixes really add no value, and cause actual breakage, since Fedora is (afaik) the only distro adding vendor prefixes, so we are the ones that get bitten by upstream changes that don't take vendor prefixes into account. The recent breakage that made me write this mail is that the new gnome-session in rawhide has a list of mandatory session components stored in gconf, and one of these components was 'nautilus', so it went looking for nautilus.desktop - which doesn't exist, since we ship gnome-nautilus.desktop. Another problem caused by these prefixes is that overlaying a self-built gnome, e.g. a jhbuild tree on top of a fedora installation gives you everything doubled in the menus. Once with a vendor prefix, and once without, instead of the indended effect of the self built tree hiding the installed desktop files. Thus, I'd like to propose that we change the packaging guidelines to stop recommending the addition of a vendor prefix, and remove existing vendor prefixes in F10. This will cause a mild one-time pain for existing users with customized menus. We can probably discuss ways to avoid that. Comments ? Matthias From kevin.kofler at chello.at Tue May 20 17:18:58 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 20 May 2008 17:18:58 +0000 (UTC) Subject: Broken kdepim3 deps (Re: rawhide report: 20080520 changes) References: <20080520102245.C6395209D29@releng1.fedora.phx.redhat.com> Message-ID: We have upgraded kdepim to a snapshot of kdepim 4.1 in Rawhide. Unfortunately, this means a few packages need fixing: > basket-kontact-1.0.2-5.fc9.i386 requires libkpinterfaces.so.1 > basket-kontact-1.0.2-5.fc9.i386 requires libkcal.so.2 > basket-kontact-1.0.2-5.fc9.i386 requires libktnef.so.1 > basket-kontact-1.0.2-5.fc9.i386 requires kdepim3 > basket-kontact-1.0.2-5.fc9.i386 requires libkdepim.so.1 BasKet will have to be built without Kontact integration (i.e. basket-kontact dropped), there's no way to integrate a KDE 3 application into KDE 4 Kontact and unfortunately BasKet 2.0 is far from ready. > kipi-plugins-0.1.5-2.fc10.i386 requires libkcal.so.2 > taskjuggler-2.4.1-1.fc10.i386 requires libkcal.so.2 > taskjuggler-2.4.1-1.fc10.i386 requires libktnef.so.1 > taskjuggler-libs-2.4.1-1.fc10.i386 requires libkcal.so.2 > tellico-1.3.1-1.fc9.i386 requires libkcal.so.2 > tellico-1.3.1-1.fc9.i386 requires libktnef.so.1 These have to be built without the optional kdepim support until/unless a KDE 4 version is available. kipi-plugins has already been rebuilt without kdepim by Rex Dieter today. > libopensync-plugin-kdepim-0.35-2.fc9.i386 requires libkcal.so.2 KDE 4 version here: http://websvn.kde.org/trunk/playground/pim/libopensync-plugin-kdepim-0.36/ Kevin Kofler From gene at czarc.net Tue May 20 17:41:12 2008 From: gene at czarc.net (Gene Czarcinski) Date: Tue, 20 May 2008 13:41:12 -0400 Subject: gkrellm themes Message-ID: <200805201341.13276.gene@czarc.net> I have been a gkrellm fan for a number of years. While gkrellm is distributed as part of Fedora, gkrellm-themes is not being distributed starting with F8 (although the package is still available as part of the F7 distribution). The reason gkrellm-themes is no longer distributed is that there is no specific licensing indicated for almost all of the themes: https://bugzilla.redhat.com/show_bug.cgi?id=385131 While themes are not necessary for gkrellm operation, they are nice "eye candy" and some produce more readable displays than others ... it is a personal preference. I am volunteering to be a "limited time" upstream package "assembler" to create a new base tarball (gkrellm-themes instead of gkrellm-skins) which will have only themes with acceptable licensing starting with the two in the current package. But, before diving head first into an empty swimming pool, I wanted to determine if there is enough interest to warrent my efforts. Using my friend google, I located: http://themes.freshmeat.net/browse/969/ all of which are marked in freshmeat as having GPL, OSI Artistic, freely distributable, or freeware "licenses". While freshmeat marks these packages as having licenses, examining a couple of the theme tarballs indicates that no license is part of the theme tarball itself. [see (9) below] First of all, I need guidance as to what licensing would be acceptable (e.g., GPL, OSI Artistic, freely distributable, freeware, BSD, etc.). I need comments by (and perhaps some contact with) IP lawyers such as those working for Red Hat. If I proceed with this packaging, my plan is: 1. Use the two GPL'ed themes in the F7 package as the base. 2. Add any other themes which have licensing embedded in a theme tarball. 3. Go through the themes in the F7 package and the freshmeat list to identify author(s) for each theme ... if there is no author (e.g., anonymous), drop that theme. 4. Send each theme author an email asking them for appropriate licensing. If I get a "NO" answer, drop that theme. If the email bounces (or I have not heard from the author after a month), drop that theme. For themes which have multiple authors (the "last" author hacked a theme of another author), lack of response or a negative response for anyone in the chain results in the theme being dropped. 5. My preferred response is for the theme's author to send me (or provide me access to) an updated tarball with appropriate licensing embedded ... add this theme tarball to gkrellm-themes. 6. If I get a response that indicates to use "xxx" acceptable licensing and provides me with a copy of that license, add the theme tarball and then add the email message and the license info to the gkrellm-themes but do not modify the theme tarball itself ... the rpm package will need to put the info in the appropriate place ... maybe make them doc files distributed in /usr/share/doc/gkrellm-themes.../ as license. 7. If I get a response that indicates to use "xxx" acceptable licensing but does not provide a copy of the license but I can locate a copy, proceed as (6) above. 8. If I get a response of "whatever ... do what you want" (or words to that effect), my action is ??? [add the theme, the email message, and a "GPL license??] ... what to do ... what to do?? Guidance please. 9. With respect to the packages listed on freshmeat, how do I handle packages where freshmeat indicates a license but none is embedded? I found one a theme with a README embedded in the tarball which says: "If you wish to alter this theme or redistribute it, please give me credit or I'll hunt you down and rip your eyes out with my teeth. Ok? good. :)" How do I handle this? There is an implication that the theme is under some sort of "freely available" license. There may be other responses which is why I am interest in IP lawyer contacts. This may be need where a theme has multiple (chained) authors which have different ideas as to what the licensing should be. As I said, I Am Not A Lawyer and I intend to take all claims of authorship at face value ... if an author says he created the theme and puts it under an acceptable license, then that is it. Similarly, I will be making no artistic judgments on what is bundled into gkrellm-themes. Naturally, if anything is truly offensive, then that theme may be rejected similar to what was done with screensavers a number of years ago. In any case, turning gkrellm-themes into a Fedora rpm package will involve the usual review process which should kick out anything really tasteless. I am not currently a Maintainer on any other package so I would prefer to turn the result over to a "regular" Maintainer. That is, if I can pull enough themes together to be worth the effort ... right now, two themes does not seem to be worth the effort. If nobody raises their hand, then I guess I will have to learn how to be a Fedora Package Maintainer. Questions, comments, guidance, etc. are solicited. -- Gene From jbarnes at virtuousgeek.org Tue May 20 18:13:56 2008 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Tue, 20 May 2008 11:13:56 -0700 Subject: Broken kdepim3 deps (Re: rawhide report: 20080520 changes) In-Reply-To: References: <20080520102245.C6395209D29@releng1.fedora.phx.redhat.com> Message-ID: <200805201113.56371.jbarnes@virtuousgeek.org> On Tuesday, May 20, 2008 10:18 am Kevin Kofler wrote: > We have upgraded kdepim to a snapshot of kdepim 4.1 in Rawhide. Do the new packages include libmapi support for akonadi? Thanks, Jjesse From rdieter at math.unl.edu Tue May 20 18:15:02 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 20 May 2008 13:15:02 -0500 Subject: getting rid of vendor prefixes for desktop files References: <1211303923.8530.10.camel@localhost.localdomain> Message-ID: Matthias Clasen wrote: > Thus, I'd like to propose that we change the packaging guidelines to > stop recommending the addition of a vendor prefix, and remove existing > vendor prefixes in F10. This will cause a mild one-time pain for > existing users with customized menus. We can probably discuss ways to > avoid that. > > Comments ? I agree with the sentiment, but, keep in mind that the current guidelines don't go so far as to mandate vendor prefixes and that there are exceptions to every rule. -- Rex From tcallawa at redhat.com Tue May 20 18:29:06 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 20 May 2008 14:29:06 -0400 Subject: gkrellm themes In-Reply-To: <200805201341.13276.gene@czarc.net> References: <200805201341.13276.gene@czarc.net> Message-ID: <1211308146.3801.286.camel@localhost.localdomain> On Tue, 2008-05-20 at 13:41 -0400, Gene Czarcinski wrote: > First of all, I need guidance as to what licensing would be acceptable > (e.g., > GPL, OSI Artistic, freely distributable, freeware, BSD, etc.). I > need > comments by (and perhaps some contact with) IP lawyers such as those > working > for Red Hat. > We have a list of acceptable licenses here: http://fedoraproject.org/wiki/Licensing Short answers: GPL: yes Artistic 1.0: no Artistic 2.0: yes BSD: yes "Freely Distributable": maybe, I'd need to look. "freeware": maybe, I'd need to look. I'd be happy to audit anything that you're unsure about. ~spot, with my Fedora Legal cap on From rdieter at math.unl.edu Tue May 20 18:29:06 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 20 May 2008 13:29:06 -0500 Subject: kdepim/libmapi References: <20080520102245.C6395209D29@releng1.fedora.phx.redhat.com> <200805201113.56371.jbarnes@virtuousgeek.org> Message-ID: Jesse Barnes wrote: > On Tuesday, May 20, 2008 10:18 am Kevin Kofler wrote: >> We have upgraded kdepim to a snapshot of kdepim 4.1 in Rawhide. > > Do the new packages include libmapi support for akonadi? no, libmapi isn't in fedora (yet), when it is, the support for it in kdepim will be enabled. We'll package libmapi for review eventually, but would love it if someone beats us to it. -- Rex From wtogami at redhat.com Tue May 20 18:48:42 2008 From: wtogami at redhat.com (Warren Togami) Date: Tue, 20 May 2008 14:48:42 -0400 Subject: Fedora's vmlinuz broken with mkelfimage In-Reply-To: <48330D75.9070109@shaw.ca> References: <48330D75.9070109@shaw.ca> Message-ID: <48331D0A.4000005@redhat.com> Jerry Vonau wrote: > > I downloaded and booted the kernel & initrd that you have linked to > using grub as the boot loader. The boot process doesn't show that > error(it's a kernel message), it finds that the initrd.img is an > initramfs and loads. mkelfimage is hardcoded for a 8 MB initial ramdisk > (it's in the man page), your initrd has an uncompressed size over that. > Perhaps you need to pass --ramdisk-base= to change the size in mkelfimage. > > hope my 2 cents is useful, *gasp* I tried --ramdisk-base and it does indeed make it boot. I don't quite understand it because Ubuntu's initrd is definitely larger than 8MB as well. I'm guessing 16MB is a safe number, because frees the memory after initrd? Anyway, thanks very much. Warren Togami wtogami at redhat.com From jbarnes at virtuousgeek.org Tue May 20 18:50:14 2008 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Tue, 20 May 2008 11:50:14 -0700 Subject: kdepim/libmapi In-Reply-To: References: <20080520102245.C6395209D29@releng1.fedora.phx.redhat.com> <200805201113.56371.jbarnes@virtuousgeek.org> Message-ID: <200805201150.14705.jbarnes@virtuousgeek.org> On Tuesday, May 20, 2008 11:29 am Rex Dieter wrote: > Jesse Barnes wrote: > > On Tuesday, May 20, 2008 10:18 am Kevin Kofler wrote: > >> We have upgraded kdepim to a snapshot of kdepim 4.1 in Rawhide. > > > > Do the new packages include libmapi support for akonadi? > > no, libmapi isn't in fedora (yet), when it is, the support for it in kdepim > will be enabled. > > We'll package libmapi for review eventually, but would love it if someone > beats us to it. I tried building it recently; it depends on experimental samba bits. So whoever packages it may have to include a snapshot of the required samba headers & code... Jesse From poelstra at redhat.com Tue May 20 18:56:54 2008 From: poelstra at redhat.com (John Poelstra) Date: Tue, 20 May 2008 11:56:54 -0700 Subject: Fedora Release Engineering Meeting Recap 2008-05-19 Message-ID: <48331EF6.3080309@redhat.com> Recap and full IRC transcript found here: http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-may-19 Please make corrections and clarifications to the wiki page. == Open Tickets == * https://fedorahosted.org/projects/rel-eng/ticket/24 * https://fedorahosted.org/projects/rel-eng/ticket/23 * Enable email to Trac Ticket filing aliases - https://fedorahosted.org/projects/fedora-infrastructure/ticket/198 * Thereafter create a ''real'' release engineering mailing list == Miscellaneous == * Figure out a way to use bodhi for tagging for F10 * Perhaps auto-tagging via karma of a non-updates repo with restricted karma ability? * http://fedoraproject.org/wiki/Infrastructure/RelengRhel5Migration * Infrastructure is asking us for an outage window to do an fsck of /mnt/koji file store * Do it this weekend starting Friday evening or Saturday morning * Estimated to run for 22 hours == IRC Transcript == From rdieter at math.unl.edu Tue May 20 19:09:39 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 20 May 2008 14:09:39 -0500 Subject: kdepim/libmapi In-Reply-To: <200805201150.14705.jbarnes@virtuousgeek.org> References: <20080520102245.C6395209D29@releng1.fedora.phx.redhat.com> <200805201113.56371.jbarnes@virtuousgeek.org> <200805201150.14705.jbarnes@virtuousgeek.org> Message-ID: <483321F3.5010200@math.unl.edu> Jesse Barnes wrote: > On Tuesday, May 20, 2008 11:29 am Rex Dieter wrote: >> Jesse Barnes wrote: >>> On Tuesday, May 20, 2008 10:18 am Kevin Kofler wrote: >>>> We have upgraded kdepim to a snapshot of kdepim 4.1 in Rawhide. >>> Do the new packages include libmapi support for akonadi? >> no, libmapi isn't in fedora (yet), when it is, the support for it in kdepim >> will be enabled. >> >> We'll package libmapi for review eventually, but would love it if someone >> beats us to it. > > I tried building it recently; it depends on experimental samba bits. So > whoever packages it may have to include a snapshot of the required samba > headers & code... Ouchie, just noticed that myself. Looks like this will have to wait awhile. -- Rex From tibbs at math.uh.edu Tue May 20 19:35:32 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 20 May 2008 14:35:32 -0500 Subject: Summary of the 2008-05-20 Packaging Committee meeting Message-ID: Meeting minutes and full logs of the packaging committee meeting which occurred on 2008-05-20 are online: http://fedoraproject.org/wiki/Packaging/Minutes http://fedoraproject.org/wiki/Packaging/Minutes20080520 Executive summary: The following drafts are now official guidelines, having been accepted by FESCO last week: * Recording the upstream status of patches http://fedoraproject.org/wiki/PackagingDrafts/PatchUpstreamStatus * Mandatory verification of desktop files http://fedoraproject.org/wiki/PackagingDrafts/DesktopVerify These should be written into the guidelines soon if this hasn't already been done by the time you read this. Issues pending FESCO ratification: * Withdrawing the JPackage naming exception. The current exception allowing "jpp" in release strings is at http://fedoraproject.org/wiki/Packaging/JPackagePolicy FPC wishes to withdraw the exemption, thus requiring jpackage-derived packages to meet the regular naming guidelines as any other package. Misc business: * A draft is being worked up regarding the use of alternatives. If you are experienced with the use of alternatives and would like to give input on the issues surrounding alternatives and packaging, please join us on the fedora-packaging mailing list. - J< From a.badger at gmail.com Tue May 20 19:50:17 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 20 May 2008 12:50:17 -0700 Subject: getting rid of vendor prefixes for desktop files In-Reply-To: References: <1211303923.8530.10.camel@localhost.localdomain> Message-ID: <48332B79.8070301@gmail.com> Rex Dieter wrote: > Matthias Clasen wrote: > >> Thus, I'd like to propose that we change the packaging guidelines to >> stop recommending the addition of a vendor prefix, and remove existing >> vendor prefixes in F10. This will cause a mild one-time pain for >> existing users with customized menus. We can probably discuss ways to >> avoid that. >> >> Comments ? > > I agree with the sentiment, but, keep in mind that the current guidelines > don't go so far as to mandate vendor prefixes and that there are exceptions > to every rule. > Current Guidelines: ''' {{{ Three examples, two of which show --vendor="", one of which shows --vendor="" }}} * If upstream uses , leave it intact, otherwise use fedora as . * It is important that vendor_id stay constant for the life of a package. This is mostly for the sake of menu-editing (which bases off of .desktop file/path names). ''' So this is confusing as to whether --vendor is mandatory or optional. I can't think of a reason that we'd want to keep recommending --vendor if both you and Rex are in favor of dropping it and we can figure out some way to mitigate the customized menu issue. -Toshio From mail at robertoragusa.it Tue May 20 19:53:39 2008 From: mail at robertoragusa.it (Roberto Ragusa) Date: Tue, 20 May 2008 21:53:39 +0200 Subject: F8 -> F9 but keeping KDE3: technically feasible? In-Reply-To: <483295E6.8030404@gmail.com> References: <483076E8.70601@robertoragusa.it> <483295E6.8030404@gmail.com> Message-ID: <48332C43.3080501@robertoragusa.it> Andrew Farris wrote: > Roberto Ragusa wrote: >> >> do you think it can be possible to upgrade a F8 to F9 with >> exclusion of the KDE packages? >> >> My idea would be to keep qt, qt4 and kde* packages from F8, >> and upgrade all the rest. > > I believe you would have to go about this by running several (maybe > many) yum upgrades separately. There is no good way to get that upgrade > done with anaconda. You would need to construct some careful excludes > for those yum upgrades so it would force those packages, and anything > that depend on them, to get skipped. It probably will not be pretty.. > it probably will take you forever to work through the upgrade.. and it > will probably cause lots of packages to fail for deps. You're going to > end up with a hybrid of F8/F9 that might be mostly F8 (at least as far > as the kde apps or anything qt based are concerned you won't upgrade > anything). You might run into issues due to glibc and the gcc change > that will stop you cold, I don't know. Best way to find out is try > running some yum commands without confirming the changes and see what a > messy list of dependency problems you get. So, anaconda is out of question. This is not too bad, as yum is a (semi?)official upgrade method and I can have greater control with yum. Running yum a lot with excludes etc. doesn't worry me much, as it usually happens when upgrading because I use many external (and sometimes fighting) repositories. Can I reasonably expect binary compatibility for F8 packages on F9? I hope gcc ABI didn't change drastically. I think I will try my luck next days; in the worst scenario I will restore a full backup. But I'm sadly using the nvidia binary driver on this machine (Quadro FX 570M) and it looks like neither the binary nor the open source drivers are an easy path for F9. If I don't find a good solution for this, attempting the F9+KDE3 mess becomes less attractive. Thank you for your considerations, Andrew. -- Roberto Ragusa mail at robertoragusa.it From markg85 at gmail.com Tue May 20 20:01:03 2008 From: markg85 at gmail.com (Mark) Date: Tue, 20 May 2008 22:01:03 +0200 Subject: changes at planet fedora In-Reply-To: <1211214812.3095.0.camel@cutter> References: <1211214812.3095.0.camel@cutter> Message-ID: <6e24a8e80805201301r44a241bdr9b2263052fe1fd8b@mail.gmail.com> 2008/5/19 seth vidal : > Hi all, > I'm making some changes with how we build up the list of folks/rss > feeds for the fedora planet. We're making it more self-service and a bit > easier to maintain for the admin group (and specifically easier for me > to put up with). For all the people currently on the planet please > follow these instructions to make sure your feed stays on there: > > http://skvidal.fedorapeople.org/docs/planet-addition.html > > These instructions will be added to the wiki after the wiki migration > happens next week. > > Let me know what problems you have, too. > > thanks, > -sv > To comment on the new rules you've made: 1. As a fedora contributor you have to have a Fedora Account System account, have signed the cla and be a member of at least one other group in FAS. I strongly disagree on this one!! A person that writes a lot about fedora and thus deserves to be on the planet list doesn't need to be registered (or wants to register) at fedora so that you people can say your community is growing (because that WILL happen when a high fedora person gets interviewed and gets asked about the community behind it whether you want it or not). I personally didn't register there yet because the registration system asks things of me that i don't want to supply or don't feel like i need to supply them thus won't register until it either changes or when i'm up to put the time in it to get it all done. 2. Next, you need to login to your fedorapeople.org account. Use your ssh key you uploaded into the FAS to do this. don't quite get this one but is releated to the FAS which i disagreed so i disagree on this one as well.. 3. You need to create a .planet file in your homedir. The content of the file should be like this: Interesting.. you are asking things of the user to do (besides posting fedora stuff) so that they can be on the planet list.. i understand why you want it but again don't agree on this one. Why do you ask of a user to do this? if a user has a blog on some place where he doesn't have access to upload files (like blogspot and wordpress) then the user, which might have very good fedora articles, can't get on the planet.. I would drop this rule if i where you and put it in the fedora accounting system if a user needs to register there anyway.. You probably look for the .planet file anyway and save it in a database. Don't get me wrong! i like the planet thing and look ther quite often but dislike the rules you've just put on them (not that i want to submit my blog). I would be surprised if this is gonna work! seems like you simply ask to much of a user for them to only have there blog indexed on some kind of a planet site. Also a person that hates fedora might get on the planet with this automated system. What i would propose: Keep it the way it is to maintain quality. perhaps do a few things automatic but not everything! if it's to much for you to handle then post a request for some other people that can help with it. I'm sure there will be a few. I would (if i don't have to register at the FAS). Just think about it. From lordmorgul at gmail.com Tue May 20 20:10:28 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Tue, 20 May 2008 13:10:28 -0700 Subject: F8 -> F9 but keeping KDE3: technically feasible? In-Reply-To: <48332C43.3080501@robertoragusa.it> References: <483076E8.70601@robertoragusa.it> <483295E6.8030404@gmail.com> <48332C43.3080501@robertoragusa.it> Message-ID: <48333034.7080502@gmail.com> Roberto Ragusa wrote: > Can I reasonably expect binary compatibility for F8 packages > on F9? I hope gcc ABI didn't change drastically. Honestly, I'm not sure how big an issue you will have with this. > I think I will try my luck next days; in the worst scenario I will > restore a full backup. > But I'm sadly using the nvidia binary driver on this machine > (Quadro FX 570M) and it looks like neither the binary nor the open > source drivers are an easy path for F9. If I don't find a > good solution for this, attempting the F9+KDE3 mess becomes > less attractive. You can use the nvidia drivers with F9 if you run the F8 xorg packages; quite a few people have been doing this with success throughout the F9 development. -- Andrew Farris www.lordmorgul.net gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29 From jspaleta at gmail.com Tue May 20 20:24:39 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 20 May 2008 12:24:39 -0800 Subject: changes at planet fedora In-Reply-To: <6e24a8e80805201301r44a241bdr9b2263052fe1fd8b@mail.gmail.com> References: <1211214812.3095.0.camel@cutter> <6e24a8e80805201301r44a241bdr9b2263052fe1fd8b@mail.gmail.com> Message-ID: <604aa7910805201324u6aa3b454ne466a05dc5305ad4@mail.gmail.com> On Tue, May 20, 2008 at 12:01 PM, Mark wrote: > I personally didn't register there yet > because the registration system asks things of me that i don't want to > supply or don't feel like i need to supply them thus won't register > until it either changes or when i'm up to put the time in it to get it > all done. What exactly in the new click-through CLA process, which is required do you find over burdensome? Not all the personal profile information is required. The click-through CLA is a much lower bar than the previous CLA process. -jef From jwboyer at gmail.com Tue May 20 20:31:57 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 20 May 2008 15:31:57 -0500 Subject: changes at planet fedora In-Reply-To: <6e24a8e80805201301r44a241bdr9b2263052fe1fd8b@mail.gmail.com> References: <1211214812.3095.0.camel@cutter> <6e24a8e80805201301r44a241bdr9b2263052fe1fd8b@mail.gmail.com> Message-ID: <20080520153157.77011c9a@vader.jdub.homelinux.org> On Tue, 20 May 2008 22:01:03 +0200 Mark wrote: > Also a person that hates fedora might get on > the planet with this automated system. Why would that be a problem? josh From smooge at gmail.com Tue May 20 20:46:19 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 20 May 2008 14:46:19 -0600 Subject: EPEL Meeting: 2008-05-21 1600 UTC * NEW TIME * Message-ID: <80d7e4090805201346r2fcddf1ew22e940a116a94d0e@mail.gmail.com> Due to some scheduling issues, we are going to try and move the EPEL meetings to Wednesday 1600 UTC in Fedora Meeting. We will try to find a time where a super-majority of the SIG/Project board together Agenda: I) Old Business A) Packages in waiting 1) asterisk 2) other? B) Build system move to koji? 1) Do we have an intern? 2) FUDcon hackathon? C) Other? II) New Business A) RH Summit Talks 1) Stahnma? 2) Quaid? B) FudCon work C) Are we a SIG or a Project? In order to better organize ourselves, what part of us is a Special Interest Group and what part of us is a Project.. and how do we better organize ourselves. D) Elections for board? 1 year terms? when to when who gets re-elected first? E) Updating Documentation for WIKI move. III) Open Discussion -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From jwilson at redhat.com Tue May 20 20:55:27 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 20 May 2008 16:55:27 -0400 Subject: Packages up for grabs In-Reply-To: <200804081534.45557.jwilson@redhat.com> References: <200804081534.45557.jwilson@redhat.com> Message-ID: <200805201655.27244.jwilson@redhat.com> On Tuesday 08 April 2008 03:34:45 pm Jarod Wilson wrote: > I've got a few packages I'm the sole maintainer on, but I simply don't use > the package anymore or have much interest in continuing to maintain. Anyone > interested in taking the following over? [...] > aquamarine > emerald > emerald-themes Damn, nobody spoke up for these... So... Shall I just orphan them, since clearly, only 3 people care about them[*], or shall I suck it up and keep maintaining them? [*] I just got a bug today about the fact emerald doesn't work in F9, needed to be rebuilt, oh, 2 months ago. -- Jarod Wilson jwilson at redhat.com From seg at haxxed.com Tue May 20 20:50:01 2008 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 20 May 2008 15:50:01 -0500 Subject: FYI: Possibility for SSL spoofing in recent Firefox 3 In-Reply-To: References: Message-ID: <1218b5bc0805201350y38bac45bg6a74663f3e8569c5@mail.gmail.com> On Tue, May 20, 2008 at 1:49 AM, Peter Lemenkov wrote: > Hello All! > For those who doesn't read blog at StartCom here is an interesting post: > > https://blog.startcom.org/?p=86 > > Looks like the designers of Firefox 3 did some questionable changes in > design of Firefox 3. > My Firefox 3 beta 5 straight out of Fedora 9 displays yellow and always has, ever since I upgraded with Fedora 9 Beta. Apparently this change happened in FF 3 RC1? It does sound like a bad idea to me. Fedora 9 does not appear to have bumped up to RC1 as of the yum update I just ran, (I just updated yesterday) so we're safe... for now. -------------- next part -------------- An HTML attachment was scrubbed... URL: From smparrish at shallowcreek.net Tue May 20 20:57:13 2008 From: smparrish at shallowcreek.net (Steven Parrish) Date: Tue, 20 May 2008 16:57:13 -0400 Subject: Adopting an orphan Message-ID: Just wanted to drop a note to the list that I am taking ownership of UNRAR. Steven Parrish From markg85 at gmail.com Tue May 20 21:02:01 2008 From: markg85 at gmail.com (Mark) Date: Tue, 20 May 2008 23:02:01 +0200 Subject: changes at planet fedora In-Reply-To: <20080520153157.77011c9a@vader.jdub.homelinux.org> References: <1211214812.3095.0.camel@cutter> <6e24a8e80805201301r44a241bdr9b2263052fe1fd8b@mail.gmail.com> <20080520153157.77011c9a@vader.jdub.homelinux.org> Message-ID: <6e24a8e80805201402j27eb56a9r3dba331eff92e4ab@mail.gmail.com> 2008/5/20 Josh Boyer : > On Tue, 20 May 2008 22:01:03 +0200 > Mark wrote: > >> Also a person that hates fedora might get on >> the planet with this automated system. > > Why would that be a problem? > > josh > Well.. being critical about fedora is fine but some haters take all opportunity to promote the os that they do like or believe in so that might be a problem. And i can imagine that the fedora planet doesn't want to much negative fedora publicity on it's own planet about it's own os. 2008/5/20 Jeff Spaleta : > On Tue, May 20, 2008 at 12:01 PM, Mark wrote: >> I personally didn't register there yet >> because the registration system asks things of me that i don't want to >> supply or don't feel like i need to supply them thus won't register >> until it either changes or when i'm up to put the time in it to get it >> all done. > > What exactly in the new click-through CLA process, which is required > do you find over burdensome? Not all the personal profile information > is required. > > The click-through CLA is a much lower bar than the previous CLA process. > -jef i didn't look at it in the last few months. But making a key (which i never use and will lose) which was required last time i checked is one of the things that i don't like to supply simply because i don't want/need it (not for the moment). Also the requirement to fill in my last name bothers me. I like to be registered there with just my nickname and nothing more. And if i need to fill it in than certainly not __public__! I must have the ability to just use a name without supplying a last name. Without that i'm not gonna register. Just: Username Firstname Lastname (optional) Password Email And done! From tcallawa at redhat.com Tue May 20 21:03:14 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 20 May 2008 17:03:14 -0400 Subject: Adopting an orphan In-Reply-To: References: Message-ID: <1211317394.3801.303.camel@localhost.localdomain> On Tue, 2008-05-20 at 16:57 -0400, Steven Parrish wrote: > Just wanted to drop a note to the list that I am taking ownership of UNRAR. Unrar is not orphaned, it is blocked by Legal. If you want the details, poke me. ~spot From jspaleta at gmail.com Tue May 20 21:05:45 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 20 May 2008 13:05:45 -0800 Subject: changes at planet fedora In-Reply-To: <6e24a8e80805201402j27eb56a9r3dba331eff92e4ab@mail.gmail.com> References: <1211214812.3095.0.camel@cutter> <6e24a8e80805201301r44a241bdr9b2263052fe1fd8b@mail.gmail.com> <20080520153157.77011c9a@vader.jdub.homelinux.org> <6e24a8e80805201402j27eb56a9r3dba331eff92e4ab@mail.gmail.com> Message-ID: <604aa7910805201405j5ec53041ya81173dfcb6c8dfa@mail.gmail.com> On Tue, May 20, 2008 at 1:02 PM, Mark wrote: > i didn't look at it in the last few months. But making a key (which i > never use and will lose) which was required last time i checked is one > of the things that i don't like to supply simply because i don't > want/need it (not for the moment). key is not required for click through cla. Perhaps you should look at what is required for the cla again. And make sure you click on the information icons for each field and see which ones are required and which are options.. and the explanation as to why the required fields are in fact required. -jef From rjones at redhat.com Tue May 20 21:10:04 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 20 May 2008 22:10:04 +0100 Subject: Bodhi package stuck in pending Message-ID: <20080520211004.GA28646@amd.home.annexia.org> Another Bodhi question ... This package: https://admin.fedoraproject.org/updates/F9/pending/ocaml-omake-0.9.8.5-3.fc9 has been stuck (apparently) in pending for 3 days. It contains an important fix which a user is waiting for. Is there something I can do to push it into updates-testing? Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From jwboyer at gmail.com Tue May 20 21:19:34 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 20 May 2008 16:19:34 -0500 Subject: changes at planet fedora In-Reply-To: <6e24a8e80805201402j27eb56a9r3dba331eff92e4ab@mail.gmail.com> References: <1211214812.3095.0.camel@cutter> <6e24a8e80805201301r44a241bdr9b2263052fe1fd8b@mail.gmail.com> <20080520153157.77011c9a@vader.jdub.homelinux.org> <6e24a8e80805201402j27eb56a9r3dba331eff92e4ab@mail.gmail.com> Message-ID: <20080520161934.3cc9ab06@vader.jdub.homelinux.org> On Tue, 20 May 2008 23:02:01 +0200 Mark wrote: > 2008/5/20 Josh Boyer : > > On Tue, 20 May 2008 22:01:03 +0200 > > Mark wrote: > > > >> Also a person that hates fedora might get on > >> the planet with this automated system. > > > > Why would that be a problem? > > > > josh > > > > Well.. being critical about fedora is fine but some haters take all > opportunity to promote the os that they do like or believe in so that > might be a problem. And i can imagine that the fedora planet doesn't > want to much negative fedora publicity on it's own planet about it's > own os. I wouldn't have a problem with comparisons against other distros on fedora planet. Even if Fedora comes out lesser in those comparisons. As for blatant "Fedora SUCKS" types of posts, usually those get lots of comments from other bloggers either agreeing with that specific item, or pointing out how inaccurate it is. And given that fedoraplanet is multi-lingual, we might already have posts like that today that you or I can't read. I'm not concerned about this at all. josh From jonstanley at gmail.com Tue May 20 21:20:22 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Tue, 20 May 2008 17:20:22 -0400 Subject: changes at planet fedora In-Reply-To: <6e24a8e80805201301r44a241bdr9b2263052fe1fd8b@mail.gmail.com> References: <1211214812.3095.0.camel@cutter> <6e24a8e80805201301r44a241bdr9b2263052fe1fd8b@mail.gmail.com> Message-ID: On Tue, May 20, 2008 at 4:01 PM, Mark wrote: > 2008/5/19 seth vidal : >> Hi all, >> I'm making some changes with how we build up the list of folks/rss >> feeds for the fedora planet. We're making it more self-service and a bit >> easier to maintain for the admin group (and specifically easier for me >> to put up with). For all the people currently on the planet please >> follow these instructions to make sure your feed stays on there: >> >> http://skvidal.fedorapeople.org/docs/planet-addition.html >> >> These instructions will be added to the wiki after the wiki migration >> happens next week. >> >> Let me know what problems you have, too. >> >> thanks, >> -sv >> > > To comment on the new rules you've made: There are no new rules, just an administrative change to allow self-service administration of the Planet. > > 1. As a fedora contributor you have to have a Fedora Account > System account, have signed the cla and be a member of at least one > other group in FAS. > > I strongly disagree on this one!! A person that writes a lot about I think the "one other group" was added, but this is due to the fact that you don't get a fedorapeople.org account until you're a member of one other group. The CLA has always been required. > fedora and thus deserves to be on the planet list doesn't need to be > registered (or wants to register) at fedora so that you people can say > your community is growing (because that WILL happen when a high fedora > person gets interviewed and gets asked about the community behind it > whether you want it or not). I personally didn't register there yet > because the registration system asks things of me that i don't want to > supply or don't feel like i need to supply them thus won't register > until it either changes or when i'm up to put the time in it to get it > all done. There's not too much time involved in getting a FAS acct these days. You need probably an SSH key (in order to use the fedorapeople services), and a click-through CLA. > 2. Next, you need to login to your fedorapeople.org account. Use > your ssh key you uploaded into the FAS to do this. > > don't quite get this one but is releated to the FAS which i disagreed > so i disagree on this one as well.. This is where the configuration happens. Your fedorapeople.org account is a shell account that all Fedora contributors receive a 150MiB quota at. So you have to login to that shell account and create a file. > > 3. You need to create a .planet file in your homedir. The content > of the file should be like this: > > Interesting.. you are asking things of the user to do (besides posting > fedora stuff) so that they can be on the planet list.. i understand > why you want it but again don't agree on this one. Why do you ask of a > user to do this? if a user has a blog on some place where he doesn't > have access to upload files (like blogspot and wordpress) then the > user, which might have very good fedora articles, can't get on the > planet.. I would drop this rule if i where you and put it in the > fedora accounting system if a user needs to register there anyway.. > You probably look for the .planet file anyway and save it in a > database. The .planet file is in your home directory on fedorapeople.org, not on your blog. Anyone can make a file in their home directory on this machine. This has been done in order to decentralize administration from Seth having to do everything, to allowing self-service (a great thing IMO). If your feed URL were to change, then you could update it yourself rather than asking for it to be done. > Don't get me wrong! i like the planet thing and look ther quite often > but dislike the rules you've just put on them (not that i want to > submit my blog). > I would be surprised if this is gonna work! seems like you simply ask > to much of a user for them to only have there blog indexed on some > kind of a planet site. Also a person that hates fedora might get on > the planet with this automated system. That's not a huge issue, content would be subject to review anyway. Feeds can be disabled if need be. From jtang at magma.ca Tue May 20 21:23:47 2008 From: jtang at magma.ca (Jason Tang) Date: Tue, 20 May 2008 17:23:47 -0400 Subject: Xorg 1.5 missed the train? Message-ID: <48334163.4080709@magma.ca> The only problem being that this release is incompatible with current nvidia drivers. Granted, I'm aware of the Fedora position regarding non-OSS, but this Xorg issue has completely destroyed many user's confidence in the dev team. Most users could care less about supposed 'valid' reasons - that fact is: No 3D acceleration == No F9 adoption (or worse, an eroding user base). Lets not play this game with F10. - Jason From jkeating at redhat.com Tue May 20 21:25:19 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 20 May 2008 17:25:19 -0400 Subject: Bodhi package stuck in pending In-Reply-To: <20080520211004.GA28646@amd.home.annexia.org> References: <20080520211004.GA28646@amd.home.annexia.org> Message-ID: <1211318720.8531.38.camel@localhost.localdomain> On Tue, 2008-05-20 at 22:10 +0100, Richard W.M. Jones wrote: > > Another Bodhi question ... This package: > > https://admin.fedoraproject.org/updates/F9/pending/ocaml-omake-0.9.8.5-3.fc9 > > has been stuck (apparently) in pending for 3 days. It contains an > important fix which a user is waiting for. Is there something I can > do to push it into updates-testing? I"m attempting to get a push going now. There happens a phenomenon where the amount of time it takes to verify all the packages are signed gets longer and longer due to the number of requested updates. Then if somebody goes and revokes an update or replaces an update with something later and I have to start the checking cycle over or else bodhi will try to push something that isn't there anymore. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Tue May 20 21:27:14 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 21 May 2008 02:57:14 +0530 Subject: Xorg 1.5 missed the train? In-Reply-To: <48334163.4080709@magma.ca> References: <48334163.4080709@magma.ca> Message-ID: <48334232.5060101@fedoraproject.org> Jason Tang wrote: > The only problem being that this release is incompatible with current > nvidia drivers. Granted, I'm aware of the Fedora position regarding > non-OSS, but this Xorg issue has completely destroyed many user's > confidence in the dev team. > > Most users could care less about supposed 'valid' reasons - that fact > is: No 3D acceleration == No F9 adoption (or worse, an eroding user > base). Lets not play this game with F10. This is no game. Whenever Xorg ABI or kernel interface changes, proprietary drivers play catch-up. Rahul From rjones at redhat.com Tue May 20 21:28:32 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 20 May 2008 22:28:32 +0100 Subject: Bodhi package stuck in pending In-Reply-To: <1211318720.8531.38.camel@localhost.localdomain> References: <20080520211004.GA28646@amd.home.annexia.org> <1211318720.8531.38.camel@localhost.localdomain> Message-ID: <20080520212832.GA28748@amd.home.annexia.org> On Tue, May 20, 2008 at 05:25:19PM -0400, Jesse Keating wrote: > On Tue, 2008-05-20 at 22:10 +0100, Richard W.M. Jones wrote: > > > > Another Bodhi question ... This package: > > > > https://admin.fedoraproject.org/updates/F9/pending/ocaml-omake-0.9.8.5-3.fc9 > > > > has been stuck (apparently) in pending for 3 days. It contains an > > important fix which a user is waiting for. Is there something I can > > do to push it into updates-testing? > > I"m attempting to get a push going now. There happens a phenomenon > where the amount of time it takes to verify all the packages are signed > gets longer and longer due to the number of requested updates. Then if > somebody goes and revokes an update or replaces an update with something > later and I have to start the checking cycle over or else bodhi will try > to push something that isn't there anymore. Thanks, I appreciate it. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From berrange at redhat.com Tue May 20 21:30:57 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 20 May 2008 22:30:57 +0100 Subject: Xorg 1.5 missed the train? In-Reply-To: <48334163.4080709@magma.ca> References: <48334163.4080709@magma.ca> Message-ID: <20080520213057.GL16499@redhat.com> On Tue, May 20, 2008 at 05:23:47PM -0400, Jason Tang wrote: > The only problem being that this release is incompatible with current > nvidia drivers. Granted, I'm aware of the Fedora position regarding > non-OSS, but this Xorg issue has completely destroyed many user's > confidence in the dev team. > > Most users could care less about supposed 'valid' reasons - that fact > is: No 3D acceleration == No F9 adoption (or worse, an eroding user > base). Lets not play this game with F10. Well I'm an Intel & Radeon user and Xorg in F9 is dramatically better better for all my machines. So, yes, if new code improves life for the open source drivers, lets do this again & again in future releaes. I don't want my desktop experiance held hostage by one company with binary drivers. I chose hardware which is supportable so I can get the best & latest open source has to offer. Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From a.badger at gmail.com Tue May 20 21:30:45 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 20 May 2008 14:30:45 -0700 Subject: Adopting an orphan In-Reply-To: <1211317394.3801.303.camel@localhost.localdomain> References: <1211317394.3801.303.camel@localhost.localdomain> Message-ID: <48334305.40401@gmail.com> Tom "spot" Callaway wrote: > On Tue, 2008-05-20 at 16:57 -0400, Steven Parrish wrote: >> Just wanted to drop a note to the list that I am taking ownership of UNRAR. > > Unrar is not orphaned, it is blocked by Legal. If you want the details, > poke me. > Sorry about the confusion of it being listed as an orphan in the pkgdb. That seems to have happened during the massbranching for F-9 and we've corrected it. -Toshio From stlwrt at gmail.com Tue May 20 21:36:40 2008 From: stlwrt at gmail.com (Pavel Shevchuk) Date: Wed, 21 May 2008 00:36:40 +0300 Subject: Adopting an orphan In-Reply-To: <48334305.40401@gmail.com> References: <1211317394.3801.303.camel@localhost.localdomain> <48334305.40401@gmail.com> Message-ID: unrar is maintained by rpm.livna.org On 5/21/08, Toshio Kuratomi wrote: > Tom "spot" Callaway wrote: > > > On Tue, 2008-05-20 at 16:57 -0400, Steven Parrish wrote: > > > > > Just wanted to drop a note to the list that I am taking ownership of > UNRAR. > > > > > > > Unrar is not orphaned, it is blocked by Legal. If you want the details, > > poke me. > > > > > Sorry about the confusion of it being listed as an orphan in the pkgdb. > That seems to have happened during the massbranching for F-9 and we've > corrected it. > > -Toshio > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- http://scwlab.com From opensource at till.name Tue May 20 21:37:04 2008 From: opensource at till.name (Till Maas) Date: Tue, 20 May 2008 23:37:04 +0200 Subject: changes at planet fedora In-Reply-To: <6e24a8e80805201301r44a241bdr9b2263052fe1fd8b@mail.gmail.com> References: <1211214812.3095.0.camel@cutter> <6e24a8e80805201301r44a241bdr9b2263052fe1fd8b@mail.gmail.com> Message-ID: <200805202337.13490.opensource@till.name> On Tue May 20 2008, Mark wrote: > 2. Next, you need to login to your fedorapeople.org account. Use > your ssh key you uploaded into the FAS to do this. > > don't quite get this one but is releated to the FAS which i disagreed > so i disagree on this one as well.. I can login into fedorapeople.org via password authentication, therefore maybe you do not need an ssh key. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From jspaleta at gmail.com Tue May 20 21:37:54 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 20 May 2008 13:37:54 -0800 Subject: Xorg 1.5 missed the train? In-Reply-To: <48334163.4080709@magma.ca> References: <48334163.4080709@magma.ca> Message-ID: <604aa7910805201437r53a4a2eeuc824b6d3c702dcfa@mail.gmail.com> On Tue, May 20, 2008 at 1:23 PM, Jason Tang wrote: > The only problem being that this release is incompatible with current > nvidia drivers. Granted, I'm aware of the Fedora position regarding > non-OSS, but this Xorg issue has completely destroyed many user's > confidence in the dev team. This would have happened even if Xorg's release was on time and we were shipping a blessed xorg server 1.5. The internal changes in the xserver which break nvidia's drivers would still be there... and Nvidia would still wait for a distribution to ship with those changes before releasing a driver. Those of us who have run versions of Fedora from FC1 onward have seen this happen before. And it will happen again. The only reason why we didnt see it recently is because X has been somewhat stagnant. The fact that we are releasing 1.4.99 instead of 1.5 isn't the reason why this is happening. Nvidia will always lag when an Xorg codebase change requires drivers to be updated. The changes that were incompatible with nvidia have been in the Xorg that Fedora 9 is shipping for months now. I'm sure Nvidia is aware of them. > > Most users could care less about supposed 'valid' reasons - that fact > is: No 3D acceleration == No F9 adoption (or worse, an eroding user > base). Lets not play this game with F10. While this is certainly not ideal.. close source drivers will never be ideal...you need to take a long view with regard to Nvidia. Xorg is free to make changes, Fedora will adopt those changes. When the Xserver has internal changes which break drivers...nvidia's drivers availability will lag. This has absolutely nothing to do with the fact that xserver 1.5 isn't officially released. Nvidia could have chosen to release beta drivers to users over a month ago built against xserver 1.4.99...which would have continued to work with xserver 1.5 on release. Those of us who have followed Fedora from FC1 or earlier from the RHL era, know how this works. When Fedora includes a version of X makes an internal change which is incompatible, nvidia lags with the release of new drivers by at least two weeks. There is a track record here. -jef From chris.stone at gmail.com Tue May 20 21:40:13 2008 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 20 May 2008 14:40:13 -0700 Subject: Xorg 1.5 missed the train? In-Reply-To: <20080520213057.GL16499@redhat.com> References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> Message-ID: On Tue, May 20, 2008 at 2:30 PM, Daniel P. Berrange wrote: > On Tue, May 20, 2008 at 05:23:47PM -0400, Jason Tang wrote: >> The only problem being that this release is incompatible with current >> nvidia drivers. Granted, I'm aware of the Fedora position regarding >> non-OSS, but this Xorg issue has completely destroyed many user's >> confidence in the dev team. >> >> Most users could care less about supposed 'valid' reasons - that fact >> is: No 3D acceleration == No F9 adoption (or worse, an eroding user >> base). Lets not play this game with F10. > > Well I'm an Intel & Radeon user and Xorg in F9 is dramatically better > better for all my machines. So, yes, if new code improves life for the > open source drivers, lets do this again & again in future releaes. I don't > want my desktop experiance held hostage by one company with binary drivers. > I chose hardware which is supportable so I can get the best & latest open > source has to offer. Why the H.E. double hockey sticks do people think proving compatibility packages for nVidia users will somehow hold the desktop hostage for everyone else? I do not understand why ajax could not provide compatibility rpms for nVidia users? Is he not paid by redhat? I mean just how difficult can it be to provide F8 xorg rpms on F9 for nVidia users?? From jkeating at redhat.com Tue May 20 21:44:37 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 20 May 2008 17:44:37 -0400 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> Message-ID: <1211319877.8531.40.camel@localhost.localdomain> On Tue, 2008-05-20 at 14:40 -0700, Christopher Stone wrote: > > Why the H.E. double hockey sticks do people think proving > compatibility packages for nVidia users will somehow hold the desktop > hostage for everyone else? > > I do not understand why ajax could not provide compatibility rpms for > nVidia users? Is he not paid by redhat? I mean just how difficult > can it be to provide F8 xorg rpms on F9 for nVidia users?? Two xservers is just insanity. Those on nvidia can choose between using the nv driver in F9, or continuing to use F8 until Nvidia gets their act together. The price you pay... -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jspaleta at gmail.com Tue May 20 21:45:23 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 20 May 2008 13:45:23 -0800 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> Message-ID: <604aa7910805201445s3ff364c4odf10acbb2e91c7cc@mail.gmail.com> On Tue, May 20, 2008 at 1:40 PM, Christopher Stone wrote: > I do not understand why ajax could not provide compatibility rpms for > nVidia users? Is he not paid by redhat? I mean just how difficult > can it be to provide F8 xorg rpms on F9 for nVidia users?? Are you suggesting that we turn X into something run by the alternatives system so we can parallel install different versions of X? I'm pretty sure that's not a reasonable then to demand of ajax. And if you aren't going to do it parallel installable..then what you are talking about is a broken concept right out of the gate. -jef From berrange at redhat.com Tue May 20 21:47:31 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 20 May 2008 22:47:31 +0100 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> Message-ID: <20080520214731.GM16499@redhat.com> On Tue, May 20, 2008 at 02:40:13PM -0700, Christopher Stone wrote: > On Tue, May 20, 2008 at 2:30 PM, Daniel P. Berrange wrote: > > On Tue, May 20, 2008 at 05:23:47PM -0400, Jason Tang wrote: > >> The only problem being that this release is incompatible with current > >> nvidia drivers. Granted, I'm aware of the Fedora position regarding > >> non-OSS, but this Xorg issue has completely destroyed many user's > >> confidence in the dev team. > >> > >> Most users could care less about supposed 'valid' reasons - that fact > >> is: No 3D acceleration == No F9 adoption (or worse, an eroding user > >> base). Lets not play this game with F10. > > > > Well I'm an Intel & Radeon user and Xorg in F9 is dramatically better > > better for all my machines. So, yes, if new code improves life for the > > open source drivers, lets do this again & again in future releaes. I don't > > want my desktop experiance held hostage by one company with binary drivers. > > I chose hardware which is supportable so I can get the best & latest open > > source has to offer. > > Why the H.E. double hockey sticks do people think proving > compatibility packages for nVidia users will somehow hold the desktop > hostage for everyone else? > > I do not understand why ajax could not provide compatibility rpms for > nVidia users? Is he not paid by redhat? I mean just how difficult > can it be to provide F8 xorg rpms on F9 for nVidia users?? The compatability RPMs already exist - its called F8. It is completely unsustainable to package 2 complete versions of the same package for the same release. Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From chris.stone at gmail.com Tue May 20 21:51:08 2008 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 20 May 2008 14:51:08 -0700 Subject: Xorg 1.5 missed the train? In-Reply-To: <1211319877.8531.40.camel@localhost.localdomain> References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <1211319877.8531.40.camel@localhost.localdomain> Message-ID: 2008/5/20 Jesse Keating : > On Tue, 2008-05-20 at 14:40 -0700, Christopher Stone wrote: > Two xservers is just insanity. Those on nvidia can choose between using > the nv driver in F9, or continuing to use F8 until Nvidia gets their act > together. The price you pay... Until nVidia gets their act together?? What the H.E. double hockey sticks are you talking about? nVidia can't do anything until xorg's ABI is *stable*. They cannot keep chasing a moving target. If xorg declared today that the ABI will be stable then perhaps nVidia can get working on new drivers. Perhaps xorg has already done this?? And I don't see why you can't have two different xorg packages. We have other compat packages with gcc and libstdc++, etc... From contact at philipashmore.com Tue May 20 21:52:05 2008 From: contact at philipashmore.com (Philip Ashmore) Date: Tue, 20 May 2008 22:52:05 +0100 Subject: Should I upgrade to Fedora 9 / KDE 4? Message-ID: <48334805.1000307@philipashmore.com> Hi there. People can only "look before you leap" if they are presented with enough information to make an informed choice. From my experience I wish I had known more. 1. The xorg update meant that the nvidia drivers couldn't simply have the portable part recompiled for each new kernel. This is what the Livna repo hosts. 2. On my install of KDE 4 (other problems may have caused this so please confirm) I have no Kate, no science screensaver, no ksysguard. I filed a bug against ksysguard / KDE 4 - https://bugzilla.redhat.com/show_bug.cgi?id=447471 I have no CD/DVD drive and no other machine. After reformatting my hard disk twice, trying to copy the DVD image to a hard disk partition to boot off it and eventually using VMware server to boot off the ISO and install to a physical hard disk, I wish I hadn't started. I've downgraded to Fedora 8 and was going to wait for the nvidia drivers to catch up, but now it looks like I'll be waiting for KDE 4.2. Ho hum. From smooge at gmail.com Tue May 20 21:53:31 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 20 May 2008 15:53:31 -0600 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> Message-ID: <80d7e4090805201453r1789a3e9vd86ed5ec0ebdea70@mail.gmail.com> On Tue, May 20, 2008 at 3:40 PM, Christopher Stone wrote: > On Tue, May 20, 2008 at 2:30 PM, Daniel P. Berrange wrote: >> On Tue, May 20, 2008 at 05:23:47PM -0400, Jason Tang wrote: >>> The only problem being that this release is incompatible with current >>> nvidia drivers. Granted, I'm aware of the Fedora position regarding >>> non-OSS, but this Xorg issue has completely destroyed many user's >>> confidence in the dev team. >>> >>> Most users could care less about supposed 'valid' reasons - that fact >>> is: No 3D acceleration == No F9 adoption (or worse, an eroding user >>> base). Lets not play this game with F10. >> >> Well I'm an Intel & Radeon user and Xorg in F9 is dramatically better >> better for all my machines. So, yes, if new code improves life for the >> open source drivers, lets do this again & again in future releaes. I don't >> want my desktop experiance held hostage by one company with binary drivers. >> I chose hardware which is supportable so I can get the best & latest open >> source has to offer. > > Why the H.E. double hockey sticks do people think proving > compatibility packages for nVidia users will somehow hold the desktop > hostage for everyone else? > > I do not understand why ajax could not provide compatibility rpms for > nVidia users? Is he not paid by redhat? I mean just how difficult > can it be to provide F8 xorg rpms on F9 for nVidia users?? > He is paid by Red Hat to work on X, not to be your personal slave. You want that find out what it costs first.. I am guessing around 100k/year for that kind of nightmare. Otherwise stay with F8 until your card is supported. Especially since he would need to make sure that pretty much every X app is compiled twice with one with the old API and one with the new one. -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From wtogami at redhat.com Tue May 20 21:58:00 2008 From: wtogami at redhat.com (Warren Togami) Date: Tue, 20 May 2008 17:58:00 -0400 Subject: Should I upgrade to Fedora 9 / KDE 4? In-Reply-To: <48334805.1000307@philipashmore.com> References: <48334805.1000307@philipashmore.com> Message-ID: <48334968.7030103@redhat.com> Philip Ashmore wrote: > Hi there. > > People can only "look before you leap" if they are presented with enough > information to make an informed choice. > > I have no CD/DVD drive and no other machine. > After reformatting my hard disk twice, trying to copy the DVD image to a > hard disk partition to boot off it and eventually using VMware server to > boot off the ISO and install to a physical hard disk, I wish I hadn't > started. Another great option would have been to try LiveUSB with persistence on a $10 2GB USB stick. With LiveUSB and persistence you can even install/upgrade RPMS. Very safe and easy way to try a new Fedora without risk. Warren Togami wtogami at redhat.com From chris.stone at gmail.com Tue May 20 21:58:00 2008 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 20 May 2008 14:58:00 -0700 Subject: Xorg 1.5 missed the train? In-Reply-To: <80d7e4090805201453r1789a3e9vd86ed5ec0ebdea70@mail.gmail.com> References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <80d7e4090805201453r1789a3e9vd86ed5ec0ebdea70@mail.gmail.com> Message-ID: On Tue, May 20, 2008 at 2:53 PM, Stephen John Smoogen wrote: > On Tue, May 20, 2008 at 3:40 PM, Christopher Stone > wrote: >> On Tue, May 20, 2008 at 2:30 PM, Daniel P. Berrange wrote: >>> On Tue, May 20, 2008 at 05:23:47PM -0400, Jason Tang wrote: >>>> The only problem being that this release is incompatible with current >>>> nvidia drivers. Granted, I'm aware of the Fedora position regarding >>>> non-OSS, but this Xorg issue has completely destroyed many user's >>>> confidence in the dev team. >>>> >>>> Most users could care less about supposed 'valid' reasons - that fact >>>> is: No 3D acceleration == No F9 adoption (or worse, an eroding user >>>> base). Lets not play this game with F10. >>> >>> Well I'm an Intel & Radeon user and Xorg in F9 is dramatically better >>> better for all my machines. So, yes, if new code improves life for the >>> open source drivers, lets do this again & again in future releaes. I don't >>> want my desktop experiance held hostage by one company with binary drivers. >>> I chose hardware which is supportable so I can get the best & latest open >>> source has to offer. >> >> Why the H.E. double hockey sticks do people think proving >> compatibility packages for nVidia users will somehow hold the desktop >> hostage for everyone else? >> >> I do not understand why ajax could not provide compatibility rpms for >> nVidia users? Is he not paid by redhat? I mean just how difficult >> can it be to provide F8 xorg rpms on F9 for nVidia users?? >> > > He is paid by Red Hat to work on X, not to be your personal slave. You > want that find out what it costs first.. I am guessing around > 100k/year for that kind of nightmare. Otherwise stay with F8 until > your card is supported. Especially since he would need to make sure > that pretty much every X app is compiled twice with one with the old > API and one with the new one. What? The way I understand it is that you could simply use the xorg on F8 with F9 without needing to recompile anything (except maybe other xorg packages)? I thought someone had already taken this approach from what I've read in the fedora forums. Obviously if you have to recompile every app that runs on X this would not be feasible, but I understand that this is not actually the case? Please enlighten me. From tmz at pobox.com Tue May 20 21:59:09 2008 From: tmz at pobox.com (Todd Zullinger) Date: Tue, 20 May 2008 17:59:09 -0400 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> Message-ID: <20080520215909.GF12622@inocybe.teonanacatl.org> Christopher Stone wrote: > Why the H.E. double hockey sticks do people think proving > compatibility packages for nVidia users will somehow hold the > desktop hostage for everyone else? > > I do not understand why ajax could not provide compatibility rpms > for nVidia users? Is he not paid by redhat? I mean just how > difficult can it be to provide F8 xorg rpms on F9 for nVidia users?? I wouldn't be surprised if ajax came after you with a few hockey sticks for suggesting that he do all that extra work just to support some binary drivers. :) Use F-8 for a while longer if you really must have nvidia drivers. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Nothing is wrong with California that a rise in the ocean level wouldn't cure. -- Ross MacDonald (1915-1983) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From jspaleta at gmail.com Tue May 20 22:05:41 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 20 May 2008 14:05:41 -0800 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <1211319877.8531.40.camel@localhost.localdomain> Message-ID: <604aa7910805201505m7cc84699p953aa880b7419413@mail.gmail.com> On Tue, May 20, 2008 at 1:51 PM, Christopher Stone wrote: > Until nVidia gets their act together?? What the H.E. double hockey > sticks are you talking about? nVidia can't do anything until xorg's > ABI is *stable*. They cannot keep chasing a moving target. If xorg > declared today that the ABI will be stable then perhaps nVidia can get > working on new drivers. Perhaps xorg has already done this?? http://www.nvnews.net/vbulletin/showthread.php?t=107725 05-13-08, 12:48 AM "I got assurance from the release manager that the ABI won't be changing between now and the official xserver 1.5 release, so the ABI will be marked as supported in the next driver release so that -ignoreABI won't be required." > > And I don't see why you can't have two different xorg packages. We > have other compat packages with gcc and libstdc++, etc... I think you are over-simplifying the complexity of what it would take to make such a scheme work for the "framework" that is X. If you can do it, and make it work seemlessly, more power to you. But I have no doubt that it is wrong to make this sort of demand on ajax's time. We've seen compatibility issues in the past with regard to nvidia on release day. There is absolutely nothing new here. -jef From a.badger at gmail.com Tue May 20 22:07:15 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 20 May 2008 15:07:15 -0700 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <1211319877.8531.40.camel@localhost.localdomain> Message-ID: <48334B93.7010804@gmail.com> Christopher Stone wrote: > And I don't see why you can't have two different xorg packages. We > have other compat packages with gcc and libstdc++, etc... > Those are very different beasts. If you have two different libstdc++ packages other packages will depend on one or the other of them. If you have two different X Servers packages need to run on both of them. Even if there aren't compile time changes that require packages to be ported to support both versions (or be compiled twice to each set of libraries) you still have the QA and support burden of making sure each of those packages run on either one of the X Servers. -Toshio From chris.stone at gmail.com Tue May 20 22:10:28 2008 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 20 May 2008 15:10:28 -0700 Subject: Xorg 1.5 missed the train? In-Reply-To: <604aa7910805201505m7cc84699p953aa880b7419413@mail.gmail.com> References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <1211319877.8531.40.camel@localhost.localdomain> <604aa7910805201505m7cc84699p953aa880b7419413@mail.gmail.com> Message-ID: On Tue, May 20, 2008 at 3:05 PM, Jeff Spaleta wrote: > On Tue, May 20, 2008 at 1:51 PM, Christopher Stone > wrote: >> Until nVidia gets their act together?? What the H.E. double hockey >> sticks are you talking about? nVidia can't do anything until xorg's >> ABI is *stable*. They cannot keep chasing a moving target. If xorg >> declared today that the ABI will be stable then perhaps nVidia can get >> working on new drivers. Perhaps xorg has already done this?? > > http://www.nvnews.net/vbulletin/showthread.php?t=107725 > 05-13-08, 12:48 AM > "I got assurance from the release manager that the ABI won't be > changing between now and the official xserver 1.5 release, so the ABI > will be marked as supported in the next driver release so that > -ignoreABI won't be required." Okay, this is good news. I'll post on the nVidia forums to make sure they know. I still think it's a bit uncalled for to say nVidia should get their act together when the ABI was only declared stable last week. > >> >> And I don't see why you can't have two different xorg packages. We >> have other compat packages with gcc and libstdc++, etc... > > I think you are over-simplifying the complexity of what it would take > to make such a scheme work for the "framework" that is X. If you can > do it, and make it work seemlessly, more power to you. But I have no > doubt that it is wrong to make this sort of demand on ajax's time. > We've seen compatibility issues in the past with regard to nvidia on > release day. There is absolutely nothing new here. As I stated in my original post "just how hard can it be to provide compatibility packages?" From what I understand, you could just drop in the F8 packages right into F9 and that's all that is required. Then nVidia users could use the f8 version of xorg while everyone else could use the f9 version. Why is it not that simple? From seg at haxxed.com Tue May 20 22:10:43 2008 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 20 May 2008 17:10:43 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> Message-ID: <1218b5bc0805201510u3444e705j8500dc9df8d1998@mail.gmail.com> On Tue, May 20, 2008 at 4:40 PM, Christopher Stone wrote: > Why the H.E. double hockey sticks do people think proving > compatibility packages for nVidia users will somehow hold the desktop > hostage for everyone else? LURK MOAR -------------- next part -------------- An HTML attachment was scrubbed... URL: From jtang at magma.ca Tue May 20 22:11:31 2008 From: jtang at magma.ca (Jason Tang) Date: Tue, 20 May 2008 18:11:31 -0400 Subject: Xorg 1.5 missed the train? In-Reply-To: <604aa7910805201437r53a4a2eeuc824b6d3c702dcfa@mail.gmail.com> References: <48334163.4080709@magma.ca> <604aa7910805201437r53a4a2eeuc824b6d3c702dcfa@mail.gmail.com> Message-ID: <48334C93.60405@magma.ca> Jeff Spaleta wrote: > On Tue, May 20, 2008 at 1:23 PM, Jason Tang wrote: > >> The only problem being that this release is incompatible with current >> nvidia drivers. Granted, I'm aware of the Fedora position regarding >> non-OSS, but this Xorg issue has completely destroyed many user's >> confidence in the dev team. >> > > This would have happened even if Xorg's release was on time and we > were shipping a blessed xorg server 1.5. The internal changes in > the xserver which break nvidia's drivers would still be there... and > Nvidia would still wait for a distribution to ship with those changes > before releasing a driver. Those of us who have run versions of Fedora > from FC1 onward have seen this happen before. And it will happen > again. The only reason why we didnt see it recently is because X has > been somewhat stagnant. The fact that we are releasing 1.4.99 instead > of 1.5 isn't the reason why this is happening. Nvidia will always > lag when an Xorg codebase change requires drivers to be updated. The > changes that were incompatible with nvidia have been in the Xorg that > Fedora 9 is shipping for months now. I'm sure Nvidia is aware of them. > > >> Most users could care less about supposed 'valid' reasons - that fact >> is: No 3D acceleration == No F9 adoption (or worse, an eroding user >> base). Lets not play this game with F10. >> > > While this is certainly not ideal.. close source drivers will never be > ideal...you need to take a long view with regard to Nvidia. Xorg is > free to make changes, Fedora will adopt those changes. When the > Xserver has internal changes which break drivers...nvidia's drivers > availability will lag. This has absolutely nothing to do with the fact > that xserver 1.5 isn't officially released. Nvidia could have chosen > to release beta drivers to users over a month ago built against > xserver 1.4.99...which would have continued to work with xserver 1.5 > on release. > > Those of us who have followed Fedora from FC1 or earlier from the RHL > era, know how this works. When Fedora includes a version of X makes an > internal change which is incompatible, nvidia lags with the release of > new drivers by at least two weeks. There is a track record here. > > -jef > > If F9 was shipping a stable Xserver 1.5, the Nvidia devs would likely have had time to update their drivers, or at least have a head start on the process. Regardless, IMHO there's more than enough blame to go around: Fedora, Xorg, Nvidia. I just don't think neglecting 2/3 of the user base makes sense. The fact is, many people use nvidia hardware. It would have seemed that pushing Xorg 1.4.99 to the development repo would have made more sense from a stability perspective. After all, it is a 'pre-release'. - J From smooge at gmail.com Tue May 20 22:13:44 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 20 May 2008 16:13:44 -0600 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <1211319877.8531.40.camel@localhost.localdomain> <604aa7910805201505m7cc84699p953aa880b7419413@mail.gmail.com> Message-ID: <80d7e4090805201513t115af9eap47b1dd164e6fca58@mail.gmail.com> On Tue, May 20, 2008 at 4:10 PM, Christopher Stone wrote: > > As I stated in my original post "just how hard can it be to provide > compatibility packages?" From what I understand, you could just drop > in the F8 packages right into F9 and that's all that is required. > Then nVidia users could use the f8 version of xorg while everyone else > could use the f9 version. Why is it not that simple? Because there are ABI changes between the old and the new? -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From jspaleta at gmail.com Tue May 20 22:14:29 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 20 May 2008 14:14:29 -0800 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <1211319877.8531.40.camel@localhost.localdomain> <604aa7910805201505m7cc84699p953aa880b7419413@mail.gmail.com> Message-ID: <604aa7910805201514h4535567atd4e7c6c67bb74a84@mail.gmail.com> On Tue, May 20, 2008 at 2:10 PM, Christopher Stone wrote: > Okay, this is good news. I'll post on the nVidia forums to make sure > they know. I still think it's a bit uncalled for to say nVidia should > get their act together when the ABI was only declared stable last > week. Dude that thread is super long...and I was quoting an nvidia dev from the thread. Trust me... they know. Post #42 is a really good read concerning the recent history of the ABI. There is absolutely nothing new here. > As I stated in my original post "just how hard can it be to provide > compatibility packages?" From what I understand, you could just drop > in the F8 packages right into F9 and that's all that is required. > Then nVidia users could use the f8 version of xorg while everyone else > could use the f9 version. Why is it not that simple? You replace the f9 versions with the f8 versions. Making that work seemlessly is the trick. And if you read the nvnews thread I just dug up...people have been able to recompile the driver that is available and get it to work. This is a storm in a teacup. It will blow itself out soon enough. -jef From mzerqung at 0pointer.de Tue May 20 22:15:34 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Wed, 21 May 2008 00:15:34 +0200 Subject: Glitch-Free PulseAudio in Rawhide In-Reply-To: References: <20080517101616.GA16071@tango.0pointer.de> <20080518200225.GC19530@tango.0pointer.de> <1211260283.6534.46.camel@dimi.lattica.com> <1218b5bc0805192305g4a12aa19h5e50c7f68b676418@mail.gmail.com> <20080520095200.GA13762@tango.0pointer.de> Message-ID: <20080520221534.GB15948@tango.0pointer.de> On Tue, 20.05.08 10:26, Colin Walters (walters at verbum.org) wrote: > > On Tue, May 20, 2008 at 5:52 AM, Lennart Poettering > wrote: > >but not because I like taping over bugs, but > > instead because we need better support of PA on the console, the a11y > > people need that. > > Er, what? Is there something that's not served by running a regular > terminal emulator from the desktop session? Sorry, I don't really know, I am not a a11y user. It's just that various a11y people came to me and told me they needed it because braille on the console seems to be more fun than on X. But don't ask me about the details. And it's trivial to do, so who am I to say no? (Also, other people already complained that we broke ogg123 and suchlike in SSH logins. If we enable simple autospawning in PA by default we can make them happy too.) Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From lesmikesell at gmail.com Tue May 20 22:17:50 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 20 May 2008 17:17:50 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: <20080520215909.GF12622@inocybe.teonanacatl.org> References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <20080520215909.GF12622@inocybe.teonanacatl.org> Message-ID: <48334E0E.7090803@gmail.com> Todd Zullinger wrote: > Christopher Stone wrote: >> Why the H.E. double hockey sticks do people think proving >> compatibility packages for nVidia users will somehow hold the >> desktop hostage for everyone else? >> >> I do not understand why ajax could not provide compatibility rpms >> for nVidia users? Is he not paid by redhat? I mean just how >> difficult can it be to provide F8 xorg rpms on F9 for nVidia users?? > > I wouldn't be surprised if ajax came after you with a few hockey > sticks for suggesting that he do all that extra work just to support > some binary drivers. :) After all, it increases the apparent value of the stable RHEL to contrast it with fedora pushing things out before a stable version release that other vendors can support. -- Les Mikesell lesmikesell at gmail.com From sundaram at fedoraproject.org Tue May 20 22:21:55 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 21 May 2008 03:51:55 +0530 Subject: Xorg 1.5 missed the train? In-Reply-To: <48334E0E.7090803@gmail.com> References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <20080520215909.GF12622@inocybe.teonanacatl.org> <48334E0E.7090803@gmail.com> Message-ID: <48334F03.6070203@fedoraproject.org> Les Mikesell wrote: > After all, it increases the apparent value of the stable RHEL to > contrast it with fedora pushing things out before a stable version > release that other vendors can support. It doesn't since people can easily move to free rebuilds of RHEL. The value of RHEL is in support subscriptions. The robustness of Fedora does not dither that value at all. Rahul From seg at haxxed.com Tue May 20 22:22:48 2008 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 20 May 2008 17:22:48 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: <48334E0E.7090803@gmail.com> References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <20080520215909.GF12622@inocybe.teonanacatl.org> <48334E0E.7090803@gmail.com> Message-ID: <1218b5bc0805201522q436b90a3jbdf34cf06c37099f@mail.gmail.com> On Tue, May 20, 2008 at 5:17 PM, Les Mikesell wrote: > After all, it increases the apparent value of the stable RHEL to contrast > it with fedora pushing things out before a stable version release that other > vendors can support. See, now you're finally starting to get it. If you want API stability, use RHEL/CentOS or GTFO. -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at spicenitz.org Tue May 20 22:23:36 2008 From: adam at spicenitz.org (Adam Goode) Date: Tue, 20 May 2008 18:23:36 -0400 Subject: review swap! (miniRPC) Message-ID: <48334F68.6060502@spicenitz.org> Hi, I've got a pretty easy package review that I'd like to swap for. It's a library for doing RPC. https://bugzilla.redhat.com/show_bug.cgi?id=447533 Upstream: http://minirpc.cs.cmu.edu/ Thanks, Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From alan at clueserver.org Tue May 20 22:24:12 2008 From: alan at clueserver.org (Alan) Date: Tue, 20 May 2008 15:24:12 -0700 (PDT) Subject: Xorg 1.5 missed the train? In-Reply-To: <604aa7910805201514h4535567atd4e7c6c67bb74a84@mail.gmail.com> References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <1211319877.8531.40.camel@localhost.localdomain> <604aa7910805201505m7cc84699p953aa880b7419413@mail.gmail.com> <604aa7910805201514h4535567atd4e7c6c67bb74a84@mail.gmail.com> Message-ID: <54216.75.164.221.130.1211322252.squirrel@clueserver.org> > On Tue, May 20, 2008 at 2:10 PM, Christopher Stone > wrote: >> Okay, this is good news. I'll post on the nVidia forums to make sure >> they know. I still think it's a bit uncalled for to say nVidia should >> get their act together when the ABI was only declared stable last >> week. > > Dude that thread is super long...and I was quoting an nvidia dev from > the thread. > Trust me... they know. Post #42 is a really good read concerning the > recent history of the ABI. There is absolutely nothing new here. There seems to be some internal debate within nvidia about when the new version(s) get released. They know the abi is stable, but there seems to be someone within nvidia who is waiting for the official 1.5 release. Any idea when the x.org 1.5 release will actually occur? The web site is less than helpful. (The schedule has a note that says "this is not a schedule".) >> As I stated in my original post "just how hard can it be to provide >> compatibility packages?" From what I understand, you could just drop >> in the F8 packages right into F9 and that's all that is required. >> Then nVidia users could use the f8 version of xorg while everyone else >> could use the f9 version. Why is it not that simple? > > You replace the f9 versions with the f8 versions. Making that work > seemlessly is the trick. > And if you read the nvnews thread I just dug up...people have been > able to recompile the driver that is available and get it to work. > This is a storm in a teacup. It will blow itself out soon enough. I am just hoping it is soon. I know what I can do to make it work, but I am not the average user. The user who started with F7 or F8 and is moving to F9 are the ones who will feel the pain. Backreving the X drivers is not an easy task for the novice. I will be waiting for the "official" release. (Unless I get impatient, which could happen.) From alan at clueserver.org Tue May 20 22:28:07 2008 From: alan at clueserver.org (Alan) Date: Tue, 20 May 2008 15:28:07 -0700 (PDT) Subject: Xorg 1.5 missed the train? In-Reply-To: <48334F03.6070203@fedoraproject.org> References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <20080520215909.GF12622@inocybe.teonanacatl.org> <48334E0E.7090803@gmail.com> <48334F03.6070203@fedoraproject.org> Message-ID: <35207.75.164.221.130.1211322487.squirrel@clueserver.org> > Les Mikesell wrote: > >> After all, it increases the apparent value of the stable RHEL to >> contrast it with fedora pushing things out before a stable version >> release that other vendors can support. > > It doesn't since people can easily move to free rebuilds of RHEL. The > value of RHEL is in support subscriptions. The robustness of Fedora does > not dither that value at all. Besides... Someone has to push these things out first. If no one pushed out new versions before the release date, they would not get much in the way of testing. Getting xorg 1.5 into the F9 betas gave it more testing than if it was just confined to the people who compile their version of X from the source code repository. Yes it causes pain for some users, but it makes for a much more stable version for the rest of us once the initial bugs get worked out. From jspaleta at gmail.com Tue May 20 22:32:18 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 20 May 2008 14:32:18 -0800 Subject: Xorg 1.5 missed the train? In-Reply-To: <48334C93.60405@magma.ca> References: <48334163.4080709@magma.ca> <604aa7910805201437r53a4a2eeuc824b6d3c702dcfa@mail.gmail.com> <48334C93.60405@magma.ca> Message-ID: <604aa7910805201532j17e57609p2d579db05e7f06a0@mail.gmail.com> On Tue, May 20, 2008 at 2:11 PM, Jason Tang wrote: > I just don't think neglecting 2/3 of the user base makes sense. The fact > is, many people use nvidia hardware. It would have seemed that pushing Xorg > 1.4.99 to the development repo would have made more sense from a stability > perspective. After all, it is a 'pre-release'. 2/3 of the userbase? Are you relying on smolt stats for that? Please read the http://www.nvnews.net/vbulletin/showthread.php?t=107725&page=3 thread comment #42 for what is probably a very accurate picture of the timeline here. The whole thread is actually a valuable read. There was more than enough time for Nvidia to release beta drivers against the stable ABI if they desired to do so. Look at it this way... what if we did all our open driver development like nvidia does. What if the open video drivers were not ported until xserver 1.5 was officially released? Would there be any value at all in doing open video driver development that way? The changes that the nvidia driver need are surely on par with the changes the open drivers needed and they could have been done in the same timescale. The real question is why isn't NVidia syncing their driver development with the upstream process? And we aren't going to answer that here. -jef From chris.stone at gmail.com Tue May 20 22:32:35 2008 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 20 May 2008 15:32:35 -0700 Subject: Xorg 1.5 missed the train? In-Reply-To: <35207.75.164.221.130.1211322487.squirrel@clueserver.org> References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <20080520215909.GF12622@inocybe.teonanacatl.org> <48334E0E.7090803@gmail.com> <48334F03.6070203@fedoraproject.org> <35207.75.164.221.130.1211322487.squirrel@clueserver.org> Message-ID: On Tue, May 20, 2008 at 3:28 PM, Alan wrote: >> Les Mikesell wrote: >> >>> After all, it increases the apparent value of the stable RHEL to >>> contrast it with fedora pushing things out before a stable version >>> release that other vendors can support. >> >> It doesn't since people can easily move to free rebuilds of RHEL. The >> value of RHEL is in support subscriptions. The robustness of Fedora does >> not dither that value at all. > > Besides... Someone has to push these things out first. If no one pushed > out new versions before the release date, they would not get much in the > way of testing. Getting xorg 1.5 into the F9 betas gave it more testing > than if it was just confined to the people who compile their version of X > from the source code repository. Yes it causes pain for some users, but > it makes for a much more stable version for the rest of us once the > initial bugs get worked out. I can tell you right now, evdev still needs more work... ;-) From contact at philipashmore.com Tue May 20 22:32:53 2008 From: contact at philipashmore.com (Philip Ashmore) Date: Tue, 20 May 2008 23:32:53 +0100 Subject: Should I upgrade to Fedora 9 / KDE 4? Message-ID: <48335195.9030809@philipashmore.com> > Philip Ashmore wrote: >> Hi there. >> >> People can only "look before you leap" if they are presented with >> enough information to make an informed choice. > >> >> I have no CD/DVD drive and no other machine. >> After reformatting my hard disk twice, trying to copy the DVD image >> to a hard disk partition to boot off it and eventually using VMware >> server to boot off the ISO and install to a physical hard disk, I >> wish I hadn't started. > > Another great option would have been to try LiveUSB with persistence > on a $10 2GB USB stick. With LiveUSB and persistence you can even > install/upgrade RPMS. Very safe and easy way to try a new Fedora > without risk. > > Warren Togami > wtogami at redhat.com If I had a laptop that could boot of USB drives then you would be correct. I have a 2002 Dell Inspiron 8000. If only computer manufacturers open-sourced their BIOS software I could add USB boot capability to my Flash BIOS and be good to go...(TODO). Yes it may be getting on a bit now but not many laptops sport a 1600x1200 display! Philip From jwboyer at gmail.com Tue May 20 22:47:18 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 20 May 2008 17:47:18 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <1211319877.8531.40.camel@localhost.localdomain> Message-ID: <20080520174718.4dcc93ba@vader.jdub.homelinux.org> On Tue, 20 May 2008 14:51:08 -0700 "Christopher Stone" wrote: > 2008/5/20 Jesse Keating : > > On Tue, 2008-05-20 at 14:40 -0700, Christopher Stone wrote: > > Two xservers is just insanity. Those on nvidia can choose between using > > the nv driver in F9, or continuing to use F8 until Nvidia gets their act > > together. The price you pay... > > Until nVidia gets their act together?? What the H.E. double hockey > sticks are you talking about? nVidia can't do anything until xorg's > ABI is *stable*. They cannot keep chasing a moving target. If xorg Sure they can. They can open source their driver and play nice. josh From lesmikesell at gmail.com Tue May 20 22:48:19 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 20 May 2008 17:48:19 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: <1218b5bc0805201522q436b90a3jbdf34cf06c37099f@mail.gmail.com> References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <20080520215909.GF12622@inocybe.teonanacatl.org> <48334E0E.7090803@gmail.com> <1218b5bc0805201522q436b90a3jbdf34cf06c37099f@mail.gmail.com> Message-ID: <48335533.4000403@gmail.com> Callum Lerwick wrote: > > After all, it increases the apparent value of the stable RHEL to > contrast it with fedora pushing things out before a stable version > release that other vendors can support. > > > See, now you're finally starting to get it. If you want API stability, > use RHEL/CentOS or GTFO. I do. I just find it unfortunate that I can't use any of the newer things in fedora because they are intertwined with things that break interfaces - including many applications that would probably work just fine on a more stable OS. -- Les Mikesell lesmikesell at gmail.com From jwboyer at gmail.com Tue May 20 22:48:55 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 20 May 2008 17:48:55 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <1211319877.8531.40.camel@localhost.localdomain> <604aa7910805201505m7cc84699p953aa880b7419413@mail.gmail.com> Message-ID: <20080520174855.49dd2154@vader.jdub.homelinux.org> On Tue, 20 May 2008 15:10:28 -0700 "Christopher Stone" wrote: > On Tue, May 20, 2008 at 3:05 PM, Jeff Spaleta wrote: > > On Tue, May 20, 2008 at 1:51 PM, Christopher Stone > > wrote: > >> Until nVidia gets their act together?? What the H.E. double hockey > >> sticks are you talking about? nVidia can't do anything until xorg's > >> ABI is *stable*. They cannot keep chasing a moving target. If xorg > >> declared today that the ABI will be stable then perhaps nVidia can get > >> working on new drivers. Perhaps xorg has already done this?? > > > > http://www.nvnews.net/vbulletin/showthread.php?t=107725 > > 05-13-08, 12:48 AM > > "I got assurance from the release manager that the ABI won't be > > changing between now and the official xserver 1.5 release, so the ABI > > will be marked as supported in the next driver release so that > > -ignoreABI won't be required." > > Okay, this is good news. I'll post on the nVidia forums to make sure > they know. I still think it's a bit uncalled for to say nVidia should > get their act together when the ABI was only declared stable last > week. > > > > >> > >> And I don't see why you can't have two different xorg packages. We > >> have other compat packages with gcc and libstdc++, etc... > > > > I think you are over-simplifying the complexity of what it would take > > to make such a scheme work for the "framework" that is X. If you can > > do it, and make it work seemlessly, more power to you. But I have no > > doubt that it is wrong to make this sort of demand on ajax's time. > > We've seen compatibility issues in the past with regard to nvidia on > > release day. There is absolutely nothing new here. > > As I stated in my original post "just how hard can it be to provide > compatibility packages?" From what I understand, you could just drop > in the F8 packages right into F9 and that's all that is required. > Then nVidia users could use the f8 version of xorg while everyone else > could use the f9 version. Why is it not that simple? If it's that simple, you should be able to do it yourself. The code is there. Have at it. (HINT: It's not simple at all) josh From markg85 at gmail.com Tue May 20 22:50:40 2008 From: markg85 at gmail.com (Mark) Date: Wed, 21 May 2008 00:50:40 +0200 Subject: changes at planet fedora In-Reply-To: References: <1211214812.3095.0.camel@cutter> <6e24a8e80805201301r44a241bdr9b2263052fe1fd8b@mail.gmail.com> Message-ID: <6e24a8e80805201550o12531af3ye6692f9571cb5230@mail.gmail.com> 2008/5/20 Jon Stanley : > On Tue, May 20, 2008 at 4:01 PM, Mark wrote: >> 2008/5/19 seth vidal : >>> Hi all, >>> I'm making some changes with how we build up the list of folks/rss >>> feeds for the fedora planet. We're making it more self-service and a bit >>> easier to maintain for the admin group (and specifically easier for me >>> to put up with). For all the people currently on the planet please >>> follow these instructions to make sure your feed stays on there: >>> >>> http://skvidal.fedorapeople.org/docs/planet-addition.html >>> >>> These instructions will be added to the wiki after the wiki migration >>> happens next week. >>> >>> Let me know what problems you have, too. >>> >>> thanks, >>> -sv >>> >> >> To comment on the new rules you've made: > > There are no new rules, just an administrative change to allow > self-service administration of the Planet. >> >> 1. As a fedora contributor you have to have a Fedora Account >> System account, have signed the cla and be a member of at least one >> other group in FAS. >> >> I strongly disagree on this one!! A person that writes a lot about > > I think the "one other group" was added, but this is due to the fact > that you don't get a fedorapeople.org account until you're a member of > one other group. The CLA has always been required. > >> fedora and thus deserves to be on the planet list doesn't need to be >> registered (or wants to register) at fedora so that you people can say >> your community is growing (because that WILL happen when a high fedora >> person gets interviewed and gets asked about the community behind it >> whether you want it or not). I personally didn't register there yet >> because the registration system asks things of me that i don't want to >> supply or don't feel like i need to supply them thus won't register >> until it either changes or when i'm up to put the time in it to get it >> all done. > > There's not too much time involved in getting a FAS acct these days. > You need probably an SSH key (in order to use the fedorapeople > services), and a click-through CLA. > >> 2. Next, you need to login to your fedorapeople.org account. Use >> your ssh key you uploaded into the FAS to do this. >> >> don't quite get this one but is releated to the FAS which i disagreed >> so i disagree on this one as well.. > > This is where the configuration happens. Your fedorapeople.org > account is a shell account that all Fedora contributors receive a > 150MiB quota at. So you have to login to that shell account and > create a file. >> >> 3. You need to create a .planet file in your homedir. The content >> of the file should be like this: >> >> Interesting.. you are asking things of the user to do (besides posting >> fedora stuff) so that they can be on the planet list.. i understand >> why you want it but again don't agree on this one. Why do you ask of a >> user to do this? if a user has a blog on some place where he doesn't >> have access to upload files (like blogspot and wordpress) then the >> user, which might have very good fedora articles, can't get on the >> planet.. I would drop this rule if i where you and put it in the >> fedora accounting system if a user needs to register there anyway.. >> You probably look for the .planet file anyway and save it in a >> database. > > The .planet file is in your home directory on fedorapeople.org, not on > your blog. Anyone can make a file in their home directory on this > machine. This has been done in order to decentralize administration > from Seth having to do everything, to allowing self-service (a great > thing IMO). If your feed URL were to change, then you could update it > yourself rather than asking for it to be done. > >> Don't get me wrong! i like the planet thing and look ther quite often >> but dislike the rules you've just put on them (not that i want to >> submit my blog). >> I would be surprised if this is gonna work! seems like you simply ask >> to much of a user for them to only have there blog indexed on some >> kind of a planet site. Also a person that hates fedora might get on >> the planet with this automated system. > > That's not a huge issue, content would be subject to review anyway. > Feeds can be disabled if need be. > Oke all that information made me change my mind a bit about it.. I still don't think it's a good idea but at least it's not a horrible as i thought it was. I still don't like it that you need to have a fedora account to be part of the planet.. seems odd to me. From jonathan.underwood at gmail.com Tue May 20 22:51:28 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 20 May 2008 23:51:28 +0100 Subject: Small RFEs for Fedora Accounts System Message-ID: <645d17210805201551q2d5e1f84l8af88e7233ba76f1@mail.gmail.com> Hi, I just had the client side certificate expire. On a CVS operation I recieved the error message: ERROR: Your Fedora client-side certificate expired. You need to download a new client-side certificate from https://admin.fedora.redhat.com/accounts/ RFE#1: Please fix the URL, which should be https://admin.fedoraproject.org/accounts On logging in I helpfully see: Todo queue: Download a client-side certificate i Clicking on the "i" I see: "The client side cert is generally used to grant access to upload packages to Fedora or for other authentication purposes like with koji. If you are not a package maintainer there is no need to worry about the client side cert" RFE#2: It would be really helpful to add to the end of that info "This certificate should be saved to ~/.fedora.cert" RFE#3: Please could we add a FAS component to bugzilla? Or is there some other component I should be filing these against? Cheers, Jonathan. From chris.stone at gmail.com Tue May 20 22:54:52 2008 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 20 May 2008 15:54:52 -0700 Subject: Xorg 1.5 missed the train? In-Reply-To: <20080520174855.49dd2154@vader.jdub.homelinux.org> References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <1211319877.8531.40.camel@localhost.localdomain> <604aa7910805201505m7cc84699p953aa880b7419413@mail.gmail.com> <20080520174855.49dd2154@vader.jdub.homelinux.org> Message-ID: On Tue, May 20, 2008 at 3:48 PM, Josh Boyer wrote: > On Tue, 20 May 2008 15:10:28 -0700 > "Christopher Stone" wrote: > >> On Tue, May 20, 2008 at 3:05 PM, Jeff Spaleta wrote: >> > On Tue, May 20, 2008 at 1:51 PM, Christopher Stone >> > wrote: >> >> Until nVidia gets their act together?? What the H.E. double hockey >> >> sticks are you talking about? nVidia can't do anything until xorg's >> >> ABI is *stable*. They cannot keep chasing a moving target. If xorg >> >> declared today that the ABI will be stable then perhaps nVidia can get >> >> working on new drivers. Perhaps xorg has already done this?? >> > >> > http://www.nvnews.net/vbulletin/showthread.php?t=107725 >> > 05-13-08, 12:48 AM >> > "I got assurance from the release manager that the ABI won't be >> > changing between now and the official xserver 1.5 release, so the ABI >> > will be marked as supported in the next driver release so that >> > -ignoreABI won't be required." >> >> Okay, this is good news. I'll post on the nVidia forums to make sure >> they know. I still think it's a bit uncalled for to say nVidia should >> get their act together when the ABI was only declared stable last >> week. >> >> > >> >> >> >> And I don't see why you can't have two different xorg packages. We >> >> have other compat packages with gcc and libstdc++, etc... >> > >> > I think you are over-simplifying the complexity of what it would take >> > to make such a scheme work for the "framework" that is X. If you can >> > do it, and make it work seemlessly, more power to you. But I have no >> > doubt that it is wrong to make this sort of demand on ajax's time. >> > We've seen compatibility issues in the past with regard to nvidia on >> > release day. There is absolutely nothing new here. >> >> As I stated in my original post "just how hard can it be to provide >> compatibility packages?" From what I understand, you could just drop >> in the F8 packages right into F9 and that's all that is required. >> Then nVidia users could use the f8 version of xorg while everyone else >> could use the f9 version. Why is it not that simple? > > If it's that simple, you should be able to do it yourself. The code is > there. Have at it. > > (HINT: It's not simple at all) According to this thread it seems pretty simple actually: http://www.fedoraforum.org/forum/showthread.php?t=188645 If redhat wants to pay me $100k a year, I'll happily make xorg compat rpms in about one day. Thank you very much. From sundaram at fedoraproject.org Tue May 20 22:58:13 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 21 May 2008 04:28:13 +0530 Subject: changes at planet fedora In-Reply-To: <6e24a8e80805201550o12531af3ye6692f9571cb5230@mail.gmail.com> References: <1211214812.3095.0.camel@cutter> <6e24a8e80805201301r44a241bdr9b2263052fe1fd8b@mail.gmail.com> <6e24a8e80805201550o12531af3ye6692f9571cb5230@mail.gmail.com> Message-ID: <48335785.4050800@fedoraproject.org> Mark wrote: > Oke all that information made me change my mind a bit about it.. I > still don't think it's a good idea but at least it's not a horrible as > i thought it was. I still don't like it that you need to have a fedora > account to be part of the planet.. seems odd to me. Planet Fedora is explicitly a aggregation of blogs from official Fedora contributors who require a Fedora account anyway. What is being done here is merely decentralization of the process of getting a contributor's blog aggregated which is a pretty good move. Rahul From seg at haxxed.com Tue May 20 23:00:10 2008 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 20 May 2008 18:00:10 -0500 Subject: Glitch-Free PulseAudio in Rawhide In-Reply-To: <20080520095200.GA13762@tango.0pointer.de> References: <20080517101616.GA16071@tango.0pointer.de> <20080518200225.GC19530@tango.0pointer.de> <1211260283.6534.46.camel@dimi.lattica.com> <1218b5bc0805192305g4a12aa19h5e50c7f68b676418@mail.gmail.com> <20080520095200.GA13762@tango.0pointer.de> Message-ID: <1218b5bc0805201600k2198bc8cib8b987bcef4acd73@mail.gmail.com> On Tue, May 20, 2008 at 4:52 AM, Lennart Poettering wrote: > And just respawning when we crash is taping over bugs, too. I am not > generally opposed to it, though. I think you need to meditate upon the Rule of Repair for a while: http://catb.org/~esr/writings/taoup/html/ch01s06.html#id2878538 Bugs happen. The manner in which you recover from them is the difference between getting useful bug reports and getting flamed to hell and back on every mailing list and blog in existence and making the entire distribution look bad. And there's the matter of appropriateness. Forcing users to stop and deal with bugs makes sense in, say, rawhide. People should not be *forced* to play QA in a stable release. They just want to Get Their Shit Done. > However I fear it won't help much > since PA's state is lost and thus all music would stop playing > anyway. This situation seems entirely recoverable to me. Why can't the clients wait around and simply reconnect to the daemon and continue when it comes back again? Sure, there would be a temporary glitch. Temporary is good. A temporary glitch is far preferable to permanent brokenness, like things just no longer working with no indication of what happened or how to proceed to fix it. A temporary glitch is ignorable. Yet it is still a glitch, so a user with time on their hands can make the *choice* to stop and investigate further. Taking away that choice takes away the user's control. Taking control away from the user makes the user unhappy. Unhappy users go out on mailing lists and blogs and endlessly flame you. To wit: http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From jtang at magma.ca Tue May 20 23:11:11 2008 From: jtang at magma.ca (Jason Tang) Date: Tue, 20 May 2008 19:11:11 -0400 Subject: Xorg 1.5 missed the train? In-Reply-To: <604aa7910805201532j17e57609p2d579db05e7f06a0@mail.gmail.com> References: <48334163.4080709@magma.ca> <604aa7910805201437r53a4a2eeuc824b6d3c702dcfa@mail.gmail.com> <48334C93.60405@magma.ca> <604aa7910805201532j17e57609p2d579db05e7f06a0@mail.gmail.com> Message-ID: <48335A8F.5000308@magma.ca> Jeff Spaleta wrote: > On Tue, May 20, 2008 at 2:11 PM, Jason Tang wrote: > >> I just don't think neglecting 2/3 of the user base makes sense. The fact >> is, many people use nvidia hardware. It would have seemed that pushing Xorg >> 1.4.99 to the development repo would have made more sense from a stability >> perspective. After all, it is a 'pre-release'. >> > > 2/3 of the userbase? Are you relying on smolt stats for that? > > Please read the > http://www.nvnews.net/vbulletin/showthread.php?t=107725&page=3 thread > comment #42 for what is probably a very accurate picture of the timeline here. > > The whole thread is actually a valuable read. There was more than > enough time for Nvidia to release beta drivers against the stable ABI > if they desired to do so. > > Look at it this way... what if we did all our open driver development > like nvidia does. What if the open video drivers were not ported until > xserver 1.5 was officially released? Would there be any value at all > in doing open video driver development that way? The changes that the > nvidia driver need are surely on par with the changes the open drivers > needed and they could have been done in the same timescale. The real > question is why isn't NVidia syncing their driver development with the > upstream process? And we aren't going to answer that here. > > -jef > > 2/3, 1/3... 1/4... whatever. I'm sure you understand my point that there are a large number or eager F9 users in pain out there. I read that nvnews thread (for the second time). And yes, I agree that (in a perfect world) nvidia should play nice, or at least keep their eye on the ball concerning upstream changes that may affect them. Granted, I don't follow the dev group all that closely, so hopefully you can forgive me for thinking that what we seem to have is a circle of groups blaming one another for their own collective failure to deliver. Of course, I can and will wait for the drivers I need to work before upgrading my primary system. Perhaps most of us 'users' would have been content with a heads-up about the nvidia breakage, and maybe a rough timeline of when to expect a fix. That way there would not have been so many struggling now. From ezigler at gmail.com Tue May 20 23:14:10 2008 From: ezigler at gmail.com (Erich Zigler) Date: Tue, 20 May 2008 18:14:10 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: <604aa7910805201532j17e57609p2d579db05e7f06a0@mail.gmail.com> References: <48334163.4080709@magma.ca> <604aa7910805201437r53a4a2eeuc824b6d3c702dcfa@mail.gmail.com> <48334C93.60405@magma.ca> <604aa7910805201532j17e57609p2d579db05e7f06a0@mail.gmail.com> Message-ID: On Tue, May 20, 2008 at 5:32 PM, Jeff Spaleta wrote: > The real > question is why isn't NVidia syncing their driver development with the > upstream process? And we aren't going to answer that here. Aren't they doing so by waiting for an official release before supporting a product? Nvidia is not distribution specific. The changes they make and release have to work for all Linux users on all distributions not just Fedora. From mzerqung at 0pointer.de Tue May 20 23:16:29 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Wed, 21 May 2008 01:16:29 +0200 Subject: Glitch-Free PulseAudio in Rawhide In-Reply-To: <1218b5bc0805201600k2198bc8cib8b987bcef4acd73@mail.gmail.com> References: <20080517101616.GA16071@tango.0pointer.de> <20080518200225.GC19530@tango.0pointer.de> <1211260283.6534.46.camel@dimi.lattica.com> <1218b5bc0805192305g4a12aa19h5e50c7f68b676418@mail.gmail.com> <20080520095200.GA13762@tango.0pointer.de> <1218b5bc0805201600k2198bc8cib8b987bcef4acd73@mail.gmail.com> Message-ID: <20080520231628.GA18762@tango.0pointer.de> On Tue, 20.05.08 18:00, Callum Lerwick (seg at haxxed.com) wrote: > Bugs happen. The manner in which you recover from them is the difference > between getting useful bug reports and getting flamed to hell and back on > every mailing list and blog in existence and making the entire distribution > look bad. Did I miss something? Shall I take that as an insult? The only one who's flaming me here is ... you! Please find some other place to troll, you are way out of line. > This situation seems entirely recoverable to me. Why can't the clients wait > around and simply reconnect to the daemon and continue when it comes back > again? Sure, there would be a temporary glitch. Temporary is good. A > temporary glitch is far preferable to permanent brokenness, like things just > no longer working with no indication of what happened or how to proceed to > fix it. A temporary glitch is ignorable. Yet it is still a glitch, so a user > with time on their hands can make the *choice* to stop and investigate > further. Taking away that choice takes away the user's control. Taking > control away from the user makes the user unhappy. Unhappy users go out on > mailing lists and blogs and endlessly flame you. Aua. I guess you understimate the complexity of something like this. And how error-prone and thus counterproductive for what you want to do a scheme like this would be. Sorry, but this is not going to happen, makes no sense. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From seg at haxxed.com Tue May 20 23:25:24 2008 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 20 May 2008 18:25:24 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: <35207.75.164.221.130.1211322487.squirrel@clueserver.org> References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <20080520215909.GF12622@inocybe.teonanacatl.org> <48334E0E.7090803@gmail.com> <48334F03.6070203@fedoraproject.org> <35207.75.164.221.130.1211322487.squirrel@clueserver.org> Message-ID: <1218b5bc0805201625p21ba80b9y9cffd6eeb7fcec9b@mail.gmail.com> On Tue, May 20, 2008 at 5:28 PM, Alan wrote: > Besides... Someone has to push these things out first. If no one pushed > out new versions before the release date, they would not get much in the > way of testing. Getting xorg 1.5 into the F9 betas gave it more testing > than if it was just confined to the people who compile their version of X > from the source code repository. Yes it causes pain for some users, but > it makes for a much more stable version for the rest of us once the > initial bugs get worked out. Yes, we've had this flame war before. Last time, it was said that Nvidia has no intention of updating their drivers to a new Xorg ABI until a distribution releases that version in a *stable* release. That means if every distribution waited around for Nvidia to have their drivers ready before release, we'd be waiting forever. So go bitch at Nvidia, not us. Standing around and waiting is not what Fedora is about. We move fast. Don't like it? Use something else. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lesmikesell at gmail.com Tue May 20 23:33:20 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 20 May 2008 18:33:20 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: <1218b5bc0805201625p21ba80b9y9cffd6eeb7fcec9b@mail.gmail.com> References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <20080520215909.GF12622@inocybe.teonanacatl.org> <48334E0E.7090803@gmail.com> <48334F03.6070203@fedoraproject.org> <35207.75.164.221.130.1211322487.squirrel@clueserver.org> <1218b5bc0805201625p21ba80b9y9cffd6eeb7fcec9b@mail.gmail.com> Message-ID: <48335FC0.2070806@gmail.com> Callum Lerwick wrote: > On Tue, May 20, 2008 at 5:28 PM, Alan > wrote: > > Besides... Someone has to push these things out first. If no one pushed > out new versions before the release date, they would not get much in the > way of testing. Getting xorg 1.5 into the F9 betas gave it more testing > than if it was just confined to the people who compile their version > of X > from the source code repository. Yes it causes pain for some users, but > it makes for a much more stable version for the rest of us once the > initial bugs get worked out. > > > Yes, we've had this flame war before. Last time, it was said that Nvidia > has no intention of updating their drivers to a new Xorg ABI until a > distribution releases that version in a *stable* release. That means if > every distribution waited around for Nvidia to have their drivers ready > before release, we'd be waiting forever. So go bitch at Nvidia, not us. > Standing around and waiting is not what Fedora is about. We move fast. > Don't like it? Use something else. Please post that on the http://fedoraproject.org/ page so everyone will understand what to expect. -- Les Mikesell lesmikesell at gmail.com From ezigler at gmail.com Tue May 20 23:36:20 2008 From: ezigler at gmail.com (Erich Zigler) Date: Tue, 20 May 2008 18:36:20 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: <1218b5bc0805201625p21ba80b9y9cffd6eeb7fcec9b@mail.gmail.com> References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <20080520215909.GF12622@inocybe.teonanacatl.org> <48334E0E.7090803@gmail.com> <48334F03.6070203@fedoraproject.org> <35207.75.164.221.130.1211322487.squirrel@clueserver.org> <1218b5bc0805201625p21ba80b9y9cffd6eeb7fcec9b@mail.gmail.com> Message-ID: 2008/5/20 Callum Lerwick : > Yes, we've had this flame war before. Last time, it was said that Nvidia has > no intention of updating their drivers to a new Xorg ABI until a > distribution releases that version in a *stable* release. That means if > every distribution waited around for Nvidia to have their drivers ready > before release, we'd be waiting forever. So go bitch at Nvidia, not us. > Standing around and waiting is not what Fedora is about. We move fast. Don't > like it? Use something else. I like Fedora, I advocate Fedora, I install it on people's workstations, and talk it up as much as I can. However Nvidia did not jump the gun and ship a prerelease Xorg. I see and agree with the point of not being held hostage by a vendor, and there is no winners here. Only losers and those losers are the Fedora users who depend on the nvidia drivers who will either have to reinstall F8 or go to another distro and provide bad word of mouth for Fedora. - Erich From sundaram at fedoraproject.org Tue May 20 23:37:08 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 21 May 2008 05:07:08 +0530 Subject: Xorg 1.5 missed the train? In-Reply-To: <48335FC0.2070806@gmail.com> References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <20080520215909.GF12622@inocybe.teonanacatl.org> <48334E0E.7090803@gmail.com> <48334F03.6070203@fedoraproject.org> <35207.75.164.221.130.1211322487.squirrel@clueserver.org> <1218b5bc0805201625p21ba80b9y9cffd6eeb7fcec9b@mail.gmail.com> <48335FC0.2070806@gmail.com> Message-ID: <483360A4.3080005@fedoraproject.org> Les Mikesell wrote: > > Please post that on the http://fedoraproject.org/ page so everyone will > understand what to expect. Frontpage of a project website is not anybody's playing ground to scribble random information. For those who care, there is ample amount of information including the overview page. Insisting on putting everything on the frontpage is just silly and not going to happen. Rahul From airlied at redhat.com Tue May 20 23:39:28 2008 From: airlied at redhat.com (Dave Airlie) Date: Wed, 21 May 2008 09:39:28 +1000 Subject: Xorg 1.5 missed the train? In-Reply-To: <48334163.4080709@magma.ca> References: <48334163.4080709@magma.ca> Message-ID: <1211326768.10484.4.camel@clockmaker.usersys.redhat.com> On Tue, 2008-05-20 at 17:23 -0400, Jason Tang wrote: > The only problem being that this release is incompatible with current > nvidia drivers. Granted, I'm aware of the Fedora position regarding > non-OSS, but this Xorg issue has completely destroyed many user's > confidence in the dev team. > > Most users could care less about supposed 'valid' reasons - that fact > is: No 3D acceleration == No F9 adoption (or worse, an eroding user > base). Lets not play this game with F10. > Let me just state, this is not going to happen ever. If you want hold your desktop ransom to a large binary piece of software, I'm sure Microsoft will sell you an OS more suited to your needs. Fedora is about having an open distro and we are *never* going to expend time or effort to support a binary driver. I say this as the co-maintainer of X.org for Fedora. Fedora is not ajax's or mine primary reason for being paid, we really wish it was. However even if Fedora was the only thing I was scheduled to work on, I would still not expend even one small shred of effort to support a binary driver running on this OS. You buy hardware with closed source you now get to keep both bits. unsure if I can clarify this any better. Dave. From d.jacobfeuerborn at conversis.de Tue May 20 22:47:13 2008 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Wed, 21 May 2008 00:47:13 +0200 Subject: Xorg 1.5 missed the train? In-Reply-To: <54216.75.164.221.130.1211322252.squirrel@clueserver.org> References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <1211319877.8531.40.camel@localhost.localdomain> <604aa7910805201505m7cc84699p953aa880b7419413@mail.gmail.com> <604aa7910805201514h4535567atd4e7c6c67bb74a84@mail.gmail.com> <54216.75.164.221.130.1211322252.squirrel@clueserver.org> Message-ID: <483354F1.7000305@conversis.de> Alan wrote: >> On Tue, May 20, 2008 at 2:10 PM, Christopher Stone >> wrote: >>> Okay, this is good news. I'll post on the nVidia forums to make sure >>> they know. I still think it's a bit uncalled for to say nVidia should >>> get their act together when the ABI was only declared stable last >>> week. >> Dude that thread is super long...and I was quoting an nvidia dev from >> the thread. >> Trust me... they know. Post #42 is a really good read concerning the >> recent history of the ABI. There is absolutely nothing new here. > > There seems to be some internal debate within nvidia about when the new > version(s) get released. They know the abi is stable, but there seems to > be someone within nvidia who is waiting for the official 1.5 release. It's about people covering their collective asses. All the nvidia guys have is the release managers assurance that no further ABI changes will happen. This is not a 100% guarantee though and so they take the safest route possible and wait until 1.5 is released. That way they can be *absolutely* sure that their driver will work and nobody at nvidia has to take even the slightest risk. It's stubborn bureaucratic policy at work. Regards, Dennis From jspaleta at gmail.com Tue May 20 23:43:30 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 20 May 2008 15:43:30 -0800 Subject: Xorg 1.5 missed the train? In-Reply-To: <48335A8F.5000308@magma.ca> References: <48334163.4080709@magma.ca> <604aa7910805201437r53a4a2eeuc824b6d3c702dcfa@mail.gmail.com> <48334C93.60405@magma.ca> <604aa7910805201532j17e57609p2d579db05e7f06a0@mail.gmail.com> <48335A8F.5000308@magma.ca> Message-ID: <604aa7910805201643oab6e480u29f0e29f8a2896fa@mail.gmail.com> On Tue, May 20, 2008 at 3:11 PM, Jason Tang wrote: > 2/3, 1/3... 1/4... whatever. I'm sure you understand my point that there > are a large number or eager F9 users in pain out there. What exactly do you want at this point? I'm prepared to get in front of a camera, and do a video with a sincere apology to nvidia driver users that we have chosen to provide better support for video hardware with open drivers...than for closed source video drivers. But nothing I can do is going to fix the problem in a way that you want. We've never claimed to support nvidia drivers. If they work..they work. If they don't they don't. We can't fix them...we don't support them. I'm not going to mince words about it. > Granted, I don't follow the dev group all that closely, so hopefully you can > forgive me for thinking that what we seem to have is a circle of groups > blaming one another for their own collective failure to deliver. Xorg has an open transparent process... we have an open transparent process. We can't do anything more than be open and transparent. If Nvidia wants to have a discussion with Xorg concerning development and release cycle I'm sure that would be a fascinating thing to read. > > Of course, I can and will wait for the drivers I need to work before > upgrading my primary system. Perhaps most of us 'users' would have been > content with a heads-up about the nvidia breakage, and maybe a rough > timeline of when to expect a fix. We've known about the nvidia breakage for months now...since the beginning of the F9 development phase really, when the snapshots of the new xserver were put in rawhide..back when few of the open video drivers worked. There was more than enough time for any contributor who cared about the NVidia issue to submit something to the release notes process specifically about the known NVidia problems. We have an open community driven process for the release notes. If there is something specific you or any NVidia driver user wants added perhaps you should look into participating in that Beat writing process or talk to the Beat Writer for Xorg. http://fedoraproject.org/wiki/DocsProject/ReleaseNotes/Beats Obviously we can't point to 3rd party drivers...even if they did work. But how can we tell you when Nvidia will fix things? Nvidia's development process is opaque, they don't tell people when to expect driver updates. We cannot impact when and what NVidia chooses to do what they do, nor can we force to be more forth coming as to their timelines. > That way there would not have been so many struggling now. Honestly I don't see how. There is absolutely nothing we can do to impact how Nvidia will respond when X needs to make an ABI change. All we could do is put a big notice in our release notes that Fedora does not support 3rd party proprietary hardware drivers..full stop. Our release notes reference a long manifesto(which I didn't write even though it's length would suggest I did) which amounts to such a statement. In the future I'll insist on a bolder statement explictly stating that we do not support 3rd party drivers. If the work..great. If they don't...they don't..take it up with the driver developers. -jef From sundaram at fedoraproject.org Tue May 20 23:47:34 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 21 May 2008 05:17:34 +0530 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <20080520215909.GF12622@inocybe.teonanacatl.org> <48334E0E.7090803@gmail.com> <48334F03.6070203@fedoraproject.org> <35207.75.164.221.130.1211322487.squirrel@clueserver.org> <1218b5bc0805201625p21ba80b9y9cffd6eeb7fcec9b@mail.gmail.com> Message-ID: <48336316.8060606@fedoraproject.org> Erich Zigler wrote: > I see and agree with the point of not being held hostage by a vendor, > and there is no winners here. Only losers and those losers are the > Fedora users who depend on the nvidia drivers Yes. Once users start depending on proprietary drivers, they have already lost the game. I am reminded of this discussion from Linus. http://lwn.net/1999/0211/a/lt-binary.html "Basically, I want people to know that when they use binary-only modules, it's THEIR problem. I want people to know that in their bones, and I want it shouted out from the rooftops. I want people to wake up in a cold sweat every once in a while if they use binary-only modules." Rahul From jtang at magma.ca Tue May 20 23:52:24 2008 From: jtang at magma.ca (Jason Tang) Date: Tue, 20 May 2008 19:52:24 -0400 Subject: Xorg 1.5 missed the train? In-Reply-To: <1211326768.10484.4.camel@clockmaker.usersys.redhat.com> References: <48334163.4080709@magma.ca> <1211326768.10484.4.camel@clockmaker.usersys.redhat.com> Message-ID: <48336438.3090304@magma.ca> Dave Airlie wrote: > On Tue, 2008-05-20 at 17:23 -0400, Jason Tang wrote: > >> The only problem being that this release is incompatible with current >> nvidia drivers. Granted, I'm aware of the Fedora position regarding >> non-OSS, but this Xorg issue has completely destroyed many user's >> confidence in the dev team. >> >> Most users could care less about supposed 'valid' reasons - that fact >> is: No 3D acceleration == No F9 adoption (or worse, an eroding user >> base). Lets not play this game with F10. >> >> > > Let me just state, this is not going to happen ever. If you want hold > your desktop ransom to a large binary piece of software, I'm sure > Microsoft will sell you an OS more suited to your needs. > > Fedora is about having an open distro and we are *never* going to expend > time or effort to support a binary driver. I say this as the > co-maintainer of X.org for Fedora. Fedora is not ajax's or mine primary > reason for being paid, we really wish it was. However even if Fedora was > the only thing I was scheduled to work on, I would still not expend even > one small shred of effort to support a binary driver running on this OS. > You buy hardware with closed source you now get to keep both bits. > > unsure if I can clarify this any better. > > Dave. > > > > Believe it or not - I do agree with Fedora's OSS principles. However, as the professional I know you are (despite the tone of your reply), I'm sure you can understand the importance of hardware compatibility. Nobody is saying you need to bend over backwards for nvidia, but actively working to break support probably isn't the right approach either. Surely you can find a way to collaborate with X.org, Nvidia and the Fedora team in a way that promotes progress, rather than stifle it. From airlied at redhat.com Wed May 21 00:00:19 2008 From: airlied at redhat.com (Dave Airlie) Date: Wed, 21 May 2008 10:00:19 +1000 Subject: Xorg 1.5 missed the train? In-Reply-To: <48336438.3090304@magma.ca> References: <48334163.4080709@magma.ca> <1211326768.10484.4.camel@clockmaker.usersys.redhat.com> <48336438.3090304@magma.ca> Message-ID: <1211328019.10484.11.camel@clockmaker.usersys.redhat.com> On Tue, 2008-05-20 at 19:52 -0400, Jason Tang wrote: > Dave Airlie wrote: > > On Tue, 2008-05-20 at 17:23 -0400, Jason Tang wrote: > > > >> The only problem being that this release is incompatible with current > >> nvidia drivers. Granted, I'm aware of the Fedora position regarding > >> non-OSS, but this Xorg issue has completely destroyed many user's > >> confidence in the dev team. > >> > >> Most users could care less about supposed 'valid' reasons - that fact > >> is: No 3D acceleration == No F9 adoption (or worse, an eroding user > >> base). Lets not play this game with F10. > >> > >> > > > > Let me just state, this is not going to happen ever. If you want hold > > your desktop ransom to a large binary piece of software, I'm sure > > Microsoft will sell you an OS more suited to your needs. > > > > Fedora is about having an open distro and we are *never* going to expend > > time or effort to support a binary driver. I say this as the > > co-maintainer of X.org for Fedora. Fedora is not ajax's or mine primary > > reason for being paid, we really wish it was. However even if Fedora was > > the only thing I was scheduled to work on, I would still not expend even > > one small shred of effort to support a binary driver running on this OS. > > You buy hardware with closed source you now get to keep both bits. > > > > unsure if I can clarify this any better. > > > > Dave. > > > > > > > > > Believe it or not - I do agree with Fedora's OSS principles. However, > as the professional I know you are (despite the tone of your reply), I'm > sure you can understand the importance of hardware compatibility. > Nobody is saying you need to bend over backwards for nvidia, but > actively working to break support probably isn't the right approach > either. Surely you can find a way to collaborate with X.org, Nvidia and > the Fedora team in a way that promotes progress, rather than stifle it. > > We already know a way, its called open source development. They release the source to their driver, and I make it work with the release of X.org I personally ported nearly all the X.org driver in Fedora to the new API/ABI (~15 drivers). This was close too a full week of work, that really I could've not done and just let old hardware die. However I took the time to do this because the source was available. If I had the source to the nvidia driver I would have ported it as well. So I've done the professional bit and fixed as much as I can, if *your* hw vendor doesn't support *your* OS of choice then I think the problem is between you and your hw vendor. Dave. From jtang at magma.ca Wed May 21 00:02:02 2008 From: jtang at magma.ca (Jason Tang) Date: Tue, 20 May 2008 20:02:02 -0400 Subject: Xorg 1.5 missed the train? In-Reply-To: <604aa7910805201643oab6e480u29f0e29f8a2896fa@mail.gmail.com> References: <48334163.4080709@magma.ca> <604aa7910805201437r53a4a2eeuc824b6d3c702dcfa@mail.gmail.com> <48334C93.60405@magma.ca> <604aa7910805201532j17e57609p2d579db05e7f06a0@mail.gmail.com> <48335A8F.5000308@magma.ca> <604aa7910805201643oab6e480u29f0e29f8a2896fa@mail.gmail.com> Message-ID: <4833667A.60203@magma.ca> Jeff Spaleta wrote: > On Tue, May 20, 2008 at 3:11 PM, Jason Tang wrote: > >> 2/3, 1/3... 1/4... whatever. I'm sure you understand my point that there >> are a large number or eager F9 users in pain out there. >> > > What exactly do you want at this point? I'm prepared to get in front > of a camera, and do a video with a sincere apology to nvidia driver > users that we have chosen to provide better support for video hardware > with open drivers...than for closed source video drivers. > But nothing I can do is going to fix the problem in a way that you > want. We've never claimed to support nvidia drivers. If they > work..they work. If they don't they don't. We can't fix them...we > don't support them. I'm not going to mince words about it. > > >> Granted, I don't follow the dev group all that closely, so hopefully you can >> forgive me for thinking that what we seem to have is a circle of groups >> blaming one another for their own collective failure to deliver. >> > > Xorg has an open transparent process... we have an open transparent > process. We can't do anything more than be open and transparent. If > Nvidia wants to have a discussion with Xorg concerning development and > release cycle I'm sure that would be a fascinating thing to read. > > >> Of course, I can and will wait for the drivers I need to work before >> upgrading my primary system. Perhaps most of us 'users' would have been >> content with a heads-up about the nvidia breakage, and maybe a rough >> timeline of when to expect a fix. >> > > We've known about the nvidia breakage for months now...since the > beginning of the F9 development phase really, when the snapshots of > the new xserver were put in rawhide..back when few of the open video > drivers worked. There was more than enough time for any contributor > who cared about the NVidia issue to submit something to the release > notes process specifically about the known NVidia problems. > We have an open community driven process for the release notes. If > there is something specific you or any NVidia driver user wants added > perhaps you should look into participating in that Beat writing > process or talk to the Beat Writer for Xorg. > http://fedoraproject.org/wiki/DocsProject/ReleaseNotes/Beats > Obviously we can't point to 3rd party drivers...even if they did work. > > But how can we tell you when Nvidia will fix things? Nvidia's > development process is opaque, they don't tell people when to expect > driver updates. We cannot impact when and what NVidia chooses to do > what they do, nor can we force to be more forth coming as to their > timelines. > > >> That way there would not have been so many struggling now. >> > > Honestly I don't see how. There is absolutely nothing we can do to > impact how Nvidia will respond when X needs to make an ABI change. > All we could do is put a big notice in our release notes that Fedora > does not support 3rd party proprietary hardware drivers..full stop. > Our release notes reference a long manifesto(which I didn't write even > though it's length would suggest I did) which amounts to such a > statement. In the future I'll insist on a bolder statement explictly > stating that we do not support 3rd party drivers. If the work..great. > If they don't...they don't..take it up with the driver developers. > > -jef > > Actually, for a long time, nvidia provided better support than ATI. And for a long time Intel wasn't really much of a contender at all. IIRC, ATI only went the open-source route recently. Anyhow, thanks for taking the time to discuss the issue. I've been a RH/Fedora user since RH5 and only want the most out of my distro of choice. Sometimes I ask A LOT. Lots of good posts to consider. From jonstanley at gmail.com Wed May 21 00:08:37 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Tue, 20 May 2008 20:08:37 -0400 Subject: Small RFEs for Fedora Accounts System In-Reply-To: <645d17210805201551q2d5e1f84l8af88e7233ba76f1@mail.gmail.com> References: <645d17210805201551q2d5e1f84l8af88e7233ba76f1@mail.gmail.com> Message-ID: On Tue, May 20, 2008 at 6:51 PM, Jonathan Underwood wrote: > Hi, > > I just had the client side certificate expire. On a CVS operation I > recieved the error message: > > ERROR: Your Fedora client-side certificate expired. > You need to download a new client-side certificate > from https://admin.fedora.redhat.com/accounts/ > > > RFE#1: Please fix the URL, which should be > https://admin.fedoraproject.org/accounts That's probably someplace in CVS-land, not in FAS-land > > On logging in I helpfully see: > > Todo queue: > Download a client-side certificate i > > Clicking on the "i" I see: > > "The client side cert is generally used to grant access to upload > packages to Fedora or for other authentication purposes like with > koji. If you are not a package maintainer there is no need to worry > about the client side cert" > > RFE#2: It would be really helpful to add to the end of that info "This > certificate should be saved to ~/.fedora.cert" I would guess that this isn't an unreasonable request, but does it not default to saving as that? Been awhile since I got one. > RFE#3: Please could we add a FAS component to bugzilla? Or is there > some other component I should be filing these against? FAS is not a package in Fedora, so there is no component. You can report bugs/problems at http://fedorahosted.org/fas however. I believe, but I'm not sure, that this is on the FAS pages as well. From a.badger at gmail.com Wed May 21 00:11:15 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 20 May 2008 17:11:15 -0700 Subject: Small RFEs for Fedora Accounts System In-Reply-To: <645d17210805201551q2d5e1f84l8af88e7233ba76f1@mail.gmail.com> References: <645d17210805201551q2d5e1f84l8af88e7233ba76f1@mail.gmail.com> Message-ID: <483368A3.60600@gmail.com> Jonathan Underwood wrote: > Hi, > > I just had the client side certificate expire. On a CVS operation I > recieved the error message: > > ERROR: Your Fedora client-side certificate expired. > You need to download a new client-side certificate > from https://admin.fedora.redhat.com/accounts/ > > > RFE#1: Please fix the URL, which should be > https://admin.fedoraproject.org/accounts > This is a cvs common change. Fixed. People will have to update their common directories in order to see the change. For most packagers this means: $ cd /my/packagingarea/PACKAGENAME $ cvs up cvs update: Updating F-9 cvs update: Updating common P common/Makefile.common P common/branches cvs update: Updating devel > On logging in I helpfully see: > > Todo queue: > Download a client-side certificate i > > Clicking on the "i" I see: > > "The client side cert is generally used to grant access to upload > packages to Fedora or for other authentication purposes like with > koji. If you are not a package maintainer there is no need to worry > about the client side cert" > > RFE#2: It would be really helpful to add to the end of that info "This > certificate should be saved to ~/.fedora.cert" > Added. This will go live when we push the next fas update. > RFE#3: Please could we add a FAS component to bugzilla? Or is there > some other component I should be filing these against? > Log into: https://fedorahosted.org/fas Click on New Ticket. -Toshio From kevin.kofler at chello.at Wed May 21 00:32:48 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 21 May 2008 00:32:48 +0000 (UTC) Subject: Should I upgrade to Fedora 9 / KDE 4? References: <48334805.1000307@philipashmore.com> Message-ID: Philip Ashmore philipashmore.com> writes: > no Kate Kate has moved to kdesdk. It's supposed to be an editor for developers, KWrite is the version for average users (based on the same editing component, the KatePart), thus the move. > no science screensaver Maybe you are/were missing kdeartwork-kxs, kdeartwork-extras or one of the xscreensaver* packages? > no ksysguard KSysGuard still exists as a standalone application. What you were referring to: > I filed a bug against ksysguard / KDE 4 - > https://bugzilla.redhat.com/show_bug.cgi?id=447471 is the Kicker applet which indeed is no longer available (and this is not a bug, it has simply not been ported or rewritten for Plasma yet). Kevin Kofler From poelstra at redhat.com Wed May 21 00:16:19 2008 From: poelstra at redhat.com (John Poelstra) Date: Tue, 20 May 2008 17:16:19 -0700 Subject: Red Hat Bugzilla 3.2 Upgrade Beta 1 Message-ID: <483369D3.7010208@redhat.com> Hi, I'm passing the following information on for the team that maintains the Bugzilla instance Fedora runs in. It provides a peak into the upcoming Bugzilla update and an opportunity to evaluate it in a test instance. Check it out. John ~~~~~~~~~~~~~~~~ Greetings, The Red Hat Bugzilla team is happy to announce the first beta release of the next version of Red Hat Bugzilla. The next version will be based on the upcoming upstream 3.2 code base soon to be released. https://partner-bugzilla.redhat.com Along the way to the final release, we will be deploying several beta releases that will be used for obtaining user feedback and for finding bugs in our code changes. Red Hat has made substantial customizations to our current 2.18 based Bugzilla system that have been ported to the new release. Several of which we are working on having them accepted by the upstream community which will help in future bug fixes and lower maintenance. We are also hoping to use the upgrade process as a stepping stone to becoming more active in the future road map of Bugzilla itself by providing help with bug fixes and enhancements and taking part in future discussions. Areas of focus for beta1: Ajax optimizations: Speedup one component/version/milestone population on the advanced query screen due to large volume of data for some products such as RHEL and Fedora. Speedup of the show_bug.cgi page by reducing amount of HTML needed to download by not loading all components unless you want to change the value. Needinfo actor support: Using the flags functionality, we are able to specify whom additional information is being required of for a report. In the current 2.18 release a combination of a bug status called NEEDINFO and needinfo flag were used. In 3.2 only a needinfo flag is being used and the bug status will be removed. Guided bug entry: Modified stock guided bug entry page used to help non experts report bugs with proper information. UI enhancements: Upstream Bugzilla developers have done extension work on streamlining the show_bug.cgi page. The page should have a cleaner less cluttered feel as well as show only editable fields for the values the user is allowed to change only. One of the more noticeable things is the removal of the "Bug Status Change" area and moving it up to the basic bug information area. External bug references: Ability to add links to outside bug trackers. XMLRPC API: The Red Hat Bugzilla system was one of the first Bugzilla installations to utilize XMLRPC extensively. Upstream as of 3.0 has a new framework for providing Web Services to clients to manipulate Bugzilla data. We have worked to help the upstream to add features to this framework to support similar functionality to what we have had in operation for some time. Some of the core functions are there such as Bug.get(), Bug.create(), Bug.search() and Bug.update() which can be used to do most things needed. Some of the operations available in our version are not yet available so we are also providing most of the old 2.18 API so that your applications and scripts should continue to work properly for the time being. Please try your scripts against the test Bugzilla system to make sure they are working properly. Let us know if there are any errors such as data not being returned in the proper format, certain methods missing, or bugs in general. New methods available (Note: these are subject to change before final release): 1. Bug.get() - Can be used to get all attributes of one or more bug reports. 2. Bug.create() - Can create a new bug report in the system. 3. Bug.update() - Can update most attributes of one or more current bug reports. 4. Bug.search() - Search the database for bugs matching search criteria similar to advanced search UI. Also supports quicksearch keywords and reloading of saved searches saved in the Bugzilla UI. 5. Bug.get_activity() - Retrieve full history of one or more bug reports. 6. Bug.add_comment() - Can add a comment to a current bug report. 7. User.login() - Can take a username and password as parameters that will return cookies that can be used for all subsequent XMLRPC method calls. (Note: required to use the new methods such as Bug.*) 8. User.create() - Create a new user if you have proper permissions. 9. User.get() - Get information about one or more current users if you have proper permissions. 10. User.update() - Allows updating of email, real name, disabled, etc for one or more current users. 11. Product.get_products() - Get information about one or more products in Bugzilla. 12. Component.get() - Get information about one or more Bugzilla components. 13. Component.create() - Create a new Bugzilla component for a specific product. 14. Component.update() - Updated the attributes of one or more Bugzilla components. Old methods ported to 3.2 (for backwards compatibility): 1. bugzilla.runQuery() 2. bugzilla.getBug() 3. bugzilla.addIT() 4. bugzilla.getBugActivity() 5. bugzilla.nameToId() 6. bugzilla.login() 7. bugzilla.getBugSimple() 8. bugzilla.editComponent() 9. bugzilla.idToName() 10. bugzilla.getBugModified() 11. bugzilla.addComment() 12. bugzilla.updateFlags() 13. bugzilla.closeBug() 14. bugzilla.changeStatus() 15. bugzilla.updateCC() 16. bugzilla.getProdInfo() 17. bugzilla.createBug() 18. bugzilla.changeAssignment() 19. bugzilla.updateDepends() 20. bugzilla.getProdCompDetails() 21. bugzilla.addComponent() 22. bugzilla.updateMilestone() 23. bugzilla.getCompInfo() 24. bugzilla.getProductDetails() 25. bugzilla.getProductDetails() 26. bugzilla.userInfo() 27. bugzilla.addUser() 28. bugzilla.disableAccount() The newer API is likely to change before the next release of upstream Bugzilla so we will be maintaining the older API during the time from 3.2 leading up to the next release. We do encourage people to try out the new API also so as to be ready for the eventual transition. There are numerous other changes behind the scenes that we haven't listed. The goal is to make sure that functionality that people have come to expect in 2.18 is possible in the new system. There are also numerous new features/fixes that are part of the upcoming 3.2 release provided by the upstream Bugzilla community. For more detailed information on what has changed since the last release, check out the [https://partner-bugzilla.redhat.com/page.cgi?id=release-notes.html Release Notes]. The database is a recent snapshot of the live database so should be useful for testing to make sure the information is displayed properly and changeable. Also with a full snapshot it is possible to test for any performance related issues. Email has been disabled so that unnecessary spam is not sent out. So feel free to make changes to bugs to verify proper working order. We are asking for everyone to get involved as much as possible with testing and feedback on the beta releases to help us make this the most robust and stable release possible. We have done extensive work at laying out what we feel the requirements are to maintain feature parity with our current system as well as compiled a list of feature enhancements that people would like to see in the next release. Our goal is to deliver a working bugzilla with the bare essential requirements similar to what is currently being used in our current 2.18 system. After that we will begin work on enhancements as time and resources permit. To view the final release requirements list please refer to our [https://bugzilla.redhat.com/show_bug.cgi?id=406071 Bugzilla 3 Tracker]. Please file any enhancement requests or bug reports in our current Bugzilla system at [https://bugzilla.redhat.com bugzilla.redhat.com]. File them under the Bugzilla product and relevant component with the version 3.2. With everyones help we can make this a great release. Thanks The Red Hat Bugzilla Team _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From kevin.kofler at chello.at Wed May 21 00:41:46 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 21 May 2008 00:41:46 +0000 (UTC) Subject: F8 -> F9 but keeping KDE3: technically feasible? References: <483076E8.70601@robertoragusa.it> <483295E6.8030404@gmail.com> <48332C43.3080501@robertoragusa.it> <48333034.7080502@gmail.com> Message-ID: Andrew Farris gmail.com> writes: > You can use the nvidia drivers with F9 if you run the F8 xorg packages; quite > a few people have been doing this with success throughout the F9 development. But if he's using F8 KDE and F8 X.Org X11, there's not much left of F9, is there? I mean, what's the goal? Being able to say he's "running F9"? IMHO it is a really bad idea to try to upgrade only parts of the distro, we have done ABSOLUTELY ZERO testing of the KDE 3 packages from F8 with F9, whoever attempts that may run into dependency problems and other issues. Kevin Kofler From lesmikesell at gmail.com Wed May 21 00:57:59 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 20 May 2008 19:57:59 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: <483360A4.3080005@fedoraproject.org> References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <20080520215909.GF12622@inocybe.teonanacatl.org> <48334E0E.7090803@gmail.com> <48334F03.6070203@fedoraproject.org> <35207.75.164.221.130.1211322487.squirrel@clueserver.org> <1218b5bc0805201625p21ba80b9y9cffd6eeb7fcec9b@mail.gmail.com> <48335FC0.2070806@gmail.com> <483360A4.3080005@fedoraproject.org> Message-ID: <48337397.3050202@gmail.com> Rahul Sundaram wrote: > Les Mikesell wrote: > >> >> Please post that on the http://fedoraproject.org/ page so everyone >> will understand what to expect. > > Frontpage of a project website is not anybody's playing ground to > scribble random information. No, it is the place to post your philosophy, and the place to make it absolutely clear whether or not you are working to release what you think is a stable product or whether you expect the users to become unwilling beta testers. > For those who care, there is ample amount > of information including the overview page. Insisting on putting > everything on the frontpage is just silly and not going to happen. Just the philosophy please. If you accidentally mistook a pre-release X version for a release version and shipped it, that's something you can gloss over in the fine print. If you think it is better for the users to deal with pre-release problems they deserve to know. -- Les Mikesell lesmikesell at gmail.com From lesmikesell at gmail.com Wed May 21 01:02:58 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 20 May 2008 20:02:58 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: <1211326768.10484.4.camel@clockmaker.usersys.redhat.com> References: <48334163.4080709@magma.ca> <1211326768.10484.4.camel@clockmaker.usersys.redhat.com> Message-ID: <483374C2.1030800@gmail.com> Dave Airlie wrote: > > Fedora is about having an open distro and we are *never* going to expend > time or effort to support a binary driver. Was anyone asking you to "support" one of the vendors that actually makes an effort to help Linux users? The issue is about shipping software with stable interfaces - i.e. release versions. Otherwise you are actively sabotaging anyone who wants to cooperate. -- Les Mikesell lesmikesell at gmail.com From sundaram at fedoraproject.org Wed May 21 01:05:45 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 21 May 2008 06:35:45 +0530 Subject: Xorg 1.5 missed the train? In-Reply-To: <48337397.3050202@gmail.com> References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <20080520215909.GF12622@inocybe.teonanacatl.org> <48334E0E.7090803@gmail.com> <48334F03.6070203@fedoraproject.org> <35207.75.164.221.130.1211322487.squirrel@clueserver.org> <1218b5bc0805201625p21ba80b9y9cffd6eeb7fcec9b@mail.gmail.com> <48335FC0.2070806@gmail.com> <483360A4.3080005@fedoraproject.org> <48337397.3050202@gmail.com> Message-ID: <48337569.6060201@fedoraproject.org> Les Mikesell wrote: > Rahul Sundaram wrote: >> Les Mikesell wrote: >> >>> >>> Please post that on the http://fedoraproject.org/ page so everyone >>> will understand what to expect. >> >> Frontpage of a project website is not anybody's playing ground to >> scribble random information. > > No, it is the place to post your philosophy. There is a link to overview and objectives which explains all that. Again, posting all of the content to the front page is not going to happen. Rahul From airlied at redhat.com Wed May 21 01:09:55 2008 From: airlied at redhat.com (Dave Airlie) Date: Wed, 21 May 2008 11:09:55 +1000 Subject: Xorg 1.5 missed the train? In-Reply-To: <483374C2.1030800@gmail.com> References: <48334163.4080709@magma.ca> <1211326768.10484.4.camel@clockmaker.usersys.redhat.com> <483374C2.1030800@gmail.com> Message-ID: <1211332195.10484.18.camel@clockmaker.usersys.redhat.com> On Tue, 2008-05-20 at 20:02 -0500, Les Mikesell wrote: > Dave Airlie wrote: > > > > Fedora is about having an open distro and we are *never* going to expend > > time or effort to support a binary driver. > > Was anyone asking you to "support" one of the vendors that actually > makes an effort to help Linux users? The issue is about shipping > software with stable interfaces - i.e. release versions. Otherwise you > are actively sabotaging anyone who wants to cooperate. > No it isn't. You clearly don't understand the problem. Let me say it real slow now.. 1. X.org ABI for 1.5 is what we ship in F9, this hasn't changed in months, I've ported 15 other drivers to it in this time. It will not change before 1.5 final is released. 2. Nvidia don't release drivers for X.org releases. 3. Nvidia only bother releasing drivers when a distro has shipped the ABI. Now we happen to be the first distro to ship most things, so we get to be distro that nvidia have to port their drivers to. Other distros lag releasing, however it won't help us if we lag, as Nvidia won't do anything until one of Fedora, Ubuntu, OpenSUSE, RHEL, or SLED do a release. We are not standing still so you can use your binary software, and if you think nvidia are doing it for the users I've got a nice bridge for sale. Dave. From lesmikesell at gmail.com Wed May 21 01:09:45 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 20 May 2008 20:09:45 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: <48336316.8060606@fedoraproject.org> References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <20080520215909.GF12622@inocybe.teonanacatl.org> <48334E0E.7090803@gmail.com> <48334F03.6070203@fedoraproject.org> <35207.75.164.221.130.1211322487.squirrel@clueserver.org> <1218b5bc0805201625p21ba80b9y9cffd6eeb7fcec9b@mail.gmail.com> <48336316.8060606@fedoraproject.org> Message-ID: <48337659.9090703@gmail.com> Rahul Sundaram wrote: > Erich Zigler wrote: > >> I see and agree with the point of not being held hostage by a vendor, >> and there is no winners here. Only losers and those losers are the >> Fedora users who depend on the nvidia drivers > > Yes. Once users start depending on proprietary drivers, they have > already lost the game. I am reminded of this discussion from Linus. > > http://lwn.net/1999/0211/a/lt-binary.html > > "Basically, I want people to know that when they use binary-only > modules, it's THEIR problem. I want people to know that in their bones, > and I want it shouted out from the rooftops. I want people to wake up > in a cold sweat every once in a while if they use binary-only modules." > If Linus got everything right, Red Hat could ship stock kernels and no one would need their support services. -- Les Mikesell lesmikesell at gmail.com From jkeating at redhat.com Wed May 21 01:11:25 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 20 May 2008 21:11:25 -0400 Subject: Xorg 1.5 missed the train? In-Reply-To: <483374C2.1030800@gmail.com> References: <48334163.4080709@magma.ca> <1211326768.10484.4.camel@clockmaker.usersys.redhat.com> <483374C2.1030800@gmail.com> Message-ID: <1211332285.8531.50.camel@localhost.localdomain> On Tue, 2008-05-20 at 20:02 -0500, Les Mikesell wrote: > > Was anyone asking you to "support" one of the vendors that actually > makes an effort to help Linux users? The issue is about shipping > software with stable interfaces - i.e. release versions. Otherwise you > are actively sabotaging anyone who wants to cooperate. Perhaps you missed the part where the ABI of X is stable for this release, and that's why the upstream maintainer wanted to see it shipped in the Fedora 9 release. Just because it doesn't have the magical "1.5" string attached doesn't mean the ABI is done and stable. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jwboyer at gmail.com Wed May 21 01:12:28 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 20 May 2008 20:12:28 -0500 Subject: changes at planet fedora In-Reply-To: <48335785.4050800@fedoraproject.org> References: <1211214812.3095.0.camel@cutter> <6e24a8e80805201301r44a241bdr9b2263052fe1fd8b@mail.gmail.com> <6e24a8e80805201550o12531af3ye6692f9571cb5230@mail.gmail.com> <48335785.4050800@fedoraproject.org> Message-ID: <20080520201228.3dfb45b6@vader.jdub.homelinux.org> On Wed, 21 May 2008 04:28:13 +0530 Rahul Sundaram wrote: > Mark wrote: > > Oke all that information made me change my mind a bit about it.. I > > still don't think it's a good idea but at least it's not a horrible as > > i thought it was. I still don't like it that you need to have a fedora > > account to be part of the planet.. seems odd to me. > > Planet Fedora is explicitly a aggregation of blogs from official Fedora > contributors who require a Fedora account anyway. What is being done Actually, I don't think that's quite true. There is at least one blog syndicated there that doesn't have a FAS account today. So the FAS requirement is new. josh From sundaram at fedoraproject.org Wed May 21 01:18:28 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 21 May 2008 06:48:28 +0530 Subject: Xorg 1.5 missed the train? In-Reply-To: <48337659.9090703@gmail.com> References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <20080520215909.GF12622@inocybe.teonanacatl.org> <48334E0E.7090803@gmail.com> <48334F03.6070203@fedoraproject.org> <35207.75.164.221.130.1211322487.squirrel@clueserver.org> <1218b5bc0805201625p21ba80b9y9cffd6eeb7fcec9b@mail.gmail.com> <48336316.8060606@fedoraproject.org> <48337659.9090703@gmail.com> Message-ID: <48337864.507@fedoraproject.org> Les Mikesell wrote: > If Linus got everything right, Red Hat could ship stock kernels and no > one would need their support services. Red Hat wouldn't be the largest contributor the kernel if it didn't think it was moving in the right direction. Support services are valuable due to the inherent complexity of an operating system and it would still be valuable if Red Hat ships "stock" kernels. Rahul From seg at haxxed.com Wed May 21 01:22:55 2008 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 20 May 2008 20:22:55 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: <48336316.8060606@fedoraproject.org> References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <20080520215909.GF12622@inocybe.teonanacatl.org> <48334E0E.7090803@gmail.com> <48334F03.6070203@fedoraproject.org> <35207.75.164.221.130.1211322487.squirrel@clueserver.org> <1218b5bc0805201625p21ba80b9y9cffd6eeb7fcec9b@mail.gmail.com> <48336316.8060606@fedoraproject.org> Message-ID: <1218b5bc0805201822p52f0dab8l3c22b76540d1cd42@mail.gmail.com> On Tue, May 20, 2008 at 6:47 PM, Rahul Sundaram wrote: > Yes. Once users start depending on proprietary drivers, they have already > lost the game. I am reminded of this discussion from Linus. > > http://lwn.net/1999/0211/a/lt-binary.html > > "Basically, I want people to know that when they use binary-only modules, > it's THEIR problem. I want people to know that in their bones, and I want > it shouted out from the rooftops. I want people to wake up in a cold sweat > every once in a while if they use binary-only modules." > Can that go on the front page? ;) This strikes right at the heart of exactly why I think open source is the superior development process. With all source available, we have total freedom to refactor and redesign our APIs, and drop legacy cruft. We can keep our code cleaner and move forward faster than any closed vendor can even dream of attaining. Just look at Windows. How many crufty, old and broken APIs is Vista still carrying around in it? I don't even want to know. Hey look a handy quote from the "Windows API" WIkipedia page: "Raymond Chen , a Microsoft developer who works on the Windows API, has said: "I could probably write for months solely about bad things apps do and what we had to do to get them to work again (often in spite of themselves). Which is why I get particularly furious when people accuse Microsoft of maliciously breaking applications during OS upgrades. If any application failed to run on Windows 95, I took it as a personal failure."" This is the trade off we have chosen. We give up long term API and ABI stability to achieve cleaner, better, more maintainable code. We can do this because we can fix application code ourselves if their own developers refuse to. Microsoft does not have that option. And of course this means we constantly get accused by various asshats who simply Don't Get It that we're "actively breaking things" and "sabotaging everyone" and "refusing to cooperate". It is closed vendors like Nvidia who are refusing to cooperate in our open process. Seriously, go back to Windows. You do not belong here. Yes I'm talking to you, Les. GTFO -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwboyer at gmail.com Wed May 21 01:24:04 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 20 May 2008 20:24:04 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <1211319877.8531.40.camel@localhost.localdomain> <604aa7910805201505m7cc84699p953aa880b7419413@mail.gmail.com> <20080520174855.49dd2154@vader.jdub.homelinux.org> Message-ID: <20080520202404.53258cb9@vader.jdub.homelinux.org> On Tue, 20 May 2008 15:54:52 -0700 "Christopher Stone" wrote: > > If it's that simple, you should be able to do it yourself. The code is > > there. Have at it. > > > > (HINT: It's not simple at all) > > > According to this thread it seems pretty simple actually: > > http://www.fedoraforum.org/forum/showthread.php?t=188645 Sure. Creating them locally is simple. Then all you'd have to do is get it past review, get the primary Xorg maintainer to agree, and support it for the entire release. Which includes handling all the bug reports for it. Which you might get a lot of and won't be able to do a damn thing about because of binary drivers. Maintaining free software is like having a kid. Anyone can make it, but it takes someone that actually cares to maintain it well. > If redhat wants to pay me $100k a year, I'll happily make xorg compat > rpms in about one day. Thank you very much. I believe that shows your fundamental lack of understanding about Fedora and open source software on many levels. josh From chris.stone at gmail.com Wed May 21 01:38:37 2008 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 20 May 2008 18:38:37 -0700 Subject: Xorg 1.5 missed the train? In-Reply-To: <20080520202404.53258cb9@vader.jdub.homelinux.org> References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <1211319877.8531.40.camel@localhost.localdomain> <604aa7910805201505m7cc84699p953aa880b7419413@mail.gmail.com> <20080520174855.49dd2154@vader.jdub.homelinux.org> <20080520202404.53258cb9@vader.jdub.homelinux.org> Message-ID: On Tue, May 20, 2008 at 6:24 PM, Josh Boyer wrote: > On Tue, 20 May 2008 15:54:52 -0700 > "Christopher Stone" wrote: >> > If it's that simple, you should be able to do it yourself. The code is >> > there. Have at it. >> > >> > (HINT: It's not simple at all) >> >> >> According to this thread it seems pretty simple actually: >> >> http://www.fedoraforum.org/forum/showthread.php?t=188645 > > Sure. Creating them locally is simple. Then all you'd have to do is > get it past review, get the primary Xorg maintainer to agree, and > support it for the entire release. Which includes handling all the bug > reports for it. Which you might get a lot of and won't be able > to do a damn thing about because of binary drivers. I don't give a hoot if the packages are supported or not, I just want an easy way to get my nVidia card working. All you people do is gripe and moan about how much work it would be and all this and that. Look, its just a matter of adding rpms to a repo, make an "unsupported" repo if you have to. The bottom line is you want to have as many people testing the OS as possible. > > Maintaining free software is like having a kid. Anyone can make it, > but it takes someone that actually cares to maintain it well. And obviously ajax does not care about 50% of Fedora's user base. It would seem to me that he is not being a good maintainer, I hope he raises his kids better than he maintains xorg. > >> If redhat wants to pay me $100k a year, I'll happily make xorg compat >> rpms in about one day. Thank you very much. > > I believe that shows your fundamental lack of understanding about > Fedora and open source software on many levels. I believe you have no idea what you are talking about. If I maintained a package which I knew was not going to work with 50% of the users hardware, and I was being paid to maintain this package, then I certainly would spend some time to allow those 50% a way to use their hardware with the rest of the OS. Nothing more to it than that, it has nothing to do with open source, it has everything to do with being professional. From denis at poolshark.org Wed May 21 01:39:30 2008 From: denis at poolshark.org (Denis Leroy) Date: Tue, 20 May 2008 18:39:30 -0700 Subject: Xorg 1.5 missed the train? In-Reply-To: <48334163.4080709@magma.ca> References: <48334163.4080709@magma.ca> Message-ID: <48337D52.7050005@poolshark.org> Jason Tang wrote: > The only problem being that this release is incompatible with current > nvidia drivers. Granted, I'm aware of the Fedora position regarding > non-OSS, but this Xorg issue has completely destroyed many user's > confidence in the dev team. That's nothing new you know. Out of the 9 fedora releases, I think at least 8 out of 9 didn't work with the Nvidia driver at release time. however Nvidia is usually pretty good at playing catch up. I'm also hostage to Nvidia's good will for my Lenovo T61's Quadro chipset, and can't upgrade to F-9 until their next release (nv doesn't work at all on this chipset). I wouldn't go back to a Radeon chipset though, not until we have a working free equivalent (emphasis on 'working') to nvidia-settings for easy dual-head support... The good news is that with xrandr maturing, we're probably almost there. From seg at haxxed.com Wed May 21 01:46:10 2008 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 20 May 2008 20:46:10 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <1211319877.8531.40.camel@localhost.localdomain> <604aa7910805201505m7cc84699p953aa880b7419413@mail.gmail.com> <20080520174855.49dd2154@vader.jdub.homelinux.org> <20080520202404.53258cb9@vader.jdub.homelinux.org> Message-ID: <1218b5bc0805201846v19edd85n3be4b48e3c519428@mail.gmail.com> Allow me to translate: On Tue, May 20, 2008 at 8:38 PM, Christopher Stone wrote: > I don't give a hoot if the packages are supported or not, I just want > an easy way to get my nVidia card working. All you people do is gripe > and moan about how much work it would be and all this and that. Look, > its just a matter of adding rpms to a repo, make an "unsupported" repo > if you have to. The bottom line is you want to have as many people > testing the OS as possible. I want a pony. And obviously ajax does not care about 50% of Fedora's user base. It > would seem to me that he is not being a good maintainer, I hope he > raises his kids better than he maintains xorg. > Ajax is a poopy-head who won't give me a pony. > I believe you have no idea what you are talking about. If I > maintained a package which I knew was not going to work with 50% of > the users hardware, and I was being paid to maintain this package, > then I certainly would spend some time to allow those 50% a way to use > their hardware with the rest of the OS. Nothing more to it than that, > it has nothing to do with open source, it has everything to do with > being professional. If *I* were Ajax I'd give me a pony! -------------- next part -------------- An HTML attachment was scrubbed... URL: From abartlet at samba.org Wed May 21 01:54:36 2008 From: abartlet at samba.org (Andrew Bartlett) Date: Wed, 21 May 2008 11:54:36 +1000 Subject: kdepim/libmapi In-Reply-To: <200805201150.14705.jbarnes@virtuousgeek.org> References: <20080520102245.C6395209D29@releng1.fedora.phx.redhat.com> <200805201113.56371.jbarnes@virtuousgeek.org> <200805201150.14705.jbarnes@virtuousgeek.org> Message-ID: <1211334876.3469.23.camel@naomi> On Tue, 2008-05-20 at 11:50 -0700, Jesse Barnes wrote: > On Tuesday, May 20, 2008 11:29 am Rex Dieter wrote: > > Jesse Barnes wrote: > > > On Tuesday, May 20, 2008 10:18 am Kevin Kofler wrote: > > >> We have upgraded kdepim to a snapshot of kdepim 4.1 in Rawhide. > > > > > > Do the new packages include libmapi support for akonadi? > > > > no, libmapi isn't in fedora (yet), when it is, the support for it in kdepim > > will be enabled. > > > > We'll package libmapi for review eventually, but would love it if someone > > beats us to it. > > I tried building it recently; it depends on experimental samba bits. So > whoever packages it may have to include a snapshot of the required samba > headers & code... I'm very happy to work with anyone wishing to package Samba4. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From chris.stone at gmail.com Wed May 21 01:54:53 2008 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 20 May 2008 18:54:53 -0700 Subject: Xorg 1.5 missed the train? In-Reply-To: <1218b5bc0805201846v19edd85n3be4b48e3c519428@mail.gmail.com> References: <48334163.4080709@magma.ca> <1211319877.8531.40.camel@localhost.localdomain> <604aa7910805201505m7cc84699p953aa880b7419413@mail.gmail.com> <20080520174855.49dd2154@vader.jdub.homelinux.org> <20080520202404.53258cb9@vader.jdub.homelinux.org> <1218b5bc0805201846v19edd85n3be4b48e3c519428@mail.gmail.com> Message-ID: 2008/5/20 Callum Lerwick : > Allow me to translate: > > On Tue, May 20, 2008 at 8:38 PM, Christopher Stone > wrote: >> >> I don't give a hoot if the packages are supported or not, I just want >> an easy way to get my nVidia card working. All you people do is gripe >> and moan about how much work it would be and all this and that. Look, >> its just a matter of adding rpms to a repo, make an "unsupported" repo >> if you have to. The bottom line is you want to have as many people >> testing the OS as possible. > > I want a pony. You sir seem to want a flame war. > >> And obviously ajax does not care about 50% of Fedora's user base. It >> would seem to me that he is not being a good maintainer, I hope he >> raises his kids better than he maintains xorg. > > Ajax is a poopy-head who won't give me a pony. I personally can live without 3D support, I'm speaking for all the people out there who just would like working hardware. > >> >> I believe you have no idea what you are talking about. If I >> maintained a package which I knew was not going to work with 50% of >> the users hardware, and I was being paid to maintain this package, >> then I certainly would spend some time to allow those 50% a way to use >> their hardware with the rest of the OS. Nothing more to it than that, >> it has nothing to do with open source, it has everything to do with >> being professional. > > If *I* were Ajax I'd give me a pony! You can have your pony, I would just like one day to actually be able to recommend the OS I use to my neighbors without being embarrassed. From airlied at redhat.com Wed May 21 02:00:26 2008 From: airlied at redhat.com (Dave Airlie) Date: Wed, 21 May 2008 12:00:26 +1000 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <1211319877.8531.40.camel@localhost.localdomain> <604aa7910805201505m7cc84699p953aa880b7419413@mail.gmail.com> <20080520174855.49dd2154@vader.jdub.homelinux.org> <20080520202404.53258cb9@vader.jdub.homelinux.org> <1218b5bc0805201846v19edd85n3be4b48e3c519428@mail.gmail.com> Message-ID: <1211335226.3768.1.camel@clockmaker.usersys.redhat.com> > > You can have your pony, I would just like one day to actually be able > to recommend the OS I use to my neighbors without being embarrassed. > Well since you recommend they use binary software, why not just say use Windows? Dave. From stickster at gmail.com Wed May 21 02:02:42 2008 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 21 May 2008 02:02:42 +0000 Subject: Xorg 1.5 missed the train? In-Reply-To: <1218b5bc0805201822p52f0dab8l3c22b76540d1cd42@mail.gmail.com> References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <20080520215909.GF12622@inocybe.teonanacatl.org> <48334E0E.7090803@gmail.com> <48334F03.6070203@fedoraproject.org> <35207.75.164.221.130.1211322487.squirrel@clueserver.org> <1218b5bc0805201625p21ba80b9y9cffd6eeb7fcec9b@mail.gmail.com> <48336316.8060606@fedoraproject.org> <1218b5bc0805201822p52f0dab8l3c22b76540d1cd42@mail.gmail.com> Message-ID: <1211335362.24852.294.camel@victoria> On Tue, 2008-05-20 at 20:22 -0500, Callum Lerwick wrote: > This is the trade off we have chosen. We give up long term API and ABI > stability to achieve cleaner, better, more maintainable code. We can > do this because we can fix application code ourselves if their own > developers refuse to. Microsoft does not have that option. And of > course this means we constantly get accused by various asshats who > simply Don't Get It that we're "actively breaking things" and > "sabotaging everyone" and "refusing to cooperate". It is closed > vendors like Nvidia who are refusing to cooperate in our open process. > Seriously, go back to Windows. You do not belong here. Yes I'm talking > to you, Les. GTFO You were doing really well up to the last couple of lines. Please, let's try to keep things civil. I know it's frustrating when community members have to explain open source fundamentals repeatedly. This might make good fodder for a FAQ entry, to which you could simply point. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From chris.stone at gmail.com Wed May 21 02:04:03 2008 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 20 May 2008 19:04:03 -0700 Subject: Xorg 1.5 missed the train? In-Reply-To: <1211335226.3768.1.camel@clockmaker.usersys.redhat.com> References: <48334163.4080709@magma.ca> <604aa7910805201505m7cc84699p953aa880b7419413@mail.gmail.com> <20080520174855.49dd2154@vader.jdub.homelinux.org> <20080520202404.53258cb9@vader.jdub.homelinux.org> <1218b5bc0805201846v19edd85n3be4b48e3c519428@mail.gmail.com> <1211335226.3768.1.camel@clockmaker.usersys.redhat.com> Message-ID: On Tue, May 20, 2008 at 7:00 PM, Dave Airlie wrote: > >> >> You can have your pony, I would just like one day to actually be able >> to recommend the OS I use to my neighbors without being embarrassed. >> > > Well since you recommend they use binary software, why not just say use > Windows? I always recommend the *best* software. In *most* cases this is open source. In the case of nVidia 3D drivers, it's closed source. In a perfect world everything would be open source, in the real world everything isn't open source. From seg at haxxed.com Wed May 21 02:04:54 2008 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 20 May 2008 21:04:54 -0500 Subject: getting rid of vendor prefixes for desktop files In-Reply-To: <48332B79.8070301@gmail.com> References: <1211303923.8530.10.camel@localhost.localdomain> <48332B79.8070301@gmail.com> Message-ID: <1218b5bc0805201904r6f454277ldd71248db956379e@mail.gmail.com> On Tue, May 20, 2008 at 2:50 PM, Toshio Kuratomi wrote: > * It is important that vendor_id stay constant for the life of a package. > This is mostly for the sake of menu-editing (which bases off of .desktop > file/path names). > ''' > > So this is confusing as to whether --vendor is mandatory or optional. I > can't think of a reason that we'd want to keep recommending --vendor if both > you and Rex are in favor of dropping it and we can figure out some way to > mitigate the customized menu issue. One thing I don't understand is how you reconcile this with the actually fairly common occurrence of the upstream vendor changing hands? Say if FooCo has a piece of software called Fooinator, and FooCo goes out of business or otherwise lets Fooinator go stale, and a community project forks it and continues development under the same name. Or maybe FooCo gets bought by BarCo. Does the filename get stuck as fooco-fooinator.desktop forever? Seems to me the simple answer is to just drop the seemingly useless notion of vendor_id. :P What is the filename getting used for? Why are we keying on it? Something smells broken here. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwboyer at gmail.com Wed May 21 02:07:25 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 20 May 2008 21:07:25 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <1211319877.8531.40.camel@localhost.localdomain> <604aa7910805201505m7cc84699p953aa880b7419413@mail.gmail.com> <20080520174855.49dd2154@vader.jdub.homelinux.org> <20080520202404.53258cb9@vader.jdub.homelinux.org> Message-ID: <20080520210725.1707cd60@vader.jdub.homelinux.org> On Tue, 20 May 2008 18:38:37 -0700 "Christopher Stone" wrote: > >> According to this thread it seems pretty simple actually: > >> > >> http://www.fedoraforum.org/forum/showthread.php?t=188645 > > > > Sure. Creating them locally is simple. Then all you'd have to do is > > get it past review, get the primary Xorg maintainer to agree, and > > support it for the entire release. Which includes handling all the bug > > reports for it. Which you might get a lot of and won't be able > > to do a damn thing about because of binary drivers. > > I don't give a hoot if the packages are supported or not, I just want > an easy way to get my nVidia card working. All you people do is gripe You have a way. You even pointed it out to me. Do what is posted in that forum and you have your solution. Why are you continuing to bother us? > and moan about how much work it would be and all this and that. Look, > its just a matter of adding rpms to a repo, make an "unsupported" repo > if you have to. The bottom line is you want to have as many people > testing the OS as possible. No. The bottom line is that Fedora does not care about, cater to, or promote binary drivers. Period. > > Maintaining free software is like having a kid. Anyone can make it, > > but it takes someone that actually cares to maintain it well. > > And obviously ajax does not care about 50% of Fedora's user base. It You pulled that number out of your ass. And it's wrong. You have no data to back that up, and what data does exist on smolts.org shows ATI has a lead. > would seem to me that he is not being a good maintainer, I hope he > raises his kids better than he maintains xorg. He raises his "kids" just fine. He makes no claims for nVidia's "kids" though. Seriously, he can't even begin to do anything about a driver that isn't open sourced. > >> If redhat wants to pay me $100k a year, I'll happily make xorg compat > >> rpms in about one day. Thank you very much. > > > > I believe that shows your fundamental lack of understanding about > > Fedora and open source software on many levels. > > I believe you have no idea what you are talking about. If I You can believe whatever the hell you want. That doesn't make it true. > maintained a package which I knew was not going to work with 50% of > the users hardware, and I was being paid to maintain this package, > then I certainly would spend some time to allow those 50% a way to use > their hardware with the rest of the OS. Nothing more to it than that, > it has nothing to do with open source, it has everything to do with > being professional. 1) It goes against the goals of Fedora, so it's not being unprofessional. 2) The maintainer's employment status should have no bearing on this argument whatsoever. What if the Xorg maintainer were a community volunteer, like 2/3 of our other packages? 3) If you're that pissed off about it, call nVidia and complain. Do something useful rather than yelling at people that provide you with pretty darn good software and don't ask for anything in return. josh From jwboyer at gmail.com Wed May 21 02:11:37 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 20 May 2008 21:11:37 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <604aa7910805201505m7cc84699p953aa880b7419413@mail.gmail.com> <20080520174855.49dd2154@vader.jdub.homelinux.org> <20080520202404.53258cb9@vader.jdub.homelinux.org> <1218b5bc0805201846v19edd85n3be4b48e3c519428@mail.gmail.com> <1211335226.3768.1.camel@clockmaker.usersys.redhat.com> Message-ID: <20080520211137.67744ac3@vader.jdub.homelinux.org> On Tue, 20 May 2008 19:04:03 -0700 "Christopher Stone" wrote: > On Tue, May 20, 2008 at 7:00 PM, Dave Airlie wrote: > > > >> > >> You can have your pony, I would just like one day to actually be able > >> to recommend the OS I use to my neighbors without being embarrassed. > >> > > > > Well since you recommend they use binary software, why not just say use > > Windows? > > I always recommend the *best* software. In *most* cases this is open > source. In the case of nVidia 3D drivers, it's closed source. In a > perfect world everything would be open source, in the real world > everything isn't open source. In your perfect world, everyone would agree with your approach and this entire conversation wouldn't happen. In the real world, you're asking Fedora to do something to enable binary drivers which goes against it's goals. And then you're whining about it when we say no. josh From chris.stone at gmail.com Wed May 21 02:15:26 2008 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 20 May 2008 19:15:26 -0700 Subject: Xorg 1.5 missed the train? In-Reply-To: <20080520210725.1707cd60@vader.jdub.homelinux.org> References: <48334163.4080709@magma.ca> <1211319877.8531.40.camel@localhost.localdomain> <604aa7910805201505m7cc84699p953aa880b7419413@mail.gmail.com> <20080520174855.49dd2154@vader.jdub.homelinux.org> <20080520202404.53258cb9@vader.jdub.homelinux.org> <20080520210725.1707cd60@vader.jdub.homelinux.org> Message-ID: On Tue, May 20, 2008 at 7:07 PM, Josh Boyer wrote: > No. The bottom line is that Fedora does not care about, cater to, or > promote binary drivers. Period. Do they care about having a usable fully functional system for a majority of their users? > You pulled that number out of your ass. And it's wrong. You have no > data to back that up, and what data does exist on smolts.org shows ATI > has a lead. I *have* looked at the smolt stats, and they don't make any sense at all. 1.6% and 1.9%, that doesn't make any sense, the smolt stats have to be wrong. I'm sure the total number of nVidia and ATI fedora desktop users is more than 4%. From chris.stone at gmail.com Wed May 21 02:19:08 2008 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 20 May 2008 19:19:08 -0700 Subject: Xorg 1.5 missed the train? In-Reply-To: <20080520211137.67744ac3@vader.jdub.homelinux.org> References: <48334163.4080709@magma.ca> <20080520174855.49dd2154@vader.jdub.homelinux.org> <20080520202404.53258cb9@vader.jdub.homelinux.org> <1218b5bc0805201846v19edd85n3be4b48e3c519428@mail.gmail.com> <1211335226.3768.1.camel@clockmaker.usersys.redhat.com> <20080520211137.67744ac3@vader.jdub.homelinux.org> Message-ID: On Tue, May 20, 2008 at 7:11 PM, Josh Boyer wrote: > On Tue, 20 May 2008 19:04:03 -0700 > "Christopher Stone" wrote: > >> On Tue, May 20, 2008 at 7:00 PM, Dave Airlie wrote: >> > >> >> >> >> You can have your pony, I would just like one day to actually be able >> >> to recommend the OS I use to my neighbors without being embarrassed. >> >> >> > >> > Well since you recommend they use binary software, why not just say use >> > Windows? >> >> I always recommend the *best* software. In *most* cases this is open >> source. In the case of nVidia 3D drivers, it's closed source. In a >> perfect world everything would be open source, in the real world >> everything isn't open source. > > In your perfect world, everyone would agree with your approach and this > entire conversation wouldn't happen. > > In the real world, you're asking Fedora to do something to enable > binary drivers which goes against it's goals. And then you're whining > about it when we say no. Oh yea, to have one developer spend one day to provide a compatibility route for a large number of Fedora users is just *way* too much to ask...sheesh... I'm not asking for someone to spend a year full time on this, it would only take about one day's worth of effort as far as I can see. From mclasen at redhat.com Wed May 21 02:21:08 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 20 May 2008 22:21:08 -0400 Subject: getting rid of vendor prefixes for desktop files In-Reply-To: <1218b5bc0805201904r6f454277ldd71248db956379e@mail.gmail.com> References: <1211303923.8530.10.camel@localhost.localdomain> <48332B79.8070301@gmail.com> <1218b5bc0805201904r6f454277ldd71248db956379e@mail.gmail.com> Message-ID: <1211336468.5819.8.camel@localhost.localdomain> On Tue, 2008-05-20 at 21:04 -0500, Callum Lerwick wrote: > Seems to me the simple answer is to just drop the seemingly useless > notion of vendor_id. :P Yes, vendor id turned out to just be a bad idea. > What is the filename getting used for? Why are we keying on it? > Something smells broken here. Using desktop files as application database/registry is broken in a lot of ways. But for better or worse, this is where we are... From dgboles at gmail.com Wed May 21 02:25:21 2008 From: dgboles at gmail.com (David Boles) Date: Tue, 20 May 2008 22:25:21 -0400 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <20080520174855.49dd2154@vader.jdub.homelinux.org> <20080520202404.53258cb9@vader.jdub.homelinux.org> <1218b5bc0805201846v19edd85n3be4b48e3c519428@mail.gmail.com> <1211335226.3768.1.camel@clockmaker.usersys.redhat.com> <20080520211137.67744ac3@vader.jdub.homelinux.org> Message-ID: <48338811.3090700@gmail.com> Christopher Stone wrote: > On Tue, May 20, 2008 at 7:11 PM, Josh Boyer wrote: >> On Tue, 20 May 2008 19:04:03 -0700 >> "Christopher Stone" wrote: >> >>> On Tue, May 20, 2008 at 7:00 PM, Dave Airlie wrote: >>>>> You can have your pony, I would just like one day to actually be able >>>>> to recommend the OS I use to my neighbors without being embarrassed. >>>>> >>>> Well since you recommend they use binary software, why not just say use >>>> Windows? >>> I always recommend the *best* software. In *most* cases this is open >>> source. In the case of nVidia 3D drivers, it's closed source. In a >>> perfect world everything would be open source, in the real world >>> everything isn't open source. >> In your perfect world, everyone would agree with your approach and this >> entire conversation wouldn't happen. >> >> In the real world, you're asking Fedora to do something to enable >> binary drivers which goes against it's goals. And then you're whining >> about it when we say no. > > Oh yea, to have one developer spend one day to provide a compatibility > route for a large number of Fedora users is just *way* too much to > ask...sheesh... > > I'm not asking for someone to spend a year full time on this, it would > only take about one day's worth of effort as far as I can see. I need this too. So get busy and provide this please. ;-) -- David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From jwboyer at gmail.com Wed May 21 02:30:28 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 20 May 2008 21:30:28 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <20080520174855.49dd2154@vader.jdub.homelinux.org> <20080520202404.53258cb9@vader.jdub.homelinux.org> <1218b5bc0805201846v19edd85n3be4b48e3c519428@mail.gmail.com> <1211335226.3768.1.camel@clockmaker.usersys.redhat.com> <20080520211137.67744ac3@vader.jdub.homelinux.org> Message-ID: <20080520213028.57210c11@vader.jdub.homelinux.org> On Tue, 20 May 2008 19:19:08 -0700 "Christopher Stone" wrote: > On Tue, May 20, 2008 at 7:11 PM, Josh Boyer wrote: > > On Tue, 20 May 2008 19:04:03 -0700 > > "Christopher Stone" wrote: > > > >> On Tue, May 20, 2008 at 7:00 PM, Dave Airlie wrote: > >> > > >> >> > >> >> You can have your pony, I would just like one day to actually be able > >> >> to recommend the OS I use to my neighbors without being embarrassed. > >> >> > >> > > >> > Well since you recommend they use binary software, why not just say use > >> > Windows? > >> > >> I always recommend the *best* software. In *most* cases this is open > >> source. In the case of nVidia 3D drivers, it's closed source. In a > >> perfect world everything would be open source, in the real world > >> everything isn't open source. > > > > In your perfect world, everyone would agree with your approach and this > > entire conversation wouldn't happen. > > > > In the real world, you're asking Fedora to do something to enable > > binary drivers which goes against it's goals. And then you're whining > > about it when we say no. > > Oh yea, to have one developer spend one day to provide a compatibility > route for a large number of Fedora users is just *way* too much to > ask...sheesh... > > I'm not asking for someone to spend a year full time on this, it would > only take about one day's worth of effort as far as I can see. You've already spent far more time whining about it to try to get Fedora to do it than it would have taken you to just go do it yourself according to your assertions. So go solve your problem. josh From chris.stone at gmail.com Wed May 21 02:34:09 2008 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 20 May 2008 19:34:09 -0700 Subject: Xorg 1.5 missed the train? In-Reply-To: <48338811.3090700@gmail.com> References: <48334163.4080709@magma.ca> <20080520202404.53258cb9@vader.jdub.homelinux.org> <1218b5bc0805201846v19edd85n3be4b48e3c519428@mail.gmail.com> <1211335226.3768.1.camel@clockmaker.usersys.redhat.com> <20080520211137.67744ac3@vader.jdub.homelinux.org> <48338811.3090700@gmail.com> Message-ID: 2008/5/20 David Boles : > I need this too. So get busy and provide this please. ;-) Sure, as soon as I get Ajax's paycheck I'll do his job for him.... From jwboyer at gmail.com Wed May 21 02:35:23 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 20 May 2008 21:35:23 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <1211319877.8531.40.camel@localhost.localdomain> <604aa7910805201505m7cc84699p953aa880b7419413@mail.gmail.com> <20080520174855.49dd2154@vader.jdub.homelinux.org> <20080520202404.53258cb9@vader.jdub.homelinux.org> <20080520210725.1707cd60@vader.jdub.homelinux.org> Message-ID: <20080520213523.34f6d5db@vader.jdub.homelinux.org> On Tue, 20 May 2008 19:15:26 -0700 "Christopher Stone" wrote: > On Tue, May 20, 2008 at 7:07 PM, Josh Boyer wrote: > > No. The bottom line is that Fedora does not care about, cater to, or > > promote binary drivers. Period. > > Do they care about having a usable fully functional system for a > majority of their users? Your majority claim is still bogus. As for the rest of that question, they care. Which is why the open source drivers are supported as much as possible and development continues to happen. It's unfortunate that nVidia doesn't provide an open source driver. However, as I've repeatedly said Fedora doesn't cater to binary drivers. Even at the cost of some functionality. josh From a.badger at gmail.com Wed May 21 02:34:09 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 20 May 2008 19:34:09 -0700 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <1211319877.8531.40.camel@localhost.localdomain> <604aa7910805201505m7cc84699p953aa880b7419413@mail.gmail.com> <20080520174855.49dd2154@vader.jdub.homelinux.org> <20080520202404.53258cb9@vader.jdub.homelinux.org> Message-ID: <48338A21.1080206@gmail.com> Christopher Stone wrote: > On Tue, May 20, 2008 at 6:24 PM, Josh Boyer wrote: >> On Tue, 20 May 2008 15:54:52 -0700 >> "Christopher Stone" wrote: >>>> If it's that simple, you should be able to do it yourself. The code is >>>> there. Have at it. >>>> >>>> (HINT: It's not simple at all) >>> >>> According to this thread it seems pretty simple actually: >>> >>> http://www.fedoraforum.org/forum/showthread.php?t=188645 >> Sure. Creating them locally is simple. Then all you'd have to do is >> get it past review, get the primary Xorg maintainer to agree, and >> support it for the entire release. Which includes handling all the bug >> reports for it. Which you might get a lot of and won't be able >> to do a damn thing about because of binary drivers. > > I don't give a hoot if the packages are supported or not, I just want > an easy way to get my nVidia card working. All you people do is gripe > and moan about how much work it would be and all this and that. Look, > its just a matter of adding rpms to a repo, make an "unsupported" repo > if you have to. The bottom line is you want to have as many people > testing the OS as possible. > Then please, make your own repo for those people who do not want supported, qa'd, bug-fixed packages. However, in Fedora all of these things fit into the definition of a maintained package. So by that measure I'd say ajax is doing a very, very good job making sure Fedora 9 will have a robust upstream community supporting it for the life of the release whereas sticking the old xorg version into the distro when its known that no one's going to spend time working on it would be plainly irresponsible. >>> If redhat wants to pay me $100k a year, I'll happily make xorg compat >>> rpms in about one day. Thank you very much. >> I believe that shows your fundamental lack of understanding about >> Fedora and open source software on many levels. > > I believe you have no idea what you are talking about. If I > maintained a package which I knew was not going to work with 50% of > the users hardware, and I was being paid to maintain this package, > then I certainly would spend some time to allow those 50% a way to use > their hardware with the rest of the OS. Nothing more to it than that, > it has nothing to do with open source, it has everything to do with > being professional. > Uhm... xorg-x11-drv-vesa? xorg-x11-drv-nv? xorg-x11-drv-nouveau? I think some time has been spent "to allow those 50% a way to use their hardware with the rest of the OS". You're asking for the wrong thing here. You want X to support optional features of your hardware. The means you're proposing to accomplish this is by adding an unmaintained software package into the distro until a proprietary driver is fixed to support it. This doesn't strike me as a good way for Fedora to proceed and you're unlikely to get any traction for making a change there. If you want to talk about adding a properly maintained package to the distro to support a proprietary driver you might have a little more agreement. If you wanted to talk about adding support for the optional features of your hardware to the distro you'd be applauded by all (though you'd probably be told that doing that work upstream where it can benefit all of the Xorg-using community is the proper venue.) -Toshio From chris.stone at gmail.com Wed May 21 02:39:13 2008 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 20 May 2008 19:39:13 -0700 Subject: Xorg 1.5 missed the train? In-Reply-To: <48338A21.1080206@gmail.com> References: <48334163.4080709@magma.ca> <1211319877.8531.40.camel@localhost.localdomain> <604aa7910805201505m7cc84699p953aa880b7419413@mail.gmail.com> <20080520174855.49dd2154@vader.jdub.homelinux.org> <20080520202404.53258cb9@vader.jdub.homelinux.org> <48338A21.1080206@gmail.com> Message-ID: On Tue, May 20, 2008 at 7:34 PM, Toshio Kuratomi wrote: > Christopher Stone wrote: >> >> On Tue, May 20, 2008 at 6:24 PM, Josh Boyer wrote: >>> >>> On Tue, 20 May 2008 15:54:52 -0700 >>> "Christopher Stone" wrote: >>>>> >>>>> If it's that simple, you should be able to do it yourself. The code is >>>>> there. Have at it. >>>>> >>>>> (HINT: It's not simple at all) >>>> >>>> According to this thread it seems pretty simple actually: >>>> >>>> http://www.fedoraforum.org/forum/showthread.php?t=188645 >>> >>> Sure. Creating them locally is simple. Then all you'd have to do is >>> get it past review, get the primary Xorg maintainer to agree, and >>> support it for the entire release. Which includes handling all the bug >>> reports for it. Which you might get a lot of and won't be able >>> to do a damn thing about because of binary drivers. >> >> I don't give a hoot if the packages are supported or not, I just want >> an easy way to get my nVidia card working. All you people do is gripe >> and moan about how much work it would be and all this and that. Look, >> its just a matter of adding rpms to a repo, make an "unsupported" repo >> if you have to. The bottom line is you want to have as many people >> testing the OS as possible. >> > Then please, make your own repo for those people who do not want supported, > qa'd, bug-fixed packages. However, in Fedora all of these things fit into > the definition of a maintained package. So by that measure I'd say ajax is > doing a very, very good job making sure Fedora 9 will have a robust upstream > community supporting it for the life of the release whereas sticking the old > xorg version into the distro when its known that no one's going to spend > time working on it would be plainly irresponsible. > >>>> If redhat wants to pay me $100k a year, I'll happily make xorg compat >>>> rpms in about one day. Thank you very much. >>> >>> I believe that shows your fundamental lack of understanding about >>> Fedora and open source software on many levels. >> >> I believe you have no idea what you are talking about. If I >> maintained a package which I knew was not going to work with 50% of >> the users hardware, and I was being paid to maintain this package, >> then I certainly would spend some time to allow those 50% a way to use >> their hardware with the rest of the OS. Nothing more to it than that, >> it has nothing to do with open source, it has everything to do with >> being professional. >> > Uhm... xorg-x11-drv-vesa? xorg-x11-drv-nv? xorg-x11-drv-nouveau? I think > some time has been spent "to allow those 50% a way to use their hardware > with the rest of the OS". > > You're asking for the wrong thing here. You want X to support optional > features of your hardware. The means you're proposing to accomplish this is > by adding an unmaintained software package into the distro until a > proprietary driver is fixed to support it. This doesn't strike me as a good > way for Fedora to proceed and you're unlikely to get any traction for > making a change there. Why can't they just be added to updates-testing and left there? Packages in this repo are not supported in the same sense as the ones in updates. From dgboles at gmail.com Wed May 21 02:39:49 2008 From: dgboles at gmail.com (David Boles) Date: Tue, 20 May 2008 22:39:49 -0400 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <20080520202404.53258cb9@vader.jdub.homelinux.org> <1218b5bc0805201846v19edd85n3be4b48e3c519428@mail.gmail.com> <1211335226.3768.1.camel@clockmaker.usersys.redhat.com> <20080520211137.67744ac3@vader.jdub.homelinux.org> <48338811.3090700@gmail.com> Message-ID: <48338B75.7020901@gmail.com> Christopher Stone wrote: > 2008/5/20 David Boles : >> I need this too. So get busy and provide this please. ;-) > > Sure, as soon as I get Ajax's paycheck I'll do his job for him.... As near as I can tell this is not his job. -- David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From jspaleta at gmail.com Wed May 21 02:42:03 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 20 May 2008 18:42:03 -0800 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <1211319877.8531.40.camel@localhost.localdomain> <604aa7910805201505m7cc84699p953aa880b7419413@mail.gmail.com> <20080520174855.49dd2154@vader.jdub.homelinux.org> <20080520202404.53258cb9@vader.jdub.homelinux.org> Message-ID: <604aa7910805201942y18371289yef381f5b07294a59@mail.gmail.com> On Tue, May 20, 2008 at 5:38 PM, Christopher Stone wrote: > I don't give a hoot if the packages are supported or not, I just want > an easy way to get my nVidia card working. All you people do is gripe > and moan about how much work it would be and all this and that. Look, > its just a matter of adding rpms to a repo, make an "unsupported" repo > if you have to. The bottom line is you want to have as many people > testing the OS as possible. There's nothing stopping you or anyone else from creating an unsupported repository containing packages which are not signed by the fedora gpg key... if you have the resources to host it...then just do it. In fact we've seen developers generate unsupported repositories in the past...there was a repo for open wireless development kernels for a time that were not supported that was very useful and yet very unsupported by the Fedora project itself in any way whatsoever. This is going to be my last post in response to you. I think your comments concerning ajax in this post have crossed a line which should not have been crossed and I believe that continuing to have a dialog with you about anything at all...is only going to reinforce the idea that your choices in how your shown displease with the situation is something condonable. Let me be clear, I think your choices to personally attack ajax are reprehensible and quite distasteful to read. There's absolutely no reason to attack ajax personally as you have done. If you want to continue to be upset over the technical issues..fine be upset...but keep it impersonal. Hint, bringing up someones parenting skills...is personal. Even as a joke, its really not proper to do in what is clearly a heated exchange. It certainly doesn't help keep emotions low. I would humbly suggest you take a moment and reread the full extent of what your have written so far and reflect as to whether this is the best way to persuade someone to do what you want, and how you'd personally react to this sort of attempt to at a character assassination if aimed in your direction. I would also encourage others who are reading this thread to refrain from responding to you, until you've made a sincere retraction and an apology. -jef"Knows from experience, that its just too easy to cross the line in a heated exchange without intending to, and it's really important to be able to take a step back. I could probably write a memior's worth of prose just recounting when I crossed the line and had to swallow some pride and make amends."spaleta From jwboyer at gmail.com Wed May 21 02:43:12 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 20 May 2008 21:43:12 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <20080520202404.53258cb9@vader.jdub.homelinux.org> <1218b5bc0805201846v19edd85n3be4b48e3c519428@mail.gmail.com> <1211335226.3768.1.camel@clockmaker.usersys.redhat.com> <20080520211137.67744ac3@vader.jdub.homelinux.org> <48338811.3090700@gmail.com> Message-ID: <20080520214312.24b06e12@vader.jdub.homelinux.org> On Tue, 20 May 2008 19:34:09 -0700 "Christopher Stone" wrote: > 2008/5/20 David Boles : > > I need this too. So get busy and provide this please. ;-) > > Sure, as soon as I get Ajax's paycheck I'll do his job for him.... I'm pretty sure ajax's job description doesn't include: "Provide solutions regardless of Fedora goals and guidelines. Jump when Chris Stone says so." You never answered my "What if Xorg was maintained by a community volunteer" question. And if everyone that worked on open source software required a paycheck from someone explicitly for that, then it either wouldn't exist at all or it would be in a much sadder state of affairs. If you want to pay someone to do this work for you, feel free. It's not ajax's job. josh From jwboyer at gmail.com Wed May 21 02:43:08 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 20 May 2008 21:43:08 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <1211319877.8531.40.camel@localhost.localdomain> <604aa7910805201505m7cc84699p953aa880b7419413@mail.gmail.com> <20080520174855.49dd2154@vader.jdub.homelinux.org> <20080520202404.53258cb9@vader.jdub.homelinux.org> <48338A21.1080206@gmail.com> Message-ID: <20080520214308.7b4ad7b2@vader.jdub.homelinux.org> On Tue, 20 May 2008 19:39:13 -0700 "Christopher Stone" wrote: > > You're asking for the wrong thing here. You want X to support optional > > features of your hardware. The means you're proposing to accomplish this is > > by adding an unmaintained software package into the distro until a > > proprietary driver is fixed to support it. This doesn't strike me as a good > > way for Fedora to proceed and you're unlikely to get any traction for > > making a change there. > > Why can't they just be added to updates-testing and left there? > Packages in this repo are not supported in the same sense as the ones > in updates. Says who? The entire purpose of updates-testing is to get _testing_ on updates that will move to stable. If things are broken there, maintainers go and fix it and resubmit fixed packages. When it's in good shape, it gets pushed up to a stable release. Go make your own repo. josh From cmadams at hiwaay.net Wed May 21 02:45:35 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 20 May 2008 21:45:35 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <20080520213057.GL16499@redhat.com> <1211319877.8531.40.camel@localhost.localdomain> <604aa7910805201505m7cc84699p953aa880b7419413@mail.gmail.com> <20080520174855.49dd2154@vader.jdub.homelinux.org> <20080520202404.53258cb9@vader.jdub.homelinux.org> Message-ID: <20080521024535.GB1307484@hiwaay.net> Once upon a time, Christopher Stone said: > I don't give a hoot if the packages are supported or not, I just want > an easy way to get my nVidia card working. You already have several choices: - continue to use F8 (which will continue to receive updates for about another 6 months) until nVidia gets their act together - use F9 and the Open Source nVidia drivers - file away what has happened time and again with nVidia's binary drivers and remember it next time you buy new hardware > And obviously ajax does not care about 50% of Fedora's user base. And extreme exageration lends so much to your arguments. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From a.badger at gmail.com Wed May 21 02:48:25 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 20 May 2008 19:48:25 -0700 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <20080520202404.53258cb9@vader.jdub.homelinux.org> <1218b5bc0805201846v19edd85n3be4b48e3c519428@mail.gmail.com> <1211335226.3768.1.camel@clockmaker.usersys.redhat.com> <20080520211137.67744ac3@vader.jdub.homelinux.org> <48338811.3090700@gmail.com> Message-ID: <48338D79.9020304@gmail.com> Christopher Stone wrote: > 2008/5/20 David Boles : >> I need this too. So get busy and provide this please. ;-) > > Sure, as soon as I get Ajax's paycheck I'll do his job for him.... > That's very seldom how open source works. If you do a job well you get recognized, hired, and paid. If you spend your time whining about why other people aren't doing things the way you'd do them usually doesn't get you anything. And of course, that doesn't even begin to deal with the fact that packaging old releases of xorg for Fedora *isn't* what ajax gets paid for. -Toshio From chris.stone at gmail.com Wed May 21 02:54:42 2008 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 20 May 2008 19:54:42 -0700 Subject: Xorg 1.5 missed the train? In-Reply-To: <48338D79.9020304@gmail.com> References: <48334163.4080709@magma.ca> <1218b5bc0805201846v19edd85n3be4b48e3c519428@mail.gmail.com> <1211335226.3768.1.camel@clockmaker.usersys.redhat.com> <20080520211137.67744ac3@vader.jdub.homelinux.org> <48338811.3090700@gmail.com> <48338D79.9020304@gmail.com> Message-ID: On Tue, May 20, 2008 at 7:48 PM, Toshio Kuratomi wrote: > Christopher Stone wrote: >> >> 2008/5/20 David Boles : >>> >>> I need this too. So get busy and provide this please. ;-) >> >> Sure, as soon as I get Ajax's paycheck I'll do his job for him.... >> > That's very seldom how open source works. If you do a job well you get > recognized, hired, and paid. If you spend your time whining about why other > people aren't doing things the way you'd do them usually doesn't get you > anything. > > And of course, that doesn't even begin to deal with the fact that packaging > old releases of xorg for Fedora *isn't* what ajax gets paid for. Yes, I know. I was being snide when I said this. I apologize. But isn't packaging part of his responsibilities? It just seems to me that an upgrade path for nVidia users could be provided without much extra effort. From lesmikesell at gmail.com Wed May 21 02:55:21 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 20 May 2008 21:55:21 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <1211319877.8531.40.camel@localhost.localdomain> <604aa7910805201505m7cc84699p953aa880b7419413@mail.gmail.com> <20080520174855.49dd2154@vader.jdub.homelinux.org> <20080520202404.53258cb9@vader.jdub.homelinux.org> <20080520210725.1707cd60@vader.jdub.homelinux.org> Message-ID: <48338F19.1020104@gmail.com> Christopher Stone wrote: > On Tue, May 20, 2008 at 7:07 PM, Josh Boyer wrote: >> No. The bottom line is that Fedora does not care about, cater to, or >> promote binary drivers. Period. > > Do they care about having a usable fully functional system for a > majority of their users? > > >> You pulled that number out of your ass. And it's wrong. You have no >> data to back that up, and what data does exist on smolts.org shows ATI >> has a lead. > > I *have* looked at the smolt stats, and they don't make any sense at > all. 1.6% and 1.9%, that doesn't make any sense, the smolt stats have > to be wrong. I'm sure the total number of nVidia and ATI fedora > desktop users is more than 4%. Yes, that page is extremely strange if you are looking at the classes/video. ATI and Nvidia are actually 83%+ of the identified adapter vendors although shown as 1.9/1.6 respectively, but by devices vmware and virtualbox virtual adapters come out on top. -- Les Mikesell lesmikesell at gmail.com From chris.stone at gmail.com Wed May 21 02:55:55 2008 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 20 May 2008 19:55:55 -0700 Subject: Xorg 1.5 missed the train? In-Reply-To: <604aa7910805201942y18371289yef381f5b07294a59@mail.gmail.com> References: <48334163.4080709@magma.ca> <1211319877.8531.40.camel@localhost.localdomain> <604aa7910805201505m7cc84699p953aa880b7419413@mail.gmail.com> <20080520174855.49dd2154@vader.jdub.homelinux.org> <20080520202404.53258cb9@vader.jdub.homelinux.org> <604aa7910805201942y18371289yef381f5b07294a59@mail.gmail.com> Message-ID: um let me be clear, the comment about Ajax raising his kids was not meant as a personal attack. I'm sure he is a fine parent. On Tue, May 20, 2008 at 7:42 PM, Jeff Spaleta wrote: > On Tue, May 20, 2008 at 5:38 PM, Christopher Stone > wrote: >> I don't give a hoot if the packages are supported or not, I just want >> an easy way to get my nVidia card working. All you people do is gripe >> and moan about how much work it would be and all this and that. Look, >> its just a matter of adding rpms to a repo, make an "unsupported" repo >> if you have to. The bottom line is you want to have as many people >> testing the OS as possible. > > There's nothing stopping you or anyone else from creating an > unsupported repository containing packages which are not signed by the > fedora gpg key... if you have the resources to host it...then just do > it. In fact we've seen developers generate unsupported repositories in > the past...there was a repo for open wireless development kernels for > a time that were not supported that was very useful and yet very > unsupported by the Fedora project itself in any way whatsoever. > > This is going to be my last post in response to you. I think your > comments concerning ajax in this post have crossed a line which should > not have been crossed and I believe that continuing to have a dialog > with you about anything at all...is only going to reinforce the idea > that your choices in how your shown displease with the situation is > something condonable. > Let me be clear, I think your choices to personally attack ajax are > reprehensible and quite distasteful to read. There's absolutely no > reason to attack ajax personally as you have done. If you want to > continue to be upset over the technical issues..fine be upset...but > keep it impersonal. Hint, bringing up someones parenting skills...is > personal. Even as a joke, its really not proper to do in what is > clearly a heated exchange. It certainly doesn't help keep emotions > low. > > I would humbly suggest you take a moment and reread the full extent of > what your have written so far and reflect as to whether this is the > best way to persuade someone to do what you want, and how you'd > personally react to this sort of attempt to at a character > assassination if aimed in your direction. > > I would also encourage others who are reading this thread to refrain > from responding to you, until you've made a sincere retraction and an > apology. > > -jef"Knows from experience, that its just too easy to cross the line > in a heated exchange without intending to, and it's really important > to be able to take a step back. I could probably write a memior's > worth of prose just recounting when I crossed the line and had to > swallow some pride and make amends."spaleta > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From jwboyer at gmail.com Wed May 21 03:02:10 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 20 May 2008 22:02:10 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <1218b5bc0805201846v19edd85n3be4b48e3c519428@mail.gmail.com> <1211335226.3768.1.camel@clockmaker.usersys.redhat.com> <20080520211137.67744ac3@vader.jdub.homelinux.org> <48338811.3090700@gmail.com> <48338D79.9020304@gmail.com> Message-ID: <20080520220210.77f97a82@vader.jdub.homelinux.org> On Tue, 20 May 2008 19:54:42 -0700 "Christopher Stone" wrote: > On Tue, May 20, 2008 at 7:48 PM, Toshio Kuratomi wrote: > > Christopher Stone wrote: > >> > >> 2008/5/20 David Boles : > >>> > >>> I need this too. So get busy and provide this please. ;-) > >> > >> Sure, as soon as I get Ajax's paycheck I'll do his job for him.... > >> > > That's very seldom how open source works. If you do a job well you get > > recognized, hired, and paid. If you spend your time whining about why other > > people aren't doing things the way you'd do them usually doesn't get you > > anything. > > > > And of course, that doesn't even begin to deal with the fact that packaging > > old releases of xorg for Fedora *isn't* what ajax gets paid for. > > Yes, I know. I was being snide when I said this. I apologize. > > But isn't packaging part of his responsibilities? It just seems to me Yes. And he has done it with extreme proficiency. What you are asking is not in the realm of simple "packaging" duties. > that an upgrade path for nVidia users could be provided without much > extra effort. The nVidia thing comes up every release. Eventually I'm sure nVidia will update their driver and then the upgrade path for users choosing to use that driver will be an option. Waiting a few more weeks for that to happen is not the end of the world. josh From katzj at redhat.com Wed May 21 03:25:27 2008 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 20 May 2008 23:25:27 -0400 Subject: Xorg 1.5 missed the train? In-Reply-To: <20080520220210.77f97a82@vader.jdub.homelinux.org> References: <48334163.4080709@magma.ca> <1218b5bc0805201846v19edd85n3be4b48e3c519428@mail.gmail.com> <1211335226.3768.1.camel@clockmaker.usersys.redhat.com> <20080520211137.67744ac3@vader.jdub.homelinux.org> <48338811.3090700@gmail.com> <48338D79.9020304@gmail.com> <20080520220210.77f97a82@vader.jdub.homelinux.org> Message-ID: <1211340327.12052.56.camel@aglarond.local> On Tue, 2008-05-20 at 22:02 -0500, Josh Boyer wrote: > > that an upgrade path for nVidia users could be provided without much > > extra effort. > > The nVidia thing comes up every release. Eventually I'm sure nVidia > will update their driver and then the upgrade path for users > choosing to use that driver will be an option. Waiting a few more weeks > for that to happen is not the end of the world. ... and if people would spend as much time helping out with nouveau[1] as they've spent complaining on this thread, we'd be that much closer to a real, sustainable solution to fully supporting nVidia's hardware as opposed to having this discussion every release. Seriously. The nouveau guys are making *real* progress. Even just trying out nouveau and providing feedback is helpful to them. Also, they have a list of things which need testing[2] as well as a list of cards which they could use some dump information from[3]. Jeremy [1] http://nouveau.freedesktop.org [2] http://nouveau.freedesktop.org/wiki/TestersWanted [3] http://people.freedesktop.org/~jpakkane/ren/ From ezigler at gmail.com Wed May 21 03:30:20 2008 From: ezigler at gmail.com (Erich Zigler) Date: Tue, 20 May 2008 22:30:20 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: <20080520220210.77f97a82@vader.jdub.homelinux.org> References: <48334163.4080709@magma.ca> <1211335226.3768.1.camel@clockmaker.usersys.redhat.com> <20080520211137.67744ac3@vader.jdub.homelinux.org> <48338811.3090700@gmail.com> <48338D79.9020304@gmail.com> <20080520220210.77f97a82@vader.jdub.homelinux.org> Message-ID: I have been reading this thread all evening and quite frankly it makes me sick to my stomach. I consider Fedora developers and users to be the cream of the crop of the Linux community. Unfortunately this thread has not shown that to be the case. I am horrified for any one who happens upon this thread via the mailing list archive as an example of what the Fedora community is about. I would like to make the following points in regard to this issue. 1. As a Fedora user who uses Fedora as a desktop machine and requires the bits that the proprietary binary Nvidia driver provides I am not a second class user. Individuals who have the ability to run OSS video drivers are not any better or worse then I am they just have different needs and requirements. 2. Demanding that a Red Hat employee who may or may not be paid to work on Fedora is not doing his job is distasteful. I have been involved in quite a few OSS projects over the years and OSS is about freedom. The freedom to work on what you find interesting or feel there is a need for. If an individual is not happy with how things are going the individual is free to make the changes they feel are important or help facilitate that change. OSS development is largely powered by volunteers. 3. The root issue is that Fedora shipped a prerelease version of Xorg that many are unhappy with. They are mainly unhappy with this fact because it shortens the time they can use Fedora 9 due to their hardware issues. This decision affected a portion of the user base. I hope that the thought and consideration went in to such a decision as this kind of Fedora backlash was expected. As geeks we always want the latest and greatest and Fedora 9 symbolizes that. This again does not make them second class users. 4. Not everyone is as up to date on what is and is not supported as we are. We must remember the little guy. The user who is just starting out with Linux or is still a novice. The user who runs the upgrade and expects everything to work as it did in Fedora 8. Fedora is a great distribution but we all know how FUD can overtake a great thing. 5. Expecting Fedora to cater to proprietary video card drivers is unrealistic. However it is not unrealistic to keep the user in mind when making such design decisions. More individuals were positively affected by the decision to include a prerelease version of Xorg then not. In the future I would recommend getting out in front of issues such as this as to prepare the user base. A subpoint under the Xorg portion of the Release Notes stating that version xx.yy of Nvidia drivers and version xx.yy of ATI drivers would not work with Fedora 9 I feel would have helped tremendously. Personally, this issue has made me want to get more involved in Fedora development. This is OSS and it is what we make of it. Thanks for reading, Erich From airlied at redhat.com Wed May 21 03:35:16 2008 From: airlied at redhat.com (Dave Airlie) Date: Wed, 21 May 2008 13:35:16 +1000 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <1211335226.3768.1.camel@clockmaker.usersys.redhat.com> <20080520211137.67744ac3@vader.jdub.homelinux.org> <48338811.3090700@gmail.com> <48338D79.9020304@gmail.com> <20080520220210.77f97a82@vader.jdub.homelinux.org> Message-ID: <1211340916.3307.2.camel@clockmaker.usersys.redhat.com> On Tue, 2008-05-20 at 22:30 -0500, Erich Zigler wrote: > I have been reading this thread all evening and quite frankly it makes > me sick to my stomach. I consider Fedora developers and users to be > the cream of the crop of the Linux community. Unfortunately this > thread has not shown that to be the case. I am horrified for any one > who happens upon this thread via the mailing list archive as an > example of what the Fedora community is about. I would like to make > the following points in regard to this issue. > > 1. As a Fedora user who uses Fedora as a desktop machine and requires > the bits that the proprietary binary Nvidia driver provides I am not a > second class user. Individuals who have the ability to run OSS video > drivers are not any better or worse then I am they just have different > needs and requirements. > > 2. Demanding that a Red Hat employee who may or may not be paid to > work on Fedora is not doing his job is distasteful. I have been > involved in quite a few OSS projects over the years and OSS is about > freedom. The freedom to work on what you find interesting or feel > there is a need for. If an individual is not happy with how things are > going the individual is free to make the changes they feel are > important or help facilitate that change. OSS development is largely > powered by volunteers. > > 3. The root issue is that Fedora shipped a prerelease version of Xorg > that many are unhappy with. They are mainly unhappy with this fact > because it shortens the time they can use Fedora 9 due to their > hardware issues. This decision affected a portion of the user base. I > hope that the thought and consideration went in to such a decision as > this kind of Fedora backlash was expected. As geeks we always want the > latest and greatest and Fedora 9 symbolizes that. This again does not > make them second class users. > > 4. Not everyone is as up to date on what is and is not supported as we > are. We must remember the little guy. The user who is just starting > out with Linux or is still a novice. The user who runs the upgrade and > expects everything to work as it did in Fedora 8. Fedora is a great > distribution but we all know how FUD can overtake a great thing. > > 5. Expecting Fedora to cater to proprietary video card drivers is > unrealistic. However it is not unrealistic to keep the user in mind > when making such design decisions. More individuals were positively > affected by the decision to include a prerelease version of Xorg then > not. In the future I would recommend getting out in front of issues > such as this as to prepare the user base. A subpoint under the Xorg > portion of the Release Notes stating that version xx.yy of Nvidia > drivers and version xx.yy of ATI drivers would not work with Fedora 9 > I feel would have helped tremendously. Can't people read or something? I just posted why 3 and 5 aren't in any way true. Let me repeat via cut-n-paste: 1. X.org ABI for 1.5 is what we ship in F9, this hasn't changed in months, I've ported 15 other drivers to it in this time. It will not change before 1.5 final is released. 2. Nvidia don't release drivers for X.org releases. 3. Nvidia only bother releasing drivers when a distro has shipped the ABI. Now we happen to be the first distro to ship most things, so we get to be distro that nvidia have to port their drivers to. Other distros lag releasing, however it won't help us if we lag, as Nvidia won't do anything until one of Fedora, Ubuntu, OpenSUSE, RHEL, or SLED do a release. I was as much responsible for shipping 1.5 pre-release in Fedora as ajax was, and funnily these threads actually move me to break the nvidia driver more often rather than less :-) Dave. From jwboyer at gmail.com Wed May 21 03:35:30 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 20 May 2008 22:35:30 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <1211335226.3768.1.camel@clockmaker.usersys.redhat.com> <20080520211137.67744ac3@vader.jdub.homelinux.org> <48338811.3090700@gmail.com> <48338D79.9020304@gmail.com> <20080520220210.77f97a82@vader.jdub.homelinux.org> Message-ID: <20080520223530.6b9a15b4@vader.jdub.homelinux.org> On Tue, 20 May 2008 22:30:20 -0500 "Erich Zigler" wrote: > Personally, this issue has made me want to get more involved in Fedora > development. This is OSS and it is what we make of it. Excellent. Then it hasn't been a waste. We look forward to your contributions. josh From chris.stone at gmail.com Wed May 21 03:48:59 2008 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 20 May 2008 20:48:59 -0700 Subject: Xorg 1.5 missed the train? In-Reply-To: <1211340916.3307.2.camel@clockmaker.usersys.redhat.com> References: <48334163.4080709@magma.ca> <20080520211137.67744ac3@vader.jdub.homelinux.org> <48338811.3090700@gmail.com> <48338D79.9020304@gmail.com> <20080520220210.77f97a82@vader.jdub.homelinux.org> <1211340916.3307.2.camel@clockmaker.usersys.redhat.com> Message-ID: On Tue, May 20, 2008 at 8:35 PM, Dave Airlie wrote: > I was as much responsible for shipping 1.5 pre-release in Fedora as ajax > was, and funnily these threads actually move me to break the nvidia > driver more often rather than less :-) I think you are missing the point. Just because nVidia sucks, it doesn't mean we have to make Fedora "suck". This is linux, and it should be possible to have a system which everyone can enjoy. With just a little bit of extra effort, a set of stable xorg rpms could have been provided in a f9 testing repo for nVidia users to use temporarily. We can still make a distro which is friendly to nVidia users without slowing down progress for everyone else. I see this mainly as a user friendliness issue more than an open source vs closed source issue. I hope Josh is correct and we will have some nVidia drivers to test with soon. From ezigler at gmail.com Wed May 21 03:50:13 2008 From: ezigler at gmail.com (Erich Zigler) Date: Tue, 20 May 2008 22:50:13 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: <1211340916.3307.2.camel@clockmaker.usersys.redhat.com> References: <48334163.4080709@magma.ca> <20080520211137.67744ac3@vader.jdub.homelinux.org> <48338811.3090700@gmail.com> <48338D79.9020304@gmail.com> <20080520220210.77f97a82@vader.jdub.homelinux.org> <1211340916.3307.2.camel@clockmaker.usersys.redhat.com> Message-ID: On Tue, May 20, 2008 at 10:35 PM, Dave Airlie wrote: > Can't people read or something? I wasn't rude to you. Why must you be rude to me? > 1. X.org ABI for 1.5 is what we ship in F9, this hasn't changed in > months, I've ported 15 other drivers to it in this time. It will not > change before 1.5 final is released. > 2. Nvidia don't release drivers for X.org releases. > 3. Nvidia only bother releasing drivers when a distro has shipped the > ABI. Now we happen to be the first distro to ship most things, so we get > to be distro that nvidia have to port their drivers to. Other distros > lag releasing, however it won't help us if we lag, as Nvidia won't do > anything until one of Fedora, Ubuntu, OpenSUSE, RHEL, or SLED do a > release. > I was as much responsible for shipping 1.5 pre-release in Fedora as ajax > was, and funnily these threads actually move me to break the nvidia > driver more often rather than less :-) You know a lot more about this stuff then I do but I don't see any thing you posted there to make #3 and #5 any less true. The point I was trying to make in #3 and #5 was consideration for the user in such decisions and noting such things as this in the Release Notes. Thanks, Erich From airlied at redhat.com Wed May 21 04:04:25 2008 From: airlied at redhat.com (Dave Airlie) Date: Wed, 21 May 2008 14:04:25 +1000 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <20080520211137.67744ac3@vader.jdub.homelinux.org> <48338811.3090700@gmail.com> <48338D79.9020304@gmail.com> <20080520220210.77f97a82@vader.jdub.homelinux.org> <1211340916.3307.2.camel@clockmaker.usersys.redhat.com> Message-ID: <1211342665.3682.2.camel@clockmaker.usersys.redhat.com> On Tue, 2008-05-20 at 22:50 -0500, Erich Zigler wrote: > On Tue, May 20, 2008 at 10:35 PM, Dave Airlie wrote: > > > Can't people read or something? > > I wasn't rude to you. Why must you be rude to me? because this thread is going on far too long and people need to get over it :), but I do apologise for that, I'm mainly replying on autopilot while trying to do actual useful work for users. > > > 1. X.org ABI for 1.5 is what we ship in F9, this hasn't changed in > > months, I've ported 15 other drivers to it in this time. It will not > > change before 1.5 final is released. > > 2. Nvidia don't release drivers for X.org releases. > > 3. Nvidia only bother releasing drivers when a distro has shipped the > > ABI. Now we happen to be the first distro to ship most things, so we get > > to be distro that nvidia have to port their drivers to. Other distros > > lag releasing, however it won't help us if we lag, as Nvidia won't do > > anything until one of Fedora, Ubuntu, OpenSUSE, RHEL, or SLED do a > > release. > > I was as much responsible for shipping 1.5 pre-release in Fedora as ajax > > was, and funnily these threads actually move me to break the nvidia > > driver more often rather than less :-) > > You know a lot more about this stuff then I do but I don't see any > thing you posted there to make #3 and #5 any less true. The point I > was trying to make in #3 and #5 was consideration for the user in such > decisions and noting such things as this in the Release Notes. Point 5 is okay, but you're point 3 said "The root issue is that Fedora shipped a prerelease version of Xorg that many are unhappy with.". I was merely pointing out that this wasn't the root issue, and that I had pointed it out before in this thread as had other people. so again, if Xorg had released 1.5 before F9 shipped it wouldn't have mattered to the current situation. See point 2 above, and then read point 3. Dave. From jspaleta at gmail.com Wed May 21 04:05:16 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 20 May 2008 20:05:16 -0800 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <48338811.3090700@gmail.com> <48338D79.9020304@gmail.com> <20080520220210.77f97a82@vader.jdub.homelinux.org> <1211340916.3307.2.camel@clockmaker.usersys.redhat.com> Message-ID: <604aa7910805202105h312ed304r5a9859e9eb1c483b@mail.gmail.com> On Tue, May 20, 2008 at 7:50 PM, Erich Zigler wrote: > You know a lot more about this stuff then I do but I don't see any > thing you posted there to make #3 and #5 any less true. The point I > was trying to make in #3 and #5 was consideration for the user in such > decisions and noting such things as this in the Release Notes. Here let me show you something... pointing out that NVidia lagged the X.org 7.3 release and its stable ABI. Fact 1: X.org 7.3 was released on 09-06-07 Reference: http://www.x.org/wiki/Releases/7.3 Fact 2: NVidia did not have a new driver ready as of X.org 7.3 release: Reference: http://www.nvnews.net/vbulletin/showthread.php?t=97942 Quote Nvidia developer on :09-06-07 "To reiterate, we can't comment on driver release schedules but I can confirm that the next driver release will support X.org 7.3. In the meantime, using -ignoreABI should be safe as long as you disable the Composite extension." Fact 3: Nvidia does not time releases around X.org releases: Reference: http://www.nvnews.net/vbulletin/showthread.php?t=98635 Quote NVidia developer on :09-06-07 "the next driver release is not pending the Xorg-7.3 release." -jef From ezigler at gmail.com Wed May 21 04:10:41 2008 From: ezigler at gmail.com (Erich Zigler) Date: Tue, 20 May 2008 23:10:41 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: <604aa7910805202105h312ed304r5a9859e9eb1c483b@mail.gmail.com> References: <48334163.4080709@magma.ca> <48338811.3090700@gmail.com> <48338D79.9020304@gmail.com> <20080520220210.77f97a82@vader.jdub.homelinux.org> <1211340916.3307.2.camel@clockmaker.usersys.redhat.com> <604aa7910805202105h312ed304r5a9859e9eb1c483b@mail.gmail.com> Message-ID: On Tue, May 20, 2008 at 11:05 PM, Jeff Spaleta wrote: > Here let me show you something... pointing out that NVidia lagged the > X.org 7.3 release and its stable ABI. > Fact 1: X.org 7.3 was released on 09-06-07 > Reference: http://www.x.org/wiki/Releases/7.3 > Fact 2: NVidia did not have a new driver ready as of X.org 7.3 release: > Reference: http://www.nvnews.net/vbulletin/showthread.php?t=97942 > Quote Nvidia developer on :09-06-07 > "To reiterate, we can't comment on driver release schedules but I can > confirm that the next driver release will support X.org 7.3. In the > meantime, using -ignoreABI should be safe as long as you disable the > Composite extension." > Fact 3: Nvidia does not time releases around X.org releases: > Reference: http://www.nvnews.net/vbulletin/showthread.php?t=98635 > Quote NVidia developer on :09-06-07 > "the next driver release is not pending the Xorg-7.3 release." Thank you. Clue gained. :) - Erich From rodd at clarkson.id.au Wed May 21 04:10:53 2008 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Wed, 21 May 2008 14:10:53 +1000 Subject: Xorg 1.5 missed the train? In-Reply-To: <20080520220210.77f97a82@vader.jdub.homelinux.org> References: <48334163.4080709@magma.ca> <1218b5bc0805201846v19edd85n3be4b48e3c519428@mail.gmail.com> <1211335226.3768.1.camel@clockmaker.usersys.redhat.com> <20080520211137.67744ac3@vader.jdub.homelinux.org> <48338811.3090700@gmail.com> <48338D79.9020304@gmail.com> <20080520220210.77f97a82@vader.jdub.homelinux.org> Message-ID: <1211343053.14575.27.camel@localhost.localdomain> On Tue, 2008-05-20 at 22:02 -0500, Josh Boyer wrote: > On Tue, 20 May 2008 19:54:42 -0700 > "Christopher Stone" wrote: > > that an upgrade path for nVidia users could be provided without much > > extra effort. > > The nVidia thing comes up every release. Eventually I'm sure nVidia > will update their driver and then the upgrade path for users > choosing to use that driver will be an option. Waiting a few more weeks > for that to happen is not the end of the world. Go nag nvidia about this, not fedora. nvidia sprout corporate nonsense about not supporting pre-release software and stating that they can't (won't) develop the driver without a stable ABI. This begs two questions. Firstly, how do you define release. For example on Windows, is release the day that that version of Windows is released? It appears not. So to use this same set of values for Linux (or Fedora) seems nonsense. Maybe release is when the ABI's are declared stable. This brings me to the second point. The devel cycle for Fedora has a point in the roadmap where the developers have to declare the ABI's stable so that developers can rely on them for the next release. This should have been more than enough for nvidia. The simple fact is that it's not ajax's fault that nvidia don't take Linux users seriously. And while it might be frustrating, you can do two things. 1. Put up with these issues with nvidia support and accept where the real blame lies. 2. Stop buying nvidia products until such time as they take Linux support seriously. As a laptop owner with a nvidia graphics driver, I won't be getting another nvidia graphics card in any new machine from now on, until I see an improvement in their approach to Linux. Just remember, ajax has supplied support for all the drivers he can (every open source driver), but he can't be expected to support closed source drivers (that's nvidia's responsibility). R. -- "It's a fine line between denial and faith. It's much better on my side" From airlied at redhat.com Wed May 21 04:13:11 2008 From: airlied at redhat.com (Dave Airlie) Date: Wed, 21 May 2008 14:13:11 +1000 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <20080520211137.67744ac3@vader.jdub.homelinux.org> <48338811.3090700@gmail.com> <48338D79.9020304@gmail.com> <20080520220210.77f97a82@vader.jdub.homelinux.org> <1211340916.3307.2.camel@clockmaker.usersys.redhat.com> Message-ID: <1211343191.3682.9.camel@clockmaker.usersys.redhat.com> On Tue, 2008-05-20 at 20:48 -0700, Christopher Stone wrote: > On Tue, May 20, 2008 at 8:35 PM, Dave Airlie wrote: > > I was as much responsible for shipping 1.5 pre-release in Fedora as ajax > > was, and funnily these threads actually move me to break the nvidia > > driver more often rather than less :-) > > I think you are missing the point. Just because nVidia sucks, it > doesn't mean we have to make Fedora "suck". This is linux, and it > should be possible to have a system which everyone can enjoy. With > just a little bit of extra effort, a set of stable xorg rpms could > have been provided in a f9 testing repo for nVidia users to use > temporarily. We can still make a distro which is friendly to nVidia > users without slowing down progress for everyone else. I see this > mainly as a user friendliness issue more than an open source vs closed > source issue. I hope Josh is correct and we will have some nVidia > drivers to test with soon. The thing is there are much more binary drivers than nvidia, if we take the attitude we should support binary driver users, we would end up having an Xorg for nvidia, and Xorg for fglrx, and Xorg for parhelia, and Xorg for 3dlabs, along with a kernel for each. The thing is we can't. If it takes me one or two days to do packages for a driver I'm not even going to download onto my system, that is one or two days I'm not pushing forward the open source graphics system. Both myself and ajax's primary roles in life is to work on Red Hat Enterprise products, we manage to schedule a fair percentage of our time to work on Fedora and upstream projects due to nice managers. If I was to give up one or two days of this time to doing something for binary drivers, it would mean I wouldn't get to spend those two days I've managed to drag myself away from Enterprise stuff on making the open-source drivers work as well as I can in the time allowed. So you want me to spend my time supporting a company that won't help me, just because you gave them money? Dave. From jdieter at gmail.com Wed May 21 04:13:15 2008 From: jdieter at gmail.com (Jonathan Dieter) Date: Wed, 21 May 2008 07:13:15 +0300 Subject: New Xorg Message-ID: <1211343195.2928.25.camel@jdlaptop> I know this probably isn't the place to do this, but I'm not sure what the right place is. ajax & Dave, thank you for the work you've done on the new Xorg. I know there have been lots of complaints, and, as an nVidia user, I understand them. However, the stuff you're working on for *all* the other drivers is pretty incredible and more than makes up for a few weeks without eye-candy on my primary system. The way it all works on Intel video cards is great, and I'm particularly impressed with the DRI2 stuff (though kernel mode-setting is pretty cool too). Please keep it up. Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From chris.stone at gmail.com Wed May 21 04:19:59 2008 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 20 May 2008 21:19:59 -0700 Subject: Xorg 1.5 missed the train? In-Reply-To: <1211343191.3682.9.camel@clockmaker.usersys.redhat.com> References: <48334163.4080709@magma.ca> <48338811.3090700@gmail.com> <48338D79.9020304@gmail.com> <20080520220210.77f97a82@vader.jdub.homelinux.org> <1211340916.3307.2.camel@clockmaker.usersys.redhat.com> <1211343191.3682.9.camel@clockmaker.usersys.redhat.com> Message-ID: On Tue, May 20, 2008 at 9:13 PM, Dave Airlie wrote: > > On Tue, 2008-05-20 at 20:48 -0700, Christopher Stone wrote: >> On Tue, May 20, 2008 at 8:35 PM, Dave Airlie wrote: >> > I was as much responsible for shipping 1.5 pre-release in Fedora as ajax >> > was, and funnily these threads actually move me to break the nvidia >> > driver more often rather than less :-) >> >> I think you are missing the point. Just because nVidia sucks, it >> doesn't mean we have to make Fedora "suck". This is linux, and it >> should be possible to have a system which everyone can enjoy. With >> just a little bit of extra effort, a set of stable xorg rpms could >> have been provided in a f9 testing repo for nVidia users to use >> temporarily. We can still make a distro which is friendly to nVidia >> users without slowing down progress for everyone else. I see this >> mainly as a user friendliness issue more than an open source vs closed >> source issue. I hope Josh is correct and we will have some nVidia >> drivers to test with soon. > > The thing is there are much more binary drivers than nvidia, if we take > the attitude we should support binary driver users, we would end up > having an Xorg for nvidia, and Xorg for fglrx, and Xorg for parhelia, > and Xorg for 3dlabs, along with a kernel for each. The thing is we > can't. > > If it takes me one or two days to do packages for a driver I'm not even > going to download onto my system, that is one or two days I'm not > pushing forward the open source graphics system. Both myself and ajax's > primary roles in life is to work on Red Hat Enterprise products, we > manage to schedule a fair percentage of our time to work on Fedora and > upstream projects due to nice managers. If I was to give up one or two > days of this time to doing something for binary drivers, it would mean I > wouldn't get to spend those two days I've managed to drag myself away > from Enterprise stuff on making the open-source drivers work as well as > I can in the time allowed. So you want me to spend my time supporting a > company that won't help me, just because you gave them money? I don't want you to spend time supporting a company, I want you to spend time supporting the Fedora users who love their OS and would love to be able to use their hardware to its fullest extent. That is all. I really don't expect an xorg build for every binary blob out there, but a stable version of xorg as an alternative for those who are having problems with the beta version should have been given more consideration in my opinion. From mike at cchtml.com Wed May 21 04:23:42 2008 From: mike at cchtml.com (Mike Cronenworth) Date: Tue, 20 May 2008 23:23:42 -0500 Subject: New Xorg In-Reply-To: <1211343195.2928.25.camel@jdlaptop> References: <1211343195.2928.25.camel@jdlaptop> Message-ID: <4833A3CE.4040104@cchtml.com> -------- Original Message -------- Subject: New Xorg From: Jonathan Dieter To: Development discussions related to Fedora Date: 05/20/2008 11:13 PM > I know this probably isn't the place to do this, but I'm not sure what > the right place is. ajax & Dave, thank you for the work you've done on > the new Xorg. I know there have been lots of complaints, and, as an > nVidia user, I understand them. > > However, the stuff you're working on for *all* the other drivers is > pretty incredible and more than makes up for a few weeks without > eye-candy on my primary system. The way it all works on Intel video > cards is great, and I'm particularly impressed with the DRI2 stuff > (though kernel mode-setting is pretty cool too). Please keep it up. > > Jonathan > +1 I have a nVidia card and I'm not butt hurt. The update will come soon enough. Then we'll forget this mess ever went down - until the next Xorg release comes around. From konrad at tylerc.org Wed May 21 04:24:20 2008 From: konrad at tylerc.org (Konrad Meyer) Date: Tue, 20 May 2008 21:24:20 -0700 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <1211343191.3682.9.camel@clockmaker.usersys.redhat.com> Message-ID: <200805202124.20893.konrad@tylerc.org> Quoth Christopher Stone: > On Tue, May 20, 2008 at 9:13 PM, Dave Airlie wrote: > > > > On Tue, 2008-05-20 at 20:48 -0700, Christopher Stone wrote: > >> On Tue, May 20, 2008 at 8:35 PM, Dave Airlie wrote: > >> > I was as much responsible for shipping 1.5 pre-release in Fedora as ajax > >> > was, and funnily these threads actually move me to break the nvidia > >> > driver more often rather than less :-) > >> > >> I think you are missing the point. Just because nVidia sucks, it > >> doesn't mean we have to make Fedora "suck". This is linux, and it > >> should be possible to have a system which everyone can enjoy. With > >> just a little bit of extra effort, a set of stable xorg rpms could > >> have been provided in a f9 testing repo for nVidia users to use > >> temporarily. We can still make a distro which is friendly to nVidia > >> users without slowing down progress for everyone else. I see this > >> mainly as a user friendliness issue more than an open source vs closed > >> source issue. I hope Josh is correct and we will have some nVidia > >> drivers to test with soon. > > > > The thing is there are much more binary drivers than nvidia, if we take > > the attitude we should support binary driver users, we would end up > > having an Xorg for nvidia, and Xorg for fglrx, and Xorg for parhelia, > > and Xorg for 3dlabs, along with a kernel for each. The thing is we > > can't. > > > > If it takes me one or two days to do packages for a driver I'm not even > > going to download onto my system, that is one or two days I'm not > > pushing forward the open source graphics system. Both myself and ajax's > > primary roles in life is to work on Red Hat Enterprise products, we > > manage to schedule a fair percentage of our time to work on Fedora and > > upstream projects due to nice managers. If I was to give up one or two > > days of this time to doing something for binary drivers, it would mean I > > wouldn't get to spend those two days I've managed to drag myself away > > from Enterprise stuff on making the open-source drivers work as well as > > I can in the time allowed. So you want me to spend my time supporting a > > company that won't help me, just because you gave them money? > > I don't want you to spend time supporting a company, I want you to > spend time supporting the Fedora users who love their OS and would > love to be able to use their hardware to its fullest extent. That is > all. I really don't expect an xorg build for every binary blob out > there, but a stable version of xorg as an alternative for those who > are having problems with the beta version should have been given more > consideration in my opinion. As was brought up in a recent thread (of a similarly long and pointless nature), any Fedora user is free to work on getting support for whatever they want into Fedora proper, and popular vote has absolutely *nothing* to do with what actually gets included in Fedora. If you want something done, do it yourself. If you aren't satisfied by numerous explanations, find something that satisfies you more than Fedora. We love having more users, but repeated complaints from leeches are just annoying. -- Conrad Meyer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From nathanael at gnat.ca Wed May 21 04:24:37 2008 From: nathanael at gnat.ca (Nathanael D. Noblet) Date: Tue, 20 May 2008 22:24:37 -0600 Subject: New Xorg In-Reply-To: <1211343195.2928.25.camel@jdlaptop> References: <1211343195.2928.25.camel@jdlaptop> Message-ID: <4833A405.6070802@gnat.ca> Jonathan Dieter wrote: > I know this probably isn't the place to do this, but I'm not sure what > the right place is. ajax & Dave, thank you for the work you've done on > the new Xorg. I know there have been lots of complaints, and, as an > nVidia user, I understand them. Me too. I'd not use it if I could have spanning desktops in the OSS version of the driver. > However, the stuff you're working on for *all* the other drivers is > pretty incredible and more than makes up for a few weeks without > eye-candy on my primary system. The way it all works on Intel video > cards is great, and I'm particularly impressed with the DRI2 stuff > (though kernel mode-setting is pretty cool too). Please keep it up. Ditto. And I can't wait till nvidia gets it and releases an OSS driver that can keep up and let us do what we want with our own hardware. -- Nathanael D. Noblet From chris.stone at gmail.com Wed May 21 04:32:51 2008 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 20 May 2008 21:32:51 -0700 Subject: Xorg 1.5 missed the train? In-Reply-To: <200805202124.20893.konrad@tylerc.org> References: <48334163.4080709@magma.ca> <1211343191.3682.9.camel@clockmaker.usersys.redhat.com> <200805202124.20893.konrad@tylerc.org> Message-ID: 2008/5/20 Konrad Meyer : > As was brought up in a recent thread (of a similarly long and pointless > nature), any Fedora user is free to work on getting support for whatever they > want into Fedora proper, and popular vote has absolutely *nothing* to do with > what actually gets included in Fedora. If you want something done, do it > yourself. If you aren't satisfied by numerous explanations, find something > that satisfies you more than Fedora. We love having more users, but repeated > complaints from leeches are just annoying. I'm sure a repo will pop up with all the necessary rpms if nVidia doesn't come out with drivers soon enough. It is just frustrating that it has to happen this way. Such a small amount of effort to make the distro user friendly for everyone, and yet we must stick to our principles and screw the end user. It doesn't make sense. From cmadams at hiwaay.net Wed May 21 04:40:44 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 20 May 2008 23:40:44 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <1211343191.3682.9.camel@clockmaker.usersys.redhat.com> <200805202124.20893.konrad@tylerc.org> Message-ID: <20080521044044.GA1467773@hiwaay.net> Once upon a time, Christopher Stone said: > Such a small amount of effort to make > the distro user friendly for everyone, Repeating that over and over does not make it any more true. > and yet we must stick to our > principles and screw the end user. It doesn't make sense. The principles are there for a reason. A little short term gain can often "screw the user" in the long run. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From dev at nigelj.com Wed May 21 04:42:20 2008 From: dev at nigelj.com (Nigel Jones) Date: Wed, 21 May 2008 16:42:20 +1200 Subject: New Xorg In-Reply-To: <1211343195.2928.25.camel@jdlaptop> References: <1211343195.2928.25.camel@jdlaptop> Message-ID: <4833A82C.2070602@nigelj.com> Jonathan Dieter wrote: > I know this probably isn't the place to do this, but I'm not sure what > the right place is. ajax & Dave, thank you for the work you've done on > the new Xorg. I know there have been lots of complaints, and, as an > nVidia user, I understand them. > I'm a nVidia user too, the only problem(s) I experience is the displayed area is a few pixels to the right than it should be (I could fix this but it'd stuff up dual boot) and it's a bit slower than what I remember F8 to be. I understand all the different viewpoints and reasons, we don't want our users left with out of date trash for 5 months until F10 is out, and nVidia wanted to make sure that nothing was going to change on them. *NO ONE* is to blame, just an unfortunate coincidence of release cycles, there isn't much point delaying a release till absolutely everything is out of beta and also, it provides an excellent method for users to play a part in improving Fedora, get them to report their thoughts/problems/bugs! > However, the stuff you're working on for *all* the other drivers is > pretty incredible and more than makes up for a few weeks without > eye-candy on my primary system. The way it all works on Intel video > cards is great, and I'm particularly impressed with the DRI2 stuff > (though kernel mode-setting is pretty cool too). Please keep it up. > I think an excellent job has been done and I think credit must be given when it's due, and it is. - Nigel (Oh and can we keep this thread on a positive note, too many negative e-mails lately... just for our sanity.... please... pretty please?) From chris.stone at gmail.com Wed May 21 04:42:49 2008 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 20 May 2008 21:42:49 -0700 Subject: Xorg 1.5 missed the train? In-Reply-To: <20080521044044.GA1467773@hiwaay.net> References: <48334163.4080709@magma.ca> <1211343191.3682.9.camel@clockmaker.usersys.redhat.com> <200805202124.20893.konrad@tylerc.org> <20080521044044.GA1467773@hiwaay.net> Message-ID: On Tue, May 20, 2008 at 9:40 PM, Chris Adams wrote: > Once upon a time, Christopher Stone said: >> Such a small amount of effort to make >> the distro user friendly for everyone, > > Repeating that over and over does not make it any more true. So, you are agreeing that it is true. > >> and yet we must stick to our >> principles and screw the end user. It doesn't make sense. > > The principles are there for a reason. A little short term gain can > often "screw the user" in the long run. Not in this case. From j.w.r.degoede at hhs.nl Wed May 21 04:56:56 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 21 May 2008 06:56:56 +0200 Subject: New Xorg In-Reply-To: <1211343195.2928.25.camel@jdlaptop> References: <1211343195.2928.25.camel@jdlaptop> Message-ID: <4833AB98.2060902@hhs.nl> Jonathan Dieter wrote: > I know this probably isn't the place to do this, but I'm not sure what > the right place is. ajax & Dave, thank you for the work you've done on > the new Xorg. I know there have been lots of complaints, and, as an > nVidia user, I understand them. > > However, the stuff you're working on for *all* the other drivers is > pretty incredible and more than makes up for a few weeks without > eye-candy on my primary system. The way it all works on Intel video > cards is great, and I'm particularly impressed with the DRI2 stuff > (though kernel mode-setting is pretty cool too). Please keep it up. > +1 Regards, Hans (who only owns radeon, intel and s3 videocards, gee I wonder why that is) From lesmikesell at gmail.com Wed May 21 05:24:44 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 21 May 2008 00:24:44 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: <1211340916.3307.2.camel@clockmaker.usersys.redhat.com> References: <48334163.4080709@magma.ca> <1211335226.3768.1.camel@clockmaker.usersys.redhat.com> <20080520211137.67744ac3@vader.jdub.homelinux.org> <48338811.3090700@gmail.com> <48338D79.9020304@gmail.com> <20080520220210.77f97a82@vader.jdub.homelinux.org> <1211340916.3307.2.camel@clockmaker.usersys.redhat.com> Message-ID: <4833B21C.2020807@gmail.com> Dave Airlie wrote: > > > Let me repeat via cut-n-paste: > 1. X.org ABI for 1.5 is what we ship in F9, this hasn't changed in > months, I've ported 15 other drivers to it in this time. It will not > change before 1.5 final is released. Seems odd that you knew it wasn't going to change and had time to port drivers but no one else knew. > 2. Nvidia don't release drivers for X.org releases. Are you speaking for them? On their own Linux forum someone who appears to be an employee says: "Full support, including GLX support, for xorg-server 1.5 will be available in a future driver release after the video driver ABI has been finalized" That sorta sounds like a plan to release a driver for the Xorg release to me. Too bad we haven't had one. Or an announcement that the ABI was finalized by the time that was written. > I was as much responsible for shipping 1.5 pre-release in Fedora as ajax > was, and funnily these threads actually move me to break the nvidia > driver more often rather than less :-) Gotta love the spirit of cooperation here. Can you break VMware and skype a little more too for the trifecta of linux-supporting vendors? -- Les Mikesell lesmikesell at gmail.com From gilboad at gmail.com Wed May 21 05:40:23 2008 From: gilboad at gmail.com (Gilboa Davara) Date: Wed, 21 May 2008 08:40:23 +0300 Subject: New Xorg In-Reply-To: <1211343195.2928.25.camel@jdlaptop> References: <1211343195.2928.25.camel@jdlaptop> Message-ID: <1211348423.14588.31.camel@gilboa-home-dev.localdomain> On Wed, 2008-05-21 at 07:13 +0300, Jonathan Dieter wrote: > I know this probably isn't the place to do this, but I'm not sure what > the right place is. ajax & Dave, thank you for the work you've done on > the new Xorg. I know there have been lots of complaints, and, as an > nVidia user, I understand them. > > However, the stuff you're working on for *all* the other drivers is > pretty incredible and more than makes up for a few weeks without > eye-candy on my primary system. The way it all works on Intel video > cards is great, and I'm particularly impressed with the DRI2 stuff > (though kernel mode-setting is pretty cool too). Please keep it up. > > Jonathan /+1. Even-though I've got a number of F8 machines with nVidia cards, I still support the X.org maintainer's decision to use a pre-release X.org/X-server version. Being an OSS project, Fedora should -only- consider the state of their OSS eco-system when making decisions. More-ever, I find that blaming Fedora for not making decisions based on nVidia's policy while ignoring the (sad) state of the OSS nv driver, is nothing short of hypocrisy. If -I- chose* to to use binary drivers - Fedora should not be held accountable for -my- decision. - Gilboa * At least until ATI/AMD OSS drivers mature and gain significant 3D support. From kevin.kofler at chello.at Wed May 21 05:59:17 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 21 May 2008 05:59:17 +0000 (UTC) Subject: Xorg 1.5 missed the train? References: <48334163.4080709@magma.ca> <1211335226.3768.1.camel@clockmaker.usersys.redhat.com> <20080520211137.67744ac3@vader.jdub.homelinux.org> <48338811.3090700@gmail.com> <48338D79.9020304@gmail.com> <20080520220210.77f97a82@vader.jdub.homelinux.org> <1211340916.3307.2.camel@clockmaker.usersys.redhat.com> <4833B21C.2020807@gmail.com> Message-ID: Les Mikesell gmail.com> writes: > Gotta love the spirit of cooperation here. Can you break VMware and > skype a little more too for the trifecta of linux-supporting vendors? Releasing binary crap isn't supporting GNU/Linux. Intel is a video chip (*) vendor supporting Free Software, AMD (ATI) is becoming one to some extent with their release of specs, NVidia is the one major vendor which is NOT supporting Free Software. (*) I'm intentionally not using "card" here to avoid the semantics wars. Kevin Kofler From lordmorgul at gmail.com Wed May 21 06:05:02 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Tue, 20 May 2008 23:05:02 -0700 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <1211343191.3682.9.camel@clockmaker.usersys.redhat.com> <200805202124.20893.konrad@tylerc.org> Message-ID: <4833BB8E.3090304@gmail.com> Christopher Stone wrote: > I'm sure a repo will pop up with all the necessary rpms if nVidia > doesn't come out with drivers soon enough. It is just frustrating > that it has to happen this way. Such a small amount of effort to make > the distro user friendly for everyone, and yet we must stick to our > principles and screw the end user. It doesn't make sense. You seem to be deliberately ignoring the already stated (more than once) in the thread actual workaround that has existed for months. The F8 version xorg rpms work just fine with F9... many people have been using them for months during the F9 development cycle... there are multiple howto and blog posts about how to make it happen. The rpms don't need to show up in a special repo. The xorg developers don't need to fix some hack-workaround-multiple-xserver release. You need to try using google. If you cannot handle the downgrade you need to try using google again for instructions on downgrading rpms. Finally, you should put your time to better use by doing the aforementioned things (which would result in a nicely working F9+nvidia glx capable system in much less time than it took to complain about this). As for your previous 'it looks easy to me' claims on providing the backward capability: please go ahead and supply those rpms at your leisure if it is so easy. The rest of us will probably just downgrade xorg to F8 happily or wait for nvidia. If you're interested, I have criticized nvidia over their slow release cycle for years now, but criticizing the Fedora community over this issue is just pointless. The problem lies in the smallish development resources nvidia has dedicated to the linux community which cannot handle rapid development and release for moving targets (the ABI changes). -- Andrew Farris www.lordmorgul.net gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29 From drago01 at gmail.com Wed May 21 06:18:28 2008 From: drago01 at gmail.com (drago01) Date: Wed, 21 May 2008 08:18:28 +0200 Subject: Xorg 1.5 missed the train? In-Reply-To: <4833BB8E.3090304@gmail.com> References: <48334163.4080709@magma.ca> <1211343191.3682.9.camel@clockmaker.usersys.redhat.com> <200805202124.20893.konrad@tylerc.org> <4833BB8E.3090304@gmail.com> Message-ID: http://www.nvnews.net/vbulletin/showpost.php?p=1653299&postcount=9 http://www.nvnews.net/vbulletin/showpost.php?p=1656695&postcount=54 http://www.nvnews.net/vbulletin/showpost.php?p=1659061&postcount=3 From lordmorgul at gmail.com Wed May 21 06:23:14 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Tue, 20 May 2008 23:23:14 -0700 Subject: Xorg 1.5 missed the train? In-Reply-To: <54216.75.164.221.130.1211322252.squirrel@clueserver.org> References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <1211319877.8531.40.camel@localhost.localdomain> <604aa7910805201505m7cc84699p953aa880b7419413@mail.gmail.com> <604aa7910805201514h4535567atd4e7c6c67bb74a84@mail.gmail.com> <54216.75.164.221.130.1211322252.squirrel@clueserver.org> Message-ID: <4833BFD2.4070901@gmail.com> Alan wrote: >> On Tue, May 20, 2008 at 2:10 PM, Christopher Stone >> wrote: >>> Okay, this is good news. I'll post on the nVidia forums to make sure >>> they know. I still think it's a bit uncalled for to say nVidia should >>> get their act together when the ABI was only declared stable last >>> week. >> Dude that thread is super long...and I was quoting an nvidia dev from >> the thread. >> Trust me... they know. Post #42 is a really good read concerning the >> recent history of the ABI. There is absolutely nothing new here. > > There seems to be some internal debate within nvidia about when the new > version(s) get released. They know the abi is stable, but there seems to > be someone within nvidia who is waiting for the official 1.5 release. If this is in reference to Zander's comments in the previously posted nvnews.net forum thread then do keep in mind this is the same Zander who is responsible for the nvidia drivers original kernel 2.6 patches and capability; He of all people knows very well how much work needs to go into supporting rapid kernel/X development changes. I'm sure that work is being done on it, and they are well aware now that (due to Fedora using the ABI) it is no longer a moving target. Had Fedora not released with the new Xorg ABI nvidia would probably still not be actively working on it yet. -- Andrew Farris www.lordmorgul.net gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29 From lordmorgul at gmail.com Wed May 21 06:28:39 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Tue, 20 May 2008 23:28:39 -0700 Subject: Xorg 1.5 missed the train? In-Reply-To: <48335FC0.2070806@gmail.com> References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <20080520215909.GF12622@inocybe.teonanacatl.org> <48334E0E.7090803@gmail.com> <48334F03.6070203@fedoraproject.org> <35207.75.164.221.130.1211322487.squirrel@clueserver.org> <1218b5bc0805201625p21ba80b9y9cffd6eeb7fcec9b@mail.gmail.com> <48335FC0.2070806@gmail.com> Message-ID: <4833C117.5090007@gmail.com> Les Mikesell wrote: > Please post that on the http://fedoraproject.org/ page so everyone will > understand what to expect. "Fedora is a Linux-based operating system that showcases the latest in free and open source software." "The Fedora Project is out front for you, leading the advancement of free, open software and content." If that is ambiguous you're not really reading very clearly. How else are you going to interpret a purpose to showcase, lead, and advance... -- Andrew Farris www.lordmorgul.net gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29 From kevin.kofler at chello.at Wed May 21 06:29:13 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 21 May 2008 06:29:13 +0000 (UTC) Subject: Xorg 1.5 missed the train? References: <48334163.4080709@magma.ca> <1211326768.10484.4.camel@clockmaker.usersys.redhat.com> <483374C2.1030800@gmail.com> Message-ID: Les Mikesell gmail.com> writes: > Was anyone asking you to "support" one of the vendors that actually > makes an effort to help Linux users? They are the one (major GPU) vendor which makes NO effort to support Free Software WHATSOEVER. NO source code (except some very old contributions to "nv" with no acceleration support, and those are intentionally obfuscated, which is blatantly against the spirit of Free Software, a lot of work Nouveau has to do is unobfuscating that code), NO specs (whatsoever - AFAIK they don't even provide them under an NDA), and repeated confirmation that they DON'T care at all about Free Software. Kevin Kofler From lesmikesell at gmail.com Wed May 21 06:44:09 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 21 May 2008 01:44:09 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: <4833C117.5090007@gmail.com> References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <20080520215909.GF12622@inocybe.teonanacatl.org> <48334E0E.7090803@gmail.com> <48334F03.6070203@fedoraproject.org> <35207.75.164.221.130.1211322487.squirrel@clueserver.org> <1218b5bc0805201625p21ba80b9y9cffd6eeb7fcec9b@mail.gmail.com> <48335FC0.2070806@gmail.com> <4833C117.5090007@gmail.com> Message-ID: <4833C4B9.3020105@gmail.com> Andrew Farris wrote: > Les Mikesell wrote: >> Please post that on the http://fedoraproject.org/ page so everyone >> will understand what to expect. > > "Fedora is a Linux-based operating system that showcases the latest in > free and open source software." > > "The Fedora Project is out front for you, leading the advancement of > free, open software and content." > > If that is ambiguous you're not really reading very clearly. How else > are you going to interpret a purpose to showcase, lead, and advance... If I wanted to showcase something, I'd make an effort to make sure it worked on popular hardware and with other popular software at its release. I don't think that's descriptive at all. -- Les Mikesell lesmikesell at gmail.com From nicu_fedora at nicubunu.ro Wed May 21 07:12:06 2008 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Wed, 21 May 2008 10:12:06 +0300 Subject: changes at planet fedora In-Reply-To: <1211214812.3095.0.camel@cutter> References: <1211214812.3095.0.camel@cutter> Message-ID: <4833CB46.4010005@nicubunu.ro> seth vidal wrote: > > http://skvidal.fedorapeople.org/docs/planet-addition.html > > These instructions will be added to the wiki after the wiki migration > happens next week. > > Let me know what problems you have, too. It does not work for me. I am already on Planet and dropped a .planet file in my homedir (nicubunu), specifying the same URL for the feed, the same person name but a different hackergotchi image. This change seems ignored, the old image is still displayed (I suspect the script finds the duplicate and remove the wrong entry). -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From emmanuel.seyman at club-internet.fr Wed May 21 07:17:12 2008 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Wed, 21 May 2008 09:17:12 +0200 Subject: New Xorg In-Reply-To: <1211348423.14588.31.camel@gilboa-home-dev.localdomain> References: <1211343195.2928.25.camel@jdlaptop> <1211348423.14588.31.camel@gilboa-home-dev.localdomain> Message-ID: <20080521071712.GA2794@orient.maison.lan> * Gilboa Davara [21/05/2008 08:53] : > > Even-though I've got a number of F8 machines with nVidia cards, I still > support the X.org maintainer's decision to use a pre-release > X.org/X-server version. +1 Nvidia cards will only work on GNU/Linux when the nouveau driver works well enough for everyday use. Anything else (this includes binary drivers) is a hack. Emmanuel From nicu_fedora at nicubunu.ro Wed May 21 07:18:27 2008 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Wed, 21 May 2008 10:18:27 +0300 Subject: changes at planet fedora In-Reply-To: <20080520201228.3dfb45b6@vader.jdub.homelinux.org> References: <1211214812.3095.0.camel@cutter> <6e24a8e80805201301r44a241bdr9b2263052fe1fd8b@mail.gmail.com> <6e24a8e80805201550o12531af3ye6692f9571cb5230@mail.gmail.com> <48335785.4050800@fedoraproject.org> <20080520201228.3dfb45b6@vader.jdub.homelinux.org> Message-ID: <4833CCC3.1050405@nicubunu.ro> Josh Boyer wrote: > Rahul Sundaram wrote: >> Planet Fedora is explicitly a aggregation of blogs from official Fedora >> contributors who require a Fedora account anyway. What is being done > > Actually, I don't think that's quite true. There is at least one blog > syndicated there that doesn't have a FAS account today. So the FAS > requirement is new. I asked on the infrastructure list about "policy" and was told there is no policy, so my understanding is me, having a FAS account, I am allowed to add *multiple* feeds, like one for my personal blog and another for my local (Romanian) Fedora community, even if this community is not a FAS account owner. -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From dev at nigelj.com Wed May 21 07:23:05 2008 From: dev at nigelj.com (Nigel Jones) Date: Wed, 21 May 2008 19:23:05 +1200 Subject: changes at planet fedora In-Reply-To: <4833CB46.4010005@nicubunu.ro> References: <1211214812.3095.0.camel@cutter> <4833CB46.4010005@nicubunu.ro> Message-ID: <4833CDD9.6090705@nigelj.com> Nicu Buculei wrote: > seth vidal wrote: >> >> http://skvidal.fedorapeople.org/docs/planet-addition.html >> >> These instructions will be added to the wiki after the wiki migration >> happens next week. >> >> Let me know what problems you have, too. > > It does not work for me. > I am already on Planet and dropped a .planet file in my homedir > (nicubunu), specifying the same URL for the feed, the same person name > but a different hackergotchi image. This change seems ignored, the old > image is still displayed (I suspect the script finds the duplicate and > remove the wrong entry). > Unless I'm mistaken, the script is not yet running or at least not publicly generating the new planet HTML, (I'm pretty sure considering my .planet file isn't in there yet) - Nigel From lordmorgul at gmail.com Wed May 21 07:25:34 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Wed, 21 May 2008 00:25:34 -0700 Subject: Xorg 1.5 missed the train? In-Reply-To: <4833C4B9.3020105@gmail.com> References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <20080520215909.GF12622@inocybe.teonanacatl.org> <48334E0E.7090803@gmail.com> <48334F03.6070203@fedoraproject.org> <35207.75.164.221.130.1211322487.squirrel@clueserver.org> <1218b5bc0805201625p21ba80b9y9cffd6eeb7fcec9b@mail.gmail.com> <48335FC0.2070806@gmail.com> <4833C117.5090007@gmail.com> <4833C4B9.3020105@gmail.com> Message-ID: <4833CE6E.8070107@gmail.com> Les Mikesell wrote: > Andrew Farris wrote: >> Les Mikesell wrote: >>> Please post that on the http://fedoraproject.org/ page so everyone >>> will understand what to expect. >> >> "Fedora is a Linux-based operating system that showcases the latest in >> free and open source software." >> >> "The Fedora Project is out front for you, leading the advancement of >> free, open software and content." >> >> If that is ambiguous you're not really reading very clearly. How else >> are you going to interpret a purpose to showcase, lead, and advance... > > If I wanted to showcase something, I'd make an effort to make sure it > worked on popular hardware and with other popular software at its > release. I don't think that's descriptive at all. All goals are not always harmonious with each other either. -- Andrew Farris www.lordmorgul.net gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29 From dev at nigelj.com Wed May 21 07:30:47 2008 From: dev at nigelj.com (Nigel Jones) Date: Wed, 21 May 2008 19:30:47 +1200 Subject: changes at planet fedora In-Reply-To: <4833CCC3.1050405@nicubunu.ro> References: <1211214812.3095.0.camel@cutter> <6e24a8e80805201301r44a241bdr9b2263052fe1fd8b@mail.gmail.com> <6e24a8e80805201550o12531af3ye6692f9571cb5230@mail.gmail.com> <48335785.4050800@fedoraproject.org> <20080520201228.3dfb45b6@vader.jdub.homelinux.org> <4833CCC3.1050405@nicubunu.ro> Message-ID: <4833CFA7.9000703@nigelj.com> Nicu Buculei wrote: > Josh Boyer wrote: >> Rahul Sundaram wrote: >>> Planet Fedora is explicitly a aggregation of blogs from official >>> Fedora contributors who require a Fedora account anyway. What is >>> being done >> >> Actually, I don't think that's quite true. There is at least one blog >> syndicated there that doesn't have a FAS account today. So the FAS >> requirement is new. In fact there are several: * Fedora Daily Package * Fedora Indonesia * Red Hat Magazine etc etc etc > > I asked on the infrastructure list about "policy" and was told there > is no policy, so my understanding is me, having a FAS account, I am > allowed to add *multiple* feeds, like one for my personal blog and > another for my local (Romanian) Fedora community, even if this > community is not a FAS account owner. > But yes, you can have more than one feed per person from my understanding. - Nigel From mschwendt at gmail.com Wed May 21 07:31:41 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 21 May 2008 09:31:41 +0200 Subject: getting rid of vendor prefixes for desktop files In-Reply-To: <1211303923.8530.10.camel@localhost.localdomain> References: <1211303923.8530.10.camel@localhost.localdomain> Message-ID: <20080521093141.234ac115.mschwendt@gmail.com> On Tue, 20 May 2008 13:18:43 -0400, Matthias Clasen wrote: > I'd like to discuss the idea of getting rid of vendor prefixes for > desktop files in Fedora. Right now, we install desktop files with a > mixture of vendor prefixes: gnome-, fedora-, redhat-, nothing. > > These prefixes really add no value, and cause actual breakage, since > Fedora is (afaik) the only distro adding vendor prefixes, so we are the > ones that get bitten by upstream changes that don't take vendor prefixes > into account. > > The recent breakage that made me write this mail is that the new > gnome-session in rawhide has a list of mandatory session components > stored in gconf, and one of these components was 'nautilus', so it went > looking for nautilus.desktop - which doesn't exist, since we ship > gnome-nautilus.desktop. > > Another problem caused by these prefixes is that overlaying a self-built > gnome, e.g. a jhbuild tree on top of a fedora installation gives you > everything doubled in the menus. Once with a vendor prefix, and once > without, instead of the indended effect of the self built tree hiding > the installed desktop files. > > Thus, I'd like to propose that we change the packaging guidelines to > stop recommending the addition of a vendor prefix, and remove existing > vendor prefixes in F10. This will cause a mild one-time pain for > existing users with customized menus. We can probably discuss ways to > avoid that. > > Comments ? What have you planned to avoid messing up user's panel and menu? For example, emacs-22.2-4.fc9 suddenly decided to ship emacs.desktop instead of the earlier gnu-emacs.desktop. This invalidated the GConf setting for my customised panel where I had dragged'n'dropped the emacs menu entry: panel/objects/object_3/%gconf.xml: /usr/share/applications/gnu-emacs.desktop Instead of the application icon it shows a blank area now. It's not the first time this has happend with a package. And it really asks for a stable vendor prefix (even if empty). Else this is much too fragile during upgrades and updates if packagers and upstream can change the vendor prefix whenever they like. From fedora-devel-list at krp.org.uk Wed May 21 07:48:52 2008 From: fedora-devel-list at krp.org.uk (Kevin Page) Date: Wed, 21 May 2008 08:48:52 +0100 Subject: New Xorg In-Reply-To: <4833A405.6070802@gnat.ca> References: <1211343195.2928.25.camel@jdlaptop> <4833A405.6070802@gnat.ca> Message-ID: <1211356132.3215.19.camel@localhost.localdomain> On Tue, 2008-05-20 at 22:24 -0600, Nathanael D. Noblet wrote: > Me too. I'd not use it if I could have spanning desktops in the OSS > version of the driver. This now works for me with nouveau in F9 (thanks!), though I appreciate it may not for all nvidia cards. I need to add: "Option" "randr12" "1" to xorg.conf I very much support the stance Fedora takes on this! kev. (Though it has to be said, my previous solution - adding a Radeon PCI card as the second head to the Nvidia PCIe card inflicted upon me - still doesn't seem to work, with no indication as to whether it ever will/should. It's tough to find a dual-head DVI solution using open source drivers; speculatively buying hardware until something works isn't always feasible. https://bugs.freedesktop.org/show_bug.cgi?id=2597 https://bugzilla.redhat.com/show_bug.cgi?id=227851 ) From mail at robertoragusa.it Wed May 21 08:19:42 2008 From: mail at robertoragusa.it (Roberto Ragusa) Date: Wed, 21 May 2008 10:19:42 +0200 Subject: F8 -> F9 but keeping KDE3: technically feasible? In-Reply-To: References: <483076E8.70601@robertoragusa.it> <483295E6.8030404@gmail.com> <48332C43.3080501@robertoragusa.it> <48333034.7080502@gmail.com> Message-ID: <4833DB1E.9080307@robertoragusa.it> Kevin Kofler wrote: > Andrew Farris gmail.com> writes: >> You can use the nvidia drivers with F9 if you run the F8 xorg packages; quite >> a few people have been doing this with success throughout the F9 development. > > But if he's using F8 KDE and F8 X.Org X11, there's not much left of F9, is > there? I mean, what's the goal? Being able to say he's "running F9"? That is what I was thinking after realizing the Xorg issue. What's left? gcc4.3, firefox3, the new Java... Is it worth the effort? I'm skeptical too. :-) > IMHO it is a really bad idea to try to upgrade only parts of the distro, we > have done ABSOLUTELY ZERO testing of the KDE 3 packages from F8 with F9, > whoever attempts that may run into dependency problems and other issues. The dependency problems are not too scary, because they will come up in yum during the update phase (even if I see many libssl and libcrypto issues). The worst part would be submarine dependencies between (patched?) KDE3 and other parts (will removable disk mounting work in KDE3 in F9? stuff like that). -- Roberto Ragusa mail at robertoragusa.it From jonathan.underwood at gmail.com Wed May 21 08:22:44 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Wed, 21 May 2008 09:22:44 +0100 Subject: Small RFEs for Fedora Accounts System In-Reply-To: <483368A3.60600@gmail.com> References: <645d17210805201551q2d5e1f84l8af88e7233ba76f1@mail.gmail.com> <483368A3.60600@gmail.com> Message-ID: <645d17210805210122y7f19b766obbce5171fd2354e@mail.gmail.com> Thanks Toshio & Jon - I'll report such stuff on the project page in future. From seg at haxxed.com Wed May 21 08:25:17 2008 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 21 May 2008 03:25:17 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: <1211335362.24852.294.camel@victoria> References: <48334163.4080709@magma.ca> <20080520215909.GF12622@inocybe.teonanacatl.org> <48334E0E.7090803@gmail.com> <48334F03.6070203@fedoraproject.org> <35207.75.164.221.130.1211322487.squirrel@clueserver.org> <1218b5bc0805201625p21ba80b9y9cffd6eeb7fcec9b@mail.gmail.com> <48336316.8060606@fedoraproject.org> <1218b5bc0805201822p52f0dab8l3c22b76540d1cd42@mail.gmail.com> <1211335362.24852.294.camel@victoria> Message-ID: <1218b5bc0805210125x8847f19if6e3bd0e18c4656d@mail.gmail.com> 2008/5/20 Paul W. Frields : > You were doing really well up to the last couple of lines. Please, > let's try to keep things civil. I know it's frustrating when community > members have to explain open source fundamentals repeatedly. This might > make good fodder for a FAQ entry, to which you could simply point. There's a reason I'm in engineering and not sales. Or marketing. Or support... But yeah. Serious FAQ territory here. -------------- next part -------------- An HTML attachment was scrubbed... URL: From seg at haxxed.com Wed May 21 08:38:43 2008 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 21 May 2008 03:38:43 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: <4833C4B9.3020105@gmail.com> References: <48334163.4080709@magma.ca> <20080520215909.GF12622@inocybe.teonanacatl.org> <48334E0E.7090803@gmail.com> <48334F03.6070203@fedoraproject.org> <35207.75.164.221.130.1211322487.squirrel@clueserver.org> <1218b5bc0805201625p21ba80b9y9cffd6eeb7fcec9b@mail.gmail.com> <48335FC0.2070806@gmail.com> <4833C117.5090007@gmail.com> <4833C4B9.3020105@gmail.com> Message-ID: <1218b5bc0805210138l4b508c05x6dc1d90fca9b25e3@mail.gmail.com> On Wed, May 21, 2008 at 1:44 AM, Les Mikesell wrote: > If I wanted to showcase something, I'd make an effort to make sure it > worked on popular hardware and with other popular software at its release. > I don't think that's descriptive at all. I like how in these threads it keeps conveniently being ignored that we work just fine out of the box on Nvidia. We just don't have 3D yet. Les GTFO. -------------- next part -------------- An HTML attachment was scrubbed... URL: From emmanuel.seyman at club-internet.fr Wed May 21 09:19:06 2008 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Wed, 21 May 2008 11:19:06 +0200 Subject: Xorg 1.5 missed the train? In-Reply-To: <1218b5bc0805210138l4b508c05x6dc1d90fca9b25e3@mail.gmail.com> References: <20080520215909.GF12622@inocybe.teonanacatl.org> <48334E0E.7090803@gmail.com> <48334F03.6070203@fedoraproject.org> <35207.75.164.221.130.1211322487.squirrel@clueserver.org> <1218b5bc0805201625p21ba80b9y9cffd6eeb7fcec9b@mail.gmail.com> <48335FC0.2070806@gmail.com> <4833C117.5090007@gmail.com> <4833C4B9.3020105@gmail.com> <1218b5bc0805210138l4b508c05x6dc1d90fca9b25e3@mail.gmail.com> Message-ID: <20080521091906.GA3918@orient.maison.lan> * Callum Lerwick [21/05/2008 11:03] : > > I like how in these threads it keeps conveniently being ignored that we work > just fine out of the box on Nvidia. We just don't have 3D yet. I've always being surprised at the amount of blame-shifting that occurs in regards to Nvidia's drivers. - The free drivers suck. This apparently isn't NVidia's fault (which is strange since they help maintain it) but the x.org developers'. - The non-free drivers aren't free. This apparently isn't NVidia's fault. - This makes the drivers impossible to ship as part of the distribution or support as a third-party repo. This is somehow the distribution's fault. - They don't release drivers once the ABI is frozen or even the day stable releases of x.org are issued. This apparently isn't their fault. - They won't release the specs. This apparently isn't their fault. - They badmouth the open source developement model. I have no idea why but this isn't their fault. Emmanuel From mefoster at gmail.com Wed May 21 09:30:55 2008 From: mefoster at gmail.com (Mary Ellen Foster) Date: Wed, 21 May 2008 10:30:55 +0100 Subject: Did the "uname" change on ppc64 in Rawhide? Message-ID: I'm trying to figure out why a package that built for F8 and F9 failed on Rawhide. Here are the logs for the failed Rawhide bid: http://koji.fedoraproject.org/koji/taskinfo?taskID=622220 In this build, "configure" dies with: checking build system type... Invalid configuration `ppc64-redhat-linux-gnu': machine `ppc64-redhat' not recognized configure: error: /bin/sh ./config.sub ppc64-redhat-linux-gnu failed Whereas on F8 and F9 on PPC64, building the identical SRPM works fine (http://koji.fedoraproject.org/koji/taskinfo?taskID=622181 and http://koji.fedoraproject.org/koji/taskinfo?taskID=622176) and the corresponding output from "configure" in both cases is: checking build system type... powerpc64-redhat-linux-gnu [ ... continue configuring ... ] Any suggestions what's going on here? Thanks, MEF -- Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/ Informatik 6: Robotics and Embedded Systems, Technische Universit?t M?nchen and ICCS, School of Informatics, University of Edinburgh From rc040203 at freenet.de Wed May 21 09:39:09 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 21 May 2008 11:39:09 +0200 Subject: Did the "uname" change on ppc64 in Rawhide? In-Reply-To: References: Message-ID: <1211362749.26792.1680.camel@beck.corsepiu.local> On Wed, 2008-05-21 at 10:30 +0100, Mary Ellen Foster wrote: > I'm trying to figure out why a package that built for F8 and F9 failed > on Rawhide. Here are the logs for the failed Rawhide bid: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=622220 > > In this build, "configure" dies with: > checking build system type... > Invalid configuration `ppc64-redhat-linux-gnu': machine > `ppc64-redhat' not recognized > configure: error: /bin/sh ./config.sub ppc64-redhat-linux-gnu failed > > Whereas on F8 and F9 on PPC64, building the identical SRPM works fine > (http://koji.fedoraproject.org/koji/taskinfo?taskID=622181 and > http://koji.fedoraproject.org/koji/taskinfo?taskID=622176) and the > corresponding output from "configure" in both cases is: > checking build system type... > powerpc64-redhat-linux-gnu > [ ... continue configuring ... ] > > Any suggestions what's going on here? Wild guess: Very likely, the package you are trying to build is shipping a very outdated "config.guess" and/or which doesn't recognize the triplet (Read: Outdated upstream sources) Either replace (patch) the versions of config.guess/config.sub inside of the tarball with more recent ones, or (better) convince upstream to update their config.guess/config.sub. Ralf From paul at city-fan.org Wed May 21 09:40:01 2008 From: paul at city-fan.org (Paul Howarth) Date: Wed, 21 May 2008 10:40:01 +0100 Subject: Did the "uname" change on ppc64 in Rawhide? In-Reply-To: References: Message-ID: <4833EDF1.5040908@city-fan.org> Mary Ellen Foster wrote: > I'm trying to figure out why a package that built for F8 and F9 failed > on Rawhide. Here are the logs for the failed Rawhide bid: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=622220 > > In this build, "configure" dies with: > checking build system type... > Invalid configuration `ppc64-redhat-linux-gnu': machine > `ppc64-redhat' not recognized > configure: error: /bin/sh ./config.sub ppc64-redhat-linux-gnu failed > > Whereas on F8 and F9 on PPC64, building the identical SRPM works fine > (http://koji.fedoraproject.org/koji/taskinfo?taskID=622181 and > http://koji.fedoraproject.org/koji/taskinfo?taskID=622176) and the > corresponding output from "configure" in both cases is: > checking build system type... > powerpc64-redhat-linux-gnu > [ ... continue configuring ... ] > > Any suggestions what's going on here? Dunno, but I came across this yesterday too. A package that built everywhere apart from ppc64 (and had built previously on F9) failed on ppc64: http://koji.fedoraproject.org/koji/taskinfo?taskID=620258 The configure script doesn't bomb out entirely but it decides that its libtool doesn't know how to build shared libraries...: checking host system type... Invalid configuration `ppc64-redhat-linux-gnu': machine `ppc64-redhat' not recognized checking build system type... Invalid configuration `ppc64-redhat-linux-gnu': machine `ppc64-redhat' not recognized checking for ld used by GCC... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes ... (snip) ... checking whether the linker (/usr/bin/ld) supports shared libraries... yes checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking dynamic linker characteristics... no checking if libtool supports shared libraries... no And that then leads to the eventual failure: gcc -shared SAX.lo entities.lo encoding.lo error.lo parser.lo parserold.lo HTMLparser.lo HTMLtree.lo debugXML.lo tree.lo xpath.lo xmlIO.lo xmlmemory.lo nanohttp.lo nanoftp.lo valid.lo xlink.lo uri.lo -Wl,-soname -Wl, -o .libs/ /usr/bin/ld: cannot open output file .libs/ : Is a directory collect2: ld returned 1 exit status which should have been: gcc -shared SAX.lo entities.lo encoding.lo error.lo parser.lo parserold.lo HTMLparser.lo HTMLtree.lo debugXML.lo tree.lo xpath.lo xmlIO.lo xmlmemory.lo nanohttp.lo nanoftp.lo valid.lo xlink.lo uri.lo -Wl,-soname -Wl,libxml.so.1 -o .libs/libxml.so.1.8.17 Paul. From mtasaka at ioa.s.u-tokyo.ac.jp Wed May 21 09:43:13 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 21 May 2008 18:43:13 +0900 Subject: Did the "uname" change on ppc64 in Rawhide? In-Reply-To: References: Message-ID: <4833EEB1.80203@ioa.s.u-tokyo.ac.jp> Mary Ellen Foster wrote, at 05/21/2008 06:30 PM +9:00: > I'm trying to figure out why a package that built for F8 and F9 failed > on Rawhide. Here are the logs for the failed Rawhide bid: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=622220 > > In this build, "configure" dies with: > checking build system type... > Invalid configuration `ppc64-redhat-linux-gnu': machine > `ppc64-redhat' not recognized > configure: error: /bin/sh ./config.sub ppc64-redhat-linux-gnu failed > > Whereas on F8 and F9 on PPC64, building the identical SRPM works fine > (http://koji.fedoraproject.org/koji/taskinfo?taskID=622181 and > http://koji.fedoraproject.org/koji/taskinfo?taskID=622176) and the > corresponding output from "configure" in both cases is: > checking build system type... > powerpc64-redhat-linux-gnu > [ ... continue configuring ... ] > > Any suggestions what's going on here? Similar exaple: https://bugzilla.redhat.com/show_bug.cgi?id=434906#c19 https://bugzilla.redhat.com/show_bug.cgi?id=434906#c20 This is because redhat-rpm-config dehavior changed on F-10: * Wed May 07 2008 Jon Masters - 9.0.3-1 - Remove overwritten config.guess|sub files (testing). This affects %configure macro. On F-8/9 %configure replaces config.{sub,guess} in the tarball with /usr/lib/rpm/config.{sub,guess} while on F-10 it does not. Regards, Mamoru From rc040203 at freenet.de Wed May 21 09:44:17 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 21 May 2008 11:44:17 +0200 Subject: Did the "uname" change on ppc64 in Rawhide? In-Reply-To: <4833EDF1.5040908@city-fan.org> References: <4833EDF1.5040908@city-fan.org> Message-ID: <1211363057.26792.1686.camel@beck.corsepiu.local> On Wed, 2008-05-21 at 10:40 +0100, Paul Howarth wrote: > Mary Ellen Foster wrote: > > I'm trying to figure out why a package that built for F8 and F9 failed > > on Rawhide. Here are the logs for the failed Rawhide bid: > > Any suggestions what's going on here? > > Dunno, but I came across this yesterday too. A package that built > everywhere apart from ppc64 (and had built previously on F9) failed on > ppc64: The culprit is upstreams shipping outdated config.guess/config.sub's. AFAICT, until recently, rpmbuild replaced config.guess/config.sub during builts, and now has been changed to use the original files upstreams ship. Ralf From paul at city-fan.org Wed May 21 09:44:42 2008 From: paul at city-fan.org (Paul Howarth) Date: Wed, 21 May 2008 10:44:42 +0100 Subject: Did the "uname" change on ppc64 in Rawhide? In-Reply-To: <1211362749.26792.1680.camel@beck.corsepiu.local> References: <1211362749.26792.1680.camel@beck.corsepiu.local> Message-ID: <4833EF0A.6050103@city-fan.org> Ralf Corsepius wrote: > On Wed, 2008-05-21 at 10:30 +0100, Mary Ellen Foster wrote: >> I'm trying to figure out why a package that built for F8 and F9 failed >> on Rawhide. Here are the logs for the failed Rawhide bid: >> >> http://koji.fedoraproject.org/koji/taskinfo?taskID=622220 >> >> In this build, "configure" dies with: >> checking build system type... >> Invalid configuration `ppc64-redhat-linux-gnu': machine >> `ppc64-redhat' not recognized >> configure: error: /bin/sh ./config.sub ppc64-redhat-linux-gnu failed >> >> Whereas on F8 and F9 on PPC64, building the identical SRPM works fine >> (http://koji.fedoraproject.org/koji/taskinfo?taskID=622181 and >> http://koji.fedoraproject.org/koji/taskinfo?taskID=622176) and the >> corresponding output from "configure" in both cases is: >> checking build system type... >> powerpc64-redhat-linux-gnu >> [ ... continue configuring ... ] >> >> Any suggestions what's going on here? > > Wild guess: Very likely, the package you are trying to build is shipping > a very outdated "config.guess" and/or which doesn't recognize the > triplet (Read: Outdated upstream sources) > > Either replace (patch) the versions of config.guess/config.sub inside of > the tarball with more recent ones, or (better) convince upstream to > update their config.guess/config.sub. Ah, I see. I guess I'll have to do it myself then since there is no active upstream for my compat-type package. Paul. From rjones at redhat.com Wed May 21 10:37:38 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 21 May 2008 11:37:38 +0100 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> Message-ID: <20080521103738.GA3890@amd.home.annexia.org> On Tue, May 20, 2008 at 02:40:13PM -0700, Christopher Stone wrote: > Why the H.E. double hockey sticks do people think proving > compatibility packages for nVidia users will somehow hold the desktop > hostage for everyone else? > > I do not understand why ajax could not provide compatibility rpms for > nVidia users? Is he not paid by redhat? I mean just how difficult > can it be to provide F8 xorg rpms on F9 for nVidia users?? NVidia could completely resolve this issue tomorrow, simply by open sourcing their graphics driver. I suggest you contact them about this. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From paul at city-fan.org Wed May 21 10:46:05 2008 From: paul at city-fan.org (Paul Howarth) Date: Wed, 21 May 2008 11:46:05 +0100 Subject: Did the "uname" change on ppc64 in Rawhide? In-Reply-To: <1211363057.26792.1686.camel@beck.corsepiu.local> References: <4833EDF1.5040908@city-fan.org> <1211363057.26792.1686.camel@beck.corsepiu.local> Message-ID: <4833FD6D.7090508@city-fan.org> Ralf Corsepius wrote: > On Wed, 2008-05-21 at 10:40 +0100, Paul Howarth wrote: >> Mary Ellen Foster wrote: >>> I'm trying to figure out why a package that built for F8 and F9 failed >>> on Rawhide. Here are the logs for the failed Rawhide bid: > >>> Any suggestions what's going on here? >> Dunno, but I came across this yesterday too. A package that built >> everywhere apart from ppc64 (and had built previously on F9) failed on >> ppc64: > > The culprit is upstreams shipping outdated config.guess/config.sub's. > > AFAICT, until recently, rpmbuild replaced config.guess/config.sub during > builts, and now has been changed to use the original files upstreams > ship. Thanks for the info. I see the history behind this in http://bugzilla.redhat.com/211069 and understand why it was done. It's easily enough fixed for ppc64 in my (ancient) package, though I suspect I'm going to need to fix it again for the various secondary architectures at some point. Paul. From ndbecker2 at gmail.com Wed May 21 11:10:09 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Wed, 21 May 2008 07:10:09 -0400 Subject: What provides phonon devel phonon/mediaobject.h Message-ID: XMplayer.h:2:32: error: phonon/mediaobject.h: No such file or directory What provides phonon/mediaobject.h (part of phonon)? From markg85 at gmail.com Wed May 21 11:24:02 2008 From: markg85 at gmail.com (Mark) Date: Wed, 21 May 2008 13:24:02 +0200 Subject: changes at planet fedora In-Reply-To: <4833CFA7.9000703@nigelj.com> References: <1211214812.3095.0.camel@cutter> <6e24a8e80805201301r44a241bdr9b2263052fe1fd8b@mail.gmail.com> <6e24a8e80805201550o12531af3ye6692f9571cb5230@mail.gmail.com> <48335785.4050800@fedoraproject.org> <20080520201228.3dfb45b6@vader.jdub.homelinux.org> <4833CCC3.1050405@nicubunu.ro> <4833CFA7.9000703@nigelj.com> Message-ID: <6e24a8e80805210424nd504e3dxedc5551df2c8896f@mail.gmail.com> 2008/5/21 Nigel Jones : > Nicu Buculei wrote: >> >> Josh Boyer wrote: >>> >>> Rahul Sundaram wrote: >>>> >>>> Planet Fedora is explicitly a aggregation of blogs from official Fedora >>>> contributors who require a Fedora account anyway. What is being done >>> >>> Actually, I don't think that's quite true. There is at least one blog >>> syndicated there that doesn't have a FAS account today. So the FAS >>> requirement is new. > > In fact there are several: > * Fedora Daily Package > * Fedora Indonesia > * Red Hat Magazine > etc etc etc >> >> I asked on the infrastructure list about "policy" and was told there is no >> policy, so my understanding is me, having a FAS account, I am allowed to add >> *multiple* feeds, like one for my personal blog and another for my local >> (Romanian) Fedora community, even if this community is not a FAS account >> owner. >> > But yes, you can have more than one feed per person from my understanding. > > - Nigel That basically that everyone that is a member of FAS becomes something like an Admin on the fedora planet.. they can add as much blogs as they want (and probably remove tthe ones they added as well) which just means he is an admin over the entered blog urls. I find it verry strange if this is what you guys want.. From jamatos at fc.up.pt Wed May 21 11:39:16 2008 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Wed, 21 May 2008 12:39:16 +0100 Subject: What provides phonon devel phonon/mediaobject.h In-Reply-To: References: Message-ID: <200805211239.21038.jamatos@fc.up.pt> On Wednesday 21 May 2008 12:10:09 Neal Becker wrote: > XMplayer.h:2:32: error: phonon/mediaobject.h: No such file or directory > > What provides phonon/mediaobject.h (part of phonon)? kdelibs-devel -- Jos? Ab?lio From kanarip at kanarip.com Wed May 21 11:40:28 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 21 May 2008 13:40:28 +0200 Subject: Recomposing with generic-logos In-Reply-To: <20080519194743.GG27865@nostromo.devel.redhat.com> References: <482FF429.3000005@kanarip.com> <20080519194743.GG27865@nostromo.devel.redhat.com> Message-ID: <48340A2C.9000202@kanarip.com> Bill Nottingham wrote: > Can you compare the package set on the compose? > A `diff -u` of "ls *.rpm" is at http://fpaste.org/paste/2289 A complete diff of the contents of stage2.img is at http://fpaste.org/paste/2290 > By 'result' you mean the installer, not live, correct? What appears > to have happend is you didn't include the @fonts group in your compose, > so you have no fonts for anaconda to use. > result in this case is the installer (images/media), yes. Both composes use external repositories to get the packages needed -as per a backported fix from wwoods-, and hence the package payload in the composed tree isn't as much related to the composing of the installer images anymore. Including @fonts in the package set didn't help. Kind regards, Jeroen van Meeuwen -kanarip From griso.roberto at gmail.com Wed May 21 11:42:55 2008 From: griso.roberto at gmail.com (Roberto Cangiamila) Date: Wed, 21 May 2008 04:42:55 -0700 (PDT) Subject: Invitation to connect on LinkedIn Message-ID: <84827922.1211370175736.JavaMail.app@com07.prod> LinkedIn ------------ Development, I'd like to add you to my professional network on LinkedIn. -Roberto Learn more: https://www.linkedin.com/e/isd/271962718/SFzmaJy7/ ------------------------------------------ What is LinkedIn? Maintain and develop your professional network: Like Roberto Cangiamila, you can stay connected to past and present colleagues and classmates who you respect. ------ (c) 2008, LinkedIn Corporation -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpope at computer.org Wed May 21 11:49:15 2008 From: mpope at computer.org (Michael Pope) Date: Wed, 21 May 2008 21:19:15 +0930 Subject: Xorg 1.5 missed the train? In-Reply-To: <48337D52.7050005@poolshark.org> References: <48334163.4080709@magma.ca> <48337D52.7050005@poolshark.org> Message-ID: <20080521211915.6a23c1c6@malbec.vatican.com.au> On Tue, 20 May 2008 18:39:30 -0700 Denis Leroy quoth: > I'm also hostage to Nvidia's good will... I also. Not happy with nvidia. However here is a small constructive criticism/suggestion for Fedora. F9 Release notes, section 21.3 "Third Party Video Drivers", add: ``As of , the version of xorg in F9 is incompatible with certain third party video drivers, including nvidia .'' That would have saved me a lot of time, and would have been a little more thoughtful without compromising Fedora's strong stance on closed source, which I endorse. Note also, this situation would have been even less painful if xorg-drv-{nv,nouveau} actually worked sensibly even in 2D. #182517 is getting pretty old and #234824 is just painful. Cheers, Mike Pope From rdieter at math.unl.edu Wed May 21 11:55:12 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 21 May 2008 06:55:12 -0500 Subject: Xorg 1.5 missed the train? References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <1211319877.8531.40.camel@localhost.localdomain> <604aa7910805201505m7cc84699p953aa880b7419413@mail.gmail.com> <20080520174855.49dd2154@vader.jdub.homelinux.org> <20080520202404.53258cb9@vader.jdub.homelinux.org> Message-ID: Christopher Stone wrote: > I don't give a hoot if the packages are supported or not, I just want > an easy way to get my nVidia card working. I'm curious, are you being even half as vocal about this to NVidia? -- Rex From billcrawford1970 at gmail.com Wed May 21 12:00:36 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 21 May 2008 13:00:36 +0100 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <604aa7910805201505m7cc84699p953aa880b7419413@mail.gmail.com> <20080520174855.49dd2154@vader.jdub.homelinux.org> <20080520202404.53258cb9@vader.jdub.homelinux.org> <20080520210725.1707cd60@vader.jdub.homelinux.org> Message-ID: <544eb990805210500g14565c4du61fae08f0d9fcbf2@mail.gmail.com> 2008/5/21 Christopher Stone : > I *have* looked at the smolt stats, and they don't make any sense at > all. 1.6% and 1.9%, that doesn't make any sense, the smolt stats have > to be wrong. I'm sure the total number of nVidia and ATI fedora > desktop users is more than 4%. That is less surprising than you might think. All but a handful of the >100 machines in this building shipped with SiS onboard video. A number of us have *added* ATI graphics (in the form of an outdated but well supported PCI Radeon 9250). These cards have been quite well supported (with 3D) for a long, long time. For none of that time has *any* nVidia hardware had a stable, supported "open source" 3D driver. The ATI card has, and it was enabled by ATI providing specs to developers, albeit I am given to understand (correct me if I'm wrong) under an NDA that could not be transferred to others once some of the original developers moved on to other projects. So, to sum up the actual *evidence* in this thread so far: The new X.org server has a new ABI. It isn't going to change when the "magical fairy dust" of the "1.5" version number is applied. Due to his modesty, ajax has not loudly trumpeted the fact he's the one who gets to decide when it's done this time around; if he says version 1.4.1.5.9.26.535.89.79.323846 is ready to ship, it's ready to ship. The (open source) ATI drivers are working, with the new server, because they're a part of the distribution, and one or two people posting on this thread have been involved in updating those drivers to work with the new ABI (and significant new development, too). This was possible because they are, well, open source. The (closed source) nVidia drivers are not. I don't know the status of the closed source ATI drivers, and I don't care too much, because I don't need to use them. However AMD, including one of the developers who works on the open source drivers, is working hard to make open source drivers work for newer cards, and it would appear a lot of progress has been made. This is not to mention Intel (I don't have any Intel graphics here, and I don't think I've ever used any; I've had Cirrus Logic, Savage, Matrox, and several ATI cards including Mach64 of various vintages as well as my current Radeons). The last nVidia hardware I used was a TNT2 in a Dell machine a few jobs back, and that was running NT. Please, stop wingeing and look at the "facts on the ground" as my manager would say :o) From trond.danielsen at gmail.com Wed May 21 12:02:51 2008 From: trond.danielsen at gmail.com (Trond Danielsen) Date: Wed, 21 May 2008 14:02:51 +0200 Subject: changes at planet fedora In-Reply-To: <6e24a8e80805210424nd504e3dxedc5551df2c8896f@mail.gmail.com> References: <1211214812.3095.0.camel@cutter> <6e24a8e80805201301r44a241bdr9b2263052fe1fd8b@mail.gmail.com> <6e24a8e80805201550o12531af3ye6692f9571cb5230@mail.gmail.com> <48335785.4050800@fedoraproject.org> <20080520201228.3dfb45b6@vader.jdub.homelinux.org> <4833CCC3.1050405@nicubunu.ro> <4833CFA7.9000703@nigelj.com> <6e24a8e80805210424nd504e3dxedc5551df2c8896f@mail.gmail.com> Message-ID: <409676c70805210502p8c6d7d9j79df72b6a58948cd@mail.gmail.com> 2008/5/21 Mark : > That basically that everyone that is a member of FAS becomes something > like an Admin on the fedora planet.. they can add as much blogs as > they want (and probably remove tthe ones they added as well) which > just means he is an admin over the entered blog urls. > > I find it verry strange if this is what you guys want.. I find this lack of trust in Fedora contributors very strange; has it not occurred to you that the powers granted by cvs access, bugzilla accounts and mailing list membership can do far more harm to the community than a hostile blog aggregated on planet F? Admins are still around to clear things out if lets say I go mad and start adding all sorts of blogs that post offensive content to planet F, but until then I believe that people who sign up to become a Fedora contributor do it to improve Fedora and not the opposite. Best Regards, -- Trond Danielsen From billcrawford1970 at gmail.com Wed May 21 12:03:11 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 21 May 2008 13:03:11 +0100 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <1218b5bc0805201846v19edd85n3be4b48e3c519428@mail.gmail.com> <1211335226.3768.1.camel@clockmaker.usersys.redhat.com> <20080520211137.67744ac3@vader.jdub.homelinux.org> <48338811.3090700@gmail.com> Message-ID: <544eb990805210503n52412aa7p186bb491ac8f0aee@mail.gmail.com> 2008/5/21 Christopher Stone : > 2008/5/20 David Boles : >> I need this too. So get busy and provide this please. ;-) > > Sure, as soon as I get Ajax's paycheck I'll do his job for him.... I'm sure you'd really enjoy doing backports for RHEL updates ... ;o) ask him about his job sometime :o) From airlied at redhat.com Wed May 21 12:07:08 2008 From: airlied at redhat.com (Dave Airlie) Date: Wed, 21 May 2008 22:07:08 +1000 Subject: Xorg 1.5 missed the train? In-Reply-To: <20080521211915.6a23c1c6@malbec.vatican.com.au> References: <48334163.4080709@magma.ca> <48337D52.7050005@poolshark.org> <20080521211915.6a23c1c6@malbec.vatican.com.au> Message-ID: <1211371628.3207.1.camel@optimus> > > Note also, this situation would have been even less painful if > xorg-drv-{nv,nouveau} actually worked sensibly even in 2D. #182517 is > getting pretty old and #234824 is just painful. > The first is a chipset issue that nvidia have never fixed. It only seems to happen on the 6150s and no fix has ever been sighted. The second bug should be fixed in the rawhide nouveau package, which I'll push into F9 at some point soon, randr should be enabled by default now so we actually use the hardware instead of just doing what the BIOS told us to do. I meant to enable randr12 by default for F9, but I messed up :-(. I'll fix this soon. Dave. From foster at in.tum.de Wed May 21 12:07:27 2008 From: foster at in.tum.de (Mary Ellen Foster) Date: Wed, 21 May 2008 13:07:27 +0100 Subject: Did the "uname" change on ppc64 in Rawhide? In-Reply-To: <4833FD6D.7090508@city-fan.org> References: <4833EDF1.5040908@city-fan.org> <1211363057.26792.1686.camel@beck.corsepiu.local> <4833FD6D.7090508@city-fan.org> Message-ID: 2008/5/21 Paul Howarth : > Thanks for the info. I see the history behind this in > http://bugzilla.redhat.com/211069 and understand why it was done. It's > easily enough fixed for ppc64 in my (ancient) package, though I suspect I'm > going to need to fix it again for the various secondary architectures at > some point. Thankfully, the issue has already (!!!) been fixed upstream for the package I was concerned about -- http://gollem.science.uva.nl/bugzilla/show_bug.cgi?id=357 I wonder how many other packages will be bitten by this change in rpmbuild; I guess that's the point of Rawhide, though. :) MEF -- Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/ Informatik 6: Robotics and Embedded Systems, Technische Universit?t M?nchen and ICCS, School of Informatics, University of Edinburgh From billcrawford1970 at gmail.com Wed May 21 12:08:00 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 21 May 2008 13:08:00 +0100 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <1211335226.3768.1.camel@clockmaker.usersys.redhat.com> <20080520211137.67744ac3@vader.jdub.homelinux.org> <48338811.3090700@gmail.com> <48338D79.9020304@gmail.com> Message-ID: <544eb990805210508l60209e27pbb5541a9c26d1dfd@mail.gmail.com> 2008/5/21 Christopher Stone : > But isn't packaging part of his responsibilities? It just seems to me > that an upgrade path for nVidia users could be provided without much > extra effort. You're asking for a *downgrade* of Xorg to support them :o) From billcrawford1970 at gmail.com Wed May 21 12:11:29 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 21 May 2008 13:11:29 +0100 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <48338811.3090700@gmail.com> <48338D79.9020304@gmail.com> <20080520220210.77f97a82@vader.jdub.homelinux.org> <1211340916.3307.2.camel@clockmaker.usersys.redhat.com> Message-ID: <544eb990805210511i6a5079c1sb683d1f028b9360a@mail.gmail.com> 2008/5/21 Christopher Stone : > I think you are missing the point. Just because nVidia sucks, it > doesn't mean we have to make Fedora "suck". This is linux, and it > should be possible to have a system which everyone can enjoy. With > just a little bit of extra effort, a set of stable xorg rpms could > have been provided in a f9 testing repo for nVidia users to use > temporarily. We can still make a distro which is friendly to nVidia > users without slowing down progress for everyone else. I see this > mainly as a user friendliness issue more than an open source vs closed > source issue. I hope Josh is correct and we will have some nVidia > drivers to test with soon. How is providing a new, shiny Xorg making Fedora "suck", please? There is a set of stable xorg rpms; it's in /pub/fedora/linux/updates/8/ ... From ezigler at gmail.com Wed May 21 12:12:26 2008 From: ezigler at gmail.com (Erich Zigler) Date: Wed, 21 May 2008 07:12:26 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: <4833BFD2.4070901@gmail.com> References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <1211319877.8531.40.camel@localhost.localdomain> <604aa7910805201505m7cc84699p953aa880b7419413@mail.gmail.com> <604aa7910805201514h4535567atd4e7c6c67bb74a84@mail.gmail.com> <54216.75.164.221.130.1211322252.squirrel@clueserver.org> <4833BFD2.4070901@gmail.com> Message-ID: On Wed, May 21, 2008 at 1:23 AM, Andrew Farris wrote: > Had Fedora not released with the new Xorg > ABI nvidia would probably still not be actively working on it yet. Actually development looks like it started before Fedora 9 released: http://www.nvnews.net/vbulletin/showthread.php?t=111460 From rawhide at fedoraproject.org Wed May 21 12:31:09 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Wed, 21 May 2008 12:31:09 +0000 (UTC) Subject: rawhide report: 20080521 changes Message-ID: <20080521123109.1EAA6209D2B@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080520/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080521/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package Falcon The Falcon Programming Language New package libx86 Library for making real-mode x86 calls New package emotion An Evas smart-object library providing video capabilities New package compat-guichan06 Compatibility libraries for guichan 0.6 New package email2trac Utilities for converting emails to trac tickets New package clustermon Monitoring and management of Red Hat Enterprise Linux Cluster Suite New package GMT-doc Documentation for Generic Mapping Tools New package figtoipe FIG to IPE conversion tool New package virt-top Utility like top(1) for displaying virtualization stats New package R-zoo Z's ordered observations for irregular time series New package wgrib2 Manipulate, inventory and decode GRIB2 files New package ricci Remote Cluster and Storage Management System New package cluster Red Hat Cluster New package GMT Generic Mapping Tools New package beecrypt An open source cryptography library Removed package cman Removed package gfs2-utils Removed package rgmanager Updated Packages: gnome-power-manager-2.23.1-2.fc10 --------------------------------- * Tue May 20 18:00:00 2008 Richard Hughes - 2.23.1-2 - Add a BR on Policykit-gnome * Tue May 20 18:00:00 2008 Richard Hughes - 2.23.1-1 - Update to 2.23.1 * Fri May 16 18:00:00 2008 Richard Hughes - 2.22.1-3 - Add a BR on unique to make the client tools single instance * Sun Apr 13 18:00:00 2008 Richard Hughes - 2.22.1-2 - Fix the homepage URL to http://www.gnome.org/projects/gnome-power-manager/ Broken deps for i386 ---------------------------------------------------------- LabPlot-1.5.1.6-4.fc8.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libMagick.so.10 basket-kontact-1.0.2-5.fc9.i386 requires libkpinterfaces.so.1 basket-kontact-1.0.2-5.fc9.i386 requires libkcal.so.2 basket-kontact-1.0.2-5.fc9.i386 requires libktnef.so.1 basket-kontact-1.0.2-5.fc9.i386 requires kdepim3 basket-kontact-1.0.2-5.fc9.i386 requires libkdepim.so.1 conduit-0.3.10-1.fc10.noarch requires gnome-python-desktop conduit-0.3.10-1.fc10.noarch requires gnome-python-extras epsilon-0.3.0.012-3.fc10.i386 requires libecore_directfb.so.0 epsilon-xine-0.3.0.012-3.fc10.i386 requires libecore_directfb.so.0 evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.i386 requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-1.2.so.11 kismet-extras-0.0.2007.10.R1-3.fc9.i386 requires libMagick.so.10 koffice-karbon-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-karbon-1.6.3-15.fc9.i386 requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libMagick.so.10 libopensync-plugin-kdepim-0.35-2.fc9.i386 requires libkcal.so.2 lsvpd-1.6.4-1.fc10.i386 requires libvpd_cxx-2.0.so.1 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) qgis-0.9.1-5.fc9.i386 requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.i386 requires libgeos.so.2 smart-0.52-54.fc9.i386 requires smart-config taskjuggler-2.4.1-1.fc10.i386 requires libkcal.so.2 taskjuggler-2.4.1-1.fc10.i386 requires libktnef.so.1 taskjuggler-libs-2.4.1-1.fc10.i386 requires libkcal.so.2 tellico-1.3.1-1.fc9.i386 requires libkcal.so.2 tellico-1.3.1-1.fc9.i386 requires libktnef.so.1 totem-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 totem-mozplugin-2.23.2-2.fc9.i386 requires libtotem-plparser-mini.so.10 totem-mozplugin-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 totem-nautilus-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 Broken deps for x86_64 ---------------------------------------------------------- LabPlot-1.5.1.6-4.fc8.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libMagick.so.10 LabPlot-1.5.1.6-4.fc8.x86_64 requires libMagick++.so.10()(64bit) LabPlot-1.5.1.6-4.fc8.x86_64 requires libMagick.so.10()(64bit) LabPlot-1.5.1.6-4.fc8.x86_64 requires libWand.so.10()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires libkcal.so.2()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires libkdepim.so.1()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires libktnef.so.1()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires kdepim3 basket-kontact-1.0.2-5.fc9.x86_64 requires libkpinterfaces.so.1()(64bit) conduit-0.3.10-1.fc10.noarch requires gnome-python-desktop conduit-0.3.10-1.fc10.noarch requires gnome-python-extras epsilon-0.3.0.012-3.fc10.i386 requires libecore_directfb.so.0 epsilon-0.3.0.012-3.fc10.x86_64 requires libecore_directfb.so.0()(64bit) epsilon-xine-0.3.0.012-3.fc10.x86_64 requires libecore_directfb.so.0()(64bit) evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libWand.so.10()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx kismet-extras-0.0.2007.10.R1-3.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.x86_64 requires libWand.so.10()(64bit) koffice-libs-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.x86_64 requires libWand.so.10()(64bit) libopensync-plugin-kdepim-0.35-2.fc9.x86_64 requires libkcal.so.2()(64bit) lsvpd-1.6.4-1.fc10.x86_64 requires libvpd_cxx-2.0.so.1()(64bit) perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) qgis-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) smart-0.52-54.fc9.x86_64 requires smart-config taskjuggler-2.4.1-1.fc10.x86_64 requires libkcal.so.2()(64bit) taskjuggler-2.4.1-1.fc10.x86_64 requires libktnef.so.1()(64bit) taskjuggler-libs-2.4.1-1.fc10.i386 requires libkcal.so.2 taskjuggler-libs-2.4.1-1.fc10.x86_64 requires libkcal.so.2()(64bit) tellico-1.3.1-1.fc9.x86_64 requires libkcal.so.2()(64bit) tellico-1.3.1-1.fc9.x86_64 requires libktnef.so.1()(64bit) totem-2.23.2-2.fc9.i386 requires libtotem-plparser.so.10 totem-2.23.2-2.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.x86_64 requires libtotem-plparser-mini.so.10()(64bit) totem-nautilus-2.23.2-2.fc9.x86_64 requires libtotem-plparser.so.10()(64bit) Broken deps for ppc ---------------------------------------------------------- LabPlot-1.5.1.6-4.fc8.ppc requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.ppc requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.ppc requires libMagick.so.10 basket-kontact-1.0.2-5.fc9.ppc requires libkpinterfaces.so.1 basket-kontact-1.0.2-5.fc9.ppc requires libkcal.so.2 basket-kontact-1.0.2-5.fc9.ppc requires libktnef.so.1 basket-kontact-1.0.2-5.fc9.ppc requires kdepim3 basket-kontact-1.0.2-5.fc9.ppc requires libkdepim.so.1 conduit-0.3.10-1.fc10.noarch requires gnome-python-desktop conduit-0.3.10-1.fc10.noarch requires gnome-python-extras epsilon-0.3.0.012-3.fc10.ppc requires libecore_directfb.so.0 epsilon-0.3.0.012-3.fc10.ppc64 requires libecore_directfb.so.0()(64bit) epsilon-xine-0.3.0.012-3.fc10.ppc requires libecore_directfb.so.0 evolution-brutus-1.2.11-2.fc9.ppc requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.ppc requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.ppc requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.ppc requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-1.2.so.11 kismet-extras-0.0.2007.10.R1-3.fc9.ppc requires libMagick.so.10 koffice-karbon-1.6.3-15.fc9.ppc requires libWand.so.10 koffice-karbon-1.6.3-15.fc9.ppc requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.ppc requires libWand.so.10 koffice-libs-1.6.3-15.fc9.ppc requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) libopensync-plugin-kdepim-0.35-2.fc9.ppc requires libkcal.so.2 lsvpd-1.6.4-1.fc10.ppc requires libvpd_cxx-2.0.so.1 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) qgis-0.9.1-5.fc9.ppc requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.ppc requires libgeos.so.2 smart-0.52-54.fc9.ppc requires smart-config taskjuggler-2.4.1-1.fc10.ppc requires libkcal.so.2 taskjuggler-2.4.1-1.fc10.ppc requires libktnef.so.1 taskjuggler-libs-2.4.1-1.fc10.ppc requires libkcal.so.2 taskjuggler-libs-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) tellico-1.3.1-1.fc9.ppc requires libkcal.so.2 tellico-1.3.1-1.fc9.ppc requires libktnef.so.1 totem-2.23.2-2.fc9.ppc requires libtotem-plparser.so.10 totem-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.ppc requires libtotem-plparser-mini.so.10 totem-mozplugin-2.23.2-2.fc9.ppc requires libtotem-plparser.so.10 totem-nautilus-2.23.2-2.fc9.ppc requires libtotem-plparser.so.10 Broken deps for ppc64 ---------------------------------------------------------- basket-kontact-1.0.2-5.fc9.ppc64 requires libkcal.so.2()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires libkdepim.so.1()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires libktnef.so.1()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires kdepim3 basket-kontact-1.0.2-5.fc9.ppc64 requires libkpinterfaces.so.1()(64bit) conduit-0.3.10-1.fc10.noarch requires gnome-python-desktop conduit-0.3.10-1.fc10.noarch requires gnome-python-extras epsilon-0.3.0.012-3.fc10.ppc64 requires libecore_directfb.so.0()(64bit) epsilon-xine-0.3.0.012-3.fc10.ppc64 requires libecore_directfb.so.0()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) kismet-extras-0.0.2007.10.R1-3.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) libopensync-plugin-kdepim-0.35-2.fc9.ppc64 requires libkcal.so.2()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot lsvpd-1.6.4-1.fc10.ppc64 requires libvpd_cxx-2.0.so.1()(64bit) perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot qgis-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) smart-0.52-54.fc9.ppc64 requires smart-config taskjuggler-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) taskjuggler-2.4.1-1.fc10.ppc64 requires libktnef.so.1()(64bit) taskjuggler-libs-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) tellico-1.3.1-1.fc9.ppc64 requires libkcal.so.2()(64bit) tellico-1.3.1-1.fc9.ppc64 requires libktnef.so.1()(64bit) totem-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) totem-mozplugin-2.23.2-2.fc9.ppc64 requires libtotem-plparser-mini.so.10()(64bit) totem-nautilus-2.23.2-2.fc9.ppc64 requires libtotem-plparser.so.10()(64bit) From nicolas.mailhot at laposte.net Wed May 21 12:42:28 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 21 May 2008 14:42:28 +0200 (CEST) Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <1211319877.8531.40.camel@localhost.localdomain> Message-ID: <43062.192.54.193.52.1211373748.squirrel@rousalka.dyndns.org> Le Mar 20 mai 2008 23:51, Christopher Stone a ?crit : > 2008/5/20 Jesse Keating : >> On Tue, 2008-05-20 at 14:40 -0700, Christopher Stone wrote: >> Two xservers is just insanity. Those on nvidia can choose between >> using >> the nv driver in F9, or continuing to use F8 until Nvidia gets their >> act >> together. The price you pay... > > Until nVidia gets their act together?? What the H.E. double hockey > sticks are you talking about? nVidia can't do anything until xorg's > ABI is *stable*. They cannot keep chasing a moving target When nvidia decided to go the proprietary closed driver route, they *chose* to keep chasing a moving target. If they don't chase is properly complain to nvidia. Either they work within xorg as FLOSS and get updated with the rest of xorg, or they work outside xorg and have to follow xorg changes by themselves. -- Nicolas Mailhot From gilboad at gmail.com Wed May 21 12:46:48 2008 From: gilboad at gmail.com (Gilboa Davara) Date: Wed, 21 May 2008 15:46:48 +0300 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <1211319877.8531.40.camel@localhost.localdomain> <604aa7910805201505m7cc84699p953aa880b7419413@mail.gmail.com> <20080520174855.49dd2154@vader.jdub.homelinux.org> Message-ID: <1211374008.1249.13.camel@gilboa-home-dev.localdomain> On Tue, 2008-05-20 at 15:54 -0700, Christopher Stone wrote: > According to this thread it seems pretty simple actually: > > http://www.fedoraforum.org/forum/showthread.php?t=188645 > > If redhat wants to pay me $100k a year, I'll happily make xorg compat > rpms in about one day. Thank you very much. Personal suggestion: Given the fact that you posts are archived, and can be found by, say, your next employer, I'd think twice before making an ass of myself in public. - Gilboa From lesmikesell at gmail.com Wed May 21 12:52:34 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 21 May 2008 07:52:34 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: <20080521091906.GA3918@orient.maison.lan> References: <20080520215909.GF12622@inocybe.teonanacatl.org> <48334E0E.7090803@gmail.com> <48334F03.6070203@fedoraproject.org> <35207.75.164.221.130.1211322487.squirrel@clueserver.org> <1218b5bc0805201625p21ba80b9y9cffd6eeb7fcec9b@mail.gmail.com> <48335FC0.2070806@gmail.com> <4833C117.5090007@gmail.com> <4833C4B9.3020105@gmail.com> <1218b5bc0805210138l4b508c05x6dc1d90fca9b25e3@mail.gmail.com> <20080521091906.GA3918@orient.maison.lan> Message-ID: <48341B12.7020106@gmail.com> Emmanuel Seyman wrote: > * Callum Lerwick [21/05/2008 11:03] : >> I like how in these threads it keeps conveniently being ignored that we work >> just fine out of the box on Nvidia. We just don't have 3D yet. > > I've always being surprised at the amount of blame-shifting that occurs > in regards to Nvidia's drivers. > > - The free drivers suck. This apparently isn't NVidia's fault (which is > strange since they help maintain it) but the x.org developers'. Yet everyone here keeps saying something better would happen if only the proprietary driver were free. > - The non-free drivers aren't free. This apparently isn't NVidia's fault. There are such things as non disclosure agreements that can prevent publishing information. Why shouldn't you respect their legal obligations? > - This makes the drivers impossible to ship as part of the distribution > or support as a third-party repo. This is somehow the distribution's > fault. The binaries permit redistribution. How does that make it impossible to have in a repository? > - They don't release drivers once the ABI is frozen or even the day > stable releases of x.org are issued. This apparently isn't their fault. This seems to be speculation, seeing as how we don't have a release and the xorg drivers were done before they told anyone else the interface was stable. > - They won't release the specs. This apparently isn't their fault. It may be legal commitments - but its their right either way and not really anyone else's business. > - They badmouth the open source developement model. I have no idea why > but this isn't their fault. Open source is probably a tiny part of their business. The stuff seems OK on a Mac and I haven't seen this kind of complaint about Solaris which uses essentially the same driver. But perhaps they do a better job of coordinating their releases so all the needed components are ready before users have to deal with it. -- Les Mikesell lesmikesell at gmail.com From cmadams at hiwaay.net Wed May 21 12:54:28 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 21 May 2008 07:54:28 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <1211343191.3682.9.camel@clockmaker.usersys.redhat.com> <200805202124.20893.konrad@tylerc.org> <20080521044044.GA1467773@hiwaay.net> Message-ID: <20080521125428.GA1093879@hiwaay.net> Once upon a time, Christopher Stone said: > On Tue, May 20, 2008 at 9:40 PM, Chris Adams wrote: > > Once upon a time, Christopher Stone said: > >> Such a small amount of effort to make > >> the distro user friendly for everyone, > > > > Repeating that over and over does not make it any more true. > > So, you are agreeing that it is true. Do you have a reading comprehension problem? No, it is NOT true; it is not "a small amount of effort". -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From lesmikesell at gmail.com Wed May 21 12:59:33 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 21 May 2008 07:59:33 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: <4833CE6E.8070107@gmail.com> References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <20080520215909.GF12622@inocybe.teonanacatl.org> <48334E0E.7090803@gmail.com> <48334F03.6070203@fedoraproject.org> <35207.75.164.221.130.1211322487.squirrel@clueserver.org> <1218b5bc0805201625p21ba80b9y9cffd6eeb7fcec9b@mail.gmail.com> <48335FC0.2070806@gmail.com> <4833C117.5090007@gmail.com> <4833C4B9.3020105@gmail.com> <4833CE6E.8070107@gmail.com> Message-ID: <48341CB5.7000506@gmail.com> Andrew Farris wrote: > >>>> Please post that on the http://fedoraproject.org/ page so everyone >>>> will understand what to expect. >>> >>> "Fedora is a Linux-based operating system that showcases the latest >>> in free and open source software." >>> >>> "The Fedora Project is out front for you, leading the advancement of >>> free, open software and content." >>> >>> If that is ambiguous you're not really reading very clearly. How >>> else are you going to interpret a purpose to showcase, lead, and >>> advance... >> >> If I wanted to showcase something, I'd make an effort to make sure it >> worked on popular hardware and with other popular software at its >> release. I don't think that's descriptive at all. > > All goals are not always harmonious with each other either. Agreed - which is why I think you should make it more clear to new users that they should not expect fedora to work as a general purpose OS running 3rd party software without problems and even the included software is often pre-release versions. -- Les Mikesell lesmikesell at gmail.com From gilboad at gmail.com Wed May 21 13:08:27 2008 From: gilboad at gmail.com (Gilboa Davara) Date: Wed, 21 May 2008 16:08:27 +0300 Subject: Xorg 1.5 missed the train? In-Reply-To: <20080521091906.GA3918@orient.maison.lan> References: <20080520215909.GF12622@inocybe.teonanacatl.org> <48334E0E.7090803@gmail.com> <48334F03.6070203@fedoraproject.org> <35207.75.164.221.130.1211322487.squirrel@clueserver.org> <1218b5bc0805201625p21ba80b9y9cffd6eeb7fcec9b@mail.gmail.com> <48335FC0.2070806@gmail.com> <4833C117.5090007@gmail.com> <4833C4B9.3020105@gmail.com> <1218b5bc0805210138l4b508c05x6dc1d90fca9b25e3@mail.gmail.com> <20080521091906.GA3918@orient.maison.lan> Message-ID: <1211375307.1249.35.camel@gilboa-home-dev.localdomain> On Wed, 2008-05-21 at 11:19 +0200, Emmanuel Seyman wrote: > * Callum Lerwick [21/05/2008 11:03] : > > > > I like how in these threads it keeps conveniently being ignored that we work > > just fine out of the box on Nvidia. We just don't have 3D yet. > > I've always being surprised at the amount of blame-shifting that occurs > in regards to Nvidia's drivers. > > - The free drivers suck. This apparently isn't NVidia's fault (which is > strange since they help maintain it) but the x.org developers'. Say what? Are you kidding me? Ever tried to write/update/maintain a driver with no documentation? Most of the work on the nv driver is being done by nVidia personal mostly because they are the only ones that have any idea what's going on with their own hardware. Just look at this Changelog! [1] > - The non-free drivers aren't free. This apparently isn't NVidia's fault. I'm well aware of the OpenGL licensing problem that killed the OSS 3.x driver and Intel/Microsoft C&D letters. Never the less, nothing stops nVidia from doing an "AMD" and releasing all the specs. > - This makes the drivers impossible to ship as part of the distribution > or support as a third-party repo. This is somehow the distribution's > fault. Wrong again. Two things. A. ANAL, but AFAIK, by releasing binary drivers nVidia is dangerously close to violating of the GPLv2 license under which the Linux kernel is distributed. (AKA derived work). AFAIK, this alone stops most of the big distributions from shipping binary drivers. B. Fedora has a policy of shipping only open source drivers and software. If you disagree with this policy, you're using the wrong distribution. > - They don't release drivers once the ABI is frozen or even the day > stable releases of x.org are issued. This apparently isn't their fault. No. nVidia has right to decide what to support and when. If I, as a client, disagrees with their policy, I -should- look elsewhere. (And I am, trust me.) However, given that fact that nVidia is more or less maintaining the nv driver, they should have been well aware when the ABI got frozen. > - They won't release the specs. This apparently isn't their fault. Are you just guessing? Or do you have solid proof to back this claim? More-ever, how both AMD and Intel found a way to release the specs without hitting the same roadblock? > - They badmouth the open source developement model. I have no idea why > but this isn't their fault. Badmouth the OSS development model? Isn't their fault? I don't think it means what you think you means [2]. > > Emmanuel > - Gilboa [1] http://webcvs.freedesktop.org/xorg/driver/xf86-video-nv/ChangeLog?revision=1.18&view=markup [2] http://www.youtube.com/watch?v=G2y8Sx4B2Sk From lesmikesell at gmail.com Wed May 21 13:11:12 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 21 May 2008 08:11:12 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: <544eb990805210511i6a5079c1sb683d1f028b9360a@mail.gmail.com> References: <48334163.4080709@magma.ca> <48338811.3090700@gmail.com> <48338D79.9020304@gmail.com> <20080520220210.77f97a82@vader.jdub.homelinux.org> <1211340916.3307.2.camel@clockmaker.usersys.redhat.com> <544eb990805210511i6a5079c1sb683d1f028b9360a@mail.gmail.com> Message-ID: <48341F70.4010902@gmail.com> Bill Crawford wrote: >> I think you are missing the point. Just because nVidia sucks, it >> doesn't mean we have to make Fedora "suck". This is linux, and it >> should be possible to have a system which everyone can enjoy. With >> just a little bit of extra effort, a set of stable xorg rpms could >> have been provided in a f9 testing repo for nVidia users to use >> temporarily. We can still make a distro which is friendly to nVidia >> users without slowing down progress for everyone else. I see this >> mainly as a user friendliness issue more than an open source vs closed >> source issue. I hope Josh is correct and we will have some nVidia >> drivers to test with soon. > > How is providing a new, shiny Xorg making Fedora "suck", please? It's all about interfaces, which are what permit programs to work together at all. They are contracts among cooperating programmers that when changed break everyone else's work and components. Changing an interface generally sucks, but shipping a freshly changed interface without publishing the new definition and giving cooperating entities time to re-do their work to match sucks even more. -- Les Mikesell lesmikesell at gmail.com From dev at nigelj.com Wed May 21 13:17:04 2008 From: dev at nigelj.com (Nigel Jones) Date: Thu, 22 May 2008 01:17:04 +1200 Subject: Xorg 1.5 missed the train? In-Reply-To: <1211375307.1249.35.camel@gilboa-home-dev.localdomain> References: <20080520215909.GF12622@inocybe.teonanacatl.org> <48334E0E.7090803@gmail.com> <48334F03.6070203@fedoraproject.org> <35207.75.164.221.130.1211322487.squirrel@clueserver.org> <1218b5bc0805201625p21ba80b9y9cffd6eeb7fcec9b@mail.gmail.com> <48335FC0.2070806@gmail.com> <4833C117.5090007@gmail.com> <4833C4B9.3020105@gmail.com> <1218b5bc0805210138l4b508c05x6dc1d90fca9b25e3@mail.gmail.com> <20080521091906.GA3918@orient.maison.lan> <1211375307.1249.35.camel@gilboa-home-dev.localdomain> Message-ID: <483420D0.7040008@nigelj.com> Gilboa Davara wrote: > On Wed, 2008-05-21 at 11:19 +0200, Emmanuel Seyman wrote: > >> * Callum Lerwick [21/05/2008 11:03] : >> >>> I like how in these threads it keeps conveniently being ignored that we work >>> just fine out of the box on Nvidia. We just don't have 3D yet. >>> >> I've always being surprised at the amount of blame-shifting that occurs >> in regards to Nvidia's drivers. >> >> - The free drivers suck. This apparently isn't NVidia's fault (which is >> strange since they help maintain it) but the x.org developers'. >> > > Say what? Are you kidding me? > Ever tried to write/update/maintain a driver with no documentation? > Most of the work on the nv driver is being done by nVidia personal > mostly because they are the only ones that have any idea what's going on > with their own hardware. > Just look at this Changelog! [1] > Note the use of *apparently* you seem to have taken Emmanuel's comments out of context, in my opinion it was 99% sarcastic... nVidia have tried to blame everything on XOrg and "other people" which is exactly what is outlined in Emmanuel's e-mail. - Nigel From cmadams at hiwaay.net Wed May 21 13:18:20 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 21 May 2008 08:18:20 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: <48341F70.4010902@gmail.com> References: <48338811.3090700@gmail.com> <48338D79.9020304@gmail.com> <20080520220210.77f97a82@vader.jdub.homelinux.org> <1211340916.3307.2.camel@clockmaker.usersys.redhat.com> <544eb990805210511i6a5079c1sb683d1f028b9360a@mail.gmail.com> <48341F70.4010902@gmail.com> Message-ID: <20080521131820.GC1093879@hiwaay.net> Once upon a time, Les Mikesell said: > It's all about interfaces, which are what permit programs to work > together at all. They are contracts among cooperating programmers that > when changed break everyone else's work and components. Changing an > interface generally sucks, but shipping a freshly changed interface > without publishing the new definition and giving cooperating entities > time to re-do their work to match sucks even more. Yeah, because you know, Fedora and X.org keep everything in hiding and never let any bits out until they are released. Also, they never tell anyone what they are doing. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From gilboad at gmail.com Wed May 21 13:23:02 2008 From: gilboad at gmail.com (Gilboa Davara) Date: Wed, 21 May 2008 16:23:02 +0300 Subject: Xorg 1.5 missed the train? In-Reply-To: <1218b5bc0805201846v19edd85n3be4b48e3c519428@mail.gmail.com> References: <48334163.4080709@magma.ca> <1211319877.8531.40.camel@localhost.localdomain> <604aa7910805201505m7cc84699p953aa880b7419413@mail.gmail.com> <20080520174855.49dd2154@vader.jdub.homelinux.org> <20080520202404.53258cb9@vader.jdub.homelinux.org> <1218b5bc0805201846v19edd85n3be4b48e3c519428@mail.gmail.com> Message-ID: <1211376182.1249.43.camel@gilboa-home-dev.localdomain> On Tue, 2008-05-20 at 20:46 -0500, Callum Lerwick wrote: > Allow me to translate: > > On Tue, May 20, 2008 at 8:38 PM, Christopher Stone > wrote: > I don't give a hoot if the packages are supported or not, I > just want > an easy way to get my nVidia card working. All you people do > is gripe > and moan about how much work it would be and all this and > that. Look, > its just a matter of adding rpms to a repo, make an > "unsupported" repo > if you have to. The bottom line is you want to have as many > people > testing the OS as possible. > > I want a pony. > > > And obviously ajax does not care about 50% of Fedora's user > base. It > would seem to me that he is not being a good maintainer, I > hope he > raises his kids better than he maintains xorg. > > > Ajax is a poopy-head who won't give me a pony. > > I believe you have no idea what you are talking about. If I > maintained a package which I knew was not going to work with > 50% of > the users hardware, and I was being paid to maintain this > package, > then I certainly would spend some time to allow those 50% a > way to use > their hardware with the rest of the OS. Nothing more to it > than that, > it has nothing to do with open source, it has everything to do > with > being professional. > > If *I* were Ajax I'd give me a pony! /* There goes my coffee (through the nose...) */ - Gilboa From gilboad at gmail.com Wed May 21 13:23:40 2008 From: gilboad at gmail.com (Gilboa Davara) Date: Wed, 21 May 2008 16:23:40 +0300 Subject: Xorg 1.5 missed the train? In-Reply-To: <483420D0.7040008@nigelj.com> References: <20080520215909.GF12622@inocybe.teonanacatl.org> <48334E0E.7090803@gmail.com> <48334F03.6070203@fedoraproject.org> <35207.75.164.221.130.1211322487.squirrel@clueserver.org> <1218b5bc0805201625p21ba80b9y9cffd6eeb7fcec9b@mail.gmail.com> <48335FC0.2070806@gmail.com> <4833C117.5090007@gmail.com> <4833C4B9.3020105@gmail.com> <1218b5bc0805210138l4b508c05x6dc1d90fca9b25e3@mail.gmail.com> <20080521091906.GA3918@orient.maison.lan> <1211375307.1249.35.camel@gilboa-home-dev.localdomain> <483420D0.7040008@nigelj.com> Message-ID: <1211376220.1249.44.camel@gilboa-home-dev.localdomain> On Thu, 2008-05-22 at 01:17 +1200, Nigel Jones wrote: > Gilboa Davara wrote: > > On Wed, 2008-05-21 at 11:19 +0200, Emmanuel Seyman wrote: > > > >> * Callum Lerwick [21/05/2008 11:03] : > >> > >>> I like how in these threads it keeps conveniently being ignored that we work > >>> just fine out of the box on Nvidia. We just don't have 3D yet. > >>> > >> I've always being surprised at the amount of blame-shifting that occurs > >> in regards to Nvidia's drivers. > >> > >> - The free drivers suck. This apparently isn't NVidia's fault (which is > >> strange since they help maintain it) but the x.org developers'. > >> > > > > Say what? Are you kidding me? > > Ever tried to write/update/maintain a driver with no documentation? > > Most of the work on the nv driver is being done by nVidia personal > > mostly because they are the only ones that have any idea what's going on > > with their own hardware. > > Just look at this Changelog! [1] > > > Note the use of *apparently* you seem to have taken Emmanuel's comments > out of context, in my opinion it was 99% sarcastic... > > nVidia have tried to blame everything on XOrg and "other people" which > is exactly what is outlined in Emmanuel's e-mail. > > - Nigel > In this case, I stand corrected, ashamed, in the corner :) - Gilboa From dimi at lattica.com Wed May 21 13:25:41 2008 From: dimi at lattica.com (Dimi Paun) Date: Wed, 21 May 2008 09:25:41 -0400 Subject: Glitch-Free PulseAudio in Rawhide In-Reply-To: <20080520105304.GC13762@tango.0pointer.de> References: <20080517101616.GA16071@tango.0pointer.de> <20080518200225.GC19530@tango.0pointer.de> <1211260283.6534.46.camel@dimi.lattica.com> <20080520105304.GC13762@tango.0pointer.de> Message-ID: <1211376341.28707.19.camel@dimi.lattica.com> On Tue, 2008-05-20 at 12:53 +0200, Lennart Poettering wrote: > > * Volume Control gives a cryptic error about a connection being lost > > Is it really that cryptic? It says exactly what happened: the > connection to the sound server is lost. It is completely irrelevant that this is exactly what happens. In fact, you could say that "a number of bytes don't reach a process via file descriptor 7" and it would be exactly what happens, all at the same time being a cryptic and bad error message. Do you really think a non technical user knows what a "server" is, especially in this context? If you are tempted to reply yes, don't bother, it Just Plain Wrong (TM). > > * Unless you know (how?!?) that you need a 'pulseaudio -D', you > > have to reboot the machine to get working sound > > I guess that's something one could say about 99% of all bugs. Not by a long shot. If an app crashes, _anybody_ knows to restart it. On this other hand, sound is a system feature that must work. The fact that it doesn't without frequent reboots reflects a design problem -- sound must restart automagically, not require the user to reboot every hour or so to recover this essential desktop feature! For fsck's sake, I didn't have to reboot Windows 3.1 that often! -- Dimi Paun Lattica, Inc. From billcrawford1970 at gmail.com Wed May 21 13:41:59 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 21 May 2008 14:41:59 +0100 Subject: Xorg 1.5 missed the train? In-Reply-To: <48341B12.7020106@gmail.com> References: <48334F03.6070203@fedoraproject.org> <35207.75.164.221.130.1211322487.squirrel@clueserver.org> <1218b5bc0805201625p21ba80b9y9cffd6eeb7fcec9b@mail.gmail.com> <48335FC0.2070806@gmail.com> <4833C117.5090007@gmail.com> <4833C4B9.3020105@gmail.com> <1218b5bc0805210138l4b508c05x6dc1d90fca9b25e3@mail.gmail.com> <20080521091906.GA3918@orient.maison.lan> <48341B12.7020106@gmail.com> Message-ID: <544eb990805210641u4b8c7d91h6285c186c75126de@mail.gmail.com> 2008/5/21 Les Mikesell : > There are such things as non disclosure agreements that can prevent > publishing information. Why shouldn't you respect their legal obligations? We're not saying they shouldn't. I am tempted to suggest they shouldn't enter into those in the first place, that would be a large can of worms though and we don't want to open another one of those while we still have a large number of nematodes wriggling away in this thread. > The binaries permit redistribution. How does that make it impossible to > have in a repository? Again, that's not the issue; the problem is that even when they *are* in a repository, they don't work with the current X.org. I see at least two popular third party repositories that do carry both the nVidia and the ATI proprietary drivers; why are there so few complaints from the ATI users about this state of affairs? > This seems to be speculation, seeing as how we don't have a release and the > xorg drivers were done before they told anyone else the interface was > stable. OK, so F9 is now not a release? > It may be legal commitments - but its their right either way and not really > anyone else's business. Yet everyone thinks it's their business to badmouth the Fedora project because they haven't allowed NVidia's legal commitments to change the Fedora project's aims and processes? > Open source is probably a tiny part of their business. The stuff seems OK > on a Mac and I haven't seen this kind of complaint about Solaris which uses > essentially the same driver. But perhaps they do a better job of > coordinating their releases so all the needed components are ready before > users have to deal with it. They'll have exactly the same problems if and when Solaris upgrades their X server. The Fedora project doesn't sell hardware and thus has less obligation (moral or otherwise) to provide for binary drivers for their OS. From billcrawford1970 at gmail.com Wed May 21 13:46:26 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 21 May 2008 14:46:26 +0100 Subject: Xorg 1.5 missed the train? In-Reply-To: <48341F70.4010902@gmail.com> References: <48334163.4080709@magma.ca> <48338D79.9020304@gmail.com> <20080520220210.77f97a82@vader.jdub.homelinux.org> <1211340916.3307.2.camel@clockmaker.usersys.redhat.com> <544eb990805210511i6a5079c1sb683d1f028b9360a@mail.gmail.com> <48341F70.4010902@gmail.com> Message-ID: <544eb990805210646l4c92ca34h262035e8c280441b@mail.gmail.com> 2008/5/21 Les Mikesell : > Bill Crawford wrote: ... >> How is providing a new, shiny Xorg making Fedora "suck", please? > It's all about interfaces, which are what permit programs to work together > at all. They are contracts among cooperating programmers that when changed > break everyone else's work and components. Changing an interface generally > sucks, but shipping a freshly changed interface without publishing the new > definition and giving cooperating entities time to re-do their work to match > sucks even more. "cooperating" You keep using that word. I do not think it means what you think it means. -- roughly quoting Inigo Montoya, a.k.a. Mandy Patinkin. From bpepple at fedoraproject.org Wed May 21 13:48:59 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 21 May 2008 09:48:59 -0400 Subject: Plan for tomorrows (20080522) FESCO meeting Message-ID: <1211377739.4210.2.camel@truman> Hi all, Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC in #fedora-meeting on irc.freenode.org: /topic FESCo meeting -- Any objection to this week's report from FPC at https://www.redhat.com/archives/fedora-devel-list/2008-May/msg01414.html /topic FESCo meeting -- Free discussion around Fedora You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule. You can also propose topics in the meeting while it is in the "Free discussion around Fedora" phase. If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing... Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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: 197 bytes Desc: This is a digitally signed message part URL: From billcrawford1970 at gmail.com Wed May 21 13:51:03 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 21 May 2008 14:51:03 +0100 Subject: Xorg 1.5 missed the train? In-Reply-To: <1211376182.1249.43.camel@gilboa-home-dev.localdomain> References: <48334163.4080709@magma.ca> <604aa7910805201505m7cc84699p953aa880b7419413@mail.gmail.com> <20080520174855.49dd2154@vader.jdub.homelinux.org> <20080520202404.53258cb9@vader.jdub.homelinux.org> <1218b5bc0805201846v19edd85n3be4b48e3c519428@mail.gmail.com> <1211376182.1249.43.camel@gilboa-home-dev.localdomain> Message-ID: <544eb990805210651r28caf529o77d8d8e52442e3f@mail.gmail.com> 2008/5/21 Gilboa Davara : > /* There goes my coffee (through the nose...) */ I usually take mine orally ;o) > - Gilboa Bill, who is turning into a grumpy old man overly fast while reading this thread. From lesmikesell at gmail.com Wed May 21 13:57:44 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 21 May 2008 08:57:44 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: <20080521131820.GC1093879@hiwaay.net> References: <48338811.3090700@gmail.com> <48338D79.9020304@gmail.com> <20080520220210.77f97a82@vader.jdub.homelinux.org> <1211340916.3307.2.camel@clockmaker.usersys.redhat.com> <544eb990805210511i6a5079c1sb683d1f028b9360a@mail.gmail.com> <48341F70.4010902@gmail.com> <20080521131820.GC1093879@hiwaay.net> Message-ID: <48342A58.8040407@gmail.com> Chris Adams wrote: > >> It's all about interfaces, which are what permit programs to work >> together at all. They are contracts among cooperating programmers that >> when changed break everyone else's work and components. Changing an >> interface generally sucks, but shipping a freshly changed interface >> without publishing the new definition and giving cooperating entities >> time to re-do their work to match sucks even more. > > Yeah, because you know, Fedora and X.org keep everything in hiding and > never let any bits out until they are released. Also, they never tell > anyone what they are doing. Exposing your development work in progress has nothing in common with announcing a new stable definition. When did the latter happen? -- Les Mikesell lesmikesell at gmail.com From mschwendt at gmail.com Wed May 21 13:58:57 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 21 May 2008 15:58:57 +0200 Subject: What provides phonon devel phonon/mediaobject.h In-Reply-To: References: Message-ID: <20080521155857.29ede011.mschwendt@gmail.com> On Wed, 21 May 2008 07:10:09 -0400, Neal Becker wrote: > XMplayer.h:2:32: error: phonon/mediaobject.h: No such file or directory > > What provides phonon/mediaobject.h (part of phonon)? $ repoquery --whatprovides \*phonon/mediaobject.h\* kdelibs-devel-6:4.0.3-7.fc9.i386 From dev at nigelj.com Wed May 21 14:00:38 2008 From: dev at nigelj.com (Nigel Jones) Date: Thu, 22 May 2008 02:00:38 +1200 Subject: What provides phonon devel phonon/mediaobject.h In-Reply-To: <20080521155857.29ede011.mschwendt@gmail.com> References: <20080521155857.29ede011.mschwendt@gmail.com> Message-ID: <48342B06.1040008@nigelj.com> Michael Schwendt wrote: > On Wed, 21 May 2008 07:10:09 -0400, Neal Becker wrote: > > >> XMplayer.h:2:32: error: phonon/mediaobject.h: No such file or directory >> >> What provides phonon/mediaobject.h (part of phonon)? >> > > $ repoquery --whatprovides \*phonon/mediaobject.h\* > kdelibs-devel-6:4.0.3-7.fc9.i386 > > iirc this is fixed by 4.0.4 in updates-testing (Rex can you confirm?) - Nigel From gilboad at gmail.com Wed May 21 14:09:36 2008 From: gilboad at gmail.com (Gilboa Davara) Date: Wed, 21 May 2008 17:09:36 +0300 Subject: Xorg 1.5 missed the train? In-Reply-To: <544eb990805210651r28caf529o77d8d8e52442e3f@mail.gmail.com> References: <48334163.4080709@magma.ca> <604aa7910805201505m7cc84699p953aa880b7419413@mail.gmail.com> <20080520174855.49dd2154@vader.jdub.homelinux.org> <20080520202404.53258cb9@vader.jdub.homelinux.org> <1218b5bc0805201846v19edd85n3be4b48e3c519428@mail.gmail.com> <1211376182.1249.43.camel@gilboa-home-dev.localdomain> <544eb990805210651r28caf529o77d8d8e52442e3f@mail.gmail.com> Message-ID: <1211378976.1249.53.camel@gilboa-home-dev.localdomain> On Wed, 2008-05-21 at 14:51 +0100, Bill Crawford wrote: > 2008/5/21 Gilboa Davara : > > > /* There goes my coffee (through the nose...) */ > > I usually take mine orally ;o) > > > - Gilboa > > Bill, who is turning into a grumpy old man overly fast while reading > this thread. > "Stupid kids! Get off the lawn!" - Gilboa From mzerqung at 0pointer.de Wed May 21 14:10:08 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Wed, 21 May 2008 16:10:08 +0200 Subject: Glitch-Free PulseAudio in Rawhide In-Reply-To: <1211376341.28707.19.camel@dimi.lattica.com> References: <20080517101616.GA16071@tango.0pointer.de> <20080518200225.GC19530@tango.0pointer.de> <1211260283.6534.46.camel@dimi.lattica.com> <20080520105304.GC13762@tango.0pointer.de> <1211376341.28707.19.camel@dimi.lattica.com> Message-ID: <20080521141008.GA18167@tango.0pointer.de> On Wed, 21.05.08 09:25, Dimi Paun (dimi at lattica.com) wrote: > It is completely irrelevant that this is exactly what happens. > In fact, you could say that "a number of bytes don't reach a process > via file descriptor 7" and it would be exactly what happens, all > at the same time being a cryptic and bad error message. > > Do you really think a non technical user knows what a "server" is, > especially in this context? If you are tempted to reply yes, don't > bother, it Just Plain Wrong (TM). Have you noticed that most error messages on Linux are this terse? I think we simply disagree here what the main focus here should be. I think the focus should be to fix the remaining issue for you so that the entire error can go away. Your focus seems to be to make failing more descriptive. -- I am not at all against making error messages more discriptive, I would happily accept a sensible patch for this. So, please stop complaining about this, get off your ass and put your code where your mouth is! But please, strerror()-like error messages is how error reporting is mostly done on Linux these days. I am not sure why you are picking on PA that much. In contrast to what you claim desktop audio is really not a core component of the system. If audio breaks the effect is rather, huh, irrelevant most of the times. I can list you a lot of components of a modern system where failure is far, far more catastrophic. And no, I am not using this as an excuse that I can produce low quality, buggy code. All I want to ask you: please keep things in relation. So you are experiencing one bug on your specific setup that makes listening to your favourite music break after a few hours of continious play. Surely annoying, something we need to fix. But just one bug, and not catastrophic. And you are raving how really really essential this is, something that "MUST JUST WORK!", and blah and foo. And then you claim we ignored systematically and was just one among many. But that's not true. Lubomir responded. As did I. Maybe we didn't treat your bug with the priority you'd have liked that we treated it with, sure. But really, no need to flame anyone about. Please, let's stop this flame war here now. Bugs happen. All the time. Bugs aren't discovered by QA, quite often. This one wasn't fixed before F9 release. > Not by a long shot. If an app crashes, _anybody_ knows to restart it. On > this other hand, sound is a system feature that must work. The fact that > it doesn't without frequent reboots reflects a design problem -- sound > must restart automagically, not require the user to reboot every hour or > so to recover this essential desktop feature! > > For fsck's sake, I didn't have to reboot Windows 3.1 that often! This is nonsense. And you know it. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From lmacken at redhat.com Wed May 21 14:24:36 2008 From: lmacken at redhat.com (Luke Macken) Date: Wed, 21 May 2008 10:24:36 -0400 Subject: Bodhi spam? In-Reply-To: <20080520093705.GA25663@amd.home.annexia.org> References: <20080520093705.GA25663@amd.home.annexia.org> Message-ID: <20080521142436.GA8221@x300> On Tue, May 20, 2008 at 10:37:05AM +0100, Richard W.M. Jones wrote: > > [Two unrelated Bodhi questions in the space of a few minutes ...] > > Is someone able to spam Bodhi? See: > > https://admin.fedoraproject.org/updates/F8/pending/ocaml-libvirt-0.4.1.1-2.fc8 Interesting... It look them 4 tries to guess the captcha for the first comment, and 2 for the second -- 2 minutes apart. Smart bot or really dumb person? I'm not quite sure what we can do about either... luke From ajax at redhat.com Wed May 21 14:25:00 2008 From: ajax at redhat.com (Adam Jackson) Date: Wed, 21 May 2008 10:25:00 -0400 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <20080520174855.49dd2154@vader.jdub.homelinux.org> <20080520202404.53258cb9@vader.jdub.homelinux.org> <1218b5bc0805201846v19edd85n3be4b48e3c519428@mail.gmail.com> <1211335226.3768.1.camel@clockmaker.usersys.redhat.com> <20080520211137.67744ac3@vader.jdub.homelinux.org> Message-ID: <1211379900.29467.136.camel@localhost.localdomain> On Tue, 2008-05-20 at 19:19 -0700, Christopher Stone wrote: > > In the real world, you're asking Fedora to do something to enable > > binary drivers which goes against it's goals. And then you're whining > > about it when we say no. > > Oh yea, to have one developer spend one day to provide a compatibility > route for a large number of Fedora users is just *way* too much to > ask...sheesh... > > I'm not asking for someone to spend a year full time on this, it would > only take about one day's worth of effort as far as I can see. That's so adorably misguided. Let's see. Compat packages for the X server and every driver. That's about sixty new packages, all of which have to go through new package review. Even if they're all perfect, you're looking at a good 30 minutes apiece just to get the things into CVS, then another hour or so until everything manages to bubble out of koji. Except, of course, that they won't be perfect, since they'll file-conflict with the non-compat drivers. So you'll have to add explicit Conflicts to each of now ~120 packages. Okay, more like an hour for each package now, since we're having to test packaging behaviour. Ooh, and now we're picking up an additional set of packages to apply stability fixes to. So, uh. ?A week and a half of doing _nothing_ _else_, when I'm already clearly overscheduled. A good solid sixty hours of work, plus a continuing time investment of essentially a whole new current distro to support, ?a level of time investment that I wouldn't sign up for for RHEL for less than seven figures of revenue. All to continue to make some binary driver work. How's no sound? Is no good for you? No's great for me. Let me put this as politely as possible: compatibility X server packages are out of the fucking question. I've refused them in paid supported products for strong technical and support reasons, and I'm not about to start doing them for free just to get my jollies preserving interoperability with someone's binary blob. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From dimi at lattica.com Wed May 21 14:27:07 2008 From: dimi at lattica.com (Dimi Paun) Date: Wed, 21 May 2008 10:27:07 -0400 Subject: Glitch-Free PulseAudio in Rawhide In-Reply-To: <20080521141008.GA18167@tango.0pointer.de> References: <20080517101616.GA16071@tango.0pointer.de> <20080518200225.GC19530@tango.0pointer.de> <1211260283.6534.46.camel@dimi.lattica.com> <20080520105304.GC13762@tango.0pointer.de> <1211376341.28707.19.camel@dimi.lattica.com> <20080521141008.GA18167@tango.0pointer.de> Message-ID: <1211380027.28707.32.camel@dimi.lattica.com> On Wed, 2008-05-21 at 16:10 +0200, Lennart Poettering wrote: > things in relation. So you are experiencing one bug on your specific > setup that makes listening to your favourite music break after a few > hours of continious play. Lennart, it is not a trivial problem. It's not that I can not listen to music, I gave that up some time ago. But sound nowadays has become an essential business function for many people. I work with a team that's geographically dispersed, and being able to use Skype is fundamental. In many way, if I can't use Skype is as bad as not being able to use the mouse. Yes, you answered, Lubomir answered, I was disciplined for not going through bugzilla, and at the end of the day nothing happened, because you seem to think this is a trivial problem that's not all that important, and I'm being an asshole. > All I want to ask you: please keep things in relation. I am trying to make you realize that for a regular user not having sound is fundamental nowadays: you can't Skype, Youtube doesn't have sound, you can't listen to your music. This is probably closer to 80% of what a _regular_ user does with a desktop, so it's not a trivial problem as you imply. > > For fsck's sake, I didn't have to reboot Windows 3.1 that often! > > This is nonsense. And you know it. Please Lennart, you said two messages ago that requiring a reboot (for regular users) to recover from software errors like the ones experienced with PA is acceptable. The point I'm trying to make is that it's not. Requiring normal users to "pulseaudio -D" is (or at least should be) out of the question. If so, what is the recovery mode? -- Dimi Paun Lattica, Inc. From mschwendt at gmail.com Wed May 21 14:32:52 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 21 May 2008 16:32:52 +0200 Subject: Bodhi spam? In-Reply-To: <20080521142436.GA8221@x300> References: <20080520093705.GA25663@amd.home.annexia.org> <20080521142436.GA8221@x300> Message-ID: <20080521163252.e44bdef5.mschwendt@gmail.com> On Wed, 21 May 2008 10:24:36 -0400, Luke Macken wrote: > On Tue, May 20, 2008 at 10:37:05AM +0100, Richard W.M. Jones wrote: > > > > [Two unrelated Bodhi questions in the space of a few minutes ...] > > > > Is someone able to spam Bodhi? See: > > > > https://admin.fedoraproject.org/updates/F8/pending/ocaml-libvirt-0.4.1.1-2.fc8 > > Interesting... > > It look them 4 tries to guess the captcha for the first comment, and 2 for the > second -- 2 minutes apart. Smart bot or really dumb person? I'm not > quite sure what we can do about either... What about the logged usernames? Can the default "Anonymous Tester" be changed from the outside? It is plural "Anonymous Testers" for the first comment and "ljkl" for the second comment. From mzerqung at 0pointer.de Wed May 21 14:42:02 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Wed, 21 May 2008 16:42:02 +0200 Subject: Glitch-Free PulseAudio in Rawhide In-Reply-To: <1211380027.28707.32.camel@dimi.lattica.com> References: <20080517101616.GA16071@tango.0pointer.de> <20080518200225.GC19530@tango.0pointer.de> <1211260283.6534.46.camel@dimi.lattica.com> <20080520105304.GC13762@tango.0pointer.de> <1211376341.28707.19.camel@dimi.lattica.com> <20080521141008.GA18167@tango.0pointer.de> <1211380027.28707.32.camel@dimi.lattica.com> Message-ID: <20080521144202.GA20987@tango.0pointer.de> On Wed, 21.05.08 10:27, Dimi Paun (dimi at lattica.com) wrote: > Yes, you answered, Lubomir answered, I was disciplined for not going > through bugzilla, and at the end of the day nothing happened, because > you seem to think this is a trivial problem that's not all that > important, and I'm being an asshole. I didn't say fixing this issue is "not important". Sure it is. But please, keep things in relation. If one bug in audio appears *that* catastrophic for you, I really want to hear you getting started on the recent OpenSSL issue. Now you claim we didn't respond by "at the end of the day". Ah, I forgot that I promised 24h response times for all bugs you post. Sorry that I have been so forgetful! > > > For fsck's sake, I didn't have to reboot Windows 3.1 that often! > > > > This is nonsense. And you know it. > > Please Lennart, you said two messages ago that requiring a reboot > (for regular users) to recover from software errors like the ones > experienced with PA is acceptable. Oh, did I say that? I guess I must suffer by dissociative identity disorder then. Because I cannot really remember making such a statement, must have be some other instance of myself then. This is my last mail in this thread. This flame war ends here from my side. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From jwilson at redhat.com Wed May 21 14:54:41 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 21 May 2008 10:54:41 -0400 Subject: Xorg 1.5 missed the train? In-Reply-To: <1211379900.29467.136.camel@localhost.localdomain> References: <48334163.4080709@magma.ca> <20080520174855.49dd2154@vader.jdub.homelinux.org> <20080520202404.53258cb9@vader.jdub.homelinux.org> <1218b5bc0805201846v19edd85n3be4b48e3c519428@mail.gmail.com> <1211335226.3768.1.camel@clockmaker.usersys.redhat.com> <20080520211137.67744ac3@vader.jdub.homelinux.org> <1211379900.29467.136.camel@localhost.localdomain> Message-ID: <483437B1.6020007@redhat.com> Adam Jackson wrote: > On Tue, 2008-05-20 at 19:19 -0700, Christopher Stone wrote: > >>> In the real world, you're asking Fedora to do something to enable >>> binary drivers which goes against it's goals. And then you're whining >>> about it when we say no. >> Oh yea, to have one developer spend one day to provide a compatibility >> route for a large number of Fedora users is just *way* too much to >> ask...sheesh... >> >> I'm not asking for someone to spend a year full time on this, it would >> only take about one day's worth of effort as far as I can see. > > That's so adorably misguided. [...] > How's no sound? Is no good for you? No's great for me. Hee, can't resist, loved this reply... :) For the record, I just sat down in front of my appletv, which I've now got running Fedora 9. Its got a GeForce 7300 or so equivalent in it. With a tiny bit of effort (much less than was put into all this stupid bitching and blaming ajax and airlied for for breaking everything), I have the latest nvidia beta driver powering a display just fine, thank you. -- Jarod Wilson jwilson at redhat.com From chris.stone at gmail.com Wed May 21 15:04:28 2008 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 21 May 2008 08:04:28 -0700 Subject: Xorg 1.5 missed the train? In-Reply-To: <1211379900.29467.136.camel@localhost.localdomain> References: <48334163.4080709@magma.ca> <20080520202404.53258cb9@vader.jdub.homelinux.org> <1218b5bc0805201846v19edd85n3be4b48e3c519428@mail.gmail.com> <1211335226.3768.1.camel@clockmaker.usersys.redhat.com> <20080520211137.67744ac3@vader.jdub.homelinux.org> <1211379900.29467.136.camel@localhost.localdomain> Message-ID: 2008/5/21 Adam Jackson : > On Tue, 2008-05-20 at 19:19 -0700, Christopher Stone wrote: > >> > In the real world, you're asking Fedora to do something to enable >> > binary drivers which goes against it's goals. And then you're whining >> > about it when we say no. >> >> Oh yea, to have one developer spend one day to provide a compatibility >> route for a large number of Fedora users is just *way* too much to >> ask...sheesh... >> >> I'm not asking for someone to spend a year full time on this, it would >> only take about one day's worth of effort as far as I can see. > > That's so adorably misguided. > > Let's see. Compat packages for the X server and every driver. That's > about sixty new packages, all of which have to go through new package > review. Even if they're all perfect, you're looking at a good 30 > minutes apiece just to get the things into CVS, then another hour or so > until everything manages to bubble out of koji. Except, of course, that > they won't be perfect, since they'll file-conflict with the non-compat > drivers. So you'll have to add explicit Conflicts to each of now ~120 > packages. Okay, more like an hour for each package now, since we're > having to test packaging behaviour. Ooh, and now we're picking up an > additional set of packages to apply stability fixes to. > > So, uh. ?A week and a half of doing _nothing_ _else_, when I'm already > clearly overscheduled. A good solid sixty hours of work, plus a > continuing time investment of essentially a whole new current distro to > support, ?a level of time investment that I wouldn't sign up for for > RHEL for less than seven figures of revenue. All to continue to make > some binary driver work. > > How's no sound? Is no good for you? No's great for me. > > Let me put this as politely as possible: compatibility X server packages > are out of the fucking question. I've refused them in paid supported > products for strong technical and support reasons, and I'm not about to > start doing them for free just to get my jollies preserving > interoperability with someone's binary blob. Pfft, you dont have to put these through review, you dont have to do a QA on them, you just have to take the f8 rpms and rebuild them on f9, stick them in updates-testing and be done with it. One or two days tops, nothing more. Sheesh.... From billcrawford1970 at gmail.com Wed May 21 15:12:11 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 21 May 2008 16:12:11 +0100 Subject: Glitch-Free PulseAudio in Rawhide In-Reply-To: <20080521144202.GA20987@tango.0pointer.de> References: <20080517101616.GA16071@tango.0pointer.de> <20080518200225.GC19530@tango.0pointer.de> <1211260283.6534.46.camel@dimi.lattica.com> <20080520105304.GC13762@tango.0pointer.de> <1211376341.28707.19.camel@dimi.lattica.com> <20080521141008.GA18167@tango.0pointer.de> <1211380027.28707.32.camel@dimi.lattica.com> <20080521144202.GA20987@tango.0pointer.de> Message-ID: <544eb990805210812p6d701945r77580f97ad7062e3@mail.gmail.com> 2008/5/21 Lennart Poettering : > This is my last mail in this thread. This flame war ends here from my side. *last word* then ;o) > Lennart From emmanuel.seyman at club-internet.fr Wed May 21 15:11:59 2008 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Wed, 21 May 2008 17:11:59 +0200 Subject: Xorg 1.5 missed the train? In-Reply-To: <483420D0.7040008@nigelj.com> References: <48334F03.6070203@fedoraproject.org> <35207.75.164.221.130.1211322487.squirrel@clueserver.org> <1218b5bc0805201625p21ba80b9y9cffd6eeb7fcec9b@mail.gmail.com> <48335FC0.2070806@gmail.com> <4833C117.5090007@gmail.com> <4833C4B9.3020105@gmail.com> <1218b5bc0805210138l4b508c05x6dc1d90fca9b25e3@mail.gmail.com> <20080521091906.GA3918@orient.maison.lan> <1211375307.1249.35.camel@gilboa-home-dev.localdomain> <483420D0.7040008@nigelj.com> Message-ID: <20080521151159.GA5891@orient.maison.lan> * Nigel Jones [21/05/2008 16:44] : > > nVidia have tried to blame everything on XOrg and "other people" which is > exactly what is outlined in Emmanuel's e-mail. It's actually the Nvidia users who seem to want to blame everything on FLOSS developers and distributions. I'm not actually opposed to this (apart from the fact that it's... , you know, wrong) but I'm always surprised at the amount of passion they can put into defending a vendor that has locked them into the situation they're spending so much time and energy complaining about. Emmanuel From mcepl at redhat.com Wed May 21 15:11:39 2008 From: mcepl at redhat.com (Matej Cepl) Date: Wed, 21 May 2008 17:11:39 +0200 Subject: Xorg 1.5 missed the train? References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <1211319877.8531.40.camel@localhost.localdomain> Message-ID: On Tue, 20 May 2008 14:51:08 -0700, Christopher Stone scripst: > nVidia can't do anything until xorg's ABI is *stable*. They can -- publish specs. Tell them they are cheating on you as your customer, when they don't tell you how to use the hardware you bought from them. Mat?j -- The content of this message is licensed under a Creative Commons Attribution 3.0 License, Some Rights Reserved. http://creativecommons.org/licenses/by/3.0/us/ From billcrawford1970 at gmail.com Wed May 21 15:17:21 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 21 May 2008 16:17:21 +0100 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <1218b5bc0805201846v19edd85n3be4b48e3c519428@mail.gmail.com> <1211335226.3768.1.camel@clockmaker.usersys.redhat.com> <20080520211137.67744ac3@vader.jdub.homelinux.org> <1211379900.29467.136.camel@localhost.localdomain> Message-ID: <544eb990805210817r129dc6o7b8aee1ad5d27c07@mail.gmail.com> 2008/5/21 Christopher Stone : > Pfft, you dont have to put these through review, you dont have to do a > QA on them, you just have to take the f8 rpms and rebuild them on f9, > stick them in updates-testing and be done with it. One or two days > tops, nothing more. Sheesh.... I *hope* you're saying "I'd do that in a hearbeat, without blinking." Partly because I want to see you try to package and maintain X. I *have* done so, locally, for my own benefit, during the modularisation effort. I can assure that while it eases maintenance in the long term when it comes to updating small parts of the infrastructure (new driver -> one new, small package to build and for people to download) you do *not* want to try to maintain it yourself, unsupported. Seriously. Of course, you *could* just go ahead and prove me wrong. Looking forward to seeing your announcement of the distro fork ... From chris.stone at gmail.com Wed May 21 15:18:47 2008 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 21 May 2008 08:18:47 -0700 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <1211319877.8531.40.camel@localhost.localdomain> Message-ID: On Wed, May 21, 2008 at 8:11 AM, Matej Cepl wrote: > On Tue, 20 May 2008 14:51:08 -0700, Christopher Stone scripst: >> nVidia can't do anything until xorg's ABI is *stable*. > > They can -- publish specs. Tell them they are cheating on you as your > customer, when they don't tell you how to use the hardware you bought from > them. Maybe my next card will be ATi, how is that driver doing? The last I've heard it still has problems, but maybe it has improved, I don't know. From rdieter at math.unl.edu Wed May 21 15:19:54 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 21 May 2008 10:19:54 -0500 Subject: What provides phonon devel phonon/mediaobject.h References: <20080521155857.29ede011.mschwendt@gmail.com> <48342B06.1040008@nigelj.com> Message-ID: Nigel Jones wrote: > Michael Schwendt wrote: >> On Wed, 21 May 2008 07:10:09 -0400, Neal Becker wrote: >> >> >>> XMplayer.h:2:32: error: phonon/mediaobject.h: No such file or directory >>> >>> What provides phonon/mediaobject.h (part of phonon)? >>> >> >> $ repoquery --whatprovides \*phonon/mediaobject.h\* >> kdelibs-devel-6:4.0.3-7.fc9.i386 >> >> > iirc this is fixed by 4.0.4 in updates-testing (Rex can you confirm?) fixed? what was broken? -- Rex From cmadams at hiwaay.net Wed May 21 15:20:23 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 21 May 2008 10:20:23 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <1218b5bc0805201846v19edd85n3be4b48e3c519428@mail.gmail.com> <1211335226.3768.1.camel@clockmaker.usersys.redhat.com> <20080520211137.67744ac3@vader.jdub.homelinux.org> <1211379900.29467.136.camel@localhost.localdomain> Message-ID: <20080521152022.GF1093879@hiwaay.net> Once upon a time, Christopher Stone said: > Pfft, you dont have to put these through review, you dont have to do a > QA on them, you just have to take the f8 rpms and rebuild them on f9, > stick them in updates-testing and be done with it. One or two days > tops, nothing more. Sheesh.... Fedora has a well-defined process for delivering packages for a good reason, and you want that policy ignored for the benefit of closed source software (that is quite possibly violating the GPL on the kernel side). The updates-testing repo is for, well, testing of updates, not distribution of random bits of unreviewed software. How exactly would users install these packages anyway? If they have installed F9, they can't use any of the regular tools to install older versions of X. They also can't use any regular update tools or they'll break X (by re-upgrading to the current packages). If it is so easy, why don't you do it in your own repo? Fedora is a fully open distribution; all the necessary tools are there. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From chris.stone at gmail.com Wed May 21 15:25:46 2008 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 21 May 2008 08:25:46 -0700 Subject: Xorg 1.5 missed the train? In-Reply-To: <20080521152022.GF1093879@hiwaay.net> References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <1218b5bc0805201846v19edd85n3be4b48e3c519428@mail.gmail.com> <1211335226.3768.1.camel@clockmaker.usersys.redhat.com> <20080520211137.67744ac3@vader.jdub.homelinux.org> <1211379900.29467.136.camel@localhost.localdomain> <20080521152022.GF1093879@hiwaay.net> Message-ID: On Wed, May 21, 2008 at 8:20 AM, Chris Adams wrote: > Once upon a time, Christopher Stone said: >> Pfft, you dont have to put these through review, you dont have to do a >> QA on them, you just have to take the f8 rpms and rebuild them on f9, >> stick them in updates-testing and be done with it. One or two days >> tops, nothing more. Sheesh.... > > Fedora has a well-defined process for delivering packages for a good > reason, and you want that policy ignored for the benefit of closed > source software (that is quite possibly violating the GPL on the kernel > side). > > The updates-testing repo is for, well, testing of updates, not > distribution of random bits of unreviewed software. How exactly would > users install these packages anyway? If they have installed F9, they > can't use any of the regular tools to install older versions of X. They > also can't use any regular update tools or they'll break X (by > re-upgrading to the current packages). > > If it is so easy, why don't you do it in your own repo? Fedora is a > fully open distribution; all the necessary tools are there. Should I make an assumption that you mean to say rpm is not a "regular" tool. Sure, you would have to add some documentation on how to install it by first uninstalling X. It's not so much compatibility and support, but more a matter of convenience. As several people have stated in this thread already, they would have just been happy if there was even one sentence in the release notes about it. But not even that much effort can be made it seems. From jkeating at redhat.com Wed May 21 15:28:42 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 May 2008 11:28:42 -0400 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <1218b5bc0805201846v19edd85n3be4b48e3c519428@mail.gmail.com> <1211335226.3768.1.camel@clockmaker.usersys.redhat.com> <20080520211137.67744ac3@vader.jdub.homelinux.org> <1211379900.29467.136.camel@localhost.localdomain> <20080521152022.GF1093879@hiwaay.net> Message-ID: <1211383722.8531.63.camel@localhost.localdomain> On Wed, 2008-05-21 at 08:25 -0700, Christopher Stone wrote: > As several people have stated in this thread already, they would have > just been happy if there was even one sentence in the release notes > about it. But not even that much effort can be made it seems. Since the Release Notes effort, like any effort in Fedora, is one that is open to all, you yourself could have added the release note item. I don't fault our X team one bit for not spending time to test the various states of the various closed source blobs with our Fedora release. In fact, it's not too late! The release notes are a living document and published on the web so that we can update them with further information. Go to it! -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mcepl at redhat.com Wed May 21 15:22:41 2008 From: mcepl at redhat.com (Matej Cepl) Date: Wed, 21 May 2008 17:22:41 +0200 Subject: Xorg 1.5 missed the train? References: <48334163.4080709@magma.ca> <1218b5bc0805201846v19edd85n3be4b48e3c519428@mail.gmail.com> <1211335226.3768.1.camel@clockmaker.usersys.redhat.com> <20080520211137.67744ac3@vader.jdub.homelinux.org> <48338811.3090700@gmail.com> <48338D79.9020304@gmail.com> Message-ID: <1brdg5xo5o.ln2@ppp1053.in.ipex.cz> On Tue, 20 May 2008 19:54:42 -0700, Christopher Stone scripst: > It just seems to me > that an upgrade path for nVidia users could be provided without much > extra effort. Yes, it seems to you. And you are wrong. So what? Mat?j -- The content of this message is licensed under a Creative Commons Attribution 3.0 License, Some Rights Reserved. http://creativecommons.org/licenses/by/3.0/us/ From mike at miketc.com Wed May 21 15:31:21 2008 From: mike at miketc.com (Mike Chambers) Date: Wed, 21 May 2008 10:31:21 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <1218b5bc0805201846v19edd85n3be4b48e3c519428@mail.gmail.com> <1211335226.3768.1.camel@clockmaker.usersys.redhat.com> <20080520211137.67744ac3@vader.jdub.homelinux.org> <1211379900.29467.136.camel@localhost.localdomain> <20080521152022.GF1093879@hiwaay.net> Message-ID: <1211383881.20155.9.camel@scrappy.miketc.com> On Wed, 2008-05-21 at 08:25 -0700, Christopher Stone wrote: > As several people have stated in this thread already, they would have > just been happy if there was even one sentence in the release notes > about it. But not even that much effort can be made it seems. And if it was in there, they would had complained that the letters weren't bold enough, or it should has been positioned at the top where they would had seen it. But they should had done their homework as well and did some searching to make sure their major hardware was compat with a new os/driver/whatever. Same as I should had done on this laptop that uses wireless driver that doesn't work out of box yet. -- Mike Chambers Fedora Project - Ambassador, Bug Zapper, Tester, User, etc.. mikec302 at fedoraproject.org From skvidal at fedoraproject.org Wed May 21 15:27:16 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 21 May 2008 11:27:16 -0400 Subject: changes at planet fedora In-Reply-To: <4833CB46.4010005@nicubunu.ro> References: <1211214812.3095.0.camel@cutter> <4833CB46.4010005@nicubunu.ro> Message-ID: <1211383636.3074.20.camel@cutter> On Wed, 2008-05-21 at 10:12 +0300, Nicu Buculei wrote: > seth vidal wrote: > > > > http://skvidal.fedorapeople.org/docs/planet-addition.html > > > > These instructions will be added to the wiki after the wiki migration > > happens next week. > > > > Let me know what problems you have, too. > > It does not work for me. > I am already on Planet and dropped a .planet file in my homedir > (nicubunu), specifying the same URL for the feed, the same person name > but a different hackergotchi image. This change seems ignored, the old > image is still displayed (I suspect the script finds the duplicate and > remove the wrong entry). Yes, the changes are not in effect, yet. I'm waiting on more .planet files to be made before flicking the switch. sorry if that wasn't more clear. I'll post more about it shortly. thanks, -sv From mcepl at redhat.com Wed May 21 15:17:17 2008 From: mcepl at redhat.com (Matej Cepl) Date: Wed, 21 May 2008 17:17:17 +0200 Subject: Xorg 1.5 missed the train? References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <1211319877.8531.40.camel@localhost.localdomain> <604aa7910805201505m7cc84699p953aa880b7419413@mail.gmail.com> <20080520174855.49dd2154@vader.jdub.homelinux.org> <20080520202404.53258cb9@vader.jdub.homelinux.org> Message-ID: On Tue, 20 May 2008 18:38:37 -0700, Christopher Stone scripst: > And obviously ajax does not care about 50% of Fedora's user base. It > would seem to me that he is not being a good maintainer, If I am not mistaken, somebody made some accounting that whole Xorg team was working 60+ hours/week at least since New Year just to make Xorg working at least as it is. I feel personally insulted by such idiotical remarks as yours in this thread. Have at least some decency, man! Mat?j -- The content of this message is licensed under a Creative Commons Attribution 3.0 License, Some Rights Reserved. http://creativecommons.org/licenses/by/3.0/us/ From skvidal at fedoraproject.org Wed May 21 15:28:34 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 21 May 2008 11:28:34 -0400 Subject: changes at planet fedora In-Reply-To: <409676c70805210502p8c6d7d9j79df72b6a58948cd@mail.gmail.com> References: <1211214812.3095.0.camel@cutter> <6e24a8e80805201301r44a241bdr9b2263052fe1fd8b@mail.gmail.com> <6e24a8e80805201550o12531af3ye6692f9571cb5230@mail.gmail.com> <48335785.4050800@fedoraproject.org> <20080520201228.3dfb45b6@vader.jdub.homelinux.org> <4833CCC3.1050405@nicubunu.ro> <4833CFA7.9000703@nigelj.com> <6e24a8e80805210424nd504e3dxedc5551df2c8896f@mail.gmail.com> <409676c70805210502p8c6d7d9j79df72b6a58948cd@mail.gmail.com> Message-ID: <1211383714.3074.22.camel@cutter> On Wed, 2008-05-21 at 14:02 +0200, Trond Danielsen wrote: > 2008/5/21 Mark : > > That basically that everyone that is a member of FAS becomes something > > like an Admin on the fedora planet.. they can add as much blogs as > > they want (and probably remove tthe ones they added as well) which > > just means he is an admin over the entered blog urls. > > > > I find it verry strange if this is what you guys want.. > > I find this lack of trust in Fedora contributors very strange; has it > not occurred to you that the powers granted by cvs access, bugzilla > accounts and mailing list membership can do far more harm to the > community than a hostile blog aggregated on planet F? Admins are still > around to clear things out if lets say I go mad and start adding all > sorts of blogs that post offensive content to planet F, but until then > I believe that people who sign up to become a Fedora contributor do it > to improve Fedora and not the opposite. yes, and I've got an 'ignore users' config option in the planet builder script so we can magically drop people from the config. "clickety-click" -sv From jwboyer at gmail.com Wed May 21 15:39:36 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 21 May 2008 10:39:36 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <20080520202404.53258cb9@vader.jdub.homelinux.org> <1218b5bc0805201846v19edd85n3be4b48e3c519428@mail.gmail.com> <1211335226.3768.1.camel@clockmaker.usersys.redhat.com> <20080520211137.67744ac3@vader.jdub.homelinux.org> <1211379900.29467.136.camel@localhost.localdomain> Message-ID: <20080521103936.6e8ace3f@vader.jdub.homelinux.org> On Wed, 21 May 2008 08:04:28 -0700 "Christopher Stone" wrote: > > How's no sound? Is no good for you? No's great for me. > > > > Let me put this as politely as possible: compatibility X server packages > > are out of the fucking question. I've refused them in paid supported > > products for strong technical and support reasons, and I'm not about to > > start doing them for free just to get my jollies preserving > > interoperability with someone's binary blob. > > Pfft, you dont have to put these through review, you dont have to do a > QA on them, you just have to take the f8 rpms and rebuild them on f9, > stick them in updates-testing and be done with it. One or two days > tops, nothing more. Sheesh.... No. And if someone actually does that, I'll be sure to raise a stink about it royally as it actively goes against every guideline we have. josh From rdieter at math.unl.edu Wed May 21 15:39:32 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 21 May 2008 10:39:32 -0500 Subject: libmapi and samba4 References: <20080520102245.C6395209D29@releng1.fedora.phx.redhat.com> <200805201113.56371.jbarnes@virtuousgeek.org> <200805201150.14705.jbarnes@virtuousgeek.org> <1211334876.3469.23.camel@naomi> Message-ID: Andrew Bartlett wrote: > I'm very happy to work with anyone wishing to package Samba4. atm, my own selfish interests are limited to libsmbclient from samba4, which I would venture would be a lot simpler to package alongside of fedora's current samba v3. -- Rex From mcepl at redhat.com Wed May 21 15:32:30 2008 From: mcepl at redhat.com (Matej Cepl) Date: Wed, 21 May 2008 17:32:30 +0200 Subject: Xorg 1.5 missed the train? References: <48334163.4080709@magma.ca> <1211335226.3768.1.camel@clockmaker.usersys.redhat.com> <20080520211137.67744ac3@vader.jdub.homelinux.org> <48338811.3090700@gmail.com> <48338D79.9020304@gmail.com> <20080520220210.77f97a82@vader.jdub.homelinux.org> <1211340916.3307.2.camel@clockmaker.usersys.redhat.com> <4833B21C.2020807@gmail.com> Message-ID: On Wed, 21 May 2008 00:24:44 -0500, Les Mikesell scripst: > Seems odd that you knew it wasn't going to change and had time to port > drivers but no one else knew. Yeah, nobody knew -- except those who can take a look at http:// gitweb.freedesktop.org/ Mat?j -- The content of this message is licensed under a Creative Commons Attribution 3.0 License, Some Rights Reserved. http://creativecommons.org/licenses/by/3.0/us/ From chris.stone at gmail.com Wed May 21 15:46:00 2008 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 21 May 2008 08:46:00 -0700 Subject: Xorg 1.5 missed the train? In-Reply-To: <1211383722.8531.63.camel@localhost.localdomain> References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <1211335226.3768.1.camel@clockmaker.usersys.redhat.com> <20080520211137.67744ac3@vader.jdub.homelinux.org> <1211379900.29467.136.camel@localhost.localdomain> <20080521152022.GF1093879@hiwaay.net> <1211383722.8531.63.camel@localhost.localdomain> Message-ID: 2008/5/21 Jesse Keating : > On Wed, 2008-05-21 at 08:25 -0700, Christopher Stone wrote: >> As several people have stated in this thread already, they would have >> just been happy if there was even one sentence in the release notes >> about it. But not even that much effort can be made it seems. > > Since the Release Notes effort, like any effort in Fedora, is one that > is open to all, you yourself could have added the release note item. > > I don't fault our X team one bit for not spending time to test the > various states of the various closed source blobs with our Fedora > release. > > In fact, it's not too late! The release notes are a living document and > published on the web so that we can update them with further > information. Go to it! It would probably get more visibility in the CommonBugs wiki page. When is the front page link going to switch over to f9 common bugs? From jspaleta at gmail.com Wed May 21 15:52:36 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 21 May 2008 07:52:36 -0800 Subject: changes at planet fedora In-Reply-To: <1211383636.3074.20.camel@cutter> References: <1211214812.3095.0.camel@cutter> <4833CB46.4010005@nicubunu.ro> <1211383636.3074.20.camel@cutter> Message-ID: <604aa7910805210852g546b286n73b7149b736290b9@mail.gmail.com> On Wed, May 21, 2008 at 7:27 AM, seth vidal wrote: > Yes, the changes are not in effect, yet. I'm waiting on more .planet > files to be made before flicking the switch. > > sorry if that wasn't more clear. > > I'll post more about it shortly. Is our 'new' planet going to have ability that Gnome's planet has, so we as readers can disable specific feeds via client side custom stylesheet hackery? http://live.gnome.org/PlanetGnome -jef From jkeating at redhat.com Wed May 21 15:54:45 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 May 2008 11:54:45 -0400 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <1211335226.3768.1.camel@clockmaker.usersys.redhat.com> <20080520211137.67744ac3@vader.jdub.homelinux.org> <1211379900.29467.136.camel@localhost.localdomain> <20080521152022.GF1093879@hiwaay.net> <1211383722.8531.63.camel@localhost.localdomain> Message-ID: <1211385285.8531.65.camel@localhost.localdomain> On Wed, 2008-05-21 at 08:46 -0700, Christopher Stone wrote: > It would probably get more visibility in the CommonBugs wiki page. > When is the front page link going to switch over to f9 common bugs? Done. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From berrange at redhat.com Wed May 21 15:56:03 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 21 May 2008 16:56:03 +0100 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <1211319877.8531.40.camel@localhost.localdomain> Message-ID: <20080521155603.GG3915@redhat.com> On Wed, May 21, 2008 at 08:18:47AM -0700, Christopher Stone wrote: > On Wed, May 21, 2008 at 8:11 AM, Matej Cepl wrote: > > On Tue, 20 May 2008 14:51:08 -0700, Christopher Stone scripst: > >> nVidia can't do anything until xorg's ABI is *stable*. > > > > They can -- publish specs. Tell them they are cheating on you as your > > customer, when they don't tell you how to use the hardware you bought from > > them. > > Maybe my next card will be ATi, how is that driver doing? The last > I've heard it still has problems, but maybe it has improved, I don't > know. It worked out of the box with F9 on my IBM T60 laptop with r500 card. No 3d, but that's not a showstopper, and 3d support is progressing very rapidly for r500 cards too: http://airlied.livejournal.com/60149.html The xrandr stuff also works flawlessly with external monitors /projectors I've tried so far. In short ATI support is looking great thanks to the excellant work done by Xorg developers and with help from ATI's release of their hardware specs. Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From skvidal at fedoraproject.org Wed May 21 15:52:12 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 21 May 2008 11:52:12 -0400 Subject: changes at planet fedora In-Reply-To: <604aa7910805210852g546b286n73b7149b736290b9@mail.gmail.com> References: <1211214812.3095.0.camel@cutter> <4833CB46.4010005@nicubunu.ro> <1211383636.3074.20.camel@cutter> <604aa7910805210852g546b286n73b7149b736290b9@mail.gmail.com> Message-ID: <1211385132.3074.24.camel@cutter> On Wed, 2008-05-21 at 07:52 -0800, Jeff Spaleta wrote: > On Wed, May 21, 2008 at 7:27 AM, seth vidal wrote: > > Yes, the changes are not in effect, yet. I'm waiting on more .planet > > files to be made before flicking the switch. > > > > sorry if that wasn't more clear. > > > > I'll post more about it shortly. > > Is our 'new' planet going to have ability that Gnome's planet has, so > we as readers can disable specific feeds via client side custom > stylesheet hackery? > http://live.gnome.org/PlanetGnome > that's a neat trick, I will look at adding that since it takes very little server side to do. -sv From chris.stone at gmail.com Wed May 21 16:01:14 2008 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 21 May 2008 09:01:14 -0700 Subject: Xorg 1.5 missed the train? In-Reply-To: <1211385285.8531.65.camel@localhost.localdomain> References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <20080520211137.67744ac3@vader.jdub.homelinux.org> <1211379900.29467.136.camel@localhost.localdomain> <20080521152022.GF1093879@hiwaay.net> <1211383722.8531.63.camel@localhost.localdomain> <1211385285.8531.65.camel@localhost.localdomain> Message-ID: 2008/5/21 Jesse Keating : > On Wed, 2008-05-21 at 08:46 -0700, Christopher Stone wrote: >> It would probably get more visibility in the CommonBugs wiki page. >> When is the front page link going to switch over to f9 common bugs? > > Done. Okay, how about some short text like: The version of the X server shipped with Fedora 9 comes with a new ABI which is not yet compatible with some third party binary drivers such as nVidia. Then we could add some links for more information, I thought the ones drago posted were good: http://www.nvnews.net/vbulletin/showpost.php?p=1653299&postcount=9 http://www.nvnews.net/vbulletin/showpost.php?p=1656695&postcount=54 http://www.nvnews.net/vbulletin/showpost.php?p=1659061&postcount=3 If this sounds good to everyone, I'll add it. > > -- > Jesse Keating > Fedora -- Freedom? is a feature! > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From ndbecker2 at gmail.com Wed May 21 16:02:57 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Wed, 21 May 2008 12:02:57 -0400 Subject: QTDIR -> 3.3? Message-ID: pkg-config --variable=prefix qt-mt /usr/lib64/qt-3.3 Is this correct on F9? Shouldn't be qt4? This is used in /etc/profile.d/qt.sh From paul at all-the-johnsons.co.uk Wed May 21 16:06:34 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Wed, 21 May 2008 17:06:34 +0100 Subject: Evolution / gtk problem in rawhide Message-ID: <1211385994.5803.2.camel@T7.Linux> Hi, Is anyone else seeing this? Some emails appear in the preview screen and when you hit reply to be just grey screens and if, when composing an email, the edit pane requires scroll bars, anything past the area that needs the scroll bars also turns grey so you can't actually see what you're doing? I'm not sure if I should file this under GTK or Evolution. Using x86_64 TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From billcrawford1970 at gmail.com Wed May 21 16:17:25 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 21 May 2008 17:17:25 +0100 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <1211379900.29467.136.camel@localhost.localdomain> <20080521152022.GF1093879@hiwaay.net> <1211383722.8531.63.camel@localhost.localdomain> <1211385285.8531.65.camel@localhost.localdomain> Message-ID: <544eb990805210917y45a7df22hb867b7e8e027d474@mail.gmail.com> 2008/5/21 Christopher Stone : > The version of the X server shipped with Fedora 9 comes with a new ABI > which is not yet compatible with some third party binary drivers such > as nVidia. No, the point is that *the third party binary drivers* are *not yet compatible with the new ABI*. Please stop throwing mud now. From jspaleta at gmail.com Wed May 21 16:18:36 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 21 May 2008 08:18:36 -0800 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <48338811.3090700@gmail.com> <48338D79.9020304@gmail.com> <20080520220210.77f97a82@vader.jdub.homelinux.org> <1211340916.3307.2.camel@clockmaker.usersys.redhat.com> <4833B21C.2020807@gmail.com> Message-ID: <604aa7910805210918kdb695eepd493d9ead475e310@mail.gmail.com> On Wed, May 21, 2008 at 7:32 AM, Matej Cepl wrote: > Yeah, nobody knew -- except those who can take a look at http:// > gitweb.freedesktop.org/ For future upstream X.org releases, date tracking important milestone points, outside of git might be a PR win. It doesn't need to be as detailed as Fedora's schedule of events, if Xorg's process doesn't support that much structure and roadmapping. And its something that a hardcore developer doesn't need to do. I'll keep an eye out for the next Xorg release push, and volunteer to do the housekeeping with regard to milestone signposting outside of git, if Xorg upstream would find value with help doing that auxiliary task. Free free to punch me in the side of the head and remind me that I volunteered to do it, if I things start up without me having approached upstream directly. -jef From lemenkov at gmail.com Wed May 21 16:19:45 2008 From: lemenkov at gmail.com (Peter Lemenkov) Date: Wed, 21 May 2008 20:19:45 +0400 Subject: Known Bugzilla disadvantage (Was: Re: Evolution / gtk problem in rawhide) Message-ID: Helo 2008/5/21 Paul : > Hi, > > Is anyone else seeing this? > > Some emails appear in the preview screen and when you hit reply to be > just grey screens and if, when composing an email, the edit pane > requires scroll bars, anything past the area that needs the scroll bars > also turns grey so you can't actually see what you're doing? > > I'm not sure if I should file this under GTK or Evolution. Known Bugzilla disadvantage - you can't submit bug to many developer's teams (team "Evolution" and team "GTK"). Instead you will be forced to make some assumptions (probably wrong ones). On the other hand, Bugzilla 3.2 is coming so maybe some things will be easier? http://jons-thoughts.blogspot.com/2008/05/red-hat-bugzilla-32-beta1-up.html -- With best regards! From billcrawford1970 at gmail.com Wed May 21 16:20:58 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 21 May 2008 17:20:58 +0100 Subject: QTDIR -> 3.3? In-Reply-To: References: Message-ID: <544eb990805210920p5c0b92a3pd11bf380119e9f21@mail.gmail.com> 2008/5/21 Neal Becker : > pkg-config --variable=prefix qt-mt > /usr/lib64/qt-3.3 > > Is this correct on F9? Shouldn't be qt4? > > This is used in /etc/profile.d/qt.sh Nope: /usr/lib/pkgconfig/Qt.pc /usr/lib/pkgconfig/Qt3Support.pc /usr/lib/pkgconfig/QtAssistantClient.pc /usr/lib/pkgconfig/QtCore.pc /usr/lib/pkgconfig/QtDBus.pc /usr/lib/pkgconfig/QtGui.pc /usr/lib/pkgconfig/QtNetwork.pc /usr/lib/pkgconfig/QtOpenGL.pc /usr/lib/pkgconfig/QtScript.pc /usr/lib/pkgconfig/QtSql.pc /usr/lib/pkgconfig/QtSvg.pc /usr/lib/pkgconfig/QtTest.pc /usr/lib/pkgconfig/QtUiTools.pc /usr/lib/pkgconfig/QtXml.pc From lesmikesell at gmail.com Wed May 21 16:24:49 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 21 May 2008 11:24:49 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <20080520211137.67744ac3@vader.jdub.homelinux.org> <1211379900.29467.136.camel@localhost.localdomain> <20080521152022.GF1093879@hiwaay.net> <1211383722.8531.63.camel@localhost.localdomain> <1211385285.8531.65.camel@localhost.localdomain> Message-ID: <48344CD1.9030108@gmail.com> Christopher Stone wrote: > 2008/5/21 Jesse Keating : >> On Wed, 2008-05-21 at 08:46 -0700, Christopher Stone wrote: >>> It would probably get more visibility in the CommonBugs wiki page. >>> When is the front page link going to switch over to f9 common bugs? >> Done. > > Okay, how about some short text like: > > The version of the X server shipped with Fedora 9 comes with a new ABI > which is not yet compatible with some third party binary drivers such > as nVidia. > > Then we could add some links for more information, I thought the ones > drago posted were good: > http://www.nvnews.net/vbulletin/showpost.php?p=1653299&postcount=9 > http://www.nvnews.net/vbulletin/showpost.php?p=1656695&postcount=54 > http://www.nvnews.net/vbulletin/showpost.php?p=1659061&postcount=3 > > If this sounds good to everyone, I'll add it. Including the actual version number of the X that fedora is shipping would add a touch of honesty about the situation even if you prefer to leave out the 'pre-release' designation. -- Les Mikesell lesmikesell at gmail.com From lesmikesell at gmail.com Wed May 21 16:27:26 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 21 May 2008 11:27:26 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: <544eb990805210917y45a7df22hb867b7e8e027d474@mail.gmail.com> References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <1211379900.29467.136.camel@localhost.localdomain> <20080521152022.GF1093879@hiwaay.net> <1211383722.8531.63.camel@localhost.localdomain> <1211385285.8531.65.camel@localhost.localdomain> <544eb990805210917y45a7df22hb867b7e8e027d474@mail.gmail.com> Message-ID: <48344D6E.6000006@gmail.com> Bill Crawford wrote: > 2008/5/21 Christopher Stone : > >> The version of the X server shipped with Fedora 9 comes with a new ABI >> which is not yet compatible with some third party binary drivers such >> as nVidia. > > No, the point is that *the third party binary drivers* are *not yet > compatible with the new ABI*. Please stop throwing mud now. No, the point is that it is a pre-release version of X, shipped will full knowledge that it will break binary drivers that no reasonable person would expect to be modified to match yet. -- Les Mikesell lesmikesell at gmail.com From tmz at pobox.com Wed May 21 16:26:08 2008 From: tmz at pobox.com (Todd Zullinger) Date: Wed, 21 May 2008 12:26:08 -0400 Subject: QTDIR -> 3.3? In-Reply-To: References: Message-ID: <20080521162608.GB17727@inocybe.teonanacatl.org> Neal Becker wrote: > pkg-config --variable=prefix qt-mt > /usr/lib64/qt-3.3 > > Is this correct on F9? Shouldn't be qt4? > > This is used in /etc/profile.d/qt.sh Seeing that /etc/profile.d/qt.sh comes from qt3, I would say that returning /usr/lib64/qt-3.3 is the only sane thing to return. :) $ repoquery --whatprovides /etc/profile.d/qt.sh qt3-0:3.3.8b-12.fc9.i386 -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Don't look for me in daylight where robots all assemble. You'll find me in my dark world, in my smoke-filled temple. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From billcrawford1970 at gmail.com Wed May 21 16:28:48 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 21 May 2008 17:28:48 +0100 Subject: Xorg 1.5 missed the train? In-Reply-To: <604aa7910805210918kdb695eepd493d9ead475e310@mail.gmail.com> References: <48334163.4080709@magma.ca> <48338D79.9020304@gmail.com> <20080520220210.77f97a82@vader.jdub.homelinux.org> <1211340916.3307.2.camel@clockmaker.usersys.redhat.com> <4833B21C.2020807@gmail.com> <604aa7910805210918kdb695eepd493d9ead475e310@mail.gmail.com> Message-ID: <544eb990805210928r7f6d90e1x68f901ffb1f00405@mail.gmail.com> 2008/5/21 Jeff Spaleta : > For future upstream X.org releases, date tracking important milestone > points, outside of git might be a PR win. It doesn't need to be as > detailed as Fedora's schedule of events, if Xorg's process doesn't > support that much structure and roadmapping. And its something that a > hardcore developer doesn't need to do. I'll keep an eye out for the > next Xorg release push, and volunteer to do the housekeeping with > regard to milestone signposting outside of git, if Xorg upstream would > find value with help doing that auxiliary task. Free free to punch me > in the side of the head and remind me that I volunteered to do it, if > I things start up without me having approached upstream directly. Yes, but nVidia do have a full time employee who participates in X.org development. So they should have known about this. From jspaleta at gmail.com Wed May 21 16:29:15 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 21 May 2008 08:29:15 -0800 Subject: changes at planet fedora In-Reply-To: <1211385132.3074.24.camel@cutter> References: <1211214812.3095.0.camel@cutter> <4833CB46.4010005@nicubunu.ro> <1211383636.3074.20.camel@cutter> <604aa7910805210852g546b286n73b7149b736290b9@mail.gmail.com> <1211385132.3074.24.camel@cutter> Message-ID: <604aa7910805210929j77bc7223vab7454da99c26683@mail.gmail.com> On Wed, May 21, 2008 at 7:52 AM, seth vidal wrote: > that's a neat trick, I will look at adding that since it takes very > little server side to do. As much as I love seeing non-English speakers use aggregate on the planet because it really shows how global our community is..which is an important aspect of our community to celebrate and build on. I personally don't get a lot of value out some of those feeds day-to-day. So I would most likely hide a number feeds that I simply can't read. And then of course, I'd hide yours because of your dirty hippy save-the-whales-by-saving-the-planet-by-conserving-energy-by-not-cooking-whale-meat political agenda. You know what would be really clever, and this would be server-side, extending the planet concept so that we could have planet urls which aggregated all the feeds from people in a particular group. We'd have a global feed that was everything, but then a just aggregate feeds based on group membership as well. -jef"we should really be allowed to ranch moose up here as a commercial endeavor"spaleta From billcrawford1970 at gmail.com Wed May 21 16:29:48 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 21 May 2008 17:29:48 +0100 Subject: Xorg 1.5 missed the train? In-Reply-To: <48344CD1.9030108@gmail.com> References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <1211379900.29467.136.camel@localhost.localdomain> <20080521152022.GF1093879@hiwaay.net> <1211383722.8531.63.camel@localhost.localdomain> <1211385285.8531.65.camel@localhost.localdomain> <48344CD1.9030108@gmail.com> Message-ID: <544eb990805210929q145a8defwe355033ba071f447@mail.gmail.com> 2008/5/21 Les Mikesell : > Including the actual version number of the X that fedora is shipping would > add a touch of honesty about the situation even if you prefer to leave out > the 'pre-release' designation. No one is hiding it. It shows up in ...oh! look! yum tells you what version it is labelled as. So does X itself, when you start it. From jkeating at redhat.com Wed May 21 16:30:30 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 May 2008 12:30:30 -0400 Subject: Xorg 1.5 missed the train? In-Reply-To: <604aa7910805210918kdb695eepd493d9ead475e310@mail.gmail.com> References: <48334163.4080709@magma.ca> <48338811.3090700@gmail.com> <48338D79.9020304@gmail.com> <20080520220210.77f97a82@vader.jdub.homelinux.org> <1211340916.3307.2.camel@clockmaker.usersys.redhat.com> <4833B21C.2020807@gmail.com> <604aa7910805210918kdb695eepd493d9ead475e310@mail.gmail.com> Message-ID: <1211387430.8531.67.camel@localhost.localdomain> On Wed, 2008-05-21 at 08:18 -0800, Jeff Spaleta wrote: > For future upstream X.org releases, date tracking important milestone > points, outside of git might be a PR win. It doesn't need to be as > detailed as Fedora's schedule of events, if Xorg's process doesn't > support that much structure and roadmapping. And its something that a > hardcore developer doesn't need to do. I'll keep an eye out for the > next Xorg release push, and volunteer to do the housekeeping with > regard to milestone signposting outside of git, if Xorg upstream would > find value with help doing that auxiliary task. Free free to punch me > in the side of the head and remind me that I volunteered to do it, if > I things start up without me having approached upstream directly. Ajax did a talk about this at the last big X meeting, regarding better release practices and asking for some help I do believe. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From skvidal at fedoraproject.org Wed May 21 16:27:42 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 21 May 2008 12:27:42 -0400 Subject: changes at planet fedora In-Reply-To: <604aa7910805210929j77bc7223vab7454da99c26683@mail.gmail.com> References: <1211214812.3095.0.camel@cutter> <4833CB46.4010005@nicubunu.ro> <1211383636.3074.20.camel@cutter> <604aa7910805210852g546b286n73b7149b736290b9@mail.gmail.com> <1211385132.3074.24.camel@cutter> <604aa7910805210929j77bc7223vab7454da99c26683@mail.gmail.com> Message-ID: <1211387262.3074.26.camel@cutter> On Wed, 2008-05-21 at 08:29 -0800, Jeff Spaleta wrote: > On Wed, May 21, 2008 at 7:52 AM, seth vidal wrote: > > that's a neat trick, I will look at adding that since it takes very > > little server side to do. > > > As much as I love seeing non-English speakers use aggregate on the > planet because it really shows how global our community is..which is > an important aspect of our community to celebrate and build on. I > personally don't get a lot of value out some of those feeds > day-to-day. So I would most likely hide a number feeds that I simply > can't read. And then of course, I'd hide yours because of your dirty > hippy save-the-whales-by-saving-the-planet-by-conserving-energy-by-not-cooking-whale-meat > political agenda. > > You know what would be really clever, and this would be server-side, > extending the planet concept so that we could have planet urls which > aggregated all the feeds from people in a particular group. We'd have > a global feed that was everything, but then a just aggregate feeds > based on group membership as well. > That was already discussed as something for sub-groups of planets. The planet config builder I wrote should easily let us add .planet.somegroup files so we can aggregate that way. It will still need to be added as a web location but it lets the aggregate happen and be self-selecting. -sv From jspaleta at gmail.com Wed May 21 16:35:45 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 21 May 2008 08:35:45 -0800 Subject: Xorg 1.5 missed the train? In-Reply-To: <544eb990805210928r7f6d90e1x68f901ffb1f00405@mail.gmail.com> References: <48334163.4080709@magma.ca> <48338D79.9020304@gmail.com> <20080520220210.77f97a82@vader.jdub.homelinux.org> <1211340916.3307.2.camel@clockmaker.usersys.redhat.com> <4833B21C.2020807@gmail.com> <604aa7910805210918kdb695eepd493d9ead475e310@mail.gmail.com> <544eb990805210928r7f6d90e1x68f901ffb1f00405@mail.gmail.com> Message-ID: <604aa7910805210935p5d53a7enb5a05442fffb4b7f@mail.gmail.com> On Wed, May 21, 2008 at 8:28 AM, Bill Crawford wrote: > Yes, but nVidia do have a full time employee who participates in X.org > development. So they should have known about this. I'm not arguing that they shouldn't. What I'm arguing is. Easily accessible signposts would be an invaluable tool for people like you and me when we are attempting to correct opinions concerning the fundamental nature of the problem here. There is a transparent process already. I do not argue that it isn't. But perhaps there is still value to be found in enhancing the perception of transparency, next time around. -jef From billcrawford1970 at gmail.com Wed May 21 16:35:48 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 21 May 2008 17:35:48 +0100 Subject: Xorg 1.5 missed the train? In-Reply-To: <48344D6E.6000006@gmail.com> References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <20080521152022.GF1093879@hiwaay.net> <1211383722.8531.63.camel@localhost.localdomain> <1211385285.8531.65.camel@localhost.localdomain> <544eb990805210917y45a7df22hb867b7e8e027d474@mail.gmail.com> <48344D6E.6000006@gmail.com> Message-ID: <544eb990805210935k781bcbafn6165c3e03aa72d10@mail.gmail.com> 2008/5/21 Les Mikesell : > No, the point is that it is a pre-release version of X, shipped will full > knowledge that it will break binary drivers that no reasonable person would > expect to be modified to match yet. I don't know where to start with the logical fallacies in this but ... It's not "prerelease" in any sense except "the release not hasn't gone out yet". The upstream developers want this shipped, and have decided the ABI is complete. It could have been labelled "1.5" and the same thing would still be happening. It doesn't "break" binary drivers. Binary drivers compiled to work with an older version need modification to work correctly with it, but so do all the ones included with it and ... they have been, as they were available to modify. A reasonable person with knowledge of the development process would know about the "breakage" ahead of time and could have done the work to port their driver to the new, slightly modified interface (the changes are incremental for the most part, and the majority of the APIs and ABIs involved haven't really changed that much at all). They did have knowledge of all this (the X development community is hardly close-lipped about the changes; there are regular "heads up" type messages from e.g. Keith Packard about the changes to RandR and so on). This means that in actual fact, you are complaining (loudly) about the failure of nVidia to provide updated drivers for you new distribution, and expect "us" to provide "you" with a Fedora 9 but without the new graphics functionality which apparently a lot of people want. From jspaleta at gmail.com Wed May 21 16:36:41 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 21 May 2008 08:36:41 -0800 Subject: Xorg 1.5 missed the train? In-Reply-To: <1211387430.8531.67.camel@localhost.localdomain> References: <48334163.4080709@magma.ca> <48338D79.9020304@gmail.com> <20080520220210.77f97a82@vader.jdub.homelinux.org> <1211340916.3307.2.camel@clockmaker.usersys.redhat.com> <4833B21C.2020807@gmail.com> <604aa7910805210918kdb695eepd493d9ead475e310@mail.gmail.com> <1211387430.8531.67.camel@localhost.localdomain> Message-ID: <604aa7910805210936q13f2822drc9913f5643ef789a@mail.gmail.com> 2008/5/21 Jesse Keating : > Ajax did a talk about this at the last big X meeting, regarding better > release practices and asking for some help I do believe. Well if he needs housekeeping help, I'm really good at dishes and laundry. -jef From billcrawford1970 at gmail.com Wed May 21 16:41:53 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 21 May 2008 17:41:53 +0100 Subject: Xorg 1.5 missed the train? In-Reply-To: <604aa7910805210935p5d53a7enb5a05442fffb4b7f@mail.gmail.com> References: <48334163.4080709@magma.ca> <20080520220210.77f97a82@vader.jdub.homelinux.org> <1211340916.3307.2.camel@clockmaker.usersys.redhat.com> <4833B21C.2020807@gmail.com> <604aa7910805210918kdb695eepd493d9ead475e310@mail.gmail.com> <544eb990805210928r7f6d90e1x68f901ffb1f00405@mail.gmail.com> <604aa7910805210935p5d53a7enb5a05442fffb4b7f@mail.gmail.com> Message-ID: <544eb990805210941o47ff303l7fb34044054e4558@mail.gmail.com> 2008/5/21 Jeff Spaleta : > I'm not arguing that they shouldn't. What I'm arguing is. Easily > accessible signposts would be an invaluable tool for people like you > and me when we are attempting to correct opinions concerning the > fundamental nature of the problem here. There is a transparent > process already. I do not argue that it isn't. But perhaps there is > still value to be found in enhancing the perception of transparency, > next time around. Heh. Yeah, good point. Sorry for that. I meant to say "I agree with you completely although I think it's unnecessary because ...[what I wrote]". Mea cupla. > -jef -ogre From lesmikesell at gmail.com Wed May 21 16:42:36 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 21 May 2008 11:42:36 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: <544eb990805210929q145a8defwe355033ba071f447@mail.gmail.com> References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <1211379900.29467.136.camel@localhost.localdomain> <20080521152022.GF1093879@hiwaay.net> <1211383722.8531.63.camel@localhost.localdomain> <1211385285.8531.65.camel@localhost.localdomain> <48344CD1.9030108@gmail.com> <544eb990805210929q145a8defwe355033ba071f447@mail.gmail.com> Message-ID: <483450FC.7010405@gmail.com> Bill Crawford wrote: > 2008/5/21 Les Mikesell : > >> Including the actual version number of the X that fedora is shipping would >> add a touch of honesty about the situation even if you prefer to leave out >> the 'pre-release' designation. > > No one is hiding it. It shows up in ...oh! look! yum tells you what > version it is labelled as. So does X itself, when you start it. But that's kind of after the fact for people who don't want to install fedora until some of the problems are worked out. -- Les Mikesell lesmikesell at gmail.com From chris.stone at gmail.com Wed May 21 16:44:22 2008 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 21 May 2008 09:44:22 -0700 Subject: Xorg 1.5 missed the train? In-Reply-To: <544eb990805210917y45a7df22hb867b7e8e027d474@mail.gmail.com> References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <1211379900.29467.136.camel@localhost.localdomain> <20080521152022.GF1093879@hiwaay.net> <1211383722.8531.63.camel@localhost.localdomain> <1211385285.8531.65.camel@localhost.localdomain> <544eb990805210917y45a7df22hb867b7e8e027d474@mail.gmail.com> Message-ID: On Wed, May 21, 2008 at 9:17 AM, Bill Crawford wrote: > 2008/5/21 Christopher Stone : > >> The version of the X server shipped with Fedora 9 comes with a new ABI >> which is not yet compatible with some third party binary drivers such >> as nVidia. > > No, the point is that *the third party binary drivers* are *not yet > compatible with the new ABI*. Please stop throwing mud now. No mud slinging was intended sir. How is this? Some hardware vendors, such as nVidia, have not yet provided drivers which are compatible with the new Xorg ABI shipped with Fedora 9. More information for nVidia users can be found here: http://www.nvnews.net/vbulletin/showpost.php?p=1653299&postcount=9 http://www.nvnews.net/vbulletin/showpost.php?p=1656695&postcount=54 http://www.nvnews.net/vbulletin/showpost.php?p=1659061&postcount=3 From jspaleta at gmail.com Wed May 21 16:44:44 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 21 May 2008 08:44:44 -0800 Subject: changes at planet fedora In-Reply-To: <1211387262.3074.26.camel@cutter> References: <1211214812.3095.0.camel@cutter> <4833CB46.4010005@nicubunu.ro> <1211383636.3074.20.camel@cutter> <604aa7910805210852g546b286n73b7149b736290b9@mail.gmail.com> <1211385132.3074.24.camel@cutter> <604aa7910805210929j77bc7223vab7454da99c26683@mail.gmail.com> <1211387262.3074.26.camel@cutter> Message-ID: <604aa7910805210944l6cd3f02clc31e48e8a0fc3347@mail.gmail.com> On Wed, May 21, 2008 at 8:27 AM, seth vidal wrote: > That was already discussed as something for sub-groups of planets. The > planet config builder I wrote should easily let us add .planet.somegroup > files so we can aggregate that way. It will still need to be added as a > web location but it lets the aggregate happen and be self-selecting. Man this sucks... I use to pride myself at thinking ahead of the curve....now it seems I'm way behind. Not exactly the implementation I had in mind..but I'm not an implementation snob. If we can have a aggregate feed for every SIG using the new automation... that will be very interesting as a way for SIGs to communicate with users...in my SIG-centric world view. -jef"You've earned a whale blubber sandwich"spaleta From lesmikesell at gmail.com Wed May 21 16:52:13 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 21 May 2008 11:52:13 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: <544eb990805210935k781bcbafn6165c3e03aa72d10@mail.gmail.com> References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <20080521152022.GF1093879@hiwaay.net> <1211383722.8531.63.camel@localhost.localdomain> <1211385285.8531.65.camel@localhost.localdomain> <544eb990805210917y45a7df22hb867b7e8e027d474@mail.gmail.com> <48344D6E.6000006@gmail.com> <544eb990805210935k781bcbafn6165c3e03aa72d10@mail.gmail.com> Message-ID: <4834533D.7010007@gmail.com> Bill Crawford wrote: >> No, the point is that it is a pre-release version of X, shipped will full >> knowledge that it will break binary drivers that no reasonable person would >> expect to be modified to match yet. > > I don't know where to start with the logical fallacies in this but ... > > It's not "prerelease" in any sense except "the release not hasn't gone > out yet". What is it that would suggest that it is finalized to a manager that might want to commit resources to writing a driver his company will have to support? > The upstream developers want this shipped, and have decided > the ABI is complete. It could have been labelled "1.5" and the same > thing would still be happening. No, it wouldn't be the same if that label had been applied and announced publicly in time for others to coordinate with a shipping date. > It doesn't "break" binary drivers. Binary drivers compiled to work > with an older version need modification to work correctly with it, Errr, how is that different from breaking? Interfaces work or not. > This means that in actual fact, you are complaining (loudly) about the > failure of nVidia to provide updated drivers for you new distribution, > and expect "us" to provide "you" with a Fedora 9 but without the new > graphics functionality which apparently a lot of people want. All I expect is a reasonable chance for others to coordinate. This is like shipping a power cord with a new plug style before announcing the matching standard for the socket where you are supposed to plug it in. -- Les Mikesell lesmikesell at gmail.com From mbarnes at redhat.com Wed May 21 16:53:19 2008 From: mbarnes at redhat.com (Matthew Barnes) Date: Wed, 21 May 2008 12:53:19 -0400 Subject: Evolution / gtk problem in rawhide In-Reply-To: <1211385994.5803.2.camel@T7.Linux> References: <1211385994.5803.2.camel@T7.Linux> Message-ID: <1211388799.23725.4.camel@localhost.localdomain> On Wed, 2008-05-21 at 17:06 +0100, Paul wrote: > Some emails appear in the preview screen and when you hit reply to be > just grey screens and if, when composing an email, the edit pane > requires scroll bars, anything past the area that needs the scroll bars > also turns grey so you can't actually see what you're doing? > > I'm not sure if I should file this under GTK or Evolution. I've reread that a few times now and I'm still not sure I understand what you're describing. Can you add screenshots to the Bugzilla report when you file it? I'd file it against gtkhtml3. Matthew Barnes From billcrawford1970 at gmail.com Wed May 21 16:53:20 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 21 May 2008 17:53:20 +0100 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <20080521152022.GF1093879@hiwaay.net> <1211383722.8531.63.camel@localhost.localdomain> <1211385285.8531.65.camel@localhost.localdomain> <544eb990805210917y45a7df22hb867b7e8e027d474@mail.gmail.com> Message-ID: <544eb990805210953r235ff23fy3c5c8a82d93039b2@mail.gmail.com> 2008/5/21 Christopher Stone : > On Wed, May 21, 2008 at 9:17 AM, Bill Crawford >> No, the point is that *the third party binary drivers* are *not yet >> compatible with the new ABI*. Please stop throwing mud now. > No mud slinging was intended sir. How is this? Much better, thanks. Sorry for sounding so personal, I just ... well, this is more accurate :o) I do understand the frustration (I've a couple of nv cards sitting at home, waiting to go in a new machine; I'm hoping the nouveau project will come up with something good for 3d before too long ...). > Some hardware vendors, such as nVidia, have not yet provided drivers > which are compatible with the new Xorg ABI shipped with Fedora 9. > More information for nVidia users can be found here: > > http://www.nvnews.net/vbulletin/showpost.php?p=1653299&postcount=9 > http://www.nvnews.net/vbulletin/showpost.php?p=1656695&postcount=54 > http://www.nvnews.net/vbulletin/showpost.php?p=1659061&postcount=3 From billcrawford1970 at gmail.com Wed May 21 16:54:27 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 21 May 2008 17:54:27 +0100 Subject: Xorg 1.5 missed the train? In-Reply-To: <483450FC.7010405@gmail.com> References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <20080521152022.GF1093879@hiwaay.net> <1211383722.8531.63.camel@localhost.localdomain> <1211385285.8531.65.camel@localhost.localdomain> <48344CD1.9030108@gmail.com> <544eb990805210929q145a8defwe355033ba071f447@mail.gmail.com> <483450FC.7010405@gmail.com> Message-ID: <544eb990805210954m284ece69m29306868a1bd7961@mail.gmail.com> 2008/5/21 Les Mikesell : > But that's kind of after the fact for people who don't want to install > fedora until some of the problems are worked out. It's already well established that the majority of people don't read the release notes before installing anyway, so it's kinda moot. From markg85 at gmail.com Wed May 21 16:58:55 2008 From: markg85 at gmail.com (Mark) Date: Wed, 21 May 2008 18:58:55 +0200 Subject: changes at planet fedora In-Reply-To: <409676c70805210502p8c6d7d9j79df72b6a58948cd@mail.gmail.com> References: <1211214812.3095.0.camel@cutter> <6e24a8e80805201301r44a241bdr9b2263052fe1fd8b@mail.gmail.com> <6e24a8e80805201550o12531af3ye6692f9571cb5230@mail.gmail.com> <48335785.4050800@fedoraproject.org> <20080520201228.3dfb45b6@vader.jdub.homelinux.org> <4833CCC3.1050405@nicubunu.ro> <4833CFA7.9000703@nigelj.com> <6e24a8e80805210424nd504e3dxedc5551df2c8896f@mail.gmail.com> <409676c70805210502p8c6d7d9j79df72b6a58948cd@mail.gmail.com> Message-ID: <6e24a8e80805210958v223109cdr7300ca6872968d07@mail.gmail.com> 2008/5/21 Trond Danielsen : > 2008/5/21 Mark : >> That basically that everyone that is a member of FAS becomes something >> like an Admin on the fedora planet.. they can add as much blogs as >> they want (and probably remove tthe ones they added as well) which >> just means he is an admin over the entered blog urls. >> >> I find it verry strange if this is what you guys want.. > > I find this lack of trust in Fedora contributors very strange; has it > not occurred to you that the powers granted by cvs access, bugzilla > accounts and mailing list membership can do far more harm to the > community than a hostile blog aggregated on planet F? Admins are still > around to clear things out if lets say I go mad and start adding all > sorts of blogs that post offensive content to planet F, but until then > I believe that people who sign up to become a Fedora contributor do it > to improve Fedora and not the opposite. > > Best Regards, > -- > Trond Danielsen > I thrust the fedora community! I've just seen abusive things earlier when people get to much rights and would hate to see that happen on planet fedora. From billcrawford1970 at gmail.com Wed May 21 17:01:27 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 21 May 2008 18:01:27 +0100 Subject: Xorg 1.5 missed the train? In-Reply-To: <4834533D.7010007@gmail.com> References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <1211383722.8531.63.camel@localhost.localdomain> <1211385285.8531.65.camel@localhost.localdomain> <544eb990805210917y45a7df22hb867b7e8e027d474@mail.gmail.com> <48344D6E.6000006@gmail.com> <544eb990805210935k781bcbafn6165c3e03aa72d10@mail.gmail.com> <4834533D.7010007@gmail.com> Message-ID: <544eb990805211001q75c28580k8b344b638451f223@mail.gmail.com> 2008/5/21 Les Mikesell : > What is it that would suggest that it is finalized to a manager that might > want to commit resources to writing a driver his company will have to > support? So why should "Fedora" commit to supporting "binary driver Foo" before their release is ready? > No, it wouldn't be the same if that label had been applied and announced > publicly in time for others to coordinate with a shipping date. You keep saying "publicly" but for the company concerned, who will have to make their driver work with the ABI in question, it being in the X server code base and discussed on the mailing lists (which they do have access to) is reasonable enough information for them to go on. > Errr, how is that different from breaking? Interfaces work or not. It's very different. The driver concerned will continue to work with the server ABI it was built to work with. Noone has mandated that every X11 server in the world be updated tomorrow night at midnight! In other words, it's old news to most, no one is forcing you to use this new server and "break" your drivers. Of course, you *could* have used hardware with open source driver support (that is updated already in the new X.org code base), but noone is forcing you to do so. > All I expect is a reasonable chance for others to coordinate. This is like > shipping a power cord with a new plug style before announcing the matching > standard for the socket where you are supposed to plug it in. Not so. In particular, noone is forcing you to change the existing sockets, and the new design was settled on quite some time ago. The people producing the plug are well aware of this process and have chosen to not update their plug design to match yet, ... and I have really had enough of these analogies even if you haven't. From mbarnes at redhat.com Wed May 21 17:04:40 2008 From: mbarnes at redhat.com (Matthew Barnes) Date: Wed, 21 May 2008 13:04:40 -0400 Subject: Known Bugzilla disadvantage (Was: Re: Evolution / gtk problem in rawhide) In-Reply-To: References: Message-ID: <1211389480.23725.14.camel@localhost.localdomain> On Wed, 2008-05-21 at 20:19 +0400, Peter Lemenkov wrote: > 2008/5/21 Paul : > > I'm not sure if I should file this under GTK or Evolution. > > Known Bugzilla disadvantage - you can't submit bug to many developer's > teams (team "Evolution" and team "GTK"). Instead you will be forced to > make some assumptions (probably wrong ones). May as well add the "X" and "Kernel" teams while you're at it. I'm sure they'd appreciate being spammed about Evolution bugs. It's not a big deal to reassign bugs to the appropriate component or maintainer. I'd actually /prefer/ reporters file bugs against the application where the bug occurred. It will trickle down to the right set of eyeballs in due time. Matthew Barnes From chris.stone at gmail.com Wed May 21 17:05:53 2008 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 21 May 2008 10:05:53 -0700 Subject: Xorg 1.5 missed the train? In-Reply-To: <544eb990805210953r235ff23fy3c5c8a82d93039b2@mail.gmail.com> References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <20080521152022.GF1093879@hiwaay.net> <1211383722.8531.63.camel@localhost.localdomain> <1211385285.8531.65.camel@localhost.localdomain> <544eb990805210917y45a7df22hb867b7e8e027d474@mail.gmail.com> <544eb990805210953r235ff23fy3c5c8a82d93039b2@mail.gmail.com> Message-ID: On Wed, May 21, 2008 at 9:53 AM, Bill Crawford wrote: > Much better, thanks. Okay added: http://fedoraproject.org/wiki/Bugs/F9Common My wiki editing skillz are not the best, so anyone feel free to improve on what I've written. It is a wiki after all. Thanks. From nicolas.mailhot at laposte.net Wed May 21 17:12:00 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 21 May 2008 19:12:00 +0200 (CEST) Subject: Xorg 1.5 missed the train? In-Reply-To: <4834533D.7010007@gmail.com> References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <20080521152022.GF1093879@hiwaay.net> <1211383722.8531.63.camel@localhost.localdomain> <1211385285.8531.65.camel@localhost.localdomain> <544eb990805210917y45a7df22hb867b7e8e027d474@mail.gmail.com> <48344D6E.6000006@gmail.com> <544eb990805210935k781bcbafn6165c3e03aa72d10@mail.gmail.com> <4834533D.7010007@gmail.com> Message-ID: <23519.192.54.193.57.1211389920.squirrel@rousalka.dyndns.org> Le Mer 21 mai 2008 18:52, Les Mikesell a ?crit : > All I expect is a reasonable chance for others to coordinate. This is > like shipping a power cord with a new plug style before announcing the > matching standard for the socket where you are supposed to plug it in. No new plug standard is ever finalized before a few companies try to manufacture it. Manufacturers are not stupid. They do exactly the same as xorg: a new design is prepared in common by interested parties, they agree among themselves it's almost cooked, some or all of them try to create products with it, the feedback from those first runs is used to correct problems on the design, and then the final "standard" and shipping products are announced at about the same time. And then sometimes market pressure means some of the first series are shipped before the standard is 100% finalized (that's for real hardware products, with real material distribution logistics problems, not something you can slap on a web site in 30s). Only very stupid engineers commit to a standard before any line of code or any product series was started. You're blinding yourself. Xorg did nothing wrong. Nvidia is late to the party (as usual) and you're gullible enough to believe its cartoon-level excuses. -- Nicolas Mailhot From lesmikesell at gmail.com Wed May 21 17:27:08 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 21 May 2008 12:27:08 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: <544eb990805211001q75c28580k8b344b638451f223@mail.gmail.com> References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <1211383722.8531.63.camel@localhost.localdomain> <1211385285.8531.65.camel@localhost.localdomain> <544eb990805210917y45a7df22hb867b7e8e027d474@mail.gmail.com> <48344D6E.6000006@gmail.com> <544eb990805210935k781bcbafn6165c3e03aa72d10@mail.gmail.com> <4834533D.7010007@gmail.com> <544eb990805211001q75c28580k8b344b638451f223@mail.gmail.com> Message-ID: <48345B6C.3030204@gmail.com> Bill Crawford wrote: > >> What is it that would suggest that it is finalized to a manager that might >> want to commit resources to writing a driver his company will have to >> support? > > So why should "Fedora" commit to supporting "binary driver Foo" before > their release is ready? That has nothing to do with what I said. I'm suggesting that fedora should ship with interfaces that are publicized as standard, and allow time for changes in this standard to propagate before shipping something different from the standard. This has nothing to do with supporting anything or anyone. It is common decency in interaction. >> No, it wouldn't be the same if that label had been applied and announced >> publicly in time for others to coordinate with a shipping date. > > You keep saying "publicly" but for the company concerned, who will > have to make their driver work with the ABI in question, it being in > the X server code base and discussed on the mailing lists (which they > do have access to) is reasonable enough information for them to go on. Do you have the authority to speak for them? It just does not sound like a reasonable business decision to expect anyone to make. >> Errr, how is that different from breaking? Interfaces work or not. > > It's very different. The driver concerned will continue to work with > the server ABI it was built to work with. Noone has mandated that > every X11 server in the world be updated tomorrow night at midnight! If you mean that, you shouldn't be shipping one that makes this demand. > In other words, it's old news to most, no one is forcing you to use > this new server and "break" your drivers. Of course, you *could* have > used hardware with open source driver support (that is updated already > in the new X.org code base), but noone is forcing you to do so. Unless you install fedora, which doesn't mention that it shipped a pre-release. >> All I expect is a reasonable chance for others to coordinate. This is like >> shipping a power cord with a new plug style before announcing the matching >> standard for the socket where you are supposed to plug it in. > > Not so. In particular, noone is forcing you to change the existing > sockets, and the new design was settled on quite some time ago. The > people producing the plug are well aware of this process and have > chosen to not update their plug design to match yet, ... and I have > really had enough of these analogies even if you haven't. It's not typical to update products to match a new standard before the standard in question is finalized, wireless-N notwithstanding. -- Les Mikesell lesmikesell at gmail.com From angray at beeb.net Wed May 21 17:27:47 2008 From: angray at beeb.net (Aaron Gray) Date: Wed, 21 May 2008 18:27:47 +0100 Subject: [F9][rawhide][regression] controllers DAC960 and sym53c8xx are not detected anymore Message-ID: <006101c8bb67$fd36c5f0$0200a8c0@ze4427wm> Fedora 9 and rawhide are not detecting Mylex DAC960 and LSI Corp. sym53c8xx SCSI controllers. These devices are detected and run fine on FC 6, 7 and 8. Attached are :- - dmesg - lspci - cat /proc/interrupts from FC8 installation. Thanks, Aaron -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: proc-interrupts.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dmesg.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lspci.txt URL: From lesmikesell at gmail.com Wed May 21 17:32:44 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 21 May 2008 12:32:44 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: <23519.192.54.193.57.1211389920.squirrel@rousalka.dyndns.org> References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <20080521152022.GF1093879@hiwaay.net> <1211383722.8531.63.camel@localhost.localdomain> <1211385285.8531.65.camel@localhost.localdomain> <544eb990805210917y45a7df22hb867b7e8e027d474@mail.gmail.com> <48344D6E.6000006@gmail.com> <544eb990805210935k781bcbafn6165c3e03aa72d10@mail.gmail.com> <4834533D.7010007@gmail.com> <23519.192.54.193.57.1211389920.squirrel@rousalka.dyndns.org> Message-ID: <48345CBC.40508@gmail.com> Nicolas Mailhot wrote: > >> All I expect is a reasonable chance for others to coordinate. This is >> like shipping a power cord with a new plug style before announcing the >> matching standard for the socket where you are supposed to plug it in. > > No new plug standard is ever finalized before a few companies try to > manufacture it. Manufacturers are not stupid. They do exactly the same > as xorg: a new design is prepared in common by interested parties, > they agree among themselves it's almost cooked, some or all of them > try to create products with it, the feedback from those first runs is > used to correct problems on the design, and then the final "standard" > and shipping products are announced at about the same time. And then > sometimes market pressure means some of the first series are shipped > before the standard is 100% finalized (that's for real hardware > products, with real material distribution logistics problems, not > something you can slap on a web site in 30s). > > Only very stupid engineers commit to a standard before any line of > code or any product series was started. You're blinding yourself. Xorg > did nothing wrong. I don't have a problem with Xorg taking any amount of time they want. The problem is in fedora shipping a pre-release - or perhaps even more so in their claim of knowing that the ABI is finalized before it is in fact published as a standard. > Nvidia is late to the party (as usual) and you're > gullible enough to believe its cartoon-level excuses. I believe in release numbers. If it is really ready, make it official. If not, don't ship it. -- Les Mikesell lesmikesell at gmail.com From stickster at gmail.com Wed May 21 17:34:18 2008 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 21 May 2008 13:34:18 -0400 Subject: Xorg 1.5 missed the train? In-Reply-To: <20080521151159.GA5891@orient.maison.lan> References: <48334F03.6070203@fedoraproject.org> <35207.75.164.221.130.1211322487.squirrel@clueserver.org> <1218b5bc0805201625p21ba80b9y9cffd6eeb7fcec9b@mail.gmail.com> <48335FC0.2070806@gmail.com> <4833C117.5090007@gmail.com> <4833C4B9.3020105@gmail.com> <1218b5bc0805210138l4b508c05x6dc1d90fca9b25e3@mail.gmail.com> <20080521091906.GA3918@orient.maison.lan> <1211375307.1249.35.camel@gilboa-home-dev.localdomain> <483420D0.7040008@nigelj.com> <20080521151159.GA5891@orient.maison.lan> Message-ID: <1211391258.1380.128.camel@victoria> On Wed, 2008-05-21 at 17:11 +0200, Emmanuel Seyman wrote: > * Nigel Jones [21/05/2008 16:44] : > > > > nVidia have tried to blame everything on XOrg and "other people" which is > > exactly what is outlined in Emmanuel's e-mail. > > It's actually the Nvidia users who seem to want to blame everything > on FLOSS developers and distributions. > > I'm not actually opposed to this (apart from the fact that it's... , you > know, wrong) but I'm always surprised at the amount of passion they can > put into defending a vendor that has locked them into the situation > they're spending so much time and energy complaining about. Stockholm Syndrome. http://en.wikipedia.org/wiki/Stockholm_syndrome -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at fedoraproject.org Wed May 21 17:35:17 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 21 May 2008 13:35:17 -0400 Subject: changes at planet fedora In-Reply-To: <6e24a8e80805210958v223109cdr7300ca6872968d07@mail.gmail.com> References: <1211214812.3095.0.camel@cutter> <6e24a8e80805201301r44a241bdr9b2263052fe1fd8b@mail.gmail.com> <6e24a8e80805201550o12531af3ye6692f9571cb5230@mail.gmail.com> <48335785.4050800@fedoraproject.org> <20080520201228.3dfb45b6@vader.jdub.homelinux.org> <4833CCC3.1050405@nicubunu.ro> <4833CFA7.9000703@nigelj.com> <6e24a8e80805210424nd504e3dxedc5551df2c8896f@mail.gmail.com> <409676c70805210502p8c6d7d9j79df72b6a58948cd@mail.gmail.com> <6e24a8e80805210958v223109cdr7300ca6872968d07@mail.gmail.com> Message-ID: <1211391317.3559.1.camel@cutter> On Wed, 2008-05-21 at 18:58 +0200, Mark wrote: > 2008/5/21 Trond Danielsen : > > 2008/5/21 Mark : > >> That basically that everyone that is a member of FAS becomes something > >> like an Admin on the fedora planet.. they can add as much blogs as > >> they want (and probably remove tthe ones they added as well) which > >> just means he is an admin over the entered blog urls. > >> > >> I find it verry strange if this is what you guys want.. > > > > I find this lack of trust in Fedora contributors very strange; has it > > not occurred to you that the powers granted by cvs access, bugzilla > > accounts and mailing list membership can do far more harm to the > > community than a hostile blog aggregated on planet F? Admins are still > > around to clear things out if lets say I go mad and start adding all > > sorts of blogs that post offensive content to planet F, but until then > > I believe that people who sign up to become a Fedora contributor do it > > to improve Fedora and not the opposite. > > > > Best Regards, > > -- > > Trond Danielsen > > > > I thrust the fedora community! > I've just seen abusive things earlier when people get to much rights > and would hate to see that happen on planet fedora. Encouraging speech means you sometimes have to put up with some bullshit, too. Instead of trying to build-in prohibitions to it I think it is best to respond on a case-by-case issue. We've built-in configuration to let us quickly pull problematic feeds if we so choose. -sv From billcrawford1970 at gmail.com Wed May 21 17:47:28 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 21 May 2008 18:47:28 +0100 Subject: Xorg 1.5 missed the train? In-Reply-To: <48345B6C.3030204@gmail.com> References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <1211385285.8531.65.camel@localhost.localdomain> <544eb990805210917y45a7df22hb867b7e8e027d474@mail.gmail.com> <48344D6E.6000006@gmail.com> <544eb990805210935k781bcbafn6165c3e03aa72d10@mail.gmail.com> <4834533D.7010007@gmail.com> <544eb990805211001q75c28580k8b344b638451f223@mail.gmail.com> <48345B6C.3030204@gmail.com> Message-ID: <544eb990805211047l3f9cb8e3pa8acf93f9cfd93fb@mail.gmail.com> 2008/5/21 Les Mikesell : > Bill Crawford wrote: >> So why should "Fedora" commit to supporting "binary driver Foo" before >> their release is ready? > > That has nothing to do with what I said. I'm suggesting that fedora should > ship with interfaces that are publicized as standard, and allow time for > changes in this standard to propagate before shipping something different > from the standard. This has nothing to do with supporting anything or > anyone. It is common decency in interaction. So in other words, Fedora must always be ... what, at least six months behind the times, or something? >> You keep saying "publicly" but for the company concerned, who will >> have to make their driver work with the ABI in question, it being in >> the X server code base and discussed on the mailing lists (which they >> do have access to) is reasonable enough information for them to go on. > > Do you have the authority to speak for them? It just does not sound like a > reasonable business decision to expect anyone to make. Huh? I'm pointing out that they speak for themselves. You're just making argument for the sake of it now. Why should anyone be held hostage to nVidia's "business decisions"? Least of all the people developing the X server, who manage to work quite well with others. Not their fault if a certain company won't play well. >> It's very different. The driver concerned will continue to work with >> the server ABI it was built to work with. Noone has mandated that >> every X11 server in the world be updated tomorrow night at midnight! > > If you mean that, you shouldn't be shipping one that makes this demand. Uh ... "I" am not doing any such thing; and in case, "Fedora" is not making any such demand by shipping this. If "you" choose to update, that's your decision, not Fedora's. Nowhere is anyone mandating that all X11 servers be updated (and your sentence above demonstrates either a deliberate refusal to understand, or a real nerve). > Unless you install fedora, which doesn't mention that it shipped a > pre-release. It's quite apparent that the situation would still have arisen even if 1.5 had made the release date for Fedora, as mentioned elsewhere in this thread was a claim that nVidia want to see the new thing shipped on a distro before committing to it. So, this is now irrelevant for the discussion (because it does not materially change the outcome of the drivers not being ready at F9 release time). Thanks, you just made the discussion easier. >> Not so. In particular, noone is forcing you to change the existing >> sockets, and the new design was settled on quite some time ago. The >> people producing the plug are well aware of this process and have >> chosen to not update their plug design to match yet, ... and I have >> really had enough of these analogies even if you haven't. > > It's not typical to update products to match a new standard before the > standard in question is finalized, wireless-N notwithstanding. This has been answered elsewhere already. From jonstanley at gmail.com Wed May 21 17:49:04 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Wed, 21 May 2008 13:49:04 -0400 Subject: [F9][rawhide][regression] controllers DAC960 and sym53c8xx are not detected anymore In-Reply-To: <006101c8bb67$fd36c5f0$0200a8c0@ze4427wm> References: <006101c8bb67$fd36c5f0$0200a8c0@ze4427wm> Message-ID: Please file this in bugzilla (https://bugzilla.redhat.com) Thanks! -Jon 2008/5/21 Aaron Gray : > Fedora 9 and rawhide are not detecting Mylex DAC960 and LSI Corp. sym53c8xx > SCSI controllers. These devices are detected and run fine on FC 6, 7 and 8. > > Attached are :- > > - dmesg > - lspci > - cat /proc/interrupts > > from FC8 installation. > > Thanks, > > Aaron > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Jon Stanley Fedora Bug Wrangler jstanley at fedoraproject.org From billcrawford1970 at gmail.com Wed May 21 17:52:34 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 21 May 2008 18:52:34 +0100 Subject: Xorg 1.5 missed the train? In-Reply-To: <48345CBC.40508@gmail.com> References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <1211385285.8531.65.camel@localhost.localdomain> <544eb990805210917y45a7df22hb867b7e8e027d474@mail.gmail.com> <48344D6E.6000006@gmail.com> <544eb990805210935k781bcbafn6165c3e03aa72d10@mail.gmail.com> <4834533D.7010007@gmail.com> <23519.192.54.193.57.1211389920.squirrel@rousalka.dyndns.org> <48345CBC.40508@gmail.com> Message-ID: <544eb990805211052l773a3c59p5b811960ffbd574e@mail.gmail.com> 2008/5/21 Les Mikesell : > I don't have a problem with Xorg taking any amount of time they want. The > problem is in fedora shipping a pre-release - or perhaps even more so in > their claim of knowing that the ABI is finalized before it is in fact > published as a standard. The X server ABI is not "published as a standard" like e.g. the standards for electrical goods. You are comparing apples and oranges, quite intentionally, with the intent of suggesting the X developers should be beholden to the way a certain company wants to conduct its driver releases. Why? >> Nvidia is late to the party (as usual) and you're >> gullible enough to believe its cartoon-level excuses. > > I believe in release numbers. If it is really ready, make it official. If > not, don't ship it. And again, you have no point besides this "it's not an official release number" yet (again) it's already been answered in this thread; they want to see it *shipped*. And now it's been shipped (which supposedly makes it more likely they'll update their drivers) you are *complaining* about this. If you want to be able to use hardware immediately with a new product, buy hardware that's supported by open source drivers and whose designers and manufacturers provide information (or even development resources) to support that process. Like, for example, another two or three big players in this market at the moment. From jspaleta at gmail.com Wed May 21 18:01:08 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 21 May 2008 10:01:08 -0800 Subject: Xorg 1.5 missed the train? In-Reply-To: <48344CD1.9030108@gmail.com> References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <1211379900.29467.136.camel@localhost.localdomain> <20080521152022.GF1093879@hiwaay.net> <1211383722.8531.63.camel@localhost.localdomain> <1211385285.8531.65.camel@localhost.localdomain> <48344CD1.9030108@gmail.com> Message-ID: <604aa7910805211101o58a3a96w194004293f47aad3@mail.gmail.com> On Wed, May 21, 2008 at 8:24 AM, Les Mikesell wrote: > Including the actual version number of the X that fedora is shipping would > add a touch of honesty about the situation even if you prefer to leave out > the 'pre-release' designation. Point of fact... our release notes DO mention its the 1.4.99 release. http://docs.fedoraproject.org/release-notes/f9/en_US/sn-Xorg.html -jef"Look on the side of the road! A dead horse! Let's beat it!"spaleta From lesmikesell at gmail.com Wed May 21 18:02:05 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 21 May 2008 13:02:05 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: <544eb990805211047l3f9cb8e3pa8acf93f9cfd93fb@mail.gmail.com> References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <1211385285.8531.65.camel@localhost.localdomain> <544eb990805210917y45a7df22hb867b7e8e027d474@mail.gmail.com> <48344D6E.6000006@gmail.com> <544eb990805210935k781bcbafn6165c3e03aa72d10@mail.gmail.com> <4834533D.7010007@gmail.com> <544eb990805211001q75c28580k8b344b638451f223@mail.gmail.com> <48345B6C.3030204@gmail.com> <544eb990805211047l3f9cb8e3pa8acf93f9cfd93fb@mail.gmail.com> Message-ID: <4834639D.1000509@gmail.com> Bill Crawford wrote: > >>> So why should "Fedora" commit to supporting "binary driver Foo" before >>> their release is ready? >> That has nothing to do with what I said. I'm suggesting that fedora should >> ship with interfaces that are publicized as standard, and allow time for >> changes in this standard to propagate before shipping something different >> from the standard. This has nothing to do with supporting anything or >> anyone. It is common decency in interaction. > > So in other words, Fedora must always be ... what, at least six months > behind the times, or something? A month, maybe... >>> You keep saying "publicly" but for the company concerned, who will >>> have to make their driver work with the ABI in question, it being in >>> the X server code base and discussed on the mailing lists (which they >>> do have access to) is reasonable enough information for them to go on. >> Do you have the authority to speak for them? It just does not sound like a >> reasonable business decision to expect anyone to make. > > Huh? I'm pointing out that they speak for themselves. You're just > making argument for the sake of it now. No, that's not what they've said. > Why should anyone be held > hostage to nVidia's "business decisions"? Publishing/following standards leaves no one hostage to anything. > Least of all the people > developing the X server, who manage to work quite well with others. And that release notice? > Not their fault if a certain company won't play well. With what standard? >> Unless you install fedora, which doesn't mention that it shipped a >> pre-release. > > It's quite apparent that the situation would still have arisen even if > 1.5 had made the release date for Fedora, as mentioned elsewhere in > this thread was a claim that nVidia want to see the new thing shipped > on a distro before committing to it. A claim that seems to have been as fabricated as yours, or at least based on ancient history. > So, this is now irrelevant for > the discussion (because it does not materially change the outcome of > the drivers not being ready at F9 release time). I don't think anyone can support that claim, given Nvida's public statement that they would target the X release. -- Les Mikesell lesmikesell at gmail.com From notting at redhat.com Wed May 21 18:01:20 2008 From: notting at redhat.com (Bill Nottingham) Date: Wed, 21 May 2008 14:01:20 -0400 Subject: Recomposing with generic-logos In-Reply-To: <48340A2C.9000202@kanarip.com> References: <482FF429.3000005@kanarip.com> <20080519194743.GG27865@nostromo.devel.redhat.com> <48340A2C.9000202@kanarip.com> Message-ID: <20080521180120.GA8983@nostromo.devel.redhat.com> Jeroen van Meeuwen (kanarip at kanarip.com) said: > A `diff -u` of "ls *.rpm" is at http://fpaste.org/paste/2289 > > A complete diff of the contents of stage2.img is at > http://fpaste.org/paste/2290 That looks to be something broken in the image creation process completely aside from fedora-logos vs generic-logos - there's nothing there that would imply the removal of specspo, for example. Are you sure you're using the right upd-instroot? Bill From nicolas.mailhot at laposte.net Wed May 21 18:03:03 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 21 May 2008 20:03:03 +0200 (CEST) Subject: Xorg 1.5 missed the train? In-Reply-To: <48345CBC.40508@gmail.com> References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <20080521152022.GF1093879@hiwaay.net> <1211383722.8531.63.camel@localhost.localdomain> <1211385285.8531.65.camel@localhost.localdomain> <544eb990805210917y45a7df22hb867b7e8e027d474@mail.gmail.com> <48344D6E.6000006@gmail.com> <544eb990805210935k781bcbafn6165c3e03aa72d10@mail.gmail.com> <4834533D.7010007@gmail.com> <23519.192.54.193.57.1211389920.squirrel@rousalka.dyndns.org> <48345CBC.40508@gmail.com> Message-ID: <63385.192.54.193.58.1211392983.squirrel@rousalka.dyndns.org> Le Mer 21 mai 2008 19:32, Les Mikesell a ?crit : > I don't have a problem with Xorg taking any amount of time they want. > The problem is in fedora shipping a pre-release - or perhaps even more > so in their claim of knowing that the ABI is finalized before it is in > fact published as a standard. I suggest you complain to the xorg 1.5 release engineer the Fedora xorg maintainer is not coordinating with him closely. And then that you follow the advice of the xorg 1.5 release engineer on this issue. -- Nicolas Mailhot From cmadams at hiwaay.net Wed May 21 18:03:33 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 21 May 2008 13:03:33 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: <4834533D.7010007@gmail.com> References: <20080521152022.GF1093879@hiwaay.net> <1211383722.8531.63.camel@localhost.localdomain> <1211385285.8531.65.camel@localhost.localdomain> <544eb990805210917y45a7df22hb867b7e8e027d474@mail.gmail.com> <48344D6E.6000006@gmail.com> <544eb990805210935k781bcbafn6165c3e03aa72d10@mail.gmail.com> <4834533D.7010007@gmail.com> Message-ID: <20080521180333.GH1093879@hiwaay.net> Once upon a time, Les Mikesell said: > What is it that would suggest that it is finalized to a manager that > might want to commit resources to writing a driver his company will have > to support? The fact that the developers have said so on public mailing lists. nVidia chooses to wait until a distro is shipping a new X before working on it; that is nVidia's problem to support. Would it be Microsoft's fault if nVidia is told about changes to the driver ABI (with all the necessary information provided), but nVidia chose to wait until the new version of Windows was on store shelves before working on a new driver? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From paul at all-the-johnsons.co.uk Wed May 21 18:04:22 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Wed, 21 May 2008 19:04:22 +0100 Subject: Evolution / gtk problem in rawhide In-Reply-To: <1211388799.23725.4.camel@localhost.localdomain> References: <1211385994.5803.2.camel@T7.Linux> <1211388799.23725.4.camel@localhost.localdomain> Message-ID: <1211393062.6827.0.camel@T7.Linux> Hi, > > I'm not sure if I should file this under GTK or Evolution. > > I've reread that a few times now and I'm still not sure I understand > what you're describing. Can you add screenshots to the Bugzilla report > when you file it? I'd file it against gtkhtml3. Done - with not one, but two screenshots! TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jspaleta at gmail.com Wed May 21 18:04:48 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 21 May 2008 10:04:48 -0800 Subject: Xorg 1.5 missed the train? In-Reply-To: <4834639D.1000509@gmail.com> References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <544eb990805210917y45a7df22hb867b7e8e027d474@mail.gmail.com> <48344D6E.6000006@gmail.com> <544eb990805210935k781bcbafn6165c3e03aa72d10@mail.gmail.com> <4834533D.7010007@gmail.com> <544eb990805211001q75c28580k8b344b638451f223@mail.gmail.com> <48345B6C.3030204@gmail.com> <544eb990805211047l3f9cb8e3pa8acf93f9cfd93fb@mail.gmail.com> <4834639D.1000509@gmail.com> Message-ID: <604aa7910805211104j5422a415x5dd2cfaad8ec8c58@mail.gmail.com> On Wed, May 21, 2008 at 10:02 AM, Les Mikesell wrote: > I don't think anyone can support that claim, given Nvida's public statement > that they would target the X release. I've already found references and posted them in a previous post which state emphatically that Nvidia doesn't not time its releases to X releases, and does not provide any date-specific times at all. References from the LAST Xorg release cycle. There is a long history here. Nvidia lags..full stop. This is absolutely nothing new. -jef From cmadams at hiwaay.net Wed May 21 18:05:28 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 21 May 2008 13:05:28 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: <48345B6C.3030204@gmail.com> References: <1211383722.8531.63.camel@localhost.localdomain> <1211385285.8531.65.camel@localhost.localdomain> <544eb990805210917y45a7df22hb867b7e8e027d474@mail.gmail.com> <48344D6E.6000006@gmail.com> <544eb990805210935k781bcbafn6165c3e03aa72d10@mail.gmail.com> <4834533D.7010007@gmail.com> <544eb990805211001q75c28580k8b344b638451f223@mail.gmail.com> <48345B6C.3030204@gmail.com> Message-ID: <20080521180528.GI1093879@hiwaay.net> Once upon a time, Les Mikesell said: > That has nothing to do with what I said. I'm suggesting that fedora > should ship with interfaces that are publicized as standard, and allow > time for changes in this standard to propagate before shipping something > different from the standard. The Fedora and X developers did publicize the change several months ago. The X.org code has been available for testing, and Fedora has had several test releases with the code integrated. What more do you expect? Do they have to take out an ad in the New York Times or send certified snail mail to nVidia? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From ajax at redhat.com Wed May 21 18:09:23 2008 From: ajax at redhat.com (Adam Jackson) Date: Wed, 21 May 2008 14:09:23 -0400 Subject: Xorg 1.5 missed the train? In-Reply-To: <63385.192.54.193.58.1211392983.squirrel@rousalka.dyndns.org> References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <20080521152022.GF1093879@hiwaay.net> <1211383722.8531.63.camel@localhost.localdomain> <1211385285.8531.65.camel@localhost.localdomain> <544eb990805210917y45a7df22hb867b7e8e027d474@mail.gmail.com> <48344D6E.6000006@gmail.com> <544eb990805210935k781bcbafn6165c3e03aa72d10@mail.gmail.com> <4834533D.7010007@gmail.com> <23519.192.54.193.57.1211389920.squirrel@rousalka.dyndns.org> <48345CBC.40508@gmail.com> <63385.192.54.193.58.1211392983.squirrel@rousalka.dyndns.org> Message-ID: <1211393363.29467.144.camel@localhost.localdomain> On Wed, 2008-05-21 at 20:03 +0200, Nicolas Mailhot wrote: > Le Mer 21 mai 2008 19:32, Les Mikesell a ?crit : > > > I don't have a problem with Xorg taking any amount of time they want. > > The problem is in fedora shipping a pre-release - or perhaps even more > > so in their claim of knowing that the ABI is finalized before it is in > > fact published as a standard. > > I suggest you complain to the xorg 1.5 release engineer the Fedora > xorg maintainer is not coordinating with him closely. And then that > you follow the advice of the xorg 1.5 release engineer on this issue. You know I'm both, right? - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From lesmikesell at gmail.com Wed May 21 18:24:08 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 21 May 2008 13:24:08 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: <20080521180528.GI1093879@hiwaay.net> References: <1211383722.8531.63.camel@localhost.localdomain> <1211385285.8531.65.camel@localhost.localdomain> <544eb990805210917y45a7df22hb867b7e8e027d474@mail.gmail.com> <48344D6E.6000006@gmail.com> <544eb990805210935k781bcbafn6165c3e03aa72d10@mail.gmail.com> <4834533D.7010007@gmail.com> <544eb990805211001q75c28580k8b344b638451f223@mail.gmail.com> <48345B6C.3030204@gmail.com> <20080521180528.GI1093879@hiwaay.net> Message-ID: <483468C8.6000702@gmail.com> Chris Adams wrote: > Once upon a time, Les Mikesell said: >> That has nothing to do with what I said. I'm suggesting that fedora >> should ship with interfaces that are publicized as standard, and allow >> time for changes in this standard to propagate before shipping something >> different from the standard. > > The Fedora and X developers did publicize the change several months ago. > The X.org code has been available for testing, and Fedora has had > several test releases with the code integrated. I thought someone said it was only a week or so ago that the ABI was even internally/informally pronounced as stable. > > What more do you expect? Do they have to take out an ad in the New York > Times or send certified snail mail to nVidia? Just naming it 1.5 would probably have been sufficient per the nVidia forum posting about targeting the release. -- Les Mikesell lesmikesell at gmail.com From jspaleta at gmail.com Wed May 21 18:26:37 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 21 May 2008 10:26:37 -0800 Subject: Xorg 1.5 missed the train? In-Reply-To: <48344D6E.6000006@gmail.com> References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <20080521152022.GF1093879@hiwaay.net> <1211383722.8531.63.camel@localhost.localdomain> <1211385285.8531.65.camel@localhost.localdomain> <544eb990805210917y45a7df22hb867b7e8e027d474@mail.gmail.com> <48344D6E.6000006@gmail.com> Message-ID: <604aa7910805211126t2b968179o15a9ef954c9217a@mail.gmail.com> On Wed, May 21, 2008 at 8:27 AM, Les Mikesell wrote: > No, the point is that it is a pre-release version of X, shipped will full > knowledge that it will break binary drivers that no reasonable person would > expect to be modified to match yet. Since the refernece for 7.3 release aren't enough to satisfy you. How about we look further back.... to 7.1. X 7.1 released May 22,2006 Reference: http://xorg.freedesktop.org/archive/X11R7.1/doc/RELNOTES.html Ubuntu 6.10 Edgy Eft, October 26, 2006 containing X 7.1 Reference: Ubuntu Forum comments concering the Edgy development phase from JULY of 2006 show that Nvidia still doesn't have drivers targetting X 7.1 and its new ABI. Reference: http://ubuntuforums.org/showthread.php?t=224363 And if you read that whole thread you get this little gem: "I believe off the record nvidia employees have said the new driver is coming late August... officially, nothing has been said though." Aug.... what is that 3 months after the ABI was 'released'? Even if we waited a month after the ABI was 'released' we could still be waiting on them. By official word nor by action has NVidia indicated that it makes an effort to release against new Xorg releases in a timely fashion. What you can count on, by looking at the history of how this works is that, Nvidia lags until a distribution has a gold release which targets a new ABI. -jef From aoliva at redhat.com Wed May 21 18:39:40 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Wed, 21 May 2008 15:39:40 -0300 Subject: Xorg 1.5 missed the train? In-Reply-To: <4833B21C.2020807@gmail.com> (Les Mikesell's message of "Wed\, 21 May 2008 00\:24\:44 -0500") References: <48334163.4080709@magma.ca> <1211335226.3768.1.camel@clockmaker.usersys.redhat.com> <20080520211137.67744ac3@vader.jdub.homelinux.org> <48338811.3090700@gmail.com> <48338D79.9020304@gmail.com> <20080520220210.77f97a82@vader.jdub.homelinux.org> <1211340916.3307.2.camel@clockmaker.usersys.redhat.com> <4833B21C.2020807@gmail.com> Message-ID: On May 21, 2008, Les Mikesell wrote: > Can you break VMware and skype a little more too +1 Could you please suggest that as a feature for Fedora 10? :-) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From aoliva at redhat.com Wed May 21 18:47:27 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Wed, 21 May 2008 15:47:27 -0300 Subject: Xorg 1.5 missed the train? In-Reply-To: (Christopher Stone's message of "Tue\, 20 May 2008 21\:19\:59 -0700") References: <48334163.4080709@magma.ca> <48338811.3090700@gmail.com> <48338D79.9020304@gmail.com> <20080520220210.77f97a82@vader.jdub.homelinux.org> <1211340916.3307.2.camel@clockmaker.usersys.redhat.com> <1211343191.3682.9.camel@clockmaker.usersys.redhat.com> Message-ID: On May 21, 2008, "Christopher Stone" wrote: > I really don't expect an xorg build for every binary blob out > there, but a stable version of xorg as an alternative for those who > are having problems with the beta version should have been given more > consideration in my opinion. This argument is facetious, and it drives the blame in the wrong direction. What does 'beta version' have to do with it? If it just so happened that X *had* released what Fedora ships as a stable version before Fedora 9, what would this have changed? Nothing. Nothing whatsoever. You'd still be stuck with a non-Free driver that doesn't work with the latest stable release. Therefore, using the terms 'stable version' and 'beta version' is a distraction, and attempt to shift the blame through the underlying implications of these terms. I suggest from this point on you use terms such as '{,in}compatible with the non-Free driver I'd like to use'. This will put things in the right perspective. You may still find reason to blame Fedora for apparently disregarding users trapped by nvidia's non-Free drivers, but really, whose fault is it that you depend on nvidia to get your graphics to work the way you want on the release of Fedora you want to use? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From mmcgrath at redhat.com Wed May 21 18:32:21 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 21 May 2008 13:32:21 -0500 (CDT) Subject: Outage Notification - 2008-05-24 03:00 UTC Message-ID: There will be an outage starting at 2008-05-24 03:00 UTC, which will last approximately 24 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2008-05-24 03:00 UTC' Affected Services: Buildsystem Unaffected Services: Websites CVS / Source Control Database DNS Mail Torrent Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/564 Reason for Outage: /mnt/koij needs to be fsck'ed. Tests against a snapshot took around 20 hours. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From lesmikesell at gmail.com Wed May 21 19:01:09 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 21 May 2008 14:01:09 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: <1211393363.29467.144.camel@localhost.localdomain> References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <20080521152022.GF1093879@hiwaay.net> <1211383722.8531.63.camel@localhost.localdomain> <1211385285.8531.65.camel@localhost.localdomain> <544eb990805210917y45a7df22hb867b7e8e027d474@mail.gmail.com> <48344D6E.6000006@gmail.com> <544eb990805210935k781bcbafn6165c3e03aa72d10@mail.gmail.com> <4834533D.7010007@gmail.com> <23519.192.54.193.57.1211389920.squirrel@rousalka.dyndns.org> <48345CBC.40508@gmail.com> <63385.192.54.193.58.1211392983.squirrel@rousalka.dyndns.org> <1211393363.29467.144.camel@localhost.localdomain> Message-ID: <48347175.4060904@gmail.com> Adam Jackson wrote: > >>> I don't have a problem with Xorg taking any amount of time they want. >>> The problem is in fedora shipping a pre-release - or perhaps even more >>> so in their claim of knowing that the ABI is finalized before it is in >>> fact published as a standard. >> I suggest you complain to the xorg 1.5 release engineer the Fedora >> xorg maintainer is not coordinating with him closely. And then that >> you follow the advice of the xorg 1.5 release engineer on this issue. > > You know I'm both, right? > > - ajax I assume that was an attempt at humor.... But, it makes it hard to claim that you didn't have some inside information about when the interface was going to stop changing. In another company that sort of thing might be called anti-competitive behavior. -- Les Mikesell lesmikesell at gmail.com From johannbg at hi.is Wed May 21 19:06:07 2008 From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Wed, 21 May 2008 19:06:07 +0000 Subject: Xorg 1.5 missed the train? In-Reply-To: <48337D52.7050005@poolshark.org> References: <48334163.4080709@magma.ca> <48337D52.7050005@poolshark.org> Message-ID: <4834729F.8030507@hi.is> Denis Leroy wrote: > Jason Tang wrote: >> The only problem being that this release is incompatible with current >> nvidia drivers. Granted, I'm aware of the Fedora position regarding >> non-OSS, but this Xorg issue has completely destroyed many user's >> confidence in the dev team. > > That's nothing new you know. Out of the 9 fedora releases, I think at > least 8 out of 9 didn't work with the Nvidia driver at release time. > however Nvidia is usually pretty good at playing catch up. > > I'm also hostage to Nvidia's good will for my Lenovo T61's Quadro > chipset, and can't upgrade to F-9 until their next release (nv doesn't > work at all on this chipset). I wouldn't go back to a Radeon chipset > though, not until we have a working free equivalent (emphasis on > 'working') to nvidia-settings for easy dual-head support... The good > news is that with xrandr maturing, we're probably almost there. > Interesting... I have no "nv" problems on my Lenovo T61p with Quadro FX570M. Running with no xorg.conf. ... http://www.smolts.org/client/show/pub_1536ec85-61c8-49d4-aeaa-3852a20d5d29 ( Of course 3D aint working but who's using it anyway and certainly 50% of Fedora's users as some claim ) JB. ... From lordmorgul at gmail.com Wed May 21 19:08:46 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Wed, 21 May 2008 12:08:46 -0700 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <20080520213057.GL16499@redhat.com> <1211319877.8531.40.camel@localhost.localdomain> <604aa7910805201505m7cc84699p953aa880b7419413@mail.gmail.com> <604aa7910805201514h4535567atd4e7c6c67bb74a84@mail.gmail.com> <54216.75.164.221.130.1211322252.squirrel@clueserver.org> <4833BFD2.4070901@gmail.com> Message-ID: <4834733E.2090605@gmail.com> Erich Zigler wrote: > On Wed, May 21, 2008 at 1:23 AM, Andrew Farris wrote: > >> Had Fedora not released with the new Xorg >> ABI nvidia would probably still not be actively working on it yet. > > Actually development looks like it started before Fedora 9 released: > > http://www.nvnews.net/vbulletin/showthread.php?t=111460 Yes, but my point is that it was pushed forward due to the impending release of Fedora 9 and otherwise probably would not have been started until another distro released with the xserver changes. NVIDIA is not going to do a driver update only because the xorg server releases; they will do it when/if a release is adopted by a popular distribution. That pattern has been well established over the last 6-8 years. Also, the 173.08 beta driver wasn't even really targeted at xserver 1.5 since it still didn't have the abi marked supported. It just happens to partially work, for some graphics cards (and not for alot of them). -- Andrew Farris www.lordmorgul.net gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29 From aoliva at redhat.com Wed May 21 19:20:39 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Wed, 21 May 2008 16:20:39 -0300 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: <1211377739.4210.2.camel@truman> (Brian Pepple's message of "Wed\, 21 May 2008 09\:48\:59 -0400") References: <1211377739.4210.2.camel@truman> Message-ID: On May 21, 2008, Brian Pepple wrote: > You want something to be discussed? Send a note to the list in reply to > this mail and I'll add it to the schedule. Given that Freedom? is a major fedora feature, I'd like to discuss enabling the creation of Fedora spins containing exclusively Free Software. These are related sub-topics: . Permission to distribute under the mark 'Fedora' spins containing kernel-libre packages, whose sole difference from identically-numbered Fedora kernel builds is the removal of a few pieces of non-Free Software. . Inclusion in Fedora (future and recent past releases) of the kernel-libre package, a 100% Free Software variant of the kernel Linux, that I've been maintaining tracking Fedora kernel builds at http://www.fsfla.org/~lxoliva/fsfla/linux-libre/ . Inclusion in Fedora (future and recent past releases) of a fedora-freedom "virtual" package, that Requires: linux-libre and Conflicts: with any Fedora package known to contain software (firmware included) that does not respect the 4 freedoms established in the Free Software definition. AFAIK these would pretty much amount to the standard non-Free kernel and a bunch of *-firmware packages, but there could be sub-packages to cover other debatable packages with obscure source code, dubious licensing policies, etc. I realize these packages should probably be submitted for inclusion through the regular package submission process, but I was advised to discuss linux-libre in FESCo first, and the second is closely related and has no upstream. I'm a bit hesitant, for these appear to be more of policy than engineering issues, and my understanding is that the board is in charge of such decisions. Anyhow, it (hopefully :-) wouldn't hurt for the board to get recommendations from engineering in this regard, assuming my understanding as to how policy decisions are made is correct. Please let me know whether this is a suitable topic for discussion in tomorrow's meeting, and I'll do my best to be there, i.e., save for unforeseeable issues or ISP LoQoS I've been subject to recently :-/ the L in LoQoS is for Lack, in case it's not obvious :-) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From jwboyer at gmail.com Wed May 21 19:33:45 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 21 May 2008 14:33:45 -0500 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: References: <1211377739.4210.2.camel@truman> Message-ID: <20080521143345.383eb10b@vader.jdub.homelinux.org> On Wed, 21 May 2008 16:20:39 -0300 Alexandre Oliva wrote: > On May 21, 2008, Brian Pepple wrote: > > > You want something to be discussed? Send a note to the list in reply to > > this mail and I'll add it to the schedule. > > Given that Freedom? is a major fedora feature, I'd like to discuss > enabling the creation of Fedora spins containing exclusively Free > Software. These are related sub-topics: > > . Permission to distribute under the mark 'Fedora' spins containing > kernel-libre packages, whose sole difference from identically-numbered > Fedora kernel builds is the removal of a few pieces of non-Free > Software. All spins must be composed of packages that are contained within the Fedora repositories. kernel-libre does not fit that category (today). > . Inclusion in Fedora (future and recent past releases) of the > kernel-libre package, a 100% Free Software variant of the kernel > Linux, that I've been maintaining tracking Fedora kernel builds at > http://www.fsfla.org/~lxoliva/fsfla/linux-libre/ We've had this discussion. We aren't going to allow a forked kernel package. Please work with the kernel team to integrate this into the main kernel package. > . Inclusion in Fedora (future and recent past releases) of a > fedora-freedom "virtual" package, that Requires: linux-libre and > Conflicts: with any Fedora package known to contain software (firmware > included) that does not respect the 4 freedoms established in the Free > Software definition. AFAIK these would pretty much amount to the > standard non-Free kernel and a bunch of *-firmware packages, but there > could be sub-packages to cover other debatable packages with obscure > source code, dubious licensing policies, etc. You don't need a package. Make a comps group. > I realize these packages should probably be submitted for inclusion > through the regular package submission process, but I was advised to > discuss linux-libre in FESCo first, and the second is closely related > and has no upstream. > > I'm a bit hesitant, for these appear to be more of policy than > engineering issues, and my understanding is that the board is in > charge of such decisions. Anyhow, it (hopefully :-) wouldn't hurt for > the board to get recommendations from engineering in this regard, > assuming my understanding as to how policy decisions are made is > correct. > > Please let me know whether this is a suitable topic for discussion in > tomorrow's meeting, and I'll do my best to be there, i.e., save for > unforeseeable issues or ISP LoQoS I've been subject to recently :-/ > the L in LoQoS is for Lack, in case it's not obvious :-) I think we can certainly discuss it. However I believe the biggest hurdle to what you propose is the extra kernel-libre package. Your overall proposal hinges on that, and the way you've stated you would like to provide it has been frowned upon quite a bit. josh From rdieter at math.unl.edu Wed May 21 19:51:19 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 21 May 2008 14:51:19 -0500 Subject: QTDIR -> 3.3? References: Message-ID: Neal Becker wrote: > pkg-config --variable=prefix qt-mt > /usr/lib64/qt-3.3 > > Is this correct on F9? Shouldn't be qt4? that's qt v3. This is qt v4's version: pkg-config --variable=prefix Qt -- Rex From vonbrand at inf.utfsm.cl Wed May 21 19:51:39 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Wed, 21 May 2008 15:51:39 -0400 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <48334163.4080709@magma.ca> <1211343191.3682.9.camel@clockmaker.usersys.redhat.com> <200805202124.20893.konrad@tylerc.org> Message-ID: <200805211951.m4LJpdR2011557@laptop13.inf.utfsm.cl> Christopher Stone wrote: > 2008/5/20 Konrad Meyer : > > As was brought up in a recent thread (of a similarly long and pointless > > nature), any Fedora user is free to work on getting support for > > whatever they want into Fedora proper, and popular vote has absolutely > > *nothing* to do with what actually gets included in Fedora. If you want > > something done, do it yourself. If you aren't satisfied by numerous > > explanations, find something that satisfies you more than Fedora. We > > love having more users, but repeated complaints from leeches are just > > annoying. > I'm sure a repo will pop up with all the necessary rpms if nVidia > doesn't come out with drivers soon enough. Go ahead an put it up! > It is just frustrating > that it has to happen this way. Such a small amount of effort to make > the distro user friendly for everyone, It is *not* a small amount of effort. We are not just talking of recompile-old-X-packages-and-forget, it means an ongoing effort of bug handling, keeping other packages depending on the old API, ... Plus if this is done, it is quite probable that nVidia would /never/ see the point of upgrading their stuff ("Why bother? It works fine with the "?) And if such is kept up, it would snowball into an enormous job of keeping whatever backward compatibility dozens of random hardware and software pieces require. Better go for a long-time-stability distribution then (but then again, I just saw problems with an oldish distribution for which they can't get machines it runs on anymore...). > and yet we must stick to our > principles and screw the end user. It is more like Fedora users are its users /because/ Fedora is bleeding edge, and of its principles; and that means breaking some eggs from time to time (if I may mix metaphors). If that doesn't apeal to you, you aren't the kind of user Fedora is aimed at. Can't please everyone, sorry about that. Just shop elsewhere. > It doesn't make sense. It makes perfect sense to me. [Full disclosure: I'm an nVidia user myself, and 3d has /never/ worked here (had enough grief with the binary driver that I gave up on it long ago). But for my needs, the current nv driver is plenty enough. YMMV.] From orion at cora.nwra.com Wed May 21 19:57:44 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 21 May 2008 13:57:44 -0600 Subject: perl 5.10 include location Message-ID: <48347EB8.6030805@cora.nwra.com> Is there some tool one should use to determine the location of the perl 5.10 include files (e.g.: /usr/lib/perl5/5.10.0/i386-linux-thread-multi/CORE)? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From lmacken at redhat.com Wed May 21 20:17:50 2008 From: lmacken at redhat.com (Luke Macken) Date: Wed, 21 May 2008 16:17:50 -0400 Subject: Bodhi spam? In-Reply-To: <20080521163252.e44bdef5.mschwendt@gmail.com> References: <20080520093705.GA25663@amd.home.annexia.org> <20080521142436.GA8221@x300> <20080521163252.e44bdef5.mschwendt@gmail.com> Message-ID: <20080521201750.GD8221@x300> On Wed, May 21, 2008 at 04:32:52PM +0200, Michael Schwendt wrote: > On Wed, 21 May 2008 10:24:36 -0400, Luke Macken wrote: > > > On Tue, May 20, 2008 at 10:37:05AM +0100, Richard W.M. Jones wrote: > > > > > > [Two unrelated Bodhi questions in the space of a few minutes ...] > > > > > > Is someone able to spam Bodhi? See: > > > > > > https://admin.fedoraproject.org/updates/F8/pending/ocaml-libvirt-0.4.1.1-2.fc8 > > > > Interesting... > > > > It look them 4 tries to guess the captcha for the first comment, and 2 for the > > second -- 2 minutes apart. Smart bot or really dumb person? I'm not > > quite sure what we can do about either... > > What about the logged usernames? Can the default "Anonymous Tester" > be changed from the outside? > > It is plural "Anonymous Testers" for the first comment and "ljkl" > for the second comment. The "Anonymous Tester" name field can be changed to pretty much whatever they want. Yes, it's a bit sketchy at the moment. I'm thinking it may be good to require an email address for testers without fedora accounts. Drive by karma's are valuable, but being able to get ahold of these people if the developer has any questions is even more valuable. luke From surenkarapetyan at gmail.com Wed May 21 20:18:51 2008 From: surenkarapetyan at gmail.com (Suren Karapetyan) Date: Thu, 22 May 2008 01:18:51 +0500 Subject: Xorg 1.5 missed the train? In-Reply-To: <48347175.4060904@gmail.com> References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <20080521152022.GF1093879@hiwaay.net> <1211383722.8531.63.camel@localhost.localdomain> <1211385285.8531.65.camel@localhost.localdomain> <544eb990805210917y45a7df22hb867b7e8e027d474@mail.gmail.com> <48344D6E.6000006@gmail.com> <544eb990805210935k781bcbafn6165c3e03aa72d10@mail.gmail.com> <4834533D.7010007@gmail.com> <23519.192.54.193.57.1211389920.squirrel@rousalka.dyndns.org> <48345CBC.40508@gmail.com> <63385.192.54.193.58.1211392983.squirrel@rousalka.dyndns.org> <1211393363.29467.144.camel@localhost.localdomain> <48347175.4060904@gmail.com> Message-ID: <483483AB.3050804@gmail.com> Les Mikesell wrote: > Adam Jackson wrote: >> >>>> I don't have a problem with Xorg taking any amount of time they want. >>>> The problem is in fedora shipping a pre-release - or perhaps even more >>>> so in their claim of knowing that the ABI is finalized before it is in >>>> fact published as a standard. >>> I suggest you complain to the xorg 1.5 release engineer the Fedora >>> xorg maintainer is not coordinating with him closely. And then that >>> you follow the advice of the xorg 1.5 release engineer on this issue. >> >> You know I'm both, right? >> >> - ajax > > I assume that was an attempt at humor.... But, it makes it hard to > claim that you didn't have some inside information about when the > interface was going to stop changing. In another company that sort of > thing might be called anti-competitive behavior. > > -- > Les Mikesell > lesmikesell at gmail.com > Guys let's stop using the argument "they didn't know it was stable"... If You're writing a driver for Your product and not just an ordinary userspace thing, but a driver half of which sits in the kernel and the other half in X, You'll HAVE TO have a guy (or maybe many more) who will be doing just that and nothing else. And I bet if someone's job is writing an Xorg driver, he would at least be signed to the -devel mailing list and would checkout from CVS/SVN/GIT/... at least once a week to watch where the development is. And don't tell that's not the case with Windows. Of course it isn't... But we aren't talking about a windows programmer who is writing Xorg driver as a hobby in the first time in his life and doesn't know that ABI's aren't very loved in FOSS world. We are speaking about a *nix programmer. I myself have an Nvidia card in my home PC (and one at work). And because I want to be able to do OpenGL (accelerated) I just excluded xorg stuff from yum upgrade. I'll have to wait for the driver from NVidia. Mea culpa (for buying NVidia.. next one will be AMD), not Fedora's (for shipping "unstable" ABI). From orion at cora.nwra.com Wed May 21 20:29:59 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 21 May 2008 14:29:59 -0600 Subject: perl 5.10 include location In-Reply-To: <48347EB8.6030805@cora.nwra.com> References: <48347EB8.6030805@cora.nwra.com> Message-ID: <48348647.4020708@cora.nwra.com> Orion Poplawski wrote: > Is there some tool one should use to determine the location of the perl > 5.10 include files (e.g.: > /usr/lib/perl5/5.10.0/i386-linux-thread-multi/CORE)? perl -MExtUtils::Embed -e perl_inc Sorry for the noise. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From surenkarapetyan at gmail.com Wed May 21 20:36:12 2008 From: surenkarapetyan at gmail.com (Suren Karapetyan) Date: Thu, 22 May 2008 01:36:12 +0500 Subject: Xorg 1.5 missed the train? In-Reply-To: <200805211951.m4LJpdR2011557@laptop13.inf.utfsm.cl> References: <48334163.4080709@magma.ca> <1211343191.3682.9.camel@clockmaker.usersys.redhat.com> <200805202124.20893.konrad@tylerc.org> <200805211951.m4LJpdR2011557@laptop13.inf.utfsm.cl> Message-ID: <483487BC.4000801@gmail.com> Horst H. von Brand wrote: > Christopher Stone wrote: >> 2008/5/20 Konrad Meyer : > >>> As was brought up in a recent thread (of a similarly long and pointless >>> nature), any Fedora user is free to work on getting support for >>> whatever they want into Fedora proper, and popular vote has absolutely >>> *nothing* to do with what actually gets included in Fedora. If you want >>> something done, do it yourself. If you aren't satisfied by numerous >>> explanations, find something that satisfies you more than Fedora. We >>> love having more users, but repeated complaints from leeches are just >>> annoying. > >> I'm sure a repo will pop up with all the necessary rpms if nVidia >> doesn't come out with drivers soon enough. > > > Go ahead an put it up! > >> It is just frustrating >> that it has to happen this way. Such a small amount of effort to make >> the distro user friendly for everyone, > > It is *not* a small amount of effort. We are not just talking of > recompile-old-X-packages-and-forget, it means an ongoing effort of bug > handling, keeping other packages depending on the old API, ... Plus if this > is done, it is quite probable that nVidia would /never/ see the point of > upgrading their stuff ("Why bother? It works fine with the set of packages>"?) And if such is kept up, it would snowball into an > enormous job of keeping whatever backward compatibility dozens of random > hardware and software pieces require. Better go for a long-time-stability > distribution then (but then again, I just saw problems with an oldish > distribution for which they can't get machines it runs on anymore...). > Windows??? anyone?? >> and yet we must stick to our >> principles and screw the end user. > > It is more like Fedora users are its users /because/ Fedora is bleeding > edge, and of its principles; and that means breaking some eggs from time to > time (if I may mix metaphors). If that doesn't apeal to you, you aren't the > kind of user Fedora is aimed at. Can't please everyone, sorry about that. > Just shop elsewhere. +1 Stable (in the meaning of not-changing) and new sometimes arent't compatible. If You want stable (read: slower-changing) try the Enterprise versions. Or Debian (2.6.18 *is* stable but it lacks the new functionality added during last 1.5 years). > >> It doesn't make sense. > > It makes perfect sense to me. > > [Full disclosure: I'm an nVidia user myself, and 3d has /never/ worked > here (had enough grief with the binary driver that I gave up on it long > ago). But for my needs, the current nv driver is plenty enough. YMMV.] > From lesmikesell at gmail.com Wed May 21 20:39:00 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 21 May 2008 15:39:00 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: <483483AB.3050804@gmail.com> References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <20080521152022.GF1093879@hiwaay.net> <1211383722.8531.63.camel@localhost.localdomain> <1211385285.8531.65.camel@localhost.localdomain> <544eb990805210917y45a7df22hb867b7e8e027d474@mail.gmail.com> <48344D6E.6000006@gmail.com> <544eb990805210935k781bcbafn6165c3e03aa72d10@mail.gmail.com> <4834533D.7010007@gmail.com> <23519.192.54.193.57.1211389920.squirrel@rousalka.dyndns.org> <48345CBC.40508@gmail.com> <63385.192.54.193.58.1211392983.squirrel@rousalka.dyndns.org> <1211393363.29467.144.camel@localhost.localdomain> <48347175.4060904@gmail.com> <483483AB.3050804@gmail.com> Message-ID: <48348864.3030909@gmail.com> Suren Karapetyan wrote: > >> I assume that was an attempt at humor.... But, it makes it hard to >> claim that you didn't have some inside information about when the >> interface was going to stop changing. In another company that sort of >> thing might be called anti-competitive behavior. >> > > Guys let's stop using the argument "they didn't know it was stable"... > If You're writing a driver for Your product and not just an ordinary > userspace thing, but a driver half of which sits in the kernel and the > other half in X, You'll HAVE TO have a guy (or maybe many more) who will > be doing just that and nothing else. Yes... But this may not be the guy that decides when an officially supported driver is announced and released. > And I bet if someone's job is writing an Xorg driver, he would at least > be signed to the -devel mailing list and would checkout from > CVS/SVN/GIT/... at least once a week to watch where the development is. Yes, so if someone mentioned that it was maybe, probably stable a week ago without being prepared to call it a release, you might expect said programmer to have noticed by now, but it hardly seems fair to expect him or his company to commit to a release at that point either. > And don't tell that's not the case with Windows. Of course it isn't... > But we aren't talking about a windows programmer who is writing Xorg > driver as a hobby in the first time in his life and doesn't know that > ABI's aren't very loved in FOSS world. We are speaking about a *nix > programmer. *nix doesn't have much to do with refusing to standardize interfaces, that's exclusively Linus's territory. I think we'll see something different when Red Hat does their release. -- Les Mikesell lesmikesell at gmail.com From tcallawa at redhat.com Wed May 21 20:55:36 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 21 May 2008 16:55:36 -0400 Subject: perl 5.10 include location In-Reply-To: <48348647.4020708@cora.nwra.com> References: <48347EB8.6030805@cora.nwra.com> <48348647.4020708@cora.nwra.com> Message-ID: <1211403336.3801.374.camel@localhost.localdomain> On Wed, 2008-05-21 at 14:29 -0600, Orion Poplawski wrote: > Orion Poplawski wrote: > > Is there some tool one should use to determine the location of the perl > > 5.10 include files (e.g.: > > /usr/lib/perl5/5.10.0/i386-linux-thread-multi/CORE)? > > perl -MExtUtils::Embed -e perl_inc Just be sure to BuildRequires: perl(ExtUtils::Embed). ~spot From tcallawa at redhat.com Wed May 21 20:57:46 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 21 May 2008 16:57:46 -0400 Subject: license tag cleanups Message-ID: <1211403466.3801.378.camel@localhost.localdomain> Just as a heads-up, I'm in the process of cleaning up the remaining license tags which are not compliant with: http://fedoraproject.org/wiki/Licensing Don't get surprised when you see me (or one of my ninjas) committing changes to your spec files in CVS. I only have about a thousand or so to go. :/ ~spot From surenkarapetyan at gmail.com Wed May 21 21:07:07 2008 From: surenkarapetyan at gmail.com (Suren Karapetyan) Date: Thu, 22 May 2008 02:07:07 +0500 Subject: Xorg 1.5 missed the train? In-Reply-To: <48348864.3030909@gmail.com> References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <20080521152022.GF1093879@hiwaay.net> <1211383722.8531.63.camel@localhost.localdomain> <1211385285.8531.65.camel@localhost.localdomain> <544eb990805210917y45a7df22hb867b7e8e027d474@mail.gmail.com> <48344D6E.6000006@gmail.com> <544eb990805210935k781bcbafn6165c3e03aa72d10@mail.gmail.com> <4834533D.7010007@gmail.com> <23519.192.54.193.57.1211389920.squirrel@rousalka.dyndns.org> <48345CBC.40508@gmail.com> <63385.192.54.193.58.1211392983.squirrel@rousalka.dyndns.org> <1211393363.29467.144.camel@localhost.localdomain> <48347175.4060904@gmail.com> <483483AB.3050804@gmail.com> <48348864.3030909@gmail.com> Message-ID: <48348EFB.9060807@gmail.com> Les Mikesell wrote: > Suren Karapetyan wrote: >> >>> I assume that was an attempt at humor.... But, it makes it hard to >>> claim that you didn't have some inside information about when the >>> interface was going to stop changing. In another company that sort >>> of thing might be called anti-competitive behavior. >>> >> >> Guys let's stop using the argument "they didn't know it was stable"... >> If You're writing a driver for Your product and not just an ordinary >> userspace thing, but a driver half of which sits in the kernel and the >> other half in X, You'll HAVE TO have a guy (or maybe many more) who >> will be doing just that and nothing else. > > Yes... But this may not be the guy that decides when an officially > supported driver is announced and released. Yep... You're right. And the guy who decides will most likely also say: "How many people use that X *thing*? Less then 1000? There is no way I'll pay for writing the driver for it." > >> And I bet if someone's job is writing an Xorg driver, he would at >> least be signed to the -devel mailing list and would checkout from >> CVS/SVN/GIT/... at least once a week to watch where the development is. > > Yes, so if someone mentioned that it was maybe, probably stable a week > ago without being prepared to call it a release, you might expect said > programmer to have noticed by now, but it hardly seems fair to expect > him or his company to commit to a release at that point either. It may not be true for his company, but it does make sense for him. The point is if the ABI seems to be stable but changes after a week, I wouldn't expect it to change much. And if I was THE programmer and I knew that after a month or so I'll be ordered to write a driver for the new version of Xorg, I would start thinking (read: compile-debug, compile-debug,...) about it as soon as the ABI *seemed* to be stable. > >> And don't tell that's not the case with Windows. Of course it isn't... >> But we aren't talking about a windows programmer who is writing Xorg >> driver as a hobby in the first time in his life and doesn't know that >> ABI's aren't very loved in FOSS world. We are speaking about a *nix >> programmer. > > *nix doesn't have much to do with refusing to standardize interfaces, > that's exclusively Linus's territory. I think we'll see something > different when Red Hat does their release. > I wasn't talking about *nix. I was talking about FOSS. And it isn't about "standardize interfaces", it's about stable ABI. Enterprise software vendors have the problem of having to support old versions of their software, even if they don't want. That's the reason of the old LM password hashes from Windows 95 till Vista, and the old LinuxThreads compatibility library in RHEL. This isn't true for FOSS developers. They don't have to be a "hostage" of the software they write. Nothing limits the speed of changes in FOSS software. That's why if a FOSS project sees even a small benefit from breaking the ABI, it won't usually think twice. From kevin.kofler at chello.at Wed May 21 21:11:16 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 21 May 2008 21:11:16 +0000 (UTC) Subject: Glitch-Free PulseAudio in Rawhide References: <20080517101616.GA16071@tango.0pointer.de> <20080518200225.GC19530@tango.0pointer.de> <20080520102615.GB13762@tango.0pointer.de> Message-ID: Lennart Poettering 0pointer.de> writes: > Hmm, this bug seems to be triggered only by KDE. Apparently in KDE PA > is not configured for module-x11-xsmp? (could anyone who actually runs > KDE check this?) Sounds like that's it, I don't see this module loaded in list-modules in pacmd. kde-settings-pulseaudio simply starts up pulseaudio -D, I take it that we should do some extra configuration? > > Then there's this weird issue: > > https://bugzilla.redhat.com/show_bug.cgi?id=361891 > > What's weird about this issue is primarily the setup (i.e. running > arts on top of pa). Call that setup "weird" if you want, but given that KDE 3 apps _only_ support aRts for sound and PA can't emulate the aRts protocol (and I don't blame it for that, given that aRts does things like decoding in the sound server; heck, it can even show video! KDE 4's modular Phonon is much better there, that finally dissociates showing video and decoding audio and video from the sound server, and is also much more flexible, supporting several solutions for both decoding and the sound server, but KDE 3 apps aren't going away overnight), running aRts on top of PA is the _only_ way to get the sound from those apps into PA (and thus avoid a sound device conflict with the many apps which _don't_ support aRts). > If you trigger one of those CPU overload issues, than this is most > likely due to the software entering some kind of busy loop. If you > want to fix this, you need to find out why we enter this busy > loop. Apparently the operation that should normally sleep for IO > doesn't sleep for IO in this case. Usually this means that an IO > condition that was signalled earlier was not handled as it should and > thus not reset. Unfortunately bugs like this don't leave any useful > coredumps, error messages or back traces and so can only be fixed by > spending some time in gdb to figure out what happens. This is hard to debug indeed. :-( So I take it you have no idea where to start with that? Please don't take this post as a flame, I'm really interested in getting things fixed and willing to do my part of the work. Sorry for having unintentionally provoked that small flamewar, this wasn't my intention, I guess my frustration with those bugs made me step over the fine line. :-( Kevin Kofler From aoliva at redhat.com Wed May 21 21:21:41 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Wed, 21 May 2008 18:21:41 -0300 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: <20080521143345.383eb10b@vader.jdub.homelinux.org> (Josh Boyer's message of "Wed\, 21 May 2008 14\:33\:45 -0500") References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> Message-ID: I didn't mean to start the discussion here. Is this normal procedure? On May 21, 2008, Josh Boyer wrote: > On Wed, 21 May 2008 16:20:39 -0300 > Alexandre Oliva wrote: >> On May 21, 2008, Brian Pepple wrote: >> >> > You want something to be discussed? Send a note to the list in reply to >> > this mail and I'll add it to the schedule. >> >> Given that Freedom? is a major fedora feature, I'd like to discuss >> enabling the creation of Fedora spins containing exclusively Free >> Software. These are related sub-topics: >> >> . Permission to distribute under the mark 'Fedora' spins containing >> kernel-libre packages, whose sole difference from identically-numbered >> Fedora kernel builds is the removal of a few pieces of non-Free >> Software. > All spins must be composed of packages that are contained within the > Fedora repositories. kernel-libre does not fit that category (today). IOW, you oppose the idea of making an exception to enable people to distribute spins of Fedora with the Freedom? feature in it? >> . Inclusion in Fedora (future and recent past releases) of the >> kernel-libre package, a 100% Free Software variant of the kernel >> Linux, that I've been maintaining tracking Fedora kernel builds at >> http://www.fsfla.org/~lxoliva/fsfla/linux-libre/ > We've had this discussion. We aren't going to allow a forked kernel > package. We're talking about a different package here. This is not a fork. Call it a branch if you must label it to achieve the purpose of denying freedom to Fedora users. > Please work with the kernel team to integrate this into the > main kernel package. I believe I've already explained why I can't do that. I refuse to distribute non-Free Software, and posting a patch that removes these bits amounts to posting those very bits. Now, how about *you* work with the Fedora team to provide Fedora users with one of its advertised features? I wouldn't mind if you took the xdelta or the tarball or the srpm I created, that provides Fedora users with freedom, and took it upstream. But both of us know upstream doesn't want that and doesn't care about the freedom that Fedora claims to care about. How do we get out of this conundrum? Admit that Fedora is not about Freedom, such that I move on and stop trying to achieve the stated goal, or actually work to at least enable users to enjoy this stated goal? >> . Inclusion in Fedora (future and recent past releases) of a >> fedora-freedom "virtual" package, that Requires: linux-libre and >> Conflicts: with any Fedora package known to contain software (firmware >> included) that does not respect the 4 freedoms established in the Free >> Software definition. AFAIK these would pretty much amount to the >> standard non-Free kernel and a bunch of *-firmware packages, but there >> could be sub-packages to cover other debatable packages with obscure >> source code, dubious licensing policies, etc. > You don't need a package. Make a comps group. One of us is missing something. How would a comps group prevent the accidental installation of say non-Free kernel or firmware packages brought in through unintended dependencies, for a user who wants to make sure no such software is installed, for example? > I think we can certainly discuss it. However I believe the biggest > hurdle to what you propose is the extra kernel-libre package. I suppose you're talking about disk space. I sympathize with that, but I don't see that a few additional megabytes out of a multiple-DVDs distro is can be so much of a problem, especially when it brings us closer to offering our users the *option* of getting one of the features we advertise most prominently. > Your overall proposal hinges on that, and the way you've stated you > would like to provide it has been frowned upon quite a bit. And largely misunderstood while at that. Not by everyone who objected to it, for sure. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From jkeating at redhat.com Wed May 21 21:23:58 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 May 2008 17:23:58 -0400 Subject: Important information regarding 'rel-eng@fedoraproject.org' emails Message-ID: <1211405038.29698.23.camel@localhost.localdomain> In an effort to be even more open, responsive, and reliable, Fedora Release Engineering has created an email to Trac gateway. Email requests for release engineering tasks sent to rel-eng at fedoraproject.org will now be turned into tickets filed in the rel-eng Trac space. This will allow for better visibility in the tasks needing to be done, a more public record of task discussions, and better record keeping to prevent things from falling through the email cracks. Any person that mails this address should receive an automated response from the Trac system regarding their ticket with a URL that they can visit to track the ticket progress, make updates, etc... Along with using email to submit tickets, email can also be used to update tickets. So long as you are replying to the mail you get from Trac about said ticket, and you keep the subject line intact, your email response will update the ticket. Please let us know either via email or through the #fedora-admin IRC channel if you experience any difficulties with this new setup. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From dwmw2 at infradead.org Wed May 21 21:25:27 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 21 May 2008 22:25:27 +0100 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> Message-ID: <1211405127.21380.382.camel@pmac.infradead.org> On Wed, 2008-05-21 at 18:21 -0300, Alexandre Oliva wrote: > I believe I've already explained why I can't do that. I refuse to > distribute non-Free Software, and posting a patch that removes these > bits amounts to posting those very bits. Really, that's a stupid objection. Just post it in ed form. Kernel-libre is a very bad plan; just help move the firmware which offends you out of the kernel instead. -- dwmw2 From aoliva at redhat.com Wed May 21 21:27:06 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Wed, 21 May 2008 18:27:06 -0300 Subject: Xorg 1.5 missed the train? In-Reply-To: <48347175.4060904@gmail.com> (Les Mikesell's message of "Wed\, 21 May 2008 14\:01\:09 -0500") References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <20080521152022.GF1093879@hiwaay.net> <1211383722.8531.63.camel@localhost.localdomain> <1211385285.8531.65.camel@localhost.localdomain> <544eb990805210917y45a7df22hb867b7e8e027d474@mail.gmail.com> <48344D6E.6000006@gmail.com> <544eb990805210935k781bcbafn6165c3e03aa72d10@mail.gmail.com> <4834533D.7010007@gmail.com> <23519.192.54.193.57.1211389920.squirrel@rousalka.dyndns.org> <48345CBC.40508@gmail.com> <63385.192.54.193.58.1211392983.squirrel@rousalka.dyndns.org> <1211393363.29467.144.camel@localhost.localdomain> <48347175.4060904@gmail.com> Message-ID: On May 21, 2008, Les Mikesell wrote: > Adam Jackson wrote: >> >>>> I don't have a problem with Xorg taking any amount of time they want. >>>> The problem is in fedora shipping a pre-release - or perhaps even more >>>> so in their claim of knowing that the ABI is finalized before it is in >>>> fact published as a standard. >>> I suggest you complain to the xorg 1.5 release engineer the Fedora >>> xorg maintainer is not coordinating with him closely. And then that >>> you follow the advice of the xorg 1.5 release engineer on this issue. >> >> You know I'm both, right? >> >> - ajax > I assume that was an attempt at humor.... But, it makes it hard to > claim that you didn't have some inside information about when the > interface was going to stop changing. In another company that sort of > thing might be called anti-competitive behavior. People have already quoted the public statements from Xorg that the ABI was stable, and nVidia's statements that their release cycle has nothing to do with Xorg's release cycle. nVidia just doesn't care. Why do you? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From mzerqung at 0pointer.de Wed May 21 21:33:23 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Wed, 21 May 2008 23:33:23 +0200 Subject: Glitch-Free PulseAudio in Rawhide In-Reply-To: References: <20080517101616.GA16071@tango.0pointer.de> <20080518200225.GC19530@tango.0pointer.de> <20080520102615.GB13762@tango.0pointer.de> Message-ID: <20080521213321.GA10729@tango.0pointer.de> On Wed, 21.05.08 21:11, Kevin Kofler (kevin.kofler at chello.at) wrote: > > Lennart Poettering 0pointer.de> writes: > > Hmm, this bug seems to be triggered only by KDE. Apparently in KDE PA > > is not configured for module-x11-xsmp? (could anyone who actually runs > > KDE check this?) > > Sounds like that's it, I don't see this module loaded in list-modules in pacmd. > kde-settings-pulseaudio simply starts up pulseaudio -D, I take it that we > should do some extra configuration? That module is loaded from XDG autostart in /etc/xdg/autostart/pulseaudio-module-xsmp.desktop. We do this because we otherwise lock up when called as "esd" from gnome-session (because g-s waits for us to start up completely and doesn't handle s-m requests while sleeping and we thus cannot load the xsmp module immediately from default.pa, because that includes waiting for the s-m to respond, and there we got our dead lock) It's a dirty work around for the way things are with g-s right now. I know that the KDE people know about this, I have no idea how or if they fixed this for KDE. This XDG file should be interpreted by KDE too, but I am not sure about the order in which it is interpreted. KDE packagers, what do you say about this? > > If you trigger one of those CPU overload issues, than this is most > > likely due to the software entering some kind of busy loop. If you > > want to fix this, you need to find out why we enter this busy > > loop. Apparently the operation that should normally sleep for IO > > doesn't sleep for IO in this case. Usually this means that an IO > > condition that was signalled earlier was not handled as it should and > > thus not reset. Unfortunately bugs like this don't leave any useful > > coredumps, error messages or back traces and so can only be fixed by > > spending some time in gdb to figure out what happens. > > This is hard to debug indeed. :-( So I take it you have no idea where to start > with that? Hmm, install debuginfo packages. Run arts on top of PA through a profile when this happens. If done properly it gives you an idea of the hot spots, i.e. the loops that turned into busy loops. But in the end you need to run the whole mess in gdb, and step through the code and find out why one of the loops started to run amok. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Wed May 21 21:34:44 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Wed, 21 May 2008 23:34:44 +0200 Subject: Glitch-Free PulseAudio in Rawhide In-Reply-To: <20080521213321.GA10729@tango.0pointer.de> References: <20080517101616.GA16071@tango.0pointer.de> <20080518200225.GC19530@tango.0pointer.de> <20080520102615.GB13762@tango.0pointer.de> <20080521213321.GA10729@tango.0pointer.de> Message-ID: <20080521213443.GB10729@tango.0pointer.de> On Wed, 21.05.08 23:33, Lennart Poettering (mzerqung at 0pointer.de) wrote: > > > If you trigger one of those CPU overload issues, than this is most > > > likely due to the software entering some kind of busy loop. If you > > > want to fix this, you need to find out why we enter this busy > > > loop. Apparently the operation that should normally sleep for IO > > > doesn't sleep for IO in this case. Usually this means that an IO > > > condition that was signalled earlier was not handled as it should and > > > thus not reset. Unfortunately bugs like this don't leave any useful > > > coredumps, error messages or back traces and so can only be fixed by > > > spending some time in gdb to figure out what happens. > > > > This is hard to debug indeed. :-( So I take it you have no idea where to start > > with that? > > Hmm, install debuginfo packages. Run arts on top of PA through a > profile when this happens. If done properly it gives you an idea of > the hot spots, i.e. the loops that turned into busy loops. That should read "profiler", not "profile". Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From tcallawa at redhat.com Wed May 21 21:39:43 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 21 May 2008 17:39:43 -0400 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: <1211405127.21380.382.camel@pmac.infradead.org> References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> <1211405127.21380.382.camel@pmac.infradead.org> Message-ID: <1211405983.3801.402.camel@localhost.localdomain> On Wed, 2008-05-21 at 22:25 +0100, David Woodhouse wrote: > On Wed, 2008-05-21 at 18:21 -0300, Alexandre Oliva wrote: > > I believe I've already explained why I can't do that. I refuse to > > distribute non-Free Software, and posting a patch that removes these > > bits amounts to posting those very bits. > > Really, that's a stupid objection. Just post it in ed form. > > Kernel-libre is a very bad plan; just help move the firmware which > offends you out of the kernel instead. This is one of those rare (and yet, wonderful) occasions upon which I entirely agree with David. ;) ~spot From tcallawa at redhat.com Wed May 21 21:47:41 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 21 May 2008 17:47:41 -0400 Subject: license tag cleanups In-Reply-To: <1211403466.3801.378.camel@localhost.localdomain> References: <1211403466.3801.378.camel@localhost.localdomain> Message-ID: <1211406461.3801.404.camel@localhost.localdomain> On Wed, 2008-05-21 at 16:57 -0400, Tom "spot" Callaway wrote: > Just as a heads-up, I'm in the process of cleaning up the remaining > license tags which are not compliant with: > http://fedoraproject.org/wiki/Licensing Since a few people have asked, if you're crazy enough to want to volunteer to help with this task, just let me know, and I'll throw part of my list at you. ~spot From skvidal at fedoraproject.org Wed May 21 21:43:18 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 21 May 2008 17:43:18 -0400 Subject: license tag cleanups In-Reply-To: <1211406461.3801.404.camel@localhost.localdomain> References: <1211403466.3801.378.camel@localhost.localdomain> <1211406461.3801.404.camel@localhost.localdomain> Message-ID: <1211406198.3559.29.camel@cutter> On Wed, 2008-05-21 at 17:47 -0400, Tom "spot" Callaway wrote: > On Wed, 2008-05-21 at 16:57 -0400, Tom "spot" Callaway wrote: > > Just as a heads-up, I'm in the process of cleaning up the remaining > > license tags which are not compliant with: > > http://fedoraproject.org/wiki/Licensing > > Since a few people have asked, if you're crazy enough to want to > volunteer to help with this task, just let me know, and I'll throw part > of my list at you. send me some of them. -sv From jonstanley at gmail.com Wed May 21 22:00:25 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Wed, 21 May 2008 18:00:25 -0400 Subject: license tag cleanups In-Reply-To: <1211406198.3559.29.camel@cutter> References: <1211403466.3801.378.camel@localhost.localdomain> <1211406461.3801.404.camel@localhost.localdomain> <1211406198.3559.29.camel@cutter> Message-ID: On Wed, May 21, 2008 at 5:43 PM, seth vidal wrote: >> Since a few people have asked, if you're crazy enough to want to >> volunteer to help with this task, just let me know, and I'll throw part >> of my list at you. > > send me some of them. Me too. Not an elegant task, but if we split it up, it goes faster and less work for you to do :) Are we building for rawhide, as well? From laxathom at fedoraproject.org Wed May 21 22:09:48 2008 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Thu, 22 May 2008 00:09:48 +0200 Subject: license tag cleanups In-Reply-To: References: <1211403466.3801.378.camel@localhost.localdomain> <1211406461.3801.404.camel@localhost.localdomain> <1211406198.3559.29.camel@cutter> Message-ID: <62bc09df0805211509s85c9e49ue6e39bc0b4af4850@mail.gmail.com> 2008/5/22 Jon Stanley : > On Wed, May 21, 2008 at 5:43 PM, seth vidal > wrote: > > >> Since a few people have asked, if you're crazy enough to want to > >> volunteer to help with this task, just let me know, and I'll throw part > >> of my list at you. > > > > send me some of them. > > Me too. Not an elegant task, but if we split it up, it goes faster > and less work for you to do :) Are we building for rawhide, as well? > Note that, you should not just looking at the COPYING, LICENSE, README files to fix license tag ;). Many packages are shipped with files (i.e, headers or *.c files) which are written into a differente licenses or license version. -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From dr.diesel at gmail.com Wed May 21 22:22:42 2008 From: dr.diesel at gmail.com (Dr. Diesel) Date: Wed, 21 May 2008 18:22:42 -0400 Subject: Anyone else with hard freezes? In-Reply-To: <2a28d2ab0805160503j4c841d5fh67a9e493a7c938ad@mail.gmail.com> References: <80d7e4090805081625m111b7955v2c96d864275334b2@mail.gmail.com> <1210398432.17530.0.camel@optimus> <2a28d2ab0805130448s2b3e8c8aw5e526bd04949d60a@mail.gmail.com> <2a28d2ab0805131341x6d4d6332nd89e1252839f3866@mail.gmail.com> <2a28d2ab0805140713h542598d6y5c010885dac62687@mail.gmail.com> <482AF52D.1080509@poolshark.org> <2a28d2ab0805141459j22db5edcmb858afd627ea5d01@mail.gmail.com> <2a28d2ab0805151433m1b323ecak47a256b148cb982f@mail.gmail.com> <20080515220101.GA8240@devserv.devel.redhat.com> <2a28d2ab0805160503j4c841d5fh67a9e493a7c938ad@mail.gmail.com> Message-ID: <2a28d2ab0805211522k277cec05r6b588b215e75d446@mail.gmail.com> Well, 24 hours of memtest86 show no errors (27 passes), system is still hosed! Is there any other tests to prove this isn't a hardware failure? I do see amarok in messages but i don't think its been running on all lockup occasion. Please Help! messages: May 21 17:53:47 localhost kernel: BUG: unable to handle kernel paging request at 00000000001200d2 May 21 17:53:47 localhost kernel: IP: [__d_lookup+246/285] __d_lookup+0xf6/0x11d May 21 17:53:47 localhost kernel: PGD 2e08c067 PUD 10e6b067 PMD 2b4b5067 PTE 0 May 21 17:53:47 localhost kernel: Oops: 0000 [21] SMP May 21 17:53:47 localhost kernel: CPU 0 May 21 17:53:47 localhost kernel: Modules linked in: nfs lockd nfs_acl coretemp w83627ehf hwmon_vid hwmon fuse sunrpc ipt_REJECT xt_tcpudp nf_conntrack_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables loop dm_multipath ipv6 snd_hda_intel snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer firewire_ohci snd_page_alloc snd_hwdep firewire_core r8169 snd pata_jmicron crc_itu_t pl2303 pata_acpi i2c_i801 usb_storage iTCO_wdt pcspkr usbserial bay button i2c_core ata_generic soundcore iTCO_vendor_support sg floppy dm_snapshot dm_zero dm_mirror dm_mod ahci libata sd_mod scsi_mod ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd [last unloaded: microcode] May 21 17:53:47 localhost kernel: Pid: 12207, comm: amarokcollectio Tainted: G D 2.6.25.3-18.fc9.x86_64 #1 May 21 17:53:47 localhost kernel: RIP: 0010:[__d_lookup+246/285] [__d_lookup+246/285] __d_lookup+0xf6/0x11d May 21 17:53:47 localhost kernel: RSP: 0018:ffff810010e4bb08 EFLAGS: 00010206 May 21 17:53:47 localhost kernel: RAX: 00000000001200d2 RBX: ffff810013db0ea0 RCX: 0000000000000011 May 21 17:53:47 localhost kernel: RDX: 000000000001c256 RSI: ffff810010e4bbf8 RDI: ffff81003f443ea0 May 21 17:53:47 localhost kernel: RBP: ffff810010e4bb58 R08: 0000000000000000 R09: 0000000000000000 May 21 17:53:47 localhost kernel: R10: 0000000000000003 R11: ffff81002508f390 R12: 00000000001200d2 May 21 17:53:47 localhost kernel: R13: ffff81003f443ea0 R14: ffff810010e4bbf8 R15: 0000000099fa0098 May 21 17:53:47 localhost kernel: FS: 0000000000000000(0000) GS:ffffffff813f6000(0000) knlGS:0000000000000000 May 21 17:53:47 localhost kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 May 21 17:53:47 localhost kernel: CR2: 00000000001200d2 CR3: 0000000010e69000 CR4: 00000000000006e0 May 21 17:53:47 localhost kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 May 21 17:53:47 localhost kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 May 21 17:53:47 localhost kernel: Process amarokcollectio (pid: 12207, threadinfo ffff810010e4a000, task ffff81000f34a000) May 21 17:53:47 localhost kernel: Stack: 000000000000000f 0000000f3f5441ed ffff810026d50900 ffffffff8104184a May 21 17:53:47 localhost kernel: 00000000001200d2 0000000000000000 ffff810010e4be88 ffff81003f54e3c8 May 21 17:53:47 localhost kernel: ffff810026d50900 ffff810010e4be88 ffff810010e4bba8 ffffffff810ac3fc May 21 17:53:47 localhost kernel: Call Trace: May 21 17:53:47 localhost kernel: [in_group_p+42/44] ? in_group_p+0x2a/0x2c May 21 17:53:47 localhost kernel: [do_lookup+44/424] do_lookup+0x2c/0x1a8 May 21 17:53:47 localhost kernel: [__link_path_walk+2481/3731] __link_path_walk+0x9b1/0xe93 May 21 17:53:47 localhost kernel: [touch_atime+131/274] ? touch_atime+0x83/0x112 May 21 17:53:47 localhost kernel: [__link_path_walk+3133/3731] __link_path_walk+0xc3d/0xe93 May 21 17:53:47 localhost kernel: [path_walk+97/195] path_walk+0x61/0xc3 May 21 17:53:47 localhost kernel: [do_path_lookup+470/561] do_path_lookup+0x1d6/0x231 May 21 17:53:47 localhost kernel: [__path_lookup_intent_open+92/159] __path_lookup_intent_open+0x5c/0x9f May 21 17:53:47 localhost kernel: [path_lookup_open+12/14] path_lookup_open+0xc/0xe May 21 17:53:47 localhost kernel: [open_namei+118/1696] open_namei+0x76/0x6a0 May 21 17:53:47 localhost kernel: [do_filp_open+40/75] do_filp_open+0x28/0x4b May 21 17:53:47 localhost kernel: [__strncpy_from_user+44/83] ? __strncpy_from_user+0x2c/0x53 May 21 17:53:47 localhost kernel: [get_unused_fd_flags+139/287] ? get_unused_fd_flags+0x8b/0x11f May 21 17:53:47 localhost kernel: [do_sys_open+81/210] do_sys_open+0x51/0xd2 May 21 17:53:47 localhost kernel: [sys_open+27/29] sys_open+0x1b/0x1d May 21 17:53:47 localhost kernel: [tracesys+213/218] tracesys+0xd5/0xda May 21 17:53:47 localhost kernel: May 21 17:53:47 localhost kernel: May 21 17:53:47 localhost kernel: Code: 04 10 75 06 f0 ff 03 48 89 d8 fe 43 08 eb 34 41 fe 44 24 f0 48 8b 45 d0 48 8b 00 48 89 45 d0 48 8b 45 d0 48 85 c0 74 19 49 89 c4 <48> 8b 00 49 8d 5c 24 e8 44 39 7b 30 0f 18 08 75 d8 e9 65 ff ff May 21 17:53:47 localhost kernel: RIP [__d_lookup+246/285] __d_lookup+0xf6/0x11d May 21 17:53:47 localhost kernel: RSP May 21 17:53:47 localhost kernel: CR2: 00000000001200d2 May 21 17:53:47 localhost kernel: ---[ end trace c2ff9cce82980cc9 ]--- May 21 17:53:49 localhost kerneloops: Submitted 1 kernel oopses to www.kerneloops.org Dmesg: BUG: unable to handle kernel paging request at 00000000001200d2 IP: [] __d_lookup+0xf6/0x11d PGD 2e088067 PUD 10f70067 PMD 2dd90067 PTE 0 Oops: 0000 [18] SMP CPU 0 Modules linked in: nfs lockd nfs_acl coretemp w83627ehf hwmon_vid hwmon fuse sunrpc ipt_REJECT xt_tcpudp nf_conntrack_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables loop dm_multipath ipv6 snd_hda_intel snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer firewire_ohci snd_page_alloc snd_hwdep firewire_core r8169 snd pata_jmicron crc_itu_t pl2303 pata_acpi i2c_i801 usb_storage iTCO_wdt pcspkr usbserial bay button i2c_core ata_generic soundcore iTCO_vendor_support sg floppy dm_snapshot dm_zero dm_mirror dm_mod ahci libata sd_mod scsi_mod ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd [last unloaded: microcode] Pid: 12190, comm: amarokcollectio Tainted: G D 2.6.25.3-18.fc9.x86_64 #1 RIP: 0010:[] [] __d_lookup+0xf6/0x11d RSP: 0018:ffff810010f5fb08 EFLAGS: 00010206 RAX: 00000000001200d2 RBX: ffff810013db0ea0 RCX: 0000000000000011 RDX: 000000000001c256 RSI: ffff810010f5fbf8 RDI: ffff81003f443ea0 RBP: ffff810010f5fb58 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000003 R11: ffff81002508f390 R12: 00000000001200d2 R13: ffff81003f443ea0 R14: ffff810010f5fbf8 R15: 0000000099fa0098 FS: 0000000000000000(0000) GS:ffffffff813f6000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000001200d2 CR3: 0000000010e45000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process amarokcollectio (pid: 12190, threadinfo ffff810010f5e000, task ffff810010e26000) Stack: 000000000000000f 0000000f3f5441ed ffff810026d50900 ffffffff8104184a 00000000001200d2 0000000000000000 ffff810010f5fe88 ffff81003f54e3c8 ffff810026d50900 ffff810010f5fe88 ffff810010f5fba8 ffffffff810ac3fc Call Trace: [] ? in_group_p+0x2a/0x2c [] do_lookup+0x2c/0x1a8 [] __link_path_walk+0x9b1/0xe93 [] ? touch_atime+0x83/0x112 [] __link_path_walk+0xc3d/0xe93 [] path_walk+0x61/0xc3 [] do_path_lookup+0x1d6/0x231 [] __path_lookup_intent_open+0x5c/0x9f [] path_lookup_open+0xc/0xe [] open_namei+0x76/0x6a0 [] do_filp_open+0x28/0x4b [] ? __strncpy_from_user+0x2c/0x53 [] ? get_unused_fd_flags+0x8b/0x11f [] do_sys_open+0x51/0xd2 [] sys_open+0x1b/0x1d [] tracesys+0xd5/0xda Code: 04 10 75 06 f0 ff 03 48 89 d8 fe 43 08 eb 34 41 fe 44 24 f0 48 8b 45 d0 48 8b 00 48 89 45 d0 48 8b 45 d0 48 85 c0 74 19 49 89 c4 <48> 8b 00 49 8d 5c 24 e8 44 39 7b 30 0f 18 08 75 d8 e9 65 ff ff RIP [] __d_lookup+0xf6/0x11d RSP CR2: 00000000001200d2 ---[ end trace c2ff9cce82980cc9 ]--- On Fri, May 16, 2008 at 8:03 AM, Dr. Diesel wrote: > On Thu, May 15, 2008 at 5:01 PM, Alan Cox wrote: >> On Thu, May 15, 2008 at 05:33:02PM -0400, Dr. Diesel wrote: >>> And more! >>> >>> ISO 9660 Extensions: Microsoft Joliet Level 3 >>> ISO 9660 Extensions: RRIP_1991A >>> mtrr: no MTRR for d0000000,ff00000 found >>> console-kit-dae[2420]: segfault at 8 ip 3c67e2a699 sp 4100fff0 error 4 >>> in libglib-2.0.so.0.1600.3[3c67e00000+de000] >>> mtrr: base(0xd0000000) is not aligned on a size(0xff00000) boundary >> >> Out of curiosity what does memtest86 think of the box. A mix of random memory >> and disk corruptions is a good candidate for suspecting RAM (although it's >> certainly not conclusive and it could be an FC9 triggered bug) > > That figures! I ran memtest86 and folding for 12+ hours when the > freezing first started, no errors. I re-run it last night at your > request and get an error! Only one, at the top, 2049meg, ran it > several times, all that the same place. > > Probably why I only see the freezes after a few days. I'll report > back if it makes a week or so with no issues. > > Thanks to all. > > -- > projecthuh.com > All of my bits are free, are yours? Fedoraproject.org > -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org From orion at cora.nwra.com Wed May 21 22:31:27 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 21 May 2008 16:31:27 -0600 Subject: perl 5.10 include location In-Reply-To: <1211403336.3801.374.camel@localhost.localdomain> References: <48347EB8.6030805@cora.nwra.com> <48348647.4020708@cora.nwra.com> <1211403336.3801.374.camel@localhost.localdomain> Message-ID: <4834A2BF.3050000@cora.nwra.com> Tom "spot" Callaway wrote: > On Wed, 2008-05-21 at 14:29 -0600, Orion Poplawski wrote: >> Orion Poplawski wrote: >>> Is there some tool one should use to determine the location of the perl >>> 5.10 include files (e.g.: >>> /usr/lib/perl5/5.10.0/i386-linux-thread-multi/CORE)? >> perl -MExtUtils::Embed -e perl_inc > > Just be sure to BuildRequires: perl(ExtUtils::Embed). > > ~spot > Yeah, I guess that's what got me tripped up. Seems like the dependencies here have changed recently. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From stlwrt at gmail.com Wed May 21 22:37:39 2008 From: stlwrt at gmail.com (Pavel Shevchuk) Date: Thu, 22 May 2008 01:37:39 +0300 Subject: New Xorg In-Reply-To: <1211356132.3215.19.camel@localhost.localdomain> References: <1211343195.2928.25.camel@jdlaptop> <4833A405.6070802@gnat.ca> <1211356132.3215.19.camel@localhost.localdomain> Message-ID: I should add that nvidia, contrary to ati, never made me cry out loud for better driver, and having UNRELEASED xserver is my own fault. With LATEST STABLE xserver 1.4 and latest driver i am more than happy with my 8600gt playing nexuiz, openarena and warsow. This thread reminds me rants of people who fail offroad having sports car On 5/21/08, Kevin Page wrote: > > On Tue, 2008-05-20 at 22:24 -0600, Nathanael D. Noblet wrote: > > Me too. I'd not use it if I could have spanning desktops in the OSS > > version of the driver. > > > This now works for me with nouveau in F9 (thanks!), though I appreciate > it may not for all nvidia cards. I need to add: > "Option" "randr12" "1" > to xorg.conf > > I very much support the stance Fedora takes on this! > > kev. > > (Though it has to be said, my previous solution - adding a Radeon PCI > card as the second head to the Nvidia PCIe card inflicted upon me - > still doesn't seem to work, with no indication as to whether it ever > will/should. It's tough to find a dual-head DVI solution using open > source drivers; speculatively buying hardware until something works > isn't always feasible. > https://bugs.freedesktop.org/show_bug.cgi?id=2597 > https://bugzilla.redhat.com/show_bug.cgi?id=227851 > > ) > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- http://scwlab.com From bpepple at fedoraproject.org Wed May 21 23:01:10 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 21 May 2008 19:01:10 -0400 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: References: <1211377739.4210.2.camel@truman> Message-ID: <1211410870.2290.5.camel@kennedy> On Wed, 2008-05-21 at 16:20 -0300, Alexandre Oliva wrote: > On May 21, 2008, Brian Pepple wrote: > > . Permission to distribute under the mark 'Fedora' spins containing > kernel-libre packages, whose sole difference from identically-numbered > Fedora kernel builds is the removal of a few pieces of non-Free > Software. I've gone ahead and add the kernel-libre topic to the schedule for tomorrow. I've put it at the end of the agenda though, since I want to make sure we get to the other items on the schedule before we begin this discussion (since I'm guessing it will be fairly lengthy). Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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: 197 bytes Desc: This is a digitally signed message part URL: From jwboyer at gmail.com Wed May 21 23:40:47 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 21 May 2008 18:40:47 -0500 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> Message-ID: <20080521184047.7b19e70b@vader.jdub.homelinux.org> On Wed, 21 May 2008 18:21:41 -0300 Alexandre Oliva wrote: > I didn't mean to start the discussion here. Is this normal procedure? Sure. Any email is open for discussion. > On May 21, 2008, Josh Boyer wrote: > > > On Wed, 21 May 2008 16:20:39 -0300 > > Alexandre Oliva wrote: > > >> On May 21, 2008, Brian Pepple wrote: > >> > >> > You want something to be discussed? Send a note to the list in reply to > >> > this mail and I'll add it to the schedule. > >> > >> Given that Freedom? is a major fedora feature, I'd like to discuss > >> enabling the creation of Fedora spins containing exclusively Free > >> Software. These are related sub-topics: > >> > >> . Permission to distribute under the mark 'Fedora' spins containing > >> kernel-libre packages, whose sole difference from identically-numbered > >> Fedora kernel builds is the removal of a few pieces of non-Free > >> Software. > > > All spins must be composed of packages that are contained within the > > Fedora repositories. kernel-libre does not fit that category (today). > > IOW, you oppose the idea of making an exception to enable people to > distribute spins of Fedora with the Freedom? feature in it? Yes. > >> . Inclusion in Fedora (future and recent past releases) of the > >> kernel-libre package, a 100% Free Software variant of the kernel > >> Linux, that I've been maintaining tracking Fedora kernel builds at > >> http://www.fsfla.org/~lxoliva/fsfla/linux-libre/ > > > We've had this discussion. We aren't going to allow a forked kernel > > package. > > We're talking about a different package here. This is not a fork. > Call it a branch if you must label it to achieve the purpose of > denying freedom to Fedora users. Ok, then I'll call it an alternate kernel package. Which we still aren't going to allow. > > Please work with the kernel team to integrate this into the > > main kernel package. > > I believe I've already explained why I can't do that. I refuse to > distribute non-Free Software, and posting a patch that removes these > bits amounts to posting those very bits. So work with upstream to get them removed or pushed to separate firmware packages. > Now, how about *you* work with the Fedora team to provide Fedora users > with one of its advertised features? I wouldn't mind if you took the > xdelta or the tarball or the srpm I created, that provides Fedora > users with freedom, and took it upstream. But both of us know > upstream doesn't want that and doesn't care about the freedom that > Fedora claims to care about. How do we get out of this conundrum? Given your preference to not work in a manner which would be compatible with Fedora Engineering practices, I'm not sure there is a way out. However perhaps you can enlist some help from someone that would be willing to do that. > Admit that Fedora is not about Freedom, such that I move on and stop > trying to achieve the stated goal, or actually work to at least enable > users to enjoy this stated goal? I think that's hyperbole. I also think the firmware rules we have in place are fair and beneficial for most users. I have no problems with you working towards your goal. As I said before, I commend it. However doing that with an alternative kernel package isn't something that sits well. > >> . Inclusion in Fedora (future and recent past releases) of a > >> fedora-freedom "virtual" package, that Requires: linux-libre and > >> Conflicts: with any Fedora package known to contain software (firmware > >> included) that does not respect the 4 freedoms established in the Free > >> Software definition. AFAIK these would pretty much amount to the > >> standard non-Free kernel and a bunch of *-firmware packages, but there > >> could be sub-packages to cover other debatable packages with obscure > >> source code, dubious licensing policies, etc. > > > You don't need a package. Make a comps group. > > One of us is missing something. How would a comps group prevent the > accidental installation of say non-Free kernel or firmware packages > brought in through unintended dependencies, for a user who wants to > make sure no such software is installed, for example? Fine, a fair point. Create a Free spin via a kickstart file. Having that virtual package is more pain to maintain than a ks file and sort of goes against how we tend to do things. > > I think we can certainly discuss it. However I believe the biggest > > hurdle to what you propose is the extra kernel-libre package. > > I suppose you're talking about disk space. I sympathize with that, Hardly. I'm talking about having any alternate kernel, period. > > Your overall proposal hinges on that, and the way you've stated you > > would like to provide it has been frowned upon quite a bit. > > And largely misunderstood while at that. Not by everyone who objected > to it, for sure. I don't think there's been a large misunderstanding. Simply two differing opinions on the matter. josh From aoliva at redhat.com Wed May 21 23:53:53 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Wed, 21 May 2008 20:53:53 -0300 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: <1211405127.21380.382.camel@pmac.infradead.org> (David Woodhouse's message of "Wed\, 21 May 2008 22\:25\:27 +0100") References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> <1211405127.21380.382.camel@pmac.infradead.org> Message-ID: On May 21, 2008, David Woodhouse wrote: > On Wed, 2008-05-21 at 18:21 -0300, Alexandre Oliva wrote: >> I believe I've already explained why I can't do that. I refuse to >> distribute non-Free Software, and posting a patch that removes these >> bits amounts to posting those very bits. > Really, that's a stupid objection. Just post it in ed form. Assuming that's acceptable upstream. I sort of doubt it, but then, I could send xdeltas as well, and if you've been part of the discussion, then you probably know that that's not the only reason why I can't take part in this plan. Another I still haven't mentioned is that I have no interest in being harrassed and verbally abused like the last discussion about freedom issues I got into there. Now, let me show you why this proposed plan is an impossible mission that people are trying to drive me into. Consider this snippet from http://www.fsfla.org/svn/fsfla/software/linux-libre/scripts/deblob-2.6.25 # SND_KORG1212 - Korg 1212 IO clean_ifdef sound/pci/korg1212/korg1212.c CONFIG_SND_KORG1212_FIRMWARE_IN_KERNEL clean_blob sound/pci/korg1212/korg1212-firmware.h # SND_MAESTRO3 - ESS Allegro/Maestro3 clean_ifdef sound/pci/maestro3.c CONFIG_SND_MAESTRO3_FIRMWARE_IN_KERNEL # SND_YMFPCI - Yamaha YMF724/740/744/754 clean_blob sound/pci/ymfpci/ymfpci_image.h clean_ifdef sound/pci/ymfpci/ymfpci_main.c CONFIG_SND_YMFPCI_FIRMWARE_IN_KERNEL clean_blob() removes long sequences of numbers, whereas clean_ifdef() runs unifdef on the named file assuming the named variable is undefined. Could you honestly tell me, with a straight face and a reasonable degree of assurance, that a patch that performs these actions stands any chance whatsoever of being accepted upstream? The firmwares are already optional to compile in, they can already be loaded with the standard firmware loading machinery. But while they're there, in the source code, distributing the kernel sources amounts to distributing this non-Free Software, and distributing binaries built out of these sources, even with these options disabled, amounts to distributing the this non-Free Software as part of the kernel sources or committing to distributing it over the next 3 years. One way or another, it amounts to propagating the problem. If you tell me with a straight face that something like this stands a chance of being accepted, I will give that a try. Otherwise, please stop sending me in a mission that can't possibly be accomplished in a way that achieves our shared goals of providing users with freedom, with an operating system built out of only Free Software. If Fedora cares about users' freedom, why would it follow and abide by policies and dubious legal theories set by someone who doesn't and is proud of it? Does anyone think the issue about non-Free firmwares is any different from the issue of non-Free drivers for nvidia cards, except for the irrelevant detail that these different pieces of software can corrupt the system (technically and morally) running on different CPUs? Seriously? Why do we bend over to keep compatibility and even distribute binary-only code published by with vendors who have taken dubious measures such as releasing code under the GPL without sources, or explicitly contributing, to the kernel Linux, code under licenses incompatible with its license, when an alternative is readily available and looking forward to being included and with an active maintainer that has already proved to be able to keep up even with daily rawhide builds, and at the same time we proudly defend the decision to ship X drivers that disregard (for good reasons) compatibility with non-Free code? What is it that appears to make these issues different? Is nVidia any less supportive to our community than any of the other vendors who push hardware and then push non-Free Software to enable their customers to use the hardware at full power? Aren't we forgetting something, or drawing a line at a point that is absolutely arbitrary (which might be fine) and not in sync with our mission (with is certainly not fine)? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From vonbrand at inf.utfsm.cl Wed May 21 23:58:24 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Wed, 21 May 2008 19:58:24 -0400 Subject: Xorg 1.5 missed the train? In-Reply-To: <48345B6C.3030204@gmail.com> References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <1211383722.8531.63.camel@localhost.localdomain> <1211385285.8531.65.camel@localhost.localdomain> <544eb990805210917y45a7df22hb867b7e8e027d474@mail.gmail.com> <48344D6E.6000006@gmail.com> <544eb990805210935k781bcbafn6165c3e03aa72d10@mail.gmail.com> <4834533D.7010007@gmail.com> <544eb990805211001q75c28580k8b344b638451f223@mail.gmail.com> <48345B6C.3030204@gmail.com> Message-ID: <200805212358.m4LNwOim024392@laptop13.inf.utfsm.cl> Les Mikesell wrote: > Bill Crawford wrote: > >> What is it that would suggest that it is finalized to a manager that might > >> want to commit resources to writing a driver his company will have to > >> support? > > So why should "Fedora" commit to supporting "binary driver Foo" > > before their release is ready? > That has nothing to do with what I said. I'm suggesting that fedora > should ship with interfaces that are publicized as standard, Check. This is the API for 1.5. > and allow > time for changes in this standard to propagate before shipping > something different from the standard. Check. Changes had been widely announced, previews shipped in rawhide and prereleases. > This has nothing to do with > supporting anything or anyone. It is common decency in interaction. Yep. nVidia is extremely rude in not following the lead, given that everybody else is working in the open. Heck, when a new Windows ships, they /are/ ready for it, even though everybody is carefully kept in the dark. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From aoliva at redhat.com Thu May 22 00:28:21 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Wed, 21 May 2008 21:28:21 -0300 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: <20080521184047.7b19e70b@vader.jdub.homelinux.org> (Josh Boyer's message of "Wed\, 21 May 2008 18\:40\:47 -0500") References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> <20080521184047.7b19e70b@vader.jdub.homelinux.org> Message-ID: On May 21, 2008, Josh Boyer wrote: > Ok, then I'll call it an alternate kernel package. Which we still > aren't going to allow. > However doing that with an alternative kernel > package isn't something that sits well. > I'm talking about having any alternate kernel, period. I have never opposed the idea of replacing the non-Free kernel Fedora ships today with linux-libre or any of its predecessors. I just thought proposing it as an alternative that I offered to maintain myself would generate less heat. Maybe I was mistaken. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From aoliva at redhat.com Thu May 22 00:35:09 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Wed, 21 May 2008 21:35:09 -0300 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: <20080521184047.7b19e70b@vader.jdub.homelinux.org> (Josh Boyer's message of "Wed\, 21 May 2008 18\:40\:47 -0500") References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> <20080521184047.7b19e70b@vader.jdub.homelinux.org> Message-ID: On May 21, 2008, Josh Boyer wrote: > So work with upstream to get them removed or pushed to separate > firmware packages. It's been tried before. I gather upstream is not interested in achieving a 100% Free Software kernel tarball. It's in conflict with our stated mission. Where do we go from that point, when upstream is not cooperative and there is a drop-in alternative. > Given your preference to not work in a manner which would be compatible > with Fedora Engineering practices, This is a very unfair assumption. I just have had access to facts that you apparently didn't. Either that or you're being intentionally obnoxious in sending me down this wild goose chase. > I'm not sure there is a way out. However perhaps you can enlist > some help from someone that would be willing to do that. Finding someone else to do it might enable more patches to be posted, but it wouldn't make it possible to achieve the goal. >> One of us is missing something. How would a comps group prevent the >> accidental installation of say non-Free kernel or firmware packages >> brought in through unintended dependencies, for a user who wants to >> make sure no such software is installed, for example? > Fine, a fair point. Create a Free spin via a kickstart file. Still no use, unless the spin comes with its own separate repository, never contaminated by non-Free Software. At which point users might as well switch to BLAG. > Having that virtual package is more pain to maintain than a ks file Err... The only person I know who has volunteered to maintain this package disagrees with this assessment, especially because the ks file does not even begin to address the longer-term goal of enabling a user to avoid the installation of non-Free Software on his system (install time and updates over time), rather than a short-term goal of avoiding the inclusion of non-Free Software in one particular spin. >> And largely misunderstood while at that. Not by everyone who objected >> to it, for sure. > I don't think there's been a large misunderstanding. Simply two > differing opinions on the matter. Like, a number of people vehemently objected to the idea of replacing the current kernel with linux-libre. I hadn't proposed anything even close to it. That's a large misunderstanding to me. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From ndbecker2 at gmail.com Thu May 22 01:09:46 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Wed, 21 May 2008 21:09:46 -0400 Subject: missing libphonon.so? Message-ID: ls -l /usr/lib64/libphonon* lrwxrwxrwx 1 root root 30 2008-05-21 19:32 /usr/lib64/libphononexperimental.so.4 -> libphononexperimental.so.4.0.4 -rwxr-xr-x 1 root root 37280 2008-05-15 09:54 /usr/lib64/libphononexperimental.so.4.0.4 lrwxrwxrwx 1 root root 18 2008-05-21 19:32 /usr/lib64/libphonon.so.4 -> libphonon.so.4.0.4 -rwxr-xr-x 1 root root 285264 2008-05-15 09:54 /usr/lib64/libphonon.so.4.0.4 There is no link libphonon.so -> libphonon.so.4.0.4 I have kdelibs-devel installed. From denis at poolshark.org Thu May 22 01:10:14 2008 From: denis at poolshark.org (Denis Leroy) Date: Wed, 21 May 2008 18:10:14 -0700 Subject: Xorg 1.5 missed the train? In-Reply-To: <4834729F.8030507@hi.is> References: <48334163.4080709@magma.ca> <48337D52.7050005@poolshark.org> <4834729F.8030507@hi.is> Message-ID: <4834C7F6.1010100@poolshark.org> J?hann B. Gu?mundsson wrote: > Denis Leroy wrote: >> Jason Tang wrote: >>> The only problem being that this release is incompatible with current >>> nvidia drivers. Granted, I'm aware of the Fedora position regarding >>> non-OSS, but this Xorg issue has completely destroyed many user's >>> confidence in the dev team. >> >> That's nothing new you know. Out of the 9 fedora releases, I think at >> least 8 out of 9 didn't work with the Nvidia driver at release time. >> however Nvidia is usually pretty good at playing catch up. >> >> I'm also hostage to Nvidia's good will for my Lenovo T61's Quadro >> chipset, and can't upgrade to F-9 until their next release (nv doesn't >> work at all on this chipset). I wouldn't go back to a Radeon chipset >> though, not until we have a working free equivalent (emphasis on >> 'working') to nvidia-settings for easy dual-head support... The good >> news is that with xrandr maturing, we're probably almost there. >> > Interesting... > > I have no "nv" problems on my Lenovo T61p with Quadro FX570M. > Running with no xorg.conf. ... > http://www.smolts.org/client/show/pub_1536ec85-61c8-49d4-aeaa-3852a20d5d29 Hmm, mine is a NVS 140M. nv yields a black screen. Even if nv worked, it's unbearably slow and can't handle dual 1680x1050 screens. But I would never criticize the Xorg developers, the only culprit for nv being so bad is NVidia itself... From jwboyer at gmail.com Thu May 22 01:22:01 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 21 May 2008 20:22:01 -0500 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> <20080521184047.7b19e70b@vader.jdub.homelinux.org> Message-ID: <20080521202201.2b0f53d4@vader.jdub.homelinux.org> On Wed, 21 May 2008 21:28:21 -0300 Alexandre Oliva wrote: > On May 21, 2008, Josh Boyer wrote: > > > Ok, then I'll call it an alternate kernel package. Which we still > > aren't going to allow. > > > However doing that with an alternative kernel > > package isn't something that sits well. > > > I'm talking about having any alternate kernel, period. > > I have never opposed the idea of replacing the non-Free kernel Fedora > ships today with linux-libre or any of its predecessors. I just > thought proposing it as an alternative that I offered to maintain > myself would generate less heat. Maybe I was mistaken. I didn't say you were going to outright replace it. But having more than one kernel package will not be allowed. It has been discussed in the past for things not even related to kernel-libre. josh From jwboyer at gmail.com Thu May 22 01:41:48 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 21 May 2008 20:41:48 -0500 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> <20080521184047.7b19e70b@vader.jdub.homelinux.org> Message-ID: <20080521204148.66eff81f@vader.jdub.homelinux.org> On Wed, 21 May 2008 21:35:09 -0300 Alexandre Oliva wrote: > On May 21, 2008, Josh Boyer wrote: > > > So work with upstream to get them removed or pushed to separate > > firmware packages. > > It's been tried before. I gather upstream is not interested in > achieving a 100% Free Software kernel tarball. It's in conflict with > our stated mission. Where do we go from that point, when upstream is > not cooperative and there is a drop-in alternative. Tough spot. I don't have an answer for you. > > Given your preference to not work in a manner which would be compatible > > with Fedora Engineering practices, > > This is a very unfair assumption. I just have had access to facts > that you apparently didn't. Either that or you're being intentionally > obnoxious in sending me down this wild goose chase. I wouldn't send you on a goose chase. Can you point me to where you've approached the upstream kernel maintainers about this? > > I'm not sure there is a way out. However perhaps you can enlist > > some help from someone that would be willing to do that. > > Finding someone else to do it might enable more patches to be posted, > but it wouldn't make it possible to achieve the goal. Because? If those patches get integrated, then wouldn't the parts you find objectionable be gone? > >> One of us is missing something. How would a comps group prevent the > >> accidental installation of say non-Free kernel or firmware packages > >> brought in through unintended dependencies, for a user who wants to > >> make sure no such software is installed, for example? > > > Fine, a fair point. Create a Free spin via a kickstart file. > > Still no use, unless the spin comes with its own separate repository, > never contaminated by non-Free Software. At which point users might > as well switch to BLAG. I don't understand that at all. You're suggesting that Fedora would have to split up the actual repositories in order to accomplish your goal? > > Having that virtual package is more pain to maintain than a ks file > > Err... The only person I know who has volunteered to maintain this > package disagrees with this assessment, especially because the ks file > does not even begin to address the longer-term goal of enabling a user > to avoid the installation of non-Free Software on his system (install > time and updates over time), rather than a short-term goal of avoiding > the inclusion of non-Free Software in one particular spin. So you propose to have this virtual package updated constantly to account for new dependencies on what _should_ be mostly firmware packages as they show up? That seems tedious and error prone, but if that's what you want you can certainly attempt it. > >> And largely misunderstood while at that. Not by everyone who objected > >> to it, for sure. > > > I don't think there's been a large misunderstanding. Simply two > > differing opinions on the matter. > > Like, a number of people vehemently objected to the idea of replacing > the current kernel with linux-libre. I hadn't proposed anything even > close to it. That's a large misunderstanding to me. I certainly didn't think you intended to _replace_ the main kernel package. But I don't agree with even providing a completely different alternative "kernel-libre" package. If it can't be built as a flavor of the existing kernel package, then I don't see it being approved for inclusion. josh From a.badger at gmail.com Thu May 22 02:01:22 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 21 May 2008 19:01:22 -0700 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> <1211405127.21380.382.camel@pmac.infradead.org> Message-ID: <4834D3F2.90409@gmail.com> Alexandre Oliva wrote: > On May 21, 2008, David Woodhouse wrote: > >> On Wed, 2008-05-21 at 18:21 -0300, Alexandre Oliva wrote: >>> I believe I've already explained why I can't do that. I refuse to >>> distribute non-Free Software, and posting a patch that removes these >>> bits amounts to posting those very bits. > >> Really, that's a stupid objection. Just post it in ed form. > > Assuming that's acceptable upstream. I sort of doubt it, but then, I > could send xdeltas as well, and if you've been part of the discussion, > then you probably know that that's not the only reason why I can't > take part in this plan. > > Another I still haven't mentioned is that I have no interest in being > harrassed and verbally abused like the last discussion about freedom > issues I got into there. > > > Now, let me show you why this proposed plan is an impossible mission > that people are trying to drive me into. Consider this snippet from > http://www.fsfla.org/svn/fsfla/software/linux-libre/scripts/deblob-2.6.25 > > # SND_KORG1212 - Korg 1212 IO > clean_ifdef sound/pci/korg1212/korg1212.c CONFIG_SND_KORG1212_FIRMWARE_IN_KERNEL > clean_blob sound/pci/korg1212/korg1212-firmware.h > > # SND_MAESTRO3 - ESS Allegro/Maestro3 > clean_ifdef sound/pci/maestro3.c CONFIG_SND_MAESTRO3_FIRMWARE_IN_KERNEL > > # SND_YMFPCI - Yamaha YMF724/740/744/754 > clean_blob sound/pci/ymfpci/ymfpci_image.h > clean_ifdef sound/pci/ymfpci/ymfpci_main.c CONFIG_SND_YMFPCI_FIRMWARE_IN_KERNEL > > clean_blob() removes long sequences of numbers, whereas clean_ifdef() > runs unifdef on the named file assuming the named variable is > undefined. > > Could you honestly tell me, with a straight face and a reasonable > degree of assurance, that a patch that performs these actions stands > any chance whatsoever of being accepted upstream? > > The firmwares are already optional to compile in, they can already be > loaded with the standard firmware loading machinery. > > But while they're there, in the source code, distributing the kernel > sources amounts to distributing this non-Free Software, and > distributing binaries built out of these sources, even with these > options disabled, amounts to distributing the this non-Free Software > as part of the kernel sources or committing to distributing it over > the next 3 years. One way or another, it amounts to propagating the > problem. > > If you tell me with a straight face that something like this stands a > chance of being accepted, I will give that a try. Otherwise, please > stop sending me in a mission that can't possibly be accomplished in a > way that achieves our shared goals of providing users with freedom, > with an operating system built out of only Free Software. > > If Fedora cares about users' freedom, why would it follow and abide by > policies and dubious legal theories set by someone who doesn't and is > proud of it? > > Does anyone think the issue about non-Free firmwares is any different > from the issue of non-Free drivers for nvidia cards, except for the > irrelevant detail that these different pieces of software can corrupt > the system (technically and morally) running on different CPUs? Yes. > Seriously? > Yes. > Why do we bend over to keep compatibility and even distribute > binary-only code published by with vendors who have taken dubious > measures such as releasing code under the GPL without sources, or > explicitly contributing, to the kernel Linux, code under licenses > incompatible with its license, when an alternative is readily > available and looking forward to being included and with an active > maintainer that has already proved to be able to keep up even with > daily rawhide builds, and at the same time we proudly defend the > decision to ship X drivers that disregard (for good reasons) > compatibility with non-Free code? > > What is it that appears to make these issues different? Is nVidia any > less supportive to our community than any of the other vendors who > push hardware and then push non-Free Software to enable their > customers to use the hardware at full power? Aren't we forgetting > something, or drawing a line at a point that is absolutely arbitrary > (which might be fine) and not in sync with our mission (with is > certainly not fine)? > There's free software as in legally licensed for us to use distribute and modify and there's free software as in four freedoms free. Unless I've missed something, the firmware in the kernel is licensed under the GPLv2 and therefore it is legally licensed for us to use, distribute, and modify. When dealing with firmware for driving a device, that's enough for a lot of us. In fact, that's more than enough in some cases as our policies [1]_ currently allow firmware packages that are freely modifiable if they are redistributable. .. [1]: http://fedoraproject.org/wiki/Licensing#BinaryFirmware -Toshio From wart at kobold.org Thu May 22 02:05:54 2008 From: wart at kobold.org (Wart) Date: Wed, 21 May 2008 19:05:54 -0700 Subject: obsoleting -selinux subpackages Message-ID: <4834D502.1090209@kobold.org> In an earlier F-? release, I had added a cyphesis-selinux subpackage which added selinux protection to the cyphesis game server. This policy has now been added to the selinux-policy-targeted package, and I need to have cyphesis-selinux removed. There are two places where this can be done safely, afaik: (a) Add 'Obsoletes: cyphesis-selinux' to the cyphesis base package (b) Add 'Obsoletes: cyphesis-selinux' to the selinux-policy-targeted package I'm tempted to go with (a) because it keeps us from having to add many Obsoletes: tags to the selinux policy packages as the -selinux subpackage get merged in. Is (a) an acceptable solution? --Wart From mjs at clemson.edu Thu May 22 02:55:46 2008 From: mjs at clemson.edu (Matthew Saltzman) Date: Thu, 22 May 2008 02:55:46 +0000 Subject: Xorg 1.5 missed the train? In-Reply-To: <4834729F.8030507@hi.is> References: <48334163.4080709@magma.ca> <48337D52.7050005@poolshark.org> <4834729F.8030507@hi.is> Message-ID: <1211424947.31623.55.camel@valkyrie.localdomain> On Wed, 2008-05-21 at 19:06 +0000, "J?hann B. Gu?mundsson" wrote: > Denis Leroy wrote: > > > Interesting... > > I have no "nv" problems on my Lenovo T61p with Quadro FX570M. > Running with no xorg.conf. ... > http://www.smolts.org/client/show/pub_1536ec85-61c8-49d4-aeaa-3852a20d5d29 > > ( Of course 3D aint working but who's using it anyway and certainly 50% > of Fedora's users as some claim ) Does suspend/resume and hibernate/resume work? Suspend was disabled in nv in F8 (even though it worked in vesa with appropriate quirks). > > JB. ... > > -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From mtasaka at ioa.s.u-tokyo.ac.jp Thu May 22 04:52:47 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 22 May 2008 13:52:47 +0900 Subject: rpms/csound/devel csound.spec,1.14,1.15 In-Reply-To: <200805220421.m4M4Ln80018949@cvs-int.fedora.redhat.com> References: <200805220421.m4M4Ln80018949@cvs-int.fedora.redhat.com> Message-ID: <4834FC1F.1040205@ioa.s.u-tokyo.ac.jp> Seth Vidal (skvidal) wrote, at 05/22/2008 01:21 PM +9:00: > Author: skvidal > > Update of /cvs/pkgs/rpms/csound/devel > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv18916 > > Modified Files: > csound.spec > Log Message: > licensing tag fix > > > > > Index: csound.spec > =================================================================== > RCS file: /cvs/pkgs/rpms/csound/devel/csound.spec,v > retrieving revision 1.14 > retrieving revision 1.15 > diff -u -r1.14 -r1.15 > --- csound.spec 1 Feb 2008 16:29:00 -0000 1.14 > +++ csound.spec 22 May 2008 04:20:59 -0000 1.15 > @@ -13,9 +13,9 @@ > Summary: Csound - sound synthesis language and library > Name: csound > Version: 5.03.0 > -Release: 16%{?dist} > +Release: 17%{?dist} > URL: http://csound.sourceforge.net/ > -License: LGPL > +License: LGPLv2+ > Group: Applications/Multimedia > > BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) > @@ -419,6 +419,9 @@ > %doc tutorial/*.py > > %changelog > +* Thu May 22 2008 Seth Vidal - 5.03.0-17 > +- license tag fix > + > * Fri Feb 1 2008 Dan Williams - 5.03.0-16 > - Fix default plugin path on 64-bit platforms (rh #407911) > - Fix file conflicts with other packages (rh #210215) Well, actually the license of csound is a bit problematic. See my comment on https://bugzilla.redhat.com/show_bug.cgi?id=440597#c8 Regards, Mamoru From kevin.kofler at chello.at Thu May 22 04:55:08 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 22 May 2008 04:55:08 +0000 (UTC) Subject: Xorg 1.5 missed the train? References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <1211385285.8531.65.camel@localhost.localdomain> <544eb990805210917y45a7df22hb867b7e8e027d474@mail.gmail.com> <48344D6E.6000006@gmail.com> <544eb990805210935k781bcbafn6165c3e03aa72d10@mail.gmail.com> <4834533D.7010007@gmail.com> <544eb990805211001q75c28580k8b344b638451f223@mail.gmail.com> <48345B6C.3030204@gmail.com> <544eb990805211047l3f9cb8e3pa8acf93f9cfd93fb@mail.gmail.com> <4834639D.1000509@gmail.com> Message-ID: Les Mikesell gmail.com> writes: > > So, this is now irrelevant for > > the discussion (because it does not materially change the outcome of > > the drivers not being ready at F9 release time). > > I don't think anyone can support that claim, given Nvida's public > statement that they would target the X release. You don't seem to get that all this talk about prereleases on their part is just a lame excuse, they didn't behave any differently in the past when what Fedora released was an official X.Org X11 release. The only thing you can possibly fault Fedora and/or X.Org for in this situation is having given NVidia a convenient excuse for their incompetence, laziness, greediness or whatever you want to call it. Kevin Kofler From aoliva at redhat.com Thu May 22 04:58:25 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Thu, 22 May 2008 01:58:25 -0300 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: <20080521204148.66eff81f@vader.jdub.homelinux.org> (Josh Boyer's message of "Wed\, 21 May 2008 20\:41\:48 -0500") References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> <20080521184047.7b19e70b@vader.jdub.homelinux.org> <20080521204148.66eff81f@vader.jdub.homelinux.org> Message-ID: On May 21, 2008, Josh Boyer wrote: > On Wed, 21 May 2008 21:35:09 -0300 > Alexandre Oliva wrote: >> On May 21, 2008, Josh Boyer wrote: >> > Given your preference to not work in a manner which would be compatible >> > with Fedora Engineering practices, >> This is a very unfair assumption. I just have had access to facts >> that you apparently didn't. Either that or you're being intentionally >> obnoxious in sending me down this wild goose chase. > I wouldn't send you on a goose chase. Thank you. > Can you point me to where you've approached the upstream kernel > maintainers about this? I haven't. I'm told others have, and have been ridiculed. From what I gather from the LKML archives and personal experiences there, I have no reason to disbelieve them. >> > I'm not sure there is a way out. However perhaps you can enlist >> > some help from someone that would be willing to do that. >> >> Finding someone else to do it might enable more patches to be posted, >> but it wouldn't make it possible to achieve the goal. > Because? Because upstream doesn't want to achieve this goal, and actively refuses to accept changes essential to get there. > If those patches get integrated, then wouldn't the parts you find > objectionable be gone? Not all of them, no. >> >> One of us is missing something. How would a comps group prevent the >> >> accidental installation of say non-Free kernel or firmware packages >> >> brought in through unintended dependencies, for a user who wants to >> >> make sure no such software is installed, for example? >> > Fine, a fair point. Create a Free spin via a kickstart file. >> Still no use, unless the spin comes with its own separate repository, >> never contaminated by non-Free Software. At which point users might >> as well switch to BLAG. > I don't understand that at all. You're suggesting that Fedora would > have to split up the actual repositories in order to accomplish your > goal? No. I'm suggesting that a fedora-freedom package that conflicts with the non-Free packages in the main repository would be a simpler way to enable users to choose not to let non-Free Software sneak into their computers. > So you propose to have this virtual package updated constantly to > account for new dependencies on what _should_ be mostly firmware > packages as they show up? Yup, except for the 'constantly'. Fortunately, there's not so much non-Free stuff in Fedora. Yes, it is error-prone, and I'm all ears to listen to to better suggestions on how to accomplish this. Ruling out all non-Free Software from Fedora would certainly make this much simpler, but I'm not going to count on that just yet ;-) >> >> And largely misunderstood while at that. Not by everyone who objected >> >> to it, for sure. >> >> > I don't think there's been a large misunderstanding. Simply two >> > differing opinions on the matter. >> >> Like, a number of people vehemently objected to the idea of replacing >> the current kernel with linux-libre. I hadn't proposed anything even >> close to it. That's a large misunderstanding to me. > I certainly didn't think you intended to _replace_ the main kernel > package. But I don't agree with even providing a completely different > alternative "kernel-libre" package. If it can't be built as a flavor > of the existing kernel package, then I don't see it being approved for > inclusion. So much for http://www.linux-books.us/fedora_core_0001.php Fedora Core is a complete desktop and server operating system created entirely with open source software. I'm pretty sure in the good old days something along these lines used to be on Fedora's front page, and that Fedora's mission statement didn't weasel out of it. But I still see people advertising today that 'freedom is a feature'. Unfortunately, it feels like it's buggy in several ways, and the bugs reported in this regard get responses along the lines of CLOSED/UPSTREAM and CLOSED/WONTFIX :-( And 'infinite freedom' is like a bad joke :-( Oh well... -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From kevin.kofler at chello.at Thu May 22 05:01:52 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 22 May 2008 05:01:52 +0000 (UTC) Subject: Xorg 1.5 missed the train? References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <1211383722.8531.63.camel@localhost.localdomain> <1211385285.8531.65.camel@localhost.localdomain> <544eb990805210917y45a7df22hb867b7e8e027d474@mail.gmail.com> <48344D6E.6000006@gmail.com> <544eb990805210935k781bcbafn6165c3e03aa72d10@mail.gmail.com> <4834533D.7010007@gmail.com> <544eb990805211001q75c28580k8b344b638451f223@mail.gmail.com> <48345B6C.3030204@gmail.com> Message-ID: Les Mikesell gmail.com> writes: > It's not typical to update products to match a new standard before the > standard in question is finalized, wireless-N notwithstanding. Yet this is normally how things work in the Free Software world, especially for drivers, one is supposed to track upstream development and keep one's driver updated for it as things change, not wait for a release. The fact that NVidia can't adapt to this is only their fault, or the fault of the non-Free license and the closed development model they have chosen. If their driver was released under an acceptable license for the upstream project their driver is for and developed in the upstream repository (as drivers are supposed to), we wouldn't have this problem. Kevin Kofler From aoliva at redhat.com Thu May 22 05:18:22 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Thu, 22 May 2008 02:18:22 -0300 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: <4834D3F2.90409@gmail.com> (Toshio Kuratomi's message of "Wed\, 21 May 2008 19\:01\:22 -0700") References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> <1211405127.21380.382.camel@pmac.infradead.org> <4834D3F2.90409@gmail.com> Message-ID: On May 21, 2008, Toshio Kuratomi wrote: > Alexandre Oliva wrote: >> On May 21, 2008, David Woodhouse wrote: >> Does anyone think the issue about non-Free firmwares is any different >> from the issue of non-Free drivers for nvidia cards, except for the >> irrelevant detail that these different pieces of software can corrupt >> the system (technically and morally) running on different CPUs? > Yes. >> Seriously? > Yes. > There's free software as in legally licensed for us to use distribute > and modify and there's free software as in four freedoms free. Unless > I've missed something, the firmware in the kernel is licensed under > the GPLv2 and therefore it is legally licensed for us to use, > distribute, and modify. I'm sorry to be the bearer of bad news, but you did indeed miss something. Have a look at the license for drivers/net/tokenring/3c359_microcode.h 2 /* 3 * The firmware this driver downloads into the tokenring card is a 4 * separate program and is not GPL'd source code, even though the Linux 5 * side driver and the routine that loads this data into the card are. 6 * 7 * This firmware is licensed to you strictly for use in conjunction 8 * with the use of 3Com 3C359 TokenRing adapters. There is no 9 * waranty expressed or implied about its fitness for any purpose. 10 */ This is just one out of some 30 examples of such licenses in the kernel. And, heck, this one doesn't even grant permission for redistribution. What are those Linux-no-libre guys thinking? Anyhow... How does this relate with my question quoted above? nVidia's video drivers are non-Free. firmware included in the kernel, as well as the other redistributable firmware included separately in Fedora, are non-Free. The hair-splitters that try to invent an artificial difference based on what CPU the code runs on don't only miss the point on supporting unethical vendors, but also on their very amoral technical grounds for introducing the artificial distinction: they're supposed to run on *some* CPU on *some* users' machines, and since we don't know what they're doing and they run in privileged mode (on whatever CPU they run), they're at least in theory perfectly capable of wreaking havoc on the entire system, and in fact some of them do. So why the exception again? Because users can't live without them? Well, sure some users can't. Nobody stops such users from being informed by Fedora about the problems in their hardware and how to get ahold of the hardware vendor to obtain some software (presumably non-Free) that will get the hardware going. Fedora doesn't need to carry such software, and Fedora doesn't need to promote or encourage its use. > .. [1]: http://fedoraproject.org/wiki/Licensing#BinaryFirmware I'm well aware of that exception. Nowhere does it say "we must force binary firmware onto every Fedora user's machine, and we must avoid at all costs any attempts to enable users to prevent the installation of such binary firwmare on their machines" :-) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From tmz at pobox.com Thu May 22 05:25:28 2008 From: tmz at pobox.com (Todd Zullinger) Date: Thu, 22 May 2008 01:25:28 -0400 Subject: license tag cleanups In-Reply-To: <1211406461.3801.404.camel@localhost.localdomain> References: <1211403466.3801.378.camel@localhost.localdomain> <1211406461.3801.404.camel@localhost.localdomain> Message-ID: <20080522052528.GA3216@inocybe.teonanacatl.org> Tom spot Callaway wrote: > Since a few people have asked, if you're crazy enough to want to > volunteer to help with this task, just let me know, and I'll throw > part of my list at you. Toss a chunk my way. I've got some time the next day or so I can work on them. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sir, you are drunk!" "Well madam, I may be be drunk, but you are ugly; the difference being I will be sober in the morning. -- Winston Churchill -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From lesmikesell at gmail.com Thu May 22 05:34:34 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 22 May 2008 00:34:34 -0500 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <1211383722.8531.63.camel@localhost.localdomain> <1211385285.8531.65.camel@localhost.localdomain> <544eb990805210917y45a7df22hb867b7e8e027d474@mail.gmail.com> <48344D6E.6000006@gmail.com> <544eb990805210935k781bcbafn6165c3e03aa72d10@mail.gmail.com> <4834533D.7010007@gmail.com> <544eb990805211001q75c28580k8b344b638451f223@mail.gmail.com> <48345B6C.3030204@gmail.com> Message-ID: <483505EA.3090801@gmail.com> Kevin Kofler wrote: > Les Mikesell gmail.com> writes: >> It's not typical to update products to match a new standard before the >> standard in question is finalized, wireless-N notwithstanding. > > Yet this is normally how things work in the Free Software world, especially for > drivers, one is supposed to track upstream development and keep one's driver > updated for it as things change, not wait for a release. It seems unique to fedora to me. When has RHEL shipped pre-release code expected to be incompatible with other popular software? -- Les Mikesell lesmikesell at gmail.com From abartlet at samba.org Thu May 22 05:35:44 2008 From: abartlet at samba.org (Andrew Bartlett) Date: Thu, 22 May 2008 15:35:44 +1000 Subject: New Xorg In-Reply-To: <1211343195.2928.25.camel@jdlaptop> References: <1211343195.2928.25.camel@jdlaptop> Message-ID: <1211434544.4782.33.camel@ruth> On Wed, 2008-05-21 at 07:13 +0300, Jonathan Dieter wrote: > I know this probably isn't the place to do this, but I'm not sure what > the right place is. ajax & Dave, thank you for the work you've done on > the new Xorg. I know there have been lots of complaints, and, as an > nVidia user, I understand them. > > However, the stuff you're working on for *all* the other drivers is > pretty incredible and more than makes up for a few weeks without > eye-candy on my primary system. The way it all works on Intel video > cards is great, and I'm particularly impressed with the DRI2 stuff > (though kernel mode-setting is pretty cool too). Please keep it up. Indeed. Fedora 9 has the best X experience that I've had with Linux. I ran rawhide and followed the ride, but the end result was *so* worth it. (Plugging my laptop into random monitors and projectors, with all sorts of resolutions, and having it just work, is a god-send). Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jdieter at gmail.com Thu May 22 05:51:42 2008 From: jdieter at gmail.com (Jonathan Dieter) Date: Thu, 22 May 2008 08:51:42 +0300 Subject: Xorg 1.5 missed the train? In-Reply-To: <483505EA.3090801@gmail.com> References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <1211383722.8531.63.camel@localhost.localdomain> <1211385285.8531.65.camel@localhost.localdomain> <544eb990805210917y45a7df22hb867b7e8e027d474@mail.gmail.com> <48344D6E.6000006@gmail.com> <544eb990805210935k781bcbafn6165c3e03aa72d10@mail.gmail.com> <4834533D.7010007@gmail.com> <544eb990805211001q75c28580k8b344b638451f223@mail.gmail.com> <48345B6C.3030204@gmail.com> <483505EA.3090801@gmail.com> Message-ID: <1211435502.2928.57.camel@jdlaptop> On Thu, 2008-05-22 at 00:34 -0500, Les Mikesell wrote: > It seems unique to fedora to me. When has RHEL shipped pre-release code > expected to be incompatible with other popular software? _____ | | | o| | -| / |_____| / |\___/| | / | | |-----/ |x x| | | | | | . . | | \___/ / \ / \ / \ I think this horse has had enough. Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From cjdahlin at ncsu.edu Thu May 22 05:54:36 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Thu, 22 May 2008 01:54:36 -0400 Subject: Xorg 1.5 missed the train? In-Reply-To: <1211435502.2928.57.camel@jdlaptop> References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <1211383722.8531.63.camel@localhost.localdomain> <1211385285.8531.65.camel@localhost.localdomain> <544eb990805210917y45a7df22hb867b7e8e027d474@mail.gmail.com> <48344D6E.6000006@gmail.com> <544eb990805210935k781bcbafn6165c3e03aa72d10@mail.gmail.com> <4834533D.7010007@gmail.com> <544eb990805211001q75c28580k8b344b638451f223@mail.gmail.com> <48345B6C.3030204@gmail.com> <483505EA.3090801@gmail.com> <1211435502.2928.57.camel@jdlaptop> Message-ID: <48350A9C.2050303@ncsu.edu> Jonathan Dieter wrote: > On Thu, 2008-05-22 at 00:34 -0500, Les Mikesell wrote: > >> It seems unique to fedora to me. When has RHEL shipped pre-release code >> expected to be incompatible with other popular software? >> > _____ > | | > | o| > | -| / > |_____| / |\___/| > | / | | > |-----/ |x x| > | | | > | | . . | > | \___/ > / \ > / \ > / \ > > I think this horse has had enough. > > Jonathan > To put it another way: sage From kevin.kofler at chello.at Thu May 22 05:58:25 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 22 May 2008 05:58:25 +0000 (UTC) Subject: missing libphonon.so? References: Message-ID: Neal Becker gmail.com> writes: > There is no link libphonon.so -> libphonon.so.4.0.4 See Rex Dieter's reply: https://bugzilla.redhat.com/show_bug.cgi?id=447831#c1 It's there, just not where you or whatever software you're packaging is expecting it. In the case of Phonon, this is easy to fix because there was no Phonon in KDE 3 which it would conflict with, so we're going to fix this (make libphonon.so available directly in %{_libdir}) in the near future. Kevin Kofler From murray.mcallister at gmail.com Thu May 22 06:57:42 2008 From: murray.mcallister at gmail.com (Murray McAllister) Date: Thu, 22 May 2008 16:57:42 +1000 Subject: thank you for the laptop[ sleep alert Message-ID: <95f1114b0805212357l755b7dd7s89fef87fb9a99762@mail.gmail.com> Hi, Apologies for mass distribution. I installed Fedora 9 on my laptop today, and after a few minutes it gave me an alert that my system will not shutdown if I close the lid. When I was consulting, I was terrified that I forgot to configure a laptop to shutdown or hibernate when the lid was closed, and imagined angry customers with melted laptops coming after me ;) So thank you all very much for adding this alert!! Regards, Murray. --------------------------------------------------------------------- pub 1024D/81B3FDEB 2007-09-19 [expires: 2008-09-18] Key fingerprint = 4ED9 9907 5BF0 4132 2B46 20D1 C0C6 362D 81B3 FDEB Murray McAllister (Fedora Docs Project / mdious) sub 2048g/B04CFA0C 2007-09-19 [expires: 2008-09-18] From email.ahmedkamal at googlemail.com Thu May 22 07:07:59 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Thu, 22 May 2008 10:07:59 +0300 Subject: thank you for the laptop[ sleep alert In-Reply-To: <95f1114b0805212357l755b7dd7s89fef87fb9a99762@mail.gmail.com> References: <95f1114b0805212357l755b7dd7s89fef87fb9a99762@mail.gmail.com> Message-ID: <3da3b5b40805220007p6859121tea559d7ec9ffe810@mail.gmail.com> I remember getting a similar message that was like "Some program is preventing your laptop from hibernating". It was nice, but I was screaming, could you please let me know *which* application was that! Not sure if you guys got something similar Regards On Thu, May 22, 2008 at 9:57 AM, Murray McAllister < murray.mcallister at gmail.com> wrote: > Hi, > > Apologies for mass distribution. I installed Fedora 9 on my laptop > today, and after a few minutes it gave me an alert that my system will > not shutdown if I close the lid. When I was consulting, I was > terrified that I forgot to configure a laptop to shutdown or > hibernate when the lid was closed, and imagined angry customers with > melted laptops coming after me ;) > > So thank you all very much for adding this alert!! > > Regards, > > Murray. > > --------------------------------------------------------------------- > pub 1024D/81B3FDEB 2007-09-19 [expires: 2008-09-18] > Key fingerprint = 4ED9 9907 5BF0 4132 2B46 20D1 C0C6 362D 81B3 FDEB > Murray McAllister (Fedora Docs Project / mdious) < > murray.mcallister at gmail.com> > sub 2048g/B04CFA0C 2007-09-19 [expires: 2008-09-18] > > -- > 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 pertusus at free.fr Thu May 22 07:32:33 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 22 May 2008 09:32:33 +0200 Subject: obsoleting -selinux subpackages In-Reply-To: <4834D502.1090209@kobold.org> References: <4834D502.1090209@kobold.org> Message-ID: <20080522073232.GA2640@free.fr> On Wed, May 21, 2008 at 07:05:54PM -0700, Wart wrote: > In an earlier F-? release, I had added a cyphesis-selinux subpackage > which added selinux protection to the cyphesis game server. This policy > has now been added to the selinux-policy-targeted package, and I need to > have cyphesis-selinux removed. There are two places where this can be > done safely, afaik: > > (a) Add 'Obsoletes: cyphesis-selinux' to the cyphesis base package > (b) Add 'Obsoletes: cyphesis-selinux' to the selinux-policy-targeted > package I think that (b) is more logical since the functionality is there now. > Is (a) an acceptable solution? I think so. -- Pat From dwmw2 at infradead.org Thu May 22 08:24:17 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 22 May 2008 09:24:17 +0100 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> <1211405127.21380.382.camel@pmac.infradead.org> Message-ID: <1211444657.21380.424.camel@pmac.infradead.org> On Wed, 2008-05-21 at 20:53 -0300, Alexandre Oliva wrote: > On May 21, 2008, David Woodhouse wrote: > > > On Wed, 2008-05-21 at 18:21 -0300, Alexandre Oliva wrote: > >> I believe I've already explained why I can't do that. I refuse to > >> distribute non-Free Software, and posting a patch that removes these > >> bits amounts to posting those very bits. > > > Really, that's a stupid objection. Just post it in ed form. > > Assuming that's acceptable upstream. I sort of doubt it, Post them to me; I'll convert them to 'diff -u' for you and send them on. > Another I still haven't mentioned is that I have no interest in being > harrassed and verbally abused like the last discussion about freedom > issues I got into there. That is best addressed by making sure you don't come across as a kook. You need to make it clear that you're not just intending to remove stuff and run away leaving it broken; for anything you change, you need to make sure there is a viable working alternative. Saying "oh, but I don't want to touch it" is a crappy excuse. If you don't want to touch it, then get someone _else_ to do the work. But don't expect your ed-scripts to be applied when they're actually causing regressions. > > Now, let me show you why this proposed plan is an impossible mission > that people are trying to drive me into. Consider this snippet from > http://www.fsfla.org/svn/fsfla/software/linux-libre/scripts/deblob-2.6.25 > > # SND_KORG1212 - Korg 1212 IO > clean_ifdef sound/pci/korg1212/korg1212.c CONFIG_SND_KORG1212_FIRMWARE_IN_KERNEL > clean_blob sound/pci/korg1212/korg1212-firmware.h > > # SND_MAESTRO3 - ESS Allegro/Maestro3 > clean_ifdef sound/pci/maestro3.c CONFIG_SND_MAESTRO3_FIRMWARE_IN_KERNEL > > # SND_YMFPCI - Yamaha YMF724/740/744/754 > clean_blob sound/pci/ymfpci/ymfpci_image.h > clean_ifdef sound/pci/ymfpci/ymfpci_main.c CONFIG_SND_YMFPCI_FIRMWARE_IN_KERNEL > > clean_blob() removes long sequences of numbers, whereas clean_ifdef() > runs unifdef on the named file assuming the named variable is > undefined. > > Could you honestly tell me, with a straight face and a reasonable > degree of assurance, that a patch that performs these actions stands > any chance whatsoever of being accepted upstream? I'll tell you what I'd do to _improve_ its chances. Would that do? What I'd do is augment the kernel's firmware class support so that users can build firmware blobs into their kernel to be accessed through the firmware class. So the ifdefs in the above code go away -- the user can just choose to include the blobs in the kernel build or not, as they see fit, and the driver just invokes the firmware loader and doesn't actually _care_ whether the firmware comes from within the kernel or from userspace. Once you've done that, you (or your minion) can start moving all the offending uses of firmware blobs over to the firmware class without _any_ regressions at all, since they'll keep working without even needing an initrd. And after that, you can look at evicting the offending blobs from the kernel altogether. Since Fedora uses an initrd anyway, we'd probably choose not to build any of the blobs into the kernel, but to ship them in a separate package(s). You can then just omit that package from your compose. I'm utterly uninterested in any response of "that sounds like work; I just want to break things" or "I don't want to touch it". Those are the responses which will get you "harassed and verbally abused" on lkml, or just ignored by me. -- dwmw2 From fedora at leemhuis.info Thu May 22 08:24:52 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 22 May 2008 10:24:52 +0200 Subject: vanilla-kernel (was: Re: Plan for tomorrows (20080522) FESCO meeting) In-Reply-To: <20080521143345.383eb10b@vader.jdub.homelinux.org> References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> Message-ID: <48352DD4.9040104@leemhuis.info> On 21.05.2008 21:33, Josh Boyer wrote: > On Wed, 21 May 2008 16:20:39 -0300 > Alexandre Oliva wrote: >> On May 21, 2008, Brian Pepple wrote: > >> Inclusion in Fedora (future and recent past releases) of the >> kernel-libre package, a 100% Free Software variant of the kernel >> Linux, that I've been maintaining tracking Fedora kernel builds at >> http://www.fsfla.org/~lxoliva/fsfla/linux-libre/ > We've had this discussion. We aren't going to allow a forked kernel > package. Please work with the kernel team to integrate this into the > main kernel package. Slightly related to this and maybe relevant for the -libre discussion: Dave, what's the status of the "precompiled vanilla kernel rpms" for Fedora? There was the idea to put them in the unusual Fedora repos (which I'd prefer) or in a dedicated repo on your people pages. Was it forgotten? To many technical hurdles? -ENOTIME? Or do we stick to the "build one yourself using rpmbuild and the magic flag if you need one" solution? Just wondering. CU knurd From nicolas.mailhot at laposte.net Thu May 22 08:37:35 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 22 May 2008 10:37:35 +0200 (CEST) Subject: vanilla-kernel (was: Re: Plan for tomorrows (20080522) FESCO meeting) In-Reply-To: <48352DD4.9040104@leemhuis.info> References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> <48352DD4.9040104@leemhuis.info> Message-ID: <9884.192.54.193.52.1211445455.squirrel@rousalka.dyndns.org> Le Jeu 22 mai 2008 10:24, Thorsten Leemhuis a ?crit : > Dave, what's the status of the "precompiled vanilla kernel rpms" for > Fedora? It would be mightily useful to have regular pre-built vanilla and linux-next fedora rpms available in a well-known repo. Often one reports kernel bugs, and then upstream asks vanilla/linux-next re-tests when you do not have a few free hours to invest in a custom kernel rebuild (yes it can be a few hours when you have to figure what changed in kernel build procedures upstream and what changed in the fedora kernel spec during the same period) -- Nicolas Mailhot From fedora at leemhuis.info Thu May 22 08:55:02 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 22 May 2008 10:55:02 +0200 Subject: vanilla-kernel In-Reply-To: <9884.192.54.193.52.1211445455.squirrel@rousalka.dyndns.org> References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> <48352DD4.9040104@leemhuis.info> <9884.192.54.193.52.1211445455.squirrel@rousalka.dyndns.org> Message-ID: <483534E6.4060605@leemhuis.info> On 22.05.2008 10:37, Nicolas Mailhot wrote: > Le Jeu 22 mai 2008 10:24, Thorsten Leemhuis a ?crit : > >> Dave, what's the status of the "precompiled vanilla kernel rpms" for >> Fedora? > It would be mightily useful to have regular pre-built vanilla and > linux-next fedora rpms available in a well-known repo. Often one > reports kernel bugs, and then upstream asks vanilla/linux-next > re-tests when you do not have a few free hours to invest in a custom > kernel rebuild (yes it can be a few hours when you have to figure what > changed in kernel build procedures upstream and what changed in the > fedora kernel spec during the same period) +1 -- the reasons why it's good to have one where in fact discussed months ago and there was an agreement to ship them somewhere (?) -- that's why I didn't mention the reasons again in my mail ;-) But you bring up another good point: having linux-next available as well a pre-compiled rpm might be a nice to have as well -- Andrew iirc some weeks ago expressed that he would like to see something like that. Sure, -next is not of use for many people, but for some people (like me) it might be a "okay, if I get them pre-compiled I'll test them as it's way easier to do so". Of course if errors show up everything gets more complicated when it comes to debugging -- but that's imho not a reasons not to ship a -next RPM. CU knurd (?) -- which never happened afaik, hence my mail From paul at city-fan.org Thu May 22 09:27:19 2008 From: paul at city-fan.org (Paul Howarth) Date: Thu, 22 May 2008 10:27:19 +0100 Subject: obsoleting -selinux subpackages In-Reply-To: <20080522073232.GA2640@free.fr> References: <4834D502.1090209@kobold.org> <20080522073232.GA2640@free.fr> Message-ID: <48353C77.8010504@city-fan.org> Patrice Dumas wrote: > On Wed, May 21, 2008 at 07:05:54PM -0700, Wart wrote: >> In an earlier F-? release, I had added a cyphesis-selinux subpackage >> which added selinux protection to the cyphesis game server. This policy >> has now been added to the selinux-policy-targeted package, and I need to >> have cyphesis-selinux removed. There are two places where this can be >> done safely, afaik: >> >> (a) Add 'Obsoletes: cyphesis-selinux' to the cyphesis base package >> (b) Add 'Obsoletes: cyphesis-selinux' to the selinux-policy-targeted >> package > > I think that (b) is more logical since the functionality is there now. I agree. >> Is (a) an acceptable solution? > > I think so. I think so too but it might be worth adding: Conflicts: selinux-policy < first-VR-including-cyphesis-policy at least for one or two releases. Paul. From aoliva at redhat.com Thu May 22 09:55:58 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Thu, 22 May 2008 06:55:58 -0300 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: <1211410870.2290.5.camel@kennedy> (Brian Pepple's message of "Wed\, 21 May 2008 19\:01\:10 -0400") References: <1211377739.4210.2.camel@truman> <1211410870.2290.5.camel@kennedy> Message-ID: On May 21, 2008, Brian Pepple wrote: > On Wed, 2008-05-21 at 16:20 -0300, Alexandre Oliva wrote: >> On May 21, 2008, Brian Pepple wrote: >> >> . Permission to distribute under the mark 'Fedora' spins containing >> kernel-libre packages, whose sole difference from identically-numbered >> Fedora kernel builds is the removal of a few pieces of non-Free >> Software. > I've gone ahead and add the kernel-libre topic to the schedule for > tomorrow. I've put it at the end of the agenda though, since I want to > make sure we get to the other items on the schedule before we begin this > discussion (since I'm guessing it will be fairly lengthy). Thanks. Here's the proposed feature I've just drafted up: http://fedoraproject.org/wiki/Features/FedoraFreedom -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From pertusus at free.fr Thu May 22 09:56:20 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 22 May 2008 11:56:20 +0200 Subject: obsoleting -selinux subpackages In-Reply-To: <48353C77.8010504@city-fan.org> References: <4834D502.1090209@kobold.org> <20080522073232.GA2640@free.fr> <48353C77.8010504@city-fan.org> Message-ID: <20080522095620.GB2640@free.fr> On Thu, May 22, 2008 at 10:27:19AM +0100, Paul Howarth wrote: > >>> Is (a) an acceptable solution? >> >> I think so. > > I think so too but it might be worth adding: > > Conflicts: selinux-policy < first-VR-including-cyphesis-policy I am not sure that it is really needed. Better have the obsolete in selinux-policy and a corresponding provides in that case. -- Pat From sundaram at fedoraproject.org Thu May 22 10:11:28 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 22 May 2008 15:41:28 +0530 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: References: <1211377739.4210.2.camel@truman> <1211410870.2290.5.camel@kennedy> Message-ID: <483546D0.8080602@fedoraproject.org> Alexandre Oliva wrote: > On May 21, 2008, Brian Pepple wrote: > >> On Wed, 2008-05-21 at 16:20 -0300, Alexandre Oliva wrote: >>> On May 21, 2008, Brian Pepple wrote: >>> >>> . Permission to distribute under the mark 'Fedora' spins containing >>> kernel-libre packages, whose sole difference from identically-numbered >>> Fedora kernel builds is the removal of a few pieces of non-Free >>> Software. > >> I've gone ahead and add the kernel-libre topic to the schedule for >> tomorrow. I've put it at the end of the agenda though, since I want to >> make sure we get to the other items on the schedule before we begin this >> discussion (since I'm guessing it will be fairly lengthy). > > Thanks. > > Here's the proposed feature I've just drafted up: > http://fedoraproject.org/wiki/Features/FedoraFreedom You might want to attend the IRC meeting and participate in the discussions regarding this proposal. Also try and pro actively address the objections raised and answer them within the wiki page. Not everyone in FESCo might have read the lengthy thread on the topic. IIRC, the primary and perhaps only real objection is that you are proposing to maintain a additional kernel package. Instead David Woodhouse, Alan Cox and others have offered to act as a gateway between you and upstream Linux community and remove the firmware out of the kernel in a way that satisfies the requirement of both the parties instead of maintaining a separate branch within Fedora. Rahul From poelstra at redhat.com Thu May 22 03:35:21 2008 From: poelstra at redhat.com (John Poelstra) Date: Wed, 21 May 2008 20:35:21 -0700 Subject: Fedora 10 Feature Process Message-ID: <4834E9F9.1090907@redhat.com> Hello Fedora 10, Fedora 9 completed the second iteration of the Fedora Feature process. It seemed to run a little smoother than things did with Fedora 8. The gist of the feedback I heard was that the marketing and documentation groups loved the feature pages and information they provided while some developers thought creating and updating the feature pages was too much work and other developers found it to be no problem at all. So before we start the next round of Feature Acceptance process by FESCo I wanted to open a dialogue here that could carry over to the FESCo meeting on 2008-05-29 whereby FESCo could vote to amend the existing policy based on the constructive feedback received. I have created a wiki page to track this process here: http://fedoraproject.org/wiki/Features/F10PolicyReview Key proposals so far include: * Tracker bugs for each feature * Better test plan information * No incomplete feature form sections Admittedly one of the next things we will need is an application to track this process so we can get away from using the wiki. I'm open to any volunteers who would like to help write such an application or could propose an existing open source tool that would handle the current information we request and track for new features. Thanks, John _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From ndbecker2 at gmail.com Thu May 22 11:06:32 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 22 May 2008 07:06:32 -0400 Subject: missing libphonon.so? References: Message-ID: Kevin Kofler wrote: > Neal Becker gmail.com> writes: >> There is no link libphonon.so -> libphonon.so.4.0.4 > > See Rex Dieter's reply: > https://bugzilla.redhat.com/show_bug.cgi?id=447831#c1 It's there, just not > where you or whatever software you're packaging is expecting it. In the > case of Phonon, this is easy to fix because there was no Phonon in KDE 3 > which it would conflict with, so we're going to fix this (make > libphonon.so available directly in %{_libdir}) in the near future. > How are kde4/qt4 apps _supposed_ to find these libs? From kevin.kofler at chello.at Thu May 22 11:18:30 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 22 May 2008 11:18:30 +0000 (UTC) Subject: missing libphonon.so? References: Message-ID: Neal Becker gmail.com> writes: > How are kde4/qt4 apps _supposed_ to find these libs? KDE 4 apps normally have: FindPackage(KDE4 REQUIRED) in their .cmake scripts. The FindKDE4.cmake snippet shipped with cmake will use kde4-config to locate FindKDE4Internal.cmake (which ships with kdelibs) and let that do the real work. Our FindKDE4Internal.cmake is patched with this: http://cvs.fedoraproject.org/viewcvs/rpms/kdelibs/F-9/kdelibs-4.0.4-parallel_devel.patch?rev=1.1&view=markup The problem is that Phonon is now getting used by apps which are not KDE apps, because Qt is also shipping a version of it (since 4.4), and those non-KDE apps are not using FindKDE4Internal.cmake, so the magic doesn't work. Kevin Kofler From snecklifter at gmail.com Thu May 22 11:22:12 2008 From: snecklifter at gmail.com (Christopher Brown) Date: Thu, 22 May 2008 12:22:12 +0100 Subject: changes at planet fedora In-Reply-To: <1211391317.3559.1.camel@cutter> References: <1211214812.3095.0.camel@cutter> <6e24a8e80805201550o12531af3ye6692f9571cb5230@mail.gmail.com> <48335785.4050800@fedoraproject.org> <20080520201228.3dfb45b6@vader.jdub.homelinux.org> <4833CCC3.1050405@nicubunu.ro> <4833CFA7.9000703@nigelj.com> <6e24a8e80805210424nd504e3dxedc5551df2c8896f@mail.gmail.com> <409676c70805210502p8c6d7d9j79df72b6a58948cd@mail.gmail.com> <6e24a8e80805210958v223109cdr7300ca6872968d07@mail.gmail.com> <1211391317.3559.1.camel@cutter> Message-ID: <364d303b0805220422tff6426ai9d222d5c7ba5e756@mail.gmail.com> 2008/5/21 seth vidal : > Encouraging speech means you sometimes have to put up with some > bullshit, too. Excellent! Can we _please_ make that the Planet Fedora tag line! Cheers -- Christopher Brown From ndbecker2 at gmail.com Thu May 22 11:34:09 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 22 May 2008 07:34:09 -0400 Subject: missing libphonon.so? References: Message-ID: Kevin Kofler wrote: > Neal Becker gmail.com> writes: >> How are kde4/qt4 apps _supposed_ to find these libs? > > KDE 4 apps normally have: > FindPackage(KDE4 REQUIRED) > in their .cmake scripts. The FindKDE4.cmake snippet shipped with cmake > will use kde4-config to locate FindKDE4Internal.cmake (which ships with > kdelibs) and let that do the real work. Our FindKDE4Internal.cmake is > patched with this: > http://cvs.fedoraproject.org/viewcvs/rpms/kdelibs/F-9/kdelibs-4.0.4-parallel_devel.patch?rev=1.1&view=markup > > The problem is that Phonon is now getting used by apps which are not KDE > apps, because Qt is also shipping a version of it (since 4.4), and those > non-KDE apps are not using FindKDE4Internal.cmake, so the magic doesn't > work. > > Kevin Kofler > The package I was trying was uniXM, which uses qmake, but also uses phonon. Maybe we need kde.pc? From jwboyer at gmail.com Thu May 22 11:57:24 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 22 May 2008 06:57:24 -0500 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a Message-ID: <20080522065724.1788e577@vader.jdub.homelinux.org> Let the naming begin! We're starting very early this time around in the name game for F10. So, let the suggestions flow! Remember the rules: 1) must have some link to Sulphur More specifically, the link should be Sulphur is a and is a Where is the same for both 2) The link between and Sulphur cannot be the same as between Werewolf and Sulphur. That link was "things that react badly with silver". I will be collecting suggestions for 1 week, so the cutoff for names is: May 29, 2008 Suggestions will be run through the legal queue and an election will happen for Fedora contributors to pick the next Fedora name. josh From jwboyer at gmail.com Thu May 22 12:06:35 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 22 May 2008 07:06:35 -0500 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> <20080521184047.7b19e70b@vader.jdub.homelinux.org> <20080521204148.66eff81f@vader.jdub.homelinux.org> Message-ID: <20080522070635.092b067a@vader.jdub.homelinux.org> On Thu, 22 May 2008 01:58:25 -0300 Alexandre Oliva wrote: > > Can you point me to where you've approached the upstream kernel > > maintainers about this? > > I haven't. I'm told others have, and have been ridiculed. From what > I gather from the LKML archives and personal experiences there, I have > no reason to disbelieve them. Ok, but you said you had facts. Now you're telling me you only have hearsay? > >> > I'm not sure there is a way out. However perhaps you can enlist > >> > some help from someone that would be willing to do that. > >> > >> Finding someone else to do it might enable more patches to be posted, > >> but it wouldn't make it possible to achieve the goal. > > > Because? > > Because upstream doesn't want to achieve this goal, and actively > refuses to accept changes essential to get there. Pointers to this would be nice. Mailing list archives, IRC conversations, anything. > > If those patches get integrated, then wouldn't the parts you find > > objectionable be gone? > > Not all of them, no. ? > > I certainly didn't think you intended to _replace_ the main kernel > > package. But I don't agree with even providing a completely different > > alternative "kernel-libre" package. If it can't be built as a flavor > > of the existing kernel package, then I don't see it being approved for > > inclusion. > > So much for http://www.linux-books.us/fedora_core_0001.php So much for having a productive conversation. You're avoiding my point (or think it's entirely hopeless) and spewing rhetoric again. Rehashing the same conversation to come to the same results isn't something I'm inclined to do. David Woodhouse and Alan Cox have offered to help you work with upstream in the past. If you choose to not take that offer of help to accomplish your goals, that's fine. josh From rjones at redhat.com Thu May 22 12:09:33 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 22 May 2008 13:09:33 +0100 Subject: OCHRE (was: Re: Werewolf -> Sulphur -> ? Sulphur is a , is a ) In-Reply-To: <20080522065724.1788e577@vader.jdub.homelinux.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> Message-ID: <20080522120933.GA23317@amd.home.annexia.org> On Thu, May 22, 2008 at 06:57:24AM -0500, Josh Boyer wrote: > 2) The link between and Sulphur cannot be the same as between > Werewolf and Sulphur. That link was "things that react badly with > silver". OCHRE (the connection is that both are yellow) Also, I quite like the word :-) And it doesn't seem to have any significant use amongst the Linux community, at least as far as I can tell from Google ... Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From kevin.kofler at chello.at Thu May 22 12:15:56 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 22 May 2008 12:15:56 +0000 (UTC) Subject: missing libphonon.so? References: Message-ID: Neal Becker gmail.com> writes: > The package I was trying was uniXM, which uses qmake, but also uses phonon. > > Maybe we need kde.pc? We just need kdelibs fixed so that libphonon.so is directly in %{_libdir}, it doesn't need special-casing for parallel-installability with KDE 3 anyway. I or one of the other KDE maintainers are going to fix this ASAP. How urgently do you need this fixed? It's easy to fix Rawhide, but for the older Fedora releases, we have to push a new kdelibs resp. kdelibs4 to fix this. Kevin Kofler From promac at gmail.com Thu May 22 12:23:41 2008 From: promac at gmail.com (Paulo Cavalcanti) Date: Thu, 22 May 2008 09:23:41 -0300 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <1211385285.8531.65.camel@localhost.localdomain> <544eb990805210917y45a7df22hb867b7e8e027d474@mail.gmail.com> <48344D6E.6000006@gmail.com> <544eb990805210935k781bcbafn6165c3e03aa72d10@mail.gmail.com> <4834533D.7010007@gmail.com> <544eb990805211001q75c28580k8b344b638451f223@mail.gmail.com> <48345B6C.3030204@gmail.com> Message-ID: <68720af30805220523q1e37bc3dvf517c5433073deb@mail.gmail.com> On Thu, May 22, 2008 at 2:01 AM, Kevin Kofler wrote: > Les Mikesell gmail.com> writes: > > It's not typical to update products to match a new standard before the > > standard in question is finalized, wireless-N notwithstanding. > > Yet this is normally how things work in the Free Software world, especially > for > drivers, one is supposed to track upstream development and keep one's > driver > updated for it as things change, not wait for a release. The fact that > NVidia > can't adapt to this is only their fault, or the fault of the non-Free > license > and the closed development model they have chosen. If their driver was > released > under an acceptable license for the upstream project their driver is for > and > developed in the upstream repository (as drivers are supposed to), we > wouldn't > have this problem. > > I am pretty sure RedHat new exactly what it was doing when choosing Xorg 1.5. The users would be used as a "mass of manoeuvre" to press Nvidia to catch up. It is a valid strategy in my opinion. Certainly, the customers of RHEL would never have to be exposed this way, but they pay for a special treatment. Those who can use the nv driver, good. Others like me, who write code to be run on Nvidia graphics boards and/or use CUDA, have no option but wait. Furthermore, I like F8 very much... -- Paulo Roma Cavalcanti LCG - UFRJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From skvidal at fedoraproject.org Thu May 22 12:27:04 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 22 May 2008 08:27:04 -0400 Subject: rpms/csound/devel csound.spec,1.14,1.15 In-Reply-To: <4834FC1F.1040205@ioa.s.u-tokyo.ac.jp> References: <200805220421.m4M4Ln80018949@cvs-int.fedora.redhat.com> <4834FC1F.1040205@ioa.s.u-tokyo.ac.jp> Message-ID: <1211459224.3559.39.camel@cutter> On Thu, 2008-05-22 at 13:52 +0900, Mamoru Tasaka wrote: > Well, actually the license of csound is a bit problematic. > See my comment on > https://bugzilla.redhat.com/show_bug.cgi?id=440597#c8 >From the way I read it the license should be LGPLv2+ byt the readme-csound5.txt file. You're right about some files needing to be pulled out of it, though. -sv From jdieter at gmail.com Thu May 22 12:38:32 2008 From: jdieter at gmail.com (Jonathan Dieter) Date: Thu, 22 May 2008 15:38:32 +0300 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080522065724.1788e577@vader.jdub.homelinux.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> Message-ID: <1211459912.3079.4.camel@jdlaptop> On Thu, 2008-05-22 at 06:57 -0500, Josh Boyer wrote: > Let the naming begin! We're starting very early this time around in > the name game for F10. So, let the suggestions flow! Might as well get the obvious out of the way: Sulphur -> Gold Sulphur -> Titanium Sulphur -> Platinum Sulphur -> Berklium (okay, maybe not so much) Where they are all chemical elements. Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From P at draigBrady.com Thu May 22 12:37:25 2008 From: P at draigBrady.com (=?ISO-8859-1?Q?P=E1draig_Brady?=) Date: Thu, 22 May 2008 13:37:25 +0100 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080522065724.1788e577@vader.jdub.homelinux.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> Message-ID: <48356905.2090805@draigBrady.com> Jupiter Sulphur has atomic number 16 Jupiter has 16 moons P?draig. From stickster at gmail.com Thu May 22 12:39:34 2008 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 22 May 2008 12:39:34 +0000 Subject: changes at planet fedora In-Reply-To: <364d303b0805220422tff6426ai9d222d5c7ba5e756@mail.gmail.com> References: <1211214812.3095.0.camel@cutter> <6e24a8e80805201550o12531af3ye6692f9571cb5230@mail.gmail.com> <48335785.4050800@fedoraproject.org> <20080520201228.3dfb45b6@vader.jdub.homelinux.org> <4833CCC3.1050405@nicubunu.ro> <4833CFA7.9000703@nigelj.com> <6e24a8e80805210424nd504e3dxedc5551df2c8896f@mail.gmail.com> <409676c70805210502p8c6d7d9j79df72b6a58948cd@mail.gmail.com> <6e24a8e80805210958v223109cdr7300ca6872968d07@mail.gmail.com> <1211391317.3559.1.camel@cutter> <364d303b0805220422tff6426ai9d222d5c7ba5e756@mail.gmail.com> Message-ID: <1211459974.4891.39.camel@victoria> On Thu, 2008-05-22 at 12:22 +0100, Christopher Brown wrote: > 2008/5/21 seth vidal : > > > Encouraging speech means you sometimes have to put up with some > > bullshit, too. > > Excellent! Can we _please_ make that the Planet Fedora tag line! Heck, we should just make it the slogan for this list while we're at it. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From gnomeuser at gmail.com Thu May 22 12:41:37 2008 From: gnomeuser at gmail.com (David Nielsen) Date: Thu, 22 May 2008 14:41:37 +0200 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080522065724.1788e577@vader.jdub.homelinux.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> Message-ID: <1dedbbfc0805220541j69638493qa596fb46b3962cfe@mail.gmail.com> 2008/5/22 Josh Boyer : > Let the naming begin! We're starting very early this time around in > the name game for F10. So, let the suggestions flow! > > Remember the rules: > > 1) must have some link to Sulphur > > More specifically, the link should be > Sulphur is a and > is a > Where is the same for both > > 2) The link between and Sulphur cannot be the same as between > Werewolf and Sulphur. That link was "things that react badly with > silver". > > I will be collecting suggestions for 1 week, so the cutoff for names is: > > May 29, 2008 > > Suggestions will be run through the legal queue and an election will > happen for Fedora contributors to pick the next Fedora name. > > josh > I know this deosn't follow the direct form but Coliadinae. The name for a subfamily of butterflies also know as the sulfer butterflys. I imagine we could have beautiful themes to go allow with that. -------------- next part -------------- An HTML attachment was scrubbed... URL: From loupgaroublond at gmail.com Thu May 22 12:47:20 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Thu, 22 May 2008 08:47:20 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080522065724.1788e577@vader.jdub.homelinux.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> Message-ID: <7f692fec0805220547m5b31417eo3a2baf681b8a4878@mail.gmail.com> On Thu, May 22, 2008 at 7:57 AM, Josh Boyer wrote: > Let the naming begin! We're starting very early this time around in > the name game for F10. So, let the suggestions flow! > > Remember the rules: > > 1) must have some link to Sulphur > > More specifically, the link should be > Sulphur is a and > is a > Where is the same for both > > 2) The link between and Sulphur cannot be the same as between > Werewolf and Sulphur. That link was "things that react badly with > silver". Sulphur is yellow and so are Sunflowers. The sunflower is generally a symbol used for any green political party or green economic plan. Perhaps we can include a daily tips piece to go along with any Infrastructure site that dispenses energy saving tips that can be used around the world. The potential for education here is really good. Just a thought. -Yaakov From stickster at gmail.com Thu May 22 12:41:30 2008 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 22 May 2008 12:41:30 +0000 Subject: Xorg 1.5 missed the train? In-Reply-To: <1211393363.29467.144.camel@localhost.localdomain> References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <20080521152022.GF1093879@hiwaay.net> <1211383722.8531.63.camel@localhost.localdomain> <1211385285.8531.65.camel@localhost.localdomain> <544eb990805210917y45a7df22hb867b7e8e027d474@mail.gmail.com> <48344D6E.6000006@gmail.com> <544eb990805210935k781bcbafn6165c3e03aa72d10@mail.gmail.com> <4834533D.7010007@gmail.com> <23519.192.54.193.57.1211389920.squirrel@rousalka.dyndns.org> <48345CBC.40508@gmail.com> <63385.192.54.193.58.1211392983.squirrel@rousalka.dyndns.org> <1211393363.29467.144.camel@localhost.localdomain> Message-ID: <1211460090.4891.42.camel@victoria> On Wed, 2008-05-21 at 14:09 -0400, Adam Jackson wrote: > On Wed, 2008-05-21 at 20:03 +0200, Nicolas Mailhot wrote: > > Le Mer 21 mai 2008 19:32, Les Mikesell a ?crit : > > > > > I don't have a problem with Xorg taking any amount of time they want. > > > The problem is in fedora shipping a pre-release - or perhaps even more > > > so in their claim of knowing that the ABI is finalized before it is in > > > fact published as a standard. > > > > I suggest you complain to the xorg 1.5 release engineer the Fedora > > xorg maintainer is not coordinating with him closely. And then that > > you follow the advice of the xorg 1.5 release engineer on this issue. > > You know I'm both, right? And a superhumanly good job you've done for this release twice over, for that matter. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dev at nigelj.com Thu May 22 12:49:41 2008 From: dev at nigelj.com (Nigel Jones) Date: Fri, 23 May 2008 00:49:41 +1200 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1211459912.3079.4.camel@jdlaptop> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211459912.3079.4.camel@jdlaptop> Message-ID: <48356BE5.2020200@nigelj.com> Jonathan Dieter wrote: > On Thu, 2008-05-22 at 06:57 -0500, Josh Boyer wrote: > >> Let the naming begin! We're starting very early this time around in >> the name game for F10. So, let the suggestions flow! >> > > Might as well get the obvious out of the way: > > Sulphur -> Gold > Sulphur -> Titanium > Sulphur -> Platinum > Sulphur -> Berklium (okay, maybe not so much) > Ewww, I dislike Gold, not only is it a bit too obvious it's also the term some people reference major releases to, why not Mercury, it keeps the same link and allows for maybe Fedora Pluto in the future :). - Nigel > Where they are all chemical elements. > > Jonathan > From stlwrt at gmail.com Thu May 22 12:51:34 2008 From: stlwrt at gmail.com (Pavel Shevchuk) Date: Thu, 22 May 2008 15:51:34 +0300 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080522065724.1788e577@vader.jdub.homelinux.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> Message-ID: Sulphur is an essential element for life (c) Wikipedia Love is an essential element for life. Fedora 10: Love! On Thu, May 22, 2008 at 2:57 PM, Josh Boyer wrote: > Let the naming begin! We're starting very early this time around in > the name game for F10. So, let the suggestions flow! > > Remember the rules: > > 1) must have some link to Sulphur > > More specifically, the link should be > Sulphur is a and > is a > Where is the same for both > > 2) The link between and Sulphur cannot be the same as between > Werewolf and Sulphur. That link was "things that react badly with > silver". > > I will be collecting suggestions for 1 week, so the cutoff for names is: > > May 29, 2008 > > Suggestions will be run through the legal queue and an election will > happen for Fedora contributors to pick the next Fedora name. > > josh > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- http://scwlab.com From johannbg at hi.is Thu May 22 12:57:35 2008 From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Thu, 22 May 2008 12:57:35 +0000 Subject: Xorg 1.5 missed the train? In-Reply-To: <4834C7F6.1010100@poolshark.org> References: <48334163.4080709@magma.ca> <48337D52.7050005@poolshark.org> <4834729F.8030507@hi.is> <4834C7F6.1010100@poolshark.org> Message-ID: <48356DBF.4070108@hi.is> Denis Leroy wrote: > J?hann B. Gu?mundsson wrote: >> Denis Leroy wrote: >>> Jason Tang wrote: >>>> The only problem being that this release is incompatible with current >>>> nvidia drivers. Granted, I'm aware of the Fedora position regarding >>>> non-OSS, but this Xorg issue has completely destroyed many user's >>>> confidence in the dev team. >>> >>> That's nothing new you know. Out of the 9 fedora releases, I think >>> at least 8 out of 9 didn't work with the Nvidia driver at release >>> time. however Nvidia is usually pretty good at playing catch up. >>> >>> I'm also hostage to Nvidia's good will for my Lenovo T61's Quadro >>> chipset, and can't upgrade to F-9 until their next release (nv >>> doesn't work at all on this chipset). I wouldn't go back to a Radeon >>> chipset though, not until we have a working free equivalent >>> (emphasis on 'working') to nvidia-settings for easy dual-head >>> support... The good news is that with xrandr maturing, we're >>> probably almost there. >>> >> Interesting... >> >> I have no "nv" problems on my Lenovo T61p with Quadro FX570M. >> Running with no xorg.conf. ... >> http://www.smolts.org/client/show/pub_1536ec85-61c8-49d4-aeaa-3852a20d5d29 >> > > Hmm, mine is a NVS 140M. nv yields a black screen. With or without an xorg.conf ? You will need an xorg.conf for dual monitors or an customised script that you run after you booted the laptop. I'm not quite sure how their gonna fix the dual monitor one without an xorg.conf, Is xrandr capable of setting virtual resolution size? > Even if nv worked, it's unbearably slow and can't handle dual > 1680x1050 screens. True the nv driver is slow.. If 1680x1050 is not supported then you need to find the next/closest supported one.. I have to settle with 1360x768 when hooking my T61p to my HDTV which has 1920x1080. Since rhgb does not have proper sanity checks ( It seems to detect the resolution of the HDTV ( 1920x1080 ) and tries to set it to that resolution, or it tries to set the resolution if the lcd display to the HDTV and I end up with both screens black) I have to first start the laptop then put it in my dock then run a xrandr script I created to change the resolution of my T6p laptop display and set it to 1360x768 and the display sent to the HDTV .. ( Not using any xorg.conf ) This is from my xorg.conf on my Dell workstation here at work, which has an ati card and is running F9 Set to "panorama/spanning desktop". I will see if I cant come up with something similar on my T61p and the nv driver.. Section "ServerLayout" Identifier "RandR Multihead layout" Screen 0 "Screen0" 0 0 EndSection Section "Monitor" Identifier "DVI-0" # xrandr -q.. Should be DVI-0 Or DVI0 VendorName "Monitor Vendor" ModelName "Dell 1800FP (Analog)" # Match your monitor Option "PreferredMode" "1280x1050" # Set it to 1680x1050 or closest match Option "dpms" # Probably can be removed EndSection Section "Monitor" Identifier "DVI-1" VendorName "Monitor Vendor" ModelName "Dell 1901FP (Analog)" Match your monitor Option "PreferredMode" "1280x1050" # Set it to 1680x1050 or closest match Option "RightOf" "DVI-0" # Can either be LeftOf or RightOf and change the DVI-0 to match xrandr -q output Option "dpms" # Probably can be removed EndSection # Change the Device section to match NV Section "Device" Identifier "Videocard0" Driver "radeon" VendorName "Videocard Vendor" BoardName "ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE]" EndSection Section "Screen" Identifier "Screen0" Device "Videocard0" Monitor "DVI-0" # Needs to match xrandr -q output DefaultDepth 24 SubSection "Display" Viewport 0 0 Virtual 2560 1024 # Set it to ( 2x1680 )x1050 or closest match Depth 24 EndSubSection EndSection > But I would never criticize the Xorg developers, the only culprit for > nv being so bad is NVidia itself... > Nor was I blaming Xorg developers.. Ajax and Dave both have been doing extremely good work. I have never understood why users always blame Fedora/Xorg for Nvidia not catching up.. I have also never understood why hardware manufactures dont release specs to the open source community or atleast provide a proper functional driver even if it's an closed one. One would think it was in their best interest to sell as much of the hardware they manufacture regardless of which OS the end user is using. JB... -------------- next part -------------- A non-text attachment was scrubbed... Name: johannbg.vcf Type: text/x-vcard Size: 365 bytes Desc: not available URL: From optimizationkit at gmail.com Thu May 22 12:58:19 2008 From: optimizationkit at gmail.com (M) Date: Thu, 22 May 2008 14:58:19 +0200 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <7f692fec0805220547m5b31417eo3a2baf681b8a4878@mail.gmail.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <7f692fec0805220547m5b31417eo3a2baf681b8a4878@mail.gmail.com> Message-ID: <58a220fa0805220558n5806546ala2f789c283265dec@mail.gmail.com> 2008/5/22 Yaakov Nemoy : > On Thu, May 22, 2008 at 7:57 AM, Josh Boyer wrote: >> Let the naming begin! We're starting very early this time around in >> the name game for F10. So, let the suggestions flow! >> >> Remember the rules: >> >> 1) must have some link to Sulphur >> >> More specifically, the link should be >> Sulphur is a and >> is a >> Where is the same for both >> >> 2) The link between and Sulphur cannot be the same as between >> Werewolf and Sulphur. That link was "things that react badly with >> silver". > > Sulphur is yellow and so are Sunflowers. > Sulphur is yellow and so are Jararacas http://pl.wikipedia.org/wiki/Grafika:%C5%BBararaka_z%C5%82ota.JPG Regards, Michal From nicu_fedora at nicubunu.ro Thu May 22 13:00:33 2008 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Thu, 22 May 2008 16:00:33 +0300 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080522065724.1788e577@vader.jdub.homelinux.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> Message-ID: <48356E71.7090605@nicubunu.ro> Josh Boyer wrote: > Let the naming begin! We're starting very early this time around in > the name game for F10. So, let the suggestions flow! OK, so I shamelessly jump in with some pimping: there are some graphic concepts drafted for a F10 theme proposal based on a steampunk concept and titled "Gears": http://fedoraproject.org/wiki/Artwork/F10Themes/Gears I wonder if someone can come with a name that can fit both the "Gears" theme and the naming scheme (linked somehow with Sulphur). -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From rawhide at fedoraproject.org Thu May 22 13:10:45 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Thu, 22 May 2008 13:10:45 +0000 (UTC) Subject: rawhide report: 20080522 changes Message-ID: <20080522131045.F309B209D29@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080521/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080522/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package hunspell-ml Malayalam hunspell dictionaries New package minirpc Remote procedure call library for stream-oriented transports New package postgresql-odbcng PostgreSQL ODBCng driver Updated Packages: Falcon-0.8.8-3.fc9 ------------------ * Wed May 21 18:00:00 2008 Michel Salim - 0.8.8-3 - Use correct libdir for module path GConf2-2.22.0-9.fc10 -------------------- * Wed May 21 18:00:00 2008 Ray Strode - 2.22.0-9 - Don't ever try to autolaunch a bus if DISPLAY is unset * Wed May 21 18:00:00 2008 Ray Strode - 2.22.0-8 - If the session bus isn't running, assume local client side access to the database (bug 446703) GMT-4.3.1-1.fc10 ---------------- * Wed May 21 18:00:00 2008 Orion Poplawski 4.3.1-1 - Update to 4.3.1, drop upstreamed patches - Remove other install fixes upstreamed GMT-doc-4.3.1-1 --------------- * Wed May 21 18:00:00 2008 Orion Poplawski 4.3.1-1 - Update to 4.3.1 PyQt4-4.4.2-1.fc10 ------------------ * Wed May 21 18:00:00 2008 Rex Dieter 4.4.2-1 - PyQt-4.4.2 R-2.7.0-4.fc10 -------------- * Wed May 21 18:00:00 2008 Tom "spot" Callaway 2.7.0-4 - fixup sed invocation added in -3 - make -devel package depend on base R = version-release - fix bad paths in package html files * Wed May 21 18:00:00 2008 Tom "spot" Callaway 2.7.0-3 - fix poorly constructed file paths in html/packages.html (bz 442727) adjtimex-1.24-1.fc10 -------------------- * Wed May 21 18:00:00 2008 Miroslav Lichvar 1.24-1 - update to 1.24 afflib-3.2.0-1.fc10 ------------------- * Wed May 21 18:00:00 2008 kwizart < kwizart at gmail.com > - 3.2.0-1 - Update to 3.2.0 am-utils-6.1.5-9.fc10 --------------------- * Tue May 20 18:00:00 2008 Karel Zak 5:6.1.5-9 - spec file cleanup according to rpmlint - fix autotools stuff beagle-0.3.7-5.fc10 ------------------- * Wed May 21 18:00:00 2008 Adel Gadllah - 0.3.7-5 - Enable chm support RH #447746 bluez-libs-3.32-1.fc10 ---------------------- * Wed May 21 18:00:00 2008 - Bastien Nocera - 3.32-1 - Update to 3.32 bluez-utils-3.32-1.fc10 ----------------------- bzr-1.5-2.fc10 -------------- * Wed May 21 18:00:00 2008 Toshio Kuratomi - 1.5-2 - Upload tarball. * Wed May 21 18:00:00 2008 Toshio Kuratomi - 1.5-1 - Update to 1.5. bzrtools-1.5.0-1.fc10 --------------------- * Wed May 21 18:00:00 2008 Toshio Kuratomi 1.5.0-1 - Update to 1.5.0 cairo-dock-1.5.5.4-5.svn1015_trunk.fc10 --------------------------------------- * Thu May 22 18:00:00 2008 Mamoru Tasaka - svn 1015 dovecot-1.0.13-7.fc10 --------------------- * Tue May 20 18:00:00 2008 Dan Horak - 1:1.0.13-7 - spec file cleanup - update sieve plugin to 1.0.3 - Resolves: #445200, #238018 doxygen-1.5.6-2.fc10 -------------------- * Wed May 21 18:00:00 2008 Than Ngo 1.5.6-2 - rebuild emerald-0.7.2-1.fc9 ------------------- * Tue May 20 18:00:00 2008 Jarod Wilson 0.7.2-1 - Update to emerald packages matching F9 compiz (#447608) enchant-1.4.2-2.fc10 -------------------- * Wed May 21 18:00:00 2008 Marc Maurer 1:1.4.2-2 - Rebuild * Wed May 21 18:00:00 2008 Marc Maurer 1:1.4.2-1 - New upstream release - Add voikko support in an enchant-voikko package - Bump glib-devel BR to 2.6.0 epsilon-0.3.0.012-4.fc10 ------------------------ * Wed May 21 18:00:00 2008 Pavel "Stalwart" Shevchuk - 0.3.0.012-4 - rebuilt filezilla-3.0.10-1.fc10 ----------------------- * Wed May 21 18:00:00 2008 kwizart < kwizart at gmail.com > - 3.0.10-1 - Update to 3.0.10 jruby-1.1.1-7.fc10 ------------------ * Wed May 21 18:00:00 2008 Conrad Meyer - 1.1.1-7 - Require joni and jline. kdebase-workspace-4.0.72-4.fc10 ------------------------------- * Wed May 21 18:00:00 2008 Than Ngo 4.0.72-4 - fix #447030, hyperlinks do not open correctly in firefox liboggz-0.9.7-1.fc10 -------------------- * Wed May 21 18:00:00 2008 Michel Salim - 0.9.7-1 - Update to 0.9.7 libvoikko-1.7-0.2.rc2.fc10 -------------------------- * Thu May 22 18:00:00 2008 - Ville-Pekka Vainio 1.7-0.2.rc2 - Don't BuildRequire the Finnish data files, this should make Koji builds a bit quicker libxml-1.8.17-20.fc10 --------------------- * Wed May 21 18:00:00 2008 Paul Howarth 1:1.8.17-20 - fixes for building with -Werror-implicit-function-declaration and some of the compiler warnings - fix config.guess and config.sub to support build on ppc64 m17n-contrib-1.1.6-4.fc10 ------------------------- * Wed May 21 18:00:00 2008 Parag Nemade -1.1.6-4 - Resolves: rh#447682,rh#447683 man-pages-ja-20080515-1.fc10 ---------------------------- * Thu May 22 18:00:00 2008 Akira TAGOH - 20080515-1 - updates to 20080515. mkelfimage-2.7-4.fc10 --------------------- * Wed May 21 18:00:00 2008 Peter Jones - 2.7-4 - Add support for intelligent placement of the ramdisk. mtr-0.73-1.fc10 --------------- * Wed May 21 18:00:00 2008 Zdenek Prikryl - 2:0.73 - Updated to 0.73 - Fixed mtr-0.69-CVE-2002-0497.patch - Added build requirement for GTK+ ocaml-bitmatch-1.3-1.fc10 ------------------------- * Wed May 21 18:00:00 2008 Richard W.M. Jones - 1.3-1 - New upstream release 1.3. openssh-5.0p1-3.fc10 -------------------- * Wed May 21 18:00:00 2008 Tomas Mraz - 5.0p1-3 - pass the connection socket to ssh-keysign (#447680) pam-1.0.1-4.fc10 ---------------- * Wed May 21 18:00:00 2008 Tomas Mraz 1.0.1-4 - pam_namespace: allow safe creation of directories owned by user (#437116) - pam_unix: fix multiple error prompts on password change (#443872) perl-Class-MOP-0.55-2.fc10 -------------------------- * Wed May 21 18:00:00 2008 Chris Weyl 0.55-2 - bump for tagging snafu... * Wed May 21 18:00:00 2008 Chris Weyl 0.55-1 - update to 0.55 perl-Config-Any-0.12-1.fc10 --------------------------- * Wed May 21 18:00:00 2008 Chris Weyl 0.12-1 - update to 0.12 php-pear-Services-Weather-1.4.3-1.fc10 -------------------------------------- * Sat May 17 18:00:00 2008 Remi Collet 1.4.3-1 - update to 1.4.3 publican-0.33-1.fc10 -------------------- * Wed May 21 18:00:00 2008 Jeff Fearn 0.33-1 - added perl requires pulseaudio-0.9.11-0.2.svn20080516.fc10 -------------------------------------- * Tue May 20 18:00:00 2008 Matthias Clasen 0.9.11-0.2.svn20080516 - Actually apply the patch python-twisted-2.5.0-1.fc10 --------------------------- * Wed May 21 18:00:00 2008 Thomas Vander Stichele - 2.5.0-1 - update to 2.5.0 release (only the umbrella package was missing) python-twisted-lore-0.3.0-1.fc10 -------------------------------- * Wed May 21 18:00:00 2008 Thomas Vander Stichele - Update to 0.3.0 release Broken deps for i386 ---------------------------------------------------------- LabPlot-1.5.1.6-4.fc8.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libMagick.so.10 basket-kontact-1.0.2-5.fc9.i386 requires libkpinterfaces.so.1 basket-kontact-1.0.2-5.fc9.i386 requires libkcal.so.2 basket-kontact-1.0.2-5.fc9.i386 requires libktnef.so.1 basket-kontact-1.0.2-5.fc9.i386 requires kdepim3 basket-kontact-1.0.2-5.fc9.i386 requires libkdepim.so.1 conduit-0.3.10-1.fc10.noarch requires gnome-python-desktop conduit-0.3.10-1.fc10.noarch requires gnome-python-extras evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.i386 requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-1.2.so.11 kismet-extras-0.0.2007.10.R1-3.fc9.i386 requires libMagick.so.10 koffice-karbon-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-karbon-1.6.3-15.fc9.i386 requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libMagick.so.10 libopensync-plugin-kdepim-0.35-2.fc9.i386 requires libkcal.so.2 lsvpd-1.6.4-1.fc10.i386 requires libvpd_cxx-2.0.so.1 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) qgis-0.9.1-5.fc9.i386 requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.i386 requires libgeos.so.2 smart-0.52-54.fc9.i386 requires smart-config taskjuggler-2.4.1-1.fc10.i386 requires libkcal.so.2 taskjuggler-2.4.1-1.fc10.i386 requires libktnef.so.1 taskjuggler-libs-2.4.1-1.fc10.i386 requires libkcal.so.2 tellico-1.3.1-1.fc9.i386 requires libkcal.so.2 tellico-1.3.1-1.fc9.i386 requires libktnef.so.1 Broken deps for x86_64 ---------------------------------------------------------- LabPlot-1.5.1.6-4.fc8.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libMagick.so.10 LabPlot-1.5.1.6-4.fc8.x86_64 requires libMagick++.so.10()(64bit) LabPlot-1.5.1.6-4.fc8.x86_64 requires libMagick.so.10()(64bit) LabPlot-1.5.1.6-4.fc8.x86_64 requires libWand.so.10()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires libkcal.so.2()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires libkdepim.so.1()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires libktnef.so.1()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires kdepim3 basket-kontact-1.0.2-5.fc9.x86_64 requires libkpinterfaces.so.1()(64bit) conduit-0.3.10-1.fc10.noarch requires gnome-python-desktop conduit-0.3.10-1.fc10.noarch requires gnome-python-extras evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libWand.so.10()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx kismet-extras-0.0.2007.10.R1-3.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.x86_64 requires libWand.so.10()(64bit) koffice-libs-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.x86_64 requires libWand.so.10()(64bit) libopensync-plugin-kdepim-0.35-2.fc9.x86_64 requires libkcal.so.2()(64bit) lsvpd-1.6.4-1.fc10.x86_64 requires libvpd_cxx-2.0.so.1()(64bit) perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) qgis-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) smart-0.52-54.fc9.x86_64 requires smart-config taskjuggler-2.4.1-1.fc10.x86_64 requires libkcal.so.2()(64bit) taskjuggler-2.4.1-1.fc10.x86_64 requires libktnef.so.1()(64bit) taskjuggler-libs-2.4.1-1.fc10.i386 requires libkcal.so.2 taskjuggler-libs-2.4.1-1.fc10.x86_64 requires libkcal.so.2()(64bit) tellico-1.3.1-1.fc9.x86_64 requires libkcal.so.2()(64bit) tellico-1.3.1-1.fc9.x86_64 requires libktnef.so.1()(64bit) Broken deps for ppc ---------------------------------------------------------- LabPlot-1.5.1.6-4.fc8.ppc requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.ppc requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.ppc requires libMagick.so.10 basket-kontact-1.0.2-5.fc9.ppc requires libkpinterfaces.so.1 basket-kontact-1.0.2-5.fc9.ppc requires libkcal.so.2 basket-kontact-1.0.2-5.fc9.ppc requires libktnef.so.1 basket-kontact-1.0.2-5.fc9.ppc requires kdepim3 basket-kontact-1.0.2-5.fc9.ppc requires libkdepim.so.1 conduit-0.3.10-1.fc10.noarch requires gnome-python-desktop conduit-0.3.10-1.fc10.noarch requires gnome-python-extras evolution-brutus-1.2.11-2.fc9.ppc requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.ppc requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.ppc requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.ppc requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-1.2.so.11 kismet-extras-0.0.2007.10.R1-3.fc9.ppc requires libMagick.so.10 koffice-karbon-1.6.3-15.fc9.ppc requires libWand.so.10 koffice-karbon-1.6.3-15.fc9.ppc requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.ppc requires libWand.so.10 koffice-libs-1.6.3-15.fc9.ppc requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) libopensync-plugin-kdepim-0.35-2.fc9.ppc requires libkcal.so.2 lsvpd-1.6.4-1.fc10.ppc requires libvpd_cxx-2.0.so.1 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) qgis-0.9.1-5.fc9.ppc requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.ppc requires libgeos.so.2 smart-0.52-54.fc9.ppc requires smart-config taskjuggler-2.4.1-1.fc10.ppc requires libkcal.so.2 taskjuggler-2.4.1-1.fc10.ppc requires libktnef.so.1 taskjuggler-libs-2.4.1-1.fc10.ppc requires libkcal.so.2 taskjuggler-libs-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) tellico-1.3.1-1.fc9.ppc requires libkcal.so.2 tellico-1.3.1-1.fc9.ppc requires libktnef.so.1 Broken deps for ppc64 ---------------------------------------------------------- basket-kontact-1.0.2-5.fc9.ppc64 requires libkcal.so.2()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires libkdepim.so.1()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires libktnef.so.1()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires kdepim3 basket-kontact-1.0.2-5.fc9.ppc64 requires libkpinterfaces.so.1()(64bit) conduit-0.3.10-1.fc10.noarch requires gnome-python-desktop conduit-0.3.10-1.fc10.noarch requires gnome-python-extras evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) kismet-extras-0.0.2007.10.R1-3.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) libopensync-plugin-kdepim-0.35-2.fc9.ppc64 requires libkcal.so.2()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot lsvpd-1.6.4-1.fc10.ppc64 requires libvpd_cxx-2.0.so.1()(64bit) perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot qgis-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) smart-0.52-54.fc9.ppc64 requires smart-config taskjuggler-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) taskjuggler-2.4.1-1.fc10.ppc64 requires libktnef.so.1()(64bit) taskjuggler-libs-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) tellico-1.3.1-1.fc9.ppc64 requires libkcal.so.2()(64bit) tellico-1.3.1-1.fc9.ppc64 requires libktnef.so.1()(64bit) From markmc at redhat.com Thu May 22 13:14:45 2008 From: markmc at redhat.com (Mark McLoughlin) Date: Thu, 22 May 2008 14:14:45 +0100 Subject: Important information regarding 'rel-eng@fedoraproject.org' emails In-Reply-To: <1211405038.29698.23.camel@localhost.localdomain> References: <1211405038.29698.23.camel@localhost.localdomain> Message-ID: <1211462085.19714.9.camel@muff> On Wed, 2008-05-21 at 17:23 -0400, Jesse Keating wrote: > In an effort to be even more open, responsive, and reliable, Fedora > Release Engineering has created an email to Trac gateway. Email > requests for release engineering tasks sent to rel-eng at fedoraproject.org > will now be turned into tickets filed in the rel-eng Trac space. e.g. here: https://fedorahosted.org/rel-eng/report/1 > This > will allow for better visibility in the tasks needing to be done, a more > public record of task discussions, and better record keeping to prevent > things from falling through the email cracks. > > Any person that mails this address should receive an automated response > from the Trac system regarding their ticket with a URL that they can > visit to track the ticket progress, make updates, etc... This is pretty cool, I think. During the F-9 freeze I would have found it handy to see other people's freeze break requests and rel-eng responses, when trying to judge how to handle my own requests. Also, in: http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-may-19 You said: "at the time we enable email -> trac, I want to create a real releng mailing list, since we can now do hosted mailing lists move discussion to the public list, and get rid of the alias which is difficult to maintain and archive" That'd be great too - I found it hard during the freeze to keep track of what rel-eng plans were with e.g. when the RC was to be composed. Generally, it's very useful for people to be able to keep an eye on what's going on in rel-eng. Cheers, Mark. From stickster at gmail.com Thu May 22 13:14:48 2008 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 22 May 2008 13:14:48 +0000 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080522065724.1788e577@vader.jdub.homelinux.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> Message-ID: <1211462088.4891.45.camel@victoria> On Thu, 2008-05-22 at 06:57 -0500, Josh Boyer wrote: > Let the naming begin! We're starting very early this time around in > the name game for F10. So, let the suggestions flow! > > Remember the rules: > > 1) must have some link to Sulphur > > More specifically, the link should be > Sulphur is a and > is a > Where is the same for both "Neon," which also happens to be the element 10 in the periodic table. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-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 Thu May 22 13:25:12 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 22 May 2008 09:25:12 -0400 Subject: Important information regarding 'rel-eng@fedoraproject.org' emails In-Reply-To: <1211462085.19714.9.camel@muff> References: <1211405038.29698.23.camel@localhost.localdomain> <1211462085.19714.9.camel@muff> Message-ID: <1211462712.5079.50.camel@localhost.localdomain> On Thu, 2008-05-22 at 14:14 +0100, Mark McLoughlin wrote: > Also, in: > > > http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-may-19 > > You said: > > "at the time we enable email -> trac, I want to create a real > releng > mailing list, since we can now do hosted mailing lists > > move discussion to the public list, and get rid of the alias which > is difficult to maintain and archive" > > That'd be great too - I found it hard during the freeze to keep track > of > what rel-eng plans were with e.g. when the RC was to be composed. > > Generally, it's very useful for people to be able to keep an eye on > what's going on in rel-eng. The list has been created, 'rel-eng at lists.fedoraproject.org' however I'm still fighting a bit with some email loops I created when trying to get said list to be the default assignee of tickets and rel-eng at fedoraproject.org being the email gateway so I haven't advertised the list as "open for business" yet. Mostly I hope our conversations happen on fedora-devel-list as that's the most appropriate place for items that concern the maintainers. The list is just a handy place to dump ticket messages, cron outputs, and other such things. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jameshubbard at gmail.com Thu May 22 13:26:56 2008 From: jameshubbard at gmail.com (James Hubbard) Date: Thu, 22 May 2008 09:26:56 -0400 Subject: Xorg 1.5 missed the train? In-Reply-To: <48356DBF.4070108@hi.is> References: <48334163.4080709@magma.ca> <48337D52.7050005@poolshark.org> <4834729F.8030507@hi.is> <4834C7F6.1010100@poolshark.org> <48356DBF.4070108@hi.is> Message-ID: 2008/5/22 "J?hann B. Gu?mundsson" : > I have also never understood why hardware manufactures dont release specs to > the open source > community or atleast provide a proper functional driver even if it's an > closed one. > > One would think it was in their best interest to sell as much of the > hardware they manufacture regardless of > which OS the end user is using. I'm going to hazard a guess and say that the reason that they don't want to hand out specs is due to the fact all of their hardware is very similar and they don't want to cannibalize sales of their high end cards. http://www.techarp.com/showarticle.aspx?artno=539 The only reason that I've been using their binary driver lately is for the suspend and dual monitor support. In Feb., they finally released a driver that would allow suspend and resume to work while my dell laptop is docked. This is after years of it not working. I've upgraded my two home machines to F9 and they seems to be working fine with the nv driver other than suspend. I'm not upgrading my work laptop until the binary driver comes out. For past few years, I've been a supporter of Nvidia. They had always provided the best binary drivers and eventually gotten around to supporting the newer video cards. I've even written a spec where Dell changed the video chips so that the better Nvidia card would be in the laptop. (This was a large order and 3D capabilities were important.) This was in spite of the fact, as others have pointed out, that they are always late releasing a driver for a new distro when X has changed. Since, ATI/AMD have changed to providing hardware specs, I'm going to be buying their stuff from now on. There's a bunch of stuff that Nvidia's driver doesn't support and who knows if it will ever get supported under Linux, i.e. hdmi audio, better power mgmt, etc. At least with the AMD, I know that there's some hope that at some point features will be added. Thank you Fedora for not being held hostage to Nvidia. Sorry this has turned into a bit of a rant. James Hubbard From tmraz at redhat.com Thu May 22 13:41:43 2008 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 22 May 2008 15:41:43 +0200 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080522065724.1788e577@vader.jdub.homelinux.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> Message-ID: <1211463703.3287.1.camel@zaphne.frost.loc> Gelatine Sulphur is used in wine making (in form of sulphur dioxide). Gelatine is used in wine making. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From skvidal at fedoraproject.org Thu May 22 13:55:52 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 22 May 2008 09:55:52 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1211462088.4891.45.camel@victoria> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211462088.4891.45.camel@victoria> Message-ID: <1211464552.3559.41.camel@cutter> On Thu, 2008-05-22 at 13:14 +0000, Paul W. Frields wrote: > On Thu, 2008-05-22 at 06:57 -0500, Josh Boyer wrote: > > Let the naming begin! We're starting very early this time around in > > the name game for F10. So, let the suggestions flow! > > > > Remember the rules: > > > > 1) must have some link to Sulphur > > > > More specifically, the link should be > > Sulphur is a and > > is a > > Where is the same for both > > "Neon," which also happens to be the element 10 in the periodic table. > I like the way you think. -sv From wolfy at nobugconsulting.ro Thu May 22 14:07:37 2008 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Thu, 22 May 2008 17:07:37 +0300 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1211462088.4891.45.camel@victoria> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211462088.4891.45.camel@victoria> Message-ID: <48357E29.2010609@nobugconsulting.ro> Paul W. Frields wrote: > On Thu, 2008-05-22 at 06:57 -0500, Josh Boyer wrote: > >> Let the naming begin! We're starting very early this time around in >> the name game for F10. So, let the suggestions flow! >> >> Remember the rules: >> >> 1) must have some link to Sulphur >> >> More specifically, the link should be >> Sulphur is a and >> is a >> Where is the same for both >> > > "Neon," which also happens to be the element 10 in the periodic table. > I LOVE this one. From skvidal at fedoraproject.org Thu May 22 14:01:37 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 22 May 2008 10:01:37 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080522065724.1788e577@vader.jdub.homelinux.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> Message-ID: <1211464897.3559.44.camel@cutter> On Thu, 2008-05-22 at 06:57 -0500, Josh Boyer wrote: > Let the naming begin! We're starting very early this time around in > the name game for F10. So, let the suggestions flow! > > Remember the rules: > > 1) must have some link to Sulphur > > More specifically, the link should be > Sulphur is a and > is a > Where is the same for both > > 2) The link between and Sulphur cannot be the same as between > Werewolf and Sulphur. That link was "things that react badly with > silver". 3) Must have a good way of getting us to "Ours goes to" as the name of the release for F11. Or something else spinal-tap-related. -sv From skvidal at fedoraproject.org Thu May 22 14:02:44 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 22 May 2008 10:02:44 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <48356BE5.2020200@nigelj.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211459912.3079.4.camel@jdlaptop> <48356BE5.2020200@nigelj.com> Message-ID: <1211464964.3559.46.camel@cutter> On Fri, 2008-05-23 at 00:49 +1200, Nigel Jones wrote: > Jonathan Dieter wrote: > > On Thu, 2008-05-22 at 06:57 -0500, Josh Boyer wrote: > > > >> Let the naming begin! We're starting very early this time around in > >> the name game for F10. So, let the suggestions flow! > >> > > > > Might as well get the obvious out of the way: > > > > Sulphur -> Gold > > Sulphur -> Titanium > > Sulphur -> Platinum > > Sulphur -> Berklium (okay, maybe not so much) > > > Ewww, I dislike Gold, not only is it a bit too obvious it's also the > term some people reference major releases to, why not Mercury, it keeps > the same link and allows for maybe Fedora Pluto in the future :). > Use of a little bit of mercury isn't the end of the world. Prolonged exposure, however, drives you nuts. how, umm, appropriate? :) -sv From mark.bidewell at alumni.clemson.edu Thu May 22 14:11:15 2008 From: mark.bidewell at alumni.clemson.edu (Mark Bidewell) Date: Thu, 22 May 2008 10:11:15 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1211464552.3559.41.camel@cutter> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211462088.4891.45.camel@victoria> <1211464552.3559.41.camel@cutter> Message-ID: On Thu, May 22, 2008 at 9:55 AM, seth vidal wrote: > On Thu, 2008-05-22 at 13:14 +0000, Paul W. Frields wrote: > > On Thu, 2008-05-22 at 06:57 -0500, Josh Boyer wrote: > > > Let the naming begin! We're starting very early this time around in > > > the name game for F10. So, let the suggestions flow! > > > > > > Remember the rules: > > > > > > 1) must have some link to Sulphur > > > > > > More specifically, the link should be > > > Sulphur is a and > > > is a > > > Where is the same for both > > > > "Neon," which also happens to be the element 10 in the periodic table. > > > > I like the way you think. > > -sv > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > +1 I have to say I like neon as well. We must be somewhat careful with the naming of Fedora. Sulpher came close to eliciting visions of a foul smelling compound - *Not* what one wants to associate with an awesome OS! Mark Bidewell -------------- next part -------------- An HTML attachment was scrubbed... URL: From icon at fedoraproject.org Thu May 22 13:52:11 2008 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Thu, 22 May 2008 09:52:11 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080522065724.1788e577@vader.jdub.homelinux.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> Message-ID: On Thu, May 22, 2008 at 7:57 AM, Josh Boyer wrote: Sulphur is an ingredient used to make chemicals. Element X is an ingredient used to make Powerpuff Girls. Thus, we should have Fedora X 10. ;) Cheers, -- Konstantin Ryabitsev Montr?al, Qu?bec From bkearney at redhat.com Thu May 22 14:14:07 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 22 May 2008 10:14:07 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1211464964.3559.46.camel@cutter> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211459912.3079.4.camel@jdlaptop> <48356BE5.2020200@nigelj.com> <1211464964.3559.46.camel@cutter> Message-ID: <48357FAF.2050300@redhat.com> Tempest That which is rained on upon you in hell: Upon the wicked he shall rain snares, fire and brimstone, and an horrible tempest: this shall be the portion of their cup. (Psalm 11:6) Since Brimstone is another name for Sulphur. -- bk seth vidal wrote: > On Fri, 2008-05-23 at 00:49 +1200, Nigel Jones wrote: >> Jonathan Dieter wrote: >>> On Thu, 2008-05-22 at 06:57 -0500, Josh Boyer wrote: >>> >>>> Let the naming begin! We're starting very early this time around in >>>> the name game for F10. So, let the suggestions flow! >>>> >>> Might as well get the obvious out of the way: >>> >>> Sulphur -> Gold >>> Sulphur -> Titanium >>> Sulphur -> Platinum >>> Sulphur -> Berklium (okay, maybe not so much) >>> >> Ewww, I dislike Gold, not only is it a bit too obvious it's also the >> term some people reference major releases to, why not Mercury, it keeps >> the same link and allows for maybe Fedora Pluto in the future :). >> > > Use of a little bit of mercury isn't the end of the world. Prolonged > exposure, however, drives you nuts. > > how, umm, appropriate? > > :) > -sv > > From billcrawford1970 at gmail.com Thu May 22 14:16:40 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Thu, 22 May 2008 15:16:40 +0100 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: References: <20080522065724.1788e577@vader.jdub.homelinux.org> Message-ID: <544eb990805220716m617863b6v28cc14b01ab0c2b2@mail.gmail.com> 2008/5/22 Konstantin Ryabitsev : > Sulphur is an ingredient used to make chemicals. > Element X is an ingredient used to make Powerpuff Girls. > > Thus, we should have Fedora X 10. ;) This does indeed fit the "... goes to 11" category too. I think we have a winner! ;o) From ssorce at redhat.com Thu May 22 14:18:26 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 22 May 2008 10:18:26 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080522065724.1788e577@vader.jdub.homelinux.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> Message-ID: <1211465906.3935.107.camel@localhost.localdomain> On Thu, 2008-05-22 at 06:57 -0500, Josh Boyer wrote: > Let the naming begin! We're starting very early this time around in > the name game for F10. So, let the suggestions flow! > > Remember the rules: > > 1) must have some link to Sulphur > > More specifically, the link should be > Sulphur is a and > is a > Where is the same for both > > 2) The link between and Sulphur cannot be the same as between > Werewolf and Sulphur. That link was "things that react badly with > silver". > > I will be collecting suggestions for 1 week, so the cutoff for names is: > > May 29, 2008 > > Suggestions will be run through the legal queue and an election will > happen for Fedora contributors to pick the next Fedora name. Steam is released by a modern combustion engine, Suplhur as well. And this would make some connection with SteamPunk too ? Simo. -- Simo Sorce * Red Hat, Inc * New York From mattdm at mattdm.org Thu May 22 14:20:09 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 22 May 2008 10:20:09 -0400 Subject: NetworkManager: I want to believe, but... [was Re: F9 potential service network bug?] In-Reply-To: <1211024075.4060.50.camel@localhost.localdomain> References: <3da3b5b40805161502w62f372dseca0ab6310e44447@mail.gmail.com> <1210975852.6805.10.camel@localhost.localdomain> <3da3b5b40805161522i2300f1cdhb1fc7b074084873f@mail.gmail.com> <604aa7910805161527j6b193c6dj2af4248155d5cdaf@mail.gmail.com> <20080517112856.GA18698@jadzia.bu.edu> <1211024075.4060.50.camel@localhost.localdomain> Message-ID: <20080522142009.GA8728@jadzia.bu.edu> On Sat, May 17, 2008 at 07:34:35AM -0400, Jesse Keating wrote: > Please post your ifconfig files as they came from the installer when > things weren't working. I've messed around with it enough that I can't get the original behavior back without reinstalling. And I had a few days unexpectedly offline, during which it looks like some problems have been pinpointed, yeah? Would it still be helpful for me to recreate? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From nicolas.mailhot at laposte.net Thu May 22 14:20:56 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 22 May 2008 16:20:56 +0200 (CEST) Subject: OCHRE (was: Re: Werewolf -> Sulphur -> ? Sulphur is a , is a ) In-Reply-To: <20080522120933.GA23317@amd.home.annexia.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <20080522120933.GA23317@amd.home.annexia.org> Message-ID: <50196.192.54.193.52.1211466056.squirrel@rousalka.dyndns.org> Le Jeu 22 mai 2008 14:09, Richard W.M. Jones a ?crit : > On Thu, May 22, 2008 at 06:57:24AM -0500, Josh Boyer wrote: >> 2) The link between and Sulphur cannot be the same as >> between >> Werewolf and Sulphur. That link was "things that react badly with >> silver". > > OCHRE Ochre is more orangish/red IIRC. But lemon is yellow. Sulphur -> Lemon -- Nicolas Mailhot From ianweller at gmail.com Thu May 22 14:21:35 2008 From: ianweller at gmail.com (Ian Weller) Date: Thu, 22 May 2008 09:21:35 -0500 (CDT) Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1211462088.4891.45.camel@victoria> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211462088.4891.45.camel@victoria> Message-ID: On Thu, 22 May 2008, Paul W. Frields wrote: > "Neon," which also happens to be the element 10 in the periodic table. > +1 -- ian From jkeating at redhat.com Thu May 22 14:25:16 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 22 May 2008 10:25:16 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <48357E29.2010609@nobugconsulting.ro> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211462088.4891.45.camel@victoria> <48357E29.2010609@nobugconsulting.ro> Message-ID: <1211466316.5079.61.camel@localhost.localdomain> On Thu, 2008-05-22 at 17:07 +0300, Manuel Wolfshant wrote: > > "Neon," which also happens to be the element 10 in the periodic > table. > > > I LOVE this one. Unfortunately it doesn't follow the "is a" algorithm. Now, one could do something like this: Sulphur is a gas found in the nebula around the blue supergiant Sher 25 Neon is a gas found in the nebula around the blue supergiant Sher 25 http://www.citeulike.org/user/tmorris/article/2635153 -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From nicolas.mailhot at laposte.net Thu May 22 14:25:00 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 22 May 2008 16:25:00 +0200 (CEST) Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080522065724.1788e577@vader.jdub.homelinux.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> Message-ID: <64325.192.54.193.52.1211466300.squirrel@rousalka.dyndns.org> Le Jeu 22 mai 2008 13:57, Josh Boyer a ?crit : > Let the naming begin! We're starting very early this time around in > the name game for F10. So, let the suggestions flow! Sulphur is a black powder ingredient Salpetre is a black powder ingredient Bang! -- Nicolas Mailhot From mattdm at mattdm.org Thu May 22 14:25:54 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 22 May 2008 10:25:54 -0400 Subject: NetworkManager: I want to believe, but... [was Re: F9 potential service network bug?] In-Reply-To: <1211069083.3070.392.camel@cookie.hadess.net> References: <3da3b5b40805161502w62f372dseca0ab6310e44447@mail.gmail.com> <1210975852.6805.10.camel@localhost.localdomain> <3da3b5b40805161522i2300f1cdhb1fc7b074084873f@mail.gmail.com> <604aa7910805161527j6b193c6dj2af4248155d5cdaf@mail.gmail.com> <20080517112856.GA18698@jadzia.bu.edu> <1211069083.3070.392.camel@cookie.hadess.net> Message-ID: <20080522142554.GB8728@jadzia.bu.edu> On Sun, May 18, 2008 at 01:04:43AM +0100, Bastien Nocera wrote: > The pluses are that: > - it should be able to boot up faster (note the should) Because of delaying network initialization, or something else? I'm generally not interested in boot time per se except in the sense of time-to-fully-operational. (For machines with static addresses -- this isn't the laptop case.) > - it informs applications that you're connected to the network (say, you > unplug the network, the router dies, or the driver for your network card > drops you off the network) I can see this being handy in some cases, but mostly, the network status of statically-configured machines is generally best monitored externally. > - and finally, it will allow routing over multiple connections in the > future (so static wired, and wireless routed over the wired, or all the > wired routed over a WWAN in case your internet connection breaks). This can be done already with static configuration, but if it makes an auto-fallback easy to configure that does seem like a plus -- but very special purpose. C'mon, seriously, is that all you've got? :) The real major plus I see is: "It's good for the desktop, so doing it on servers means it all works the same." But that's kind of a hard sell -- and since in many cases I end up the one _making_ the sell, I'd like something more to work with. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From Christian.Iseli at unil.ch Thu May 22 14:27:29 2008 From: Christian.Iseli at unil.ch (Christian Iseli) Date: Thu, 22 May 2008 16:27:29 +0200 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: References: <1211377739.4210.2.camel@truman> <1211410870.2290.5.camel@kennedy> Message-ID: <20080522162729.1c8298da@ludwig-alpha.unil.ch> On Thu, 22 May 2008 06:55:58 -0300, Alexandre Oliva wrote: > Here's the proposed feature I've just drafted up: > http://fedoraproject.org/wiki/Features/FedoraFreedom /me rambles a bit... Unless I'm mistaken, I assume such a libre system will run on ix86 and x86_64 machines. As far as I understand, nobody has a GPL'd version of those processors, nor a choice to hack on their "source" code and distribute changes... There is no real distinction between what is hardware and what is software. It is more like a continuum between the two, and firmware, as its name implies, lies somewhere between hard- and soft-ware. To make a long story short, we need to draw a line somewhere between where we require GPL'd source code, and where we do not. That line is defined in http://fedoraproject.org/wiki/Packaging/LicensingGuidelines#BinaryFirmware I think it is a laudable goal to move that line as close to having GPL'd hardware as possible, but as others have mentioned, I think this means working with upstream kernel to get to a point where you feel you have all the liberty you expect from the kernel in Fedora. CHF 0.02... Cheers, Christian From skvidal at fedoraproject.org Thu May 22 14:23:44 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 22 May 2008 10:23:44 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1211466316.5079.61.camel@localhost.localdomain> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211462088.4891.45.camel@victoria> <48357E29.2010609@nobugconsulting.ro> <1211466316.5079.61.camel@localhost.localdomain> Message-ID: <1211466224.3559.48.camel@cutter> On Thu, 2008-05-22 at 10:25 -0400, Jesse Keating wrote: > On Thu, 2008-05-22 at 17:07 +0300, Manuel Wolfshant wrote: > > > "Neon," which also happens to be the element 10 in the periodic > > table. > > > > > I LOVE this one. > > Unfortunately it doesn't follow the "is a" algorithm. yes it does. Sulphur is an element in the periodic table Neon is an element in the periodic table -sv From anders at trudheim.co.uk Thu May 22 14:31:02 2008 From: anders at trudheim.co.uk (Anders Karlsson) Date: Thu, 22 May 2008 16:31:02 +0200 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <48356E71.7090605@nicubunu.ro> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <48356E71.7090605@nicubunu.ro> Message-ID: <20080522143102.GS3951@localhost.localdomain> * Nicu Buculei [20080522 15:01]: > Josh Boyer wrote: >> Let the naming begin! We're starting very early this time around in >> the name game for F10. So, let the suggestions flow! > > OK, so I shamelessly jump in with some pimping: there are some graphic > concepts drafted for a F10 theme proposal based on a steampunk concept and > titled "Gears": > http://fedoraproject.org/wiki/Artwork/F10Themes/Gears > > I wonder if someone can come with a name that can fit both the "Gears" > theme and the naming scheme (linked somehow with Sulphur). That theme looks very much like some of the graphics in the Bitmap Brothers game "Chaos Engine". I like it! Can't find a link to tie Sulphur to Chaos or Chaos Engine though. :-/ -- Anders From mrmazda at ij.net Thu May 22 14:32:47 2008 From: mrmazda at ij.net (Felix Miata) Date: Thu, 22 May 2008 10:32:47 -0400 Subject: OCHRE In-Reply-To: <50196.192.54.193.52.1211466056.squirrel@rousalka.dyndns.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <20080522120933.GA23317@amd.home.annexia.org> <50196.192.54.193.52.1211466056.squirrel@rousalka.dyndns.org> Message-ID: <4835840F.3020508@ij.net> On 2008/05/22 16:20 (GMT+0200) Nicolas Mailhot apparently typed: > Ochre is more orangish/red IIRC. > But lemon is yellow. Sulphur -> Lemon bad smell -> sour product -1 -- ". . . . in everything, do to others what you would have them do to you . . . ." Matthew 7:12 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ From mattdm at mattdm.org Thu May 22 14:33:44 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 22 May 2008 10:33:44 -0400 Subject: hook into rpm install/update/deletion of any package (for etckeeper) In-Reply-To: <20080519184747.GD1519793@hiwaay.net> References: <200805192002.44554.opensource@till.name> <1211220705.3095.9.camel@cutter> <200805192031.36555.opensource@till.name> <20080519184747.GD1519793@hiwaay.net> Message-ID: <20080522143344.GC8728@jadzia.bu.edu> On Mon, May 19, 2008 at 01:47:47PM -0500, Chris Adams wrote: > > I knew there are yum plugins and etckeeper will probably need one, but it > > would not be enough for me, because I also often install packages via rpm > > when I built them myself. > You could write a daemon that monitors /etc with inotify. Alternately, Or take a look at incrond, included in fedora already. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Thu May 22 14:34:38 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 22 May 2008 10:34:38 -0400 Subject: NetworkManager: I want to believe, but... [was Re: F9 potential service network bug?] In-Reply-To: <20080522142009.GA8728@jadzia.bu.edu> References: <3da3b5b40805161502w62f372dseca0ab6310e44447@mail.gmail.com> <1210975852.6805.10.camel@localhost.localdomain> <3da3b5b40805161522i2300f1cdhb1fc7b074084873f@mail.gmail.com> <604aa7910805161527j6b193c6dj2af4248155d5cdaf@mail.gmail.com> <20080517112856.GA18698@jadzia.bu.edu> <1211024075.4060.50.camel@localhost.localdomain> <20080522142009.GA8728@jadzia.bu.edu> Message-ID: <1211466878.5079.63.camel@localhost.localdomain> On Thu, 2008-05-22 at 10:20 -0400, Matthew Miller wrote: > > I've messed around with it enough that I can't get the original behavior > back without reinstalling. And I had a few days unexpectedly offline, during > which it looks like some problems have been pinpointed, yeah? Would it still > be helpful for me to recreate? I'd defer to Dan Williams. I think he has some updates coming that may help. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From billcrawford1970 at gmail.com Thu May 22 14:34:35 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Thu, 22 May 2008 15:34:35 +0100 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <64325.192.54.193.52.1211466300.squirrel@rousalka.dyndns.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <64325.192.54.193.52.1211466300.squirrel@rousalka.dyndns.org> Message-ID: <544eb990805220734x5557d11dt9cb58554f57303d@mail.gmail.com> 2008/5/22 Nicolas Mailhot : > > Le Jeu 22 mai 2008 13:57, Josh Boyer a ?crit : >> Let the naming begin! We're starting very early this time around in >> the name game for F10. So, let the suggestions flow! > > Sulphur is a black powder ingredient > Salpetre is a black powder ingredient > > Bang! Swamp. Sulphur is evil-smelling. Swamp is evil-smelling. From jkeating at redhat.com Thu May 22 14:42:32 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 22 May 2008 10:42:32 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1211466224.3559.48.camel@cutter> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211462088.4891.45.camel@victoria> <48357E29.2010609@nobugconsulting.ro> <1211466316.5079.61.camel@localhost.localdomain> <1211466224.3559.48.camel@cutter> Message-ID: <1211467352.5079.65.camel@localhost.localdomain> On Thu, 2008-05-22 at 10:23 -0400, seth vidal wrote: > yes it does. > > Sulphur is an element in the periodic table > Neon is an element in the periodic table And that feels way too generic, like "fred" is a word in the dictionary, "alphanumeric" is a word in the dictionary. It's not trying hard enough (: -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From dwmw2 at infradead.org Thu May 22 14:42:41 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 22 May 2008 15:42:41 +0100 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: <20080522162729.1c8298da@ludwig-alpha.unil.ch> References: <1211377739.4210.2.camel@truman> <1211410870.2290.5.camel@kennedy> <20080522162729.1c8298da@ludwig-alpha.unil.ch> Message-ID: <1211467361.21380.448.camel@pmac.infradead.org> On Thu, 2008-05-22 at 16:27 +0200, Christian Iseli wrote: > /me rambles a bit... > > Unless I'm mistaken, I assume such a libre system will run on ix86 and > x86_64 machines. I assume Alex won't be including an interpreter for closed-source ACPI bytecode in his kernel. So it's likely to have problems on a lot of i386 and x86_64 machines. Should be OK on PPC though :) -- dwmw2 From cmadams at hiwaay.net Thu May 22 14:49:00 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 22 May 2008 09:49:00 -0500 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1211467352.5079.65.camel@localhost.localdomain> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211462088.4891.45.camel@victoria> <48357E29.2010609@nobugconsulting.ro> <1211466316.5079.61.camel@localhost.localdomain> <1211466224.3559.48.camel@cutter> <1211467352.5079.65.camel@localhost.localdomain> Message-ID: <20080522144859.GC1072817@hiwaay.net> Once upon a time, Jesse Keating said: > On Thu, 2008-05-22 at 10:23 -0400, seth vidal wrote: > > yes it does. > > > > Sulphur is an element in the periodic table > > Neon is an element in the periodic table > > And that feels way too generic, like "fred" is a word in the dictionary, > "alphanumeric" is a word in the dictionary. It's not trying hard enough Yeah, but "element in the periodic table" is a much more exclusive list than "word in the dictionary". I mean, they haven't even added Unobtainium yet! -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From wolfy at nobugconsulting.ro Thu May 22 14:49:11 2008 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Thu, 22 May 2008 17:49:11 +0300 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1211467352.5079.65.camel@localhost.localdomain> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211462088.4891.45.camel@victoria> <48357E29.2010609@nobugconsulting.ro> <1211466316.5079.61.camel@localhost.localdomain> <1211466224.3559.48.camel@cutter> <1211467352.5079.65.camel@localhost.localdomain> Message-ID: <483587E7.2020300@nobugconsulting.ro> Jesse Keating wrote: > On Thu, 2008-05-22 at 10:23 -0400, seth vidal wrote: > >> yes it does. >> >> Sulphur is an element in the periodic table >> Neon is an element in the periodic table >> > > And that feels way too generic, like "fred" is a word in the dictionary, > "alphanumeric" is a word in the dictionary. It's not trying hard enough > (: > I'd argument that the link Fedora 10 < --> 10th element in the periodic table is worth it. That's why I liked it so much. From skvidal at fedoraproject.org Thu May 22 14:52:06 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 22 May 2008 10:52:06 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1211467352.5079.65.camel@localhost.localdomain> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211462088.4891.45.camel@victoria> <48357E29.2010609@nobugconsulting.ro> <1211466316.5079.61.camel@localhost.localdomain> <1211466224.3559.48.camel@cutter> <1211467352.5079.65.camel@localhost.localdomain> Message-ID: <1211467926.3559.51.camel@cutter> On Thu, 2008-05-22 at 10:42 -0400, Jesse Keating wrote: > On Thu, 2008-05-22 at 10:23 -0400, seth vidal wrote: > > yes it does. > > > > Sulphur is an element in the periodic table > > Neon is an element in the periodic table > > And that feels way too generic, like "fred" is a word in the dictionary, > "alphanumeric" is a word in the dictionary. It's not trying hard enough In terms of words in the dictionary there are millions there are only 118. (so far) -sv From choeger at cs.tu-berlin.de Thu May 22 14:59:36 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Thu, 22 May 2008 16:59:36 +0200 Subject: Xorg very, very hungry... Message-ID: <1211468376.26044.9.camel@choeger6> Hi, when I activated compiz on my new R61 I was amazed how good it worked. But today I found that with top: 24420 root 20 0 672m 337m 9648 S 6.6 17.0 5:54.02 Xorg Is that normal? regards christoph -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From berrange at redhat.com Thu May 22 15:03:24 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 22 May 2008 16:03:24 +0100 Subject: Xorg very, very hungry... In-Reply-To: <1211468376.26044.9.camel@choeger6> References: <1211468376.26044.9.camel@choeger6> Message-ID: <20080522150324.GD26567@redhat.com> On Thu, May 22, 2008 at 04:59:36PM +0200, Christoph H?ger wrote: > Hi, > > when I activated compiz on my new R61 I was amazed how good it worked. > > But today I found that with top: > > 24420 root 20 0 672m 337m 9648 S 6.6 17.0 5:54.02 Xorg > > Is that normal? It probably has lots of pixmaps loaded on behalf of the apps you are running. Use xrestop to monitor it Dan -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From aph at redhat.com Thu May 22 15:04:19 2008 From: aph at redhat.com (Andrew Haley) Date: Thu, 22 May 2008 16:04:19 +0100 Subject: Xorg very, very hungry... In-Reply-To: <1211468376.26044.9.camel@choeger6> References: <1211468376.26044.9.camel@choeger6> Message-ID: <48358B73.90304@redhat.com> Christoph H?ger wrote: > Hi, > > when I activated compiz on my new R61 I was amazed how good it worked. > > But today I found that with top: > > 24420 root 20 0 672m 337m 9648 S 6.6 17.0 5:54.02 Xorg > > Is that normal? That depends. Clients often ask X to cache bitmaps for them, and they can be huge. Andrew. From jkeating at redhat.com Thu May 22 15:15:00 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 22 May 2008 11:15:00 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1211467926.3559.51.camel@cutter> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211462088.4891.45.camel@victoria> <48357E29.2010609@nobugconsulting.ro> <1211466316.5079.61.camel@localhost.localdomain> <1211466224.3559.48.camel@cutter> <1211467352.5079.65.camel@localhost.localdomain> <1211467926.3559.51.camel@cutter> Message-ID: <1211469300.5079.67.camel@localhost.localdomain> On Thu, 2008-05-22 at 10:52 -0400, seth vidal wrote: > there are only 118. (so far) Still, I bet you could find a more creative way to link Sulphur and Neon together without going for the obvious. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mike at miketc.com Thu May 22 15:17:12 2008 From: mike at miketc.com (Mike Chambers) Date: Thu, 22 May 2008 10:17:12 -0500 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080522143102.GS3951@localhost.localdomain> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <48356E71.7090605@nicubunu.ro> <20080522143102.GS3951@localhost.localdomain> Message-ID: <1211469432.2678.0.camel@scrappy.miketc.com> On Thu, 2008-05-22 at 16:31 +0200, Anders Karlsson wrote: > * Nicu Buculei [20080522 15:01]: > > Josh Boyer wrote: > >> Let the naming begin! We're starting very early this time around in > >> the name game for F10. So, let the suggestions flow! > > > > OK, so I shamelessly jump in with some pimping: there are some graphic > > concepts drafted for a F10 theme proposal based on a steampunk concept and > > titled "Gears": > > http://fedoraproject.org/wiki/Artwork/F10Themes/Gears > > > > I wonder if someone can come with a name that can fit both the "Gears" > > theme and the naming scheme (linked somehow with Sulphur). > > That theme looks very much like some of the graphics in the Bitmap > Brothers game "Chaos Engine". I like it! > > Can't find a link to tie Sulphur to Chaos or Chaos Engine though. :-/ Gears at made of metal? Can tie into it that way somehow? -- Mike Chambers Fedora Project - Ambassador, Bug Zapper, Tester, User, etc.. mikec302 at fedoraproject.org From drago01 at gmail.com Thu May 22 15:25:48 2008 From: drago01 at gmail.com (drago01) Date: Thu, 22 May 2008 17:25:48 +0200 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080522065724.1788e577@vader.jdub.homelinux.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> Message-ID: On Thu, May 22, 2008 at 1:57 PM, Josh Boyer wrote: > Let the naming begin! We're starting very early this time around in > the name game for F10. So, let the suggestions flow! > > Remember the rules: > > 1) must have some link to Sulphur > > More specifically, the link should be > Sulphur is a and > is a > Where is the same for both > > 2) The link between and Sulphur cannot be the same as between > Werewolf and Sulphur. That link was "things that react badly with > silver". Diamond ? connection is obvious (crystal) From jspaleta at gmail.com Thu May 22 15:27:54 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 22 May 2008 07:27:54 -0800 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1211462088.4891.45.camel@victoria> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211462088.4891.45.camel@victoria> Message-ID: <604aa7910805220827y453b482dl8fd68d5b174f61dd@mail.gmail.com> 2008/5/22 Paul W. Frields : > "Neon," which also happens to be the element 10 in the periodic table. Okay smart guy, how you would move out from Neon to "Ours goes to" So is there money in the budget for a neon sign that reads "Fedora" to display at to events? For example FUDCon Fairbanks? -jef"house poor"spaleta From johannbg at hi.is Thu May 22 14:43:03 2008 From: johannbg at hi.is (=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=) Date: Thu, 22 May 2008 14:43:03 +0000 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: References: <20080522065724.1788e577@vader.jdub.homelinux.org> Message-ID: <48358677.2040807@hi.is> Konstantin Ryabitsev wrote: > On Thu, May 22, 2008 at 7:57 AM, Josh Boyer wrote: > > Sulphur is an ingredient used to make chemicals. > Element X is an ingredient used to make Powerpuff Girls. > > Thus, we should have Fedora X 10. ;) > > Cheers, > +1 Fedora X.. X marks the spot... JB -------------- next part -------------- A non-text attachment was scrubbed... Name: johannbg.vcf Type: text/x-vcard Size: 381 bytes Desc: not available URL: From choeger at cs.tu-berlin.de Thu May 22 15:22:40 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Thu, 22 May 2008 17:22:40 +0200 Subject: Xorg very, very hungry... In-Reply-To: <20080522150324.GD26567@redhat.com> References: <1211468376.26044.9.camel@choeger6> <20080522150324.GD26567@redhat.com> Message-ID: <1211469760.26044.12.camel@choeger6> Am Donnerstag, den 22.05.2008, 16:03 +0100 schrieb Daniel P. Berrange: > On Thu, May 22, 2008 at 04:59:36PM +0200, Christoph H?ger wrote: > > Hi, > > > > when I activated compiz on my new R61 I was amazed how good it worked. > > > > But today I found that with top: > > > > 24420 root 20 0 672m 337m 9648 S 6.6 17.0 5:54.02 Xorg > > > > Is that normal? > > It probably has lots of pixmaps loaded on behalf of the apps you are > running. Use xrestop to monitor it > > Dan > -- > |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| > |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| > |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| > Hi, actual snapshot: top: 24420 root 20 0 595m 261m 10m R 29.8 13.1 8:54.40 Xorg xrestop: Pixmaps: 27596K total, Other: 178K total, All: 27774K total Seems unlikely to me, that its all about the cache ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From zboszor at freemail.hu Thu May 22 15:45:19 2008 From: zboszor at freemail.hu (Zoltan Boszormenyi) Date: Thu, 22 May 2008 17:45:19 +0200 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <64325.192.54.193.52.1211466300.squirrel@rousalka.dyndns.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <64325.192.54.193.52.1211466300.squirrel@rousalka.dyndns.org> Message-ID: <4835950F.2080801@freemail.hu> Nicolas Mailhot ?rta: > Le Jeu 22 mai 2008 13:57, Josh Boyer a ?crit : > >> Let the naming begin! We're starting very early this time around in >> the name game for F10. So, let the suggestions flow! >> > > Sulphur is a black powder ingredient > Salpetre is a black powder ingredient > > Bang! > When Sulphur is burning everyone notices. (smells badly) When Phosphor is burning, everyone notices. (you can't put out, burns under water, ingredient of greek fire) Sulphur is lethal in some forms. (Sulphuric acid) Phosphor is lethal in some forms, killer in others. (greek fire vs phosphor acid in coke) :-) From jspaleta at gmail.com Thu May 22 15:53:08 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 22 May 2008 07:53:08 -0800 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: <1211467361.21380.448.camel@pmac.infradead.org> References: <1211377739.4210.2.camel@truman> <1211410870.2290.5.camel@kennedy> <20080522162729.1c8298da@ludwig-alpha.unil.ch> <1211467361.21380.448.camel@pmac.infradead.org> Message-ID: <604aa7910805220853y365ecbb2qd64319388ed26e89@mail.gmail.com> On Thu, May 22, 2008 at 6:42 AM, David Woodhouse wrote: > I assume Alex won't be including an interpreter for closed-source ACPI > bytecode in his kernel. So it's likely to have problems on a lot of i386 > and x86_64 machines. Should be OK on PPC though :) It would however be fascinating to see how many machines fall over and die in the attempt. I like your action plan concerning the firmware conversion, but what the hell do i know. If your plan ever makes it to an upstream technical discussion, I want to make sure I know about so I can read along. -jef From jwboyer at gmail.com Thu May 22 15:58:52 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 22 May 2008 10:58:52 -0500 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <48358677.2040807@hi.is> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <48358677.2040807@hi.is> Message-ID: <20080522105852.0cc59f7b@weaponx> On Thu, 22 May 2008 14:43:03 +0000 "J?hann B. Gu?mundsson" wrote: > Konstantin Ryabitsev wrote: > > On Thu, May 22, 2008 at 7:57 AM, Josh Boyer wrote: > > > > Sulphur is an ingredient used to make chemicals. > > Element X is an ingredient used to make Powerpuff Girls. > > > > Thus, we should have Fedora X 10. ;) > > > > Cheers, > > > +1 > > Fedora X.. > X marks the spot... I'm fairly certain this would be denied due to the other operating system that calls itself "OSX". josh From kevin at scrye.com Thu May 22 16:02:03 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Thu, 22 May 2008 10:02:03 -0600 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080522143102.GS3951@localhost.localdomain> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <48356E71.7090605@nicubunu.ro> <20080522143102.GS3951@localhost.localdomain> Message-ID: <20080522100203.6746e0ae@ohm.scrye.com> On Thu, 22 May 2008 16:31:02 +0200 anders at trudheim.co.uk (Anders Karlsson) wrote: > * Nicu Buculei [20080522 15:01]: > > Josh Boyer wrote: > >> Let the naming begin! We're starting very early this time around > >> in the name game for F10. So, let the suggestions flow! > > > > OK, so I shamelessly jump in with some pimping: there are some > > graphic concepts drafted for a F10 theme proposal based on a > > steampunk concept and titled "Gears": > > http://fedoraproject.org/wiki/Artwork/F10Themes/Gears > > > > I wonder if someone can come with a name that can fit both the > > "Gears" theme and the naming scheme (linked somehow with Sulphur). > > That theme looks very much like some of the graphics in the Bitmap > Brothers game "Chaos Engine". I like it! > > Can't find a link to tie Sulphur to Chaos or Chaos Engine though. :-/ Both "characters" in a video game? Sulphur is in http://en.wikipedia.org/wiki/Phantom_Brave Might be streching it a bit to call the Chaos Engine a character though. ;) kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From steve.dowe at onecool.com Thu May 22 16:03:33 2008 From: steve.dowe at onecool.com (Steve Dowe) Date: Thu, 22 May 2008 17:03:33 +0100 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <3E241CC6FB3A4A498507355A8E917197@internal.onecool.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org><48358677.2040807@hi.is> <3E241CC6FB3A4A498507355A8E917197@internal.onecool.com> Message-ID: <48359955.6000109@onecool.com> Josh Boyer wrote: > On Thu, 22 May 2008 14:43:03 +0000 > "J?hann B. Gu?mundsson" wrote: > >> Konstantin Ryabitsev wrote: >>> On Thu, May 22, 2008 at 7:57 AM, Josh Boyer wrote: >>> >>> Sulphur is an ingredient used to make chemicals. >>> Element X is an ingredient used to make Powerpuff Girls. >>> >>> Thus, we should have Fedora X 10. ;) >>> >>> Cheers, >>> >> +1 >> >> Fedora X.. >> X marks the spot... > > I'm fairly certain this would be denied due to the other operating > system that calls itself "OSX". I'm pretty sure you cannot trademark a Roman Numeral. Steve From dcbw at redhat.com Thu May 22 16:04:27 2008 From: dcbw at redhat.com (Dan Williams) Date: Thu, 22 May 2008 12:04:27 -0400 Subject: NetworkManager: I want to believe, but... [was Re: F9 potential service network bug?] In-Reply-To: <20080522142554.GB8728@jadzia.bu.edu> References: <3da3b5b40805161502w62f372dseca0ab6310e44447@mail.gmail.com> <1210975852.6805.10.camel@localhost.localdomain> <3da3b5b40805161522i2300f1cdhb1fc7b074084873f@mail.gmail.com> <604aa7910805161527j6b193c6dj2af4248155d5cdaf@mail.gmail.com> <20080517112856.GA18698@jadzia.bu.edu> <1211069083.3070.392.camel@cookie.hadess.net> <20080522142554.GB8728@jadzia.bu.edu> Message-ID: <1211472267.5352.25.camel@localhost.localdomain> On Thu, 2008-05-22 at 10:25 -0400, Matthew Miller wrote: > On Sun, May 18, 2008 at 01:04:43AM +0100, Bastien Nocera wrote: > > The pluses are that: > > - it should be able to boot up faster (note the should) > > Because of delaying network initialization, or something else? I'm generally > not interested in boot time per se except in the sense of > time-to-fully-operational. (For machines with static addresses -- this isn't > the laptop case.) If you have a wired interface marked for DHCP, but no cable plugged in, and ONBOOT=yes, the network service will block waiting until the DHCP timeout. In general, you want connections to come up as they become available. > > - it informs applications that you're connected to the network (say, you > > unplug the network, the router dies, or the driver for your network card > > drops you off the network) > > I can see this being handy in some cases, but mostly, the network status of > statically-configured machines is generally best monitored externally. > > > - and finally, it will allow routing over multiple connections in the > > future (so static wired, and wireless routed over the wired, or all the > > wired routed over a WWAN in case your internet connection breaks). > > This can be done already with static configuration, but if it makes an > auto-fallback easy to configure that does seem like a plus -- but very > special purpose. > > > C'mon, seriously, is that all you've got? :) > > The real major plus I see is: "It's good for the desktop, so doing it on > servers means it all works the same." But that's kind of a hard sell -- and > since in many cases I end up the one _making_ the sell, I'd like something > more to work with. Many of the features of NetworkManager do make life easier on desktops and aren't as useful on a server machine. So if you're just interested in servers, the story shouldn't be any different with NM than with the 'network' service, except that NM provides a single source for information about the network that programs can query. If you're using a single ethernet adapter, statically configured, without a desktop, and only running say httpd and samba, then no, you probably don't want to use NM. You certainly _could_ if you wanted to. If we're talking about GUIs, or more mobile machines like laptops or mobile internet devices, or desktops in general, or multi-user systems where finer-grained control of network devices is desired, then I can list more advantages of NetworkManager. Dan From a.badger at gmail.com Thu May 22 16:10:55 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 22 May 2008 09:10:55 -0700 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> <1211405127.21380.382.camel@pmac.infradead.org> <4834D3F2.90409@gmail.com> Message-ID: <48359B0F.2070605@gmail.com> Alexandre Oliva wrote: > On May 21, 2008, Toshio Kuratomi wrote: >> There's free software as in legally licensed for us to use distribute >> and modify and there's free software as in four freedoms free. Unless >> I've missed something, the firmware in the kernel is licensed under >> the GPLv2 and therefore it is legally licensed for us to use, >> distribute, and modify. > > I'm sorry to be the bearer of bad news, but you did indeed miss > something. > > Have a look at the license for drivers/net/tokenring/3c359_microcode.h > > 2 /* > 3 * The firmware this driver downloads into the tokenring card is a > 4 * separate program and is not GPL'd source code, even though the Linux > 5 * side driver and the routine that loads this data into the card are. > 6 * > 7 * This firmware is licensed to you strictly for use in conjunction > 8 * with the use of 3Com 3C359 TokenRing adapters. There is no > 9 * waranty expressed or implied about its fitness for any purpose. > 10 */ > > This is just one out of some 30 examples of such licenses in the > kernel. And, heck, this one doesn't even grant permission for > redistribution. What are those Linux-no-libre guys thinking? > Thanks! The Packaging Committee and kernel maintainers will have to look into what's going on here. Although that doesn't address your larger issue of binary firmware. -Toshio From dcbw at redhat.com Thu May 22 16:13:20 2008 From: dcbw at redhat.com (Dan Williams) Date: Thu, 22 May 2008 12:13:20 -0400 Subject: NetworkManager: I want to believe, but... [was Re: F9 potential service network bug?] In-Reply-To: <20080522142009.GA8728@jadzia.bu.edu> References: <3da3b5b40805161502w62f372dseca0ab6310e44447@mail.gmail.com> <1210975852.6805.10.camel@localhost.localdomain> <3da3b5b40805161522i2300f1cdhb1fc7b074084873f@mail.gmail.com> <604aa7910805161527j6b193c6dj2af4248155d5cdaf@mail.gmail.com> <20080517112856.GA18698@jadzia.bu.edu> <1211024075.4060.50.camel@localhost.localdomain> <20080522142009.GA8728@jadzia.bu.edu> Message-ID: <1211472800.5352.31.camel@localhost.localdomain> On Thu, 2008-05-22 at 10:20 -0400, Matthew Miller wrote: > On Sat, May 17, 2008 at 07:34:35AM -0400, Jesse Keating wrote: > > Please post your ifconfig files as they came from the installer when > > things weren't working. > > I've messed around with it enough that I can't get the original behavior > back without reinstalling. And I had a few days unexpectedly offline, during > which it looks like some problems have been pinpointed, yeah? Would it still > be helpful for me to recreate? Yes, the problem with the netinstall has been pinpointed and fixed in: https://admin.fedoraproject.org/updates/F9/pending/NetworkManager-0.7.0-0.9.3.svn3675.fc9 http://koji.fedoraproject.org/koji/buildinfo?buildID=49712 What was your /etc/sysconfig/network file? Dan From notting at redhat.com Thu May 22 16:21:38 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 22 May 2008 12:21:38 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <48356905.2090805@draigBrady.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <48356905.2090805@draigBrady.com> Message-ID: <20080522162138.GD8819@nostromo.devel.redhat.com> P?draig Brady (P at draigBrady.com) said: > Jupiter > > Sulphur has atomic number 16 > Jupiter has 16 moons That's not really direct enough of a link. Bill From jspaleta at gmail.com Thu May 22 16:26:02 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 22 May 2008 08:26:02 -0800 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080522162138.GD8819@nostromo.devel.redhat.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <48356905.2090805@draigBrady.com> <20080522162138.GD8819@nostromo.devel.redhat.com> Message-ID: <604aa7910805220926o2738942bo3e7e5bad35828107@mail.gmail.com> On Thu, May 22, 2008 at 8:21 AM, Bill Nottingham wrote: > P?draig Brady (P at draigBrady.com) said: >> Jupiter >> >> Sulphur has atomic number 16 >> Jupiter has 16 moons > > That's not really direct enough of a link. In the classical bohr model of the atom.. Sulphor has 16 circling moon-like electrons! -jef From ajax at redhat.com Thu May 22 16:36:39 2008 From: ajax at redhat.com (Adam Jackson) Date: Thu, 22 May 2008 12:36:39 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080522065724.1788e577@vader.jdub.homelinux.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> Message-ID: <1211474199.29467.204.camel@localhost.localdomain> On Thu, 2008-05-22 at 06:57 -0500, Josh Boyer wrote: > Let the naming begin! We're starting very early this time around in > the name game for F10. So, let the suggestions flow! British variants of American noun spellings: spectre, camomile, draught, gaol, demagogue (marginal, demagog is rare in the US too), saltpetre (double points for both being components of gunpowder). Towns in Clarke County, Indiana: Whiskey Run. County seats in Oklahoma: Ada, Kingfisher. Mountains in Alberta: Babel, Diadem, The Finger, Gong. Finally, if we insist on using other element names, I propose the narrower class of "elements with many allotropes", in which case phosphorus is probably the next best candidate. Ada and Saltpetre definitely fit with the steampunk art theme. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From steve.dowe at onecool.com Thu May 22 16:34:41 2008 From: steve.dowe at onecool.com (Steve Dowe) Date: Thu, 22 May 2008 17:34:41 +0100 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <6B7C453DE0834ED29C89C86EEB6E6A14@internal.onecool.com> References: <6B7C453DE0834ED29C89C86EEB6E6A14@internal.onecool.com> Message-ID: <4835A0A1.9010602@onecool.com> Josh Boyer wrote: > Let the naming begin! We're starting very early this time around in > the name game for F10. So, let the suggestions flow! > > Remember the rules: > > 1) must have some link to Sulphur > > More specifically, the link should be > Sulphur is a and > is a > Where is the same for both > > 2) The link between and Sulphur cannot be the same as between > Werewolf and Sulphur. That link was "things that react badly with > silver". This might be a bit "random", but how about Mississippi? The reason is that Sulphur is a location along Interstate 10 in Louisiana, US. So is Mississippi. The development process of open source software is much like a river, with new life (i.e. effort - patches, code, bug fixes, etc) travelling upstream and the results of that effort travelling back downstream. That Interstate "10" matches Fedora release version 10 is purely co-incidental, of course... Just my two cents' worth. :) From billcrawford1970 at gmail.com Thu May 22 16:43:39 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Thu, 22 May 2008 17:43:39 +0100 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1211474199.29467.204.camel@localhost.localdomain> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211474199.29467.204.camel@localhost.localdomain> Message-ID: <544eb990805220943i4311e61bg58517a76695980e@mail.gmail.com> 2008/5/22 Adam Jackson : > County seats in Oklahoma: Ada, Kingfisher. > Ada and Saltpetre definitely fit with the steampunk art theme. We already had a "Fisher" back in the day so I think we should avoid Kingfisher. But and Lovelace reference would be good. Nitre would be even better (pun on nitrous oxide, which is used to make cars etc gp faster) as a precursor to black powder. From stickster at gmail.com Thu May 22 16:44:06 2008 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 22 May 2008 12:44:06 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <48359955.6000109@onecool.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <48358677.2040807@hi.is> <3E241CC6FB3A4A498507355A8E917197@internal.onecool.com> <48359955.6000109@onecool.com> Message-ID: <1211474646.4891.72.camel@victoria> On Thu, 2008-05-22 at 17:03 +0100, Steve Dowe wrote: > Josh Boyer wrote: > > On Thu, 22 May 2008 14:43:03 +0000 > > "J?hann B. Gu?mundsson" wrote: > > > >> Konstantin Ryabitsev wrote: > >>> On Thu, May 22, 2008 at 7:57 AM, Josh Boyer wrote: > >>> > >>> Sulphur is an ingredient used to make chemicals. > >>> Element X is an ingredient used to make Powerpuff Girls. > >>> > >>> Thus, we should have Fedora X 10. ;) > >>> > >>> Cheers, > >>> > >> +1 > >> > >> Fedora X.. > >> X marks the spot... > > > > I'm fairly certain this would be denied due to the other operating > > system that calls itself "OSX". > > I'm pretty sure you cannot trademark a Roman Numeral. I'm absolutely certain that we don't want to look like copycats. :-) -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From stickster at gmail.com Thu May 22 16:47:17 2008 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 22 May 2008 16:47:17 +0000 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <604aa7910805220827y453b482dl8fd68d5b174f61dd@mail.gmail.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211462088.4891.45.camel@victoria> <604aa7910805220827y453b482dl8fd68d5b174f61dd@mail.gmail.com> Message-ID: <1211474837.4891.76.camel@victoria> On Thu, 2008-05-22 at 07:27 -0800, Jeff Spaleta wrote: > 2008/5/22 Paul W. Frields : > > "Neon," which also happens to be the element 10 in the periodic table. > > Okay smart guy, how you would move out from Neon to "Ours goes to" > > So is there money in the budget for a neon sign that reads "Fedora" > to display at to events? For example FUDCon Fairbanks? Hey, I didn't say that was going to be my only contribution to the name process! :-D I do think we really, REALLY need to find something that can link to some form of "Goes To." If someone could link Sulphur with Spinal Tap or a heavy metal cliche, that would work. Or if they can get us to a link from Sulphur to the title of a New Wave punk/rock album, that would work too. (XTC had "Go 2" in 1970-something -- 1977, maybe?) -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-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 Thu May 22 16:47:05 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 22 May 2008 11:47:05 -0500 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1211462088.4891.45.camel@victoria> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211462088.4891.45.camel@victoria> Message-ID: <16de708d0805220947i37e96c82jf1240b86384822fb@mail.gmail.com> 2008/5/22 Paul W. Frields : > On Thu, 2008-05-22 at 06:57 -0500, Josh Boyer wrote: >> Let the naming begin! We're starting very early this time around in >> the name game for F10. So, let the suggestions flow! >> >> Remember the rules: >> >> 1) must have some link to Sulphur >> >> More specifically, the link should be >> Sulphur is a and >> is a >> Where is the same for both > > "Neon," which also happens to be the element 10 in the periodic table. +1 for Neon, the graphical possibilities seem promising: http://commons.wikimedia.org/wiki/Image:Electron_shell_010_Neon.svg -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From alan at redhat.com Thu May 22 16:47:42 2008 From: alan at redhat.com (Alan Cox) Date: Thu, 22 May 2008 12:47:42 -0400 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> <1211405127.21380.382.camel@pmac.infradead.org> <4834D3F2.90409@gmail.com> Message-ID: <20080522164742.GD8443@devserv.devel.redhat.com> On Thu, May 22, 2008 at 02:18:22AM -0300, Alexandre Oliva wrote: > kernel. And, heck, this one doesn't even grant permission for > redistribution. What are those Linux-no-libre guys thinking? Well we were thinking (and much legal advice seems to agree) that the firmware is a separate work. Like your BIOS for example. We had been gradually moving firmware to user space via request_firmware until various free software extremists made such idiots of themselves on the kernel list a couple of years ago everyone stopped because they were so p***ed off with them. From billcrawford1970 at gmail.com Thu May 22 16:48:18 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Thu, 22 May 2008 17:48:18 +0100 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <4835A0A1.9010602@onecool.com> References: <6B7C453DE0834ED29C89C86EEB6E6A14@internal.onecool.com> <4835A0A1.9010602@onecool.com> Message-ID: <544eb990805220948q58464674m6be63bc6c43d1581@mail.gmail.com> 2008/5/22 Steve Dowe : > The reason is that Sulphur is a location along Interstate 10 in Louisiana, > US. So is Mississippi. Lafayette would leave many many opportunities for the next connection, but I'm sure it's been used elsewhere for something OS-related. Can't put my finger on it ... From billcrawford1970 at gmail.com Thu May 22 16:50:26 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Thu, 22 May 2008 17:50:26 +0100 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <544eb990805220948q58464674m6be63bc6c43d1581@mail.gmail.com> References: <6B7C453DE0834ED29C89C86EEB6E6A14@internal.onecool.com> <4835A0A1.9010602@onecool.com> <544eb990805220948q58464674m6be63bc6c43d1581@mail.gmail.com> Message-ID: <544eb990805220950h2296fb88i57e7b15b7a092b4c@mail.gmail.com> 2008/5/22 Bill Crawford : > 2008/5/22 Steve Dowe : > >> The reason is that Sulphur is a location along Interstate 10 in Louisiana, >> US. So is Mississippi. > > Lafayette would leave many many opportunities for the next connection, > but I'm sure it's been used elsewhere for something OS-related. Can't > put my finger on it ... > Ah yes: http://www.purdueexponent.org/interface/bebop/showstory.php?date=2003/09/23§ion=features From chris.stone at gmail.com Thu May 22 17:04:21 2008 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 22 May 2008 10:04:21 -0700 Subject: HEADS-UP: New pygame 1.8.0 in rawhide Message-ID: # repoquery --whatrequires pygame childsplay-0:0.90.2-1.fc9.noarch PySolFC-music-0:4.40-3.noarch pygame-devel-0:1.7.1-16.fc9.i386 bubbros-0:1.6-1.fc8.drb.x86_64 angrydd-0:1.0.1-3.fc8.noarch poker2d-0:1.5.0-1.fc9.x86_64 pygame-devel-0:1.7.1-16.fc9.x86_64 monsterz-0:0.7.1-3.fc9.x86_64 keyjnote-0:0.10.2-1.fc9.noarch python-kaa-imlib2-0:0.2.3-2.fc9.x86_64 magicor-0:1.1-0.1.rc1.fc9.noarch seahorse-adventures-0:1.0-2.fc8.noarch slingshot-0:0.8.1p-1.fc8.noarch solarwolf-0:1.5-2.fc8.noarch poker2d-0:1.4.0-1.fc9.x86_64 Enjoy! From notting at redhat.com Thu May 22 17:07:18 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 22 May 2008 13:07:18 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080522065724.1788e577@vader.jdub.homelinux.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> Message-ID: <20080522170718.GE8819@nostromo.devel.redhat.com> Josh Boyer (jwboyer at gmail.com) said: > I will be collecting suggestions for 1 week, so the cutoff for names is: > > May 29, 2008 OK, so things Sulphur is: - an element (already covered) - 'Sulfur' is a defunct magazine. Other defunct magazines include: Talk Premiere Sassy Red Hat Linux If you stretch it to include just 'magazines', the list obviously gets larger. - a town in Indiana, or Louisiana, or Oklahoma Gary Eureka Leavenworth (oh, the places to go from there) Marysville Kurtz (the horror, the horror!) Petroleum Popcorn Scipio Cherokee/Choctaw/many other Native American tribes Milton Tallulah Transylvania Eastwood Hickory Waterloo Vatican Independence White Castle - a river (in Texas and Arkansas, fwiw) Orinoco Amazon Sabine Styx Tam (just kidding) Yukon Ob Snake de la Plata Jordan Severn (whoops) - a mountain Everest Kilimanjaro Stanley Erebus Terror Matterhorn (leading to... Fedora 11: Pirates of the Caribbean!) Etna Ranier Majestic Ulysses Man'O'War Thor Diablo Olympus Archimedes OK, I'll stop now. We probably don't need to submit *all* of these. Bill From aoliva at redhat.com Thu May 22 17:08:12 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Thu, 22 May 2008 14:08:12 -0300 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: <20080522162729.1c8298da@ludwig-alpha.unil.ch> (Christian Iseli's message of "Thu\, 22 May 2008 16\:27\:29 +0200") References: <1211377739.4210.2.camel@truman> <1211410870.2290.5.camel@kennedy> <20080522162729.1c8298da@ludwig-alpha.unil.ch> Message-ID: On May 22, 2008, Christian Iseli wrote: > As far as I understand, nobody has a GPL'd version of those > processors, AFAICT, you're one of those who believe that "Free Software" means "GPL". No, sir. GPL is just the most common out of the very many Free Software licenses that exist. I'm not going for GPL. I'm going for "respect for the 4 freedoms", as per the Free Software Definition. Bringing the GPL into the debate is completely misplaced. Your other mistake is to assume that this has anything to do with what users had on their computers before installing Fedora, or whatever they choose to install after installing Fedora, for that matter. It doesn't. It's about what *we* distribute under the label Fedora. Nothing but it. IOW, any attempts to point at other sources of problems are just distractions, because we don't distribute these other sources of problems. I don't object to our enabling people to live with them, as long as we don't participate in the process of distributing them, because is not just neutral to our mission, it's detrimental to it. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From johannbg at hi.is Thu May 22 17:09:58 2008 From: johannbg at hi.is (=?windows-1252?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Thu, 22 May 2008 17:09:58 +0000 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080522065724.1788e577@vader.jdub.homelinux.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> Message-ID: <4835A8E6.9070402@hi.is> Josh Boyer wrote: > Let the naming begin! We're starting very early this time around in > the name game for F10. So, let the suggestions flow! > > Remember the rules: > > 1) must have some link to Sulphur > > More specifically, the link should be > Sulphur is a and > is a > Where is the same for both > > 2) The link between and Sulphur cannot be the same as between > Werewolf and Sulphur. That link was "things that react badly with > silver". > > I will be collecting suggestions for 1 week, so the cutoff for names is: > > May 29, 2008 > > Suggestions will be run through the legal queue and an election will > happen for Fedora contributors to pick the next Fedora name. > > josh > > Sulphur ice .. Ice ... /Fedora Ice ... Cant you feel the breeze .... _* *_/ "The craters never get above ?200?C, and radar observations from Earth suggest they could be filled with water ice. A gamma-ray and neutron spectrometer will study the craters to determine if the source is water ice, sulphur ice, <-- or just super-chilled rock." ( http://www.newscientist.com/article/dn6171-spacecraft-set-to-probe-mercurys-mysteries.html ) JB. -------------- next part -------------- A non-text attachment was scrubbed... Name: johannbg.vcf Type: text/x-vcard Size: 365 bytes Desc: not available URL: From limb at jcomserv.net Thu May 22 17:09:59 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 22 May 2008 12:09:59 -0500 (CDT) Subject: HEADS-UP: New pygame 1.8.0 in rawhide In-Reply-To: References: Message-ID: <45021.198.175.55.5.1211476199.squirrel@mail.jcomserv.net> > # repoquery --whatrequires pygame > childsplay-0:0.90.2-1.fc9.noarch > PySolFC-music-0:4.40-3.noarch > pygame-devel-0:1.7.1-16.fc9.i386 > bubbros-0:1.6-1.fc8.drb.x86_64 > angrydd-0:1.0.1-3.fc8.noarch > poker2d-0:1.5.0-1.fc9.x86_64 > pygame-devel-0:1.7.1-16.fc9.x86_64 > monsterz-0:0.7.1-3.fc9.x86_64 > keyjnote-0:0.10.2-1.fc9.noarch > python-kaa-imlib2-0:0.2.3-2.fc9.x86_64 > magicor-0:1.1-0.1.rc1.fc9.noarch > seahorse-adventures-0:1.0-2.fc8.noarch > slingshot-0:0.8.1p-1.fc8.noarch > solarwolf-0:1.5-2.fc8.noarch > poker2d-0:1.4.0-1.fc9.x86_64 Will this necessitate a rebuild? > Enjoy! > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From thomas at apestaart.org Thu May 22 17:00:40 2008 From: thomas at apestaart.org (thomas at apestaart.org) Date: Thu, 22 May 2008 19:00:40 +0200 Subject: RELEASE: Mach 0.9.3 'Niger' Message-ID: <200805221700.m4MH0eDb014293@otto.amantes> This mail announces the release of Mach 0.9.3 'Niger'. mach allows you to set up clean roots from scratch for any distribution or distribution variation supported. Currently, this is limited to RPM-based distributions. This clean build root can be used for making clean packages, running jailed services, testing builds, or making disk images of clean roots. For more information, see http://thomas.apestaart.org/projects/mach/ To file bugs, go to https://apestaart.org/thomas/trac/newticket -------------- next part -------------- mach - make a chroot - RELEASE NOTES ------------------------------------ Announcing the release of mach 0.9.3 - Niger. WHAT IS IT ---------- mach allows you to set up clean roots from scratch for any distribution or distribution variation supported. This clean build root can be used to run jailed services, create disk images, or build clean packages. mach can currently set up roots for the following distributions: - Fedora 7, 8, 9 (Fedora, Everything, updated, rpm.livna.org, devel JPackage, FreshRPMS, GStreamer) - Fedora 4, 5, 6 (core, updated, extras, rpm.livna.org, JPackage, FreshRPMS, GStreamer) - Fedora 1, 2, 3 (core, updated, www.fedora.us, rpm.livna.org, JPackage, FreshRPMS, GStreamer) - Red Hat 8.0, 9 (basic, updated, www.fedora.us, rpm.livna.org, JPackage, GStreamer, FreshRPMS) - Red Hat 7.2, 7.3 (basic, updated, FreshRPMS, JPackage) - Red Hat 7.0, 7.1 (basic, updated, FreshRPMS) - CentOS 4, 5 - SuSE 8.1/8.2/9 - Yellowdog Linux 3.0 (basic, updated, FreshRPMS) - Yellowdog Linux 2.3 (basic, updated, FreshRPMS) - Dave/Dina 0.0/oven/fridge Read the README included in the distribution for a better overview. CHANGES ------- - Add F8 and F9 repositories and reorganize repositories (Thomas, Ville) - Default to CentOS configs when built on RHEL (Ville) - Remove Connectiva 9 (Ville) WHY WOULD YOU USE IT -------------------- mach is helpful: - to create minimal chroot environments to jail services in - to create clean packages for distributions - to catch spec file mistakes, missing buildrequires, and more INFORMATION ----------- mach's homepage is at http://thomas.apestaart.org/projects/mach/ mach is hosted on SourceForge; the project page is http://www.sourceforge.net/projects/mach/ There is a mailing list for development and use of mach. See http://lists.sourceforge.net/lists/listinfo/mach-devel QUICKSTART ---------- a) On a Fedora 4 Core system, install the mach rpm from http://thomas.apestaart.org/download/mach b) su - mach c) mach setup base d) mach chroot poke around a bit in the fresh root e) exit f) mach rebuild http://ayo.freshrpms.net/fedora/linux/4/i386/SRPMS.core/vorbis-tools-1.0.1-6.src.rpm If all goes well, you'll get a nice freshly built vorbis-tools package. Now go out, experiment and bug report ! MAILING LIST ------------ A mailing list has been set up for discussion of mach use and development. Check http://lists.sourceforge.net/lists/listinfo/mach-devel for information. The list is low-volume. BUGS ---- To file bugs, go to https://apestaart.org/thomas/trac Always state what platform you are running on, if it's a clean install or somehow updated, how I can reproduce the bug, and output of a run of the failed command with -d (debugging). CONTRIBUTORS ------------ Contributors to releases include - Thomas Vander Stichele - Ville Skytt?? - Jeff Pitman - Rudi Chiarito - Matthias Saou - Nigel Metheringham - Jan Schmidt From aoliva at redhat.com Thu May 22 17:13:08 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Thu, 22 May 2008 14:13:08 -0300 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: <1211467361.21380.448.camel@pmac.infradead.org> (David Woodhouse's message of "Thu\, 22 May 2008 15\:42\:41 +0100") References: <1211377739.4210.2.camel@truman> <1211410870.2290.5.camel@kennedy> <20080522162729.1c8298da@ludwig-alpha.unil.ch> <1211467361.21380.448.camel@pmac.infradead.org> Message-ID: On May 22, 2008, David Woodhouse wrote: > On Thu, 2008-05-22 at 16:27 +0200, Christian Iseli wrote: >> /me rambles a bit... >> >> Unless I'm mistaken, I assume such a libre system will run on ix86 and >> x86_64 machines. > I assume Alex won't be including an interpreter for closed-source ACPI > bytecode in his kernel. Is this an intentional strawman, or do you really not get the point? Why wouldn't I? There's nothing offensive or immoral about the interpreter, AFAIK. What is offensive and immoral is the imposition of restrictions on the bytecode that enables one's machine to work. But the interpreter itself can't tell whether it's offensive or immoral, since it doesn't have brains to understand technical and legal restrictions that the bytecode itself or its corresponding source code might be subject to. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From chris.stone at gmail.com Thu May 22 17:16:35 2008 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 22 May 2008 10:16:35 -0700 Subject: HEADS-UP: New pygame 1.8.0 in rawhide In-Reply-To: <45021.198.175.55.5.1211476199.squirrel@mail.jcomserv.net> References: <45021.198.175.55.5.1211476199.squirrel@mail.jcomserv.net> Message-ID: On Thu, May 22, 2008 at 10:09 AM, Jon Ciesla wrote: > Will this necessitate a rebuild? If your app uses files in /usr/include/python2.5/pygame then I would say yes, otherwise AFAIK those python modules are loaded at runtime. You should test you game to make sure it works though. From jdy at cs.brown.edu Thu May 22 17:16:45 2008 From: jdy at cs.brown.edu (Joel) Date: Thu, 22 May 2008 17:16:45 +0000 (UTC) Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211462088.4891.45.camel@victoria> <48357E29.2010609@nobugconsulting.ro> <1211466316.5079.61.camel@localhost.localdomain> <1211466224.3559.48.camel@cutter> <1211467352.5079.65.camel@localhost.localdomain> <483587E7.2020300@nobugconsulting.ro> Message-ID: Manuel Wolfshant nobugconsulting.ro> writes: > Jesse Keating wrote: >> And that feels way too generic, like "fred" is a word in the dictionary, >> "alphanumeric" is a word in the dictionary. It's not trying hard enough > I'd argument that the link Fedora 10 < --> 10th element in the periodic > table is worth it. That's why I liked it so much. Furthermore, 10 is how you write 16 in hex... JOel From billcrawford1970 at gmail.com Thu May 22 17:18:24 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Thu, 22 May 2008 18:18:24 +0100 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080522170718.GE8819@nostromo.devel.redhat.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <20080522170718.GE8819@nostromo.devel.redhat.com> Message-ID: <544eb990805221018h2a263e00y82eed56b43a698d4@mail.gmail.com> 2008/5/22 Bill Nottingham : > Independence You should rush to release Fedora X (Independence) on July 4th. It may well be US-centric, but it's pretty widely known :o) > White Castle Say, didn't we pass a ... From katzj at redhat.com Thu May 22 17:17:35 2008 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 22 May 2008 13:17:35 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080522170718.GE8819@nostromo.devel.redhat.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <20080522170718.GE8819@nostromo.devel.redhat.com> Message-ID: <1211476655.16123.7.camel@aglarond.local> On Thu, 2008-05-22 at 13:07 -0400, Bill Nottingham wrote: > - a town in Indiana, or Louisiana, or Oklahoma This also lets us get to Cambridge. Which is all kinds of fun :-) Jeremy From cmadams at hiwaay.net Thu May 22 17:24:59 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 22 May 2008 12:24:59 -0500 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1211476655.16123.7.camel@aglarond.local> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <20080522170718.GE8819@nostromo.devel.redhat.com> <1211476655.16123.7.camel@aglarond.local> Message-ID: <20080522172459.GE1072817@hiwaay.net> Once upon a time, Jeremy Katz said: > On Thu, 2008-05-22 at 13:07 -0400, Bill Nottingham wrote: > > - a town in Indiana, or Louisiana, or Oklahoma > > This also lets us get to Cambridge. Which is all kinds of fun :-) Wasn't there already a Cambridge (and a Eureka for that matter)? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From angray at beeb.net Thu May 22 17:36:56 2008 From: angray at beeb.net (Aaron Gray) Date: Thu, 22 May 2008 18:36:56 +0100 Subject: [F9][rawhide][regression] controllers DAC960 and sym53c8xx arenot detected anymore References: <006101c8bb67$fd36c5f0$0200a8c0@ze4427wm> Message-ID: <006401c8bc32$6ed1a980$0200a8c0@ze4427wm> > Please file this in bugzilla (https://bugzilla.redhat.com) I have found a simular bug in bugzilla :- https://bugzilla.redhat.com/show_bug.cgi?id=447552 Aaron > Thanks! > -Jon > > 2008/5/21 Aaron Gray : >> Fedora 9 and rawhide are not detecting Mylex DAC960 and LSI Corp. >> sym53c8xx >> SCSI controllers. These devices are detected and run fine on FC 6, 7 and >> 8. >> >> Attached are :- >> >> - dmesg >> - lspci >> - cat /proc/interrupts >> >> from FC8 installation. >> >> Thanks, >> >> Aaron >> >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list >> > > > > -- > Jon Stanley > Fedora Bug Wrangler > jstanley at fedoraproject.org > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > -- > No virus found in this incoming message. > Checked by AVG. > Version: 7.5.524 / Virus Database: 269.23.21/1458 - Release Date: > 21/05/2008 07:21 > > From billcrawford1970 at gmail.com Thu May 22 17:37:45 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Thu, 22 May 2008 18:37:45 +0100 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080522172459.GE1072817@hiwaay.net> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <20080522170718.GE8819@nostromo.devel.redhat.com> <1211476655.16123.7.camel@aglarond.local> <20080522172459.GE1072817@hiwaay.net> Message-ID: <544eb990805221037r63fe8d23i2c120899885afb19@mail.gmail.com> 2008/5/22 Chris Adams : > Wasn't there already a Cambridge (and a Eureka for that matter)? Internal code name for RH 8, wasn't it? Or what became 7.3 perhaps. From gjalves at gjalves.com.br Thu May 22 17:45:41 2008 From: gjalves at gjalves.com.br (Gustavo Alves) Date: Thu, 22 May 2008 14:45:41 -0300 Subject: Problem with intel i810 driver Message-ID: <69e11d1f0805221045r772ac4eu128e564e4f9b095f@mail.gmail.com> Hi All, When I use "intel" driver, xorg give me the following errors: (EE) Failed to load module "intelmaster" (module does not exist, 0) (EE) Failed to load module "intelbatchbuffer" (module does not exist, 0) The original name on up-to-date intel driver is intel_master and intel_batchbuffer. How I should proceed? Renaming modules from intelbatchbuffer to intel_batchbuffer or change the references for it to intel_batchbuffer? Thanks. -- Gustavo Junior Alves GJAlves Tecnologia Tel: +55 19 9223-0500 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwmw2 at infradead.org Thu May 22 17:48:14 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 22 May 2008 18:48:14 +0100 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: <20080522164742.GD8443@devserv.devel.redhat.com> References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> <1211405127.21380.382.camel@pmac.infradead.org> <4834D3F2.90409@gmail.com> <20080522164742.GD8443@devserv.devel.redhat.com> Message-ID: <1211478494.21380.459.camel@pmac.infradead.org> On Thu, 2008-05-22 at 12:47 -0400, Alan Cox wrote: > On Thu, May 22, 2008 at 02:18:22AM -0300, Alexandre Oliva wrote: > > kernel. And, heck, this one doesn't even grant permission for > > redistribution. What are those Linux-no-libre guys thinking? > > Well we were thinking (and much legal advice seems to agree) that the firmware > is a separate work. Like your BIOS for example. Being a separate work doesn't save it from the requirements of the GPL. The GPL clearly states that under some circumstances it _does_ extend to sections which are independent and separate works in themselves. And it seems fairly clear to me that those circumstances include the firmware blobs included in the Linux kernel tarball. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. (OK, that's the firmware). But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. (as is that). -- dwmw2 From ianweller at gmail.com Thu May 22 17:50:22 2008 From: ianweller at gmail.com (Ian Weller) Date: Thu, 22 May 2008 12:50:22 -0500 (CDT) Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <604aa7910805220926o2738942bo3e7e5bad35828107@mail.gmail.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <48356905.2090805@draigBrady.com> <20080522162138.GD8819@nostromo.devel.redhat.com> <604aa7910805220926o2738942bo3e7e5bad35828107@mail.gmail.com> Message-ID: On Thu, 22 May 2008, Jeff Spaleta wrote: > On Thu, May 22, 2008 at 8:21 AM, Bill Nottingham wrote: >> P?draig Brady (P at draigBrady.com) said: >>> Jupiter >>> >>> Sulphur has atomic number 16 >>> Jupiter has 16 moons >> >> That's not really direct enough of a link. > > In the classical bohr model of the atom.. Sulphor has 16 circling > moon-like electrons! > This made me fall out of my chair laughing. -- ian From lordmorgul at gmail.com Thu May 22 17:52:58 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Thu, 22 May 2008 10:52:58 -0700 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <1218b5bc0805201846v19edd85n3be4b48e3c519428@mail.gmail.com> <1211335226.3768.1.camel@clockmaker.usersys.redhat.com> <20080520211137.67744ac3@vader.jdub.homelinux.org> <1211379900.29467.136.camel@localhost.localdomain> <20080521152022.GF1093879@hiwaay.net> Message-ID: <4835B2FA.1090803@gmail.com> Christopher Stone wrote: > On Wed, May 21, 2008 at 8:20 AM, Chris Adams wrote: >> If it is so easy, why don't you do it in your own repo? Fedora is a >> fully open distribution; all the necessary tools are there. > > Should I make an assumption that you mean to say rpm is not a > "regular" tool. Sure, you would have to add some documentation on how > to install it by first uninstalling X. It's not so much compatibility > and support, but more a matter of convenience. You have yet to explain how doing this effort, rebuilding the f8 xorg and hosting it in updates-testing for f9... is going to change IN ANY WAY the method you must follow for downgrading Xorg on F9. The version numbers are still going to be lower than the F9 xorg unless you deliberately break everything sane about rpm versioning in order to force them to upgrade. Insisting that those rpms need rebuilt and specifically hosted for f9 is stupidity. Downgrading xorg using the current F8 rpms works just fine. It takes exactly the same effort as attempting to downgrade xorg using rpms with a silly .fc9 in their name. You download rpms, you install them, you prevent them from getting updated by f9 rpms. -- Andrew Farris www.lordmorgul.net gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29 From aoliva at redhat.com Thu May 22 17:53:41 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Thu, 22 May 2008 14:53:41 -0300 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: <20080522070635.092b067a@vader.jdub.homelinux.org> (Josh Boyer's message of "Thu\, 22 May 2008 07\:06\:35 -0500") References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> <20080521184047.7b19e70b@vader.jdub.homelinux.org> <20080521204148.66eff81f@vader.jdub.homelinux.org> <20080522070635.092b067a@vader.jdub.homelinux.org> Message-ID: On May 22, 2008, Josh Boyer wrote: > On Thu, 22 May 2008 01:58:25 -0300 > Alexandre Oliva wrote: >> > Can you point me to where you've approached the upstream kernel >> > maintainers about this? >> >> I haven't. I'm told others have, and have been ridiculed. From what >> I gather from the LKML archives and personal experiences there, I have >> no reason to disbelieve them. > Ok, but you said you had facts. Now you're telling me you only have > hearsay? As in, what's in the archives, including my personal experiences on LKML, are hearsay? I don't think so. >> Because upstream doesn't want to achieve this goal, and actively >> refuses to accept changes essential to get there. > Pointers to this would be nice. Mailing list archives, IRC > conversations, anything. I don't have any such pointers handy, save for the related discussions that you'll find with a web search for "LKML remove firmware or blob". >> > If those patches get integrated, then wouldn't the parts you find >> > objectionable be gone? >> Not all of them, no. > ? Sorry. I was so much in a mindset of "there's no way upstream is going to accept this" that I focused only on the second half of your question, completely missing the antecedent that conflicted with my mindset and that would have made the answer 'yes'. So, I take back the above. Given the antecedent, the answer would be 'yes'. I just don't see that happening. I guess it may be worth a shot, though. >> > I certainly didn't think you intended to _replace_ the main kernel >> > package. But I don't agree with even providing a completely different >> > alternative "kernel-libre" package. If it can't be built as a flavor >> > of the existing kernel package, then I don't see it being approved for >> > inclusion. >> So much for http://www.linux-books.us/fedora_core_0001.php > So much for having a productive conversation. You're avoiding my point > (or think it's entirely hopeless) and spewing rhetoric again. I thought the acceptance of all patches upstream was entirely hopeless. However, DWMW2's suggestion today might work, although I still don't quite understand its details. I wasn't trying to avoid your point. My response was an allusion to what I perceive as an inconsistency between Fedora's long-ago stated goal (build an entire operating system out of free and open source software) and the preference for following an upstream that (through their actions) oppose this goal, rather than giving precedence to the stated goal and switching to another upstream that is compatible with the goal. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From ianweller at gmail.com Thu May 22 17:53:30 2008 From: ianweller at gmail.com (Ian Weller) Date: Thu, 22 May 2008 12:53:30 -0500 (CDT) Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1211469300.5079.67.camel@localhost.localdomain> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211462088.4891.45.camel@victoria> <48357E29.2010609@nobugconsulting.ro> <1211466316.5079.61.camel@localhost.localdomain> <1211466224.3559.48.camel@cutter> <1211467352.5079.65.camel@localhost.localdomain> <1211467926.3559.51.camel@cutter> <1211469300.5079.67.camel@localhost.localdomain> Message-ID: On Thu, 22 May 2008, Jesse Keating wrote: > On Thu, 2008-05-22 at 10:52 -0400, seth vidal wrote: >> there are only 118. (so far) > > Still, I bet you could find a more creative way to link Sulphur and Neon > together without going for the obvious. > What you came up with at http://www.redhat.com/archives/fedora-devel-list/2008-May/msg01810.html would work for me. ;) -- ian From ianweller at gmail.com Thu May 22 17:56:54 2008 From: ianweller at gmail.com (Ian Weller) Date: Thu, 22 May 2008 12:56:54 -0500 (CDT) Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <48359955.6000109@onecool.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org><48358677.2040807@hi.is> <3E241CC6FB3A4A498507355A8E917197@internal.onecool.com> <48359955.6000109@onecool.com> Message-ID: On Thu, 22 May 2008, Steve Dowe wrote: > I'm pretty sure you cannot trademark a Roman Numeral. > If I were on {insert fruit company}'s legal team, I would disagree. -- ian From aoliva at redhat.com Thu May 22 18:00:42 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Thu, 22 May 2008 15:00:42 -0300 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: <48359B0F.2070605@gmail.com> (Toshio Kuratomi's message of "Thu\, 22 May 2008 09\:10\:55 -0700") References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> <1211405127.21380.382.camel@pmac.infradead.org> <4834D3F2.90409@gmail.com> <48359B0F.2070605@gmail.com> Message-ID: On May 22, 2008, Toshio Kuratomi wrote: > Thanks! The Packaging Committee and kernel maintainers will have to > look into what's going on here. Although that doesn't address your > larger issue of binary firmware. Indeed, it doesn't. I don't think there are very many of these firmwares that are licensed in such obnoxious terms. But it's certainly not the only example of this kind of problem. The nouveau-drm patches that we're adding ourselves contain relatively large chunks of "voodoo" [sic] code copied from non-Free drivers by means of mmio dumps, but no copyright notices or licensing associated specifically to those pieces of code. As much as I appreciate what these folks are doing, I'm not sure this approach is ethical, let alone legal. I don't know whether this has been run through legal, but if it hasn't, I suggest that it be. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From lordmorgul at gmail.com Thu May 22 18:00:11 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Thu, 22 May 2008 11:00:11 -0700 Subject: thank you for the laptop[ sleep alert In-Reply-To: <3da3b5b40805220007p6859121tea559d7ec9ffe810@mail.gmail.com> References: <95f1114b0805212357l755b7dd7s89fef87fb9a99762@mail.gmail.com> <3da3b5b40805220007p6859121tea559d7ec9ffe810@mail.gmail.com> Message-ID: <4835B4AB.3000704@gmail.com> Ahmed Kamal wrote: > I remember getting a similar message that was like "Some program is > preventing your laptop from hibernating". It was nice, but I was screaming, > could you please let me know *which* application was that! Not sure if you > guys got something similar That is almost certainly packagekit doing updates. -- Andrew Farris www.lordmorgul.net gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29 From jonstanley at gmail.com Thu May 22 18:13:14 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Thu, 22 May 2008 14:13:14 -0400 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: <1211478494.21380.459.camel@pmac.infradead.org> References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> <1211405127.21380.382.camel@pmac.infradead.org> <4834D3F2.90409@gmail.com> <20080522164742.GD8443@devserv.devel.redhat.com> <1211478494.21380.459.camel@pmac.infradead.org> Message-ID: On Thu, May 22, 2008 at 1:48 PM, David Woodhouse wrote: > On Thu, 2008-05-22 at 12:47 -0400, Alan Cox wrote: >> On Thu, May 22, 2008 at 02:18:22AM -0300, Alexandre Oliva wrote: >> > kernel. And, heck, this one doesn't even grant permission for >> > redistribution. What are those Linux-no-libre guys thinking? >> >> Well we were thinking (and much legal advice seems to agree) that the firmware >> is a separate work. Like your BIOS for example. > > Being a separate work doesn't save it from the requirements of the GPL. > > The GPL clearly states that under some circumstances it _does_ extend to > sections which are independent and separate works in themselves. > > And it seems fairly clear to me that those circumstances include the > firmware blobs included in the Linux kernel tarball. > > If identifiable sections of that work are not derived from the > Program, and can be reasonably considered independent and > separate works in themselves, then this License, and its terms, > do not apply to those sections when you distribute them as > separate works. > > (OK, that's the firmware). > > But when you distribute the same sections as part of a whole > which is a work based on the Program, the distribution of the > whole must be on the terms of this License, whose permissions > for other licensees extend to the entire whole, and thus to each > and every part regardless of who wrote it. This could probably be considered as a "mere aggregation" for the purposes of the GPL, however, IANAL From aoliva at redhat.com Thu May 22 18:18:47 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Thu, 22 May 2008 15:18:47 -0300 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: <1211444657.21380.424.camel@pmac.infradead.org> (David Woodhouse's message of "Thu\, 22 May 2008 09\:24\:17 +0100") References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> <1211405127.21380.382.camel@pmac.infradead.org> <1211444657.21380.424.camel@pmac.infradead.org> Message-ID: On May 22, 2008, David Woodhouse wrote: > On Wed, 2008-05-21 at 20:53 -0300, Alexandre Oliva wrote: >> Assuming that's acceptable upstream. I sort of doubt it, > Post them to me; I'll convert them to 'diff -u' for you and send them > on. Thanks, I'll probably take up the offer. > That is best addressed by making sure you don't come across as a kook. Can't really help that, there's a fundamental cultural clash. That's why your offer to be the man in the middle is so invaluable. > You need to make it clear that you're not just intending to remove stuff > and run away leaving it broken; But I am :-) :-) Seriously, not really; I don't intend to deprive users of the ability to get their stuff to work, but I also have limited resources to put into personal projects, so it's hard to do more than the absolutely minimum necessary to achieve the goal I had in mind. Even more so because I foresee a lot of resistance, that ultimately makes me expect it to be a pointless exercise. But it's yet another of those win-win situations, in which if I try it and succeed, excellent; if I don't, I can at least come back and say "see?, I told you" :-) >> Could you honestly tell me, with a straight face and a reasonable >> degree of assurance, that a patch that performs these actions stands >> any chance whatsoever of being accepted upstream? > I'll tell you what I'd do to _improve_ its chances. Would that do? It seems like a reasonable idea and a useful feature (although I don't quite see that as a major improvement over loading this stuff out of initrd), but I honestly don't see that upstream will want to sacrifice the convenience of having the firmware right there as part of their buildable tarball just because such a feature is in place. They don't exactly care about helping us achieve a 100% Free source tarball, you know :-) I guess we'll have to try and see. Maybe we should start with the non-redistributable piece of firmware I mentioned. > And after that, you can look at evicting the offending blobs from the > kernel altogether. This is the part I don't see happening. And if it doesn't happen, then all of this will have been just running around in circles as far as my goals are concerned. > Since Fedora uses an initrd anyway, we'd probably choose not to > build any of the blobs into the kernel, but to ship them in a > separate package(s). You can then just omit that package from your > compose. As long as they're part of the kernel source tarball, the distribution of any spins allegedly Free still involve the distribution of this non-Free Software. So achieving anything less than a blob-free kernel source tarball is no progress. Now, do you understand what I'd need to achieve in order to accomplish the goal I set out to accomplish, and do you still believe there's even a slight chance of that coming about upstream? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From pregier at ittc.ku.edu Thu May 22 18:24:14 2008 From: pregier at ittc.ku.edu (Phil Regier) Date: Thu, 22 May 2008 13:24:14 -0500 Subject: What ever happened to "Stateless Linux"? Message-ID: <4835BA4E.7080107@ittc.ku.edu> It would appear that the guides which popped up at the time of the FC6-FC7 transition have gone more or less defunct since then: http://fedoraproject.org/wiki/StatelessLinux It would also seem that the URLs referenced by the above under http://people.redhat.com/~law/ have not been updated since FC7. What is the current stated of Stateless development under Fedora and related distributions? Have the specialized tools been deprecated with no replacement, or are there new tools to fill any possible gaps? Thanks... Phil From sander at vermin.nl Thu May 22 18:34:09 2008 From: sander at vermin.nl (Sander Vermin) Date: Thu, 22 May 2008 20:34:09 +0200 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080522065724.1788e577@vader.jdub.homelinux.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> Message-ID: <4835BCA1.4040507@vermin.nl> Josh Boyer schreef: > Let the naming begin! We're starting very early this time around in > the name game for F10. So, let the suggestions flow! > > Remember the rules: > > 1) must have some link to Sulphur > > More specifically, the link should be > Sulphur is a and > is a > Where is the same for both > > 2) The link between and Sulphur cannot be the same as between > Werewolf and Sulphur. That link was "things that react badly with > silver". > > I will be collecting suggestions for 1 week, so the cutoff for names is: > > May 29, 2008 > > Suggestions will be run through the legal queue and an election will > happen for Fedora contributors to pick the next Fedora name. > > josh > > This is a link for a cool name :-) Sulphur is a cure for psoriasis and ultraviolet is a cure for psoriasis Fedora 10 (ultraviolet) or for short Fedora 10 (UV) From alan at redhat.com Thu May 22 18:48:14 2008 From: alan at redhat.com (Alan Cox) Date: Thu, 22 May 2008 14:48:14 -0400 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: <1211478494.21380.459.camel@pmac.infradead.org> References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> <1211405127.21380.382.camel@pmac.infradead.org> <4834D3F2.90409@gmail.com> <20080522164742.GD8443@devserv.devel.redhat.com> <1211478494.21380.459.camel@pmac.infradead.org> Message-ID: <20080522184814.GA17490@devserv.devel.redhat.com> On Thu, May 22, 2008 at 06:48:14PM +0100, David Woodhouse wrote: > > is a separate work. Like your BIOS for example. > > Being a separate work doesn't save it from the requirements of the GPL. > > The GPL clearly states that under some circumstances it _does_ extend to > sections which are independent and separate works in themselves. > If identifiable sections of that work are not derived from the > Program, and can be reasonably considered independent and > separate works in themselves, then this License, and its terms, > do not apply to those sections when you distribute them as > separate works. > > (OK, that's the firmware). No it isn't. See "mere aggregation" -- Take control of enterprise infrastructure Sign up for starfleet academy today From notting at redhat.com Thu May 22 18:52:52 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 22 May 2008 14:52:52 -0400 Subject: What ever happened to "Stateless Linux"? In-Reply-To: <4835BA4E.7080107@ittc.ku.edu> References: <4835BA4E.7080107@ittc.ku.edu> Message-ID: <20080522185252.GG8819@nostromo.devel.redhat.com> Phil Regier (pregier at ittc.ku.edu) said: > It would appear that the guides which popped up at the time of the FC6-FC7 > transition have gone more or less defunct since then: > > http://fedoraproject.org/wiki/StatelessLinux > > It would also seem that the URLs referenced by the above under > > http://people.redhat.com/~law/ > > have not been updated since FC7. What is the current stated of Stateless > development under Fedora and related distributions? Have the specialized > tools been deprecated with no replacement, or are there new tools to fill > any possible gaps? We have readonly-root support, for local filesystems, NFS, and iSCSI. For things like management and deployment, there are tools like cobbler and puppet, but there's not a specific integrated infrastructure. Bill From cjdahlin at ncsu.edu Thu May 22 18:58:43 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Thu, 22 May 2008 14:58:43 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: References: <20080522065724.1788e577@vader.jdub.homelinux.org> <48356905.2090805@draigBrady.com> <20080522162138.GD8819@nostromo.devel.redhat.com> <604aa7910805220926o2738942bo3e7e5bad35828107@mail.gmail.com> Message-ID: <4835C263.9080801@ncsu.edu> Ian Weller wrote: > On Thu, 22 May 2008, Jeff Spaleta wrote: > >> On Thu, May 22, 2008 at 8:21 AM, Bill Nottingham >> wrote: >>> P?draig Brady (P at draigBrady.com) said: >>>> Jupiter >>>> >>>> Sulphur has atomic number 16 >>>> Jupiter has 16 moons >>> >>> That's not really direct enough of a link. >> >> In the classical bohr model of the atom.. Sulphor has 16 circling >> moon-like electrons! >> > This made me fall out of my chair laughing. -- ian Congratulations. You're a bigger nerd than me. --CJD From peter at thecodergeek.com Thu May 22 19:01:09 2008 From: peter at thecodergeek.com (Peter Gordon) Date: Thu, 22 May 2008 12:01:09 -0700 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080522065724.1788e577@vader.jdub.homelinux.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> Message-ID: <1211482869.6803.1.camel@werewolf> My two cents...er, naming suggestions. :) Sulphur is an essential components of all living cells. Water is an essential components of all living cells. Sulphur is a substance found naturally as crystals. Quartz is a substance found naturally as crystals. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-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 Thu May 22 18:36:14 2008 From: davej at redhat.com (Dave Jones) Date: Thu, 22 May 2008 14:36:14 -0400 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: <1211444657.21380.424.camel@pmac.infradead.org> References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> <1211405127.21380.382.camel@pmac.infradead.org> <1211444657.21380.424.camel@pmac.infradead.org> Message-ID: <20080522183614.GB32314@redhat.com> On Thu, May 22, 2008 at 09:24:17AM +0100, David Woodhouse wrote: > > # SND_KORG1212 - Korg 1212 IO > > clean_ifdef sound/pci/korg1212/korg1212.c CONFIG_SND_KORG1212_FIRMWARE_IN_KERNEL > > clean_blob sound/pci/korg1212/korg1212-firmware.h > > > > # SND_MAESTRO3 - ESS Allegro/Maestro3 > > clean_ifdef sound/pci/maestro3.c CONFIG_SND_MAESTRO3_FIRMWARE_IN_KERNEL > > > > # SND_YMFPCI - Yamaha YMF724/740/744/754 > > clean_blob sound/pci/ymfpci/ymfpci_image.h > > clean_ifdef sound/pci/ymfpci/ymfpci_main.c CONFIG_SND_YMFPCI_FIRMWARE_IN_KERNEL > > > > clean_blob() removes long sequences of numbers, whereas clean_ifdef() > > runs unifdef on the named file assuming the named variable is > > undefined. > > > > Could you honestly tell me, with a straight face and a reasonable > > degree of assurance, that a patch that performs these actions stands > > any chance whatsoever of being accepted upstream? > > I'll tell you what I'd do to _improve_ its chances. Would that do? > > What I'd do is augment the kernel's firmware class support so that users > can build firmware blobs into their kernel to be accessed through the > firmware class. So the ifdefs in the above code go away -- the user can > just choose to include the blobs in the kernel build or not, as they see > fit, and the driver just invokes the firmware loader and doesn't > actually _care_ whether the firmware comes from within the kernel or > from userspace. It's even easier than that. The drivers mentioned above _already_ have firmware loader support. All that's needed is for someone to convert those arrays into an actual file the firmware loader can read, and package it up in an rpm, along with udev scripts to auto-load it, and we can disable that CONFIG option in the kernel. Dave -- http://www.codemonkey.org.uk From jdieter at gmail.com Thu May 22 19:44:48 2008 From: jdieter at gmail.com (Jonathan Dieter) Date: Thu, 22 May 2008 22:44:48 +0300 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1211482869.6803.1.camel@werewolf> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211482869.6803.1.camel@werewolf> Message-ID: <1211485488.3079.12.camel@jdlaptop> On Thu, 2008-05-22 at 12:01 -0700, Peter Gordon wrote: > My two cents...er, naming suggestions. :) > > Sulphur is an essential components of all living cells. > Water is an essential components of all living cells. FWIW, Sulphur is an odorless substance & Water is an odorless substance. But I think Aqua/Agua/Dihydrogen Monoxide sounds better than water. My wife suggested Ozone: Sulpheric acid is a component in air pollution; Ozone is a component in air pollution (particularly in cities). Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jspaleta at gmail.com Thu May 22 19:54:09 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 22 May 2008 11:54:09 -0800 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: <20080522183614.GB32314@redhat.com> References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> <1211405127.21380.382.camel@pmac.infradead.org> <1211444657.21380.424.camel@pmac.infradead.org> <20080522183614.GB32314@redhat.com> Message-ID: <604aa7910805221254w1b1227d6o811484d201f50a53@mail.gmail.com> On Thu, May 22, 2008 at 10:36 AM, Dave Jones wrote: > It's even easier than that. The drivers mentioned above _already_ have > firmware loader support. All that's needed is for someone to convert > those arrays into an actual file the firmware loader can read, and > package it up in an rpm, along with udev scripts to auto-load it, > and we can disable that CONFIG option in the kernel. You sir, have brightened my day. If you weren't several thousand miles away, I'd probably track you down and give you a hug. But since I am several thousand miles away. I'll have to delegate that task to someone else. Someone hug Dave for me! -jef From stickster at gmail.com Thu May 22 19:54:41 2008 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 22 May 2008 15:54:41 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211462088.4891.45.camel@victoria> <48357E29.2010609@nobugconsulting.ro> <1211466316.5079.61.camel@localhost.localdomain> <1211466224.3559.48.camel@cutter> <1211467352.5079.65.camel@localhost.localdomain> <483587E7.2020300@nobugconsulting.ro> Message-ID: <1211486081.4891.113.camel@victoria> On Thu, 2008-05-22 at 17:16 +0000, Joel wrote: > Manuel Wolfshant nobugconsulting.ro> writes: > > Jesse Keating wrote: > > >> And that feels way too generic, like "fred" is a word in the dictionary, > >> "alphanumeric" is a word in the dictionary. It's not trying hard enough > > > I'd argument that the link Fedora 10 < --> 10th element in the periodic > > table is worth it. That's why I liked it so much. > > Furthermore, 10 is how you write 16 in hex... And neon is also used often in signs that say "OPEN." :-) -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-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 May 22 20:04:45 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 22 May 2008 16:04:45 -0400 Subject: upstart plans for F10+ Message-ID: <20080522200445.GA24822@nostromo.devel.redhat.com> Since I've been asked in various places what we're planning to do with upstart now that Fedora 9 has shipped, I figured I'd lay out the basic plan. To do any large-scale conversion of SysV init scripts to upstart, we need some features that are not in the current (0.3.9) version. Hence, the first thing is to get upstart 0.5 ready for inclusion. For example, we need support for the following: - Depending on multiple events I.e., have something start only if two separate events have both completed successfully. For a disturbing example of how we work around this now, read /etc/event.d/serial. - Ability to enable/disable events in a way other than removing the file (The reasoning for this should be fairly obvious) - Ability to group events into sets, or profiles This allows us to handle the sort of behaviors that runlevels are used for sanely. - Ability to easily have upstart events depend on SysV scripts, and vice-versa If one of a SysV scripts' dependencies is started by upstart, we need to be able to still handle that sanely. This isn't meant to be an exhaustive list, but it is meant to illustrate why we can't just move services right now. Once we get upstart 0.5 in, we can then look at potentially moving some subset of things that are now handled elsewhere to upstart. Examples would be: - Always-on services such as dbus, syslog, and audit - Reworking things like netfs to be more sane, when it comes to networks coming and going, network block devices being attached and detached, and so on - Potentially splitting some of rc.sysinit into multiple events. Not sure this buys us much, as right now the flow is *extremely* sequential (start_udev -> fsck -> remount r/w -> clean out /tmp) - Coming up with a sane network notification strategy Right now, we have events kicked off on network changes: - via netreport - via NetworkManagerDispatcher - conceivably, via upstart (after all, spawning commands/etc based on events is its raison d'etre) Having a coherent strategy for apps to only need to worry about dropping things in one place would make sense. - (possibly) having either upstart 'handle' sysv services more natively or wrap tools such as chkconfig, /sbin/service so they handle both SysV and upstart. All clear as mud? Bill From jspaleta at gmail.com Thu May 22 20:06:54 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 22 May 2008 12:06:54 -0800 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1211486081.4891.113.camel@victoria> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211462088.4891.45.camel@victoria> <48357E29.2010609@nobugconsulting.ro> <1211466316.5079.61.camel@localhost.localdomain> <1211466224.3559.48.camel@cutter> <1211467352.5079.65.camel@localhost.localdomain> <483587E7.2020300@nobugconsulting.ro> <1211486081.4891.113.camel@victoria> Message-ID: <604aa7910805221306k7530111dhb9398bfc37b83399@mail.gmail.com> 2008/5/22 Paul W. Frields : > And neon is also used often in signs that say "OPEN." :-) dude...like really...we need a flickering neon sign made up that says Fedora: Open -jef From konrad at tylerc.org Thu May 22 20:10:49 2008 From: konrad at tylerc.org (Konrad Meyer) Date: Thu, 22 May 2008 13:10:49 -0700 Subject: upstart plans for F10+ In-Reply-To: <20080522200445.GA24822@nostromo.devel.redhat.com> References: <20080522200445.GA24822@nostromo.devel.redhat.com> Message-ID: <200805221310.49695.konrad@tylerc.org> Quoth Bill Nottingham: > Since I've been asked in various places what we're planning to > do with upstart now that Fedora 9 has shipped, I figured I'd > lay out the basic plan. > > To do any large-scale conversion of SysV init scripts to upstart, > we need some features that are not in the current (0.3.9) version. > Hence, the first thing is to get upstart 0.5 ready for inclusion. > For example, we need support for the following: > > - Depending on multiple events > > I.e., have something start only if two separate events have > both completed successfully. For a disturbing example of how > we work around this now, read /etc/event.d/serial. > > - Ability to enable/disable events in a way other than removing > the file > > (The reasoning for this should be fairly obvious) > > - Ability to group events into sets, or profiles > > This allows us to handle the sort of behaviors that runlevels are > used for sanely. > > - Ability to easily have upstart events depend on SysV scripts, and > vice-versa > > If one of a SysV scripts' dependencies is started by upstart, we > need to be able to still handle that sanely. > > This isn't meant to be an exhaustive list, but it is meant to > illustrate why we can't just move services right now. > > Once we get upstart 0.5 in, we can then look at potentially moving > some subset of things that are now handled elsewhere to upstart. > Examples would be: > > - Always-on services such as dbus, syslog, and audit > - Reworking things like netfs to be more sane, when > it comes to networks coming and going, network block devices being > attached and detached, and so on > - Potentially splitting some of rc.sysinit into multiple events. > Not sure this buys us much, as right now the flow is *extremely* > sequential (start_udev -> fsck -> remount r/w -> clean out /tmp) > - Coming up with a sane network notification strategy > Right now, we have events kicked off on network changes: > - via netreport > - via NetworkManagerDispatcher > - conceivably, via upstart (after all, spawning commands/etc based > on events is its raison d'etre) > Having a coherent strategy for apps to only need to worry about > dropping things in one place would make sense. > - (possibly) having either upstart 'handle' sysv services more natively > or wrap tools such as chkconfig, /sbin/service so they handle both > SysV and upstart. > > All clear as mud? > > Bill Thanks for keeping us informed of the current state of (upstart) affairs. -- Conrad Meyer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From optimizationkit at gmail.com Thu May 22 20:24:24 2008 From: optimizationkit at gmail.com (M) Date: Thu, 22 May 2008 22:24:24 +0200 Subject: upstart plans for F10+ In-Reply-To: <20080522200445.GA24822@nostromo.devel.redhat.com> References: <20080522200445.GA24822@nostromo.devel.redhat.com> Message-ID: <58a220fa0805221324g65cd1b91m68a12a0fc8d65231@mail.gmail.com> Hi, 2008/5/22 Bill Nottingham : > Since I've been asked in various places what we're planning to > do with upstart now that Fedora 9 has shipped, I figured I'd > lay out the basic plan. > > To do any large-scale conversion of SysV init scripts to upstart, > we need some features that are not in the current (0.3.9) version. > Hence, the first thing is to get upstart 0.5 ready for inclusion. > For example, we need support for the following: > > - Depending on multiple events AFAIK it's already in Upstart trunk > > I.e., have something start only if two separate events have > both completed successfully. For a disturbing example of how > we work around this now, read /etc/event.d/serial. FYI /etc/event.d was changed to /etc/init/jobs.d > > - Ability to enable/disable events in a way other than removing > the file > > (The reasoning for this should be fairly obvious) > > - Ability to group events into sets, or profiles > > This allows us to handle the sort of behaviors that runlevels are > used for sanely. > > - Ability to easily have upstart events depend on SysV scripts, and > vice-versa > > If one of a SysV scripts' dependencies is started by upstart, we > need to be able to still handle that sanely. > > This isn't meant to be an exhaustive list, but it is meant to > illustrate why we can't just move services right now. > > Once we get upstart 0.5 in, we can then look at potentially moving > some subset of things that are now handled elsewhere to upstart. > Examples would be: > > - Always-on services such as dbus, syslog, and audit > - Reworking things like netfs to be more sane, when > it comes to networks coming and going, network block devices being > attached and detached, and so on > - Potentially splitting some of rc.sysinit into multiple events. > Not sure this buys us much, as right now the flow is *extremely* > sequential (start_udev -> fsck -> remount r/w -> clean out /tmp) I wanted to do this, but actually initctl is not finished - it will be needed to sending variable values i.e. value of SELINUX_STATE from rcS-check-selinux-state to scripts that depend on SELINUX_STATE. > - Coming up with a sane network notification strategy > Right now, we have events kicked off on network changes: > - via netreport > - via NetworkManagerDispatcher > - conceivably, via upstart (after all, spawning commands/etc based > on events is its raison d'etre) > Having a coherent strategy for apps to only need to worry about > dropping things in one place would make sense. > - (possibly) having either upstart 'handle' sysv services more natively > or wrap tools such as chkconfig, /sbin/service so they handle both > SysV and upstart. > > All clear as mud? > > Bill > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Regards, Michal From walters at verbum.org Thu May 22 20:31:07 2008 From: walters at verbum.org (Colin Walters) Date: Thu, 22 May 2008 16:31:07 -0400 Subject: upstart plans for F10+ In-Reply-To: <20080522200445.GA24822@nostromo.devel.redhat.com> References: <20080522200445.GA24822@nostromo.devel.redhat.com> Message-ID: On Thu, May 22, 2008 at 4:04 PM, Bill Nottingham wrote: > > Once we get upstart 0.5 in, we can then look at potentially moving > some subset of things that are now handled elsewhere to upstart. > Examples would be: > > - Always-on services such as dbus, syslog, and audit Last time I talked to Scott he had in-progress code to make 0.5 manage the system bus internally. If the system bus depends on syslog and audit those may need to be started too. > - Reworking things like netfs to be more sane, when > it comes to networks coming and going, network block devices being > attached and detached, and so on Aren't pretty much all kernel based network filesystems broken in the world of dynamic networking? From optimizationkit at gmail.com Thu May 22 20:32:15 2008 From: optimizationkit at gmail.com (M) Date: Thu, 22 May 2008 22:32:15 +0200 Subject: upstart plans for F10+ In-Reply-To: <58a220fa0805221324g65cd1b91m68a12a0fc8d65231@mail.gmail.com> References: <20080522200445.GA24822@nostromo.devel.redhat.com> <58a220fa0805221324g65cd1b91m68a12a0fc8d65231@mail.gmail.com> Message-ID: <58a220fa0805221332j18a2af97w749f9fd96001d300@mail.gmail.com> BTW. It would be cool if someone created a separate mailing list for Upstart init script "development" and git repository. Regards, M. From berrange at redhat.com Thu May 22 20:33:11 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 22 May 2008 21:33:11 +0100 Subject: upstart plans for F10+ In-Reply-To: References: <20080522200445.GA24822@nostromo.devel.redhat.com> Message-ID: <20080522203311.GX26567@redhat.com> On Thu, May 22, 2008 at 04:31:07PM -0400, Colin Walters wrote: > On Thu, May 22, 2008 at 4:04 PM, Bill Nottingham wrote: > > > > Once we get upstart 0.5 in, we can then look at potentially moving > > some subset of things that are now handled elsewhere to upstart. > > Examples would be: > > > > - Always-on services such as dbus, syslog, and audit > > Last time I talked to Scott he had in-progress code to make 0.5 manage > the system bus internally. If the system bus depends on syslog and > audit those may need to be started too. > > > - Reworking things like netfs to be more sane, when > > it comes to networks coming and going, network block devices being > > attached and detached, and so on > > Aren't pretty much all kernel based network filesystems broken in the > world of dynamic networking? Not to mention network based block devices too... Dan -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From loupgaroublond at gmail.com Thu May 22 20:29:02 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Thu, 22 May 2008 16:29:02 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1211486081.4891.113.camel@victoria> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211462088.4891.45.camel@victoria> <48357E29.2010609@nobugconsulting.ro> <1211466316.5079.61.camel@localhost.localdomain> <1211466224.3559.48.camel@cutter> <1211467352.5079.65.camel@localhost.localdomain> <483587E7.2020300@nobugconsulting.ro> <1211486081.4891.113.camel@victoria> Message-ID: <7f692fec0805221329s25298462w5d75eac7626c0bfe@mail.gmail.com> 2008/5/22 Paul W. Frields : > On Thu, 2008-05-22 at 17:16 +0000, Joel wrote: >> Manuel Wolfshant nobugconsulting.ro> writes: >> > Jesse Keating wrote: >> >> >> And that feels way too generic, like "fred" is a word in the dictionary, >> >> "alphanumeric" is a word in the dictionary. It's not trying hard enough >> >> > I'd argument that the link Fedora 10 < --> 10th element in the periodic >> > table is worth it. That's why I liked it so much. >> >> Furthermore, 10 is how you write 16 in hex... > > And neon is also used often in signs that say "OPEN." :-) A flickering NEON overlay on top of a SteamPunk-ish blueprint for Fedora? There's something almost incongruous here that it's almost sexy. -Yaakov From ssorce at redhat.com Thu May 22 20:38:53 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 22 May 2008 16:38:53 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <604aa7910805221306k7530111dhb9398bfc37b83399@mail.gmail.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211462088.4891.45.camel@victoria> <48357E29.2010609@nobugconsulting.ro> <1211466316.5079.61.camel@localhost.localdomain> <1211466224.3559.48.camel@cutter> <1211467352.5079.65.camel@localhost.localdomain> <483587E7.2020300@nobugconsulting.ro> <1211486081.4891.113.camel@victoria> <604aa7910805221306k7530111dhb9398bfc37b83399@mail.gmail.com> Message-ID: <1211488733.3935.136.camel@localhost.localdomain> On Thu, 2008-05-22 at 12:06 -0800, Jeff Spaleta wrote: > 2008/5/22 Paul W. Frields : > > And neon is also used often in signs that say "OPEN." :-) > > dude...like really...we need a flickering neon sign made up that says > Fedora: Open Like this: http://people.redhat.com/ssorce/fedora-open.png ? :-) -- Simo Sorce * Red Hat, Inc * New York From jspaleta at gmail.com Thu May 22 20:40:04 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 22 May 2008 12:40:04 -0800 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <7f692fec0805221329s25298462w5d75eac7626c0bfe@mail.gmail.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211462088.4891.45.camel@victoria> <48357E29.2010609@nobugconsulting.ro> <1211466316.5079.61.camel@localhost.localdomain> <1211466224.3559.48.camel@cutter> <1211467352.5079.65.camel@localhost.localdomain> <483587E7.2020300@nobugconsulting.ro> <1211486081.4891.113.camel@victoria> <7f692fec0805221329s25298462w5d75eac7626c0bfe@mail.gmail.com> Message-ID: <604aa7910805221340x66d93f9fx352db99c9c835589@mail.gmail.com> On Thu, May 22, 2008 at 12:29 PM, Yaakov Nemoy wrote: > A flickering NEON overlay on top of a SteamPunk-ish blueprint for > Fedora? There's something almost incongruous here that it's almost > sexy. It's like walking into a store that is currently undergoing renovations for expansion but are still open for business. It's striking the balance between staying inviting and but keeping the construction moving. -jef From cjdahlin at ncsu.edu Thu May 22 20:40:37 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Thu, 22 May 2008 16:40:37 -0400 Subject: upstart plans for F10+ In-Reply-To: <20080522200445.GA24822@nostromo.devel.redhat.com> References: <20080522200445.GA24822@nostromo.devel.redhat.com> Message-ID: <4835DA45.5070601@ncsu.edu> Bill Nottingham wrote: > Since I've been asked in various places what we're planning to > do with upstart now that Fedora 9 has shipped, I figured I'd > lay out the basic plan. > > To do any large-scale conversion of SysV init scripts to upstart, > we need some features that are not in the current (0.3.9) version. > Hence, the first thing is to get upstart 0.5 ready for inclusion. > For example, we need support for the following: > > - Depending on multiple events > > I.e., have something start only if two separate events have > both completed successfully. For a disturbing example of how > we work around this now, read /etc/event.d/serial. > > This is in place now. > - Ability to enable/disable events in a way other than removing > the file > > (The reasoning for this should be fairly obvious) > > Might be a way to do this now with some of the new environment stuff, but a good solid way of doing it should come in 0.5.1. This is my first summer project, should be done by FUDCon latest. > - Ability to group events into sets, or profiles > > This allows us to handle the sort of behaviors that runlevels are > used for sanely. > > Comes with above. > - Ability to easily have upstart events depend on SysV scripts, and > vice-versa > > If one of a SysV scripts' dependencies is started by upstart, we > need to be able to still handle that sanely. > > We're pretty close to this as of now really. A bit more /etc/rc tweaking will get this. > This isn't meant to be an exhaustive list, but it is meant to > illustrate why we can't just move services right now. > > Once we get upstart 0.5 in, we can then look at potentially moving > some subset of things that are now handled elsewhere to upstart. > Examples would be: > > - Always-on services such as dbus, syslog, and audit > - Reworking things like netfs to be more sane, when > it comes to networks coming and going, network block devices being > attached and detached, and so on > - Potentially splitting some of rc.sysinit into multiple events. > Not sure this buys us much, as right now the flow is *extremely* > sequential (start_udev -> fsck -> remount r/w -> clean out /tmp) > We're shipping a 900-line shell script. That's the reason. > - Coming up with a sane network notification strategy > Right now, we have events kicked off on network changes: > - via netreport > - via NetworkManagerDispatcher > - conceivably, via upstart (after all, spawning commands/etc based > on events is its raison d'etre) > Having a coherent strategy for apps to only need to worry about > dropping things in one place would make sense. > +1. As soon as more of the DBus stuff appears in trunk (Scott seems to have quite a bit more on his hard drive than he's leaking to launchpad) I'm going to go chat with the NM people about this. > - (possibly) having either upstart 'handle' sysv services more natively > or wrap tools such as chkconfig, /sbin/service so they handle both > SysV and upstart. > > We're going to have a very hard time doing this without effecting the sysv interface. > All clear as mud? > > Bill > > As clear as an azure sky of deepest summer. You can rely on me, Fred. --CJD From ssorce at redhat.com Thu May 22 20:41:34 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 22 May 2008 16:41:34 -0400 Subject: upstart plans for F10+ In-Reply-To: References: <20080522200445.GA24822@nostromo.devel.redhat.com> Message-ID: <1211488894.3935.138.camel@localhost.localdomain> On Thu, 2008-05-22 at 16:31 -0400, Colin Walters wrote: > On Thu, May 22, 2008 at 4:04 PM, Bill Nottingham wrote: > > > > Once we get upstart 0.5 in, we can then look at potentially moving > > some subset of things that are now handled elsewhere to upstart. > > Examples would be: > > > > - Always-on services such as dbus, syslog, and audit > > Last time I talked to Scott he had in-progress code to make 0.5 manage > the system bus internally. If the system bus depends on syslog and > audit those may need to be started too. > > > - Reworking things like netfs to be more sane, when > > it comes to networks coming and going, network block devices being > > attached and detached, and so on > > Aren't pretty much all kernel based network filesystems broken in the > world of dynamic networking? It depends on what you mean by broken, CIFS for example can handle reconnections ... Simo. -- Simo Sorce * Red Hat, Inc * New York From notting at redhat.com Thu May 22 20:44:07 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 22 May 2008 16:44:07 -0400 Subject: upstart plans for F10+ In-Reply-To: References: <20080522200445.GA24822@nostromo.devel.redhat.com> Message-ID: <20080522204407.GA30257@nostromo.devel.redhat.com> Colin Walters (walters at verbum.org) said: > > - Reworking things like netfs to be more sane, when > > it comes to networks coming and going, network block devices being > > attached and detached, and so on > > Aren't pretty much all kernel based network filesystems broken in the > world of dynamic networking? I mean, right now we have a static init script that runs once on boot to mount NFS, SMB, etc, and set up network block devices. It's also (in F9) kicked when NM brings up a new default route. What would be sane is to have it just mount things when it can reach the proper network, and lazily unmount them when that network goes away. Heck, this can be extended to all filesystems - why should you do mount -a to mount /usr/local - why not just have anything in fstab automatically mounted when the device with the proper filesystem signature is found? Bill From jspaleta at gmail.com Thu May 22 20:45:02 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 22 May 2008 12:45:02 -0800 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1211488733.3935.136.camel@localhost.localdomain> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <48357E29.2010609@nobugconsulting.ro> <1211466316.5079.61.camel@localhost.localdomain> <1211466224.3559.48.camel@cutter> <1211467352.5079.65.camel@localhost.localdomain> <483587E7.2020300@nobugconsulting.ro> <1211486081.4891.113.camel@victoria> <604aa7910805221306k7530111dhb9398bfc37b83399@mail.gmail.com> <1211488733.3935.136.camel@localhost.localdomain> Message-ID: <604aa7910805221345p62aded14of68745c709f343b4@mail.gmail.com> On Thu, May 22, 2008 at 12:38 PM, Simo Sorce wrote: > Like this: http://people.redhat.com/ssorce/fedora-open.png ? except a real one...we can bask in the glow of at tradeshow events...and at fudcon's. and the open should always be red....duh -jef From notting at redhat.com Thu May 22 20:45:21 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 22 May 2008 16:45:21 -0400 Subject: upstart plans for F10+ In-Reply-To: <4835DA45.5070601@ncsu.edu> References: <20080522200445.GA24822@nostromo.devel.redhat.com> <4835DA45.5070601@ncsu.edu> Message-ID: <20080522204521.GB30257@nostromo.devel.redhat.com> Casey Dahlin (cjdahlin at ncsu.edu) said: >> - Potentially splitting some of rc.sysinit into multiple events. >> Not sure this buys us much, as right now the flow is *extremely* >> sequential (start_udev -> fsck -> remount r/w -> clean out /tmp) > > We're shipping a 900-line shell script. That's the reason. libtool scoffs at you. Bill From sundaram at fedoraproject.org Thu May 22 20:50:50 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 23 May 2008 02:20:50 +0530 Subject: upstart plans for F10+ In-Reply-To: <20080522200445.GA24822@nostromo.devel.redhat.com> References: <20080522200445.GA24822@nostromo.devel.redhat.com> Message-ID: <4835DCAA.9060208@fedoraproject.org> Bill Nottingham wrote: > Since I've been asked in various places what we're planning to > do with upstart now that Fedora 9 has shipped, I figured I'd > lay out the basic plan. > Might not be entirely related but are we going to get rid of the conflict between network and NetworkManager service by Fedora 10? Rahul From skvidal at fedoraproject.org Thu May 22 20:46:06 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 22 May 2008 16:46:06 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <604aa7910805221340x66d93f9fx352db99c9c835589@mail.gmail.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211462088.4891.45.camel@victoria> <48357E29.2010609@nobugconsulting.ro> <1211466316.5079.61.camel@localhost.localdomain> <1211466224.3559.48.camel@cutter> <604aa7910805221340x66d93f9fx352db99c9c835589@mail.gmail.com> Message-ID: <1211489166.9686.7.camel@cutter> On Thu, 2008-05-22 at 12:40 -0800, Jeff Spaleta wrote: > On Thu, May 22, 2008 at 12:29 PM, Yaakov Nemoy wrote: > > A flickering NEON overlay on top of a SteamPunk-ish blueprint for > > Fedora? There's something almost incongruous here that it's almost > > sexy. > > > It's like walking into a store that is currently undergoing > renovations for expansion but are still open for business. > It's striking the balance between staying inviting and but keeping the > construction moving. > Remember the movie Brazil? Remember the computers? - very steampunk-y Remember the logo for the movie? neon. :) -sv From cjdahlin at ncsu.edu Thu May 22 21:00:36 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Thu, 22 May 2008 17:00:36 -0400 Subject: upstart plans for F10+ In-Reply-To: <4835DCAA.9060208@fedoraproject.org> References: <20080522200445.GA24822@nostromo.devel.redhat.com> <4835DCAA.9060208@fedoraproject.org> Message-ID: <4835DEF4.7040006@ncsu.edu> Rahul Sundaram wrote: > Bill Nottingham wrote: >> Since I've been asked in various places what we're planning to do >> with upstart now that Fedora 9 has shipped, I figured I'd >> lay out the basic plan. >> > > Might not be entirely related but are we going to get rid of the > conflict between network and NetworkManager service by Fedora 10? > > Rahul > My understanding is yes. --CJD From notting at redhat.com Thu May 22 21:05:53 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 22 May 2008 17:05:53 -0400 Subject: upstart plans for F10+ In-Reply-To: <4835DCAA.9060208@fedoraproject.org> References: <20080522200445.GA24822@nostromo.devel.redhat.com> <4835DCAA.9060208@fedoraproject.org> Message-ID: <20080522210553.GB3409@nostromo.devel.redhat.com> Rahul Sundaram (sundaram at fedoraproject.org) said: > Bill Nottingham wrote: >> Since I've been asked in various places what we're planning to do with >> upstart now that Fedora 9 has shipped, I figured I'd >> lay out the basic plan. > > Might not be entirely related but are we going to get rid of the conflict > between network and NetworkManager service by Fedora 10? What conflict is there? They're using the same configurations... Bill From sundaram at fedoraproject.org Thu May 22 21:09:37 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 23 May 2008 02:39:37 +0530 Subject: upstart plans for F10+ In-Reply-To: <20080522210553.GB3409@nostromo.devel.redhat.com> References: <20080522200445.GA24822@nostromo.devel.redhat.com> <4835DCAA.9060208@fedoraproject.org> <20080522210553.GB3409@nostromo.devel.redhat.com> Message-ID: <4835E111.3070301@fedoraproject.org> Bill Nottingham wrote: > Rahul Sundaram (sundaram at fedoraproject.org) said: >> Bill Nottingham wrote: >>> Since I've been asked in various places what we're planning to do with >>> upstart now that Fedora 9 has shipped, I figured I'd >>> lay out the basic plan. >> Might not be entirely related but are we going to get rid of the conflict >> between network and NetworkManager service by Fedora 10? > > What conflict is there? They're using the same configurations... Why is there two different services? IIRC, I can't start both services together in Fedora 9. Rahul From berrange at redhat.com Thu May 22 21:11:22 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 22 May 2008 22:11:22 +0100 Subject: upstart plans for F10+ In-Reply-To: <4835E111.3070301@fedoraproject.org> References: <20080522200445.GA24822@nostromo.devel.redhat.com> <4835DCAA.9060208@fedoraproject.org> <20080522210553.GB3409@nostromo.devel.redhat.com> <4835E111.3070301@fedoraproject.org> Message-ID: <20080522211122.GA26567@redhat.com> On Fri, May 23, 2008 at 02:39:37AM +0530, Rahul Sundaram wrote: > Bill Nottingham wrote: > >Rahul Sundaram (sundaram at fedoraproject.org) said: > >>Bill Nottingham wrote: > >>>Since I've been asked in various places what we're planning to do with > >>>upstart now that Fedora 9 has shipped, I figured I'd > >>>lay out the basic plan. > >>Might not be entirely related but are we going to get rid of the conflict > >>between network and NetworkManager service by Fedora 10? > > > >What conflict is there? They're using the same configurations... > > Why is there two different services? IIRC, I can't start both services > together in Fedora 9. Yes you can - just add NM_CONTROLLED=no to the files /etc/sysconfig/network-scripts/ifcfg-XXXX that you want NM to ignore. Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From notting at redhat.com Thu May 22 21:21:36 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 22 May 2008 17:21:36 -0400 Subject: upstart plans for F10+ In-Reply-To: <4835E111.3070301@fedoraproject.org> References: <20080522200445.GA24822@nostromo.devel.redhat.com> <4835DCAA.9060208@fedoraproject.org> <20080522210553.GB3409@nostromo.devel.redhat.com> <4835E111.3070301@fedoraproject.org> Message-ID: <20080522212136.GC4069@nostromo.devel.redhat.com> Rahul Sundaram (sundaram at fedoraproject.org) said: >> What conflict is there? They're using the same configurations... > > Why is there two different services? NetworkManager does not currently have support for bonding, bridging, VLANs, and similar virtual devices. This can be fixed by getting this support into NetworkManager, but it isn't really related to upstart at all. Bill From felix.schwarz at oss.schwarz.eu Thu May 22 21:33:10 2008 From: felix.schwarz at oss.schwarz.eu (Felix Schwarz) Date: Thu, 22 May 2008 23:33:10 +0200 Subject: PyLucene: How to package libraries that link against OpenJDK libraries? Message-ID: <4835E696.1010401@oss.schwarz.eu> Hi, I'm trying to package JCC/PyLucene. Now that OpenJDK made it into Fedora (and EPEL 5), PyLucene with JCC could possibly be included with Fedora. But I'm facing some problems writing the spec files, therefore I did not submit the packages for a review: - JCC rpm [1]: include and lflags are set in setup.py which I have to change so that the file contains the rights paths. How can I get these paths while avoid these pitfalls: a) Do not have to rebuild JCC every time OpenJDK gets a version bump? b) Use the correct arch? (...lib/i386) - ok that one could be solved with some shell scripting in the spec file c) How to get the correct vm type? On i386 there is a client and a server vm. Is there a way I can "just" get the client vm directory (and as a fallback the server vm)? d) JCC uses JNI so the library paths must be set correctly at runtime. Unfortunately, the OpenJDK package does not add its paths to /etc/ld.so.conf.d (did I miss something?) Is there another workaround besides using rpath (bad, see a) or filing a bug against OpenJDK? - PyLucene rpm [2]: Besides the linker search path I have another problem with the version number. PyLucene uses version numbers which are illegal in RPM such as "2.3.2-1" (sic!). I think the best way to handle it (besides upstream changing the numbering schema) is just to use "2.3.2.1". Any objections? And last but not least the naming: PyLucene seems pretty clear to me, it conforms to the Python packaging guidelines. But what to do with JCC? It is essentially a python application containing a C++ library which links against the JDK. Should this be called python-jcc? Probably many of these questions are very much newbie-style and may be trivial for the more experienced but all pointers are appreciated :-) fs [1] http://www.schwarz.eu/opensource/rpm/JCC/1.9-2/ [2] http://www.schwarz.eu/opensource/rpm/PyLucene/2.3.2-1/ From loupgaroublond at gmail.com Thu May 22 21:42:06 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Thu, 22 May 2008 17:42:06 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1211489166.9686.7.camel@cutter> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211462088.4891.45.camel@victoria> <48357E29.2010609@nobugconsulting.ro> <1211466316.5079.61.camel@localhost.localdomain> <1211466224.3559.48.camel@cutter> <604aa7910805221340x66d93f9fx352db99c9c835589@mail.gmail.com> <1211489166.9686.7.camel@cutter> Message-ID: <7f692fec0805221442n2d332eb0qa8469fc285667d4e@mail.gmail.com> On Thu, May 22, 2008 at 4:46 PM, seth vidal wrote: > On Thu, 2008-05-22 at 12:40 -0800, Jeff Spaleta wrote: >> On Thu, May 22, 2008 at 12:29 PM, Yaakov Nemoy wrote: >> > A flickering NEON overlay on top of a SteamPunk-ish blueprint for >> > Fedora? There's something almost incongruous here that it's almost >> > sexy. >> >> >> It's like walking into a store that is currently undergoing >> renovations for expansion but are still open for business. >> It's striking the balance between staying inviting and but keeping the >> construction moving. >> > > Remember the movie Brazil? > > Remember the computers? - very steampunk-y > > Remember the logo for the movie? neon. Remember? The movie's half a year younger than I am. I suppose I shall have to take a look and see if there's any inspiration for this here. -Yaakov From fedora at dm.cobite.com Thu May 22 21:50:57 2008 From: fedora at dm.cobite.com (David Mansfield) Date: Thu, 22 May 2008 17:50:57 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1211489166.9686.7.camel@cutter> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211462088.4891.45.camel@victoria> <48357E29.2010609@nobugconsulting.ro> <1211466316.5079.61.camel@localhost.localdomain> <1211466224.3559.48.camel@cutter> <604aa7910805221340x66d93f9fx352db99c9c835589@mail.gmail.com> <1211489166.9686.7.camel@cutter> Message-ID: <1211493057.3584.4.camel@gandalf.cobite.com> On Thu, 2008-05-22 at 16:46 -0400, seth vidal wrote: > On Thu, 2008-05-22 at 12:40 -0800, Jeff Spaleta wrote: > > On Thu, May 22, 2008 at 12:29 PM, Yaakov Nemoy wrote: > > > A flickering NEON overlay on top of a SteamPunk-ish blueprint for > > > Fedora? There's something almost incongruous here that it's almost > > > sexy. > > > > > > It's like walking into a store that is currently undergoing > > renovations for expansion but are still open for business. > > It's striking the balance between staying inviting and but keeping the > > construction moving. > > > > Remember the movie Brazil? > > Remember the computers? - very steampunk-y > > Remember the logo for the movie? neon. > But does Brazil go to 11? On a separate note, a previous poster's suggestion of Ultraviolet, and the abbreviation of 'UV' made me wonder if there could be some sort of roman numeral pun that would get us to 'these go to 11', and also play off the Fruity Operating System roman numeral fetish. It would have to be awfully clever to hit all those targets and still associate with Sulphur. I'm just haven't thought of one yet... David From dsmith at redhat.com Thu May 22 21:53:08 2008 From: dsmith at redhat.com (David Smith) Date: Thu, 22 May 2008 16:53:08 -0500 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: References: <1211377739.4210.2.camel@truman> Message-ID: <4835EB44.5050501@redhat.com> Alexandre Oliva wrote: > . Inclusion in Fedora (future and recent past releases) of a > fedora-freedom "virtual" package, that Requires: linux-libre and > Conflicts: with any Fedora package known to contain software (firmware > included) that does not respect the 4 freedoms established in the Free > Software definition. AFAIK these would pretty much amount to the > standard non-Free kernel and a bunch of *-firmware packages, but there > could be sub-packages to cover other debatable packages with obscure > source code, dubious licensing policies, etc. Here's a (possibly bad) idea to think about. Write a yum plugin that refuses to install packages that have licensing policies you object to. That sounds much easier to deal with than trying to keep your virtual package up to date with new packages continually being added to the repository. -- David Smith dsmith at redhat.com Red Hat http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax) From adi1981.2k5 at gmail.com Thu May 22 21:59:10 2008 From: adi1981.2k5 at gmail.com (Adrian P) Date: Thu, 22 May 2008 23:59:10 +0200 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080522065724.1788e577@vader.jdub.homelinux.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> Message-ID: It won't be strictly followed to Josh's notes about Fedora naming, but i'll take a try. Fireworks or gun powder are being made from Sulphur. Sulphur is one of their ingredients. When we're launching fireworks, they're exploding. So... Mine proposal is: Fedora 10 "eXplosion" Note 'X' as 10, also explosion can mean here explosion of new technologies/functionalities etc in Fedora 10 2008/5/22 Josh Boyer : > Let the naming begin! We're starting very early this time around in > the name game for F10. So, let the suggestions flow! > > Remember the rules: > > 1) must have some link to Sulphur > > More specifically, the link should be > Sulphur is a and > is a > Where is the same for both > > 2) The link between and Sulphur cannot be the same as between > Werewolf and Sulphur. That link was "things that react badly with > silver". > > I will be collecting suggestions for 1 week, so the cutoff for names is: > > May 29, 2008 > > Suggestions will be run through the legal queue and an election will > happen for Fedora contributors to pick the next Fedora name. > > josh > > -- > 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 cjdahlin at ncsu.edu Thu May 22 21:59:02 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Thu, 22 May 2008 17:59:02 -0400 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: <4835EB44.5050501@redhat.com> References: <1211377739.4210.2.camel@truman> <4835EB44.5050501@redhat.com> Message-ID: <4835ECA6.2080808@ncsu.edu> David Smith wrote: > Alexandre Oliva wrote: > >> . Inclusion in Fedora (future and recent past releases) of a >> fedora-freedom "virtual" package, that Requires: linux-libre and >> Conflicts: with any Fedora package known to contain software (firmware >> included) that does not respect the 4 freedoms established in the Free >> Software definition. AFAIK these would pretty much amount to the >> standard non-Free kernel and a bunch of *-firmware packages, but there >> could be sub-packages to cover other debatable packages with obscure >> source code, dubious licensing policies, etc. >> > > Here's a (possibly bad) idea to think about. Write a yum plugin that > refuses to install packages that have licensing policies you object to. > That sounds much easier to deal with than trying to keep your virtual > package up to date with new packages continually being added to the > repository. > > Better way to do it would be to have license packages. So packages could "requires" nonfree, and this would show up in the yum reports. Yum remove nonfree would also purge your system effectively. --CJD From walters at verbum.org Thu May 22 22:09:09 2008 From: walters at verbum.org (Colin Walters) Date: Thu, 22 May 2008 18:09:09 -0400 Subject: PyLucene: How to package libraries that link against OpenJDK libraries? In-Reply-To: <4835E696.1010401@oss.schwarz.eu> References: <4835E696.1010401@oss.schwarz.eu> Message-ID: On Thu, May 22, 2008 at 5:33 PM, Felix Schwarz wrote: > Hi, > > I'm trying to package JCC/PyLucene. Now that OpenJDK made it into Fedora > (and EPEL 5), PyLucene with JCC could possibly be included with Fedora. Wow, JCC is terrifying. Interacting with Lucene via Jython would be...saner =) > But I'm facing some problems writing the spec files, therefore I did not > submit the packages for a review: > - JCC rpm [1]: include and lflags are set in setup.py which I have to change > so that the file contains the rights paths. How can I get these paths while > avoid these pitfalls: Fix the upstream setup.py to detect JPackage compatible VM layouts. Basically the directory /usr/lib/jvm/java has the current default VM. The algorithm I used in a patch for java-gnome is to check whether /etc/java/jpackage-release exists, and if so assume a JPackage compatible layout. You could also just look in /usr/lib/jvm/java too. > a) Do not have to rebuild JCC every time OpenJDK gets a version bump? I don't think so, but that's a question for JCC upstream. > b) Use the correct arch? (...lib/i386) - ok that one could be solved with > some shell scripting in the spec file Fix the upstream setup.py > c) How to get the correct vm type? On i386 there is a client and a server > vm. Is there a way I can "just" get the client vm directory (and as a > fallback the server vm)? Hm, if the project needs to poke at the internal VM libraries I'm not sure there's a clean way to do that, but an OpenJDK hacker might be able to give you an answer. > d) JCC uses JNI so the library paths must be set correctly at runtime. > Unfortunately, the OpenJDK package does not add its paths to > /etc/ld.so.conf.d (did I miss something?) Is there another workaround > besides using rpath (bad, see a) or filing a bug against OpenJDK? Right now, you should hardcode the paths to the library in your package. See: http://fedoraproject.org/wiki/Packaging/Java#head-61a3ee0d05ff616ef9be2021b489610e036fd932 Specifically, "If the JNI-using code calls System.loadLibrary you'll have to patch it to use System.load, passing it the full path to the dynamic shared object." For an example of this see http://cvs.fedoraproject.org/viewcvs/devel/javasqlite/ This is necessary until we get multilib-awareness into OpenJDK upstream. > - PyLucene rpm [2]: Besides the linker search path I have another problem > with > the version number. PyLucene uses version numbers which are illegal in RPM > such as "2.3.2-1" (sic!). I think the best way to handle it (besides > upstream changing the numbering schema) is just to use "2.3.2.1". Any > objections? Sounds reasonable. > And last but not least the naming: PyLucene seems pretty clear to me, it > conforms to the Python packaging guidelines. But what to do with JCC? It is > essentially a python application containing a C++ library which links > against the JDK. Should this be called python-jcc? Sure. From walters at verbum.org Thu May 22 22:13:23 2008 From: walters at verbum.org (Colin Walters) Date: Thu, 22 May 2008 18:13:23 -0400 Subject: upstart plans for F10+ In-Reply-To: <20080522204407.GA30257@nostromo.devel.redhat.com> References: <20080522200445.GA24822@nostromo.devel.redhat.com> <20080522204407.GA30257@nostromo.devel.redhat.com> Message-ID: On Thu, May 22, 2008 at 4:44 PM, Bill Nottingham wrote: > > I mean, right now we have a static init script that runs once > on boot to mount NFS, SMB, etc, and set up network block devices. > It's also (in F9) kicked when NM brings up a new default route. > > What would be sane is to have it just mount things when it can > reach the proper network, and lazily unmount them when that > network goes away. The issue with this is that at least last time I checked, at least some file systems like NFS basically don't handle the network going away from underneath them; if you have any userspace processes accessing them they'll be wedged unrecoverably in D state. I gave up long ago on using kernel-based network filesystems on my laptop for this reason. Simo says CIFS handles this, so maybe other filesystems could be fixed. But anyways, mounting after the network is available (triggered by NM) makes sense probably. From tmus at tmus.dk Thu May 22 22:38:23 2008 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Thu, 22 May 2008 20:38:23 -0200 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <48357FAF.2050300@redhat.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211459912.3079.4.camel@jdlaptop> <48356BE5.2020200@nigelj.com> <1211464964.3559.46.camel@cutter> <48357FAF.2050300@redhat.com> Message-ID: Bryan Kearney wrote: > Tempest > > That which is rained on upon you in hell: > > Upon the wicked he shall rain snares, fire and brimstone, and an > horrible tempest: this shall be the portion of their cup. (Psalm 11:6) > > Since Brimstone is another name for Sulphur. > So why not simply Brimstone? Where the link is that they are both, well, identical :) Normally, actual evolution of the name would probably be preferred to synonyms, but Brimstone is a super-cool name :) /Thomas From smooge at gmail.com Thu May 22 22:41:15 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 22 May 2008 16:41:15 -0600 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1211462088.4891.45.camel@victoria> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211462088.4891.45.camel@victoria> Message-ID: <80d7e4090805221541n4204beb4ic09b1d287579f570@mail.gmail.com> 2008/5/22 Paul W. Frields : > On Thu, 2008-05-22 at 06:57 -0500, Josh Boyer wrote: >> Let the naming begin! We're starting very early this time around in >> the name game for F10. So, let the suggestions flow! >> >> Remember the rules: >> >> 1) must have some link to Sulphur >> >> More specifically, the link should be >> Sulphur is a and >> is a >> Where is the same for both > > "Neon," which also happens to be the element 10 in the periodic table. > +1 Neon. -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From tmus at tmus.dk Thu May 22 22:43:31 2008 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Thu, 22 May 2008 20:43:31 -0200 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080522065724.1788e577@vader.jdub.homelinux.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> Message-ID: Josh Boyer wrote: > Let the naming begin! We're starting very early this time around in > the name game for F10. So, let the suggestions flow! > > Remember the rules: > > 1) must have some link to Sulphur > > More specifically, the link should be > Sulphur is a and > is a > Where is the same for both > > 2) The link between and Sulphur cannot be the same as between > Werewolf and Sulphur. That link was "things that react badly with > silver". > > I will be collecting suggestions for 1 week, so the cutoff for names is: > > May 29, 2008 > > Suggestions will be run through the legal queue and an election will > happen for Fedora contributors to pick the next Fedora name. > > josh > How about "Shiner"... Since people seems to like to use the color as the link to the next version name: Sulphur is yellow A shiner (aka a black eye) turns yellow after a few days It's also a cool name that packs a punch :-) /Thomas From mjs at clemson.edu Thu May 22 23:22:05 2008 From: mjs at clemson.edu (Matthew Saltzman) Date: Thu, 22 May 2008 23:22:05 +0000 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1211493057.3584.4.camel@gandalf.cobite.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211462088.4891.45.camel@victoria> <48357E29.2010609@nobugconsulting.ro> <1211466316.5079.61.camel@localhost.localdomain> <1211466224.3559.48.camel@cutter> <604aa7910805221340x66d93f9fx352db99c9c835589@mail.gmail.com> <1211489166.9686.7.camel@cutter> <1211493057.3584.4.camel@gandalf.cobite.com> Message-ID: <1211498526.28666.18.camel@valkyrie.localdomain> On Thu, 2008-05-22 at 17:50 -0400, David Mansfield wrote: > On Thu, 2008-05-22 at 16:46 -0400, seth vidal wrote: > > On Thu, 2008-05-22 at 12:40 -0800, Jeff Spaleta wrote: > > > On Thu, May 22, 2008 at 12:29 PM, Yaakov Nemoy wrote: > > > > A flickering NEON overlay on top of a SteamPunk-ish blueprint for > > > > Fedora? There's something almost incongruous here that it's almost > > > > sexy. > > > > > > > > > It's like walking into a store that is currently undergoing > > > renovations for expansion but are still open for business. > > > It's striking the balance between staying inviting and but keeping the > > > construction moving. > > > > > > > Remember the movie Brazil? > > > > Remember the computers? - very steampunk-y > > > > Remember the logo for the movie? neon. > > > > > But does Brazil go to 11? How about like this: "Neon" is a memorable image from the movie Brazil; "Ours go to 11" is a memorable image from the movie Spinal Tap. Although "ducts" is the most memorable image from Brazil. Don't quite see how to get from "sulpher" to "duct", though... > David > > > -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From cjdahlin at ncsu.edu Thu May 22 23:35:06 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Thu, 22 May 2008 19:35:06 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080522065724.1788e577@vader.jdub.homelinux.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> Message-ID: <4836032A.5070204@ncsu.edu> Josh Boyer wrote: > Let the naming begin! We're starting very early this time around in > the name game for F10. So, let the suggestions flow! > > Remember the rules: > > 1) must have some link to Sulphur > > More specifically, the link should be > Sulphur is a and > is a > Where is the same for both > > 2) The link between and Sulphur cannot be the same as between > Werewolf and Sulphur. That link was "things that react badly with > silver". > > I will be collecting suggestions for 1 week, so the cutoff for names is: > > May 29, 2008 > > Suggestions will be run through the legal queue and an election will > happen for Fedora contributors to pick the next Fedora name. > > josh > > "Stonehenge" since sulfer is a stone. The link to "Ours goes to 11" is then obvious :) --CJD From bpepple at fedoraproject.org Fri May 23 00:03:41 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Thu, 22 May 2008 20:03:41 -0400 Subject: FESCo Meeting Summary for 2008-05-08 Message-ID: <1211501021.29628.2.camel@kennedy> == Members Present == * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Bill Nottingham (notting) * Kevin Fenzi (nirik) * Jeremy Katz (jeremy) * Christopher Aillon (caillon) * Dennis Gilmore (dgilmore) * Warren Togami (warren) * Christian Iseli (c4chris) * David Woodhouse (dwmw2) * Jesse Keating (f13) * Tom Callaway (spot) == Absent == * Josh Boyer (jwb) == Summary == === Fedora Packaging Committee Proposal === * FESCo approved the FPC's proposal for withdrawing the JPackage naming exception. === Cut-off date for new packages requests in older branches === * FESCo decided the cut-off for new F-(X-2) packages is when F-X goes gold. (For example, new F8 package requests will not be accepted after F10 goes gold). bpepple has updated the wiki to reflect this. === Kernel-libre === * FESCo wants this feature, but it needs to go upstream first and not involve an alternative kernel package. dwmw2 offered to help Alexandre Oliva (lxo) work with upstream on this. IRC log can be found at: http://bpepple.fedorapeople.org/fesco/FESCo-2008-05-22.html Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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: 197 bytes Desc: This is a digitally signed message part URL: From bpepple at fedoraproject.org Fri May 23 00:26:38 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Thu, 22 May 2008 20:26:38 -0400 Subject: Packager Sponsors Responsibility Policy Message-ID: <1211502398.29628.16.camel@kennedy> Hi all, I'm looking for some feedback on what we've got so far for the Packager Sponsors Responsibility Policy. http://fedoraproject.org/wiki/Extras/Schedule/SponsorResponsibilityPolicy --- == Who are Packager Sponsors? === Packager Sponsors are maintainers that have a good record of maintaining packages, doing reviews and assisting others with the processes and procedures of Fedora. Sponsors act as mentors for new contributors to help point them to areas they would like to contribute, assist them with processes and procedures and assist them when they need general guidance. Sponsors also are responsible for fixing mistakes made by their sponsored maintainers if they are unable to do so. Every Fedora package maintainer should have a sponsor. == Make sure the maintainers you sponsor follow guidelines == Sponsors should try and keep up with the doings of their sponsored maintainers. Bugzilla has the ability to let you know via email all activity for a given address. Initial sponsored maintainers should have more scrutiny than long established maintainers with a known record of good efforts. == Help answer maintainers questions == Sponsors should be available to their sponsored maintainers to answer questions. It's up to the sponsor if they wish to be available via IRC, email, bugzilla, mailing list posts, phone or the like. In the event a sponsor is unable to answer a question, they should escalate it to the appropriate list, FESCO, FAB or the like and get an answer passed back. == Fix issues caused by sponsored maintainers == If one of your sponsored maintainers is unable to fix an issue in their package(s), it's up to the sponsor to step in and make the needed fixes. This might include pushing a security update when the maintainer is unavailable, applying a patch, removing a improperly build package, or other time or security sensitive issue. Note that the maintainer should be shown the fix and how to manage the issue moving forward. == Revoking Sponsorship == A sponsor may elect to revoke their sponsorship of a maintainer in rare and extreme situations. These situations might include: A maintainer that no longer wishes to contribute to Fedora, a maintainer that refuses to follow guidelines, or irreconcilable differences between the maintainer and the Sponsor. In this event it is the responsibility of the Sponsor to orphan the maintainers packages, and do any other needed cleanups. == Sponsorship Duration == Sponsorship of a maintainer begins when the Sponsor approves them in the Fedora Account System. Sponsorship of a maintainer ends when that sponsorship is revoked, or when that maintainer themselves becomes a Sponsor. == Who Sponsors the Sponsors? == Once a maintainer has been granted sponsorship status (via a vote of FESCO), that Sponsor will be held accountable by FESCO, and not their previous Sponsor. --- If there is anything you feel is missing, or could be explained better, please reply to this thread (along with any suggested wording). Thanks, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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: 197 bytes Desc: This is a digitally signed message part URL: From mattdm at mattdm.org Fri May 23 02:17:25 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 22 May 2008 22:17:25 -0400 Subject: NetworkManager: I want to believe, but... [was Re: F9 potential service network bug?] In-Reply-To: <1211472267.5352.25.camel@localhost.localdomain> References: <3da3b5b40805161502w62f372dseca0ab6310e44447@mail.gmail.com> <1210975852.6805.10.camel@localhost.localdomain> <3da3b5b40805161522i2300f1cdhb1fc7b074084873f@mail.gmail.com> <604aa7910805161527j6b193c6dj2af4248155d5cdaf@mail.gmail.com> <20080517112856.GA18698@jadzia.bu.edu> <1211069083.3070.392.camel@cookie.hadess.net> <20080522142554.GB8728@jadzia.bu.edu> <1211472267.5352.25.camel@localhost.localdomain> Message-ID: <20080523021725.GA5233@jadzia.bu.edu> On Thu, May 22, 2008 at 12:04:27PM -0400, Dan Williams wrote: > > Because of delaying network initialization, or something else? I'm generally > > not interested in boot time per se except in the sense of > > time-to-fully-operational. (For machines with static addresses -- this isn't > > the laptop case.) > If you have a wired interface marked for DHCP, but no cable plugged in, > and ONBOOT=yes, the network service will block waiting until the DHCP > timeout. In general, you want connections to come up as they become > available. Too much context got snipped out, apparently. The question here is: what is the advantage of having NetworkManager handle *static* addresses? [...] > If you're using a single ethernet adapter, statically configured, > without a desktop, and only running say httpd and samba, then no, you > probably don't want to use NM. You certainly _could_ if you wanted to. Ok, so then we've got a hard sell coming up as NetworkManager becomes *the* way for Fedora -- if the official line is that a major use case "probably [doesn't] want to use NM" but it's incredibly difficult to do anything else, I'm left shrugging and using my fallback line of "uh, yeah, that does kinda suck. sorry about that, then." > If we're talking about GUIs, or more mobile machines like laptops or > mobile internet devices, or desktops in general, or multi-user systems > where finer-grained control of network devices is desired, then I can > list more advantages of NetworkManager. Clearly -- I'm totally with you there. Now that it actually works (thanks very much, by the way!) on my laptop, I'm very glad for it. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Fri May 23 02:19:57 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 22 May 2008 22:19:57 -0400 Subject: NetworkManager: I want to believe, but... [was Re: F9 potential service network bug?] In-Reply-To: <1211472800.5352.31.camel@localhost.localdomain> References: <3da3b5b40805161502w62f372dseca0ab6310e44447@mail.gmail.com> <1210975852.6805.10.camel@localhost.localdomain> <3da3b5b40805161522i2300f1cdhb1fc7b074084873f@mail.gmail.com> <604aa7910805161527j6b193c6dj2af4248155d5cdaf@mail.gmail.com> <20080517112856.GA18698@jadzia.bu.edu> <1211024075.4060.50.camel@localhost.localdomain> <20080522142009.GA8728@jadzia.bu.edu> <1211472800.5352.31.camel@localhost.localdomain> Message-ID: <20080523021957.GB5233@jadzia.bu.edu> On Thu, May 22, 2008 at 12:13:20PM -0400, Dan Williams wrote: > Yes, the problem with the netinstall has been pinpointed and fixed in: > https://admin.fedoraproject.org/updates/F9/pending/NetworkManager-0.7.0-0.9.3.svn3675.fc9 > http://koji.fedoraproject.org/koji/buildinfo?buildID=49712 > What was your /etc/sysconfig/network file? NETWORKING=yes HOSTNAME=localhost.localdomain IPV6_DEFAULTGW= (which is also odd since I told it to explicitly use a given hostname.) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From aoliva at redhat.com Fri May 23 02:20:36 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Thu, 22 May 2008 23:20:36 -0300 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: <20080522183614.GB32314@redhat.com> (Dave Jones's message of "Thu\, 22 May 2008 14\:36\:14 -0400") References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> <1211405127.21380.382.camel@pmac.infradead.org> <1211444657.21380.424.camel@pmac.infradead.org> <20080522183614.GB32314@redhat.com> Message-ID: On May 22, 2008, Dave Jones wrote: >> > # SND_KORG1212 - Korg 1212 IO >> > clean_ifdef sound/pci/korg1212/korg1212.c CONFIG_SND_KORG1212_FIRMWARE_IN_KERNEL >> > clean_blob sound/pci/korg1212/korg1212-firmware.h >> > >> > # SND_MAESTRO3 - ESS Allegro/Maestro3 >> > clean_ifdef sound/pci/maestro3.c CONFIG_SND_MAESTRO3_FIRMWARE_IN_KERNEL >> > >> > # SND_YMFPCI - Yamaha YMF724/740/744/754 >> > clean_blob sound/pci/ymfpci/ymfpci_image.h >> > clean_ifdef sound/pci/ymfpci/ymfpci_main.c CONFIG_SND_YMFPCI_FIRMWARE_IN_KERNEL > It's even easier than that. The drivers mentioned above _already_ have > firmware loader support. Which is exactly why I mentioned these 3. tg3 would be another such example, but that's about it. They already are controlled by the config options, but this doesn't solve anything, even if we were to actually disable these config options. > All that's needed is for someone to convert > those arrays into an actual file the firmware loader can read, and > package it up in an rpm, along with udev scripts to auto-load it, > and we can disable that CONFIG option in the kernel. But this still won't accomplish the goal of enabling someone to distribute Fedora without distributing or committing to distribute non-Free Software. Anything less than actually removing the non-Free Software from the kernel sources won't accomplish that. Do you see *this* happening? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From katzj at redhat.com Fri May 23 02:25:01 2008 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 22 May 2008 22:25:01 -0400 Subject: NetworkManager: I want to believe, but... [was Re: F9 potential service network bug?] In-Reply-To: <1211472267.5352.25.camel@localhost.localdomain> References: <3da3b5b40805161502w62f372dseca0ab6310e44447@mail.gmail.com> <1210975852.6805.10.camel@localhost.localdomain> <3da3b5b40805161522i2300f1cdhb1fc7b074084873f@mail.gmail.com> <604aa7910805161527j6b193c6dj2af4248155d5cdaf@mail.gmail.com> <20080517112856.GA18698@jadzia.bu.edu> <1211069083.3070.392.camel@cookie.hadess.net> <20080522142554.GB8728@jadzia.bu.edu> <1211472267.5352.25.camel@localhost.localdomain> Message-ID: <1211509501.19171.7.camel@aglarond.local> On Thu, 2008-05-22 at 12:04 -0400, Dan Williams wrote: > If you're using a single ethernet adapter, statically configured, > without a desktop, and only running say httpd and samba, then no, you > probably don't want to use NM. You certainly _could_ if you wanted to. No, we probably *do* want people using NetworkManager here because maintaining two entirely orthogonal network stacks is somewhat insane and makes the rest of the system harder to manage. Jeremy From katzj at redhat.com Fri May 23 02:26:08 2008 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 22 May 2008 22:26:08 -0400 Subject: NetworkManager: I want to believe, but... [was Re: F9 potential service network bug?] In-Reply-To: <20080523021725.GA5233@jadzia.bu.edu> References: <3da3b5b40805161502w62f372dseca0ab6310e44447@mail.gmail.com> <1210975852.6805.10.camel@localhost.localdomain> <3da3b5b40805161522i2300f1cdhb1fc7b074084873f@mail.gmail.com> <604aa7910805161527j6b193c6dj2af4248155d5cdaf@mail.gmail.com> <20080517112856.GA18698@jadzia.bu.edu> <1211069083.3070.392.camel@cookie.hadess.net> <20080522142554.GB8728@jadzia.bu.edu> <1211472267.5352.25.camel@localhost.localdomain> <20080523021725.GA5233@jadzia.bu.edu> Message-ID: <1211509568.19171.9.camel@aglarond.local> On Thu, 2008-05-22 at 22:17 -0400, Matthew Miller wrote: > On Thu, May 22, 2008 at 12:04:27PM -0400, Dan Williams wrote: > > > Because of delaying network initialization, or something else? I'm generally > > > not interested in boot time per se except in the sense of > > > time-to-fully-operational. (For machines with static addresses -- this isn't > > > the laptop case.) > > If you have a wired interface marked for DHCP, but no cable plugged in, > > and ONBOOT=yes, the network service will block waiting until the DHCP > > timeout. In general, you want connections to come up as they become > > available. > > Too much context got snipped out, apparently. The question here is: what is > the advantage of having NetworkManager handle *static* addresses? Even with static addresses you can have your connectivity dropped for various reasons. And having one way of finding out "is the network up" makes it so that we can actually *depend* on that in other places throughout the OS Jeremy From aoliva at redhat.com Fri May 23 02:32:38 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Thu, 22 May 2008 23:32:38 -0300 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: <4835ECA6.2080808@ncsu.edu> (Casey Dahlin's message of "Thu\, 22 May 2008 17\:59\:02 -0400") References: <1211377739.4210.2.camel@truman> <4835EB44.5050501@redhat.com> <4835ECA6.2080808@ncsu.edu> Message-ID: On May 22, 2008, Casey Dahlin wrote: > David Smith wrote: >> Alexandre Oliva wrote: >> Write a yum plugin that refuses to install packages that have >> licensing policies you object to. This is not about the license. The kernel claims to be under GPLv2, even though, per our licensing policies and guidelines, it should be 'redistributable', or not even that. A license doesn't ensure your freedom. A copyright license mere states some permissions that, per copyright law, you might require in order to do certain things that, in the absence of these permissions, would be substantial limitations to your freedom. But lack of permissions in a license isn't the only way software can become non-Free. Consider software under the modified BSD license, for example. Some of it is present in Microsoft Windows, and it's still under that BSD license. If you look at all the fine-print, you'll eventually find the UCB copyright notice and a copy of the license. But does that make that piece of software Free Software, just because it's licensed under a Free Software license? Obfuscated code pretending to be source may also be under various Free Software licenses, but still deny users the freedom to study the source code and adapt the software to their needs, because the obfuscated source code is incomprehensible and not amenable to modification. The licence a package is under isn't everything. Please don't conflate these two related but significantly different topics into one. >> That sounds much easier to deal with than trying to keep your virtual >> package up to date with new packages continually being added to the >> repository. >> >> > Better way to do it would be to have license packages. So packages > could "requires" nonfree, and this would show up in the yum > reports. Yum remove nonfree would also purge your system effectively. And then, if you exclude nonfree from the repo, no such package would be installed. Yes, this can work beautifully. The catches I can think of here is that this proposal depends on the maintainer of the package containing non-Free Software to introduce the dependency, and, if the non-Free Software is found out after a build, someone might still get the impression that that particular build does not contain non-Free Software, while it's widely known that it does, and someone who rejects nonfree might end up keeping the non-Free package installed because an update says it would introduce non-Free Software. A fedora-freedom package is superior IMHO because (i) it can be updated so as to mark existing packages as containing non-Free Software, (ii) it makes the choice positive, (iii) it is easier to connect it to a feature, (iv) it enables finer-grained control of what you don't want on your system. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From michael.wiktowy at gmail.com Fri May 23 02:34:32 2008 From: michael.wiktowy at gmail.com (Michael Wiktowy) Date: Thu, 22 May 2008 22:34:32 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1211489166.9686.7.camel@cutter> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211462088.4891.45.camel@victoria> <48357E29.2010609@nobugconsulting.ro> <1211466316.5079.61.camel@localhost.localdomain> <1211466224.3559.48.camel@cutter> <604aa7910805221340x66d93f9fx352db99c9c835589@mail.gmail.com> <1211489166.9686.7.camel@cutter> Message-ID: <3e4ec4600805221934v11e50233wd0e859730811ba0c@mail.gmail.com> On Thu, May 22, 2008 at 4:46 PM, seth vidal wrote: > Remember the movie Brazil? > > Remember the computers? - very steampunk-y > > Remember the logo for the movie? neon. I used to *love* that movie ... until I started living it. Now I can't watch it : ] Anyways ... >From Wikipedia: The distinctive colors of Jupiter's volcanic moon, Io, are from various forms of molten, solid and gaseous sulfur. So maybe the Jupiter moon connection wasn't so bad ... but the name of a moon ... "Io" instead ... kind of looks like "10" :] Kind of stretching the association but: Sulphur is yellow and stinks like rotten eggs Io is yellow and stinks like rotten eggs :] I do like the "Neon" suggestion a lot though. Lots of graphical potential: http://us.st11.yimg.com/us.st.yimg.com/I/everything-neon_2002_124397355 /Mike From aoliva at redhat.com Fri May 23 02:36:38 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Thu, 22 May 2008 23:36:38 -0300 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: <20080522164742.GD8443@devserv.devel.redhat.com> (Alan Cox's message of "Thu\, 22 May 2008 12\:47\:42 -0400") References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> <1211405127.21380.382.camel@pmac.infradead.org> <4834D3F2.90409@gmail.com> <20080522164742.GD8443@devserv.devel.redhat.com> Message-ID: On May 22, 2008, Alan Cox wrote: > On Thu, May 22, 2008 at 02:18:22AM -0300, Alexandre Oliva wrote: >> kernel. And, heck, this one doesn't even grant permission for >> redistribution. What are those Linux-no-libre guys thinking? > Well we were thinking (and much legal advice seems to agree) that the firmware > is a separate work. This completely misses the point. It doesn't matter if it's a separate work or not. The point is that software is being distributed without permission to do so. The arguments on whether redistributable software can be combined with GPLed under the mere aggregation clause, valid or not, mean nothing when the software isn't redistributable in the first place. > Like your BIOS for example. There wasn't a copy of my BIOS in linux-2.6.25.tar.bz2 last time I looked. If there was, it might very well be a copyright violation, depending, among other factors, on whether the BIOS grants permission for redistribution. > We had been gradually moving firmware to user space via request_firmware until > various free software extremists made such idiots of themselves on the kernel > list a couple of years ago everyone stopped because they were so p***ed off > with them. Which just goes to support my claim that it's very unlikely that the changes that remove non-Free blobs from the kernel just won't be accepted. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From stickster at gmail.com Fri May 23 02:46:16 2008 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 22 May 2008 22:46:16 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <7f692fec0805221329s25298462w5d75eac7626c0bfe@mail.gmail.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211462088.4891.45.camel@victoria> <48357E29.2010609@nobugconsulting.ro> <1211466316.5079.61.camel@localhost.localdomain> <1211466224.3559.48.camel@cutter> <1211467352.5079.65.camel@localhost.localdomain> <483587E7.2020300@nobugconsulting.ro> <1211486081.4891.113.camel@victoria> <7f692fec0805221329s25298462w5d75eac7626c0bfe@mail.gmail.com> Message-ID: <1211510776.18404.3.camel@victoria> On Thu, 2008-05-22 at 16:29 -0400, Yaakov Nemoy wrote: > 2008/5/22 Paul W. Frields : > > On Thu, 2008-05-22 at 17:16 +0000, Joel wrote: > >> Manuel Wolfshant nobugconsulting.ro> writes: > >> > Jesse Keating wrote: > >> > >> >> And that feels way too generic, like "fred" is a word in the dictionary, > >> >> "alphanumeric" is a word in the dictionary. It's not trying hard enough > >> > >> > I'd argument that the link Fedora 10 < --> 10th element in the periodic > >> > table is worth it. That's why I liked it so much. > >> > >> Furthermore, 10 is how you write 16 in hex... > > > > And neon is also used often in signs that say "OPEN." :-) > > A flickering NEON overlay on top of a SteamPunk-ish blueprint for > Fedora? There's something almost incongruous here that it's almost > sexy. No almost about it! -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-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 May 23 03:24:17 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 22 May 2008 19:24:17 -0800 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1211489166.9686.7.camel@cutter> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211462088.4891.45.camel@victoria> <48357E29.2010609@nobugconsulting.ro> <1211466316.5079.61.camel@localhost.localdomain> <1211466224.3559.48.camel@cutter> <604aa7910805221340x66d93f9fx352db99c9c835589@mail.gmail.com> <1211489166.9686.7.camel@cutter> Message-ID: <604aa7910805222024x2718ba3er936b45fe2c34d410@mail.gmail.com> On Thu, May 22, 2008 at 12:46 PM, seth vidal wrote: > Remember the movie Brazil? > > Remember the computers? - very steampunk-y > > Remember the logo for the movie? neon. So FUDCon in Brazil around the time of F10's release?!? -jef From kevin.kofler at chello.at Fri May 23 03:43:32 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 23 May 2008 03:43:32 +0000 (UTC) Subject: New system-config-acpid References: <48207BC5.3060105@redhat.com> <20080506154407.GA21822@nostromo.devel.redhat.com> <1210089619.17842.2.camel@localhost.localdomain> Message-ID: Jesse Keating redhat.com> writes: > On Tue, 2008-05-06 at 18:46 +0300, Pavel Shevchuk wrote: > > To make laptop custom buttons work in gdm/kdm? > > gdm at least runs session agents like gnome-power-manager so that you > can get events like this. GDM essentially starts up a full-blown desktop environment in the display manager, which IMHO is really overkill! How much stuff do you need running to prompt for username and password? Meanwhile KDM gets along just fine without even a window manager, let alone all those daemons. Kevin Kofler From mattdm at mattdm.org Fri May 23 03:47:08 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 22 May 2008 23:47:08 -0400 Subject: NetworkManager: I want to believe, but... [was Re: F9 potential service network bug?] In-Reply-To: <1211509568.19171.9.camel@aglarond.local> References: <3da3b5b40805161502w62f372dseca0ab6310e44447@mail.gmail.com> <1210975852.6805.10.camel@localhost.localdomain> <3da3b5b40805161522i2300f1cdhb1fc7b074084873f@mail.gmail.com> <604aa7910805161527j6b193c6dj2af4248155d5cdaf@mail.gmail.com> <20080517112856.GA18698@jadzia.bu.edu> <1211069083.3070.392.camel@cookie.hadess.net> <20080522142554.GB8728@jadzia.bu.edu> <1211472267.5352.25.camel@localhost.localdomain> <20080523021725.GA5233@jadzia.bu.edu> <1211509568.19171.9.camel@aglarond.local> Message-ID: <20080523034708.GA12797@jadzia.bu.edu> On Thu, May 22, 2008 at 10:26:08PM -0400, Jeremy Katz wrote: > > Too much context got snipped out, apparently. The question here is: what > > is the advantage of having NetworkManager handle *static* addresses? > Even with static addresses you can have your connectivity dropped for > various reasons. And having one way of finding out "is the network up" > makes it so that we can actually *depend* on that in other places > throughout the OS But "is the network up" a generally useful question? I find that "can I reach the network resource I need" is the more important one, and the "is the network up" issue basically a detail. I mean, who cares if the network is up if the gateway is down? This is why external monitoring (big brother or the like) is more practical. As I said earlier, I can see this as having some minor use, but I'm gonna have some serious trouble making it alone be the selling point. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Fri May 23 03:50:23 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 22 May 2008 23:50:23 -0400 Subject: NetworkManager: I want to believe, but... [was Re: F9 potential service network bug?] In-Reply-To: <1211509501.19171.7.camel@aglarond.local> References: <3da3b5b40805161502w62f372dseca0ab6310e44447@mail.gmail.com> <1210975852.6805.10.camel@localhost.localdomain> <3da3b5b40805161522i2300f1cdhb1fc7b074084873f@mail.gmail.com> <604aa7910805161527j6b193c6dj2af4248155d5cdaf@mail.gmail.com> <20080517112856.GA18698@jadzia.bu.edu> <1211069083.3070.392.camel@cookie.hadess.net> <20080522142554.GB8728@jadzia.bu.edu> <1211472267.5352.25.camel@localhost.localdomain> <1211509501.19171.7.camel@aglarond.local> Message-ID: <20080523035023.GB12797@jadzia.bu.edu> On Thu, May 22, 2008 at 10:25:01PM -0400, Jeremy Katz wrote: > > If you're using a single ethernet adapter, statically configured, > > without a desktop, and only running say httpd and samba, then no, you > > probably don't want to use NM. You certainly _could_ if you wanted to. > No, we probably *do* want people using NetworkManager here because > maintaining two entirely orthogonal network stacks is somewhat insane > and makes the rest of the system harder to manage. Right, now *this* one I see as a strong selling point -- but it's selling more to the system developers than to sysadmins (and, presumably, enterprise Linux customers, if that's on anyone's mind...). -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jwboyer at gmail.com Fri May 23 03:51:02 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 22 May 2008 22:51:02 -0500 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1211474646.4891.72.camel@victoria> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <48358677.2040807@hi.is> <3E241CC6FB3A4A498507355A8E917197@internal.onecool.com> <48359955.6000109@onecool.com> <1211474646.4891.72.camel@victoria> Message-ID: <20080522225102.67d62b57@vader.jdub.homelinux.org> On Thu, 22 May 2008 12:44:06 -0400 "Paul W. Frields" wrote: > On Thu, 2008-05-22 at 17:03 +0100, Steve Dowe wrote: > > Josh Boyer wrote: > > > On Thu, 22 May 2008 14:43:03 +0000 > > > "J?hann B. Gu?mundsson" wrote: > > > > > >> Konstantin Ryabitsev wrote: > > >>> On Thu, May 22, 2008 at 7:57 AM, Josh Boyer wrote: > > >>> > > >>> Sulphur is an ingredient used to make chemicals. > > >>> Element X is an ingredient used to make Powerpuff Girls. > > >>> > > >>> Thus, we should have Fedora X 10. ;) > > >>> > > >>> Cheers, > > >>> > > >> +1 > > >> > > >> Fedora X.. > > >> X marks the spot... > > > > > > I'm fairly certain this would be denied due to the other operating > > > system that calls itself "OSX". > > > > I'm pretty sure you cannot trademark a Roman Numeral. > > I'm absolutely certain that we don't want to look like copycats. :-) And I'm absolutely certain that regardless of whether you can trademark a roman number or not, legal won't let it fly. josh From jwboyer at gmail.com Fri May 23 03:53:39 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 22 May 2008 22:53:39 -0500 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080522170718.GE8819@nostromo.devel.redhat.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <20080522170718.GE8819@nostromo.devel.redhat.com> Message-ID: <20080522225339.37e00e32@vader.jdub.homelinux.org> On Thu, 22 May 2008 13:07:18 -0400 Bill Nottingham wrote: > Josh Boyer (jwboyer at gmail.com) said: > > I will be collecting suggestions for 1 week, so the cutoff for names is: > > > > May 29, 2008 > > OK, so things Sulphur is: > > - an element (already covered) > > - 'Sulfur' is a defunct magazine. Other defunct magazines include: > > Talk > Premiere > Sassy > Red Hat Linux > > If you stretch it to include just 'magazines', the list obviously gets larger. > > - a town in Indiana, or Louisiana, or Oklahoma > > Gary > Eureka > Leavenworth (oh, the places to go from there) > Marysville > Kurtz (the horror, the horror!) > Petroleum > Popcorn > Scipio > Cherokee/Choctaw/many other Native American tribes > Milton > Tallulah > Transylvania > Eastwood > Hickory > Waterloo > Vatican > Independence > White Castle > > - a river (in Texas and Arkansas, fwiw) > > Orinoco > Amazon > Sabine > Styx > Tam (just kidding) > Yukon > Ob > Snake > de la Plata > Jordan > Severn (whoops) > > > - a mountain > > Everest > Kilimanjaro > Stanley > Erebus > Terror > Matterhorn (leading to... Fedora 11: Pirates of the Caribbean!) > Etna > Ranier > Majestic > Ulysses > Man'O'War > Thor > Diablo > Olympus > Archimedes > > OK, I'll stop now. We probably don't need to submit *all* of these. Please, help me. Tell me the ones you care about. Your knowledge of useless things related to Sulphur (garnered from Wikipedia or not) overwhelms me. josh From jwboyer at gmail.com Fri May 23 03:57:25 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 22 May 2008 22:57:25 -0500 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <16de708d0805220947i37e96c82jf1240b86384822fb@mail.gmail.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211462088.4891.45.camel@victoria> <16de708d0805220947i37e96c82jf1240b86384822fb@mail.gmail.com> Message-ID: <20080522225725.074d97f3@vader.jdub.homelinux.org> On Thu, 22 May 2008 11:47:05 -0500 "Arthur Pemberton" wrote: > 2008/5/22 Paul W. Frields : > > On Thu, 2008-05-22 at 06:57 -0500, Josh Boyer wrote: > >> Let the naming begin! We're starting very early this time around in > >> the name game for F10. So, let the suggestions flow! > >> > >> Remember the rules: > >> > >> 1) must have some link to Sulphur > >> > >> More specifically, the link should be > >> Sulphur is a and > >> is a > >> Where is the same for both > > > > "Neon," which also happens to be the element 10 in the periodic table. > > +1 for Neon, the graphical possibilities seem promising: > http://commons.wikimedia.org/wiki/Image:Electron_shell_010_Neon.svg Ok, no more plus 1'ing. They don't count at the moment. I collect all the valid names that aren't duplicates, they get run past legal, and then you can plus 1 until your fingers fall off. Forgive me if I'm grumpy, but this thread will be huge as it is, and reading emails that are just plus 1's just adds to it. josh From k.georgiou at imperial.ac.uk Fri May 23 03:59:57 2008 From: k.georgiou at imperial.ac.uk (Kostas Georgiou) Date: Fri, 23 May 2008 04:59:57 +0100 Subject: upstart plans for F10+ In-Reply-To: References: <20080522200445.GA24822@nostromo.devel.redhat.com> <20080522204407.GA30257@nostromo.devel.redhat.com> Message-ID: <20080523035957.GA24410@imperial.ac.uk> On Thu, May 22, 2008 at 06:13:23PM -0400, Colin Walters wrote: > On Thu, May 22, 2008 at 4:44 PM, Bill Nottingham wrote: > > > > I mean, right now we have a static init script that runs once > > on boot to mount NFS, SMB, etc, and set up network block devices. > > It's also (in F9) kicked when NM brings up a new default route. > > > > What would be sane is to have it just mount things when it can > > reach the proper network, and lazily unmount them when that > > network goes away. > > The issue with this is that at least last time I checked, at least > some file systems like NFS basically don't handle the network going > away from underneath them; if you have any userspace processes > accessing them they'll be wedged unrecoverably in D state. I gave up > long ago on using kernel-based network filesystems on my laptop for > this reason. > > Simo says CIFS handles this, so maybe other filesystems could be fixed. > > But anyways, mounting after the network is available (triggered by NM) > makes sense probably. This is a bit dangerours... Have a look at /etc/init.d/netfs and tell me what will happen if you have an fs marked _netdev and the fsck fails if netfs doesn't run at init but under NM at some random point. In my opinion you only use netfs for filesystems that you want available at boot and n general you also want them to be always available, processes freezing until the network is available is not a problem but a feature. For everything else that isn't needed at boot there is always autofs. Starting netfs at some random point after the boot or stopping it isn't a very good idea really, not everyone is running in a laptop. Kostas From notting at redhat.com Fri May 23 04:04:10 2008 From: notting at redhat.com (Bill Nottingham) Date: Fri, 23 May 2008 00:04:10 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080522225339.37e00e32@vader.jdub.homelinux.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <20080522170718.GE8819@nostromo.devel.redhat.com> <20080522225339.37e00e32@vader.jdub.homelinux.org> Message-ID: <20080523040410.GD8843@nostromo.devel.redhat.com> Josh Boyer (jwboyer at gmail.com) said: > Please, help me. Tell me the ones you care about. Your knowledge of > useless things related to Sulphur (garnered from Wikipedia or not) > overwhelms me. Heh. Well, considering the winnowing that legal tends to do, I figure it's better to have more. As to the ones *I* find interesting: Premiere Red Hat Linux (yeah, yeah) Eureka Popcorn White Castle Styx Jordan Kilimanjaro Terror Ulysses Thor Bill From loupgaroublond at gmail.com Fri May 23 04:09:45 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Fri, 23 May 2008 00:09:45 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080523040410.GD8843@nostromo.devel.redhat.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <20080522170718.GE8819@nostromo.devel.redhat.com> <20080522225339.37e00e32@vader.jdub.homelinux.org> <20080523040410.GD8843@nostromo.devel.redhat.com> Message-ID: <7f692fec0805222109u4b991e4bi5f2c599d0f052abf@mail.gmail.com> On Fri, May 23, 2008 at 12:04 AM, Bill Nottingham wrote: > Josh Boyer (jwboyer at gmail.com) said: >> Please, help me. Tell me the ones you care about. Your knowledge of >> useless things related to Sulphur (garnered from Wikipedia or not) >> overwhelms me. > > Heh. Well, considering the winnowing that legal tends to do, I figure > it's better to have more. As to the ones *I* find interesting: > > Kilimanjaro Don't forget the classic western variety, Kilimanhorse -Yaakov From trond.danielsen at gmail.com Fri May 23 05:15:54 2008 From: trond.danielsen at gmail.com (Trond Danielsen) Date: Fri, 23 May 2008 07:15:54 +0200 Subject: New system-config-acpid In-Reply-To: References: <48207BC5.3060105@redhat.com> <20080506154407.GA21822@nostromo.devel.redhat.com> <1210089619.17842.2.camel@localhost.localdomain> Message-ID: <409676c70805222215n4b30c80h7d516d5140a28ee7@mail.gmail.com> 2008/5/23 Kevin Kofler : > Jesse Keating redhat.com> writes: >> On Tue, 2008-05-06 at 18:46 +0300, Pavel Shevchuk wrote: >> > To make laptop custom buttons work in gdm/kdm? >> >> gdm at least runs session agents like gnome-power-manager so that you >> can get events like this. > > GDM essentially starts up a full-blown desktop environment in the display > manager, which IMHO is really overkill! How much stuff do you need running to > prompt for username and password? Meanwhile KDM gets along just fine without > even a window manager, let alone all those daemons. I think this is a great thing because it makes my laptop behave as it should even if I am not currently logged in (suspend when battery is low, power management etc.). -- Trond Danielsen From trond.danielsen at gmail.com Fri May 23 05:33:56 2008 From: trond.danielsen at gmail.com (Trond Danielsen) Date: Fri, 23 May 2008 07:33:56 +0200 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1211462088.4891.45.camel@victoria> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211462088.4891.45.camel@victoria> Message-ID: <409676c70805222233j2fd5a79bqd1e93f5e0c21eca1@mail.gmail.com> 2008/5/22 Paul W. Frields : > On Thu, 2008-05-22 at 06:57 -0500, Josh Boyer wrote: >> Let the naming begin! We're starting very early this time around in >> the name game for F10. So, let the suggestions flow! >> >> Remember the rules: >> >> 1) must have some link to Sulphur >> >> More specifically, the link should be >> Sulphur is a and >> is a >> Where is the same for both > > "Neon," which also happens to be the element 10 in the periodic table. Great suggesting! Combined with a large Fedora 10 neon light sign for the release party and matching artwork I think we would have a killer combination. -- Trond Danielsen From rhally at mindspring.com Fri May 23 06:13:41 2008 From: rhally at mindspring.com (Richard Hally) Date: Fri, 23 May 2008 02:13:41 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080522065724.1788e577@vader.jdub.homelinux.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> Message-ID: <48366095.50204@mindspring.com> Josh Boyer wrote: > Let the naming begin! We're starting very early this time around in > the name game for F10. So, let the suggestions flow! > > Remember the rules: > > 1) must have some link to Sulphur > > More specifically, the link should be > Sulphur is a and > is a > Where is the same for both > > 2) The link between and Sulphur cannot be the same as between > Werewolf and Sulphur. That link was "things that react badly with > silver". > > I will be collecting suggestions for 1 week, so the cutoff for names is: > > May 29, 2008 > > Suggestions will be run through the legal queue and an election will > happen for Fedora contributors to pick the next Fedora name. > > josh > Acid -- "we are all on Acid" or "give it an Acid test" sulfur is a chemical -> acid is a chemical. There is of course sulphuric acid and acid rain. The theme is obviously Psychedelic or tie dyed(dating myself). From seg at haxxed.com Fri May 23 06:27:03 2008 From: seg at haxxed.com (Callum Lerwick) Date: Fri, 23 May 2008 01:27:03 -0500 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1211465906.3935.107.camel@localhost.localdomain> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211465906.3935.107.camel@localhost.localdomain> Message-ID: <1218b5bc0805222327s52328183s224af7c2db4b293f@mail.gmail.com> On Thu, May 22, 2008 at 9:18 AM, Simo Sorce wrote: > Steam is released by a modern combustion engine, Suplhur as well. > > And this would make some connection with SteamPunk too ? Possible trademark issues with Valve's content distribution platform: http://www.steampowered.com/ Incidentally which, along with Xbox Live, we should be watching very carefully. We already have the content delivery part down, but we're lacking in the community part. The Gnome Online Desktop is pretty close. Achievements for Open Arena, anyone? :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhally at mindspring.com Fri May 23 06:31:45 2008 From: rhally at mindspring.com (Richard Hally) Date: Fri, 23 May 2008 02:31:45 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080522065724.1788e577@vader.jdub.homelinux.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> Message-ID: <483664D1.8010303@mindspring.com> Josh Boyer wrote: > Let the naming begin! We're starting very early this time around in > the name game for F10. So, let the suggestions flow! > > Remember the rules: > > 1) must have some link to Sulphur > > More specifically, the link should be > Sulphur is a and > is a > Where is the same for both > > 2) The link between and Sulphur cannot be the same as between > Werewolf and Sulphur. That link was "things that react badly with > silver". > > I will be collecting suggestions for 1 week, so the cutoff for names is: > > May 29, 2008 > > Suggestions will be run through the legal queue and an election will > happen for Fedora contributors to pick the next Fedora name. > > josh > Steam -- sulfur is in coal; steam is in coal (indirectly when you burn coal to heat water) (Yes that's a stretch) We can all be steamed. We'll all be in hot water. we can power a technical revolution. The theme could be that gears theme (http://fedoraproject.org/wiki/Artwork/F10Themes/Gears From pemboa at gmail.com Fri May 23 06:36:35 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 23 May 2008 01:36:35 -0500 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1218b5bc0805222327s52328183s224af7c2db4b293f@mail.gmail.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211465906.3935.107.camel@localhost.localdomain> <1218b5bc0805222327s52328183s224af7c2db4b293f@mail.gmail.com> Message-ID: <16de708d0805222336s34d62ef3y26216bcbfbf252e1@mail.gmail.com> 2008/5/23 Callum Lerwick : > On Thu, May 22, 2008 at 9:18 AM, Simo Sorce wrote: >> >> Steam is released by a modern combustion engine, Suplhur as well. >> >> And this would make some connection with SteamPunk too ? > > Possible trademark issues with Valve's content distribution platform: I have to say, all this trademark stuff is getting depressing. Sorry for the off-topic comment. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From rhally at mindspring.com Fri May 23 06:39:37 2008 From: rhally at mindspring.com (Richard Hally) Date: Fri, 23 May 2008 02:39:37 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <483664D1.8010303@mindspring.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <483664D1.8010303@mindspring.com> Message-ID: <483666A9.6070402@mindspring.com> Richard Hally wrote: > Josh Boyer wrote: >> Let the naming begin! We're starting very early this time around in >> the name game for F10. So, let the suggestions flow! >> >> Remember the rules: >> >> 1) must have some link to Sulphur >> >> More specifically, the link should be >> Sulphur is a and >> is a >> Where is the same for both >> >> 2) The link between and Sulphur cannot be the same as between >> Werewolf and Sulphur. That link was "things that react badly with >> silver". >> >> I will be collecting suggestions for 1 week, so the cutoff for names is: >> >> May 29, 2008 >> >> Suggestions will be run through the legal queue and an election will >> happen for Fedora contributors to pick the next Fedora name. >> >> josh >> > > Steam -- > > sulfur is in coal; steam is in coal (indirectly when you burn coal to > heat water) (Yes that's a stretch) > > We can all be steamed. We'll all be in hot water. we can power a > technical revolution. > > The theme could be that gears theme > (http://fedoraproject.org/wiki/Artwork/F10Themes/Gears > woops, strike that "steam" suggestion, it is in use elsewhere. How about Coal -- Coal contains sulfur...maybe we will get Coal for Christmas? sorry, it's getting late. Richard From alexl at users.sourceforge.net Fri May 23 06:51:01 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Thu, 22 May 2008 23:51:01 -0700 Subject: Broken kdepim3 deps (Re: rawhide report: 20080520 changes) In-Reply-To: (Kevin Kofler's message of "Tue\, 20 May 2008 17\:18\:58 +0000 \(UTC\)") References: <20080520102245.C6395209D29@releng1.fedora.phx.redhat.com> Message-ID: <4ezlqhfr8q.fsf@allele2.eebweb.arizona.edu> >>>>> "KK" == Kevin Kofler writes: KK> We have upgraded kdepim to a snapshot of kdepim 4.1 in KK> Rawhide. Unfortunately, this means a few packages need fixing: [...] >> tellico-1.3.1-1.fc9.i386 requires libkcal.so.2 >> tellico-1.3.1-1.fc9.i386 requires libktnef.so.1 KK> These have to be built without the optional kdepim support KK> until/unless a KDE 4 version is available. kipi-plugins has KK> already been rebuilt without kdepim by Rex Dieter today. tellico has now been rebuilt without the kdepim support: http://koji.fedoraproject.org/koji/buildinfo?buildID=50265 From hughsient at gmail.com Fri May 23 06:58:35 2008 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 23 May 2008 07:58:35 +0100 Subject: thank you for the laptop[ sleep alert In-Reply-To: <4835B4AB.3000704@gmail.com> References: <95f1114b0805212357l755b7dd7s89fef87fb9a99762@mail.gmail.com> <3da3b5b40805220007p6859121tea559d7ec9ffe810@mail.gmail.com> <4835B4AB.3000704@gmail.com> Message-ID: <1211525915.3427.7.camel@hughsie-work> On Thu, 2008-05-22 at 11:00 -0700, Andrew Farris wrote: > > That is almost certainly packagekit doing updates. Sure, that message sucks. There's a bug open here: https://bugzilla.redhat.com/show_bug.cgi?id=439219 Richard. From dwmw2 at infradead.org Fri May 23 07:44:17 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 23 May 2008 08:44:17 +0100 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: <20080522184814.GA17490@devserv.devel.redhat.com> References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> <1211405127.21380.382.camel@pmac.infradead.org> <4834D3F2.90409@gmail.com> <20080522164742.GD8443@devserv.devel.redhat.com> <1211478494.21380.459.camel@pmac.infradead.org> <20080522184814.GA17490@devserv.devel.redhat.com> Message-ID: <1211528657.21380.478.camel@pmac.infradead.org> On Thu, 2008-05-22 at 14:48 -0400, Alan Cox wrote: > On Thu, May 22, 2008 at 06:48:14PM +0100, David Woodhouse wrote: > > > is a separate work. Like your BIOS for example. > > > > Being a separate work doesn't save it from the requirements of the GPL. > > > > The GPL clearly states that under some circumstances it _does_ extend to > > sections which are independent and separate works in themselves. > > > If identifiable sections of that work are not derived from the > > Program, and can be reasonably considered independent and > > separate works in themselves, then this License, and its terms, > > do not apply to those sections when you distribute them as > > separate works. > > > > (OK, that's the firmware). > > No it isn't. See "mere aggregation" That's a very optimistic interpretation of 'mere aggregation', given that the licence is very clearly stating that it applies not only to derivative works but also to collective works. Firmware and driver work together and form a coherent whole; neither is particularly useful without the other. This isn't "mere aggregation" in the sense of freeware software CDs which would bundle unrelated programs on the cover of a magazine. It's more than that -- it _is_ a collective work. But of course, until/unless it's tested in court, neither of us is right or wrong. -- dwmw2 From dwmw2 at infradead.org Fri May 23 07:46:01 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 23 May 2008 08:46:01 +0100 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: <20080522183614.GB32314@redhat.com> References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> <1211405127.21380.382.camel@pmac.infradead.org> <1211444657.21380.424.camel@pmac.infradead.org> <20080522183614.GB32314@redhat.com> Message-ID: <1211528761.21380.481.camel@pmac.infradead.org> On Thu, 2008-05-22 at 14:36 -0400, Dave Jones wrote: > It's even easier than that. The drivers mentioned above _already_ have > firmware loader support. All that's needed is for someone to convert > those arrays into an actual file the firmware loader can read, and > package it up in an rpm, along with udev scripts to auto-load it, > and we can disable that CONFIG option in the kernel. Yeah, but that's just the start. We'd need to convert other drivers to use the firwmare loader too instead of having their own private blobs. And while we're doing that we _are_ going to get people complaining that we force them to use an initrd where they didn't need to before. Hence the suggestion to make the firmware loader capable of having a built-in set of blobs. -- dwmw2 From tim.lauridsen at googlemail.com Fri May 23 07:38:53 2008 From: tim.lauridsen at googlemail.com (Tim Lauridsen) Date: Fri, 23 May 2008 09:38:53 +0200 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080522170718.GE8819@nostromo.devel.redhat.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <20080522170718.GE8819@nostromo.devel.redhat.com> Message-ID: <4836748D.2090707@googlemail.com> Bill Nottingham wrote: >> > Thor I like this on, The marvel character Thor has yellow hair, Thor is the Nordic thunder god (lightning bolts are draw in yellow) http://en.wikipedia.org/wiki/Image:Thor-272.jpg > Diablo This one is cool (Fedora 10 : El Diablo) Diablo smells like sulphur. Tim From nicu_fedora at nicubunu.ro Fri May 23 07:59:43 2008 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Fri, 23 May 2008 10:59:43 +0300 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <4836748D.2090707@googlemail.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <20080522170718.GE8819@nostromo.devel.redhat.com> <4836748D.2090707@googlemail.com> Message-ID: <4836796F.8040101@nicubunu.ro> Tim Lauridsen wrote: > Bill Nottingham wrote: >> Diablo > > This one is cool (Fedora 10 : El Diablo) Diablo smells like sulphur. In the fourth act of Diablo II were plenty of rivers of something, molten sulphur, lava or both (yup, it was in Hell): http://www.gamebanshee.com/showshot.php?/screenshots/diabloii/screenshot42.jpg -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From harald at redhat.com Fri May 23 08:33:25 2008 From: harald at redhat.com (Harald Hoyer) Date: Fri, 23 May 2008 10:33:25 +0200 Subject: Neon Sign In-Reply-To: <7f692fec0805221329s25298462w5d75eac7626c0bfe@mail.gmail.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211462088.4891.45.camel@victoria> <48357E29.2010609@nobugconsulting.ro> <1211466316.5079.61.camel@localhost.localdomain> <1211466224.3559.48.camel@cutter> <1211467352.5079.65.camel@localhost.localdomain> <483587E7.2020300@nobugconsulting.ro> <1211486081.4891.113.camel@victoria> <7f692fec0805221329s25298462w5d75eac7626c0bfe@mail.gmail.com> Message-ID: Yaakov Nemoy wrote: > 2008/5/22 Paul W. Frields : >> On Thu, 2008-05-22 at 17:16 +0000, Joel wrote: >>> Manuel Wolfshant nobugconsulting.ro> writes: >>>> Jesse Keating wrote: >>>>> And that feels way too generic, like "fred" is a word in the dictionary, >>>>> "alphanumeric" is a word in the dictionary. It's not trying hard enough >>>> I'd argument that the link Fedora 10 < --> 10th element in the periodic >>>> table is worth it. That's why I liked it so much. >>> Furthermore, 10 is how you write 16 in hex... >> And neon is also used often in signs that say "OPEN." :-) > > A flickering NEON overlay on top of a SteamPunk-ish blueprint for > Fedora? There's something almost incongruous here that it's almost > sexy. > > -Yaakov > Hmm, I liked the idea and inkscaped s.th. together :) Somebody can make an animated png out of it ... blinking :) http://harald.fedorapeople.org/Fedora-always-open.png http://harald.fedorapeople.org/Fedora-always-open.svg From harald at redhat.com Fri May 23 08:35:03 2008 From: harald at redhat.com (Harald Hoyer) Date: Fri, 23 May 2008 10:35:03 +0200 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1211488733.3935.136.camel@localhost.localdomain> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211462088.4891.45.camel@victoria> <48357E29.2010609@nobugconsulting.ro> <1211466316.5079.61.camel@localhost.localdomain> <1211466224.3559.48.camel@cutter> <1211467352.5079.65.camel@localhost.localdomain> <483587E7.2020300@nobugconsulting.ro> <1211486081.4891.113.camel@victoria> <604aa7910805221306k7530111dhb9398bfc37b83399@mail.gmail.com> <1211488733.3935.136.camel@localhost.localdomain> Message-ID: Simo Sorce wrote: > On Thu, 2008-05-22 at 12:06 -0800, Jeff Spaleta wrote: >> 2008/5/22 Paul W. Frields : >>> And neon is also used often in signs that say "OPEN." :-) >> dude...like really...we need a flickering neon sign made up that says >> Fedora: Open > > Like this: http://people.redhat.com/ssorce/fedora-open.png ? > > :-) > http://harald.fedorapeople.org/Fedora-always-open.png http://harald.fedorapeople.org/Fedora-always-open.svg you are free to modify and let it blink :) From giallu at gmail.com Fri May 23 09:02:57 2008 From: giallu at gmail.com (Gianluca Sforna) Date: Fri, 23 May 2008 11:02:57 +0200 Subject: Firefox crashing Message-ID: It seems that I can consistently crash my Firefox (firefox-3.0-0.60.beta5.fc9.x86_64) just by fast switching between tabs. If I run firefox from the console I get: which: no soundwrapper in (/usr/lib64/qt-3.3/bin:/usr/kerberos/bin:/usr/lib64/ccache:/usr/local/bin:/usr/bin:/bin:/sbin:/home/giallu/bin:/usr/sbin) which: no soundwrapper in (/usr/lib64/qt-3.3/bin:/usr/kerberos/bin:/usr/lib64/ccache:/usr/local/bin:/usr/bin:/bin:/sbin:/home/giallu/bin:/usr/sbin) Gtk-Message: Failed to load module "gnomebreakpad": libgnomebreakpad.so: cannot open shared object file: No such file or directory (npviewer.bin:22267): Gtk-WARNING **: Unable to locate theme engine in module_path: "nodoka", (npviewer.bin:22267): Gtk-WARNING **: Unable to locate theme engine in module_path: "nodoka", /usr/lib64/firefox-3.0b5/run-mozilla.sh: line 131: 22212 Segmentation fault (core dumped) "$prog" ${1+"$@"} and I've got some gdb backtrace (I can give more if needed): Program received signal SIGSEGV, Segmentation fault. js_GetStringBytes (cx=, str=) at jsstr.c:3207 3207 if (!rt->deflatedStringCacheLock) { (gdb) bt #0 js_GetStringBytes (cx=, str=) at jsstr.c:3207 #1 0x0000003ccd6171ed in JS_GetStringBytes (str=) at jsapi.c:5304 #2 0x000000337c2b849e in jsdScript (this=, aCx=, aScript=) at jsd_xpc.cpp:992 #3 0x000000337c2b9c4f in jsdScript::FromPtr (aCx=, aScript=) at jsd_xpc.h:155 #4 0x000000337c2b86fc in jsdService::EnumerateScripts ( this=, enumerator=) at jsd_xpc.cpp:2712 #5 0x000000337c421fd4 in NS_InvokeByIndex_P (that=, methodIndex=, paramCount=, params=) at xptcinvoke_x86_64_linux.cpp:208 #6 0x000000337bc4b4ef in XPCWrappedNative::CallMethod ( ccx=, mode=) at xpcwrappednative.cpp:2369 #7 0x000000337bc53c0b in XPC_WN_CallMethod (cx=, obj=, argc=, argv=, vp=) at xpcwrappednativejsops.cpp:1470 #8 0x0000003ccd64bf17 in js_Invoke (cx=, ---Type to continue, or q to quit--- argc=, vp=, flags=) at jsinterp.c:1287 #9 0x0000003ccd63f258 in js_Interpret (cx=0x36a35f0) at jsinterp.c:4841 #10 0x0000003ccd64bf7f in js_Invoke (cx=, argc=, vp=, flags=) at jsinterp.c:1303 Before going the bugzilla route I would like to know if some of you is experiencing the same but also opinions about why nspluginwrapper is not protecting me from that... TIA Gianluca From alan at redhat.com Fri May 23 09:12:56 2008 From: alan at redhat.com (Alan Cox) Date: Fri, 23 May 2008 05:12:56 -0400 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> <1211405127.21380.382.camel@pmac.infradead.org> <4834D3F2.90409@gmail.com> <20080522164742.GD8443@devserv.devel.redhat.com> Message-ID: <20080523091256.GB31575@devserv.devel.redhat.com> On Thu, May 22, 2008 at 11:36:38PM -0300, Alexandre Oliva wrote: > Which just goes to support my claim that it's very unlikely that the > changes that remove non-Free blobs from the kernel just won't be > accepted. Well that mostly depends if the people doing the work are prepared to be rational about it and submit request_firmware() based support, test it and identify the additional files needed. So far all we've had from the "Free software extremist" side has been - stupid patches to just remove stuff - insults - long political arguments on a technical list - people saying "we" (being some undefined 'kernel community' with whom they apparently think they have a service contract) should fix it. Alan From aph at redhat.com Fri May 23 09:13:25 2008 From: aph at redhat.com (Andrew Haley) Date: Fri, 23 May 2008 10:13:25 +0100 Subject: PyLucene: How to package libraries that link against OpenJDK libraries? In-Reply-To: References: <4835E696.1010401@oss.schwarz.eu> Message-ID: <48368AB5.2080405@redhat.com> Colin Walters wrote: > On Thu, May 22, 2008 at 5:33 PM, Felix Schwarz > wrote: > >> c) How to get the correct vm type? On i386 there is a client and a server >> vm. Is there a way I can "just" get the client vm directory (and as a >> fallback the server vm)? > > Hm, if the project needs to poke at the internal VM libraries I'm not > sure there's a clean way to do that, but an OpenJDK hacker might be > able to give you an answer. This is a bit mysterious. I guess I don't understand why PyLucene would want to poke at the internal VM libraries. >> d) JCC uses JNI so the library paths must be set correctly at runtime. >> Unfortunately, the OpenJDK package does not add its paths to >> /etc/ld.so.conf.d (did I miss something?) Is there another workaround >> besides using rpath (bad, see a) or filing a bug against OpenJDK? OpenJDK doesn't need to add its paths to /etc/ld.so.conf.d. It calls (for example) putenv("LD_LIBRARY_PATH=/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server:\ /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64:\ /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/../lib/amd64" + the old path.) and re-execs java. > Right now, you should hardcode the paths to the library in your package. See: > http://fedoraproject.org/wiki/Packaging/Java#head-61a3ee0d05ff616ef9be2021b489610e036fd932 > Specifically, "If the JNI-using code calls System.loadLibrary you'll > have to patch it to use System.load, passing it the full path to the > dynamic shared object." > > For an example of this see > http://cvs.fedoraproject.org/viewcvs/devel/javasqlite/ > > This is necessary until we get multilib-awareness into OpenJDK upstream. Interesting. What multilib-awareness do you think we need? It's not immediately clear to me where the beinefit would be. Andrew. From alan at redhat.com Fri May 23 09:15:53 2008 From: alan at redhat.com (Alan Cox) Date: Fri, 23 May 2008 05:15:53 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080523040410.GD8843@nostromo.devel.redhat.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <20080522170718.GE8819@nostromo.devel.redhat.com> <20080522225339.37e00e32@vader.jdub.homelinux.org> <20080523040410.GD8843@nostromo.devel.redhat.com> Message-ID: <20080523091553.GD31575@devserv.devel.redhat.com> On Fri, May 23, 2008 at 12:04:10AM -0400, Bill Nottingham wrote: > Jordan That might be touchy in some places. Not just political ones but also in some places "crossing the jordan" is a phrase equivalent to "kicking the bucket" or "pushing up the daisies" and might not be a great association ;) From markg85 at gmail.com Fri May 23 09:31:30 2008 From: markg85 at gmail.com (Mark) Date: Fri, 23 May 2008 11:31:30 +0200 Subject: upstart plans for F10+ In-Reply-To: <20080522200445.GA24822@nostromo.devel.redhat.com> References: <20080522200445.GA24822@nostromo.devel.redhat.com> Message-ID: <6e24a8e80805230231r3f2f0af4j8d5fd52f02e1fb5d@mail.gmail.com> 2008/5/22 Bill Nottingham : > Since I've been asked in various places what we're planning to > do with upstart now that Fedora 9 has shipped, I figured I'd > lay out the basic plan. > > To do any large-scale conversion of SysV init scripts to upstart, > we need some features that are not in the current (0.3.9) version. And why not cooperate with ubuntu and use the upstart scripts that they made? That would leave only a few other ones to make if any at all. From mcepl at redhat.com Fri May 23 09:27:47 2008 From: mcepl at redhat.com (Matej Cepl) Date: Fri, 23 May 2008 11:27:47 +0200 Subject: Problem with intel i810 driver References: <69e11d1f0805221045r772ac4eu128e564e4f9b095f@mail.gmail.com> Message-ID: On 2008-05-22, 17:45 GMT, Gustavo Alves wrote: > When I use "intel" driver, xorg give me the following errors: > > (EE) Failed to load module "intelmaster" (module does not exist, 0) > (EE) Failed to load module "intelbatchbuffer" (module does not exist, 0) > > The original name on up-to-date intel driver is intel_master and > intel_batchbuffer. How I should proceed? Renaming modules from > intelbatchbuffer to intel_batchbuffer or change the references for it to > intel_batchbuffer? Please, file a bug into Red Hat Bugzilla with /etc/X11/xorg.conf and /var/log/Xorg.*.log attached. Thank you, Mat?j Cepl From mcepl at redhat.com Fri May 23 09:33:17 2008 From: mcepl at redhat.com (Matej Cepl) Date: Fri, 23 May 2008 11:33:17 +0200 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a References: <20080522065724.1788e577@vader.jdub.homelinux.org> <20080522170718.GE8819@nostromo.devel.redhat.com> <544eb990805221018h2a263e00y82eed56b43a698d4@mail.gmail.com> Message-ID: On 2008-05-22, 17:18 GMT, Bill Crawford wrote: > You should rush to release Fedora X (Independence) on July 4th. > It may well be US-centric, but it's pretty widely known :o) Will be probably ignored as was my suggestion for Fedora 8 (released in early November 2007, 90 years after the disaster) -- Aurora. Oh well. Mat?j From mcepl at redhat.com Fri May 23 09:34:57 2008 From: mcepl at redhat.com (Matej Cepl) Date: Fri, 23 May 2008 11:34:57 +0200 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211474199.29467.204.camel@localhost.localdomain> <544eb990805220943i4311e61bg58517a76695980e@mail.gmail.com> Message-ID: <1nfig5xbv1.ln2@ppp1053.in.ipex.cz> On 2008-05-22, 16:43 GMT, Bill Crawford wrote: > But and Lovelace reference would be good. And I am sure mimho would create logos for that ;-). Mat?j From opensource at till.name Fri May 23 09:56:15 2008 From: opensource at till.name (Till Maas) Date: Fri, 23 May 2008 11:56:15 +0200 Subject: NetworkManager: I want to believe, but... In-Reply-To: <20080523035023.GB12797@jadzia.bu.edu> References: <3da3b5b40805161502w62f372dseca0ab6310e44447@mail.gmail.com> <1211509501.19171.7.camel@aglarond.local> <20080523035023.GB12797@jadzia.bu.edu> Message-ID: <200805231156.24832.opensource@till.name> On Fri May 23 2008, Matthew Miller wrote: > On Thu, May 22, 2008 at 10:25:01PM -0400, Jeremy Katz wrote: > > No, we probably *do* want people using NetworkManager here because > > maintaining two entirely orthogonal network stacks is somewhat insane > > and makes the rest of the system harder to manage. > > Right, now *this* one I see as a strong selling point -- but it's selling > more to the system developers than to sysadmins (and, presumably, > enterprise Linux customers, if that's on anyone's mind...). It is also helpful for users, e.g. I use my notebook sometimes in places where it gets a dynamic ip address, sometimes where it has its static ip address. Here it would also be nice to have only one tool that can handle both instead of two that can handle only some parts. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From mcepl at redhat.com Fri May 23 09:49:02 2008 From: mcepl at redhat.com (Matej Cepl) Date: Fri, 23 May 2008 11:49:02 +0200 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a References: <20080522065724.1788e577@vader.jdub.homelinux.org> <7f692fec0805220547m5b31417eo3a2baf681b8a4878@mail.gmail.com> Message-ID: On 2008-05-22, 12:47 GMT, Yaakov Nemoy wrote: > The sunflower is generally a symbol used for any green > political party or green economic plan. Perhaps we can include > a daily tips piece to go along with any Infrastructure site > that dispenses energy saving tips that can be used around the > world. The potential for education here is really good. Or maybe somebody could finally fix power management not to suck that much ;-) Mat?j From markg85 at gmail.com Fri May 23 10:05:49 2008 From: markg85 at gmail.com (Mark) Date: Fri, 23 May 2008 12:05:49 +0200 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1nfig5xbv1.ln2@ppp1053.in.ipex.cz> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211474199.29467.204.camel@localhost.localdomain> <544eb990805220943i4311e61bg58517a76695980e@mail.gmail.com> <1nfig5xbv1.ln2@ppp1053.in.ipex.cz> Message-ID: <6e24a8e80805230305x723f3f41ode2b401ac7f95cf6@mail.gmail.com> oke.. crazy suggestion (Solar) Flare Sulphur influence life (making it) a flare influence life (destroying it). Flare obseletes sulphur. Also Fedora Flare sounds nice And for Fedora 11 you can link Lightning to Flare. Flare is Fast, but lightning is Faster. From mcepl at redhat.com Fri May 23 10:04:41 2008 From: mcepl at redhat.com (Matej Cepl) Date: Fri, 23 May 2008 12:04:41 +0200 Subject: Xorg 1.5 missed the train? References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <1211379900.29467.136.camel@localhost.localdomain> <20080521152022.GF1093879@hiwaay.net> <1211383722.8531.63.camel@localhost.localdomain> <1211385285.8531.65.camel@localhost.localdomain> <544eb990805210917y45a7df22hb867b7e8e027d474@mail.gmail.com> Message-ID: On 2008-05-21, 16:44 GMT, Christopher Stone wrote: > No mud slinging was intended sir. How is this? Pretty good -- could you find some similar information about fglrx drivers as well, please? Matej From mcepl at redhat.com Fri May 23 10:03:32 2008 From: mcepl at redhat.com (Matej Cepl) Date: Fri, 23 May 2008 12:03:32 +0200 Subject: Xorg 1.5 missed the train? References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <20080520211137.67744ac3@vader.jdub.homelinux.org> <1211379900.29467.136.camel@localhost.localdomain> <20080521152022.GF1093879@hiwaay.net> <1211383722.8531.63.camel@localhost.localdomain> <1211385285.8531.65.camel@localhost.localdomain> Message-ID: On 2008-05-21, 16:01 GMT, Christopher Stone wrote: > The version of the X server shipped with Fedora 9 comes with > a new ABI which is not yet compatible with some third party > binary drivers such as nVidia. Just please reword it so that it doesn't like Fedora's fault. Something along the lines: Third party developers have not managed to port their graphical drivers (nvidia and fglrx are the most prominent) to the new Xorg API shipped in the current Fedora release yet. If your use of the computer depends on these drivers, then you are strongly advised either not to upgrade Fedora 9 yet, exclude xorg\* packages from upgrade (when using yum upgrade), or downgrade your xorg\* packages back to those in Fedora 8 after installation (when using upgrade from DVD). What about this? Mat?j From rawhide at fedoraproject.org Fri May 23 10:29:23 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Fri, 23 May 2008 10:29:23 +0000 (UTC) Subject: rawhide report: 20080523 changes Message-ID: <20080523102923.189EE209D29@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080522/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080523/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package decibel-audio-player Music player for GNOME New package libfakekey Library for converting characters to X key-presses New package matchbox-keyboard An on screen virtual keyboard New package mathmap MathMap GIMP Plug-In and Command-Line Tool New package perl-GO-TermFinder Identify GO nodes that annotate a group of genes with a significant p-value New package perl-Test-CPAN-Meta Validation of the META.yml file in a CPAN distribution New package rubygem-krb5-auth Kerberos binding for Ruby Updated Packages: SOAPpy-0.11.6-7.fc10 -------------------- * Thu May 22 18:00:00 2008 Christopher Stone 0.11.6-7 - Simplify %files - Remove no longer needed Obsoletes/Provides - Update %license tag TnL-071111-5.fc10 ----------------- * Thu May 22 18:00:00 2008 Hans de Goede 071111-5 - Rebuild for new cegui amqp-1.0.656025-5.fc10 ---------------------- * Tue May 13 18:00:00 2008 Rafael Schloming - 0:1.0.656025-5 - Update the source tarball for MRG Beta 4 * Mon May 12 18:00:00 2008 Rafael Schloming - 0:1.0-5 - Imported new source tarball for MRG Beta 4 * Tue Apr 22 18:00:00 2008 Nuno Santos - 0:1.0-4 - Include 0-10 DTD bash-3.2-23.fc10 ---------------- * Thu May 22 18:00:00 2008 Roman Rakus - #446420 - COMP_WORDBREAKS settings now works bind-9.5.0-34.rc1.fc10 ---------------------- * Thu May 22 18:00:00 2008 Adam Tkac 32:9.5.0-34.rc1 - fixes needed to pass package review (#225614) * Wed May 21 18:00:00 2008 Adam Tkac 32:9.5.0-33.1.rc1 - bind-chroot now depends on bind (#446477) cairo-dock-1.5.5.4-5.svn1020_trunk.fc10 --------------------------------------- * Fri May 23 18:00:00 2008 Mamoru Tasaka - svn 1020 cegui-0.6.0-1.fc10 ------------------ * Sun May 18 18:00:00 2008 Hans de Goede 0.6.0-1 - New upstream release 0.6.0 - No ABI stability, use full versioned (libtool -release) sonames - Use system tolua++, change license tag to match - Use system tinyxml claws-mail-plugins-3.4.0-1.fc10.1 --------------------------------- * Wed Apr 23 18:00:00 2008 Andreas Bierfert - 3.4.0-1 - version upgrade cluster-2.99.02-3.fc10 ---------------------- * Thu May 22 18:00:00 2008 Fabio M. Di Nitto - 2.99.02-3 - New kernel-headers has what we need release. - Drop BR on kernel-devel. - Drop cluster-dlmheaders.patch. - Drop --kernel_* from configure invokation. - Cleanup a few comments in the spec file. conduit-0.3.10-4.fc10 --------------------- * Thu May 22 18:00:00 2008 Bernard Johnson - 0.3.10-4 - for real * Thu May 22 18:00:00 2008 Bernard Johnson - 0.3.10-3 - fix typo of typo * Thu May 22 18:00:00 2008 Bernard Johnson - 0.3.10-2 - fix typo in requirements crystalspace-1.2-5.fc10 ----------------------- * Mon May 19 18:00:00 2008 Hans de Goede 1.2-5 - Rebuild for new cegui - Work around redhat bugzilla bug 432185 on ppc by disabling python on ppc cwiid-0.6.00-8.fc10 ------------------- firefox-3.0-0.65.cvs20080416.fc10 --------------------------------- * Thu May 22 18:00:00 2008 Christopher Aillon 3.0-0.65 - Revert to 2008-04-16 trunk fsvs-1.1.15-2.fc10 ------------------ * Thu May 22 18:00:00 2008 David Fraser 1.1.15-2 - Bumping release number to fix up build through bodhi * Wed Apr 30 18:00:00 2008 David Fraser 1.1.15-1 - Upgraded to 1.1.15 * Wed Apr 2 18:00:00 2008 David Fraser 1.1.14-1 - Upgraded to 1.1.14 gdb-6.8-9.fc10 -------------- * Thu May 22 18:00:00 2008 Jan Kratochvil - 6.8-9 - Fix memory trashing on binaries from GNAT/Ada (workaround GCC PR 35998). * Thu May 15 18:00:00 2008 Tom "spot" Callaway - 6.8-8 - Silence memcpy check which returns false positive (sparc64) * Thu May 15 18:00:00 2008 Tom "spot" Callaway - 6.8-7 - patch from DaveM for sparc/sparc64 - touch up spec to enable sparcv9/sparc64 * Sat May 3 18:00:00 2008 Jan Kratochvil - 6.8-6 - Fix gdb.base/gcore-shmid0.exp to be unresolved on recent kernels. - Make the testsuite results of dfp-test.exp more stable. gnome-password-generator-1.6-1.fc10 ----------------------------------- * Sat May 17 18:00:00 2008 Debarshi Ray - 1.6-1 - Version bump to 1.6. Closes Red Hat Bugzilla bug #292541. gtk-qt-engine-1.1-2.fc10 ------------------------ * Thu May 22 18:00:00 2008 Rex Dieter 1:1.1-2 - Provides: gtk-qt-engine-kde4 kdeedu-4.0.72-3.fc10 -------------------- * Fri May 23 18:00:00 2008 Kevin Kofler 4.0.72-3 - put unversioned libanalitza.so in -libs instead of -devel (#448035) kdelibs-4.0.72-5.fc10 --------------------- * Thu May 22 18:00:00 2008 Kevin Kofler - 4.0.72-5 - keep libphonon.so in %{_libdir} for non-KDE apps (#447831) kernel-2.6.26-0.25.rc3.git4.fc10 -------------------------------- * Thu May 22 18:00:00 2008 Dave Jones - Fix gianfar build. * Thu May 22 18:00:00 2008 Dave Jones - 2.6.26-rc3-git4 * Wed May 21 18:00:00 2008 John W. Linville - libertas: Fix ethtool statistics - mac80211: fix NULL pointer dereference in ieee80211_compatible_rates - mac80211: don't claim iwspy support - rtl8187: resource leak in error case - hostap_cs: add ID for Conceptronic CON11CPro - orinoco_cs: add ID for SpeedStream wireless adapters * Wed May 21 18:00:00 2008 Dave Jones - 2.6.26-rc3-git3 * Tue May 20 18:00:00 2008 Dave Jones - 2.6.26-rc3-git1 * Mon May 19 18:00:00 2008 John W. Linville - mac80211 : Association with 11n hidden ssid ap. - libertas: fix command timeout after firmware failure - mac80211: Add RTNL version of ieee80211_iterate_active_interfaces - wireless: Create 'device' symlink in sysfs - hostap: fix "registers" registration in procfs - wireless, airo: waitbusy() won't delay - iwlwifi : Set monitor mode for 4965 - iwlwifi : Set monitor mode for 3945 - make sta_rx_agg_session_timer_expired() static - remove ieee80211_tx_frame() - remove ieee80211_wx_{get,set}_auth() - wireless: fix "iwlwifi: unify init driver flow" - iwl3945: do not delay hardware scan if it is a direct scan - ath5k: Fix loop variable initializations - zd1211rw: initial IBSS support - mac80211: use hardware flags for signal/noise units - mac80211: make rx radiotap header more flexible - iwlwifi: HW dependent run time calibration - iwlwifi: HW crypto acceleration fixes - iwlwifi: remove uneeded callback - iwlwifi: CT-Kill configuration fix - iwlwifi: HT IE in probe request clean up - iwlwifi: clean up register names and defines - iwlwifi: move Flow Handlers define to iwl-fh.h - iwlwifi: move verify_ucode functions to iwl-core - iwlwifi: move hw_rx_handler_setup to iwl-4965.c - iwlwifi-5000: update the CT-Kill value for 5000 series - iwlwifi-5000: add run time calibrations for 5000 - iwlwifi-5000: update the byte count in SCD - iwlwifi: move iwl4965_init_alive_start to iwl-4965.c - wireless: Add missing locking to cfg80211_dev_rename - mac80211: correct skb allocation - iwlwifi: move per driverdebug_level to per device - iwlwifi: move debug_level to sysfs/bus/pci/devices - iwlwifi: update levels of debug prints - iwlwifi: adding parameter of fw_restart - iwlwifi: remove support for Narrow Channel (10Mhz) - iwlwifi: HT antenna/chains overhaul - iwlwifi: TLC modifications - iwlwifi: rate scale module cleanups - iwlwifi: rate scale restructure toggle_antenna functions - iwlwifi: rs fix wrong parenthesizing in rs_get_lower_rate function - iwlwifi: rate sacaling fixes - iwlwifi: more RS improvements - mac80211: remove unnecessary byteshifts in frame control testing - wireless: use get/put_unaligned_* helpers - mac80211: tkip.c use kernel-provided infrastructure - b43: replace limit_value macro with clamp_val - b43legacy: replace limit_value macro with clamp_val - b43: use the bitrev helpers rather than rolling a private one - libertas: debug output tweaks for lbs_thread - libertas: make some functions void - libertas: allow removal of card at any time - libertas: remove lbs_get_data_rate() - b43: nphy.c remove duplicated include - mac80211: Replace ieee80211_tx_control->key_idx with ieee80211_key_conf - mac80211: Add IEEE80211_KEY_FLAG_PAIRWISE - rt2x00: Support hardware RTS and CTS-to-self frames - rt2x00: Remove DRIVER_SUPPORT_MIXED_INTERFACES - rt2x00: Use rt2x00 queue numbering - rt2x00: Add helper macros - rt2x00: Fix kernel-doc - rt2x00: Release rt2x00 2.1.5 - rt2x00: Clarify supported chipsets in Kconfig - mac80211: Set IEEE80211_TXPD_REQ_TX_STATUS for all TX frames - mac80211: a few code cleanups - mac80211: clean up get_tx_stats callback - mac80211: remove queue info from ieee80211_tx_status - mac80211: QoS related cleanups - mac80211: fix wme code - mac80211: require four hardware queues for QoS/HT - mac80211: proper STA info locking - mac80211: fix queue constant confusion - wireless: fix warning introduced by "mac80211: QoS related cleanups" - ssb: Allow reading of 440-byte SPROM that is not rev 4 - b43: Rewrite LO calibration algorithm - b43: Remove some dead code - b43: Don't disable IRQs in mac_suspend - iwlwifi: Add power level support - airo: use netstats in net_device structure - arlan: use netstats in net_device structure - atmel: use netstats in net_device structure - iwlwifi: arranging aggregation actions - iwlwifi: expanding HW parameters control - iwlwifi: support 64 bit DMA masks - iwlwifi: handle shared memory - iwlwifi: unify init driver flow - iwlwifi: iwl-sta redundant includes clean up - iwlwifi-5000: add iwl 5000 shared memory handlers - iwlwifi: map A-MPDU HW queue to mac80211 A-MPDU SW queue - iwlwifi-5000: rename iwl5000_init_nic to iwl5000_init_config - iwlwifi: create disable SCD Tx FIFOs handler - iwlwifi: move NIC init and Tx queues init to iwlcore - iwlwifi: handle shared memory Rx index access - iwlwifi: remove 4965 prefix from iwl4965_kw and iwl4965_tx_queue - iwlwifi: fix spinlock used before initialized - iwlwifi: move find station to iwl-sta.c - iwlwifi: cleanup set_pwr_src - iwlwifi: define ANA_PLL values in iwl-csr.h - iwlwifi: export int iwl4965_set_pwr_src - iwlwifi: changing EEPROM layout handling - iwlwifi: remove includes to net/ieee80211.h - iwlwifi: add apm init handler - iwlwifi: add iwl_hw_detect function to iwl core - iwlwifi: check eeprom version in pci probe time - iwlwifi: reorganize TX RX constatns - iwlwifi: 3945 remove unused SCD definitions - iwlwifi: remove 49 prefix from general CSR values - iwlwifi: remove unnecessary apmg settings - iwlwifi: wrapping nic configuration in iwl core handler - iwlwifi-5000: adding initial recognition for the 5000 family - iwlwifi-5000: add ops infrastructure for 5000 - iwlwifi-5000: add apm_init handler for 5000 HW family - iwlwifi-5000: use iwl4965_set_pwr_src in 5000 - iwlwifi-5000: EEPROM settings for 5000 - iwlwifi-5000: adding iwl5000 HW parameters - iwlwifi-5000: adjust antennas names in 5000 HW family - iwlwifi-5000: Add HW REV of 5000 HW family - iwlwifi-5000: add eeprom check version handler - iwlwifi-5000: add nic config handler for 5000 HW - iwlwifi: rename iwl-4965-commands to iwl-commands.h - iwlwifi: rename iwl-4965.h to iwl-dev.h - iwlwifi: move RX code to iwl-rx.c - iwlwifi: don't override association channel with control channel - iwlwifi: remove 4965 from station_entry - iwlwifi: debugfs EEPROM dump - iwlwifi: remove 4965 from rx_packet - iwlwifi: generalize iwl4965_send_add_station function - iwlwifi-5000: add build_addsta_hcmd handler for 5000 HW - iwlwifi: move iwl4965_set_rxon_ht into iwlcore - iwlwifi: compile iwl-sta into iwlcore - iwlwifi: add device sysfs version entry - at76: use hardware flags for signal/noise units * Mon May 19 18:00:00 2008 Dave Jones - Disable PATA_ISAPNP (it's busted). lcov-1.6-1.fc10 --------------- * Thu May 22 18:00:00 2008 Roland McGrath - 1.6-1 - Update to 1.6 release. - Fix License: tag. man-pages-ja-20080515-2.fc10 ---------------------------- * Fri May 23 18:00:00 2008 Akira TAGOH - 20080515-2 - correct the description of 'continue' built-in command in bash(1). moodle-1.9.1-1.fc10 ------------------- * Thu May 22 18:00:00 2008 Jon Ciesla - 1.9.1-1 - Update to 1.9.1. - Updated language packs to 22 May 2008 versions. - Added Welsh, Uzbek support. - Added php-xmlrpc Requires. ncview-1.93c-2.fc10 ------------------- * Thu Apr 10 18:00:00 2008 Patrice Dumas - 1.93c-2 - update to 1.93c ogre-1.4.8-2.fc10 ----------------- * Thu May 22 18:00:00 2008 Hans de Goede 1.4.8-2 - Rebuild for new cegui - Use system tinyxml (bz 447698) opengrok-0.6.1-2.fc10 --------------------- * Thu May 22 18:00:00 2008 Lubomir Rintel 0.6.1-2 - Tolerate svn-javahl not being in correct directory, in RHEL5 - Replace sed-mungled configuration with hardcoded, so that stamps don't change perl-Algorithm-CheckDigits-0.49-1.fc10 -------------------------------------- * Thu May 22 18:00:00 2008 Xavier Bachelot - 0.49-1 - Update to 0.49. perl-Catalyst-Action-RenderView-0.08-1.fc10 ------------------------------------------- * Wed May 21 18:00:00 2008 Chris Weyl 0.08-1 - update to 0.08 perl-Catalyst-Plugin-SubRequest-0.13-1.fc10 ------------------------------------------- * Wed May 21 18:00:00 2008 Chris Weyl 0.13-1 - update to 0.13 perl-Class-Accessor-Grouped-0.08001-1.fc10 ------------------------------------------ * Wed May 21 18:00:00 2008 Chris Weyl 0.08001-1 - update to 0.08001 perl-Digest-CRC-0.14-1.fc10 --------------------------- * Thu May 22 18:00:00 2008 Christopher Stone 0.14-1 - Upstream sync perl-Event-1.11-1.fc10 ---------------------- * Wed May 21 18:00:00 2008 Chris Weyl 1.11-1 - update to 1.11 perl-Net-eBay-0.48-1.fc10 ------------------------- * Thu May 22 18:00:00 2008 Xavier Bachelot - 0.48-1 - Update to 0.45. perl-PDF-API2-0.69-5.fc10 ------------------------- * Thu May 22 18:00:00 2008 Bernard Johnson - 0.69-5 - bump rel for new sources in F-7 * Thu May 22 18:00:00 2008 Bernard Johnson - 0.69-4 - fix dejavu font path (bz #447505) perl-WWW-Search-2.501-1.fc10 ---------------------------- * Thu May 15 18:00:00 2008 Xavier Bachelot - 2.501-1 - New upstream version 2.501. php-pear-Date-Holidays-0.19.1-1.fc10 ------------------------------------ * Thu May 22 18:00:00 2008 Christopher Stone 0.19.1-1 - Upstream sync php-pear-Net-Curl-1.2.5-1.fc10 ------------------------------ * Thu May 22 18:00:00 2008 Christopher Stone 1.2.5-1 - Upstream sync - Change license to BSD - Add empty %build section php-pear-PHPUnit-3.2.19-1.fc10 ------------------------------ * Thu May 22 18:00:00 2008 Christopher Stone 3.2.19-1 - Upstream sync php-pear-Pager-2.4.6-1.fc10 --------------------------- * Thu May 22 18:00:00 2008 Christopher Stone 2.4.6-1 - Upstream sync php-pear-Payment-Process-0.6.6-1.fc10 ------------------------------------- * Thu May 22 18:00:00 2008 Christopher Stone 0.6.6-1 - Upstream sync - Update License - Add empty build section - Fix rpmlint warnings php-pecl-xdebug-2.0.3-1.fc10 ---------------------------- * Thu May 22 18:00:00 2008 Christopher Stone 2.0.3-1 - Upstream sync - Clean up libedit usage - Minor rpmlint fix Broken deps for i386 ---------------------------------------------------------- LabPlot-1.5.1.6-4.fc8.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libMagick.so.10 basket-kontact-1.0.2-5.fc9.i386 requires libkpinterfaces.so.1 basket-kontact-1.0.2-5.fc9.i386 requires libkcal.so.2 basket-kontact-1.0.2-5.fc9.i386 requires libktnef.so.1 basket-kontact-1.0.2-5.fc9.i386 requires kdepim3 basket-kontact-1.0.2-5.fc9.i386 requires libkdepim.so.1 chess-1.0-14.fc10.i386 requires libCEGUIBase.so.1 evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.i386 requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-1.2.so.11 kismet-extras-0.0.2007.10.R1-3.fc9.i386 requires libMagick.so.10 koffice-karbon-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-karbon-1.6.3-15.fc9.i386 requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libMagick.so.10 libopensync-plugin-kdepim-0.35-2.fc9.i386 requires libkcal.so.2 lsvpd-1.6.4-1.fc10.i386 requires libvpd_cxx-2.0.so.1 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.i386 requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.i386 requires libgeos.so.2 smart-0.52-54.fc9.i386 requires smart-config taskjuggler-2.4.1-1.fc10.i386 requires libkcal.so.2 taskjuggler-2.4.1-1.fc10.i386 requires libktnef.so.1 taskjuggler-libs-2.4.1-1.fc10.i386 requires libkcal.so.2 tellico-1.3.1-1.fc9.i386 requires libkcal.so.2 tellico-1.3.1-1.fc9.i386 requires libktnef.so.1 Broken deps for x86_64 ---------------------------------------------------------- LabPlot-1.5.1.6-4.fc8.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libMagick.so.10 LabPlot-1.5.1.6-4.fc8.x86_64 requires libMagick++.so.10()(64bit) LabPlot-1.5.1.6-4.fc8.x86_64 requires libMagick.so.10()(64bit) LabPlot-1.5.1.6-4.fc8.x86_64 requires libWand.so.10()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires libkcal.so.2()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires libkdepim.so.1()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires libktnef.so.1()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires kdepim3 basket-kontact-1.0.2-5.fc9.x86_64 requires libkpinterfaces.so.1()(64bit) chess-1.0-14.fc10.x86_64 requires libCEGUIBase.so.1()(64bit) evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libWand.so.10()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx kismet-extras-0.0.2007.10.R1-3.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.x86_64 requires libWand.so.10()(64bit) koffice-libs-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.x86_64 requires libWand.so.10()(64bit) libopensync-plugin-kdepim-0.35-2.fc9.x86_64 requires libkcal.so.2()(64bit) lsvpd-1.6.4-1.fc10.x86_64 requires libvpd_cxx-2.0.so.1()(64bit) perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) smart-0.52-54.fc9.x86_64 requires smart-config taskjuggler-2.4.1-1.fc10.x86_64 requires libkcal.so.2()(64bit) taskjuggler-2.4.1-1.fc10.x86_64 requires libktnef.so.1()(64bit) taskjuggler-libs-2.4.1-1.fc10.i386 requires libkcal.so.2 taskjuggler-libs-2.4.1-1.fc10.x86_64 requires libkcal.so.2()(64bit) tellico-1.3.1-1.fc9.x86_64 requires libkcal.so.2()(64bit) tellico-1.3.1-1.fc9.x86_64 requires libktnef.so.1()(64bit) Broken deps for ppc ---------------------------------------------------------- LabPlot-1.5.1.6-4.fc8.ppc requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.ppc requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.ppc requires libMagick.so.10 basket-kontact-1.0.2-5.fc9.ppc requires libkpinterfaces.so.1 basket-kontact-1.0.2-5.fc9.ppc requires libkcal.so.2 basket-kontact-1.0.2-5.fc9.ppc requires libktnef.so.1 basket-kontact-1.0.2-5.fc9.ppc requires kdepim3 basket-kontact-1.0.2-5.fc9.ppc requires libkdepim.so.1 chess-1.0-14.fc10.ppc requires libCEGUIBase.so.1 evolution-brutus-1.2.11-2.fc9.ppc requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.ppc requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.ppc requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.ppc requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-1.2.so.11 kismet-extras-0.0.2007.10.R1-3.fc9.ppc requires libMagick.so.10 koffice-karbon-1.6.3-15.fc9.ppc requires libWand.so.10 koffice-karbon-1.6.3-15.fc9.ppc requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.ppc requires libWand.so.10 koffice-libs-1.6.3-15.fc9.ppc requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) libopensync-plugin-kdepim-0.35-2.fc9.ppc requires libkcal.so.2 lsvpd-1.6.4-1.fc10.ppc requires libvpd_cxx-2.0.so.1 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.ppc requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.ppc requires libgeos.so.2 smart-0.52-54.fc9.ppc requires smart-config taskjuggler-2.4.1-1.fc10.ppc requires libkcal.so.2 taskjuggler-2.4.1-1.fc10.ppc requires libktnef.so.1 taskjuggler-libs-2.4.1-1.fc10.ppc requires libkcal.so.2 taskjuggler-libs-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) tellico-1.3.1-1.fc9.ppc requires libkcal.so.2 tellico-1.3.1-1.fc9.ppc requires libktnef.so.1 Broken deps for ppc64 ---------------------------------------------------------- basket-kontact-1.0.2-5.fc9.ppc64 requires libkcal.so.2()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires libkdepim.so.1()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires libktnef.so.1()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires kdepim3 basket-kontact-1.0.2-5.fc9.ppc64 requires libkpinterfaces.so.1()(64bit) chess-1.0-14.fc10.ppc64 requires libCEGUIBase.so.1()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) kismet-extras-0.0.2007.10.R1-3.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) libopensync-plugin-kdepim-0.35-2.fc9.ppc64 requires libkcal.so.2()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot lsvpd-1.6.4-1.fc10.ppc64 requires libvpd_cxx-2.0.so.1()(64bit) perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) smart-0.52-54.fc9.ppc64 requires smart-config taskjuggler-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) taskjuggler-2.4.1-1.fc10.ppc64 requires libktnef.so.1()(64bit) taskjuggler-libs-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) tellico-1.3.1-1.fc9.ppc64 requires libkcal.so.2()(64bit) tellico-1.3.1-1.fc9.ppc64 requires libktnef.so.1()(64bit) From harald at redhat.com Fri May 23 10:35:21 2008 From: harald at redhat.com (Harald Hoyer) Date: Fri, 23 May 2008 12:35:21 +0200 Subject: Neon Sign In-Reply-To: References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211462088.4891.45.camel@victoria> <48357E29.2010609@nobugconsulting.ro> <1211466316.5079.61.camel@localhost.localdomain> <1211466224.3559.48.camel@cutter> <1211467352.5079.65.camel@localhost.localdomain> <483587E7.2020300@nobugconsulting.ro> <1211486081.4891.113.camel@victoria> <7f692fec0805221329s25298462w5d75eac7626c0bfe@mail.gmail.com> Message-ID: Harald Hoyer wrote: > Hmm, I liked the idea and inkscaped s.th. together :) > > Somebody can make an animated png out of it ... blinking :) > > http://harald.fedorapeople.org/Fedora-always-open.png > http://harald.fedorapeople.org/Fedora-always-open.svg > http://harald.fedorapeople.org/always-open/ From billcrawford1970 at gmail.com Fri May 23 11:18:32 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Fri, 23 May 2008 12:18:32 +0100 Subject: New system-config-acpid In-Reply-To: <409676c70805222215n4b30c80h7d516d5140a28ee7@mail.gmail.com> References: <48207BC5.3060105@redhat.com> <20080506154407.GA21822@nostromo.devel.redhat.com> <1210089619.17842.2.camel@localhost.localdomain> <409676c70805222215n4b30c80h7d516d5140a28ee7@mail.gmail.com> Message-ID: <544eb990805230418j636b2957oa618865440d36f80@mail.gmail.com> 2008/5/23 Trond Danielsen : > I think this is a great thing because it makes my laptop behave as it > should even if I am not currently logged in (suspend when battery is > low, power management etc.). You shouldn't need a full "desktop environment" for that. It's been like this: Hey, let's make all these important things like managing wireless connectivity be done on the user's desktop. Hey, let's make all this stuff work in the login manager by pretending someone's logged in. ... why not just make the stuff work without requiring desktop-oriented tools to be running as part of a login session? Suspending should be handled "behind the scenes". From dcbw at redhat.com Fri May 23 11:31:33 2008 From: dcbw at redhat.com (Dan Williams) Date: Fri, 23 May 2008 07:31:33 -0400 Subject: NetworkManager: I want to believe, but... In-Reply-To: <200805231156.24832.opensource@till.name> References: <3da3b5b40805161502w62f372dseca0ab6310e44447@mail.gmail.com> <1211509501.19171.7.camel@aglarond.local> <20080523035023.GB12797@jadzia.bu.edu> <200805231156.24832.opensource@till.name> Message-ID: <1211542293.30036.6.camel@localhost.localdomain> On Fri, 2008-05-23 at 11:56 +0200, Till Maas wrote: > On Fri May 23 2008, Matthew Miller wrote: > > On Thu, May 22, 2008 at 10:25:01PM -0400, Jeremy Katz wrote: > > > > No, we probably *do* want people using NetworkManager here because > > > maintaining two entirely orthogonal network stacks is somewhat insane > > > and makes the rest of the system harder to manage. > > > > Right, now *this* one I see as a strong selling point -- but it's selling > > more to the system developers than to sysadmins (and, presumably, > > enterprise Linux customers, if that's on anyone's mind...). > > It is also helpful for users, e.g. I use my notebook sometimes in places where > it gets a dynamic ip address, sometimes where it has its static ip address. > Here it would also be nice to have only one tool that can handle both instead > of two that can handle only some parts. Right; simply because you don't keep your laptop in one place all the time, it's definitely a candidate for NM. Dan From bnocera at redhat.com Fri May 23 11:31:20 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Fri, 23 May 2008 12:31:20 +0100 Subject: New system-config-acpid In-Reply-To: <544eb990805230418j636b2957oa618865440d36f80@mail.gmail.com> References: <48207BC5.3060105@redhat.com> <20080506154407.GA21822@nostromo.devel.redhat.com> <1210089619.17842.2.camel@localhost.localdomain> <409676c70805222215n4b30c80h7d516d5140a28ee7@mail.gmail.com> <544eb990805230418j636b2957oa618865440d36f80@mail.gmail.com> Message-ID: <1211542280.3566.53.camel@cookie.hadess.net> On Fri, 2008-05-23 at 12:18 +0100, Bill Crawford wrote: > 2008/5/23 Trond Danielsen : > > > I think this is a great thing because it makes my laptop behave as it > > should even if I am not currently logged in (suspend when battery is > > low, power management etc.). > > You shouldn't need a full "desktop environment" for that. It's been like this: It's only misinformed people who say there's a "full desktop environment" there. > Hey, let's make all these important things like managing wireless > connectivity be done on the user's desktop. > Hey, let's make all this stuff work in the login manager by pretending > someone's logged in. > > ... why not just make the stuff work without requiring > desktop-oriented tools to be running as part of a login session? > Suspending should be handled "behind the scenes". It's already behing the scenes. Just that the policy belongs in gnome-power-manager, which will show us a nice battery icon for us. Would you want to rewrite gnome-power-manager instead of using a cut down version? We also need a background wallpaper, and sound for accessibility reasons, as well as a keyboard layout switcher so we let gnome-settings-daemon handle those. There might be a few windows popping up, so we could rewrite a smaller window manager (which we'd need to debug, and fix separately, or we use metacity instead. It's not a full desktop environment, it's cut-down versions of the software in the desktop, and only carefully selected software is run. From kanarip at kanarip.com Fri May 23 11:34:57 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 23 May 2008 13:34:57 +0200 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1211474646.4891.72.camel@victoria> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <48358677.2040807@hi.is> <3E241CC6FB3A4A498507355A8E917197@internal.onecool.com> <48359955.6000109@onecool.com> <1211474646.4891.72.camel@victoria> Message-ID: <4836ABE1.8090106@kanarip.com> Paul W. Frields wrote: > I'm absolutely certain that we don't want to look like copycats. :-) > lolcatz would be more appropriate ;-) -Jeroen From stickster at gmail.com Fri May 23 11:50:03 2008 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 23 May 2008 07:50:03 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080522170718.GE8819@nostromo.devel.redhat.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <20080522170718.GE8819@nostromo.devel.redhat.com> Message-ID: <1211543403.23635.3.camel@victoria> On Thu, 2008-05-22 at 13:07 -0400, Bill Nottingham wrote: > Josh Boyer (jwboyer at gmail.com) said: > > I will be collecting suggestions for 1 week, so the cutoff for names is: > > > > May 29, 2008 > > OK, so things Sulphur is: - A kind of butterfly. Monarch? -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-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 gmail.com Fri May 23 11:54:27 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 23 May 2008 06:54:27 -0500 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <58a220fa0805220558n5806546ala2f789c283265dec@mail.gmail.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <7f692fec0805220547m5b31417eo3a2baf681b8a4878@mail.gmail.com> <58a220fa0805220558n5806546ala2f789c283265dec@mail.gmail.com> Message-ID: <20080523065427.6b5420b4@vader.jdub.homelinux.org> On Thu, 22 May 2008 14:58:19 +0200 M wrote: > 2008/5/22 Yaakov Nemoy : > > On Thu, May 22, 2008 at 7:57 AM, Josh Boyer wrote: > >> Let the naming begin! We're starting very early this time around in > >> the name game for F10. So, let the suggestions flow! > >> > >> Remember the rules: > >> > >> 1) must have some link to Sulphur > >> > >> More specifically, the link should be > >> Sulphur is a and > >> is a > >> Where is the same for both > >> > >> 2) The link between and Sulphur cannot be the same as between > >> Werewolf and Sulphur. That link was "things that react badly with > >> silver". > > > > Sulphur is yellow and so are Sunflowers. > > > > Sulphur is yellow and so are Jararacas > http://pl.wikipedia.org/wiki/Grafika:%C5%BBararaka_z%C5%82ota.JPG That doesn't follow the "is a" form. josh From balajig81 at gmail.com Fri May 23 11:56:09 2008 From: balajig81 at gmail.com (G) Date: Fri, 23 May 2008 17:26:09 +0530 Subject: Account in Fedorapeople.org and planet fedora Message-ID: <6dd1343e0805230456i778b403ds6d02973ba8a605cd@mail.gmail.com> Hi I am sorry if this is not the right forum to ask this question.My Name is Balaji and i am a fedora contributor. I am part of the Ambassadors, Docs and bug triage team. I am planning to set up my blog and i just would like to know whether i am eligible for an account in fedorapeople.org which in turn would help me to add my blog to planet fedora. I was unable to find my name in the fedorapeople.org .Should i do something to get my name added there or i am not eligible for it ? My FAS login ID is balajig8 Thanks, Cheers, Balaji From jwboyer at gmail.com Fri May 23 11:57:02 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 23 May 2008 06:57:02 -0500 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <48366095.50204@mindspring.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <48366095.50204@mindspring.com> Message-ID: <20080523065702.1e021094@vader.jdub.homelinux.org> On Fri, 23 May 2008 02:13:41 -0400 Richard Hally wrote: > Josh Boyer wrote: > > Let the naming begin! We're starting very early this time around in > > the name game for F10. So, let the suggestions flow! > > > > Remember the rules: > > > > 1) must have some link to Sulphur > > > > More specifically, the link should be > > Sulphur is a and > > is a > > Where is the same for both > > > > 2) The link between and Sulphur cannot be the same as between > > Werewolf and Sulphur. That link was "things that react badly with > > silver". > > > > I will be collecting suggestions for 1 week, so the cutoff for names is: > > > > May 29, 2008 > > > > Suggestions will be run through the legal queue and an election will > > happen for Fedora contributors to pick the next Fedora name. > > > > josh > > > > Acid -- "we are all on Acid" or "give it an Acid test" > > sulfur is a chemical -> acid is a chemical. Sulfur is an element, not a chemical. josh From tnorth at fedoraproject.org Fri May 23 12:00:56 2008 From: tnorth at fedoraproject.org (Thibault North) Date: Fri, 23 May 2008 14:00:56 +0200 Subject: Account in Fedorapeople.org and planet fedora In-Reply-To: <6dd1343e0805230456i778b403ds6d02973ba8a605cd@mail.gmail.com> References: <6dd1343e0805230456i778b403ds6d02973ba8a605cd@mail.gmail.com> Message-ID: <8e967d910805230500r41078d06la8c8e6690f559205@mail.gmail.com> On Fri, May 23, 2008 at 1:56 PM, G wrote: > Hi > > I am sorry if this is not the right forum to ask this question.My Name > is Balaji and i am a fedora contributor. I am part of the Ambassadors, > Docs and bug triage team. I am planning to set up my blog and i just > would like to know whether i am eligible for an account in > fedorapeople.org which in turn would help me to add my blog to planet > fedora. I was unable to find my name in the fedorapeople.org .Should > i do something to get my name added there or i am not eligible for it ? To have your name on fedoapeople.org, just login to fedorapeople with SSH and mkdir ~/public_html . Maybe you will also need to touch index..html. Your name should appear soon after that. > > My FAS login ID is balajig8 > > Thanks, > > Cheers, > Balaji > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From jonstanley at gmail.com Fri May 23 12:02:51 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Fri, 23 May 2008 08:02:51 -0400 Subject: Account in Fedorapeople.org and planet fedora In-Reply-To: <6dd1343e0805230456i778b403ds6d02973ba8a605cd@mail.gmail.com> References: <6dd1343e0805230456i778b403ds6d02973ba8a605cd@mail.gmail.com> Message-ID: On Fri, May 23, 2008 at 7:56 AM, G wrote: > would like to know whether i am eligible for an account in > fedorapeople.org which in turn would help me to add my blog to planet The front page of fedorapeople.org only lists people that have HTML content there. By virtue of being a Fedora contributor (the technical requirement is CLA done and at least one other group in FAS, which you meet), then you already have an account on fedorapeople.org. Just ssh to the box, using the SSH key that you uploaded to FAS, and create the .planet file. Note that the planet is not actually using this new configuration mechanism yet, but it will in the near future. If you want the blog added prior to that, just send a mail to admin at fedoraproject.org From jwboyer at gmail.com Fri May 23 12:05:24 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 23 May 2008 07:05:24 -0500 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <16de708d0805222336s34d62ef3y26216bcbfbf252e1@mail.gmail.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211465906.3935.107.camel@localhost.localdomain> <1218b5bc0805222327s52328183s224af7c2db4b293f@mail.gmail.com> <16de708d0805222336s34d62ef3y26216bcbfbf252e1@mail.gmail.com> Message-ID: <20080523070524.5b6e3527@vader.jdub.homelinux.org> On Fri, 23 May 2008 01:36:35 -0500 "Arthur Pemberton" wrote: > 2008/5/23 Callum Lerwick : > > On Thu, May 22, 2008 at 9:18 AM, Simo Sorce wrote: > >> > >> Steam is released by a modern combustion engine, Suplhur as well. > >> > >> And this would make some connection with SteamPunk too ? > > > > Possible trademark issues with Valve's content distribution platform: > > I have to say, all this trademark stuff is getting depressing. Sorry > for the off-topic comment. It's a fact of life. Taxes are depressing as well. josh From opensource at till.name Fri May 23 12:07:31 2008 From: opensource at till.name (Till Maas) Date: Fri, 23 May 2008 14:07:31 +0200 Subject: Account in Fedorapeople.org and planet fedora In-Reply-To: <6dd1343e0805230456i778b403ds6d02973ba8a605cd@mail.gmail.com> References: <6dd1343e0805230456i778b403ds6d02973ba8a605cd@mail.gmail.com> Message-ID: <200805231407.37952.opensource@till.name> On Fri May 23 2008, "G" wrote: > I am sorry if this is not the right forum to ask this question.My Name > is Balaji and i am a fedora contributor. I am part of the Ambassadors, > Docs and bug triage team. I am planning to set up my blog and i just > would like to know whether i am eligible for an account in > fedorapeople.org which in turn would help me to add my blog to planet > fedora. I was unable to find my name in the fedorapeople.org .Should > i do something to get my name added there or i am not eligible for it ? Did you try to login to fedorapeople.org via ssh with your FAS username and the matching ssh key? Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From jwboyer at gmail.com Fri May 23 12:11:44 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 23 May 2008 07:11:44 -0500 Subject: OCHRE (was: Re: Werewolf -> Sulphur -> ? Sulphur is a , is a ) In-Reply-To: <20080522120933.GA23317@amd.home.annexia.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <20080522120933.GA23317@amd.home.annexia.org> Message-ID: <20080523071144.42325a8e@vader.jdub.homelinux.org> On Thu, 22 May 2008 13:09:33 +0100 "Richard W.M. Jones" wrote: > On Thu, May 22, 2008 at 06:57:24AM -0500, Josh Boyer wrote: > > 2) The link between and Sulphur cannot be the same as between > > Werewolf and Sulphur. That link was "things that react badly with > > silver". > > OCHRE > > (the connection is that both are yellow) But it doesn't fit the "is a" rule. josh From jbowes at redhat.com Fri May 23 12:15:10 2008 From: jbowes at redhat.com (James Bowes) Date: Fri, 23 May 2008 08:15:10 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1211543403.23635.3.camel@victoria> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <20080522170718.GE8819@nostromo.devel.redhat.com> <1211543403.23635.3.camel@victoria> Message-ID: <20080523121509.GC27748@crux.yyz.redhat.com> On Fri, May 23, 2008 at 07:50:03AM -0400, Paul W. Frields wrote: > On Thu, 2008-05-22 at 13:07 -0400, Bill Nottingham wrote: > > Josh Boyer (jwboyer at gmail.com) said: > > > I will be collecting suggestions for 1 week, so the cutoff for names is: > > > > > > May 29, 2008 > > > > OK, so things Sulphur is: > > - A kind of butterfly. > > Monarch? Then Fedora 11 can be "Doctor Girlfriend" http://en.wikipedia.org/wiki/Monarch_(The_Venture_Bros.) -James -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From balajig81 at gmail.com Fri May 23 12:15:33 2008 From: balajig81 at gmail.com (G) Date: Fri, 23 May 2008 17:45:33 +0530 Subject: Account in Fedorapeople.org and planet fedora In-Reply-To: <8e967d910805230500r41078d06la8c8e6690f559205@mail.gmail.com> References: <6dd1343e0805230456i778b403ds6d02973ba8a605cd@mail.gmail.com> <8e967d910805230500r41078d06la8c8e6690f559205@mail.gmail.com> Message-ID: <6dd1343e0805230515r744d2cc1i39f494d0561d69e2@mail.gmail.com> Hi Thibault Thanks for the information. Will try that Cheers, Balaji On 5/23/08, Thibault North wrote: > On Fri, May 23, 2008 at 1:56 PM, G wrote: > > Hi > > > > I am sorry if this is not the right forum to ask this question.My Name > > is Balaji and i am a fedora contributor. I am part of the Ambassadors, > > Docs and bug triage team. I am planning to set up my blog and i just > > would like to know whether i am eligible for an account in > > fedorapeople.org which in turn would help me to add my blog to planet > > fedora. I was unable to find my name in the fedorapeople.org .Should > > i do something to get my name added there or i am not eligible for it ? > > > To have your name on fedoapeople.org, just login to fedorapeople with > SSH and mkdir ~/public_html . > Maybe you will also need to touch index..html. Your name should appear > soon after that. > > > > > > My FAS login ID is balajig8 > > > > Thanks, > > > > Cheers, > > Balaji > > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From billcrawford1970 at gmail.com Fri May 23 12:17:49 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Fri, 23 May 2008 13:17:49 +0100 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1nfig5xbv1.ln2@ppp1053.in.ipex.cz> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211474199.29467.204.camel@localhost.localdomain> <544eb990805220943i4311e61bg58517a76695980e@mail.gmail.com> <1nfig5xbv1.ln2@ppp1053.in.ipex.cz> Message-ID: <544eb990805230517k54f460c0k71d4b3d903f2d4ee@mail.gmail.com> 2008/5/23 Matej Cepl : > And I am sure mimho would create logos for that ;-). Well, ... the possibilities are endless: A bunch of (fluorescent coloured) straws. A doily. A difference engine (that would fit the steam punk theme which a number of people have mentioned elsewhere). A portrait of Ada. A portrait of Linda. ... I like that steam punk thing. The "feersum enjinn" (spelling?) connection is good. I like Victorian themes (the whole sepia photography thing, plus early steps towards the "gentleman inventor" culture. So ... How about simply ... Xenon. - It's symbol is X (but it's not the name), which is the same as the release number. - It's an element. - It really promotes the "science lab" possibilities of Fedora. - We could be the *second* example of a Xenon-Sulfur bond (see http://pubs.acs.org/cgi-bin/abstract.cgi/jacsat/1998/120/i31/abs/ja981032d.html ...) - A mixture of Xenon and Sulfur was proposed for LAMPs (see http://members.misty.com/don/sulfbulb.html ...) - I'll stop now. > Mat?j Bill From walters at verbum.org Fri May 23 12:19:25 2008 From: walters at verbum.org (Colin Walters) Date: Fri, 23 May 2008 08:19:25 -0400 Subject: PyLucene: How to package libraries that link against OpenJDK libraries? In-Reply-To: <48368AB5.2080405@redhat.com> References: <4835E696.1010401@oss.schwarz.eu> <48368AB5.2080405@redhat.com> Message-ID: On Fri, May 23, 2008 at 5:13 AM, Andrew Haley wrote: > > Interesting. What multilib-awareness do you think we need? It's not > immediately clear to me where the beinefit would be. Code calling System.loadLibrary (i.e. most software out there that wants to dlopen) would work. From billcrawford1970 at gmail.com Fri May 23 12:21:26 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Fri, 23 May 2008 13:21:26 +0100 Subject: New system-config-acpid In-Reply-To: <1211542280.3566.53.camel@cookie.hadess.net> References: <48207BC5.3060105@redhat.com> <20080506154407.GA21822@nostromo.devel.redhat.com> <1210089619.17842.2.camel@localhost.localdomain> <409676c70805222215n4b30c80h7d516d5140a28ee7@mail.gmail.com> <544eb990805230418j636b2957oa618865440d36f80@mail.gmail.com> <1211542280.3566.53.camel@cookie.hadess.net> Message-ID: <544eb990805230521p75645e7ar8f7835c5d70bbb14@mail.gmail.com> 2008/5/23 Bastien Nocera : > It's already behing the scenes. Just that the policy belongs in > gnome-power-manager, which will show us a nice battery icon for us. GNOME power manager? Not everyone wants to use that, y'know. > Would you want to rewrite gnome-power-manager instead of using a cut > down version? Because I don't use GNOME? > We also need a background wallpaper, and sound for accessibility > reasons, as well as a keyboard layout switcher so we let > gnome-settings-daemon handle those. There might be a few windows popping > up, so we could rewrite a smaller window manager (which we'd need to > debug, and fix separately, or we use metacity instead. Sound, sure. That again points to a "system wide" solution instead of "desktop centric" ones like PA. > It's not a full desktop environment, it's cut-down versions of the > software in the desktop, and only carefully selected software is run. Still going the wrong way, stuff should be developed that isn't dependent on being "part of a desktop" in the first place. From walters at verbum.org Fri May 23 12:25:53 2008 From: walters at verbum.org (Colin Walters) Date: Fri, 23 May 2008 08:25:53 -0400 Subject: NetworkManager: I want to believe, but... [was Re: F9 potential service network bug?] In-Reply-To: <20080523034708.GA12797@jadzia.bu.edu> References: <3da3b5b40805161502w62f372dseca0ab6310e44447@mail.gmail.com> <3da3b5b40805161522i2300f1cdhb1fc7b074084873f@mail.gmail.com> <604aa7910805161527j6b193c6dj2af4248155d5cdaf@mail.gmail.com> <20080517112856.GA18698@jadzia.bu.edu> <1211069083.3070.392.camel@cookie.hadess.net> <20080522142554.GB8728@jadzia.bu.edu> <1211472267.5352.25.camel@localhost.localdomain> <20080523021725.GA5233@jadzia.bu.edu> <1211509568.19171.9.camel@aglarond.local> <20080523034708.GA12797@jadzia.bu.edu> Message-ID: On Thu, May 22, 2008 at 11:47 PM, Matthew Miller wrote: > > But "is the network up" a generally useful question? Yes. --Colin, who just finished last night implementing much improved network status handling in his SSH client via NetworkManager http://svn.gnome.org/viewvc/hotwire-ssh/trunk/hotssh/sshwindow.py?limit_changes=100&r1=4&r2=5&pathrev=5 From naheemzaffar at gmail.com Fri May 23 12:42:36 2008 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Fri, 23 May 2008 13:42:36 +0100 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <1211379900.29467.136.camel@localhost.localdomain> <20080521152022.GF1093879@hiwaay.net> <1211383722.8531.63.camel@localhost.localdomain> <1211385285.8531.65.camel@localhost.localdomain> Message-ID: <3adc77210805230542t126e5d62i76e9234a105d622a@mail.gmail.com> I think it also needs to be made clear that free drivers shipped with Fedora DO work. so something along the lines of: *Proprietary (third party) video drivers* Fedora ships a pre-release of the next version of the xorg which has a new ABI. All drivers contained within fedora have been ported to use this ABI and mostly work as expected. However, third part drivers from some vendors (AMD and nVidia) have not yet been made compatible with this new xorg ABI. If your use of the computer depends on these proprietary drivers, then you are strongly advise to either not upgrade to Fedora 9 yet, exclude xorg\* packages from upgrade (when using yum upgrade), or downgrade your xorg\* packages back to those in Fedora 8 after installation (when using upgrade from DVD). (second para mostly taken as is from Matej Cepl's email.) (as for status of fglrx, it has a new release yesterday, but it seems only compatibility for the kernel 2.6.25 was added, not the new xorg ABI) From balajig81 at gmail.com Fri May 23 12:57:23 2008 From: balajig81 at gmail.com (G) Date: Fri, 23 May 2008 18:27:23 +0530 Subject: Account in Fedorapeople.org and planet fedora In-Reply-To: <6dd1343e0805230515r744d2cc1i39f494d0561d69e2@mail.gmail.com> References: <6dd1343e0805230456i778b403ds6d02973ba8a605cd@mail.gmail.com> <8e967d910805230500r41078d06la8c8e6690f559205@mail.gmail.com> <6dd1343e0805230515r744d2cc1i39f494d0561d69e2@mail.gmail.com> Message-ID: <6dd1343e0805230557t4f7642b7k732e28b2e12602bd@mail.gmail.com> Hi I find that the SSH Key what i enter is not valid. I ve forgotten the key and ve installed Fedora 9 and i guess i ve lost the saved key too. Is there any way that i can retrieve it ? Cheers, Balaji On 5/23/08, G wrote: > Hi Thibault > > Thanks for the information. Will try that > > Cheers, > Balaji > > > > On 5/23/08, Thibault North wrote: > > On Fri, May 23, 2008 at 1:56 PM, G wrote: > > > Hi > > > > > > I am sorry if this is not the right forum to ask this question.My Name > > > is Balaji and i am a fedora contributor. I am part of the Ambassadors, > > > Docs and bug triage team. I am planning to set up my blog and i just > > > would like to know whether i am eligible for an account in > > > fedorapeople.org which in turn would help me to add my blog to planet > > > fedora. I was unable to find my name in the fedorapeople.org .Should > > > i do something to get my name added there or i am not eligible for it ? > > > > > > To have your name on fedoapeople.org, just login to fedorapeople with > > SSH and mkdir ~/public_html . > > Maybe you will also need to touch index..html. Your name should appear > > soon after that. > > > > > > > > > > My FAS login ID is balajig8 > > > > > > Thanks, > > > > > > Cheers, > > > Balaji > > > > > > > > -- > > > fedora-devel-list mailing list > > > fedora-devel-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > From aph at redhat.com Fri May 23 12:58:55 2008 From: aph at redhat.com (Andrew Haley) Date: Fri, 23 May 2008 13:58:55 +0100 Subject: PyLucene: How to package libraries that link against OpenJDK libraries? In-Reply-To: References: <4835E696.1010401@oss.schwarz.eu> <48368AB5.2080405@redhat.com> Message-ID: <4836BF8F.8050200@redhat.com> Colin Walters wrote: > On Fri, May 23, 2008 at 5:13 AM, Andrew Haley wrote: >> Interesting. What multilib-awareness do you think we need? It's not >> immediately clear to me where the beinefit would be. > > Code calling System.loadLibrary (i.e. most software out there that > wants to dlopen) would work. Well yes, obviously, but in what way would multilib-awareness help? Even if you have a mixture of 32-bit and 64-bit VMs in the same system, the VMs themselves wouldn't need to be multilib-aware. Andrew. From walters at verbum.org Fri May 23 13:09:33 2008 From: walters at verbum.org (Colin Walters) Date: Fri, 23 May 2008 09:09:33 -0400 Subject: PyLucene: How to package libraries that link against OpenJDK libraries? In-Reply-To: <4836BF8F.8050200@redhat.com> References: <4835E696.1010401@oss.schwarz.eu> <48368AB5.2080405@redhat.com> <4836BF8F.8050200@redhat.com> Message-ID: On Fri, May 23, 2008 at 8:58 AM, Andrew Haley wrote: > Colin Walters wrote: >> On Fri, May 23, 2008 at 5:13 AM, Andrew Haley wrote: >>> Interesting. What multilib-awareness do you think we need? It's not >>> immediately clear to me where the beinefit would be. >> >> Code calling System.loadLibrary (i.e. most software out there that >> wants to dlopen) would work. > > Well yes, obviously, but in what way would multilib-awareness help? > Even if you have a mixture of 32-bit and 64-bit VMs in the same system, > the VMs themselves wouldn't need to be multilib-aware. I didn't write that section of the Java guidelines, so perhaps I'm misinterpreting it. But I read "...modifying IcedTea to look for JNI shared objects in %{_libdir}/jni" as "multilib-aware". But maybe the operative change is the /jni and not the %{libdir}, so the IcedTea/OpenJDK change is really to be "JPackage layout aware"? From chris.stone at gmail.com Fri May 23 13:10:24 2008 From: chris.stone at gmail.com (Christopher Stone) Date: Fri, 23 May 2008 06:10:24 -0700 Subject: Xorg 1.5 missed the train? In-Reply-To: <3adc77210805230542t126e5d62i76e9234a105d622a@mail.gmail.com> References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <20080521152022.GF1093879@hiwaay.net> <1211383722.8531.63.camel@localhost.localdomain> <1211385285.8531.65.camel@localhost.localdomain> <3adc77210805230542t126e5d62i76e9234a105d622a@mail.gmail.com> Message-ID: On Fri, May 23, 2008 at 5:42 AM, Naheem Zaffar wrote: > I think it also needs to be made clear that free drivers shipped with > Fedora DO work. > > so something along the lines of: > > *Proprietary (third party) video drivers* > > Fedora ships a pre-release of the next version of the xorg which has a > new ABI. All drivers contained within fedora have been ported to use > this ABI and mostly work as expected. However, third part drivers from > some vendors (AMD and nVidia) have not yet been made compatible with > this new xorg ABI. > > If your use of the computer depends on these proprietary drivers, then > you are strongly advise to either not upgrade to Fedora 9 yet, exclude > xorg\* packages from upgrade (when using yum upgrade), or downgrade > your xorg\* packages back to those in Fedora 8 after installation > (when using upgrade from DVD). > > (second para mostly taken as is from Matej Cepl's email.) > > (as for status of fglrx, it has a new release yesterday, but it seems > only compatibility for the kernel 2.6.25 was added, not the new xorg > ABI) Guys, its a wiki, go to it! From aph at redhat.com Fri May 23 13:19:39 2008 From: aph at redhat.com (Andrew Haley) Date: Fri, 23 May 2008 14:19:39 +0100 Subject: PyLucene: How to package libraries that link against OpenJDK libraries? In-Reply-To: References: <4835E696.1010401@oss.schwarz.eu> <48368AB5.2080405@redhat.com> <4836BF8F.8050200@redhat.com> Message-ID: <4836C46B.4010803@redhat.com> Colin Walters wrote: > On Fri, May 23, 2008 at 8:58 AM, Andrew Haley wrote: >> Colin Walters wrote: >>> On Fri, May 23, 2008 at 5:13 AM, Andrew Haley wrote: >>>> Interesting. What multilib-awareness do you think we need? It's not >>>> immediately clear to me where the beinefit would be. >>> Code calling System.loadLibrary (i.e. most software out there that >>> wants to dlopen) would work. >> Well yes, obviously, but in what way would multilib-awareness help? >> Even if you have a mixture of 32-bit and 64-bit VMs in the same system, >> the VMs themselves wouldn't need to be multilib-aware. > > I didn't write that section of the Java guidelines, so perhaps I'm > misinterpreting it. But I read "...modifying IcedTea to look for JNI > shared objects in %{_libdir}/jni" as "multilib-aware". But maybe the > operative change is the /jni and not the %{libdir}, so the > IcedTea/OpenJDK change is really to be "JPackage layout aware"? That sounds much more likely. OpenJDK already looks in the correct libdir, and adding "%{_libdir}/jni" would be a simple change. The code that sets the path is here in java_md.c: sprintf(new_runpath, "LD_LIBRARY_PATH=" "%s:" "%s/lib/%s:" "%s/../lib/%s", jvmpath, #ifdef DUAL_MODE jrepath, ((wanted==64)?BIG_ARCH:SMALL_ARCH), jrepath, ((wanted==64)?BIG_ARCH:SMALL_ARCH) #else jrepath, arch, jrepath, arch #endif ); Andrew. From pertusus at free.fr Fri May 23 13:28:21 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 23 May 2008 15:28:21 +0200 Subject: Packager Sponsors Responsibility Policy In-Reply-To: <1211502398.29628.16.camel@kennedy> References: <1211502398.29628.16.camel@kennedy> Message-ID: <20080523132821.GC2612@free.fr> On Thu, May 22, 2008 at 08:26:38PM -0400, Brian Pepple wrote: > Hi all, > > I'm looking for some feedback on what we've got so far for the Packager > Sponsors Responsibility Policy. > http://fedoraproject.org/wiki/Extras/Schedule/SponsorResponsibilityPolicy Overall looks good. There are some technicall bits missing to help sponsors monitor the sponsored people. > == Make sure the maintainers you sponsor follow guidelines == > Sponsors should try and keep up with the doings of their sponsored > maintainers. Bugzilla has the ability to let you know via email all > activity for a given address. Initial sponsored maintainers should have > more scrutiny than long established maintainers with a known record of > good efforts. Here, it would be nice to have an example of how to achieve the 'Bugzilla has the ability to let you know via email all activity for a given address.' > == Fix issues caused by sponsored maintainers == > If one of your sponsored maintainers is unable to fix an issue in their > package(s), it's up to the sponsor to step in and make the needed fixes. > This might include pushing a security update when the maintainer is > unavailable, applying a patch, removing a improperly build package, or > other time or security sensitive issue. Note that the maintainer should > be shown the fix and how to manage the issue moving forward. There are many technical issues here. It would be nice if a sponsor could be in initialCC/Watchcommit/commit for all the packages of a sponsored person (and not by package), without needing a manual intervention from the sponsored person, and such that the sponsored person cannot revoke it. Also it should be easy to give up with those acls when the sponsor thinks that the sponsored person is competent enough. > == Revoking Sponsorship == > A sponsor may elect to revoke their sponsorship of a maintainer in rare > and extreme situations. These situations might include: A maintainer > that no longer wishes to contribute to Fedora, a maintainer that refuses > to follow guidelines, or irreconcilable differences between the > maintainer and the Sponsor. In this event it is the responsibility of > the Sponsor to orphan the maintainers packages, and do any other needed > cleanups. I think that it should be stated that it always have to be explained to FESCo. -- Pat From rjones at redhat.com Fri May 23 13:28:39 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 23 May 2008 14:28:39 +0100 Subject: OCHRE (was: Re: Werewolf -> Sulphur -> ? Sulphur is a , is a ) In-Reply-To: <20080523071144.42325a8e@vader.jdub.homelinux.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <20080522120933.GA23317@amd.home.annexia.org> <20080523071144.42325a8e@vader.jdub.homelinux.org> Message-ID: <20080523132839.GA20241@amd.home.annexia.org> On Fri, May 23, 2008 at 07:11:44AM -0500, Josh Boyer wrote: > On Thu, 22 May 2008 13:09:33 +0100 > "Richard W.M. Jones" wrote: > > > On Thu, May 22, 2008 at 06:57:24AM -0500, Josh Boyer wrote: > > > 2) The link between and Sulphur cannot be the same as between > > > Werewolf and Sulphur. That link was "things that react badly with > > > silver". > > > > OCHRE > > > > (the connection is that both are yellow) > > But it doesn't fit the "is a" rule. ?? "is a yellow substance"? BTW, I mean of course Yellow Ochre as opposed to Red Ochre. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From jmoyer at redhat.com Fri May 23 13:32:08 2008 From: jmoyer at redhat.com (Jeff Moyer) Date: Fri, 23 May 2008 09:32:08 -0400 Subject: upstart plans for F10+ In-Reply-To: <20080523035957.GA24410@imperial.ac.uk> (Kostas Georgiou's message of "Fri, 23 May 2008 04:59:57 +0100") References: <20080522200445.GA24822@nostromo.devel.redhat.com> <20080522204407.GA30257@nostromo.devel.redhat.com> <20080523035957.GA24410@imperial.ac.uk> Message-ID: Kostas Georgiou writes: > On Thu, May 22, 2008 at 06:13:23PM -0400, Colin Walters wrote: > >> On Thu, May 22, 2008 at 4:44 PM, Bill Nottingham wrote: >> > >> > I mean, right now we have a static init script that runs once >> > on boot to mount NFS, SMB, etc, and set up network block devices. >> > It's also (in F9) kicked when NM brings up a new default route. >> > >> > What would be sane is to have it just mount things when it can >> > reach the proper network, and lazily unmount them when that >> > network goes away. >> >> The issue with this is that at least last time I checked, at least >> some file systems like NFS basically don't handle the network going >> away from underneath them; if you have any userspace processes >> accessing them they'll be wedged unrecoverably in D state. I gave up >> long ago on using kernel-based network filesystems on my laptop for >> this reason. >> >> Simo says CIFS handles this, so maybe other filesystems could be fixed. >> >> But anyways, mounting after the network is available (triggered by NM) >> makes sense probably. > > This is a bit dangerours... > > Have a look at /etc/init.d/netfs and tell me what will happen if you have > an fs marked _netdev and the fsck fails if netfs doesn't run at init but > under NM at some random point. > > In my opinion you only use netfs for filesystems that you want available > at boot and n general you also want them to be always available, processes > freezing until the network is available is not a problem but a feature. > For everything else that isn't needed at boot there is always autofs. Lots of deployments use autofs for file systems that are needed "at boot." Further, autofs will not react favorably if file systems are unmounted out from under it. I agree with the sentiment that, if the network goes down, allow the file system to continue to retry until the network is back online. Cheers, Jeff From opensource at till.name Fri May 23 13:34:11 2008 From: opensource at till.name (Till Maas) Date: Fri, 23 May 2008 15:34:11 +0200 Subject: Account in Fedorapeople.org and planet fedora In-Reply-To: <6dd1343e0805230557t4f7642b7k732e28b2e12602bd@mail.gmail.com> References: <6dd1343e0805230456i778b403ds6d02973ba8a605cd@mail.gmail.com> <6dd1343e0805230515r744d2cc1i39f494d0561d69e2@mail.gmail.com> <6dd1343e0805230557t4f7642b7k732e28b2e12602bd@mail.gmail.com> Message-ID: <200805231534.21440.opensource@till.name> On Fri May 23 2008, "G" wrote: > I find that the SSH Key what i enter is not valid. I ve forgotten the > key and ve installed Fedora 9 and i guess i ve lost the saved key too. > Is there any way that i can retrieve it ? You can create a new one and upload it to FAS, e.g. with: ssh-keygen -b 2048 -t rsa -f ~/.ssh/id_rsa_fedora_2008-05-23 Then upload ~/.ssh/id_rsa_fedora_2008-05-23.pub to FAS. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From hun at n-dimensional.de Fri May 23 13:40:47 2008 From: hun at n-dimensional.de (Hans Ulrich Niedermann) Date: Fri, 23 May 2008 15:40:47 +0200 Subject: NetworkManager: I want to believe, but... In-Reply-To: <20080523034708.GA12797@jadzia.bu.edu> References: <3da3b5b40805161502w62f372dseca0ab6310e44447@mail.gmail.com> <1210975852.6805.10.camel@localhost.localdomain> <3da3b5b40805161522i2300f1cdhb1fc7b074084873f@mail.gmail.com> <604aa7910805161527j6b193c6dj2af4248155d5cdaf@mail.gmail.com> <20080517112856.GA18698@jadzia.bu.edu> <1211069083.3070.392.camel@cookie.hadess.net> <20080522142554.GB8728@jadzia.bu.edu> <1211472267.5352.25.camel@localhost.localdomain> <20080523021725.GA5233@jadzia.bu.edu> <1211509568.19171.9.camel@aglarond.local> <20080523034708.GA12797@jadzia.bu.edu> Message-ID: <4836C95F.7000401@n-dimensional.de> Matthew Miller wrote: > But "is the network up" a generally useful question? I can picture several situations where "this system is online" or "this system is offline" can cause more harm than it solves problems. "Is *the* network up?" "No." Now software will refuse to connect to 127.0.0.1, ::1 or any other locally configured network address, for that matter - even though these addresses are local and can be reached locally without any network being connected. cf. https://bugzilla.redhat.com/show_bug.cgi?id=443385 Firefox refuses to connect to http://127.0.0.1/ when "offline" "Is address 1.2.3.4 or dead:beef::1 reachable?" "Yes/No." This would be a better question locally running software could ask. The answer could be determined by just looking at the local routing tables (aka "ip route" and "ip -6 route" output). > I find that "can I > reach the network resource I need" is the more important one, and the "is > the network up" issue basically a detail.I mean, who cares if the network > is up if the gateway is down? This is why external monitoring (big brother > or the like) is more practical. "Is resource //FOO on server 12.34.56.78 port 12345 available?" "Yes/No" That is the real question you want to know and can be easily determined by the software which wants to access //FOO on 12.34.56.78:12345 in the first place. Having a common system service maintaining resource availability state by actually communicating with other nodes in the network only to determine resource reachability is probably not very desirable. It requires communication with all potentially interesting network nodes, knowledge of many different protocols, etc. That is a lot of effort just for determining availability which the services themselves will be in a much better position to determine. Exploiting the local routing table for a more fine-grained online/offline status should be quite easy in comparison. -- Hans Ulrich Niedermann -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From jkeating at redhat.com Fri May 23 13:54:00 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 23 May 2008 09:54:00 -0400 Subject: Orphan perl-Net-Telnet Message-ID: <1211550840.5079.101.camel@localhost.localdomain> I think I got ownership of this due to the merger, and well, I haven't touched it. Somebody else should really own this. It's now orphaned in pkgdb, have at it! -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From dwmw2 at infradead.org Fri May 23 13:56:51 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 23 May 2008 14:56:51 +0100 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: <604aa7910805220853y365ecbb2qd64319388ed26e89@mail.gmail.com> References: <1211377739.4210.2.camel@truman> <1211410870.2290.5.camel@kennedy> <20080522162729.1c8298da@ludwig-alpha.unil.ch> <1211467361.21380.448.camel@pmac.infradead.org> <604aa7910805220853y365ecbb2qd64319388ed26e89@mail.gmail.com> Message-ID: <1211551011.28967.20.camel@pmac.infradead.org> On Thu, 2008-05-22 at 07:53 -0800, Jeff Spaleta wrote: > On Thu, May 22, 2008 at 6:42 AM, David Woodhouse wrote: > > I assume Alex won't be including an interpreter for closed-source ACPI > > bytecode in his kernel. So it's likely to have problems on a lot of i386 > > and x86_64 machines. Should be OK on PPC though :) > > It would however be fascinating to see how many machines fall over and > die in the attempt. I like your action plan concerning the firmware > conversion, but what the hell do i know. If your plan ever makes it > to an upstream technical discussion, I want to make sure I know about > so I can read along. http://lkml.org/lkml/2008/5/23/170 -- dwmw2 From jkeating at redhat.com Fri May 23 13:59:11 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 23 May 2008 09:59:11 -0400 Subject: upstart plans for F10+ In-Reply-To: <6e24a8e80805230231r3f2f0af4j8d5fd52f02e1fb5d@mail.gmail.com> References: <20080522200445.GA24822@nostromo.devel.redhat.com> <6e24a8e80805230231r3f2f0af4j8d5fd52f02e1fb5d@mail.gmail.com> Message-ID: <1211551151.5079.104.camel@localhost.localdomain> On Fri, 2008-05-23 at 11:31 +0200, Mark wrote: > 2008/5/22 Bill Nottingham : > > Since I've been asked in various places what we're planning to > > do with upstart now that Fedora 9 has shipped, I figured I'd > > lay out the basic plan. > > > > To do any large-scale conversion of SysV init scripts to upstart, > > we need some features that are not in the current (0.3.9) version. > > And why not cooperate with ubuntu and use the upstart scripts that they made? > That would leave only a few other ones to make if any at all. Given that ubuntu is still using sysv compat mode as well, what scripts do they have for us to re-use? -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Fri May 23 14:12:31 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 23 May 2008 10:12:31 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080523121509.GC27748@crux.yyz.redhat.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <20080522170718.GE8819@nostromo.devel.redhat.com> <1211543403.23635.3.camel@victoria> <20080523121509.GC27748@crux.yyz.redhat.com> Message-ID: <1211551951.5079.106.camel@localhost.localdomain> On Fri, 2008-05-23 at 08:15 -0400, James Bowes wrote: > Then Fedora 11 can be "Doctor Girlfriend" > http://en.wikipedia.org/wiki/Monarch_(The_Venture_Bros.) Oh hells yes. We can do a whole Brock Sampson theme too. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jwboyer at gmail.com Fri May 23 14:39:54 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 23 May 2008 09:39:54 -0500 Subject: OCHRE (was: Re: Werewolf -> Sulphur -> ? Sulphur is a , is a ) In-Reply-To: <20080523132839.GA20241@amd.home.annexia.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <20080522120933.GA23317@amd.home.annexia.org> <20080523071144.42325a8e@vader.jdub.homelinux.org> <20080523132839.GA20241@amd.home.annexia.org> Message-ID: <20080523093954.2f7e7618@vader.jdub.homelinux.org> On Fri, 23 May 2008 14:28:39 +0100 "Richard W.M. Jones" wrote: > On Fri, May 23, 2008 at 07:11:44AM -0500, Josh Boyer wrote: > > On Thu, 22 May 2008 13:09:33 +0100 > > "Richard W.M. Jones" wrote: > > > > > On Thu, May 22, 2008 at 06:57:24AM -0500, Josh Boyer wrote: > > > > 2) The link between and Sulphur cannot be the same as between > > > > Werewolf and Sulphur. That link was "things that react badly with > > > > silver". > > > > > > OCHRE > > > > > > (the connection is that both are yellow) > > > > But it doesn't fit the "is a" rule. > > ?? > > "is a yellow substance"? See. That wasn't that hard. This is like Jeopardy. Phrasing counts ;). josh From naheemzaffar at gmail.com Fri May 23 14:58:14 2008 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Fri, 23 May 2008 15:58:14 +0100 Subject: Xorg 1.5 missed the train? In-Reply-To: References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <20080521152022.GF1093879@hiwaay.net> <1211383722.8531.63.camel@localhost.localdomain> <1211385285.8531.65.camel@localhost.localdomain> <3adc77210805230542t126e5d62i76e9234a105d622a@mail.gmail.com> Message-ID: <3adc77210805230758y605b5d46we5f638b4a172b0de@mail.gmail.com> I do not have a Fedora account and I can see no edit link for anonymous users. From james at fedoraproject.com Fri May 23 15:03:09 2008 From: james at fedoraproject.com (James Antill) Date: Fri, 23 May 2008 11:03:09 -0400 Subject: NetworkManager: I want to believe, but... In-Reply-To: <4836C95F.7000401@n-dimensional.de> References: <3da3b5b40805161502w62f372dseca0ab6310e44447@mail.gmail.com> <1210975852.6805.10.camel@localhost.localdomain> <3da3b5b40805161522i2300f1cdhb1fc7b074084873f@mail.gmail.com> <604aa7910805161527j6b193c6dj2af4248155d5cdaf@mail.gmail.com> <20080517112856.GA18698@jadzia.bu.edu> <1211069083.3070.392.camel@cookie.hadess.net> <20080522142554.GB8728@jadzia.bu.edu> <1211472267.5352.25.camel@localhost.localdomain> <20080523021725.GA5233@jadzia.bu.edu> <1211509568.19171.9.camel@aglarond.local> <20080523034708.GA12797@jadzia.bu.edu> <4836C95F.7000401@n-dimensional.de> Message-ID: <1211554989.13935.32.camel@code.and.org> On Fri, 2008-05-23 at 15:40 +0200, Hans Ulrich Niedermann wrote: > Matthew Miller wrote: > > > But "is the network up" a generally useful question? > > I can picture several situations where "this system is online" or "this > system is offline" can cause more harm than it solves problems. Can you think of any good ones? > "Is *the* network up?" "No." > > Now software will refuse to connect to 127.0.0.1, ::1 or any > other locally configured network address, for that matter - even > though these addresses are local and can be reached locally without > any network being connected. > > cf. https://bugzilla.redhat.com/show_bug.cgi?id=443385 > Firefox refuses to connect to http://127.0.0.1/ when "offline" firefox isn't required to do this, testing for "localhost" is not that hard. You could argue the same about "blah.example.com" when it resolves to 127.0.0.1 ... but latency of DNS lookups are the leading cause of firefox being unresponsive for me, AFAICS. > "Is address 1.2.3.4 or dead:beef::1 reachable?" "Yes/No." > > This would be a better question locally running software could > ask. > > The answer could be determined by just looking at the local routing > tables (aka "ip route" and "ip -6 route" output). I don't know about you but I rarely type IPs into anything, so the normal question would be more likely is "blah.example.com" available? And if the answer involves waiting for the DNS requests to timeout then it's much worse. Also this takes a view of the internet staying with single destinations ... for instance yum using tools really don't want to have to test if every destination in all the repo. mirrors files are "unavailable" if you aren't actually on a wireless network. -- James Antill Fedora From j.w.r.degoede at hhs.nl Fri May 23 14:52:19 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 23 May 2008 16:52:19 +0200 Subject: Announcing a new F-10 Feature Proposal: Better Webcam Support Message-ID: <4836DA23.3090709@hhs.nl> See: http://fedoraproject.org/wiki/Features/BetterWebcamSupport Regards, Hans From ndbecker2 at gmail.com Fri May 23 15:11:14 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 23 May 2008 11:11:14 -0400 Subject: missing libphonon.so? References: Message-ID: Kevin Kofler wrote: > Neal Becker gmail.com> writes: >> The package I was trying was uniXM, which uses qmake, but also uses >> phonon. >> >> Maybe we need kde.pc? > > We just need kdelibs fixed so that libphonon.so is directly in %{_libdir}, > it doesn't need special-casing for parallel-installability with KDE 3 > anyway. I or one of the other KDE maintainers are going to fix this ASAP. > How urgently do you need this fixed? It's easy to fix Rawhide, but for the > older Fedora releases, we have to push a new kdelibs resp. kdelibs4 to fix > this. > > Kevin Kofler > Not urgent, but is libphonon the only 1 (i.e., only lib currently packaged with kdelibs that likely would be needed by 3rd parties not using kde's cmake framework)? From markg85 at gmail.com Fri May 23 15:16:29 2008 From: markg85 at gmail.com (Mark) Date: Fri, 23 May 2008 17:16:29 +0200 Subject: upstart plans for F10+ In-Reply-To: <1211551151.5079.104.camel@localhost.localdomain> References: <20080522200445.GA24822@nostromo.devel.redhat.com> <6e24a8e80805230231r3f2f0af4j8d5fd52f02e1fb5d@mail.gmail.com> <1211551151.5079.104.camel@localhost.localdomain> Message-ID: <6e24a8e80805230816y33ef0235h3e6d6fd2b3fc0489@mail.gmail.com> 2008/5/23 Jesse Keating : > On Fri, 2008-05-23 at 11:31 +0200, Mark wrote: >> 2008/5/22 Bill Nottingham : >> > Since I've been asked in various places what we're planning to >> > do with upstart now that Fedora 9 has shipped, I figured I'd >> > lay out the basic plan. >> > >> > To do any large-scale conversion of SysV init scripts to upstart, >> > we need some features that are not in the current (0.3.9) version. >> >> And why not cooperate with ubuntu and use the upstart scripts that they made? >> That would leave only a few other ones to make if any at all. > > > Given that ubuntu is still using sysv compat mode as well, what scripts > do they have for us to re-use? > > -- > Jesse Keating > Fedora -- Freedom? is a feature! > I really thought they used upstart scripts already.. o well than make upstart scripts together with ubuntu. will go twice as fast and both dists will benefit from it. See it as a project Fedora and Ubuntu start (and finish) together. From notting at redhat.com Fri May 23 15:24:26 2008 From: notting at redhat.com (Bill Nottingham) Date: Fri, 23 May 2008 11:24:26 -0400 Subject: Announcing a new F-10 Feature Proposal: Better Webcam Support In-Reply-To: <4836DA23.3090709@hhs.nl> References: <4836DA23.3090709@hhs.nl> Message-ID: <20080523152426.GB3224@nostromo.devel.redhat.com> Hans de Goede (j.w.r.degoede at hhs.nl) said: > See: > > http://fedoraproject.org/wiki/Features/BetterWebcamSupport Any reason a shim library is simpler than porting apps to V4L2? Bill From paulds at bu.edu Fri May 23 15:25:12 2008 From: paulds at bu.edu (Paul Stauffer) Date: Fri, 23 May 2008 11:25:12 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080522065724.1788e577@vader.jdub.homelinux.org> Message-ID: <20080523152512.GD4238@cs.bu.edu> > Let the naming begin! We're starting very early this time around in the > name game for F10. So, let the suggestions flow! "Farnsworth" Sulpher is a producer of blue flame. (Pete) Farnsworth is a producer of Blue Flame. Cuz dude, *rocket cars*. :) http://en.wikipedia.org/wiki/Blue_Flame_%28car%29 This could obviously lead to either Futurama references or to famous inventors. Additional minor benefits: the name has 10 letters, and "Fedora Farnsworth" is alliterative. cheers, - Paul -- Paul Stauffer Manager of Research Computing Computer Science Department Boston University From jkeating at redhat.com Fri May 23 15:28:37 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 23 May 2008 11:28:37 -0400 Subject: upstart plans for F10+ In-Reply-To: <6e24a8e80805230816y33ef0235h3e6d6fd2b3fc0489@mail.gmail.com> References: <20080522200445.GA24822@nostromo.devel.redhat.com> <6e24a8e80805230231r3f2f0af4j8d5fd52f02e1fb5d@mail.gmail.com> <1211551151.5079.104.camel@localhost.localdomain> <6e24a8e80805230816y33ef0235h3e6d6fd2b3fc0489@mail.gmail.com> Message-ID: <1211556517.5079.120.camel@localhost.localdomain> On Fri, 2008-05-23 at 17:16 +0200, Mark wrote: > I really thought they used upstart scripts already.. o well than make > upstart scripts together with ubuntu. will go twice as fast and both > dists will benefit from it. See it as a project Fedora and Ubuntu > start (and finish) together. Perhaps you missed the part where we upstream all our changes as best we can. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From pregier at ittc.ku.edu Fri May 23 15:30:36 2008 From: pregier at ittc.ku.edu (Phil Regier) Date: Fri, 23 May 2008 10:30:36 -0500 Subject: What ever happened to "Stateless Linux"? In-Reply-To: <20080522190851.GA21648@nostromo.devel.redhat.com> References: <4835BA4E.7080107@ittc.ku.edu> <20080522185252.GG8819@nostromo.devel.redhat.com> <4835C305.70708@ittc.ku.edu> <20080522190851.GA21648@nostromo.devel.redhat.com> Message-ID: <4836E31C.7090103@ittc.ku.edu> I forgot to CC the list on the last message, so in case anyone else is interested, this did work quite well after a little local tweaking. It may or may not be interesting to note that anaconda under Fedora 9 failed to run to completion from the command line, but it worked very well under 8. Thanks again, Bill! Phil Bill Nottingham wrote: > Phil Regier (pregier at ittc.ku.edu) said: >> Great; thanks! All I'm looking for is simple readonly-root with no >> management/deployment needed; should I (theoretically) just be able to hack >> my way through the old CreateClientImage guide with any recent Fedora >> release, then, and just boot the results with an existing pxelinux server, >> ignoring the old StatelessServer RPM for the most part? > > Just set up your filesystem (with whatever method) and set READONLY=yes > in /etc/sysconfig/readonly-root > > Bill From kevin.kofler at chello.at Fri May 23 15:31:24 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 23 May 2008 15:31:24 +0000 (UTC) Subject: missing libphonon.so? References: Message-ID: Neal Becker gmail.com> writes: > Not urgent, but is libphonon the only 1 (i.e., only lib currently packaged > with kdelibs that likely would be needed by 3rd parties not using kde's > cmake framework)? Most likely yes. Most of the stuff in there depends on the core KDE libs (libkdecore, libkdeui). But if the problem shows up with other libs, we can come up with a solution for those when it does. And FYI, this is now fixed in Rawhide: http://cvs.fedoraproject.org/viewcvs/rpms/kdelibs/devel/kdelibs.spec?r1=1.319&r2=1.320 and there's a fixed F9 build which hasn't been pushed yet. Kevin Kofler From panemade at gmail.com Fri May 23 15:35:51 2008 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Fri, 23 May 2008 21:05:51 +0530 Subject: Announcing a new F-10 Feature Proposal: Better Webcam Support In-Reply-To: <4836DA23.3090709@hhs.nl> References: <4836DA23.3090709@hhs.nl> Message-ID: Hi Hans, On 5/23/08, Hans de Goede wrote: > See: > > http://fedoraproject.org/wiki/Features/BetterWebcamSupport I don't see any webcam applications mentioned on this page but have you seen ucview package in fedora? I have tested it with old "Logitech QuickCam Messenger " and its working fine. Its using v4l kernel module. You should give a try to ucview application with webcams available with you. I think with ucview you should be able to view video from webcams using v4l and v4l2 kernel modules. More you can check at Regards, Parag. From sundaram at fedoraproject.org Fri May 23 15:38:08 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 23 May 2008 21:08:08 +0530 Subject: Xorg 1.5 missed the train? In-Reply-To: <3adc77210805230758y605b5d46we5f638b4a172b0de@mail.gmail.com> References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <20080521152022.GF1093879@hiwaay.net> <1211383722.8531.63.camel@localhost.localdomain> <1211385285.8531.65.camel@localhost.localdomain> <3adc77210805230542t126e5d62i76e9234a105d622a@mail.gmail.com> <3adc77210805230758y605b5d46we5f638b4a172b0de@mail.gmail.com> Message-ID: <4836E4E0.8050701@fedoraproject.org> Naheem Zaffar wrote: > I do not have a Fedora account and I can see no edit link for anonymous users. Added as suggested. Anonymous edits are not allowed in the Fedora wiki for accountability. http://fedoraproject.org/join-fedora Rahul From jkeating at redhat.com Fri May 23 15:37:57 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 23 May 2008 11:37:57 -0400 Subject: Announcing a new F-10 Feature Proposal: Better Webcam Support In-Reply-To: References: <4836DA23.3090709@hhs.nl> Message-ID: <1211557077.5079.122.camel@localhost.localdomain> On Fri, 2008-05-23 at 21:05 +0530, Parag N(????) wrote: > Hi Hans, > > On 5/23/08, Hans de Goede wrote: > > See: > > > > http://fedoraproject.org/wiki/Features/BetterWebcamSupport > > I don't see any webcam applications mentioned on this page but > have you seen ucview package in fedora? I have tested it with old > "Logitech QuickCam Messenger " and its working fine. Its using v4l > kernel module. > You should give a try to ucview application with webcams available > with you. I think with ucview you should be able to view video from > webcams using v4l and v4l2 kernel modules. > More you can check at > Regards, > Parag. See also 'cheese' -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From panemade at gmail.com Fri May 23 15:38:33 2008 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Fri, 23 May 2008 21:08:33 +0530 Subject: Announcing a new F-10 Feature Proposal: Better Webcam Support In-Reply-To: References: <4836DA23.3090709@hhs.nl> Message-ID: Hi, On 5/23/08, Parag N(????) wrote: > Hi Hans, > > > On 5/23/08, Hans de Goede wrote: > > See: > > > > http://fedoraproject.org/wiki/Features/BetterWebcamSupport > > > I don't see any webcam applications mentioned on this page but > have you seen ucview package in fedora? I have tested it with old > "Logitech QuickCam Messenger " and its working fine. Its using v4l > kernel module. > You should give a try to ucview application with webcams available > with you. I think with ucview you should be able to view video from > webcams using v4l and v4l2 kernel modules. More you can check at http://www.unicap-imaging.org/ > Regards, > > Parag. > From s0238762 at sms.ed.ac.uk Fri May 23 15:40:06 2008 From: s0238762 at sms.ed.ac.uk (Ioannis Nousias) Date: Fri, 23 May 2008 16:40:06 +0100 Subject: freenx-server.x86_64 missing dependency Message-ID: <4836E556.1060700@sms.ed.ac.uk> Hello, I'm having a problem with freenx in F9. the freenx package has been replaced with freenx-server one that requires /usr/lib64/nx, which doesn't exist in the repos. There is nx.i386, but no nx.x86_64 is this a know issue ? regards, Ioannis PS: using freenx.x86_64 doesn't work either (no dependency problems, but I don't get a working server) -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From bnocera at redhat.com Fri May 23 15:44:58 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Fri, 23 May 2008 16:44:58 +0100 Subject: New system-config-acpid In-Reply-To: <544eb990805230521p75645e7ar8f7835c5d70bbb14@mail.gmail.com> References: <48207BC5.3060105@redhat.com> <20080506154407.GA21822@nostromo.devel.redhat.com> <1210089619.17842.2.camel@localhost.localdomain> <409676c70805222215n4b30c80h7d516d5140a28ee7@mail.gmail.com> <544eb990805230418j636b2957oa618865440d36f80@mail.gmail.com> <1211542280.3566.53.camel@cookie.hadess.net> <544eb990805230521p75645e7ar8f7835c5d70bbb14@mail.gmail.com> Message-ID: <1211557498.3566.91.camel@cookie.hadess.net> On Fri, 2008-05-23 at 13:21 +0100, Bill Crawford wrote: > 2008/5/23 Bastien Nocera : > > > It's already behing the scenes. Just that the policy belongs in > > gnome-power-manager, which will show us a nice battery icon for us. > > GNOME power manager? Not everyone wants to use that, y'know. > > > Would you want to rewrite gnome-power-manager instead of using a cut > > down version? > > Because I don't use GNOME? Then why don't you use a DM that's more suited to whatever setup you use? From sundaram at fedoraproject.org Fri May 23 15:57:38 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 23 May 2008 21:27:38 +0530 Subject: New system-config-acpid In-Reply-To: <1211557498.3566.91.camel@cookie.hadess.net> References: <48207BC5.3060105@redhat.com> <20080506154407.GA21822@nostromo.devel.redhat.com> <1210089619.17842.2.camel@localhost.localdomain> <409676c70805222215n4b30c80h7d516d5140a28ee7@mail.gmail.com> <544eb990805230418j636b2957oa618865440d36f80@mail.gmail.com> <1211542280.3566.53.camel@cookie.hadess.net> <544eb990805230521p75645e7ar8f7835c5d70bbb14@mail.gmail.com> <1211557498.3566.91.camel@cookie.hadess.net> Message-ID: <4836E972.5050809@fedoraproject.org> Bastien Nocera wrote: > On Fri, 2008-05-23 at 13:21 +0100, Bill Crawford wrote: >> 2008/5/23 Bastien Nocera : >> >>> It's already behing the scenes. Just that the policy belongs in >>> gnome-power-manager, which will show us a nice battery icon for us. >> GNOME power manager? Not everyone wants to use that, y'know. >> >>> Would you want to rewrite gnome-power-manager instead of using a cut >>> down version? >> Because I don't use GNOME? > > Then why don't you use a DM that's more suited to whatever setup you > use? Completely agree with you. If you are selecting KDE from the DVD image, make sure you have KDM installed. The only problem is that we refuse to do this sane thing by default. Rahul From billcrawford1970 at gmail.com Fri May 23 16:03:43 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Fri, 23 May 2008 17:03:43 +0100 Subject: New system-config-acpid In-Reply-To: <1211557498.3566.91.camel@cookie.hadess.net> References: <48207BC5.3060105@redhat.com> <20080506154407.GA21822@nostromo.devel.redhat.com> <1210089619.17842.2.camel@localhost.localdomain> <409676c70805222215n4b30c80h7d516d5140a28ee7@mail.gmail.com> <544eb990805230418j636b2957oa618865440d36f80@mail.gmail.com> <1211542280.3566.53.camel@cookie.hadess.net> <544eb990805230521p75645e7ar8f7835c5d70bbb14@mail.gmail.com> <1211557498.3566.91.camel@cookie.hadess.net> Message-ID: <544eb990805230903i257a1a76i4c0d70e319ad2159@mail.gmail.com> 2008/5/23 Bastien Nocera : > Then why don't you use a DM that's more suited to whatever setup you > use? AIUI the current gdm is supposed to have been rearchitected and rewritten almost from scratch precisely so it's supposed to be usable more easily with all desktops? But never mind, .... From sundaram at fedoraproject.org Fri May 23 16:06:36 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 23 May 2008 21:36:36 +0530 Subject: New system-config-acpid In-Reply-To: <544eb990805230903i257a1a76i4c0d70e319ad2159@mail.gmail.com> References: <48207BC5.3060105@redhat.com> <20080506154407.GA21822@nostromo.devel.redhat.com> <1210089619.17842.2.camel@localhost.localdomain> <409676c70805222215n4b30c80h7d516d5140a28ee7@mail.gmail.com> <544eb990805230418j636b2957oa618865440d36f80@mail.gmail.com> <1211542280.3566.53.camel@cookie.hadess.net> <544eb990805230521p75645e7ar8f7835c5d70bbb14@mail.gmail.com> <1211557498.3566.91.camel@cookie.hadess.net> <544eb990805230903i257a1a76i4c0d70e319ad2159@mail.gmail.com> Message-ID: <4836EB8C.7050305@fedoraproject.org> Bill Crawford wrote: > 2008/5/23 Bastien Nocera : > >> Then why don't you use a DM that's more suited to whatever setup you >> use? > > AIUI the current gdm is supposed to have been rearchitected and > rewritten almost from scratch precisely so it's supposed to be usable > more easily with all desktops? But never mind, .... I never saw that as a goal. Where did you read that? Rahul From billcrawford1970 at gmail.com Fri May 23 16:17:00 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Fri, 23 May 2008 17:17:00 +0100 Subject: New system-config-acpid In-Reply-To: <4836EB8C.7050305@fedoraproject.org> References: <48207BC5.3060105@redhat.com> <1210089619.17842.2.camel@localhost.localdomain> <409676c70805222215n4b30c80h7d516d5140a28ee7@mail.gmail.com> <544eb990805230418j636b2957oa618865440d36f80@mail.gmail.com> <1211542280.3566.53.camel@cookie.hadess.net> <544eb990805230521p75645e7ar8f7835c5d70bbb14@mail.gmail.com> <1211557498.3566.91.camel@cookie.hadess.net> <544eb990805230903i257a1a76i4c0d70e319ad2159@mail.gmail.com> <4836EB8C.7050305@fedoraproject.org> Message-ID: <544eb990805230917q783dfc7ew1566cf431ebb76ef@mail.gmail.com> 2008/5/23 Rahul Sundaram : > I never saw that as a goal. Where did you read that? IIRC it came up during one of the endless discussions about KDE being "allegedly" a second-class citizen in Fedora ... From gjalves at gjalves.com.br Fri May 23 16:20:19 2008 From: gjalves at gjalves.com.br (Gustavo Alves) Date: Fri, 23 May 2008 13:20:19 -0300 Subject: freenx-server.x86_64 missing dependency In-Reply-To: <4836E556.1060700@sms.ed.ac.uk> References: <4836E556.1060700@sms.ed.ac.uk> Message-ID: <69e11d1f0805230920q59ca9924h2a93f1123a1831bf@mail.gmail.com> Hi, There is a bug registered about it https://bugzilla.redhat.com/show_bug.cgi?id=447998 Regards, Gustavo On Fri, May 23, 2008 at 12:40 PM, Ioannis Nousias wrote: > Hello, > > I'm having a problem with freenx in F9. > > the freenx package has been replaced with freenx-server one that requires > /usr/lib64/nx, which doesn't exist in the repos. There is nx.i386, but no > nx.x86_64 > > is this a know issue ? > > > regards, > Ioannis > > > PS: using freenx.x86_64 doesn't work either (no dependency problems, but I > don't get a working server) > > > -- > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Gustavo Junior Alves GJAlves Tecnologia Tel: +55 19 9223-0500 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bnocera at redhat.com Fri May 23 16:20:57 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Fri, 23 May 2008 17:20:57 +0100 Subject: Announcing a new F-10 Feature Proposal: Better Webcam Support In-Reply-To: <20080523152426.GB3224@nostromo.devel.redhat.com> References: <4836DA23.3090709@hhs.nl> <20080523152426.GB3224@nostromo.devel.redhat.com> Message-ID: <1211559657.3566.97.camel@cookie.hadess.net> On Fri, 2008-05-23 at 11:24 -0400, Bill Nottingham wrote: > Hans de Goede (j.w.r.degoede at hhs.nl) said: > > See: > > > > http://fedoraproject.org/wiki/Features/BetterWebcamSupport > > Any reason a shim library is simpler than porting apps to V4L2? Same question here. There's a good number of applications that are either obsoleted by a v4l2 version, or support both versions. Which applications were you thinking of supporting with this scheme? Unless there's tens of open source apps that would need changing, or a couple of (useful) proprietary ones that don't support v4l2, the library is probably not very useful to have (especially as you probably wouldn't be able to port _all_ the v4l1 drivers to v4l2). You might also want to see what can be done to remove GStreamer's V4L2 plugin's experimental status: http://tinyurl.com/4ft7ej Cheers From kevin at scrye.com Fri May 23 16:20:47 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Fri, 23 May 2008 10:20:47 -0600 Subject: Packager Sponsors Responsibility Policy In-Reply-To: <20080523132821.GC2612@free.fr> References: <1211502398.29628.16.camel@kennedy> <20080523132821.GC2612@free.fr> Message-ID: <20080523102047.7eeae2f0@ohm.scrye.com> On Fri, 23 May 2008 15:28:21 +0200 pertusus at free.fr (Patrice Dumas) wrote: > On Thu, May 22, 2008 at 08:26:38PM -0400, Brian Pepple wrote: > > Hi all, > > > > I'm looking for some feedback on what we've got so far for the > > Packager Sponsors Responsibility Policy. > > http://fedoraproject.org/wiki/Extras/Schedule/SponsorResponsibilityPolicy > > Overall looks good. There are some technicall bits missing to help > sponsors monitor the sponsored people. Agreed. > > == Make sure the maintainers you sponsor follow guidelines == > > Sponsors should try and keep up with the doings of their sponsored > > maintainers. Bugzilla has the ability to let you know via email all > > activity for a given address. Initial sponsored maintainers should > > have more scrutiny than long established maintainers with a known > > record of good efforts. > > Here, it would be nice to have an example of how to achieve the > 'Bugzilla has the ability to let you know via email all activity for a > given address.' - Login to bugzilla.redhat.com with your account. - Click the 'account' button at the top. - Click the 'email' tab. - Enter a , delimited list of users email address(es) in the 'users to watch' text entry box. - Click 'submit changes' > > == Fix issues caused by sponsored maintainers == > > If one of your sponsored maintainers is unable to fix an issue in > > their package(s), it's up to the sponsor to step in and make the > > needed fixes. This might include pushing a security update when the > > maintainer is unavailable, applying a patch, removing a improperly > > build package, or other time or security sensitive issue. Note that > > the maintainer should be shown the fix and how to manage the issue > > moving forward. > > There are many technical issues here. It would be nice if a sponsor > could be in initialCC/Watchcommit/commit for all the packages of a > sponsored person (and not by package), without needing a manual > intervention from the sponsored person, and such that the sponsored > person cannot revoke it. Also it should be easy to give up with those > acls when the sponsor thinks that the sponsored person is competent > enough. Yeah, that would be nice. Pkgdb enhancement it sounds like... could you file it? > > > == Revoking Sponsorship == > > A sponsor may elect to revoke their sponsorship of a maintainer in > > rare and extreme situations. These situations might include: A > > maintainer that no longer wishes to contribute to Fedora, a > > maintainer that refuses to follow guidelines, or irreconcilable > > differences between the maintainer and the Sponsor. In this event > > it is the responsibility of the Sponsor to orphan the maintainers > > packages, and do any other needed cleanups. > > I think that it should be stated that it always have to be explained > to FESCo. I think thats a good idea... at that point someone may be able to step in and work with the maintainer and take over sponsorship (in those cases where it's just personal differences that are driving the sponsor to not want to continue with that maintainer). kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From sundaram at fedoraproject.org Fri May 23 16:23:40 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 23 May 2008 21:53:40 +0530 Subject: New system-config-acpid In-Reply-To: <544eb990805230917q783dfc7ew1566cf431ebb76ef@mail.gmail.com> References: <48207BC5.3060105@redhat.com> <1210089619.17842.2.camel@localhost.localdomain> <409676c70805222215n4b30c80h7d516d5140a28ee7@mail.gmail.com> <544eb990805230418j636b2957oa618865440d36f80@mail.gmail.com> <1211542280.3566.53.camel@cookie.hadess.net> <544eb990805230521p75645e7ar8f7835c5d70bbb14@mail.gmail.com> <1211557498.3566.91.camel@cookie.hadess.net> <544eb990805230903i257a1a76i4c0d70e319ad2159@mail.gmail.com> <4836EB8C.7050305@fedoraproject.org> <544eb990805230917q783dfc7ew1566cf431ebb76ef@mail.gmail.com> Message-ID: <4836EF8C.5080806@fedoraproject.org> Bill Crawford wrote: > 2008/5/23 Rahul Sundaram : > >> I never saw that as a goal. Where did you read that? > > IIRC it came up during one of the endless discussions about KDE being > "allegedly" a second-class citizen in Fedora .. Please cite the source. The rewrite afaik has never had working with other desktop environments better as a goal (I wouldn't even know what such a goal would even mean). The goals are listed in http://live.gnome.org/GDM/NewDesign Rahul From caolanm at redhat.com Fri May 23 16:54:53 2008 From: caolanm at redhat.com (Caolan McNamara) Date: Fri, 23 May 2008 17:54:53 +0100 Subject: PyLucene: How to package libraries that link against OpenJDK libraries? In-Reply-To: <48368AB5.2080405@redhat.com> References: <4835E696.1010401@oss.schwarz.eu> <48368AB5.2080405@redhat.com> Message-ID: <1211561693.15135.4.camel@vain.rhgalway> On Fri, 2008-05-23 at 10:13 +0100, Andrew Haley wrote: > Colin Walters wrote: > > On Thu, May 22, 2008 at 5:33 PM, Felix Schwarz > > wrote: > > > >> c) How to get the correct vm type? On i386 there is a client and a server > >> vm. Is there a way I can "just" get the client vm directory (and as a > >> fallback the server vm)? > > > This is a bit mysterious. I guess I don't understand why PyLucene > would want to poke at the internal VM libraries. *Possibly* so as to be able to dlopen libjvm.so in order to call JNI_CreateJavaVM C. From smooge at gmail.com Fri May 23 17:12:01 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Fri, 23 May 2008 11:12:01 -0600 Subject: What ever happened to "Stateless Linux"? In-Reply-To: <4836E31C.7090103@ittc.ku.edu> References: <4835BA4E.7080107@ittc.ku.edu> <20080522185252.GG8819@nostromo.devel.redhat.com> <4835C305.70708@ittc.ku.edu> <20080522190851.GA21648@nostromo.devel.redhat.com> <4836E31C.7090103@ittc.ku.edu> Message-ID: <80d7e4090805231012g1cf7b98fs2896ce94ca1028c@mail.gmail.com> On Fri, May 23, 2008 at 9:30 AM, Phil Regier wrote: > I forgot to CC the list on the last message, so in case anyone else is > interested, this did work quite well after a little local tweaking. > > It may or may not be interesting to note that anaconda under Fedora 9 failed > to run to completion from the command line, but it worked very well under 8. > > Thanks again, Bill! > A secondary question is what do people need stateless linux to do? What are the places it is useful and how can it be built to do that? A sort of 10 things that can be hacked on and checked off. -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From aoliva at redhat.com Fri May 23 17:18:30 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Fri, 23 May 2008 14:18:30 -0300 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: <1211528657.21380.478.camel@pmac.infradead.org> (David Woodhouse's message of "Fri\, 23 May 2008 08\:44\:17 +0100") References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> <1211405127.21380.382.camel@pmac.infradead.org> <4834D3F2.90409@gmail.com> <20080522164742.GD8443@devserv.devel.redhat.com> <1211478494.21380.459.camel@pmac.infradead.org> <20080522184814.GA17490@devserv.devel.redhat.com> <1211528657.21380.478.camel@pmac.infradead.org> Message-ID: On May 23, 2008, David Woodhouse wrote: > On Thu, 2008-05-22 at 14:48 -0400, Alan Cox wrote: >> On Thu, May 22, 2008 at 06:48:14PM +0100, David Woodhouse wrote: >> > > is a separate work. Like your BIOS for example. >> > >> > Being a separate work doesn't save it from the requirements of the GPL. >> > >> > The GPL clearly states that under some circumstances it _does_ extend to >> > sections which are independent and separate works in themselves. >> >> > If identifiable sections of that work are not derived from the >> > Program, and can be reasonably considered independent and >> > separate works in themselves, then this License, and its terms, >> > do not apply to those sections when you distribute them as >> > separate works. >> > >> > (OK, that's the firmware). >> >> No it isn't. See "mere aggregation" > That's a very optimistic interpretation of 'mere aggregation', given > that the licence is very clearly stating that it applies not only to > derivative works but also to collective works. Besides, in order to claim it's mere aggregation, you have to be able to point at the separate works and say "see, I aggregated this work, that is under the GPLv2, with these other works, that are under various other licenses". Now, where can I get this original work that is under the GPL, that was aggregated with other works? It's just the sort of thing I've looking for, couldn't find, and ended up creating linux-libre for. But I can't find it anywhere. I claim this separate independent work has never existed. > But of course, until/unless it's tested in court, neither of us is right > or wrong. +1 -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From aoliva at redhat.com Fri May 23 17:19:55 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Fri, 23 May 2008 14:19:55 -0300 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: <1211528761.21380.481.camel@pmac.infradead.org> (David Woodhouse's message of "Fri\, 23 May 2008 08\:46\:01 +0100") References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> <1211405127.21380.382.camel@pmac.infradead.org> <1211444657.21380.424.camel@pmac.infradead.org> <20080522183614.GB32314@redhat.com> <1211528761.21380.481.camel@pmac.infradead.org> Message-ID: On May 23, 2008, David Woodhouse wrote: > Hence the suggestion to make the firmware loader capable of having a > built-in set of blobs. Now, the part of your plan that I'm still missing is how to get from that to a blob-free GPLed kernel source tarball. Care to share? Thanks, -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From ssorce at redhat.com Fri May 23 17:20:22 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 23 May 2008 13:20:22 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <48366095.50204@mindspring.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <48366095.50204@mindspring.com> Message-ID: <1211563222.3935.182.camel@localhost.localdomain> On Fri, 2008-05-23 at 02:13 -0400, Richard Hally wrote: > Josh Boyer wrote: > > Let the naming begin! We're starting very early this time around in > > the name game for F10. So, let the suggestions flow! > > > > Remember the rules: > > > > 1) must have some link to Sulphur > > > > More specifically, the link should be > > Sulphur is a and > > is a > > Where is the same for both > > > > 2) The link between and Sulphur cannot be the same as between > > Werewolf and Sulphur. That link was "things that react badly with > > silver". > > > > I will be collecting suggestions for 1 week, so the cutoff for names is: > > > > May 29, 2008 > > > > Suggestions will be run through the legal queue and an election will > > happen for Fedora contributors to pick the next Fedora name. > > > > josh > > > > Acid -- "we are all on Acid" or "give it an Acid test" > > sulfur is a chemical -> acid is a chemical. Acid is not a chemical per se, it is a property. SImo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Fri May 23 17:21:47 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 23 May 2008 13:21:47 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <483664D1.8010303@mindspring.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <483664D1.8010303@mindspring.com> Message-ID: <1211563307.3935.185.camel@localhost.localdomain> On Fri, 2008-05-23 at 02:31 -0400, Richard Hally wrote: > Josh Boyer wrote: > > Let the naming begin! We're starting very early this time around in > > the name game for F10. So, let the suggestions flow! > > > > Remember the rules: > > > > 1) must have some link to Sulphur > > > > More specifically, the link should be > > Sulphur is a and > > is a > > Where is the same for both > > > > 2) The link between and Sulphur cannot be the same as between > > Werewolf and Sulphur. That link was "things that react badly with > > silver". > > > > I will be collecting suggestions for 1 week, so the cutoff for names is: > > > > May 29, 2008 > > > > Suggestions will be run through the legal queue and an election will > > happen for Fedora contributors to pick the next Fedora name. > > > > josh > > > > Steam -- > > sulfur is in coal; steam is in coal (indirectly when you burn coal to heat > water) (Yes that's a stretch) > > We can all be steamed. We'll all be in hot water. we can power a technical > revolution. I have already proposed 'steam'. With, I think, also a better link :-) Simo. -- Simo Sorce * Red Hat, Inc * New York From dwmw2 at infradead.org Fri May 23 17:27:02 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 23 May 2008 18:27:02 +0100 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> <1211405127.21380.382.camel@pmac.infradead.org> <1211444657.21380.424.camel@pmac.infradead.org> <20080522183614.GB32314@redhat.com> <1211528761.21380.481.camel@pmac.infradead.org> Message-ID: <1211563622.28967.60.camel@pmac.infradead.org> On Fri, 2008-05-23 at 14:19 -0300, Alexandre Oliva wrote: > On May 23, 2008, David Woodhouse wrote: > > > Hence the suggestion to make the firmware loader capable of having a > > built-in set of blobs. > > Now, the part of your plan that I'm still missing is how to get from > that to a blob-free GPLed kernel source tarball. Care to share? First we get to a point where the blobs exist separately in the kernel and _can_ be easily removed. The korg1212 sound driver patch was just the first of many, and someone will need to finish the job. When that's done, we can have a sensible discussion upstream about moving them to a separate tarball. And as I said -- even if upstream baulks at that last step, I'd support Fedora doing it on our own. -- dwmw2 From greno at verizon.net Fri May 23 17:41:32 2008 From: greno at verizon.net (Gerry Reno) Date: Fri, 23 May 2008 13:41:32 -0400 Subject: sata and changing devices Message-ID: <483701CC.5010002@verizon.net> We have a new machine which has SATA. This is the first machine we have had with SATA. SATA and these changing device locations are giving me a headache. None of our disk device tools work with SATA. For instance we have a tool that will save all the MBR's and partition tables off to files such as 'hda.mbr' and 'hda.part'. With SATA this does not work because what was 'sda' during this boot may be 'sdc' on the next boot. So I need to find out if there is some best practice guide for how to rewrite our tools so that they can support SATA. We use LVM over RAID on all our drives and all our RAID and LVM tools appear to still work. It is only when dealing with the low-level disk devices themselves that we have problems. Can someone give me some suggestions as to how to manage things when using SATA? Regards, Gerry From pregier at ittc.ku.edu Fri May 23 17:55:22 2008 From: pregier at ittc.ku.edu (Phil Regier) Date: Fri, 23 May 2008 12:55:22 -0500 Subject: What ever happened to "Stateless Linux"? In-Reply-To: <80d7e4090805231012g1cf7b98fs2896ce94ca1028c@mail.gmail.com> References: <4835BA4E.7080107@ittc.ku.edu> <20080522185252.GG8819@nostromo.devel.redhat.com> <4835C305.70708@ittc.ku.edu> <20080522190851.GA21648@nostromo.devel.redhat.com> <4836E31C.7090103@ittc.ku.edu> <80d7e4090805231012g1cf7b98fs2896ce94ca1028c@mail.gmail.com> Message-ID: <4837050A.1050707@ittc.ku.edu> I'm not entirely sure I follow. If you're looking to justify a perception of broad interest, I probably won't be able to offer much on that front. :) For my current purposes, the idea is to be able to to run a full GNU/Linux environment on top of a machine that has a simple system already installed without touching the system as it's installed on disk, in this particular case for testing/running third-party imaging software (not my idea) with no hardware reconfiguration. Another benefit is speed; it's hard to match (estimated) 60 seconds from bare metal to full-fledged init 3 (init 5 if you want to spend the time setting it up) when you're in a hurry and don't have time to re-load a machine. I also seem to recall there being a time when smartctl was not available from rescue mode, but it looks like that concern is obsolete (may have been for a long time now). Even so, from time to time there's something I need to do to recover a failing system that I can't quite seem to do from a rescue shell. So the only benefit that I see in this case that would apply to the Fedora world at large is just the instant-provisioning aspect, which probably is or will be subsumed by a more general set of functionality, such as cobbler. See anything of potentially real value here? Phil Stephen John Smoogen wrote: > On Fri, May 23, 2008 at 9:30 AM, Phil Regier wrote: >> I forgot to CC the list on the last message, so in case anyone else is >> interested, this did work quite well after a little local tweaking. >> >> It may or may not be interesting to note that anaconda under Fedora 9 failed >> to run to completion from the command line, but it worked very well under 8. >> >> Thanks again, Bill! >> > > A secondary question is what do people need stateless linux to do? > What are the places it is useful and how can it be built to do that? A > sort of 10 things that can be hacked on and checked off. > > > From harald at redhat.com Fri May 23 18:00:23 2008 From: harald at redhat.com (Harald Hoyer) Date: Fri, 23 May 2008 20:00:23 +0200 Subject: Neon Sign In-Reply-To: References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211462088.4891.45.camel@victoria> <48357E29.2010609@nobugconsulting.ro> <1211466316.5079.61.camel@localhost.localdomain> <1211466224.3559.48.camel@cutter> <1211467352.5079.65.camel@localhost.localdomain> <483587E7.2020300@nobugconsulting.ro> <1211486081.4891.113.camel@victoria> <7f692fec0805221329s25298462w5d75eac7626c0bfe@mail.gmail.com> Message-ID: Harald Hoyer wrote: > Harald Hoyer wrote: >> Hmm, I liked the idea and inkscaped s.th. together :) >> >> Somebody can make an animated png out of it ... blinking :) >> >> http://harald.fedorapeople.org/Fedora-always-open.png >> http://harald.fedorapeople.org/Fedora-always-open.svg >> > > http://harald.fedorapeople.org/always-open/ > http://harald.fedorapeople.org/always-open/Fedora-animated.gif From jkeating at redhat.com Fri May 23 18:30:36 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 23 May 2008 14:30:36 -0400 Subject: sata and changing devices In-Reply-To: <483701CC.5010002@verizon.net> References: <483701CC.5010002@verizon.net> Message-ID: <1211567436.5079.147.camel@localhost.localdomain> On Fri, 2008-05-23 at 13:41 -0400, Gerry Reno wrote: > We have a new machine which has SATA. This is the first machine we have > had with SATA. SATA and these changing device locations are giving me a > headache. None of our disk device tools work with SATA. For instance > we have a tool that will save all the MBR's and partition tables off to > files such as 'hda.mbr' and 'hda.part'. With SATA this does not work > because what was 'sda' during this boot may be 'sdc' on the next boot. > So I need to find out if there is some best practice guide for how to > rewrite our tools so that they can support SATA. We use LVM over RAID > on all our drives and all our RAID and LVM tools appear to still work. > It is only when dealing with the low-level disk devices themselves that > we have problems. Can someone give me some suggestions as to how to > manage things when using SATA? > > Regards, > Gerry > Use disk UUIDs instead of device names. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Fri May 23 18:30:09 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 23 May 2008 11:30:09 -0700 Subject: Packager Sponsors Responsibility Policy In-Reply-To: <20080523102047.7eeae2f0@ohm.scrye.com> References: <1211502398.29628.16.camel@kennedy> <20080523132821.GC2612@free.fr> <20080523102047.7eeae2f0@ohm.scrye.com> Message-ID: <48370D31.9040304@gmail.com> Kevin Fenzi wrote: > On Fri, 23 May 2008 15:28:21 +0200 > pertusus at free.fr (Patrice Dumas) wrote: > >> On Thu, May 22, 2008 at 08:26:38PM -0400, Brian Pepple wrote: >>> == Fix issues caused by sponsored maintainers == >>> If one of your sponsored maintainers is unable to fix an issue in >>> their package(s), it's up to the sponsor to step in and make the >>> needed fixes. This might include pushing a security update when the >>> maintainer is unavailable, applying a patch, removing a improperly >>> build package, or other time or security sensitive issue. Note that >>> the maintainer should be shown the fix and how to manage the issue >>> moving forward. >> There are many technical issues here. It would be nice if a sponsor >> could be in initialCC/Watchcommit/commit for all the packages of a >> sponsored person (and not by package), without needing a manual >> intervention from the sponsored person, and such that the sponsored >> person cannot revoke it. Also it should be easy to give up with those >> acls when the sponsor thinks that the sponsored person is competent >> enough. > > Yeah, that would be nice. Pkgdb enhancement it sounds like... > could you file it? > Just a note: This would be a large change to the packagedb. If someone wants to spearhead implementation of it, let me know and I'll outline some of the changes that will need to be made. -Toshio From fedora at dm.cobite.com Fri May 23 18:31:33 2008 From: fedora at dm.cobite.com (David Mansfield) Date: Fri, 23 May 2008 14:31:33 -0400 Subject: Neon Sign In-Reply-To: References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211462088.4891.45.camel@victoria> <48357E29.2010609@nobugconsulting.ro> <1211466316.5079.61.camel@localhost.localdomain> <1211466224.3559.48.camel@cutter> <1211467352.5079.65.camel@localhost.localdomain> <483587E7.2020300@nobugconsulting.ro> <1211486081.4891.113.camel@victoria> <7f692fec0805221329s25298462w5d75eac7626c0bfe@mail.gmail.com> Message-ID: <1211567493.3584.25.camel@gandalf.cobite.com> On Fri, 2008-05-23 at 20:00 +0200, Harald Hoyer wrote: > Harald Hoyer wrote: > > Harald Hoyer wrote: > >> Hmm, I liked the idea and inkscaped s.th. together :) > >> > >> Somebody can make an animated png out of it ... blinking :) > >> > >> http://harald.fedorapeople.org/Fedora-always-open.png > >> http://harald.fedorapeople.org/Fedora-always-open.svg > >> > > > > http://harald.fedorapeople.org/always-open/ > > > > > http://harald.fedorapeople.org/always-open/Fedora-animated.gif > Now you're talkin! Looks great! I'm convinced. David From berrange at redhat.com Fri May 23 18:34:01 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 23 May 2008 19:34:01 +0100 Subject: sata and changing devices In-Reply-To: <483701CC.5010002@verizon.net> References: <483701CC.5010002@verizon.net> Message-ID: <20080523183401.GC12467@redhat.com> On Fri, May 23, 2008 at 01:41:32PM -0400, Gerry Reno wrote: > We have a new machine which has SATA. This is the first machine we have > had with SATA. SATA and these changing device locations are giving me a > headache. None of our disk device tools work with SATA. For instance > we have a tool that will save all the MBR's and partition tables off to > files such as 'hda.mbr' and 'hda.part'. With SATA this does not work > because what was 'sda' during this boot may be 'sdc' on the next boot. > So I need to find out if there is some best practice guide for how to > rewrite our tools so that they can support SATA. We use LVM over RAID > on all our drives and all our RAID and LVM tools appear to still work. > It is only when dealing with the low-level disk devices themselves that > we have problems. Can someone give me some suggestions as to how to > manage things when using SATA? If you want stable device names, don't use /dev/sd* at all. This is what /dev/disk/by-{id,label,path,uuid}/* are for Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From harald at redhat.com Fri May 23 18:37:31 2008 From: harald at redhat.com (Harald Hoyer) Date: Fri, 23 May 2008 20:37:31 +0200 Subject: Neon Sign In-Reply-To: <1211567493.3584.25.camel@gandalf.cobite.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211462088.4891.45.camel@victoria> <48357E29.2010609@nobugconsulting.ro> <1211466316.5079.61.camel@localhost.localdomain> <1211466224.3559.48.camel@cutter> <1211467352.5079.65.camel@localhost.localdomain> <483587E7.2020300@nobugconsulting.ro> <1211486081.4891.113.camel@victoria> <7f692fec0805221329s25298462w5d75eac7626c0bfe@mail.gmail.com> <1211567493.3584.25.camel@gandalf.cobite.com> Message-ID: David Mansfield wrote: > On Fri, 2008-05-23 at 20:00 +0200, Harald Hoyer wrote: >> Harald Hoyer wrote: >>> Harald Hoyer wrote: >>>> Hmm, I liked the idea and inkscaped s.th. together :) >>>> >>>> Somebody can make an animated png out of it ... blinking :) >>>> >>>> http://harald.fedorapeople.org/Fedora-always-open.png >>>> http://harald.fedorapeople.org/Fedora-always-open.svg >>>> >>> http://harald.fedorapeople.org/always-open/ >>> >> >> http://harald.fedorapeople.org/always-open/Fedora-animated.gif >> > > Now you're talkin! Looks great! > > I'm convinced. > > David > > I am sure somebody else can do better. I am no artist, only software developer :) From aoliva at redhat.com Fri May 23 19:00:04 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Fri, 23 May 2008 16:00:04 -0300 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: <1211563622.28967.60.camel@pmac.infradead.org> (David Woodhouse's message of "Fri\, 23 May 2008 18\:27\:02 +0100") References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> <1211405127.21380.382.camel@pmac.infradead.org> <1211444657.21380.424.camel@pmac.infradead.org> <20080522183614.GB32314@redhat.com> <1211528761.21380.481.camel@pmac.infradead.org> <1211563622.28967.60.camel@pmac.infradead.org> Message-ID: On May 23, 2008, David Woodhouse wrote: > On Fri, 2008-05-23 at 14:19 -0300, Alexandre Oliva wrote: >> On May 23, 2008, David Woodhouse wrote: >> >> > Hence the suggestion to make the firmware loader capable of having a >> > built-in set of blobs. >> >> Now, the part of your plan that I'm still missing is how to get from >> that to a blob-free GPLed kernel source tarball. Care to share? > First we get to a point where the blobs exist separately in the kernel > and _can_ be easily removed. The korg1212 sound driver patch was just > the first of many, and someone will need to finish the job. Understood. I see one of your patches simply renames a .h to a .c and makes the blob a built-in firmware. Any reason to not have moved it to the firmware/ dir, as I expected from looking at your patches? rm -rf firmware/ is so much simpler :-) > When that's done, we can have a sensible discussion upstream about > moving them to a separate tarball. Hard to have a sensible discussion when what's obvious to one is ridiculous to the other, and vice-versa. (And, just to avoid misunderstandings, I don't mean you or Alan to be neither "one" or "other" in the previous sentence :-) > And as I said -- even if upstream baulks at that last step, I'd > support Fedora doing it on our own. So that we'd have our own linux-libre? Sounds like a plan. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From jspaleta at gmail.com Fri May 23 19:01:13 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 23 May 2008 11:01:13 -0800 Subject: Neon Sign In-Reply-To: References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211466224.3559.48.camel@cutter> <1211467352.5079.65.camel@localhost.localdomain> <483587E7.2020300@nobugconsulting.ro> <1211486081.4891.113.camel@victoria> <7f692fec0805221329s25298462w5d75eac7626c0bfe@mail.gmail.com> Message-ID: <604aa7910805231201w5be70406k95ea980f2a0d72be@mail.gmail.com> On Fri, May 23, 2008 at 10:00 AM, Harald Hoyer wrote: > http://harald.fedorapeople.org/always-open/Fedora-animated.gif Holy bat guano batman! How do we add an audio track to that so we can hear the eletrical flickering. That's so very very good. -jef From harald at redhat.com Fri May 23 19:13:06 2008 From: harald at redhat.com (Harald Hoyer) Date: Fri, 23 May 2008 21:13:06 +0200 Subject: Neon Sign In-Reply-To: <604aa7910805231201w5be70406k95ea980f2a0d72be@mail.gmail.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211466224.3559.48.camel@cutter> <1211467352.5079.65.camel@localhost.localdomain> <483587E7.2020300@nobugconsulting.ro> <1211486081.4891.113.camel@victoria> <7f692fec0805221329s25298462w5d75eac7626c0bfe@mail.gmail.com> <604aa7910805231201w5be70406k95ea980f2a0d72be@mail.gmail.com> Message-ID: Jeff Spaleta wrote: > On Fri, May 23, 2008 at 10:00 AM, Harald Hoyer wrote: >> http://harald.fedorapeople.org/always-open/Fedora-animated.gif > > Holy bat guano batman! > > How do we add an audio track to that so we can hear the eletrical flickering. > > That's so very very good. > > -jef > Here is the source... feel free to do it :) http://harald.fedorapeople.org/always-open/Fedora-animated.xcf From loupgaroublond at gmail.com Fri May 23 19:08:48 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Fri, 23 May 2008 15:08:48 -0400 Subject: Neon Sign In-Reply-To: References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211466224.3559.48.camel@cutter> <1211467352.5079.65.camel@localhost.localdomain> <483587E7.2020300@nobugconsulting.ro> <1211486081.4891.113.camel@victoria> <7f692fec0805221329s25298462w5d75eac7626c0bfe@mail.gmail.com> Message-ID: <7f692fec0805231208o18c55b68u5b5c7e48dc1ded46@mail.gmail.com> On Fri, May 23, 2008 at 2:00 PM, Harald Hoyer wrote: > Harald Hoyer wrote: >> >> Harald Hoyer wrote: >>> >>> Hmm, I liked the idea and inkscaped s.th. together :) >>> >>> Somebody can make an animated png out of it ... blinking :) >>> >>> http://harald.fedorapeople.org/Fedora-always-open.png >>> http://harald.fedorapeople.org/Fedora-always-open.svg >>> >> >> http://harald.fedorapeople.org/always-open/ >> > > > http://harald.fedorapeople.org/always-open/Fedora-animated.gif Makes me want to go out at 2 am for a cup of coffee and chocolate pie at the local diner for some late night Fedora Hacking. -Yaakov From lesmikesell at gmail.com Fri May 23 19:27:29 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 23 May 2008 14:27:29 -0500 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> <1211405127.21380.382.camel@pmac.infradead.org> <1211444657.21380.424.camel@pmac.infradead.org> <20080522183614.GB32314@redhat.com> <1211528761.21380.481.camel@pmac.infradead.org> <1211563622.28967.60.camel@pmac.infradead.org> Message-ID: <48371AA1.5080500@gmail.com> Alexandre Oliva wrote: > > Any reason to not have moved it to the firmware/ dir, as I expected > from looking at your patches? > > rm -rf firmware/ is so much simpler :-) For your purpose, wouldn't you want to separate source-available-firmware and documentation-available bit settings from the parts that would be more difficult for you to modify freely? -- Les Mikesell lesmikesell at gmail.com From ivazqueznet at gmail.com Fri May 23 19:33:03 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Fri, 23 May 2008 15:33:03 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: References: <20080522065724.1788e577@vader.jdub.homelinux.org> <20080522170718.GE8819@nostromo.devel.redhat.com> <544eb990805221018h2a263e00y82eed56b43a698d4@mail.gmail.com> Message-ID: <1211571183.3444.21.camel@ignacio.lan> On Fri, 2008-05-23 at 11:33 +0200, Matej Cepl wrote: > On 2008-05-22, 17:18 GMT, Bill Crawford wrote: > > You should rush to release Fedora X (Independence) on July 4th. > > It may well be US-centric, but it's pretty widely known :o) > > Will be probably ignored as was my suggestion for Fedora > 8 (released in early November 2007, 90 years after the disaster) > -- Aurora. Oh well. Unfortunately Aurora is already the name of a SPARC port of Fedora. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-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 May 23 19:35:26 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 23 May 2008 11:35:26 -0800 Subject: Neon Sign In-Reply-To: References: <20080522065724.1788e577@vader.jdub.homelinux.org> <483587E7.2020300@nobugconsulting.ro> <1211486081.4891.113.camel@victoria> <7f692fec0805221329s25298462w5d75eac7626c0bfe@mail.gmail.com> <604aa7910805231201w5be70406k95ea980f2a0d72be@mail.gmail.com> Message-ID: <604aa7910805231235j44b13ea0k2fdf5740acadef9b@mail.gmail.com> On Fri, May 23, 2008 at 11:13 AM, Harald Hoyer wrote: > Here is the source... feel free to do it :) There's a reason i started the sentence with 'How do we...' instead of 'We should...' It was my attempt to indicate that your achievements have surpassed me, and that I a filled only with un-knowledge in the areas of animated imagery. I guess i need to convert the animated gif into a theora video and add an audio track. I guess that's the best way to accomplish it. -jef From loupgaroublond at gmail.com Fri May 23 19:12:15 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Fri, 23 May 2008 15:12:15 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1211563222.3935.182.camel@localhost.localdomain> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <48366095.50204@mindspring.com> <1211563222.3935.182.camel@localhost.localdomain> Message-ID: <7f692fec0805231212q2dcfce60uaf79c277db2f98bd@mail.gmail.com> On Fri, May 23, 2008 at 1:20 PM, Simo Sorce wrote: > On Fri, 2008-05-23 at 02:13 -0400, Richard Hally wrote: >> Josh Boyer wrote: >> > Let the naming begin! We're starting very early this time around in >> > the name game for F10. So, let the suggestions flow! >> > >> > Remember the rules: >> > >> > 1) must have some link to Sulphur >> > >> > More specifically, the link should be >> > Sulphur is a and >> > is a >> > Where is the same for both >> > >> > 2) The link between and Sulphur cannot be the same as between >> > Werewolf and Sulphur. That link was "things that react badly with >> > silver". >> > >> > I will be collecting suggestions for 1 week, so the cutoff for names is: >> > >> > May 29, 2008 >> > >> > Suggestions will be run through the legal queue and an election will >> > happen for Fedora contributors to pick the next Fedora name. >> > >> > josh >> > >> >> Acid -- "we are all on Acid" or "give it an Acid test" >> >> sulfur is a chemical -> acid is a chemical. > > Acid is not a chemical per se, it is a property. > Lysergic Acid Diethylamide :) (or more appropriately Lysergsaeurediethylamid). We could dedicate Fedora 10 to Albert Hoffman, and then say ours goes to 102. -Yaakov From cra at WPI.EDU Fri May 23 18:16:53 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 23 May 2008 14:16:53 -0400 Subject: Neon Sign In-Reply-To: References: <1211466316.5079.61.camel@localhost.localdomain> <1211466224.3559.48.camel@cutter> <1211467352.5079.65.camel@localhost.localdomain> <483587E7.2020300@nobugconsulting.ro> <1211486081.4891.113.camel@victoria> <7f692fec0805221329s25298462w5d75eac7626c0bfe@mail.gmail.com> Message-ID: <20080523181653.GD3364@angus.ind.WPI.EDU> On Fri, May 23, 2008 at 08:00:23PM +0200, Harald Hoyer wrote: > Harald Hoyer wrote: >> Harald Hoyer wrote: >>> Hmm, I liked the idea and inkscaped s.th. together :) >>> >>> Somebody can make an animated png out of it ... blinking :) >>> >>> http://harald.fedorapeople.org/Fedora-always-open.png >>> http://harald.fedorapeople.org/Fedora-always-open.svg >>> >> >> http://harald.fedorapeople.org/always-open/ >> > > > http://harald.fedorapeople.org/always-open/Fedora-animated.gif +1 Neon Excellent! From jspaleta at gmail.com Fri May 23 19:39:29 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 23 May 2008 11:39:29 -0800 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: <1211551011.28967.20.camel@pmac.infradead.org> References: <1211377739.4210.2.camel@truman> <1211410870.2290.5.camel@kennedy> <20080522162729.1c8298da@ludwig-alpha.unil.ch> <1211467361.21380.448.camel@pmac.infradead.org> <604aa7910805220853y365ecbb2qd64319388ed26e89@mail.gmail.com> <1211551011.28967.20.camel@pmac.infradead.org> Message-ID: <604aa7910805231239v77a17d6bk21fa04cc22fe412d@mail.gmail.com> On Fri, May 23, 2008 at 5:56 AM, David Woodhouse wrote: > http://lkml.org/lkml/2008/5/23/170 Thanks. I solemnly swear not to insert myself into the technical discussion and drag it too its doom. But I think its a good thing to watch and maybe hold up later as a way to drive technical changes upstream effectively. -jef From John.Mizell at tch.com Fri May 23 19:43:55 2008 From: John.Mizell at tch.com (John.Mizell at tch.com) Date: Fri, 23 May 2008 13:43:55 -0600 Subject: WPA2 support ase-ccm/tkip Message-ID: Does WPA2/WPA support aes-ccm/tkip in fedora currently? I do not see it as an option in network manager. If not is being worked on? John Mizell Systems Administrator TCH 4185 Harrison Blvd. Suite 202 Ogden, Utah 84403 801-624-4604 From alan at redhat.com Fri May 23 19:49:42 2008 From: alan at redhat.com (Alan Cox) Date: Fri, 23 May 2008 15:49:42 -0400 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: <1211528657.21380.478.camel@pmac.infradead.org> References: <20080521143345.383eb10b@vader.jdub.homelinux.org> <1211405127.21380.382.camel@pmac.infradead.org> <4834D3F2.90409@gmail.com> <20080522164742.GD8443@devserv.devel.redhat.com> <1211478494.21380.459.camel@pmac.infradead.org> <20080522184814.GA17490@devserv.devel.redhat.com> <1211528657.21380.478.camel@pmac.infradead.org> Message-ID: <20080523194942.GA13150@devserv.devel.redhat.com> On Fri, May 23, 2008 at 08:44:17AM +0100, David Woodhouse wrote: > > No it isn't. See "mere aggregation" > > That's a very optimistic interpretation of 'mere aggregation', given > that the licence is very clearly stating that it applies not only to > derivative works but also to collective works. I think the lawyers probably have more idea than you. From pemboa at gmail.com Fri May 23 19:57:28 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 23 May 2008 14:57:28 -0500 Subject: Neon Sign In-Reply-To: <604aa7910805231201w5be70406k95ea980f2a0d72be@mail.gmail.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211467352.5079.65.camel@localhost.localdomain> <483587E7.2020300@nobugconsulting.ro> <1211486081.4891.113.camel@victoria> <7f692fec0805221329s25298462w5d75eac7626c0bfe@mail.gmail.com> <604aa7910805231201w5be70406k95ea980f2a0d72be@mail.gmail.com> Message-ID: <16de708d0805231257r4b838069g31c0b7829de8cd96@mail.gmail.com> On Fri, May 23, 2008 at 2:01 PM, Jeff Spaleta wrote: > On Fri, May 23, 2008 at 10:00 AM, Harald Hoyer wrote: >> http://harald.fedorapeople.org/always-open/Fedora-animated.gif > > Holy bat guano batman! > > How do we add an audio track to that so we can hear the eletrical flickering. > > That's so very very good. Would likely require flash -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From cooly at gnome.eu.org Fri May 23 19:59:11 2008 From: cooly at gnome.eu.org (Lucian Langa) Date: Fri, 23 May 2008 22:59:11 +0300 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <4836796F.8040101@nicubunu.ro> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <20080522170718.GE8819@nostromo.devel.redhat.com> <4836748D.2090707@googlemail.com> <4836796F.8040101@nicubunu.ro> Message-ID: <1211572751.27940.24.camel@mayday> ? The mineral pyrite, or iron pyrite,is an iron sulfide with the formula FeS2. http://en.wikipedia.org/wiki/Pyrite http://www.3dchem.com/molecules.asp?ID=153# Cheers, --lucilanga On Fri, 2008-05-23 at 10:59 +0300, Nicu Buculei wrote: > Tim Lauridsen wrote: > > Bill Nottingham wrote: > >> Diablo > > > > This one is cool (Fedora 10 : El Diablo) Diablo smells like sulphur. > > In the fourth act of Diablo II were plenty of rivers of something, > molten sulphur, lava or both (yup, it was in Hell): > http://www.gamebanshee.com/showshot.php?/screenshots/diabloii/screenshot42.jpg From alan at redhat.com Fri May 23 20:00:48 2008 From: alan at redhat.com (Alan Cox) Date: Fri, 23 May 2008 16:00:48 -0400 Subject: sata and changing devices In-Reply-To: <483701CC.5010002@verizon.net> References: <483701CC.5010002@verizon.net> Message-ID: <20080523200048.GC13150@devserv.devel.redhat.com> On Fri, May 23, 2008 at 01:41:32PM -0400, Gerry Reno wrote: > So I need to find out if there is some best practice guide for how to > rewrite our tools so that they can support SATA. We use LVM over RAID > on all our drives and all our RAID and LVM tools appear to still work. > It is only when dealing with the low-level disk devices themselves that > we have problems. Can someone give me some suggestions as to how to > manage things when using SATA? You want to look at the volume itself. SATA is hotplug so talking about devices by their bus location is a bit meaningless. You've got two useful identifiers 1. The serial number of the drive available directly either by using SG_IO to issue an IDENTIFY or the boot one (which is fine) via ioctls too. Or you can script parsing hdparm of course. 2. Labels on the file systems which is what RAID/LVM/etc all use. For low level work where you want to know "this physical disk is the one I saw last week" the disk vendor|model|serial combination should be unique for any modern real world drive. From harald at redhat.com Fri May 23 20:03:24 2008 From: harald at redhat.com (Harald Hoyer) Date: Fri, 23 May 2008 22:03:24 +0200 Subject: Neon Sign In-Reply-To: <604aa7910805231235j44b13ea0k2fdf5740acadef9b@mail.gmail.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <483587E7.2020300@nobugconsulting.ro> <1211486081.4891.113.camel@victoria> <7f692fec0805221329s25298462w5d75eac7626c0bfe@mail.gmail.com> <604aa7910805231201w5be70406k95ea980f2a0d72be@mail.gmail.com> <604aa7910805231235j44b13ea0k2fdf5740acadef9b@mail.gmail.com> Message-ID: Jeff Spaleta wrote: > On Fri, May 23, 2008 at 11:13 AM, Harald Hoyer wrote: >> Here is the source... feel free to do it :) > > There's a reason i started the sentence with 'How do we...' instead > of 'We should...' It was my attempt to indicate that your achievements > have surpassed me, and that I a filled only with un-knowledge in the > areas of animated imagery. I guess i need to convert the animated gif > into a theora video and add an audio track. I guess that's the best > way to accomplish it. > > -jef > Here is an ogg video :) http://harald.fedorapeople.org/always-open/Fedora-animated.ogv $ totem http://harald.fedorapeople.org/always-open/Fedora-animated.ogv I split the .xcf in several pngs and did: $ mencoder -fps 2 mf://*.png -o output.avi -ovc lavc -lavcopts vcodec=mpeg4 $ ffmpeg2theora output.avi -o output.ogv Is there a better way? From P at draigBrady.com Fri May 23 20:03:28 2008 From: P at draigBrady.com (=?ISO-8859-1?Q?P=E1draig_Brady?=) Date: Fri, 23 May 2008 21:03:28 +0100 Subject: Neon Sign In-Reply-To: References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211462088.4891.45.camel@victoria> <48357E29.2010609@nobugconsulting.ro> <1211466316.5079.61.camel@localhost.localdomain> <1211466224.3559.48.camel@cutter> <1211467352.5079.65.camel@localhost.localdomain> <483587E7.2020300@nobugconsulting.ro> <1211486081.4891.113.camel@victoria> <7f692fec0805221329s25298462w5d75eac7626c0bfe@mail.gmail.com> Message-ID: <48372310.90804@draigBrady.com> Harald Hoyer wrote: > > http://harald.fedorapeople.org/always-open/Fedora-animated.gif very very good! From stickster at gmail.com Fri May 23 20:06:16 2008 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 23 May 2008 16:06:16 -0400 Subject: Neon Sign In-Reply-To: References: <20080522065724.1788e577@vader.jdub.homelinux.org> <483587E7.2020300@nobugconsulting.ro> <1211486081.4891.113.camel@victoria> <7f692fec0805221329s25298462w5d75eac7626c0bfe@mail.gmail.com> <604aa7910805231201w5be70406k95ea980f2a0d72be@mail.gmail.com> <604aa7910805231235j44b13ea0k2fdf5740acadef9b@mail.gmail.com> Message-ID: <1211573176.31834.3.camel@victoria> On Fri, 2008-05-23 at 22:03 +0200, Harald Hoyer wrote: > Jeff Spaleta wrote: > > On Fri, May 23, 2008 at 11:13 AM, Harald Hoyer wrote: > >> Here is the source... feel free to do it :) > > > > There's a reason i started the sentence with 'How do we...' instead > > of 'We should...' It was my attempt to indicate that your achievements > > have surpassed me, and that I a filled only with un-knowledge in the > > areas of animated imagery. I guess i need to convert the animated gif > > into a theora video and add an audio track. I guess that's the best > > way to accomplish it. > > > > -jef > > > > Here is an ogg video :) > > http://harald.fedorapeople.org/always-open/Fedora-animated.ogv > > $ totem http://harald.fedorapeople.org/always-open/Fedora-animated.ogv > > I split the .xcf in several pngs and did: > > $ mencoder -fps 2 mf://*.png -o output.avi -ovc lavc -lavcopts vcodec=mpeg4 > $ ffmpeg2theora output.avi -o output.ogv > > Is there a better way? I'd think so, if only from the "FOSS only" perspective. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-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 May 23 20:06:25 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 23 May 2008 12:06:25 -0800 Subject: Neon Sign In-Reply-To: References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211486081.4891.113.camel@victoria> <7f692fec0805221329s25298462w5d75eac7626c0bfe@mail.gmail.com> <604aa7910805231201w5be70406k95ea980f2a0d72be@mail.gmail.com> <604aa7910805231235j44b13ea0k2fdf5740acadef9b@mail.gmail.com> Message-ID: <604aa7910805231306s220412ebucb5b3152188e34d5@mail.gmail.com> On Fri, May 23, 2008 at 12:03 PM, Harald Hoyer wrote: > Here is an ogg video :) > > http://harald.fedorapeople.org/always-open/Fedora-animated.ogv > > $ totem http://harald.fedorapeople.org/always-open/Fedora-animated.ogv > > I split the .xcf in several pngs and did: > > $ mencoder -fps 2 mf://*.png -o output.avi -ovc lavc -lavcopts vcodec=mpeg4 > $ ffmpeg2theora output.avi -o output.ogv > > Is there a better way? there has to be a way to do it with gst based pipelines. And I'd rather use that way...because its out-of-the-box compatible. Having to reach for mencoder or ffmpeg for dealing with formats we can actually support out of the box...is "the lose." -jef From jwboyer at gmail.com Fri May 23 20:09:11 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 23 May 2008 15:09:11 -0500 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1211572751.27940.24.camel@mayday> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <20080522170718.GE8819@nostromo.devel.redhat.com> <4836748D.2090707@googlemail.com> <4836796F.8040101@nicubunu.ro> <1211572751.27940.24.camel@mayday> Message-ID: <20080523150911.500f2f1d@vader.jdub.homelinux.org> On Fri, 23 May 2008 22:59:11 +0300 Lucian Langa wrote: > > ? > The mineral pyrite, or iron pyrite,is an iron sulfide with the formula > FeS2. Hm. pyrite is commonly known as "Fool's Gold". Also, what is the "is a" connection there? Sulphur is a... Pyrite is a... josh From sandeen at redhat.com Fri May 23 20:10:30 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Fri, 23 May 2008 15:10:30 -0500 Subject: Neon Sign In-Reply-To: <1211573176.31834.3.camel@victoria> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <483587E7.2020300@nobugconsulting.ro> <1211486081.4891.113.camel@victoria> <7f692fec0805221329s25298462w5d75eac7626c0bfe@mail.gmail.com> <604aa7910805231201w5be70406k95ea980f2a0d72be@mail.gmail.com> <604aa7910805231235j44b13ea0k2fdf5740acadef9b@mail.gmail.com> <1211573176.31834.3.camel@victoria> Message-ID: <483724B6.4070509@redhat.com> Paul W. Frields wrote: > On Fri, 2008-05-23 at 22:03 +0200, Harald Hoyer wrote: >> Jeff Spaleta wrote: >>> On Fri, May 23, 2008 at 11:13 AM, Harald Hoyer wrote: >>>> Here is the source... feel free to do it :) >>> There's a reason i started the sentence with 'How do we...' instead >>> of 'We should...' It was my attempt to indicate that your achievements >>> have surpassed me, and that I a filled only with un-knowledge in the >>> areas of animated imagery. I guess i need to convert the animated gif >>> into a theora video and add an audio track. I guess that's the best >>> way to accomplish it. >>> >>> -jef >>> >> Here is an ogg video :) >> >> http://harald.fedorapeople.org/always-open/Fedora-animated.ogv >> >> $ totem http://harald.fedorapeople.org/always-open/Fedora-animated.ogv >> >> I split the .xcf in several pngs and did: >> >> $ mencoder -fps 2 mf://*.png -o output.avi -ovc lavc -lavcopts vcodec=mpeg4 >> $ ffmpeg2theora output.avi -o output.ogv >> >> Is there a better way? > > I'd think so, if only from the "FOSS only" perspective. png2theora? -Eric From harald at redhat.com Fri May 23 20:10:11 2008 From: harald at redhat.com (Harald Hoyer) Date: Fri, 23 May 2008 22:10:11 +0200 Subject: Neon Sign In-Reply-To: <604aa7910805231306s220412ebucb5b3152188e34d5@mail.gmail.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211486081.4891.113.camel@victoria> <7f692fec0805221329s25298462w5d75eac7626c0bfe@mail.gmail.com> <604aa7910805231201w5be70406k95ea980f2a0d72be@mail.gmail.com> <604aa7910805231235j44b13ea0k2fdf5740acadef9b@mail.gmail.com> <604aa7910805231306s220412ebucb5b3152188e34d5@mail.gmail.com> Message-ID: Jeff Spaleta wrote: > On Fri, May 23, 2008 at 12:03 PM, Harald Hoyer wrote: >> Here is an ogg video :) >> >> http://harald.fedorapeople.org/always-open/Fedora-animated.ogv >> >> $ totem http://harald.fedorapeople.org/always-open/Fedora-animated.ogv >> >> I split the .xcf in several pngs and did: >> >> $ mencoder -fps 2 mf://*.png -o output.avi -ovc lavc -lavcopts vcodec=mpeg4 >> $ ffmpeg2theora output.avi -o output.ogv >> >> Is there a better way? > > there has to be a way to do it with gst based pipelines. And I'd > rather use that way...because its out-of-the-box compatible. Having > to reach for mencoder or ffmpeg for dealing with formats we can > actually support out of the box...is "the lose." > > -jef > Tell me how :) From harald at redhat.com Fri May 23 20:16:29 2008 From: harald at redhat.com (Harald Hoyer) Date: Fri, 23 May 2008 22:16:29 +0200 Subject: Neon Sign In-Reply-To: <483724B6.4070509@redhat.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <483587E7.2020300@nobugconsulting.ro> <1211486081.4891.113.camel@victoria> <7f692fec0805221329s25298462w5d75eac7626c0bfe@mail.gmail.com> <604aa7910805231201w5be70406k95ea980f2a0d72be@mail.gmail.com> <604aa7910805231235j44b13ea0k2fdf5740acadef9b@mail.gmail.com> <1211573176.31834.3.camel@victoria> <483724B6.4070509@redhat.com> Message-ID: Eric Sandeen wrote: > Paul W. Frields wrote: >> On Fri, 2008-05-23 at 22:03 +0200, Harald Hoyer wrote: >>> Jeff Spaleta wrote: >>>> On Fri, May 23, 2008 at 11:13 AM, Harald Hoyer wrote: >>>>> Here is the source... feel free to do it :) >>>> There's a reason i started the sentence with 'How do we...' instead >>>> of 'We should...' It was my attempt to indicate that your achievements >>>> have surpassed me, and that I a filled only with un-knowledge in the >>>> areas of animated imagery. I guess i need to convert the animated gif >>>> into a theora video and add an audio track. I guess that's the best >>>> way to accomplish it. >>>> >>>> -jef >>>> >>> Here is an ogg video :) >>> >>> http://harald.fedorapeople.org/always-open/Fedora-animated.ogv >>> >>> $ totem http://harald.fedorapeople.org/always-open/Fedora-animated.ogv >>> >>> I split the .xcf in several pngs and did: >>> >>> $ mencoder -fps 2 mf://*.png -o output.avi -ovc lavc -lavcopts vcodec=mpeg4 >>> $ ffmpeg2theora output.avi -o output.ogv >>> >>> Is there a better way? >> I'd think so, if only from the "FOSS only" perspective. > > png2theora? > > -Eric > $ png2theora -f 2 -v 10 -o output.ogg file-%02d.png too obvious :) replaced the old one with the free version and renamed it to .ogg :) http://harald.fedorapeople.org/always-open/Fedora-animated.ogg From jspaleta at gmail.com Fri May 23 20:16:49 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 23 May 2008 12:16:49 -0800 Subject: Neon Sign In-Reply-To: <483724B6.4070509@redhat.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <604aa7910805231201w5be70406k95ea980f2a0d72be@mail.gmail.com> <604aa7910805231235j44b13ea0k2fdf5740acadef9b@mail.gmail.com> <1211573176.31834.3.camel@victoria> <483724B6.4070509@redhat.com> Message-ID: <604aa7910805231316s12f0254i904d5f106764c3e7@mail.gmail.com> On Fri, May 23, 2008 at 12:10 PM, Eric Sandeen wrote: > png2theora? excellent yum install theora-tools -jef From j.w.r.degoede at hhs.nl Fri May 23 20:16:40 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 23 May 2008 22:16:40 +0200 Subject: Announcing a new F-10 Feature Proposal: Better Webcam Support In-Reply-To: <20080523152426.GB3224@nostromo.devel.redhat.com> References: <4836DA23.3090709@hhs.nl> <20080523152426.GB3224@nostromo.devel.redhat.com> Message-ID: <48372628.7030905@hhs.nl> Bill Nottingham wrote: > Hans de Goede (j.w.r.degoede at hhs.nl) said: >> See: >> >> http://fedoraproject.org/wiki/Features/BetterWebcamSupport > > Any reason a shim library is simpler than porting apps to V4L2? > Because most v4l1 apps expect to say things to the webcam like gimme rgb data please, whereas the raw format on the usb wire may be something completely different with v4l1, the conversion used to be done in the kernel, but with v4l2 this is (rightfully) no longer done. Also there are quite a few v4l1 apps. So its not just API conversion, but also image format conversion. Alternatively a v4l2 library could be written which offers a higher abstraction layer could be written and apps ported to that, I guess thats the golden way. But so much todo in so little time. The shim also has the advantage of working with abominations like flash and skype, which although abominal are also quite popular. Regards, Hans From j.w.r.degoede at hhs.nl Fri May 23 20:17:55 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 23 May 2008 22:17:55 +0200 Subject: Announcing a new F-10 Feature Proposal: Better Webcam Support In-Reply-To: <1211559657.3566.97.camel@cookie.hadess.net> References: <4836DA23.3090709@hhs.nl> <20080523152426.GB3224@nostromo.devel.redhat.com> <1211559657.3566.97.camel@cookie.hadess.net> Message-ID: <48372673.5020703@hhs.nl> Bastien Nocera wrote: > On Fri, 2008-05-23 at 11:24 -0400, Bill Nottingham wrote: >> Hans de Goede (j.w.r.degoede at hhs.nl) said: >>> See: >>> >>> http://fedoraproject.org/wiki/Features/BetterWebcamSupport >> Any reason a shim library is simpler than porting apps to V4L2? > > Same question here. There's a good number of applications that are > either obsoleted by a v4l2 version, or support both versions. Which > applications were you thinking of supporting with this scheme? > > Unless there's tens of open source apps that would need changing, or a > couple of (useful) proprietary ones that don't support v4l2, the library > is probably not very useful to have (especially as you probably wouldn't > be able to port _all_ the v4l1 drivers to v4l2). > See my reaction to Bill's question, and yes there are a few usefull proprietary apps in the mix unfortunately. > You might also want to see what can be done to remove GStreamer's V4L2 > plugin's experimental status: > http://tinyurl.com/4ft7ej > That definitely the plan as I want cheese to be working 100% out of the box. Regards, Hans From jspaleta at gmail.com Fri May 23 20:20:28 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 23 May 2008 12:20:28 -0800 Subject: Neon Sign In-Reply-To: References: <20080522065724.1788e577@vader.jdub.homelinux.org> <604aa7910805231201w5be70406k95ea980f2a0d72be@mail.gmail.com> <604aa7910805231235j44b13ea0k2fdf5740acadef9b@mail.gmail.com> <1211573176.31834.3.camel@victoria> <483724B6.4070509@redhat.com> Message-ID: <604aa7910805231320s6681ba7dy7a57036c606e0110@mail.gmail.com> On Fri, May 23, 2008 at 12:16 PM, Harald Hoyer wrote: > too obvious :) replaced the old one with the free version and renamed it to > .ogg :) > > http://harald.fedorapeople.org/always-open/Fedora-animated.ogg Now! do it all again..starting with a blank gimp application but this time record the process with instanbul and create a screencast so we can include it as one of our first videos for a Fedora content channel meant for miro. Think of it as an initiation or hazing ritual required of all incoming Board members. -jef From stickster at gmail.com Fri May 23 20:22:42 2008 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 23 May 2008 20:22:42 +0000 Subject: Neon Sign In-Reply-To: <604aa7910805231320s6681ba7dy7a57036c606e0110@mail.gmail.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <604aa7910805231201w5be70406k95ea980f2a0d72be@mail.gmail.com> <604aa7910805231235j44b13ea0k2fdf5740acadef9b@mail.gmail.com> <1211573176.31834.3.camel@victoria> <483724B6.4070509@redhat.com> <604aa7910805231320s6681ba7dy7a57036c606e0110@mail.gmail.com> Message-ID: <1211574162.31834.5.camel@victoria> On Fri, 2008-05-23 at 12:20 -0800, Jeff Spaleta wrote: > On Fri, May 23, 2008 at 12:16 PM, Harald Hoyer wrote: > > too obvious :) replaced the old one with the free version and renamed it to > > .ogg :) > > > > http://harald.fedorapeople.org/always-open/Fedora-animated.ogg > > > Now! do it all again..starting with a blank gimp application but this > time record the process with instanbul and create a screencast so we > can include it as one of our first videos for a Fedora content channel > meant for miro. > > Think of it as an initiation or hazing ritual required of all incoming > Board members. Or at the very least, what you get for putting your waffles (cakes?) somewhere Jef can see them. ;-) -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From greno at verizon.net Fri May 23 20:24:01 2008 From: greno at verizon.net (Gerry Reno) Date: Fri, 23 May 2008 16:24:01 -0400 Subject: sata and changing devices In-Reply-To: <20080523200048.GC13150@devserv.devel.redhat.com> References: <483701CC.5010002@verizon.net> <20080523200048.GC13150@devserv.devel.redhat.com> Message-ID: <483727E1.80803@verizon.net> Alan Cox wrote: > On Fri, May 23, 2008 at 01:41:32PM -0400, Gerry Reno wrote: > >> So I need to find out if there is some best practice guide for how to >> rewrite our tools so that they can support SATA. We use LVM over RAID >> on all our drives and all our RAID and LVM tools appear to still work. >> It is only when dealing with the low-level disk devices themselves that >> we have problems. Can someone give me some suggestions as to how to >> manage things when using SATA? >> > > You want to look at the volume itself. SATA is hotplug so talking about > devices by their bus location is a bit meaningless. > > You've got two useful identifiers > > 1. The serial number of the drive available directly either by using > SG_IO to issue an IDENTIFY or the boot one (which is fine) via ioctls too. > Or you can script parsing hdparm of course. > > 2. Labels on the file systems which is what RAID/LVM/etc all use. > > For low level work where you want to know "this physical disk is the one > I saw last week" the disk vendor|model|serial combination should be unique > for any modern real world drive. > > The serial number might be ok until you replace the disk. Just have to remember to rerun the tools for the replacement and to note the replacement lineage. In scripts I think I could parse smartctl output for serial numbers or is there something better under /proc I can parse? -------------- next part -------------- An HTML attachment was scrubbed... URL: From harald at redhat.com Fri May 23 20:24:34 2008 From: harald at redhat.com (Harald Hoyer) Date: Fri, 23 May 2008 22:24:34 +0200 Subject: Neon Sign In-Reply-To: <604aa7910805231320s6681ba7dy7a57036c606e0110@mail.gmail.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <604aa7910805231201w5be70406k95ea980f2a0d72be@mail.gmail.com> <604aa7910805231235j44b13ea0k2fdf5740acadef9b@mail.gmail.com> <1211573176.31834.3.camel@victoria> <483724B6.4070509@redhat.com> <604aa7910805231320s6681ba7dy7a57036c606e0110@mail.gmail.com> Message-ID: Jeff Spaleta wrote: > On Fri, May 23, 2008 at 12:16 PM, Harald Hoyer wrote: >> too obvious :) replaced the old one with the free version and renamed it to >> .ogg :) >> >> http://harald.fedorapeople.org/always-open/Fedora-animated.ogg > > > Now! do it all again..starting with a blank gimp application but this > time record the process with instanbul and create a screencast so we > can include it as one of our first videos for a Fedora content channel > meant for miro. > > Think of it as an initiation or hazing ritual required of all incoming > Board members. > > -jef > *rofl* :) btw, it all started with a blank inkscape :) From jspaleta at gmail.com Fri May 23 20:27:06 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 23 May 2008 12:27:06 -0800 Subject: Neon Sign In-Reply-To: <1211574162.31834.5.camel@victoria> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <604aa7910805231201w5be70406k95ea980f2a0d72be@mail.gmail.com> <604aa7910805231235j44b13ea0k2fdf5740acadef9b@mail.gmail.com> <1211573176.31834.3.camel@victoria> <483724B6.4070509@redhat.com> <604aa7910805231320s6681ba7dy7a57036c606e0110@mail.gmail.com> <1211574162.31834.5.camel@victoria> Message-ID: <604aa7910805231327w3dae10c9n515633268d8b611@mail.gmail.com> 2008/5/23 Paul W. Frields : > Or at the very least, what you get for putting your waffles (cakes?) > somewhere Jef can see them. ;-) You're already doing it... sucker. I need to get seth to do one. I'm sure a seth voice over would be fun to listen to. -jef From sundaram at fedoraproject.org Fri May 23 20:29:05 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 24 May 2008 01:59:05 +0530 Subject: libflashsupport Message-ID: <48372911.9010502@fedoraproject.org> Hi, It seems libflashsupport was dropped out of the default package list in Fedora 9 and I didn't see any public discussion on the reasons behind this change (release notes didn't get updated either until recently unfortunately) Can someone familiar with this change explain the reason? Rahul From jspaleta at gmail.com Fri May 23 20:32:42 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 23 May 2008 12:32:42 -0800 Subject: Neon Sign In-Reply-To: References: <20080522065724.1788e577@vader.jdub.homelinux.org> <604aa7910805231201w5be70406k95ea980f2a0d72be@mail.gmail.com> <604aa7910805231235j44b13ea0k2fdf5740acadef9b@mail.gmail.com> <1211573176.31834.3.camel@victoria> <483724B6.4070509@redhat.com> <604aa7910805231320s6681ba7dy7a57036c606e0110@mail.gmail.com> Message-ID: <604aa7910805231332n70e46a27j97e93fafb001c764@mail.gmail.com> On Fri, May 23, 2008 at 12:24 PM, Harald Hoyer wrote: > *rofl* :) > > btw, it all started with a blank inkscape :) We've been screwing around with trying to get some sort of content channel up so we can dog food our own multimedia stuff for what seems like forever. It's a real chicken and egg problem, but with miro for distribution and cheese, pitivi and istanbul for basic video creation and editting we have enough right now to start dogfooding things and generating a content channel. I don't care how crappy that initial content is. I fully expect Board members to be guinea pigs in terms of generating consumable content if we get a miro channel going, at least until people with more skill inside our community take the pludge. -jef From harald at redhat.com Fri May 23 20:34:08 2008 From: harald at redhat.com (Harald Hoyer) Date: Fri, 23 May 2008 22:34:08 +0200 Subject: Neon Sign In-Reply-To: <604aa7910805231320s6681ba7dy7a57036c606e0110@mail.gmail.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <604aa7910805231201w5be70406k95ea980f2a0d72be@mail.gmail.com> <604aa7910805231235j44b13ea0k2fdf5740acadef9b@mail.gmail.com> <1211573176.31834.3.camel@victoria> <483724B6.4070509@redhat.com> <604aa7910805231320s6681ba7dy7a57036c606e0110@mail.gmail.com> Message-ID: <48372A40.3040402@redhat.com> Jeff Spaleta wrote: > On Fri, May 23, 2008 at 12:16 PM, Harald Hoyer wrote: >> too obvious :) replaced the old one with the free version and renamed it to >> .ogg :) >> >> http://harald.fedorapeople.org/always-open/Fedora-animated.ogg > > > Now! do it all again..starting with a blank gimp application but this > time record the process with instanbul and create a screencast so we > can include it as one of our first videos for a Fedora content channel > meant for miro. > > Think of it as an initiation or hazing ritual required of all incoming > Board members. > > -jef > First you add some nifty sound to that video.. From alan at redhat.com Fri May 23 20:34:39 2008 From: alan at redhat.com (Alan Cox) Date: Fri, 23 May 2008 16:34:39 -0400 Subject: sata and changing devices In-Reply-To: <483727E1.80803@verizon.net> References: <483701CC.5010002@verizon.net> <20080523200048.GC13150@devserv.devel.redhat.com> <483727E1.80803@verizon.net> Message-ID: <20080523203439.GE13150@devserv.devel.redhat.com> On Fri, May 23, 2008 at 04:24:01PM -0400, Gerry Reno wrote: > The serial number might be ok until you replace the disk. Just have to > remember to rerun the tools for the replacement and to note the > replacement lineage. In scripts I think I could parse smartctl output > for serial numbers or is there something better under /proc I can parse? hdparm is probably better to parse than hdparm. Especially hdparm --Istdout From greno at verizon.net Fri May 23 20:45:09 2008 From: greno at verizon.net (Gerry Reno) Date: Fri, 23 May 2008 16:45:09 -0400 Subject: sata and changing devices In-Reply-To: <20080523203439.GE13150@devserv.devel.redhat.com> References: <483701CC.5010002@verizon.net> <20080523200048.GC13150@devserv.devel.redhat.com> <483727E1.80803@verizon.net> <20080523203439.GE13150@devserv.devel.redhat.com> Message-ID: <48372CD5.7010801@verizon.net> Alan Cox wrote: > On Fri, May 23, 2008 at 04:24:01PM -0400, Gerry Reno wrote: > >> The serial number might be ok until you replace the disk. Just have to >> remember to rerun the tools for the replacement and to note the >> replacement lineage. In scripts I think I could parse smartctl output >> for serial numbers or is there something better under /proc I can parse? >> > > hdparm is probably better to parse than hdparm. Especially > > hdparm --Istdout > > Ok, I was trying to steer clear of hdparm if I could because I got bit a couple times with that command. But in this instance in a script it should be ok. -------------- next part -------------- An HTML attachment was scrubbed... URL: From notting at redhat.com Fri May 23 20:51:14 2008 From: notting at redhat.com (Bill Nottingham) Date: Fri, 23 May 2008 16:51:14 -0400 Subject: libflashsupport In-Reply-To: <48372911.9010502@fedoraproject.org> References: <48372911.9010502@fedoraproject.org> Message-ID: <20080523205114.GB29875@nostromo.devel.redhat.com> Rahul Sundaram (sundaram at fedoraproject.org) said: > It seems libflashsupport was dropped out of the default package list in > Fedora 9 and I didn't see any public discussion on the reasons behind this > change (release notes didn't get updated either until recently > unfortunately) Can someone familiar with this change explain the reason? Check the FESCo logs... general reasoning is that it existed solely as a crutch for third-party software, IIRC. Bill From stickster at gmail.com Fri May 23 20:32:59 2008 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 23 May 2008 16:32:59 -0400 Subject: Neon Sign In-Reply-To: <604aa7910805231327w3dae10c9n515633268d8b611@mail.gmail.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <604aa7910805231201w5be70406k95ea980f2a0d72be@mail.gmail.com> <604aa7910805231235j44b13ea0k2fdf5740acadef9b@mail.gmail.com> <1211573176.31834.3.camel@victoria> <483724B6.4070509@redhat.com> <604aa7910805231320s6681ba7dy7a57036c606e0110@mail.gmail.com> <1211574162.31834.5.camel@victoria> <604aa7910805231327w3dae10c9n515633268d8b611@mail.gmail.com> Message-ID: <1211574779.31834.7.camel@victoria> On Fri, 2008-05-23 at 12:27 -0800, Jeff Spaleta wrote: > 2008/5/23 Paul W. Frields : > > Or at the very least, what you get for putting your waffles (cakes?) > > somewhere Jef can see them. ;-) > > You're already doing it... sucker. I need to get seth to do one. I'm > sure a seth voice over would be fun to listen to. /me ponies up for that ticket. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From aoliva at redhat.com Fri May 23 21:10:00 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Fri, 23 May 2008 18:10:00 -0300 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080522065724.1788e577@vader.jdub.homelinux.org> (Josh Boyer's message of "Thu\, 22 May 2008 06\:57\:24 -0500") References: <20080522065724.1788e577@vader.jdub.homelinux.org> Message-ID: On May 22, 2008, Josh Boyer wrote: > I will be collecting suggestions for 1 week, so the cutoff for names is: Sulphur is an ingredient in fertilizers. Shit! :-) :-P :-D -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From dcbw at redhat.com Fri May 23 21:15:21 2008 From: dcbw at redhat.com (Dan Williams) Date: Fri, 23 May 2008 17:15:21 -0400 Subject: WPA2 support ase-ccm/tkip In-Reply-To: References: Message-ID: <1211577321.23622.2.camel@localhost.localdomain> On Fri, 2008-05-23 at 13:43 -0600, John.Mizell at tch.com wrote: > Does WPA2/WPA support aes-ccm/tkip in fedora currently? I do not see it as > an option in network manager. If not is being worked on? It's supported, just choose WPA/WPA2. NM/wpa_supplicant will choose the right option for your wireless network based on the capabilities that the AP advertises in its beacon frames. One corner case where this might _not_ work is older drivers that do not have the ability to probe-scan specific SSIDs (airo, atmel, orinoco are a few), and therefore need the supplicant's ap_scan=2 option, which requires the user to configure the connection for _exactly_ the settings the AP supports. If that's you, I'd like to hear what driver and wireless hardware you're using. Dan From vpivaini at cs.helsinki.fi Fri May 23 21:17:23 2008 From: vpivaini at cs.helsinki.fi (Ville-Pekka Vainio) Date: Sat, 24 May 2008 00:17:23 +0300 Subject: Packaging Firefox extensions (Finnish spell checking) Message-ID: <200805240017.23616.vpivaini@cs.helsinki.fi> Hi all, I've been packaging Finnish spell checking support for Fedora (see http://voikko.sourceforge.net/) and now I've packaged a Firefox extension which uses the Voikko library to do spell checking in Finnish. My initial testing package can be found here: http://vpv.fedorapeople.org/packages/mozvoikko/ What do you think about packaging Firefox extensions, are they allowed and would someone be interested in reviewing this package if I submitted it? Beagle-firefox is probably the only Firefox extension packaged currently in Fedora and I made my package so that it matches the locations etc. used in that package. Of course the extensions can be installed from Mozilla's web site as well, but especially with this extension there would be a couple of benefits if it was shipped as an RPM: It can be built against the libvoikko and libmalaga libraries available in Fedora and it uses the Finnish data files available in Fedora (malaga-suomi-voikko). The extension version which probably will be shipped from Mozilla's web site needs to have the libraries and the data files compiled in it, because it can't assume much from the target system. Thus it will probably be much larger (the uncompressed data files seem to be around 8 megabytes) whereas the extension built to call the stuff already in the system takes around 70 kilobytes (uncompressed). Also, if the extension is installed via Firefox from Mozilla's site, it will only be installed for the single user, so if the system has for example 5 users and all of them install the extension for themselves, the difference will be even bigger. -- Ville-Pekka Vainio From walters at verbum.org Fri May 23 21:36:09 2008 From: walters at verbum.org (Colin Walters) Date: Fri, 23 May 2008 17:36:09 -0400 Subject: Packaging Firefox extensions (Finnish spell checking) In-Reply-To: <200805240017.23616.vpivaini@cs.helsinki.fi> References: <200805240017.23616.vpivaini@cs.helsinki.fi> Message-ID: On Fri, May 23, 2008 at 5:17 PM, Ville-Pekka Vainio wrote: > Hi all, > > I've been packaging Finnish spell checking support for Fedora (see > http://voikko.sourceforge.net/) and now I've packaged a Firefox extension > which uses the Voikko library to do spell checking in Finnish. My initial > testing package can be found here: > http://vpv.fedorapeople.org/packages/mozvoikko/ > > What do you think about packaging Firefox extensions, are they allowed and > would someone be interested in reviewing this package if I submitted it? It's fine, see also the mugshot package for use of the system-installed extensions standard. I haven't looked at the Beagle extension but hopefully it's doing the right thing. The main thing lacking is integration of the addon dialog and PackageKit. From gene at czarc.net Fri May 23 21:36:39 2008 From: gene at czarc.net (Gene Czarcinski) Date: Fri, 23 May 2008 17:36:39 -0400 Subject: gkrellm themes In-Reply-To: <1211308146.3801.286.camel@localhost.localdomain> References: <200805201341.13276.gene@czarc.net> <1211308146.3801.286.camel@localhost.localdomain> Message-ID: <200805231736.39470.gene@czarc.net> On Tuesday 20 May 2008 14:29:06 Tom "spot" Callaway wrote: > We have a list of acceptable licenses here: > > http://fedoraproject.org/wiki/Licensing OK, I took a look at the list ... wow that is a long list! I guess a lot of folks like spending time crafting unique licenses. I assume all licenses in the "good" list are OK and all in the "bad" list are not. Do you have a suggestion as to a "preferred" license for this kind of stuff ... graphics and configuration files mostly. I would really like to get most folks to all use the same license (see below). Also, do you have any suggestions on how to handle cases where multiple individuals have had their hand in things: A creates a theme. B then modifies A's theme to create a new theme. C comes along and modifies B's theme plus add some stuff from a theme created by D to create yet another theme. That may sound convoluted but it appears to be the case for some of these themes. I also assume that any theme citing Carsten Haitzler's (Rasterman's) enlightenment window manager as a source is OK (I do not need that author's blessing too). I am not sure what will be needed in the SPEC file with respect to licensing (since you are reviewing spec files). I sure do not want to see a bunch of theme packages ... one for every license type. That is too much over-achieving. Gene From jkeating at redhat.com Fri May 23 22:01:35 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 23 May 2008 18:01:35 -0400 Subject: No rawhide creation this weekend Message-ID: <1211580095.5079.159.camel@localhost.localdomain> Due to the outage ( https://www.redhat.com/archives/fedora-devel-announce/2008-May/msg00012.html ) no rawhide will be created this weekend. Cheers! -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From kevin at scrye.com Fri May 23 22:29:55 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Fri, 23 May 2008 16:29:55 -0600 Subject: Xfce SIG meeting! Message-ID: <20080523162955.7677c1a3@ohm.scrye.com> Greetings. We would like to try and get together interested folks for the first Xfce SIG meeting, sometime next week on irc.freenode.net in the #fedora-meeting channel. Please see: http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel for when available times are for the #fedora-meeting channel. If interested parties could mail me their preferred times for meeting, I can schedule a meeting time for next week. Note that I will be out on vacation next week, but should have net and be able to meet anyhow. Possible topics for the meeting: - Going over the list of outstanding Xfce bugs - Talking about plans for F10 cycle - Further integration efforts for themes/icons - Xfce spin changes/wishlists Thanks! kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From greno at verizon.net Fri May 23 22:30:37 2008 From: greno at verizon.net (Gerry Reno) Date: Fri, 23 May 2008 18:30:37 -0400 Subject: sata and changing devices In-Reply-To: <48372CD5.7010801@verizon.net> References: <483701CC.5010002@verizon.net> <20080523200048.GC13150@devserv.devel.redhat.com> <483727E1.80803@verizon.net> <20080523203439.GE13150@devserv.devel.redhat.com> <48372CD5.7010801@verizon.net> Message-ID: <4837458D.9080105@verizon.net> Just following up on this theme with respect to GRUB. When Anaconda installed GRUB it put entries into /boot/grub/device.map. But in grub> when I do a 'find /boot/grub/stage1' the list of devices containing the boot files is altogether different from what is in device.map. So my question is this: On systems with SATA, is device.map no longer used? Since it seems under GRUB that the devices where GRUB finds the boot files keep changing between boots is device.map even usable? From fedora at matbooth.co.uk Fri May 23 22:42:16 2008 From: fedora at matbooth.co.uk (Mat Booth) Date: Fri, 23 May 2008 23:42:16 +0100 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1211543403.23635.3.camel@victoria> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <20080522170718.GE8819@nostromo.devel.redhat.com> <1211543403.23635.3.camel@victoria> Message-ID: <9497e9990805231542n5ff05e9as68591fbf28a4709c@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 2008/5/23 Paul W. Frields : > On Thu, 2008-05-22 at 13:07 -0400, Bill Nottingham wrote: >> Josh Boyer (jwboyer at gmail.com) said: >> > I will be collecting suggestions for 1 week, so the cutoff for names is: >> > >> > May 29, 2008 >> >> OK, so things Sulphur is: > > - A kind of butterfly. > > Monarch? > Cabbage. :-) - -- Mat Booth www.matbooth.co.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: http://getfiregpg.org iEYEARECAAYFAkg3SIkACgkQKfdzh3zDrvB3VwCfWIWRsbLdrmeV7YHoobHCqPOz RSQAoLaYsZWcuQEfGxy1ru/DhFMvtyt/ =Zxfo -----END PGP SIGNATURE----- From hun at n-dimensional.de Fri May 23 23:00:26 2008 From: hun at n-dimensional.de (Hans Ulrich Niedermann) Date: Sat, 24 May 2008 01:00:26 +0200 Subject: "10" < "9": Get rid of string comparisons in time for F-10? Message-ID: <48374C8A.5070606@n-dimensional.de> On #fedora-devel, the issue of comparing Fedora versions by string comparison just came up. With F-10 on the way, this will be the first time when string comparing versions will fail in a "10" < "7" way. The case in question was a classic older %if "%{?fedora}" > "7", which should be changed to %if 0%{?fedora} > 7, as Rex Dieter and Christopher Stone have pointed out: http://fedoraproject.org/wiki/Packaging/DistTag#head-1c550109af0705ccb71329619b99428af2fd3e25 Where else but in spec files may similarly wrong string comparisons be happening? Is a systematic effort required to fix these comparisons in the run-up to F-10? -- Hans Ulrich Niedermann -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From s0238762 at sms.ed.ac.uk Fri May 23 23:12:38 2008 From: s0238762 at sms.ed.ac.uk (Ioannis Nousias) Date: Sat, 24 May 2008 00:12:38 +0100 Subject: freenx-server.x86_64 missing dependency In-Reply-To: <69e11d1f0805230920q59ca9924h2a93f1123a1831bf@mail.gmail.com> References: <4836E556.1060700@sms.ed.ac.uk> <69e11d1f0805230920q59ca9924h2a93f1123a1831bf@mail.gmail.com> Message-ID: <48374F66.4080505@sms.ed.ac.uk> thanks for the pointer regards, Ioannis Gustavo Alves wrote: > Hi, > > There is a bug registered about it > > https://bugzilla.redhat.com/show_bug.cgi?id=447998 > > Regards, > > Gustavo > > On Fri, May 23, 2008 at 12:40 PM, Ioannis Nousias > > wrote: > > Hello, > > I'm having a problem with freenx in F9. > > the freenx package has been replaced with freenx-server one that > requires /usr/lib64/nx, which doesn't exist in the repos. There is > nx.i386, but no nx.x86_64 > > is this a know issue ? > > > regards, > Ioannis > > > PS: using freenx.x86_64 doesn't work either (no dependency > problems, but I don't get a working server) > > > -- > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > -- > Gustavo Junior Alves > GJAlves Tecnologia > Tel: +55 19 9223-0500 -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From denis at poolshark.org Fri May 23 23:25:21 2008 From: denis at poolshark.org (Denis Leroy) Date: Fri, 23 May 2008 16:25:21 -0700 Subject: sata and changing devices In-Reply-To: <483727E1.80803@verizon.net> References: <483701CC.5010002@verizon.net> <20080523200048.GC13150@devserv.devel.redhat.com> <483727E1.80803@verizon.net> Message-ID: <48375261.2020007@poolshark.org> Gerry Reno wrote: > The serial number might be ok until you replace the disk. Just have to > remember to rerun the tools for the replacement and to note the > replacement lineage. In scripts I think I could parse smartctl output > for serial numbers or is there something better under /proc I can parse? sg_inq /dev/sda From bnocera at redhat.com Fri May 23 23:34:33 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Sat, 24 May 2008 00:34:33 +0100 Subject: libflashsupport In-Reply-To: <20080523205114.GB29875@nostromo.devel.redhat.com> References: <48372911.9010502@fedoraproject.org> <20080523205114.GB29875@nostromo.devel.redhat.com> Message-ID: <1211585673.3566.120.camel@cookie.hadess.net> On Fri, 2008-05-23 at 16:51 -0400, Bill Nottingham wrote: > Rahul Sundaram (sundaram at fedoraproject.org) said: > > It seems libflashsupport was dropped out of the default package list in > > Fedora 9 and I didn't see any public discussion on the reasons behind this > > change (release notes didn't get updated either until recently > > unfortunately) Can someone familiar with this change explain the reason? > > Check the FESCo logs... general reasoning is that it existed solely > as a crutch for third-party software, IIRC. And I'm sure the people who came up with that idea made sure to nicely ask Adobe to make their Flash plugins depend on it. Or explained to them what that tool did so they can fix their software. From bnocera at redhat.com Fri May 23 23:38:05 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Sat, 24 May 2008 00:38:05 +0100 Subject: Announcing a new F-10 Feature Proposal: Better Webcam Support In-Reply-To: <48372673.5020703@hhs.nl> References: <4836DA23.3090709@hhs.nl> <20080523152426.GB3224@nostromo.devel.redhat.com> <1211559657.3566.97.camel@cookie.hadess.net> <48372673.5020703@hhs.nl> Message-ID: <1211585885.3566.124.camel@cookie.hadess.net> On Fri, 2008-05-23 at 22:17 +0200, Hans de Goede wrote: > Bastien Nocera wrote: > > On Fri, 2008-05-23 at 11:24 -0400, Bill Nottingham wrote: > >> Hans de Goede (j.w.r.degoede at hhs.nl) said: > >>> See: > >>> > >>> http://fedoraproject.org/wiki/Features/BetterWebcamSupport > >> Any reason a shim library is simpler than porting apps to V4L2? > > > > Same question here. There's a good number of applications that are > > either obsoleted by a v4l2 version, or support both versions. Which > > applications were you thinking of supporting with this scheme? > > > > Unless there's tens of open source apps that would need changing, or a > > couple of (useful) proprietary ones that don't support v4l2, the library > > is probably not very useful to have (especially as you probably wouldn't > > be able to port _all_ the v4l1 drivers to v4l2). > > > > See my reaction to Bill's question, and yes there are a few usefull proprietary > apps in the mix unfortunately. Do you have a list of those apps? Both the proprietary ones and the Open Source ones. For the latter, it could be more interesting to create a guide for the conversion from V4L1 to V4L2, and see whether Fedora maintainers of those projects can help out with the conversion, or at least submit it upstream for consideration. > > You might also want to see what can be done to remove GStreamer's V4L2 > > plugin's experimental status: > > http://tinyurl.com/4ft7ej > > > > That definitely the plan as I want cheese to be working 100% out of the box. Great stuff. From mzerqung at 0pointer.de Fri May 23 23:54:51 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Sat, 24 May 2008 01:54:51 +0200 Subject: libflashsupport In-Reply-To: <1211585673.3566.120.camel@cookie.hadess.net> References: <48372911.9010502@fedoraproject.org> <20080523205114.GB29875@nostromo.devel.redhat.com> <1211585673.3566.120.camel@cookie.hadess.net> Message-ID: <20080523235451.GA8466@tango.0pointer.de> On Sat, 24.05.08 00:34, Bastien Nocera (bnocera at redhat.com) wrote: > > On Fri, 2008-05-23 at 16:51 -0400, Bill Nottingham wrote: > > Rahul Sundaram (sundaram at fedoraproject.org) said: > > > It seems libflashsupport was dropped out of the default package list in > > > Fedora 9 and I didn't see any public discussion on the reasons behind this > > > change (release notes didn't get updated either until recently > > > unfortunately) Can someone familiar with this change explain the reason? > > > > Check the FESCo logs... general reasoning is that it existed solely > > as a crutch for third-party software, IIRC. > > And I'm sure the people who came up with that idea made sure to nicely > ask Adobe to make their Flash plugins depend on it. Or explained to them > what that tool did so they can fix their software. Adobe Flash 10 doesn't need libflashsupport anymore to work fine on ALSA ioplug-based backends such as pulse. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From ivazqueznet at gmail.com Sat May 24 00:11:36 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Fri, 23 May 2008 20:11:36 -0400 Subject: libflashsupport In-Reply-To: <20080523235451.GA8466@tango.0pointer.de> References: <48372911.9010502@fedoraproject.org> <20080523205114.GB29875@nostromo.devel.redhat.com> <1211585673.3566.120.camel@cookie.hadess.net> <20080523235451.GA8466@tango.0pointer.de> Message-ID: <1211587896.3444.28.camel@ignacio.lan> On Sat, 2008-05-24 at 01:54 +0200, Lennart Poettering wrote: > Adobe Flash 10 doesn't need libflashsupport anymore to work fine on > ALSA ioplug-based backends such as pulse. Presumably it's still needed for SSL and V4L though. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dr.diesel at gmail.com Sat May 24 00:13:12 2008 From: dr.diesel at gmail.com (Dr. Diesel) Date: Fri, 23 May 2008 20:13:12 -0400 Subject: libflashsupport In-Reply-To: <1211587896.3444.28.camel@ignacio.lan> References: <48372911.9010502@fedoraproject.org> <20080523205114.GB29875@nostromo.devel.redhat.com> <1211585673.3566.120.camel@cookie.hadess.net> <20080523235451.GA8466@tango.0pointer.de> <1211587896.3444.28.camel@ignacio.lan> Message-ID: <2a28d2ab0805231713q1c68e81em18032439db0662b9@mail.gmail.com> Where do you get Flash 10 for linux? 2008/5/23 Ignacio Vazquez-Abrams : > On Sat, 2008-05-24 at 01:54 +0200, Lennart Poettering wrote: >> Adobe Flash 10 doesn't need libflashsupport anymore to work fine on >> ALSA ioplug-based backends such as pulse. > > Presumably it's still needed for SSL and V4L though. > > -- > Ignacio Vazquez-Abrams > > PLEASE don't CC me; I'm already subscribed > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org From ivazqueznet at gmail.com Sat May 24 00:18:08 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Fri, 23 May 2008 20:18:08 -0400 Subject: libflashsupport In-Reply-To: <2a28d2ab0805231713q1c68e81em18032439db0662b9@mail.gmail.com> References: <48372911.9010502@fedoraproject.org> <20080523205114.GB29875@nostromo.devel.redhat.com> <1211585673.3566.120.camel@cookie.hadess.net> <20080523235451.GA8466@tango.0pointer.de> <1211587896.3444.28.camel@ignacio.lan> <2a28d2ab0805231713q1c68e81em18032439db0662b9@mail.gmail.com> Message-ID: <1211588288.3444.30.camel@ignacio.lan> On Fri, 2008-05-23 at 20:13 -0400, Dr. Diesel wrote: > Where do you get Flash 10 for linux? http://labs.adobe.com/technologies/flashplayer10/ -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mzerqung at 0pointer.de Sat May 24 00:24:30 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Sat, 24 May 2008 02:24:30 +0200 Subject: libflashsupport In-Reply-To: <1211587896.3444.28.camel@ignacio.lan> References: <48372911.9010502@fedoraproject.org> <20080523205114.GB29875@nostromo.devel.redhat.com> <1211585673.3566.120.camel@cookie.hadess.net> <20080523235451.GA8466@tango.0pointer.de> <1211587896.3444.28.camel@ignacio.lan> Message-ID: <20080524002430.GA9566@tango.0pointer.de> On Fri, 23.05.08 20:11, Ignacio Vazquez-Abrams (ivazqueznet at gmail.com) wrote: > On Sat, 2008-05-24 at 01:54 +0200, Lennart Poettering wrote: > > Adobe Flash 10 doesn't need libflashsupport anymore to work fine on > > ALSA ioplug-based backends such as pulse. > > Presumably it's still needed for SSL and V4L though. Flash comes internally with support for SSL, V4L and ALSA. The only reason I hacked up libflashsupport is to add PulseAudio support. I never touched the SSL/V4L part of libflashsupport however. And for Flash 10 we don't need specific Pulse support anymore, since they fixed the way they are using the ALSA API. And hence we don't need libflashsupport at all anymore, and let Flash use SSL, V4L and ALSA directly again. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From bnocera at redhat.com Sat May 24 00:27:58 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Sat, 24 May 2008 01:27:58 +0100 Subject: Tempelhof (was Re: Werewolf -> Sulphur -> ? Sulphur is a , is a ) In-Reply-To: <20080522065724.1788e577@vader.jdub.homelinux.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> Message-ID: <1211588878.3566.136.camel@cookie.hadess.net> On Thu, 2008-05-22 at 06:57 -0500, Josh Boyer wrote: > Let the naming begin! We're starting very early this time around in > the name game for F10. So, let the suggestions flow! > > Remember the rules: > > 1) must have some link to Sulphur > > More specifically, the link should be > Sulphur is a and > is a > Where is the same for both > > 2) The link between and Sulphur cannot be the same as between > Werewolf and Sulphur. That link was "things that react badly with > silver". The answer is: Tempelhof Sulphur is a 16-minute short film[1]. Tempelhof[2] is a 16-minute short film[3]. [1]: http://www.imdb.com/title/tt0358178/ [2]: http://en.wikipedia.org/wiki/Tempelhof and http://en.wikipedia.org/wiki/Tempelhof_International_Airport [3]: http://www.pushpushtheater.com/international/portalfilmfest.html Some pretty good connections after that (I'm sure the airport could send Spinal Tap to the London Tube), and Nicu can use his gears from the planes. From bnocera at redhat.com Sat May 24 00:29:16 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Sat, 24 May 2008 01:29:16 +0100 Subject: libflashsupport In-Reply-To: <20080523235451.GA8466@tango.0pointer.de> References: <48372911.9010502@fedoraproject.org> <20080523205114.GB29875@nostromo.devel.redhat.com> <1211585673.3566.120.camel@cookie.hadess.net> <20080523235451.GA8466@tango.0pointer.de> Message-ID: <1211588956.3566.137.camel@cookie.hadess.net> On Sat, 2008-05-24 at 01:54 +0200, Lennart Poettering wrote: > On Sat, 24.05.08 00:34, Bastien Nocera (bnocera at redhat.com) wrote: > > > > > On Fri, 2008-05-23 at 16:51 -0400, Bill Nottingham wrote: > > > Rahul Sundaram (sundaram at fedoraproject.org) said: > > > > It seems libflashsupport was dropped out of the default package list in > > > > Fedora 9 and I didn't see any public discussion on the reasons behind this > > > > change (release notes didn't get updated either until recently > > > > unfortunately) Can someone familiar with this change explain the reason? > > > > > > Check the FESCo logs... general reasoning is that it existed solely > > > as a crutch for third-party software, IIRC. > > > > And I'm sure the people who came up with that idea made sure to nicely > > ask Adobe to make their Flash plugins depend on it. Or explained to them > > what that tool did so they can fix their software. > > Adobe Flash 10 doesn't need libflashsupport anymore to work fine on > ALSA ioplug-based backends such as pulse. Good stuff then. Thanks. From greno at verizon.net Sat May 24 00:39:02 2008 From: greno at verizon.net (Gerry Reno) Date: Fri, 23 May 2008 20:39:02 -0400 Subject: sata and changing devices In-Reply-To: <48375261.2020007@poolshark.org> References: <483701CC.5010002@verizon.net> <20080523200048.GC13150@devserv.devel.redhat.com> <483727E1.80803@verizon.net> <48375261.2020007@poolshark.org> Message-ID: <483763A6.3090809@verizon.net> Denis Leroy wrote: > Gerry Reno wrote: >> The serial number might be ok until you replace the disk. Just have >> to remember to rerun the tools for the replacement and to note the >> replacement lineage. In scripts I think I could parse smartctl >> output for serial numbers or is there something better under /proc I >> can parse? > > sg_inq /dev/sda > Thanks. Here is the output I get from sg_inq: # sg_inq /dev/sda standard INQUIRY: PQual=0 Device_type=0 RMB=0 version=0x05 [SPC-3] [AERC=0] [TrmTsk=0] NormACA=0 HiSUP=0 Resp_data_format=2 SCCS=0 ACC=0 TPGS=0 3PC=0 Protect=0 BQue=0 EncServ=0 MultiP=0 [MChngr=0] [ACKREQQ=0] Addr16=0 [RelAdr=0] WBus16=0 Sync=0 Linked=0 [TranDis=0] CmdQue=0 [SPI: Clocking=0x0 QAS=0 IUS=0] length=96 (0x60) Peripheral device type: disk Vendor identification: ATA Product identification: Hitachi HDP72502 Product revision level: GM2O Unit serial number: GEK231RB045L2A How new is this? Not sure the Vendor ID looks exactly right though. From mzerqung at 0pointer.de Sat May 24 00:42:36 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Sat, 24 May 2008 02:42:36 +0200 Subject: Tempelhof (was Re: Werewolf -> Sulphur -> ? Sulphur is a , is a ) In-Reply-To: <1211588878.3566.136.camel@cookie.hadess.net> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211588878.3566.136.camel@cookie.hadess.net> Message-ID: <20080524004236.GA10030@tango.0pointer.de> On Sat, 24.05.08 01:27, Bastien Nocera (bnocera at redhat.com) wrote: > On Thu, 2008-05-22 at 06:57 -0500, Josh Boyer wrote: > > Let the naming begin! We're starting very early this time around in > > the name game for F10. So, let the suggestions flow! > > > > Remember the rules: > > > > 1) must have some link to Sulphur > > > > More specifically, the link should be > > Sulphur is a and > > is a > > Where is the same for both > > > > 2) The link between and Sulphur cannot be the same as between > > Werewolf and Sulphur. That link was "things that react badly with > > silver". > > The answer is: > Tempelhof If we take this "world domination" thing seriously we definitely should name a Fedora release after a Nazi airport. I am all for it, would be a great signal to the world! Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From bnocera at redhat.com Sat May 24 01:12:35 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Sat, 24 May 2008 02:12:35 +0100 Subject: Tempelhof (was Re: Werewolf -> Sulphur -> ? Sulphur is a , is a ) In-Reply-To: <20080524004236.GA10030@tango.0pointer.de> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211588878.3566.136.camel@cookie.hadess.net> <20080524004236.GA10030@tango.0pointer.de> Message-ID: <1211591555.3566.142.camel@cookie.hadess.net> On Sat, 2008-05-24 at 02:42 +0200, Lennart Poettering wrote: > On Sat, 24.05.08 01:27, Bastien Nocera (bnocera at redhat.com) wrote: > > > On Thu, 2008-05-22 at 06:57 -0500, Josh Boyer wrote: > > > Let the naming begin! We're starting very early this time around in > > > the name game for F10. So, let the suggestions flow! > > > > > > Remember the rules: > > > > > > 1) must have some link to Sulphur > > > > > > More specifically, the link should be > > > Sulphur is a and > > > is a > > > Where is the same for both > > > > > > 2) The link between and Sulphur cannot be the same as between > > > Werewolf and Sulphur. That link was "things that react badly with > > > silver". > > > > The answer is: > > Tempelhof > > If we take this "world domination" thing seriously we definitely > should name a Fedora release after a Nazi airport. I am all for it, > would be a great signal to the world! At the same time, it's just an airport that happened to have been built under the Nazi regime. I didn't see people worrying that much watching Herbie. But then against Walt Disney was alleged anti-semite... From aoliva at redhat.com Sat May 24 00:13:32 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Fri, 23 May 2008 21:13:32 -0300 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080522065724.1788e577@vader.jdub.homelinux.org> (Josh Boyer's message of "Thu\, 22 May 2008 06\:57\:24 -0500") References: <20080522065724.1788e577@vader.jdub.homelinux.org> Message-ID: On May 22, 2008, Josh Boyer wrote: > Let the naming begin! We're starting very early this time around in > the name game for F10. So, let the suggestions flow! Xenon, Neon and Carbide appear to name existing software products already, but Oil, Deuterium and sulphur are other kinds of lamps, more specifically, other materials used to build lamps, and I couldn't find any programs using these names. Pyrethrum, nicotine and sulphur are inseticides, they kills bugs! Charcoal, nitrate and sulphur are components of gunpowder. Fire and sulfur (brimstone) are major features of hell. Sulfur, Mercury and Salt are the Three Primes of alchemy. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From aoliva at redhat.com Fri May 23 23:27:30 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Fri, 23 May 2008 20:27:30 -0300 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: <48371AA1.5080500@gmail.com> (Les Mikesell's message of "Fri\, 23 May 2008 14\:27\:29 -0500") References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> <1211405127.21380.382.camel@pmac.infradead.org> <1211444657.21380.424.camel@pmac.infradead.org> <20080522183614.GB32314@redhat.com> <1211528761.21380.481.camel@pmac.infradead.org> <1211563622.28967.60.camel@pmac.infradead.org> <48371AA1.5080500@gmail.com> Message-ID: On May 23, 2008, Les Mikesell wrote: > Alexandre Oliva wrote: >> >> Any reason to not have moved it to the firmware/ dir, as I expected >> from looking at your patches? >> >> rm -rf firmware/ is so much simpler :-) > For your purpose, wouldn't you want to separate > source-available-firmware and documentation-available bit settings > from the parts that would be more difficult for you to modify freely? For my purpose, yes, removing firmware that is Free would be unnecessary. But if it can be packaged separately and there are advantages to it, why take the technically inferior course of action? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From zing at fastmail.fm Sat May 24 01:45:58 2008 From: zing at fastmail.fm (Zing) Date: Sat, 24 May 2008 01:45:58 +0000 (UTC) Subject: NetworkManager: I want to believe, but... [was Re: F9 potential service network bug?] References: <3da3b5b40805161502w62f372dseca0ab6310e44447@mail.gmail.com> <1210975852.6805.10.camel@localhost.localdomain> <3da3b5b40805161522i2300f1cdhb1fc7b074084873f@mail.gmail.com> <604aa7910805161527j6b193c6dj2af4248155d5cdaf@mail.gmail.com> <20080517112856.GA18698@jadzia.bu.edu> <1211069083.3070.392.camel@cookie.hadess.net> <20080522142554.GB8728@jadzia.bu.edu> <1211472267.5352.25.camel@localhost.localdomain> <1211509501.19171.7.camel@aglarond.local> Message-ID: On Thu, 22 May 2008 22:25:01 -0400, Jeremy Katz wrote: > On Thu, 2008-05-22 at 12:04 -0400, Dan Williams wrote: >> If you're using a single ethernet adapter, statically configured, >> without a desktop, and only running say httpd and samba, then no, you >> probably don't want to use NM. You certainly _could_ if you wanted to. > > No, we probably *do* want people using NetworkManager here because > maintaining two entirely orthogonal network stacks is somewhat insane > and makes the rest of the system harder to manage. IMO, the options that server admins want (or at least I want) is what dan essentially says: to run without a daemon "managing" my network interface... it's just pure bloatiness and feel goodiness from this perspective. I don't want _another_ thing to have to diagnose when things go red alert on a bare bones server. So, we have that ability now. I'm happy. It sounds like this will always be the case, and if so, great. From szj087 at gmail.com Sat May 24 02:08:04 2008 From: szj087 at gmail.com (=?GB2312?B?y+/X2r79?=) Date: Sat, 24 May 2008 10:08:04 +0800 Subject: The problems upgraded to fedora 9 Message-ID: To be frankly, Fedora 9 is great distribution, but there is nothing perfect in the world with no exception of Fedora :) sipx project can be compiled successfully on Fedora 8, my another program is compiled successfully on fedora 8 also But after I upgraded my pc to fedora 9, all the things changed. My program failed to compile on fedora 9 with the complaints of some functions like memset, strcpy not found. Sipx projects has the same problem, which can find strncpy, strcmp, and so on. The worst is that it always report the following errors [all-recursive] errors or [check-recursive] errors I was confused by these strange errors. Does fedora 9 change its include path and contents.of tools chains? Can anyone give me some hints? Thanks very much for your kindly help zongjun From walters at verbum.org Sat May 24 02:13:11 2008 From: walters at verbum.org (Colin Walters) Date: Fri, 23 May 2008 22:13:11 -0400 Subject: The problems upgraded to fedora 9 In-Reply-To: References: Message-ID: On Fri, May 23, 2008 at 10:08 PM, ??? wrote: > To be frankly, Fedora 9 is great distribution, but there is nothing > perfect in the world with no exception of Fedora :) > > sipx project can be compiled successfully on Fedora 8, my another > program is compiled successfully on fedora 8 also > > But after I upgraded my pc to fedora 9, all the things changed. http://gcc.gnu.org/gcc-4.3/porting_to.html (scroll to "Header dependency cleanup") From kevin at scrye.com Sat May 24 03:55:36 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Fri, 23 May 2008 21:55:36 -0600 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080522065724.1788e577@vader.jdub.homelinux.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> Message-ID: <20080523215536.57510891@ohm.scrye.com> Here's my list to add: sulphur is used to make paper papyrus larch hemp sulphur is something that appears in the star trek(tm) episode 'arena' gorn metron transporter enterprise phaser sulphur is something that comes from Sicily Archimedes Bellini Etna sulphur is something who's production and distribution were controlled in wartime (WW1, USA) gasoline meat bicycle bacon electricity sulphur is used in dyes indigo madder larkspur sulphur is the name of a mountain in banff national park fifi castle bonnet I guess some of those are a bit generic, but I could see possibility for some good ones in there. ;) kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From gnomeuser at gmail.com Sat May 24 04:34:09 2008 From: gnomeuser at gmail.com (David Nielsen) Date: Sat, 24 May 2008 06:34:09 +0200 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080523215536.57510891@ohm.scrye.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <20080523215536.57510891@ohm.scrye.com> Message-ID: <1dedbbfc0805232134o67f3bd79y3c28e21c82f2b59d@mail.gmail.com> 24. maj. 2008 05.55 skrev Kevin Fenzi : > hemp > Not that it is a bad thing, but this one could welcome a huge amount of bong hit jokes. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dev at nigelj.com Sat May 24 05:09:41 2008 From: dev at nigelj.com (Nigel Jones) Date: Sat, 24 May 2008 17:09:41 +1200 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080523215536.57510891@ohm.scrye.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <20080523215536.57510891@ohm.scrye.com> Message-ID: <4837A315.9070802@nigelj.com> Kevin Fenzi wrote: > Here's my list to add: > > sulphur is used to make paper > > papyrus > larch > hemp > > sulphur is something that appears in the star trek(tm) episode 'arena' > > gorn > metron > transporter > enterprise > phaser > > sulphur is something that comes from Sicily > > Archimedes > Bellini > Etna > > sulphur is something who's production and distribution were controlled > in wartime (WW1, USA) > > gasoline > meat > bicycle > bacon > electricity > > sulphur is used in dyes > > indigo > madder > larkspur > > sulphur is the name of a mountain in banff national park > > fifi > castle > bonnet > sulphur is the cause of the smell in Rotorua, New Zealand... from Wikipedia: " Rotorua is nicknamed Sulphur City, because of the aforementioned thermal activity. The sulphur gives off an odour unique to Rotorua that adds to the visitor experience." Lots of potential names for F11, flipflop (what some of the politicians like to do and an alternative name for a jandal), Trout, Volcano... I dunno there are a heck lot more. - Nigel From j.w.r.degoede at hhs.nl Sat May 24 05:34:27 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 24 May 2008 07:34:27 +0200 Subject: Announcing a new F-10 Feature Proposal: Better Webcam Support In-Reply-To: <1211585885.3566.124.camel@cookie.hadess.net> References: <4836DA23.3090709@hhs.nl> <20080523152426.GB3224@nostromo.devel.redhat.com> <1211559657.3566.97.camel@cookie.hadess.net> <48372673.5020703@hhs.nl> <1211585885.3566.124.camel@cookie.hadess.net> Message-ID: <4837A8E3.5010908@hhs.nl> Bastien Nocera wrote: > On Fri, 2008-05-23 at 22:17 +0200, Hans de Goede wrote: >> Bastien Nocera wrote: >>> On Fri, 2008-05-23 at 11:24 -0400, Bill Nottingham wrote: >>>> Hans de Goede (j.w.r.degoede at hhs.nl) said: >>>>> See: >>>>> >>>>> http://fedoraproject.org/wiki/Features/BetterWebcamSupport >>>> Any reason a shim library is simpler than porting apps to V4L2? >>> Same question here. There's a good number of applications that are >>> either obsoleted by a v4l2 version, or support both versions. Which >>> applications were you thinking of supporting with this scheme? >>> >>> Unless there's tens of open source apps that would need changing, or a >>> couple of (useful) proprietary ones that don't support v4l2, the library >>> is probably not very useful to have (especially as you probably wouldn't >>> be able to port _all_ the v4l1 drivers to v4l2). >>> >> See my reaction to Bill's question, and yes there are a few usefull proprietary >> apps in the mix unfortunately. > > Do you have a list of those apps? Both the proprietary ones and the Open > Source ones. For the latter, it could be more interesting to create a > guide for the conversion from V4L1 to V4L2, and see whether Fedora > maintainers of those projects can help out with the conversion, or at > least submit it upstream for consideration. > No list atm, noteworthy closed source ones are flash (adobe version) and skype. Opensource v4l1 viewers I know about are camomara, spcaview. But quite a few v4l2 apps also don't work with all v4l2 cams due to not supporting all needed colorformats, examples of these are for example xawtv and luvcview. I must say my primary focus at the moment is getting drivers cleaned up and merged in the mainline, but the userspace side of things definetely needs work too. Regards, Hans From rhally at mindspring.com Sat May 24 06:10:10 2008 From: rhally at mindspring.com (Richard Hally) Date: Sat, 24 May 2008 02:10:10 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080523065702.1e021094@vader.jdub.homelinux.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <48366095.50204@mindspring.com> <20080523065702.1e021094@vader.jdub.homelinux.org> Message-ID: <4837B142.7040307@mindspring.com> Josh Boyer wrote: > On Fri, 23 May 2008 02:13:41 -0400 > Richard Hally wrote: > >> Josh Boyer wrote: >>> Let the naming begin! We're starting very early this time around in >>> the name game for F10. So, let the suggestions flow! >>> >>> Remember the rules: >>> >>> 1) must have some link to Sulphur >>> >>> More specifically, the link should be >>> Sulphur is a and >>> is a >>> Where is the same for both >>> >>> 2) The link between and Sulphur cannot be the same as between >>> Werewolf and Sulphur. That link was "things that react badly with >>> silver". >>> >>> I will be collecting suggestions for 1 week, so the cutoff for names is: >>> >>> May 29, 2008 >>> >>> Suggestions will be run through the legal queue and an election will >>> happen for Fedora contributors to pick the next Fedora name. >>> >>> josh >>> >> Acid -- "we are all on Acid" or "give it an Acid test" >> >> sulfur is a chemical -> acid is a chemical. > > Sulfur is an element, not a chemical. > > josh > To be a little pedantic, chemical -- the noun usage is defined in my dictionary as "A substance produced by or used in a chemical process". The adjective usage is defined as 1. "Of or pertaining to chemistry" 2. "Of or pertaining to the properties of chemicals". Strictly speaking all elements are chemicals. Chemical compounds usually have multiple elements but a single element is still a chemical. From dev at nigelj.com Sat May 24 06:15:34 2008 From: dev at nigelj.com (Nigel Jones) Date: Sat, 24 May 2008 18:15:34 +1200 Subject: Away for a couple of days Message-ID: <4837B286.1080506@nigelj.com> Hi All, Just FYI I'll be quite busy the next few days, couple of reasons: a) -ETOOBUSY b) -EBADHARDWARE - RAM is giving me nightmares on my desktop, so I'll be spending a bit of time trying to get that going I *should* be able to still look after my packages and I'll be infrequently checking my dev e-mail & IRC, if anything urgent comes up, you can always try to catch me on my normal e-mail address nigel at nigelj.com. I'll be back around 0000 28th May UTC - Nigel From rhally at mindspring.com Sat May 24 06:17:56 2008 From: rhally at mindspring.com (Richard Hally) Date: Sat, 24 May 2008 02:17:56 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1211563222.3935.182.camel@localhost.localdomain> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <48366095.50204@mindspring.com> <1211563222.3935.182.camel@localhost.localdomain> Message-ID: <4837B314.7090800@mindspring.com> Simo Sorce wrote: > On Fri, 2008-05-23 at 02:13 -0400, Richard Hally wrote: >> Josh Boyer wrote: >>> Let the naming begin! We're starting very early this time around in >>> the name game for F10. So, let the suggestions flow! >>> >>> Remember the rules: >>> >>> 1) must have some link to Sulphur >>> >>> More specifically, the link should be >>> Sulphur is a and >>> is a >>> Where is the same for both >>> >>> 2) The link between and Sulphur cannot be the same as between >>> Werewolf and Sulphur. That link was "things that react badly with >>> silver". >>> >>> I will be collecting suggestions for 1 week, so the cutoff for names is: >>> >>> May 29, 2008 >>> >>> Suggestions will be run through the legal queue and an election will >>> happen for Fedora contributors to pick the next Fedora name. >>> >>> josh >>> >> Acid -- "we are all on Acid" or "give it an Acid test" >> >> sulfur is a chemical -> acid is a chemical. > > Acid is not a chemical per se, it is a property. > > SImo. > The correct word for the property is "acidic". Sulfuric acid is acidic i.e. has the the properties of an acid. see also LSD. =8) From rhally at mindspring.com Sat May 24 06:20:00 2008 From: rhally at mindspring.com (Richard Hally) Date: Sat, 24 May 2008 02:20:00 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1211563307.3935.185.camel@localhost.localdomain> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <483664D1.8010303@mindspring.com> <1211563307.3935.185.camel@localhost.localdomain> Message-ID: <4837B390.9090405@mindspring.com> Simo Sorce wrote: > On Fri, 2008-05-23 at 02:31 -0400, Richard Hally wrote: >> Josh Boyer wrote: >>> Let the naming begin! We're starting very early this time around in >>> the name game for F10. So, let the suggestions flow! >>> >>> Remember the rules: >>> >>> 1) must have some link to Sulphur >>> >>> More specifically, the link should be >>> Sulphur is a and >>> is a >>> Where is the same for both >>> >>> 2) The link between and Sulphur cannot be the same as between >>> Werewolf and Sulphur. That link was "things that react badly with >>> silver". >>> >>> I will be collecting suggestions for 1 week, so the cutoff for names is: >>> >>> May 29, 2008 >>> >>> Suggestions will be run through the legal queue and an election will >>> happen for Fedora contributors to pick the next Fedora name. >>> >>> josh >>> >> Steam -- >> >> sulfur is in coal; steam is in coal (indirectly when you burn coal to heat >> water) (Yes that's a stretch) >> >> We can all be steamed. We'll all be in hot water. we can power a technical >> revolution. > > I have already proposed 'steam'. > With, I think, also a better link :-) > > Simo. > yup, saw that after I posted. Too bad it is already in use. =8) From harald at redhat.com Sat May 24 06:40:51 2008 From: harald at redhat.com (Harald Hoyer) Date: Sat, 24 May 2008 08:40:51 +0200 Subject: Tempelhof (was Re: Werewolf -> Sulphur -> ? Sulphur is a , is a ) In-Reply-To: <20080524004236.GA10030@tango.0pointer.de> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211588878.3566.136.camel@cookie.hadess.net> <20080524004236.GA10030@tango.0pointer.de> Message-ID: Lennart Poettering wrote: > On Sat, 24.05.08 01:27, Bastien Nocera (bnocera at redhat.com) wrote: > >> On Thu, 2008-05-22 at 06:57 -0500, Josh Boyer wrote: >>> Let the naming begin! We're starting very early this time around in >>> the name game for F10. So, let the suggestions flow! >>> >>> Remember the rules: >>> >>> 1) must have some link to Sulphur >>> >>> More specifically, the link should be >>> Sulphur is a and >>> is a >>> Where is the same for both >>> >>> 2) The link between and Sulphur cannot be the same as between >>> Werewolf and Sulphur. That link was "things that react badly with >>> silver". >> The answer is: >> Tempelhof > > If we take this "world domination" thing seriously we definitely > should name a Fedora release after a Nazi airport. I am all for it, > would be a great signal to the world! > > > > Lennart > Bang! Godwin's law! From rhally at mindspring.com Sat May 24 07:23:55 2008 From: rhally at mindspring.com (Richard Hally) Date: Sat, 24 May 2008 03:23:55 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <7f692fec0805231212q2dcfce60uaf79c277db2f98bd@mail.gmail.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <48366095.50204@mindspring.com> <1211563222.3935.182.camel@localhost.localdomain> <7f692fec0805231212q2dcfce60uaf79c277db2f98bd@mail.gmail.com> Message-ID: <4837C28B.1050501@mindspring.com> Yaakov Nemoy wrote: > On Fri, May 23, 2008 at 1:20 PM, Simo Sorce wrote: >> On Fri, 2008-05-23 at 02:13 -0400, Richard Hally wrote: >>> Josh Boyer wrote: >>>> Let the naming begin! We're starting very early this time around in >>>> the name game for F10. So, let the suggestions flow! >>>> >>>> Remember the rules: >>>> >>>> 1) must have some link to Sulphur >>>> >>>> More specifically, the link should be >>>> Sulphur is a and >>>> is a >>>> Where is the same for both >>>> >>>> 2) The link between and Sulphur cannot be the same as between >>>> Werewolf and Sulphur. That link was "things that react badly with >>>> silver". >>>> >>>> I will be collecting suggestions for 1 week, so the cutoff for names is: >>>> >>>> May 29, 2008 >>>> >>>> Suggestions will be run through the legal queue and an election will >>>> happen for Fedora contributors to pick the next Fedora name. >>>> >>>> josh >>>> >>> Acid -- "we are all on Acid" or "give it an Acid test" >>> >>> sulfur is a chemical -> acid is a chemical. >> Acid is not a chemical per se, it is a property. >> > > Lysergic Acid Diethylamide :) (or more appropriately > Lysergsaeurediethylamid). We could dedicate Fedora 10 to Albert > Hoffman, and then say ours goes to 102. > > -Yaakov > That's one of the possible interpretations. aka LSD =8-) There are plenty of pictures and diagrams for it. There is already one in the xscreensaver "molecule" available in Fedora. From vpivaini at cs.helsinki.fi Sat May 24 07:34:06 2008 From: vpivaini at cs.helsinki.fi (Ville-Pekka Vainio) Date: Sat, 24 May 2008 10:34:06 +0300 Subject: Packaging Firefox extensions (Finnish spell checking) In-Reply-To: References: <200805240017.23616.vpivaini@cs.helsinki.fi> Message-ID: <200805241034.06930.vpivaini@cs.helsinki.fi> Colin Walters wrote: > It's fine, see also the mugshot package for use of the > system-installed extensions standard. I haven't looked at the Beagle > extension but hopefully it's doing the right thing. Ok, I did. Both of these packages seem to do the same thing, they have their files in %{_libdir}/mozilla/extensions/%{firefox_app_id}/%{mugshot_ext_id} or something similar. > The main thing lacking is integration of the addon dialog and PackageKit. I don't quite understand what you mean. If the firefox-voikko package passes review, I plan to have it in the Fedora repositories just like any other package. I don't really see what PackageKit specifically has to do with that. The addon dialog "just works", when you install the RPM, Firefox detects the new extension files and opens up the addon dialog when (re)started. -- Ville-Pekka Vainio From nicolas.mailhot at laposte.net Sat May 24 07:49:39 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 24 May 2008 09:49:39 +0200 (CEST) Subject: NetworkManager: I want to believe, but... [was Re: F9 potential service network bug?] In-Reply-To: References: <3da3b5b40805161502w62f372dseca0ab6310e44447@mail.gmail.com> <1210975852.6805.10.camel@localhost.localdomain> <3da3b5b40805161522i2300f1cdhb1fc7b074084873f@mail.gmail.com> <604aa7910805161527j6b193c6dj2af4248155d5cdaf@mail.gmail.com> <20080517112856.GA18698@jadzia.bu.edu> <1211069083.3070.392.camel@cookie.hadess.net> <20080522142554.GB8728@jadzia.bu.edu> <1211472267.5352.25.camel@localhost.localdomain> <1211509501.19171.7.camel@aglarond.local> Message-ID: <48284.192.54.193.58.1211615379.squirrel@rousalka.dyndns.org> Le Sam 24 mai 2008 03:45, Zing a ?crit : > IMO, the options that server admins want (or at least I want) is what > dan essentially says: to run without a daemon "managing" my network > interface... it's just pure bloatiness and feel goodiness from this > perspective. It's pure bloatiness now because NM people are focused on the client-side. If they stopped thinking about laptop needs but focused a little more on non-laptop desktop and server needs they'd have better acceptance. 1. "how can I pull down the network interface as fast as possible to save battery" or 2."how can I move my network interface from wifi to wired" are laptop considerations 1. how can I identify network interface is my access to network foo 2. how can I make sure the right filtering rules for network foo are activated on this interface 3. how can I signal the software components supposed to be providing a service to network foo this is their interface and they can activate 4. how can I adapt the DNS records if needed (some servers are on dhcp too, some desktops use dyndns) 5. how can I bond it with another that provides the same path for redundancy is something that would provide a real added value for non-laptop users -- Nicolas Mailhot From nicolas.mailhot at laposte.net Sat May 24 07:51:19 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 24 May 2008 09:51:19 +0200 (CEST) Subject: Announcing a new F-10 Feature Proposal: Better Webcam Support In-Reply-To: <4837A8E3.5010908@hhs.nl> References: <4836DA23.3090709@hhs.nl> <20080523152426.GB3224@nostromo.devel.redhat.com> <1211559657.3566.97.camel@cookie.hadess.net> <48372673.5020703@hhs.nl> <1211585885.3566.124.camel@cookie.hadess.net> <4837A8E3.5010908@hhs.nl> Message-ID: <48488.192.54.193.58.1211615479.squirrel@rousalka.dyndns.org> Le Sam 24 mai 2008 07:34, Hans de Goede a ?crit : > I must say my primary focus at the moment is getting drivers cleaned > up > and merged in the mainline, but the userspace side of things > definetely needs work too. ivtv is not fully v4l2 BTW. It needs some v4l2 love -- Nicolas Mailhot From nicolas.mailhot at laposte.net Sat May 24 08:01:08 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 24 May 2008 10:01:08 +0200 (CEST) Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <4837C28B.1050501@mindspring.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <48366095.50204@mindspring.com> <1211563222.3935.182.camel@localhost.localdomain> <7f692fec0805231212q2dcfce60uaf79c277db2f98bd@mail.gmail.com> <4837C28B.1050501@mindspring.com> Message-ID: <49514.192.54.193.58.1211616068.squirrel@rousalka.dyndns.org> >>>>> 1) must have some link to Sulphur >>>>> >>>>> More specifically, the link should be >>>>> Sulphur is a and >>>>> is a >>>>> Where is the same for both Another one: Sulphur is a volcano output Nu?e ardente is a volcano output (http://en.wikipedia.org/wiki/Nuee_ardente) -- Nicolas Mailhot From dwmw2 at infradead.org Sat May 24 09:51:06 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 24 May 2008 10:51:06 +0100 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> <1211405127.21380.382.camel@pmac.infradead.org> <1211444657.21380.424.camel@pmac.infradead.org> <20080522183614.GB32314@redhat.com> <1211528761.21380.481.camel@pmac.infradead.org> <1211563622.28967.60.camel@pmac.infradead.org> Message-ID: <1211622666.31212.83.camel@shinybook.infradead.org> On Fri, 2008-05-23 at 16:00 -0300, Alexandre Oliva wrote: > Understood. > > I see one of your patches simply renames a .h to a .c and makes the > blob a built-in firmware. > > Any reason to not have moved it to the firmware/ dir, as I expected > from looking at your patches? I considered it, but I figured it was better to do things one step at a a time. I was probably wrong though; I'll take another look. -- dwmw2 From kanarip at kanarip.com Sat May 24 10:08:38 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sat, 24 May 2008 12:08:38 +0200 Subject: rawhide report: 20080523 changes In-Reply-To: <20080523102923.189EE209D29@releng1.fedora.phx.redhat.com> References: <20080523102923.189EE209D29@releng1.fedora.phx.redhat.com> Message-ID: <4837E926.8000902@kanarip.com> Rawhide wrote: > setting up repos > setting up old repo file:///mnt/koji/mash/rawhide-20080522/development/source/SRPMS > Excluding Packages in global exclude list > Finished > setting up new repo file:///mnt/koji/mash/rawhide-20080523/development/source/SRPMS > Excluding Packages in global exclude list > Finished > performing the diff Is it a coincidence or do the changelog entries in these mails stop after "p"? I'm looking at the rawhide report's 0523 and 0522 (since the changelog entries got sorted?). Kind regards, Jeroen van Meeuwen -kanarip From dwmw2 at infradead.org Sat May 24 10:57:35 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 24 May 2008 11:57:35 +0100 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> <1211405127.21380.382.camel@pmac.infradead.org> <1211444657.21380.424.camel@pmac.infradead.org> <20080522183614.GB32314@redhat.com> <1211528761.21380.481.camel@pmac.infradead.org> <1211563622.28967.60.camel@pmac.infradead.org> Message-ID: <1211626655.540.8.camel@pmac.infradead.org> On Fri, 2008-05-23 at 16:00 -0300, Alexandre Oliva wrote: > I see one of your patches simply renames a .h to a .c and makes the > blob a built-in firmware. > > Any reason to not have moved it to the firmware/ dir, as I expected > from looking at your patches? This attempts it, on top of the current git tree. Doesn't work with O= build though, because it doesn't create the firmware/korg/ directory: Real life calls... index f6b0c3c..f9d7f17 100644 --- a/firmware/Makefile +++ b/firmware/Makefile @@ -2,9 +2,12 @@ # kbuild file for firmware/ # +firmware-$(CONFIG_SND_KORG1212_FIRMWARE_IN_KERNEL) += korg/k1212 + firmware_bins := $(subst ",,$(CONFIG_BUILTIN_FIRMWARE)) -firmware_objs := $(patsubst %,%.o, $(firmware_bins)) -firmware_srcs := $(patsubst %,$(obj)/%.c, $(firmware_bins)) +firmware_srcs_generated := $(patsubst %,$(obj)/%.c, $(firmware_bins)) +firmware_objs := $(patsubst %,%.o, $(firmware_bins) $(firmware-y)) +firmware_dirs := $(dir $(firmware_objs)) quiet_cmd_fwbin = MK_FW $@ @@ -21,4 +24,4 @@ $(firmware_srcs): $(obj)/%.c: $(srctree)/$(obj)/% obj-y := $(firmware_objs) -targets := $(firmware_objs) +targets := $(firmware_objs) $(firmware_srcs_generated) diff --git a/sound/pci/korg1212/korg1212-firmware.c b/firmware/korg/k1212.c similarity index 100% rename from sound/pci/korg1212/korg1212-firmware.c rename to firmware/korg/k1212.c diff --git a/sound/pci/korg1212/Makefile b/sound/pci/korg1212/Makefile index 7a5ebdf..f11ce1b 100644 --- a/sound/pci/korg1212/Makefile +++ b/sound/pci/korg1212/Makefile @@ -7,4 +7,3 @@ snd-korg1212-objs := korg1212.o # Toplevel Module Dependency obj-$(CONFIG_SND_KORG1212) += snd-korg1212.o -obj-$(CONFIG_SND_KORG1212_FIRMWARE_IN_KERNEL) += korg1212-firmware.o -- dwmw2 From paul at all-the-johnsons.co.uk Sat May 24 11:05:55 2008 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Sat, 24 May 2008 12:05:55 +0100 Subject: Mounting drives by label Message-ID: <20080524110110.M17856@all-the-johnsons.co.uk> Hi, I've labelled my drives using e2label and they're now being recognised as home_drive, audio_drive and devel_drive. I can only sometimes mount them using fstab as it looks like the labels aren't being used, but the last /dev/ sd* is (for example, /dev/sde1 might be audio_drive, but then on the next boot, /dev/sdf1 is audio_drive but then the system fails on booting with the error that /dev/sde1 is mounted). There is nothing in /etc/mtab, but the problem seems to occur when the system is rebooted after the shutdown procedure didn't work correctly. Any ideas on this or what I should file it under with BZ? TTFN Paul -- Programmer, GirlGamer www.girlgamer.com From email.ahmedkamal at googlemail.com Sat May 24 11:19:27 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Sat, 24 May 2008 14:19:27 +0300 Subject: Mounting drives by label In-Reply-To: <20080524110110.M17856@all-the-johnsons.co.uk> References: <20080524110110.M17856@all-the-johnsons.co.uk> Message-ID: <3da3b5b40805240419s765e78eaje24490791ca5eea2@mail.gmail.com> I think sata drives are not meant to be persistent. Replace /dev/sdX in your fastab, with LABEL=audio_drive or so. This will mount the drives by label Regards On Sat, May 24, 2008 at 2:05 PM, Paul F. Johnson < paul at all-the-johnsons.co.uk> wrote: > Hi, > > I've labelled my drives using e2label and they're now being recognised as > home_drive, audio_drive and devel_drive. I can only sometimes mount them > using fstab as it looks like the labels aren't being used, but the last > /dev/ > sd* is (for example, /dev/sde1 might be audio_drive, but then on the next > boot, /dev/sdf1 is audio_drive but then the system fails on booting with > the > error that /dev/sde1 is mounted). > > There is nothing in /etc/mtab, but the problem seems to occur when the > system > is rebooted after the shutdown procedure didn't work correctly. > > Any ideas on this or what I should file it under with BZ? > > TTFN > > Paul > > -- > Programmer, GirlGamer > www.girlgamer.com > > -- > 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 jkeating at redhat.com Sat May 24 11:22:18 2008 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 24 May 2008 07:22:18 -0400 Subject: rawhide report: 20080523 changes In-Reply-To: <4837E926.8000902@kanarip.com> References: <20080523102923.189EE209D29@releng1.fedora.phx.redhat.com> <4837E926.8000902@kanarip.com> Message-ID: <1211628138.5079.162.camel@localhost.localdomain> On Sat, 2008-05-24 at 12:08 +0200, Jeroen van Meeuwen wrote: > > Is it a coincidence or do the changelog entries in these mails stop > after "p"? I'm looking at the rawhide report's 0523 and 0522 (since the > changelog entries got sorted?). repodiff is getting a traceback when ran in cron's environment redirecting to a file. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From aoliva at redhat.com Sat May 24 11:37:02 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Sat, 24 May 2008 08:37:02 -0300 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: <20080523194942.GA13150@devserv.devel.redhat.com> (Alan Cox's message of "Fri\, 23 May 2008 15\:49\:42 -0400") References: <20080521143345.383eb10b@vader.jdub.homelinux.org> <1211405127.21380.382.camel@pmac.infradead.org> <4834D3F2.90409@gmail.com> <20080522164742.GD8443@devserv.devel.redhat.com> <1211478494.21380.459.camel@pmac.infradead.org> <20080522184814.GA17490@devserv.devel.redhat.com> <1211528657.21380.478.camel@pmac.infradead.org> <20080523194942.GA13150@devserv.devel.redhat.com> Message-ID: On May 23, 2008, Alan Cox wrote: > On Fri, May 23, 2008 at 08:44:17AM +0100, David Woodhouse wrote: >> > No it isn't. See "mere aggregation" >> >> That's a very optimistic interpretation of 'mere aggregation', given >> that the licence is very clearly stating that it applies not only to >> derivative works but also to collective works. > I think the lawyers probably have more idea than you. Although I'm pretty sure they'd have a hard time making this case once they saw something like this: http://lkml.org/lkml/2007/9/18/277 Their opinions may very well be more informed, but until a court decides on the matter, they're just as right or wrong as ours. It's not too hard to find a lawyer that will tell you what you want to hear. It's like going to doctors until you find one that says you're not going to die soon, and then become convinced this one is right and all the others were wrong in their diagnostic :-) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From jwboyer at gmail.com Sat May 24 12:17:14 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Sat, 24 May 2008 07:17:14 -0500 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <4837B142.7040307@mindspring.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <48366095.50204@mindspring.com> <20080523065702.1e021094@vader.jdub.homelinux.org> <4837B142.7040307@mindspring.com> Message-ID: <20080524071714.696bf8c5@vader.jdub.homelinux.org> On Sat, 24 May 2008 02:10:10 -0400 Richard Hally wrote: > Josh Boyer wrote: > > On Fri, 23 May 2008 02:13:41 -0400 > > Richard Hally wrote: > > > >> Josh Boyer wrote: > >>> Let the naming begin! We're starting very early this time around in > >>> the name game for F10. So, let the suggestions flow! > >>> > >>> Remember the rules: > >>> > >>> 1) must have some link to Sulphur > >>> > >>> More specifically, the link should be > >>> Sulphur is a and > >>> is a > >>> Where is the same for both > >>> > >>> 2) The link between and Sulphur cannot be the same as between > >>> Werewolf and Sulphur. That link was "things that react badly with > >>> silver". > >>> > >>> I will be collecting suggestions for 1 week, so the cutoff for names is: > >>> > >>> May 29, 2008 > >>> > >>> Suggestions will be run through the legal queue and an election will > >>> happen for Fedora contributors to pick the next Fedora name. > >>> > >>> josh > >>> > >> Acid -- "we are all on Acid" or "give it an Acid test" > >> > >> sulfur is a chemical -> acid is a chemical. > > > > Sulfur is an element, not a chemical. > > > > josh > > > > To be a little pedantic, chemical -- the noun usage is defined in my dictionary > as "A substance produced by or used in a chemical process". > The adjective usage is defined as 1. "Of or pertaining to chemistry" 2. "Of or > pertaining to the properties of chemicals". > > Strictly speaking all elements are chemicals. Chemical compounds usually have > multiple elements but a single element is still a chemical. Indeed you are right. My chemistry teacher would be sorely disappointed in me. josh From erik at vanpienbroek.nl Sat May 24 12:33:22 2008 From: erik at vanpienbroek.nl (Erik van Pienbroek) Date: Sat, 24 May 2008 14:33:22 +0200 Subject: The problems upgraded to fedora 9 In-Reply-To: References: Message-ID: <1211632402.9630.6.camel@erik.lan> Op zaterdag 24-05-2008 om 10:08 uur [tijdzone +0800], schreef ???: > My program failed to compile on fedora 9 with the complaints of some > functions like memset, strcpy not found. Hi, This is probably caused by gcc 4.3, which is more strict than previous versions of gcc. Most of the time these errors are caused by missing #include's. The functions memset and strcpy are both declared in string.h, so you need to check if the .c file which fails to compile has an #include in it and add it if necessary. To find out which function is declared in which .h file, you can consult the man-pages (for example: man strncpy) Regards, Erik van Pienbroek From harald at redhat.com Sat May 24 12:38:52 2008 From: harald at redhat.com (Harald Hoyer) Date: Sat, 24 May 2008 14:38:52 +0200 Subject: Mounting drives by label In-Reply-To: <3da3b5b40805240419s765e78eaje24490791ca5eea2@mail.gmail.com> References: <20080524110110.M17856@all-the-johnsons.co.uk> <3da3b5b40805240419s765e78eaje24490791ca5eea2@mail.gmail.com> Message-ID: Ahmed Kamal wrote: > I think sata drives are not meant to be persistent. Replace /dev/sdX in > your fastab, with LABEL=audio_drive or so. This will mount the drives by > label > Regards > > On Sat, May 24, 2008 at 2:05 PM, Paul F. Johnson > > wrote: > > Hi, > > I've labelled my drives using e2label and they're now being > recognised as > home_drive, audio_drive and devel_drive. I can only sometimes mount them > using fstab as it looks like the labels aren't being used, but the > last /dev/ > sd* is (for example, /dev/sde1 might be audio_drive, but then on the > next > boot, /dev/sdf1 is audio_drive but then the system fails on booting > with the > error that /dev/sde1 is mounted). > > There is nothing in /etc/mtab, but the problem seems to occur when > the system > is rebooted after the shutdown procedure didn't work correctly. > > Any ideas on this or what I should file it under with BZ? > > TTFN > > Paul > > -- > Programmer, GirlGamer > www.girlgamer.com > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > /dev/disk $ find /dev/disk /dev/disk /dev/disk/by-label /dev/disk/by-label/Recovery\x20Partition /dev/disk/by-label/VAIO /dev/disk/by-label/\x2fboot /dev/disk/by-uuid /dev/disk/by-uuid/FC30-3DA9 /dev/disk/by-uuid/dc173540-b6c2-40cd-b167-aad6fd6f3668 /dev/disk/by-uuid/9ECCDDF0CCDDC327 /dev/disk/by-uuid/4C54A5A254A58EF0 /dev/disk/by-uuid/a11cd600-3f6b-4c3d-96bf-3e12f16f6e5f /dev/disk/by-id /dev/disk/by-id/usb-Sony_PRS-505.UC:SD_080046100067D048-0:2-part1 /dev/disk/by-id/usb-Sony_PRS-505.UC:SD_080046100067D048-0:2 /dev/disk/by-id/usb-Sony_PRS-505.UC:MS_080046100067D048-0:1 /dev/disk/by-id/usb-Sony_PRS-505.UC_080046100067D048-0:0 /dev/disk/by-id/ata-FUJITSU_MHV2200BT_NY06T6825BW7-part5 /dev/disk/by-id/scsi-SATA_FUJITSU_MHV2200_NY06T6825BW7-part5 /dev/disk/by-id/ata-FUJITSU_MHV2200BT_NY06T6825BW7-part1 /dev/disk/by-id/scsi-SATA_FUJITSU_MHV2200_NY06T6825BW7-part1 /dev/disk/by-id/ata-FUJITSU_MHV2200BT_NY06T6825BW7-part2 /dev/disk/by-id/scsi-SATA_FUJITSU_MHV2200_NY06T6825BW7-part2 /dev/disk/by-id/ata-FUJITSU_MHV2200BT_NY06T6825BW7-part3 /dev/disk/by-id/scsi-SATA_FUJITSU_MHV2200_NY06T6825BW7-part3 /dev/disk/by-id/ata-FUJITSU_MHV2200BT_NY06T6825BW7-part4 /dev/disk/by-id/scsi-SATA_FUJITSU_MHV2200_NY06T6825BW7-part4 /dev/disk/by-id/ata-FUJITSU_MHV2200BT_NY06T6825BW7 /dev/disk/by-id/scsi-SATA_FUJITSU_MHV2200_NY06T6825BW7 /dev/disk/by-path /dev/disk/by-path/pci-0000:00:1d.7-usb-0:1:1.0-scsi-0:0:0:2-part1 /dev/disk/by-path/pci-0000:00:1d.7-usb-0:1:1.0-scsi-0:0:0:2 /dev/disk/by-path/pci-0000:00:1d.7-usb-0:1:1.0-scsi-0:0:0:1 /dev/disk/by-path/pci-0000:00:1d.7-usb-0:1:1.0-scsi-0:0:0:0 /dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0-part5 /dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0-part1 /dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0-part2 /dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0-part3 /dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0-part4 /dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 /dev/disk/by-path/pci-0000:00:1f.1-scsi-0:0:0:0 From jreiser at BitWagon.com Sat May 24 12:41:14 2008 From: jreiser at BitWagon.com (John Reiser) Date: Sat, 24 May 2008 05:41:14 -0700 Subject: Mounting drives by label In-Reply-To: <20080524110110.M17856@all-the-johnsons.co.uk> References: <20080524110110.M17856@all-the-johnsons.co.uk> Message-ID: <48380CEA.1070002@BitWagon.com> > I've labelled my drives using e2label and they're now being recognised as > home_drive, audio_drive and devel_drive. I can only sometimes mount them > using fstab as it looks like the labels aren't being used, but the last /dev/ > sd* is (for example, /dev/sde1 might be audio_drive, but then on the next > boot, /dev/sdf1 is audio_drive but then the system fails on booting with the > error that /dev/sde1 is mounted). > > There is nothing in /etc/mtab, but the problem seems to occur when the system > is rebooted after the shutdown procedure didn't work correctly. > > Any ideas on this or what I should file it under with BZ? If /etc/fstab contains lines such as /dev/sdf1 /dir1 ext3 defaults 2 2 then you are at the mercy of the random order in which the system recognizes drives (sde, sdf, etc.) It is somewhat curious, but not necessarily a bug, if the order changes upon reboot after a failed shutdown (and no hardware changes.) If /etc/fstab contains lines such as LABEL=audio_drive /dir1 ext3 defaults 2 2 then the first partition with label "audio_drive" should be mounted as /dir1. It is up to you to keep the labels unique. Duplicate labels commonly occur after moving drives from system to system, because neither people nor anaconda reliably choose unique names ("/", "/1", "/home", "/boot", etc.) If /etc/fstab contains lines such as UUID=xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /dir1 ext3 defaults 2 2 then the first partition with the specified UUID should be mounted as /dir1. There is only a *very* small probability of collision in UUID, as long as you don't copy partitions with a "blind" copy command such as 'cp' or 'dd'. "tune2fs -l /dev/sdf1" shows the UUID of the ext3 filesystem in the partition /dev/sdf1. -- From jonathan.underwood at gmail.com Sat May 24 13:17:47 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sat, 24 May 2008 14:17:47 +0100 Subject: libflashsupport In-Reply-To: <20080523235451.GA8466@tango.0pointer.de> References: <48372911.9010502@fedoraproject.org> <20080523205114.GB29875@nostromo.devel.redhat.com> <1211585673.3566.120.camel@cookie.hadess.net> <20080523235451.GA8466@tango.0pointer.de> Message-ID: <645d17210805240617x25ad89a6x2de991a60d20817a@mail.gmail.com> 2008/5/24 Lennart Poettering : > Adobe Flash 10 doesn't need libflashsupport anymore to work fine on > ALSA ioplug-based backends such as pulse. Empirically I installed flash in a F-9 fresh install and had no sound in flash. I then installed libflashsupport, and got sound. The user mailing list is similarly full of similar discussions. From dwmw2 at infradead.org Sat May 24 14:39:30 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 24 May 2008 15:39:30 +0100 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: <1211626655.540.8.camel@pmac.infradead.org> References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> <1211405127.21380.382.camel@pmac.infradead.org> <1211444657.21380.424.camel@pmac.infradead.org> <20080522183614.GB32314@redhat.com> <1211528761.21380.481.camel@pmac.infradead.org> <1211563622.28967.60.camel@pmac.infradead.org> <1211626655.540.8.camel@pmac.infradead.org> Message-ID: <1211639970.540.11.camel@pmac.infradead.org> On Sat, 2008-05-24 at 11:57 +0100, David Woodhouse wrote: > This attempts it, on top of the current git tree. Doesn't work with O= > build though, because it doesn't create the firmware/korg/ directory: This works, but why in hell do I need the FORCE on the rule for $(firmware_dirs)? Without it, the directory (in the object dir, obviously) never gets created. Sam, any ideas? commit e5d131e78c4da8e3579aba0d7f533018bd801fdf Author: David Woodhouse Date: Sat May 24 11:56:32 2008 +0100 test Signed-off-by: David Woodhouse diff --git a/firmware/Makefile b/firmware/Makefile index f6b0c3c..8ce2b81 100644 --- a/firmware/Makefile +++ b/firmware/Makefile @@ -2,10 +2,15 @@ # kbuild file for firmware/ # +firmware-$(CONFIG_SND_KORG1212_FIRMWARE_IN_KERNEL) += korg/k1212 + firmware_bins := $(subst ",,$(CONFIG_BUILTIN_FIRMWARE)) -firmware_objs := $(patsubst %,%.o, $(firmware_bins)) -firmware_srcs := $(patsubst %,$(obj)/%.c, $(firmware_bins)) +firmware_srcs_generated := $(patsubst %,$(obj)/%.c, $(firmware_bins)) +firmware_objs := $(patsubst %,%.o, $(firmware_bins) $(firmware-y)) +firmware_dirs := $(patsubst %,$(obj)/%,$(dir $(firmware_objs))) +quiet_cmd_mkdir = MKDIR $@ + cmd_mkdir = mkdir -p $@ quiet_cmd_fwbin = MK_FW $@ cmd_fwbin = echo '/* File automatically generated */' > $@ ; \ @@ -16,9 +21,15 @@ quiet_cmd_fwbin = MK_FW $@ echo '};' >> $@ ; \ echo 'DECLARE_BUILTIN_FIRMWARE("$(patsubst firmware/%.c,%,$@)",fw);' >> $@ -$(firmware_srcs): $(obj)/%.c: $(srctree)/$(obj)/% +$(firmware_srcs_generated): $(obj)/%.c: $(srctree)/$(obj)/% + echo dirs :$(firmware_dirs) $(call cmd,fwbin) +$(firmware_dirs): FORCE + $(call cmd,mkdir) + +$(patsubst %,$(obj)/%,$(firmware_objs)): $(firmware_dirs) + obj-y := $(firmware_objs) -targets := $(firmware_objs) +targets := $(firmware_objs) $(firmware_srcs_generated) diff --git a/sound/pci/korg1212/korg1212-firmware.c b/firmware/korg/k1212.c similarity index 100% rename from sound/pci/korg1212/korg1212-firmware.c rename to firmware/korg/k1212.c diff --git a/sound/pci/korg1212/Makefile b/sound/pci/korg1212/Makefile index 7a5ebdf..f11ce1b 100644 --- a/sound/pci/korg1212/Makefile +++ b/sound/pci/korg1212/Makefile @@ -7,4 +7,3 @@ snd-korg1212-objs := korg1212.o # Toplevel Module Dependency obj-$(CONFIG_SND_KORG1212) += snd-korg1212.o -obj-$(CONFIG_SND_KORG1212_FIRMWARE_IN_KERNEL) += korg1212-firmware.o -- dwmw2 From eng at prowip.net.br Sat May 24 14:46:05 2008 From: eng at prowip.net.br (HM Eng.Prowip) Date: Sat, 24 May 2008 11:46:05 -0300 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: References: <20080522065724.1788e577@vader.jdub.homelinux.org> Message-ID: <200805241146.06114.eng@prowip.net.br> On Friday 23 May 2008 21:13:32 Alexandre Oliva wrote: > On May 22, 2008, Josh Boyer wrote: > > Let the naming begin! We're starting very early this time around in > > the name game for F10. So, let the suggestions flow! > > Xenon, Neon and Carbide appear to name existing software products > already, but Oil, Deuterium and sulphur are other kinds of lamps, more > specifically, other materials used to build lamps, and I couldn't find > any programs using these names. > > Pyrethrum, nicotine and sulphur are inseticides, they kills bugs! > > Charcoal, nitrate and sulphur are components of gunpowder. > > Fire and sulfur (brimstone) are major features of hell. > > Sulfur, Mercury and Salt are the Three Primes of alchemy. > well, not important to me but couldn't resist ... IMO you should avoid any mistical and religious similarities and funny comparisms (remember what the fanatics brought up about the BSD daemon, even if completely wrong) also avoid fantasies, but probably you were already in hell so you know about sulfur there :) ... there is no hell and sulfur at first thought derives from "old eggs" and sometimes next day from beer excess and other marvelous things you wouldn't use the name gaschamber either in synomity to holocaust so please let the hell, gods, wizzards and witches out sooo, if you want express something strong, powerful and related to science but still mistical in a certain way you eventually like nitrogen or hidrogen or something else more real HM > -- > Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ > Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} > FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ > Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} -- Atenciosamente Prowip Telecom Ltda. A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From vpivaini at cs.helsinki.fi Sat May 24 14:51:10 2008 From: vpivaini at cs.helsinki.fi (Ville-Pekka Vainio) Date: Sat, 24 May 2008 17:51:10 +0300 Subject: Packaging Firefox extensions (Finnish spell checking) In-Reply-To: <200805240017.23616.vpivaini@cs.helsinki.fi> References: <200805240017.23616.vpivaini@cs.helsinki.fi> Message-ID: <200805241751.11525.vpivaini@cs.helsinki.fi> To get the ball rolling, I have made a review request of firefox-voikko, which is here: https://bugzilla.redhat.com/show_bug.cgi?id=448215 Literally during the same minute that I posted the RR, upstream released a new version, so the spec and SRPM are actually outdated, but I will go and make an updated package now. -- Ville-Pekka Vainio From bnocera at redhat.com Sat May 24 15:04:27 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Sat, 24 May 2008 16:04:27 +0100 Subject: Breaking GStreamer apps Message-ID: <1211641467.3566.164.camel@cookie.hadess.net> Heya, I've removed the gnome-vfs GStreamer plugins from rawhide's gstreamer-plugins-base, as we should be using the GIO plugin now. Let me know (via Bugzilla) what breaks. Cheers From caillon at redhat.com Sat May 24 15:14:09 2008 From: caillon at redhat.com (Christopher Aillon) Date: Sat, 24 May 2008 11:14:09 -0400 Subject: Packaging Firefox extensions (Finnish spell checking) In-Reply-To: <200805240017.23616.vpivaini@cs.helsinki.fi> References: <200805240017.23616.vpivaini@cs.helsinki.fi> Message-ID: <483830C1.9070907@redhat.com> On 05/23/2008 05:17 PM, Ville-Pekka Vainio wrote: > Hi all, > > I've been packaging Finnish spell checking support for Fedora (see > http://voikko.sourceforge.net/) and now I've packaged a Firefox extension > which uses the Voikko library to do spell checking in Finnish. My initial > testing package can be found here: > http://vpv.fedorapeople.org/packages/mozvoikko/ Is there a reason the dictionary can't be integrated into hunspell? I don't want to get to the point where we have an extension for every language spellcheck. Hunspell exists to make this easier, and I'd rather see this happen there... From caillon at redhat.com Sat May 24 15:18:11 2008 From: caillon at redhat.com (Christopher Aillon) Date: Sat, 24 May 2008 11:18:11 -0400 Subject: The problems upgraded to fedora 9 In-Reply-To: <1211632402.9630.6.camel@erik.lan> References: <1211632402.9630.6.camel@erik.lan> Message-ID: <483831B3.1080408@redhat.com> On 05/24/2008 08:33 AM, Erik van Pienbroek wrote: > Op zaterdag 24-05-2008 om 10:08 uur [tijdzone +0800], schreef ???: >> My program failed to compile on fedora 9 with the complaints of some >> functions like memset, strcpy not found. > > Hi, > > This is probably caused by gcc 4.3, which is more strict than previous > versions of gcc. Most of the time these errors are caused by missing > #include's. The functions memset and strcpy are both declared in > string.h, so you need to check if the .c file which fails to compile has > an #include in it and add it if necessary. But if you are using C++, then #include From vpivaini at cs.helsinki.fi Sat May 24 16:04:34 2008 From: vpivaini at cs.helsinki.fi (Ville-Pekka Vainio) Date: Sat, 24 May 2008 19:04:34 +0300 Subject: Packaging Firefox extensions (Finnish spell checking) In-Reply-To: <483830C1.9070907@redhat.com> References: <200805240017.23616.vpivaini@cs.helsinki.fi> <483830C1.9070907@redhat.com> Message-ID: <200805241904.34953.vpivaini@cs.helsinki.fi> Christopher Aillon wrote: > Is there a reason the dictionary can't be integrated into hunspell? I > don't want to get to the point where we have an extension for every > language spellcheck. Hunspell exists to make this easier, and I'd > rather see this happen there... The Voikko project initially started as the hunspell-fi project, but hunspell was dropped for now, because using malaga gives better results with the Finnish language. If you're interested, please read . One big decision maker was also the fact that someone called Hannu V?is?nen maintains a big Finnish vocabulary known upstream as suomi-malaga, in Fedora packaged as malaga-suomi-voikko. This, as the name suggests, requires using malaga. Voikko gives excellent results with the Finnish language currently, much better than any other free software implementations (myspell/ispell/aspell and hunspell, whose upstreams are practically non-existent currently). In my opinion Voikko is now working at least as well as the only proprietary Finnish spell checker for Linux I know, Soikko. So it's pretty much the best you can get. There are less than 10 people working on Voikko right now, probably more like 5 and they're doing a great job. You do have a valid point, but I really don't see the architechture changing to hunspell or any other in the near future. Remember we don't need to have the Voikko stuff in every Fedora installation, for example the openoffice.org-voikko package is currently only installed if the user installs OO.o and the Finnish language support group. -- Ville-Pekka Vainio From naheemzaffar at gmail.com Sat May 24 16:06:54 2008 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Sat, 24 May 2008 17:06:54 +0100 Subject: bugz.fedoraproject.org? Message-ID: <3adc77210805240906w685707adr4122598fdcef5beb@mail.gmail.com> Is the redirect from bugz.fedoraproject.org down? It gives me a blank page. using (e.g.) http://bugz.fedoraproject.org/yum gives the error "The requested URL /yum was not found on this server." (it makes life easier knowing that I can go to bugz.fedoraproject.org/foo to get all bugs for foo listed..) From ricky at fedoraproject.org Sat May 24 16:58:47 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Sat, 24 May 2008 12:58:47 -0400 Subject: bugz.fedoraproject.org? In-Reply-To: <3adc77210805240906w685707adr4122598fdcef5beb@mail.gmail.com> References: <3adc77210805240906w685707adr4122598fdcef5beb@mail.gmail.com> Message-ID: <20080524165847.GC29468@Max> On 2008-05-24 05:06:54 PM, Naheem Zaffar wrote: > Is the redirect from bugz.fedoraproject.org down? > > It gives me a blank page. using (e.g.) > http://bugz.fedoraproject.org/yum gives the error "The requested URL > /yum was not found on this server." > > (it makes life easier knowing that I can go to > bugz.fedoraproject.org/foo to get all bugs for foo listed..) Oops, we accidentally disabled that in our configuration. It should be back up in a couple of minutes. Thanks for letting us know, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From caillon at redhat.com Sat May 24 17:00:28 2008 From: caillon at redhat.com (Christopher Aillon) Date: Sat, 24 May 2008 13:00:28 -0400 Subject: Packaging Firefox extensions (Finnish spell checking) In-Reply-To: <200805241904.34953.vpivaini@cs.helsinki.fi> References: <200805240017.23616.vpivaini@cs.helsinki.fi> <483830C1.9070907@redhat.com> <200805241904.34953.vpivaini@cs.helsinki.fi> Message-ID: <483849AC.8010400@redhat.com> On 05/24/2008 12:04 PM, Ville-Pekka Vainio wrote: > The Voikko project initially started as the hunspell-fi project, but hunspell > was dropped for now, because using malaga > gives better results with the > Finnish language. If you're interested, please read > . Actually, that page says the malaga backend is worse than hunspell, lacking important items such as threadsafety and does not perform well in comparison. We already have a backend which we deem to be the right backend and it would be great if work could be moved there to help get hunspell in order. > One big decision maker was > also the fact that someone called Hannu V?is?nen maintains a big Finnish > vocabulary known upstream as suomi-malaga, in Fedora packaged as > malaga-suomi-voikko. This, as the name suggests, requires using malaga. Right, this is the only reason that I can tell for using malaga. Someone did the work for malaga, but not for hunspell. > Voikko gives excellent results with the Finnish language currently, much > better than any other free software implementations (myspell/ispell/aspell > and hunspell, whose upstreams are practically non-existent currently). In my > opinion Voikko is now working at least as well as the only proprietary > Finnish spell checker for Linux I know, Soikko. So it's pretty much the best > you can get. Don't confuse the dictionary with the backend. So far I haven't seen a reason why the hunspell backend couldn't support Finnish as well as malaga if people would simply work on a dictionary for that backend instead. I think it is important to note our strong desire for making it work with hunspell. We went through great lengths to make hunspell THE dictionary. See http://fedoraproject.org/wiki/Releases/FeatureDictionary which this would now regress. From vonbrand at inf.utfsm.cl Sat May 24 17:54:12 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sat, 24 May 2008 13:54:12 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1211466316.5079.61.camel@localhost.localdomain> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211462088.4891.45.camel@victoria> <48357E29.2010609@nobugconsulting.ro> <1211466316.5079.61.camel@localhost.localdomain> Message-ID: <200805241754.m4OHsCmq028801@laptop13.inf.utfsm.cl> Jesse Keating wrote: > On Thu, 2008-05-22 at 17:07 +0300, Manuel Wolfshant wrote: > > > "Neon," which also happens to be the element 10 in the periodic > > table. > > > > > I LOVE this one. > > Unfortunately it doesn't follow the "is a" algorithm. How not? Sulphur and Neon are both chemical elements. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From vonbrand at inf.utfsm.cl Sat May 24 17:56:32 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sat, 24 May 2008 13:56:32 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1211488733.3935.136.camel@localhost.localdomain> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211462088.4891.45.camel@victoria> <48357E29.2010609@nobugconsulting.ro> <1211466316.5079.61.camel@localhost.localdomain> <1211466224.3559.48.camel@cutter> <1211467352.5079.65.camel@localhost.localdomain> <483587E7.2020300@nobugconsulting.ro> <1211486081.4891.113.camel@victoria> <604aa7910805221306k7530111dhb9398bfc37b83399@mail.gmail.com> <1211488733.3935.136.camel@localhost.localdomain> Message-ID: <200805241756.m4OHuWGK028943@laptop13.inf.utfsm.cl> Simo Sorce wrote: > On Thu, 2008-05-22 at 12:06 -0800, Jeff Spaleta wrote: > > 2008/5/22 Paul W. Frields : > > > And neon is also used often in signs that say "OPEN." :-) > > > > dude...like really...we need a flickering neon sign made up that says > > Fedora: Open > > Like this: http://people.redhat.com/ssorce/fedora-open.png ? Neon has a redish color, not blue. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From stlwrt at gmail.com Sat May 24 18:03:31 2008 From: stlwrt at gmail.com (Pavel Shevchuk) Date: Sat, 24 May 2008 21:03:31 +0300 Subject: The problems upgraded to fedora 9 In-Reply-To: References: Message-ID: Don't forget to send patch upstream to make it work out of box next time ;) On 5/24/08, ??? wrote: > To be frankly, Fedora 9 is great distribution, but there is nothing > perfect in the world with no exception of Fedora :) > > sipx project can be compiled successfully on Fedora 8, my another > program is compiled successfully on fedora 8 also > > But after I upgraded my pc to fedora 9, all the things changed. > > My program failed to compile on fedora 9 with the complaints of some > functions like memset, strcpy not found. > > Sipx projects has the same problem, which can find strncpy, strcmp, > and so on. The worst is that it always report the following errors > > [all-recursive] errors or [check-recursive] errors > > I was confused by these strange errors. > > Does fedora 9 change its include path and contents.of tools chains? > > Can anyone give me some hints? > > Thanks very much for your kindly help > > zongjun > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- http://scwlab.com From paul at all-the-johnsons.co.uk Sat May 24 18:04:39 2008 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Sat, 24 May 2008 19:04:39 +0100 Subject: glibc-2.8.90-4 causing tonnes of problems -help! Message-ID: <20080524175942.M65050@all-the-johnsons.co.uk> Hi, Depending on the box depends on the issues. For my i686 box (this one), Firefox is completely unusable (crashes with glibc errors). My x86_64 box worked then dies (it currently won't boot as /sbin/init and a few others aren't there! Prior to this, evolution would die as glibc would not allocate enough memory) I have tried to download the glibc-2.8.90-3 src rpm to rebuild it (as a stop gap until 2.8.90-5 is out), but nothing will download from koji for it (either via wget or konqueror). Can some kind soul please help me out by uploading the 2.8.90-3 src.rpm somewhere? I can probably get the x86_64 box up again by booting from RIP Linux, unpacking the 2.8.90-4 rpms and manually copying the files over then rebooting. Unless there is an easier way.... TTFN Paul -- Programmer, GirlGamer www.girlgamer.com From vonbrand at inf.utfsm.cl Sat May 24 18:10:50 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sat, 24 May 2008 14:10:50 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080522170718.GE8819@nostromo.devel.redhat.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <20080522170718.GE8819@nostromo.devel.redhat.com> Message-ID: <200805241810.m4OIAoci029859@laptop13.inf.utfsm.cl> Bill Nottingham wrote: [...] > - a river (in Texas and Arkansas, fwiw) > > Orinoco > Amazon > Sabine > Styx This I like most. Or Nile. Danube? Loire? Rhine? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From rhally at mindspring.com Sat May 24 18:12:01 2008 From: rhally at mindspring.com (Richard Hally) Date: Sat, 24 May 2008 14:12:01 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <200805241754.m4OHsCmq028801@laptop13.inf.utfsm.cl> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211462088.4891.45.camel@victoria> <48357E29.2010609@nobugconsulting.ro> <1211466316.5079.61.camel@localhost.localdomain> <200805241754.m4OHsCmq028801@laptop13.inf.utfsm.cl> Message-ID: <48385A71.2020008@mindspring.com> Horst H. von Brand wrote: > Jesse Keating wrote: >> On Thu, 2008-05-22 at 17:07 +0300, Manuel Wolfshant wrote: >>>> "Neon," which also happens to be the element 10 in the periodic >>> table. >>>> >>> I LOVE this one. >> Unfortunately it doesn't follow the "is a" algorithm. > > How not? Sulphur and Neon are both chemical elements. "Neon" may not get past legal since it is the name of a car model used by the Chrysler Corporation. http://en.wikipedia.org/wiki/Dodge_Neon From vpivaini at cs.helsinki.fi Sat May 24 18:13:08 2008 From: vpivaini at cs.helsinki.fi (Ville-Pekka Vainio) Date: Sat, 24 May 2008 21:13:08 +0300 Subject: Packaging Firefox extensions (Finnish spell checking) In-Reply-To: <483849AC.8010400@redhat.com> References: <200805240017.23616.vpivaini@cs.helsinki.fi> <200805241904.34953.vpivaini@cs.helsinki.fi> <483849AC.8010400@redhat.com> Message-ID: <200805242113.09038.vpivaini@cs.helsinki.fi> Christopher Aillon wrote: > Don't confuse the dictionary with the backend. So far I haven't seen a > reason why the hunspell backend couldn't support Finnish as well as > malaga if people would simply work on a dictionary for that backend > instead. I think it is important to note our strong desire for making it > work with hunspell. We went through great lengths to make hunspell THE > dictionary. See > http://fedoraproject.org/wiki/Releases/FeatureDictionary which this > would now regress. Noted, I can also mention this discussion in the Voikko mailing list. I wasn't even following the Voikko project at 2006 when this decision was apparently made, I also don't know the code well enough to discuss the differences in detail. I know about FeatureDictionary and I have talked about Voikko, which is already in Fedora anyway, with Caolan, among others. At this point the thing is though, either we have very good Finnish spell checking in Fedora with Voikko or we don't have any Finnish spell checking at all. Right now, as far as I can see, the Voikko project is lacking manpower for such drastic changes as changing the backend. They are doing a good job improving the current codebase in small steps, however. -- Ville-Pekka Vainio From vonbrand at inf.utfsm.cl Sat May 24 18:21:32 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sat, 24 May 2008 14:21:32 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: References: <20080522065724.1788e577@vader.jdub.homelinux.org> Message-ID: <200805241821.m4OILWi4030486@laptop13.inf.utfsm.cl> Alexandre Oliva wrote: > On May 22, 2008, Josh Boyer wrote: > > > Let the naming begin! We're starting very early this time around in > > the name game for F10. So, let the suggestions flow! > Xenon, Neon and Carbide appear to name existing software products > already, but Oil, Deuterium and sulphur are other kinds of lamps, more > specifically, other materials used to build lamps, and I couldn't find > any programs using these names. Just too bad... Caloric was the name of the (imaginary) element heat Elements for Aristotle were fire, water, air, fire. Alchemy experts around here for other elements? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From angray at beeb.net Sat May 24 19:32:26 2008 From: angray at beeb.net (Aaron Gray) Date: Sat, 24 May 2008 20:32:26 +0100 Subject: [F9][rawhide][regression] controllers DAC960 and sym53c8xxarenot detected anymore References: <006101c8bb67$fd36c5f0$0200a8c0@ze4427wm> <006401c8bc32$6ed1a980$0200a8c0@ze4427wm> Message-ID: <006401c8bdd4$e5e9cb80$0c00a8c0@ze4427wm> >> Please file this in bugzilla (https://bugzilla.redhat.com) > > I have found a simular bug in bugzilla :- > > https://bugzilla.redhat.com/show_bug.cgi?id=447552 Looks like it is the same bug and it also effects the LSI Corp. sym53c8xx controller. Aaron >> Thanks! >> -Jon >> >> 2008/5/21 Aaron Gray : >>> Fedora 9 and rawhide are not detecting Mylex DAC960 and LSI Corp. >>> sym53c8xx >>> SCSI controllers. These devices are detected and run fine on FC 6, 7 and >>> 8. >>> >>> Attached are :- >>> >>> - dmesg >>> - lspci >>> - cat /proc/interrupts >>> >>> from FC8 installation. >>> >>> Thanks, >>> >>> Aaron >>> >>> -- >>> fedora-devel-list mailing list >>> fedora-devel-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-devel-list >>> >> >> >> >> -- >> Jon Stanley >> Fedora Bug Wrangler >> jstanley at fedoraproject.org >> >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list >> >> >> -- >> No virus found in this incoming message. >> Checked by AVG. >> Version: 7.5.524 / Virus Database: 269.23.21/1458 - Release Date: >> 21/05/2008 07:21 >> >> > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > -- > No virus found in this incoming message. > Checked by AVG. Version: 7.5.524 / Virus Database: 269.24.0/1460 - Release > Date: 22/05/2008 07:06 > > From maillist at diffingo.com Sat May 24 19:33:36 2008 From: maillist at diffingo.com (Stewart Adam) Date: Sat, 24 May 2008 15:33:36 -0400 Subject: Thoughts on a hardware-specific bugzilla? Message-ID: <1211657616.19112.4.camel@Diffingo.localdomain> Hi, I've been working out a few hardware bugs on a new laptop lately, and I thought it would be interesting to create a specific category/product in the current bugzilla for hardware bugs. Various components could be listed as the different hardware categories (wifi, screen/backlight, trackpad, keyboard, speakers, etc) and this way hardware issues could be tracked separately from software bugs. Hopefully, this would help hardware bugs be resolved faster and it would be a good step forward for getting more computers to work out of the box on a standard Fedora install. Do you think it's worth it? (Just to clarify, by "hardware bugs" I mean things like missing device IDs from kernel source files, suspend quirks, display backlight control, missing sound, or a component not being detected at all. Devices malfunctioning in Linux due to a driver bug would fall under software bugs IMO) Stewart From bpepple at fedoraproject.org Sat May 24 19:52:39 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sat, 24 May 2008 15:52:39 -0400 Subject: Packager Sponsors Responsibility Policy In-Reply-To: <20080523132821.GC2612@free.fr> References: <1211502398.29628.16.camel@kennedy> <20080523132821.GC2612@free.fr> Message-ID: <1211658759.10860.5.camel@kennedy> On Fri, 2008-05-23 at 15:28 +0200, Patrice Dumas wrote: > On Thu, May 22, 2008 at 08:26:38PM -0400, Brian Pepple wrote: > > I'm looking for some feedback on what we've got so far for the Packager > > Sponsors Responsibility Policy. > > http://fedoraproject.org/wiki/Extras/Schedule/SponsorResponsibilityPolicy > > Overall looks good. There are some technicall bits missing to help > sponsors monitor the sponsored people. Thanks for the suggestions, I'll incorporate them into the policy. Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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: 197 bytes Desc: This is a digitally signed message part URL: From vonbrand at inf.utfsm.cl Sat May 24 20:09:21 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sat, 24 May 2008 16:09:21 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <200805241146.06114.eng@prowip.net.br> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <200805241146.06114.eng@prowip.net.br> Message-ID: <200805242009.m4OK9LZm005103@laptop13.inf.utfsm.cl> HM Eng.Prowip wrote: > On Friday 23 May 2008 21:13:32 Alexandre Oliva wrote: > > On May 22, 2008, Josh Boyer wrote: > > > Let the naming begin! We're starting very early this time around in > > > the name game for F10. So, let the suggestions flow! > > > > Xenon, Neon and Carbide appear to name existing software products > > already, but Oil, Deuterium and sulphur are other kinds of lamps, more > > specifically, other materials used to build lamps, and I couldn't find > > any programs using these names. > > > > Pyrethrum, nicotine and sulphur are inseticides, they kills bugs! > > > > Charcoal, nitrate and sulphur are components of gunpowder. > > > > Fire and sulfur (brimstone) are major features of hell. > > > > Sulfur, Mercury and Salt are the Three Primes of alchemy. Phlogiston came quite close to sulphur in the (corresponding, obsolete) chemical theory. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From ivazqueznet at gmail.com Sat May 24 21:28:51 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Sat, 24 May 2008 17:28:51 -0400 Subject: Thoughts on a hardware-specific bugzilla? In-Reply-To: <1211657616.19112.4.camel@Diffingo.localdomain> References: <1211657616.19112.4.camel@Diffingo.localdomain> Message-ID: <1211664532.3444.53.camel@ignacio.lan> On Sat, 2008-05-24 at 15:33 -0400, Stewart Adam wrote: > I've been working out a few hardware bugs on a new laptop lately, and I > thought it would be interesting to create a specific category/product in > the current bugzilla for hardware bugs. Various components could be > listed as the different hardware categories (wifi, screen/backlight, > trackpad, keyboard, speakers, etc) and this way hardware issues could be > tracked separately from software bugs. Hopefully, this would help > hardware bugs be resolved faster and it would be a good step forward for > getting more computers to work out of the box on a standard Fedora > install. Do you think it's worth it? I'm wondering if this discussion doesn't belong on the cross-distribution list. http://lists.freedesktop.org/mailman/listinfo/distributions -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-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 Sat May 24 19:12:29 2008 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Sat, 24 May 2008 12:12:29 -0700 Subject: wikiold frozen, work on wikinew begins, early-import happening right now Message-ID: <1211656349.3443.152.camel@calliope.phig.org> http://fedoraproject.org/wiki ==> /wikiold on 27 May == 'wikiold' == MoinMoin http://fedoraproject.org/wikinew ==> /wiki on 27 May == 'wikinew' == MediaWiki The content from MoinMoin (wikiold) is being early-imported to MediaWiki (wikinew). That is happening right now and should be ready in N hours. N == when it's ready. I'll send another announcement at that time. This content is going to be imported *again* on 27 May, to capture any changes made to wikiold. The details of that are being worked on, but the goal is to have content fidelity. Your help is needed in maintaining fidelity. Here is what you should do: 1. Don't edit either wiki until you hear the early-import is done 2. If your content can wait until 27 May (Tuesday) for the public to view it at fp.org/wiki, then do the work in wikinew and it goes live with the final-import on Tuesday. This is a chance to fix pages in wikinew that are not going to stay steady. ** DO NOT edit the page in both wikiold and wikinew. ** ** Pick one and stick with it through the migration. ** 3. If your content cannot wait until Tuesday and *must* be visible to the public at fp.org/wiki between now and Tuesday, do the work in wikiold. On Tuesday, it is final-imported into wikinew. You then want to check the content post-import as you would any other pages. Questions? #fedora-docs on irc.freenode.net is where the Wiki Gardeners hang out. Time to start pruning and trimming and re-planting. - Karsten, Wiki Gardener -- Karsten Wade, Sr. Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org gpg key : AD0E0C41 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From wtogami at redhat.com Sun May 25 03:28:43 2008 From: wtogami at redhat.com (Warren Togami) Date: Sat, 24 May 2008 23:28:43 -0400 Subject: X Keyboard layout problem Message-ID: <4838DCEB.3050700@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=448196 This is a critical problem for anybody using a non-US keyboard layout with LTSP. LTSP on Debian uses ltsp-trunk/client/configure-x.sh to generate an xorg.conf and mangle it to use an explicit keyboard layout before running the actual X. Fedora LTSP uses X autoconfiguration without an xorg.conf. This seems to be working extremely well, except for cases like this where we need a specific configuration option that differs from the X autoconfiguration. Any ideas of what we can do? Warren Togami wtogami at redhat.com From seg at haxxed.com Sun May 25 05:42:12 2008 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 25 May 2008 00:42:12 -0500 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <48385A71.2020008@mindspring.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211462088.4891.45.camel@victoria> <48357E29.2010609@nobugconsulting.ro> <1211466316.5079.61.camel@localhost.localdomain> <200805241754.m4OHsCmq028801@laptop13.inf.utfsm.cl> <48385A71.2020008@mindspring.com> Message-ID: <1218b5bc0805242242r6233b522t7f1e8b2cc3681700@mail.gmail.com> On Sat, May 24, 2008 at 1:12 PM, Richard Hally wrote: > Horst H. von Brand wrote: > >> Jesse Keating wrote: >> >>> On Thu, 2008-05-22 at 17:07 +0300, Manuel Wolfshant wrote: >>> >>>> "Neon," which also happens to be the element 10 in the periodic >>>>> >>>> table. >>>> >>>>> >>>>> >>>> I LOVE this one. >>>> >>> Unfortunately it doesn't follow the "is a" algorithm. >>> >> >> How not? Sulphur and Neon are both chemical elements. >> > > "Neon" may not get past legal since it is the name of a car model used by > the Chrysler Corporation. http://en.wikipedia.org/wiki/Dodge_Neon Trademarks are enforced with industry and uniqueness in mind. I would hope that cars and operating systems are unrelated enough markets to not be a problem. Its also not particularly unique, being the name of an element. But then IANAL. -------------- next part -------------- An HTML attachment was scrubbed... URL: From seg at haxxed.com Sun May 25 05:48:57 2008 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 25 May 2008 00:48:57 -0500 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <544eb990805230517k54f460c0k71d4b3d903f2d4ee@mail.gmail.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1211474199.29467.204.camel@localhost.localdomain> <544eb990805220943i4311e61bg58517a76695980e@mail.gmail.com> <1nfig5xbv1.ln2@ppp1053.in.ipex.cz> <544eb990805230517k54f460c0k71d4b3d903f2d4ee@mail.gmail.com> Message-ID: <1218b5bc0805242248n55b37bc4ucfc2e8b34a5d8e49@mail.gmail.com> On Fri, May 23, 2008 at 7:17 AM, Bill Crawford wrote: > How about simply ... > > Xenon. > > - It's symbol is X (but it's not the name), which is the same as the > release number. > - It's an element. > - It really promotes the "science lab" possibilities of Fedora. > - We could be the *second* example of a Xenon-Sulfur bond (see > > http://pubs.acs.org/cgi-bin/abstract.cgi/jacsat/1998/120/i31/abs/ja981032d.html > ...) > - A mixture of Xenon and Sulfur was proposed for LAMPs (see > http://members.misty.com/don/sulfbulb.html ...) > - I'll stop now. It's also the name of the CPU in the Xbox 360 (And at one point the codename for the 360 itself): http://en.wikipedia.org/wiki/Xenon_(processor) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at robertoragusa.it Sun May 25 10:19:46 2008 From: mail at robertoragusa.it (Roberto Ragusa) Date: Sun, 25 May 2008 12:19:46 +0200 Subject: F9 installation screenshot (and installation duration) In-Reply-To: References: <4816E76F.50308@gmail.com> <8990327d0804290423o6bef20c0g8ab07576ea81068@mail.gmail.com> <20080429121439.GN27333@localhost.localdomain> Message-ID: <48393D42.8060908@robertoragusa.it> Kevin Kofler wrote: > Chris Lumens redhat.com> writes: >> We used to have that, but removed it. The reason is that our estimates >> are never going to be very good based on all sorts of things like time >> to download packges (in HTTP/FTP cases) and how long it takes to run a >> package's pre/post scriptlet. > > In fact, in my experience, the estimates have always been complete nonsense > (off by a factor of 2 in either direction or things like that) even for fairly > predictable HDD installs, so IMHO you did the right thing. :-) > Why not just showing the *elapsed* time, instead of the time to completion? Elapsed is accurate. :-) I mean, a user can mentally roughly estimate the remaining time using the elapsed time and the progress bar; but we avoid the "45 minutes, 25 minutes, 55 minutes" effect. And if the progress bar is completely unreliable as a time-related axis, why is it there? Only to show that the process is running? A simple scrolling list of packages as they're installed would be better, then. BTW, using the size of the packages as input for the progress bar appears inappropriate to me in recent Fedora versions as the big part of the elapsed time is taken by install scripts, not by the file copying. I tried a simple experiment on my Fedora 8: $ rpm -qa|wc -l 2458 $ rpm -qa --scripts >/tmp/all_scripts $ grep -c ldconfig /tmp/all_scripts 1348 $ grep -c gtk-update-icon-cache /tmp/all_scripts 436 $ grep -c update-desktop-database /tmp/all_scripts 165 $ grep -c fc-cache /tmp/all_scripts 144 The installation time, expecially when upgrading (many packages, more fragmentation) is becoming too long. Executing more than 1000 times something which finds all the libs in the system can't be totally right. On modern machines the disk cache helps a lot, so everything becomes CPU bound, and then fast CPUs also help. At that point the bottleneck becomes the RPM DB transaction stuff (tons of fsync()?), expecially in the last phase of the process which seems to take forever. On older laptops (512MB, slow disk) the cache is ineffective and the disk goes crazy. I have no idea how this can be solved, but I still want to raise this as an issue, it is getting bad. Best regards. -- Roberto Ragusa mail at robertoragusa.it From debarshi.ray at gmail.com Sun May 25 12:10:33 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Sun, 25 May 2008 17:40:33 +0530 Subject: Need some help with Anjuta 2.4.1 Message-ID: <3170f42f0805250510h5569b865qb04b1902e57e8463@mail.gmail.com> I am in the process of updating Anjuta to 2.4.1 from 2.2.3 for Fedora 9 and Rawhide. The relevant patch, SPEC and source tarball are in CVS. However, rpmlint is spewing a large number of errors and warnings which generally look spurious to me. Could someone could throw an eye on it and comment? Happy hacking, Debarshi -- "From what we get, we can make a living; what we give, however, makes a life." -- Arthur Ashe From christoph.wickert at googlemail.com Sun May 25 13:15:02 2008 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Sun, 25 May 2008 15:15:02 +0200 Subject: Xfce SIG meeting! In-Reply-To: <20080523162955.7677c1a3@ohm.scrye.com> References: <20080523162955.7677c1a3@ohm.scrye.com> Message-ID: <1211721302.3386.8.camel@wicktop.localdomain> Am Freitag, den 23.05.2008, 16:29 -0600 schrieb Kevin Fenzi: > Greetings. > > We would like to try and get together interested folks for the first > Xfce SIG meeting, sometime next week on irc.freenode.net in the > #fedora-meeting channel. > > Please see: > http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel > for when available times are for the #fedora-meeting channel. > > If interested parties could mail me their preferred times for meeting, > I can schedule a meeting time for next week. For me every free slot between 20.00-23.00 UTC should be okay, not sure if this suitable for others, so I'm open to more suggestions. > Note that I will be out on > vacation next week, but should have net and be able to meet anyhow. I will be attending Linuxtag at Berlin next week, so my time and net access is limited. I think I should be able to do it in the evenings, otherwise is suggest we start a week later. Christoph From lsof at nodata.co.uk Sun May 25 13:18:56 2008 From: lsof at nodata.co.uk (nodata) Date: Sun, 25 May 2008 15:18:56 +0200 Subject: F9 installation screenshot In-Reply-To: <1209461368.9484.127.camel@localhost.localdomain> References: <4816E76F.50308@gmail.com> <1209461368.9484.127.camel@localhost.localdomain> Message-ID: <1211721536.3665.0.camel@sb-home> Am Dienstag, den 29.04.2008, 11:29 +0200 schrieb Lubomir Kundrak: > On Tue, 2008-04-29 at 14:46 +0530, Amitakhya Phukan wrote: > > hi! > > > > i managed to take a screenshot while updating my F8 to F9 rawhide. i > > chose "upgrade existing installation". everything was smooth. but there > > was this progress bar movement that really surprised me. it said it had > > to update 915 packages. at 496 packages, isn't it more than 50% complete > > ? the progress bar however is at far less than 50%. is that expected > > behaviour ? why ?? > > I guess it takes sizes of packages into account. > > > i am attaching a pic i took from my mobile :) . people pls pardon me for > > the tilted image i had to take. i couldn't get it properly done with my > > mobile. sos sorry for that. > > This is not a good idea. Imagine how much much mail traffic do you > generate with that, given how many people are subscribed to the list. > Also, many people use text-only e-mail clients. > > A better idea would be to make the image accessible via web possibly > using service such as http://imageshack.us/ and post just a link. If the list shouldn't accept attachments like this, the list shouldn't allow them. > > Thanks, > -- > Lubomir Kundrak (Red Hat Security Response Team) > From billcrawford1970 at gmail.com Sun May 25 14:28:58 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Sun, 25 May 2008 15:28:58 +0100 Subject: upstart plans for F10+ In-Reply-To: <20080522200445.GA24822@nostromo.devel.redhat.com> References: <20080522200445.GA24822@nostromo.devel.redhat.com> Message-ID: <200805251528.59505.billcrawford1970@googlemail.com> On Thursday 22 May 2008 21:04:45 Bill Nottingham wrote: > - Potentially splitting some of rc.sysinit into multiple events. > Not sure this buys us much, as right now the flow is *extremely* > sequential (start_udev -> fsck -> remount r/w -> clean out /tmp) Here's one pet peeve of mine (and it's not upstart-specific): why can't udev be made a "real" service that can be shut down or reloaded / restarted via a "service udev restart" method? From bernie at codewiz.org Sun May 25 14:32:46 2008 From: bernie at codewiz.org (Bernie Innocenti) Date: Sun, 25 May 2008 16:32:46 +0200 Subject: ctrlproxy-3.0.6 Message-ID: <4839788E.3030303@codewiz.org> Ciao, I updated ctrlproxy to 3.0.6, and the resulting packages are here: http://www.codewiz.org/pub/fedora/pkgs/ Patch follows. Can I commit it to CVS? diff -u -p -r1.15 ctrlproxy.spec --- ctrlproxy.spec 19 Feb 2008 07:31:45 -0000 1.15 +++ ctrlproxy.spec 25 May 2008 14:25:14 -0000 @@ -1,12 +1,18 @@ +%define ctrlproxy_homedir %{_var}/lib/ctrlproxy +%define ctrlproxy_logdir %{_var}/log/irc +%define ctrlproxy_service ctrlproxy +%define ctrlproxy_user ctrlproxy + Summary: ctrlproxy Name: ctrlproxy -Version: 3.0.5 -Release: 2%{?dist} +Version: 3.0.6 +Release: 1%{?dist} License: GPLv2+ Group: Applications/Internet Source: http://jelmer.vernstok.nl/releases/ctrlproxy-%{version}.tar.gz Url: http://jelmer.vernstok.nl/ctrlproxy/ -Patch0: ctrlproxy-fix-ansi-build.patch +Source100: ctrlproxy.init +Source101: ctrlproxy.config BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) BuildRequires: glib2-devel, popt, gnutls-devel @@ -31,7 +37,6 @@ ctrlproxy development headers %prep %setup -q -%patch0 -p1 %build %configure @@ -45,6 +50,23 @@ mkdir $RPM_BUILD_ROOT make DESTDIR=$RPM_BUILD_ROOT install make DESTDIR=$RPM_BUILD_ROOT -C doc install chmod 0644 ${RPM_BUILD_ROOT}%{_datadir}/ctrlproxy/motd +install -D -m 0755 %{SOURCE100} $RPM_BUILD_ROOT/%{_sysconfdir}/init.d/ctrlproxy +install -D -m 0640 %{SOURCE101} $RPM_BUILD_ROOT/%{ctrlproxy_homedir}/config +install -D -d -m 0750 $RPM_BUILD_ROOT/%{ctrlproxy_logdir} + + +%pre +/usr/sbin/useradd -s /sbin/nologin -M -r -d %{ctrlproxy_homedir} \ + -c "ctrlproxy IRC daemon" %{ctrlproxy_user} &>/dev/null || : + +%post +/sbin/chkconfig --add %{ctrlproxy_service} + +%preun +if [ $1 = 0 ]; then + /sbin/service %{ctrlproxy_service} stop > /dev/null 2>&1 || : + /sbin/chkconfig --del %{ctrlproxy_service} +fi %clean [ -d "$RPM_BUILD_ROOT" -a "$RPM_BUILD_ROOT" != "/" ] && rm -rf $RPM_BUILD_ROOT @@ -59,12 +81,24 @@ chmod 0644 ${RPM_BUILD_ROOT}%{_datadir}/ %dir %{_docdir}/ctrlproxy %{_docdir}/ctrlproxy/* +%{_sysconfdir}/init.d/ctrlproxy +%attr(0750, ctrlproxy, ctrlproxy) %dir %{ctrlproxy_logdir} +%attr(0750, ctrlproxy, ctrlproxy) %dir %{ctrlproxy_homedir} +%attr(0750, ctrlproxy, ctrlproxy) %config(noreplace) %{ctrlproxy_homedir}/config + + %files devel %defattr(-,root,root) %{_includedir}/ctrlproxy-3.0/* %{_libdir}/pkgconfig/ctrlproxy.pc %changelog +* Sun May 25 2008 Bernardo Innocenti 3.0.6-1 +- Update to latest upstream +- Drop ctrlproxy-fix-irssi-log.patch +- Add initscript +- Create a ctrlproxy user to run ctrlproxy as a daemon + * Tue Feb 19 2008 Fedora Release Engineering - 3.0.5-2 - Autorebuild for GCC 4.3 -- \___/ _| X | Bernie Innocenti - http://www.codewiz.org/ \|_O_| "It's an education project, not a laptop project!" From wtogami at redhat.com Sun May 25 15:20:08 2008 From: wtogami at redhat.com (Warren Togami) Date: Sun, 25 May 2008 11:20:08 -0400 Subject: X Keyboard layout problem In-Reply-To: References: Message-ID: <483983A8.2030809@redhat.com> I think xorg.conf should be optional. The default no xorg.conf should be able to handle simpler options overlayed on top of the autoconfiguration. Keyboard layout and resolution should be overridable. Extra fonts should be detected automatically (you need xorg.conf options for this? huh?) Dual screen might be a legitimate case where you need your own xorg.conf. Warren Togami wtogami at redhat.com Bond, Darryl wrote: > I think we need to be able to generate a special xorg.conf. > What if we need a lower/higher resolution than the one the auto configurator determines. > > My site (with 300 LTSP clients) has lots of special needs in the xorg.conf, ie resolution, extra fonts, dual screen etc. > > Xrandr may be the way to handle resolution after the X server starts. > > Darryl > > > -----Original Message----- > From: k12linux-devel-list-bounces at redhat.com [mailto:k12linux-devel-list-bounces at redhat.com] On Behalf Of Warren Togami > Sent: Sunday, 25 May 2008 1:29 PM > To: k12linux-devel-list at redhat.com; Development discussions related to Fedora Core > Subject: X Keyboard layout problem > > > https://bugzilla.redhat.com/show_bug.cgi?id=448196 > This is a critical problem for anybody using a non-US keyboard layout with LTSP. > > LTSP on Debian uses ltsp-trunk/client/configure-x.sh to generate an xorg.conf and mangle it to use an explicit keyboard layout before running the actual X. > > Fedora LTSP uses X autoconfiguration without an xorg.conf. This seems to be working extremely well, except for cases like this where we need a specific configuration option that differs from the X autoconfiguration. > > Any ideas of what we can do? > > Warren Togami > wtogami at redhat.com > > _______________________________________________ > K12Linux-devel-list mailing list > K12Linux-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/k12linux-devel-list > > The contents of this electronic message and any attachments are intended only for the addressee and may contain legally privileged, personal, sensitive or confidential information. If you are not the intended addressee, and have received this email, any transmission, distribution, downloading, printing or photocopying of the contents of this message or attachments is strictly prohibited. Any legal privilege or confidentiality attached to this message and attachments is not waived, lost or destroyed by reason of delivery to any person other than intended addressee. If you have received this message and are not the intended addressee you should notify the sender by return email and destroy all copies of the message and any attachments. Unless expressly attributed, the views expressed in this email do not necessarily represent the views of the company. > > _______________________________________________ > K12Linux-devel-list mailing list > K12Linux-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/k12linux-devel-list From loupgaroublond at gmail.com Sun May 25 16:45:33 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Sun, 25 May 2008 12:45:33 -0400 Subject: Notice of awayness Message-ID: <7f692fec0805250945y35b61d41y13ad59a622072a@mail.gmail.com> Hi lists, I'm probably not important enough that it warrants a full message, but this is to inform you that I will be out of touch from May 26th 2008 through May 31st 2008. I will have limited access to internet and email, and will be busy interacting with people in meatspace anyways. If there are any major problems with Smolt, or anything else that requires my attention, the best person to reach is probably Mike McGrath. -Yaakov From jaroslav at aster.pl Sun May 25 17:17:59 2008 From: jaroslav at aster.pl (=?utf-8?q?Jaros=C5=82aw_G=C3=B3rny?=) Date: Sun, 25 May 2008 19:17:59 +0200 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080522065724.1788e577@vader.jdub.homelinux.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> Message-ID: <200805251917.59913.jaroslav@aster.pl> Hi, Thursday 22 of May 2008 13:57:24 Josh Boyer napisa?(a): > Let the naming begin! We're starting very early this time around in > the name game for F10. So, let the suggestions flow! > > Remember the rules: > > 1) must have some link to Sulphur > > More specifically, the link should be > Sulphur is a and > is a > Where is the same for both what about Yellowstone :) yulphur is yellow, yellowstone is yellow regards, -- jg From jwboyer at gmail.com Sun May 25 17:29:25 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Sun, 25 May 2008 12:29:25 -0500 Subject: ctrlproxy-3.0.6 In-Reply-To: <4839788E.3030303@codewiz.org> References: <4839788E.3030303@codewiz.org> Message-ID: <20080525122925.19aa934a@vader.jdub.homelinux.org> On Sun, 25 May 2008 16:32:46 +0200 Bernie Innocenti wrote: > Ciao, > > I updated ctrlproxy to 3.0.6, and the resulting packages are here: > http://www.codewiz.org/pub/fedora/pkgs/ > > Patch follows. Can I commit it to CVS? Sure. Would you like to own the package outright? I've little time to maintain it these days, and you seem both interested and capable. josh From vonbrand at inf.utfsm.cl Sun May 25 17:30:15 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sun, 25 May 2008 13:30:15 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <200805251917.59913.jaroslav@aster.pl> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <200805251917.59913.jaroslav@aster.pl> Message-ID: <200805251730.m4PHUGOv019049@laptop13.inf.utfsm.cl> Jaros??aw G??rny wrote: > Thursday 22 of May 2008 13:57:24 Josh Boyer napisa??(a): > > Let the naming begin! We're starting very early this time around in > > the name game for F10. So, let the suggestions flow! > > > > Remember the rules: > > > > 1) must have some link to Sulphur > > > > More specifically, the link should be > > Sulphur is a and > > is a > > Where is the same for both > > what about Yellowstone :) > > yulphur is yellow, > yellowstone is yellow Nope. "Sulphur" is a "yellow stone". ;-) -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From dwmw2 at infradead.org Sun May 25 17:50:27 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 25 May 2008 18:50:27 +0100 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> <1211405127.21380.382.camel@pmac.infradead.org> <1211444657.21380.424.camel@pmac.infradead.org> <20080522183614.GB32314@redhat.com> <1211528761.21380.481.camel@pmac.infradead.org> <1211563622.28967.60.camel@pmac.infradead.org> Message-ID: <1211737827.31212.139.camel@shinybook.infradead.org> On Fri, 2008-05-23 at 16:00 -0300, Alexandre Oliva wrote: > Understood. > > I see one of your patches simply renames a .h to a .c and makes the > blob a built-in firmware. > > Any reason to not have moved it to the firmware/ dir, as I expected > from looking at your patches? OK, this is now done, posted to lkml and in the git tree. You (or your minions) can now set about converting all the existing users of 'blobs' to use request_firmware() for them, as I've demonstrated for the korg1212 driver. I can give accounts on git.infradead.org for people to put up git trees. Would be good if someone would do the ACPI 'Custom DSDT' support too... -- dwmw2 From bernie at codewiz.org Sun May 25 18:05:34 2008 From: bernie at codewiz.org (Bernie Innocenti) Date: Sun, 25 May 2008 20:05:34 +0200 Subject: ctrlproxy-3.0.6 In-Reply-To: <20080525122925.19aa934a@vader.jdub.homelinux.org> References: <4839788E.3030303@codewiz.org> <20080525122925.19aa934a@vader.jdub.homelinux.org> Message-ID: <4839AA6E.4090002@codewiz.org> Josh Boyer wrote: > Bernie Innocenti wrote: >> Patch follows. Can I commit it to CVS? > > Sure. Would you like to own the package outright? I've little time > to maintain it these days, and you seem both interested and capable. Ok, thanks. I don't mind co-owning it with others. I will commit with the change suggested by Hans Ulrich Niedermann. -- \___/ _| X | Bernie Innocenti - http://www.codewiz.org/ \|_O_| "It's an education project, not a laptop project!" From gene at czarc.net Sun May 25 18:56:07 2008 From: gene at czarc.net (Gene Czarcinski) Date: Sun, 25 May 2008 14:56:07 -0400 Subject: ntfs-3g and ntfsprogs Message-ID: <200805251456.08119.gene@czarc.net> What are the near term plans for ntfs-3g and ntfsprogs? I am specifically thinking of the F10/F11 time frame (the next year). I assume that the long term plan (goal) is to have a single package which does everything "right" which is currently done by the combination of ntfs-3g and ntfsprogs. My understanding (it may be incorrect) is that ntfs-3g is a fork of ntfsprogs and was forked because ntfsprogs was not moving quickly enough to supported needed functionality (e.g., full, reliable read/write support). Well, ntfsprogs has now been updated (version 2.0) to provide the functionality in ntfs-3g and this is the version in F9 (F8 still has the old ntfsprogs). Will ntfs-3g be dropped in F10 or F11? If ntfs-3g is dropped, will ntfsprogs packaging do anything to provide easy compatibility (e.g., library symlinks). If ntfsprogs now provides the needed functionality and reliability, then I assume that all software under current maintenance/development which needs ntfs support should be using ntfsprogs. Correct?? Gene From drago01 at gmail.com Sun May 25 19:07:52 2008 From: drago01 at gmail.com (drago01) Date: Sun, 25 May 2008 21:07:52 +0200 Subject: ntfs-3g and ntfsprogs In-Reply-To: <200805251456.08119.gene@czarc.net> References: <200805251456.08119.gene@czarc.net> Message-ID: well no .. you are wrong. ntfs-3g is a filesystem driver while ntfsprogs are tools to manage/create ntfs volumes. you are confusing ntfsprogs with in kernel ntfs driver ... which was never built in fedora/redhat kernels anyway. From j.w.r.degoede at hhs.nl Sun May 25 19:42:47 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 25 May 2008 21:42:47 +0200 Subject: Review swapsies Message-ID: <4839C137.7090307@hhs.nl> Hi All, Is the time of the week again when I've got a couple of new packages which are in need of review, as always I'm willing to review any package in return: * elice - Elice is a PureBasic to c++ translator / compiler https://bugzilla.redhat.com/show_bug.cgi?id=448310 * lostlabyrinth - Lost Labyrinth is a coffeebreak dungeon crawling game https://bugzilla.redhat.com/show_bug.cgi?id=448311 * lostlabyrinth-sounds - Lost Labyrinth sounds https://bugzilla.redhat.com/show_bug.cgi?id=448312 * lostlabyrinth-graphics - Lost Labyrinth graphics https://bugzilla.redhat.com/show_bug.cgi?id=448313 Thanks & Regards, Hans From gene at czarc.net Sun May 25 20:10:39 2008 From: gene at czarc.net (Gene Czarcinski) Date: Sun, 25 May 2008 16:10:39 -0400 Subject: ntfs-3g and ntfsprogs In-Reply-To: References: <200805251456.08119.gene@czarc.net> Message-ID: <200805251610.39596.gene@czarc.net> On Sunday 25 May 2008 15:07:52 drago01 wrote: > well no .. you are wrong. > ntfs-3g is a filesystem driver while ntfsprogs are tools to > manage/create ntfs volumes. > you are confusing ntfsprogs with in kernel ntfs driver ... which was > never built in fedora/redhat kernels anyway. I believe you are correct for distributions before Fedora 9. Fedora 9 includes ntfsprogs-2.0.0. If you do "rpm -ql" for ntfsprogs and ntfsprogs-devel, you will see libraries and include files to support software development. You might also look at the output of "rpm -q --provides" and "rpm -q --whatrequires" for the ntfs-3g and ntfsprogs packages (or do repoquery which may be better). Yes, ntfsprogs has utilities which are not in ntfs-3g but (with 2.0.0), they also claim to have functionality and reliability to equal or exceed that in ntfs-3g. See the ntfsprogs website http://www.linux-ntfs.org/ Now granted, 2.0.0 of ntfsprogs was recently released may have some bugs or undesirable "features", so it may be prudent to keep ntfs-3g around for a while. But, Fedora is, in many ways, a "bleeding edge" distribution. Bugs will not be found and fixed unless someone uses the software. I assume (mmmm ... I need to check this) that the utilities in ntfsprogs such as ntfsclone and ntfsresize use the libraries which are part of ntfsprogs rather than those in ntfs-3g. [checked: rpm and repoquery show no dependency between ntfs-3g and ntfsprogs] I was a little surprised that there was no mention in the F9 Release Notes (just that anaconda now supported ntfs partition resizing). But, on the other hand, there is not much (except anaconda and qtparted) which really requires the new ntfsprogs and developers (rightly) are more interested in the linux packages. BTW, I find it convenient to have ntfsclone and ntfsresize on the F9 RescueCD (also called the network install cd). ntfsclone together with "nc" and "ssh" provide a convenient way to backup an ntfs partition onto server storage (what else is large enough these days). Gene From optimizationkit at gmail.com Sun May 25 20:26:35 2008 From: optimizationkit at gmail.com (M) Date: Sun, 25 May 2008 22:26:35 +0200 Subject: Review swapsies In-Reply-To: <4839C137.7090307@hhs.nl> References: <4839C137.7090307@hhs.nl> Message-ID: <58a220fa0805251326n289a8e9scc8191c91df1ae9e@mail.gmail.com> Hi, 2008/5/25 Hans de Goede : > Hi All, > > Is the time of the week again when I've got a couple of new packages which > are in need of review, as always I'm willing to review any package in > return: I'm not a Fedora developer, so my review might be useless > > * elice - Elice is a PureBasic to c++ translator / compiler > https://bugzilla.redhat.com/show_bug.cgi?id=448310 > > * lostlabyrinth - Lost Labyrinth is a coffeebreak dungeon crawling game > https://bugzilla.redhat.com/show_bug.cgi?id=448311 > > * lostlabyrinth-sounds - Lost Labyrinth sounds > https://bugzilla.redhat.com/show_bug.cgi?id=448312 > > * lostlabyrinth-graphics - Lost Labyrinth graphics > https://bugzilla.redhat.com/show_bug.cgi?id=448313 I have no problems installing these packages. When I run "lostlabyrinth" I see a black screen, when I run lostlabyrinth.bin I see this bug http://www.stardust.webpages.pl/files/bug.png > > Thanks & Regards, > > Hans Regards, Michal From sundaram at fedoraproject.org Sun May 25 20:32:13 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 26 May 2008 02:02:13 +0530 Subject: Review swapsies In-Reply-To: <58a220fa0805251326n289a8e9scc8191c91df1ae9e@mail.gmail.com> References: <4839C137.7090307@hhs.nl> <58a220fa0805251326n289a8e9scc8191c91df1ae9e@mail.gmail.com> Message-ID: <4839CCCD.9010507@fedoraproject.org> M wrote: > Hi, > > 2008/5/25 Hans de Goede : >> Hi All, >> >> Is the time of the week again when I've got a couple of new packages which >> are in need of review, as always I'm willing to review any package in >> return: > > I'm not a Fedora developer, so my review might be useless Everybody can do informal reviews. Refer to http://fedoraproject.org/wiki/Packaging/ReviewGuidelines Rahul From seandarcy2 at gmail.com Sun May 25 20:47:39 2008 From: seandarcy2 at gmail.com (sean darcy) Date: Sun, 25 May 2008 16:47:39 -0400 Subject: 2.6.26-0.25.rc3.git4 or VirtualBox ? Message-ID: I'm using VirtualBox to run rawhide. kernel-2.6.26-0.25.rc3.git4.fc10.i686 locks up hard with: unable to handle kernel NULL pointer dereference at 00000246 2.6.25.3-18 works fine. Does anyone else see this, or is it VirtualBox? sean From j.w.r.degoede at hhs.nl Sun May 25 20:53:28 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 25 May 2008 22:53:28 +0200 Subject: Review swapsies In-Reply-To: <58a220fa0805251326n289a8e9scc8191c91df1ae9e@mail.gmail.com> References: <4839C137.7090307@hhs.nl> <58a220fa0805251326n289a8e9scc8191c91df1ae9e@mail.gmail.com> Message-ID: <4839D1C8.4010902@hhs.nl> M wrote: > Hi, > > 2008/5/25 Hans de Goede : >> Hi All, >> >> Is the time of the week again when I've got a couple of new packages which >> are in need of review, as always I'm willing to review any package in >> return: > > I'm not a Fedora developer, so my review might be useless > >> * elice - Elice is a PureBasic to c++ translator / compiler >> https://bugzilla.redhat.com/show_bug.cgi?id=448310 >> >> * lostlabyrinth - Lost Labyrinth is a coffeebreak dungeon crawling game >> https://bugzilla.redhat.com/show_bug.cgi?id=448311 >> >> * lostlabyrinth-sounds - Lost Labyrinth sounds >> https://bugzilla.redhat.com/show_bug.cgi?id=448312 >> >> * lostlabyrinth-graphics - Lost Labyrinth graphics >> https://bugzilla.redhat.com/show_bug.cgi?id=448313 > > I have no problems installing these packages. > > When I run "lostlabyrinth" I see a black screen, when I run > lostlabyrinth.bin I see this bug > http://www.stardust.webpages.pl/files/bug.png > The bug when directly launching lostlabyrinth.bin is normal, the black screen when launching is not normal, are you seeing any messages to the terminal? Regards, Hans From lordmorgul at gmail.com Sun May 25 21:02:29 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Sun, 25 May 2008 14:02:29 -0700 Subject: F9 installation screenshot In-Reply-To: <1209588047.29552.37.camel@rousalka.okg> References: <8990327d0804290423o6bef20c0g8ab07576ea81068@mail.gmail.com> <20080429121439.GN27333@localhost.localdomain> <8990327d0804290558k5f32d775ic9ddd24b164f4744@mail.gmail.com> <8990327d0804290600x12482214s97fc57b14098f3be@mail.gmail.com> <1209481464.18191.6.camel@gibraltar.str.redhat.com> <20080429154009.GR26399@inocybe.teonanacatl.org> <1209506979.22831.121.camel@aglarond.local> <20080430025732.GV26399@inocybe.teonanacatl.org> <28979.192.54.193.59.1209541945.squirrel@rousalka.dyndns.org> <1209585473.4950.79.camel@localhost> <1209588047.29552.37.camel@rousalka.okg> Message-ID: <4839D3E5.5040205@gmail.com> Nicolas Mailhot wrote: > ?Smart international organisations have nothing to win in draping > themselves in American symbols and imagery (or Chinese symbols and > imagery or French symbols and imagery, etc). You win hearth by > emphasising your local presence and if you can't do it you better > project a bland and neutral image. It is not difficult whatsoever for imagery to be turned off for installations in locales the image train is not designed for. Culturally sensitive/relevant imagery can be used in some locales and just a simple progress bar installer can be shown for others. It doesn't have to be all or nothing. -- Andrew Farris www.lordmorgul.net gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29 From optimizationkit at gmail.com Sun May 25 21:11:41 2008 From: optimizationkit at gmail.com (M) Date: Sun, 25 May 2008 23:11:41 +0200 Subject: Review swapsies In-Reply-To: <4839D1C8.4010902@hhs.nl> References: <4839C137.7090307@hhs.nl> <58a220fa0805251326n289a8e9scc8191c91df1ae9e@mail.gmail.com> <4839D1C8.4010902@hhs.nl> Message-ID: <58a220fa0805251411t1c3e39afj1be46d260a22cd57@mail.gmail.com> 2008/5/25 Hans de Goede : > M wrote: >> >> Hi, >> >> 2008/5/25 Hans de Goede : >>> >>> Hi All, >>> >>> Is the time of the week again when I've got a couple of new packages >>> which >>> are in need of review, as always I'm willing to review any package in >>> return: >> >> I'm not a Fedora developer, so my review might be useless >> >>> * elice - Elice is a PureBasic to c++ translator / compiler >>> https://bugzilla.redhat.com/show_bug.cgi?id=448310 >>> >>> * lostlabyrinth - Lost Labyrinth is a coffeebreak dungeon crawling game >>> https://bugzilla.redhat.com/show_bug.cgi?id=448311 >>> >>> * lostlabyrinth-sounds - Lost Labyrinth sounds >>> https://bugzilla.redhat.com/show_bug.cgi?id=448312 >>> >>> * lostlabyrinth-graphics - Lost Labyrinth graphics >>> https://bugzilla.redhat.com/show_bug.cgi?id=448313 >> >> I have no problems installing these packages. >> >> When I run "lostlabyrinth" I see a black screen, when I run >> lostlabyrinth.bin I see this bug >> http://www.stardust.webpages.pl/files/bug.png >> > > The bug when directly launching lostlabyrinth.bin is normal, the black > screen when launching is not normal, are you seeing any messages to the > terminal? I restarted X and now game run without any problem. Strange, because before I had to restart X.org twice. > > Regards, > > Hans Regards, Michal From optimizationkit at gmail.com Sun May 25 21:18:12 2008 From: optimizationkit at gmail.com (M) Date: Sun, 25 May 2008 23:18:12 +0200 Subject: Review swapsies In-Reply-To: <58a220fa0805251411t1c3e39afj1be46d260a22cd57@mail.gmail.com> References: <4839C137.7090307@hhs.nl> <58a220fa0805251326n289a8e9scc8191c91df1ae9e@mail.gmail.com> <4839D1C8.4010902@hhs.nl> <58a220fa0805251411t1c3e39afj1be46d260a22cd57@mail.gmail.com> Message-ID: <58a220fa0805251418g7339c242x10ff6357cb092722@mail.gmail.com> 2008/5/25 M : > 2008/5/25 Hans de Goede : >> M wrote: >>> >>> Hi, >>> >>> 2008/5/25 Hans de Goede : >>>> >>>> Hi All, >>>> >>>> Is the time of the week again when I've got a couple of new packages >>>> which >>>> are in need of review, as always I'm willing to review any package in >>>> return: >>> >>> I'm not a Fedora developer, so my review might be useless >>> >>>> * elice - Elice is a PureBasic to c++ translator / compiler >>>> https://bugzilla.redhat.com/show_bug.cgi?id=448310 >>>> >>>> * lostlabyrinth - Lost Labyrinth is a coffeebreak dungeon crawling game >>>> https://bugzilla.redhat.com/show_bug.cgi?id=448311 >>>> >>>> * lostlabyrinth-sounds - Lost Labyrinth sounds >>>> https://bugzilla.redhat.com/show_bug.cgi?id=448312 >>>> >>>> * lostlabyrinth-graphics - Lost Labyrinth graphics >>>> https://bugzilla.redhat.com/show_bug.cgi?id=448313 >>> >>> I have no problems installing these packages. >>> >>> When I run "lostlabyrinth" I see a black screen, when I run >>> lostlabyrinth.bin I see this bug >>> http://www.stardust.webpages.pl/files/bug.png >>> >> >> The bug when directly launching lostlabyrinth.bin is normal, the black >> screen when launching is not normal, are you seeing any messages to the >> terminal? > > I restarted X and now game run without any problem. Strange, because > before I had to restart X.org twice. It might be a problem with kernel, I have some klauncher[3602]: segfault at 8048814 ip 00724da8 sp bffc0f10 error 7 in libX11.so.6.2.0[70f000+fd000] tomboy[31729]: segfault at b6f1c548 ip b6f1c548 sp bfc34b3c error 4 in libbreakpad.so.0.0.0[b6f29000+50000] in logs Regards, M. From naheemzaffar at gmail.com Sun May 25 21:51:06 2008 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Sun, 25 May 2008 22:51:06 +0100 Subject: ntfs-3g and ntfsprogs In-Reply-To: <200805251610.39596.gene@czarc.net> References: <200805251456.08119.gene@czarc.net> <200805251610.39596.gene@czarc.net> Message-ID: <3adc77210805251451m4cba4931v698467bd5848b5d0@mail.gmail.com> Did a small amount of digging and found this topic: http://forum.linux-ntfs.org/viewtopic.php?t=741 Apparently ntfsprogs and ntfs-3g are fully competitive - ntfsprogs gained read/write support, ntfs-3g got the extra utilities that were a part of ntfsprogs. >From that topic what I see the main differences is that ntfsprogs claim to be faster. ntfs-3g claims ntfsprogs is buggy. From dgboles at gmail.com Sun May 25 22:27:37 2008 From: dgboles at gmail.com (David Boles) Date: Sun, 25 May 2008 18:27:37 -0400 Subject: 2.6.26-0.25.rc3.git4 or VirtualBox ? In-Reply-To: References: Message-ID: <4839E7D9.6060904@gmail.com> sean darcy wrote: > I'm using VirtualBox to run rawhide. > > kernel-2.6.26-0.25.rc3.git4.fc10.i686 locks up hard with: > > unable to handle kernel NULL pointer dereference at 00000246 > > 2.6.25.3-18 works fine. > > Does anyone else see this, or is it VirtualBox? > > sean > I see what is probably the same thing. -- David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From arjan at infradead.org Sun May 25 22:46:44 2008 From: arjan at infradead.org (Arjan van de Ven) Date: Sun, 25 May 2008 15:46:44 -0700 Subject: 2.6.26-0.25.rc3.git4 or VirtualBox ? In-Reply-To: References: Message-ID: <20080525154644.359c90b4@infradead.org> On Sun, 25 May 2008 16:47:39 -0400 sean darcy wrote: > I'm using VirtualBox to run rawhide. > > kernel-2.6.26-0.25.rc3.git4.fc10.i686 locks up hard with: > > unable to handle kernel NULL pointer dereference at 00000246 > > 2.6.25.3-18 works fine. I wouldn't call it "fine"; VirtualBox is one of the top causes of kernel oopses that we're seeing on Linux right now... I'm not surprised it's not working well with 2.6.26 either. From stlwrt at gmail.com Sun May 25 23:36:16 2008 From: stlwrt at gmail.com (Pavel Shevchuk) Date: Mon, 26 May 2008 02:36:16 +0300 Subject: 2.6.26-0.25.rc3.git4 or VirtualBox ? In-Reply-To: References: Message-ID: After Sun bought Innotek i can't wait for xen dom0 kernel availability in fedora9. For me vbox is dead =( On 5/25/08, sean darcy wrote: > I'm using VirtualBox to run rawhide. > > kernel-2.6.26-0.25.rc3.git4.fc10.i686 locks up hard with: > > unable to handle kernel NULL pointer dereference at 00000246 > > 2.6.25.3-18 works fine. > > Does anyone else see this, or is it VirtualBox? > > sean > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- http://scwlab.com From seandarcy2 at gmail.com Mon May 26 01:26:09 2008 From: seandarcy2 at gmail.com (sean darcy) Date: Sun, 25 May 2008 21:26:09 -0400 Subject: 2.6.26-0.25.rc3.git4 or VirtualBox ? In-Reply-To: <20080525154644.359c90b4@infradead.org> References: <20080525154644.359c90b4@infradead.org> Message-ID: Arjan van de Ven wrote: > On Sun, 25 May 2008 16:47:39 -0400 > sean darcy wrote: > >> I'm using VirtualBox to run rawhide. >> >> kernel-2.6.26-0.25.rc3.git4.fc10.i686 locks up hard with: >> >> unable to handle kernel NULL pointer dereference at 00000246 >> >> 2.6.25.3-18 works fine. > > I wouldn't call it "fine"; > VirtualBox is one of the top causes of kernel oopses that we're seeing > on Linux right now... I'm not surprised it's not working well with > 2.6.26 either. > "fine" means it WFM. It does all I ask. I'm certainly not a vbox fanatic. In fact, I've only been using it for a couple of days. That's why I posted: is this a vbox problem, or a kernel issue. If no one else is seeing a hard lockup on bare metal, then it's vbox. AFAICS from the response, 1 guy sees the same lockup on bare metal, 2 don't like vbox. sean From szj087 at gmail.com Mon May 26 01:35:19 2008 From: szj087 at gmail.com (=?GB2312?B?y+/X2r79?=) Date: Mon, 26 May 2008 09:35:19 +0800 Subject: 2.6.26-0.25.rc3.git4 or VirtualBox ? In-Reply-To: References: <20080525154644.359c90b4@infradead.org> Message-ID: Hi, sean I am not an expert on Virtual box or kernel, but I know kernel-2.6.26-0.25.rc3.git4.fc10.i686 is for F10, I use virtualbox 1.6.0 on Fedora 9, it works fine realy. AFAIK virtual box only supports Fedora9 or older Fedora series now. F10 is not in the scope of consideration now since its Alpha version is not ready now. Thanks Zongjun 2008/5/26 sean darcy : > Arjan van de Ven wrote: >> >> On Sun, 25 May 2008 16:47:39 -0400 >> sean darcy wrote: >> >>> I'm using VirtualBox to run rawhide. >>> >>> kernel-2.6.26-0.25.rc3.git4.fc10.i686 locks up hard with: >>> >>> unable to handle kernel NULL pointer dereference at 00000246 >>> >>> 2.6.25.3-18 works fine. >> >> I wouldn't call it "fine"; >> VirtualBox is one of the top causes of kernel oopses that we're seeing >> on Linux right now... I'm not surprised it's not working well with >> 2.6.26 either. >> > > "fine" means it WFM. It does all I ask. > > I'm certainly not a vbox fanatic. In fact, I've only been using it for a > couple of days. That's why I posted: is this a vbox problem, or a kernel > issue. > > If no one else is seeing a hard lockup on bare metal, then it's vbox. AFAICS > from the response, 1 guy sees the same lockup on bare metal, 2 don't like > vbox. > > sean > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From tcallawa at redhat.com Mon May 26 03:36:49 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sun, 25 May 2008 23:36:49 -0400 Subject: ntfs-3g and ntfsprogs In-Reply-To: <200805251456.08119.gene@czarc.net> References: <200805251456.08119.gene@czarc.net> Message-ID: <1211773009.6251.3.camel@localhost.localdomain> On Sun, 2008-05-25 at 14:56 -0400, Gene Czarcinski wrote: > I assume that the long term plan (goal) is to have a single package > which does everything "right" which is currently done by the > combination of ntfs-3g and ntfsprogs. ntfsprogs is not really maintained these days, but it provides utilities that ntfs-3g does not intend to implement in the near term. Long term, it is probable that ntfs-3g will enable the same set of functionality that ntfsprogs does, but until then, we'll continue to leverage the best of both worlds. ~spot, maintainer for both ntfs-3g and ntfsprogs From tcallawa at redhat.com Mon May 26 03:39:49 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sun, 25 May 2008 23:39:49 -0400 Subject: ntfs-3g and ntfsprogs In-Reply-To: <200805251456.08119.gene@czarc.net> References: <200805251456.08119.gene@czarc.net> Message-ID: <1211773189.6251.6.camel@localhost.localdomain> Whoops, hit send too early, forgot to answer your questions. :) On Sun, 2008-05-25 at 14:56 -0400, Gene Czarcinski wrote: > Will ntfs-3g be dropped in F10 or F11? No (at least for F-10, I have no plans to drop it in F-11). > If ntfsprogs now provides the needed functionality and reliability, > then I assume that all software under current maintenance/development > which needs ntfs support should be using ntfsprogs. Correct?? Nope. ntfs-3g is primarily for mounting. Nothing is using its library/headers at this time (to the best of my knowledge). Not that there is anything wrong with them, they're just new. These two apps are really more complimentary than it might seem, but if anything, ntfs-3g is growing much faster and has a much more active community. ~spot From seg at haxxed.com Mon May 26 06:14:45 2008 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 26 May 2008 01:14:45 -0500 Subject: upstart plans for F10+ In-Reply-To: References: <20080522200445.GA24822@nostromo.devel.redhat.com> <20080522204407.GA30257@nostromo.devel.redhat.com> Message-ID: <1218b5bc0805252314q42b16ab4qf8b38f0f6242f352@mail.gmail.com> On Thu, May 22, 2008 at 5:13 PM, Colin Walters wrote: > On Thu, May 22, 2008 at 4:44 PM, Bill Nottingham > wrote: > > > > I mean, right now we have a static init script that runs once > > on boot to mount NFS, SMB, etc, and set up network block devices. > > It's also (in F9) kicked when NM brings up a new default route. > > > > What would be sane is to have it just mount things when it can > > reach the proper network, and lazily unmount them when that > > network goes away. > > The issue with this is that at least last time I checked, at least > some file systems like NFS basically don't handle the network going > away from underneath them; if you have any userspace processes > accessing them they'll be wedged unrecoverably in D state. I gave up > long ago on using kernel-based network filesystems on my laptop for > this reason. > It should be noted that anything using gnome-vfs, that is, most anything gnome, seems to like to happily stat every mounted filesystem constantly, often for no apparent reason, even if that app isn't even doing anything with that mount. This means your entire desktop locks the f-ck up if an NFS mount goes dead, gnome panel and all. It also seems to prevent automounts from ever timing out. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arjan at infradead.org Mon May 26 06:29:36 2008 From: arjan at infradead.org (Arjan van de Ven) Date: Sun, 25 May 2008 23:29:36 -0700 Subject: 2.6.26-0.25.rc3.git4 or VirtualBox ? In-Reply-To: References: <20080525154644.359c90b4@infradead.org> Message-ID: <20080525232936.09d6a4f5@infradead.org> On Sun, 25 May 2008 21:26:09 -0400 sean darcy wrote: > Arjan van de Ven wrote: > > On Sun, 25 May 2008 16:47:39 -0400 > > sean darcy wrote: > > > >> I'm using VirtualBox to run rawhide. > >> > >> kernel-2.6.26-0.25.rc3.git4.fc10.i686 locks up hard with: > >> > >> unable to handle kernel NULL pointer dereference at 00000246 > >> > >> 2.6.25.3-18 works fine. > > > > I wouldn't call it "fine"; > > VirtualBox is one of the top causes of kernel oopses that we're > > seeing on Linux right now... I'm not surprised it's not working > > well with 2.6.26 either. > > > > "fine" means it WFM. It does all I ask. > > I'm certainly not a vbox fanatic. In fact, I've only been using it > for a couple of days. That's why I posted: is this a vbox problem, or > a kernel issue. you're probably seeing: http://www.kerneloops.org/search.php?search=g_abExecMemory which a lot of other folks are seeing, so much so that this is in the top 15 of all kernel oopses/warnings reported in the last week. Given the backtrace and the high frequency of this thing, I'm pretty sure it's a VirtualBox bug. From rawhide at fedoraproject.org Mon May 26 09:46:39 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Mon, 26 May 2008 09:46:39 +0000 (UTC) Subject: rawhide report: 20080526 changes Message-ID: <20080526094640.2C6D4209CC4@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080523/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080526/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package clutter-cairo A basic Cairo clutter widget New package libuninum Library for converting unicode strings to numbers New package supybot Cross-platform IRC bot written in Python Updated Packages: banshee-0.99.2-2.fc10 --------------------- * Sat May 24 18:00:00 2008 Nigel Jones - 0.99.2-2 - Rebuild & correct BR * Fri May 23 18:00:00 2008 Nigel Jones - 0.99.2-1 - New Upstream Release (0.99.2) - Beta 2 - Enable podcast & boo cairo-dock-1.5.5.4-5.svn1033_trunk.fc10 --------------------------------------- * Sun May 25 18:00:00 2008 Mamoru Tasaka - svn 1033 cbrpager-0.9.17-2.fc10 ---------------------- * Mon May 26 18:00:00 2008 Mamoru Tasaka - 0.9.17-2 - Escape filename in zip file properly * Sat May 24 18:00:00 2008 Mamoru Tasaka - 0.9.17-1 - 0.9.17 - 2 patches dropped, upstream applied * Fri May 23 18:00:00 2008 Mamoru Tasaka - 0.9.16-2 - 0.9.16 - Properly handle file name (shell escaping issue) chess-1.0-15.fc10 ----------------- * Thu May 22 18:00:00 2008 Hans de Goede 1.0-15 - Rebuild for new cegui deluge-0.5.9.1-1.fc10 --------------------- * Fri May 23 18:00:00 2008 Peter Gordon - 0.5.9.1-1 - Update to new upstream release (0.5.9.1) e2fsprogs-1.40.10-1.fc10 ------------------------ * Fri May 23 18:00:00 2008 Eric Sandeen 1.40.10-1 - New upstream version eiciel-0.9.6.1-1.fc10 --------------------- * Sat May 24 18:00:00 2008 Chris Weyl 0.9.6.1-1 - update to 0.9.6.1 - patch system user/group bounds; primitive but works :) Should resolve RH#445667. - oh, and the nautlius extensions dir seems to have changed. Let's use what libnautilus-extensions.pc says is the right directory, instead of hardcoding it. * Mon Feb 18 17:00:00 2008 Fedora Release Engineering - 0.9.5-2 - Autorebuild for GCC 4.3 ejabberd-2.0.1-1.fc10 --------------------- * Sat May 24 18:00:00 2008 Peter Lemenkov 2.0.1-1 - Ver. 2.0.1 - Upstreamed patches dropped - No longer uses versioned libdir (/usr/lib/ejabberd-x.x.x) - Added sql-scripts in docs-directory * Mon May 5 18:00:00 2008 Peter Lemenkov 2.0.0-3 - Fix build against R11B-2 email2trac-0.13-3.fc10 ---------------------- * Fri May 23 18:00:00 2008 Jesse Keating - 0.13-3 - Add a patch to handle both X-Spam-Score and X-Spam-Level fedora-gnome-theme-8.0.0-2.fc10 ------------------------------- * Fri May 23 18:00:00 2008 Martin Sourada - 8.0.0-2 - Require gtk-nodoka-engine instead of nodoka-theme-gnome (bug 447644) flam3-2.7.12-2.fc10 ------------------- * Sun May 25 18:00:00 2008 Ian Weller 2.7.12-2 - Rebuild for new man pages * Sun May 25 18:00:00 2008 Ian Weller 2.7.12-1 - Upstream updated fmt-ptrn-1.3.17-2.fc10 ---------------------- * Sun May 25 18:00:00 2008 W. Michael Petullo - 1.3.17-2 - Fixed placement of %doc in RPM specification. gdal-1.5.1-9.fc10 ----------------- * Sun May 25 18:00:00 2008 Balint Cristian - 1.5.1-9 - enable ruby and java packages - fix spurious sed problem - spec file cosmetics * Fri May 23 18:00:00 2008 Balint Cristian - 1.5.1-8 - fix sincos on all arch glibc-2.8.90-5 -------------- * Sun May 25 18:00:00 2008 Jakub Jelinek 2.8.90-5 - update from trunk gmyth-0.7.1-5.fc10 ------------------ * Fri May 23 18:00:00 2008 - Bastien Nocera - 0.7.1-5 - Update gmyth-upnp to 0.7.1 gnokii-0.6.25-2.fc10 -------------------- * Fri May 23 18:00:00 2008 Robert Scheck 0.6.25-2 - Set empty --vendor rather none for using desktop-file-install - Fixed initscript as gnokii-smsd stays in /usr/bin not /usr/sbin gstreamer-plugins-base-0.10.19-4.fc10 ------------------------------------- * Sat May 24 18:00:00 2008 - Bastien Nocera - 0.10.19-4 - Remove the gnome-vfs plugin, and see what breaks * Wed May 21 18:00:00 2008 Tom "spot" Callaway - 0.10.19-3 - fix license tag * Fri Apr 18 18:00:00 2008 - Bastien Nocera - 0.10.19-2 - Add patch to avoid sync problems in the ALSA sink when a specific track has both playback and record flags gtk-sharp2-2.12.0-1.fc10 ------------------------ * Fri May 23 18:00:00 2008 Xavier Lamien - 2.12.0 - Updated Release. halevt-0.0.9-1.fc10 ------------------- * Sat May 24 18:00:00 2008 Patrice Dumas 0.0.9-1 - update to 0.0.9 hamster-applet-0.5-1.fc10 ------------------------- * Sun May 25 18:00:00 2008 Mads Villadsen - 0.5-1 - Update to latest upstream release - Preferences are now editable via user interface - Added option to stop tracking on shutdown - Current activity is now showing up in totals im-chooser-0.99.6-5.fc10 ------------------------ * Mon May 26 18:00:00 2008 Akira TAGOH - 0.99.6-5 - Fix a typo in the package group of imsettings-xfce. (#448037) java-1.6.0-openjdk-1.6.0.0-0.14.b09.fc10 ---------------------------------------- * Thu May 22 18:00:00 2008 Lillian Angel - 1:1.6.0.0-0.14.b09 - Added new patch java-1.6.0-openjdk-java-access-bridge-tck.patch. - Updated release. jd-2.0.0-0.5.svn2066_trunk.fc10 ------------------------------- * Sun May 25 18:00:00 2008 Mamoru Tasaka - 2.0.0-0.5.svn2066_trunk - Enable alsa * Sun May 25 18:00:00 2008 Mamoru Tasaka - svn trunk 2066 kdelibs-4.0.72-8.fc10 --------------------- * Sat May 24 18:00:00 2008 Rex Dieter - 4.0.72-8 - revert previous, don't include kde3-compat symlink (here, anyway) * Fri May 23 18:00:00 2008 Rex Dieter - 4.0.72-7 - -common: provide %_datadir/apps/kdeui for kde3 apps (#447965) kdelibs3-3.5.9-13.fc10 ---------------------- * Sat May 24 18:00:00 2008 Rex Dieter 3.5.9-13 - f9+: include kdeui symlink here + scriptlets to help rpm handle it * Fri May 23 18:00:00 2008 Rex Dieter 3.5.9-12 - f9+: omit %{_datadir}/apps/kdeui, use version from kdelibs-common (#447965) Broken deps for i386 ---------------------------------------------------------- LabPlot-1.5.1.6-4.fc8.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libMagick.so.10 avahi-ui-sharp-0.6.22-10.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 avahi-ui-sharp-0.6.22-10.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 basket-kontact-1.0.2-5.fc9.i386 requires libkpinterfaces.so.1 basket-kontact-1.0.2-5.fc9.i386 requires libkcal.so.2 basket-kontact-1.0.2-5.fc9.i386 requires libktnef.so.1 basket-kontact-1.0.2-5.fc9.i386 requires kdepim3 basket-kontact-1.0.2-5.fc9.i386 requires libkdepim.so.1 beagle-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-evolution-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-thunderbird-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 dsniff-2.4-0.2.b1.fc9.i386 requires libnids.so.1.21 evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-sharp-0.17.2-1.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.i386 requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-1.2.so.11 f-spot-0.4.3.1-1.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.i386 requires mono(glade-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gmime-sharp-2.2.19-1.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(atk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(glade-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(pango-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gsf-sharp-0.8.1-7.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.i386 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 ipod-sharp-0.8.0-4.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 ipod-sharp-0.8.0-4.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 ipod-sharp-0.8.0-4.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 kismet-extras-0.0.2007.10.R1-3.fc9.i386 requires libMagick.so.10 koffice-karbon-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-karbon-1.6.3-15.fc9.i386 requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libMagick.so.10 libopensync-plugin-kdepim-0.35-2.fc9.i386 requires libkcal.so.2 lsvpd-1.6.4-1.fc10.i386 requires libvpd_cxx-2.0.so.1 mono-addins-0.3.1-1.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 mono-addins-0.3.1-1.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 mono-addins-0.3.1-1.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 mono-addins-0.3.1-1.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.i386 requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.i386 requires libgeos.so.2 smart-0.52-54.fc9.i386 requires smart-config taskjuggler-2.4.1-1.fc10.i386 requires libkcal.so.2 taskjuggler-2.4.1-1.fc10.i386 requires libktnef.so.1 taskjuggler-libs-2.4.1-1.fc10.i386 requires libkcal.so.2 tomboy-0.10.1-2.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.i386 requires mono(pango-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 Broken deps for x86_64 ---------------------------------------------------------- LabPlot-1.5.1.6-4.fc8.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libMagick.so.10 LabPlot-1.5.1.6-4.fc8.x86_64 requires libMagick++.so.10()(64bit) LabPlot-1.5.1.6-4.fc8.x86_64 requires libMagick.so.10()(64bit) LabPlot-1.5.1.6-4.fc8.x86_64 requires libWand.so.10()(64bit) avahi-ui-sharp-0.6.22-10.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 avahi-ui-sharp-0.6.22-10.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 basket-kontact-1.0.2-5.fc9.x86_64 requires libkcal.so.2()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires libkdepim.so.1()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires libktnef.so.1()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires kdepim3 basket-kontact-1.0.2-5.fc9.x86_64 requires libkpinterfaces.so.1()(64bit) beagle-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-evolution-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-thunderbird-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 dsniff-2.4-0.2.b1.fc9.x86_64 requires libnids.so.1.21()(64bit) evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libWand.so.10()(64bit) evolution-sharp-0.17.2-1.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) f-spot-0.4.3.1-1.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx gbrainy-0.61-5.fc9.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gmime-sharp-2.2.19-1.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(atk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gsf-sharp-0.8.1-7.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 ipod-sharp-0.8.0-4.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 ipod-sharp-0.8.0-4.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 ipod-sharp-0.8.0-4.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 kismet-extras-0.0.2007.10.R1-3.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.x86_64 requires libWand.so.10()(64bit) koffice-libs-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.x86_64 requires libWand.so.10()(64bit) libopensync-plugin-kdepim-0.35-2.fc9.x86_64 requires libkcal.so.2()(64bit) lsvpd-1.6.4-1.fc10.x86_64 requires libvpd_cxx-2.0.so.1()(64bit) mono-addins-0.3.1-1.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 mono-addins-0.3.1-1.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 mono-addins-0.3.1-1.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 mono-addins-0.3.1-1.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) smart-0.52-54.fc9.x86_64 requires smart-config taskjuggler-2.4.1-1.fc10.x86_64 requires libkcal.so.2()(64bit) taskjuggler-2.4.1-1.fc10.x86_64 requires libktnef.so.1()(64bit) taskjuggler-libs-2.4.1-1.fc10.i386 requires libkcal.so.2 taskjuggler-libs-2.4.1-1.fc10.x86_64 requires libkcal.so.2()(64bit) tomboy-0.10.1-2.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 Broken deps for ppc ---------------------------------------------------------- LabPlot-1.5.1.6-4.fc8.ppc requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.ppc requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.ppc requires libMagick.so.10 avahi-ui-sharp-0.6.22-10.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 avahi-ui-sharp-0.6.22-10.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 basket-kontact-1.0.2-5.fc9.ppc requires libkpinterfaces.so.1 basket-kontact-1.0.2-5.fc9.ppc requires libkcal.so.2 basket-kontact-1.0.2-5.fc9.ppc requires libktnef.so.1 basket-kontact-1.0.2-5.fc9.ppc requires kdepim3 basket-kontact-1.0.2-5.fc9.ppc requires libkdepim.so.1 beagle-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 beagle-evolution-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 beagle-thunderbird-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 dsniff-2.4-0.2.b1.fc9.ppc requires libnids.so.1.21 evolution-brutus-1.2.11-2.fc9.ppc requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.ppc requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.ppc requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-sharp-0.17.2-1.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.ppc requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-1.2.so.11 f-spot-0.4.3.1-1.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.ppc requires mono(glade-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gmime-sharp-2.2.19-1.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(atk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(glade-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(pango-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gsf-sharp-0.8.1-7.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.ppc requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 ipod-sharp-0.8.0-4.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 ipod-sharp-0.8.0-4.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 ipod-sharp-0.8.0-4.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 kismet-extras-0.0.2007.10.R1-3.fc9.ppc requires libMagick.so.10 koffice-karbon-1.6.3-15.fc9.ppc requires libWand.so.10 koffice-karbon-1.6.3-15.fc9.ppc requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.ppc requires libWand.so.10 koffice-libs-1.6.3-15.fc9.ppc requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) libopensync-plugin-kdepim-0.35-2.fc9.ppc requires libkcal.so.2 lsvpd-1.6.4-1.fc10.ppc requires libvpd_cxx-2.0.so.1 mono-addins-0.3.1-1.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 mono-addins-0.3.1-1.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 mono-addins-0.3.1-1.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 mono-addins-0.3.1-1.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.ppc requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.ppc requires libgeos.so.2 smart-0.52-54.fc9.ppc requires smart-config taskjuggler-2.4.1-1.fc10.ppc requires libkcal.so.2 taskjuggler-2.4.1-1.fc10.ppc requires libktnef.so.1 taskjuggler-libs-2.4.1-1.fc10.ppc requires libkcal.so.2 taskjuggler-libs-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) tomboy-0.10.1-2.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.ppc requires mono(pango-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 Broken deps for ppc64 ---------------------------------------------------------- basket-kontact-1.0.2-5.fc9.ppc64 requires libkcal.so.2()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires libkdepim.so.1()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires libktnef.so.1()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires kdepim3 basket-kontact-1.0.2-5.fc9.ppc64 requires libkpinterfaces.so.1()(64bit) dsniff-2.4-0.2.b1.fc9.ppc64 requires libnids.so.1.21()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) kismet-extras-0.0.2007.10.R1-3.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) libopensync-plugin-kdepim-0.35-2.fc9.ppc64 requires libkcal.so.2()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot lsvpd-1.6.4-1.fc10.ppc64 requires libvpd_cxx-2.0.so.1()(64bit) perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) smart-0.52-54.fc9.ppc64 requires smart-config taskjuggler-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) taskjuggler-2.4.1-1.fc10.ppc64 requires libktnef.so.1()(64bit) taskjuggler-libs-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) From seg at haxxed.com Mon May 26 09:51:14 2008 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 26 May 2008 04:51:14 -0500 Subject: Announcing a new F-10 Feature Proposal: Better Webcam Support In-Reply-To: <48372628.7030905@hhs.nl> References: <4836DA23.3090709@hhs.nl> <20080523152426.GB3224@nostromo.devel.redhat.com> <48372628.7030905@hhs.nl> Message-ID: <1218b5bc0805260251l42aa0aafj99e194487b7334f6@mail.gmail.com> On Fri, May 23, 2008 at 3:16 PM, Hans de Goede wrote: > So its not just API conversion, but also image format conversion. > Alternatively a v4l2 library could be written which offers a higher > abstraction layer could be written and apps ported to that, I guess thats > the golden way. But so much todo in so little time. > Like, say, XVideo? We have the xf86-video-v4l driver, which gives you all kinds of nice acceleration if you're displaying directly to screen. Has the advantage of being not Linux specific. On the down side it ties you to X, which may be a deal killer depending on the app. Though gstreamer is really the way to go. Which means we need proper gstreamer plugins to wrap v4l/v4l2 and/or XVideo and whatever else. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexl at users.sourceforge.net Mon May 26 10:57:34 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Mon, 26 May 2008 03:57:34 -0700 Subject: rawhide report: 20080526 changes In-Reply-To: <20080526094640.2C6D4209CC4@releng1.fedora.phx.redhat.com> (rawhide@fedoraproject.org's message of "Mon\, 26 May 2008 09\:46\:39 +0000 \(UTC\)") References: <20080526094640.2C6D4209CC4@releng1.fedora.phx.redhat.com> Message-ID: <6oabidcoyp.fsf@allele2.eebweb.arizona.edu> >>>>> rawhide writes: > setting up repos setting up old repo > file:///mnt/koji/mash/rawhide-20080523/development/source/SRPMS > kdelibs3-3.5.9-13.fc10 > ---------------------- > * Sat May 24 18:00:00 2008 Rex Dieter 3.5.9-13 > - f9+: include kdeui symlink here + scriptlets to help rpm handle it > * Fri May 23 18:00:00 2008 Rex Dieter 3.5.9-12 > - f9+: omit %{_datadir}/apps/kdeui, use version from kdelibs-common (#447965) > Broken deps for i386 > ---------------------------------------------------------- > avahi-ui-sharp-0.6.22-10.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 > avahi-ui-sharp-0.6.22-10.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 > banshee-0.99.2-2.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 > banshee-0.99.2-2.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 > banshee-0.99.2-2.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 > banshee-0.99.2-2.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 > banshee-0.99.2-2.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 > basket-kontact-1.0.2-5.fc9.i386 requires libkpinterfaces.so.1 > basket-kontact-1.0.2-5.fc9.i386 requires libkcal.so.2 > basket-kontact-1.0.2-5.fc9.i386 requires libktnef.so.1 > basket-kontact-1.0.2-5.fc9.i386 requires kdepim3 > basket-kontact-1.0.2-5.fc9.i386 requires libkdepim.so.1 > beagle-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 > beagle-0.3.7-5.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 > beagle-0.3.7-5.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 > beagle-0.3.7-5.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 > beagle-0.3.7-5.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 > beagle-evolution-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 > beagle-gnome-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 > beagle-gnome-0.3.7-5.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 > beagle-gnome-0.3.7-5.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 > beagle-gnome-0.3.7-5.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 > beagle-gnome-0.3.7-5.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 > beagle-thunderbird-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 Looks like the diff between the repos still errors out somewhere around packages starting after kdelibs3* This unfortunately misses out all the mono changes which must have happened, implied by all broken deps for mono packages. Was there a big version API/ABI bump for mono in rawhide? Was it announced? From kanarip at kanarip.com Mon May 26 11:10:21 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 26 May 2008 13:10:21 +0200 Subject: rawhide report: 20080526 changes In-Reply-To: <6oabidcoyp.fsf@allele2.eebweb.arizona.edu> References: <20080526094640.2C6D4209CC4@releng1.fedora.phx.redhat.com> <6oabidcoyp.fsf@allele2.eebweb.arizona.edu> Message-ID: <483A9A9D.3030809@kanarip.com> Alex Lancaster wrote: > Was there a > big version API/ABI bump for mono in rawhide? Was it announced? > I don't know but as far as I can see the packages depending on mono capabilities require one specific version of mono (capabilities)... Would not every single minor version bump of mono packages cause these packages depending on these specific versions failing to resolve these requirements? -Jeroen From dtimms at iinet.net.au Mon May 26 11:45:58 2008 From: dtimms at iinet.net.au (David Timms) Date: Mon, 26 May 2008 21:45:58 +1000 Subject: package reviews: show only review reqs using a particluar language ? Message-ID: <483AA2F6.50802@iinet.net.au> While trying to find packages that I consider I'd have the skills to give good feedback on, I keep coming up against the hard java etc stuff, that I have no idea about... Is there currently a way to query bugzilla about say packages only written in java, python or c ? Are bugzilla tags freeform, ie could any bugzilla user add such a tag to the review ? DaveT. From rjones at redhat.com Mon May 26 11:57:37 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 26 May 2008 12:57:37 +0100 Subject: package reviews: show only review reqs using a particluar language ? In-Reply-To: <483AA2F6.50802@iinet.net.au> References: <483AA2F6.50802@iinet.net.au> Message-ID: <20080526115737.GA25201@amd.home.annexia.org> On Mon, May 26, 2008 at 09:45:58PM +1000, David Timms wrote: > While trying to find packages that I consider I'd have the skills to give > good feedback on, I keep coming up against the hard java etc stuff, that I > have no idea about... > > Is there currently a way to query bugzilla about say packages only written > in java, python or c ? > > Are bugzilla tags freeform, ie could any bugzilla user add such a tag to > the review ? Yes, this would be useful to know. At the moment all OCaml related bugs have 'ocaml' in the Summary line, and I have some searches which are basically freeform searches which check for 'ocaml' in the Summary. It would be nice to have a better more official way to handle this. Perhaps by depending on a "master" bug (the same way that ExcludeArch / Blocker bugs are tracked). Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From dtimms at iinet.net.au Mon May 26 12:10:17 2008 From: dtimms at iinet.net.au (David Timms) Date: Mon, 26 May 2008 22:10:17 +1000 Subject: Thoughts on a hardware-specific bugzilla? In-Reply-To: <1211664532.3444.53.camel@ignacio.lan> References: <1211657616.19112.4.camel@Diffingo.localdomain> <1211664532.3444.53.camel@ignacio.lan> Message-ID: <483AA8A9.6060504@iinet.net.au> Ignacio Vazquez-Abrams wrote: > On Sat, 2008-05-24 at 15:33 -0400, Stewart Adam wrote: >> I've been working out a few hardware bugs on a new laptop lately, and I >> thought it would be interesting to create a specific category/product in >> the current bugzilla for hardware bugs. Various components could be >> listed as the different hardware categories (wifi, screen/backlight, >> trackpad, keyboard, speakers, etc) and this way hardware issues could be >> tracked separately from software bugs. Hopefully, this would help >> hardware bugs To me they would be in firmware, and non-fixable; unless the manufacturer is using loadable firmware to make the device usable. But that is really software in any case... >> be resolved faster and it would be a good step forward for >> getting more computers to work out of the box on a standard Fedora >> install. Do you think it's worth it? > > I'm wondering if this discussion doesn't belong on the > cross-distribution list. Is that because the hw issues tends to hit all distros ? If there was such a thing, it would be good to base of or link to the smolt hardware database. You have probably seen the bit where you can indicate if your machine's bits work out of the box, with non-free driver, with extra config etc. For the problem ones, the smolt entry can be used to create a wiki entry where any info {eg workaround, manual load, specific configs can be stored.}. bug tracking pointers could go in here as well. There is also a more manual hw database on: http://www.linuxquestions.org/hcl/ The think I like about smolt is that the submission of your machine's bit's IDs is automatic, along with some quick buttons to indicate how well the item worked. It might be nice for a machine side gui app to open your machine's smolt submission, rather than having to know the smoltX CLI stuff. From bnocera at redhat.com Mon May 26 12:56:40 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Mon, 26 May 2008 13:56:40 +0100 Subject: Thoughts on a hardware-specific bugzilla? In-Reply-To: <1211657616.19112.4.camel@Diffingo.localdomain> References: <1211657616.19112.4.camel@Diffingo.localdomain> Message-ID: <1211806600.3566.196.camel@cookie.hadess.net> On Sat, 2008-05-24 at 15:33 -0400, Stewart Adam wrote: > Hi, > > I've been working out a few hardware bugs on a new laptop lately, and I > thought it would be interesting to create a specific category/product in > the current bugzilla for hardware bugs. Various components could be > listed as the different hardware categories (wifi, screen/backlight, > trackpad, keyboard, speakers, etc) and this way hardware issues could be > tracked separately from software bugs. Hopefully, this would help > hardware bugs be resolved faster and it would be a good step forward for > getting more computers to work out of the box on a standard Fedora > install. Do you think it's worth it? We're pretty good at pushing things upstream, so maybe you're better off filing bugs directly in the Fedora bugzillas. I used a tracker in a product that's only available internally to track issues with my Dell Latitude D420[1] when I got it, but it wasn't very useful. You might be better off: - Creating a wiki page for it - Telling sites like tuxmobile about it - and making sure all the issues get filed (maybe with work-arounds in the wiki page itself) The main point is that all those laptops/machines should work out-of-the-box, so anything that we can do in Fedora to make that better should be taken seriously. I remember working on various issues for an older Sony Vaio laptop (S1XP) that didn't work that well with FC2. By the time for FC4, everything on it was working out-of-the-box. Note that Red Hat have a number of people interested in making this work well (hey Richard and Matthew!), so all the fixes, would be upstreamed in due time. It also makes it easier for us to move problems between components (is the backlight not working a kernel, a hal, a hal-info, or an Xorg driver problem?). > (Just to clarify, by "hardware bugs" I mean things like missing device > IDs from kernel source files, suspend quirks, display backlight control, > missing sound, or a component not being detected at all. Devices > malfunctioning in Linux due to a driver bug would fall under software > bugs IMO) Wiki pages with links to bugs is the way to go, and allows us to update easily, and discuss problems related to the device. [1]: For that laptop, we got the backlight working in HAL, Rfkill support in HAL as well, hints in hal-info for the WWAN driver, and a lot of device driver updates. All of which have been upstreamed. From bnocera at redhat.com Mon May 26 12:59:31 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Mon, 26 May 2008 13:59:31 +0100 Subject: upstart plans for F10+ In-Reply-To: <1218b5bc0805252314q42b16ab4qf8b38f0f6242f352@mail.gmail.com> References: <20080522200445.GA24822@nostromo.devel.redhat.com> <20080522204407.GA30257@nostromo.devel.redhat.com> <1218b5bc0805252314q42b16ab4qf8b38f0f6242f352@mail.gmail.com> Message-ID: <1211806771.3566.199.camel@cookie.hadess.net> On Mon, 2008-05-26 at 01:14 -0500, Callum Lerwick wrote: > It should be noted that anything using gnome-vfs, that is, most > anything gnome, seems to like to happily stat every mounted filesystem > constantly, often for no apparent reason, even if that app isn't even > doing anything with that mount. This means your entire desktop locks > the f-ck up if an NFS mount goes dead, gnome panel and all. It also > seems to prevent automounts from ever timing out. That shouldn't happen really. In any case, we're phasing out gnome-vfs. If you see the same problems in gvfs/gio applications, please file a bug, we'd be happy to get it fixed. Cheers From robert at fedoraproject.org Mon May 26 13:23:28 2008 From: robert at fedoraproject.org (Robert Scheck) Date: Mon, 26 May 2008 15:23:28 +0200 Subject: Announcing a new F-10 Feature Proposal: Better Webcam Support In-Reply-To: <1218b5bc0805260251l42aa0aafj99e194487b7334f6@mail.gmail.com> References: <4836DA23.3090709@hhs.nl> <20080523152426.GB3224@nostromo.devel.redhat.com> <48372628.7030905@hhs.nl> <1218b5bc0805260251l42aa0aafj99e194487b7334f6@mail.gmail.com> Message-ID: <20080526132328.GA4497@hurricane.linuxnetz.de> On Mon, 26 May 2008, Callum Lerwick wrote: > Though gstreamer is really the way to go. Which means we need proper > gstreamer plugins to wrap v4l/v4l2 and/or XVideo and whatever else. Well, v4l/v4l2 was "yum install ucview -y && ucview" in the past for me - such as on Asus Eee PC. Greetings, Robert From dtimms at iinet.net.au Mon May 26 13:28:50 2008 From: dtimms at iinet.net.au (David Timms) Date: Mon, 26 May 2008 23:28:50 +1000 Subject: Need some help with Anjuta 2.4.1 In-Reply-To: <3170f42f0805250510h5569b865qb04b1902e57e8463@mail.gmail.com> References: <3170f42f0805250510h5569b865qb04b1902e57e8463@mail.gmail.com> Message-ID: <483ABB12.8030803@iinet.net.au> Debarshi Ray wrote: > I am in the process of updating Anjuta to 2.4.1 from 2.2.3 for Fedora > 9 and Rawhide. The relevant patch, SPEC and source tarball are in CVS. > However, rpmlint is spewing a large number of errors and warnings > which generally look spurious to me. Could someone could throw an eye > on it and comment? The spec url is ? The rpmlint e/w are ? scratch build url ? From robert at fedoraproject.org Mon May 26 13:30:16 2008 From: robert at fedoraproject.org (Robert Scheck) Date: Mon, 26 May 2008 15:30:16 +0200 Subject: glibc-2.8.90-4 causing tonnes of problems -help! In-Reply-To: <20080524175942.M65050@all-the-johnsons.co.uk> References: <20080524175942.M65050@all-the-johnsons.co.uk> Message-ID: <20080526133016.GB4497@hurricane.linuxnetz.de> Hello Paul, On Sat, 24 May 2008, Paul F. Johnson wrote: > I have tried to download the glibc-2.8.90-3 src rpm to rebuild it (as a stop > gap until 2.8.90-5 is out), but nothing will download from koji for it (either > via wget or konqueror). can you see the issues with 2.8.90-5 as well? I upgraded yesterday or so to -5 and can't see any issues. But as I'm a lazy schmuck, left out everything between 2.8-x and 2.8.90-5... Greetings, Robert From overholt at redhat.com Mon May 26 13:53:03 2008 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 26 May 2008 09:53:03 -0400 Subject: F9 Live USB IO Errors Message-ID: <20080526135303.GB18648@redhat.com> Hi, I've made some live USB sticks with persistent overlays for a few people. 3 of the people have now told me that they can no longer boot as they get IO errors with what looks like corrupted filesystems. Has this happened to anyone else? The USB sticks were a variety of 1 GB and 2 GB models from various manufacturers and I've never had any issues with them before. I created the sticks like so: sudo livecd-iso-to-disk --reset-mbr \ --overlay-size-mb <1000 or 200 or whatever> \ Fedora-9-i686-Live.iso /dev/sdb1 Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From opensource at till.name Mon May 26 14:13:29 2008 From: opensource at till.name (Till Maas) Date: Mon, 26 May 2008 16:13:29 +0200 Subject: package reviews: show only review reqs using a particluar language ? In-Reply-To: <20080526115737.GA25201@amd.home.annexia.org> References: <483AA2F6.50802@iinet.net.au> <20080526115737.GA25201@amd.home.annexia.org> Message-ID: <200805261613.45410.opensource@till.name> On Monday 26 May 2008 13:57:37 Richard W.M. Jones wrote: > At the moment all OCaml related bugs have 'ocaml' in the Summary line, > and I have some searches which are basically freeform searches which > check for 'ocaml' in the Summary. It would be nice to have a better > more official way to handle this. Perhaps by depending on a "master" > bug (the same way that ExcludeArch / Blocker bugs are tracked). Imho the summary is a good place for this, because then one can easily check and filter for a particular language on the review mailinglist. Also it can be easily seen on a bug search results page. Maybe it could be agreed on a special way to mention it in case it is not already obvious, e.g. add the language in parenthesis after the package name, e.g. Review Request: foobarmatic (ruby) - some foo for bar Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From nicu_fedora at nicubunu.ro Mon May 26 14:16:05 2008 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Mon, 26 May 2008 17:16:05 +0300 Subject: F9 Live USB IO Errors In-Reply-To: <20080526135303.GB18648@redhat.com> References: <20080526135303.GB18648@redhat.com> Message-ID: <483AC625.70705@nicubunu.ro> Andrew Overholt wrote: > Hi, > > I've made some live USB sticks with persistent overlays for a few > people. 3 of the people have now told me that they can no longer boot > as they get IO errors with what looks like corrupted filesystems. Has > this happened to anyone else? The USB sticks were a variety of 1 GB and > 2 GB models from various manufacturers and I've never had any issues > with them before. Well, it happened to me, but after I pressed the "reset" button while doing a massive yum install (the computer was frozen while playing with Compiz during the install). (as a matter of fact, that happened to me twice, don't remember why I used reset the second time). And I had some strange IO errors in another occasion (at the F9 Release Party, gave a KDE4 stick to people to play with it, after a while the GUI was frozen, Ctrl+Alt+F1 to a text terminal showed some IO errors, didn't get the time to see if it still boots) -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From foster at in.tum.de Mon May 26 14:26:14 2008 From: foster at in.tum.de (Mary Ellen Foster) Date: Mon, 26 May 2008 15:26:14 +0100 Subject: F9 Live USB IO Errors In-Reply-To: <483AC625.70705@nicubunu.ro> References: <20080526135303.GB18648@redhat.com> <483AC625.70705@nicubunu.ro> Message-ID: 2008/5/26 Nicu Buculei : >> I've made some live USB sticks with persistent overlays for a few >> people. 3 of the people have now told me that they can no longer boot >> as they get IO errors with what looks like corrupted filesystems. Has >> this happened to anyone else? The USB sticks were a variety of 1 GB and >> 2 GB models from various manufacturers and I've never had any issues >> with them before. > > Well, it happened to me, but after I pressed the "reset" button while doing > a massive yum install (the computer was frozen while playing with Compiz > during the install). (as a matter of fact, that happened to me twice, don't > remember why I used reset the second time). That happened once, and I assumed I'd overrun the size of the overlay -- didn't investigate further. Is there a check of any sort to make sure you don't overflow? There didn't used to be in the livecd-to-iso installer, and that would certainly corrupt file systems ... MEF -- Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/ Informatik 6: Robotics and Embedded Systems, Technische Universit?t M?nchen and ICCS, School of Informatics, University of Edinburgh From overholt at redhat.com Mon May 26 14:45:06 2008 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 26 May 2008 10:45:06 -0400 Subject: F9 Live USB IO Errors In-Reply-To: <20080526135303.GB18648@redhat.com> References: <20080526135303.GB18648@redhat.com> Message-ID: <20080526144506.GC30486@redhat.com> * Andrew Overholt [2008-05-26 09:54]: > > I've made some live USB sticks with persistent overlays for a few > people. 3 of the people have now told me that they can no longer boot > as they get IO errors with what looks like corrupted filesystems. 2 of the 3 have now confirmed for me that they hit hard lockups while running and had to hard-reboot their machines. Afterwards, they could not re-boot from the USB stick. Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From tnorth at fedoraproject.org Mon May 26 14:54:57 2008 From: tnorth at fedoraproject.org (Thibault North) Date: Mon, 26 May 2008 16:54:57 +0200 Subject: F9 Live USB IO Errors In-Reply-To: References: <20080526135303.GB18648@redhat.com> <483AC625.70705@nicubunu.ro> Message-ID: <8e967d910805260754w160780e1y58c96a5f3f7d3af7@mail.gmail.com> On Mon, May 26, 2008 at 4:26 PM, Mary Ellen Foster wrote: > 2008/5/26 Nicu Buculei : >>> I've made some live USB sticks with persistent overlays for a few >>> people. 3 of the people have now told me that they can no longer boot >>> as they get IO errors with what looks like corrupted filesystems. Has >>> this happened to anyone else? The USB sticks were a variety of 1 GB and >>> 2 GB models from various manufacturers and I've never had any issues >>> with them before. >> >> Well, it happened to me, but after I pressed the "reset" button while doing >> a massive yum install (the computer was frozen while playing with Compiz >> during the install). (as a matter of fact, that happened to me twice, don't >> remember why I used reset the second time). > > That happened once, and I assumed I'd overrun the size of the overlay > -- didn't investigate further. Is there a check of any sort to make > sure you don't overflow? There didn't used to be in the livecd-to-iso > installer, and that would certainly corrupt file systems ... Also happend to me. Freezed while updating. I Ctrl+C and rebooted, but unable to restart. There was place remaining on the disk. > > MEF > > -- > Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/ > Informatik 6: Robotics and Embedded Systems, Technische Universit?t M?nchen > and ICCS, School of Informatics, University of Edinburgh > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From zaitcev at redhat.com Mon May 26 19:01:41 2008 From: zaitcev at redhat.com (Pete Zaitcev) Date: Mon, 26 May 2008 12:01:41 -0700 Subject: USB devices not being recognised In-Reply-To: <1211302172.4830.5.camel@T7.Linux> References: <1211302172.4830.5.camel@T7.Linux> Message-ID: <20080526120141.85d71bbd.zaitcev@redhat.com> On Tue, 20 May 2008 17:49:32 +0100, Paul wrote: > I have a Tevion USB IP phone which used to work under F9 rawhide without > a problem. > > If I now plug it in while the system is powering up, the kernel > complains (causes a loop condition). The "loop condition" does not tell me anything. Please send me your dmesg, I'll have a look. > [...] If I plug it in after I hit the > desktop nothing happens - no LEDs light up or the sound system see it. This sounds like someone enabled auto-suspend again. -- Pete From Bl0ngo067 at aim.com Mon May 26 19:00:07 2008 From: Bl0ngo067 at aim.com (Brad Longo) Date: Mon, 26 May 2008 15:00:07 -0400 Subject: LiveCD With SELinux Disabled Message-ID: <1211828407.16294.4.camel@localhost.localdomain> I am trying to customize my own livecd with livecd-tools, and I am wondering if there is something I can put into the livecd-fedora-9-desktop.ks file so that selinux is disabled by default. I was thinking something like passing selinux=0 to vmlinuz at boot or something like that. Does anyone have any idea? -- Brad Longo Aerospace Engineering and Applied Mathematics North Carolina State University Raleigh, North Carolina USA From sundaram at fedoraproject.org Mon May 26 19:13:00 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 27 May 2008 00:43:00 +0530 Subject: LiveCD With SELinux Disabled In-Reply-To: <1211828407.16294.4.camel@localhost.localdomain> References: <1211828407.16294.4.camel@localhost.localdomain> Message-ID: <483B0BBC.1020900@fedoraproject.org> Brad Longo wrote: > I am trying to customize my own livecd with livecd-tools, and I am > wondering if there is something I can put into the > livecd-fedora-9-desktop.ks file so that selinux is disabled by default. > I was thinking something like passing selinux=0 to vmlinuz at boot or > something like that. Does anyone have any idea? Add "selinux --disabled" Rahul From Jochen at herr-schmitt.de Tue May 27 04:19:46 2008 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Mon, 26 May 2008 21:19:46 -0700 Subject: IText resurection Message-ID: <0ML31I-1K0iEh0mnI-0000wP@mrelayeu.kundenserver.de> Hallo, I have got a mail which pointed to the following post: https://www.redhat.com/archives/fedora-list/2008-May/msg03064.html Now I want to ask for the state of iText relating th the licensing issue which cause the removement of this package from Fedora. Are there any effort for re-inclussion of this package into Fedora? Best Regards: Jochen Schmitt From dmc.fedora at filteredperception.org Mon May 26 19:30:54 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 26 May 2008 12:30:54 -0700 Subject: F9 Live USB IO Errors In-Reply-To: <20080526144506.GC30486@redhat.com> References: <20080526135303.GB18648@redhat.com> <20080526144506.GC30486@redhat.com> Message-ID: <483B0FEE.6080702@filteredperception.org> Andrew Overholt wrote: > * Andrew Overholt [2008-05-26 09:54]: >> I've made some live USB sticks with persistent overlays for a few >> people. 3 of the people have now told me that they can no longer boot >> as they get IO errors with what looks like corrupted filesystems. > > 2 of the 3 have now confirmed for me that they hit hard lockups while > running and had to hard-reboot their machines. Afterwards, they could > not re-boot from the USB stick. > > Andrew Well known nature of the feature. See a post of mine on fedora-livecd-list https://www.redhat.com/archives/fedora-livecd-list/2008-May/msg00051.html I've suggested several times over the last 6 months that this issue be well documented to set expectations appropriately. -dmc/jdog From jonathan.underwood at gmail.com Mon May 26 19:54:06 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 26 May 2008 20:54:06 +0100 Subject: IText resurection In-Reply-To: <0ML31I-1K0iEh0mnI-0000wP@mrelayeu.kundenserver.de> References: <0ML31I-1K0iEh0mnI-0000wP@mrelayeu.kundenserver.de> Message-ID: <645d17210805261254o43d871bjedbd6ed857f96d7e@mail.gmail.com> 2008/5/27 Jochen Schmitt : > Hallo, > > I have got a mail which pointed to the following post: > > https://www.redhat.com/archives/fedora-list/2008-May/msg03064.html > > Now I want to ask for the state of iText relating th the > licensing issue which cause the removement of this package from > Fedora. > For reference, relevant previous discussions: https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00209.html which references back to this (lengthyish) thread: http://www.redhat.com/archives/fedora-devel-list/2007-November/msg00726.html > Are there any effort for re-inclussion of this package into > Fedora? > Not that I am aware of. J. From szaka at ntfs-3g.org Mon May 26 20:07:47 2008 From: szaka at ntfs-3g.org (Szabolcs Szakacsits) Date: Mon, 26 May 2008 20:07:47 +0000 (UTC) Subject: ntfs-3g and ntfsprogs References: <200805251456.08119.gene@czarc.net> <1211773009.6251.3.camel@localhost.localdomain> Message-ID: Tom "spot" Callaway redhat.com> writes: > > ntfsprogs is not really maintained these days, but it provides utilities > that ntfs-3g does not intend to implement in the near term. It only depends on users' and developers' interest. Ntfs-3g did implement, improved and fixed many ntfsprogs utilities in the last six years (ntfsresize, ntfsclone, mkntfs, ntfsfix, vista compatibility, etc). And we do plan to include stable versions of at least the most important ones in NTFS-3G in the next 2-4 months (mkfs, fsck, label, resize, clone, image, restore, info, debug, cmp). Currently we're using a stable, old CVS ntfsprogs version between 1.13.1 and 2.0.0 which is essential for the NTFS-3G quality assurance and regression testing. Porting and validation of the tools and all the tests on http://ntfs-3g.org/quality.html takes quite a lot of time and close attention not to introduce reliability problems. Regards, Szaka -- NTFS-3G: http://ntfs-3g.org From jonathan.underwood at gmail.com Mon May 26 20:16:43 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 26 May 2008 21:16:43 +0100 Subject: IText resurection In-Reply-To: <0ML31I-1K0iEh0mnI-0000wP@mrelayeu.kundenserver.de> References: <0ML31I-1K0iEh0mnI-0000wP@mrelayeu.kundenserver.de> Message-ID: <645d17210805261316q188fba44h470a11e722795a82@mail.gmail.com> 2008/5/27 Jochen Schmitt : > Are there any effort for re-inclussion of this package into > Fedora? I'd be happy to help out with this if you like - I was mostly waiting for the java packaging guidelines situationj to settle down before looking at it, and learning how to package java stuff (having never done any java packages before.). From szaka at ntfs-3g.org Mon May 26 20:55:31 2008 From: szaka at ntfs-3g.org (Szabolcs Szakacsits) Date: Mon, 26 May 2008 20:55:31 +0000 (UTC) Subject: ntfs-3g and ntfsprogs References: <200805251456.08119.gene@czarc.net> <1211773189.6251.6.camel@localhost.localdomain> Message-ID: Tom "spot" Callaway redhat.com> writes: > Nope. ntfs-3g is primarily for mounting. Nothing is using its > library/headers at this time (to the best of my knowledge). ntfs-3g.probe. Though probably it's mostly used only on OS X which requires it before mount. > These two apps are really more complimentary than it might seem, but if > anything, ntfs-3g is growing much faster and has a much more active > community. Yep. Ntfs-3g is the active ex-Linux-NTFS developers plus many new ones. I'm still on all the Linux-NTFS lists and notification systems and I can't see productive activity. Well, we were never a big group, only a few of us. Basically the project was killed when the maintainer got hired by Apple in 2005 to work on their currently closed source, work-in-progress driver by rewriting the Linux NTFS code (we agreed and were promised to get the new code what we didn't). This was one of the many reasons NTFS-3G had to partially fork: to keep the open source NTFS development alive. Regards, Szaka -- NTFS-3G: http://ntfs-3g.org From gene at czarc.net Mon May 26 21:13:31 2008 From: gene at czarc.net (Gene Czarcinski) Date: Mon, 26 May 2008 17:13:31 -0400 Subject: ntfs-3g and ntfsprogs In-Reply-To: <1211773009.6251.3.camel@localhost.localdomain> References: <200805251456.08119.gene@czarc.net> <1211773009.6251.3.camel@localhost.localdomain> Message-ID: <200805261713.31355.gene@czarc.net> On Sunday 25 May 2008 23:36:49 Tom "spot" Callaway wrote: > On Sun, 2008-05-25 at 14:56 -0400, Gene Czarcinski wrote: > > I assume that the long term plan (goal) is to have a single package > > which does everything "right" which is currently done by the > > combination of ntfs-3g and ntfsprogs. > > ntfsprogs is not really maintained these days, but it provides utilities > that ntfs-3g does not intend to implement in the near term. > > Long term, it is probable that ntfs-3g will enable the same set of > functionality that ntfsprogs does, but until then, we'll continue to > leverage the best of both worlds. > > ~spot, maintainer for both ntfs-3g and ntfsprogs I am not trying to start any kind of "war" but just trying to provide some food for thought ... 1. I grant you that 2.0.0 ntfsprogs is very "new" after about a year and a half of no activity so the package should be treated with care ... there is a very large amount of change between the 1.13.1 version in F8 and the 2.0.0 version now in F9. Continuing to use ntfs-3g as the default for mounting in F10 makes sense. [yes, I am aware of http://forum.linux-ntfs.org/viewtopic.php?t=741 and it appears there is some animosity between the two developer groups ... I would hope that gets settled and the two projects merge at some point] 2. With F9, anaconda includes ntfsprogs in the rescuecd and uses ntfsresize to support resizing of ntfs partitions during Fedora install. Note: I find it interesting that I have never seen documentation which defines just what packages/software anaconda sucks in for the installer/rescue bootable systems except in anaconda-runtime's upd-instroot shell script. 3. I have taken a quick look at the ntfs-3g src.rpm, their website, and their mailing list archives. I see nothing which implies plans to incorporate functionality of the utilities in ntfsprogs into ntfs-3g. So, if you use ntfs-3g for mounting ntfs partitions, then, yes, you also need ntfsprogs to cover the functionality of its utilities. 4. On the other hand, version 2.0.0 of ntfsprogs does now include a mount command for mounting ntfs partitions. However, as packaged for Fedora, this mount command is not provided. IF [and this is a big if] (a) ntfsprogs continues to provide active maintenance/development that it recently demonstrated and if (b) ntfsprogs (specifically the mount command and read/write I/O) demonstrates to have good reliability, then I believe that ntfs-3g could be removed (at some time in the future) and only ntfsprogs provided in Fedora. My suggestion: Provide an additional binary package for the ntfsprogs mount command (e.g., ntfsprogs-mount) which would have the mount command and man-page. Installation of this "new" package should be made to conflict with ntfs-3g so that both could not be installed at the same time. For F10 (an probably F11) continue with the current default installs ... that is, both ntfs-3g and ntfsprogs but not ntfsprogs-mount. My reasoning is that unless software is readily available, nobody will test it. Few, if any, individuals will go to the effort of building their own ntfsprogs package to include the mount command. The risk to you (spot as the current Maintainer/stuckee and perhaps others at Red Hat) is that you may get additional BZ reports on problems with partitions mounted with ntfsprogs' mount command. However, if there are bugs in ntfsprogs-2.0.0, then I claim you will get additional BZ reports from users using the other ntfsprogs utilities. Anyway ... some food for thought. Does anyone else in the developer community have any thoughts on this? Gene From tcallawa at redhat.com Mon May 26 21:49:29 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 26 May 2008 17:49:29 -0400 Subject: ntfs-3g and ntfsprogs In-Reply-To: <200805261713.31355.gene@czarc.net> References: <200805251456.08119.gene@czarc.net> <1211773009.6251.3.camel@localhost.localdomain> <200805261713.31355.gene@czarc.net> Message-ID: <1211838569.6251.32.camel@localhost.localdomain> On Mon, 2008-05-26 at 17:13 -0400, Gene Czarcinski wrote: > My suggestion: Provide an additional binary package for the ntfsprogs > mount command (e.g., ntfsprogs-mount) which would have the mount > command and man-page. Installation of this "new" package should be > made to conflict with ntfs-3g so that both could not be installed at > the same time. For F10 (an probably F11) continue with the current > default installs ... that is, both ntfs-3g and ntfsprogs but not > ntfsprogs-mount. I disagree. Having two methods for ntfs mount seems like a recipe for failure. I looked at both of them, and determined that the ntfs-3g mount mechanism was far more robust and better maintained. I don't really think we benefit at all from enabling the ntfsprogs mount functionality. Or, to put it more succinctly, when we've had any problems with ntfs-3g mount, Szaka has been extremely helpful in working with us to resolve the issues. We've also had issues with the ntfsprogs suite, and received zero help or feedback on our patches. "Supporting" the ntfsprogs mount will simply lead to more bugs, and I've got enough of those as is. :) I'm hopeful that in time, the conflict/competition between ntfs-3g and ntfsprogs will all balance itself out. If we need to enable the ntfsprogs mount, it is only a minor amount of work, and could be done quickly. ~spot p.s. I'm hedging my bets on ntfs-3g. They show community and growth, where ntfsprogs doesn't. From tcallawa at redhat.com Mon May 26 21:51:34 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 26 May 2008 17:51:34 -0400 Subject: "10" < "9": Get rid of string comparisons in time for F-10? In-Reply-To: <48374C8A.5070606@n-dimensional.de> References: <48374C8A.5070606@n-dimensional.de> Message-ID: <1211838694.6251.33.camel@localhost.localdomain> On Sat, 2008-05-24 at 01:00 +0200, Hans Ulrich Niedermann wrote: > On #fedora-devel, the issue of comparing Fedora versions by string > comparison just came up. With F-10 on the way, this will be the first > time when string comparing versions will fail in a "10" < "7" way. > > The case in question was a classic older %if "%{?fedora}" > "7", which > should be changed to %if 0%{?fedora} > 7, as Rex Dieter and Christopher > Stone have pointed out: > http://fedoraproject.org/wiki/Packaging/DistTag#head-1c550109af0705ccb71329619b99428af2fd3e25 > > Where else but in spec files may similarly wrong string comparisons be > happening? Is a systematic effort required to fix these comparisons in > the run-up to F-10? Probably. This is something we should look into, and I've added it to my todo list. ~spot From kmaraas at broadpark.no Mon May 26 23:08:10 2008 From: kmaraas at broadpark.no (Kjartan Maraas) Date: Tue, 27 May 2008 01:08:10 +0200 Subject: SESSION_MANAGER env var in rawhide and XSMP spec Message-ID: <1211843290.3610.7.camel@localhost.localdomain> Hi I've been trying to track down some issues with gnome-session in GNOME 2.23.x which is in rawhide now. I first noticed this when trying out a jhbuild of GNOME 2.23.x, but then noticed that rawhide suffers from the same symptoms. A bunch of processes are left in [defunct] state after login and starting new programs complains about not being able to connect to the session manager. After some investigation and help from one of the gnome-session maintainers we noticed that the SESSION_MANAGER env var in rawhide differs from other distros. What I see in rawhide is this: [kmaraas at localhost gnome-session]$ echo $SESSION_MANAGER local/unix:@/tmp/.ICE-unix/2994 and he had: ?local/henderson:/tmp/.ICE-unix/14577 The XSMP spec has this to say: The client finds the network address of the SM in a system-dependent way. On POSIX systems an environment variable called SESSION_MANAGER will contain a list of network IDs. Each id will contain the transport name followed by a slash and the (transport-specific) address. A TCP/IP address would look like this: tcp/hostname:portnumber where the hostname is a fully qualified domain name. A Unix Domain address looks like this: local/hostname:path A DECnet address would look like this: decnet/nodename::objname If multiple network IDs are specified, they should be separated by commas. Is the current format in rawhide according to spec? And does gnome-session just have to be updated to handle this format? Cheers Kjartan From walters at verbum.org Mon May 26 23:52:07 2008 From: walters at verbum.org (Colin Walters) Date: Mon, 26 May 2008 19:52:07 -0400 Subject: SESSION_MANAGER env var in rawhide and XSMP spec In-Reply-To: <1211843290.3610.7.camel@localhost.localdomain> References: <1211843290.3610.7.camel@localhost.localdomain> Message-ID: On Mon, May 26, 2008 at 7:08 PM, Kjartan Maraas wrote: > [kmaraas at localhost gnome-session]$ echo $SESSION_MANAGER > local/unix:@/tmp/.ICE-unix/2994 I believe this change is described here: http://www.redhat.com/archives/rhl-devel-list/2007-October/msg00034.html From greno at verizon.net Mon May 26 23:56:27 2008 From: greno at verizon.net (Gerry Reno) Date: Mon, 26 May 2008 19:56:27 -0400 Subject: sata and changing devices In-Reply-To: <4837458D.9080105@verizon.net> References: <483701CC.5010002@verizon.net> <20080523200048.GC13150@devserv.devel.redhat.com> <483727E1.80803@verizon.net> <20080523203439.GE13150@devserv.devel.redhat.com> <48372CD5.7010801@verizon.net> <4837458D.9080105@verizon.net> Message-ID: <483B4E2B.4060001@verizon.net> Gerry Reno wrote: > Just following up on this theme with respect to GRUB. When Anaconda > installed GRUB it put entries into /boot/grub/device.map. But in > grub> when I do a 'find /boot/grub/stage1' the list of devices > containing the boot files is altogether different from what is in > device.map. So my question is this: On systems with SATA, is > device.map no longer used? Since it seems under GRUB that the devices > where GRUB finds the boot files keep changing between boots is > device.map even usable? > > Also, with respect to modifying our low-level device management/backup tools to support SATA. This is turning out to be somewhat more difficult than just using hdparm. We rely on the output of mdadm, the lvm display commands, /etc/fstab and others to build a picture of the current state. The problem is that with SATA none of these tools is producing an output that maps the devices to a particular known location where you could find a particular piece of hardware. Prior to SATA for the most part people were using PATA devices and hda was always a specific piece of hardware. But the tool output now is still using this type of device identification (sda) which in the future is actually meaningless and therefore is quite useless for building a picture of the current state that could be used later to recover the state in the event of some disaster. I am looking for some suggestions as to how to generate a backup state picture for physical SATA devices that encompasses mbr, partition tables, raid configuraton, lvm configuration, and filesystem mounting using mdadm, {pv|lv|vg}display, {f|sf}disk or parted. This was all very straightforward with PATA devices but is anything but with these SATA devices. Regards, Gerry From vonbrand at inf.utfsm.cl Tue May 27 01:14:59 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Mon, 26 May 2008 21:14:59 -0400 Subject: glibc-2.8.90-4 causing tonnes of problems -help! In-Reply-To: <20080526133016.GB4497@hurricane.linuxnetz.de> References: <20080524175942.M65050@all-the-johnsons.co.uk> <20080526133016.GB4497@hurricane.linuxnetz.de> Message-ID: <200805270114.m4R1ExDM007984@laptop13.inf.utfsm.cl> Robert Scheck wrote: > On Sat, 24 May 2008, Paul F. Johnson wrote: > > I have tried to download the glibc-2.8.90-3 src rpm to rebuild it (as a > > stop gap until 2.8.90-5 is out), but nothing will download from koji > > for it (either via wget or konqueror). > can you see the issues with 2.8.90-5 as well? I upgraded yesterday or so to > -5 and can't see any issues. But as I'm a lazy schmuck, left out everything > between 2.8-x and 2.8.90-5... With 2.8.90-5 x86_64 can get at the yum repos (yum was failing for me). -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From Bl0ngo067 at aim.com Tue May 27 01:19:32 2008 From: Bl0ngo067 at aim.com (Brad Longo) Date: Mon, 26 May 2008 21:19:32 -0400 Subject: LiveCD With SELinux Disabled In-Reply-To: <483B0BBC.1020900@fedoraproject.org> References: <1211828407.16294.4.camel@localhost.localdomain> <483B0BBC.1020900@fedoraproject.org> Message-ID: <1211851172.3044.1.camel@localhost.localdomain> On Tue, 2008-05-27 at 00:43 +0530, Rahul Sundaram wrote: > Brad Longo wrote: > > I am trying to customize my own livecd with livecd-tools, and I am > > wondering if there is something I can put into the > > livecd-fedora-9-desktop.ks file so that selinux is disabled by default. > > I was thinking something like passing selinux=0 to vmlinuz at boot or > > something like that. Does anyone have any idea? > > Add "selinux --disabled" > > Rahul > I'm guessing that goes under the %post section? Brad From sundaram at fedoraproject.org Tue May 27 01:31:48 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 27 May 2008 07:01:48 +0530 Subject: LiveCD With SELinux Disabled In-Reply-To: <1211851172.3044.1.camel@localhost.localdomain> References: <1211828407.16294.4.camel@localhost.localdomain> <483B0BBC.1020900@fedoraproject.org> <1211851172.3044.1.camel@localhost.localdomain> Message-ID: <483B6484.4080407@fedoraproject.org> Brad Longo wrote: > On Tue, 2008-05-27 at 00:43 +0530, Rahul Sundaram wrote: >> Brad Longo wrote: >>> I am trying to customize my own livecd with livecd-tools, and I am >>> wondering if there is something I can put into the >>> livecd-fedora-9-desktop.ks file so that selinux is disabled by default. >>> I was thinking something like passing selinux=0 to vmlinuz at boot or >>> something like that. Does anyone have any idea? >> Add "selinux --disabled" >> >> Rahul >> > > I'm guessing that goes under the %post section? No. It goes into the start of the ks file before the %packages section. Rahul From jmorris at namei.org Tue May 27 01:31:33 2008 From: jmorris at namei.org (James Morris) Date: Tue, 27 May 2008 11:31:33 +1000 (EST) Subject: Are you using the ATI FireGL driver on F9 ? Message-ID: Thanks to kerneloops.org, I've noticed that people using the proprietary ATI "firegl" driver with (especially) 2.6.25.3-18.fc9.i686 are getting a kernel BUG when the driver calls into the capability code. http://www.kerneloops.org/oops.php?number=13598 I'm curious to know what the driver is doing with capabilities, and would appreciate it if someone using the driver could send me the output of the following as a non-root user via gnome-terminal or xterm: $ id && cat /proc/self/status |grep ^Cap Thanks. -- James Morris From Bl0ngo067 at aim.com Tue May 27 01:40:04 2008 From: Bl0ngo067 at aim.com (Brad Longo) Date: Mon, 26 May 2008 21:40:04 -0400 Subject: LiveUSB Trouble Message-ID: <1211852404.3044.13.camel@localhost.localdomain> I am trying to create a live USB stick, but I am having some issues. First I will say how I made it and then maybe someone can tell me what I may have done wrong or if there is a bug. I tried to use Revisor, but it just doesn't show up for this reason: (revisor:4312): Gdk-WARNING **: DESKTOP_STARTUP_ID contains invalid UTF-8 I downloaded it from the repos btw. So instead I downloaded the livecd-tools and went from there. I ran the following: $ su $ livecd-creator \ --config=/usr/share/livecd-tools/livecd-fedora-desktop.ks \ --fslabel=Fedora 9 LiveCD $parted /dev/sdb (parted) toggle 1 boot (parted) quit $livecd-iso-to-disk Fedora-9-LiveCD.iso /dev/sdb1 I ran all of this successfully without any errors. $ qemu -hda /dev/sdb1 -std-vga When I try to run qemu I get: qemu: could not open disk image /dev/sdb1 Does anyone have any idea as to why it does not boot the image? -- Brad Longo Aerospace Engineering and Applied Mathematics North Carolina State University Raleigh, North Carolina USA From cra at WPI.EDU Tue May 27 02:25:57 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 26 May 2008 22:25:57 -0400 Subject: F9 Live USB IO Errors In-Reply-To: <483B0FEE.6080702@filteredperception.org> References: <20080526135303.GB18648@redhat.com> <20080526144506.GC30486@redhat.com> <483B0FEE.6080702@filteredperception.org> Message-ID: <20080527022557.GH29821@angus.ind.WPI.EDU> On Mon, May 26, 2008 at 12:30:54PM -0700, Douglas McClendon wrote: > Andrew Overholt wrote: >> * Andrew Overholt [2008-05-26 09:54]: >>> I've made some live USB sticks with persistent overlays for a few >>> people. 3 of the people have now told me that they can no longer boot >>> as they get IO errors with what looks like corrupted filesystems. >> >> 2 of the 3 have now confirmed for me that they hit hard lockups while >> running and had to hard-reboot their machines. Afterwards, they could >> not re-boot from the USB stick. >> >> Andrew > > Well known nature of the feature. See a post of mine on fedora-livecd-list > > https://www.redhat.com/archives/fedora-livecd-list/2008-May/msg00051.html > > I've suggested several times over the last 6 months that this issue be > well documented to set expectations appropriately. I don't understand how it could corrupt the UNDERLYING vfat partition, but that is what happend to me twice. I was unable to mount the USB stick as a normal vfat data drive from a regular (non-Live) booted system after filling and crashing the persistent overlay when it was booted as a Live USB system. It seems there is a vfat bug that is corrupting the filesystem. From aoliva at redhat.com Tue May 27 03:39:33 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Tue, 27 May 2008 00:39:33 -0300 Subject: NetworkManager: I want to believe, but... In-Reply-To: (Colin Walters's message of "Fri\, 23 May 2008 08\:25\:53 -0400") References: <3da3b5b40805161502w62f372dseca0ab6310e44447@mail.gmail.com> <3da3b5b40805161522i2300f1cdhb1fc7b074084873f@mail.gmail.com> <604aa7910805161527j6b193c6dj2af4248155d5cdaf@mail.gmail.com> <20080517112856.GA18698@jadzia.bu.edu> <1211069083.3070.392.camel@cookie.hadess.net> <20080522142554.GB8728@jadzia.bu.edu> <1211472267.5352.25.camel@localhost.localdomain> <20080523021725.GA5233@jadzia.bu.edu> <1211509568.19171.9.camel@aglarond.local> <20080523034708.GA12797@jadzia.bu.edu> Message-ID: On May 23, 2008, "Colin Walters" wrote: > On Thu, May 22, 2008 at 11:47 PM, Matthew Miller wrote: >> >> But "is the network up" a generally useful question? > Yes. > --Colin, who just finished last night implementing much improved > network status handling in his SSH client via NetworkManager > http://svn.gnome.org/viewvc/hotwire-ssh/trunk/hotssh/sshwindow.py?limit_changes=100&r1=4&r2=5&pathrev=5 So what does it do when one out of 3 networks a server is directly connected to is down, and you attempt to connect to a host that is reachable through one of the working interfaces? How does "is the network up?" even being to make sense for anything with more than one network interface? What if two of the networks have redundant paths out to the Internet, and the third doesn't, and only the third is up at a given moment? And what if you're not trying to reach the Internet, just another server down the hall that *is* reachable? Heck, what if I'm just trying to reach one of the virtual machines running on the local server, while the primary network interface was taken off line? What if I'm trying to diagnose a firewall problem on my server that makes it *look* like the network is down for whatever heuristics NetworkManager uses to make its decision, but that lets enough through that I could get in from my desktop? And vice-versa, except that I'm not allowed to connect to my desktop because the network is allegedly down. How do you even begin to define 'network', to be able to decide what the 'up' is about? I don't doubt it's possible to make up a number of examples in which the question actually makes sense and it has an answer that also makes sense, but that's hardly enough to extend the claim from "useful for some relevant cases" to "generally useful". I think we're still quite distant from the DWIM pipe dream. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From fedora at theholbrooks.org Tue May 27 03:47:28 2008 From: fedora at theholbrooks.org (Brandon Holbrook) Date: Mon, 26 May 2008 22:47:28 -0500 Subject: Orphaning my Packages (or: RIP, Fedora!) Message-ID: <483B8450.6070505@theholbrooks.org> I'm happy to report that I'm finally feeing myself of everything Fedora! Starting around a year ago Fedora's red tape and horrible bureaucracy started turning me off. It all culminated with the legendary "No KMODs in Fedora" blanket policy on Sept 13. So obviously when I submitted open-vm-tools as a new package 5 days later (I didn't know they passed such a ridiculous policy at the time) here: https://bugzilla.redhat.com/show_bug.cgi?id=294341, it was rejected. Since then I've been migrating all my boxes at home and work away from Fedora/CentOS/RHEL to other distros and found the move to be very refreshing. Fedora now only lives in a couple VMs here at home for me to maintain my packages (a strange bit of irony, since it was Fedora's unwillingness to play nicely in a VM that pushed me away to begin with...), but I haven't even been doing a good job at that. Therefore, I am hereby relinquishing my responsibilities of everything Fedora, which include the following packages: eclipse-phpeclipse -- PHP Eclipse plugin maradns -- Security-aware DNS Server mod_auth_pam -- PAM authentication module for Apache php-json -- An extremely fast PHP extension for JSON php-pear-Mail-Mime -- Classes to create and decode mime messages php-pear-Mail-mimeDecode -- transcodes mime messages php-pear-Net-Sieve -- Communication with timsieved php-pecl-Fileinfo -- Fileinfo is a PHP extension that wraps the libmagic library php-shout -- PHP module for communicating with Icecast servers tripwire -- IDS (Intrusion Detection System) From the Horde groupware suite: horde -- The common Horde Framework for all Horde applications imp -- The Internet Messaging Program: webmail access to IMAP/POP3 accounts ingo -- The Horde web-based Email Filter Rules Manager jeta -- Horde Java SSH module kronolith -- The Horde calendar application turba -- The Horde contact management application Denis Leroy said throughout this process that such a blanket policy was shortsighted, would hurt Fedora more than it helped, and drive people away to other distros. He was right, I'm one of those people. Good luck clinging to your "principles", Fedora, and farewell. -Brandon From dmc.fedora at filteredperception.org Tue May 27 03:50:30 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 26 May 2008 20:50:30 -0700 Subject: F9 Live USB IO Errors In-Reply-To: <20080527022557.GH29821@angus.ind.WPI.EDU> References: <20080526135303.GB18648@redhat.com> <20080526144506.GC30486@redhat.com> <483B0FEE.6080702@filteredperception.org> <20080527022557.GH29821@angus.ind.WPI.EDU> Message-ID: <483B8506.6050602@filteredperception.org> Chuck Anderson wrote: > On Mon, May 26, 2008 at 12:30:54PM -0700, Douglas McClendon wrote: >> Andrew Overholt wrote: >>> * Andrew Overholt [2008-05-26 09:54]: >>>> I've made some live USB sticks with persistent overlays for a few >>>> people. 3 of the people have now told me that they can no longer boot >>>> as they get IO errors with what looks like corrupted filesystems. >>> 2 of the 3 have now confirmed for me that they hit hard lockups while >>> running and had to hard-reboot their machines. Afterwards, they could >>> not re-boot from the USB stick. >>> >>> Andrew >> Well known nature of the feature. See a post of mine on fedora-livecd-list >> >> https://www.redhat.com/archives/fedora-livecd-list/2008-May/msg00051.html >> >> I've suggested several times over the last 6 months that this issue be >> well documented to set expectations appropriately. > > I don't understand how it could corrupt the UNDERLYING vfat partition, > but that is what happend to me twice. I was unable to mount the USB > stick as a normal vfat data drive from a regular (non-Live) booted > system after filling and crashing the persistent overlay when it was > booted as a Live USB system. It seems there is a vfat bug that is > corrupting the filesystem. Agreed, any vfat corruption would be seem to be due to kernel bugs outside of liveusb persistence, though perhaps it is better at triggering the bugs than typical usage. I have run across similar vfat corruption on usbsticks with linux. So bad that an fsck.vfat goes basically crazy, i.e. asks a million questions, and if you do yes to all, results in a filesystem that is mountable but very corrupt, but vaguely reminiscent of the original contents. But note, the original post doesn't mention that kind of problem. Just that they can't boot, with what looks like a corrupted filesystem (which sounds like the natural behaviour when booting with a persistent liveusb that had filled up its overlay). -dmc From Fedora at FamilleCollet.com Tue May 27 05:01:33 2008 From: Fedora at FamilleCollet.com (Remi Collet) Date: Tue, 27 May 2008 07:01:33 +0200 Subject: Orphaning my Packages (or: RIP, Fedora!) In-Reply-To: <483B8450.6070505@theholbrooks.org> References: <483B8450.6070505@theholbrooks.org> Message-ID: <483B95AD.8060404@FamilleCollet.com> Brandon Holbrook a ?crit : > php-json -- An extremely fast PHP extension for JSON > php-pear-Mail-Mime -- Classes to create and decode mime messages > php-pear-Mail-mimeDecode -- transcodes mime messages > php-pear-Net-Sieve -- Communication with timsieved > php-pecl-Fileinfo -- Fileinfo is a PHP extension that wraps the libmagic > library > php-shout -- PHP module for communicating with Icecast servers I can take ownership of this php related package (as/with a co-maintener if someone else want) Remi. From dev at nigelj.com Tue May 27 05:56:38 2008 From: dev at nigelj.com (Nigel Jones) Date: Tue, 27 May 2008 17:56:38 +1200 (NZST) Subject: Orphaning my Packages (or: RIP, Fedora!) In-Reply-To: <483B8450.6070505@theholbrooks.org> References: <483B8450.6070505@theholbrooks.org> Message-ID: <58178.202.154.148.153.1211867798.squirrel@webmail.nigelj.com> On Tue, May 27, 2008 3:47 pm, Brandon Holbrook wrote: [snip] > From the Horde groupware suite: > horde -- The common Horde Framework for all Horde applications > imp -- The Internet Messaging Program: webmail access to IMAP/POP3 > accounts > ingo -- The Horde web-based Email Filter Rules Manager > jeta -- Horde Java SSH module > kronolith -- The Horde calendar application > turba -- The Horde contact management application I'll be happy to take these packages. From ivazqueznet at gmail.com Tue May 27 06:26:41 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Tue, 27 May 2008 02:26:41 -0400 Subject: Orphaning my Packages (or: RIP, Fedora!) In-Reply-To: <483B8450.6070505@theholbrooks.org> References: <483B8450.6070505@theholbrooks.org> Message-ID: <1211869601.4081.3.camel@ignacio.lan> On Mon, 2008-05-26 at 22:47 -0500, Brandon Holbrook wrote: > mod_auth_pam -- PAM authentication module for Apache *yoink* -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pj.pandit at yahoo.co.in Tue May 27 07:40:07 2008 From: pj.pandit at yahoo.co.in (Prasad J Pandit) Date: Tue, 27 May 2008 13:10:07 +0530 (IST) Subject: Stalled tlock review Message-ID: <929321.8994.qm@web94615.mail.in2.yahoo.com> Hello there, I've this package called `tlock', for which I did create a review request at: https://bugzilla.redhat.com/show_bug.cgi?id=444952 But sadly, our on-going review is stalled since Ralf stopped responding(don't know why). Now, I've no clue as to what needs to be done. I'd appreciate it if someone could continue the review process? Also I'm keen to know about Ralf. Thank you! --- Regards -Prasad PS: Please don't send me html/attachment/Fwd mails Check out the all-new face of Yahoo! India. Go to http://in.yahoo.com/ From rc040203 at freenet.de Tue May 27 07:55:56 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 27 May 2008 09:55:56 +0200 Subject: Stalled tlock review In-Reply-To: <929321.8994.qm@web94615.mail.in2.yahoo.com> References: <929321.8994.qm@web94615.mail.in2.yahoo.com> Message-ID: <1211874956.2977.65.camel@beck.corsepiu.local> On Tue, 2008-05-27 at 13:10 +0530, Prasad J Pandit wrote: > Hello there, > > I've this package called `tlock', for which I did create a review request > at: https://bugzilla.redhat.com/show_bug.cgi?id=444952 But sadly, our on-going review is stalled since Ralf stopped responding(don't know why). It's quite simple: Real life interfered. I have been AFK for most of the time in past 2 weeks, which had caused the review to gradually approach the bottom of my personal "working stack". > Now, I've no clue as to what needs to be done. You need to find a sponsor to formally review this package. It would help you to have another package open for review. Ralf From alan at redhat.com Tue May 27 08:22:04 2008 From: alan at redhat.com (Alan Cox) Date: Tue, 27 May 2008 04:22:04 -0400 Subject: sata and changing devices In-Reply-To: <483B4E2B.4060001@verizon.net> References: <483701CC.5010002@verizon.net> <20080523200048.GC13150@devserv.devel.redhat.com> <483727E1.80803@verizon.net> <20080523203439.GE13150@devserv.devel.redhat.com> <48372CD5.7010801@verizon.net> <4837458D.9080105@verizon.net> <483B4E2B.4060001@verizon.net> Message-ID: <20080527082204.GA22443@devserv.devel.redhat.com> On Mon, May 26, 2008 at 07:56:27PM -0400, Gerry Reno wrote: > specific piece of hardware. But the tool output now is still using this > type of device identification (sda) which in the future is actually Nor did PATA except for the four "legacy" devices (hda-hdd) which have no meaning for modern devices > generate a backup state picture for physical SATA devices that > encompasses mbr, partition tables, raid configuraton, lvm configuration, > and filesystem mounting using mdadm, {pv|lv|vg}display, {f|sf}disk or > parted. This was all very straightforward with PATA devices but is > anything but with these SATA devices. SATA is hotplug, beyond "which is the boot volume" there isn't anything which ties a drive to a given port. LVM/MD and friends all understand uuid/label for good reason. From hun at n-dimensional.de Tue May 27 09:02:09 2008 From: hun at n-dimensional.de (Hans Ulrich Niedermann) Date: Tue, 27 May 2008 11:02:09 +0200 Subject: "10" < "9": Get rid of string comparisons in time for F-10? In-Reply-To: <1211838694.6251.33.camel@localhost.localdomain> References: <48374C8A.5070606@n-dimensional.de> <1211838694.6251.33.camel@localhost.localdomain> Message-ID: <483BCE11.7060804@n-dimensional.de> Tom "spot" Callaway wrote: > On Sat, 2008-05-24 at 01:00 +0200, Hans Ulrich Niedermann wrote: >> The case in question was a classic older %if "%{?fedora}" > "7", which >> should be changed to %if 0%{?fedora} > 7, as Rex Dieter and Christopher >> Stone have pointed out: >> http://fedoraproject.org/wiki/Packaging/DistTag#head-1c550109af0705ccb71329619b99428af2fd3e25 >> >> Where else but in spec files may similarly wrong string comparisons be >> happening? Is a systematic effort required to fix these comparisons in >> the run-up to F-10? > > Probably. This is something we should look into, and I've added it to my > todo list. My quick and dirty spec file string comparison checker script is at: http://ndim.fedorapeople.org/stuff/rpm/string-comparison-check.sh Log files for devel, F-9, F-8, F-7 branches: http://ndim.fedorapeople.org/stuff/rpm/string-comp-devel.log http://ndim.fedorapeople.org/stuff/rpm/string-comp-F-9.log http://ndim.fedorapeople.org/stuff/rpm/string-comp-F-8.log http://ndim.fedorapeople.org/stuff/rpm/string-comp-F-7.log To give a rough idea of the scale: devel: 85 string comparisons in 46 spec files F-9: 90 string comparisons in 50 spec files F-8: 117 string comparisons in 59 spec files F-7: 121 string comparisons in 63 spec files If someone wants to do mass bug filing or reporting sorted by maintainer name based on that, you'd probably need to filter out a few cases where this simple grep finds false positives. The == and != comparisons might be working as intended. -- Hans Ulrich Niedermann -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From j.w.r.degoede at hhs.nl Tue May 27 09:55:29 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 27 May 2008 11:55:29 +0200 Subject: Fedora project: making a website with Fedora-Free music Message-ID: <483BDA91.9020008@hhs.nl> Hi All, Today I've been discussing with upstream replacing some non free music with Free music, as I need to do often when packaging games (in this case Lost Labyrinth). I have been thinking recently about how convenient it would be to have a website where one can browse all known Fedora-Free (as in can be part of Fedora under the content Licensing guidelines) music. The Fedora package collection already contains quite a bit of music. Some put in -music packages because its in ogg format and thus quite large, but also quite a few modtracker and midi format songs, which are much smaller and sometimes even hidden away in .wad / .dat files. Thus I want to make a website with: -Unpacked (as in click on it and it will play) versions of all music included in Fedora, sorted by format and license, and preferably also catogorised by genre. -Links to other website which contain all Free, or clearly marked partially Free music. The first website which comes mind for the links section is the excellent: http://www.dogmazic.net/ So now I need 2 things 1) Free (as in gratis) hosting, with lots of diskspace and potentially quite some bandwidth usage. 2) Someone to help me build the website, the last time I've done php / html was in 1999 :) 1) Is the most urgent without 2 I'll just create a few folders like this: mod mod/GPL mod/CC-xx mod/CC-Nd-xx midi midi/GPL midi/CC-xx midi/CC-Nd-xx ogg ogg/GPL ogg/CC-xx ogg/CC-Nd-xx links links/index.html (good old html-1.0 list with links) And use apache's dir listing as html generator :) I know this is crude, but it still beats not having any central place to checkout all the music already in Fedora at all by a long shot. Regards, Hans From valent.turkovic at gmail.com Tue May 27 10:25:34 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 27 May 2008 12:25:34 +0200 Subject: Announcing a new F-10 Feature Proposal: Better Webcam Support In-Reply-To: <4837A8E3.5010908@hhs.nl> References: <4836DA23.3090709@hhs.nl> <20080523152426.GB3224@nostromo.devel.redhat.com> <1211559657.3566.97.camel@cookie.hadess.net> <48372673.5020703@hhs.nl> <1211585885.3566.124.camel@cookie.hadess.net> <4837A8E3.5010908@hhs.nl> Message-ID: <64b14b300805270325t35757e05w48939b6c799dd98e@mail.gmail.com> On Sat, May 24, 2008 at 7:34 AM, Hans de Goede wrote: > Bastien Nocera wrote: >> >> On Fri, 2008-05-23 at 22:17 +0200, Hans de Goede wrote: >>> >>> Bastien Nocera wrote: >>>> >>>> On Fri, 2008-05-23 at 11:24 -0400, Bill Nottingham wrote: >>>>> >>>>> Hans de Goede (j.w.r.degoede at hhs.nl) said: >>>>>> >>>>>> See: >>>>>> >>>>>> http://fedoraproject.org/wiki/Features/BetterWebcamSupport >>>>> >>>>> Any reason a shim library is simpler than porting apps to V4L2? >>>> >>>> Same question here. There's a good number of applications that are >>>> either obsoleted by a v4l2 version, or support both versions. Which >>>> applications were you thinking of supporting with this scheme? >>>> >>>> Unless there's tens of open source apps that would need changing, or a >>>> couple of (useful) proprietary ones that don't support v4l2, the library >>>> is probably not very useful to have (especially as you probably wouldn't >>>> be able to port _all_ the v4l1 drivers to v4l2). >>>> >>> See my reaction to Bill's question, and yes there are a few usefull >>> proprietary apps in the mix unfortunately. >> >> Do you have a list of those apps? Both the proprietary ones and the Open >> Source ones. For the latter, it could be more interesting to create a >> guide for the conversion from V4L1 to V4L2, and see whether Fedora >> maintainers of those projects can help out with the conversion, or at >> least submit it upstream for consideration. >> > > No list atm, noteworthy closed source ones are flash (adobe version) and > skype. Opensource v4l1 viewers I know about are camomara, spcaview. But > quite a few v4l2 apps also don't work with all v4l2 cams due to not > supporting all needed colorformats, examples of these are for example xawtv > and luvcview. > > I must say my primary focus at the moment is getting drivers cleaned up and > merged in the mainline, but the userspace side of things definetely needs > work too. > > Regards, > > Hans Is there something that Fedora users with few webcams that aren't recognised under Fedora because of non-existing drivers can do to help? Is there some way that we can give you feedback about webcams we have so that they get supported? I know that that is a lame question but I had to ask it. Cheers, Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From valent.turkovic at gmail.com Tue May 27 10:28:59 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 27 May 2008 12:28:59 +0200 Subject: libflashsupport In-Reply-To: <20080523235451.GA8466@tango.0pointer.de> References: <48372911.9010502@fedoraproject.org> <20080523205114.GB29875@nostromo.devel.redhat.com> <1211585673.3566.120.camel@cookie.hadess.net> <20080523235451.GA8466@tango.0pointer.de> Message-ID: <64b14b300805270328k3b1039c1k3f5d9971ca6307a7@mail.gmail.com> On Sat, May 24, 2008 at 1:54 AM, Lennart Poettering wrote: > On Sat, 24.05.08 00:34, Bastien Nocera (bnocera at redhat.com) wrote: > >> >> On Fri, 2008-05-23 at 16:51 -0400, Bill Nottingham wrote: >> > Rahul Sundaram (sundaram at fedoraproject.org) said: >> > > It seems libflashsupport was dropped out of the default package list in >> > > Fedora 9 and I didn't see any public discussion on the reasons behind this >> > > change (release notes didn't get updated either until recently >> > > unfortunately) Can someone familiar with this change explain the reason? >> > >> > Check the FESCo logs... general reasoning is that it existed solely >> > as a crutch for third-party software, IIRC. >> >> And I'm sure the people who came up with that idea made sure to nicely >> ask Adobe to make their Flash plugins depend on it. Or explained to them >> what that tool did so they can fix their software. > > Adobe Flash 10 doesn't need libflashsupport anymore to work fine on > ALSA ioplug-based backends such as pulse. > > Lennart Current version of Flash 10 doesn't work with Firefox under linux. Cheers, Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From valent.turkovic at gmail.com Tue May 27 10:37:23 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 27 May 2008 12:37:23 +0200 Subject: SWFdec vs Gnash (also gcjwebplugin) In-Reply-To: References: <1210804636.27281.5.camel@trinity.blade> Message-ID: <64b14b300805270337x3e851498jfd1fce410d0da654@mail.gmail.com> On Thu, May 15, 2008 at 12:49 AM, Pavel Shevchuk wrote: > swfdec depends on less gnome-libs, and at least for me it works much > better than gnash. It also has very nice "click to enable" feature For me this is the most irritating feature of swfdec, so your mileage may vary. How can I disable that feature? Also swfdec depends on gstreamer-ffmpeg packages that aren't in fedora repository. AFAIK gnash doesn't have such disadvantage. Cheers, Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From rawhide at fedoraproject.org Tue May 27 10:39:24 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Tue, 27 May 2008 10:39:24 +0000 (UTC) Subject: rawhide report: 20080527 changes Message-ID: <20080527103924.3AAF4209CC4@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080526/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080527/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package libusb1 A library which allows userspace access to USB devices New package phplogcon A syslog data viewer for the web New package xfce4-dict A Dictionary Client for the Xfce desktop environment Updated Packages: R-multtest-1.20.0-1.fc10 ------------------------ * Mon May 26 18:00:00 2008 pingou 1.20.0-1 - Update to version 1.20.0 R-tkWidgets-1.18.0-1.fc10 ------------------------- * Tue May 27 18:00:00 2008 pingou 1.18.0-1 - Update to version 1.18.0 R-widgetTools-1.16.0-3.fc10 --------------------------- * Tue May 27 18:00:00 2008 pingou 1.16.0-3 - Change in Source1 * Tue May 27 18:00:00 2008 pingou 1.16.0-2 - Change in Source1 - Change in the url * Tue May 27 18:00:00 2008 pingou 1.16.0-1 - Update to version 1.16.0 * Sat Feb 9 17:00:00 2008 Pingou 1.15.0-3 - Correct typo error on the URL akonadi-0.81.0-0.1.20080526svn812787.fc10 ----------------------------------------- * Mon May 26 18:00:00 2008 Kevin Kofler 0.81.0-0.1.20080526svn812787 - update to revision 812787 from KDE SVN (to match KDE 4.1 Beta 1) - restore builtin automoc4 for now - update file list, require pkgconfig in -devel (.pc file now included) alliance-5.0-15.20070718snap.fc10 --------------------------------- * Mon May 26 18:00:00 2008 Chitlesh Goorah - 5.0-15.20070718snap - Bugfix: error in postinstall scriptlet: /etc/profile.d/alc_env.sh not found #442379 - Bugfix: /etc/profile.d/alc_env.csh assumes MANPATH is preset #440083 * Tue May 20 18:00:00 2008 Thibault North < tnorth [AT] fedoraproject DOT org> - 5.0-14.20070718snap - Add to Electronics Menu anjuta-2.4.1-1.fc10 ------------------- * Sat May 24 18:00:00 2008 Debarshi Ray - 1:2.4.1-1 - Version bump to 2.4.1. Closes Red Hat Bugzilla bug #446242. - Spurious file modification messages from Scintilla fixed by upstream. Closes Red Hat Bugzilla bug #447090. * Tue May 13 18:00:00 2008 Debarshi Ray - 1:2.2.3-8 - Added missing header to fix build failure on ia64. Closes Red Hat Bugzilla bug #446020. bind-9.5.0-35.rc1.fc10 ---------------------- * Mon May 26 18:00:00 2008 Adam Tkac 32:9.5.0-35.rc1 - make /var/run/named writable by named (#448277) - fixed one non-utf8 file Broken deps for i386 ---------------------------------------------------------- LabPlot-1.5.1.6-4.fc8.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libMagick.so.10 avahi-ui-sharp-0.6.22-10.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 avahi-ui-sharp-0.6.22-10.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 basket-kontact-1.0.2-5.fc9.i386 requires libkpinterfaces.so.1 basket-kontact-1.0.2-5.fc9.i386 requires libkcal.so.2 basket-kontact-1.0.2-5.fc9.i386 requires libktnef.so.1 basket-kontact-1.0.2-5.fc9.i386 requires kdepim3 basket-kontact-1.0.2-5.fc9.i386 requires libkdepim.so.1 beagle-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-evolution-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-thunderbird-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 bibletime-1.6.5-4.fc9.i386 requires libsword-1.5.10.so compiz-kde-0.7.2-4.fc10.i386 requires libplasma.so.1 dsniff-2.4-0.2.b1.fc9.i386 requires libnids.so.1.21 evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-sharp-0.17.2-1.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.i386 requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-1.2.so.11 extragear-plasma-4.0.72-0.1.20080506svn804581.fc10.i386 requires libplasma.so.1 f-spot-0.4.3.1-1.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.i386 requires mono(glade-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gmime-sharp-2.2.19-1.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(atk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(glade-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(pango-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gnomesword-2.3.3-2.fc9.i386 requires libsword-1.5.10.so gsf-sharp-0.8.1-7.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.i386 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 ipod-sharp-0.8.0-4.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 ipod-sharp-0.8.0-4.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 ipod-sharp-0.8.0-4.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 kdebindings-4.0.72-1.fc10.i386 requires libplasma.so.1 kdeedu-4.0.72-3.fc10.i386 requires libplasma.so.1 7:kdenetwork-4.0.72-2.fc10.i386 requires libplasma.so.1 kdesdk-4.0.72-2.fc10.i386 requires libplasma.so.1 6:kdeutils-4.0.72-1.fc10.i386 requires libplasma.so.1 kio_sword-0.3-6.fc9.i386 requires libsword-1.5.10.so kismet-extras-0.0.2007.10.R1-3.fc9.i386 requires libMagick.so.10 koffice-karbon-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-karbon-1.6.3-15.fc9.i386 requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libMagick.so.10 libopensync-plugin-kdepim-0.35-2.fc9.i386 requires libkcal.so.2 lsvpd-1.6.4-1.fc10.i386 requires libvpd_cxx-2.0.so.1 mono-addins-0.3.1-1.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 mono-addins-0.3.1-1.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 mono-addins-0.3.1-1.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 mono-addins-0.3.1-1.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.i386 requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.i386 requires libgeos.so.2 smart-0.52-54.fc9.i386 requires smart-config taskjuggler-2.4.1-1.fc10.i386 requires libkcal.so.2 taskjuggler-2.4.1-1.fc10.i386 requires libktnef.so.1 taskjuggler-libs-2.4.1-1.fc10.i386 requires libkcal.so.2 tomboy-0.10.1-2.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.i386 requires mono(pango-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 Broken deps for x86_64 ---------------------------------------------------------- LabPlot-1.5.1.6-4.fc8.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.i386 requires libMagick.so.10 LabPlot-1.5.1.6-4.fc8.x86_64 requires libMagick++.so.10()(64bit) LabPlot-1.5.1.6-4.fc8.x86_64 requires libMagick.so.10()(64bit) LabPlot-1.5.1.6-4.fc8.x86_64 requires libWand.so.10()(64bit) avahi-ui-sharp-0.6.22-10.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 avahi-ui-sharp-0.6.22-10.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 basket-kontact-1.0.2-5.fc9.x86_64 requires libkcal.so.2()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires libkdepim.so.1()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires libktnef.so.1()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires kdepim3 basket-kontact-1.0.2-5.fc9.x86_64 requires libkpinterfaces.so.1()(64bit) beagle-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-evolution-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-thunderbird-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 bibletime-1.6.5-4.fc9.x86_64 requires libsword-1.5.10.so()(64bit) compiz-kde-0.7.2-4.fc10.x86_64 requires libplasma.so.1()(64bit) dsniff-2.4-0.2.b1.fc9.x86_64 requires libnids.so.1.21()(64bit) evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libWand.so.10()(64bit) evolution-sharp-0.17.2-1.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) extragear-plasma-4.0.72-0.1.20080506svn804581.fc10.i386 requires libplasma.so.1 extragear-plasma-4.0.72-0.1.20080506svn804581.fc10.x86_64 requires libplasma.so.1()(64bit) f-spot-0.4.3.1-1.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx gbrainy-0.61-5.fc9.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gmime-sharp-2.2.19-1.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(atk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gnomesword-2.3.3-2.fc9.x86_64 requires libsword-1.5.10.so()(64bit) gsf-sharp-0.8.1-7.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 ipod-sharp-0.8.0-4.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 ipod-sharp-0.8.0-4.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 ipod-sharp-0.8.0-4.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 kdebindings-4.0.72-1.fc10.i386 requires libplasma.so.1 kdebindings-4.0.72-1.fc10.x86_64 requires libplasma.so.1()(64bit) kdeedu-4.0.72-3.fc10.x86_64 requires libplasma.so.1()(64bit) 7:kdenetwork-4.0.72-2.fc10.x86_64 requires libplasma.so.1()(64bit) kdesdk-4.0.72-2.fc10.x86_64 requires libplasma.so.1()(64bit) 6:kdeutils-4.0.72-1.fc10.i386 requires libplasma.so.1 6:kdeutils-4.0.72-1.fc10.x86_64 requires libplasma.so.1()(64bit) kio_sword-0.3-6.fc9.x86_64 requires libsword-1.5.10.so()(64bit) kismet-extras-0.0.2007.10.R1-3.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.x86_64 requires libWand.so.10()(64bit) koffice-libs-1.6.3-15.fc9.i386 requires libWand.so.10 koffice-libs-1.6.3-15.fc9.i386 requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.x86_64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.x86_64 requires libWand.so.10()(64bit) libopensync-plugin-kdepim-0.35-2.fc9.x86_64 requires libkcal.so.2()(64bit) lsvpd-1.6.4-1.fc10.x86_64 requires libvpd_cxx-2.0.so.1()(64bit) mono-addins-0.3.1-1.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 mono-addins-0.3.1-1.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 mono-addins-0.3.1-1.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 mono-addins-0.3.1-1.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) smart-0.52-54.fc9.x86_64 requires smart-config taskjuggler-2.4.1-1.fc10.x86_64 requires libkcal.so.2()(64bit) taskjuggler-2.4.1-1.fc10.x86_64 requires libktnef.so.1()(64bit) taskjuggler-libs-2.4.1-1.fc10.i386 requires libkcal.so.2 taskjuggler-libs-2.4.1-1.fc10.x86_64 requires libkcal.so.2()(64bit) tomboy-0.10.1-2.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 Broken deps for ppc ---------------------------------------------------------- LabPlot-1.5.1.6-4.fc8.ppc requires libMagick++.so.10 LabPlot-1.5.1.6-4.fc8.ppc requires libWand.so.10 LabPlot-1.5.1.6-4.fc8.ppc requires libMagick.so.10 avahi-ui-sharp-0.6.22-10.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 avahi-ui-sharp-0.6.22-10.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 basket-kontact-1.0.2-5.fc9.ppc requires libkpinterfaces.so.1 basket-kontact-1.0.2-5.fc9.ppc requires libkcal.so.2 basket-kontact-1.0.2-5.fc9.ppc requires libktnef.so.1 basket-kontact-1.0.2-5.fc9.ppc requires kdepim3 basket-kontact-1.0.2-5.fc9.ppc requires libkdepim.so.1 beagle-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 beagle-evolution-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 beagle-thunderbird-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 bibletime-1.6.5-4.fc9.ppc requires libsword-1.5.10.so compiz-kde-0.7.2-4.fc10.ppc requires libplasma.so.1 dsniff-2.4-0.2.b1.fc9.ppc requires libnids.so.1.21 evolution-brutus-1.2.11-2.fc9.ppc requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.ppc requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.ppc requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-sharp-0.17.2-1.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.ppc requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-1.2.so.11 extragear-plasma-4.0.72-0.1.20080506svn804581.fc10.ppc requires libplasma.so.1 extragear-plasma-4.0.72-0.1.20080506svn804581.fc10.ppc64 requires libplasma.so.1()(64bit) f-spot-0.4.3.1-1.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.ppc requires mono(glade-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gmime-sharp-2.2.19-1.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(atk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(glade-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(pango-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gnomesword-2.3.3-2.fc9.ppc requires libsword-1.5.10.so gsf-sharp-0.8.1-7.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.ppc requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 ipod-sharp-0.8.0-4.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 ipod-sharp-0.8.0-4.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 ipod-sharp-0.8.0-4.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 kdebindings-4.0.72-1.fc10.ppc requires libplasma.so.1 kdebindings-4.0.72-1.fc10.ppc64 requires libplasma.so.1()(64bit) kdeedu-4.0.72-3.fc10.ppc requires libplasma.so.1 7:kdenetwork-4.0.72-2.fc10.ppc requires libplasma.so.1 kdesdk-4.0.72-2.fc10.ppc requires libplasma.so.1 6:kdeutils-4.0.72-1.fc10.ppc requires libplasma.so.1 6:kdeutils-4.0.72-1.fc10.ppc64 requires libplasma.so.1()(64bit) kio_sword-0.3-6.fc9.ppc requires libsword-1.5.10.so kismet-extras-0.0.2007.10.R1-3.fc9.ppc requires libMagick.so.10 koffice-karbon-1.6.3-15.fc9.ppc requires libWand.so.10 koffice-karbon-1.6.3-15.fc9.ppc requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.ppc requires libWand.so.10 koffice-libs-1.6.3-15.fc9.ppc requires libMagick.so.10 koffice-libs-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) libopensync-plugin-kdepim-0.35-2.fc9.ppc requires libkcal.so.2 lsvpd-1.6.4-1.fc10.ppc requires libvpd_cxx-2.0.so.1 mono-addins-0.3.1-1.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 mono-addins-0.3.1-1.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 mono-addins-0.3.1-1.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 mono-addins-0.3.1-1.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.ppc requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.ppc requires libgeos.so.2 smart-0.52-54.fc9.ppc requires smart-config taskjuggler-2.4.1-1.fc10.ppc requires libkcal.so.2 taskjuggler-2.4.1-1.fc10.ppc requires libktnef.so.1 taskjuggler-libs-2.4.1-1.fc10.ppc requires libkcal.so.2 taskjuggler-libs-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) tomboy-0.10.1-2.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.ppc requires mono(pango-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 Broken deps for ppc64 ---------------------------------------------------------- basket-kontact-1.0.2-5.fc9.ppc64 requires libkcal.so.2()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires libkdepim.so.1()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires libktnef.so.1()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires kdepim3 basket-kontact-1.0.2-5.fc9.ppc64 requires libkpinterfaces.so.1()(64bit) bibletime-1.6.5-4.fc9.ppc64 requires libsword-1.5.10.so()(64bit) dsniff-2.4-0.2.b1.fc9.ppc64 requires libnids.so.1.21()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) extragear-plasma-4.0.72-0.1.20080506svn804581.fc10.ppc64 requires libplasma.so.1()(64bit) gnomesword-2.3.3-2.fc9.ppc64 requires libsword-1.5.10.so()(64bit) kdebindings-4.0.72-1.fc10.ppc64 requires libplasma.so.1()(64bit) kdeedu-4.0.72-3.fc10.ppc64 requires libplasma.so.1()(64bit) 7:kdenetwork-4.0.72-2.fc10.ppc64 requires libplasma.so.1()(64bit) kdesdk-4.0.72-2.fc10.ppc64 requires libplasma.so.1()(64bit) 6:kdeutils-4.0.72-1.fc10.ppc64 requires libplasma.so.1()(64bit) kio_sword-0.3-6.fc9.ppc64 requires libsword-1.5.10.so()(64bit) kismet-extras-0.0.2007.10.R1-3.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-karbon-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libMagick.so.10()(64bit) koffice-libs-1.6.3-15.fc9.ppc64 requires libWand.so.10()(64bit) libopensync-plugin-kdepim-0.35-2.fc9.ppc64 requires libkcal.so.2()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot lsvpd-1.6.4-1.fc10.ppc64 requires libvpd_cxx-2.0.so.1()(64bit) perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) smart-0.52-54.fc9.ppc64 requires smart-config taskjuggler-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) taskjuggler-2.4.1-1.fc10.ppc64 requires libktnef.so.1()(64bit) taskjuggler-libs-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) From pertusus at free.fr Tue May 27 10:42:40 2008 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 27 May 2008 12:42:40 +0200 Subject: SWFdec vs Gnash (also gcjwebplugin) In-Reply-To: <64b14b300805270337x3e851498jfd1fce410d0da654@mail.gmail.com> References: <1210804636.27281.5.camel@trinity.blade> <64b14b300805270337x3e851498jfd1fce410d0da654@mail.gmail.com> Message-ID: <20080527104240.GB2595@free.fr> On Tue, May 27, 2008 at 12:37:23PM +0200, Valent Turkovic wrote: > On Thu, May 15, 2008 at 12:49 AM, Pavel Shevchuk wrote: > > swfdec depends on less gnome-libs, and at least for me it works much > > better than gnash. It also has very nice "click to enable" feature > > For me this is the most irritating feature of swfdec, so your mileage > may vary. How can I disable that feature? > Also swfdec depends on gstreamer-ffmpeg packages that aren't in fedora > repository. AFAIK gnash doesn't have such disadvantage. gnash also depends on gstreamer-ffmpeg for flv and mp3 audio. -- Pat From ivazqueznet at gmail.com Tue May 27 10:44:18 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Tue, 27 May 2008 06:44:18 -0400 Subject: libflashsupport In-Reply-To: <64b14b300805270328k3b1039c1k3f5d9971ca6307a7@mail.gmail.com> References: <48372911.9010502@fedoraproject.org> <20080523205114.GB29875@nostromo.devel.redhat.com> <1211585673.3566.120.camel@cookie.hadess.net> <20080523235451.GA8466@tango.0pointer.de> <64b14b300805270328k3b1039c1k3f5d9971ca6307a7@mail.gmail.com> Message-ID: <1211885058.4081.9.camel@ignacio.lan> On Tue, 2008-05-27 at 12:28 +0200, Valent Turkovic wrote: > Current version of Flash 10 doesn't work with Firefox under linux. I have 10.0 b218 working just fine with nspluginwrapper on both F8 i386 and x86_64. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From valent.turkovic at gmail.com Tue May 27 10:45:12 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 27 May 2008 12:45:12 +0200 Subject: SWFdec vs Gnash (also gcjwebplugin) In-Reply-To: <20080527104240.GB2595@free.fr> References: <1210804636.27281.5.camel@trinity.blade> <64b14b300805270337x3e851498jfd1fce410d0da654@mail.gmail.com> <20080527104240.GB2595@free.fr> Message-ID: <64b14b300805270345h450b7b06q60eb0a3d88e23e8b@mail.gmail.com> On Tue, May 27, 2008 at 12:42 PM, Patrice Dumas wrote: > On Tue, May 27, 2008 at 12:37:23PM +0200, Valent Turkovic wrote: >> On Thu, May 15, 2008 at 12:49 AM, Pavel Shevchuk wrote: >> > swfdec depends on less gnome-libs, and at least for me it works much >> > better than gnash. It also has very nice "click to enable" feature >> >> For me this is the most irritating feature of swfdec, so your mileage >> may vary. How can I disable that feature? >> Also swfdec depends on gstreamer-ffmpeg packages that aren't in fedora >> repository. AFAIK gnash doesn't have such disadvantage. > > gnash also depends on gstreamer-ffmpeg for flv and mp3 audio. Ok, my bad. If anybody knows how to disable "click to enable" feature of swfdec please share the info. Cheers, Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From panemade at gmail.com Tue May 27 10:51:11 2008 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Tue, 27 May 2008 16:21:11 +0530 Subject: Announcing a new F-10 Feature Proposal: Better Webcam Support In-Reply-To: <64b14b300805270325t35757e05w48939b6c799dd98e@mail.gmail.com> References: <4836DA23.3090709@hhs.nl> <20080523152426.GB3224@nostromo.devel.redhat.com> <1211559657.3566.97.camel@cookie.hadess.net> <48372673.5020703@hhs.nl> <1211585885.3566.124.camel@cookie.hadess.net> <4837A8E3.5010908@hhs.nl> <64b14b300805270325t35757e05w48939b6c799dd98e@mail.gmail.com> Message-ID: Hi , On Tue, May 27, 2008 at 3:55 PM, Valent Turkovic wrote: > On Sat, May 24, 2008 at 7:34 AM, Hans de Goede wrote: >> Bastien Nocera wrote: >>> >>> On Fri, 2008-05-23 at 22:17 +0200, Hans de Goede wrote: >>>> >>>> Bastien Nocera wrote: >>>>> >>>>> On Fri, 2008-05-23 at 11:24 -0400, Bill Nottingham wrote: >>>>>> >>>>>> Hans de Goede (j.w.r.degoede at hhs.nl) said: >>>>>>> >>>>>>> See: >>>>>>> >>>>>>> http://fedoraproject.org/wiki/Features/BetterWebcamSupport >>>>>> >>>>>> Any reason a shim library is simpler than porting apps to V4L2? >>>>> >>>>> Same question here. There's a good number of applications that are >>>>> either obsoleted by a v4l2 version, or support both versions. Which >>>>> applications were you thinking of supporting with this scheme? >>>>> >>>>> Unless there's tens of open source apps that would need changing, or a >>>>> couple of (useful) proprietary ones that don't support v4l2, the library >>>>> is probably not very useful to have (especially as you probably wouldn't >>>>> be able to port _all_ the v4l1 drivers to v4l2). >>>>> >>>> See my reaction to Bill's question, and yes there are a few usefull >>>> proprietary apps in the mix unfortunately. >>> >>> Do you have a list of those apps? Both the proprietary ones and the Open >>> Source ones. For the latter, it could be more interesting to create a >>> guide for the conversion from V4L1 to V4L2, and see whether Fedora >>> maintainers of those projects can help out with the conversion, or at >>> least submit it upstream for consideration. >>> >> >> No list atm, noteworthy closed source ones are flash (adobe version) and >> skype. Opensource v4l1 viewers I know about are camomara, spcaview. But >> quite a few v4l2 apps also don't work with all v4l2 cams due to not >> supporting all needed colorformats, examples of these are for example xawtv >> and luvcview. >> >> I must say my primary focus at the moment is getting drivers cleaned up and >> merged in the mainline, but the userspace side of things definetely needs >> work too. >> >> Regards, >> >> Hans > > Is there something that Fedora users with few webcams that aren't > recognised under Fedora because of non-existing drivers can do to > help? Is there some way that we can give you feedback about webcams we > have so that they get supported? I know that that is a lame question > but I had to ask it. you can report your feedback to that respective webcam driver's upstream project mailing list. e.g. 1) If you got your webcam working using uvcvideo driver then you can report to uvc mailing list linux-uvc-devel at lists.berlios.de. also check http://linux-uvc.berlios.de/ 1) If you got your webcam working using gscpa driver then you can report to gspca mailing list spca50x-devs at lists.sourceforge.net. Regards, Parag. From mzerqung at 0pointer.de Tue May 27 10:52:27 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 27 May 2008 12:52:27 +0200 Subject: libflashsupport In-Reply-To: <64b14b300805270328k3b1039c1k3f5d9971ca6307a7@mail.gmail.com> References: <48372911.9010502@fedoraproject.org> <20080523205114.GB29875@nostromo.devel.redhat.com> <1211585673.3566.120.camel@cookie.hadess.net> <20080523235451.GA8466@tango.0pointer.de> <64b14b300805270328k3b1039c1k3f5d9971ca6307a7@mail.gmail.com> Message-ID: <20080527105227.GA17076@tango.0pointer.de> On Tue, 27.05.08 12:28, Valent Turkovic (valent.turkovic at gmail.com) wrote: > > Adobe Flash 10 doesn't need libflashsupport anymore to work fine on > > ALSA ioplug-based backends such as pulse. > > > > Lennart > > Current version of Flash 10 doesn't work with Firefox under linux. Thanks for sharing this elaborate error description with us! Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From ben.lewis at benl.co.uk Tue May 27 10:54:54 2008 From: ben.lewis at benl.co.uk (Benjamin Lewis) Date: Tue, 27 May 2008 11:54:54 +0100 Subject: Fedora project: making a website with Fedora-Free music In-Reply-To: <483BDA91.9020008@hhs.nl> References: <483BDA91.9020008@hhs.nl> Message-ID: <200805271154.59011.ben.lewis@benl.co.uk> On Tuesday 27 May 2008 10:55:29 Hans de Goede wrote: > Hi All, > > Today I've been discussing with upstream replacing some non free music with > Free music, as I need to do often when packaging games (in this case Lost > Labyrinth). > > I have been thinking recently about how convenient it would be to have a > website where one can browse all known Fedora-Free (as in can be part of > Fedora under the content Licensing guidelines) music. > > The Fedora package collection already contains quite a bit of music. Some > put in -music packages because its in ogg format and thus quite large, but > also quite a few modtracker and midi format songs, which are much smaller > and sometimes even hidden away in .wad / .dat files. > > Thus I want to make a website with: > -Unpacked (as in click on it and it will play) versions of all music > included in Fedora, sorted by format and license, and preferably also > catogorised by genre. > > -Links to other website which contain all Free, or clearly marked partially > Free music. > > The first website which comes mind for the links section is the > excellent: http://www.dogmazic.net/ > > > So now I need 2 things > 1) Free (as in gratis) hosting, with lots of diskspace and potentially > quite some bandwidth usage. > > 2) Someone to help me build the website, the last time I've done php / html > was in 1999 :) > I would be willing to help with no. 2, although I can't really help with the hosting as mine is in a state of serious flux atm and really dosn't have enough diskspace. > > 1) Is the most urgent without 2 I'll just create a few folders like this: > > mod > mod/GPL > mod/CC-xx > mod/CC-Nd-xx > midi > midi/GPL > midi/CC-xx > midi/CC-Nd-xx > ogg > ogg/GPL > ogg/CC-xx > ogg/CC-Nd-xx > links > links/index.html (good old html-1.0 list with links) > > And use apache's dir listing as html generator :) I know this is crude, but > it still beats not having any central place to checkout all the music > already in Fedora at all by a long shot. > > Regards, > > Hans -- Benjamin Lewis Fedora Ambassador - http://fedoraproject.org./ ben.lewis at benl.co.uk ----------------------------------------------------------------------- http://benl.co.uk./ PGP Key: 0x647E480C "In cases of major discrepancy, it is always reality that got it wrong" -- RFC 1118 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: From valent.turkovic at gmail.com Tue May 27 10:58:50 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 27 May 2008 12:58:50 +0200 Subject: Fedora 10 and flash? Message-ID: <64b14b300805270358m21391353kb3e963ebfa054c4a@mail.gmail.com> Hi, I must share this report with you. I don't use Ubuntu but I installed it on one PC in a lab for students and kids to learn using it (we have half Fedora and half Ubuntu lab). I opened Firefox and went to www.redhatmagazine.com and immediately I got a pop up window with a choice to install Adobe Flash, Swhdec or Gnash plugin. I was amazed how well this worked and that I had a choice to pick any one plugin that I believe it better. I know about Fedora's upstream mentality but I must take my hat to Ubuntu devels for making their "Ubuntu plugin service" work great. I know that this is what Mozilla should have made but with their track for supporting linux isn't the best one. And also I see some projects that fedora made and didn't wait for the others but fedora and red hat devels made them because they were missing (pulseaudio, networkmanager, and lots of others...) so does it make sense to you that Fedora makes also "Fedor plugin service" for Fedora 10 or do you believe that if it is not in Firefox by default than Fedora should not touch it in anyway? Why? Cheers, Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From valent.turkovic at gmail.com Tue May 27 11:06:18 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 27 May 2008 13:06:18 +0200 Subject: Fedora 10 and flash? In-Reply-To: <64b14b300805270358m21391353kb3e963ebfa054c4a@mail.gmail.com> References: <64b14b300805270358m21391353kb3e963ebfa054c4a@mail.gmail.com> Message-ID: <64b14b300805270406o782576c6j659de3cf81f88d18@mail.gmail.com> I have a correction, it is called "Plugin finder service" and not "Ubuntu plugin service" and here are the screenshots: http://www.uploadgeek.com/uploads456/0/Prikaz_zaslona-Plugin Finder Service.png http://www.uploadgeek.com/uploads456/0/Prikaz_zaslona.png http://www.uploadgeek.com/uploads456/0/Prikaz_zaslona-2.png http://www.uploadgeek.com/uploads456/0/Prikaz_zaslona-3.png http://www.uploadgeek.com/uploads456/0/Prikaz_zaslona-4.png http://www.uploadgeek.com/uploads456/0/Prikaz_zaslona-5.png http://www.uploadgeek.com/uploads456/0/Prikaz_zaslona-Install multimedia codecs-1.png Cheers, Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From nicu_fedora at nicubunu.ro Tue May 27 11:07:41 2008 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Tue, 27 May 2008 14:07:41 +0300 Subject: Fedora project: making a website with Fedora-Free music In-Reply-To: <483BDA91.9020008@hhs.nl> References: <483BDA91.9020008@hhs.nl> Message-ID: <483BEB7D.1080200@nicubunu.ro> Hans de Goede wrote: > Today I've been discussing with upstream replacing some non free music > with Free music, as I need to do often when packaging games (in this > case Lost Labyrinth). > > I have been thinking recently about how convenient it would be to have a > website where one can browse all known Fedora-Free (as in can be part of > Fedora under the content Licensing guidelines) music. Free enough that we can use also as a soundtrack for screencasts (that's is, if someone likes game music as sountreact for his screencast) > The Fedora package collection already contains quite a bit of music. > Some put in -music packages because its in ogg format and thus quite > large, but also quite a few modtracker and midi format songs, which are > much smaller and sometimes even hidden away in .wad / .dat files. > > Thus I want to make a website with: > -Unpacked (as in click on it and it will play) versions of all music > included > in Fedora, sorted by format and license, and preferably also > catogorised by > genre. > > -Links to other website which contain all Free, or clearly marked partially > Free music. > > The first website which comes mind for the links section is the excellent: > http://www.dogmazic.net/ Or like this http://ccmixter.org/ ? > So now I need 2 things > 1) Free (as in gratis) hosting, with lots of diskspace and potentially > quite > some bandwidth usage. > > 2) Someone to help me build the website, the last time I've done php / > html was > in 1999 :) How about using ccHost, the software used by (and made for) ccMixter? The problem is that it may need support for some file formats > 1) Is the most urgent without 2 I'll just create a few folders like this: > > mod > mod/GPL > mod/CC-xx > mod/CC-Nd-xx > midi > midi/GPL > midi/CC-xx > midi/CC-Nd-xx > ogg > ogg/GPL > ogg/CC-xx > ogg/CC-Nd-xx > links > links/index.html (good old html-1.0 list with links) > > And use apache's dir listing as html generator :) I know this is crude, > but it still beats not having any central place to checkout all the > music already in Fedora at all by a long shot. -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From j.w.r.degoede at hhs.nl Tue May 27 11:10:45 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 27 May 2008 13:10:45 +0200 Subject: Announcing a new F-10 Feature Proposal: Better Webcam Support In-Reply-To: <64b14b300805270325t35757e05w48939b6c799dd98e@mail.gmail.com> References: <4836DA23.3090709@hhs.nl> <20080523152426.GB3224@nostromo.devel.redhat.com> <1211559657.3566.97.camel@cookie.hadess.net> <48372673.5020703@hhs.nl> <1211585885.3566.124.camel@cookie.hadess.net> <4837A8E3.5010908@hhs.nl> <64b14b300805270325t35757e05w48939b6c799dd98e@mail.gmail.com> Message-ID: <483BEC35.8030906@hhs.nl> Valent Turkovic wrote: > On Sat, May 24, 2008 at 7:34 AM, Hans de Goede wrote: >> Bastien Nocera wrote: >>> On Fri, 2008-05-23 at 22:17 +0200, Hans de Goede wrote: >>>> Bastien Nocera wrote: >>>>> On Fri, 2008-05-23 at 11:24 -0400, Bill Nottingham wrote: >>>>>> Hans de Goede (j.w.r.degoede at hhs.nl) said: >>>>>>> See: >>>>>>> >>>>>>> http://fedoraproject.org/wiki/Features/BetterWebcamSupport >>>>>> Any reason a shim library is simpler than porting apps to V4L2? >>>>> Same question here. There's a good number of applications that are >>>>> either obsoleted by a v4l2 version, or support both versions. Which >>>>> applications were you thinking of supporting with this scheme? >>>>> >>>>> Unless there's tens of open source apps that would need changing, or a >>>>> couple of (useful) proprietary ones that don't support v4l2, the library >>>>> is probably not very useful to have (especially as you probably wouldn't >>>>> be able to port _all_ the v4l1 drivers to v4l2). >>>>> >>>> See my reaction to Bill's question, and yes there are a few usefull >>>> proprietary apps in the mix unfortunately. >>> Do you have a list of those apps? Both the proprietary ones and the Open >>> Source ones. For the latter, it could be more interesting to create a >>> guide for the conversion from V4L1 to V4L2, and see whether Fedora >>> maintainers of those projects can help out with the conversion, or at >>> least submit it upstream for consideration. >>> >> No list atm, noteworthy closed source ones are flash (adobe version) and >> skype. Opensource v4l1 viewers I know about are camomara, spcaview. But >> quite a few v4l2 apps also don't work with all v4l2 cams due to not >> supporting all needed colorformats, examples of these are for example xawtv >> and luvcview. >> >> I must say my primary focus at the moment is getting drivers cleaned up and >> merged in the mainline, but the userspace side of things definetely needs >> work too. >> >> Regards, >> >> Hans > > Is there something that Fedora users with few webcams that aren't > recognised under Fedora because of non-existing drivers can do to > help? Is there some way that we can give you feedback about webcams we > have so that they get supported? I know that that is a lame question > but I had to ask it. > Well, there always is a chance it is supported but the usb id isn't registered as such yet, do you know which usb controller / bridge the webcam uses and which ccd sensor? Otherwise try installing the windows drivers (under wine for example) and look through the .inf files / use strings on the binaries for hints. Regards, Hans From mcepl at redhat.com Tue May 27 11:29:25 2008 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 27 May 2008 13:29:25 +0200 Subject: Fedora 10 and flash? References: <64b14b300805270358m21391353kb3e963ebfa054c4a@mail.gmail.com> <64b14b300805270406o782576c6j659de3cf81f88d18@mail.gmail.com> Message-ID: On Tue, 27 May 2008 13:06:18 +0200, Valent Turkovic scripst: > I have a correction, it is called "Plugin finder service" and not > "Ubuntu plugin service" and here are the screenshots: And here is the bug in RH Bugzilla about it -- http:// bugzilla.redhat.com/432957. Matej -- The content of this message is licensed under a Creative Commons Attribution 3.0 License, Some Rights Reserved. http://creativecommons.org/licenses/by/3.0/us/ From jwboyer at gmail.com Tue May 27 11:31:07 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 27 May 2008 06:31:07 -0500 Subject: Orphaning my Packages (or: RIP, Fedora!) In-Reply-To: <483B8450.6070505@theholbrooks.org> References: <483B8450.6070505@theholbrooks.org> Message-ID: <20080527063107.4b582788@vader.jdub.homelinux.org> On Mon, 26 May 2008 22:47:28 -0500 Brandon Holbrook wrote: > Denis Leroy said throughout this process that such a blanket policy was > shortsighted, would hurt Fedora more than it helped, and drive people > away to other distros. He was right, I'm one of those people. Good > luck clinging to your "principles", Fedora, and farewell. Contrary to your statement, I believe our number of users is growing. At any rate, we wish you well. josh From jspaleta at gmail.com Tue May 27 11:34:43 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 27 May 2008 03:34:43 -0800 Subject: Fedora 10 and flash? In-Reply-To: <64b14b300805270358m21391353kb3e963ebfa054c4a@mail.gmail.com> References: <64b14b300805270358m21391353kb3e963ebfa054c4a@mail.gmail.com> Message-ID: <604aa7910805270434n58ead5b4sed85dec5c48aa832@mail.gmail.com> On Tue, May 27, 2008 at 2:58 AM, Valent Turkovic wrote: > Hi, I must share this report with you. > I don't use Ubuntu but I installed it on one PC in a lab for students > and kids to learn using it (we have half Fedora and half Ubuntu lab). > I opened Firefox and went to www.redhatmagazine.com and immediately I > got a pop up window with a choice to install Adobe Flash, Swhdec or > Gnash plugin. I was amazed how well this worked and that I had a > choice to pick any one plugin that I believe it better. > I know about Fedora's upstream mentality but I must take my hat to > Ubuntu devels for making their "Ubuntu plugin service" work great. I > know that this is what Mozilla should have made but with their track > for supporting linux isn't the best one. Are you volunteering to create the necessary firefox extension and the plugin finder service implementation which mimics what Ubuntu is doing? Can you find the code that implements the service as they provide it for review? Until we know how they do it, and what data they use to do it, we don't really have a starting point worth talking about as to whether we can do what they do. I would have some concerns about running a central Fedora service, because any service Fedora would run would not be able to point at or reference a 3rd party repository at all..which would sort of defeat the point i think. I've also already had conversations with upstream Mozilla people concerning enhancing the upstream plugin finder... upstream contribution is welcome... its just a matter of people working with them. I'm not even sure we would need to run a service actually, if a client side firefox extension could intercept the plugin request and translate it into a packaging provides to send to packagekit. This is something to bring up with the packagekit developers. Regardless of whether this was upstream code or a Fedora specific extension or service... someone who cares about this would need to step forward to work on it or it's not going to go anywhere. -jef From jspaleta at gmail.com Tue May 27 11:46:08 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 27 May 2008 03:46:08 -0800 Subject: Orphaning my Packages (or: RIP, Fedora!) In-Reply-To: <20080527063107.4b582788@vader.jdub.homelinux.org> References: <483B8450.6070505@theholbrooks.org> <20080527063107.4b582788@vader.jdub.homelinux.org> Message-ID: <604aa7910805270446v4a11d87eu598ec15824b1f4e9@mail.gmail.com> On Tue, May 27, 2008 at 3:31 AM, Josh Boyer wrote: > Contrary to your statement, I believe our number of users is growing. > At any rate, we wish you well. It's difficult to get a handle on user numbers. We keep finding more and more ways to give people live images we can't track because they aren't hitting or mirrormanager looking for updates. But our contributor numbers are definitely going up. We need to start trying to identifying active/wayward/inactive/lost contributors to get a better idea of our retention rate over some timescale. Not everyone who leaves the project does it with this much...flare. There's probably some critical window of time where new contributors can show up and slip away. ..but if we keep them engaged beyond that time period the retention percentage goes up. But that's just me guessing. -jef From mfleming at enlartenment.com Tue May 27 11:48:30 2008 From: mfleming at enlartenment.com (Michael Fleming) Date: Tue, 27 May 2008 21:48:30 +1000 Subject: Orphaning my Packages (or: RIP, Fedora!) In-Reply-To: <483B8450.6070505@theholbrooks.org> References: <483B8450.6070505@theholbrooks.org> Message-ID: <20080527214830.07d92cf5@defender> On Mon, 26 May 2008 22:47:28 -0500 Brandon Holbrook wrote: > I'm happy to report that I'm finally feeing myself of everything > Fedora! Starting around a year ago Fedora's red tape and horrible > bureaucracy started turning me off. It all culminated with the > legendary "No KMODs in Fedora" blanket policy on Sept 13. So > obviously when I submitted open-vm-tools as a new package 5 days > later (I didn't know they passed such a ridiculous policy at the > time) here: https://bugzilla.redhat.com/show_bug.cgi?id=294341, it > was rejected. > > Since then I've been migrating all my boxes at home and work away > from Fedora/CentOS/RHEL to other distros and found the move to be > very refreshing. Fedora now only lives in a couple VMs here at home > for me to maintain my packages (a strange bit of irony, since it was > Fedora's unwillingness to play nicely in a VM that pushed me away to > begin with...), but I haven't even been doing a good job at that. > Therefore, I am hereby relinquishing my responsibilities of > everything Fedora, which include the following packages: > > eclipse-phpeclipse -- PHP Eclipse plugin > maradns -- Security-aware DNS Server I'll take over maradns if there's no objections. Cheers, Michael. From balajig81 at gmail.com Tue May 27 12:01:04 2008 From: balajig81 at gmail.com (G) Date: Tue, 27 May 2008 17:31:04 +0530 Subject: Orphaning my Packages (or: RIP, Fedora!) In-Reply-To: <604aa7910805270446v4a11d87eu598ec15824b1f4e9@mail.gmail.com> References: <483B8450.6070505@theholbrooks.org> <20080527063107.4b582788@vader.jdub.homelinux.org> <604aa7910805270446v4a11d87eu598ec15824b1f4e9@mail.gmail.com> Message-ID: <6dd1343e0805270501l2d2191c5s8dff31836e3c8d0a@mail.gmail.com> Hi Jef > But our contributor numbers are definitely going up. We need to > start trying to identifying active/wayward/inactive/lost contributors > to get a better idea of our retention rate over some timescale. Not > everyone who leaves the project does it with this much...flare. > There's probably some critical window of time where new contributors > can show up and slip away. ..but if we keep them engaged beyond that > time period the retention percentage goes up. But that's just me > guessing. Off late There are more contributors joinig fedora which is excellent .I feel one area that we could improve on is the statistics as you mentioned about fedora contributors and also feedback to contributors which would help the contributors to get to know that their efforts are being counted and monitored too. This would help them to get even more motivated and helps in reducing the attrition rates :) Cheers Balaji On 5/27/08, Jeff Spaleta wrote: > On Tue, May 27, 2008 at 3:31 AM, Josh Boyer wrote: > > Contrary to your statement, I believe our number of users is growing. > > At any rate, we wish you well. > > > > It's difficult to get a handle on user numbers. We keep finding more > and more ways to give people live images we can't track because they > aren't hitting or mirrormanager looking for updates. > > But our contributor numbers are definitely going up. We need to > start trying to identifying active/wayward/inactive/lost contributors > to get a better idea of our retention rate over some timescale. Not > everyone who leaves the project does it with this much...flare. > There's probably some critical window of time where new contributors > can show up and slip away. ..but if we keep them engaged beyond that > time period the retention percentage goes up. But that's just me > guessing. > > -jef > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From valent.turkovic at gmail.com Tue May 27 12:02:17 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 27 May 2008 14:02:17 +0200 Subject: Announcing a new F-10 Feature Proposal: Better Webcam Support In-Reply-To: References: <4836DA23.3090709@hhs.nl> <20080523152426.GB3224@nostromo.devel.redhat.com> <1211559657.3566.97.camel@cookie.hadess.net> <48372673.5020703@hhs.nl> <1211585885.3566.124.camel@cookie.hadess.net> <4837A8E3.5010908@hhs.nl> <64b14b300805270325t35757e05w48939b6c799dd98e@mail.gmail.com> Message-ID: <64b14b300805270502m6bfa315au7e7b6bb996f7da60@mail.gmail.com> >> Is there something that Fedora users with few webcams that aren't >> recognised under Fedora because of non-existing drivers can do to >> help? Is there some way that we can give you feedback about webcams we >> have so that they get supported? I know that that is a lame question >> but I had to ask it. > you can report your feedback to that respective webcam driver's > upstream project mailing list. e.g. > 1) If you got your webcam working using uvcvideo driver then you > can report to uvc mailing list linux-uvc-devel at lists.berlios.de. also > check http://linux-uvc.berlios.de/ I sent them a nice thank you note because my webcam on HP laptop that is working is using uvcvideo module. Here is lsusb output: Bus 001 Device 002: ID 0c45:62c0 Microdia Pavilion Webcam Cheers, Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From lordmorgul at gmail.com Tue May 27 12:03:21 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Tue, 27 May 2008 08:03:21 -0400 Subject: package reviews: show only review reqs using a particluar language ? In-Reply-To: <200805261613.45410.opensource@till.name> References: <483AA2F6.50802@iinet.net.au> <20080526115737.GA25201@amd.home.annexia.org> <200805261613.45410.opensource@till.name> Message-ID: <483BF889.9010607@gmail.com> Till Maas wrote: > On Monday 26 May 2008 13:57:37 Richard W.M. Jones wrote: > >> At the moment all OCaml related bugs have 'ocaml' in the Summary line, >> and I have some searches which are basically freeform searches which >> check for 'ocaml' in the Summary. It would be nice to have a better >> more official way to handle this. Perhaps by depending on a "master" >> bug (the same way that ExcludeArch / Blocker bugs are tracked). > > Imho the summary is a good place for this, because then one can easily check > and filter for a particular language on the review mailinglist. Also it can > be easily seen on a bug search results page. Maybe it could be agreed on a > special way to mention it in case it is not already obvious, e.g. add the > language in parenthesis after the package name, e.g. > > Review Request: foobarmatic (ruby) - some foo for bar But language as a freeform random part of summary is not very clear either. Review Request: foobarmatic c - some foo for C++ code documentation parsing Review Request: foobarmatic written in c++ - makes ruby colored slippers Review Request: foobarmatic perl - pythons on a plane Seems like use of a whiteboard status flag or tracker bug would be much more useful than trying to randomly search out those summary clues. -- Andrew Farris www.lordmorgul.net gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29 From jspaleta at gmail.com Tue May 27 12:06:19 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 27 May 2008 04:06:19 -0800 Subject: Orphaning my Packages (or: RIP, Fedora!) In-Reply-To: <6dd1343e0805270501l2d2191c5s8dff31836e3c8d0a@mail.gmail.com> References: <483B8450.6070505@theholbrooks.org> <20080527063107.4b582788@vader.jdub.homelinux.org> <604aa7910805270446v4a11d87eu598ec15824b1f4e9@mail.gmail.com> <6dd1343e0805270501l2d2191c5s8dff31836e3c8d0a@mail.gmail.com> Message-ID: <604aa7910805270506v5842a9a4x7af5fe92569e2759@mail.gmail.com> On Tue, May 27, 2008 at 4:01 AM, G wrote: > Off late There are more contributors joinig fedora which is excellent > .I feel one area that we could improve on is the statistics as you > mentioned about fedora contributors and also feedback to contributors > which would help the contributors to get to know that their efforts > are being counted and monitored too. This would help them to get even > more motivated and helps in reducing the attrition rates :) I'm all ears as to what you think is appropriate feedback. -jef From valent.turkovic at gmail.com Tue May 27 12:09:30 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 27 May 2008 14:09:30 +0200 Subject: Announcing a new F-10 Feature Proposal: Better Webcam Support In-Reply-To: <483BEC35.8030906@hhs.nl> References: <4836DA23.3090709@hhs.nl> <20080523152426.GB3224@nostromo.devel.redhat.com> <1211559657.3566.97.camel@cookie.hadess.net> <48372673.5020703@hhs.nl> <1211585885.3566.124.camel@cookie.hadess.net> <4837A8E3.5010908@hhs.nl> <64b14b300805270325t35757e05w48939b6c799dd98e@mail.gmail.com> <483BEC35.8030906@hhs.nl> Message-ID: <64b14b300805270509g179334a6xcf059c13eed8fc25@mail.gmail.com> On Tue, May 27, 2008 at 1:10 PM, Hans de Goede wrote: > Valent Turkovic wrote: >> >> On Sat, May 24, 2008 at 7:34 AM, Hans de Goede >> wrote: >>> >>> Bastien Nocera wrote: >>>> >>>> On Fri, 2008-05-23 at 22:17 +0200, Hans de Goede wrote: >>>>> >>>>> Bastien Nocera wrote: >>>>>> >>>>>> On Fri, 2008-05-23 at 11:24 -0400, Bill Nottingham wrote: >>>>>>> >>>>>>> Hans de Goede (j.w.r.degoede at hhs.nl) said: >>>>>>>> >>>>>>>> See: >>>>>>>> >>>>>>>> http://fedoraproject.org/wiki/Features/BetterWebcamSupport >>>>>>> >>>>>>> Any reason a shim library is simpler than porting apps to V4L2? >>>>>> >>>>>> Same question here. There's a good number of applications that are >>>>>> either obsoleted by a v4l2 version, or support both versions. Which >>>>>> applications were you thinking of supporting with this scheme? >>>>>> >>>>>> Unless there's tens of open source apps that would need changing, or a >>>>>> couple of (useful) proprietary ones that don't support v4l2, the >>>>>> library >>>>>> is probably not very useful to have (especially as you probably >>>>>> wouldn't >>>>>> be able to port _all_ the v4l1 drivers to v4l2). >>>>>> >>>>> See my reaction to Bill's question, and yes there are a few usefull >>>>> proprietary apps in the mix unfortunately. >>>> >>>> Do you have a list of those apps? Both the proprietary ones and the Open >>>> Source ones. For the latter, it could be more interesting to create a >>>> guide for the conversion from V4L1 to V4L2, and see whether Fedora >>>> maintainers of those projects can help out with the conversion, or at >>>> least submit it upstream for consideration. >>>> >>> No list atm, noteworthy closed source ones are flash (adobe version) and >>> skype. Opensource v4l1 viewers I know about are camomara, spcaview. But >>> quite a few v4l2 apps also don't work with all v4l2 cams due to not >>> supporting all needed colorformats, examples of these are for example >>> xawtv >>> and luvcview. >>> >>> I must say my primary focus at the moment is getting drivers cleaned up >>> and >>> merged in the mainline, but the userspace side of things definetely needs >>> work too. >>> >>> Regards, >>> >>> Hans >> >> Is there something that Fedora users with few webcams that aren't >> recognised under Fedora because of non-existing drivers can do to >> help? Is there some way that we can give you feedback about webcams we >> have so that they get supported? I know that that is a lame question >> but I had to ask it. >> > > Well, there always is a chance it is supported but the usb id isn't > registered as such yet, do you know which usb controller / bridge the webcam > uses and which ccd sensor? Otherwise try installing the windows drivers > (under wine for example) and look through the .inf files / use strings on > the binaries for hints. > > Regards, > > Hans Thank you Hans, I have opened them so I can see the chips and models of web cams. I googled them before and found that there are no drivers that work for them in Linux. Usb is working ok because it recognizes other usb devices and it recognised that something got connected... Cheers, Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From valent.turkovic at gmail.com Tue May 27 12:39:10 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 27 May 2008 14:39:10 +0200 Subject: libflashsupport In-Reply-To: <20080527105227.GA17076@tango.0pointer.de> References: <48372911.9010502@fedoraproject.org> <20080523205114.GB29875@nostromo.devel.redhat.com> <1211585673.3566.120.camel@cookie.hadess.net> <20080523235451.GA8466@tango.0pointer.de> <64b14b300805270328k3b1039c1k3f5d9971ca6307a7@mail.gmail.com> <20080527105227.GA17076@tango.0pointer.de> Message-ID: <64b14b300805270539s296d306dt5a89cb60f722b8b@mail.gmail.com> On Tue, May 27, 2008 at 12:52 PM, Lennart Poettering wrote: > On Tue, 27.05.08 12:28, Valent Turkovic (valent.turkovic at gmail.com) wrote: > >> > Adobe Flash 10 doesn't need libflashsupport anymore to work fine on >> > ALSA ioplug-based backends such as pulse. >> > >> > Lennart >> >> Current version of Flash 10 doesn't work with Firefox under linux. > > Thanks for sharing this elaborate error description with us! > > Lennart I have downloaded and installed flash10 beta from adobe via their rpm and also via .sh file under FC6 running FF3b. I have asked others on local news group and I got few reports from people using other distros that they also have issues with it not working. When I install it via rpm file then FF3 still says that I don't have Flash plugin installed, so I remove it and install it via .sh file in ~/.mozilla/plugins/ and then it doesn't complain that it doesn't have the plugin but it still doesn't show any flash videos... It this better? ;) Cheers, Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From limb at jcomserv.net Tue May 27 13:12:02 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 27 May 2008 08:12:02 -0500 (CDT) Subject: Orphaning my Packages (or: RIP, Fedora!) In-Reply-To: <483B95AD.8060404@FamilleCollet.com> References: <483B8450.6070505@theholbrooks.org> <483B95AD.8060404@FamilleCollet.com> Message-ID: <28910.198.175.55.5.1211893922.squirrel@mail.jcomserv.net> > Brandon Holbrook a ?crit : > >> php-json -- An extremely fast PHP extension for JSON >> php-pear-Mail-Mime -- Classes to create and decode mime messages >> php-pear-Mail-mimeDecode -- transcodes mime messages >> php-pear-Net-Sieve -- Communication with timsieved >> php-pecl-Fileinfo -- Fileinfo is a PHP extension that wraps the libmagic >> library >> php-shout -- PHP module for communicating with Icecast servers > > I can take ownership of this php related package (as/with a co-maintener > if someone else want) I'm happy to stay on as comaintainer of p-p-M-mimeDecode. > Remi. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From dtimms at iinet.net.au Tue May 27 13:19:53 2008 From: dtimms at iinet.net.au (David Timms) Date: Tue, 27 May 2008 23:19:53 +1000 Subject: Orphaning my Packages - "packager pump-ups" :-) In-Reply-To: <604aa7910805270506v5842a9a4x7af5fe92569e2759@mail.gmail.com> References: <483B8450.6070505@theholbrooks.org> <20080527063107.4b582788@vader.jdub.homelinux.org> <604aa7910805270446v4a11d87eu598ec15824b1f4e9@mail.gmail.com> <6dd1343e0805270501l2d2191c5s8dff31836e3c8d0a@mail.gmail.com> <604aa7910805270506v5842a9a4x7af5fe92569e2759@mail.gmail.com> Message-ID: <483C0A79.9000404@iinet.net.au> Jeff Spaleta wrote: > On Tue, May 27, 2008 at 4:01 AM, G wrote: >> Off late There are more contributors joinig fedora which is excellent ... > I'm all ears as to what you think is appropriate feedback. How many times has my package, and it's updates been downloaded ? ie am I really just doing this for myself, or are my fellow Fedorians benefiting from my work {and it takes me weeks to get even a basic package ready for the review process, so I understand how much work} ? This could at least be tracked on the fedoraproject managed sites, as raw down-load hits. Would miss the packages that are included in live cd's and within download media. Perhaps an advance on the mirror-manager tracker that allows a mirror to upload download hit counts for each rpm file for the day/week/month etc ? Also, number of available and or installed packages that use my package as a requires ? smolt for packages ? opt-in, no-ip tracking possible. I guess that is what redhat network etc would have been doing in "helping us track our system's updatedness" in late rhl / early fedora times. And, many thanks to Brandon for the work done in making some php packages like json available - this made it a lot easier for me to get eg sugar crm demo going for work. Cheers, DaveT. From fedora at matbooth.co.uk Tue May 27 13:24:16 2008 From: fedora at matbooth.co.uk (Mat Booth) Date: Tue, 27 May 2008 14:24:16 +0100 Subject: Orphaning my Packages (or: RIP, Fedora!) In-Reply-To: <483B8450.6070505@theholbrooks.org> References: <483B8450.6070505@theholbrooks.org> Message-ID: <9497e9990805270624u1698962etc356d0de6b5e3d7a@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, May 27, 2008 at 4:47 AM, Brandon Holbrook wrote: > I'm happy to report that I'm finally feeing myself of everything Fedora! > Starting around a year ago Fedora's red tape and horrible bureaucracy > started turning me off. It all culminated with the legendary "No KMODs in > Fedora" blanket policy on Sept 13. So obviously when I submitted > open-vm-tools as a new package 5 days later (I didn't know they passed such > a ridiculous policy at the time) here: > https://bugzilla.redhat.com/show_bug.cgi?id=294341, it was rejected. > > Since then I've been migrating all my boxes at home and work away from > Fedora/CentOS/RHEL to other distros and found the move to be very > refreshing. Fedora now only lives in a couple VMs here at home for me to > maintain my packages (a strange bit of irony, since it was Fedora's > unwillingness to play nicely in a VM that pushed me away to begin with...), > but I haven't even been doing a good job at that. Therefore, I am hereby > relinquishing my responsibilities of everything Fedora, which include the > following packages: > > eclipse-phpeclipse -- PHP Eclipse plugin I will take eclipse-phpeclipse, since I'm already maintaining one other eclipse plugin I don't think it will be too much hassle. - -- Mat Booth www.matbooth.co.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: http://getfiregpg.org iEYEARECAAYFAkg8C8MACgkQKfdzh3zDrvAzlACfUJSAlzIixV2EdXA1jodrn1vV VEMAoLKrqCJE/7hxtnFebPfekafUSkNh =CGx+ -----END PGP SIGNATURE----- From jonstanley at gmail.com Tue May 27 13:33:41 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Tue, 27 May 2008 09:33:41 -0400 Subject: package reviews: show only review reqs using a particluar language ? In-Reply-To: <483AA2F6.50802@iinet.net.au> References: <483AA2F6.50802@iinet.net.au> Message-ID: On Mon, May 26, 2008 at 7:45 AM, David Timms wrote: > Are bugzilla tags freeform, ie could any bugzilla user add such a tag to the > review ? Keywords are not freeform, status whiteboard is. This is used for various things by different parties. In the bug triage world, we use it for a "we've been here" type tag. There's also a quasi-official tag of "NeedsRetesting" which will attract the attention of QA-minded folks to actually test a build for you. There's a few others which other folks use. If you want to use it for something else, feel free! From opensource at till.name Tue May 27 13:54:22 2008 From: opensource at till.name (Till Maas) Date: Tue, 27 May 2008 15:54:22 +0200 Subject: package reviews: show only review reqs using a particluar language ? In-Reply-To: <483BF889.9010607@gmail.com> References: <483AA2F6.50802@iinet.net.au> <200805261613.45410.opensource@till.name> <483BF889.9010607@gmail.com> Message-ID: <200805271554.27653.opensource@till.name> On Tue May 27 2008, Andrew Farris wrote: > Till Maas wrote: > > Also it can be easily seen on a bug search results page. Maybe it could > > be agreed on a special way to mention it in case it is not already > > obvious, e.g. add the language in parenthesis after the package name, > > e.g. > > > > Review Request: foobarmatic (ruby) - some foo for bar > > But language as a freeform random part of summary is not very clear either. I did not suggest a freeform random part but a defined part of the subject, e.g. in parentheses. > Review Request: foobarmatic c - some foo for C++ code documentation parsing > Review Request: foobarmatic written in c++ - makes ruby colored slippers > Review Request: foobarmatic perl - pythons on a plane Review Request: foobarmatic (c) - some foo for C++ code documentation parsing Review Request: foobarmatic (c++) - makes ruby colored slippers Review Request: foobarmatic (perl) - pythons on a plane Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From lemenkov at gmail.com Tue May 27 14:00:01 2008 From: lemenkov at gmail.com (Peter Lemenkov) Date: Tue, 27 May 2008 18:00:01 +0400 Subject: Fedora 10 and flash? In-Reply-To: <64b14b300805270358m21391353kb3e963ebfa054c4a@mail.gmail.com> References: <64b14b300805270358m21391353kb3e963ebfa054c4a@mail.gmail.com> Message-ID: 2008/5/27 Valent Turkovic : > Hi, I must share this report with you. > I don't use Ubuntu but I installed it on one PC in a lab for students > and kids to learn using it (we have half Fedora and half Ubuntu lab). > I opened Firefox and went to www.redhatmagazine.com and immediately I > got a pop up window with a choice to install Adobe Flash, Swhdec or > Gnash plugin. I was amazed how well this worked and that I had a > choice to pick any one plugin that I believe it better. > I know about Fedora's upstream mentality but I must take my hat to > Ubuntu devels for making their "Ubuntu plugin service" work great. I > know that this is what Mozilla should have made but with their track > for supporting linux isn't the best one. And also I see some projects > that fedora made and didn't wait for the others but fedora and red hat > devels made them because they were missing (pulseaudio, > networkmanager, and lots of others...) so does it make sense to you > that Fedora makes also "Fedor plugin service" for Fedora 10 or do you > believe that if it is not in Firefox by default than Fedora should not > touch it in anyway? Why? > > Cheers, The REAL issues are: * www.redhatmagazine.com uses flash (ads). * your Ubuntu box doesn't have AdBlock+ installed. You should set it up. -- With best regards! From kaboom at oobleck.net Tue May 27 13:27:21 2008 From: kaboom at oobleck.net (Chris Ricker) Date: Tue, 27 May 2008 09:27:21 -0400 (EDT) Subject: sata and changing devices In-Reply-To: <20080527082204.GA22443@devserv.devel.redhat.com> References: <483701CC.5010002@verizon.net> <20080523200048.GC13150@devserv.devel.redhat.com> <483727E1.80803@verizon.net> <20080523203439.GE13150@devserv.devel.redhat.com> <48372CD5.7010801@verizon.net> <4837458D.9080105@verizon.net> <483B4E2B.4060001@verizon.net> <20080527082204.GA22443@devserv.devel.redhat.com> Message-ID: On Tue, 27 May 2008, Alan Cox wrote: > SATA is hotplug, beyond "which is the boot volume" there isn't anything which > ties a drive to a given port. LVM/MD and friends all understand uuid/label for > good reason. Does cryptsetup? That's the one thing I've noticed still uses /dev/sda or /dev/hda style device names later, chris From ajax at redhat.com Tue May 27 14:14:39 2008 From: ajax at redhat.com (Adam Jackson) Date: Tue, 27 May 2008 10:14:39 -0400 Subject: SESSION_MANAGER env var in rawhide and XSMP spec In-Reply-To: <1211843290.3610.7.camel@localhost.localdomain> References: <1211843290.3610.7.camel@localhost.localdomain> Message-ID: <1211897679.29467.320.camel@localhost.localdomain> On Tue, 2008-05-27 at 01:08 +0200, Kjartan Maraas wrote: > Hi > > I've been trying to track down some issues with gnome-session in GNOME > 2.23.x which is in rawhide now. I first noticed this when trying out a > jhbuild of GNOME 2.23.x, but then noticed that rawhide suffers from the > same symptoms. A bunch of processes are left in [defunct] state after > login and starting new programs complains about not being able to > connect to the session manager. > > After some investigation and help from one of the gnome-session > maintainers we noticed that the SESSION_MANAGER env var in rawhide > differs from other distros. What I see in rawhide is this: > > [kmaraas at localhost gnome-session]$ echo $SESSION_MANAGER > local/unix:@/tmp/.ICE-unix/2994 > > and he had: > > ?local/henderson:/tmp/.ICE-unix/14577 I'm not aware of any code placing semantic meaning on the SESSION_MANAGER variable. libSM doesn't even look at the right hand side of the / in the transport spec when the transport is "local", so the different hostnames shouldn't matter. That said, that change didn't actually fix the bug I put it in to try to fix, so I should probably just back it out. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mike at miketc.com Tue May 27 14:35:26 2008 From: mike at miketc.com (Mike Chambers) Date: Tue, 27 May 2008 09:35:26 -0500 Subject: libflashsupport In-Reply-To: <64b14b300805270539s296d306dt5a89cb60f722b8b@mail.gmail.com> References: <48372911.9010502@fedoraproject.org> <20080523205114.GB29875@nostromo.devel.redhat.com> <1211585673.3566.120.camel@cookie.hadess.net> <20080523235451.GA8466@tango.0pointer.de> <64b14b300805270328k3b1039c1k3f5d9971ca6307a7@mail.gmail.com> <20080527105227.GA17076@tango.0pointer.de> <64b14b300805270539s296d306dt5a89cb60f722b8b@mail.gmail.com> Message-ID: <1211898926.4868.5.camel@scrappy.miketc.com> On Tue, 2008-05-27 at 14:39 +0200, Valent Turkovic wrote: > I have downloaded and installed flash10 beta from adobe via their rpm > and also via .sh file under FC6 running FF3b. I have asked others on > local news group and I got few reports from people using other distros > that they also have issues with it not working. > > When I install it via rpm file then FF3 still says that I don't have > Flash plugin installed, so I remove it and install it via .sh file in > ~/.mozilla/plugins/ and then it doesn't complain that it doesn't have > the plugin but it still doesn't show any flash videos... Running ver 10 on x86 system running F9 without libflashsupport and seems to be running just fine. -- Mike Chambers Fedora Project - Ambassador, Bug Zapper, Tester, User, etc.. mikec302 at fedoraproject.org From mike at miketc.com Tue May 27 14:44:37 2008 From: mike at miketc.com (Mike Chambers) Date: Tue, 27 May 2008 09:44:37 -0500 Subject: Wiki Migration (Tuesday 05-26-2008) In-Reply-To: <1211898842.4570.124.camel@bree.homelinux.com> References: <64b14b300805270547s6a407242l1b9447fe0eb3c53b@mail.gmail.com> <1211898842.4570.124.camel@bree.homelinux.com> Message-ID: <1211899477.4868.8.camel@scrappy.miketc.com> On Tue, 2008-05-27 at 10:04 -0430, Patrick O'Callaghan wrote: > On Tue, 2008-05-27 at 14:47 +0200, Valent Turkovic wrote: > > On Sat, May 24, 2008 at 4:37 PM, Mike McGrath wrote: > > > Hello Fedora Universe! It is my pleasure to announce that starting on > > > Tuesday http://fedoraproject.org/wiki/ will be run by Mediawiki instead > > > of Moin. Why bother announcing this to everyone? Well there are a couple > > > of reasons. > > > > For people like me who missed the discussion about this move to > > Mediawiki it would be nice to see the link. I believe that you made a > > right choice and I love Mediawiki but I would just like to see what is > > benefits are there with moving to Mediawiki so that I can take > > advantage of them. > > Why are you replying on this list to a message from a different list? > Not everyone is on fedora-announce-list so a reply to a non-existent > message is somewhat disconcerting. Has the transition to Mediawiki happened yet or we still on Moin at the moment? -- Mike Chambers Fedora Project - Ambassador, Bug Zapper, Tester, User, etc.. mikec302 at fedoraproject.org From nicu_fedora at nicubunu.ro Tue May 27 14:48:20 2008 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Tue, 27 May 2008 17:48:20 +0300 Subject: Fedora 10 and flash? In-Reply-To: References: <64b14b300805270358m21391353kb3e963ebfa054c4a@mail.gmail.com> Message-ID: <483C1F34.8010809@nicubunu.ro> Peter Lemenkov wrote: > 2008/5/27 Valent Turkovic : >> Hi, I must share this report with you. >> I don't use Ubuntu but I installed it on one PC in a lab for students >> and kids to learn using it (we have half Fedora and half Ubuntu lab). >> I opened Firefox and went to www.redhatmagazine.com and immediately I >> got a pop up window with a choice to install Adobe Flash, Swhdec or >> Gnash plugin. > > The REAL issues are: > > * www.redhatmagazine.com uses flash (ads). > * your Ubuntu box doesn't have AdBlock+ installed. You should set it up. Uh... no! RHM uses Flash for streaming videos, not for ads. And before you ask, they provide also OGG Theora versions for those videos. -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From hughsient at gmail.com Tue May 27 14:53:42 2008 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 27 May 2008 15:53:42 +0100 Subject: Fedora 10 and flash? In-Reply-To: <604aa7910805270434n58ead5b4sed85dec5c48aa832@mail.gmail.com> References: <64b14b300805270358m21391353kb3e963ebfa054c4a@mail.gmail.com> <604aa7910805270434n58ead5b4sed85dec5c48aa832@mail.gmail.com> Message-ID: <1211900022.3400.8.camel@hughsie-work> On Tue, 2008-05-27 at 03:34 -0800, Jeff Spaleta wrote: > I'm not even sure we would need to run a service actually, if a client > side firefox extension could intercept the plugin request and > translate it into a packaging provides to send to packagekit. This is > something to bring up with the packagekit developers. Sure, it's trivial to add as long as there are rpm virtual provides, for instance, you could have all three flash packages provide browser-plugin-flash and then hook this in to PackageKit trivially. Then you just need to convert the plugin request -> rpm provide and then just tell PackageKit what provide you want installing. It'll even show the user a menu with choice if there's more than one package providing this. Yell if you are interested making this work. Richard. From kwade at redhat.com Tue May 27 14:55:36 2008 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Tue, 27 May 2008 07:55:36 -0700 Subject: Wiki Migration (Tuesday 05-26-2008) In-Reply-To: <1211899477.4868.8.camel@scrappy.miketc.com> References: <64b14b300805270547s6a407242l1b9447fe0eb3c53b@mail.gmail.com> <1211898842.4570.124.camel@bree.homelinux.com> <1211899477.4868.8.camel@scrappy.miketc.com> Message-ID: <1211900136.3594.111.camel@calliope.phig.org> On Tue, 2008-05-27 at 09:44 -0500, Mike Chambers wrote: > Has the transition to Mediawiki happened yet or we still on Moin at the > moment? Neither! We've been working on the new MediaWiki instance for the last few days and later today are going to do the final data import of anything that was modified in Moin since Saturday. At that point we'll send out another announcement with useful URLs. We are still on target for this announcement to come out tonight UTC. - Karsten -- Karsten Wade, Sr. Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org gpg key : AD0E0C41 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Tue May 27 14:56:45 2008 From: notting at redhat.com (Bill Nottingham) Date: Tue, 27 May 2008 10:56:45 -0400 Subject: Fedora 10 and flash? In-Reply-To: <1211900022.3400.8.camel@hughsie-work> References: <64b14b300805270358m21391353kb3e963ebfa054c4a@mail.gmail.com> <604aa7910805270434n58ead5b4sed85dec5c48aa832@mail.gmail.com> <1211900022.3400.8.camel@hughsie-work> Message-ID: <20080527145645.GA23210@nostromo.devel.redhat.com> Richard Hughes (hughsient at gmail.com) said: > Then you just need to convert the plugin request -> rpm provide and then > just tell PackageKit what provide you want installing. It'll even show > the user a menu with choice if there's more than one package providing > this. > > Yell if you are interested making this work. The biggest issue is with things like Flash where we don't control the packaging. Bill From notting at redhat.com Tue May 27 14:57:26 2008 From: notting at redhat.com (Bill Nottingham) Date: Tue, 27 May 2008 10:57:26 -0400 Subject: upstart plans for F10+ In-Reply-To: <200805251528.59505.billcrawford1970@googlemail.com> References: <20080522200445.GA24822@nostromo.devel.redhat.com> <200805251528.59505.billcrawford1970@googlemail.com> Message-ID: <20080527145726.GB23210@nostromo.devel.redhat.com> Bill Crawford (billcrawford1970 at gmail.com) said: > On Thursday 22 May 2008 21:04:45 Bill Nottingham wrote: > > > - Potentially splitting some of rc.sysinit into multiple events. > > Not sure this buys us much, as right now the flow is *extremely* > > sequential (start_udev -> fsck -> remount r/w -> clean out /tmp) > > Here's one pet peeve of mine (and it's not upstart-specific): why can't udev > be made a "real" service that can be shut down or reloaded / restarted via > a "service udev restart" method? Why are you needing to restart udev? Bill From billcrawford1970 at gmail.com Tue May 27 15:02:32 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Tue, 27 May 2008 16:02:32 +0100 Subject: upstart plans for F10+ In-Reply-To: <20080527145726.GB23210@nostromo.devel.redhat.com> References: <20080522200445.GA24822@nostromo.devel.redhat.com> <200805251528.59505.billcrawford1970@googlemail.com> <20080527145726.GB23210@nostromo.devel.redhat.com> Message-ID: <544eb990805270802l8026ecxbd4fc90d5734dff7@mail.gmail.com> 2008/5/27 Bill Nottingham : > Why are you needing to restart udev? Updates libs? I noticed at least one package (I think glibc?) does a "telinit u" after install, so the new libs are used. If something fundamental like that, openssl/gnutls or selinux libs gets updated, I usually restart all the services (so there's no deleted but still referenced files hanging about taking up disk space / ram if nothing else). Yes, I can reboot, but that sorta irritates :o) From Matt_Domsch at dell.com Tue May 27 15:13:11 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 27 May 2008 10:13:11 -0500 Subject: Orphaning my Packages - "packager pump-ups" :-) In-Reply-To: <483C0A79.9000404@iinet.net.au> References: <483B8450.6070505@theholbrooks.org> <20080527063107.4b582788@vader.jdub.homelinux.org> <604aa7910805270446v4a11d87eu598ec15824b1f4e9@mail.gmail.com> <6dd1343e0805270501l2d2191c5s8dff31836e3c8d0a@mail.gmail.com> <604aa7910805270506v5842a9a4x7af5fe92569e2759@mail.gmail.com> <483C0A79.9000404@iinet.net.au> Message-ID: <20080527151311.GB25696@auslistsprd01.us.dell.com> On Tue, May 27, 2008 at 11:19:53PM +1000, David Timms wrote: > Jeff Spaleta wrote: > >On Tue, May 27, 2008 at 4:01 AM, G wrote: > >>Off late There are more contributors joinig fedora which is excellent > ... > > >I'm all ears as to what you think is appropriate feedback. > How many times has my package, and it's updates been downloaded ? > ie am I really just doing this for myself, or are my fellow Fedorians > benefiting from my work {and it takes me weeks to get even a basic > package ready for the review process, so I understand how much work} ? > > This could at least be tracked on the fedoraproject managed sites, as > raw down-load hits. Would miss the packages that are included in live > cd's and within download media. > > Perhaps an advance on the mirror-manager tracker that allows a mirror to > upload download hit counts for each rpm file for the day/week/month etc ? https://fedorahosted.org/fedora-infrastructure/ticket/549 is filed; needs someone to champion it. > Also, number of available and or installed packages that use my package > as a requires ? yum provides this, albeit not recursively. > And, many thanks to Brandon for the work done in making some php > packages like json available - this made it a lot easier for me to get > eg sugar crm demo going for work. Indeed. Brandon, best of luck in your future endeavors. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From tibbs at math.uh.edu Tue May 27 15:18:04 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 27 May 2008 10:18:04 -0500 Subject: Orphaning my Packages (or: RIP, Fedora!) In-Reply-To: <58178.202.154.148.153.1211867798.squirrel@webmail.nigelj.com> References: <483B8450.6070505@theholbrooks.org> <58178.202.154.148.153.1211867798.squirrel@webmail.nigelj.com> Message-ID: >>>>> "NJ" == Nigel Jones writes: NJ> I'll be happy to take these packages. I'd be happy to co-maintain the horde packages with you. - J< From Matt_Domsch at dell.com Tue May 27 15:22:14 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 27 May 2008 10:22:14 -0500 Subject: Announcing a new F-10 Feature Proposal: Better Webcam Support In-Reply-To: <4837A8E3.5010908@hhs.nl> References: <4836DA23.3090709@hhs.nl> <20080523152426.GB3224@nostromo.devel.redhat.com> <1211559657.3566.97.camel@cookie.hadess.net> <48372673.5020703@hhs.nl> <1211585885.3566.124.camel@cookie.hadess.net> <4837A8E3.5010908@hhs.nl> Message-ID: <20080527152214.GC25696@auslistsprd01.us.dell.com> On Sat, May 24, 2008 at 07:34:27AM +0200, Hans de Goede wrote: > >Do you have a list of those apps? Both the proprietary ones and the Open > >Source ones. For the latter, it could be more interesting to create a > >guide for the conversion from V4L1 to V4L2, and see whether Fedora > >maintainers of those projects can help out with the conversion, or at > >least submit it upstream for consideration. > > > > No list atm, noteworthy closed source ones are flash (adobe version) and > skype. skype works fine for me on F9 x86_64 with both my laptop's integrated webcam (Dell XPS M1330 with the thinner screen and VGA webcam) as well as a "Creative Live! Cam Video IM Pro" I picked up at Frys this morning for my kids. I did have to upgrade skype to the latest beta though. Ekiga works fine with both too. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From bnocera at redhat.com Tue May 27 15:25:33 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Tue, 27 May 2008 16:25:33 +0100 Subject: Fedora 10 and flash? In-Reply-To: <20080527145645.GA23210@nostromo.devel.redhat.com> References: <64b14b300805270358m21391353kb3e963ebfa054c4a@mail.gmail.com> <604aa7910805270434n58ead5b4sed85dec5c48aa832@mail.gmail.com> <1211900022.3400.8.camel@hughsie-work> <20080527145645.GA23210@nostromo.devel.redhat.com> Message-ID: <1211901933.26865.15.camel@snoogens.fab.redhat.com> On Tue, 2008-05-27 at 10:56 -0400, Bill Nottingham wrote: > Richard Hughes (hughsient at gmail.com) said: > > Then you just need to convert the plugin request -> rpm provide and then > > just tell PackageKit what provide you want installing. It'll even show > > the user a menu with choice if there's more than one package providing > > this. > > > > Yell if you are interested making this work. > > The biggest issue is with things like Flash where we don't control > the packaging. I'm sure we could get them to add a few lines of Provides if we asked nicely... Those don't need to be automated, the Flash plugin only handles 2 mime-types. From bnocera at redhat.com Tue May 27 15:25:51 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Tue, 27 May 2008 16:25:51 +0100 Subject: Fedora 10 and flash? In-Reply-To: <64b14b300805270406o782576c6j659de3cf81f88d18@mail.gmail.com> References: <64b14b300805270358m21391353kb3e963ebfa054c4a@mail.gmail.com> <64b14b300805270406o782576c6j659de3cf81f88d18@mail.gmail.com> Message-ID: <1211901951.26865.17.camel@snoogens.fab.redhat.com> On Tue, 2008-05-27 at 13:06 +0200, Valent Turkovic wrote: > I have a correction, it is called "Plugin finder service" and not > "Ubuntu plugin service" and here are the screenshots: The "Plugin finder service" is the only hard bit. With the RPM provides work Panu is doing (which both Richard and I need), we should be able to export the plugin's mime-types to the provides. Adding a UI on top is a matter of some PackageKit UI. We're planning on doing that for codecs and applications (when you don't have a handler for a particular mime-type). From johannbg at hi.is Tue May 27 15:31:43 2008 From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Tue, 27 May 2008 15:31:43 +0000 Subject: [RFE] Better rawhide report Message-ID: <483C295F.4060708@hi.is> I've been wondering if it would be possible to produce better structured rawhide report. This would require potentially patches to repodiff ( yum-utils ) At least it should be possible to dump the output to a file then run scripts to recreate it.. Somebody involved in the rawhide report process might be able provide more info on how the rawhide report is generated. Any way here's an example how I would like to see rawhide report looking like http://pastebin.org/38885 rather then the rawhide report we currently are receiving . For example I don't see why we should need an need to have an specific/extra line for each new package ( "New package $PACKAGE" \n Description of package ) in the report instead of having New package(s) ---------------------------- Package(a) - Description Package(b) - Description And why we cant receive version updates like this.. Updated to new version ----------------------------- Package(a) - Version Package(b) - Version JB -------------- next part -------------- A non-text attachment was scrubbed... Name: johannbg.vcf Type: text/x-vcard Size: 365 bytes Desc: not available URL: From skvidal at fedoraproject.org Tue May 27 15:38:06 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 27 May 2008 11:38:06 -0400 Subject: [RFE] Better rawhide report In-Reply-To: <483C295F.4060708@hi.is> References: <483C295F.4060708@hi.is> Message-ID: <1211902686.14871.51.camel@cutter> On Tue, 2008-05-27 at 15:31 +0000, "J?hann B. Gu?mundsson" wrote: > I've been wondering if it would be possible to > produce better structured rawhide report. > > This would require potentially patches to repodiff ( yum-utils ) > At least it should be possible to dump the output to a file then > run scripts to recreate it.. > > Somebody involved in the rawhide report process might be able > provide more info on how the rawhide report is generated. > > Any way here's an example how I would like to see rawhide report looking > like > http://pastebin.org/38885 rather then the rawhide report we currently > are receiving . > > For example I don't see why we should need an need to have an > specific/extra line for each new package > ( "New package $PACKAGE" \n Description of package ) in the report > instead of having > > New package(s) > ---------------------------- > > Package(a) - Description > Package(b) - Description > > And why we cant receive version updates like this.. > > Updated to new version > ----------------------------- > > Package(a) - Version > Package(b) - Version > The format of the output of repodiff was determined by how rawhide reports were before. Nothing else. If you wanted to be really impressive modify repodiff so it can take an optional genshi template for its output. -sv From jspaleta at gmail.com Tue May 27 15:51:27 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 27 May 2008 07:51:27 -0800 Subject: Orphaning my Packages - "packager pump-ups" :-) In-Reply-To: <483C0A79.9000404@iinet.net.au> References: <483B8450.6070505@theholbrooks.org> <20080527063107.4b582788@vader.jdub.homelinux.org> <604aa7910805270446v4a11d87eu598ec15824b1f4e9@mail.gmail.com> <6dd1343e0805270501l2d2191c5s8dff31836e3c8d0a@mail.gmail.com> <604aa7910805270506v5842a9a4x7af5fe92569e2759@mail.gmail.com> <483C0A79.9000404@iinet.net.au> Message-ID: <604aa7910805270851i18587023rdca942d01cfad66@mail.gmail.com> On Tue, May 27, 2008 at 5:19 AM, David Timms wrote: > smolt for packages ? opt-in, no-ip tracking possible. I guess that is what > redhat network etc would have been doing in "helping us track our system's > updatedness" in late rhl / early fedora times. Can smolt be extended to give people a choice as to what optional information they want to 'gift' back to the project? no-ip tracking.. you're no fun. Don't you want to see where in the world your packages are being used? -jef From gene at czarc.net Tue May 27 15:51:57 2008 From: gene at czarc.net (Gene Czarcinski) Date: Tue, 27 May 2008 11:51:57 -0400 Subject: ntfs-3g and ntfsprogs In-Reply-To: <1211838569.6251.32.camel@localhost.localdomain> References: <200805251456.08119.gene@czarc.net> <200805261713.31355.gene@czarc.net> <1211838569.6251.32.camel@localhost.localdomain> Message-ID: <200805271151.58225.gene@czarc.net> On Monday 26 May 2008 17:49:29 Tom "spot" Callaway wrote: > On Mon, 2008-05-26 at 17:13 -0400, Gene Czarcinski wrote: > > My suggestion: Provide an additional binary package for the ntfsprogs > > mount command (e.g., ntfsprogs-mount) which would have the mount > > command and man-page. Installation of this "new" package should be > > made to conflict with ntfs-3g so that both could not be installed at > > the same time. For F10 (an probably F11) continue with the current > > default installs ... that is, both ntfs-3g and ntfsprogs but not > > ntfsprogs-mount. > > I disagree. Having two methods for ntfs mount seems like a recipe for > failure. I looked at both of them, and determined that the ntfs-3g mount > mechanism was far more robust and better maintained. I don't really > think we benefit at all from enabling the ntfsprogs mount functionality. OK, you sold me. I learned many years ago that it really does not matter how "fast" something runs if its operation is not reliably correct. > > Or, to put it more succinctly, when we've had any problems with ntfs-3g > mount, Szaka has been extremely helpful in working with us to resolve > the issues. We've also had issues with the ntfsprogs suite, and received > zero help or feedback on our patches. "Supporting" the ntfsprogs mount > will simply lead to more bugs, and I've got enough of those as is. :) Even more sold. I have already had a minor problem with ntfsclone where is would not restore to a (vmware virtual disk) partition which was exactly the same size/same geometry as the original. The work around was to make the partition slightly larger, do the ntfsclone restore (which now worked), and then fix things up with ntfsresize. > > I'm hopeful that in time, the conflict/competition between ntfs-3g and > ntfsprogs will all balance itself out. If we need to enable the > ntfsprogs mount, it is only a minor amount of work, and could be done > quickly. I sure hope the issues are resolved and the two projects merge. > > ~spot > > p.s. I'm hedging my bets on ntfs-3g. They show community and growth, > where ntfsprogs doesn't. As I said, it was somewhat surprising to have a project be more or less stagnate and then, suddenly, issue a huge change. This alone makes ntfsprogs a bit questionable. The ntfsprogs mount command is a minor issue. The real question to me is how good the code is in libntfs as compared to libntfs-3g. Gene From stlwrt at gmail.com Tue May 27 16:35:10 2008 From: stlwrt at gmail.com (Pavel Shevchuk) Date: Tue, 27 May 2008 19:35:10 +0300 Subject: Announcing a new F-10 Feature Proposal: Better Webcam Support In-Reply-To: <20080527152214.GC25696@auslistsprd01.us.dell.com> References: <4836DA23.3090709@hhs.nl> <20080523152426.GB3224@nostromo.devel.redhat.com> <1211559657.3566.97.camel@cookie.hadess.net> <48372673.5020703@hhs.nl> <1211585885.3566.124.camel@cookie.hadess.net> <4837A8E3.5010908@hhs.nl> <20080527152214.GC25696@auslistsprd01.us.dell.com> Message-ID: Skype is out of beta for a while already and works great with my Logitech Pro9000 (uvc driver). RPMs from skype.com work great even on x86_64 system On 5/27/08, Matt Domsch wrote: > On Sat, May 24, 2008 at 07:34:27AM +0200, Hans de Goede wrote: > > >Do you have a list of those apps? Both the proprietary ones and the Open > > >Source ones. For the latter, it could be more interesting to create a > > >guide for the conversion from V4L1 to V4L2, and see whether Fedora > > >maintainers of those projects can help out with the conversion, or at > > >least submit it upstream for consideration. > > > > > > > No list atm, noteworthy closed source ones are flash (adobe version) and > > skype. > > > skype works fine for me on F9 x86_64 with both my laptop's integrated > webcam (Dell XPS M1330 with the thinner screen and VGA webcam) as well > as a "Creative Live! Cam Video IM Pro" I picked up at Frys this > morning for my kids. I did have to upgrade skype to the latest beta > though. > > Ekiga works fine with both too. > > > > -- > Matt Domsch > Linux Technology Strategist, Dell Office of the CTO > linux.dell.com & www.dell.com/linux > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- http://scwlab.com From kmaraas at broadpark.no Tue May 27 16:56:13 2008 From: kmaraas at broadpark.no (Kjartan Maraas) Date: Tue, 27 May 2008 18:56:13 +0200 Subject: SESSION_MANAGER env var in rawhide and XSMP spec In-Reply-To: <1211897679.29467.320.camel@localhost.localdomain> References: <1211843290.3610.7.camel@localhost.localdomain> <1211897679.29467.320.camel@localhost.localdomain> Message-ID: <1211907373.3314.7.camel@localhost.localdomain> ti., 27.05.2008 kl. 10.14 -0400, skrev Adam Jackson: > On Tue, 2008-05-27 at 01:08 +0200, Kjartan Maraas wrote: > > Hi > > > > I've been trying to track down some issues with gnome-session in GNOME > > 2.23.x which is in rawhide now. I first noticed this when trying out a > > jhbuild of GNOME 2.23.x, but then noticed that rawhide suffers from the > > same symptoms. A bunch of processes are left in [defunct] state after > > login and starting new programs complains about not being able to > > connect to the session manager. > > > > After some investigation and help from one of the gnome-session > > maintainers we noticed that the SESSION_MANAGER env var in rawhide > > differs from other distros. What I see in rawhide is this: > > > > [kmaraas at localhost gnome-session]$ echo $SESSION_MANAGER > > local/unix:@/tmp/.ICE-unix/2994 > > > > and he had: > > > > ?local/henderson:/tmp/.ICE-unix/14577 > > I'm not aware of any code placing semantic meaning on the > SESSION_MANAGER variable. libSM doesn't even look at the right hand > side of the / in the transport spec when the transport is "local", so > the different hostnames shouldn't matter. > No, I don't think it's really the difference in semantics that causes gnome-session to break after all. The code only seems to look at the "local/" part of the string anyway. The code is like this: /** * gsm_xsmp_init: * * Initializes XSMP. Notably, it creates the XSMP listening socket and * sets the SESSION_MANAGER environment variable to point to it. **/ void gsm_xsmp_init (void) { char error[256]; mode_t saved_umask; IceListenObj *listeners; int num_listeners; int i, local_listener; /* Set up sane error handlers */ IceSetErrorHandler (ice_error_handler); IceSetIOErrorHandler (ice_io_error_handler); SmsSetErrorHandler (sms_error_handler); /* Initialize libSM; we pass NULL for hostBasedAuthProc to disable * host-based authentication. */ if (!SmsInitialize (PACKAGE, VERSION, accept_xsmp_connection, NULL, NULL, sizeof (error), error)) gsm_initialization_error (TRUE, "Could not initialize libSM: %s", error); #ifdef HAVE_X11_XTRANS_XTRANS_H /* By default, IceListenForConnections will open one socket for each * transport type known to X. We don't want connections from remote * hosts, so for security reasons it would be best if ICE didn't * even open any non-local sockets. So we use an internal ICElib * method to disable them here. Unfortunately, there is no way to * ask X what transport types it knows about, so we're forced to * guess. */ _IceTransNoListen ("tcp"); #endif /* Create the XSMP socket. Older versions of IceListenForConnections * have a bug which causes the umask to be set to 0 on certain types * of failures. Probably not an issue on any modern systems, but * we'll play it safe. */ saved_umask = umask (0); umask (saved_umask); if (!IceListenForConnections (&num_listeners, &listeners, sizeof (error), error)) gsm_initialization_error (TRUE, _("Could not create ICE listening socket: %s"), error); umask (saved_umask); /* Find the local socket in the returned socket list. */ local_listener = -1; for (i = 0; i < num_listeners; i++) { char *id = IceGetListenConnectionString (listeners[i]); if (!strncmp (id, "local/", sizeof ("local/") - 1)) { local_listener = i; xsmp_network_id = g_strdup (id); g_free (id); break; } g_free (id); } if (local_listener == -1) gsm_initialization_error (TRUE, "IceListenForConnections did not return a local listener!"); if (num_listeners == 1) xsmp_sockets = listeners; else { /* Xtrans was apparently compiled with support for some * non-local transport besides TCP (which we disabled above). We * close those additional sockets here. (There's no API for * closing a subset of the returned connections, so we have to * cheat...) * * If the g_warning below is triggering for you and you want to * stop it, the fix is to add additional _IceTransNoListen() * calls above. */ IceListenObj local_listener_socket = listeners[local_listener]; listeners[local_listener] = listeners[num_listeners - 1]; #ifdef HAVE_X11_XTRANS_XTRANS_H g_warning ("IceListenForConnections returned %d non-local listeners: %s", num_listeners - 1, IceComposeNetworkIdList (num_listeners - 1, listeners)); #endif IceFreeListenObjs (num_listeners - 1, listeners); xsmp_sockets = malloc (sizeof (IceListenObj)); xsmp_sockets[0] = local_listener_socket; } /* Update .ICEauthority with new auth entries for our socket */ if (!update_iceauthority (TRUE, xsmp_network_id)) { /* FIXME: is this really fatal? Hm... */ gsm_initialization_error (TRUE, "Could not update ICEauthority file %s", IceAuthFileName ()); } g_setenv ("SESSION_MANAGER", xsmp_network_id, TRUE); g_debug ("SESSION_MANAGER=%s\n", xsmp_network_id); } Cheers Kjartan From billcrawford1970 at gmail.com Tue May 27 17:02:13 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Tue, 27 May 2008 18:02:13 +0100 Subject: SESSION_MANAGER env var in rawhide and XSMP spec In-Reply-To: <1211907373.3314.7.camel@localhost.localdomain> References: <1211843290.3610.7.camel@localhost.localdomain> <1211897679.29467.320.camel@localhost.localdomain> <1211907373.3314.7.camel@localhost.localdomain> Message-ID: <544eb990805271002n48c50721x1523cd18e5209fae@mail.gmail.com> 2008/5/27 Kjartan Maraas : > #ifdef HAVE_X11_XTRANS_XTRANS_H > /* By default, IceListenForConnections will open one socket for each > * transport type known to X. We don't want connections from remote > * hosts, so for security reasons it would be best if ICE didn't > * even open any non-local sockets. So we use an internal ICElib > * method to disable them here. Unfortunately, there is no way to > * ask X what transport types it knows about, so we're forced to > * guess. > */ > _IceTransNoListen ("tcp"); > #endif [...] > if (!IceListenForConnections (&num_listeners, &listeners, > sizeof (error), error)) > gsm_initialization_error (TRUE, _("Could not create ICE listening socket: %s"), error); > umask (saved_umask); > > /* Find the local socket in the returned socket list. */ > local_listener = -1; > for (i = 0; i < num_listeners; i++) > { > char *id = IceGetListenConnectionString (listeners[i]); > > if (!strncmp (id, "local/", sizeof ("local/") - 1)) > { > local_listener = i; Bet this is picking up the "abstract socket" listener, and not getting the "real" unix socket one. This might explain a connection problem. From dr.diesel at gmail.com Tue May 27 17:37:04 2008 From: dr.diesel at gmail.com (Dr. Diesel) Date: Tue, 27 May 2008 13:37:04 -0400 Subject: Anyone else with hard freezes? In-Reply-To: <2a28d2ab0805211522k277cec05r6b588b215e75d446@mail.gmail.com> References: <80d7e4090805081625m111b7955v2c96d864275334b2@mail.gmail.com> <2a28d2ab0805130448s2b3e8c8aw5e526bd04949d60a@mail.gmail.com> <2a28d2ab0805131341x6d4d6332nd89e1252839f3866@mail.gmail.com> <2a28d2ab0805140713h542598d6y5c010885dac62687@mail.gmail.com> <482AF52D.1080509@poolshark.org> <2a28d2ab0805141459j22db5edcmb858afd627ea5d01@mail.gmail.com> <2a28d2ab0805151433m1b323ecak47a256b148cb982f@mail.gmail.com> <20080515220101.GA8240@devserv.devel.redhat.com> <2a28d2ab0805160503j4c841d5fh67a9e493a7c938ad@mail.gmail.com> <2a28d2ab0805211522k277cec05r6b588b215e75d446@mail.gmail.com> Message-ID: <2a28d2ab0805271037n58988747m384893a886d2f555@mail.gmail.com> All, Even though memtest86 would run fine for > 24 hours without error I up and decided to swap on the memory. Since I've no lockups or weirdness, I'm fairly confidant the memory was the issue. Thanks Andy On Wed, May 21, 2008 at 6:22 PM, Dr. Diesel wrote: > Well, 24 hours of memtest86 show no errors (27 passes), system is > still hosed! Is there any other tests to prove this isn't a hardware > failure? I do see amarok in messages but i don't think its been > running on all lockup occasion. > > Please Help! > > messages: > > May 21 17:53:47 localhost kernel: BUG: unable to handle kernel paging > request at 00000000001200d2 > May 21 17:53:47 localhost kernel: IP: [__d_lookup+246/285] __d_lookup+0xf6/0x11d > May 21 17:53:47 localhost kernel: PGD 2e08c067 PUD 10e6b067 PMD 2b4b5067 PTE 0 > May 21 17:53:47 localhost kernel: Oops: 0000 [21] SMP > May 21 17:53:47 localhost kernel: CPU 0 > May 21 17:53:47 localhost kernel: Modules linked in: nfs lockd nfs_acl > coretemp w83627ehf hwmon_vid hwmon fuse sunrpc ipt_REJECT xt_tcpudp > nf_conntrack_ipv4 xt_state nf_conntrack iptable_filter ip_tables > x_tables loop dm_multipath ipv6 snd_hda_intel snd_seq_dummy > snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss > snd_mixer_oss snd_pcm snd_timer firewire_ohci snd_page_alloc snd_hwdep > firewire_core r8169 snd pata_jmicron crc_itu_t pl2303 pata_acpi > i2c_i801 usb_storage iTCO_wdt pcspkr usbserial bay button i2c_core > ata_generic soundcore iTCO_vendor_support sg floppy dm_snapshot > dm_zero dm_mirror dm_mod ahci libata sd_mod scsi_mod ext3 jbd mbcache > uhci_hcd ohci_hcd ehci_hcd [last unloaded: microcode] > May 21 17:53:47 localhost kernel: Pid: 12207, comm: amarokcollectio > Tainted: G D 2.6.25.3-18.fc9.x86_64 #1 > May 21 17:53:47 localhost kernel: RIP: 0010:[__d_lookup+246/285] > [__d_lookup+246/285] __d_lookup+0xf6/0x11d > May 21 17:53:47 localhost kernel: RSP: 0018:ffff810010e4bb08 EFLAGS: 00010206 > May 21 17:53:47 localhost kernel: RAX: 00000000001200d2 RBX: > ffff810013db0ea0 RCX: 0000000000000011 > May 21 17:53:47 localhost kernel: RDX: 000000000001c256 RSI: > ffff810010e4bbf8 RDI: ffff81003f443ea0 > May 21 17:53:47 localhost kernel: RBP: ffff810010e4bb58 R08: > 0000000000000000 R09: 0000000000000000 > May 21 17:53:47 localhost kernel: R10: 0000000000000003 R11: > ffff81002508f390 R12: 00000000001200d2 > May 21 17:53:47 localhost kernel: R13: ffff81003f443ea0 R14: > ffff810010e4bbf8 R15: 0000000099fa0098 > May 21 17:53:47 localhost kernel: FS: 0000000000000000(0000) > GS:ffffffff813f6000(0000) knlGS:0000000000000000 > May 21 17:53:47 localhost kernel: CS: 0010 DS: 0000 ES: 0000 CR0: > 0000000080050033 > May 21 17:53:47 localhost kernel: CR2: 00000000001200d2 CR3: > 0000000010e69000 CR4: 00000000000006e0 > May 21 17:53:47 localhost kernel: DR0: 0000000000000000 DR1: > 0000000000000000 DR2: 0000000000000000 > May 21 17:53:47 localhost kernel: DR3: 0000000000000000 DR6: > 00000000ffff0ff0 DR7: 0000000000000400 > May 21 17:53:47 localhost kernel: Process amarokcollectio (pid: 12207, > threadinfo ffff810010e4a000, task ffff81000f34a000) > May 21 17:53:47 localhost kernel: Stack: 000000000000000f > 0000000f3f5441ed ffff810026d50900 ffffffff8104184a > May 21 17:53:47 localhost kernel: 00000000001200d2 0000000000000000 > ffff810010e4be88 ffff81003f54e3c8 > May 21 17:53:47 localhost kernel: ffff810026d50900 ffff810010e4be88 > ffff810010e4bba8 ffffffff810ac3fc > May 21 17:53:47 localhost kernel: Call Trace: > May 21 17:53:47 localhost kernel: [in_group_p+42/44] ? in_group_p+0x2a/0x2c > May 21 17:53:47 localhost kernel: [do_lookup+44/424] do_lookup+0x2c/0x1a8 > May 21 17:53:47 localhost kernel: [__link_path_walk+2481/3731] > __link_path_walk+0x9b1/0xe93 > May 21 17:53:47 localhost kernel: [touch_atime+131/274] ? > touch_atime+0x83/0x112 > May 21 17:53:47 localhost kernel: [__link_path_walk+3133/3731] > __link_path_walk+0xc3d/0xe93 > May 21 17:53:47 localhost kernel: [path_walk+97/195] path_walk+0x61/0xc3 > May 21 17:53:47 localhost kernel: [do_path_lookup+470/561] > do_path_lookup+0x1d6/0x231 > May 21 17:53:47 localhost kernel: [__path_lookup_intent_open+92/159] > __path_lookup_intent_open+0x5c/0x9f > May 21 17:53:47 localhost kernel: [path_lookup_open+12/14] > path_lookup_open+0xc/0xe > May 21 17:53:47 localhost kernel: [open_namei+118/1696] open_namei+0x76/0x6a0 > May 21 17:53:47 localhost kernel: [do_filp_open+40/75] do_filp_open+0x28/0x4b > May 21 17:53:47 localhost kernel: [__strncpy_from_user+44/83] ? > __strncpy_from_user+0x2c/0x53 > May 21 17:53:47 localhost kernel: [get_unused_fd_flags+139/287] ? > get_unused_fd_flags+0x8b/0x11f > May 21 17:53:47 localhost kernel: [do_sys_open+81/210] do_sys_open+0x51/0xd2 > May 21 17:53:47 localhost kernel: [sys_open+27/29] sys_open+0x1b/0x1d > May 21 17:53:47 localhost kernel: [tracesys+213/218] tracesys+0xd5/0xda > May 21 17:53:47 localhost kernel: > May 21 17:53:47 localhost kernel: > May 21 17:53:47 localhost kernel: Code: 04 10 75 06 f0 ff 03 48 89 d8 > fe 43 08 eb 34 41 fe 44 24 f0 48 8b 45 d0 48 8b 00 48 89 45 d0 48 8b > 45 d0 48 85 c0 74 19 49 89 c4 <48> 8b 00 49 8d 5c 24 e8 44 39 7b 30 0f > 18 08 75 d8 e9 65 ff ff > May 21 17:53:47 localhost kernel: RIP [__d_lookup+246/285] > __d_lookup+0xf6/0x11d > May 21 17:53:47 localhost kernel: RSP > May 21 17:53:47 localhost kernel: CR2: 00000000001200d2 > May 21 17:53:47 localhost kernel: ---[ end trace c2ff9cce82980cc9 ]--- > May 21 17:53:49 localhost kerneloops: Submitted 1 kernel oopses to > www.kerneloops.org > > > Dmesg: > > BUG: unable to handle kernel paging request at 00000000001200d2 > IP: [] __d_lookup+0xf6/0x11d > PGD 2e088067 PUD 10f70067 PMD 2dd90067 PTE 0 > Oops: 0000 [18] SMP > CPU 0 > Modules linked in: nfs lockd nfs_acl coretemp w83627ehf hwmon_vid > hwmon fuse sunrpc ipt_REJECT xt_tcpudp nf_conntrack_ipv4 xt_state > nf_conntrack iptable_filter ip_tables x_tables loop dm_multipath ipv6 > snd_hda_intel snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq > snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer > firewire_ohci snd_page_alloc snd_hwdep firewire_core r8169 snd > pata_jmicron crc_itu_t pl2303 pata_acpi i2c_i801 usb_storage iTCO_wdt > pcspkr usbserial bay button i2c_core ata_generic soundcore > iTCO_vendor_support sg floppy dm_snapshot dm_zero dm_mirror dm_mod > ahci libata sd_mod scsi_mod ext3 jbd mbcache uhci_hcd ohci_hcd > ehci_hcd [last unloaded: microcode] > Pid: 12190, comm: amarokcollectio Tainted: G D 2.6.25.3-18.fc9.x86_64 #1 > RIP: 0010:[] [] __d_lookup+0xf6/0x11d > RSP: 0018:ffff810010f5fb08 EFLAGS: 00010206 > RAX: 00000000001200d2 RBX: ffff810013db0ea0 RCX: 0000000000000011 > RDX: 000000000001c256 RSI: ffff810010f5fbf8 RDI: ffff81003f443ea0 > RBP: ffff810010f5fb58 R08: 0000000000000000 R09: 0000000000000000 > R10: 0000000000000003 R11: ffff81002508f390 R12: 00000000001200d2 > R13: ffff81003f443ea0 R14: ffff810010f5fbf8 R15: 0000000099fa0098 > FS: 0000000000000000(0000) GS:ffffffff813f6000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 00000000001200d2 CR3: 0000000010e45000 CR4: 00000000000006e0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > Process amarokcollectio (pid: 12190, threadinfo ffff810010f5e000, task > ffff810010e26000) > Stack: 000000000000000f 0000000f3f5441ed ffff810026d50900 ffffffff8104184a > 00000000001200d2 0000000000000000 ffff810010f5fe88 ffff81003f54e3c8 > ffff810026d50900 ffff810010f5fe88 ffff810010f5fba8 ffffffff810ac3fc > Call Trace: > [] ? in_group_p+0x2a/0x2c > [] do_lookup+0x2c/0x1a8 > [] __link_path_walk+0x9b1/0xe93 > [] ? touch_atime+0x83/0x112 > [] __link_path_walk+0xc3d/0xe93 > [] path_walk+0x61/0xc3 > [] do_path_lookup+0x1d6/0x231 > [] __path_lookup_intent_open+0x5c/0x9f > [] path_lookup_open+0xc/0xe > [] open_namei+0x76/0x6a0 > [] do_filp_open+0x28/0x4b > [] ? __strncpy_from_user+0x2c/0x53 > [] ? get_unused_fd_flags+0x8b/0x11f > [] do_sys_open+0x51/0xd2 > [] sys_open+0x1b/0x1d > [] tracesys+0xd5/0xda > > > Code: 04 10 75 06 f0 ff 03 48 89 d8 fe 43 08 eb 34 41 fe 44 24 f0 48 > 8b 45 d0 48 8b 00 48 89 45 d0 48 8b 45 d0 48 85 c0 74 19 49 89 c4 <48> > 8b 00 49 8d 5c 24 e8 44 39 7b 30 0f 18 08 75 d8 e9 65 ff ff > RIP [] __d_lookup+0xf6/0x11d > RSP > CR2: 00000000001200d2 > ---[ end trace c2ff9cce82980cc9 ]--- > > On Fri, May 16, 2008 at 8:03 AM, Dr. Diesel wrote: >> On Thu, May 15, 2008 at 5:01 PM, Alan Cox wrote: >>> On Thu, May 15, 2008 at 05:33:02PM -0400, Dr. Diesel wrote: >>>> And more! >>>> >>>> ISO 9660 Extensions: Microsoft Joliet Level 3 >>>> ISO 9660 Extensions: RRIP_1991A >>>> mtrr: no MTRR for d0000000,ff00000 found >>>> console-kit-dae[2420]: segfault at 8 ip 3c67e2a699 sp 4100fff0 error 4 >>>> in libglib-2.0.so.0.1600.3[3c67e00000+de000] >>>> mtrr: base(0xd0000000) is not aligned on a size(0xff00000) boundary >>> >>> Out of curiosity what does memtest86 think of the box. A mix of random memory >>> and disk corruptions is a good candidate for suspecting RAM (although it's >>> certainly not conclusive and it could be an FC9 triggered bug) >> >> That figures! I ran memtest86 and folding for 12+ hours when the >> freezing first started, no errors. I re-run it last night at your >> request and get an error! Only one, at the top, 2049meg, ran it >> several times, all that the same place. >> >> Probably why I only see the freezes after a few days. I'll report >> back if it makes a week or so with no issues. >> >> Thanks to all. >> >> -- >> projecthuh.com >> All of my bits are free, are yours? Fedoraproject.org >> > > > > -- > projecthuh.com > All of my bits are free, are yours? Fedoraproject.org > -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org From tcallawa at redhat.com Tue May 27 17:38:16 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 27 May 2008 13:38:16 -0400 Subject: ntfs-3g and ntfsprogs In-Reply-To: <200805271151.58225.gene@czarc.net> References: <200805251456.08119.gene@czarc.net> <200805261713.31355.gene@czarc.net> <1211838569.6251.32.camel@localhost.localdomain> <200805271151.58225.gene@czarc.net> Message-ID: <1211909896.6251.74.camel@localhost.localdomain> On Tue, 2008-05-27 at 11:51 -0400, Gene Czarcinski wrote: > As I said, it was somewhat surprising to have a project be more or > less stagnate and then, suddenly, issue a huge change. Apparently, the back story there is that someone really wanted his specific bug fixes added, got commit access, did a release, then walked away from it. ~spot From surenkarapetyan at gmail.com Tue May 27 17:42:50 2008 From: surenkarapetyan at gmail.com (Suren Karapetyan) Date: Tue, 27 May 2008 22:42:50 +0500 Subject: libflashsupport In-Reply-To: <64b14b300805270328k3b1039c1k3f5d9971ca6307a7@mail.gmail.com> References: <48372911.9010502@fedoraproject.org> <20080523205114.GB29875@nostromo.devel.redhat.com> <1211585673.3566.120.camel@cookie.hadess.net> <20080523235451.GA8466@tango.0pointer.de> <64b14b300805270328k3b1039c1k3f5d9971ca6307a7@mail.gmail.com> Message-ID: <483C481A.9010005@gmail.com> Valent Turkovic wrote: > On Sat, May 24, 2008 at 1:54 AM, Lennart Poettering > wrote: >> On Sat, 24.05.08 00:34, Bastien Nocera (bnocera at redhat.com) wrote: >> >>> On Fri, 2008-05-23 at 16:51 -0400, Bill Nottingham wrote: >>>> Rahul Sundaram (sundaram at fedoraproject.org) said: >>>>> It seems libflashsupport was dropped out of the default package list in >>>>> Fedora 9 and I didn't see any public discussion on the reasons behind this >>>>> change (release notes didn't get updated either until recently >>>>> unfortunately) Can someone familiar with this change explain the reason? >>>> Check the FESCo logs... general reasoning is that it existed solely >>>> as a crutch for third-party software, IIRC. >>> And I'm sure the people who came up with that idea made sure to nicely >>> ask Adobe to make their Flash plugins depend on it. Or explained to them >>> what that tool did so they can fix their software. >> Adobe Flash 10 doesn't need libflashsupport anymore to work fine on >> ALSA ioplug-based backends such as pulse. >> >> Lennart > > Current version of Flash 10 doesn't work with Firefox under linux. > > Cheers, > Valent. > > Well... Mozilla's understanding of beta and Adobe's are different. mozilla beta: works most of the time adobe beta: sometimes works, sometimes doesn't From billcrawford1970 at gmail.com Tue May 27 18:00:40 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Tue, 27 May 2008 19:00:40 +0100 Subject: Anyone else with hard freezes? In-Reply-To: <2a28d2ab0805271037n58988747m384893a886d2f555@mail.gmail.com> References: <80d7e4090805081625m111b7955v2c96d864275334b2@mail.gmail.com> <2a28d2ab0805131341x6d4d6332nd89e1252839f3866@mail.gmail.com> <2a28d2ab0805140713h542598d6y5c010885dac62687@mail.gmail.com> <482AF52D.1080509@poolshark.org> <2a28d2ab0805141459j22db5edcmb858afd627ea5d01@mail.gmail.com> <2a28d2ab0805151433m1b323ecak47a256b148cb982f@mail.gmail.com> <20080515220101.GA8240@devserv.devel.redhat.com> <2a28d2ab0805160503j4c841d5fh67a9e493a7c938ad@mail.gmail.com> <2a28d2ab0805211522k277cec05r6b588b215e75d446@mail.gmail.com> <2a28d2ab0805271037n58988747m384893a886d2f555@mail.gmail.com> Message-ID: <544eb990805271100p70239edfsbb0672ad6419878f@mail.gmail.com> 2008/5/27 Dr. Diesel : > All, > > Even though memtest86 would run fine for > 24 hours without error I up > and decided to swap on the memory. Since I've no lockups or > weirdness, I'm fairly confidant the memory was the issue. That would suggest, perhaps, that when memtest is running, very little else in the system is active (e.g. disks aren't doing anything, graphics card is not drawing much power for acceleration blocks etc) ... which might indicate that your power supply isn't quite up to the job. Glad it's working now though. From dwinship at redhat.com Tue May 27 18:40:01 2008 From: dwinship at redhat.com (Dan Winship) Date: Tue, 27 May 2008 14:40:01 -0400 Subject: SESSION_MANAGER env var in rawhide and XSMP spec In-Reply-To: <544eb990805271002n48c50721x1523cd18e5209fae@mail.gmail.com> References: <1211843290.3610.7.camel@localhost.localdomain> <1211897679.29467.320.camel@localhost.localdomain> <1211907373.3314.7.camel@localhost.localdomain> <544eb990805271002n48c50721x1523cd18e5209fae@mail.gmail.com> Message-ID: <483C5581.3060609@redhat.com> Bill Crawford wrote: >> if (!strncmp (id, "local/", sizeof ("local/") - 1)) >> { >> local_listener = i; > > Bet this is picking up the "abstract socket" listener, and not getting > the "real" unix socket one. This might explain a connection problem. Yeah. See also http://bugzilla.gnome.org/show_bug.cgi?id=534641#c2 So is the right fix to assume there might be multiple local sockets, and listen on all of them? -- Dan From pjones at redhat.com Tue May 27 18:43:55 2008 From: pjones at redhat.com (Peter Jones) Date: Tue, 27 May 2008 14:43:55 -0400 Subject: Xorg 1.5 missed the train? In-Reply-To: <3adc77210805230758y605b5d46we5f638b4a172b0de@mail.gmail.com> References: <20080520202404.53258cb9@vader.jdub.homelinux.org> <20080521152022.GF1093879@hiwaay.net> <1211383722.8531.63.camel@localhost.localdomain> <1211385285.8531.65.camel@localhost.localdomain> <3adc77210805230542t126e5d62i76e9234a105d622a@mail.gmail.com> <3adc77210805230758y605b5d46we5f638b4a172b0de@mail.gmail.com> Message-ID: <483C566B.3010607@redhat.com> Naheem Zaffar wrote: > I do not have a Fedora account and I can see no edit link for anonymous users. One of the many bars to encouraging collaboration and contribution is that there's just no legally acceptable way to do it without requiring that somebody know who the contributors are. That's life in the current legal climate. -- Peter From pjones at redhat.com Tue May 27 19:01:28 2008 From: pjones at redhat.com (Peter Jones) Date: Tue, 27 May 2008 15:01:28 -0400 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: <1211444657.21380.424.camel@pmac.infradead.org> References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> <1211405127.21380.382.camel@pmac.infradead.org> <1211444657.21380.424.camel@pmac.infradead.org> Message-ID: <483C5A88.6000905@redhat.com> David Woodhouse wrote: > What I'd do is augment the kernel's firmware class support so that users > can build firmware blobs into their kernel to be accessed through the > firmware class. So the ifdefs in the above code go away -- the user can > just choose to include the blobs in the kernel build or not, as they see > fit, and the driver just invokes the firmware loader and doesn't > actually _care_ whether the firmware comes from within the kernel or > from userspace. (Having not read the follow-ups on the list yet...) This is the right track, but if anybody goes down this route, please, please organize it this way: 1) make the firwmare class support caching of firmware images (which also means supporting manual expiry of them at runtime...) 2) give the firmware class an interface to "push" an image which has not been requested. That is, preloading the cache. 3) make an initcall that runs before almost all of drivers/ which loads all built-in firmware images. This solves the "built-in modules using request_firmware don't work" problem, but still allows us to e.g. update built-in firmware images at runtime to support debugging builds, new features, blatantly violating the "can not modify" license sections in the comfort of our own homes, etc. -- Peter From pjones at redhat.com Tue May 27 19:20:10 2008 From: pjones at redhat.com (Peter Jones) Date: Tue, 27 May 2008 15:20:10 -0400 Subject: Plan for tomorrows (20080522) FESCO meeting In-Reply-To: References: <1211377739.4210.2.camel@truman> <20080521143345.383eb10b@vader.jdub.homelinux.org> <20080521184047.7b19e70b@vader.jdub.homelinux.org> Message-ID: <483C5EEA.6010200@redhat.com> Alexandre Oliva wrote: > On May 21, 2008, Josh Boyer wrote: > >> So work with upstream to get them removed or pushed to separate >> firmware packages. > > It's been tried before. I gather upstream is not interested in > achieving a 100% Free Software kernel tarball. It's in conflict with > our stated mission. Where do we go from that point, when upstream is > not cooperative and there is a drop-in alternative. I think this is a bit heavy-handed. If we take the "make it doable either as built-in or loaded from userspace at runtime, from a second tarball" approach as discussed, I suspect you'll discover that it's less "is not interested in achieving" (by which I assume you meant "is unwilling") and more "doesn't perceive it as useful goal to work on". >> Having that virtual package is more pain to maintain than a ks file > > Err... The only person I know who has volunteered to maintain this > package disagrees with this assessment, especially because the ks file > does not even begin to address the longer-term goal of enabling a user > to avoid the installation of non-Free Software on his system (install > time and updates over time), rather than a short-term goal of avoiding > the inclusion of non-Free Software in one particular spin. You are largely ignoring the infrastructure around installation and upgrades of multiple kernels. There is more maintenance work than just in the kernel package (or packages, in your scenario) itself. It is not insignificant. Josh Boyer wrote: > I certainly didn't think you intended to _replace_ the main kernel > package. But I don't agree with even providing a completely different > alternative "kernel-libre" package. If it can't be built as a flavor > of the existing kernel package, then I don't see it being approved for > inclusion. And I'd still be against that. If the goal is allowing users to install and use a system without any of the non-free firmware (assuming that's even plausible for our hypothetical user), then you also need to change the package selection code in anaconda, among other things. As much as I wish it were, kernel* is not just another package. -- Peter From lordmorgul at gmail.com Tue May 27 19:24:57 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Tue, 27 May 2008 15:24:57 -0400 Subject: package reviews: show only review reqs using a particluar language ? In-Reply-To: <200805271554.27653.opensource@till.name> References: <483AA2F6.50802@iinet.net.au> <200805261613.45410.opensource@till.name> <483BF889.9010607@gmail.com> <200805271554.27653.opensource@till.name> Message-ID: <483C6009.9070105@gmail.com> Till Maas wrote: > On Tue May 27 2008, Andrew Farris wrote: >> Till Maas wrote: > >>> Also it can be easily seen on a bug search results page. Maybe it could >>> be agreed on a special way to mention it in case it is not already >>> obvious, e.g. add the language in parenthesis after the package name, >>> e.g. >>> >>> Review Request: foobarmatic (ruby) - some foo for bar >> But language as a freeform random part of summary is not very clear either. > > I did not suggest a freeform random part but a defined part of the subject, > e.g. in parentheses. > >> Review Request: foobarmatic c - some foo for C++ code documentation parsing >> Review Request: foobarmatic written in c++ - makes ruby colored slippers >> Review Request: foobarmatic perl - pythons on a plane > > Review Request: foobarmatic (c) - some foo for C++ code documentation parsing > Review Request: foobarmatic (c++) - makes ruby colored slippers > Review Request: foobarmatic (perl) - pythons on a plane Nevertheless getting everyone to conform to something that arbitrary is more difficult than tagging a tracker bug. -- Andrew Farris www.lordmorgul.net gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29 From skvidal at fedoraproject.org Tue May 27 19:53:18 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 27 May 2008 15:53:18 -0400 Subject: package popularity ratings Message-ID: <1211917998.14871.88.camel@cutter> Hi, I got this bug assigned to yum the other day: https://bugzilla.redhat.com/show_bug.cgi?id=446836 it's not really a yum item, yet, b/c yum can really only USE the data, not generate it. However, I don't know where it should go. Is anyone working on this sort of thing? -sv -- I only speak for me. From fedora at dm.cobite.com Tue May 27 20:45:02 2008 From: fedora at dm.cobite.com (David Mansfield) Date: Tue, 27 May 2008 16:45:02 -0400 Subject: perl DateTime packaging question Message-ID: <1211921102.16076.39.camel@gandalf.cobite.com> I've read the Packaging/Perl guidelines and one thing isn't clear to me (specifically, it relates to perl-DateTime package). Under what circumstances are separate modules (i.e. bundled separately at CPAN) published together in one RPM, and when should it be different RPMs? In this case, DateTime, DateTime-TimeZone and DateTime-Locale are all part of perl-DateTime, but they are different CPAN 'entities' with different release schedules, tarballs, authors etc. Is this just an issue of packager discretion? Thanks, David From pertusus at free.fr Tue May 27 21:06:47 2008 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 27 May 2008 23:06:47 +0200 Subject: perl DateTime packaging question In-Reply-To: <1211921102.16076.39.camel@gandalf.cobite.com> References: <1211921102.16076.39.camel@gandalf.cobite.com> Message-ID: <20080527210647.GA2663@free.fr> On Tue, May 27, 2008 at 04:45:02PM -0400, David Mansfield wrote: > I've read the Packaging/Perl guidelines and one thing isn't clear to me > (specifically, it relates to perl-DateTime package). > > Under what circumstances are separate modules (i.e. bundled separately > at CPAN) published together in one RPM, and when should it be different > RPMs? > > In this case, DateTime, DateTime-TimeZone and DateTime-Locale are all > part of perl-DateTime, but they are different CPAN 'entities' with > different release schedules, tarballs, authors etc. > > Is this just an issue of packager discretion? It is, although shipping different packages in one (with different release schedules, tarballs, authors etc.) is bad practice. Normally this is raised during reviews, but not here. I suggest that you open a bug against perl-DateTime. -- Pat From mdehaan at redhat.com Tue May 27 21:14:28 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 27 May 2008 17:14:28 -0400 Subject: package popularity ratings In-Reply-To: <1211917998.14871.88.camel@cutter> References: <1211917998.14871.88.camel@cutter> Message-ID: <483C79B4.1070402@redhat.com> seth vidal wrote: > Hi, > I got this bug assigned to yum the other day: > > https://bugzilla.redhat.com/show_bug.cgi?id=446836 > > it's not really a yum item, yet, b/c yum can really only USE the data, > not generate it. > > However, I don't know where it should go. Is anyone working on this sort > of thing? > > -sv > > > > " Very similar to ubuntu's popularity meter, but better. " Cough, *Debian*, cough. I'd be interested in this too. Smolt has opt-in ways to send stats, could we hijack that submission infrastructure to also do software inventory? If so, the code seems like it would be pretty simple. We'd probably want that to be /another/ opt in switch since it's slightly different info? --Michael From berrange at redhat.com Tue May 27 21:25:14 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 27 May 2008 22:25:14 +0100 Subject: package popularity ratings In-Reply-To: <1211917998.14871.88.camel@cutter> References: <1211917998.14871.88.camel@cutter> Message-ID: <20080527212514.GC14298@redhat.com> On Tue, May 27, 2008 at 03:53:18PM -0400, seth vidal wrote: > Hi, > I got this bug assigned to yum the other day: > > https://bugzilla.redhat.com/show_bug.cgi?id=446836 > > it's not really a yum item, yet, b/c yum can really only USE the data, > not generate it. > > However, I don't know where it should go. Is anyone working on this sort > of thing? Isn't any package popularity rating going to be hugely skewed such that the 'default install set' packages are basically always rated top, making rankings of dubious value Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From rnorwood at redhat.com Tue May 27 21:25:19 2008 From: rnorwood at redhat.com (Robin Norwood) Date: Tue, 27 May 2008 17:25:19 -0400 Subject: package popularity ratings In-Reply-To: <1211917998.14871.88.camel@cutter> References: <1211917998.14871.88.camel@cutter> Message-ID: <20080527172519.6c970cac@solitude.devel.redhat.com> On Tue, 27 May 2008 15:53:18 -0400 seth vidal wrote: > Hi, > I got this bug assigned to yum the other day: > > https://bugzilla.redhat.com/show_bug.cgi?id=446836 > > it's not really a yum item, yet, b/c yum can really only USE the data, > not generate it. > > However, I don't know where it should go. Is anyone working on this > sort of thing? I'm looking at something along these lines, but don't have anything to show yet. I should have something for public consumption (text, not code) this week. -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From gnomeuser at gmail.com Tue May 27 21:31:42 2008 From: gnomeuser at gmail.com (David Nielsen) Date: Tue, 27 May 2008 23:31:42 +0200 Subject: package popularity ratings In-Reply-To: <20080527172519.6c970cac@solitude.devel.redhat.com> References: <1211917998.14871.88.camel@cutter> <20080527172519.6c970cac@solitude.devel.redhat.com> Message-ID: <1dedbbfc0805271431q30bce04t9812b889be42ec74@mail.gmail.com> 2008/5/27 Robin Norwood : > On Tue, 27 May 2008 15:53:18 -0400 > seth vidal wrote: > > > Hi, > > I got this bug assigned to yum the other day: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=446836 > > > > it's not really a yum item, yet, b/c yum can really only USE the data, > > not generate it. > > > > However, I don't know where it should go. Is anyone working on this > > sort of thing? > Doesn't mugshot collect this kind of data for it's application recommendations? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ville.skytta at iki.fi Tue May 27 21:35:52 2008 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Wed, 28 May 2008 00:35:52 +0300 Subject: perl DateTime packaging question In-Reply-To: <20080527210647.GA2663@free.fr> References: <1211921102.16076.39.camel@gandalf.cobite.com> <20080527210647.GA2663@free.fr> Message-ID: <200805280035.52613.ville.skytta@iki.fi> On Wednesday 28 May 2008, Patrice Dumas wrote: > On Tue, May 27, 2008 at 04:45:02PM -0400, David Mansfield wrote: > > In this case, DateTime, DateTime-TimeZone and DateTime-Locale are all > > part of perl-DateTime, but they are different CPAN 'entities' with > > different release schedules, tarballs, authors etc. > > > > Is this just an issue of packager discretion? > > It is, although shipping different packages in one (with different > release schedules, tarballs, authors etc.) is bad practice. Normally > this is raised during reviews, but not here. https://bugzilla.redhat.com/167376 Said the submitter: "This package is a bit odd. To avoid circular dependencies, I've bundled DateTime, DateTime::Locale, and DateTime::TimeZone." From skvidal at fedoraproject.org Tue May 27 21:39:51 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 27 May 2008 17:39:51 -0400 Subject: package popularity ratings In-Reply-To: <20080527212514.GC14298@redhat.com> References: <1211917998.14871.88.camel@cutter> <20080527212514.GC14298@redhat.com> Message-ID: <1211924391.14871.90.camel@cutter> On Tue, 2008-05-27 at 22:25 +0100, Daniel P. Berrange wrote: > On Tue, May 27, 2008 at 03:53:18PM -0400, seth vidal wrote: > > Hi, > > I got this bug assigned to yum the other day: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=446836 > > > > it's not really a yum item, yet, b/c yum can really only USE the data, > > not generate it. > > > > However, I don't know where it should go. Is anyone working on this sort > > of thing? > > Isn't any package popularity rating going to be hugely skewed such that > the 'default install set' packages are basically always rated top, making > rankings of dubious value > that's been my general impression which is why I was curious who wanted to look at it since my overt bias against them is a bit discouraging :) -sv From pertusus at free.fr Tue May 27 21:41:00 2008 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 27 May 2008 23:41:00 +0200 Subject: perl DateTime packaging question In-Reply-To: <200805280035.52613.ville.skytta@iki.fi> References: <1211921102.16076.39.camel@gandalf.cobite.com> <20080527210647.GA2663@free.fr> <200805280035.52613.ville.skytta@iki.fi> Message-ID: <20080527214100.GB2663@free.fr> On Wed, May 28, 2008 at 12:35:52AM +0300, Ville Skytt? wrote: > On Wednesday 28 May 2008, Patrice Dumas wrote: > > On Tue, May 27, 2008 at 04:45:02PM -0400, David Mansfield wrote: > > > In this case, DateTime, DateTime-TimeZone and DateTime-Locale are all > > > part of perl-DateTime, but they are different CPAN 'entities' with > > > different release schedules, tarballs, authors etc. > > > > > > Is this just an issue of packager discretion? > > > > It is, although shipping different packages in one (with different > > release schedules, tarballs, authors etc.) is bad practice. Normally > > this is raised during reviews, but not here. > > https://bugzilla.redhat.com/167376 > > Said the submitter: > "This package is a bit odd. To avoid circular dependencies, I've bundled > DateTime, DateTime::Locale, and DateTime::TimeZone." How could I miss it! Believe me or not, I had a look at the review... Anyway this seems right then, although a comment in the spec would be nice. -- Pat From jcm at redhat.com Tue May 27 21:40:51 2008 From: jcm at redhat.com (Jon Masters) Date: Tue, 27 May 2008 17:40:51 -0400 Subject: Wiki Migration (Tuesday 05-26-2008) In-Reply-To: <1211900136.3594.111.camel@calliope.phig.org> References: <64b14b300805270547s6a407242l1b9447fe0eb3c53b@mail.gmail.com> <1211898842.4570.124.camel@bree.homelinux.com> <1211899477.4868.8.camel@scrappy.miketc.com> <1211900136.3594.111.camel@calliope.phig.org> Message-ID: <1211924451.15791.17.camel@londonpacket.bos.redhat.com> On Tue, 2008-05-27 at 07:55 -0700, Karsten 'quaid' Wade wrote: > On Tue, 2008-05-27 at 09:44 -0500, Mike Chambers wrote: > > > Has the transition to Mediawiki happened yet or we still on Moin at the > > moment? > > Neither! > > We've been working on the new MediaWiki instance for the last few days > and later today are going to do the final data import of anything that > was modified in Moin since Saturday. At that point we'll send out > another announcement with useful URLs. We are still on target for this > announcement to come out tonight UTC. Any idea why it is redirecting to https by default? Seems overkill. Jon. From tibbs at math.uh.edu Tue May 27 21:41:23 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 27 May 2008 16:41:23 -0500 Subject: perl DateTime packaging question In-Reply-To: <20080527210647.GA2663@free.fr> References: <1211921102.16076.39.camel@gandalf.cobite.com> <20080527210647.GA2663@free.fr> Message-ID: >>>>> "PD" == Patrice Dumas writes: PD> It is, although shipping different packages in one (with different PD> release schedules, tarballs, authors etc.) is bad PD> practice. Normally this is raised during reviews, but not here. Well, this was explained in the review ticket: https://bugzilla.redhat.com/show_bug.cgi?id=167376 "This package is a bit odd. To avoid circular dependencies, I've bundled DateTime, DateTime::Locale, and DateTime::TimeZone." I'm not sure of the best way to avoid those circular dependencies, but surely bundling a few closely related and very small modules is low on the hierarchy of packaging sins. PD> I suggest that you open a bug against perl-DateTime. Not sure what good it would do, given the above. - J< From pertusus at free.fr Tue May 27 21:49:57 2008 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 27 May 2008 23:49:57 +0200 Subject: perl DateTime packaging question In-Reply-To: References: <1211921102.16076.39.camel@gandalf.cobite.com> <20080527210647.GA2663@free.fr> Message-ID: <20080527214957.GC2663@free.fr> On Tue, May 27, 2008 at 04:41:23PM -0500, Jason L Tibbitts III wrote: > >>>>> "PD" == Patrice Dumas writes: > > PD> It is, although shipping different packages in one (with different > PD> release schedules, tarballs, authors etc.) is bad > PD> practice. Normally this is raised during reviews, but not here. > > Well, this was explained in the review ticket: > https://bugzilla.redhat.com/show_bug.cgi?id=167376 > > "This package is a bit odd. To avoid circular dependencies, I've > bundled DateTime, DateTime::Locale, and DateTime::TimeZone." > > I'm not sure of the best way to avoid those circular dependencies, but > surely bundling a few closely related and very small modules is low on > the hierarchy of packaging sins. I think that it is perfectly right, in fact. > PD> I suggest that you open a bug against perl-DateTime. > > Not sure what good it would do, given the above. Indeed, sorry, I missed the explanation. -- Pat From jonstanley at gmail.com Tue May 27 22:07:11 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Tue, 27 May 2008 18:07:11 -0400 Subject: Wiki Migration (Tuesday 05-26-2008) In-Reply-To: <1211924451.15791.17.camel@londonpacket.bos.redhat.com> References: <64b14b300805270547s6a407242l1b9447fe0eb3c53b@mail.gmail.com> <1211898842.4570.124.camel@bree.homelinux.com> <1211899477.4868.8.camel@scrappy.miketc.com> <1211900136.3594.111.camel@calliope.phig.org> <1211924451.15791.17.camel@londonpacket.bos.redhat.com> Message-ID: On Tue, May 27, 2008 at 5:40 PM, Jon Masters wrote: > Any idea why it is redirecting to https by default? Seems overkill. My best guess would be that we're using basic auth - therefore, no opportunity to redrrect to https for a login page. From martin.sourada at gmail.com Tue May 27 22:06:47 2008 From: martin.sourada at gmail.com (Martin Sourada) Date: Wed, 28 May 2008 00:06:47 +0200 Subject: Firefox 3 dreadfully slow on new fedora wiki?! Message-ID: <1211926007.3058.7.camel@pc-notebook> Hi, I don't know what's causing it but it seems firefox 3 (and epiphany built against gecko) is almost unable to load new fedora wiki. I thought it might be some connections problems somewhere on the line, but then I got an idea to try Midori with WebKit backend. What was my surprise when the browser started and loaded the wiki page in nearly no time, while Firefox is still trying. I can do that multiple times and the wiki in Firefox is still not loaded (actually it took it over 10 minutes to load and it even wasn't able to load some of the images at all). Where the problem might be? Thanks, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Tue May 27 22:34:24 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 27 May 2008 15:34:24 -0700 Subject: Firefox 3 dreadfully slow on new fedora wiki?! In-Reply-To: <1211926007.3058.7.camel@pc-notebook> References: <1211926007.3058.7.camel@pc-notebook> Message-ID: <483C8C70.3010401@gmail.com> Martin Sourada wrote: > Hi, > > I don't know what's causing it but it seems firefox 3 (and epiphany > built against gecko) is almost unable to load new fedora wiki. I thought > it might be some connections problems somewhere on the line, but then I > got an idea to try Midori with WebKit backend. What was my surprise when > the browser started and loaded the wiki page in nearly no time, while > Firefox is still trying. I can do that multiple times and the wiki in > Firefox is still not loaded (actually it took it over 10 minutes to load > and it even wasn't able to load some of the images at all). Where the > problem might be? > We're looking into this now on #fedora-admin. Mike Mcgrath has just made a change that appears to fix this. If not, feel free to either hop on IRC to help diagnose or send another email. Thanks, -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From jspaleta at gmail.com Tue May 27 22:43:34 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 27 May 2008 14:43:34 -0800 Subject: package popularity ratings In-Reply-To: <20080527212514.GC14298@redhat.com> References: <1211917998.14871.88.camel@cutter> <20080527212514.GC14298@redhat.com> Message-ID: <604aa7910805271543macd17dape1e4a6ec7655f15@mail.gmail.com> On Tue, May 27, 2008 at 1:25 PM, Daniel P. Berrange wrote: > Isn't any package popularity rating going to be hugely skewed such that > the 'default install set' packages are basically always rated top, making > rankings of dubious value I personally see zero value in a flat popularity rating. I would see more value if we could find a way to correlate users such that I could datamine the application preferences of people who were already running systems similar to mine. For example, XFCE users as a breed might prefer certain applications which are not 'popular' in the general userbase, but were immensely popular inside the XFCE subculture. Those shared preferences would never show up in a flat popularity rating..a rating destined to be dominated by FVWM2 users...so such a flat rating would never really be what XFCE users would find value in. But if we had a way to correlate a systems/usages/people with other systems/usages/people which are mostly similar, then we have something interesting as a metric...a metric that can support both common and niche subgroups..based solely on individual usage cases or habits. That way XCFE users, would end up correlating with other XCFE users and would have the software 'popularity' ranking biased by that correlation. It would end up being dynamic, in that as your usage patterns changed, how you would correlate with others would change as well without anyone elses habits changing. Centralization of 'popularity' is simply not flexible enough to be interesting in the brave new world of the social network. -jef"Did i mention that I hate social networking"spaleta From smooge at gmail.com Tue May 27 22:51:57 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 27 May 2008 16:51:57 -0600 Subject: package popularity ratings In-Reply-To: <604aa7910805271543macd17dape1e4a6ec7655f15@mail.gmail.com> References: <1211917998.14871.88.camel@cutter> <20080527212514.GC14298@redhat.com> <604aa7910805271543macd17dape1e4a6ec7655f15@mail.gmail.com> Message-ID: <80d7e4090805271551w730e3bc7tc77b6f71ae6b2613@mail.gmail.com> On Tue, May 27, 2008 at 4:43 PM, Jeff Spaleta wrote: > On Tue, May 27, 2008 at 1:25 PM, Daniel P. Berrange wrote: >> Isn't any package popularity rating going to be hugely skewed such that >> the 'default install set' packages are basically always rated top, making >> rankings of dubious value > > I personally see zero value in a flat popularity rating. > I would see more value if we could find a way to correlate users such > that I could datamine the application preferences of people who were > already running systems similar to mine. > > For example, XFCE users as a breed might prefer certain applications > which are not 'popular' in the general userbase, but were immensely > popular inside the XFCE subculture. Those shared preferences would > never show up in a flat popularity rating..a rating destined to be > dominated by FVWM2 users...so such a flat rating would never really be > what XFCE users would find value in. > They would be better suited with: People who installed Thunar also installed ... bsd-games and fortune_mod > -jef"Did i mention that I hate social networking"spaleta > Stephen "Amazon is our salvation..." Smoogen -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From robert at fedoraproject.org Tue May 27 22:58:35 2008 From: robert at fedoraproject.org (Robert Scheck) Date: Wed, 28 May 2008 00:58:35 +0200 Subject: Orphaning my Packages (or: RIP, Fedora!) In-Reply-To: <483B8450.6070505@theholbrooks.org> References: <483B8450.6070505@theholbrooks.org> Message-ID: <20080527225835.GA12180@hurricane.linuxnetz.de> On Mon, 26 May 2008, Brandon Holbrook wrote: > php-pecl-Fileinfo -- Fileinfo is a PHP extension that wraps the libmagic I would take it on all branches, if nobody cares or want's it explicitly - Remi, how much do you care about it? Please let me know, if somebody want's it explicitly, otherwise I would take care of it end of the week or maybe next week (I'm currently on LinuxTag in Berlin). Greetings, Robert -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From robert at fedoraproject.org Tue May 27 23:02:46 2008 From: robert at fedoraproject.org (Robert Scheck) Date: Wed, 28 May 2008 01:02:46 +0200 Subject: Announcing a new F-10 Feature Proposal: Better Webcam Support In-Reply-To: <64b14b300805270325t35757e05w48939b6c799dd98e@mail.gmail.com> References: <4836DA23.3090709@hhs.nl> <20080523152426.GB3224@nostromo.devel.redhat.com> <1211559657.3566.97.camel@cookie.hadess.net> <48372673.5020703@hhs.nl> <1211585885.3566.124.camel@cookie.hadess.net> <4837A8E3.5010908@hhs.nl> <64b14b300805270325t35757e05w48939b6c799dd98e@mail.gmail.com> Message-ID: <20080527230246.GB12180@hurricane.linuxnetz.de> On Tue, 27 May 2008, Valent Turkovic wrote: > >> Do you have a list of those apps? Both the proprietary ones and the Open > >> Source ones. For the latter, it could be more interesting to create a > >> guide for the conversion from V4L1 to V4L2, and see whether Fedora > >> maintainers of those projects can help out with the conversion, or at > >> least submit it upstream for consideration. For me tiny "ucview" (using unicap library) takes care of most v4l1, v4l2 webcams and als has support for v4l2-1394. So camomara and spcaview are not the only OSS v4l1 viewers currently. Ucview also supports different formats and upstream is very active and responsive. Greetings, Robert From berrange at redhat.com Wed May 28 00:09:56 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 28 May 2008 01:09:56 +0100 Subject: package popularity ratings In-Reply-To: <1211924391.14871.90.camel@cutter> References: <1211917998.14871.88.camel@cutter> <20080527212514.GC14298@redhat.com> <1211924391.14871.90.camel@cutter> Message-ID: <20080528000956.GA14349@redhat.com> On Tue, May 27, 2008 at 05:39:51PM -0400, seth vidal wrote: > On Tue, 2008-05-27 at 22:25 +0100, Daniel P. Berrange wrote: > > On Tue, May 27, 2008 at 03:53:18PM -0400, seth vidal wrote: > > > Hi, > > > I got this bug assigned to yum the other day: > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=446836 > > > > > > it's not really a yum item, yet, b/c yum can really only USE the data, > > > not generate it. > > > > > > However, I don't know where it should go. Is anyone working on this sort > > > of thing? > > > > Isn't any package popularity rating going to be hugely skewed such that > > the 'default install set' packages are basically always rated top, making > > rankings of dubious value > > that's been my general impression which is why I was curious who wanted > to look at it since my overt bias against them is a bit discouraging :) I think a more useful metric would be a popularity list based on which programs are *run*. You'd obviously have to exclude things that are typically batch-run/scripted - eg bash would dominate. Count any binary run with a .desktop file perhaps, although that'd exclude mutt and emacs. IIRC mugshot/gnome live is already able to track this kind of metric Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From greno at verizon.net Wed May 28 02:55:26 2008 From: greno at verizon.net (Gerry Reno) Date: Tue, 27 May 2008 22:55:26 -0400 Subject: sata and changing devices In-Reply-To: <20080527082204.GA22443@devserv.devel.redhat.com> References: <483701CC.5010002@verizon.net> <20080523200048.GC13150@devserv.devel.redhat.com> <483727E1.80803@verizon.net> <20080523203439.GE13150@devserv.devel.redhat.com> <48372CD5.7010801@verizon.net> <4837458D.9080105@verizon.net> <483B4E2B.4060001@verizon.net> <20080527082204.GA22443@devserv.devel.redhat.com> Message-ID: <483CC99E.9090100@verizon.net> Alan Cox wrote: > On Mon, May 26, 2008 at 07:56:27PM -0400, Gerry Reno wrote: > >> specific piece of hardware. But the tool output now is still using this >> type of device identification (sda) which in the future is actually >> > > Nor did PATA except for the four "legacy" devices (hda-hdd) which have no > meaning for modern devices > > >> generate a backup state picture for physical SATA devices that >> encompasses mbr, partition tables, raid configuraton, lvm configuration, >> and filesystem mounting using mdadm, {pv|lv|vg}display, {f|sf}disk or >> parted. This was all very straightforward with PATA devices but is >> anything but with these SATA devices. >> > > SATA is hotplug, beyond "which is the boot volume" there isn't anything which > ties a drive to a given port. LVM/MD and friends all understand uuid/label for > good reason. > > Yes, I get all that. But in backup/recovery scenarios where say you've lost 3 drives out of 12 in 4 arrays (this happened to us). You've got to figure out what physical drives have to be replaced and then put the correct mbr and partitions back on their replacements from backups even before you can even get to stamping them with the old array uuid and then the higher level tools that understand uuid and filesystem labels at the end of the food chain can do their thing. It's great to have these logical views of the devices but in hardware failure/recovery scenarios you need a solid physical view of things so that you minimize confusion during hardware recovery and the risk of further damage. Many times during recovery you have to replace hardware, boot into rescue, perform some work, shutdown, install more hardware or change something about hardware, boot back into rescue, ... And each time you boot back into rescue, guess what, your device letters are changing so throw away your notes from the last boot and start over. So having all the tools provide a means of working in a physical view for recoveries would be a great thing. Regards, Gerry -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.wiktowy at gmail.com Wed May 28 03:57:01 2008 From: michael.wiktowy at gmail.com (Michael Wiktowy) Date: Tue, 27 May 2008 23:57:01 -0400 Subject: Sudoku PDF Printer Showdown Message-ID: <3e4ec4600805272057p3adc3507t65a7d61bc55a1f2d@mail.gmail.com> Hello, I decided to take a simple usage case to illustrate a killer feature in Linux that would be fantastic if it only didn't suck in a few ways. I hope that this prompts the developers with the know-how to do this last bit of polishing needed and spark some discussion on delivering the best user experience to make this PDF generation/viewing/editing work-flow absolutely top-notch. The application was chosen just because it generated a simple blend of text and vector graphics (and I actually tried to do this and email them to my family only to reinforce to them that Linux was a quirky pain when I was trying to illustrate to them the cool things that you could do with Linux out of the box) Pasted from Tomboy Notes so I hope the formating comes out as something better than flame-bait: *The Mission*: ? Print Multiple Sudoku puzzles as PDF files ? 10 puzzles with 2 per page ? View them anywhere ? Edit them *Tools used*: ? gnome-games.i386 1:2.22.1.1-5.fc9 ? cups-pdf.i386 2.4.7-1.fc9 ? cairo.i386 1.6.4-1.fc9 ? evince.i386 2.22.1.1-1.fc9 ? AdobeReader_enu.i486 8.1.2-1 ? inkscape.i386 0.46-2.fc9 ? selinux-policy.noarch 3.3.1-55.fc9 (this will make sense later) *Results*: Printing with Cups ("Cups-PDF"): ? Prints successfully ? good print format options ? just dumps it on the desktop with some default name ? cups-pdf setroubleshooter unhappiness ? see https://bugzilla.redhat.com/show_bug.cgi?id=448652 ? Displays correctly in Evince ? Displays correctly in Adobe Reader ? Imports incorrectly in Inkscape ? missing all text but at least lines are shown and editable after ungrouping ? see https://bugzilla.redhat.com/show_bug.cgi?id=448654 ? multiple of binary streams when viewed in text editor Printing with Cairo ("Create a PDF document"): ? Prints successfully ? more limited print format options ? can choose where the file goes and what it is called ? but file chooser is not obvious and keeps defaulting back to output.pdf in user's home directory ? Displays correctly in Evince ? Displays incorrectly in Adobe Reader ? missing bottom puzzle numbers and title in each page ? see https://bugzilla.redhat.com/show_bug.cgi?id=441341 ? and upstream bug http://bugzilla.gnome.org/show_bug.cgi?id=527954 ? Imports beautifully in Inkscape ? ungrouped and editable text and lines ? only one binary stream when viewed in text editor Printing with Ideal Fictional Dream PDF Printer: ? Print successfully (cairo comes closest) ? Give me the choice of where to stick the file upon Clicking print or make the default name a bit more intuitive ("appname_date.pdf") ? default to the last chosen directory or at least "Documents" if it exists ? have a superset of Cups-PDF and Cairo print format options ? Display correctly in Evince (gold star for both cairo and cups-pdf ... and evince) ? Display correctly in Adobe Reader (cups-pdf wins) ? Import beautifully in Inkscape (cairo wins) ? as real editable fonts and vector art when source is vector art and embedded raster images when not ? grouped or upgrouped does not matter although grouped makes things easier to adjust position if you happened to import it over something existing ? I don't really care what it looks like in a text editor but my guess would be that the fewest binary blobs is best (cairo wins) Thanks for reading, /Mike From pingou at pingoured.fr Wed May 28 06:43:05 2008 From: pingou at pingoured.fr (pingou) Date: Wed, 28 May 2008 08:43:05 +0200 Subject: package popularity ratings In-Reply-To: <1211917998.14871.88.camel@cutter> References: <1211917998.14871.88.camel@cutter> Message-ID: <483CFEF9.9010809@pingoured.fr> seth vidal wrote: > Hi, > I got this bug assigned to yum the other day: > > https://bugzilla.redhat.com/show_bug.cgi?id=446836 > > it's not really a yum item, yet, b/c yum can really only USE the data, > not generate it. > > However, I don't know where it should go. Is anyone working on this sort > of thing? > I do not think that user would be that much interesting in having/knowing the top 1000 software used... By doing this that would influence them, and oriented them to the most used one... better stay in another famous and world well known proprietary software that almost every one use... But I do think that I would like to have this information for the package I maintain ! Nowadays as packager the only feed back that told me that my packages are used is basically bugzilla, which mean that if I have packaged a good software that runs without problem I have no idea whether I have worked for myself or if other people are actually using it. In brief: * I do not want/need these information for all the packages as a user * I want these information for my packages as I am a packager. Hope it makes sense :) Regards, Pierre From mail at robertoragusa.it Wed May 28 08:29:25 2008 From: mail at robertoragusa.it (Roberto Ragusa) Date: Wed, 28 May 2008 10:29:25 +0200 Subject: Wiki Migration (Tuesday 05-26-2008) In-Reply-To: References: <64b14b300805270547s6a407242l1b9447fe0eb3c53b@mail.gmail.com> <1211898842.4570.124.camel@bree.homelinux.com> <1211899477.4868.8.camel@scrappy.miketc.com> <1211900136.3594.111.camel@calliope.phig.org> <1211924451.15791.17.camel@londonpacket.bos.redhat.com> Message-ID: <483D17E5.3040504@robertoragusa.it> Jon Stanley wrote: > On Tue, May 27, 2008 at 5:40 PM, Jon Masters wrote: > >> Any idea why it is redirecting to https by default? Seems overkill. > > My best guess would be that we're using basic auth - therefore, no > opportunity to redrrect to https for a login page. If I'm on an http:// page and I click RandomPage, it switches to https. Can it be avoided? (I'm visiting as guest) -- Roberto Ragusa mail at robertoragusa.it From loupgaroublond at gmail.com Wed May 28 08:49:49 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Wed, 28 May 2008 10:49:49 +0200 Subject: package popularity ratings In-Reply-To: <604aa7910805271543macd17dape1e4a6ec7655f15@mail.gmail.com> References: <1211917998.14871.88.camel@cutter> <20080527212514.GC14298@redhat.com> <604aa7910805271543macd17dape1e4a6ec7655f15@mail.gmail.com> Message-ID: <7f692fec0805280149o7490cb8bo7bc75e6ff36a1f67@mail.gmail.com> On Wed, May 28, 2008 at 12:43 AM, Jeff Spaleta wrote: > On Tue, May 27, 2008 at 1:25 PM, Daniel P. Berrange wrote: >> Isn't any package popularity rating going to be hugely skewed such that >> the 'default install set' packages are basically always rated top, making >> rankings of dubious value > > I personally see zero value in a flat popularity rating. > I would see more value if we could find a way to correlate users such > that I could datamine the application preferences of people who were > already running systems similar to mine. > > For example, XFCE users as a breed might prefer certain applications > which are not 'popular' in the general userbase, but were immensely > popular inside the XFCE subculture. Those shared preferences would > never show up in a flat popularity rating..a rating destined to be > dominated by FVWM2 users...so such a flat rating would never really be > what XFCE users would find value in. > > But if we had a way to correlate a systems/usages/people with other > systems/usages/people which are mostly similar, then we have something > interesting as a metric...a metric that can support both common and > niche subgroups..based solely on individual usage cases or habits. > That way XCFE users, would end up correlating with other XCFE users > and would have the software 'popularity' ranking biased by that > correlation. > > It would end up being dynamic, in that as your usage patterns changed, > how you would correlate with others would change as well without > anyone elses habits changing. > > Centralization of 'popularity' is simply not flexible enough to be > interesting in the brave new world of the social network. This is actually an old issue, and it got brought up again last February when I spoke to the people at OpenSuSE. But first, a little history. When Smolt was started, there were privacy concerns. The decision was to restrict the amount of information collected, to ensure that there would be fewer complaints. The final decision was to collect no packaging information. Then, I came up with a privacy scheme that should eliminate 95% of the legitimate concerns one may have. This reopened the decision to collect arbitrary information. Nevertheless, Smolt and the project is concerned primarily with hardware, although we can be linked to easily with other databases. Personally, I would like to see packaging information kept out of our database anyways, just for complexity issues. Then, I spoke with some people from OpenSuSE and they mentioned that they had a similar project, one which collected information about the initially installed DE. We may include the capability to collect this information in a future version but it will probably be disabled by default on Fedora. If it does get setup, in the Fedora Land, the values would be determined by which DE package groups have been installed. Even so, the information can be selectively hidden from smolt, if the user prefers. Finally, I am interested in combining several programs into the firstboot screen. This way, we can make it easy for the user to decide how participatory he wants to be. Getting this together is on the Agenda for the summer. That said, Smolt itself won't be concerned with package information and details. - Yaakov "sick of recurring conversation threads" Nemoy From martin.sourada at gmail.com Wed May 28 08:55:48 2008 From: martin.sourada at gmail.com (Martin Sourada) Date: Wed, 28 May 2008 10:55:48 +0200 Subject: Firefox 3 dreadfully slow on new fedora wiki?! In-Reply-To: <483C8C70.3010401@gmail.com> References: <1211926007.3058.7.camel@pc-notebook> <483C8C70.3010401@gmail.com> Message-ID: <1211964948.3058.10.camel@pc-notebook> On Tue, 2008-05-27 at 15:34 -0700, Toshio Kuratomi wrote: > We're looking into this now on #fedora-admin. > > Mike Mcgrath has just made a change that appears to fix this. If not, > feel free to either hop on IRC to help diagnose or send another email. > > Thanks, > -Toshio > It looks like it's working now :-) Thanks, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From valent.turkovic at gmail.com Wed May 28 09:48:52 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 28 May 2008 11:48:52 +0200 Subject: libflashsupport In-Reply-To: <64b14b300805270539s296d306dt5a89cb60f722b8b@mail.gmail.com> References: <48372911.9010502@fedoraproject.org> <20080523205114.GB29875@nostromo.devel.redhat.com> <1211585673.3566.120.camel@cookie.hadess.net> <20080523235451.GA8466@tango.0pointer.de> <64b14b300805270328k3b1039c1k3f5d9971ca6307a7@mail.gmail.com> <20080527105227.GA17076@tango.0pointer.de> <64b14b300805270539s296d306dt5a89cb60f722b8b@mail.gmail.com> Message-ID: <64b14b300805280248v4bceeed8m3353f91db2350717@mail.gmail.com> On Tue, May 27, 2008 at 2:39 PM, Valent Turkovic wrote: > On Tue, May 27, 2008 at 12:52 PM, Lennart Poettering > wrote: >> On Tue, 27.05.08 12:28, Valent Turkovic (valent.turkovic at gmail.com) wrote: >> >>> > Adobe Flash 10 doesn't need libflashsupport anymore to work fine on >>> > ALSA ioplug-based backends such as pulse. >>> > >>> > Lennart >>> >>> Current version of Flash 10 doesn't work with Firefox under linux. >> >> Thanks for sharing this elaborate error description with us! >> >> Lennart > > I have downloaded and installed flash10 beta from adobe via their rpm > and also via .sh file under FC6 running FF3b. I have asked others on > local news group and I got few reports from people using other distros > that they also have issues with it not working. > > When I install it via rpm file then FF3 still says that I don't have > Flash plugin installed, so I remove it and install it via .sh file in > ~/.mozilla/plugins/ and then it doesn't complain that it doesn't have > the plugin but it still doesn't show any flash videos... > > It this better? ;) > > Cheers, > Valent. > > -- > http://kernelreloaded.blog385.com/ > linux, blog, anime, spirituality, windsurf, wireless > registered as user #367004 with the Linux Counter, http://counter.li.org. > ICQ: 2125241, Skype: valent.turkovic > I needed to so some sym linking but then flash 10 worked under FC6 with FF3. Flash 10 works under Fedora 9 for me. Cheers, Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From atkac at redhat.com Wed May 28 10:21:59 2008 From: atkac at redhat.com (Adam Tkac) Date: Wed, 28 May 2008 12:21:59 +0200 Subject: How act when bug should be documented in release notes or known bugs Message-ID: <20080528102159.GA10196@evileye.atkac.englab.brq.redhat.com> Hi all, is somewhere procedure how act when some bug should be documented in release notes or on known-bugs page? I'm talking about problem in F9 final - when you install bind-chroot package (you selected "Install DNS server") bind installation fails due no dependency on bind and after installation bind and bind-chroot have to be removed and installed again. (https://bugzilla.redhat.com/show_bug.cgi?id=446477#c6) Update is released but it would be nice to inform users that this problem exists and they should not install bind-chroot directly from ISO. How should I do it? Regards, Adam -- Adam Tkac, Red Hat, Inc. From dev at nigelj.com Wed May 28 10:23:04 2008 From: dev at nigelj.com (Nigel Jones) Date: Wed, 28 May 2008 22:23:04 +1200 Subject: Outage Notification - 2008-05-28 10:00 UTC Message-ID: <483D3288.2040401@nigelj.com> We are currently experiencing an unplanned outage as of 2008-05-28 10:00 UTC Affected Services: CVS / Source Control Unaffected Services: Websites Buildsystem Database DNS Mail Torrent Reason for Outage: There appears to be a routing issue preventing outside hosts accessing the machine that runs the CVS system used by Fedora Developers and the Docs Team We are currently in the process of isolating the issue but an ETA is not available and apologise for any inconvenience. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. Regards, Nigel Jones From rawhide at fedoraproject.org Wed May 28 10:39:43 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Wed, 28 May 2008 10:39:43 +0000 (UTC) Subject: rawhide report: 20080528 changes Message-ID: <20080528103943.DFE91209CC4@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080527/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080528/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package daa2iso Program for converting DAA files to ISO New package libcaptury A library for X11/OpenGL video capturing framework New package lxsplit File split / merge utility New package perl-Event-Lib Perl wrapper around libevent New package qgtkstyle Qt style rendering using GTK+ themes Updated Packages: AcetoneISO2-2.0.2-4.fc10 ------------------------ * Tue May 27 18:00:00 2008 Tom "spot" Callaway - 2.0.2-4 - only try to use PowerISO as a converter on x86 platforms (bz 447214) GMT-4.3.1-2.fc10 ---------------- * Tue May 27 18:00:00 2008 Orion Poplawski 4.3.1-2 - Fix lowercase provides (bug #448263) GMT-doc-4.3.1-2 --------------- LabPlot-1.5.1.6-6.fc9 --------------------- * Sat Apr 12 18:00:00 2008 Thibault North - 1.5.1.6-6 - Fixes for GCC 4.3 - Updated dependencies - Now requires electronics-menu R-multtest-1.20.0-2.fc10 ------------------------ * Tue May 27 18:00:00 2008 pingou 1.20.0-2 - Rebuild R-qvalue-1.14.0-2.fc10 ---------------------- * Tue May 27 18:00:00 2008 pingou 1.14.0-2 - Rebuild * Tue May 27 18:00:00 2008 pingou 1.14.0-1 - Update to version 1.14.0 TurboGears-1.0.4.4-3.fc10 ------------------------- * Tue May 27 18:00:00 2008 Luke Macken 1.0.4.4-3 - Patch our setup.py to remove the hard version requirements for SQLObject. This has changed upstream as well. anyremote-4.6-1.fc10 -------------------- * Fri May 30 18:00:00 2008 Mikhail Fedotov - 4.6-1 - Small enhancements bibletime-1.6.5.1-1.fc10 ------------------------ * Mon May 26 18:00:00 2008 Deji Akingunola - 1.6.5.1-1 - Update to 1.6.5.1 bluez-gnome-0.26-1.fc9 ---------------------- * Tue Apr 8 18:00:00 2008 - Bastien Nocera - 0.26-1 - Update to 0.26 cairo-dock-1.5.6-0.1.svn1044_trunk.fc10 --------------------------------------- * Tue May 27 18:00:00 2008 Mamoru Tasaka - svn 1044 cdrkit-1.1.8-1.fc10 ------------------- * Tue May 27 18:00:00 2008 Roman Rakus - 1.1.8-1 - Version 1.1.8 - old patches included - added bzip2-devel to build requirements - fixed #171510 - preserve directory permissions compiz-0.7.2-5.fc10 ------------------- * Tue May 27 18:00:00 2008 Kevin Kofler - 0.7.2-5 - Rebuild for KDE 4.0.80 control-center-2.23.2-1.fc10 ---------------------------- * Tue May 27 18:00:00 2008 Matthias Clasen - 2.23.2-1 - Update to 2.23.2 dbus-glib-0.74-9.fc10 --------------------- * Tue May 27 18:00:00 2008 Dan Williams - 0.74-9 - Handle unknown object properties without asserting (fdo #16079) - Handle GetAll() property names correctly (fdo #16114) - Enable the freeze-abi patch - Cherry-pick some fixes from upstream git * Thu May 8 18:00:00 2008 Matthias Clasen - 0.74-8 - Fix license field * Tue Apr 15 18:00:00 2008 Colin Walters - 0.74-7 - Ensure ABI is frozen as it stands now dhcpv6-1.0.17-1.fc10 -------------------- * Fri May 23 18:00:00 2008 David Cantrell - 1.0.16-1 - Upgrade to dhcpv6-1.0.16, major changes: Use libnl rather than homegrown netlink code Better error handling in dhcp6c Updates to the dhcp6c usage screen and man page Record the correct PID for dhcp6c eclipse-mylyn-2.3.2-6.fc9 ------------------------- * Wed May 14 18:00:00 2008 Andrew Overholt 2.3.2-6 - ".qualifier" -> actual release qualifier in build (due to upstream build system change (e.o#108291, rh#446468). evolution-sharp-0.17.2-2.fc10 ----------------------------- * Tue May 27 18:00:00 2008 Matthew Barnes - 0.17.2-2.fc10 - Rebuild against newer mono(glib-sharp). extragear-plasma-4.0.80-2.fc10 ------------------------------ * Tue May 27 18:00:00 2008 Kevin Kofler 4.0.80-2 - add missing BR openldap-devel - update file list, add icon scriptlets * Mon May 26 18:00:00 2008 Than Ngo 4.0.80-1 - 4.1 beta 1 filesystem-2.4.15-1.fc10 ------------------------ * Tue May 27 18:00:00 2008 Phil Knirsch - 2.4.15-1 - First round of Fedora package review changes (#225752) gcalctool-5.23.2-1.fc10 ----------------------- * Tue May 27 18:00:00 2008 Matthias Clasen - 5.23.2-1 - Update to 5.23.2 gdal-1.5.1-11.fc10 ------------------ * Tue May 27 18:00:00 2008 Balint Cristian - 1.5.1-11 - fix multilib gdal-config, add wrapper around - fix typos in cpl_config.h wrapper * Tue May 27 18:00:00 2008 Balint Cristian - 1.5.1-10 - fix for multilib packaging bz#341231 - huge spec cleanup - enable russian and brazil docs - enable and triage more docs glib2-2.17.0-1.fc10 ------------------- * Tue May 27 18:00:00 2008 Matthias Clasen - 2.17.0-1 - Update to 2.17.0 gmime-2.2.21-1.fc10 ------------------- * Tue May 27 18:00:00 2008 Matthias Clasen - 2.2.21-1 - Update to 2.2.21 gnome-keyring-2.22.2-1.fc10 --------------------------- * Tue May 27 18:00:00 2008 Tomas Bzatek - 2.22.2-1 - Update to 2.22.2 gnome-system-monitor-2.23.2-1.fc10 ---------------------------------- * Tue May 27 18:00:00 2008 Matthias Clasen - 2.23.2-1 - Update to 2.23.2 gnomesword-2.3.4-1.fc10 ----------------------- * Mon May 26 18:00:00 2008 Deji Akingunola - 2.3.4-1 - Update to 2.3.4 gnupg-1.4.9-3.fc10 ------------------ * Tue May 27 18:00:00 2008 Nalin Dahyabhai - 1.4.9-3 - note license is actually GPLv3+ rather than just GPLv3 (Todd Zullinger, * Sat May 24 18:00:00 2008 Tom "spot" Callaway - 1.4.9-2 - fix build failure with curl-7.18.1+ and gcc-4.3+ * Mon May 19 18:00:00 2008 Dennis Gilmore - 1.4.9-1.1 - rebuild for sparc guitone-0.8-1.fc10 ------------------ * Mon May 26 18:00:00 2008 Thomas Moschny - 0.8-1 - Update to upstream version 0.8. - Add a zero-day patch from upstream. - License is GPLv3+ now. gvfs-0.2.4-1.fc10 ----------------- * Tue May 27 18:00:00 2008 Tomas Bzatek - 0.2.4-1 - Update to 0.2.4 hdf5-1.8.1-0.rc1.1.fc10 ----------------------- * Tue May 27 18:00:00 2008 Orion Poplawski 1.8.1-0.rc1.1 - Update to 1.8.1-rc1 imapsync-1.252-2.fc10 --------------------- * Tue May 27 18:00:00 2008 Marek Mahut - 1.252-2 - Upstream release - Dependency fix (BZ#447800) ipod-sharp-0.8.0-5.fc10 ----------------------- * Tue May 27 18:00:00 2008 Nigel Jones 0.8.0-5 - Rebuild for new gtk-sharp2 k3b-1.0.5-1.fc10 ---------------- * Tue May 27 18:00:00 2008 Rex Dieter - 0:1.0.5-1 - k3b-1.0.5 - k3brc: set manual buffer size here - omit reload patch (for now), to verify if still needed. kde-l10n-4.0.80-1.fc10 ---------------------- * Mon May 26 18:00:00 2008 Than Ngo 4.0.80-1 - 4.1 beta 1 kdeaccessibility-4.0.80-1.fc10 ------------------------------ * Mon May 26 18:00:00 2008 Than Ngo 4.0.80-1 - Beta 1 kdeadmin-4.0.80-1.fc10 ---------------------- * Mon May 26 18:00:00 2008 Than Ngo 4.0.80-1 - 4.1 beta1 kdeartwork-4.0.80-1.fc10 ------------------------ * Mon May 26 18:00:00 2008 Than Ngo 4.0.80-1 - 4.1 beta1 kdebase-4.0.80-3.fc10 --------------------- * Tue May 27 18:00:00 2008 Than Ngo 4.0.80-2 - rebuild to fix undefined symbol issue in dolphin * Tue May 27 18:00:00 2008 Kevin Kofler 4.0.80-3 - respun tarball from upstream kdebindings-4.0.80-2.fc10 ------------------------- * Tue May 27 18:00:00 2008 Kevin Kofler 4.0.80-2 - disable php-qt for now - apply PyKDE4 and smokekde build fixes from upstream - update file lists (comment out smokeplasma, add new smoke/ruby files) - fix incorrect libdir on lib64 platforms * Mon May 26 18:00:00 2008 Than Ngo 4.0.80-1 - 4.1 beta1 kdeedu-4.0.80-2.fc10 -------------------- * Tue May 27 18:00:00 2008 Kevin Kofler 4.0.80-2 - patch to build against OpenBabel 2.2.0 beta4 * Mon May 26 18:00:00 2008 Than Ngo 4.0.80-1 - 4.1 beta1 kdegames-4.0.80-2.fc10 ---------------------- * Tue May 27 18:00:00 2008 Kevin Kofler 4.0.80-2 - Obsoletes/Provides ksirk * Mon May 26 18:00:00 2008 Than Ngo 4.0.80-1 - 4.1 beta1 kdegraphics-4.0.80-1.fc10 ------------------------- * Mon May 26 18:00:00 2008 Than Ngo 4.0.80-1 - 4.1 beta1 kdemultimedia-4.0.80-1.fc10 --------------------------- * Mon May 26 18:00:00 2008 Than Ngo 4.0.80-1 - 4.1 beta1 kdenetwork-4.0.80-1.fc10 ------------------------ * Mon May 26 18:00:00 2008 Than Ngo 4.0.80-1 - 4.1 beta1 kdepim-4.0.80-1.fc10 -------------------- * Mon May 26 18:00:00 2008 Than Ngo 4.0.80-1 - 4.1 beta1 kdesdk-4.0.80-1.fc10 -------------------- * Mon May 26 18:00:00 2008 Than Ngo 4.0.80-1 - 4.1 beta1 kdetoys-4.0.80-1.fc10 --------------------- * Mon May 26 18:00:00 2008 Than Ngo 4.0.80-1 - 4.1 beta1 kdeutils-4.0.80-1.fc10 ---------------------- * Mon May 26 18:00:00 2008 Than Ngo 4.0.80-1 - 4.1 beta1 Broken deps for i386 ---------------------------------------------------------- LabPlot-1.5.1.6-6.fc9.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libWand.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libMagick.so.10 avahi-ui-sharp-0.6.22-10.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 avahi-ui-sharp-0.6.22-10.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 basket-kontact-1.0.2-5.fc9.i386 requires libkpinterfaces.so.1 basket-kontact-1.0.2-5.fc9.i386 requires libkcal.so.2 basket-kontact-1.0.2-5.fc9.i386 requires libktnef.so.1 basket-kontact-1.0.2-5.fc9.i386 requires kdepim3 basket-kontact-1.0.2-5.fc9.i386 requires libkdepim.so.1 beagle-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-evolution-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-thunderbird-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 dsniff-2.4-0.2.b1.fc9.i386 requires libnids.so.1.21 evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.i386 requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-1.2.so.11 f-spot-0.4.3.1-1.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.i386 requires mono(glade-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(atk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(glade-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(pango-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gsf-sharp-0.8.1-7.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.i386 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 kismet-extras-0.0.2007.10.R1-3.fc9.i386 requires libMagick.so.10 libopensync-plugin-kdepim-0.35-2.fc9.i386 requires libkcal.so.2 lsvpd-1.6.4-1.fc10.i386 requires libvpd_cxx-2.0.so.1 mono-addins-0.3.1-1.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 mono-addins-0.3.1-1.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 mono-addins-0.3.1-1.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 mono-addins-0.3.1-1.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.i386 requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.i386 requires libgeos.so.2 smart-0.52-54.fc9.i386 requires smart-config taskjuggler-2.4.1-1.fc10.i386 requires libkcal.so.2 taskjuggler-2.4.1-1.fc10.i386 requires libktnef.so.1 taskjuggler-libs-2.4.1-1.fc10.i386 requires libkcal.so.2 tomboy-0.10.1-2.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.i386 requires mono(pango-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 Broken deps for x86_64 ---------------------------------------------------------- LabPlot-1.5.1.6-6.fc9.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libWand.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libMagick.so.10 LabPlot-1.5.1.6-6.fc9.x86_64 requires libMagick++.so.10()(64bit) LabPlot-1.5.1.6-6.fc9.x86_64 requires libMagick.so.10()(64bit) LabPlot-1.5.1.6-6.fc9.x86_64 requires libWand.so.10()(64bit) avahi-ui-sharp-0.6.22-10.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 avahi-ui-sharp-0.6.22-10.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 basket-kontact-1.0.2-5.fc9.x86_64 requires libkcal.so.2()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires libkdepim.so.1()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires libktnef.so.1()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires kdepim3 basket-kontact-1.0.2-5.fc9.x86_64 requires libkpinterfaces.so.1()(64bit) beagle-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-evolution-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-thunderbird-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 dsniff-2.4-0.2.b1.fc9.x86_64 requires libnids.so.1.21()(64bit) evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libWand.so.10()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) f-spot-0.4.3.1-1.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx gbrainy-0.61-5.fc9.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(atk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gsf-sharp-0.8.1-7.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 kismet-extras-0.0.2007.10.R1-3.fc9.x86_64 requires libMagick.so.10()(64bit) libopensync-plugin-kdepim-0.35-2.fc9.x86_64 requires libkcal.so.2()(64bit) lsvpd-1.6.4-1.fc10.x86_64 requires libvpd_cxx-2.0.so.1()(64bit) mono-addins-0.3.1-1.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 mono-addins-0.3.1-1.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 mono-addins-0.3.1-1.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 mono-addins-0.3.1-1.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) smart-0.52-54.fc9.x86_64 requires smart-config taskjuggler-2.4.1-1.fc10.x86_64 requires libkcal.so.2()(64bit) taskjuggler-2.4.1-1.fc10.x86_64 requires libktnef.so.1()(64bit) taskjuggler-libs-2.4.1-1.fc10.i386 requires libkcal.so.2 taskjuggler-libs-2.4.1-1.fc10.x86_64 requires libkcal.so.2()(64bit) tomboy-0.10.1-2.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 Broken deps for ppc ---------------------------------------------------------- LabPlot-1.5.1.6-6.fc9.ppc requires libMagick++.so.10 LabPlot-1.5.1.6-6.fc9.ppc requires libWand.so.10 LabPlot-1.5.1.6-6.fc9.ppc requires libMagick.so.10 avahi-ui-sharp-0.6.22-10.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 avahi-ui-sharp-0.6.22-10.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 basket-kontact-1.0.2-5.fc9.ppc requires libkpinterfaces.so.1 basket-kontact-1.0.2-5.fc9.ppc requires libkcal.so.2 basket-kontact-1.0.2-5.fc9.ppc requires libktnef.so.1 basket-kontact-1.0.2-5.fc9.ppc requires kdepim3 basket-kontact-1.0.2-5.fc9.ppc requires libkdepim.so.1 beagle-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 beagle-evolution-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 beagle-thunderbird-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 dsniff-2.4-0.2.b1.fc9.ppc requires libnids.so.1.21 evolution-brutus-1.2.11-2.fc9.ppc requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.ppc requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.ppc requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.ppc requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-1.2.so.11 f-spot-0.4.3.1-1.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.ppc requires mono(glade-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(atk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(glade-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(pango-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gsf-sharp-0.8.1-7.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.ppc requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 kismet-extras-0.0.2007.10.R1-3.fc9.ppc requires libMagick.so.10 libopensync-plugin-kdepim-0.35-2.fc9.ppc requires libkcal.so.2 lsvpd-1.6.4-1.fc10.ppc requires libvpd_cxx-2.0.so.1 mono-addins-0.3.1-1.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 mono-addins-0.3.1-1.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 mono-addins-0.3.1-1.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 mono-addins-0.3.1-1.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.ppc requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.ppc requires libgeos.so.2 smart-0.52-54.fc9.ppc requires smart-config taskjuggler-2.4.1-1.fc10.ppc requires libkcal.so.2 taskjuggler-2.4.1-1.fc10.ppc requires libktnef.so.1 taskjuggler-libs-2.4.1-1.fc10.ppc requires libkcal.so.2 taskjuggler-libs-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) tomboy-0.10.1-2.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.ppc requires mono(pango-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 Broken deps for ppc64 ---------------------------------------------------------- basket-kontact-1.0.2-5.fc9.ppc64 requires libkcal.so.2()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires libkdepim.so.1()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires libktnef.so.1()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires kdepim3 basket-kontact-1.0.2-5.fc9.ppc64 requires libkpinterfaces.so.1()(64bit) dsniff-2.4-0.2.b1.fc9.ppc64 requires libnids.so.1.21()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) kismet-extras-0.0.2007.10.R1-3.fc9.ppc64 requires libMagick.so.10()(64bit) libopensync-plugin-kdepim-0.35-2.fc9.ppc64 requires libkcal.so.2()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot lsvpd-1.6.4-1.fc10.ppc64 requires libvpd_cxx-2.0.so.1()(64bit) perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) smart-0.52-54.fc9.ppc64 requires smart-config taskjuggler-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) taskjuggler-2.4.1-1.fc10.ppc64 requires libktnef.so.1()(64bit) taskjuggler-libs-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) From mtasaka at ioa.s.u-tokyo.ac.jp Wed May 28 13:20:45 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 28 May 2008 22:20:45 +0900 Subject: Wiki Migration Complete! In-Reply-To: References: Message-ID: <483D5C2D.6070901@ioa.s.u-tokyo.ac.jp> Mike McGrath wrote, at 05/28/2008 08:05 AM +9:00: > The migration to Mediawiki is finally complete! The technical side, > that is. Now is the part where we all learn how to migrate our > knowledge and clean-up content. > > http://fedoraproject.org/wiki/ As I am doing many package reviews I have a question. Before this migration https://fedoraproject.org/wiki/Packaging showed all wiki pages which were marked as in "Packaging" category and from the page I usually searched the needed wiki page related to packaging issue. Now the URL above shows almost nothing. Are there similar page now which shows all wiki pages related to packaging issue? Regards, Mamoru From aportal at univ-montp2.fr Wed May 28 13:45:45 2008 From: aportal at univ-montp2.fr (Alain PORTAL) Date: Wed, 28 May 2008 15:45:45 +0200 Subject: Wiki Migration Complete! In-Reply-To: <483D5C2D.6070901@ioa.s.u-tokyo.ac.jp> References: <483D5C2D.6070901@ioa.s.u-tokyo.ac.jp> Message-ID: <200805281545.46044.aportal@univ-montp2.fr> Le mercredi 28 mai 2008 ? 15:20, Mamoru Tasaka a ?crit?: > Now the URL above shows almost nothing. Are there similar page now > which shows all wiki pages related to packaging issue? Yes https://fedoraproject.org/wiki/PackageMaintainers Regards Alain -- La version fran?aise des pages de manuel Linux http://manpagesfr.free.fr From martin.sourada at gmail.com Wed May 28 13:42:21 2008 From: martin.sourada at gmail.com (Martin Sourada) Date: Wed, 28 May 2008 15:42:21 +0200 Subject: Wiki Migration Complete! In-Reply-To: <483D5C2D.6070901@ioa.s.u-tokyo.ac.jp> References: <483D5C2D.6070901@ioa.s.u-tokyo.ac.jp> Message-ID: <1211982141.32592.10.camel@pc-notebook> On Wed, 2008-05-28 at 22:20 +0900, Mamoru Tasaka wrote: > Mike McGrath wrote, at 05/28/2008 08:05 AM +9:00: > > The migration to Mediawiki is finally complete! The technical side, > > that is. Now is the part where we all learn how to migrate our > > knowledge and clean-up content. > > > > http://fedoraproject.org/wiki/ > > As I am doing many package reviews I have a question. > > Before this migration > https://fedoraproject.org/wiki/Packaging > showed all wiki pages which were marked as in "Packaging" category > and from the page I usually searched the needed wiki page related to > packaging issue. > > Now the URL above shows almost nothing. Are there similar page now > which shows all wiki pages related to packaging issue? > > Regards, > Mamoru > Might this one [1] be the page you are looking for? Martin References: [1] https://fedoraproject.org/wiki/PackageMaintainers -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mtasaka at ioa.s.u-tokyo.ac.jp Wed May 28 13:52:07 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 28 May 2008 22:52:07 +0900 Subject: Wiki Migration Complete! In-Reply-To: <200805281545.46044.aportal@univ-montp2.fr> References: <483D5C2D.6070901@ioa.s.u-tokyo.ac.jp> <200805281545.46044.aportal@univ-montp2.fr> Message-ID: <483D6387.9000005@ioa.s.u-tokyo.ac.jp> Alain PORTAL wrote, at 05/28/2008 10:45 PM +9:00: > Le mercredi 28 mai 2008 ? 15:20, Mamoru Tasaka a ?crit : > >> Now the URL above shows almost nothing. Are there similar page now >> which shows all wiki pages related to packaging issue? > > Yes > https://fedoraproject.org/wiki/PackageMaintainers > Actually no. The URL you quoted does not have the link to the guidelines of Ruby, Java, python related packages, sysv initscripts conventions, etc. Regards, Mamoru From pertusus at free.fr Wed May 28 13:51:53 2008 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 28 May 2008 15:51:53 +0200 Subject: Wiki Migration Complete! In-Reply-To: <200805281545.46044.aportal@univ-montp2.fr> References: <483D5C2D.6070901@ioa.s.u-tokyo.ac.jp> <200805281545.46044.aportal@univ-montp2.fr> Message-ID: <20080528135153.GC2588@free.fr> On Wed, May 28, 2008 at 03:45:45PM +0200, Alain PORTAL wrote: > Le mercredi 28 mai 2008 ? 15:20, Mamoru Tasaka a ?crit?: > > > Now the URL above shows almost nothing. Are there similar page now > > which shows all wiki pages related to packaging issue? > > Yes > https://fedoraproject.org/wiki/PackageMaintainers This page is the equivalent of the former front page for packagers, which was a table previously. I am not sure it is what Mamoru is looking for. -- Pat From mtasaka at ioa.s.u-tokyo.ac.jp Wed May 28 14:01:56 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 28 May 2008 23:01:56 +0900 Subject: Wiki Migration Complete! In-Reply-To: <20080528135153.GC2588@free.fr> References: <483D5C2D.6070901@ioa.s.u-tokyo.ac.jp> <200805281545.46044.aportal@univ-montp2.fr> <20080528135153.GC2588@free.fr> Message-ID: <483D65D4.8040100@ioa.s.u-tokyo.ac.jp> Patrice Dumas wrote, at 05/28/2008 10:51 PM +9:00: > On Wed, May 28, 2008 at 03:45:45PM +0200, Alain PORTAL wrote: >> Le mercredi 28 mai 2008 ? 15:20, Mamoru Tasaka a ?crit : >> >>> Now the URL above shows almost nothing. Are there similar page now >>> which shows all wiki pages related to packaging issue? >> Yes >> https://fedoraproject.org/wiki/PackageMaintainers > > This page is the equivalent of the former front page for packagers, > which was a table previously. I am not sure it is what Mamoru is looking > for. > I am looking for (from google cache:) http://72.14.235.104/search?q=cache:Xe4_JbpotHcJ:fedoraproject.org/wiki/Packaging+http://fedoraproject.org/wiki/Packaging&ct=clnk&cd=1 Regards, Mamoru From galibert at pobox.com Wed May 28 14:09:52 2008 From: galibert at pobox.com (Olivier Galibert) Date: Wed, 28 May 2008 16:09:52 +0200 Subject: Wiki Migration Complete! In-Reply-To: <483D5C2D.6070901@ioa.s.u-tokyo.ac.jp> References: <483D5C2D.6070901@ioa.s.u-tokyo.ac.jp> Message-ID: <20080528140952.GA77125@dspnet.fr.eu.org> On Wed, May 28, 2008 at 10:20:45PM +0900, Mamoru Tasaka wrote: > Mike McGrath wrote, at 05/28/2008 08:05 AM +9:00: > >The migration to Mediawiki is finally complete! The technical side, > >that is. Now is the part where we all learn how to migrate our > >knowledge and clean-up content. > > > >http://fedoraproject.org/wiki/ > > As I am doing many package reviews I have a question. > > Before this migration > https://fedoraproject.org/wiki/Packaging > showed all wiki pages which were marked as in "Packaging" category > and from the page I usually searched the needed wiki page related to > packaging issue. > > Now the URL above shows almost nothing. Are there similar page now > which shows all wiki pages related to packaging issue? The mediawiki way is to add a [[Category:Packaging]] in all the pages you're interested in, I'd guess all in Packaging/*. Then the page Category:Packaging will have the list. OG. From dev at nigelj.com Wed May 28 13:55:13 2008 From: dev at nigelj.com (Nigel Jones) Date: Thu, 29 May 2008 01:55:13 +1200 Subject: Wiki Migration Complete! In-Reply-To: <483D6387.9000005@ioa.s.u-tokyo.ac.jp> References: <483D5C2D.6070901@ioa.s.u-tokyo.ac.jp> <200805281545.46044.aportal@univ-montp2.fr> <483D6387.9000005@ioa.s.u-tokyo.ac.jp> Message-ID: <483D6441.8040303@nigelj.com> Mamoru Tasaka wrote: > Alain PORTAL wrote, at 05/28/2008 10:45 PM +9:00: >> Le mercredi 28 mai 2008 ? 15:20, Mamoru Tasaka a ?crit : >> >>> Now the URL above shows almost nothing. Are there similar page now >>> which shows all wiki pages related to packaging issue? >> >> Yes >> https://fedoraproject.org/wiki/PackageMaintainers >> > > Actually no. > The URL you quoted does not have the link to the guidelines of Ruby, > Java, python > related packages, sysv initscripts conventions, etc. http://fedoraproject.org/wiki/Packaging/Guidelines - Nigel > > Regards, > Mamoru > From gjalves at gjalves.com.br Wed May 28 14:16:58 2008 From: gjalves at gjalves.com.br (Gustavo Alves) Date: Wed, 28 May 2008 11:16:58 -0300 Subject: PATH for sudo users Message-ID: <69e11d1f0805280716g7b088efcif62c248fbe259cdc@mail.gmail.com> The file /etc/profile only allow /sbin and /usr/sbin paths to uid 0 user. Unfortunately, other users needs this path, as sys group (refered on sudoers, for example). To avoid the inclusion of the path on each user, I like to implement some sort of autoconfiguration. As first try, I'm allowing the /sbin path to euid 0 and group_id sys and adm. There is another way to do this? Fedora should do it? Thanks for any advises. -- Gustavo Junior Alves GJAlves Tecnologia Tel: +55 19 9223-0500 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bpepple at fedoraproject.org Wed May 28 14:28:00 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 28 May 2008 10:28:00 -0400 Subject: Plan for tomorrows (20080529) FESCO meeting Message-ID: <1211984880.27774.3.camel@truman> Hi all, Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC in #fedora-meeting on irc.freenode.org: /topic FESCo meeting -- https://fedoraproject.org/wiki/Extras/Schedule/SponsorResponsibilityPolicy -- bpepple topic FESCO-Meeting -- FESCo Responsibilities/Role -- all /topic FESCo meeting -- Free discussion around Fedora You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule. You can also propose topics in the meeting while it is in the "Free discussion around Fedora" phase. If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing... Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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: 197 bytes Desc: This is a digitally signed message part URL: From sstarr at platform.com Wed May 28 14:38:13 2008 From: sstarr at platform.com (Shawn Starr) Date: Wed, 28 May 2008 10:38:13 -0400 Subject: PATH for sudo users Message-ID: >Gustavo Alves >Sent: Wednesday, May 28, 2008 10:17 AM >Subject: PATH for sudo users >The file /etc/profile only allow /sbin and /usr/sbin paths to uid 0 user. Unfortunately, other users needs this >path, as sys group (refered on sudoers, for example). To avoid the inclusion of the path on each user, I like to implement some sort of >autoconfiguration. As first try, I'm allowing the /sbin path to euid 0 and group_id sys and adm. There is another way to do this? >Fedora should do it? >Thanks for any advises. -- >Gustavo Junior Alves Hi Gustavo, You might want to search for the following thread for the discussion: "Adding /sbin and /usr/sbin to everyone's path in F10" Thanks, Shawn. From P at draigBrady.com Wed May 28 14:41:19 2008 From: P at draigBrady.com (=?ISO-8859-1?Q?P=E1draig_Brady?=) Date: Wed, 28 May 2008 15:41:19 +0100 Subject: PATH for sudo users In-Reply-To: <69e11d1f0805280716g7b088efcif62c248fbe259cdc@mail.gmail.com> References: <69e11d1f0805280716g7b088efcif62c248fbe259cdc@mail.gmail.com> Message-ID: <483D6F0F.2070409@draigBrady.com> Gustavo Alves wrote: > The file /etc/profile only allow /sbin and /usr/sbin paths to uid 0 > user. Unfortunately, other users needs this path, as sys group (refered > on sudoers, for example). To avoid the inclusion of the path on each > user, I like to implement some sort of autoconfiguration. As first try, > I'm allowing the /sbin path to euid 0 and group_id sys and adm. There is > another way to do this? Fedora should do it? > > Thanks for any advises. I think all users are getting the /sbin/ paths in F10 which should make this a moot point? Interestingly on ubuntu user paths are not propagated by sudo for security reasons (sudo is built --with-secure-path) I work around this by defining the following alias: alias sudo='sudo env PATH=$PATH' P?draig. From robert at marcanoonline.com Wed May 28 16:06:57 2008 From: robert at marcanoonline.com (Robert Marcano) Date: Wed, 28 May 2008 11:36:57 -0430 Subject: PATH for sudo users In-Reply-To: <69e11d1f0805280716g7b088efcif62c248fbe259cdc@mail.gmail.com> References: <69e11d1f0805280716g7b088efcif62c248fbe259cdc@mail.gmail.com> Message-ID: <1211990817.2901.7.camel@localhost.localdomain> On Wed, 2008-05-28 at 11:16 -0300, Gustavo Alves wrote: > The file /etc/profile only allow /sbin and /usr/sbin paths to uid 0 > user. Unfortunately, other users needs this path, as sys group > (refered on sudoers, for example). To avoid the inclusion of the path > on each user, I like to implement some sort of autoconfiguration. As > first try, I'm allowing the /sbin path to euid 0 and group_id sys and > adm. There is another way to do this? Fedora should do it? > > Thanks for any advises. add a new script to /etc/profile.d/ > > -- > Gustavo Junior Alves > GJAlves Tecnologia > Tel: +55 19 9223-0500 ________________________________________ Robert Marcano web: http://www.marcanoonline.com/ gpg --keyserver hkp://pgp.mit.edu/ --recv-key 72A0DCFD From fedora at dm.cobite.com Wed May 28 16:09:49 2008 From: fedora at dm.cobite.com (David Mansfield) Date: Wed, 28 May 2008 12:09:49 -0400 Subject: perl DateTime packaging question In-Reply-To: <20080527214957.GC2663@free.fr> References: <1211921102.16076.39.camel@gandalf.cobite.com> <20080527210647.GA2663@free.fr> <20080527214957.GC2663@free.fr> Message-ID: <1211990989.16076.44.camel@gandalf.cobite.com> On Tue, 2008-05-27 at 23:49 +0200, Patrice Dumas wrote: > On Tue, May 27, 2008 at 04:41:23PM -0500, Jason L Tibbitts III wrote: > > >>>>> "PD" == Patrice Dumas writes: > > > > PD> It is, although shipping different packages in one (with different > > PD> release schedules, tarballs, authors etc.) is bad > > PD> practice. Normally this is raised during reviews, but not here. > > > > Well, this was explained in the review ticket: > > https://bugzilla.redhat.com/show_bug.cgi?id=167376 > > > > "This package is a bit odd. To avoid circular dependencies, I've > > bundled DateTime, DateTime::Locale, and DateTime::TimeZone." > > > > I'm not sure of the best way to avoid those circular dependencies, but > > surely bundling a few closely related and very small modules is low on > > the hierarchy of packaging sins. > > I think that it is perfectly right, in fact. > > > PD> I suggest that you open a bug against perl-DateTime. > > > > Not sure what good it would do, given the above. > > Indeed, sorry, I missed the explanation. > Problem is, the explanation is a bit bunk. The reason I'm even here is because I'm getting the package via EPEL, and it conflicts with the DAG/rpmforge packaging, which does use three separate packages (quite successfully - I've been living with DAG/rpmforge for years happily, and only recently got into the EPEL business). So the question is: is there a 'yummy' way to make a package which bundles all three perl CPAN tarballs 'Obsolete' one which is packaged as three separate ones... and vice-versa I suppose. I'm trying to find a way to make DAG/rpmforge and EPEL play nice (for perl-DateTime). Any ideas? Thanks, David From opensource at till.name Wed May 28 16:44:26 2008 From: opensource at till.name (Till Maas) Date: Wed, 28 May 2008 18:44:26 +0200 Subject: perl DateTime packaging question In-Reply-To: <1211990989.16076.44.camel@gandalf.cobite.com> References: <1211921102.16076.39.camel@gandalf.cobite.com> <20080527214957.GC2663@free.fr> <1211990989.16076.44.camel@gandalf.cobite.com> Message-ID: <200805281844.27496.opensource@till.name> On Wed May 28 2008, David Mansfield wrote: > So the question is: is there a 'yummy' way to make a package which > bundles all three perl CPAN tarballs 'Obsolete' one which is packaged as > three separate ones... and vice-versa I suppose. You can add this to your epel repository config file to exclude the perl-DateTime package: exclude=perl-DateTime Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From ianweller at gmail.com Wed May 28 16:42:28 2008 From: ianweller at gmail.com (Ian Weller) Date: Wed, 28 May 2008 11:42:28 -0500 (CDT) Subject: Wiki Migration Complete! In-Reply-To: <483D5C2D.6070901@ioa.s.u-tokyo.ac.jp> References: <483D5C2D.6070901@ioa.s.u-tokyo.ac.jp> Message-ID: On Wed, 28 May 2008, Mamoru Tasaka wrote: > Before this migration > https://fedoraproject.org/wiki/Packaging > showed all wiki pages which were marked as in "Packaging" category > and from the page I usually searched the needed wiki page related to > packaging issue. > > Now the URL above shows almost nothing. Are there similar page now > which shows all wiki pages related to packaging issue? > Going to [[Special:Allpages]] and asking it to start at Packaging can also give you the same thing, if I recall correctly. -- ian From jwboyer at gmail.com Wed May 28 17:32:15 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 28 May 2008 12:32:15 -0500 Subject: Plan for tomorrows (20080529) FESCO meeting In-Reply-To: <1211984880.27774.3.camel@truman> References: <1211984880.27774.3.camel@truman> Message-ID: <20080528123215.29648f3c@vader.jdub.homelinux.org> On Wed, 28 May 2008 10:28:00 -0400 Brian Pepple wrote: > Hi all, > > Please find below the list of topics that are likely to come up in the > next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC > in #fedora-meeting on irc.freenode.org: > > /topic FESCo meeting -- > https://fedoraproject.org/wiki/Extras/Schedule/SponsorResponsibilityPolicy -- bpepple > > topic FESCO-Meeting -- FESCo Responsibilities/Role -- all Do we really want to go over that now, with the election so close? I would think this would be a good topic for the newly elected FESCo to tackle as their first item. josh From gbillios at gmail.com Wed May 28 17:46:14 2008 From: gbillios at gmail.com (George Billios) Date: Wed, 28 May 2008 20:46:14 +0300 Subject: NVidia drivers for Xorg 1.5 prerelease Message-ID: <483D9A66.7010403@gmail.com> For anyone interested. http://www.nvnews.net/vbulletin/showthread.php?t=113919 From dr.diesel at gmail.com Wed May 28 17:50:39 2008 From: dr.diesel at gmail.com (Dr. Diesel) Date: Wed, 28 May 2008 12:50:39 -0500 Subject: NVidia drivers for Xorg 1.5 prerelease In-Reply-To: <483D9A66.7010403@gmail.com> References: <483D9A66.7010403@gmail.com> Message-ID: <2a28d2ab0805281050w67b1029as3d31acfc0a8b919@mail.gmail.com> YES! Thanks for the info! Wonder how long till Livna gets them posted? 2008/5/28 George Billios : > For anyone interested. > > http://www.nvnews.net/vbulletin/showthread.php?t=113919 > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org From katzj at redhat.com Wed May 28 18:02:00 2008 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 28 May 2008 14:02:00 -0400 Subject: Plan for tomorrows (20080529) FESCO meeting In-Reply-To: <20080528123215.29648f3c@vader.jdub.homelinux.org> References: <1211984880.27774.3.camel@truman> <20080528123215.29648f3c@vader.jdub.homelinux.org> Message-ID: <483D9E18.20604@redhat.com> Josh Boyer wrote: > On Wed, 28 May 2008 10:28:00 -0400 Brian Pepple wrote: >> Please find below the list of topics that are likely to come up in the >> next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC >> in #fedora-meeting on irc.freenode.org: >> >> /topic FESCo meeting -- >> https://fedoraproject.org/wiki/Extras/Schedule/SponsorResponsibilityPolicy -- bpepple >> >> topic FESCO-Meeting -- FESCo Responsibilities/Role -- all > > Do we really want to go over that now, with the election so close? I > would think this would be a good topic for the newly elected FESCo to > tackle as their first item. I think that we *have* to tackle it now. How can we expect people to vote in an educated fashion if we don't know what we're voting for the people to do? Jeremy From jwboyer at gmail.com Wed May 28 18:04:57 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 28 May 2008 13:04:57 -0500 Subject: Plan for tomorrows (20080529) FESCO meeting In-Reply-To: <483D9E18.20604@redhat.com> References: <1211984880.27774.3.camel@truman> <20080528123215.29648f3c@vader.jdub.homelinux.org> <483D9E18.20604@redhat.com> Message-ID: <20080528130457.7e3e12ed@vader.jdub.homelinux.org> On Wed, 28 May 2008 14:02:00 -0400 Jeremy Katz wrote: > Josh Boyer wrote: > > On Wed, 28 May 2008 10:28:00 -0400 Brian Pepple wrote: > >> Please find below the list of topics that are likely to come up in the > >> next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC > >> in #fedora-meeting on irc.freenode.org: > >> > >> /topic FESCo meeting -- > >> https://fedoraproject.org/wiki/Extras/Schedule/SponsorResponsibilityPolicy -- bpepple > >> > >> topic FESCO-Meeting -- FESCo Responsibilities/Role -- all > > > > Do we really want to go over that now, with the election so close? I > > would think this would be a good topic for the newly elected FESCo to > > tackle as their first item. > > I think that we *have* to tackle it now. How can we expect people to > vote in an educated fashion if we don't know what we're voting for the > people to do? That's fine. Just as long as everyone keeps in mind that what we decide today can change immediately with the new FESCo. josh From chasd at silveroaks.com Wed May 28 18:21:45 2008 From: chasd at silveroaks.com (chasd) Date: Wed, 28 May 2008 13:21:45 -0500 Subject: Sudoku PDF Printer Showdown In-Reply-To: <20080528103932.76136619AF1@hormel.redhat.com> References: <20080528103932.76136619AF1@hormel.redhat.com> Message-ID: <5E0CEFD4-2BBC-41A5-9C5F-0218F694268C@silveroaks.com> From someone that has used Acrobat ( no, I don't mean Reader ) since version 2.1 - > *The Mission*: > > ? Print Multiple Sudoku puzzles as PDF files > ? 10 puzzles with 2 per page > ? View them anywhere > ? Edit them > *Tools used*: > > ? gnome-games.i386 1:2.22.1.1-5.fc9 > ? cups-pdf.i386 2.4.7-1.fc9 > ? cairo.i386 1.6.4-1.fc9 > ? evince.i386 2.22.1.1-1.fc9 > ? AdobeReader_enu.i486 8.1.2-1 > ? inkscape.i386 0.46-2.fc9 > ? selinux-policy.noarch 3.3.1-55.fc9 (this will make sense later) From your tools list, it would be better to create them with InkScape to begin with, and bypass PDF. A PDF is not considered an editable format, even though there are tools that allow it. Editing PDFs gets messy quickly. > *Results*: > > Printing with Cups ("Cups-PDF"): > ? Prints successfully > ? good print format options > ? just dumps it on the desktop with some default name > ? cups-pdf setroubleshooter unhappiness This is configurable in /etc/cups/cups-pdf.conf There are several options there which could solve the issues of where the file is written, the user that writes it ( not sure about context ), and the filename. > ? Imports incorrectly in Inkscape InkScape just got PDF editing support, it isn't going to be as good as Adobe Acrobat. > ? multiple of binary streams when viewed in text editor A valid PDF can be binary encoded. You may not want that, but it is valid to the specs. Also note that a valid PDF can have edits appended to the end of the file that over-ride something in the body, and there is a checksum involved so a parser knows it got all the data, you can't just "cat foo >> bar.pdf" and have it work. A PDF may look like a simple ASCII- based format ( sometimes anyway ), but it much more complicated than that. > Printing with Ideal Fictional Dream PDF Printer: Print to SVG or the PDF-Mars format instead. Mars uses XML as the file format for PDF instead of the traditional PDF gorp. The Mars file format uses the "zip-it-up" ODT format, and has everything described as XML referencing each page as an SVG. Although there are few Mars tools available right now ;) Charles Dostale System Admin - Silver Oaks Communications http://www.silveroaks.com/ 824 17th Street, Moline IL 61265 From johnp at redhat.com Wed May 28 18:53:51 2008 From: johnp at redhat.com (John (J5) Palmieri) Date: Wed, 28 May 2008 14:53:51 -0400 Subject: Questions about packagedb search Message-ID: <1212000831.16679.15.camel@localhost.localdomain> Hi Ionu?, I was looking at your packagedb branch. On of the things I am doing in MyFedora is a unified search frontend which would use various search backends such as packagedb for packages and fas for people. Right now I use koji for querying which is fast but lacks the extra info that packagedb give us. A couple of questions about the code. First is more of a request. Can you add allow_json=True to the @expose method of the package method? I'm reading this line: # return only the packages in known collections or all of them if release in range(1,16): Is that range arbitrary? What does it mean? What are valid release values? What if I want all available releases? My last question is what does this method return in terms of data structure? Having all this info will make my development smoother. Python docs strings listing the parameters and the return value would be even more helpful. Thanks for the work you have done. Hopefully we can get it live fairly soon. -- John (J5) Palmieri From sundaram at fedoraproject.org Wed May 28 19:01:03 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 29 May 2008 00:31:03 +0530 Subject: How act when bug should be documented in release notes or known bugs In-Reply-To: <20080528102159.GA10196@evileye.atkac.englab.brq.redhat.com> References: <20080528102159.GA10196@evileye.atkac.englab.brq.redhat.com> Message-ID: <483DABEF.2030303@fedoraproject.org> Adam Tkac wrote: > Hi all, > > is somewhere procedure how act when some bug should be documented in > release notes or on known-bugs page? > > I'm talking about problem in F9 final - when you install bind-chroot > package (you selected "Install DNS server") bind installation fails > due no dependency on bind and after installation bind and bind-chroot > have to be removed and installed again. > (https://bugzilla.redhat.com/show_bug.cgi?id=446477#c6) > > Update is released but it would be nice to inform users that this > problem exists and they should not install bind-chroot directly from > ISO. How should I do it? The release note process is detailed at http://fedoraproject.org/wiki/DocsProject/ReleaseNotes/Process A couple of post release updates have already been pushed out. I am not sure we are doing anymore at this point. Rahul From Matt_Domsch at dell.com Wed May 28 20:51:38 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 28 May 2008 15:51:38 -0500 Subject: Plan for tomorrows (20080529) FESCO meeting: FTBFS bugs In-Reply-To: <1211984880.27774.3.camel@truman> References: <1211984880.27774.3.camel@truman> Message-ID: <20080528205138.GC18364@auslistsprd01.us.dell.com> On Wed, May 28, 2008 at 10:28:00AM -0400, Brian Pepple wrote: > Hi all, > > Please find below the list of topics that are likely to come up in the > next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC > in #fedora-meeting on irc.freenode.org: > > /topic FESCo meeting -- > https://fedoraproject.org/wiki/Extras/Schedule/SponsorResponsibilityPolicy -- bpepple > > topic FESCO-Meeting -- FESCo Responsibilities/Role -- all > > /topic FESCo meeting -- Free discussion around Fedora > > You want something to be discussed? Send a note to the list in reply to > this mail and I'll add it to the schedule. You can also propose topics > in the meeting while it is in the "Free discussion around Fedora" phase. One thing that came up in today's QA meeting was a desire to remove packages from the repository that "Fail To Build From Source" [1] for several months leading up to a Beta release when there is no resolution in sight. I'm currently doing a rawhide rebuild, and expect on the order of 350 packages currently in rawhide to fail to rebuild. There are at least 144 which are known to not rebuild, which have bugs filed blocking the FTBFS bug [2] (or one of its decendants). I'll file additional bugs later this week based on my rawhide run. There are at least these many in rawhide today with "old" dist tags which have failed for me in the past week: .fc6: 12 gdmap-0.7.5-6.fc6.src.rpm aiksaurus-1.2.1-15.fc6.src.rpm ht2html-2.0-5.fc6.src.rpm lineak-defaultplugin-0.9-2.fc6.src.rpm lineak-xosdplugin-0.9-2.fc6.src.rpm lineakd-0.9-5.fc6.src.rpm oooqs2-1.0-3.fc6.src.rpm orpie-1.4.3-5.fc6.src.rpm qa-assistant-0.4.90.5-2.fc6.src.rpm scim-skk-0.5.2-8.fc6.src.rpm soundtracker-0.6.8-2.fc6.src.rpm .fc7: 27 svnmailer-1.0.8-3.fc7.src.rpm conexusmm-0.5.0-3.fc7.src.rpm moto4lin-0.3-6.fc7.src.rpm SOAPpy-0.11.6-6.fc7.src.rpm fluxstyle-1.0.1-2.fc7.src.rpm fonttools-2.0-0.11.20060223cvs.fc7.src.rpm fontypython-0.2.0-6.fc7.src.rpm gl-117-1.3.2-4.fc7.src.rpm gstm-1.2-6.fc7.src.rpm gtk-sharp-1.0.10-12.fc7.src.rpm gtksourceview-sharp-2.0-25.fc7.src.rpm junitperf-1.9.1-2jpp.1.fc7.src.rpm kphotobymail-0.4.1-1.fc7.src.rpm mbuffer-20070502-1.fc7.src.rpm pcmanx-gtk2-0.3.5-9.336svn.fc7.src.rpm pekwm-0.1.5-5.fc7.src.rpm plague-0.4.4.1-4.fc7.src.rpm python-durus-3.5-3.fc7.src.rpm python-pydns-2.3.0-5.fc7.src.rpm python-simpletal-4.1-5.fc7.src.rpm python-tpg-3.1.0-4.fc7.src.rpm python-urljr-1.0.1-1.fc7.src.rpm pyzor-0.4.0-11.fc7.src.rpm qps-1.9.19-0.2.b.fc7.src.rpm ruby-bdb-0.6.0-1.fc7.src.rpm rudeconfig-5.0.5-1.fc7.src.rpm sblim-wbemcli-1.5.1-5.fc7.src.rpm (and of course there are packages with no dist tag which fail too) so the number of packages we'd consider here isn't huge, but is nonzero. Please consider adopting a policy regarding packages which continue to fail to build from source for a given distribution. These packages need attention, if only because we have disabled F6 buildroots which would be necessary to build and fix a bug in such a package package in the F9 release. I agree with Will Woods' suggestion (pardon if I mis-attribute) that such cutoff point should be the Beta cut of the next version of the release. [1] http://fedoraproject.org/wiki/FTBFS [2] FTBFS bug: https://bugzilla.redhat.com/show_bug.cgi?id=440169 -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From maillist at diffingo.com Wed May 28 21:23:46 2008 From: maillist at diffingo.com (Stewart Adam) Date: Wed, 28 May 2008 17:23:46 -0400 Subject: NVidia drivers for Xorg 1.5 prerelease In-Reply-To: <2a28d2ab0805281050w67b1029as3d31acfc0a8b919@mail.gmail.com> References: <483D9A66.7010403@gmail.com> <2a28d2ab0805281050w67b1029as3d31acfc0a8b919@mail.gmail.com> Message-ID: <1212009826.14031.0.camel@Diffingo.localdomain> They're being pushed tomorrow, grab them here: http://build64.livna.org:8880/plague-results/fedora-9-livna/ Stewart On Wed, 2008-05-28 at 12:50 -0500, Dr. Diesel wrote: > YES! Thanks for the info! Wonder how long till Livna gets them posted? > > > 2008/5/28 George Billios : > > For anyone interested. > > > > http://www.nvnews.net/vbulletin/showthread.php?t=113919 > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > > -- > projecthuh.com > All of my bits are free, are yours? Fedoraproject.org > From michael.wiktowy at gmail.com Wed May 28 21:33:58 2008 From: michael.wiktowy at gmail.com (Michael Wiktowy) Date: Wed, 28 May 2008 17:33:58 -0400 Subject: Sudoku PDF Printer Showdown In-Reply-To: <5E0CEFD4-2BBC-41A5-9C5F-0218F694268C@silveroaks.com> References: <20080528103932.76136619AF1@hormel.redhat.com> <5E0CEFD4-2BBC-41A5-9C5F-0218F694268C@silveroaks.com> Message-ID: <3e4ec4600805281433s3da70c6eu43231c2dc70cc4a8@mail.gmail.com> On Wed, May 28, 2008 at 2:21 PM, chasd wrote: >> *Tools used*: >> >> ? gnome-games.i386 1:2.22.1.1-5.fc9 >> ? cups-pdf.i386 2.4.7-1.fc9 >> ? cairo.i386 1.6.4-1.fc9 >> ? evince.i386 2.22.1.1-1.fc9 >> ? AdobeReader_enu.i486 8.1.2-1 >> ? inkscape.i386 0.46-2.fc9 >> ? selinux-policy.noarch 3.3.1-55.fc9 (this will make sense later) > > From your tools list, it would be better to create them with InkScape to > begin with, and bypass PDF. > A PDF is not considered an editable format, even though there are tools that > allow it. > Editing PDFs gets messy quickly. Thanks for the feedback. Well ... there are times when all you have is a PDF as the source material to work from. So it is certainly nice to have the refined tools to dig into the contents and modify things. But as I am trying to illustrate with this simple example, the PDF generation that is available to all apps that can print has some issues also. There is also a bit of a correction. I mistakenly thought that gnome-print uses cairo as a backend to generate PDFs. From what I understand now, it does it all itself internally so blame or praise in my test was falsely placed on cairo and should be on gnome-print. I guess I have to read more about how all the pieces fit together ... > This is configurable in /etc/cups/cups-pdf.conf > There are several options there which could solve the issues of where the > file is written, the user that writes it ( not sure about context ), and the > filename. Thanks ... I'll take a look. >> ? Imports incorrectly in Inkscape > > InkScape just got PDF editing support, it isn't going to be as good as Adobe > Acrobat. No doubt. I found that Inkscape does an excellent job as a first iteration though and was hoping to point out some places it doesn't. I have a personal project underway that is taking PDFs and adding editable PDF form fields on top. I have found that using Inkscape to convert the PDF pages to SVGs and import those into Scribus where I can add the form fields and some simple javascript gives OK results. The SVG font translation into Scribus 1.3.4 is not so stellar though. I am hoping that 1.3.5 is better. >> ? multiple of binary streams when viewed in text editor > > A valid PDF can be binary encoded. You may not want that, but it is valid to > the specs. > Also note that a valid PDF can have edits appended to the end of the file > that over-ride something in the body, and there is a checksum involved so a > parser knows it got all the data, you can't just "cat foo >> bar.pdf" and > have it work. A PDF may look like a simple ASCII-based format ( sometimes > anyway ), but it much more complicated than that. Doing the overlay/substitution thing is more appropriate in many situations but not all. Xournal does this quite nicely with its PDF Annotation functionality. I wish I could do this also with Scribus in my project described above as I am simply adding new content but the importing of PDFs in Scribus is .... marginal. However, you are always increasing the file size this way and increasing the rendering time. >> Printing with Ideal Fictional Dream PDF Printer: > > Print to SVG or the PDF-Mars format instead. > > Mars uses XML as the file format for PDF instead of the traditional PDF > gorp. The Mars file format uses the "zip-it-up" ODT format, and has > everything described as XML referencing each page as an SVG. Although there > are few Mars tools available right now ;) That would be the problem. Is there a package in the Fedora distro that will enable a "Print to SVG" option? /Mike From bpepple at fedoraproject.org Wed May 28 23:13:18 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 28 May 2008 19:13:18 -0400 Subject: Plan for tomorrows (20080529) FESCO meeting: FTBFS bugs In-Reply-To: <20080528205138.GC18364@auslistsprd01.us.dell.com> References: <1211984880.27774.3.camel@truman> <20080528205138.GC18364@auslistsprd01.us.dell.com> Message-ID: <1212016398.15248.2.camel@kennedy> On Wed, 2008-05-28 at 15:51 -0500, Matt Domsch wrote: > One thing that came up in today's QA meeting was a desire to remove > packages from the repository that "Fail To Build From Source" [1] for > several months leading up to a Beta release when there is no > resolution in sight. I'm currently doing a rawhide rebuild, and > expect on the order of 350 packages currently in rawhide to fail to > rebuild. There are at least 144 which are known to not rebuild, which > have bugs filed blocking the FTBFS bug [2] (or one of its decendants). > I'll file additional bugs later this week based on my rawhide run. > Please consider adopting a policy regarding packages which continue to > fail to build from source for a given distribution. These packages > need attention, if only because we have disabled F6 buildroots which > would be necessary to build and fix a bug in such a package package in > the F9 release. I agree with Will Woods' suggestion (pardon if I > mis-attribute) that such cutoff point should be the Beta cut of the > next version of the release. Seem reasonable to me. I'll add it to the schedule for tomorrow. Thanks, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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: 197 bytes Desc: This is a digitally signed message part URL: From axel.lin at gmail.com Thu May 29 04:32:12 2008 From: axel.lin at gmail.com (axel lin) Date: Thu, 29 May 2008 12:32:12 +0800 Subject: which package contains xf86_ansic.h in Fedora 9? Message-ID: <427d64720805282132m587f8c33y4818653be4e1137d@mail.gmail.com> hi list, I got "error: xf86_ansic.h: No such file or directory" when compile evtourch driver in Fedora 9. Anyone knows which package contains the missing header file? Thanks, Axel -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivazqueznet at gmail.com Thu May 29 04:46:30 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Thu, 29 May 2008 00:46:30 -0400 Subject: which package contains xf86_ansic.h in Fedora 9? In-Reply-To: <427d64720805282132m587f8c33y4818653be4e1137d@mail.gmail.com> References: <427d64720805282132m587f8c33y4818653be4e1137d@mail.gmail.com> Message-ID: <1212036390.4081.85.camel@ignacio.lan> On Thu, 2008-05-29 at 12:32 +0800, axel lin wrote: > I got "error: xf86_ansic.h: No such file or directory" when > compile > evtourch driver in Fedora 9. > Anyone knows which package contains the missing header file? yum whatprovides /\*/xf86_ansic.h -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tmz at pobox.com Thu May 29 05:10:41 2008 From: tmz at pobox.com (Todd Zullinger) Date: Thu, 29 May 2008 01:10:41 -0400 Subject: which package contains xf86_ansic.h in Fedora 9? In-Reply-To: <1212036390.4081.85.camel@ignacio.lan> References: <427d64720805282132m587f8c33y4818653be4e1137d@mail.gmail.com> <1212036390.4081.85.camel@ignacio.lan> Message-ID: <20080529051041.GU2769@inocybe.teonanacatl.org> Ignacio Vazquez-Abrams wrote: > On Thu, 2008-05-29 at 12:32 +0800, axel lin wrote: >> I got "error: xf86_ansic.h: No such file or directory" when >> compile >> evtourch driver in Fedora 9. >> Anyone knows which package contains the missing header file? > > yum whatprovides /\*/xf86_ansic.h The answer though is that nothing provides it AFAICT. The driver probably needs updated to work with the new xorg in F9. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Truth is like a well-known whore. Everybody knows her but it's embarrassing to meet her in the street. -- Wolfgang Borchert -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From airlied at redhat.com Thu May 29 06:15:42 2008 From: airlied at redhat.com (Dave Airlie) Date: Thu, 29 May 2008 16:15:42 +1000 Subject: which package contains xf86_ansic.h in Fedora 9? In-Reply-To: <427d64720805282132m587f8c33y4818653be4e1137d@mail.gmail.com> References: <427d64720805282132m587f8c33y4818653be4e1137d@mail.gmail.com> Message-ID: <1212041743.3627.11.camel@clockmaker.usersys.redhat.com> On Thu, 2008-05-29 at 12:32 +0800, axel lin wrote: > hi list, > I got "error: xf86_ansic.h: No such file or directory" when > compile > evtourch driver in Fedora 9. > Anyone knows which package contains the missing header file? > Its not longer used. the driver you are compiling needs de-ansification. Dave. > Thanks, > Axel > > -- > 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 Thu May 29 07:38:34 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 29 May 2008 09:38:34 +0200 Subject: Plan for tomorrows (20080529) FESCO meeting: FTBFS bugs In-Reply-To: <20080528205138.GC18364@auslistsprd01.us.dell.com> References: <1211984880.27774.3.camel@truman> <20080528205138.GC18364@auslistsprd01.us.dell.com> Message-ID: <20080529073834.GA2595@free.fr> On Wed, May 28, 2008 at 03:51:38PM -0500, Matt Domsch wrote: > > Please consider adopting a policy regarding packages which continue to > fail to build from source for a given distribution. These packages > need attention, if only because we have disabled F6 buildroots which > would be necessary to build and fix a bug in such a package package in > the F9 release. I agree with Will Woods' suggestion (pardon if I > mis-attribute) that such cutoff point should be the Beta cut of the > next version of the release. I own some packages that don't rebuild (in F-9), I was waiting for an upstream release that didn't came (for libnc-dap, though there was a release of libdap). I'd prefer if they were kept. I'll take the time to patch them to rebuild, but I'd prefer doing it only if needed. -- Pat From dev at nigelj.com Thu May 29 08:07:51 2008 From: dev at nigelj.com (Nigel Jones) Date: Thu, 29 May 2008 20:07:51 +1200 Subject: Call For Testers - Elections Application Message-ID: <483E6457.7010505@nigelj.com> Hi everyone, With Fedora 9 out the door we hit a very busy time for elections, the previous system was, well lets just say, not optimal. So I accepted the goal of creating an application by our post-release election season that would integrate well with FAS and would allow a different method of voting, Range Voting. If your not familiar with Range Voting check out http://en.wikipedia.org/wiki/Range_voting the essentials however is that you rank candidates from 0<-># of candidates, if you don't like them, just rank them 0. In the future, the application will not only allow the Board and Steering Committees to hold elections, it will (hopefully) become available to SIGs and Steering Committees for any time of poll/call to vote. This is where you all come in, it's impossible for a small group of people to find every possible mistake or bug in ANY item of software, so the more people we can get in to test it and report bugs/issues/thoughts the better! All I ask is 10-20 minutes of your time, whenever your free over the couple of days to test and provide feedback. Instructions: 1) You'll need an account on the test instance of FAS at http://publictest10.fedoraproject.org/accounts/ (PLEASE) do not use your normal password and you don't need to do CLA etc (I've removed that requirement in the elections app for now). 2) Please direct your browser to https://publictest10.fedoraproject.org/elections/ and test away! 3) Try voting etc, make sure that you *can* view the results at https://publictest10.fedoraproject.org/elections/results/fedora but can't view the results at https://publictest10.fedoraproject.org/elections/results/president Notes: * I'm aware the UI is absolutely awful, there is already a ticket open for this (https://fedorahosted.org/elections/ticket/4) please feel free to add items there. * Any errors you encounter that are 'unexpected' to you, please file a ticket at https://fedorahosted.org/elections/newticket setting Milestone to 'Release 0.1.0' with full reproduction steps, and the time it occurred (TZ=UTC date) * Any other feedback can be directed to the elections-devel list (elections-devel at lists.fedorahosted.org) After 5am UTC on the 1st June both elections will end and the 'results' should be public and hopefully we'll have a decent election app! Thanks a lot & Happy Testing, Nigel Jones p.s. Sorry to those that fall asleep during my e-mail - I nearly did too! p.s.s. Thanks must be given to Toshio, Ricky, Luca and Mike who have all assisted in this release From balajig81 at gmail.com Thu May 29 08:33:08 2008 From: balajig81 at gmail.com (G) Date: Thu, 29 May 2008 14:03:08 +0530 Subject: Suggestion with respect to the Fedora Update System Message-ID: <6dd1343e0805290133q4149cfb1vecc48ca3d8d82b35@mail.gmail.com> Hi I got the following mail from Fedora updates. It says "The following package has been moved to stable from testing". The Karma value corresponding to this package is still zero (mentioned in the below thread). Correct me if i am wrong, if the value reaches 3 its moved to stable, thats how i understood it. I gave a comment for that package that i am not able to test it because i was not aware what needs to be tested for that enhancement. Apart from this i ve an other problem. Suggestions and Comments Welcome for this problem :) . I browse through the Fedora Updates repository to start testing packages which are under the fedora testing branch, but for some of the packages, i see that its given as an enhancement (like the below one) but i am not able to go ahead testing it because it does not specifiy whats the enhnacement is about. I did notice that there are some bug fixes too made which has got the word "bugfix" but does not map to a Bug ID i.e, the Bug ID is not mentioned in the updates. It becomes diffficult to test those packages and give appropriate and correct feedback.I shouldnt give back a report saying that it works or it does not work which might be a wrong test result because i might be testing something but the fix would be for something else. I would really appreciate if you all could help me with a suggestion on this. I went a step ahead by raising a ticket in the bodhi system so that we could have a field in the updates system where in when a packager uploads the packages, a mandatory field on whats fixed if its a bug fix could be stated and if its an enhanement , a small note on what the enhancement is. Will this suggestion work ? This would really help people testing packages from the bodhi repository and thereby make Fedora a real rock solid distro. Thanks for reading this . Hope people don't mistake me for this :) Cheers, Balaji On 5/29/08, updates at fedoraproject.org wrote: > The following comment has been added to the gedit-2.22.1-1.fc9 update: > > balajig8 - 2008-05-25 14:44:49 (karma: 0) > Hi > It would be really helpful if you could let me know what the enhancement is so that i could test it and let you know the result. I would also really appreciate if the bugID( in this case the enhancement ID) could also be given so that i could test it specifically > > Cheers > Balaji > > To reply to this comment, please visit the URL at the bottom of this mail > > ================================================================================ > gedit-2.22.1-1.fc9 > ================================================================================ > Update ID: FEDORA-2008-3797 > Release: Fedora 9 > Status: stable > Type: enhancement > Karma: 0 > Submitter: hadess > Submitted: 2008-04-30 10:57:01 > Comments: bodhi - 2008-05-29 02:43:33 (karma 0) > This update has been pushed to stable > bodhi - 2008-05-13 15:29:10 (karma 0) > This update has been pushed to testing > balajig8 - 2008-05-25 14:44:49 (karma 0) > Hi It would be really helpful if you could let me > know what the enhancement is so that i could test it > and let you know the result. I would also really > appreciate if the bugID( in this case the enhancement > ID) could also be given so that i could test it > specifically Cheers Balaji > > http://admin.fedoraproject.org/updates/F9/FEDORA-2008-3797 > > From vikigoyal at gmail.com Thu May 29 08:33:30 2008 From: vikigoyal at gmail.com (Vikram Goyal) Date: Thu, 29 May 2008 14:03:30 +0530 Subject: F9 installation screenshot In-Reply-To: <4818DD86.5020805@ncsu.edu> References: <4818DD86.5020805@ncsu.edu> Message-ID: <20080529083330.GA4000@f9host.f9domain> On Wed, Apr 30, 2008 at 04:58:46PM -0400, Casey Dahlin wrote: > Sweet horror of horrors! A hotdog with eyes! Imagine how offended people > might be! > Hmm! please, what is a hotdog;? > I can't for the life of me see the problem. Will everyone everywhere get the > joke? Maybe not. But who gets offended by popcorn? > > Insisting on cultural sterility insults everyone equally. Let the American > jokes be, and while we're at it, let's have some European and Japanese humor > in the mix. People make this OS, let's have some fingerprints on it. > > --CJD > > -- vikram... |||||||| |||||||| ^^'''''^^||root||^^^'''''''^^ // \\ )) //(( \\// \\ // /\\ || \\ || / )) (( \\ -- nesting roaches shorted out the ether cable -- . - ~|~ = From roopesh.majeti at gmail.com Thu May 29 09:22:05 2008 From: roopesh.majeti at gmail.com (roopesh majeti) Date: Thu, 29 May 2008 14:52:05 +0530 Subject: Call For Testers - Elections Application In-Reply-To: <483E6457.7010505@nigelj.com> References: <483E6457.7010505@nigelj.com> Message-ID: <599059470805290222g2d0d5d2emdcb07a26e56ceae1@mail.gmail.com> I tried just now and following are my thoughts : 1) The first page is good. But a clear heading like "Vote for President " will be good rather than "Real President Nominee". 2) When the user wants to know the info about a Nominee, once he clicks the link "info", it is better to have a pop-up, rather than redirecting the whole page. 3) A non-uniformity is there in the Nominee's information. It is true that the control directs us to the user homepage. But for this President Nominee stuff, it is good to develope a generic page having information populated regarding that Nominee. 4) Why the site is re-directed to cnn.com/politics when the user request for more information on the President Ranking page ? 5) After confirming the Vote, the user is redirected to the initial home page. But the following appears at the bottom. "Build time: 0.115s, Page size: 2.23KB" It is truely required to display to the end-user ? 6) When tried to view the results, by clicking "Community", iam facing this problem. 500 Internal error Overall, it looks fine. -Roopesh On 5/29/08, Nigel Jones wrote: > Hi everyone, > > With Fedora 9 out the door we hit a very busy time for elections, the > previous system was, well lets just say, not optimal. > > So I accepted the goal of creating an application by our post-release > election season that would integrate well with FAS and would allow a > different method of voting, Range Voting. > > If your not familiar with Range Voting check out > http://en.wikipedia.org/wiki/Range_voting the essentials however is that > you rank candidates from 0<-># of candidates, if you don't like them, just > rank them 0. > > In the future, the application will not only allow the Board and Steering > Committees to hold elections, it will (hopefully) become available to SIGs > and Steering Committees for any time of poll/call to vote. > > This is where you all come in, it's impossible for a small group of people > to find every possible mistake or bug in ANY item of software, so the more > people we can get in to test it and report bugs/issues/thoughts the better! > > All I ask is 10-20 minutes of your time, whenever your free over the couple > of days to test and provide feedback. > > Instructions: > 1) You'll need an account on the test instance of FAS at > http://publictest10.fedoraproject.org/accounts/ (PLEASE) do not use your > normal password and you don't need to do CLA etc (I've removed that > requirement in the elections app for now). > 2) Please direct your browser to > https://publictest10.fedoraproject.org/elections/ and test away! > 3) Try voting etc, make sure that you *can* view the results at > https://publictest10.fedoraproject.org/elections/results/fedora but can't > view the results at > https://publictest10.fedoraproject.org/elections/results/president > > Notes: > * I'm aware the UI is absolutely awful, there is already a ticket open for > this (https://fedorahosted.org/elections/ticket/4) please feel free to add > items there. > * Any errors you encounter that are 'unexpected' to you, please file a > ticket at https://fedorahosted.org/elections/newticket setting Milestone > to 'Release 0.1.0' with full reproduction steps, and the time it occurred > (TZ=UTC date) > * Any other feedback can be directed to the elections-devel list ( > elections-devel at lists.fedorahosted.org) > > After 5am UTC on the 1st June both elections will end and the 'results' > should be public and hopefully we'll have a decent election app! > > Thanks a lot & Happy Testing, > > Nigel Jones > > p.s. Sorry to those that fall asleep during my e-mail - I nearly did too! > p.s.s. Thanks must be given to Toshio, Ricky, Luca and Mike who have all > assisted in this release > > -- > 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 rawhide at fedoraproject.org Thu May 29 09:28:03 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Thu, 29 May 2008 09:28:03 +0000 (UTC) Subject: rawhide report: 20080529 changes Message-ID: <20080529092804.1DFD1209CC7@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080528/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080529/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package perl-PHP-Serialization Converts between PHP's serialize() output and the equivalent Perl structure Updated Packages: R-2.7.0-5.fc10 -------------- * Wed May 28 18:00:00 2008 Tom "spot" Callaway 2.7.0-5 - add cairo-devel to BR/R, so that cairo backend gets built SDL-1.2.13-4.fc10 ----------------- * Wed May 28 18:00:00 2008 Dennis Gilmore 1.2.13-4 - fix sparc multilib handling apcupsd-3.14.4-1.fc10 --------------------- * Wed May 28 18:00:00 2008 Tomas Smetana - 3.14.4-1 - new upstream version cairo-dock-1.5.6-1.date20080528.fc10 ------------------------------------ cobbler-1.0.0-2.fc10 -------------------- * Tue May 27 18:00:00 2008 Michael DeHaan - 1.0.0-2 - Upstream changes (see CHANGELOG) * Fri May 16 18:00:00 2008 Michael DeHaan - 0.9.2-2 - Upstream changes (see CHANGELOG) - moved /var/lib/cobbler/settings to /etc/cobbler/settings * Fri May 9 18:00:00 2008 Michael DeHaan - 0.9.1-1 - Upstream changes (see CHANGELOG) - packaged /etc/cobbler/users.conf - remaining CGI replaced with mod_python * Tue Apr 8 18:00:00 2008 Michael DeHaan - 0.8.3-2 - Upstream changes (see CHANGELOG) cups-1.3.7-3.fc10 ----------------- * Wed May 28 18:00:00 2008 Tim Waugh 1:1.3.7-3 - If cupsdTimeoutJob is called when the originating connection is still known, pass that to the function so that copy_banner can get at it if necessary (bug #447200). dhcpv6-1.0.18-1.fc10 -------------------- * Wed May 28 18:00:00 2008 David Cantrell - 1.0.18-1 - Make dadlist in src/dad_parse.c a global dkms-2.0.19.1-1.fc10 -------------------- * Wed May 28 18:00:00 2008 Matt Domsch 2.0.19.1 - depmod on uninstall before mkinitrd, depmod fix & cleanups - find_module_from_ko() could incorrectly return multiple values gambas2-2.6.0-1.fc10 -------------------- * Wed May 28 18:00:00 2008 Tom "spot" Callaway 2.6.0-1 - update to 2.6.0 gdal-1.5.1-13.fc10 ------------------ git-1.5.5.3-1.fc10 ------------------ * Wed May 28 18:00:00 2008 James Bowes 1.5.5.3-1 - git-1.5.5.3 gnome-libs-1.4.2-9.fc10 ----------------------- * Wed May 28 18:00:00 2008 Paul Howarth 1:1.4.2-9 - Break recursive gnome-config <-> pkg-config loop if 64-bit glib-devel package is not installed on a 64-bit system (#445981) - Add file dependency on glib.pc to enforce installation of 64-bit glib-devel with 64-bit gnome-libs-devel (#445981) gtk-recordmydesktop-0.3.7.2-1.fc10 ---------------------------------- * Wed May 28 18:00:00 2008 Sindre Pedersen Bj?rdal - 0.3.7.2-1 - New upstream release guitone-0.8-2.fc10 ------------------ * Wed May 28 18:00:00 2008 Thomas Moschny - 0.8-2 - Fix order of commands in the build section. hunspell-sv-1.27-1.fc10 ----------------------- * Wed May 28 18:00:00 2008 Caolan McNamara - 1.27-1 - latest version ipe-6.0-0.27.pre30.fc10 ----------------------- * Wed May 28 18:00:00 2008 Laurent Rineau - 6.0-0.27.pre30.fc10 - Add an upstream patch (Patch2), that should fix the incompatibility with pdfTeX-1.40 (TeXLive 2007), which is in Fedora?9. * Tue Mar 4 17:00:00 2008 Laurent Rineau - 6.0-0.25.pre30.fc10 - Fix the URL: tag. (rebuild needed) kdegames-4.0.80-3.fc10 ---------------------- * Wed May 28 18:00:00 2008 Kevin Kofler 4.0.80-3 - add kbreakout and ksirk to description kdepim-4.0.80-2.fc10 -------------------- * Wed May 28 18:00:00 2008 Kevin Kofler 4.0.80-2 - put unversioned libkpilot_conduit_base.so in -libs instead of -devel (#448395) kernel-2.6.26-0.43.rc4.git2.fc10 -------------------------------- * Wed May 28 18:00:00 2008 Dave Jones - PPC gets sad with debug alloc (bz 448598) * Wed May 28 18:00:00 2008 Dave Jones - Make the OQO2 use polled IO for its ethernet. * Wed May 28 18:00:00 2008 Dave Jones - Make 8139too PIO/MMIO a module parameter * Wed May 28 18:00:00 2008 Dave Jones - 2.6.26-rc4-git2 * Wed May 28 18:00:00 2008 Dave Jones - 2.6.26-rc4-git1 * Wed May 28 18:00:00 2008 Chuck Ebbert - Remove eeepc driver, now upstream as eeepc-laptop. koan-1.0.0-1.fc10 ----------------- * Fri May 16 18:00:00 2008 Michael DeHaan - 0.9.2-2 - Upstream changes (see CHANGELOG) * Fri May 9 18:00:00 2008 Michael DeHaan - 0.9.0-1 - Upstream changes (see CHANGELOG) - truncate changelog (see git for history) libsepol-2.0.29-1.fc10 ---------------------- * Wed May 28 18:00:00 2008 Dan Walsh 2.0.29-1 - Upgrade to latest from NSA * Merge user and role mapping support from Joshua Brindle. mew-6.1-0.1.rc1.fc10 -------------------- * Wed May 28 18:00:00 2008 Akira TAGOH - 6.1-0.1.rc1 - New upstream release. mkinitrd-6.0.51-3.fc10 ---------------------- * Wed May 28 18:00:00 2008 Jeremy Katz - 6.0.51-2 - rebuild for libdhcp6client mono-addins-0.3.1-2.fc10 ------------------------ * Wed May 28 18:00:00 2008 Tom "spot" Callaway - 0.3.1-2 - rebuild for new gtk-sharp2 oddjob-0.29.1-1.fc10 -------------------- * Wed May 28 18:00:00 2008 Nalin Dahyabhai 0.29.1-1 - when we install the mkhomedir subpackage, if there's a running oddjobd, ask it to reload its configuration - fix missing bits from the namespace changes in configuration files - restart the service in %postun ogdi-3.2.0-0.11.beta2.fc10 -------------------------- * Wed May 28 18:00:00 2008 Balint Cristian - 3.2.0-0.11.beta2 - fix a spourios permission * Wed May 28 18:00:00 2008 Balint Cristian - 3.2.0-0.10.beta2 - new bugfix upstream - drop all patches, upstream now openldap-2.4.9-5.fc10 --------------------- * Wed May 28 18:00:00 2008 Jan Safranek 2.4.9-5 - use /sbin/nologin as shell of ldap user (#447919) openssl-0.9.8g-9.fc10 --------------------- * Wed May 28 18:00:00 2008 Tomas Mraz 0.9.8g-9 - fix CVE-2008-0891 - server name extension crash (#448492) - fix CVE-2008-1672 - server key exchange message omit crash (#448495) orca-2.23.2-3.fc10 ------------------ * Wed May 28 18:00:00 2008 Jon McCann - 2.23.2-3 - Add BuildRequires gnome-python2-bonobo back * Wed May 28 18:00:00 2008 Jon McCann - 2.23.2-2 - Require gnome-python2-bonobo and gnome-python2-libwnck perl-Geo-METAR-1.15-2.fc10 -------------------------- * Wed May 28 18:00:00 2008 kwizart < kwizart at gmail.com > - 1.15-2 - Fix %doc * Wed May 28 18:00:00 2008 kwizart < kwizart at gmail.com > - 1.15-1 - Update to 1.15 perl-Image-ExifTool-7.25-2.fc10 ------------------------------- * Wed May 28 18:00:00 2008 Tom "spot" Callaway 7.25-2 - get rid of empty arch-specific directories (bz 448744) perl-Moose-0.44-2.fc10 ---------------------- * Wed May 28 18:00:00 2008 Chris Weyl 0.44-2 - bump * Wed May 21 18:00:00 2008 Chris Weyl 0.44-1 - update to 0.44 perl-Sub-Identify-0.03-1.fc10 ----------------------------- * Wed May 28 18:00:00 2008 Chris Weyl 0.03-1 - update to 0.03 pm-utils-1.1.2.1-2.fc10 ----------------------- * Wed May 28 18:00:00 2008 Richard Hughes - 1.1.2.1-2 - Change BR from docbook-utils to xmlto * Wed May 28 18:00:00 2008 Richard Hughes - 1.1.2.1-1 - Update to 1.1.2.1 qt-recordmydesktop-0.3.7.2-1.fc10 --------------------------------- * Wed May 28 18:00:00 2008 Sindre Pedersen Bj?rdal - 0.3.7.2-1 - New upstream release recordmydesktop-0.3.7.3-1.fc10 ------------------------------ * Wed May 28 18:00:00 2008 Sindre Pedersen Bj?rdal - 0.3.7.3-1 - New upstream release rhm-0.2.2060-3.fc10 ------------------- rpmlint-0.83-1.fc10 ------------------- * Tue May 27 18:00:00 2008 Ville Skytt? - 0.83-1 - 0.83, fixes #237204, #428096, #430206, #433783, #434694, #444441. - Fedora licensing patch applied upstream. - Move pre-2007 changelog entries to CHANGES.package.old. - Sync Fedora license list with Revision 0.88. * Tue May 20 18:00:00 2008 Todd Zullinger - Sync Fedora license list with Revision 0.83 (Wiki rev 131). rsyslog-3.19.4-1.fc10 --------------------- * Wed May 28 18:00:00 2008 Peter Vrabec 3.19.4-1 - upgrade sbcl-1.0.17-2.fc10 ------------------ * Wed May 28 18:00:00 2008 Rex Dieter - 1.0.17-2 - omit ppc build (#448734) - skip tests, known to (sometimes) hang * Wed May 28 18:00:00 2008 Rex Dieter - 1.0.17-1 - sbcl-1.0.17 * Fri Apr 25 18:00:00 2008 Rex Dieter - 1.0.16-1 - sbcl-1.0.16 * Thu Apr 10 18:00:00 2008 Rex Dieter - 1.0.15-2 - binutils patch * Fri Feb 29 17:00:00 2008 Rex Dieter - 1.0.15-1 - sbcl-1.0.15 - %check: skip run-tests, hangs on room.test.sh * Tue Feb 19 17:00:00 2008 Fedora Release Engineering - 1.0.14-2 - Autorebuild for GCC 4.3 * Mon Jan 28 17:00:00 2008 Rex Dieter 1.0.14-1 - sbcl-1.0.14 sugar-0.81.2-1.gitc2f847c2d4.fc10 --------------------------------- * Wed May 28 18:00:00 2008 Tomeu Vizoso - 0.81.2-1.gitc2f847c2d4 - Update to last git. sugar-toolkit-0.81.3-1.gitfcc468a323.fc10 ----------------------------------------- * Wed May 28 18:00:00 2008 Tomeu Vizoso - 0.81.3-1.gitfcc468a323 - Update to last git. xkeyboard-config-1.3-1.fc10 --------------------------- * Wed May 28 18:00:00 2008 Matthias Clasen - 1.3-1 - Update to 1.3 xmltoman-0.4-1.fc10 ------------------- * Thu May 29 18:00:00 2008 Lubomir Rintel - 0.4-1 - New upstream release zaptel-1.4.11-1.fc10 -------------------- * Wed May 28 18:00:00 2008 Jeffrey C. Ollie - 1.4.11-1 - Update to 1.4.11 Summary: Added Packages: 1 Removed Packages: 0 Modified Packages: 45 Broken deps for i386 ---------------------------------------------------------- LabPlot-1.5.1.6-6.fc9.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libWand.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libMagick.so.10 avahi-ui-sharp-0.6.22-10.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 avahi-ui-sharp-0.6.22-10.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 basket-kontact-1.0.2-5.fc9.i386 requires libkpinterfaces.so.1 basket-kontact-1.0.2-5.fc9.i386 requires libkcal.so.2 basket-kontact-1.0.2-5.fc9.i386 requires libktnef.so.1 basket-kontact-1.0.2-5.fc9.i386 requires kdepim3 basket-kontact-1.0.2-5.fc9.i386 requires libkdepim.so.1 beagle-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-evolution-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-thunderbird-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 dsniff-2.4-0.2.b1.fc9.i386 requires libnids.so.1.21 epiphany-2.22.1.1-1.fc9.i386 requires iso-codes >= 0:0.45 evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.i386 requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-1.2.so.11 f-spot-0.4.3.1-1.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.i386 requires mono(glade-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 1:gdm-2.22.0-6.fc10.i386 requires iso-codes gecko-sharp2-0.12-7.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(atk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(glade-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(pango-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gsf-sharp-0.8.1-7.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 gtk-recordmydesktop-0.3.7.2-1.fc10.noarch requires recordmydesktop = 0:0.3.7.2 gtksourceview-sharp-2.0-25.fc7.i386 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 iso-codes-devel-2.1-1.fc10.noarch requires iso-codes = 0:2.1-1.fc10 kismet-extras-0.0.2007.10.R1-3.fc9.i386 requires libMagick.so.10 libopensync-plugin-kdepim-0.35-2.fc9.i386 requires libkcal.so.2 lsvpd-1.6.4-1.fc10.i386 requires libvpd_cxx-2.0.so.1 maxima-runtime-sbcl-5.14.0-4.fc9.i386 requires sbcl = 0:1.0.13 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.i386 requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.i386 requires libgeos.so.2 qt-recordmydesktop-0.3.7.2-1.fc10.noarch requires recordmydesktop = 0:0.3.7.2 smart-0.52-54.fc9.i386 requires smart-config taskjuggler-2.4.1-1.fc10.i386 requires libkcal.so.2 taskjuggler-2.4.1-1.fc10.i386 requires libktnef.so.1 taskjuggler-libs-2.4.1-1.fc10.i386 requires libkcal.so.2 tomboy-0.10.1-2.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.i386 requires mono(pango-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 totem-2.23.3-2.fc10.i386 requires iso-codes Broken deps for x86_64 ---------------------------------------------------------- LabPlot-1.5.1.6-6.fc9.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libWand.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libMagick.so.10 LabPlot-1.5.1.6-6.fc9.x86_64 requires libMagick++.so.10()(64bit) LabPlot-1.5.1.6-6.fc9.x86_64 requires libMagick.so.10()(64bit) LabPlot-1.5.1.6-6.fc9.x86_64 requires libWand.so.10()(64bit) avahi-ui-sharp-0.6.22-10.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 avahi-ui-sharp-0.6.22-10.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 basket-kontact-1.0.2-5.fc9.x86_64 requires libkcal.so.2()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires libkdepim.so.1()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires libktnef.so.1()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires kdepim3 basket-kontact-1.0.2-5.fc9.x86_64 requires libkpinterfaces.so.1()(64bit) beagle-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-evolution-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-thunderbird-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 dsniff-2.4-0.2.b1.fc9.x86_64 requires libnids.so.1.21()(64bit) evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libWand.so.10()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) f-spot-0.4.3.1-1.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx gbrainy-0.61-5.fc9.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(atk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gsf-sharp-0.8.1-7.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gtk-recordmydesktop-0.3.7.2-1.fc10.noarch requires recordmydesktop = 0:0.3.7.2 gtksourceview-sharp-2.0-25.fc7.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 kismet-extras-0.0.2007.10.R1-3.fc9.x86_64 requires libMagick.so.10()(64bit) libopensync-plugin-kdepim-0.35-2.fc9.x86_64 requires libkcal.so.2()(64bit) lsvpd-1.6.4-1.fc10.x86_64 requires libvpd_cxx-2.0.so.1()(64bit) maxima-runtime-sbcl-5.14.0-4.fc9.x86_64 requires sbcl = 0:1.0.13 muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) qt-recordmydesktop-0.3.7.2-1.fc10.noarch requires recordmydesktop = 0:0.3.7.2 smart-0.52-54.fc9.x86_64 requires smart-config taskjuggler-2.4.1-1.fc10.x86_64 requires libkcal.so.2()(64bit) taskjuggler-2.4.1-1.fc10.x86_64 requires libktnef.so.1()(64bit) taskjuggler-libs-2.4.1-1.fc10.i386 requires libkcal.so.2 taskjuggler-libs-2.4.1-1.fc10.x86_64 requires libkcal.so.2()(64bit) tomboy-0.10.1-2.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 Broken deps for ppc ---------------------------------------------------------- LabPlot-1.5.1.6-6.fc9.ppc requires libMagick++.so.10 LabPlot-1.5.1.6-6.fc9.ppc requires libWand.so.10 LabPlot-1.5.1.6-6.fc9.ppc requires libMagick.so.10 avahi-ui-sharp-0.6.22-10.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 avahi-ui-sharp-0.6.22-10.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 basket-kontact-1.0.2-5.fc9.ppc requires libkpinterfaces.so.1 basket-kontact-1.0.2-5.fc9.ppc requires libkcal.so.2 basket-kontact-1.0.2-5.fc9.ppc requires libktnef.so.1 basket-kontact-1.0.2-5.fc9.ppc requires kdepim3 basket-kontact-1.0.2-5.fc9.ppc requires libkdepim.so.1 beagle-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 beagle-evolution-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 beagle-thunderbird-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 dsniff-2.4-0.2.b1.fc9.ppc requires libnids.so.1.21 evolution-brutus-1.2.11-2.fc9.ppc requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.ppc requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.ppc requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.ppc requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-1.2.so.11 f-spot-0.4.3.1-1.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.ppc requires mono(glade-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(atk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(glade-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(pango-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gsf-sharp-0.8.1-7.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 gtk-recordmydesktop-0.3.7.2-1.fc10.noarch requires recordmydesktop = 0:0.3.7.2 gtksourceview-sharp-2.0-25.fc7.ppc requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 kismet-extras-0.0.2007.10.R1-3.fc9.ppc requires libMagick.so.10 libopensync-plugin-kdepim-0.35-2.fc9.ppc requires libkcal.so.2 lsvpd-1.6.4-1.fc10.ppc requires libvpd_cxx-2.0.so.1 maxima-runtime-sbcl-5.14.0-4.fc9.ppc requires sbcl = 0:1.0.13 muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.ppc requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.ppc requires libgeos.so.2 qt-recordmydesktop-0.3.7.2-1.fc10.noarch requires recordmydesktop = 0:0.3.7.2 smart-0.52-54.fc9.ppc requires smart-config taskjuggler-2.4.1-1.fc10.ppc requires libkcal.so.2 taskjuggler-2.4.1-1.fc10.ppc requires libktnef.so.1 taskjuggler-libs-2.4.1-1.fc10.ppc requires libkcal.so.2 taskjuggler-libs-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) tomboy-0.10.1-2.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.ppc requires mono(pango-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 Broken deps for ppc64 ---------------------------------------------------------- basket-kontact-1.0.2-5.fc9.ppc64 requires libkcal.so.2()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires libkdepim.so.1()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires libktnef.so.1()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires kdepim3 basket-kontact-1.0.2-5.fc9.ppc64 requires libkpinterfaces.so.1()(64bit) dsniff-2.4-0.2.b1.fc9.ppc64 requires libnids.so.1.21()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) gtk-recordmydesktop-0.3.7.2-1.fc10.noarch requires recordmydesktop = 0:0.3.7.2 kismet-extras-0.0.2007.10.R1-3.fc9.ppc64 requires libMagick.so.10()(64bit) libopensync-plugin-kdepim-0.35-2.fc9.ppc64 requires libkcal.so.2()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot lsvpd-1.6.4-1.fc10.ppc64 requires libvpd_cxx-2.0.so.1()(64bit) perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) qt-recordmydesktop-0.3.7.2-1.fc10.noarch requires recordmydesktop = 0:0.3.7.2 smart-0.52-54.fc9.ppc64 requires smart-config taskjuggler-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) taskjuggler-2.4.1-1.fc10.ppc64 requires libktnef.so.1()(64bit) taskjuggler-libs-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) From paul at city-fan.org Thu May 29 09:35:08 2008 From: paul at city-fan.org (Paul Howarth) Date: Thu, 29 May 2008 10:35:08 +0100 Subject: Suggestion with respect to the Fedora Update System In-Reply-To: <6dd1343e0805290133q4149cfb1vecc48ca3d8d82b35@mail.gmail.com> References: <6dd1343e0805290133q4149cfb1vecc48ca3d8d82b35@mail.gmail.com> Message-ID: <483E78CC.3090605@city-fan.org> "G" wrote: > Hi > > I got the following mail from Fedora updates. It says "The following > package has been moved to stable from testing". The Karma value > corresponding to this package is still zero (mentioned in the below > thread). Correct me if i am wrong, if the value reaches 3 its moved to > stable, thats how i understood it. I gave a comment for that package > that i am not able to test it because i was not aware what needs to be > tested for that enhancement. > > Apart from this i ve an other problem. Suggestions and Comments > Welcome for this problem :) . > I browse through the Fedora Updates repository to start testing > packages which are under the fedora testing branch, but for some of > the packages, i see that its given as an enhancement (like the below > one) but i am not able to go ahead testing it because it does not > specifiy whats the enhnacement is about. I did notice that there are > some bug fixes too made which has got the word "bugfix" but does not > map to a Bug ID i.e, the Bug ID is not mentioned in the updates. It > becomes diffficult to test those packages and give appropriate and > correct feedback.I shouldnt give back a report saying that it works or > it does not work which might be a wrong test result because i might be > testing something but the fix would be for something else. > > I would really appreciate if you all could help me with a suggestion > on this. I went a step ahead by raising a ticket in the bodhi system > so that we could have a field in the updates system where in when a > packager uploads the packages, a mandatory field on whats fixed if its > a bug fix could be stated and if its an enhanement , a small note on > what the enhancement is. Will this suggestion work ? > > This would really help people testing packages from the bodhi > repository and thereby make Fedora a real rock solid distro. > > Thanks for reading this . Hope people don't mistake me for this :) Often the bugs or enhancements come directly from upstream and not as a result of tickets in Fedora's bugzilla. Sometimes there's not even an entry in the upstream bug tracker either, so it's not always possible to provide such references. Having said that, I see many updates with no explanatory notes to say what the bug or enhancement is, and in the case where there's no ticket to refer to I think the notes can fill the gap quite well. Paul. From dev at nigelj.com Thu May 29 09:39:15 2008 From: dev at nigelj.com (Nigel Jones) Date: Thu, 29 May 2008 21:39:15 +1200 Subject: Call For Testers - Elections Application In-Reply-To: <599059470805290222g2d0d5d2emdcb07a26e56ceae1@mail.gmail.com> References: <483E6457.7010505@nigelj.com> <599059470805290222g2d0d5d2emdcb07a26e56ceae1@mail.gmail.com> Message-ID: <483E79C3.5050101@nigelj.com> roopesh majeti wrote: > I tried just now and following are my thoughts : > > 1) The first page is good. But a clear heading like "Vote for > President " will be good rather than "Real President Nominee". This depends on the election name in the DB, for real elections it'll be something like "Fedora Board F-9 Election" (or similar). > > 2) When the user wants to know the info about a Nominee, once he > clicks the link "info", it is better to have a pop-up, rather than > redirecting the whole page. > > 3) A non-uniformity is there in the Nominee's information. It is true > that the control directs us to the user homepage. But for this > President Nominee stuff, it is good to develope a generic page having > information populated regarding that Nominee. > > 4) Why the site is re-directed to cnn.com/politics > when the user request for more information > on the President Ranking page ? The CNN Politics bit was maybe a the worse part of the joke but I was kinda refering to the US Primaries etc (i'll change this in a minute), the info links for 'real' elections will goto the Wiki page(s) with the candidate information, until someone higher up in the food chain says they want it done a different way, I'm going to stick with this. An early mock up on this concept looked absolutely disgusting from a UI POV > > 5) After confirming the Vote, the user is redirected to the initial > home page. But the following appears at the bottom. > "Build time: 0.115s, Page size: 2.23KB" > It is truely required to display to the end-user ? That'll be disabled on the final implementation, just wanted it there so I could go every now and then to make sure it was happy. > > 6) When tried to view the results, by clicking "Community", iam facing > this problem. > 500 Internal error I'll keep an eye on this, I can't see an immediate reason for the 500 error though. > > > Overall, it looks fine. Thanks, - Nigel > > -Roopesh > > On 5/29/08, *Nigel Jones* > wrote: > > Hi everyone, > > With Fedora 9 out the door we hit a very busy time for elections, > the previous system was, well lets just say, not optimal. > > So I accepted the goal of creating an application by our > post-release election season that would integrate well with FAS > and would allow a different method of voting, Range Voting. > > If your not familiar with Range Voting check out > http://en.wikipedia.org/wiki/Range_voting the essentials however > is that you rank candidates from 0<-># of candidates, if you don't > like them, just rank them 0. > > In the future, the application will not only allow the Board and > Steering Committees to hold elections, it will (hopefully) become > available to SIGs and Steering Committees for any time of > poll/call to vote. > > This is where you all come in, it's impossible for a small group > of people to find every possible mistake or bug in ANY item of > software, so the more people we can get in to test it and report > bugs/issues/thoughts the better! > > All I ask is 10-20 minutes of your time, whenever your free over > the couple of days to test and provide feedback. > > Instructions: > 1) You'll need an account on the test instance of FAS at > http://publictest10.fedoraproject.org/accounts/ (PLEASE) do not > use your normal password and you don't need to do CLA etc (I've > removed that requirement in the elections app for now). > 2) Please direct your browser to > https://publictest10.fedoraproject.org/elections/ and test away! > 3) Try voting etc, make sure that you *can* view the results at > https://publictest10.fedoraproject.org/elections/results/fedora > but can't view the results at > https://publictest10.fedoraproject.org/elections/results/president > > Notes: > * I'm aware the UI is absolutely awful, there is already a ticket > open for this (https://fedorahosted.org/elections/ticket/4) please > feel free to add items there. > * Any errors you encounter that are 'unexpected' to you, please > file a ticket at https://fedorahosted.org/elections/newticket > setting Milestone to 'Release 0.1.0' with full reproduction steps, > and the time it occurred (TZ=UTC date) > * Any other feedback can be directed to the elections-devel list > (elections-devel at lists.fedorahosted.org > ) > > After 5am UTC on the 1st June both elections will end and the > 'results' should be public and hopefully we'll have a decent > election app! > > Thanks a lot & Happy Testing, > > Nigel Jones > > p.s. Sorry to those that fall asleep during my e-mail - I nearly > did too! > p.s.s. Thanks must be given to Toshio, Ricky, Luca and Mike who > have all assisted in this release > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > From balajig81 at gmail.com Thu May 29 09:46:19 2008 From: balajig81 at gmail.com (G) Date: Thu, 29 May 2008 15:16:19 +0530 Subject: Suggestion with respect to the Fedora Update System In-Reply-To: <483E78CC.3090605@city-fan.org> References: <6dd1343e0805290133q4149cfb1vecc48ca3d8d82b35@mail.gmail.com> <483E78CC.3090605@city-fan.org> Message-ID: <6dd1343e0805290246j2e0509c0lae53ea250e7a835d@mail.gmail.com> > Often the bugs or enhancements come directly from upstream and not as a > result of tickets in Fedora's bugzilla. Sometimes there's not even an entry > in the upstream bug tracker either, so it's not always possible to provide > such references. True! that but there should be same way to resolve this so that the test case to be tested is given somewhere as part of the update system or a link atleast > Having said that, I see many updates with no explanatory notes to say what > the bug or enhancement is, and in the case where there's no ticket to refer > to I think the notes can fill the gap quite well. If you take the enhancement mentioned in the mail , i dont have any clue on how to proceed and that makes it difficult. Probably a note atleast on what to be tested could obviously make a difference and that atlteast should be mandatory i feel. Cheers, Balaji On 5/29/08, Paul Howarth wrote: > "G" wrote: > > > Hi > > > > I got the following mail from Fedora updates. It says "The following > > package has been moved to stable from testing". The Karma value > > corresponding to this package is still zero (mentioned in the below > > thread). Correct me if i am wrong, if the value reaches 3 its moved to > > stable, thats how i understood it. I gave a comment for that package > > that i am not able to test it because i was not aware what needs to be > > tested for that enhancement. > > > > Apart from this i ve an other problem. Suggestions and Comments > > Welcome for this problem :) . > > I browse through the Fedora Updates repository to start testing > > packages which are under the fedora testing branch, but for some of > > the packages, i see that its given as an enhancement (like the below > > one) but i am not able to go ahead testing it because it does not > > specifiy whats the enhnacement is about. I did notice that there are > > some bug fixes too made which has got the word "bugfix" but does not > > map to a Bug ID i.e, the Bug ID is not mentioned in the updates. It > > becomes diffficult to test those packages and give appropriate and > > correct feedback.I shouldnt give back a report saying that it works or > > it does not work which might be a wrong test result because i might be > > testing something but the fix would be for something else. > > > > I would really appreciate if you all could help me with a suggestion > > on this. I went a step ahead by raising a ticket in the bodhi system > > so that we could have a field in the updates system where in when a > > packager uploads the packages, a mandatory field on whats fixed if its > > a bug fix could be stated and if its an enhanement , a small note on > > what the enhancement is. Will this suggestion work ? > > > > This would really help people testing packages from the bodhi > > repository and thereby make Fedora a real rock solid distro. > > > > Thanks for reading this . Hope people don't mistake me for this :) > > > > Often the bugs or enhancements come directly from upstream and not as a > result of tickets in Fedora's bugzilla. Sometimes there's not even an entry > in the upstream bug tracker either, so it's not always possible to provide > such references. > > Having said that, I see many updates with no explanatory notes to say what > the bug or enhancement is, and in the case where there's no ticket to refer > to I think the notes can fill the gap quite well. > > Paul. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From opensource at till.name Thu May 29 09:55:16 2008 From: opensource at till.name (Till Maas) Date: Thu, 29 May 2008 11:55:16 +0200 Subject: Suggestion with respect to the Fedora Update System In-Reply-To: <6dd1343e0805290246j2e0509c0lae53ea250e7a835d@mail.gmail.com> References: <6dd1343e0805290133q4149cfb1vecc48ca3d8d82b35@mail.gmail.com> <483E78CC.3090605@city-fan.org> <6dd1343e0805290246j2e0509c0lae53ea250e7a835d@mail.gmail.com> Message-ID: <200805291155.26287.opensource@till.name> On Thu May 29 2008, "G" wrote: > If you take the enhancement mentioned in the mail , i dont have any > clue on how to proceed and that makes it difficult. Probably a note > atleast on what to be tested could obviously make a difference and > that atlteast should be mandatory i feel. Often it will be enough just to use the application a little to provide feedback, e.g. as long as the application does not crash or corrupt some data, then the update is good enough most of the times imho. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From balajig81 at gmail.com Thu May 29 10:05:09 2008 From: balajig81 at gmail.com (G) Date: Thu, 29 May 2008 15:35:09 +0530 Subject: Suggestion with respect to the Fedora Update System In-Reply-To: <200805291155.26287.opensource@till.name> References: <6dd1343e0805290133q4149cfb1vecc48ca3d8d82b35@mail.gmail.com> <483E78CC.3090605@city-fan.org> <6dd1343e0805290246j2e0509c0lae53ea250e7a835d@mail.gmail.com> <200805291155.26287.opensource@till.name> Message-ID: <6dd1343e0805290305j11fce27ft72c9bdebac511100@mail.gmail.com> > > If you take the enhancement mentioned in the mail , i dont have any > > clue on how to proceed and that makes it difficult. Probably a note > > atleast on what to be tested could obviously make a difference and > > that atlteast should be mandatory i feel. Ok but for some packages some testers have responded saying "It works for me " some people have told it does not work me " . If you look at these 2 statements, its contradicting, thats point one and the next one is "It" is still undefined for other testers :). My suggestion is why cannot we define "It" as a test case or an enhancement atleast. I sincerely feel that it would make a big difference. Probably we could review our updates system and try adding a field which gives more info.I also strongly feel that it would help our contributors in a real positive way. Cheers, Balaji On 5/29/08, Till Maas wrote: > On Thu May 29 2008, "G" wrote: > > > If you take the enhancement mentioned in the mail , i dont have any > > clue on how to proceed and that makes it difficult. Probably a note > > atleast on what to be tested could obviously make a difference and > > that atlteast should be mandatory i feel. > > > Often it will be enough just to use the application a little to provide > feedback, e.g. as long as the application does not crash or corrupt some > data, then the update is good enough most of the times imho. > > Regards, > > Till > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > From opensource at till.name Thu May 29 10:15:21 2008 From: opensource at till.name (Till Maas) Date: Thu, 29 May 2008 12:15:21 +0200 Subject: Suggestion with respect to the Fedora Update System In-Reply-To: <6dd1343e0805290305j11fce27ft72c9bdebac511100@mail.gmail.com> References: <6dd1343e0805290133q4149cfb1vecc48ca3d8d82b35@mail.gmail.com> <200805291155.26287.opensource@till.name> <6dd1343e0805290305j11fce27ft72c9bdebac511100@mail.gmail.com> Message-ID: <200805291215.22573.opensource@till.name> On Thu May 29 2008, "G" wrote: > Ok but for some packages some testers have responded saying "It works > for me " some people have told it does not work me " . If you look at > these 2 statements, its contradicting, thats point one and the next > one is "It" is still undefined for other testers :). My suggestion is > why cannot we define "It" as a test case or an enhancement atleast. I > sincerely feel that it would make a big difference. > Probably we could review our updates system and try adding a field > which gives more info.I also strongly feel that it would help our > contributors in a real positive way. Imho everytime some package receives bad karma, it needs to be explained what did not work, otherwise nobody can fix it. For good karma, imho the testcases could be better collected somewhere else than in each update, because they will not differ much for each release, e.g. for a yum update one would always check whether update/install/remove works. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From balajig81 at gmail.com Thu May 29 10:59:04 2008 From: balajig81 at gmail.com (G) Date: Thu, 29 May 2008 16:29:04 +0530 Subject: Suggestion with respect to the Fedora Update System In-Reply-To: <200805291215.22573.opensource@till.name> References: <6dd1343e0805290133q4149cfb1vecc48ca3d8d82b35@mail.gmail.com> <200805291155.26287.opensource@till.name> <6dd1343e0805290305j11fce27ft72c9bdebac511100@mail.gmail.com> <200805291215.22573.opensource@till.name> Message-ID: <6dd1343e0805290359s6c46e9b4hf1fe00239bb8b669@mail.gmail.com> > Imho everytime some package receives bad karma, it needs to be explained what > did not work, otherwise nobody can fix it. For good karma, imho the testcases > could be better collected somewhere else than in each update, because they > will not differ much for each release, e.g. for a yum update one would always > check whether update/install/remove works. For bugs which does not have any Bug ID tagged and for an enhancement for which there is no note written about the enhancement, should i take this approach of just installing the package, check whether the basic application works and it does not corrupt any other stuff and inform it works ? or should i do something more than this and yeah documenting it somewhere should be fine , there should be some databasse we need that helps as a reference. This is mandatory Cheers Balaji On 5/29/08, Till Maas wrote: > On Thu May 29 2008, "G" wrote: > > > > Ok but for some packages some testers have responded saying "It works > > for me " some people have told it does not work me " . If you look at > > these 2 statements, its contradicting, thats point one and the next > > one is "It" is still undefined for other testers :). My suggestion is > > why cannot we define "It" as a test case or an enhancement atleast. I > > sincerely feel that it would make a big difference. > > Probably we could review our updates system and try adding a field > > which gives more info.I also strongly feel that it would help our > > contributors in a real positive way. > > > Imho everytime some package receives bad karma, it needs to be explained what > did not work, otherwise nobody can fix it. For good karma, imho the testcases > could be better collected somewhere else than in each update, because they > will not differ much for each release, e.g. for a yum update one would always > check whether update/install/remove works. > > Regards, > > Till > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > From ndbecker2 at gmail.com Thu May 29 13:32:52 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 29 May 2008 09:32:52 -0400 Subject: samba critical security issue Message-ID: http://blogs.zdnet.com/security/?p=1206 From j.w.r.degoede at hhs.nl Thu May 29 13:56:10 2008 From: j.w.r.degoede at hhs.nl (Goede, J.W.R. de) Date: Thu, 29 May 2008 15:56:10 +0200 Subject: Fedora project: making a website with Fedora-Free music In-Reply-To: <483BEB7D.1080200@nicubunu.ro> References: <483BDA91.9020008@hhs.nl> <483BEB7D.1080200@nicubunu.ro> Message-ID: On Tue, 27 May 2008 14:07:41 +0300 Nicu Buculei wrote: > Hans de Goede wrote: > > Today I've been discussing with upstream replacing some > non free music > > with Free music, as I need to do often when packaging > games (in this > > case Lost Labyrinth). > > > > I have been thinking recently about how convenient it > would be to have a > > website where one can browse all known Fedora-Free (as > in can be part of > > Fedora under the content Licensing guidelines) music. > > Free enough that we can use also as a soundtrack for > screencasts (that's is, if someone likes game music as > sountreact for his screencast) > Was that a question or a remark? In case it was a question, yes they should be free enough, although you might need to put some atrtribution in the begin / end titles for attribution. > > -Links to other website which contain all Free, or > clearly marked partially > > Free music. > > > > The first website which comes mind for the links > section is the excellent: > > http://www.dogmazic.net/ > > Or like this http://ccmixter.org/ ? > That would be an interesting site for the links section too, yes. > > How about using ccHost, the software used by (and made > for) ccMixter? The problem is that it may need support > for some file formats > I dunno, ccmixter looks rather more convoluted / harder to navigate then I would want this site to look. Regards, Hans From wwoods at redhat.com Thu May 29 13:56:27 2008 From: wwoods at redhat.com (Will Woods) Date: Thu, 29 May 2008 09:56:27 -0400 Subject: samba critical security issue In-Reply-To: References: Message-ID: <1212069387.17508.19.camel@zebes.localdomain> On Thu, 2008-05-29 at 09:32 -0400, Neal Becker wrote: > http://blogs.zdnet.com/security/?p=1206 We track security bugs by CVE id.. so it'd help if you provided those when reporting one. Anyway, following the links in that article, I find that the issue has been assigned CVE-2008-1105. The security team adds CVE ids as aliases for all security bugs, so you can just search bugzilla by CVE id: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2008-1105 ..and there you have it. Fix is in updates-testing for F9. -w From jkeating at redhat.com Thu May 29 14:21:41 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 29 May 2008 10:21:41 -0400 Subject: Plan for tomorrows (20080529) FESCO meeting: FTBFS bugs In-Reply-To: <20080528205138.GC18364@auslistsprd01.us.dell.com> References: <1211984880.27774.3.camel@truman> <20080528205138.GC18364@auslistsprd01.us.dell.com> Message-ID: <1212070901.16130.12.camel@localhost.localdomain> On Wed, 2008-05-28 at 15:51 -0500, Matt Domsch wrote: > (and of course there are packages with no dist tag which fail too) so > the number of packages we'd consider here isn't huge, but is nonzero. > > Please consider adopting a policy regarding packages which continue to > fail to build from source for a given distribution. These packages > need attention, if only because we have disabled F6 buildroots which > would be necessary to build and fix a bug in such a package package in > the F9 release. I agree with Will Woods' suggestion (pardon if I > mis-attribute) that such cutoff point should be the Beta cut of the > next version of the release. For me, Beta is too late. I'd rather see them go post-alpha, like immediately post-alpha. Since these all have ftbfs bugs filed, can't we use those bugs as the basis of finding non-responsive maintainers, and initiate the orphan process on these packages, which would get sweeped up in that same post-alpha, pre-beta timeframe? -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Thu May 29 14:22:35 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 29 May 2008 10:22:35 -0400 Subject: Plan for tomorrows (20080529) FESCO meeting: FTBFS bugs In-Reply-To: <20080529073834.GA2595@free.fr> References: <1211984880.27774.3.camel@truman> <20080528205138.GC18364@auslistsprd01.us.dell.com> <20080529073834.GA2595@free.fr> Message-ID: <1212070955.16130.13.camel@localhost.localdomain> On Thu, 2008-05-29 at 09:38 +0200, Patrice Dumas wrote: > > I own some packages that don't rebuild (in F-9), I was waiting for an > upstream release that didn't came (for libnc-dap, though there was a > release of libdap). I'd prefer if they were kept. I'll take the time to > patch them to rebuild, but I'd prefer doing it only if needed. This is why I want to use the non-responsive maintainer policy. If you've responded in the bug you wouldn't be triggered as non-responsive. We'd still have to figure out some way to get your build going, but we wouldn't be waiting on a black hole. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From opensource at till.name Thu May 29 15:05:33 2008 From: opensource at till.name (Till Maas) Date: Thu, 29 May 2008 17:05:33 +0200 Subject: Suggestion with respect to the Fedora Update System In-Reply-To: <6dd1343e0805290359s6c46e9b4hf1fe00239bb8b669@mail.gmail.com> References: <6dd1343e0805290133q4149cfb1vecc48ca3d8d82b35@mail.gmail.com> <200805291215.22573.opensource@till.name> <6dd1343e0805290359s6c46e9b4hf1fe00239bb8b669@mail.gmail.com> Message-ID: <200805291705.42210.opensource@till.name> On Thu May 29 2008, "G" wrote: > For bugs which does not have any Bug ID tagged and for an enhancement > for which there is no note written about the enhancement, should i > take this approach of just installing the package, check whether the > basic application works and it does not corrupt any other stuff and > inform it works ? or should i do something more than this and yeah There is no real policy about this, therefore I say checking the basics is enough for now. You can also note this in the comment. > documenting it somewhere should be fine , there should be some > databasse we need that helps as a reference. This is mandatory You can just start and try to create some reference for some packages you are interested and join the QA-Sig, i.e. contact the people listed here: http://fedoraproject.org/wiki/SIGs/QA Maybe you can together create a framework / procedures to document the test cases and assign them to testers. Also you can ask on the Fedora testing list: https://www.redhat.com/mailman/listinfo/fedora-test-list Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From poelstra at redhat.com Thu May 29 15:07:53 2008 From: poelstra at redhat.com (John Poelstra) Date: Thu, 29 May 2008 08:07:53 -0700 Subject: Plan for tomorrows (20080529) FESCO meeting In-Reply-To: <1211984880.27774.3.camel@truman> References: <1211984880.27774.3.camel@truman> Message-ID: <483EC6C9.8080805@redhat.com> Brian Pepple said the following on 05/28/2008 07:28 AM Pacific Time: > Hi all, > > Please find below the list of topics that are likely to come up in the > next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC > in #fedora-meeting on irc.freenode.org: > > /topic FESCo meeting -- > https://fedoraproject.org/wiki/Extras/Schedule/SponsorResponsibilityPolicy -- bpepple > > topic FESCO-Meeting -- FESCo Responsibilities/Role -- all > > /topic FESCo meeting -- Free discussion around Fedora > > You want something to be discussed? Send a note to the list in reply to > this mail and I'll add it to the schedule. You can also propose topics > in the meeting while it is in the "Free discussion around Fedora" phase. > > If your name/nick is on above list please update the status on the > Extras schedule pages in the wiki ahead of the meeting. That way all the > other FESCo members and interested contributors know what up ahead of > the meeting. And we will avoid long delays in the meeting -- those often > arise if someone describes the recent happenings on a topic directly in > the meeting while all the others have to wait for his slow typing... > > Later, > /B > Proposed topic: Finalize Fedora 10 Feature process https://www.redhat.com/archives/fedora-devel-announce/2008-May/msg00014.html So far NO feedback has been received here: http://fedoraproject.org/wiki/Features/F10PolicyReview John From bpepple at fedoraproject.org Thu May 29 15:21:53 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Thu, 29 May 2008 11:21:53 -0400 Subject: Plan for tomorrows (20080529) FESCO meeting In-Reply-To: <483EC6C9.8080805@redhat.com> References: <1211984880.27774.3.camel@truman> <483EC6C9.8080805@redhat.com> Message-ID: <1212074513.3532.1.camel@truman> On Thu, 2008-05-29 at 08:07 -0700, John Poelstra wrote: > Proposed topic: Finalize Fedora 10 Feature process > > https://www.redhat.com/archives/fedora-devel-announce/2008-May/msg00014.html > > So far NO feedback has been received here: > http://fedoraproject.org/wiki/Features/F10PolicyReview We'll probably be discussing this partially when we discuss FESCo's role/responsibility during today's meeting. Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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: 197 bytes Desc: This is a digitally signed message part URL: From bnocera at redhat.com Thu May 29 16:32:31 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Thu, 29 May 2008 17:32:31 +0100 Subject: Watchlists (was Re: Wiki Migration Complete!) In-Reply-To: <483D5C2D.6070901@ioa.s.u-tokyo.ac.jp> References: <483D5C2D.6070901@ioa.s.u-tokyo.ac.jp> Message-ID: <1212078751.2821.23.camel@cookie.hadess.net> Mike McGrath wrote, at 05/28/2008 08:05 AM +9:00: > The migration to Mediawiki is finally complete! The technical side, > that is. Now is the part where we all learn how to migrate our > knowledge and clean-up content. > > http://fedoraproject.org/wiki/ Is there any way to get our watchlists back from the old Wiki? I was watching a number of pages, but the watchlist is now empty. Even the list from the old wiki would be useful to me, so I can resubscribe in the new one. Cheers From opensource at till.name Thu May 29 16:40:03 2008 From: opensource at till.name (Till Maas) Date: Thu, 29 May 2008 18:40:03 +0200 Subject: Watchlists (was Re: Wiki Migration Complete!) In-Reply-To: <1212078751.2821.23.camel@cookie.hadess.net> References: <483D5C2D.6070901@ioa.s.u-tokyo.ac.jp> <1212078751.2821.23.camel@cookie.hadess.net> Message-ID: <200805291840.17451.opensource@till.name> On Thu May 29 2008, Bastien Nocera wrote: > Is there any way to get our watchlists back from the old Wiki? I was > watching a number of pages, but the watchlist is now empty. > > Even the list from the old wiki would be useful to me, so I can > resubscribe in the new one. You can get the contents of the old wiki at: http://fedoraproject.org/wikiold/ Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From skvidal at fedoraproject.org Thu May 29 16:59:51 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 29 May 2008 12:59:51 -0400 Subject: Watchlists (was Re: Wiki Migration Complete!) In-Reply-To: <200805291840.17451.opensource@till.name> References: <483D5C2D.6070901@ioa.s.u-tokyo.ac.jp> <1212078751.2821.23.camel@cookie.hadess.net> <200805291840.17451.opensource@till.name> Message-ID: <1212080391.3716.0.camel@cutter> On Thu, 2008-05-29 at 18:40 +0200, Till Maas wrote: > On Thu May 29 2008, Bastien Nocera wrote: > > > Is there any way to get our watchlists back from the old Wiki? I was > > watching a number of pages, but the watchlist is now empty. > > > > Even the list from the old wiki would be useful to me, so I can > > resubscribe in the new one. > > You can get the contents of the old wiki at: > http://fedoraproject.org/wikiold/ > and your old watchlist is in your userprofile page - at the bottom. -sv From bnocera at redhat.com Thu May 29 17:10:38 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Thu, 29 May 2008 18:10:38 +0100 Subject: Watchlists (was Re: Wiki Migration Complete!) In-Reply-To: <1212080391.3716.0.camel@cutter> References: <483D5C2D.6070901@ioa.s.u-tokyo.ac.jp> <1212078751.2821.23.camel@cookie.hadess.net> <200805291840.17451.opensource@till.name> <1212080391.3716.0.camel@cutter> Message-ID: <1212081038.2821.25.camel@cookie.hadess.net> On Thu, 2008-05-29 at 12:59 -0400, seth vidal wrote: > On Thu, 2008-05-29 at 18:40 +0200, Till Maas wrote: > > On Thu May 29 2008, Bastien Nocera wrote: > > > > > Is there any way to get our watchlists back from the old Wiki? I was > > > watching a number of pages, but the watchlist is now empty. > > > > > > Even the list from the old wiki would be useful to me, so I can > > > resubscribe in the new one. > > > > You can get the contents of the old wiki at: > > http://fedoraproject.org/wikiold/ > > > > and your old watchlist is in your userprofile page - at the bottom. Thank you both. From pratykschingh at gmail.com Thu May 29 17:25:36 2008 From: pratykschingh at gmail.com (Prateek Singh) Date: Thu, 29 May 2008 23:10:36 +0545 Subject: Orphaning my Packages (or: RIP, Fedora!) In-Reply-To: <20080527225835.GA12180@hurricane.linuxnetz.de> References: <483B8450.6070505@theholbrooks.org> <20080527225835.GA12180@hurricane.linuxnetz.de> Message-ID: > Brandon Holbrook a ?crit : > >> php-json -- An extremely fast PHP extension for JSON >> php-pear-Mail-Mime -- Classes to create and decode mime messages >> php-pear-Mail-mimeDecode -- transcodes mime messages >> php-pear-Net-Sieve -- Communication with timsieved >> php-pecl-Fileinfo -- Fileinfo is a PHP extension that wraps the libmagic >> library >> php-shout -- PHP module for communicating with Icecast servers > > I can take ownership of this php related package (as/with a co-maintener > if someone else want) I would be happy to co-maintain the packages. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kagesenshi.87 at gmail.com Thu May 29 17:40:45 2008 From: kagesenshi.87 at gmail.com (Izhar Firdaus) Date: Fri, 30 May 2008 01:40:45 +0800 Subject: building mozilla Prism on Fedora Message-ID: I'm trying to build mozilla prism trunk using fedora dependencies (xulrunner etc). I have no experience building an xulrunner apps and using the mozilla buildsystem before. I tried following this http://developer.mozilla.org/en/docs/Creating_XULRunner_Apps_with_the_Mozilla_Build_System (replacing the sdk tarball with its rpm package equivalent) but failed miserably. Can somebody point me to some site that i can read to get me on the right path? or maybe some clues?. I really want prism on fedora, but so far nobody seems to have packaged it .. -- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? http://fedoraproject.org/wiki/MohdIzharFirdaus http://blog.kagesenshi.org 92C2 B295 B40B B3DC 6866 5011 5BD2 584A 8A5D 7331 From poelstra at redhat.com Thu May 29 18:23:36 2008 From: poelstra at redhat.com (John Poelstra) Date: Thu, 29 May 2008 11:23:36 -0700 Subject: Fedora Org Clarity Attempt Message-ID: <483EF4A8.5040300@redhat.com> Watching the FESCo meeting today a lot of things were not clear, but one thing that stood out too me is that that we really don't have is a clear picture or agreement on what the "Fedora Org" looks like and and how it is supposed to work. I'm sure some out there will think I'm getting to "corporate", however I've often found that creating picture of things helps to simplify things in ways that thousands of words can't. Attached is starting template. Fill out the rest with your ideal version of what it should all look like and I'd be glad to help refactor into different proposals. If you won't want to mess with open office... explain it in text and I'll draw it for you. John -------------- next part -------------- A non-text attachment was scrubbed... Name: fedora-org-2008-05-v1.odg Type: application/vnd.oasis.opendocument.graphics Size: 10070 bytes Desc: not available URL: From rdieter at math.unl.edu Thu May 29 18:49:01 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 29 May 2008 13:49:01 -0500 Subject: Orphaning my Packages (or: RIP, Fedora!) References: <483B8450.6070505@theholbrooks.org> <1211869601.4081.3.camel@ignacio.lan> Message-ID: Ignacio Vazquez-Abrams wrote: > On Mon, 2008-05-26 at 22:47 -0500, Brandon Holbrook wrote: >> mod_auth_pam -- PAM authentication module for Apache > > *yoink* I can help out here (on epel) too. -- Rx From jspaleta at gmail.com Thu May 29 19:52:56 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 29 May 2008 11:52:56 -0800 Subject: Fedora Org Clarity Attempt In-Reply-To: <483EF4A8.5040300@redhat.com> References: <483EF4A8.5040300@redhat.com> Message-ID: <604aa7910805291252v7a8cbecdg1cd02c40786bbabc@mail.gmail.com> 2008/5/29 John Poelstra : > I'm sure some out there will think I'm getting to "corporate", however I've > often found that creating picture of things helps to simplify things in ways > that thousands of words can't. Yeah, I've tried to suggest a new meme via my Role based SIG proposal. Which by the way is infinitely better than yours because I used inkscape and generated an SVG...with rainbow colors and gradients. More seriously.... let me suggest that if we are going to think in terms of an organizational chart as you have proposed...that we do it in a way that stresses three key factors with regard to relationships among Fedora subproject units. For this discussion I'm still assuming that SIGs will be using the role-based concept and thus have a more complicated structure best illustrated with my super awesome rainbow svg. And as such they sit somewhat outside a standard organizational chart because of their highly collaborative nature. Factor 1: Dispute Resolution Who do you go to when a subproject can't reach agreement and needs arbitration? Factor 2: Intra-Project Communication Which group do you expect a subproject to receive important information from and to send important information to, to insure communication to other sub-projects. Factor 3: Oversight Which other group sets and updates policy boundaries which a subproject is explicitly constrained by. In a corporate entity, all of this would be thought of as accountability... who do you report to.. and the answer would usually be the same entity for all 3 factors. I'm not sure that is the case for Fedora, as a volunteer staffed organization. -jef From aoliva at redhat.com Thu May 29 19:58:00 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Thu, 29 May 2008 16:58:00 -0300 Subject: Call For Testers - Elections Application In-Reply-To: <483E6457.7010505@nigelj.com> (Nigel Jones's message of "Thu\, 29 May 2008 20\:07\:51 +1200") References: <483E6457.7010505@nigelj.com> Message-ID: On May 29, 2008, Nigel Jones wrote: > So I accepted the goal of creating an application by our > post-release election season that would integrate well with FAS and > would allow a different method of voting, Range Voting. Have you considered basing your work on CIVS? http://www.cs.cornell.edu/andru/civs.html I've got a version stripped off of all the voting-by-e-mail aspects, which you might be interested in. Search for 'civs' in my home page (URL in the .sig). -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From txtoth at gmail.com Thu May 29 20:08:53 2008 From: txtoth at gmail.com (Xavier Toth) Date: Thu, 29 May 2008 15:08:53 -0500 Subject: gdm xserver restart as login user Message-ID: The gdm docs say that in Solaris the xserver is restarted as the login user instead of root as an added security precaution. Would it be possible to get this same functionality for Fedora? From kevin.kofler at chello.at Thu May 29 20:13:42 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 29 May 2008 20:13:42 +0000 (UTC) Subject: Suggestion with respect to the Fedora Update System References: <6dd1343e0805290133q4149cfb1vecc48ca3d8d82b35@mail.gmail.com> Message-ID: "G" gmail.com> writes: > Correct me if i am wrong, if the value reaches 3 its moved to > stable, thats how i understood it. The maintainer can request a push to stable whenever he/she wants, even if the karma is at -1000. The +3 threshold is only the threshold at which Bodhi will automatically request a push to stable. Most pushes to stable are requested manually because otherwise we'd wait forever for the +3 karma. Kevin Kofler From jspaleta at gmail.com Thu May 29 20:28:32 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 29 May 2008 12:28:32 -0800 Subject: Suggestion with respect to the Fedora Update System In-Reply-To: References: <6dd1343e0805290133q4149cfb1vecc48ca3d8d82b35@mail.gmail.com> Message-ID: <604aa7910805291328w6ed7f0c0if92959341c4cf0e2@mail.gmail.com> On Thu, May 29, 2008 at 12:13 PM, Kevin Kofler wrote: > The maintainer can request a push to stable whenever he/she wants, even if the > karma is at -1000. The +3 threshold is only the threshold at which Bodhi will > automatically request a push to stable. Most pushes to stable are requested > manually because otherwise we'd wait forever for the +3 karma. I am of the humble opinion, that we aren't going to see more users engage in specific package testing, unless we have a clientside tool which can inform users of the availability of the update in a way that encourages them to use bodhi for testing updates after they are installed. It's a really tough ui problem. Or to put it another way...with updates-testing enabled I don't easily know which packages are from updates-testing without making special effort to determine it. Unless I notice breakage, bodhi karma pushes from me probably aren't going to happen for most updates-testing packages i pull down. I am probably not alone. If the packaging UI remind me as to which packages I have installed were from updates-testing and which ones I have yet commented on, that would be an immense help in encouraging me to respond in a timely fashion and send in positive karma. -jef From j.w.r.degoede at hhs.nl Thu May 29 21:03:40 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 29 May 2008 23:03:40 +0200 Subject: Fedora project: making a website with Fedora-Free music In-Reply-To: <200805271154.59011.ben.lewis@benl.co.uk> References: <483BDA91.9020008@hhs.nl> <200805271154.59011.ben.lewis@benl.co.uk> Message-ID: <483F1A2C.4080603@hhs.nl> Benjamin Lewis wrote: > On Tuesday 27 May 2008 10:55:29 Hans de Goede wrote: >> Hi All, >> >> Today I've been discussing with upstream replacing some non free music with >> Free music, as I need to do often when packaging games (in this case Lost >> Labyrinth). >> >> I have been thinking recently about how convenient it would be to have a >> website where one can browse all known Fedora-Free (as in can be part of >> Fedora under the content Licensing guidelines) music. >> >> The Fedora package collection already contains quite a bit of music. Some >> put in -music packages because its in ogg format and thus quite large, but >> also quite a few modtracker and midi format songs, which are much smaller >> and sometimes even hidden away in .wad / .dat files. >> >> Thus I want to make a website with: >> -Unpacked (as in click on it and it will play) versions of all music >> included in Fedora, sorted by format and license, and preferably also >> catogorised by genre. >> >> -Links to other website which contain all Free, or clearly marked partially >> Free music. >> >> The first website which comes mind for the links section is the >> excellent: http://www.dogmazic.net/ >> >> >> So now I need 2 things >> 1) Free (as in gratis) hosting, with lots of diskspace and potentially >> quite some bandwidth usage. >> >> 2) Someone to help me build the website, the last time I've done php / html >> was in 1999 :) >> > > I would be willing to help with no. 2, although I can't really help with the > hosting as mine is in a state of serious flux atm and really dosn't have > enough diskspace. > Thanks for the offer, I'll keep it in mind if / when I get this project from the ground. Regards, Hans From poelstra at redhat.com Thu May 29 22:02:33 2008 From: poelstra at redhat.com (John Poelstra) Date: Thu, 29 May 2008 15:02:33 -0700 Subject: Fedora Org Clarity Attempt In-Reply-To: <604aa7910805291252v7a8cbecdg1cd02c40786bbabc@mail.gmail.com> References: <483EF4A8.5040300@redhat.com> <604aa7910805291252v7a8cbecdg1cd02c40786bbabc@mail.gmail.com> Message-ID: <483F27F9.5070903@redhat.com> Jeff Spaleta said the following on 05/29/2008 12:52 PM Pacific Time: > 2008/5/29 John Poelstra : >> I'm sure some out there will think I'm getting to "corporate", however I've >> often found that creating picture of things helps to simplify things in ways >> that thousands of words can't. > > Yeah, I've tried to suggest a new meme via my Role based SIG proposal. > Which by the way is infinitely better than yours because I used > inkscape and generated > an SVG...with rainbow colors and gradients. > > More seriously.... > let me suggest that if we are going to think in terms of an > organizational chart as you have proposed...that we do it in a way > that stresses three key factors with regard to relationships among > Fedora subproject units. For this discussion I'm still assuming that > SIGs will be using the role-based concept and thus have a more > complicated structure best illustrated with my super awesome rainbow > svg. And as such they sit somewhat outside a standard organizational > chart because of their highly collaborative nature. > > Factor 1: Dispute Resolution > Who do you go to when a subproject can't reach agreement and needs arbitration? > > Factor 2: Intra-Project Communication > Which group do you expect a subproject to receive important information from and > to send important information to, to insure communication to other sub-projects. > > Factor 3: Oversight > Which other group sets and updates policy boundaries which a > subproject is explicitly constrained by. > > > In a corporate entity, all of this would be thought of as > accountability... who do you report to.. and the answer would usually > be the same entity for all 3 factors. I'm not sure that is the case > for Fedora, as a volunteer staffed organization. I think your three factors are great! With the flattening of many organizations reporting lines are not as linear as they used to be so I would disagree that all three factors would be met by one entity. I think accountability definitely applies to Fedora. Aren't we accountable to each other as a project to do what we say we will do on a given task? And if we don't do what we've committed to, the project suffers? I don't think accountability only applies to situations where you can be fired. In my experience, when accountability is crafted well it leads to be better results, not more bureaucracy. John From jspaleta at gmail.com Thu May 29 22:18:50 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 29 May 2008 14:18:50 -0800 Subject: Fedora Org Clarity Attempt In-Reply-To: <483F27F9.5070903@redhat.com> References: <483EF4A8.5040300@redhat.com> <604aa7910805291252v7a8cbecdg1cd02c40786bbabc@mail.gmail.com> <483F27F9.5070903@redhat.com> Message-ID: <604aa7910805291518g453924ebgd47f1c5a475761b7@mail.gmail.com> On Thu, May 29, 2008 at 2:02 PM, John Poelstra wrote: > I think accountability definitely applies to Fedora. Aren't we accountable > to each other as a project to do what we say we will do on a given task? > And if we don't do what we've committed to, the project suffers? If I were going to depict accountability as a relationship on the org chart for us how do i draw a relationship between one person and everyone in an organizational chart and still have the chart make sense? If it ends up looking like a graph of the Fedora repository wide packaging depedancies... its not going to be particularly helpful. Yes accountability is there, but I don't think we can easily draw a group to group relationship for it for our organization. -jef"we need a 3D org chart that can only be navigated as a layer in compiz-fusion"spaleta From d.lesca at solinos.it Thu May 29 22:37:18 2008 From: d.lesca at solinos.it (Dario Lesca) Date: Fri, 30 May 2008 00:37:18 +0200 Subject: f9: x86_64: Missing C++ runtime support for g++ (/usr/bin/g++). Message-ID: <1212100638.3581.9.camel@lesca.home.solinos.it> Hi, I try to rebuild hylafax on F9/x86_64, I have installer this package: > [root at arese ~]# yum list |grep -i '++' > bonnie++.x86_64 1.03a-9.fc9 installed > compat-gcc-34-c++.x86_64 3.4.6-9 installed > compat-libstdc++-296.i386 2.96-140 installed > compat-libstdc++-33.x86_64 3.2.3-63 installed > gcc-c++.x86_64 4.3.0-8 installed > gcc-objc++.x86_64 4.3.0-8 installed > libsigc++20.x86_64 2.2.2-1.fc9 installed > libstdc++.x86_64 4.3.0-8 installed > libstdc++.i386 4.3.0-8 installed > libstdc++-devel.x86_64 4.3.0-8 installed > ....... But when I run "rpmbuild --rebuild hylafax-4.4.4-1rhel5.src.rpm" I get this error: > Missing C++ runtime support for g++ (/usr/bin/g++). > > Compilation of the following test program failed: > > ---------------------------------------------------------- > #include "iostream.h" > int main(){ cout << "Hello World!" << endl; return 0;} > ---------------------------------------------------------- > > Usually this is because you do not have a standard C++ library > installed on your system or you have installed it in a non-standard > location. If you do not have a C++ library installed, then you must > install it. If it is installed in a non-standard location, then you > should configure the compiler so that it will automatically be found. > > (For recent gcc releases this is libstdc++, for older gcc - libg++) How I can remove this error? Which package I have yet to install ? Many thanks for help. -- Dario Lesca From jakub at redhat.com Thu May 29 22:49:53 2008 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 29 May 2008 18:49:53 -0400 Subject: f9: x86_64: Missing C++ runtime support for g++ (/usr/bin/g++). In-Reply-To: <1212100638.3581.9.camel@lesca.home.solinos.it> References: <1212100638.3581.9.camel@lesca.home.solinos.it> Message-ID: <20080529224953.GY16061@devserv.devel.redhat.com> On Fri, May 30, 2008 at 12:37:18AM +0200, Dario Lesca wrote: > > Compilation of the following test program failed: > > > > ---------------------------------------------------------- > > #include "iostream.h" > > int main(){ cout << "Hello World!" << endl; return 0;} > > ---------------------------------------------------------- > > > > Usually this is because you do not have a standard C++ library > > installed on your system or you have installed it in a non-standard > > location. If you do not have a C++ library installed, then you must > > install it. If it is installed in a non-standard location, then you > > should configure the compiler so that it will automatically be found. > > > > (For recent gcc releases this is libstdc++, for older gcc - libg++) > > How I can remove this error? The above is not valid C++98, you need to use #include using namespace std; int main() { cout << "Hello World!" << endl; return 0; } g++34 provides backwards support for deprecated pre-ISO C++ headers, g++ doesn't any longer. See http://gcc.gnu.org/gcc-4.3/porting_to.html "Removal of Pre-ISO headers" for more info. Jakub From robert at fedoraproject.org Thu May 29 22:59:02 2008 From: robert at fedoraproject.org (Robert Scheck) Date: Fri, 30 May 2008 00:59:02 +0200 Subject: Suggestion with respect to the Fedora Update System In-Reply-To: <6dd1343e0805290133q4149cfb1vecc48ca3d8d82b35@mail.gmail.com> References: <6dd1343e0805290133q4149cfb1vecc48ca3d8d82b35@mail.gmail.com> Message-ID: <20080529225902.GA10840@hurricane.linuxnetz.de> On Thu, 29 May 2008, G wrote: > specifiy whats the enhnacement is about. I did notice that there are > some bug fixes too made which has got the word "bugfix" but does not > map to a Bug ID i.e, the Bug ID is not mentioned in the updates. It I am using "bugfix" also if the package fixes an upstream bug or multiple of them and I surely won't open a bug report to myself to clone the maybe or maybe not existing upstream bug report. If upstream says, the release is a bugfix release, I'm marking as such. And if I've a bug report in Red Hat Bugzilla to it, I'll mention it, if there's none, it's not my problem. IMHO, you first should make the possibility to reference to upstream bug tracking tools and hey, there is a DESCRIPTION field as well which can be used to put information into. You don't always need a fscking bug report - sorry ;-) Sorry, but I'm pissed off by bodhi, because pushing e.g. security updates takes sometimes very long or same for feature updates. This was also in some discussion with Paul W. Frields here around LinuxTag as a problem for us as packagers. Maybe we can get rid of the REAL problems first before messing around with possible "features". Thank you. Greetings, Robert From a.badger at gmail.com Fri May 30 04:17:30 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 29 May 2008 21:17:30 -0700 Subject: Let's make a plan for python3.0 in Fedora 10+ Message-ID: <483F7FDA.9000701@gmail.com> The python programming language is going to be releasing a new version sometime around the time of the Fedora 10 release. Unlike past releases, this one will have wide-spread backwards incompatibility in the python language itself. We need to think about how we want to pull the new language into the distribution and porting of existing apps/modules. Here's a proposal to start us off but I hope geppetto (the python maintainer) and ivazquez (who maintains python3.0 packages in his spare time[1]_) will weigh in with their thoughts. .. _[1]: http://ivazquez.fedorapeople.org/packages/python3000/ == Proposal == * We should review and add the python3000 package to Fedora devel ASAP so people can work out any bugs with the packaging before F10 release. * python3000 will not be in the default install for F10. It should not conflict in any way with the python-2.x package we ship. We should not port our system tools (system-config-*, anaconda, yum, etc) to python3000 for F10. * In F10 modules should not be shipped for python3000 unless upstream is taking patches for python3000/has a python3000 compatible release branch. * python3000 modules should have a separate namespace from python2.x modules. The packaging committee will need to decide on that (python3-foo, python3000-foo, python3k-foo are possibilities. python3.0-foo should not be considered as 3.x versions should not have the same backwards incompatibilities that 2.x->3.x has.) * Porting to python3000 will occur at some point but that should be a post-Fedora 10 feature that we decide on after python-3.0 final has been released. We will also need to discuss whether to port our tools piecemeal or altogether at that time and to what extent (if any) we will allow splitting from any upstreams that only support python-2.x. == Rationale and Notes == * python3000 is backwards incompatible with python2.x. Unicode strings, print becoming a function, exception changes, removal of old-style classes, and many other changes will prevent nearly all python2.x programs and modules from functioning in python3000 without source code changes. In this way, it is practically a new language. * Porting to python3.0 as a whole distro will take a significant amount of time. Being able to break that up and work with upstreams to port smaller portions at a time will aid us in focusing effort where it's needed. * python2.6.x will be with us for a long time as Guido has said it will be supported for a much longer time than the 2.n=>2.n+1 series. However, that doesn't mean that the 3rd party modules we depend on will be supported on both 2.x and 3.x. * Working with upstream module authors on these ports will be extremely important. There are likely to be upstreams that want to support only python-2.x or both python-2.x and python3000 for a while. There are tools to help port from 2.x to 3.x but without upstream to be a point of distribution for the resulting work we'd bear the burden of maintaining a fork which we definitely don't want to do. * Timeline: Sep 03 2008: Python 2.6 and 3.0 final [2]_ * Overview of changes http://docs.python.org/dev/3.0/whatsnew/3.0.html .. _[2]: http://www.python.org/dev/peps/pep-0361/ -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From tibbs at math.uh.edu Fri May 30 04:21:57 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 29 May 2008 23:21:57 -0500 Subject: f9: x86_64: Missing C++ runtime support for g++ (/usr/bin/g++). In-Reply-To: <1212100638.3581.9.camel@lesca.home.solinos.it> References: <1212100638.3581.9.camel@lesca.home.solinos.it> Message-ID: >>>>> "DL" == Dario Lesca writes: DL> Hi, I try to rebuild hylafax on F9/x86_64, I have installer this DL> package: Well, probably easier to build the package under review, which fixed many issues including the gcc 4.3 incompatibility. https://bugzilla.redhat.com//show_bug.cgi?id=188542 Try the package from comment 83. - J< From seg at haxxed.com Fri May 30 04:37:17 2008 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 29 May 2008 23:37:17 -0500 Subject: Rosegarden maintenance, also moving. Message-ID: <1218b5bc0805292137v1aa11347gf18845d6079643ab@mail.gmail.com> Rosegarden really deserves better maintenance than I've been giving it lately. I need co-maintainers. And if say, there's someone who actually follows upstream development who wants to take over as primary maintainer, that would be fine by me. I just package the thing. :) Audio SIG people should co-maintain, and it's also a QT/KDE app so KDE SIG people should probably keep an eye on it too. There's some open bugs that really ought to be pushed upstream... Also, I'm currently in the middle of a rather messy move to a new apartment so all my stuff is packed up, I'm not going to be able to do any package maintance for the next month or so. If there's any pressing issues with any of my other packages feel free to take care of them. None of my packages should have ACLs on them. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fdinitto at redhat.com Fri May 30 04:46:54 2008 From: fdinitto at redhat.com (Fabio M. Di Nitto) Date: Fri, 30 May 2008 06:46:54 +0200 Subject: problem building packages for F-9 updates Message-ID: <1212122814.26342.24.camel@diapolon.int.fabbione.net> Hi guys, i am sure this has been discussed in the past, but google isn't help me today. I am preparing an update for cman that requires an updated BR version of openais. openais has been updated and built on koji but not submitted to bodhi since the packages needs to go in all at the same time to work properly. The problem is very simple.. koji doesn't use the new openais version so cman simply fails to build. What is the right procedure/way to handle this situation? Thanks Fabio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From denis at poolshark.org Fri May 30 04:46:32 2008 From: denis at poolshark.org (Denis Leroy) Date: Fri, 30 May 2008 06:46:32 +0200 Subject: Orphaning my Packages (or: RIP, Fedora!) In-Reply-To: <483B8450.6070505@theholbrooks.org> References: <483B8450.6070505@theholbrooks.org> Message-ID: <483F86A8.2000907@poolshark.org> Brandon Holbrook wrote: [cut] > Denis Leroy said throughout this process that such a blanket policy was > shortsighted, would hurt Fedora more than it helped, and drive people > away to other distros. He was right, I'm one of those people. Good > luck clinging to your "principles", Fedora, and farewell. > -Brandon Ok. While I do indeed think that open-vm-tools makes a pretty good case to argue that Fedora's kernel module policy is inadequate, Brandon I think you're overreacting by leaving the community over this. I doubt there are many fedora contributors that agree with every bits of policies we have in place, but that doesn't mean we lose sleep over it :-) -denis From konrad at tylerc.org Fri May 30 04:54:33 2008 From: konrad at tylerc.org (Konrad Meyer) Date: Thu, 29 May 2008 21:54:33 -0700 Subject: problem building packages for F-9 updates In-Reply-To: <1212122814.26342.24.camel@diapolon.int.fabbione.net> References: <1212122814.26342.24.camel@diapolon.int.fabbione.net> Message-ID: <200805292154.33800.konrad@tylerc.org> Quoth Fabio M. Di Nitto: > Hi guys, > > i am sure this has been discussed in the past, but google isn't help me > today. > > I am preparing an update for cman that requires an updated BR version of > openais. > > openais has been updated and built on koji but not submitted to bodhi > since the packages needs to go in all at the same time to work properly. > > The problem is very simple.. koji doesn't use the new openais version so > cman simply fails to build. > > What is the right procedure/way to handle this situation? > > Thanks > Fabio Send a request to releng asking for override tags on the version(s) of openais that you need. -- Conrad Meyer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From fdinitto at redhat.com Fri May 30 05:02:28 2008 From: fdinitto at redhat.com (Fabio M. Di Nitto) Date: Fri, 30 May 2008 07:02:28 +0200 Subject: problem building packages for F-9 updates In-Reply-To: <200805292154.33800.konrad@tylerc.org> References: <1212122814.26342.24.camel@diapolon.int.fabbione.net> <200805292154.33800.konrad@tylerc.org> Message-ID: <1212123748.26342.28.camel@diapolon.int.fabbione.net> On Thu, 2008-05-29 at 21:54 -0700, Konrad Meyer wrote: > > Send a request to releng asking for override tags on the version(s) of openais > that you need. Thanks for the extremely quick answer! Fabio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From Fedora at FamilleCollet.com Fri May 30 05:06:55 2008 From: Fedora at FamilleCollet.com (Remi Collet) Date: Fri, 30 May 2008 07:06:55 +0200 Subject: Orphaning my Packages (or: RIP, Fedora!) In-Reply-To: References: <483B8450.6070505@theholbrooks.org> <20080527225835.GA12180@hurricane.linuxnetz.de> Message-ID: <483F8B6F.8050109@FamilleCollet.com> Prateek Singh a ?crit : > > I can take ownership of this php related package (as/with a co-maintener > > if someone else want) I've already take ownership > > I would be happy to co-maintain the packages. No problem, request it in pkgbd. Remi. From Fedora at FamilleCollet.com Fri May 30 05:10:00 2008 From: Fedora at FamilleCollet.com (Remi Collet) Date: Fri, 30 May 2008 07:10:00 +0200 Subject: Orphaning my Packages (or: RIP, Fedora!) In-Reply-To: <20080527225835.GA12180@hurricane.linuxnetz.de> References: <483B8450.6070505@theholbrooks.org> <20080527225835.GA12180@hurricane.linuxnetz.de> Message-ID: <483F8C28.6020301@FamilleCollet.com> Robert Scheck a ?crit : > I would take it on all branches, if nobody cares or want's it explicitly - > Remi, how much do you care about it? Please let me know, if somebody want's > it explicitly, otherwise I would take care of it end of the week or maybe > next week (I'm currently on LinuxTag in Berlin). > I"ve already take it You can add you in pkgdb or ask me to release the ownership it if you really want to be the primary maintener. Remi. > > Greetings, > Robert > From choeger at cs.tu-berlin.de Fri May 30 08:33:43 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Fri, 30 May 2008 10:33:43 +0200 Subject: no updates? Message-ID: <1212136423.2425.21.camel@choeger6> Hi, since some days I get absolutely no updates. Under bodhi I can see (just a simple example) gstreamer-plugins-base-0.10.19-2.fc9 on my system there is [choeger at choeger6 svn]$ rpm -q gstreamer-plugins-base gstreamer-plugins-base-0.10.19-1.fc9.i386 and yum says: no packages found. I assume that goes for a lot of packages (including yum, gedit and others I've had a look at). What went wrong? regards christoph -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From valent.turkovic at gmail.com Fri May 30 08:54:04 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Fri, 30 May 2008 10:54:04 +0200 Subject: Networkmanager service is shutdown too early Message-ID: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> During the boot I have some samba shares mounted because I have them configured to mount via fstab file. When I shutdown or reboot I get a screen for 2-3 minutes that shows smbfs service trying to unmount samba shares but NM service has already shutdown and there is no working network connection :( I have seen this "bad" behaviour in F8 and have reported it on this mailinglist, but I hoped that the new and smarter NM would take care of it, but unfortunately it didn't :( So: https://bugzilla.redhat.com/show_bug.cgi?id=449070 Cheers, Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From mschwendt at gmail.com Fri May 30 09:32:26 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Fri, 30 May 2008 11:32:26 +0200 Subject: no updates? In-Reply-To: <1212136423.2425.21.camel@choeger6> References: <1212136423.2425.21.camel@choeger6> Message-ID: <20080530113226.bfa82b4c.mschwendt@gmail.com> On Fri, 30 May 2008 10:33:43 +0200, Christoph H?ger wrote: > Hi, Wrong list? You seem to refer to F9 => fedora-list not fedora-devel-list. > since some days I get absolutely no updates. Are they available on your favourite mirror already? Or do you use the mirrorlist? > Under bodhi I can see (just a simple example) > gstreamer-plugins-base-0.10.19-2.fc9 That's a very recent update, which takes time to travel to all mirrors. > and yum says: no packages found. > > I assume that goes for a lot of packages (including yum, gedit and > others I've had a look at). > > What went wrong? "yum clean metadata", then try again. Alternatively, disable mirrorlist and pick a nearby mirror, which is up-to-date often and sooner than arbitrary mirrors on mirrorlist. -- Fedora release 8 (Werewolf) - Linux 2.6.23.15-137.fc8 loadavg: 1.64 1.27 1.16 From billcrawford1970 at gmail.com Fri May 30 10:01:18 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Fri, 30 May 2008 11:01:18 +0100 Subject: Suggestion with respect to the Fedora Update System In-Reply-To: <604aa7910805291328w6ed7f0c0if92959341c4cf0e2@mail.gmail.com> References: <6dd1343e0805290133q4149cfb1vecc48ca3d8d82b35@mail.gmail.com> <604aa7910805291328w6ed7f0c0if92959341c4cf0e2@mail.gmail.com> Message-ID: <544eb990805300301s33a0b65bkd9fcd2d8f7426c54@mail.gmail.com> 2008/5/29 Jeff Spaleta : > Or to put it another way...with updates-testing enabled I don't easily > know which packages are from updates-testing without making special > effort to determine it. You know yum will tell you? [root at bill ~]# yum --enablerepo updates-testing list updates adobe-linux-i386 100% |=========================| 951 B 00:00 updates-testing 100% |=========================| 2.3 kB 00:00 primary.sqlite.bz2 100% |=========================| 408 kB 00:00 updates 100% |=========================| 2.3 kB 00:00 primary.sqlite.bz2 100% |=========================| 2.9 MB 00:02 freshrpms 100% |=========================| 2.4 kB 00:00 fedora 100% |=========================| 2.1 kB 00:00 Updated Packages bind-libs.i386 32:9.5.0-27.rc1.fc8 updates-testing bind-utils.i386 32:9.5.0-27.rc1.fc8 updates-testing dbus-glib.i386 0.73-8.fc8 updates-testing [ and so on ... ] From ivazqueznet at gmail.com Fri May 30 10:05:04 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Fri, 30 May 2008 06:05:04 -0400 Subject: Suggestion with respect to the Fedora Update System In-Reply-To: <544eb990805300301s33a0b65bkd9fcd2d8f7426c54@mail.gmail.com> References: <6dd1343e0805290133q4149cfb1vecc48ca3d8d82b35@mail.gmail.com> <604aa7910805291328w6ed7f0c0if92959341c4cf0e2@mail.gmail.com> <544eb990805300301s33a0b65bkd9fcd2d8f7426c54@mail.gmail.com> Message-ID: <1212141904.4081.129.camel@ignacio.lan> On Fri, 2008-05-30 at 11:01 +0100, Bill Crawford wrote: > 2008/5/29 Jeff Spaleta : > > > Or to put it another way...with updates-testing enabled I don't easily > > know which packages are from updates-testing without making special > > effort to determine it. > > You know yum will tell you? > > [root at bill ~]# yum --enablerepo updates-testing list updates That doesn't help once they're installed. Only bodhi (and verifying the signatures) can tell you. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ivazqueznet at gmail.com Fri May 30 10:10:11 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Fri, 30 May 2008 06:10:11 -0400 Subject: Let's make a plan for python3.0 in Fedora 10+ In-Reply-To: <483F7FDA.9000701@gmail.com> References: <483F7FDA.9000701@gmail.com> Message-ID: <1212142211.4081.131.camel@ignacio.lan> On Thu, 2008-05-29 at 21:17 -0700, Toshio Kuratomi wrote: > The python programming language is going to be releasing a new version > sometime around the time of the Fedora 10 release. Unlike past > releases, this one will have wide-spread backwards incompatibility in > the python language itself. We need to think about how we want to pull > the new language into the distribution and porting of existing > apps/modules. Here's a proposal to start us off but I hope geppetto > (the python maintainer) and ivazquez (who maintains python3.0 packages > in his spare time[1]_) will weigh in with their thoughts. > > .. _[1]: http://ivazquez.fedorapeople.org/packages/python3000/ > > == Proposal == > > * We should review and add the python3000 package to Fedora devel ASAP > so people can work out any bugs with the packaging before F10 release. Agreed... but I'm obviously biased ;) > * python3000 will not be in the default install for F10. It should not > conflict in any way with the python-2.x package we ship. We should not > port our system tools (system-config-*, anaconda, yum, etc) to > python3000 for F10. Agreed. Instead, we should work on porting them to at least 2.6 (if not 3.0 outright) for F11. > * In F10 modules should not be shipped for python3000 unless upstream is > taking patches for python3000/has a python3000 compatible release branch. Agreed. We don't want the burden of maintenance. > * python3000 modules should have a separate namespace from python2.x > modules. The packaging committee will need to decide on that > (python3-foo, python3000-foo, python3k-foo are possibilities. > python3.0-foo should not be considered as 3.x versions should not have > the same backwards incompatibilities that 2.x->3.x has.) Agreed. I started using "python3000-" myself, but I'm flexible. > == Rationale and Notes == > > * python3000 is backwards incompatible with python2.x. Unicode strings, > print becoming a function, exception changes, removal of old-style > classes, and many other changes will prevent nearly all python2.x > programs and modules from functioning in python3000 without source code > changes. In this way, it is practically a new language. To be clear, it will be incompatible with Python 2.5 or earlier. Python 2.6[1] is a way station between 2.5 and 3.0, and can be used to help any porting efforts. [1] http://docs.python.org/dev/whatsnew/2.6.html -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rawhide at fedoraproject.org Fri May 30 10:16:30 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Fri, 30 May 2008 10:16:30 +0000 (UTC) Subject: rawhide report: 20080530 changes Message-ID: <20080530101630.A93D2209CC4@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080529/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080530/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package libgphoto2 Library for accessing digital cameras New package perl-Encode-Detect Encode::Encoding subclass that detects the encoding of data Updated Packages: PackageKit-0.2.2-2.20080529.fc10 -------------------------------- * Thu May 29 18:00:00 2008 Richard Hughes - 0.2.2-2.20080529 - Pull in a new snapshot from the unstable branch. a2ps-4.14-5.fc10 ---------------- * Thu May 29 18:00:00 2008 Tim Waugh 4.14-5 - Removed old patches. adns-1.4-4.fc10 --------------- * Thu May 29 18:00:00 2008 Dennis Gilmore - 1.4-4 - some arches need -fPIC am-utils-6.1.5-10.fc10 ---------------------- * Thu May 29 18:00:00 2008 Karel Zak 5:6.1.5-10 - fix #435420 - CVE-2008-1078 am-utils: insecure usage of temporary files anaconda-11.4.1.2-1 ------------------- * Thu May 29 18:00:00 2008 Chris Lumens - 11.4.1.2-1 - Allow ext4 migration again for testing at least (katzj) - Remount filesystems after migration (#440055) (katzj) - Add blkid to the keepfiles list so jkeating will whine less (pjones) - Don't allow vfat /boot (katzj) - Use the base yum doConfigSetup method. (clumens) - Include the yum repo files from fedora-release in stage2. (clumens) - No longer maintain our own list of extra repos. (clumens) - Sort the repos in the UI. (clumens) - Add cost, includepkgs, and excludepkgs to the ks repo objects (#448501). (clumens) - Stop pretending to support Greek text mode (#208841) (katzj) - Make it clear you need to reboot to use the installed system (#238297) (katzj) - Activate LVM for when we do meta-resizing (#441706) (katzj) - List Norweigian as Bokm??l (#437355) (katzj) - Simplify the install classes. (clumens) - Don't show the EFI filesystem unless we're on an EFI platform (katzj) - Add nfsv4 so that we don't nuke them on upgrades (#448145) (katzj) - When there are errors reading the live CD, offer a retry. (clumens) - Can't recover from buildTransaction errors on a per-repo basis (#447796). (clumens) - Set default partition size to 200 MB in the custom partitioning UI. (clumens) - Limit the size of things in exception dumps to 1k. (clumens) - Catch IOErrors one place they seem to happen most. (clumens) - Add a unique user agent for anaconda's grabbing in stage2 (katzj) - Remove text mode help support as well. (clumens) - Check for all the non-mkfs utilities required for each filesystem type. (clumens) - More partitioning error handling fixes (#446453). (clumens) - Require cracklib-python for the rootpassword screen. (notting) - Use pykickstart's deprecated versions of the xconfig and monitor classes. (clumens) - Fix tyop in upgrade migrate screen (#446363) (katzj) aspell-0.60.6-2.fc10 -------------------- * Thu May 29 18:00:00 2008 Ivana Varekova - 12:0.60.6-2 - Resolves: #447428 aspell sigserv on checking file with 0 length autobuild-applet-1.0.3-7.fc10 ----------------------------- * Thu May 29 18:00:00 2008 Tom "spot" Callaway - COPYING lies, code is actually LGPLv2+ * Thu May 29 18:00:00 2008 Daniel P. Berrange - 1.0.3-7 - COPYING is correct. Code is GPLv2+, but also re-uses the LGPLv2+ eggtrayicon module * Wed May 21 18:00:00 2008 Xavier Lamien - 1.0.3-6 - Fix license tag. bash-3.2-24.fc10 ---------------- * Wed May 28 18:00:00 2008 Roman Rakus - 3.2-24 - #217359 - use posix glob library bind-9.5.0-36.fc10 ------------------ * Thu May 29 18:00:00 2008 Adam Tkac 32:9.5.0-36 - updated to 9.5.0 final - use getifaddrs to find available interfaces blt-2.4-28.z.fc10 ----------------- * Thu May 29 18:00:00 2008 Sergio Pascual 2.4-28.z - Patched to recover blt::graph (bz #446862) coda-6.9.4-0.1.rc2.fc10 ----------------------- * Thu May 29 18:00:00 2008 Hans de Goede 6.9.4-0.1.rc2 - Update to 6.9.4~rc2 (bz 448749) crypto-utils-2.4-1 ------------------ cups-1.3.7-4.fc10 ----------------- * Thu May 29 18:00:00 2008 Tim Waugh 1:1.3.7-4 - Fix last fix (bug #447200). dovecot-1.0.13-8.fc10 --------------------- * Thu May 29 18:00:00 2008 Dan Horak - 1:1.0.13-8 - update scriptlets to follow UsersAndGroups guideline - remove support for upgrading from version < 1.0 from scriptlets - Resolves: #448095 dsniff-2.4-0.3.b1.fc10 ---------------------- * Thu May 29 18:00:00 2008 Robert Scheck 2.4-0.3.b1 - Rebuild against libnids 1.23 ejabberd-2.0.1-2.fc10 --------------------- * Thu May 29 18:00:00 2008 Peter Lemenkov 2.0.1-2 - Fixed BZ# 439583 ekg2-0.2-0.1.rc1.fc10 --------------------- * Wed May 28 18:00:00 2008 Dominik Mierzejewski 0.2-0.1.rc1 - updated to 0.2-rc1 (#435369) - fixed multiarch conflicts (#341051) - updated gcc43 patch - fixed compilation against the new glibc fedora-logos-9.0.1-1.fc10 ------------------------- * Thu May 29 18:00:00 2008 Ray Strode - 9.0.1-1 - Add logo with white type face ganyremote-3.0-1.fc10 --------------------- * Sun May 25 18:00:00 2008 Mikhail Fedotov - 3.0-1 Bugfixes and enhancements to better support anyremote-J2ME client v4.6 and anyremote2html v0.5. gcompris-8.4.5-2.fc10 --------------------- * Thu May 29 18:00:00 2008 Hans de Goede 8.4.5-2 - Fix gcompris not starting anymore (oops) (bz 448642) gnome-keyring-2.22.2-2.fc10 --------------------------- * Thu May 29 18:00:00 2008 Colin Walters - 2.22.2-2 - Add patch to nuke allow-deny dialog, see linked upstream bug for discussion gnome-packagekit-0.2.2-2.20080529.fc10 -------------------------------------- * Thu May 29 18:00:00 2008 Richard Hughes - 0.2.2-2.20080529 - Pull in a new snapshot from the unstable branch. gnome-screensaver-2.23.3-0.2008.05.29.1.fc10 -------------------------------------------- * Thu May 29 18:00:00 2008 Jon McCann - 2.23.3-0.2008.05.29.1 - Update to snapshot * Thu May 22 18:00:00 2008 Matthias Clasen - 2.23.3-0.2008.05.14.2 - Fix directory ownership (#447498) gpm-1.20.3-1.fc10 ----------------- * Thu May 29 18:00:00 2008 Zdenek Prikryl - 1.20.3-1 - Updated to 1.20.3 - Fixed init script to comply with LSB standard (#246937) - Mass patch cleanup - Fixed typo in doc (#446679) gtk-recordmydesktop-0.3.7.2-2.fc10 ---------------------------------- kdebase-workspace-4.0.80-2.fc10 ------------------------------- * Thu May 29 18:00:00 2008 Rex Dieter 4.0.80-2 - BR: libcaptury-devel kernel-2.6.26-0.44.rc4.git2.fc10 -------------------------------- * Thu May 29 18:00:00 2008 Kristian H??gsberg - Add linux-2.6-silence-x86-decompressor.patch to silence the decompressor spew when 'quiet' is passed. kernel-xen-2.6-2.6.25.2-4.fc10 ------------------------------ * Thu May 29 18:00:00 2008 Mark McLoughlin - Enable ia32 emulation (ehabkost, #437358) libpano13-2.9.12-6.fc10 ----------------------- * Thu May 29 18:00:00 2008 Bruno Postle - 2.9.12-6 - bumping to fix broken shipped binaries on F-9 libvoikko-1.7-3.fc10 -------------------- * Fri May 30 18:00:00 2008 Ville-Pekka Vainio - 1.7-3 - Add Requires pkgconfig to -devel lynx-2.8.6-16.fc10 ------------------ * Thu May 29 18:00:00 2008 Jiri Moskovcak - 2.8.6-16 - updated to latest stable version 2.8.6rel5 - Resolves: #214205 - added build patches from Dennis Gilmore - skipped 2 releases to correct the NVR path maxima-5.15.0-1.fc10 -------------------- * Wed May 28 18:00:00 2008 Rex Dieter - 5.15.0-1 - maxima-5.15.0 - omit ppc (sbcl, #448734) - omit gcl (f10+ busted, for now) - touchup scriptlets * Tue Feb 19 17:00:00 2008 Fedora Release Engineering - 5.14.0-6 - Autorebuild for GCC 4.3 * Mon Jan 28 17:00:00 2008 Rex Dieter 5.14.0-5 - respin (sbcl) net-snmp-5.4.1-17.fc10 ---------------------- * Thu May 29 18:00:00 2008 Dennis Gilmore 5.4.1-17 - fix sparc handling in /usr/include/net-snmp/net-snmp-config-sparc.h netcdf-4.0.0-0.6.beta2.fc10 --------------------------- * Thu May 29 18:00:00 2008 Balint Cristian - 4.0.0-0.6.beta2 - fix symlink to netcdf-3 numpy-1.1.0-1.fc10 ------------------ * Thu May 29 18:00:00 2008 Jarod Wilson 1.1.0-1 - New upstream release * Tue May 6 18:00:00 2008 Jarod Wilson 1.0.4-1 - New upstream release parted-1.8.8-6.fc10 ------------------- * Thu May 29 18:00:00 2008 Joel Granados - 1.8.8-6 - Do a better job at recognizing the dos partition. (#246423) perl-Class-C3-Componentised-1.0003-1.fc10 ----------------------------------------- * Wed May 28 18:00:00 2008 Chris Weyl 1.0003-1 - update to 1.0003 perl-Gnome2-VFS-1.081-1.fc10 ---------------------------- * Wed May 28 18:00:00 2008 Chris Weyl 1.081-1 - update to 1.081 perl-MRO-Compat-0.07-1.fc10 --------------------------- * Wed May 28 18:00:00 2008 Chris Weyl 0.07-1 - update to 0.07 perl-Regexp-Common-2.122-1.fc10 ------------------------------- * Thu May 29 18:00:00 2008 Tom "spot" Callaway - 2.122-1 - update to 2.122 - license change perl-WWW-Mechanize-1.34-1.fc10 ------------------------------ * Wed May 28 18:00:00 2008 Chris Weyl 1.34-1 - update to 1.34 perl-aliased-0.22-1.fc10 ------------------------ * Wed May 28 18:00:00 2008 Chris Weyl 0.22-1 - update to 0.22 pm-utils-1.1.2.2-1.fc10 ----------------------- * Thu May 29 18:00:00 2008 Richard Hughes - 1.1.2.2-1 - Update to 1.1.2.2 poker-network-1.6.0-1.fc10 -------------------------- * Thu May 29 18:00:00 2008 Christopher Stone 1.6.0-1 - Upstream sync * Sat May 24 18:00:00 2008 Christopher Stone 1.5.0-3 - Add $syslog to LSB headers on initscripts poker2d-1.6.0-1.fc10 -------------------- * Thu May 29 18:00:00 2008 Christopher Stone 1.6.0-1 - Upstream sync pulseaudio-0.9.11-0.1.svn20080529.fc10 -------------------------------------- * Thu May 29 18:00:00 2008 Lennart Poettering 0.9.11-0.0.svn20080529 - New SVN snapshot pyclutter-0.6.2-2.fc10 ---------------------- * Wed May 28 18:00:00 2008 Allisson Azevedo 0.6.2-2 - Rebuild against clutter-cairo pykickstart-1.36-1.fc10 ----------------------- * Thu May 29 18:00:00 2008 Chris Lumens - 1.36-1 - It should be repo --cost, not repo --priority. (clumens) qt-recordmydesktop-0.3.7.2-2.fc10 --------------------------------- rss-glx-0.8.1.p-20.fc10 ----------------------- * Thu May 29 18:00:00 2008 Nils Philippsen 0.8.1.p-20 - use %bcond, %with macros for consistency - don't use quotes around %fedora macro to make it work with Fedora 10 - use correct binary names for KDE (#448844) tailor-0.9.33-1.fc10 -------------------- * Thu May 29 18:00:00 2008 Dan Hor??k 0.9.33-1 - update to upstream version 0.9.33 * Mon Apr 14 18:00:00 2008 Mat??j Cepl 0.9.31-1 - update to upsteram version 0.9.31 telepathy-mission-control-4.65-2.fc10 ------------------------------------- * Thu May 29 18:00:00 2008 Sindre Pedersen Bj??rdal - 4.65-2 - Update to new upstream release (4.65) texinfo-4.12-2.fc10 ------------------- * Thu May 29 18:00:00 2008 Vitezslav Crhonek - 4.12-2 - Fix Requires and info post script yum-utils-1.1.14-4.fc10 ----------------------- * Thu May 29 18:00:00 2008 Tim Lauridsen - remove the fastestmirror-asyncore.py - And do it right this time Summary: Added Packages: 2 Removed Packages: 0 Modified Packages: 54 Broken deps for i386 ---------------------------------------------------------- LabPlot-1.5.1.6-6.fc9.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libWand.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libMagick.so.10 avahi-ui-sharp-0.6.22-10.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 avahi-ui-sharp-0.6.22-10.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 basket-kontact-1.0.2-5.fc9.i386 requires libkpinterfaces.so.1 basket-kontact-1.0.2-5.fc9.i386 requires libkcal.so.2 basket-kontact-1.0.2-5.fc9.i386 requires libktnef.so.1 basket-kontact-1.0.2-5.fc9.i386 requires kdepim3 basket-kontact-1.0.2-5.fc9.i386 requires libkdepim.so.1 beagle-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-evolution-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-thunderbird-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.i386 requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-1.2.so.11 f-spot-0.4.3.1-1.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.i386 requires mono(glade-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(atk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(glade-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(pango-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gsf-sharp-0.8.1-7.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.i386 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 kismet-extras-0.0.2007.10.R1-3.fc9.i386 requires libMagick.so.10 libopensync-plugin-kdepim-0.35-2.fc9.i386 requires libkcal.so.2 lsvpd-1.6.4-1.fc10.i386 requires libvpd_cxx-2.0.so.1 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.i386 requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.i386 requires libgeos.so.2 smart-0.52-54.fc9.i386 requires smart-config taskjuggler-2.4.1-1.fc10.i386 requires libkcal.so.2 taskjuggler-2.4.1-1.fc10.i386 requires libktnef.so.1 taskjuggler-libs-2.4.1-1.fc10.i386 requires libkcal.so.2 tomboy-0.10.1-2.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.i386 requires mono(pango-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 Broken deps for x86_64 ---------------------------------------------------------- LabPlot-1.5.1.6-6.fc9.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libWand.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libMagick.so.10 LabPlot-1.5.1.6-6.fc9.x86_64 requires libMagick++.so.10()(64bit) LabPlot-1.5.1.6-6.fc9.x86_64 requires libMagick.so.10()(64bit) LabPlot-1.5.1.6-6.fc9.x86_64 requires libWand.so.10()(64bit) avahi-ui-sharp-0.6.22-10.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 avahi-ui-sharp-0.6.22-10.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 basket-kontact-1.0.2-5.fc9.x86_64 requires libkcal.so.2()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires libkdepim.so.1()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires libktnef.so.1()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires kdepim3 basket-kontact-1.0.2-5.fc9.x86_64 requires libkpinterfaces.so.1()(64bit) beagle-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-evolution-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-thunderbird-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libWand.so.10()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) f-spot-0.4.3.1-1.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx gbrainy-0.61-5.fc9.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(atk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gsf-sharp-0.8.1-7.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 kismet-extras-0.0.2007.10.R1-3.fc9.x86_64 requires libMagick.so.10()(64bit) libopensync-plugin-kdepim-0.35-2.fc9.x86_64 requires libkcal.so.2()(64bit) lsvpd-1.6.4-1.fc10.x86_64 requires libvpd_cxx-2.0.so.1()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) smart-0.52-54.fc9.x86_64 requires smart-config taskjuggler-2.4.1-1.fc10.x86_64 requires libkcal.so.2()(64bit) taskjuggler-2.4.1-1.fc10.x86_64 requires libktnef.so.1()(64bit) taskjuggler-libs-2.4.1-1.fc10.i386 requires libkcal.so.2 taskjuggler-libs-2.4.1-1.fc10.x86_64 requires libkcal.so.2()(64bit) tomboy-0.10.1-2.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 Broken deps for ppc ---------------------------------------------------------- LabPlot-1.5.1.6-6.fc9.ppc requires libMagick++.so.10 LabPlot-1.5.1.6-6.fc9.ppc requires libWand.so.10 LabPlot-1.5.1.6-6.fc9.ppc requires libMagick.so.10 avahi-ui-sharp-0.6.22-10.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 avahi-ui-sharp-0.6.22-10.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 basket-kontact-1.0.2-5.fc9.ppc requires libkpinterfaces.so.1 basket-kontact-1.0.2-5.fc9.ppc requires libkcal.so.2 basket-kontact-1.0.2-5.fc9.ppc requires libktnef.so.1 basket-kontact-1.0.2-5.fc9.ppc requires kdepim3 basket-kontact-1.0.2-5.fc9.ppc requires libkdepim.so.1 beagle-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 beagle-evolution-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 beagle-thunderbird-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 evolution-brutus-1.2.11-2.fc9.ppc requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.ppc requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.ppc requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.ppc requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-1.2.so.11 f-spot-0.4.3.1-1.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.ppc requires mono(glade-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(atk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(glade-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(pango-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gsf-sharp-0.8.1-7.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.ppc requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 kismet-extras-0.0.2007.10.R1-3.fc9.ppc requires libMagick.so.10 libopensync-plugin-kdepim-0.35-2.fc9.ppc requires libkcal.so.2 lsvpd-1.6.4-1.fc10.ppc requires libvpd_cxx-2.0.so.1 muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.ppc requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.ppc requires libgeos.so.2 smart-0.52-54.fc9.ppc requires smart-config taskjuggler-2.4.1-1.fc10.ppc requires libkcal.so.2 taskjuggler-2.4.1-1.fc10.ppc requires libktnef.so.1 taskjuggler-libs-2.4.1-1.fc10.ppc requires libkcal.so.2 taskjuggler-libs-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) tomboy-0.10.1-2.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.ppc requires mono(pango-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 wxMaxima-0.7.4-3.fc9.ppc requires maxima >= 0:5.13 Broken deps for ppc64 ---------------------------------------------------------- basket-kontact-1.0.2-5.fc9.ppc64 requires libkcal.so.2()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires libkdepim.so.1()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires libktnef.so.1()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires kdepim3 basket-kontact-1.0.2-5.fc9.ppc64 requires libkpinterfaces.so.1()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) kismet-extras-0.0.2007.10.R1-3.fc9.ppc64 requires libMagick.so.10()(64bit) libopensync-plugin-kdepim-0.35-2.fc9.ppc64 requires libkcal.so.2()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot lsvpd-1.6.4-1.fc10.ppc64 requires libvpd_cxx-2.0.so.1()(64bit) perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) smart-0.52-54.fc9.ppc64 requires smart-config taskjuggler-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) taskjuggler-2.4.1-1.fc10.ppc64 requires libktnef.so.1()(64bit) taskjuggler-libs-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) From billcrawford1970 at gmail.com Fri May 30 10:34:26 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Fri, 30 May 2008 11:34:26 +0100 Subject: Suggestion with respect to the Fedora Update System In-Reply-To: <1212141904.4081.129.camel@ignacio.lan> References: <6dd1343e0805290133q4149cfb1vecc48ca3d8d82b35@mail.gmail.com> <604aa7910805291328w6ed7f0c0if92959341c4cf0e2@mail.gmail.com> <544eb990805300301s33a0b65bkd9fcd2d8f7426c54@mail.gmail.com> <1212141904.4081.129.camel@ignacio.lan> Message-ID: <544eb990805300334l32255e0evc776f3cfcf60bf9a@mail.gmail.com> 2008/5/30 Ignacio Vazquez-Abrams : > On Fri, 2008-05-30 at 11:01 +0100, Bill Crawford wrote: >> [root at bill ~]# yum --enablerepo updates-testing list updates > That doesn't help once they're installed. Only bodhi (and verifying the > signatures) can tell you. Oops. You're quite right. Um, maybe disabling the testing repo and running package-cleanup --orphans would help? [ answer: not necessarily; but it should then exclude stuff that's already been pushed to stable ] From skvidal at fedoraproject.org Fri May 30 12:41:10 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 30 May 2008 08:41:10 -0400 Subject: Suggestion with respect to the Fedora Update System In-Reply-To: <544eb990805300334l32255e0evc776f3cfcf60bf9a@mail.gmail.com> References: <6dd1343e0805290133q4149cfb1vecc48ca3d8d82b35@mail.gmail.com> <604aa7910805291328w6ed7f0c0if92959341c4cf0e2@mail.gmail.com> <544eb990805300301s33a0b65bkd9fcd2d8f7426c54@mail.gmail.com> <1212141904.4081.129.camel@ignacio.lan> <544eb990805300334l32255e0evc776f3cfcf60bf9a@mail.gmail.com> Message-ID: <1212151270.9616.7.camel@cutter> On Fri, 2008-05-30 at 11:34 +0100, Bill Crawford wrote: > 2008/5/30 Ignacio Vazquez-Abrams : > > On Fri, 2008-05-30 at 11:01 +0100, Bill Crawford wrote: > > >> [root at bill ~]# yum --enablerepo updates-testing list updates > > > That doesn't help once they're installed. Only bodhi (and verifying the > > signatures) can tell you. > > Oops. You're quite right. > > Um, maybe disabling the testing repo and running package-cleanup > --orphans would help? > > [ answer: not necessarily; but it should then exclude stuff that's > already been pushed to stable ] If the pkgs have been removed from updates-testing and never made it to updates you could run: yum list extras and see if they show up there. -sv From ivazqueznet at gmail.com Fri May 30 13:37:22 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Fri, 30 May 2008 09:37:22 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080522065724.1788e577@vader.jdub.homelinux.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> Message-ID: <1212154642.4081.147.camel@ignacio.lan> "...is an orthorhombic crystal." Goethite: "...is named after a poet." Curite: "...is named after a physicist." Topaz, Olivine: "...is a birthstone/gemstone." -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-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 Fri May 30 13:41:12 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 30 May 2008 09:41:12 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080522065724.1788e577@vader.jdub.homelinux.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> Message-ID: <1212154872.16130.41.camel@localhost.localdomain> On Thu, 2008-05-22 at 06:57 -0500, Josh Boyer wrote: > I will be collecting suggestions for 1 week, so the cutoff for names > is: > > May 29, 2008 > > Suggestions will be run through the legal queue and an election will > happen for Fedora contributors to pick the next Fedora name. A little added twist here. I'd like to give the Fedora Board a chance at culling the list a little bit before sending on to Legal. There were a number of names that made it through the "is a" test and Legal that might not have been the best ideas for naming a release. Add to that the fact that Red Hat has used outside Legal to do the name clearance the last few times and that is a measurable cost both in time and money. The more names we ask to clear the more expensive and longer the delay will be before we have a set to vote upon. So I am asking the Fedora Board to review the list of names that Josh has collected and remove any they deem not acceptable as a Fedora release name before handing it to Legal. (Note, I haven't yet directly talked to the board about this, so I'm just assuming that they'll be on... board... with this.) -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jwboyer at gmail.com Fri May 30 14:09:35 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 30 May 2008 09:09:35 -0500 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080530135634.GC11236@domsch.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1212154872.16130.41.camel@localhost.localdomain> <20080530135634.GC11236@domsch.com> Message-ID: <20080530090935.1878ca68@vader.jdub.homelinux.org> On Fri, 30 May 2008 08:56:34 -0500 Matt Domsch wrote: > > A little added twist here. I'd like to give the Fedora Board a chance > > at culling the list a little bit before sending on to Legal. There were > > a number of names that made it through the "is a" test and Legal that > > might not have been the best ideas for naming a release. Add to that > > the fact that Red Hat has used outside Legal to do the name clearance > > the last few times and that is a measurable cost both in time and money. > > The more names we ask to clear the more expensive and longer the delay > > will be before we have a set to vote upon. So I am asking the Fedora > > Board to review the list of names that Josh has collected and remove any > > they deem not acceptable as a Fedora release name before handing it to > > Legal. > > > > (Note, I haven't yet directly talked to the board about this, so I'm > > just assuming that they'll be on... board... with this.) > > Seems a very reasonable request. The Board doesn't want to limit > people's brainstorming, but I can see value in culling the list that's > sent out for trademark research. OK. So the current list I have is at: http://jwboyer.fedorapeople.org/ If I have missed one that follows the rules, please let me know and I'll review it and add it. I'm taking further submissions until the end of today, and then I'll send the list to the Board for culling. After that, we'll send the revised list to legal. josh From jkeating at redhat.com Fri May 30 15:08:08 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 30 May 2008 11:08:08 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1212154872.16130.41.camel@localhost.localdomain> <20080530135634.GC11236@domsch.com> <20080530090935.1878ca68@vader.jdub.homelinux.org> Message-ID: <1212160088.16130.113.camel@localhost.localdomain> On Fri, 2008-05-30 at 17:04 +0200, Max Spevack wrote: > is my recommendation. We already have "Red Hat Linux" as being defunct magazine names. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Fri May 30 15:17:23 2008 From: notting at redhat.com (Bill Nottingham) Date: Fri, 30 May 2008 11:17:23 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080530090935.1878ca68@vader.jdub.homelinux.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1212154872.16130.41.camel@localhost.localdomain> <20080530135634.GC11236@domsch.com> <20080530090935.1878ca68@vader.jdub.homelinux.org> Message-ID: <20080530151723.GC22183@nostromo.devel.redhat.com> Josh Boyer (jwboyer at gmail.com) said: > > > (Note, I haven't yet directly talked to the board about this, so I'm > > > just assuming that they'll be on... board... with this.) > > > > Seems a very reasonable request. The Board doesn't want to limit > > people's brainstorming, but I can see value in culling the list that's > > sent out for trademark research. > > OK. So the current list I have is at: > > http://jwboyer.fedorapeople.org/ > > If I have missed one that follows the rules, please let me know and > I'll review it and add it. I'm taking further submissions until the > end of today, and then I'll send the list to the Board for culling. > After that, we'll send the revised list to legal. My only suggestion is that we may want to reserve the right to ... un-cull... the list if legal only comes back with one or two approved names. Bill From gdk at redhat.com Fri May 30 16:08:18 2008 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Fri, 30 May 2008 12:08:18 -0400 (EDT) Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1212154872.16130.41.camel@localhost.localdomain> <20080530135634.GC11236@domsch.com> <20080530090935.1878ca68@vader.jdub.homelinux.org> Message-ID: On Fri, 30 May 2008, Max Spevack wrote: > On Fri, 30 May 2008, Josh Boyer wrote: > >> If I have missed one that follows the rules, please let me know and I'll >> review it and add it. > > Sulphur is a "Linux distribution name". > > "Red Hat Linux 10" is a "Linux distribution name". > > Therefore: > > Fedora 10 (Red Hat Linux 10) > > is my recommendation. +1! --g From billcrawford1970 at gmail.com Fri May 30 16:50:10 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Fri, 30 May 2008 17:50:10 +0100 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080530090935.1878ca68@vader.jdub.homelinux.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1212154872.16130.41.camel@localhost.localdomain> <20080530135634.GC11236@domsch.com> <20080530090935.1878ca68@vader.jdub.homelinux.org> Message-ID: <544eb990805300950y7799726aua5d7c5c984dc0d5b@mail.gmail.com> 2008/5/30 Josh Boyer : > OK. So the current list I have is at: > > http://jwboyer.fedorapeople.org/ > > If I have missed one that follows the rules, please let me know and > I'll review it and add it. I'm taking further submissions until the > end of today, and then I'll send the list to the Board for culling. > After that, we'll send the revised list to legal. I take it "Xenon" was excluded due to similarity to Lucy Lawless' divine warrior princess r?le? From fedora at leemhuis.info Fri May 30 16:54:14 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 30 May 2008 18:54:14 +0200 Subject: Fedora Org Clarity Attempt In-Reply-To: <483EF4A8.5040300@redhat.com> References: <483EF4A8.5040300@redhat.com> Message-ID: <48403136.7060005@leemhuis.info> On 29.05.2008 20:23, John Poelstra wrote: > Watching the FESCo meeting today a lot of things were not clear, but one > thing that stood out too me is that that we really don't have is a clear > picture or agreement on what the "Fedora Org" looks like and and how it > is supposed to work. [...] FYI, during the Core and Extras merge there was a longer discussion about this topic and there were even some pictures ;-) See for example: https://www.redhat.com/archives/fedora-advisory-board/2007-January/msg00129.html Maybe that stuff is a bit of a help for you work now. Cu knurd From jkeating at redhat.com Fri May 30 16:59:59 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 30 May 2008 12:59:59 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <544eb990805300950y7799726aua5d7c5c984dc0d5b@mail.gmail.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1212154872.16130.41.camel@localhost.localdomain> <20080530135634.GC11236@domsch.com> <20080530090935.1878ca68@vader.jdub.homelinux.org> <544eb990805300950y7799726aua5d7c5c984dc0d5b@mail.gmail.com> Message-ID: <1212166799.16130.126.camel@localhost.localdomain> On Fri, 2008-05-30 at 17:50 +0100, Bill Crawford wrote: > I take it "Xenon" was excluded due to similarity to Lucy Lawless' > divine warrior princess r?le? If not that, the fact that it was used as a CPU code name is probably ab bit too close for trademark comfort. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From gnomeuser at gmail.com Fri May 30 17:00:18 2008 From: gnomeuser at gmail.com (David Nielsen) Date: Fri, 30 May 2008 19:00:18 +0200 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <544eb990805300950y7799726aua5d7c5c984dc0d5b@mail.gmail.com> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1212154872.16130.41.camel@localhost.localdomain> <20080530135634.GC11236@domsch.com> <20080530090935.1878ca68@vader.jdub.homelinux.org> <544eb990805300950y7799726aua5d7c5c984dc0d5b@mail.gmail.com> Message-ID: <1dedbbfc0805301000s1d317f69odc4a027607f33676@mail.gmail.com> 2008/5/30 Bill Crawford : > 2008/5/30 Josh Boyer : > > > OK. So the current list I have is at: > > > > http://jwboyer.fedorapeople.org/ > > > > If I have missed one that follows the rules, please let me know and > > I'll review it and add it. I'm taking further submissions until the > > end of today, and then I'll send the list to the Board for culling. > > After that, we'll send the revised list to legal. > > I take it "Xenon" was excluded due to similarity to Lucy Lawless' > divine warrior princess r?le? > It's a common name in the IT industry, e.g. that used to be a game by that name back when I was a kid (late 80's). It's also the name of the XBOX360 CPU as well as the codename for that platform. Just to mention a few.. basically a problematic name. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcbw at redhat.com Fri May 30 17:32:07 2008 From: dcbw at redhat.com (Dan Williams) Date: Fri, 30 May 2008 13:32:07 -0400 Subject: Networkmanager service is shutdown too early In-Reply-To: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> Message-ID: <1212168727.8178.13.camel@localhost.localdomain> On Fri, 2008-05-30 at 10:54 +0200, Valent Turkovic wrote: > During the boot I have some samba shares mounted because I have them > configured to mount via fstab file. > > When I shutdown or reboot I get a screen for 2-3 minutes that shows > smbfs service trying to unmount samba shares but NM service has > already shutdown and there is no working network connection :( > > I have seen this "bad" behaviour in F8 and have reported it on this > mailinglist, but I hoped that the new and smarter NM would take care > of it, but unfortunately it didn't :( Probably need to adjust the stop priorities of NM and haldaemon to be right after messagebus (K85) rather than where they currently are... The problem is that NM is being stopped to early. Dan From notting at redhat.com Fri May 30 17:41:06 2008 From: notting at redhat.com (Bill Nottingham) Date: Fri, 30 May 2008 13:41:06 -0400 Subject: Networkmanager service is shutdown too early In-Reply-To: <1212168727.8178.13.camel@localhost.localdomain> References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <1212168727.8178.13.camel@localhost.localdomain> Message-ID: <20080530174106.GE30687@nostromo.devel.redhat.com> Dan Williams (dcbw at redhat.com) said: > On Fri, 2008-05-30 at 10:54 +0200, Valent Turkovic wrote: > > During the boot I have some samba shares mounted because I have them > > configured to mount via fstab file. > > > > When I shutdown or reboot I get a screen for 2-3 minutes that shows > > smbfs service trying to unmount samba shares but NM service has > > already shutdown and there is no working network connection :( > > > > I have seen this "bad" behaviour in F8 and have reported it on this > > mailinglist, but I hoped that the new and smarter NM would take care > > of it, but unfortunately it didn't :( > > Probably need to adjust the stop priorities of NM and haldaemon to be > right after messagebus (K85) rather than where they currently are... > The problem is that NM is being stopped to early. 'After netfs' should be good enough. Although netfs stop should possibly do lazy umounts. Bill From dcbw at redhat.com Fri May 30 17:46:42 2008 From: dcbw at redhat.com (Dan Williams) Date: Fri, 30 May 2008 13:46:42 -0400 Subject: Networkmanager service is shutdown too early In-Reply-To: <20080530174106.GE30687@nostromo.devel.redhat.com> References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <1212168727.8178.13.camel@localhost.localdomain> <20080530174106.GE30687@nostromo.devel.redhat.com> Message-ID: <1212169602.8178.22.camel@localhost.localdomain> On Fri, 2008-05-30 at 13:41 -0400, Bill Nottingham wrote: > Dan Williams (dcbw at redhat.com) said: > > On Fri, 2008-05-30 at 10:54 +0200, Valent Turkovic wrote: > > > During the boot I have some samba shares mounted because I have them > > > configured to mount via fstab file. > > > > > > When I shutdown or reboot I get a screen for 2-3 minutes that shows > > > smbfs service trying to unmount samba shares but NM service has > > > already shutdown and there is no working network connection :( > > > > > > I have seen this "bad" behaviour in F8 and have reported it on this > > > mailinglist, but I hoped that the new and smarter NM would take care > > > of it, but unfortunately it didn't :( > > > > Probably need to adjust the stop priorities of NM and haldaemon to be > > right after messagebus (K85) rather than where they currently are... > > The problem is that NM is being stopped to early. > > 'After netfs' should be good enough. Although netfs stop should possibly > do lazy umounts. Ok, just need to bump NM a few bits later it looks like; might as well be K84 to be right after messagebus. Dan From notting at redhat.com Fri May 30 17:59:14 2008 From: notting at redhat.com (Bill Nottingham) Date: Fri, 30 May 2008 13:59:14 -0400 Subject: Networkmanager service is shutdown too early In-Reply-To: <1212169602.8178.22.camel@localhost.localdomain> References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <1212168727.8178.13.camel@localhost.localdomain> <20080530174106.GE30687@nostromo.devel.redhat.com> <1212169602.8178.22.camel@localhost.localdomain> Message-ID: <20080530175914.GF30687@nostromo.devel.redhat.com> Dan Williams (dcbw at redhat.com) said: > > 'After netfs' should be good enough. Although netfs stop should possibly > > do lazy umounts. > > Ok, just need to bump NM a few bits later it looks like; might as well > be K84 to be right after messagebus. Well, NM will exit anyway when the messagebus exits, will it not? Bill From jspaleta at gmail.com Fri May 30 18:07:12 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 30 May 2008 10:07:12 -0800 Subject: Suggestion with respect to the Fedora Update System In-Reply-To: <544eb990805300334l32255e0evc776f3cfcf60bf9a@mail.gmail.com> References: <6dd1343e0805290133q4149cfb1vecc48ca3d8d82b35@mail.gmail.com> <604aa7910805291328w6ed7f0c0if92959341c4cf0e2@mail.gmail.com> <544eb990805300301s33a0b65bkd9fcd2d8f7426c54@mail.gmail.com> <1212141904.4081.129.camel@ignacio.lan> <544eb990805300334l32255e0evc776f3cfcf60bf9a@mail.gmail.com> Message-ID: <604aa7910805301107k55bcafe4ve8d37844809b514f@mail.gmail.com> On Fri, May 30, 2008 at 2:34 AM, Bill Crawford wrote: > Um, maybe disabling the testing repo and running package-cleanup > --orphans would help? > > [ answer: not necessarily; but it should then exclude stuff that's > already been pushed to stable ] I am reasonable clued in on how to heuristically figure out what I am running for testing. Trying to out pedantic me is a losing proposition, and utterly not the point I trying to make. If we want a noticable uptick in the number of people using bodhi, we need to drive the necessarily information to interact with bodhi into the default UI. There is a substantial lack of 'timely' communication to our users regarding our desire to have them interact with bodhi. We fail at communicating a consistent message. If we want to see the karma system really used, we'll need to encourage people to use updates-testing and have an easy way for people to know that we desire their feedback on the packagins installed from updates-testing. Only the rarest of people are going to really enjoy crafting special scripted queries with yum or repoquery with magic incantations on the cmdline. And these are the same breed of people who are going to attempt to crack bodhi's capcha system so they can script a karma bump because they in fact loath any and all graphical interface approach and would prefer that all activity could be non-interactively scripted on system whose only user application not run from cron is vi. In fact I could already be working on that. -jef"2 hours into a 30 hour trip from Fairbanks,US to Sydney,AU."spaleta From choeger at cs.tu-berlin.de Fri May 30 18:10:24 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Fri, 30 May 2008 20:10:24 +0200 Subject: no updates?no updates In-Reply-To: <20080530113226.bfa82b4c.mschwendt@gmail.com> References: <1212136423.2425.21.camel@choeger6> <20080530113226.bfa82b4c.mschwendt@gmail.com> Message-ID: <1212171024.3093.1.camel@choeger6> Am Freitag, den 30.05.2008, 11:32 +0200 schrieb Michael Schwendt: > On Fri, 30 May 2008 10:33:43 +0200, Christoph H?ger wrote: > > > Hi, > > Wrong list? You seem to refer to F9 => fedora-list not > fedora-devel-list. Ah sorry, evolutions autocompletion got me, "fedora" was resolved to fedora-devel. I should have a look at that feature. > > > since some days I get absolutely no updates. > > Are they available on your favourite mirror already? > Or do you use the mirrorlist? That was the mirrorlist. > > > Under bodhi I can see (just a simple example) > > gstreamer-plugins-base-0.10.19-2.fc9 > > That's a very recent update, which takes time to travel to all mirrors. > > > and yum says: no packages found. > > > > I assume that goes for a lot of packages (including yum, gedit and > > others I've had a look at). > > > > What went wrong? > > "yum clean metadata", then try again. Alternatively, disable > mirrorlist and pick a nearby mirror, which is up-to-date often > and sooner than arbitrary mirrors on mirrorlist. > > -- > Fedora release 8 (Werewolf) - Linux 2.6.23.15-137.fc8 > loadavg: 1.64 1.27 1.16 > yum clean metadata and _then_ yum clean all did the trick. I have no idea why yum clean all did not work before. Thank you anyway! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From dcbw at redhat.com Fri May 30 18:24:39 2008 From: dcbw at redhat.com (Dan Williams) Date: Fri, 30 May 2008 14:24:39 -0400 Subject: Networkmanager service is shutdown too early In-Reply-To: <20080530175914.GF30687@nostromo.devel.redhat.com> References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <1212168727.8178.13.camel@localhost.localdomain> <20080530174106.GE30687@nostromo.devel.redhat.com> <1212169602.8178.22.camel@localhost.localdomain> <20080530175914.GF30687@nostromo.devel.redhat.com> Message-ID: <1212171879.8178.56.camel@localhost.localdomain> On Fri, 2008-05-30 at 13:59 -0400, Bill Nottingham wrote: > Dan Williams (dcbw at redhat.com) said: > > > 'After netfs' should be good enough. Although netfs stop should possibly > > > do lazy umounts. > > > > Ok, just need to bump NM a few bits later it looks like; might as well > > be K84 to be right after messagebus. > > Well, NM will exit anyway when the messagebus exits, will it not? No, because the Debian guys got all cranky and want NM to handle dbus dropouts, because if they need to restart dbus because of a security issue they don't want that to take down the entire machine including networking. So there's code to poll the bus every so often and try to reconnect if NM gets disconnected (either due to an NM error like sending a non-UTF8 string over the bus or if dbus quits/dies). Dan From mschwendt at gmail.com Fri May 30 18:33:00 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Fri, 30 May 2008 20:33:00 +0200 Subject: no updates?no updates In-Reply-To: <1212171024.3093.1.camel@choeger6> References: <1212136423.2425.21.camel@choeger6> <20080530113226.bfa82b4c.mschwendt@gmail.com> <1212171024.3093.1.camel@choeger6> Message-ID: <20080530203300.deebe9a6.mschwendt@gmail.com> On Fri, 30 May 2008 20:10:24 +0200, Christoph H?ger wrote: > > "yum clean metadata", then try again. Alternatively, disable > > mirrorlist and pick a nearby mirror, which is up-to-date often > > and sooner than arbitrary mirrors on mirrorlist. > > yum clean metadata and _then_ yum clean all did the trick. I have no > idea why yum clean all did not work before. Coincidence. :) "clean all" includes "clean metadata" (see "man yum"), but is not needed. It is enough to purge metadata and retry till mirrorlist points you to an up-to-date mirror. You just deleted all downloaded/cached packages instead of just the metadata files. From k.georgiou at imperial.ac.uk Fri May 30 18:47:39 2008 From: k.georgiou at imperial.ac.uk (Kostas Georgiou) Date: Fri, 30 May 2008 19:47:39 +0100 Subject: Networkmanager service is shutdown too early In-Reply-To: <1212169602.8178.22.camel@localhost.localdomain> References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <1212168727.8178.13.camel@localhost.localdomain> <20080530174106.GE30687@nostromo.devel.redhat.com> <1212169602.8178.22.camel@localhost.localdomain> Message-ID: <20080530184739.GA2473@imperial.ac.uk> On Fri, May 30, 2008 at 01:46:42PM -0400, Dan Williams wrote: > On Fri, 2008-05-30 at 13:41 -0400, Bill Nottingham wrote: > > Dan Williams (dcbw at redhat.com) said: > > > On Fri, 2008-05-30 at 10:54 +0200, Valent Turkovic wrote: > > > > During the boot I have some samba shares mounted because I have them > > > > configured to mount via fstab file. > > > > > > > > When I shutdown or reboot I get a screen for 2-3 minutes that shows > > > > smbfs service trying to unmount samba shares but NM service has > > > > already shutdown and there is no working network connection :( > > > > > > > > I have seen this "bad" behaviour in F8 and have reported it on this > > > > mailinglist, but I hoped that the new and smarter NM would take care > > > > of it, but unfortunately it didn't :( > > > > > > Probably need to adjust the stop priorities of NM and haldaemon to be > > > right after messagebus (K85) rather than where they currently are... > > > The problem is that NM is being stopped to early. > > > > 'After netfs' should be good enough. Although netfs stop should possibly > > do lazy umounts. > > Ok, just need to bump NM a few bits later it looks like; might as well > be K84 to be right after messagebus. Why not go all the way to 90 as network to be on the safe side? With a quick look I can see some scripts that might not be happy if the network is down with a priority above 84, racoon/dund/rdisc/rpcgssd/nasd for example. Kostas From walters at verbum.org Fri May 30 18:50:57 2008 From: walters at verbum.org (Colin Walters) Date: Fri, 30 May 2008 14:50:57 -0400 Subject: Networkmanager service is shutdown too early In-Reply-To: <1212171879.8178.56.camel@localhost.localdomain> References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <1212168727.8178.13.camel@localhost.localdomain> <20080530174106.GE30687@nostromo.devel.redhat.com> <1212169602.8178.22.camel@localhost.localdomain> <20080530175914.GF30687@nostromo.devel.redhat.com> <1212171879.8178.56.camel@localhost.localdomain> Message-ID: On Fri, May 30, 2008 at 2:24 PM, Dan Williams wrote: > On Fri, 2008-05-30 at 13:59 -0400, Bill Nottingham wrote: > > Dan Williams (dcbw at redhat.com) said: > > > > 'After netfs' should be good enough. Although netfs stop should > possibly > > > > do lazy umounts. > > > > > > Ok, just need to bump NM a few bits later it looks like; might as well > > > be K84 to be right after messagebus. > > > > Well, NM will exit anyway when the messagebus exits, will it not? > Another simple solution is to not have a shutdown script at all. Just let NM get killed by the global kill -9 before filesystem unmounts. (which is what we should do for pretty much all services with the exception of MySQL/Postgres basically too) -------------- next part -------------- An HTML attachment was scrubbed... URL: From clydekunkel7734 at cox.net Fri May 30 18:50:53 2008 From: clydekunkel7734 at cox.net (Clyde E. Kunkel) Date: Fri, 30 May 2008 14:50:53 -0400 Subject: Networkmanager service is shutdown too early In-Reply-To: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> Message-ID: <48404C8D.1050403@cox.net> Valent Turkovic wrote: > During the boot I have some samba shares mounted because I have them > configured to mount via fstab file. > > When I shutdown or reboot I get a screen for 2-3 minutes that shows > smbfs service trying to unmount samba shares but NM service has > already shutdown and there is no working network connection :( > > I have seen this "bad" behaviour in F8 and have reported it on this > mailinglist, but I hoped that the new and smarter NM would take care > of it, but unfortunately it didn't :( > > So: > https://bugzilla.redhat.com/show_bug.cgi?id=449070 > > Cheers, > Valent. > Look like bz https://bugzilla.redhat.com/show_bug.cgi?id=218237 -- --------------------------------- Regards, Old Fart From nicolas.mailhot at laposte.net Fri May 30 19:09:28 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 30 May 2008 21:09:28 +0200 Subject: Networkmanager service is shutdown too early In-Reply-To: References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <1212168727.8178.13.camel@localhost.localdomain> <20080530174106.GE30687@nostromo.devel.redhat.com> <1212169602.8178.22.camel@localhost.localdomain> <20080530175914.GF30687@nostromo.devel.redhat.com> <1212171879.8178.56.camel@localhost.localdomain> Message-ID: <1212174568.3294.0.camel@rousalka.okg> Le vendredi 30 mai 2008 ? 14:50 -0400, Colin Walters a ?crit : > > Another simple solution is to not have a shutdown script at all. Just > let NM get killed by the global kill -9 before filesystem unmounts. > (which is what we should do for pretty much all services with the > exception of MySQL/Postgres basically too) The global kill -9 does not help you when you need to stop or restart a single service -- 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 notting at redhat.com Fri May 30 19:21:31 2008 From: notting at redhat.com (Bill Nottingham) Date: Fri, 30 May 2008 15:21:31 -0400 Subject: Networkmanager service is shutdown too early In-Reply-To: <1212174568.3294.0.camel@rousalka.okg> References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <1212168727.8178.13.camel@localhost.localdomain> <20080530174106.GE30687@nostromo.devel.redhat.com> <1212169602.8178.22.camel@localhost.localdomain> <20080530175914.GF30687@nostromo.devel.redhat.com> <1212171879.8178.56.camel@localhost.localdomain> <1212174568.3294.0.camel@rousalka.okg> Message-ID: <20080530192131.GA4724@nostromo.devel.redhat.com> Nicolas Mailhot (nicolas.mailhot at laposte.net) said: > > Another simple solution is to not have a shutdown script at all. Just > > let NM get killed by the global kill -9 before filesystem unmounts. > > (which is what we should do for pretty much all services with the > > exception of MySQL/Postgres basically too) > > The global kill -9 does not help you when you need to stop or restart a > single service Having a stop() stanza is not the same thing as having a KXXfoo script in /etc/rc{0,6}.d. Not that the latter is easy to manage sanely in our current paradigm. Bill From ssorce at redhat.com Fri May 30 19:29:26 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 30 May 2008 15:29:26 -0400 Subject: Networkmanager service is shutdown too early In-Reply-To: <1212171879.8178.56.camel@localhost.localdomain> References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <1212168727.8178.13.camel@localhost.localdomain> <20080530174106.GE30687@nostromo.devel.redhat.com> <1212169602.8178.22.camel@localhost.localdomain> <20080530175914.GF30687@nostromo.devel.redhat.com> <1212171879.8178.56.camel@localhost.localdomain> Message-ID: <1212175766.12605.174.camel@localhost.localdomain> On Fri, 2008-05-30 at 14:24 -0400, Dan Williams wrote: > On Fri, 2008-05-30 at 13:59 -0400, Bill Nottingham wrote: > > Dan Williams (dcbw at redhat.com) said: > > > > 'After netfs' should be good enough. Although netfs stop should possibly > > > > do lazy umounts. > > > > > > Ok, just need to bump NM a few bits later it looks like; might as well > > > be K84 to be right after messagebus. > > > > Well, NM will exit anyway when the messagebus exits, will it not? > > No, because the Debian guys got all cranky and want NM to handle dbus > dropouts, because if they need to restart dbus because of a security > issue they don't want that to take down the entire machine including > networking. So there's code to poll the bus every so often and try to > reconnect if NM gets disconnected (either due to an NM error like > sending a non-UTF8 string over the bus or if dbus quits/dies). I am very glad the debian guys got "all cranky" on this issue, Temrinating network connections just because a component need to resytart is plain silly. Simo. -- Simo Sorce * Red Hat, Inc * New York From walters at verbum.org Fri May 30 19:33:37 2008 From: walters at verbum.org (Colin Walters) Date: Fri, 30 May 2008 15:33:37 -0400 Subject: Networkmanager service is shutdown too early In-Reply-To: <1212175766.12605.174.camel@localhost.localdomain> References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <1212168727.8178.13.camel@localhost.localdomain> <20080530174106.GE30687@nostromo.devel.redhat.com> <1212169602.8178.22.camel@localhost.localdomain> <20080530175914.GF30687@nostromo.devel.redhat.com> <1212171879.8178.56.camel@localhost.localdomain> <1212175766.12605.174.camel@localhost.localdomain> Message-ID: On Fri, May 30, 2008 at 3:29 PM, Simo Sorce wrote: > > I am very glad the debian guys got "all cranky" on this issue, > Temrinating network connections just because a component need to > resytart is plain silly. DBus is not the same as any other random software because it is explicitly designed to provide reliable communication *between* components, much like the kernel. If you restart it at random times that reliability guarantee is destroyed. http://mail.gnome.org/archives/networkmanager-list/2005-March/thread.html#00027 -------------- next part -------------- An HTML attachment was scrubbed... URL: From skvidal at fedoraproject.org Fri May 30 19:38:26 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 30 May 2008 15:38:26 -0400 Subject: Networkmanager service is shutdown too early In-Reply-To: References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <1212168727.8178.13.camel@localhost.localdomain> <20080530174106.GE30687@nostromo.devel.redhat.com> <1212169602.8178.22.camel@localhost.localdomain> <20080530175914.GF30687@nostromo.devel.redhat.com> <1212171879.8178.56.camel@localhost.localdomain> <1212175766.12605.174.camel@localhost.localdomain> Message-ID: <1212176306.9616.26.camel@cutter> On Fri, 2008-05-30 at 15:33 -0400, Colin Walters wrote: > On Fri, May 30, 2008 at 3:29 PM, Simo Sorce wrote: > > > I am very glad the debian guys got "all cranky" on this issue, > Temrinating network connections just because a component need > to > resytart is plain silly. > > DBus is not the same as any other random software because it is > explicitly designed to provide reliable communication *between* > components, much like the kernel. If you restart it at random times > that reliability guarantee is destroyed. > > http://mail.gnome.org/archives/networkmanager-list/2005-March/thread.html#00027 > Simo's point still holds though. What you've described above is a better reason to have not designed nm around dbus not a reason why we should be okay with our network services going away when we restart dbus. -sv From walters at verbum.org Fri May 30 19:45:05 2008 From: walters at verbum.org (Colin Walters) Date: Fri, 30 May 2008 15:45:05 -0400 Subject: Networkmanager service is shutdown too early In-Reply-To: <1212176306.9616.26.camel@cutter> References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <1212168727.8178.13.camel@localhost.localdomain> <20080530174106.GE30687@nostromo.devel.redhat.com> <1212169602.8178.22.camel@localhost.localdomain> <20080530175914.GF30687@nostromo.devel.redhat.com> <1212171879.8178.56.camel@localhost.localdomain> <1212175766.12605.174.camel@localhost.localdomain> <1212176306.9616.26.camel@cutter> Message-ID: On Fri, May 30, 2008 at 3:38 PM, seth vidal wrote: > > Simo's point still holds though. What you've described above is a better > reason to have not designed nm around dbus not a reason why we should be > okay with our network services going away when we restart dbus. If you want your operating system to be held together with shell script, duct tape, and ad-hoc use of Unix domain sockets that's cool, I'd rather have a reliable and stable system. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssorce at redhat.com Fri May 30 19:58:15 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 30 May 2008 15:58:15 -0400 Subject: Networkmanager service is shutdown too early In-Reply-To: References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <1212168727.8178.13.camel@localhost.localdomain> <20080530174106.GE30687@nostromo.devel.redhat.com> <1212169602.8178.22.camel@localhost.localdomain> <20080530175914.GF30687@nostromo.devel.redhat.com> <1212171879.8178.56.camel@localhost.localdomain> <1212175766.12605.174.camel@localhost.localdomain> <1212176306.9616.26.camel@cutter> Message-ID: <1212177495.12605.185.camel@localhost.localdomain> On Fri, 2008-05-30 at 15:45 -0400, Colin Walters wrote: > On Fri, May 30, 2008 at 3:38 PM, seth vidal > wrote: > > > > Simo's point still holds though. What you've described above > is a better > reason to have not designed nm around dbus not a reason why we > should be > okay with our network services going away when we restart > dbus. > > If you want your operating system to be held together with shell > script, duct tape, and ad-hoc use of Unix domain sockets that's cool, > I'd rather have a reliable and stable system. A reliable system is one that does not kill my SSH connection when I do: service restart messagebus I expect Network Manager to manage my network not to kill it when it is not necessary. Simo. -- Simo Sorce * Red Hat, Inc * New York From walters at verbum.org Fri May 30 20:06:04 2008 From: walters at verbum.org (Colin Walters) Date: Fri, 30 May 2008 16:06:04 -0400 Subject: Networkmanager service is shutdown too early In-Reply-To: References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <1212168727.8178.13.camel@localhost.localdomain> <20080530174106.GE30687@nostromo.devel.redhat.com> <1212169602.8178.22.camel@localhost.localdomain> <20080530175914.GF30687@nostromo.devel.redhat.com> <1212171879.8178.56.camel@localhost.localdomain> <1212175766.12605.174.camel@localhost.localdomain> <1212176306.9616.26.camel@cutter> Message-ID: On Fri, May 30, 2008 at 3:45 PM, Colin Walters wrote: > On Fri, May 30, 2008 at 3:38 PM, seth vidal > wrote: > >> >> Simo's point still holds though. What you've described above is a better >> reason to have not designed nm around dbus not a reason why we should be >> okay with our network services going away when we restart dbus. > > > If you want your operating system to be held together with shell script, > duct tape, and ad-hoc use of Unix domain sockets that's cool, I'd rather > have a reliable and stable system. > Let me reply with something a little less antagonistic - it's just frustrating because everyone sees "Oh another daemon, let me reboot it" and blames application developers, when it's just too hard of a problem to deal with. DBus actually shares a lot of similarities with SCTP ( http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol); it's a realization that message-oriented (as opposed to stream-oriented) is fundamentally more useful to applications. DBus just happens to be implemented in userspace, but that doesn't mean it's just another daemon, any more than TCP stacks that live in userspace in some old operating system designs could just be restarted at any time without any obvious side effects on the system. Speaking of userspace kernel integration, I'd be pretty surprised if you could reliably stop the fuse service too; given all the discussion about nearly unfixable race condititons in rmmod that have ( http://lwn.net/Articles/31474/). Auditing every program and making them able to cleanly support restarts of system services like HAL, NetworkManager, and PackageKit would be a huge task, for similar reasons because these services build up state. It might sort of work most of the time, but what you *really* do not want is for the system to sometimes break when the user plugs in a USB key when the background package upgrade happened to restart the bus at just the wrong time. -------------- next part -------------- An HTML attachment was scrubbed... URL: From walters at verbum.org Fri May 30 20:07:11 2008 From: walters at verbum.org (Colin Walters) Date: Fri, 30 May 2008 16:07:11 -0400 Subject: Networkmanager service is shutdown too early In-Reply-To: <1212177495.12605.185.camel@localhost.localdomain> References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <20080530174106.GE30687@nostromo.devel.redhat.com> <1212169602.8178.22.camel@localhost.localdomain> <20080530175914.GF30687@nostromo.devel.redhat.com> <1212171879.8178.56.camel@localhost.localdomain> <1212175766.12605.174.camel@localhost.localdomain> <1212176306.9616.26.camel@cutter> <1212177495.12605.185.camel@localhost.localdomain> Message-ID: On Fri, May 30, 2008 at 3:58 PM, Simo Sorce wrote: > > A reliable system is one that does not kill my SSH connection when I do: > > service restart messagebus > > I expect Network Manager to manage my network not to kill it when it is > not necessary. Yes, with the upgrade to Upstart 0.5, "service restart messagebus" will simply be a noop. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssorce at redhat.com Fri May 30 20:23:58 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 30 May 2008 16:23:58 -0400 Subject: Networkmanager service is shutdown too early In-Reply-To: References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <1212168727.8178.13.camel@localhost.localdomain> <20080530174106.GE30687@nostromo.devel.redhat.com> <1212169602.8178.22.camel@localhost.localdomain> <20080530175914.GF30687@nostromo.devel.redhat.com> <1212171879.8178.56.camel@localhost.localdomain> <1212175766.12605.174.camel@localhost.localdomain> <1212176306.9616.26.camel@cutter> Message-ID: <1212179038.12605.197.camel@localhost.localdomain> On Fri, 2008-05-30 at 16:06 -0400, Colin Walters wrote: > On Fri, May 30, 2008 at 3:45 PM, Colin Walters > wrote: > On Fri, May 30, 2008 at 3:38 PM, seth vidal > wrote: > > > > > Simo's point still holds though. What you've described > above is a better > reason to have not designed nm around dbus not a > reason why we should be > okay with our network services going away when we > restart dbus. > > If you want your operating system to be held together with > shell script, duct tape, and ad-hoc use of Unix domain sockets > that's cool, I'd rather have a reliable and stable system. > > Let me reply with something a little less antagonistic - it's just > frustrating because everyone sees "Oh another daemon, let me reboot > it" and blames application developers, when it's just too hard of a > problem to deal with. So it's hard to "reconnect" if DBUS goes down for any reason ? That doesn't really speak good for DBUS, because it is sure that for one reason or another it will go down at some point. Caliming that DBUS can never be restarted is putting your head under the sand. Bugs just happen, dbus might explode for who knows what reason, does it mean the machine should implode as well ? > DBus actually shares a lot of similarities with SCTP > (http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol); > it's a realization that message-oriented (as opposed to > stream-oriented) is fundamentally more useful to applications. DBus > just happens to be implemented in userspace, but that doesn't mean > it's just another daemon, any more than TCP stacks that live in > userspace in some old operating system designs could just be restarted > at any time without any obvious side effects on the system. Good applications are usually built to reconnect when a transport they use becomes unavailable. if some network switch breaks for a few seconds down the road my connections have a good chance of surviving and if when connectivity is back things keep going as if nothing happened. In any case apps usually just know how to handle a TCP error and reconnect. This is because they want to be reliable and not to depend on a 100% reliable subsystem (because ther eis nothing 100% reliable in software or in hardware today). > Speaking of userspace kernel integration, I'd be pretty surprised if > you could reliably stop the fuse service too; given all the discussion > about nearly unfixable race condititons in rmmod that have > (http://lwn.net/Articles/31474/). That's why I never used Fuse so far for important long lived stuff. I do not mind it on a desktop to quickly access something, but is not something I'd use on a server. > Auditing every program and making them able to cleanly support > restarts of system services like HAL, NetworkManager, and PackageKit > would be a huge task, If it is a huge task we have worst problems, we have apps badly engineered. > for similar reasons because these services build up state. It might > sort of work most of the time, but what you *really* do not want is > for the system to sometimes break when the user plugs in a USB key > when the background package upgrade happened to restart the bus at > just the wrong time. Corner cases always exist, how probable it is that this will happen ? Is this a good reason to stick head in the sand and claim DBUS is the perfect daemon that never dies ? Maybe it is, I have no reason to think DBUS is not reliable, but on this things I am conservative, and I think that if a daemon needs patching we shouldn't have to reboot the machine (or restart half the services which is basically the same). Simo. -- Simo Sorce * Red Hat, Inc * New York From walters at verbum.org Fri May 30 20:32:10 2008 From: walters at verbum.org (Colin Walters) Date: Fri, 30 May 2008 16:32:10 -0400 Subject: Networkmanager service is shutdown too early In-Reply-To: <1212179038.12605.197.camel@localhost.localdomain> References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <1212169602.8178.22.camel@localhost.localdomain> <20080530175914.GF30687@nostromo.devel.redhat.com> <1212171879.8178.56.camel@localhost.localdomain> <1212175766.12605.174.camel@localhost.localdomain> <1212176306.9616.26.camel@cutter> <1212179038.12605.197.camel@localhost.localdomain> Message-ID: On Fri, May 30, 2008 at 4:23 PM, Simo Sorce wrote: > > So it's hard to "reconnect" if DBUS goes down for any reason ? > That doesn't really speak good for DBUS, because it is sure that for one > reason or another it will go down at some point. > Caliming that DBUS can never be restarted is putting your head under the > sand. Bugs just happen, dbus might explode for who knows what reason, > does it mean the machine should implode as well ? Sure. All software has bugs. I submit that it's far more likely for the kernel (or more specifically, drivers) or hardware flaws than DBus. Good applications are usually built to reconnect when a transport they > use becomes unavailable. if some network switch breaks for a few seconds > down the road my connections have a good chance of surviving and if when > connectivity is back things keep going as if nothing happened. Right. You know how basically every mail client explodes error dialogs when your network connection happens to be broken for a bit? Imagine those error dialogs popping up in your file browser because suddenly HAL went away during a software upgrade. Not cool. > If it is a huge task we have worst problems, we have apps badly > engineered. > No. Applications are not engineered to survive a kernel restart either. Just think of DBus as a kernel extension. Or from another view, there is precedent even in traditional Unix for privileged userspace processes - think init. Just pretend that DBus happened to be implemented in the init process instead of as pid 2. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan at redhat.com Fri May 30 20:49:38 2008 From: alan at redhat.com (Alan Cox) Date: Fri, 30 May 2008 16:49:38 -0400 Subject: Networkmanager service is shutdown too early In-Reply-To: References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <1212168727.8178.13.camel@localhost.localdomain> <20080530174106.GE30687@nostromo.devel.redhat.com> <1212169602.8178.22.camel@localhost.localdomain> <20080530175914.GF30687@nostromo.devel.redhat.com> <1212171879.8178.56.camel@localhost.localdomain> <1212175766.12605.174.camel@localhost.localdomain> Message-ID: <20080530204938.GC6179@devserv.devel.redhat.com> On Fri, May 30, 2008 at 03:33:37PM -0400, Colin Walters wrote: > DBus is not the same as any other random software because it is explicitly > designed to provide reliable communication *between* components, much like > the kernel. If you restart it at random times that reliability guarantee is > destroyed. So the questions you should ask are - Why does restarting dbus have to be unreliable - Why isn't there a recovery mechanism - Why does network manager have to do the work itself not the support code And more fundamentally Why the ... are people still writing software which doesn't try and tolerate faults that are recoverable to a useful extent. Yes dbus might have to lose a few messages and send everyone a "duh whoops" event so they can recover but "oh dear it broke everyone reboot" is not good engineering. So I'm likewise pleased the Debian people raised a sensible point. Alan From alan at redhat.com Fri May 30 20:51:37 2008 From: alan at redhat.com (Alan Cox) Date: Fri, 30 May 2008 16:51:37 -0400 Subject: Networkmanager service is shutdown too early In-Reply-To: <1212176306.9616.26.camel@cutter> References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <1212168727.8178.13.camel@localhost.localdomain> <20080530174106.GE30687@nostromo.devel.redhat.com> <1212169602.8178.22.camel@localhost.localdomain> <20080530175914.GF30687@nostromo.devel.redhat.com> <1212171879.8178.56.camel@localhost.localdomain> <1212175766.12605.174.camel@localhost.localdomain> <1212176306.9616.26.camel@cutter> Message-ID: <20080530205137.GD6179@devserv.devel.redhat.com> On Fri, May 30, 2008 at 03:38:26PM -0400, seth vidal wrote: > Simo's point still holds though. What you've described above is a better > reason to have not designed nm around dbus not a reason why we should be > okay with our network services going away when we restart dbus. I disagree - dbus is 99% really neat. Fix dbus and you improve everything, if everyone works around it everyone loses. From alan at redhat.com Fri May 30 20:59:23 2008 From: alan at redhat.com (Alan Cox) Date: Fri, 30 May 2008 16:59:23 -0400 Subject: Networkmanager service is shutdown too early In-Reply-To: References: <1212168727.8178.13.camel@localhost.localdomain> <20080530174106.GE30687@nostromo.devel.redhat.com> <1212169602.8178.22.camel@localhost.localdomain> <20080530175914.GF30687@nostromo.devel.redhat.com> <1212171879.8178.56.camel@localhost.localdomain> <1212175766.12605.174.camel@localhost.localdomain> <1212176306.9616.26.camel@cutter> Message-ID: <20080530205923.GE6179@devserv.devel.redhat.com> On Fri, May 30, 2008 at 04:06:04PM -0400, Colin Walters wrote: > implemented in userspace, but that doesn't mean it's just another daemon, > any more than TCP stacks that live in userspace in some old operating system > designs could just be restarted at any time without any obvious side effects > on the system. I would suggest you take a look at the failover work people have done in user space and also the higher level communication protocols. There is a reason it is done higher up the stack - you want to deal at transaction level. I can *turn off* my NFS server, go for lunch, come back, turn it on and my client -keeps working-. I can restart the old X font server live I can restart all my web services while using them and I maybe get a reset or odd error then it recovers I can unplug and replug hard disks and it'll recover nowdays in almost all cases Software should try and limp on and/or recover itself nicely. That way you'll get a usable product that degrades acceptably. You wouldn't build a house that fell down if any single brick cracked. > Speaking of userspace kernel integration, I'd be pretty surprised if you > could reliably stop the fuse service too; given all the discussion about > nearly unfixable race condititons in rmmod that have ( > http://lwn.net/Articles/31474/). Fuse is pretty close and its considered a bug that it isn't 100% perfect on this yet. > Auditing every program and making them able to cleanly support restarts of > system services like HAL, NetworkManager, and PackageKit would be a huge > task, for similar reasons because these services build up state. It might It would be a huge step forward if they firstly just restarted as a default response to dbus went away. Almost every one of them builds up a new state when run from startup and it'll be far better than "oh reboot again" Windows mentality crap. Some like NetworkManager need to be a bit smarter - but not a lot. > sort of work most of the time, but what you *really* do not want is for the > system to sometimes break when the user plugs in a USB key when the > background package upgrade happened to restart the bus at just the wrong > time. Most of the time is better than not restarting which means it *never* works. Which do you prefer Insert USB key - nothing happens Repeat 50 times, reboot or Insert USB key - nothing happens Repeat - ah success Aaln From alan at redhat.com Fri May 30 21:06:35 2008 From: alan at redhat.com (Alan Cox) Date: Fri, 30 May 2008 17:06:35 -0400 Subject: Networkmanager service is shutdown too early In-Reply-To: References: <1212169602.8178.22.camel@localhost.localdomain> <20080530175914.GF30687@nostromo.devel.redhat.com> <1212171879.8178.56.camel@localhost.localdomain> <1212175766.12605.174.camel@localhost.localdomain> <1212176306.9616.26.camel@cutter> <1212179038.12605.197.camel@localhost.localdomain> Message-ID: <20080530210635.GF6179@devserv.devel.redhat.com> On Fri, May 30, 2008 at 04:32:10PM -0400, Colin Walters wrote: > Right. You know how basically every mail client explodes error dialogs when > your network connection happens to be broken for a bit? Imagine those error > dialogs popping up in your file browser because suddenly HAL went away > during a software upgrade. Not cool. Bad example. My email client reports the link was lost. If I try again it politely tries again so I can recover from a lost link or a mail server reset without losing my mail client or restarting it. It even tries to keep local state and carry on, so only mail not cached locally can't be read in full. When the link is lost it shows me that politely (no more dialogs) and limps on. Rather handy as I use it on the train. What I would expect from nautilus at minimum is - sync desktop state - restart - flicker a bit - continue And what I would really expect is - icons for dbus dependant things are overlaid with a "?" logo - maybe a single dialogue (with a 'don't show me again') - my desktop to reconnect to dbus and recover its state politely without any restarts by me. > > If it is a huge task we have worst problems, we have apps badly > > engineered. > > No. Applications are not engineered to survive a kernel restart either. Actually they are. They sync their data so they don't corrupt, they can do cluster failover. In addition kernel restart currently can't be done live (for good reasons that are genuinely hard) so it makes no sense for the app to do more advanced stuff. Dbus recovery is not hard (perfect dbus recovery is hard but it isn't neccessary either) > Just think of DBus as a kernel extension. Or from another view, there is > precedent even in traditional Unix for privileged userspace processes - > think init. Just pretend that DBus happened to be implemented in the init > process instead of as pid 2. Bad example too - making init restart is on the kernel todo list and there are some test patches for this floating around. Alan From walters at verbum.org Fri May 30 21:17:20 2008 From: walters at verbum.org (Colin Walters) Date: Fri, 30 May 2008 17:17:20 -0400 Subject: Networkmanager service is shutdown too early In-Reply-To: <20080530205923.GE6179@devserv.devel.redhat.com> References: <1212168727.8178.13.camel@localhost.localdomain> <1212169602.8178.22.camel@localhost.localdomain> <20080530175914.GF30687@nostromo.devel.redhat.com> <1212171879.8178.56.camel@localhost.localdomain> <1212175766.12605.174.camel@localhost.localdomain> <1212176306.9616.26.camel@cutter> <20080530205923.GE6179@devserv.devel.redhat.com> Message-ID: On Fri, May 30, 2008 at 4:59 PM, Alan Cox wrote: > > Which do you prefer > > Insert USB key - nothing happens > Repeat 50 times, reboot Which model is this? In the model where we don't restart, it will work 100% reliably. > > or > > Insert USB key - nothing happens > Repeat - ah success > We will get bug reports about things like that. They will not be easily reproducible. And remember the USB key example is by far the least bad. -------------- next part -------------- An HTML attachment was scrubbed... URL: From walters at verbum.org Fri May 30 21:47:53 2008 From: walters at verbum.org (Colin Walters) Date: Fri, 30 May 2008 17:47:53 -0400 Subject: Networkmanager service is shutdown too early In-Reply-To: <20080530210635.GF6179@devserv.devel.redhat.com> References: <1212169602.8178.22.camel@localhost.localdomain> <1212171879.8178.56.camel@localhost.localdomain> <1212175766.12605.174.camel@localhost.localdomain> <1212176306.9616.26.camel@cutter> <1212179038.12605.197.camel@localhost.localdomain> <20080530210635.GF6179@devserv.devel.redhat.com> Message-ID: On Fri, May 30, 2008 at 5:06 PM, Alan Cox wrote: > > And what I would really expect is > > - icons for dbus dependant things are overlaid with a "?" logo > - maybe a single dialogue (with a 'don't show me again') > - my desktop to reconnect to dbus and recover its state politely > without any restarts by me. Do you have any idea how much custom code that is, when multiplied by all services and all programs that use them? And remember, this is all code that will *almost never be called*. It will not be tested very well. In fact, I would argue such special recovery code is far more likely to actually *introduce* problems. For example, will it handle the case where I'm currently dragging a file from a USB key? Look; with respect to the desktop and upgrades, we have far larger problems in Fedora than the system bus. Do you realize that currently in Fedora, we actually have a *worse* experience upgrading Firefox than compared to Windows? Why is that? Our upgrade process is currently defined just as "untar and run some shell scripts". What do we do about the running Firefox? Nothing. No notification. You have to know to hunt and close all the windows and then click the icon again. Actually the fact that we replace all the old files means the currently running one breaks in subtle ways; for example, if you notice the Ctrl-f dialog won't work after an upgrade because it's trying to load a file from disk that isn't there anymore. For sure Firefox's versioned structure exacerbates this problem, but it's by no means limited to Firefox. In general *any* program that opens a file that it expects to be there in the currently running version but is not in the new one will break. How do you solve that? You don't. We need to require a logout and log back in. Possibly could be more clever about scanning executables in of the RPM and linking those to running processes, and then linking the processes to X windows and pulsing them or something but...yeah. Remember for the desktop use case we do not have a Unix administrator sitting there with a root shell who knows the details of how the operating system works. For our users it simply *cannot fail*. Bad example too - making init restart is on the kernel todo list and there > are some test patches for this floating around. Ok, let's say that restarting the system bus is on our todo list too. =) -------------- next part -------------- An HTML attachment was scrubbed... URL: From tibbs at math.uh.edu Fri May 30 22:10:38 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 30 May 2008 17:10:38 -0500 Subject: Hylafax review issues Message-ID: One of the oldest review tickets still open is https://bugzilla.redhat.com/show_bug.cgi?id=188542, for the fax server hylafax. Earlier this month I picked this up an attempt to try and shepherd it through the process, but I'm stuck on a couple of issues and the submitter does not seem to be willing to address them satisfactorily. Maybe I should just say "hell no" and drop the review, but I guess my objections could be wrong so I figured I'd try to start some discussion. Issue one is the name: There are multiple pieces of software claiming to be hylafax. There's the software at hylafax.org, and then there's the package at hylafax.sourceforge.net, where it is called "hylafax+". I quote: The "+" means that it is better. There's also an "enterprise" version from ifax.com. The second version, which upstream calls itself "hylafax+" is the one being submitted, but the submitter argues against using that name (see comment 38): However, my suggestion would follow what I've said above about the Apache http server. The distinction of the "+" will mean very little to Fedora users (and in-fact may make the package more-difficult to identify) unless there is more than one HylaFAX package being distributed by Fedora (say, for example, separate "hylafax+" and "hylafax.org" packages). Anyone else agree with that reasoning? What about using Provides: hylafax until the hylafax.org package makes it into the distro (assuming someone actually wants to submit it)? The second issue is an FHS violation: several directories are installed under /var/spool which contain things that aren't really in the spirit of /var/spool. There's a /var/spool/hylafax/bin directory which, you guessed it, contains executables, a /var/spool/hylafax/config directory containing config files, and /var/spool/hylafax/etc containing other, different config files. Here's what the submitter has to say (see comment 83): While the vast majority of HylaFAX binaries and their respective configuration files are installed outside of /var/spool/hylafax, those three directories (etc, bin, and config) are configuration files and configuration utility scripts, etc., that control how the spools are handled. Due to the way that HylaFAX daemons operate it would be extremely cumbersome (if not impossible - as in the case of a chroot) for these to be elsewhere. They're very much like the configuration files that LPRng had under /var/spool/lpd. So, that's my argument. I hope that it's acceptable. But if it's not... unfortunately there's not much that I am willing to do about it. Now, lprng isn't in the distro and I really don't think it would have passed review like that, so I can't buy that as an argument. "cumbersome", well, too bad I guess. I'm not sure about a chroot. I mean, just fix the code to look elsewhere. How hard could it be? But even if, it's too hard to fix, what about a few symlinks? (To somewhere under /usr/libexec for the bin stuff, and somewhere under /etc for for config and etc directories.) Do three symlinks violate the FHS significantly enough to cause issues? My understanding is that this should be OK with chroots (as long as the links are relative.) And how does all of this square with selinux? I'd be appreciative of any suggestions. - J< From mostafa at daneshvar.org.uk Fri May 30 22:16:52 2008 From: mostafa at daneshvar.org.uk (Mostafa Daneshvar) Date: Sat, 31 May 2008 02:46:52 +0430 Subject: Introduction: Mostafa Daneshvar Message-ID: <200805310246.56493.mostafa@daneshvar.org.uk> Hi I am Mostafa Daneshvar. I am from Iran. I am using Fedora 9 as my OS. I am coordinator of Balochi language in fedora project. I hope I can help in development of Fedora My Wiki page: https://fedoraproject.org/wiki/MostafaDaneshvar -- Mostafa Baloch http://www.mdaneshvar.ir -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From alan at redhat.com Fri May 30 23:13:51 2008 From: alan at redhat.com (Alan Cox) Date: Fri, 30 May 2008 19:13:51 -0400 Subject: Networkmanager service is shutdown too early In-Reply-To: References: <1212169602.8178.22.camel@localhost.localdomain> <20080530175914.GF30687@nostromo.devel.redhat.com> <1212171879.8178.56.camel@localhost.localdomain> <1212175766.12605.174.camel@localhost.localdomain> <1212176306.9616.26.camel@cutter> <20080530205923.GE6179@devserv.devel.redhat.com> Message-ID: <20080530231351.GA10243@devserv.devel.redhat.com> On Fri, May 30, 2008 at 05:17:20PM -0400, Colin Walters wrote: > On Fri, May 30, 2008 at 4:59 PM, Alan Cox wrote: > > > > > Which do you prefer > > > > Insert USB key - nothing happens > > Repeat 50 times, reboot > > > Which model is this? In the model where we don't restart, it will work 100% > reliably. Only if it doesn't crash > > Insert USB key - nothing happens > > Repeat - ah success > > > > We will get bug reports about things like that. They will not be easily > reproducible. So you log the event then when you get a bug report you shoot the process at the right moment. From alan at redhat.com Fri May 30 23:18:09 2008 From: alan at redhat.com (Alan Cox) Date: Fri, 30 May 2008 19:18:09 -0400 Subject: Networkmanager service is shutdown too early In-Reply-To: References: <1212171879.8178.56.camel@localhost.localdomain> <1212175766.12605.174.camel@localhost.localdomain> <1212176306.9616.26.camel@cutter> <1212179038.12605.197.camel@localhost.localdomain> <20080530210635.GF6179@devserv.devel.redhat.com> Message-ID: <20080530231809.GB10243@devserv.devel.redhat.com> > > And what I would really expect is > > > > - icons for dbus dependant things are overlaid with a "?" logo > > - maybe a single dialogue (with a 'don't show me again') > > - my desktop to reconnect to dbus and recover its state politely > > without any restarts by me. > > > Do you have any idea how much custom code that is, when multiplied by all > services and all programs that use them? And remember, this is all code > that will *almost never be called*. It will not be tested very well. It'll get called a lot in your test suite by simulation (just as kernel folk use virtualisation to simulate hardware fails). Seriously - I recognize that and its why "I would really expect" and a rather more realistic short term solution were both listed. > Look; with respect to the desktop and upgrades, we have far larger problems > in Fedora than the system bus. Do you realize that currently in Fedora, we Yes but the system bus is fixable and hanging more stuff off it so it breaks more and more will just move people off the bus and in turn make the problem worse and worse. > How do you solve that? You don't. We need to require a logout and log back > in. Possibly could be more clever about scanning executables in of the RPM > and linking those to running processes, and then linking the processes to X > windows and pulsing them or something but...yeah. Actually firefox is pretty smart and there are ugly ways to do it. I do agree with the general problem - but its going off topic and a diversion > Remember for the desktop use case we do not have a Unix administrator > sitting there with a root shell who knows the details of how the operating > system works. For our users it simply *cannot fail*. I disagree - it must recover itself Alan From dimi at lattica.com Fri May 30 23:35:13 2008 From: dimi at lattica.com (Dimi Paun) Date: Fri, 30 May 2008 19:35:13 -0400 Subject: Networkmanager service is shutdown too early In-Reply-To: <20080530204938.GC6179@devserv.devel.redhat.com> References: <64b14b300805300154l7a6e55abkc5d65a541fade623@mail.gmail.com> <1212168727.8178.13.camel@localhost.localdomain> <20080530174106.GE30687@nostromo.devel.redhat.com> <1212169602.8178.22.camel@localhost.localdomain> <20080530175914.GF30687@nostromo.devel.redhat.com> <1212171879.8178.56.camel@localhost.localdomain> <1212175766.12605.174.camel@localhost.localdomain> <20080530204938.GC6179@devserv.devel.redhat.com> Message-ID: <1212190513.5355.271.camel@dimi.lattica.com> On Fri, 2008-05-30 at 16:49 -0400, Alan Cox wrote: > Why the ... are people still writing software which doesn't try and > tolerate faults that are recoverable to a useful extent. Yes dbus > might have to lose a few messages and send everyone a "duh whoops" > event so they can recover but "oh dear it broke everyone reboot" is > not good engineering. This is exactly the problem that we were discussing some time ago about PulseAudio. It is a great daemon, but right now it crashes reliably for me, and until I figured out that I needed to run "pulseaudio -D" from a terminal, my only way out was a reboot! This is pretty brutal. I understand that we aim for perfection, but we're far from it. The thing crashes reliably here after a few hours of use, and there is No Way(TM) you can expect regular human beings to issue a "pulseaudio -D". When you put 2+2 together it follows that we have a desktop that normal users must completely restart every few hours to get working sound! When I brought this up last time, I was told by the developers that it's normal behaviour for most software out there, and that I should file bugs and work toward marking PA perfect. I don't understand why it's so inconceivable for PA to restart itself? There isn't all that much state to begin with, and _any_ user would prefer a sound glitch to a full desktop restart (or even to a "pulseaudio -D"!). -- Dimi Paun Lattica, Inc. From kwade at redhat.com Sat May 31 00:17:42 2008 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Fri, 30 May 2008 17:17:42 -0700 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080522065724.1788e577@vader.jdub.homelinux.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> Message-ID: <1212193062.3594.413.camel@calliope.phig.org> On Thu, 2008-05-22 at 06:57 -0500, Josh Boyer wrote: > Let the naming begin! We're starting very early this time around in > the name game for F10. So, let the suggestions flow! This is the second or third time I have entirely missed the naming discussion. Why? Not all contributors slavishly read every word on fedora-devel-list. Next time, PLEASE, a cross-project announcement is in order. Otherwise you disenfranchise every project that does not have f-devel-l as their primary project list. Previously it was suggested that the people who make the distribution should be involved in the naming, that is why it is not on e.g. fedora-list. These days, I can't see how we can imagine making a distro without all of the other subprojects. Why should we name the distro without them? - Karsten > Remember the rules: > > 1) must have some link to Sulphur > > More specifically, the link should be > Sulphur is a and > is a > Where is the same for both > > 2) The link between and Sulphur cannot be the same as between > Werewolf and Sulphur. That link was "things that react badly with > silver". > > I will be collecting suggestions for 1 week, so the cutoff for names is: > > May 29, 2008 > > Suggestions will be run through the legal queue and an election will > happen for Fedora contributors to pick the next Fedora name. > > josh > -- Karsten Wade, Sr. Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org gpg key : AD0E0C41 -------------- next part -------------- A non-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 gmail.com Sat May 31 01:24:08 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 30 May 2008 20:24:08 -0500 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1212193062.3594.413.camel@calliope.phig.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1212193062.3594.413.camel@calliope.phig.org> Message-ID: <20080530202408.62e15ccd@vader.jdub.homelinux.org> On Fri, 30 May 2008 17:17:42 -0700 "Karsten 'quaid' Wade" wrote: > On Thu, 2008-05-22 at 06:57 -0500, Josh Boyer wrote: > > Let the naming begin! We're starting very early this time around in > > the name game for F10. So, let the suggestions flow! > > This is the second or third time I have entirely missed the naming discussion. > > Why? > > Not all contributors slavishly read every word on fedora-devel-list. > > Next time, PLEASE, a cross-project announcement is in order. Otherwise > you disenfranchise every project that does not have f-devel-l as their > primary project list. > > Previously it was suggested that the people who make the distribution > should be involved in the naming, that is why it is not on e.g. > fedora-list. These days, I can't see how we can imagine making a distro > without all of the other subprojects. Why should we name the distro > without them? Hi, Apparently humans make mistakes. I'm told this is a result of many different things, including fat fingers and this very irritating problem of not having perfect memories. So. Apologies. It wasn't intentional. If you'd like, I'll extend the deadline for another 4 days and you can forward the initial announcement to whatever lists you'd like. Just make sure the replies get to me so I can collect them. josh From vonbrand at inf.utfsm.cl Sat May 31 02:02:25 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Fri, 30 May 2008 22:02:25 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080530090935.1878ca68@vader.jdub.homelinux.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1212154872.16130.41.camel@localhost.localdomain> <20080530135634.GC11236@domsch.com> <20080530090935.1878ca68@vader.jdub.homelinux.org> Message-ID: <200805310202.m4V22Pcw012945@laptop13.inf.utfsm.cl> Josh Boyer wrote: > On Fri, 30 May 2008 08:56:34 -0500 > Matt Domsch wrote: > > > > A little added twist here. I'd like to give the Fedora Board a chance > > > at culling the list a little bit before sending on to Legal. There were > > > a number of names that made it through the "is a" test and Legal that > > > might not have been the best ideas for naming a release. Add to that > > > the fact that Red Hat has used outside Legal to do the name clearance > > > the last few times and that is a measurable cost both in time and money. > > > The more names we ask to clear the more expensive and longer the delay > > > will be before we have a set to vote upon. So I am asking the Fedora > > > Board to review the list of names that Josh has collected and remove any > > > they deem not acceptable as a Fedora release name before handing it to > > > Legal. > > > > > > (Note, I haven't yet directly talked to the board about this, so I'm > > > just assuming that they'll be on... board... with this.) > > > > Seems a very reasonable request. The Board doesn't want to limit > > people's brainstorming, but I can see value in culling the list that's > > sent out for trademark research. > > OK. So the current list I have is at: > > http://jwboyer.fedorapeople.org/ Seeing what the relationship is would be nice. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 From jkeating at redhat.com Sat May 31 02:08:08 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 30 May 2008 22:08:08 -0400 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1212193062.3594.413.camel@calliope.phig.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1212193062.3594.413.camel@calliope.phig.org> Message-ID: <1212199688.16130.135.camel@localhost.localdomain> On Fri, 2008-05-30 at 17:17 -0700, Karsten 'quaid' Wade wrote: > Not all contributors slavishly read every word on fedora-devel-list. Perhaps not. But perhaps the chance to participate in the naming of a distribution is a treat we gift upon those that do... In the early days the naming was picked by those who were in the office late at night hacking crap together to make the release happen. Then it moved to something more where a few people would pick some names and then those would get voted on by members of fedora-maintainers-list. Then we allowed said maintainers to offer suggestions. Then we shut down fedora-maintainers-list and moved the suggestions to fedora-devel-list. The spirit is the same, those that are slogging along and putting up with the traffic and doing the necessary work are those who get some bonus in offering suggestions for the name of the next release. Actually voting on the names that have made it back through the board and Legal will be open to a far broader range of Fedora contributors. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jwboyer at gmail.com Sat May 31 02:17:57 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 30 May 2008 21:17:57 -0500 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <200805310202.m4V22Pcw012945@laptop13.inf.utfsm.cl> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1212154872.16130.41.camel@localhost.localdomain> <20080530135634.GC11236@domsch.com> <20080530090935.1878ca68@vader.jdub.homelinux.org> <200805310202.m4V22Pcw012945@laptop13.inf.utfsm.cl> Message-ID: <20080530211757.47f67760@vader.jdub.homelinux.org> On Fri, 30 May 2008 22:02:25 -0400 "Horst H. von Brand" wrote: > Josh Boyer wrote: > > On Fri, 30 May 2008 08:56:34 -0500 > > Matt Domsch wrote: > > > > > > A little added twist here. I'd like to give the Fedora Board a chance > > > > at culling the list a little bit before sending on to Legal. There were > > > > a number of names that made it through the "is a" test and Legal that > > > > might not have been the best ideas for naming a release. Add to that > > > > the fact that Red Hat has used outside Legal to do the name clearance > > > > the last few times and that is a measurable cost both in time and money. > > > > The more names we ask to clear the more expensive and longer the delay > > > > will be before we have a set to vote upon. So I am asking the Fedora > > > > Board to review the list of names that Josh has collected and remove any > > > > they deem not acceptable as a Fedora release name before handing it to > > > > Legal. > > > > > > > > (Note, I haven't yet directly talked to the board about this, so I'm > > > > just assuming that they'll be on... board... with this.) > > > > > > Seems a very reasonable request. The Board doesn't want to limit > > > people's brainstorming, but I can see value in culling the list that's > > > sent out for trademark research. > > > > OK. So the current list I have is at: > > > > http://jwboyer.fedorapeople.org/ > > Seeing what the relationship is would be nice. Fortunately they are all archived in the fedora-devel list. You'll get the relationship documented in the release page when the winner is picked. josh From jwboyer at gmail.com Sat May 31 02:20:28 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 30 May 2008 21:20:28 -0500 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <1212199688.16130.135.camel@localhost.localdomain> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1212193062.3594.413.camel@calliope.phig.org> <1212199688.16130.135.camel@localhost.localdomain> Message-ID: <20080530212028.6b0f0839@vader.jdub.homelinux.org> On Fri, 30 May 2008 22:08:08 -0400 Jesse Keating wrote: > On Fri, 2008-05-30 at 17:17 -0700, Karsten 'quaid' Wade wrote: > > Not all contributors slavishly read every word on fedora-devel-list. > > Perhaps not. But perhaps the chance to participate in the naming of a > distribution is a treat we gift upon those that do... I think you tread a fine line there. Most contributors are on fedora-devel list or follow it some way. However, I can see how some on docs or art, who _are_ doing, wouldn't be. Hence my offer to extend it for 4 days so Karsten can forward the rules email to the contributing groups he thinks might not be following fedora-devel. josh From dev at nigelj.com Sat May 31 04:54:24 2008 From: dev at nigelj.com (Nigel Jones) Date: Sat, 31 May 2008 16:54:24 +1200 Subject: Werewolf -> Sulphur -> ? Sulphur is a , is a In-Reply-To: <20080530212028.6b0f0839@vader.jdub.homelinux.org> References: <20080522065724.1788e577@vader.jdub.homelinux.org> <1212193062.3594.413.camel@calliope.phig.org> <1212199688.16130.135.camel@localhost.localdomain> <20080530212028.6b0f0839@vader.jdub.homelinux.org> Message-ID: <4840DA00.8070809@nigelj.com> Josh Boyer wrote: > On Fri, 30 May 2008 22:08:08 -0400 > Jesse Keating wrote: > > >> On Fri, 2008-05-30 at 17:17 -0700, Karsten 'quaid' Wade wrote: >> >>> Not all contributors slavishly read every word on fedora-devel-list. >>> >> Perhaps not. But perhaps the chance to participate in the naming of a >> distribution is a treat we gift upon those that do... >> > > I think you tread a fine line there. > > Most contributors are on fedora-devel list or follow it some way. > However, I can see how some on docs or art, who _are_ doing, wouldn't > be. I totally agree here, the Docs team salve away right before release ensuring that (for instance) the release notes are correct and factual, and that we can produce some documentation so our users can use what we the maintainers do. You could use the exact same rationale to say that the Artwork guys get a say too. Package maintainers are only one (although large) component of any Fedora release. - Nigel From j.w.r.degoede at hhs.nl Sat May 31 08:28:30 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 31 May 2008 10:28:30 +0200 Subject: Review swapsies Message-ID: <48410C2E.3040404@hhs.nl> Hi All, I'm still looking for reviewers for the following: * elice - Elice is a PureBasic to c++ translator / compiler https://bugzilla.redhat.com/show_bug.cgi?id=448310 * lostlabyrinth - Lost Labyrinth is a coffeebreak dungeon crawling game https://bugzilla.redhat.com/show_bug.cgi?id=448311 * lostlabyrinth-sounds - Lost Labyrinth sounds https://bugzilla.redhat.com/show_bug.cgi?id=448312 * lostlabyrinth-graphics - Lost Labyrinth graphics https://bugzilla.redhat.com/show_bug.cgi?id=448313 * trophy - Car racing game with special features https://bugzilla.redhat.com/show_bug.cgi?id=448422 As always I'll review 1 package in return for each package of mine you review. Thanks & Regards, Hans From dan at danny.cz Sat May 31 08:53:02 2008 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Sat, 31 May 2008 10:53:02 +0200 Subject: Review swapsies In-Reply-To: <48410C2E.3040404@hhs.nl> References: <48410C2E.3040404@hhs.nl> Message-ID: <1212223982.3364.2.camel@eagle.danny.cz> Hans de Goede p??e v So 31. 05. 2008 v 10:28 +0200: > Hi All, > > I'm still looking for reviewers for the following: > ... > * trophy - Car racing game with special features > https://bugzilla.redhat.com/show_bug.cgi?id=448422 > trophy is mine now ;-) > As always I'll review 1 package in return for each package of mine you review. can you take https://bugzilla.redhat.com/show_bug.cgi?id=442280 ? Dan From ivazqueznet at gmail.com Sat May 31 09:35:33 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Sat, 31 May 2008 05:35:33 -0400 Subject: Review swapsies In-Reply-To: <48410C2E.3040404@hhs.nl> References: <48410C2E.3040404@hhs.nl> Message-ID: <1212226533.455.12.camel@ignacio.lan> On Sat, 2008-05-31 at 10:28 +0200, Hans de Goede wrote: > * elice - Elice is a PureBasic to c++ translator / compiler > https://bugzilla.redhat.com/show_bug.cgi?id=448310 I don't really have anything up right now, but I'll take this one. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rawhide at fedoraproject.org Sat May 31 11:02:51 2008 From: rawhide at fedoraproject.org (Rawhide) Date: Sat, 31 May 2008 11:02:51 +0000 (UTC) Subject: rawhide report: 20080531 changes Message-ID: <20080531110251.BDC45209CC7@releng1.fedora.phx.redhat.com> setting up repos setting up old repo file:///mnt/koji/mash/rawhide-20080530/development/source/SRPMS Excluding Packages in global exclude list Finished setting up new repo file:///mnt/koji/mash/rawhide-20080531/development/source/SRPMS Excluding Packages in global exclude list Finished performing the diff New package gabedit GUI for computational chemistry New package gmm A generic C++ template library for sparse, dense and skyline matrices New package json-glib Library for JavaScript Object Notation format New package perl-CPAN-Mini Create a minimal mirror of CPAN New package perl-Catalyst-Plugin-Session Catalyst generic session plugin New package plymouth Plymouth Graphical Boot Animation and Logger New package pyrenamer A mass file renamer written in PyGTK New package python-toscawidgets Toolkit to help create widgets for WSGI web apps New package python-virtkey Python extension for emulating keypresses and getting current keyboard layout New package subtitleeditor GTK+2 tool to edit subtitles for GNU/Linux/*BSD New package xdotool Fake keyboard/mouse input Updated Packages: bzr-gtk-0.94.0-2.fc10 --------------------- * Wed May 21 18:00:00 2008 Toshio Kuratomi 0.94.0-2 - Add patch from upstream to fix all bzr-gtk commands when seahorse isn't present. launchpad #228922. * Wed May 7 18:00:00 2008 Toshio Kuratomi 0.94-1.1 - Add Encoding metadata for EL-5/F-7 desktop-file-validate. cbrpager-0.9.18-1.fc10 ---------------------- * Sat May 31 18:00:00 2008 Mamoru Tasaka - 0.9.18-1 - 0.9.18 - 1 patch dropped, upstream applied chkrootkit-0.48-8.fc10 ---------------------- * Fri May 30 18:00:00 2008 Michael Schwendt - 0.48-8 - Let chkproc default to procps version 3. cluster-2.99.02-4.fc10 ---------------------- * Fri May 23 18:00:00 2008 Fabio M. Di Nitto - 2.99.02-4 - Add missing OpenIPMI requires to cman for fence_ipmilan cups-1.3.7-5.fc10 ----------------- * Fri May 30 18:00:00 2008 Tim Waugh 1:1.3.7-5 - Better fix for cupsdTimeoutJob LSPP configuration suggested by Matt Anderson (bug #447200). dbus-1.2.1-4.fc10 ----------------- * Thu May 29 18:00:00 2008 Casey Dahlin - 1.2.1-4 - Patches for fd.o bugs 15635, 15571, 15588, 15570 ds9-5.2-2.fc10 -------------- * Fri May 30 18:00:00 2008 Sergio Pascual - 5.2-2 - Updated gcc 4.3 patch * Fri May 30 18:00:00 2008 Sergio Pascual - 5.2-1 - New upstream source eclipse-3.3.2-12.fc9 -------------------- * Wed May 14 18:00:00 2008 Andrew Overholt 3.3.2-12 - Back-port patch for e.o#206432 (rh#446064). eclipse-pydev-1.3.17-1.fc9 -------------------------- * Tue May 20 18:00:00 2008 Jeff Johnston 1:1.3.17-1 - Resolves Bugzilla #447455 - 1.3.17 fedora-ds-base-1.1.1-1.fc10 --------------------------- * Fri May 23 18:00:00 2008 Rich Megginson - 1.1.1-1 - 1.1.1 release candidate - several bug fixes fuse-s3fs-0.6-1.fc10 -------------------- * Fri May 30 18:00:00 2008 Neil Horman 0.6-1 - Updated s3fs to upstream version 0.6 gimp-2.4.6-1.fc10 ----------------- * Fri May 30 18:00:00 2008 Nils Philippsen - 2:2.4.6-1 - version 2.4.6 Changes in GIMP 2.4.6 ===================== - fixed handling of the "antialias" tool option (bug #521069) - when loading a TIFF image, always set a filename on it (bug #521436) - fixed initial state of curve type in Curves tool (bug #523873) - fixed potential crash in the Dicom load plug-in - respect the brush mask in the Heal tool (bug #521433) - plugged some minor memory leaks - fixed a glitch in the DND code (bug #317992) - gimp-image-convert() must not accept palettes with > 256 colors (bug - fixed parameter description in the Map Object plug-in (bug #526679) - fixed compilation of unit tests on Mac OS X (bug #528160) - fixed handling of "argc-lower-val-y" PDB parameter in Curve Bend plug-in - fixed overlap problem in Hue-Saturation tool (bug #527085) - fixed asymmetry in Unsharp Mask plug-in (bug #530077) - don't show non-existant color profiles in the selector (bug #528958) - fixed issues with default aspect ratio in the Crop tool (bug #532057) - fixed compilation of the PDF import plug-in with libpoppler 0.8 - fixed bug in clipboard brush code (bug #532886) - corrected layer mask flag in PSD save plug-in (bug #526811) - fixed an issue with tablets and newer X.Org releases - keep the JPEG save plug-in from writing an empty EXIF tag (bug #529469) - fixed crash in Selective Gaussion Blur plug-in (bug #529280) - added new translations (Belarusian, Catalan, Norwegian Nynorsk) - translation fixes and updates (ar, ca, de, el, es, fi, fr, hu, it, ko, pl, pt_BR, ro, sv) gtk2-2.13.1-2.fc10 ------------------ * Fri May 30 18:00:00 2008 Matthias Clasen - 2.13.1-2 - Fix a problem with some pixbuf loaders * Fri May 30 18:00:00 2008 Matthias Clasen - 2.13.1-1 - Update to 2.13.1 hunspell-da-1.7.21-1.fc10 ------------------------- * Fri May 30 18:00:00 2008 Caolan McNamara - 1.7.21-1 - latest version imlib2-1.4.0-7.fc10 ------------------- * Fri May 30 18:00:00 2008 Tomas Smetana 1.4.0-7 - patch for CVE-2008-2426 iprutils-2.2.8-4.fc9 -------------------- * Wed Apr 9 18:00:00 2008 Roman Rakus - 2.2.8-4 - Rewrited initscripts for satisfying LSB spec ipython-0.8.3-1.fc10 -------------------- * Fri May 30 18:00:00 2008 James Bowes 0.8.3-1 - Update to 0.8.3 kdevelop-3.5.2-1.fc9 -------------------- * Mon May 19 18:00:00 2008 Kevin Kofler - 9:3.5.2-1 - update to 3.5.2 - F9+: BR qt3-devel-docs instead of qt-devel-docs - F9+: Require qt3-designer instead of qt-designer - drop backported fix_missing_output_kdev3.5.1 patch kernel-2.6.26-0.45.rc4.git2.fc10 -------------------------------- kyum-0.7.5-12.fc9 ----------------- * Thu Apr 24 18:00:00 2008 Jochen Schmitt 0.7.5-12 - Add kdebase3 as an Req. libcdio-0.80-1.fc10 ------------------- * Thu May 29 18:00:00 2008 Adrian Reber - 0.80-1 - updated to 0.80 - removed upstreamed patches - last GPLv2+ release libxml2-2.6.32-3.fc10 --------------------- * Fri May 30 18:00:00 2008 Daniel Veillard 2.6.31-3.fc10 - cleanup based on Fedora packaging guidelines, should fix #226079 - separate a -static package nautilus-2.23.2-3.fc10 ---------------------- * Fri May 30 18:00:00 2008 Tomas Bzatek - 2.23.2-3 - Add DnD support to drop files onto archive files with help of file-roller (gnomebz #377157) - Add fix preventing crash on bad GFileInfos (gnomebz #519743) net-snmp-5.4.1-18.fc10 ---------------------- * Sat May 31 18:00:00 2008 Dennis Gilmore 5.4.1-18 - fix sparc handling in /usr/bin/net-snmp-config pulseaudio-0.9.11-0.3.svn20080529.fc10 -------------------------------------- * Fri May 30 18:00:00 2008 Lennart Poettering 0.9.11-0.3.svn20080529 - Fix snapshot versioning pyfits-1.3-3.fc9 ---------------- python-vobject-0.6.5-1.fc10 --------------------------- * Fri May 30 18:00:00 2008 James Bowes - 0.6.5-1 - Update to 0.6.5 qca2-2.0.0-3.fc10 ----------------- * Fri May 30 18:00:00 2008 Dennis Gilmore - 2.0.0-3 - crypto.prf is in libdir not datadir snake-0.11-0.5.fc9 ------------------ * Fri May 16 18:00:00 2008 James Laska 0.11-0.5 - ticket#51 - Call ybin or zipl when appropriate after updating grubby - ticket#39 - add snake-install cmdline arg support - ticket#25 - added a snake/tui boot argument screen - ticket#52 - snake.tree _makename and __str__ result in the same name system-config-network-1.5.10-1.fc9 ---------------------------------- * Tue May 27 18:00:00 2008 Harald Hoyer - 1.5.9 - fixed console perms for Fedora <= 8 * Tue May 27 18:00:00 2008 Harald Hoyer - 1.5.10 - fixed Makefile.am * Fri May 16 18:00:00 2008 Harald Hoyer - 1.5.8 - copy info from DNS page into each ifcfg file (dcbw) telepathy-glib-0.7.9-1.fc10 --------------------------- * Fri May 30 18:00:00 2008 Brian Pepple - 0.7.9-1 - Update to 0.7.9. - Enable tests. tzdata-2008c-1.fc10 ------------------- * Fri May 30 18:00:00 2008 Petr Machata - 2008c-1 - Upstream 2008c - Mongolia changes zone - Pakistan DST is scheduled until Sep/1, instead of Aug/31 - Drop Morocco and Pakistan patches that are superseded by upstream - Fix a typo in Java subpackage name uim-1.5.0-1.fc10 ---------------- * Thu May 22 18:00:00 2008 Akira TAGOH - 1.5.0-1 - New upstream release. - Add xemacs-uim sub-package. - Qt4 immodule is available in uim-qt now. (#440172) - Build with --with-anthy-utf8 and --with-eb. - Rename uim-el and uim-el-common to emacs-uim and emacs-common-uim. wormux-0.8-1.fc10 ----------------- * Thu May 29 18:00:00 2008 Wart 0.8-1 - Update to 0.8 Summary: Added Packages: 11 Removed Packages: 0 Modified Packages: 34 Broken deps for i386 ---------------------------------------------------------- LabPlot-1.5.1.6-6.fc9.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libWand.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libMagick.so.10 avahi-ui-sharp-0.6.22-10.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 avahi-ui-sharp-0.6.22-10.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 basket-kontact-1.0.2-5.fc9.i386 requires libkpinterfaces.so.1 basket-kontact-1.0.2-5.fc9.i386 requires libkcal.so.2 basket-kontact-1.0.2-5.fc9.i386 requires libktnef.so.1 basket-kontact-1.0.2-5.fc9.i386 requires kdepim3 basket-kontact-1.0.2-5.fc9.i386 requires libkdepim.so.1 beagle-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-evolution-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-thunderbird-0.3.7-5.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.i386 requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.i386 requires libcamel-1.2.so.11 f-spot-0.4.3.1-1.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.i386 requires mono(glade-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(atk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(glade-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(pango-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(glade-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(pango-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gsf-sharp-0.8.1-7.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.i386 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.i386 requires mono(gdk-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.i386 requires mono(gtk-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.i386 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.i386 requires mono(gtk-sharp) = 0:2.10.0.0 kismet-extras-0.0.2007.10.R1-3.fc9.i386 requires libMagick.so.10 libopensync-plugin-kdepim-0.35-2.fc9.i386 requires libkcal.so.2 lsvpd-1.6.4-1.fc10.i386 requires libvpd_cxx-2.0.so.1 muine-0.8.8-9.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.i386 requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.i386 requires libgeos.so.2 smart-0.52-54.fc9.i386 requires smart-config taskjuggler-2.4.1-1.fc10.i386 requires libkcal.so.2 taskjuggler-2.4.1-1.fc10.i386 requires libktnef.so.1 taskjuggler-libs-2.4.1-1.fc10.i386 requires libkcal.so.2 tomboy-0.10.1-2.fc9.i386 requires mono(glib-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.i386 requires mono(pango-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.i386 requires mono(gdk-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.i386 requires mono(gtk-sharp) = 0:2.10.0.0 Broken deps for x86_64 ---------------------------------------------------------- LabPlot-1.5.1.6-6.fc9.i386 requires libMagick++.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libWand.so.10 LabPlot-1.5.1.6-6.fc9.i386 requires libMagick.so.10 LabPlot-1.5.1.6-6.fc9.x86_64 requires libMagick++.so.10()(64bit) LabPlot-1.5.1.6-6.fc9.x86_64 requires libMagick.so.10()(64bit) LabPlot-1.5.1.6-6.fc9.x86_64 requires libWand.so.10()(64bit) avahi-ui-sharp-0.6.22-10.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 avahi-ui-sharp-0.6.22-10.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 basket-kontact-1.0.2-5.fc9.x86_64 requires libkcal.so.2()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires libkdepim.so.1()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires libktnef.so.1()(64bit) basket-kontact-1.0.2-5.fc9.x86_64 requires kdepim3 basket-kontact-1.0.2-5.fc9.x86_64 requires libkpinterfaces.so.1()(64bit) beagle-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-evolution-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 beagle-thunderbird-0.3.7-5.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 evolution-brutus-1.2.11-2.fc9.i386 requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.i386 requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.i386 requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.x86_64 requires libWand.so.10()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.x86_64 requires libedataserver-1.2.so.9()(64bit) f-spot-0.4.3.1-1.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 freenx-server-0.7.2-8.fc10.x86_64 requires /usr/lib64/nx gbrainy-0.61-5.fc9.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(atk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(glade-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gsf-sharp-0.8.1-7.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 kismet-extras-0.0.2007.10.R1-3.fc9.x86_64 requires libMagick.so.10()(64bit) libopensync-plugin-kdepim-0.35-2.fc9.x86_64 requires libkcal.so.2()(64bit) lsvpd-1.6.4-1.fc10.x86_64 requires libvpd_cxx-2.0.so.1()(64bit) muine-0.8.8-9.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.x86_64 requires libgeos.so.2()(64bit) smart-0.52-54.fc9.x86_64 requires smart-config taskjuggler-2.4.1-1.fc10.x86_64 requires libkcal.so.2()(64bit) taskjuggler-2.4.1-1.fc10.x86_64 requires libktnef.so.1()(64bit) taskjuggler-libs-2.4.1-1.fc10.i386 requires libkcal.so.2 taskjuggler-libs-2.4.1-1.fc10.x86_64 requires libkcal.so.2()(64bit) tomboy-0.10.1-2.fc9.x86_64 requires mono(glib-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.x86_64 requires mono(gdk-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.x86_64 requires mono(pango-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.x86_64 requires mono(gtk-sharp) = 0:2.10.0.0 Broken deps for ppc ---------------------------------------------------------- LabPlot-1.5.1.6-6.fc9.ppc requires libMagick++.so.10 LabPlot-1.5.1.6-6.fc9.ppc requires libWand.so.10 LabPlot-1.5.1.6-6.fc9.ppc requires libMagick.so.10 avahi-ui-sharp-0.6.22-10.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 avahi-ui-sharp-0.6.22-10.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 banshee-0.99.2-2.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 basket-kontact-1.0.2-5.fc9.ppc requires libkpinterfaces.so.1 basket-kontact-1.0.2-5.fc9.ppc requires libkcal.so.2 basket-kontact-1.0.2-5.fc9.ppc requires libktnef.so.1 basket-kontact-1.0.2-5.fc9.ppc requires kdepim3 basket-kontact-1.0.2-5.fc9.ppc requires libkdepim.so.1 beagle-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 beagle-0.3.7-5.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 beagle-evolution-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 beagle-gnome-0.3.7-5.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 beagle-thunderbird-0.3.7-5.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 evolution-brutus-1.2.11-2.fc9.ppc requires libcamel-1.2.so.11 evolution-brutus-1.2.11-2.fc9.ppc requires libWand.so.10 evolution-brutus-1.2.11-2.fc9.ppc requires libMagick.so.10 evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-provider-1.2.so.11 evolution-zimbra-0.1.0-5.fc9.ppc requires libedataserver-1.2.so.9 evolution-zimbra-0.1.0-5.fc9.ppc requires libcamel-1.2.so.11 f-spot-0.4.3.1-1.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 f-spot-0.4.3.1-1.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.ppc requires mono(glade-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gbrainy-0.61-5.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 gecko-sharp2-0.12-7.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gnome-do-0.4.2.0-1.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(atk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(glade-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(pango-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gnome-sharp-2.16.1-1.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(glade-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(pango-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gnome-subtitles-0.8-2.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gsf-sharp-0.8.1-7.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.ppc requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.ppc requires mono(gdk-sharp) = 0:2.10.0.0 gtksourceview-sharp-2.0-25.fc7.ppc requires mono(gtk-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.ppc requires mono(glib-sharp) = 0:2.10.0.0 gtksourceview2-sharp-1.0-2.svn89788.fc10.ppc requires mono(gtk-sharp) = 0:2.10.0.0 kismet-extras-0.0.2007.10.R1-3.fc9.ppc requires libMagick.so.10 libopensync-plugin-kdepim-0.35-2.fc9.ppc requires libkcal.so.2 lsvpd-1.6.4-1.fc10.ppc requires libvpd_cxx-2.0.so.1 muine-0.8.8-9.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 muine-0.8.8-9.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.ppc requires libgeos.so.2 qgis-grass-0.9.1-5.fc9.ppc requires libgeos.so.2 smart-0.52-54.fc9.ppc requires smart-config taskjuggler-2.4.1-1.fc10.ppc requires libkcal.so.2 taskjuggler-2.4.1-1.fc10.ppc requires libktnef.so.1 taskjuggler-libs-2.4.1-1.fc10.ppc requires libkcal.so.2 taskjuggler-libs-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) tomboy-0.10.1-2.fc9.ppc requires mono(glib-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.ppc requires mono(pango-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.ppc requires mono(gdk-sharp) = 0:2.10.0.0 tomboy-0.10.1-2.fc9.ppc requires mono(gtk-sharp) = 0:2.10.0.0 wxMaxima-0.7.4-3.fc9.ppc requires maxima >= 0:5.13 Broken deps for ppc64 ---------------------------------------------------------- basket-kontact-1.0.2-5.fc9.ppc64 requires libkcal.so.2()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires libkdepim.so.1()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires libktnef.so.1()(64bit) basket-kontact-1.0.2-5.fc9.ppc64 requires kdepim3 basket-kontact-1.0.2-5.fc9.ppc64 requires libkpinterfaces.so.1()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libMagick.so.10()(64bit) evolution-brutus-1.2.11-2.fc9.ppc64 requires libWand.so.10()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-provider-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libcamel-1.2.so.11()(64bit) evolution-zimbra-0.1.0-5.fc9.ppc64 requires libedataserver-1.2.so.9()(64bit) kismet-extras-0.0.2007.10.R1-3.fc9.ppc64 requires libMagick.so.10()(64bit) libopensync-plugin-kdepim-0.35-2.fc9.ppc64 requires libkcal.so.2()(64bit) livecd-tools-017-1.fc9.ppc64 requires yaboot lsvpd-1.6.4-1.fc10.ppc64 requires libvpd_cxx-2.0.so.1()(64bit) perl-Catalyst-Model-LDAP-0.16-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-Plugin-StackTrace-0.07-3.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Catalyst-View-JSON-0.24-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Task-Weaken-1.02-2.fc8.noarch requires perl(:MODULE_COMPAT_5.8.8) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 ppc64-utils-0.14-2.fc9.ppc64 requires yaboot python-gasp-0.1.1-0.fc9.noarch requires python-pygame qgis-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) qgis-grass-0.9.1-5.fc9.ppc64 requires libgeos.so.2()(64bit) smart-0.52-54.fc9.ppc64 requires smart-config taskjuggler-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) taskjuggler-2.4.1-1.fc10.ppc64 requires libktnef.so.1()(64bit) taskjuggler-libs-2.4.1-1.fc10.ppc64 requires libkcal.so.2()(64bit) From Matt_Domsch at dell.com Sat May 31 12:24:22 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sat, 31 May 2008 07:24:22 -0500 Subject: Fedora x86_64 rawhide rebuild in mock status 2008-05-27 Message-ID: <20080531072422.A1480@humbolt.us.dell.com> Fedora Rawhide-in-Mock Build Results for x86_64 based on rawhide as of 5-27-2008 (it takes a few days to build 5700 packages twice). There is a proposal before FESCo to remove packages that Fail To Build >From Source (FTBFS)[1] from the distribution, if the package owner has no bug comments indicating it will be fixed in a reasonable amount of time before the next major release. This would take place immediately following the Alpha release[2]. Please comment on the thread on fedora-devel-list[3], or come to the FESCo meeting next Thursday[4], if you have concerns. [1] http://fedoraproject.org/wiki/FTBFS [2] http://fedoraproject.org/wiki/Schedule (shows F9 presently, extrapolate for F10) [3] https://www.redhat.com/archives/fedora-devel-list/2008-May/msg02369.html [4] http://fedoraproject.org/wiki/Development/SteeringCommittee/Meetings Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Total packages: 5722 Number failed to build: 378 Number expected to fail due to ExclusiveArch or ExcludeArch: 35 Leaving: 343 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 192 ---------------------------------- amanda-2.5.2p1-10.fc9 (build/make) rbrich ardour-2.4.1-1.fc9 (build/make) green,jwrdegoede astromenace-1.2-8.fc9 (build/make) limb axis-1.2.1-3jpp.8.fc9 (build/make) pcheung beagle-0.3.7-5.fc10 (build/make) drago01,drago01,psytux bmpx-0.40.13-11.fc9 (build/make) akahl boo-0.8.1.2865-4.fc9 (build/make) pfj brltty-3.9-2.2.fc9 (build/make) kasal cdo-1.0.8-2.fc9 (build/make) edhill cernlib-2006-29.fc9 (build/make) pertusus cernlib-g77-2006-29.fc9 (build/make) pertusus compat-db-4.5.20-5.fc9 (build/make) jnovy compface-1.5.2-7 (build/make) mschwendt condor-7.0.0-8.fc9 (build/make) matt contacts-0.8-3.fc10 (build/make) jkeating cpio-2.9-7.fc9 (build/make) ovasik cvs-1.11.22-13.fc9 (build/make) jmoskovc cyrus-imapd-2.3.11-1.fc9 (build/make) sharkcz db4-4.6.21-5.fc9 (build/make) jnovy dxpc-3.9.1-0.3.b1.fc9 (build/make) guthrie ecl-0.9j-2.fc9 (build/make) gemi epiphany-2.22.1.1-1.fc9 (build/make) gecko-maint erlang-R12B-1.1.fc9 (build/make) gemi evolution-brutus-1.2.11-2.fc9 (build/make) bpepple,colding evolution-remove-duplicates-0.0.3-3.fc9 (build/make) salimma evolution-zimbra-0.1.0-5.fc9 (build/make) mbarnes,mmahut expect-5.43.0-13.fc9 (build/make) vcrhonek fakechroot-2.5-13.fc9 (build/make) athimm fakeroot-1.6.4-16.fc9 (build/make) athimm Falcon-0.8.8-3.fc9 (build/make) salimma firewalk-5.0-2.fc9 (build/make) sindrepb fontmatrix-0.4.2-1.fc9 (build/make) pnemade f-spot-0.4.3.1-1.fc10 (build/make) orphan fusion-icon-0.1.0-0.2.5e2dc9git.fc9 (build/make) karlik galeon-2.0.5-1.fc9 (build/make) denis gauche-gl-0.4.4-3.fc9 (build/make) gemi gauche-gtk-0.4.1-17.fc9 (build/make) gemi gbrainy-0.61-5.fc9 (build/make) sereinit gcombust-0.1.55-13 (build/make) thias geronimo-specs-1.0-1.M2.2jpp.12 (build/make) fnasser gkrellm-wifi-0.9.12-7.fc9 (build/make) jwrdegoede glib-1.2.10-29.fc9 (build/make) rdieter gnome-applet-timer-2.0.1-1.fc9 (build/make) cwickert gnome-do-0.4.2.0-1.fc10 (build/make) sindrepb,sindrepb gnome-themes-2.23.1-1.fc10 (build/make) mclasen gnupg2-2.0.9-1.fc9 (build/make) rdieter,nalin gpgme-1.1.6-3.fc9 (build/make) rdieter gphoto2-2.4.0-10.fc9 (build/make) jnovy grads-1.9b4-23.fc9 (build/make) pertusus graphviz-2.16.1-0.5.fc9 (build/make) jima grass-6.3.0-3.fc10 (build/make) rezso,pertusus gridengine-6.1u4-1.fc10 (build/make) orion gstreamer-plugins-good-0.10.8-1.fc10 (build/make) ajax gtk+-1.2.10-61.fc9 (build/make) rdieter gtkglext-1.2.0-6.fc9 (build/make) corsepiu gtkmozembedmm-1.4.2.cvs20060817-17.fc9 (build/make) hguemar guilt-0.30-1.fc8 (build/make) sandeen hedgewars-0.9.3-1.fc10 (build/make) jwrdegoede HelixPlayer-1.0.9-2.fc9 (build/make) abompard hesiod-3.1.0-10 (build/make) nalin iksemel-1.3-4.fc9 (build/make) jcollie javasqlite-20080420-1.fc10 (build/make) scop jed-0.99.18-7.fc9 (build/make) notting junitperf-1.9.1-2jpp.1.fc7 (build/make) mwringe kdebluetooth-1.0-0.41.beta8.fc9 (build/make) gilboa,scop kickpim-0.5.3-14.fc9 (build/make) rdieter kleansweep-0.2.9-7.fc9 (build/make) chitlesh kst-1.6.0-2.fc10 (build/make) mtruch ladspa-1.12-9.fc9 (build/make) thomasvs lib765-0.4.1-3.fc9 (build/make) lucilanga,pfj libapreq2-2.09-0.15.rc2.fc9 (build/make) bojan libcdio-0.79-3.fc9 (build/make) adrian libdhcp-1.99.8-1.fc10 (build/make) dcantrel libfwbuilder-2.1.16-2.fc9 (build/make) ertzing libgii-1.0.2-6.fc9 (build/make) kwizart libidn-0.6.14-7 (build/make) jorton libitl-0.6.4-4.fc9 (build/make) izhar libjpeg-6b-41.fc9 (build/make) tgl libnet10-1.0.2a-14.fc9 (build/make) pertusus libopensync-0.36-2.fc9 (build/make) awjb libopensync-plugin-kdepim-0.35-2.fc9 (build/make) awjb libsigsegv-2.4-6.fc9 (build/make) rdieter libstroke-0.5.1-17.fc9 (build/make) chitlesh mapserver-5.0.2-2.fc9 (build/make) rezso,oliver,devrim mecab-0.97-1.fc9 (build/make) mtasaka mercurial-1.0-4.fc9 (build/make) nbecker,ausil,mmcgrath,nbecker mesa-7.1-0.31.fc9 (build/make) ajax,ajax mod_suphp-0.6.3-1.fc9 (build/make) ixs monodevelop-0.19-6.fc9 (build/make) pfj mono-ndoc-1.3.1-2.fc10 (build/make) spot mono-nunit22-2.2.10-3.fc10 (build/make) spot mono-sharpcvslib-0.35-2.fc10 (build/make) spot muine-0.8.8-9.fc9 (build/make) sindrepb muine-scrobbler-0.1.8-5.fc9 (build/make) sindrepb mysql-connector-java-3.1.12-5.fc9 (build/make) ifoox nant-0.85-21.fc9 (build/make) pfj nautilus-open-terminal-0.9-2.fc9 (build/make) pfrields nautilus-search-tool-0.2.2-3.fc9 (build/make) pfrields ncl-5.0.0-11.fc9 (build/make) orion nco-3.9.3-1.fc9 (build/make) edhill,pertusus netcdf-decoders-5.0.0-1.fc9 (build/make) orion,pertusus netcdf-perl-1.2.3-7.fc9 (build/make) orion,perl-sig,pertusus ngspice-17-14.fc9 (build/make) chitlesh ntfs-config-1.0-0.6.rc5.fc9 (build/make) laxathom ntl-5.4.2-2.fc9 (build/make) rdieter numpy-1.0.3.1-2.fc9 (build/make) jwilson,jspaleta ocaml-SDL-0.7.2-12.fc10 (build/make) rjones openhpi-subagent-2.3.4-2.fc10 (build/make) sharkcz openoffice.org-voikko-2.2-4.fc9 (build/make) vpv pam_abl-0.2.3-4.fc9 (build/make) adalloz,tmraz pdfedit-0.3.2-4.fc9 (build/make) bjohnson perl-Cache-Cache-1.05-2.fc9 (build/make) steve,perl-sig perl-Class-MethodMaker-2.10-3.fc9 (build/make) dgregor,perl-sig perl-Convert-UUlib-1.09-4.fc9 (build/make) nim,perl-sig,robert perl-Crypt-Simple-0.06-5.fc9 (needs_perl_ExtUtils_MakeMaker) allisson perl-CSS-1.08-2.fc10 (build/make) terjeros perl-DBD-SQLite-1.14-7.fc9 (build/make) kasal,perl-sig,steve,rnorwood,mmaslano perl-GD-SVG-0.28-4.fc9 (build/make) alexlan,perl-sig perl-Gnome2-GConf-1.044-3.fc9 (build/make) cweyl,perl-sig perl-Graph-0.84-2.fc9 (build/make) alexlan,perl-sig perl-Log-Dispatch-FileRotate-1.16-2.fc9 (build/make) spot,perl-sig,corsepiu perl-MIME-Lite-3.01-6.fc9 (build/make) mmcgrath,perl-sig perl-mogilefs-server-2.17-5.fc9 (build/make) ruben perl-Net-CUPS-0.55-4.fc9 (build/make) cweyl,perl-sig perl-Net-Netmask-1.9015-1.fc8 (build/make) wtogami,perl-sig perl-Net-Packet-3.25-3.fc9 (build/make) sindrepb perl-Net-Server-0.97-2.fc9 (build/make) nim,perl-sig perl-Net-Write-1.00-3.fc9 (build/make) sindrepb perl-OLE-Storage_Lite-0.15-2.fc9 (build/make) spot,perl-sig perl-Pod-POM-0.17-9.fc9 (build/make) spot,perl-sig perl-Spreadsheet-WriteExcel-2.20-2.fc9 (build/make) spot,perl-sig perl-SVG-2.37-1.fc9 (build/make) alexlan,perl-sig perl-Text-CharWidth-0.04-4.fc9 (build/make) athimm perl-Text-Kakasi-2.04-8.fc9 (build/make) tagoh,perl-sig perl-Text-Shellwords-1.08-4.fc9 (build/make) alexlan,perl-sig perl-Text-WrapI18N-0.06-3.fc9 (build/make) athimm perl-Time-modules-2006.0814-2.fc9 (build/make) kaboom,perl-sig,xavierb perl-Unicode-Map-0.112-14.fc9 (build/make) abompard,perl-sig perl-Unicode-Map8-0.12-17.fc9 (build/make) abompard,perl-sig perl-Unicode-MapUTF8-1.11-6.fc8 (build/make) abompard,perl-sig perl-Unicode-String-2.09-8.fc9 (build/make) abompard,perl-sig perl-XML-LibXSLT-1.63-5.fc9 (build/make) shishz,perl-sig perl-XML-XPath-1.13-6.fc9 (build/make) kasal,perl-sig,rnorwood,mmaslano powerman-1.0.32-5.fc9 (build/make) jwilson powerpc-utils-papr-1.0.4-3.fc9 (build/make) dwmw2,rrakus psacct-6.3.2-50.fc9 (build/make) varekova pth-2.0.7-6 (build/make) mschwendt python-imaging-1.1.6-9.fc9 (build/make) jamatos,jgranado python-xlrd-0.6.1-5.fc9 (build/make) ondrejj,jafo qcad-2.0.5.0-8.fc9 (build/make) gemi qgis-0.9.1-5.fc9 (build/make) silfreed,rezso qmmp-0.1.5-2.fc9 (build/make) kvolny,jwrdegoede qof-0.7.5-2.fc9 (build/make) limb qscintilla-2.2-1.fc10 (build/make) rdieter rapidsvn-0.9.6-1.fc9 (build/make) timj rekall-2.4.6-4.fc9 (build/make) spot repoman-0.9-3.fc8 (build/make) dcantrel,clumens ricci-0.13.0-3.fc9 (build/make) rmccabe rkward-0.5.0b-2.fc10 (build/make) pingou R-Matrix-0.999375-4.fc9 (build/make) tmoertel rss-glx-0.8.1.p-19.fc9 (build/make) nphilipp ruby-1.8.6.114-1.fc9 (build/make) tagoh ruby-gnome2-0.16.0-28.fc9 (build/make) allisson ruby-mecab-0.97-1.fc9 (build/make) mtasaka samba-3.2.0-1.pre3.10.fc10 (build/make) simo,gd ScientificPython-2.6-12.fc9 (build/make) jspaleta slrn-0.9.8.1pl1-8.20070716cvs.fc9 (build/make) mlichvar smarteiffel-2.3-2.fc9 (build/make) gemi sudo-1.6.9p13-6.fc10 (build/make) pvrabec,kzak svnmailer-1.0.8-3.fc7 (build/make) mfleming taglib-sharp-2.0.3.0-4.fc10 (build/make) spot taskjuggler-2.4.1-1.fc10 (build/make) ovasik tclchecker-1.4-4.20061030cvs.fc9 (build/make) wart tcldebugger-1.4-6.20061030cvs.fc9 (build/make) wart tcpdump-3.9.8-4.fc9 (build/make) mlichvar tomboy-0.10.1-2.fc9 (build/make) rstrode vorbis-tools-1.2.0-1.fc9 (build/make) zprikryl,jwrdegoede vtk-5.0.4-21.fc9 (build/make) athimm,orion widelands-0-0.11.build12.fc9 (build/make) karlik wkf-1.3.11-2.fc9 (build/make) mtasaka wlassistant-0.5.7-7.fc9 (build/make) spot writer2latex-0.5-2.fc9 (build/make) caolanm xbase-2.0.0-11.fc9 (build/make) spot xemacs-21.5.28-6.fc9 (build/make) scop xemacs-packages-extra-20070427-1.fc8 (build/make) scop xfce4-mailwatch-plugin-1.0.1-8.fc9 (build/make) cwickert xfce4-verve-plugin-0.3.5-4.fc9 (build/make) cwickert,kevin xlhtml-0.5-8.fc9 (build/make) abompard xmms-cdread-0.14-13.fc9 (build/make) jsoeterb xscorch-0.2.0-12.fc8 (build/make) mgarski xscreensaver-5.05-3.fc9 (build/make) mtasaka xsupplicant-1.2.8-6.fc9.2 (build/make) spot With bugs filed: 151 ---------------------------------- aiksaurus-1.2.1-15.fc6 ['434484 ASSIGNED', '440795 NEW'] (build/make) uwog anaconda-11.4.1.1-1 ['235757 ASSIGNED', '235757 ASSIGNED', '385201 NEW', '442431 MODIFIED', '442832 MODIFIED', '375011 NEW', '431757 NEW', '443045 NEW', '443422 NEW', '443041 NEW', '441018 NEW', '344301 NEW', '6175 ASSIGNED', '35236 ASSIGNED', '437972 ASSIGNED', '444894 ASSIGNED', '447015 MODIFIED', '440055 MODIFIED', '441706 MODIFIED', '244431 NEW', '446126 NEW', '442461 NEW', '444490 NEW', '441708 MODIFIED', '441846 MODIFIED', '442751 MODIFIED', '441470 MODIFIED', '444127 NEEDINFO', '444203 ASSIGNED', '444127 NEEDINFO', '350941 NEW'] (build/make) anaconda-maint astyle-1.21-6.fc8 ['440797 NEW', '433971 ASSIGNED'] (build/make) addutko,mtasaka aterm-1.0.1-2.fc9 ['440779 ASSIGNED'] (build/make) awjb bacula-2.0.3-13.fc9 ['440905 NEW'] (build/make) ixs,mmcgrath banshee-0.99.2-2.fc10 ['440860 ASSIGNED'] (build/make) nigelj,spot basket-1.0.2-5.fc9 ['433960 ASSIGNED'] (build/make) abompard bes-3.5.3-3.fc9 ['440807 NEW', '434360 ASSIGNED'] (build/make) pertusus bitbake-1.8.8-1.fc8 ['440562 NEW'] (build/make) ixs blam-1.8.3-13.fc9 ['241850 NEW', '434382 ASSIGNED', '434382 ASSIGNED'] (build/make) alexlan,sindrepb blobby-0.6-0.7.a.fc8 ['440725 NEW', '433961 ASSIGNED'] (build/make) abompard brutus-keyring-0.9.0-6.fc8 ['440809 NEW', '434007 ASSIGNED'] (build/make) bpepple,colding callweaver-1.2-0.4.rc5.20071230.fc9 ['440927 NEW', '434066 ASSIGNED'] (build/make) dwmw2 camstream-0.26.3-12.fc8 ['440878 NEW', '434345 ASSIGNED'] (build/make) nomis80 cdcollect-0.6.0-5.fc9 ['309191 ASSIGNED'] (build/make) sharkcz clisp-2.43-5.fc9 ['238954 ASSIGNED', '166347 ASSIGNED', '434101 ASSIGNED'] (build/make) gemi,green compat-erlang-R10B-11.9.fc9 ['434102 ASSIGNED'] (build/make) gemi conexusmm-0.5.0-3.fc7 ['440847 NEW'] (build/make) rvinyard coolkey-1.1.0-6.fc9 ['440753 NEW'] (build/make) rrelyea,jmagne coreutils-6.11-4.fc10 ['243588 ASSIGNED', '197064 ASSIGNED', '202823 ASSIGNED', '239501 ASSIGNED'] (build/make) ovasik,twaugh crystal-clear-20050622-6.fc8 ['440851 NEW'] (build/make) chitlesh dap-freeform_handler-3.7.7-2.fc9 ['440885 NEW', '434362 ASSIGNED'] (build/make) pertusus dap-hdf4_handler-3.7.7-3.fc9 ['440714 NEW', '434363 ASSIGNED'] (build/make) pertusus dar-2.3.6-3.fc9 ['440746 NEW', '434519 ASSIGNED'] (build/make) xris djvulibre-3.5.20-2.fc9 ['440910 NEW'] (build/make) thias dmraid-1.0.0.rc14-6.fc9 ['434310 ASSIGNED'] (build/make) lvm-team,agk,mornfall,bmr,mbroz,mauelsha,dwysocha dosfstools-2.11-9.fc9 ['448247 NEW'] (build/make) kasal elektra-0.6.10-6.fc9 ['434364 ASSIGNED'] (build/make) pertusus,kwizart fish-1.23.0-2.fc9 ['440724 NEW'] (build/make) ascii,oliver fluxstyle-1.0.1-2.fc7 ['440757 NEW'] (build/make) errr fonttools-2.0-0.11.20060223cvs.fc7 ['434409 ASSIGNED'] (build/make) roozbeh,fonts-sig fontypython-0.2.0-6.fc7 ['440756 ASSIGNED'] (build/make) cr33dog,fonts-sig freeipmi-0.5.1-3.fc9 ['440875 NEW'] (build/make) pknirsch fwbuilder-2.1.16-2.fc9 ['440846 NEW'] (build/make) ertzing gauche-0.8.13-1.fc9 ['253365 ASSIGNED'] (build/make) gemi gazpacho-0.7.2-2.fc8 ['440859 NEW'] (build/make) icon gdmap-0.7.5-6.fc6 ['440889 NEW', '434529 ASSIGNED'] (build/make) splinux ghc-6.8.2-2.fc9 ['239713 ASSIGNED', '239713 ASSIGNED', '239713 ASSIGNED', '434004 ASSIGNED', '433670 NEW'] (build/make) bos,petersen,ynemoy gl-117-1.3.2-4.fc7 ['434443 ASSIGNED'] (build/make) steve gnome-applet-tvn24-0.2.8-3.fc9 ['440715 NEW', '434300 ASSIGNED'] (build/make) orphan gnome-specimen-0.3-1.fc8 ['440868 NEW'] (build/make) splinux gnome-subtitles-0.8-2.fc10 ['447388 NEW'] (build/make) belegdol gnu-smalltalk-3.0.1-3.fc9 ['286261 NEW', '436656 NEW'] (build/make) s4504kr,laxathom gprolog-1.3.0-12.fc9 ['440945 NEW', '440945 NEW', '434421 ASSIGNED'] (build/make) s4504kr gpsim-0.22.0-5.fc8 ['440835 NEW', '434061 ASSIGNED'] (build/make) dionysos gresistor-0.0.1-11.fc8 ['440866 NEW'] (build/make) chitlesh gstm-1.2-6.fc7 ['440719 NEW', '434531 ASSIGNED'] (build/make) splinux gtk2hs-0.9.12.1-8.fc9 ['440493 NEW', '434005 ASSIGNED'] (build/make) bos,petersen gtk-sharp-1.0.10-12.fc7 ['434373 ASSIGNED'] (build/make) pfj gtksourceview-sharp-2.0-25.fc7 ['434374 ASSIGNED'] (build/make) pfj gwget-0.99-5.fc9 ['440744 NEW'] (build/make) cwickert ht2html-2.0-5.fc6 ['440916 NEW'] (build/make) ifoox Inventor-2.1.5-31.fc9 ['245192 NEW', '245192 NEW', '434035 ASSIGNED'] (build/make) corsepiu itpp-4.0.0-2.fc9 ['440939 NEW', '434076 ASSIGNED'] (build/make) edhill jabbin-2.0-0.6.beta2a.fc9 ['440730 NEW'] (build/make) kurzawa jgroups-2.2.9.2-3jpp.2 ['434352 ASSIGNED'] (build/make) dbhole kazehakase-0.5.4-4.fc9 ['402641 NEW', '402641 NEW'] (build/make) mtasaka kismet-0.0.2007.10.R1-3.fc9 ['434084 ASSIGNED'] (build/make) ensc klear-0.7.0-1.svn113.fc9 ['440755 NEW'] (build/make) trasher koffice-langpack-1.6.3-1.fc8 ['440758 ASSIGNED'] (build/make) awjb kphotobymail-0.4.1-1.fc7 ['440873 ASSIGNED'] (build/make) kushal ktechlab-0.3.69-5.fc8 ['434030 ASSIGNED'] (build/make) chitlesh LabPlot-1.5.1.6-6.fc9 ['434019 ASSIGNED'] (build/make) chitlesh,chitlesh,tnorth lam-7.1.2-11.fc9 ['440926 NEW', '434065 ASSIGNED'] (build/make) dledford lat-1.2.3-3.fc9 ['241911 ASSIGNED'] (build/make) pghmcfc libdap-3.7.10-2.fc9 ['440854 NEW', '434366 ASSIGNED'] (build/make) pertusus libFoundation-1.1.3-11.fc9 ['440564 NEW'] (build/make) athimm libgtksourceviewmm-0.3.1-1.fc8 ['440877 NEW', '434532 ASSIGNED'] (build/make) splinux libnc-dap-3.7.0-9.fc9 ['440768 NEW', '434367 ASSIGNED'] (build/make) pertusus libopensync-plugin-google-calendar-0.35-2.fc9 ['433995 ASSIGNED'] (build/make) awjb libzzub-0.2.3-12.fc9 ['293751 NEW', '293751 NEW'] (build/make) akahl,mtasaka lilypond-2.10.33-1.fc8 ['440826 NEW', '434394 ASSIGNED'] (build/make) qspencer lineakd-0.9-5.fc6 ['440774 NEW', '434523 ASSIGNED'] (build/make) xris lineak-defaultplugin-0.9-2.fc6 ['440821 NEW', '434520 ASSIGNED'] (build/make) xris lineak-xosdplugin-0.9-2.fc6 ['440929 NEW', '434522 ASSIGNED'] (build/make) xris linpsk-0.9-3.fc9 ['440778 NEW'] (build/make) bjensen,sindrepb,sconklin linux-atm-2.5.0-5 ['434069 ASSIGNED'] (build/make) dwmw2 log4net-1.2.10-4.fc9 ['434700 ASSIGNED'] (build/make) snecker lostirc-0.4.6-3.fc8 ['440921 NEW'] (build/make) splinux,splinux mbuffer-20070502-1.fc7 ['440836 ASSIGNED', '433969 ASSIGNED'] (build/make) adalloz mimetic-0.9.3-2.fc8 ['440838 NEW', '434086 ASSIGNED'] (build/make) ensc mkinitrd-6.0.52-2.fc9 ['245645 ASSIGNED', '245645 ASSIGNED', '296361 NEW', '198387 ASSIGNED', '443082 NEW', '424591 ASSIGNED', '424591 ASSIGNED', '442811 ASSIGNED'] (build/make) pjones,wtogami,dcantrel moto4lin-0.3-6.fc7 ['440713 NEW', '434135 ASSIGNED'] (build/make) jafo mtd-utils-1.1.0-2.fc8 ['440845 NEW', '434070 ASSIGNED'] (build/make) dwmw2,jwboyer multiget-1.1.4-7.fc8 ['440801 ASSIGNED', '433980 ASSIGNED'] (build/make) orphan,mtasaka mx-2.0.6-3 ['434325 ASSIGNED'] (build/make) misa mx4j-3.0.1-6jpp.4 ['246183 NEW', '440731 NEW', '434097 ASSIGNED'] (build/make) fnasser MyPasswordSafe-0.6.7-4.20061216.fc9 ['442840 NEW'] (build/make) ertzing mysql-gui-tools-5.0r12-5.fc9 ['440734 NEW', '433987 ASSIGNED'] (build/make) ausil nethack-vultures-2.1.0-10.fc8 ['434317 ASSIGNED'] (build/make) meme oggconvert-0.3.0-14.fc9 ['440943 NEW'] (build/make) ngompa oooqs2-1.0-3.fc6 ['433988 ASSIGNED'] (build/make) ausil orpie-1.4.3-5.fc6 ['440823 NEW', '434524 ASSIGNED'] (build/make) xris pan-0.132-2.fc8 ['433970 ASSIGNED'] (build/make) adalloz,mpeters pcmanx-gtk2-0.3.5-9.336svn.fc7 ['440745 NEW', '434299 ASSIGNED'] (open_missing_mode) leo pdsh-2.11-6.fc9 ['440811 NEW'] (build/make) kg6fnk pekwm-0.1.5-5.fc7 ['440883 NEW', '434089 ASSIGNED'] (build/make) errr perl-5.10.0-24.fc10 ['198399 NEW'] (build/make) mmaslano,spot,corsepiu,rnorwood,kasal petitboot-0.0.1-7.fc8 ['440853 NEW', '434071 ASSIGNED'] (build/make) dwmw2,jwboyer pic2aa-0.2.1-3.fc9 ['440764 NEW'] (build/make) kurzawa piklab-0.15.0-1.fc9 ['434032 ASSIGNED'] (build/make) chitlesh,dionysos plague-0.4.4.1-4.fc7 ['443709 NEW', '440874 NEW'] (build/make) dcbw plotmm-0.1.2-6.fc9 ['440563 NEW'] (build/make) hguemar plplot-5.9.0-1.fc9 ['241233 ASSIGNED', '433913 NEW'] (build/make) orion proftpd-1.3.1-3.fc9 ['440729 NEW'] (build/make) thias psi-0.11-4.fc9 ['440737 NEW'] (build/make) abompard python-dialog-2.7-7.fc8 ['440819 NEW'] (build/make) abompard python-durus-3.5-3.fc7 ['440781 NEW', '434427 MODIFIED'] (build/make) shahms python-memcached-1.39-1.fc8 ['440931 NEW'] (build/make) jafo python-pydns-2.3.0-5.fc7 ['440912 NEW'] (build/make) jafo python-pyspf-2.0.3-1.fc8 ['440793 NEW'] (build/make) jafo python-reportlab-2.1-2.fc9 ['440827 NEW'] (build/make) bpepple python-simpletal-4.1-5.fc7 ['440930 NEW'] (build/make) shahms python-tpg-3.1.0-4.fc7 ['440763 NEW'] (build/make) shahms python-urljr-1.0.1-1.fc7 ['440901 NEW'] (build/make) jcollie pyzor-0.4.0-11.fc7 ['440790 NEW'] (build/make) ixs qa-assistant-0.4.90.5-2.fc6 ['440914 ASSIGNED'] (build/make) toshio qca-1.0-10.fc9 ['440850 NEW'] (build/make) abompard qca2-2.0.0-2.fc9 ['440940 NEW'] (build/make) abompard qca-gnupg-2.0.0-0.2.beta1.fc9 ['440743 NEW'] (build/make) abompard qca-ossl-2.0.0-0.4.beta3.fc9 ['440908 NEW'] (build/make) abompard qca-tls-1.0-13.fc9 ['440909 NEW'] (build/make) abompard qgo-1.5.4r2-1.fc9 ['440728 NEW'] (build/make) kaboom qps-1.9.19-0.2.b.fc7 ['440904 NEW', '434312 ASSIGNED'] (build/make) makghosh qsynth-0.2.5-7.fc9 ['440736 NEW'] (build/make) nando qtiplot-0.9-8.fc9 ['440844 NEW', '434100 ASSIGNED'] (build/make) frankb QuantLib-0.9.0-5.fc9 ['440934 NEW', '440934 NEW'] (build/make) spot ruby-bdb-0.6.0-1.fc7 ['440882 NEW', '434090 ASSIGNED'] (build/make) errr rudeconfig-5.0.5-1.fc7 ['440848 NEW', '434131 ASSIGNED'] (build/make) homeless rxvt-unicode-9.02-2.fc9 ['440789 ASSIGNED'] (build/make) awjb sbcl-1.0.13-1.fc9 ['448734 NEW', '434401 ASSIGNED'] (build/make) rdieter,green sblim-wbemcli-1.5.1-5.fc7 ['440893 NEW', '434129 ASSIGNED'] (build/make) hamzy scim-skk-0.5.2-8.fc6 ['440863 NEW', '434419 ASSIGNED'] (build/make) ryo scim-tomoe-0.6.0-2.fc8 ['434420 ASSIGNED'] (build/make) ryo,petersen scribus-1.3.4-5.fc9 ['440766 ASSIGNED'] (build/make) awjb scrip-1.4-9.fc8 ['440769 NEW', '434079 ASSIGNED'] (build/make) edhill selinux-policy-3.3.1-45.fc10 ['391451 NEW'] (build/make) dwalsh,jkubin seq24-0.8.7-8.fc8 ['440363 ASSIGNED', '434123 ASSIGNED'] (build/make) green showimg-0.9.5-16.fc9 ['440890 NEW', '433966 ASSIGNED'] (build/make) abompard sos-1.8-1.fc8 ['440839 NEW'] (build/make) navid soundtracker-0.6.8-2.fc6 ['440767 NEW', '434425 ASSIGNED'] (build/make) seg straw-0.27-12.fc9 ['440806 ASSIGNED'] (build/make) subhodip supertux-0.3.1-1.fc9 ['440816 NEW', '434445 ASSIGNED'] (build/make) steve synaptics-0.14.6-7.fc9 ['437039 ASSIGNED'] (build/make) krh syslinux-3.61-2.fc9 ['444291 ASSIGNED'] (build/make) pjones tomcat5-5.5.26-1jpp.2.fc9 ['198470 NEEDINFO'] (build/make) devrim,devrim trousers-0.3.1-5.fc9 ['440733 NEW', '434267 ASSIGNED'] (build/make) key,ejratl xen-3.2.0-10.fc9 ['442052 NEW', '433921 NEW'] (build/make) xen-maint,berrange xml-commons-resolver-1.1-1jpp.12 ['432075 NEW', '434098 ASSIGNED'] (build/make) fnasser xorg-x11-fonts-7.2-6.fc9 ['437689 ASSIGNED', '444377 ASSIGNED'] (build/make) xgl-maint,fonts-sig yoltia-0.22.1-2.fc9 ['440935 NEW'] (build/make) kurzawa ---------------------------------- Packages by owner: abompard: HelixPlayer,basket,blobby,perl-Unicode-Map,perl-Unicode-Map8,perl-Unicode-MapUTF8,perl-Unicode-String,psi,python-dialog,qca,qca-gnupg,qca-ossl,qca-tls,qca2,showimg,xlhtml adalloz: mbuffer,pam_abl,pan addutko: astyle adrian: libcdio agk: dmraid ajax: gstreamer-plugins-good,mesa,mesa akahl: bmpx,libzzub alexlan: blam,perl-GD-SVG,perl-Graph,perl-SVG,perl-Text-Shellwords allisson: perl-Crypt-Simple,ruby-gnome2 anaconda-maint: anaconda ascii: fish athimm: fakechroot,fakeroot,libFoundation,perl-Text-CharWidth,perl-Text-WrapI18N,vtk ausil: mercurial,mysql-gui-tools,oooqs2 awjb: aterm,koffice-langpack,libopensync,libopensync-plugin-google-calendar,libopensync-plugin-kdepim,rxvt-unicode,scribus belegdol: gnome-subtitles berrange: xen bjensen: linpsk bjohnson: pdfedit bmr: dmraid bojan: libapreq2 bos: ghc,gtk2hs bpepple: brutus-keyring,evolution-brutus,python-reportlab caolanm: writer2latex chitlesh: LabPlot,LabPlot,crystal-clear,gresistor,kleansweep,ktechlab,libstroke,ngspice,piklab clumens: repoman colding: brutus-keyring,evolution-brutus corsepiu: Inventor,gtkglext,perl,perl-Log-Dispatch-FileRotate cr33dog: fontypython cweyl: perl-Gnome2-GConf,perl-Net-CUPS cwickert: gnome-applet-timer,gwget,xfce4-mailwatch-plugin,xfce4-verve-plugin dbhole: jgroups dcantrel: libdhcp,mkinitrd,repoman dcbw: plague denis: galeon devrim: mapserver,tomcat5,tomcat5 dgregor: perl-Class-MethodMaker dionysos: gpsim,piklab dledford: lam drago01: beagle,beagle dwalsh: selinux-policy dwmw2: callweaver,linux-atm,mtd-utils,petitboot,powerpc-utils-papr dwysocha: dmraid edhill: cdo,itpp,nco,scrip ejratl: trousers ensc: kismet,mimetic errr: fluxstyle,pekwm,ruby-bdb ertzing: MyPasswordSafe,fwbuilder,libfwbuilder fnasser: geronimo-specs,mx4j,xml-commons-resolver fonts-sig: fonttools,fontypython,xorg-x11-fonts frankb: qtiplot gd: samba gecko-maint: epiphany gemi: clisp,compat-erlang,ecl,erlang,gauche,gauche-gl,gauche-gtk,qcad,smarteiffel gilboa: kdebluetooth green: ardour,clisp,sbcl,seq24 guthrie: dxpc hamzy: sblim-wbemcli hguemar: gtkmozembedmm,plotmm homeless: rudeconfig icon: gazpacho ifoox: ht2html,mysql-connector-java ixs: bacula,bitbake,mod_suphp,pyzor izhar: libitl jafo: moto4lin,python-memcached,python-pydns,python-pyspf,python-xlrd jamatos: python-imaging jcollie: iksemel,python-urljr jgranado: python-imaging jima: graphviz jkeating: contacts jkubin: selinux-policy jmagne: coolkey jmoskovc: cvs jnovy: compat-db,db4,gphoto2 jorton: libidn jsoeterb: xmms-cdread jspaleta: ScientificPython,numpy jwboyer: mtd-utils,petitboot jwilson: numpy,powerman jwrdegoede: ardour,gkrellm-wifi,hedgewars,qmmp,vorbis-tools kaboom: perl-Time-modules,qgo karlik: fusion-icon,widelands kasal: brltty,dosfstools,perl,perl-DBD-SQLite,perl-XML-XPath kevin: xfce4-verve-plugin key: trousers kg6fnk: pdsh krh: synaptics kurzawa: jabbin,pic2aa,yoltia kushal: kphotobymail kvolny: qmmp kwizart: elektra,libgii kzak: sudo laxathom: gnu-smalltalk,ntfs-config leo: pcmanx-gtk2 limb: astromenace,qof lucilanga: lib765 lvm-team: dmraid makghosh: qps matt: condor mauelsha: dmraid mbarnes: evolution-zimbra mbroz: dmraid mclasen: gnome-themes meme: nethack-vultures mfleming: svnmailer mgarski: xscorch misa: mx mlichvar: slrn,tcpdump mmahut: evolution-zimbra mmaslano: perl,perl-DBD-SQLite,perl-XML-XPath mmcgrath: bacula,mercurial,perl-MIME-Lite mornfall: dmraid mpeters: pan mschwendt: compface,pth mtasaka: astyle,kazehakase,libzzub,mecab,multiget,ruby-mecab,wkf,xscreensaver mtruch: kst mwringe: junitperf nalin: gnupg2,hesiod nando: qsynth navid: sos nbecker: mercurial,mercurial ngompa: oggconvert nigelj: banshee nim: perl-Convert-UUlib,perl-Net-Server nomis80: camstream notting: jed nphilipp: rss-glx oliver: fish,mapserver ondrejj: python-xlrd orion: gridengine,ncl,netcdf-decoders,netcdf-perl,plplot,vtk orphan: f-spot,gnome-applet-tvn24,multiget ovasik: coreutils,cpio,taskjuggler pcheung: axis perl-sig: netcdf-perl,perl-Cache-Cache,perl-Class-MethodMaker,perl-Convert-UUlib,perl-DBD-SQLite,perl-GD-SVG,perl-Gnome2-GConf,perl-Graph,perl-Log-Dispatch-FileRotate,perl-MIME-Lite,perl-Net-CUPS,perl-Net-Netmask,perl-Net-Server,perl-OLE-Storage_Lite,perl-Pod-POM,perl-SVG,perl-Spreadsheet-WriteExcel,perl-Text-Kakasi,perl-Text-Shellwords,perl-Time-modules,perl-Unicode-Map,perl-Unicode-Map8,perl-Unicode-MapUTF8,perl-Unicode-String,perl-XML-LibXSLT,perl-XML-XPath pertusus: bes,cernlib,cernlib-g77,dap-freeform_handler,dap-hdf4_handler,elektra,grads,grass,libdap,libnc-dap,libnet10,nco,netcdf-decoders,netcdf-perl petersen: ghc,gtk2hs,scim-tomoe pfj: boo,gtk-sharp,gtksourceview-sharp,lib765,monodevelop,nant pfrields: nautilus-open-terminal,nautilus-search-tool pghmcfc: lat pingou: rkward pjones: mkinitrd,syslinux pknirsch: freeipmi pnemade: fontmatrix psytux: beagle pvrabec: sudo qspencer: lilypond rbrich: amanda rdieter: glib,gnupg2,gpgme,gtk+,kickpim,libsigsegv,ntl,qscintilla,sbcl rezso: grass,mapserver,qgis rjones: ocaml-SDL rmccabe: ricci rnorwood: perl,perl-DBD-SQLite,perl-XML-XPath robert: perl-Convert-UUlib roozbeh: fonttools rrakus: powerpc-utils-papr rrelyea: coolkey rstrode: tomboy ruben: perl-mogilefs-server rvinyard: conexusmm ryo: scim-skk,scim-tomoe s4504kr: gnu-smalltalk,gprolog salimma: Falcon,evolution-remove-duplicates sandeen: guilt sconklin: linpsk scop: javasqlite,kdebluetooth,xemacs,xemacs-packages-extra seg: soundtracker sereinit: gbrainy shahms: python-durus,python-simpletal,python-tpg sharkcz: cdcollect,cyrus-imapd,openhpi-subagent shishz: perl-XML-LibXSLT silfreed: qgis simo: samba sindrepb: blam,firewalk,gnome-do,gnome-do,linpsk,muine,muine-scrobbler,perl-Net-Packet,perl-Net-Write snecker: log4net splinux: gdmap,gnome-specimen,gstm,libgtksourceviewmm,lostirc,lostirc spot: QuantLib,banshee,mono-ndoc,mono-nunit22,mono-sharpcvslib,perl,perl-Log-Dispatch-FileRotate,perl-OLE-Storage_Lite,perl-Pod-POM,perl-Spreadsheet-WriteExcel,rekall,taglib-sharp,wlassistant,xbase,xsupplicant steve: gl-117,perl-Cache-Cache,perl-DBD-SQLite,supertux subhodip: straw tagoh: perl-Text-Kakasi,ruby terjeros: perl-CSS tgl: libjpeg thias: djvulibre,gcombust,proftpd thomasvs: ladspa timj: rapidsvn tmoertel: R-Matrix tmraz: pam_abl tnorth: LabPlot toshio: qa-assistant trasher: klear twaugh: coreutils uwog: aiksaurus varekova: psacct vcrhonek: expect vpv: openoffice.org-voikko wart: tclchecker,tcldebugger wtogami: mkinitrd,perl-Net-Netmask xavierb: perl-Time-modules xen-maint: xen xgl-maint: xorg-x11-fonts xris: dar,lineak-defaultplugin,lineak-xosdplugin,lineakd,orpie ynemoy: ghc zprikryl: vorbis-tools -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From Matt_Domsch at dell.com Sat May 31 12:25:28 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sat, 31 May 2008 07:25:28 -0500 Subject: Fedora i386 rawhide rebuild in mock status 2008-05-27 Message-ID: <20080531072528.A2064@humbolt.us.dell.com> Fedora Rawhide-in-Mock Build Results for i386 based on rawhide as of 5-27-2008 (it takes a few days to build 5700 packages twice). There is a proposal before FESCo to remove packages that Fail To Build >From Source (FTBFS)[1] from the distribution, if the package owner has no bug comments indicating it will be fixed in a reasonable amount of time before the next major release. This would take place immediately following the Alpha release[2]. Please comment on the thread on fedora-devel-list[3], or come to the FESCo meeting next Thursday[4], if you have concerns. [1] http://fedoraproject.org/wiki/FTBFS [2] http://fedoraproject.org/wiki/Schedule (shows F9 presently, extrapolate for F10) [3] https://www.redhat.com/archives/fedora-devel-list/2008-May/msg02369.html [4] http://fedoraproject.org/wiki/Development/SteeringCommittee/Meetings Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Total packages: 5723 Number failed to build: 308 Number expected to fail due to ExclusiveArch or ExcludeArch: 12 Leaving: 296 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 157 ---------------------------------- amanda-2.5.2p1-10.fc9 (build/make) rbrich ardour-2.4.1-1.fc9 (build/make) green,jwrdegoede astromenace-1.2-8.fc9 (build/make) limb beagle-0.3.7-5.fc10 (build/make) drago01,drago01,psytux bmpx-0.40.13-11.fc9 (build/make) akahl brltty-3.9-2.2.fc9 (build/make) kasal cdo-1.0.8-2.fc9 (build/make) edhill cernlib-2006-29.fc9 (build/make) pertusus cernlib-g77-2006-29.fc9 (build/make) pertusus compat-db-4.5.20-5.fc9 (build/make) jnovy compface-1.5.2-7 (build/make) mschwendt condor-7.0.0-8.fc9 (build/make) matt cpio-2.9-7.fc9 (build/make) ovasik db4-4.6.21-5.fc9 (build/make) jnovy dxpc-3.9.1-0.3.b1.fc9 (build/make) guthrie eclipse-subclipse-1.2.4-9.fc9 (build/make) robmv epiphany-2.22.1.1-1.fc9 (build/make) gecko-maint erlang-R12B-1.1.fc9 (build/make) gemi evolution-brutus-1.2.11-2.fc9 (build/make) bpepple,colding evolution-remove-duplicates-0.0.3-3.fc9 (build/make) salimma evolution-zimbra-0.1.0-5.fc9 (buildroot) mbarnes,mmahut fakechroot-2.5-13.fc9 (build/make) athimm fakeroot-1.6.4-16.fc9 (build/make) athimm Falcon-0.8.8-3.fc9 (build/make) salimma fontmatrix-0.4.2-1.fc9 (build/make) pnemade fusion-icon-0.1.0-0.2.5e2dc9git.fc9 (build/make) karlik galeon-2.0.5-1.fc9 (build/make) denis gkrellm-wifi-0.9.12-7.fc9 (build/make) jwrdegoede glib-1.2.10-29.fc9 (build/make) rdieter gnome-applet-timer-2.0.1-1.fc9 (build/make) cwickert gnome-themes-2.23.1-1.fc10 (build/make) mclasen gnupg2-2.0.9-1.fc9 (build/make) rdieter,nalin gpgme-1.1.6-3.fc9 (build/make) rdieter gphoto2-2.4.0-10.fc9 (build/make) jnovy grads-1.9b4-23.fc9 (build/make) pertusus graphviz-2.16.1-0.5.fc9 (build/make) jima grass-6.3.0-3.fc10 (build/make) rezso,pertusus gstreamer-plugins-good-0.10.8-1.fc10 (build/make) ajax gtk+-1.2.10-61.fc9 (build/make) rdieter gtkglext-1.2.0-6.fc9 (build/make) corsepiu gtkmozembedmm-1.4.2.cvs20060817-17.fc9 (build/make) hguemar guilt-0.30-1.fc8 (build/make) sandeen HelixPlayer-1.0.9-2.fc9 (build/make) abompard hugs98-2006.09-4.fc9 (build/make) gemi iksemel-1.3-4.fc9 (build/make) jcollie jed-0.99.18-7.fc9 (build/make) notting junitperf-1.9.1-2jpp.1.fc7 (build/make) mwringe kdebluetooth-1.0-0.41.beta8.fc9 (build/make) gilboa,scop kickpim-0.5.3-14.fc9 (build/make) rdieter kleansweep-0.2.9-7.fc9 (build/make) chitlesh kst-1.6.0-2.fc10 (build/make) mtruch ladspa-1.12-9.fc9 (build/make) thomasvs libapreq2-2.09-0.15.rc2.fc9 (build/make) bojan libcdio-0.79-3.fc9 (build/make) adrian libfwbuilder-2.1.16-2.fc9 (build/make) ertzing libidn-0.6.14-7 (build/make) jorton libitl-0.6.4-4.fc9 (build/make) izhar libjpeg-6b-41.fc9 (build/make) tgl libopensync-0.36-2.fc9 (build/make) awjb libopensync-plugin-kdepim-0.35-2.fc9 (build/make) awjb libsigsegv-2.4-6.fc9 (build/make) rdieter listen-0.5-18.fc9 (build/make) hguemar lrmi-0.10-4.fc9 (build/make) kevin mecab-0.97-1.fc9 (build/make) mtasaka mercurial-1.0-4.fc9 (build/make) nbecker,ausil,mmcgrath,nbecker mesa-7.1-0.31.fc9 (build/make) ajax,ajax mod_suphp-0.6.3-1.fc9 (build/make) ixs monodevelop-0.19-6.fc9 (build/make) pfj mosml-2.01-11.fc9 (build/make) gemi muine-scrobbler-0.1.8-5.fc9 (build/make) sindrepb nant-0.85-21.fc9 (build/make) pfj nautilus-open-terminal-0.9-2.fc9 (build/make) pfrields nautilus-search-tool-0.2.2-3.fc9 (build/make) pfrields ncl-5.0.0-11.fc9 (build/make) orion nco-3.9.3-1.fc9 (build/make) edhill,pertusus netcdf-decoders-5.0.0-1.fc9 (build/make) orion,pertusus netcdf-perl-1.2.3-7.fc9 (build/make) orion,perl-sig,pertusus ngspice-17-14.fc9 (build/make) chitlesh ntfs-config-1.0-0.6.rc5.fc9 (build/make) laxathom ntl-5.4.2-2.fc9 (build/make) rdieter numpy-1.0.3.1-2.fc9 (build/make) jwilson,jspaleta ocaml-SDL-0.7.2-12.fc10 (build/make) rjones openhpi-subagent-2.3.4-2.fc10 (build/make) sharkcz openoffice.org-voikko-2.2-4.fc9 (build/make) vpv pam_abl-0.2.3-4.fc9 (build/make) adalloz,tmraz pdfedit-0.3.2-4.fc9 (build/make) bjohnson perl-Class-MethodMaker-2.10-3.fc9 (build/make) dgregor,perl-sig perl-Convert-UUlib-1.09-4.fc9 (build/make) nim,perl-sig,robert perl-Crypt-Simple-0.06-5.fc9 (needs_perl_ExtUtils_MakeMaker) allisson perl-CSS-1.08-2.fc10 (build/make) terjeros perl-DBD-SQLite-1.14-7.fc9 (build/make) kasal,perl-sig,steve,rnorwood,mmaslano perl-GD-SVG-0.28-4.fc9 (build/make) alexlan,perl-sig perl-Gnome2-GConf-1.044-3.fc9 (build/make) cweyl,perl-sig perl-Graph-0.84-2.fc9 (build/make) alexlan,perl-sig perl-Log-Dispatch-FileRotate-1.16-2.fc9 (build/make) spot,perl-sig,corsepiu perl-MIME-Lite-3.01-6.fc9 (build/make) mmcgrath,perl-sig perl-Net-CUPS-0.55-4.fc9 (build/make) cweyl,perl-sig perl-Net-Netmask-1.9015-1.fc8 (build/make) wtogami,perl-sig perl-Net-Packet-3.25-3.fc9 (build/make) sindrepb perl-Net-Server-0.97-2.fc9 (build/make) nim,perl-sig perl-Net-Write-1.00-3.fc9 (build/make) sindrepb perl-OLE-Storage_Lite-0.15-2.fc9 (build/make) spot,perl-sig perl-Pod-POM-0.17-9.fc9 (build/make) spot,perl-sig perl-Spreadsheet-WriteExcel-2.20-2.fc9 (build/make) spot,perl-sig perl-SVG-2.37-1.fc9 (build/make) alexlan,perl-sig perl-Text-CharWidth-0.04-4.fc9 (build/make) athimm perl-Text-Kakasi-2.04-8.fc9 (build/make) tagoh,perl-sig perl-Text-Shellwords-1.08-4.fc9 (build/make) alexlan,perl-sig perl-Text-WrapI18N-0.06-3.fc9 (build/make) athimm perl-Time-modules-2006.0814-2.fc9 (build/make) kaboom,perl-sig,xavierb perl-Unicode-Map-0.112-14.fc9 (build/make) abompard,perl-sig perl-Unicode-Map8-0.12-17.fc9 (build/make) abompard,perl-sig perl-Unicode-MapUTF8-1.11-6.fc8 (build/make) abompard,perl-sig perl-Unicode-String-2.09-8.fc9 (build/make) abompard,perl-sig perl-XML-LibXSLT-1.63-5.fc9 (build/make) shishz,perl-sig perl-XML-XPath-1.13-6.fc9 (build/make) kasal,perl-sig,rnorwood,mmaslano powerman-1.0.32-5.fc9 (build/make) jwilson powerpc-utils-papr-1.0.4-3.fc9 (build/make) dwmw2,rrakus psacct-6.3.2-50.fc9 (build/make) varekova pth-2.0.7-6 (build/make) mschwendt python-imaging-1.1.6-9.fc9 (build/make) jamatos,jgranado python-xlrd-0.6.1-5.fc9 (build/make) ondrejj,jafo qcad-2.0.5.0-8.fc9 (build/make) gemi qgis-0.9.1-5.fc9 (build/make) silfreed,rezso qmmp-0.1.5-2.fc9 (build/make) kvolny,jwrdegoede qof-0.7.5-2.fc9 (build/make) limb qscintilla-2.2-1.fc10 (build/make) rdieter rapidsvn-0.9.6-1.fc9 (build/make) timj repoman-0.9-3.fc8 (build/make) dcantrel,clumens ricci-0.13.0-3.fc9 (build/make) rmccabe rkward-0.5.0b-2.fc10 (build/make) pingou R-Matrix-0.999375-4.fc9 (build/make) tmoertel rss-glx-0.8.1.p-19.fc9 (build/make) nphilipp ruby-1.8.6.114-1.fc9 (build/make) tagoh ruby-gnome2-0.16.0-28.fc9 (build/make) allisson ruby-mecab-0.97-1.fc9 (build/make) mtasaka samba-3.2.0-1.pre3.10.fc10 (build/make) simo,gd ScientificPython-2.6-12.fc9 (build/make) jspaleta slrn-0.9.8.1pl1-8.20070716cvs.fc9 (build/make) mlichvar smarteiffel-2.3-2.fc9 (build/make) gemi sudo-1.6.9p13-6.fc10 (build/make) pvrabec,kzak svgalib-1.9.25-4.fc9 (build/make) jwrdegoede,orion svnmailer-1.0.8-3.fc7 (build/make) mfleming taglib-sharp-2.0.3.0-4.fc10 (build/make) spot taskjuggler-2.4.1-1.fc10 (build/make) ovasik tclchecker-1.4-4.20061030cvs.fc9 (build/make) wart tcldebugger-1.4-6.20061030cvs.fc9 (build/make) wart vorbis-tools-1.2.0-1.fc9 (build/make) zprikryl,jwrdegoede vtk-5.0.4-21.fc9 (build/make) athimm,orion wlassistant-0.5.7-7.fc9 (build/make) spot writer2latex-0.5-2.fc9 (build/make) caolanm xemacs-21.5.28-6.fc9 (build/make) scop xemacs-packages-extra-20070427-1.fc8 (build/make) scop xfce4-mailwatch-plugin-1.0.1-8.fc9 (build/make) cwickert xfce4-verve-plugin-0.3.5-4.fc9 (build/make) cwickert,kevin xsupplicant-1.2.8-6.fc9.2 (build/make) spot zhcon-0.2.6-8.fc9 (build/make) zhu With bugs filed: 139 ---------------------------------- aiksaurus-1.2.1-15.fc6 ['434484 ASSIGNED', '440795 NEW'] (build/make) uwog astyle-1.21-6.fc8 ['440797 NEW', '433971 ASSIGNED'] (build/make) addutko,mtasaka aterm-1.0.1-2.fc9 ['440779 ASSIGNED'] (build/make) awjb bacula-2.0.3-13.fc9 ['440905 NEW'] (build/make) ixs,mmcgrath banshee-0.99.2-2.fc10 ['440860 ASSIGNED'] (build/make) nigelj,spot basket-1.0.2-5.fc9 ['433960 ASSIGNED'] (build/make) abompard bes-3.5.3-3.fc9 ['440807 NEW', '434360 ASSIGNED'] (build/make) pertusus bitbake-1.8.8-1.fc8 ['440562 NEW'] (build/make) ixs blam-1.8.3-13.fc9 ['241850 NEW', '434382 ASSIGNED', '434382 ASSIGNED'] (build/make) alexlan,sindrepb blobby-0.6-0.7.a.fc8 ['440725 NEW', '433961 ASSIGNED'] (build/make) abompard brutus-keyring-0.9.0-6.fc8 ['440809 NEW', '434007 ASSIGNED'] (build/make) bpepple,colding callweaver-1.2-0.4.rc5.20071230.fc9 ['440927 NEW', '434066 ASSIGNED'] (build/make) dwmw2 camstream-0.26.3-12.fc8 ['440878 NEW', '434345 ASSIGNED'] (build/make) nomis80 clisp-2.43-5.fc9 ['238954 ASSIGNED', '166347 ASSIGNED', '434101 ASSIGNED'] (build/make) gemi,green compat-erlang-R10B-11.9.fc9 ['434102 ASSIGNED'] (build/make) gemi conexusmm-0.5.0-3.fc7 ['440847 NEW'] (build/make) rvinyard coolkey-1.1.0-6.fc9 ['440753 NEW'] (build/make) rrelyea,jmagne coreutils-6.11-4.fc10 ['243588 ASSIGNED', '197064 ASSIGNED', '202823 ASSIGNED', '239501 ASSIGNED'] (build/make) ovasik,twaugh crystal-clear-20050622-6.fc8 ['440851 NEW'] (build/make) chitlesh dap-freeform_handler-3.7.7-2.fc9 ['440885 NEW', '434362 ASSIGNED'] (build/make) pertusus dap-hdf4_handler-3.7.7-3.fc9 ['440714 NEW', '434363 ASSIGNED'] (build/make) pertusus dar-2.3.6-3.fc9 ['440746 NEW', '434519 ASSIGNED'] (build/make) xris djvulibre-3.5.20-2.fc9 ['440910 NEW'] (build/make) thias dmraid-1.0.0.rc14-6.fc9 ['434310 ASSIGNED'] (build/make) lvm-team,agk,mornfall,bmr,mbroz,mauelsha,dwysocha dosfstools-2.11-9.fc9 ['448247 NEW'] (build/make) kasal elektra-0.6.10-6.fc9 ['434364 ASSIGNED'] (build/make) pertusus,kwizart fish-1.23.0-2.fc9 ['440724 NEW'] (build/make) ascii,oliver fluxstyle-1.0.1-2.fc7 ['440757 NEW'] (build/make) errr fonttools-2.0-0.11.20060223cvs.fc7 ['434409 ASSIGNED'] (build/make) roozbeh,fonts-sig fontypython-0.2.0-6.fc7 ['440756 ASSIGNED'] (build/make) cr33dog,fonts-sig freeipmi-0.5.1-3.fc9 ['440875 NEW'] (build/make) pknirsch fwbuilder-2.1.16-2.fc9 ['440846 NEW'] (build/make) ertzing gazpacho-0.7.2-2.fc8 ['440859 NEW'] (build/make) icon gcl-2.6.7-18.fc9 ['440913 NEW'] (build/make) gemi,green gdmap-0.7.5-6.fc6 ['440889 NEW', '434529 ASSIGNED'] (build/make) splinux ghc-6.8.2-2.fc9 ['239713 ASSIGNED', '239713 ASSIGNED', '239713 ASSIGNED', '434004 ASSIGNED', '433670 NEW'] (build/make) bos,petersen,ynemoy gl-117-1.3.2-4.fc7 ['434443 ASSIGNED'] (build/make) steve gnome-applet-tvn24-0.2.8-3.fc9 ['440715 NEW', '434300 ASSIGNED'] (build/make) orphan gnu-smalltalk-3.0.1-3.fc9 ['286261 NEW', '436656 NEW'] (build/make) s4504kr,laxathom gpsim-0.22.0-5.fc8 ['440835 NEW', '434061 ASSIGNED'] (build/make) dionysos gresistor-0.0.1-11.fc8 ['440866 NEW'] (build/make) chitlesh gstm-1.2-6.fc7 ['440719 NEW', '434531 ASSIGNED'] (build/make) splinux gtk2hs-0.9.12.1-8.fc9 ['440493 NEW', '434005 ASSIGNED'] (build/make) bos,petersen gtk-sharp-1.0.10-12.fc7 ['434373 ASSIGNED'] (build/make) pfj gwget-0.99-5.fc9 ['440744 NEW'] (build/make) cwickert ht2html-2.0-5.fc6 ['440916 NEW'] (build/make) ifoox Inventor-2.1.5-31.fc9 ['245192 NEW', '245192 NEW', '434035 ASSIGNED'] (build/make) corsepiu itpp-4.0.0-2.fc9 ['440939 NEW', '434076 ASSIGNED'] (build/make) edhill jabbin-2.0-0.6.beta2a.fc9 ['440730 NEW'] (build/make) kurzawa jgroups-2.2.9.2-3jpp.2 ['434352 ASSIGNED'] (build/make) dbhole kazehakase-0.5.4-4.fc9 ['402641 NEW', '402641 NEW'] (build/make) mtasaka kismet-0.0.2007.10.R1-3.fc9 ['434084 ASSIGNED'] (build/make) ensc klear-0.7.0-1.svn113.fc9 ['440755 NEW'] (build/make) trasher koffice-langpack-1.6.3-1.fc8 ['440758 ASSIGNED'] (build/make) awjb kphotobymail-0.4.1-1.fc7 ['440873 ASSIGNED'] (build/make) kushal ktechlab-0.3.69-5.fc8 ['434030 ASSIGNED'] (build/make) chitlesh LabPlot-1.5.1.6-6.fc9 ['434019 ASSIGNED'] (build/make) chitlesh,chitlesh,tnorth lam-7.1.2-11.fc9 ['440926 NEW', '434065 ASSIGNED'] (build/make) dledford libdap-3.7.10-2.fc9 ['440854 NEW', '434366 ASSIGNED'] (build/make) pertusus libFoundation-1.1.3-11.fc9 ['440564 NEW'] (build/make) athimm libgtksourceviewmm-0.3.1-1.fc8 ['440877 NEW', '434532 ASSIGNED'] (build/make) splinux libnc-dap-3.7.0-9.fc9 ['440768 NEW', '434367 ASSIGNED'] (build/make) pertusus libopensync-plugin-google-calendar-0.35-2.fc9 ['433995 ASSIGNED'] (build/make) awjb libzzub-0.2.3-12.fc9 ['293751 NEW', '293751 NEW'] (build/make) akahl,mtasaka lilypond-2.10.33-1.fc8 ['440826 NEW', '434394 ASSIGNED'] (build/make) qspencer lineakd-0.9-5.fc6 ['440774 NEW', '434523 ASSIGNED'] (build/make) xris lineak-defaultplugin-0.9-2.fc6 ['440821 NEW', '434520 ASSIGNED'] (build/make) xris lineak-xosdplugin-0.9-2.fc6 ['440929 NEW', '434522 ASSIGNED'] (build/make) xris linpsk-0.9-3.fc9 ['440778 NEW'] (build/make) bjensen,sindrepb,sconklin linux-atm-2.5.0-5 ['434069 ASSIGNED'] (build/make) dwmw2 lostirc-0.4.6-3.fc8 ['440921 NEW'] (build/make) splinux,splinux mbuffer-20070502-1.fc7 ['440836 ASSIGNED', '433969 ASSIGNED'] (build/make) adalloz mimetic-0.9.3-2.fc8 ['440838 NEW', '434086 ASSIGNED'] (build/make) ensc moto4lin-0.3-6.fc7 ['440713 NEW', '434135 ASSIGNED'] (build/make) jafo mtd-utils-1.1.0-2.fc8 ['440845 NEW', '434070 ASSIGNED'] (build/make) dwmw2,jwboyer multiget-1.1.4-7.fc8 ['440801 ASSIGNED', '433980 ASSIGNED'] (build/make) orphan,mtasaka mx-2.0.6-3 ['434325 ASSIGNED'] (build/make) misa mx4j-3.0.1-6jpp.4 ['246183 NEW', '440731 NEW', '434097 ASSIGNED'] (build/make) fnasser MyPasswordSafe-0.6.7-4.20061216.fc9 ['442840 NEW'] (build/make) ertzing mysql-gui-tools-5.0r12-5.fc9 ['440734 NEW', '433987 ASSIGNED'] (build/make) ausil nethack-vultures-2.1.0-10.fc8 ['434317 ASSIGNED'] (build/make) meme oggconvert-0.3.0-14.fc9 ['440943 NEW'] (build/make) ngompa oooqs2-1.0-3.fc6 ['433988 ASSIGNED'] (build/make) ausil orpie-1.4.3-5.fc6 ['440823 NEW', '434524 ASSIGNED'] (build/make) xris pan-0.132-2.fc8 ['433970 ASSIGNED'] (build/make) adalloz,mpeters pcmanx-gtk2-0.3.5-9.336svn.fc7 ['440745 NEW', '434299 ASSIGNED'] (open_missing_mode) leo pdsh-2.11-6.fc9 ['440811 NEW'] (build/make) kg6fnk pekwm-0.1.5-5.fc7 ['440883 NEW', '434089 ASSIGNED'] (build/make) errr perl-5.10.0-24.fc10 ['198399 NEW'] (build/make) mmaslano,spot,corsepiu,rnorwood,kasal petitboot-0.0.1-7.fc8 ['440853 NEW', '434071 ASSIGNED'] (build/make) dwmw2,jwboyer pic2aa-0.2.1-3.fc9 ['440764 NEW'] (build/make) kurzawa piklab-0.15.0-1.fc9 ['434032 ASSIGNED'] (build/make) chitlesh,dionysos plague-0.4.4.1-4.fc7 ['443709 NEW', '440874 NEW'] (build/make) dcbw plotmm-0.1.2-6.fc9 ['440563 NEW'] (build/make) hguemar plplot-5.9.0-1.fc9 ['241233 ASSIGNED', '433913 NEW'] (build/make) orion proftpd-1.3.1-3.fc9 ['440729 NEW'] (build/make) thias psi-0.11-4.fc9 ['440737 NEW'] (build/make) abompard python-dialog-2.7-7.fc8 ['440819 NEW'] (build/make) abompard python-durus-3.5-3.fc7 ['440781 NEW', '434427 MODIFIED'] (build/make) shahms python-memcached-1.39-1.fc8 ['440931 NEW'] (build/make) jafo python-pydns-2.3.0-5.fc7 ['440912 NEW'] (build/make) jafo python-pyspf-2.0.3-1.fc8 ['440793 NEW'] (build/make) jafo python-simpletal-4.1-5.fc7 ['440930 NEW'] (build/make) shahms python-tpg-3.1.0-4.fc7 ['440763 NEW'] (build/make) shahms python-urljr-1.0.1-1.fc7 ['440901 NEW'] (build/make) jcollie pyzor-0.4.0-11.fc7 ['440790 NEW'] (build/make) ixs qa-assistant-0.4.90.5-2.fc6 ['440914 ASSIGNED'] (build/make) toshio qca-1.0-10.fc9 ['440850 NEW'] (build/make) abompard qca2-2.0.0-2.fc9 ['440940 NEW'] (build/make) abompard qca-gnupg-2.0.0-0.2.beta1.fc9 ['440743 NEW'] (build/make) abompard qca-ossl-2.0.0-0.4.beta3.fc9 ['440908 NEW'] (build/make) abompard qca-tls-1.0-13.fc9 ['440909 NEW'] (build/make) abompard qgo-1.5.4r2-1.fc9 ['440728 NEW'] (build/make) kaboom qps-1.9.19-0.2.b.fc7 ['440904 NEW', '434312 ASSIGNED'] (build/make) makghosh qsynth-0.2.5-7.fc9 ['440736 NEW'] (build/make) nando qtiplot-0.9-8.fc9 ['440844 NEW', '434100 ASSIGNED'] (build/make) frankb ruby-bdb-0.6.0-1.fc7 ['440882 NEW', '434090 ASSIGNED'] (build/make) errr rudeconfig-5.0.5-1.fc7 ['440848 NEW', '434131 ASSIGNED'] (build/make) homeless rxvt-unicode-9.02-2.fc9 ['440789 ASSIGNED'] (build/make) awjb sbcl-1.0.13-1.fc9 ['448734 NEW', '434401 ASSIGNED'] (build/make) rdieter,green sblim-wbemcli-1.5.1-5.fc7 ['440893 NEW', '434129 ASSIGNED'] (build/make) hamzy scim-skk-0.5.2-8.fc6 ['440863 NEW', '434419 ASSIGNED'] (build/make) ryo scim-tomoe-0.6.0-2.fc8 ['434420 ASSIGNED'] (build/make) ryo,petersen scribus-1.3.4-5.fc9 ['440766 ASSIGNED'] (build/make) awjb scrip-1.4-9.fc8 ['440769 NEW', '434079 ASSIGNED'] (build/make) edhill selinux-policy-3.3.1-45.fc10 ['391451 NEW'] (build/make) dwalsh,jkubin seq24-0.8.7-8.fc8 ['440363 ASSIGNED', '434123 ASSIGNED'] (build/make) green showimg-0.9.5-16.fc9 ['440890 NEW', '433966 ASSIGNED'] (build/make) abompard sos-1.8-1.fc8 ['440839 NEW'] (build/make) navid soundtracker-0.6.8-2.fc6 ['440767 NEW', '434425 ASSIGNED'] (build/make) seg straw-0.27-12.fc9 ['440806 ASSIGNED'] (build/make) subhodip supertux-0.3.1-1.fc9 ['440816 NEW', '434445 ASSIGNED'] (build/make) steve synaptics-0.14.6-7.fc9 ['437039 ASSIGNED'] (build/make) krh syslinux-3.61-2.fc9 ['444291 ASSIGNED'] (build/make) pjones trousers-0.3.1-5.fc9 ['440733 NEW', '434267 ASSIGNED'] (build/make) key,ejratl wine-0.9.58-1.fc9 ['440951 ON_QA', '440951 ON_QA'] (build/make) awjb xen-3.2.0-10.fc9 ['442052 NEW', '433921 NEW'] (build/make) xen-maint,berrange xml-commons-resolver-1.1-1jpp.12 ['432075 NEW', '434098 ASSIGNED'] (build/make) fnasser yoltia-0.22.1-2.fc9 ['440935 NEW'] (build/make) kurzawa ---------------------------------- Packages by owner: abompard: HelixPlayer,basket,blobby,perl-Unicode-Map,perl-Unicode-Map8,perl-Unicode-MapUTF8,perl-Unicode-String,psi,python-dialog,qca,qca-gnupg,qca-ossl,qca-tls,qca2,showimg adalloz: mbuffer,pam_abl,pan addutko: astyle adrian: libcdio agk: dmraid ajax: gstreamer-plugins-good,mesa,mesa akahl: bmpx,libzzub alexlan: blam,perl-GD-SVG,perl-Graph,perl-SVG,perl-Text-Shellwords allisson: perl-Crypt-Simple,ruby-gnome2 ascii: fish athimm: fakechroot,fakeroot,libFoundation,perl-Text-CharWidth,perl-Text-WrapI18N,vtk ausil: mercurial,mysql-gui-tools,oooqs2 awjb: aterm,koffice-langpack,libopensync,libopensync-plugin-google-calendar,libopensync-plugin-kdepim,rxvt-unicode,scribus,wine berrange: xen bjensen: linpsk bjohnson: pdfedit bmr: dmraid bojan: libapreq2 bos: ghc,gtk2hs bpepple: brutus-keyring,evolution-brutus caolanm: writer2latex chitlesh: LabPlot,LabPlot,crystal-clear,gresistor,kleansweep,ktechlab,ngspice,piklab clumens: repoman colding: brutus-keyring,evolution-brutus corsepiu: Inventor,gtkglext,perl,perl-Log-Dispatch-FileRotate cr33dog: fontypython cweyl: perl-Gnome2-GConf,perl-Net-CUPS cwickert: gnome-applet-timer,gwget,xfce4-mailwatch-plugin,xfce4-verve-plugin dbhole: jgroups dcantrel: repoman dcbw: plague denis: galeon dgregor: perl-Class-MethodMaker dionysos: gpsim,piklab dledford: lam drago01: beagle,beagle dwalsh: selinux-policy dwmw2: callweaver,linux-atm,mtd-utils,petitboot,powerpc-utils-papr dwysocha: dmraid edhill: cdo,itpp,nco,scrip ejratl: trousers ensc: kismet,mimetic errr: fluxstyle,pekwm,ruby-bdb ertzing: MyPasswordSafe,fwbuilder,libfwbuilder fnasser: mx4j,xml-commons-resolver fonts-sig: fonttools,fontypython frankb: qtiplot gd: samba gecko-maint: epiphany gemi: clisp,compat-erlang,erlang,gcl,hugs98,mosml,qcad,smarteiffel gilboa: kdebluetooth green: ardour,clisp,gcl,sbcl,seq24 guthrie: dxpc hamzy: sblim-wbemcli hguemar: gtkmozembedmm,listen,plotmm homeless: rudeconfig icon: gazpacho ifoox: ht2html ixs: bacula,bitbake,mod_suphp,pyzor izhar: libitl jafo: moto4lin,python-memcached,python-pydns,python-pyspf,python-xlrd jamatos: python-imaging jcollie: iksemel,python-urljr jgranado: python-imaging jima: graphviz jkubin: selinux-policy jmagne: coolkey jnovy: compat-db,db4,gphoto2 jorton: libidn jspaleta: ScientificPython,numpy jwboyer: mtd-utils,petitboot jwilson: numpy,powerman jwrdegoede: ardour,gkrellm-wifi,qmmp,svgalib,vorbis-tools kaboom: perl-Time-modules,qgo karlik: fusion-icon kasal: brltty,dosfstools,perl,perl-DBD-SQLite,perl-XML-XPath kevin: lrmi,xfce4-verve-plugin key: trousers kg6fnk: pdsh krh: synaptics kurzawa: jabbin,pic2aa,yoltia kushal: kphotobymail kvolny: qmmp kwizart: elektra kzak: sudo laxathom: gnu-smalltalk,ntfs-config leo: pcmanx-gtk2 limb: astromenace,qof lvm-team: dmraid makghosh: qps matt: condor mauelsha: dmraid mbarnes: evolution-zimbra mbroz: dmraid mclasen: gnome-themes meme: nethack-vultures mfleming: svnmailer misa: mx mlichvar: slrn mmahut: evolution-zimbra mmaslano: perl,perl-DBD-SQLite,perl-XML-XPath mmcgrath: bacula,mercurial,perl-MIME-Lite mornfall: dmraid mpeters: pan mschwendt: compface,pth mtasaka: astyle,kazehakase,libzzub,mecab,multiget,ruby-mecab mtruch: kst mwringe: junitperf nalin: gnupg2 nando: qsynth navid: sos nbecker: mercurial,mercurial ngompa: oggconvert nigelj: banshee nim: perl-Convert-UUlib,perl-Net-Server nomis80: camstream notting: jed nphilipp: rss-glx oliver: fish ondrejj: python-xlrd orion: ncl,netcdf-decoders,netcdf-perl,plplot,svgalib,vtk orphan: gnome-applet-tvn24,multiget ovasik: coreutils,cpio,taskjuggler perl-sig: netcdf-perl,perl-Class-MethodMaker,perl-Convert-UUlib,perl-DBD-SQLite,perl-GD-SVG,perl-Gnome2-GConf,perl-Graph,perl-Log-Dispatch-FileRotate,perl-MIME-Lite,perl-Net-CUPS,perl-Net-Netmask,perl-Net-Server,perl-OLE-Storage_Lite,perl-Pod-POM,perl-SVG,perl-Spreadsheet-WriteExcel,perl-Text-Kakasi,perl-Text-Shellwords,perl-Time-modules,perl-Unicode-Map,perl-Unicode-Map8,perl-Unicode-MapUTF8,perl-Unicode-String,perl-XML-LibXSLT,perl-XML-XPath pertusus: bes,cernlib,cernlib-g77,dap-freeform_handler,dap-hdf4_handler,elektra,grads,grass,libdap,libnc-dap,nco,netcdf-decoders,netcdf-perl petersen: ghc,gtk2hs,scim-tomoe pfj: gtk-sharp,monodevelop,nant pfrields: nautilus-open-terminal,nautilus-search-tool pingou: rkward pjones: syslinux pknirsch: freeipmi pnemade: fontmatrix psytux: beagle pvrabec: sudo qspencer: lilypond rbrich: amanda rdieter: glib,gnupg2,gpgme,gtk+,kickpim,libsigsegv,ntl,qscintilla,sbcl rezso: grass,qgis rjones: ocaml-SDL rmccabe: ricci rnorwood: perl,perl-DBD-SQLite,perl-XML-XPath robert: perl-Convert-UUlib robmv: eclipse-subclipse roozbeh: fonttools rrakus: powerpc-utils-papr rrelyea: coolkey rvinyard: conexusmm ryo: scim-skk,scim-tomoe s4504kr: gnu-smalltalk salimma: Falcon,evolution-remove-duplicates sandeen: guilt sconklin: linpsk scop: kdebluetooth,xemacs,xemacs-packages-extra seg: soundtracker shahms: python-durus,python-simpletal,python-tpg sharkcz: openhpi-subagent shishz: perl-XML-LibXSLT silfreed: qgis simo: samba sindrepb: blam,linpsk,muine-scrobbler,perl-Net-Packet,perl-Net-Write splinux: gdmap,gstm,libgtksourceviewmm,lostirc,lostirc spot: banshee,perl,perl-Log-Dispatch-FileRotate,perl-OLE-Storage_Lite,perl-Pod-POM,perl-Spreadsheet-WriteExcel,taglib-sharp,wlassistant,xsupplicant steve: gl-117,perl-DBD-SQLite,supertux subhodip: straw tagoh: perl-Text-Kakasi,ruby terjeros: perl-CSS tgl: libjpeg thias: djvulibre,proftpd thomasvs: ladspa timj: rapidsvn tmoertel: R-Matrix tmraz: pam_abl tnorth: LabPlot toshio: qa-assistant trasher: klear twaugh: coreutils uwog: aiksaurus varekova: psacct vpv: openoffice.org-voikko wart: tclchecker,tcldebugger wtogami: perl-Net-Netmask xavierb: perl-Time-modules xen-maint: xen xris: dar,lineak-defaultplugin,lineak-xosdplugin,lineakd,orpie ynemoy: ghc zhu: zhcon zprikryl: vorbis-tools -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From a.j.delaney at brighton.ac.uk Sat May 31 12:34:07 2008 From: a.j.delaney at brighton.ac.uk (Aidan Delaney) Date: Sat, 31 May 2008 13:34:07 +0100 Subject: Interest in Cell architecture SIG Message-ID: <1212237247.2784.8.camel@ScaryMonster> Dear all, I have mutilated Jakub Jelinek's excellent binutils and gcc packages to create binutils-spu and gcc-spu. Both mutant packages need a significant amount of polishing. However, I'm wondering if others are interested in a Fedora tool chain for the Cell processor? I'm primarily interested in the PS3 architecture. So (a) Are you interested in a Fedora Architecture SIG for Cell who would test and maintain a SPU tool chain, and (b) Are you interested in taking the route I've taken in constructing a tool chain for Fedora (GCC 4.3 based) rather than supporting the IBM Cell SDK (GCC 4.1 based)? -- Aidan Delaney From dominik at greysector.net Sat May 31 12:41:12 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sat, 31 May 2008 14:41:12 +0200 Subject: Introduction: Mostafa Daneshvar In-Reply-To: <200805310246.56493.mostafa@daneshvar.org.uk> References: <200805310246.56493.mostafa@daneshvar.org.uk> Message-ID: <20080531124112.GA5838@mokona.greysector.net> On Saturday, 31 May 2008 at 00:16, Mostafa Daneshvar wrote: > Hi > I am Mostafa Daneshvar. I am from Iran. I am using Fedora 9 as my OS. I am > coordinator of Balochi language in fedora project. I hope I can help in > development of Fedora Welcome! > My Wiki page: https://fedoraproject.org/wiki/MostafaDaneshvar With the recent migration to MediaWiki, you should move your page to User:Lashar instead. Regards, R. -- Fedora http://fedoraproject.org/wiki/DominikMierzejewski Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From dominik at greysector.net Sat May 31 12:46:30 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sat, 31 May 2008 14:46:30 +0200 Subject: Interest in Cell architecture SIG In-Reply-To: <1212237247.2784.8.camel@ScaryMonster> References: <1212237247.2784.8.camel@ScaryMonster> Message-ID: <20080531124630.GB5838@mokona.greysector.net> On Saturday, 31 May 2008 at 14:34, Aidan Delaney wrote: > Dear all, > I have mutilated Jakub Jelinek's excellent binutils and gcc packages to > create binutils-spu and gcc-spu. Both mutant packages need a > significant amount of polishing. However, I'm wondering if others are > interested in a Fedora tool chain for the Cell processor? I'm primarily > interested in the PS3 architecture. > So > (a) Are you interested in a Fedora Architecture SIG for Cell who would > test and maintain a SPU tool chain, and > (b) Are you interested in taking the route I've taken in constructing a > tool chain for Fedora (GCC 4.3 based) rather than supporting the IBM > Cell SDK (GCC 4.1 based)? FWIW, I have access to an IBM LS20/QS21 machine (4 Cell cores and 2 AMD Opteron cores) running Fedora 8, so if you want something tested, I can help. Regards, R. -- Fedora http://fedoraproject.org/wiki/DominikMierzejewski Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From j.w.r.degoede at hhs.nl Sat May 31 13:04:13 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 31 May 2008 15:04:13 +0200 Subject: Hylafax review issues In-Reply-To: References: Message-ID: <48414CCD.4010401@hhs.nl> Jason L Tibbitts III wrote: > One of the oldest review tickets still open is > https://bugzilla.redhat.com/show_bug.cgi?id=188542, for the fax server > hylafax. Earlier this month I picked this up an attempt to try and > shepherd it through the process, but I'm stuck on a couple of issues > and the submitter does not seem to be willing to address them > satisfactorily. Maybe I should just say "hell no" and drop the > review, but I guess my objections could be wrong so I figured I'd try > to start some discussion. > > Issue one is the name: There are multiple pieces of software claiming > to be hylafax. There's the software at hylafax.org, and then there's > the package at hylafax.sourceforge.net, where it is called > "hylafax+". I quote: > The "+" means that it is better. > > There's also an "enterprise" version from ifax.com. The second > version, which upstream calls itself "hylafax+" is the one being > submitted, but the submitter argues against using that name (see > comment 38): > However, my suggestion would follow what I've said above about the > Apache http server. The distinction of the "+" will mean very > little to Fedora users (and in-fact may make the package > more-difficult to identify) unless there is more than one HylaFAX > package being distributed by Fedora (say, for example, separate > "hylafax+" and "hylafax.org" packages). > > Anyone else agree with that reasoning? I tend to agree that plain hylafax is the right name for a couple of reaons: 1) hylafax is quite well known so I would expect "yum install hylafax" to just work, but also something like rpm -q hylafax. Note that the quite well known-ness also is an argument to get this thing reviewed and included it really is a shame that Fedora currently does not have a hylafax package, so Jason good work on trying to get this through review! 2) When in doubt about things like Casing or cases like this I always look at the source tarbal name, and that in this case is plain hylafax, not hylafax+ changing the name would mean that a -n argument would be needed to %setup, also notice that the installed binaries, service, etc are all called hylafax without the +. > The second issue is an FHS violation: several directories are > installed under /var/spool which contain things that aren't really in > the spirit of /var/spool. There's a /var/spool/hylafax/bin directory > which, you guessed it, contains executables, a > /var/spool/hylafax/config directory containing config files, and > /var/spool/hylafax/etc containing other, different config files. > > Here's what the submitter has to say (see comment 83): > While the vast majority of HylaFAX binaries and their respective > configuration files are installed outside of /var/spool/hylafax, > those three directories (etc, bin, and config) are configuration > files and configuration utility scripts, etc., that control how the > spools are handled. > > Due to the way that HylaFAX daemons operate it would be extremely > cumbersome (if not impossible - as in the case of a chroot) for > these to be elsewhere. They're very much like the configuration > files that LPRng had under /var/spool/lpd. > > So, that's my argument. I hope that it's acceptable. But if it's > not... unfortunately there's not much that I am willing to do about > it. > > But even if, it's too hard to fix, what about a few symlinks? (To > somewhere under /usr/libexec for the bin stuff, and somewhere under > /etc for for config and etc directories.) Do three symlinks violate > the FHS significantly enough to cause issues? My understanding is > that this should be OK with chroots (as long as the links are > relative.) And how does all of this square with selinux? > I tend to agree with you on this one, but having just packaged coda I know how non FHS compliant locations can sometimes be hardcoded all over the place (no not as easy as a singel define somewhere, paths written fully all over the place). So I'm somewhat sympathetic to the submitters arguments, have you suggested the symlink approach to him? Regards, Hans From dev at nigelj.com Sat May 31 13:10:47 2008 From: dev at nigelj.com (Nigel Jones) Date: Sun, 01 Jun 2008 01:10:47 +1200 Subject: Fedora x86_64 rawhide rebuild in mock status 2008-05-27 In-Reply-To: <20080531072422.A1480@humbolt.us.dell.com> References: <20080531072422.A1480@humbolt.us.dell.com> Message-ID: <48414E57.10703@nigelj.com> Matt Domsch wrote: > banshee-0.99.2-2.fc10 ['440860 ASSIGNED'] (build/make) nigelj,spot > Technically this would have built from source, per 448365 which is the new FTBFS bug for banshee, I've closed 440860 because it is to say the least useless. One thing to note is: a) I was not aware of 440860 when I adopted (I should have changed the owner when I adopted it (oops)) b) Upon checking koji, it would have been possible to note that banshee had built from source on Apr 13 c) imo it's a 'bad thing' to mark bugs as 'ASSIGNED' without at the very least also hitting 'Reassign bug to owner and QA contact of selected component' Now I'm not targeting anyone but just suggesting that maybe some extra consideration needs to be taken into account for these sort of bugs, and potentially a couple of changes in practice, i.e.: * Never mark a bug as ASSIGNED (a BugZappers opinion on a bug my be completely different from the Maintainers) * When bugs haven't been touched by the assignee, hit the Reassign bug to owner button just in case the maintainer has changed since then * If you decide to BugZap FTBFS bugs, check if they still FTBFS (i.e. look in koji). Just some thoughts, - Nigel From paul at city-fan.org Sat May 31 13:57:10 2008 From: paul at city-fan.org (Paul Howarth) Date: Sat, 31 May 2008 14:57:10 +0100 Subject: Fedora x86_64 rawhide rebuild in mock status 2008-05-27 In-Reply-To: <20080531072422.A1480@humbolt.us.dell.com> References: <20080531072422.A1480@humbolt.us.dell.com> Message-ID: <20080531145710.0ef4b266@metropolis.intra.city-fan.org> On Sat, 31 May 2008 07:24:22 -0500 Matt Domsch wrote: > Fedora Rawhide-in-Mock Build Results for x86_64 > based on rawhide as of 5-27-2008 (it takes a few days to build 5700 > packages twice). > > There is a proposal before FESCo to remove packages that Fail To Build > >From Source (FTBFS)[1] from the distribution, if the package owner > >has > no bug comments indicating it will be fixed in a reasonable amount of > time before the next major release. This would take place immediately > following the Alpha release[2]. Please comment on the thread on > fedora-devel-list[3], or come to the FESCo meeting next Thursday[4], > if you have concerns. > > > [1] http://fedoraproject.org/wiki/FTBFS > [2] http://fedoraproject.org/wiki/Schedule (shows F9 presently, > extrapolate for F10) > [3] > https://www.redhat.com/archives/fedora-devel-list/2008-May/msg02369.html > [4] > http://fedoraproject.org/wiki/Development/SteeringCommittee/Meetings > > > Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ > > Total packages: 5722 > Number failed to build: 378 > Number expected to fail due to ExclusiveArch or ExcludeArch: 35 > Leaving: 343 > (there may be some duplicates if rawhide has 2 versions of a package) ... > With bugs filed: 151 > ---------------------------------- ... > dledford lat-1.2.3-3.fc9 ['241911 ASSIGNED'] (build/make) pghmcfc Bug #241911 is the ppc64 excludearch tracker bug for lat, not a FTBFS bug. The package currently fails to build in Rawhide due to broken deps in the mono stack that it buildreqs. Paul. From Matt_Domsch at dell.com Sat May 31 13:58:08 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sat, 31 May 2008 08:58:08 -0500 Subject: Fedora x86_64 rawhide rebuild in mock status 2008-05-27 In-Reply-To: <48414E57.10703@nigelj.com> References: <20080531072422.A1480@humbolt.us.dell.com> <48414E57.10703@nigelj.com> Message-ID: <20080531135808.GA9722@auslistsprd01.us.dell.com> On Sun, Jun 01, 2008 at 01:10:47AM +1200, Nigel Jones wrote: > Matt Domsch wrote: > >banshee-0.99.2-2.fc10 ['440860 ASSIGNED'] (build/make) nigelj,spot > > > Technically this would have built from source, per 448365 which is the > new FTBFS bug for banshee, I've closed 440860 because it is to say the > least useless. OK, but then you need 448365 to block 'FTBFS', (or another bug that blocks 'FTBFS', it looks recursively) otherwise my scripts won't find 448365 and I would wind up filing _another_ bug. I've added this now. In the future, if you think an auto-filed bug is a dupe, feel free to close it of course, but make the open bug block FTBFS. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From Matt_Domsch at dell.com Sat May 31 14:29:06 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sat, 31 May 2008 09:29:06 -0500 Subject: Fedora x86_64 rawhide rebuild in mock status 2008-05-27 In-Reply-To: <20080531145710.0ef4b266@metropolis.intra.city-fan.org> References: <20080531072422.A1480@humbolt.us.dell.com> <20080531145710.0ef4b266@metropolis.intra.city-fan.org> Message-ID: <20080531142906.GB9722@auslistsprd01.us.dell.com> On Sat, May 31, 2008 at 02:57:10PM +0100, Paul Howarth wrote: > > dledford lat-1.2.3-3.fc9 ['241911 ASSIGNED'] (build/make) pghmcfc > > Bug #241911 is the ppc64 excludearch tracker bug for lat, not a FTBFS > bug. The package currently fails to build in Rawhide due to broken deps > in the mono stack that it buildreqs. Odd; I do a simple recursion via bugzilla queries, down the 'blockedby' chain, starting from FTBFS. Not sure how it picked up that bug though. I'll keep an eye out for this. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From dan at danny.cz Sat May 31 15:02:08 2008 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Sat, 31 May 2008 17:02:08 +0200 Subject: Fedora x86_64 rawhide rebuild in mock status 2008-05-27 In-Reply-To: <20080531142906.GB9722@auslistsprd01.us.dell.com> References: <20080531072422.A1480@humbolt.us.dell.com> <20080531145710.0ef4b266@metropolis.intra.city-fan.org> <20080531142906.GB9722@auslistsprd01.us.dell.com> Message-ID: <1212246128.3364.5.camel@eagle.danny.cz> Matt Domsch p??e v So 31. 05. 2008 v 09:29 -0500: > On Sat, May 31, 2008 at 02:57:10PM +0100, Paul Howarth wrote: > > > dledford lat-1.2.3-3.fc9 ['241911 ASSIGNED'] (build/make) pghmcfc > > > > Bug #241911 is the ppc64 excludearch tracker bug for lat, not a FTBFS > > bug. The package currently fails to build in Rawhide due to broken deps > > in the mono stack that it buildreqs. > the same situation is with cdcollect-0.6.0-5.fc9 ['309191 ASSIGNED'] (build/make) sharkcz > Odd; I do a simple recursion via bugzilla queries, down the > 'blockedby' chain, starting from FTBFS. Not sure how it picked up > that bug though. I'll keep an eye out for this. Dan From tibbs at math.uh.edu Sat May 31 16:12:53 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 31 May 2008 11:12:53 -0500 Subject: Hylafax review issues In-Reply-To: <48414CCD.4010401@hhs.nl> References: <48414CCD.4010401@hhs.nl> Message-ID: >>>>> "HdG" == Hans de Goede writes: HdG> hylafax is quite well known so I would expect "yum install HdG> hylafax" to just work, but also something like rpm -q hylafax. Well, I'd certainly agree, if this was actually the hylafax software. But it's not; it's the hylafax+ software. I'll freely admit that nobody so far has tried to get the hylafax sotfware into Fedora, and perhaps that will never happen. If we assume that it will never happen, then we have no conflict and I suppose we don't care. I'm not sure that we can make this assumption, though. I'm trying to think of a situation where an upstream fork with a slightly different name tries to get itself into a distro with the original name in (what seems to me to be) an attempt to gain legitimacy. I don't think it's happened before, and we should avoid hastily taking a precident-setting position. HdG> 2) When in doubt about things like Casing or cases like this I HdG> always look at the source tarbal name, and that in this case is HdG> plain hylafax, not hylafax+ changing the name would mean that a HdG> -n argument would be needed to %setup, also notice that the HdG> installed binaries, service, etc are all called hylafax without HdG> the +. Well, that's just the nature of the upstream, though. Their web site is plain about the naming and there's a reasonable argument (already made in the review ticket) that their tarballs are misnamed. I think the nature of forks will generally result in situations as we have with the binaries. HdG> So I'm somewhat sympathetic to the submitters arguments, have you HdG> suggested the symlink approach to him? I have not; I wanted to see how reasonable others thought the approach was before proposing it, having him do the work and then getting flamed for it in the review ticket. - J< From jwboyer at gmail.com Sat May 31 16:15:02 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Sat, 31 May 2008 11:15:02 -0500 Subject: Interest in Cell architecture SIG In-Reply-To: <1212237247.2784.8.camel@ScaryMonster> References: <1212237247.2784.8.camel@ScaryMonster> Message-ID: <20080531111502.73c6d7be@vader.jdub.homelinux.org> On Sat, 31 May 2008 13:34:07 +0100 Aidan Delaney wrote: > Dear all, > I have mutilated Jakub Jelinek's excellent binutils and gcc packages to > create binutils-spu and gcc-spu. Both mutant packages need a > significant amount of polishing. However, I'm wondering if others are > interested in a Fedora tool chain for the Cell processor? I'm primarily > interested in the PS3 architecture. > So > (a) Are you interested in a Fedora Architecture SIG for Cell who would > test and maintain a SPU tool chain, and > (b) Are you interested in taking the route I've taken in constructing a > tool chain for Fedora (GCC 4.3 based) rather than supporting the IBM > Cell SDK (GCC 4.1 based)? I'd rather do this under the PPC SIG, rather than create a whole new one just for Cell. Now, providing a whole new toolchain might be possible but you'd have to make sure it doesn't conflict with the stock toolchains. josh From a.j.delaney at brighton.ac.uk Sat May 31 16:32:29 2008 From: a.j.delaney at brighton.ac.uk (Aidan Delaney) Date: Sat, 31 May 2008 17:32:29 +0100 Subject: Interest in Cell architecture SIG In-Reply-To: <20080531111502.73c6d7be@vader.jdub.homelinux.org> References: <1212237247.2784.8.camel@ScaryMonster> <20080531111502.73c6d7be@vader.jdub.homelinux.org> Message-ID: <1212251550.2784.15.camel@ScaryMonster> Josh, On Sat, 2008-05-31 at 11:15 -0500, Josh Boyer wrote: > I'd rather do this under the PPC SIG, rather than create a whole new > one just for Cell. That makes sense. > Now, providing a whole new toolchain might be possible but you'd have > to make sure it doesn't conflict with the stock toolchains. At the moment I'm just looking at providing tools prefixed with "spu-" such as spu-as, spu-ld, spu-gcc etc... I don't expect conflicts as these packages are based on the current gcc versions in Fedora (with the same patches). -- Aidan Delaney From j.w.r.degoede at hhs.nl Sat May 31 17:23:28 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 31 May 2008 19:23:28 +0200 Subject: Hylafax review issues In-Reply-To: References: <48414CCD.4010401@hhs.nl> Message-ID: <48418990.7090307@hhs.nl> Jason L Tibbitts III wrote: >>>>>> "HdG" == Hans de Goede writes: > > HdG> hylafax is quite well known so I would expect "yum install > HdG> hylafax" to just work, but also something like rpm -q hylafax. > > Well, I'd certainly agree, if this was actually the hylafax software. > But it's not; it's the hylafax+ software. I'll freely admit that > nobody so far has tried to get the hylafax sotfware into Fedora, and > perhaps that will never happen. If we assume that it will never > happen, then we have no conflict and I suppose we don't care. I'm not > sure that we can make this assumption, though. > Well the question here IMHO is not so much how to name the package as it is which fork to package, making them parallel installable will be very hard todo and AFAIK we don't want conflicting packages. Now reading this imho pretty neutral description of the various forks: http://en.wikipedia.org/wiki/HylaFAX I believe that hylafax+ best fits Fedora. Regards, Hans From bigjoe1008 at gmail.com Sat May 31 17:25:50 2008 From: bigjoe1008 at gmail.com (Joe Harnish) Date: Sat, 31 May 2008 13:25:50 -0400 Subject: Hylafax review issues In-Reply-To: References: <48414CCD.4010401@hhs.nl> Message-ID: <763fc8580805311025m20bdccb3p1786044fd7fedfc9@mail.gmail.com> > > I'm trying to think of a situation where an upstream fork with a > slightly different name tries to get itself into a distro with the > original name in (what seems to me to be) an attempt to gain > legitimacy. I don't think it's happened before, and we should avoid > hastily taking a precident-setting position. The one package that could have a similar problem is jabberd and jabberd2. They are two separate yet actively developed projects (http://en.wikipedia.org/wiki/Jabberd). --Joe From tibbs at math.uh.edu Sat May 31 19:00:24 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 31 May 2008 14:00:24 -0500 Subject: Hylafax review issues In-Reply-To: <48418990.7090307@hhs.nl> References: <48414CCD.4010401@hhs.nl> <48418990.7090307@hhs.nl> Message-ID: >>>>> "HdG" == Hans de Goede writes: HdG> Well the question here IMHO is not so much how to name the HdG> package as it is which fork to package, making them parallel HdG> installable will be very hard todo and AFAIK we don't want HdG> conflicting packages. I agree that it would be very difficult to make them able to be installed at the same time, but if the hylafax authors or some other interested party decided to submit their software I don't see why we'd turn them away just because someone who forked their package decided not to change the name of the binaries. HdG> I believe that hylafax+ best fits Fedora. I don't see any point in attempting to decide which of many choices fits Fedora; hylafax+ is simply the only one that's been submitted. For comparison, Debian and Ubuntu don't seem to ship hylafax+; they ship hylafax and in addition split the package into -client, -server and -doc subpackages (which may be worth considering here). Gentoo has ebuilds for both hylafax and hylafax+ named accordingly. I'm not sure how to check Suse. Also of some importance, I think, is the fact that you can visit hylafax.org and download source and binary packages for Fedora (up to F7 at least) and they're named, you guessed it, "hylafax". I've no clue why they haven't submitted them to Fedora proper, but the folks who do (or maybe sponsor) that packaging work actually request that the hylafax+ package be named "hylafax+". http://www.hylafax.org/content/Fedora_Packages - J< From j.w.r.degoede at hhs.nl Sat May 31 19:08:25 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 31 May 2008 21:08:25 +0200 Subject: Hylafax review issues In-Reply-To: References: <48414CCD.4010401@hhs.nl> <48418990.7090307@hhs.nl> Message-ID: <4841A229.3010808@hhs.nl> Jason L Tibbitts III wrote: >>>>>> "HdG" == Hans de Goede writes: > > HdG> Well the question here IMHO is not so much how to name the > HdG> package as it is which fork to package, making them parallel > HdG> installable will be very hard todo and AFAIK we don't want > HdG> conflicting packages. > > I agree that it would be very difficult to make them able to be > installed at the same time, but if the hylafax authors or some other > interested party decided to submit their software I don't see why we'd > turn them away just because someone who forked their package decided > not to change the name of the binaries. > > HdG> I believe that hylafax+ best fits Fedora. > > I don't see any point in attempting to decide which of many choices > fits Fedora; hylafax+ is simply the only one that's been submitted. > > For comparison, Debian and Ubuntu don't seem to ship hylafax+; they > ship hylafax and in addition split the package into -client, -server > and -doc subpackages (which may be worth considering here). > > Gentoo has ebuilds for both hylafax and hylafax+ named accordingly. > > I'm not sure how to check Suse. > > Also of some importance, I think, is the fact that you can visit > hylafax.org and download source and binary packages for Fedora (up to > F7 at least) and they're named, you guessed it, "hylafax". I've no > clue why they haven't submitted them to Fedora proper, but the folks > who do (or maybe sponsor) that packaging work actually request that > the hylafax+ package be named "hylafax+". > http://www.hylafax.org/content/Fedora_Packages > Hmm, I don't see them requesting that anywhere, or have you been in direct contact with them? Anyways, yes there are some arguments to call the package hylafax+. to be honest, here is whats in my mind the best solution: call hylafax+ package hylafax+ call hylafax original package (if we get one ever) hylafax.org Don't call any package ever hylafax as with all the forks thats to ambigious. Make hylafax+ provide hylafax for easy install, dunno what todo if we get a hylafax.org too, but lets worry about that later. Now we need to sell this to the submitter of the package though. Regards, Hans From a.badger at gmail.com Sat May 31 20:10:27 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 31 May 2008 13:10:27 -0700 Subject: Hylafax review issues In-Reply-To: References: Message-ID: <4841B0B3.1010300@gmail.com> Jason L Tibbitts III wrote: > One of the oldest review tickets still open is > https://bugzilla.redhat.com/show_bug.cgi?id=188542, for the fax server > hylafax. Earlier this month I picked this up an attempt to try and > shepherd it through the process, but I'm stuck on a couple of issues > and the submitter does not seem to be willing to address them > satisfactorily. Maybe I should just say "hell no" and drop the > review, but I guess my objections could be wrong so I figured I'd try > to start some discussion. > > Issue one is the name: There are multiple pieces of software claiming > to be hylafax. There's the software at hylafax.org, and then there's > the package at hylafax.sourceforge.net, where it is called > "hylafax+". I quote: > The "+" means that it is better. > > There's also an "enterprise" version from ifax.com. The second > version, which upstream calls itself "hylafax+" is the one being > submitted, but the submitter argues against using that name (see > comment 38): > However, my suggestion would follow what I've said above about the > Apache http server. The distinction of the "+" will mean very > little to Fedora users (and in-fact may make the package > more-difficult to identify) unless there is more than one HylaFAX > package being distributed by Fedora (say, for example, separate > "hylafax+" and "hylafax.org" packages). > > Anyone else agree with that reasoning? What about using > Provides: hylafax > until the hylafax.org package makes it into the distro (assuming > someone actually wants to submit it)? > From reading the review top to bottom I think Lee is willing to name the Fedora package hylafax+, just not the upstream tarball. I don't know why he hasn't done that yet except perhaps no one has said, "yes please do it that way". I would okay the Provide: hylafax as long as there's no other hylafax in the distro. Once there is we'd have to decide what to do -- alternatives for postfix uses full paths to binaries, MTA,server(smtp), smtpd, smtpdaemon. "sendmail" is not provided. Perhaps hylafax.org could be added as hylafax.org similar to xorg and openoffice.org and "hylafax" can be equivalent to sendmail's generic provides. > The second issue is an FHS violation: several directories are > installed under /var/spool which contain things that aren't really in > the spirit of /var/spool. There's a /var/spool/hylafax/bin directory > which, you guessed it, contains executables, a > /var/spool/hylafax/config directory containing config files, and > /var/spool/hylafax/etc containing other, different config files. > > Here's what the submitter has to say (see comment 83): > While the vast majority of HylaFAX binaries and their respective > configuration files are installed outside of /var/spool/hylafax, > those three directories (etc, bin, and config) are configuration > files and configuration utility scripts, etc., that control how the > spools are handled. > > Due to the way that HylaFAX daemons operate it would be extremely > cumbersome (if not impossible - as in the case of a chroot) for > these to be elsewhere. They're very much like the configuration > files that LPRng had under /var/spool/lpd. > > So, that's my argument. I hope that it's acceptable. But if it's > not... unfortunately there's not much that I am willing to do about > it. > > Now, lprng isn't in the distro and I really don't think it would have > passed review like that, so I can't buy that as an argument. > "cumbersome", well, too bad I guess. I'm not sure about a chroot. I > mean, just fix the code to look elsewhere. How hard could it be? > This one's much harder. It must be fixed. I took a look at the Debian package (they have hylafax.org and not hylafax+) and they do a copy on startup of the config files. that's not ideal but it's similar to the symlink idea. The Debian package doesn't mention the binaries so I assume they remain in /var/spool. This only addresses one concern of the FHS, though: that config files have a canonical place on the filesystem for users to find them. Three other programs I know we ship that have chroot operation are postfix, scponly, and bind: postfix does not ship with a chroot configuration in Fedora. In order to enable the chroot, you have to change the configuration file. The instructions will place the chroot in the /var/spool/postfix directory. You have to copy the files that the programs need to operate in the chroot jail yourself and maintain them as updates come out. scponly is similar. It doesn't have any specific directory by default so you can set the chroot to be any set of directories on the system but you still have to build and maintain the chroot yourself. bind has a package bind-chroot that sets up in /var/named/chroot. It includes a new copy of the conf files, data directories, etc. These are separate from the files that come with the normal bind package. Based on these existing packages the right thing to do in Fedora seems to be: follow the FHS even if it prevents chroots. If the author of the package wants chroots for Fedora, supply a subpackage or a script that sets up and maintains the chroot. > But even if, it's too hard to fix, what about a few symlinks? (To > somewhere under /usr/libexec for the bin stuff, and somewhere under > /etc for for config and etc directories.) Do three symlinks violate > the FHS significantly enough to cause issues? My understanding is > that this should be OK with chroots (as long as the links are > relative.) And how does all of this square with selinux? > Yeah, need an SELinux person to weigh in here. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From valent.turkovic at gmail.com Sat May 31 20:14:10 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Sat, 31 May 2008 22:14:10 +0200 Subject: Fedora 10 and flash? In-Reply-To: <604aa7910805270434n58ead5b4sed85dec5c48aa832@mail.gmail.com> References: <64b14b300805270358m21391353kb3e963ebfa054c4a@mail.gmail.com> <604aa7910805270434n58ead5b4sed85dec5c48aa832@mail.gmail.com> Message-ID: <64b14b300805311314g27d7313ag828c726280d983e6@mail.gmail.com> On Tue, May 27, 2008 at 1:34 PM, Jeff Spaleta wrote: > On Tue, May 27, 2008 at 2:58 AM, Valent Turkovic > wrote: >> Hi, I must share this report with you. >> I don't use Ubuntu but I installed it on one PC in a lab for students >> and kids to learn using it (we have half Fedora and half Ubuntu lab). >> I opened Firefox and went to www.redhatmagazine.com and immediately I >> got a pop up window with a choice to install Adobe Flash, Swhdec or >> Gnash plugin. I was amazed how well this worked and that I had a >> choice to pick any one plugin that I believe it better. >> I know about Fedora's upstream mentality but I must take my hat to >> Ubuntu devels for making their "Ubuntu plugin service" work great. I >> know that this is what Mozilla should have made but with their track >> for supporting linux isn't the best one. > > > Are you volunteering to create the necessary firefox extension and the > plugin finder service implementation which mimics what Ubuntu is > doing? Can you find the code that implements the service as they > provide it for review? Until we know how they do it, and what data > they use to do it, we don't really have a starting point worth talking > about as to whether we can do what they do. I would have some > concerns about running a central Fedora service, because any service > Fedora would run would not be able to point at or reference a 3rd > party repository at all..which would sort of defeat the point i think. > > I've also already had conversations with upstream Mozilla people > concerning enhancing the upstream plugin finder... upstream > contribution is welcome... its just a matter of people working with > them. > > I'm not even sure we would need to run a service actually, if a client > side firefox extension could intercept the plugin request and > translate it into a packaging provides to send to packagekit. This is > something to bring up with the packagekit developers. > > Regardless of whether this was upstream code or a Fedora specific > extension or service... > someone who cares about this would need to step forward to work on it > or it's not going to go anywhere. > > -jef > https://wiki.ubuntu.com/FlashExperienceIntrepid Have you maybe also talked with Ubuntu devels that made Ubuntu "Plugin finder service" ? Maybe they are willing to contribute their code and expertise to upstream Mozilla for this ? Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From pbrobinson at gmail.com Sat May 31 21:16:10 2008 From: pbrobinson at gmail.com (Peter Robinson) Date: Sat, 31 May 2008 22:16:10 +0100 Subject: building mozilla Prism on Fedora In-Reply-To: References: Message-ID: <5256d0b0805311416q7e38cd6ewfefdaea62af3031@mail.gmail.com> > I'm trying to build mozilla prism trunk using fedora dependencies > (xulrunner etc). I have no experience building an xulrunner apps and > using the mozilla buildsystem before. I tried following this > http://developer.mozilla.org/en/docs/Creating_XULRunner_Apps_with_the_Mozilla_Build_System > (replacing the sdk tarball with its rpm package equivalent) but failed > miserably. > > Can somebody point me to some site that i can read to get me on the > right path? or maybe some clues?. I really want prism on fedora, but > so far nobody seems to have packaged it .. I have it building OK but the installing bit is a bit weird. I was going to finish up a package and submit it next week. It might be a bit of a hack but I thought it might be a start for the basis of a package for some feedback. Cheers, Peter From bpepple at fedoraproject.org Sat May 31 21:30:37 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sat, 31 May 2008 17:30:37 -0400 Subject: FESCo election delay Message-ID: <1212269437.4837.11.camel@kennedy> Hi all, At Thursday's FESCo meeting, it was decided to delay the upcoming FESCo election since we are working on defining what FESCo's role/responsibility will be in the future. Until this is finished, we felt that it didn't make sense to run the election since candidates expectations of FESCo's role might be different than what it evolves into. We're hoping this will be resolved fairly soon, and we'll send out an announcement on the decision and when the new election will be held. If anyone has any questions, don't hesitate to contact me. Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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: 197 bytes Desc: This is a digitally signed message part URL: From tgl at redhat.com Sat May 31 21:39:05 2008 From: tgl at redhat.com (Tom Lane) Date: Sat, 31 May 2008 17:39:05 -0400 Subject: Fedora x86_64 rawhide rebuild in mock status 2008-05-27 In-Reply-To: <20080531072422.A1480@humbolt.us.dell.com> References: <20080531072422.A1480@humbolt.us.dell.com> Message-ID: <8886.1212269945@sss.pgh.pa.us> Matt Domsch writes: > Fedora Rawhide-in-Mock Build Results for x86_64 > ... > libjpeg-6b-41.fc9 (build/make) tgl This appears to be a newly-introduced autoconf bug: https://bugzilla.redhat.com/show_bug.cgi?id=449245 which very possibly has broken a few other packages besides mine. I could add a patch to work around it, but unless Karsten rejects 449245 as not-a-bug I'm disinclined to do so. There's no policy expecting maintainers to put in short-term workarounds for toolchain bugs is there? regards, tom lane From rodd at clarkson.id.au Sat May 31 23:13:15 2008 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Sun, 01 Jun 2008 09:13:15 +1000 Subject: no updates? In-Reply-To: <20080530113226.bfa82b4c.mschwendt@gmail.com> References: <1212136423.2425.21.camel@choeger6> <20080530113226.bfa82b4c.mschwendt@gmail.com> Message-ID: <1212275595.6925.42.camel@localhost.localdomain> On Fri, 2008-05-30 at 11:32 +0200, Michael Schwendt wrote: > On Fri, 30 May 2008 10:33:43 +0200, Christoph H?ger wrote: > > > Hi, > > Wrong list? You seem to refer to F9 => fedora-list not > fedora-devel-list. > > > since some days I get absolutely no updates. > > Are they available on your favourite mirror already? > Or do you use the mirrorlist? I've had this same problem a couple of times. You'll see updates coming in in email to fedora-test-list and then after a couple of days you'll notice that the updates never happened. If I then yum clean all the updates work as soon as I run yum update manually. I think there might be a bug here, but haven't got any idea how to test for it, and haven't got around to reporting it either. R. -- "It's a fine line between denial and faith. It's much better on my side"